dcc823-2-10

UFMG - ICEx - DCC

DCC823 – Engenharia de Software

1o. Semestre de 2011

Aulas: 3as e 5as. 07:30-09:10 sala 2013 Notas das Provas

Segundo trabalho:

Enunciado e datas

Template

Finalização do segundo trabalho:

Entregar um relatório de no máximo 3 páginas, até o dia 20/06/2011, seguindo este formato;

>>>>Trabalho 1

Primeiro trabalho de DCC823

Você deve preparar um artigo do tipo levantamento ("survey") onde

você deve relatar como que a comunidade de investigação relacionada

à linguagem UML 2.x está tratando o elemento de

modelagem "associação" no contexto da relação com a linguagem Java.

O seu artigo será avaliado, em primeiro lugar,

(a menos de erros sintáticos!) pela articulação dos conceitos que devem

ser extraídos de artigos de qualidade. Ou seja, você deve demonstrar

(1)capacidade de selecionar bons artigos e (2)capacidade de escrever um texto

que articula os conceitos desenvolvidos (ou não!) em cada um dos artigos

selecionados.

Serão levados em consideração os aspectos que são discutidos abaixo

(nesta página WWW)

relativos a trabalhos que foram desenvolvidos em anos anteriores da disciplina.

Nome do artigo a ser elaborado é:

----------------------

Um estudo da literatura sobre Associação no contexto da transcrição

entre diagramas de classe da UML 2 e a linguagem Java

---------------------

Para contextualizar ainda mais este trabalho sugiro que

seja considerado o seguinte artigo (dentre outros):

-------------

Dominik Gessenharter

Mapping the UML2 Semantics of Associations

to a Java Code Generation Model

Models'2008

LNCS 5301, pp. 813-827, 2008

Springer-Verlag

-----------

Data de Entrega 12/abril/2011 – Preferencialmente o artigo deve ter no máximo 6 páginas.

	Mat		TP1
1	2011653856	ALCEMIR RODRIGUES SANTOS	14
2	2011663177	DANILO ARAUJO PORTELA
3	2011702377	DARLEY WILSON DIAS
4	2011702466	HEIDER RICARDO MACIEL
5	2011669701	JULIANA PADILHA	12
6	2011702555	MARCELO LEONARDO SANT'ANA DE ALMEIDA	12
7	2011702601	MATHEUS PEREIRA AMARAL MOREIRA
8	2011702660	RODRIGO DE LIMA PINHEIRO	12
9	2011702687	ROSANA MOREIRA MARTINS	12
10	2011702709	SIMONE ISABELA DE RESENDE XAVIER	12
11	2011702725	THIAGO MARTINS DE VASCONCELOS

Artigo SLR

>>>> Trabalho

Uma visão do uso do termo “processo” no contexto da Engenharia de Software

até as 17:00

xx/xx/2010

Observação 1: Existem muitos estilos de apresentação de citações e referências. Tem se tornando comum um estilo “concreto” de citações onde os autores usam a citação (numérica ou alfabetica) como se fosse um substantivo:

Em [1] é apresentado .... ou //evitar

Em [Fulano et al, 2005] é apresentado ... //evitar

[2] afirma que bla bla. ou //evitar

[Ciclano & Beltrano, 2006] afirmam que .... //evitar

Esta abordagem é apresentada por [3]. ou Esta abordagem é apresentada por [Pessoa, 2008]. //evitar

O nosso livro texto, infelizmente, apresenta este “estilo”; por exemplo na página 443 há várias instâncias:
[Royce98] argumenta que...

Deve ser usada uma abordagem conservadora no uso de citações onde a citação não é “substantivada”:

Exemplos:

Fulano e outros apresentam bla bla [1]. ou Fulano e outros [Fulano et al. 2005] apresentam ...

Ciclano e Beltrano afirmam que bla bla [2]. ou Ciclano e Beltrano afirmam que .... [Ciclano& Beltrano, 2006]

Esta abordagem é discutida no trabalho de Fulano[3]. ou

Esta abordagem é apresentada no trabalho de Pessoa [Pessoa, 2008].

O exemplo do nosso livro texto (página 443) ficaria:

Royce [Royce98] argumenta que ...

Observação 2:O seu artigo será valiado principalmente em função de (i)não conter “afirmações não triviais” sem citar referência adequada e (ii) ter citações adequadas para “afirmações não triviais”. Em alguns artigos aparece uma afirmação seguida de uma ou mais citações para as referências, mas muitas vezes estas referências são livros ou artigos extensos! Neste trabalho as “afirmações não triviais” devem ter citações e as citações para artigos com mais de 15 páginas deverão obrigatoriamente citar a página!

Quando uma referência de mais de 14 páginas tem apenas uma citação a página pode estar na referência, exemplo

Fulano e outros [1] apresentam bla bla ...

...
[1] Fulano, F., Ciclano, C. Beltrano, B., Good article in Software Engineering, <adornos adequados>, p. 27

Mas quando a referência de mais de 14 páginas tem mais de uma citação a página deve estar na citação, exemplo:

Fulano e outros [1, p. 27] apresentam bla bla...
Fulano e outros[1, p. 35] discutem com ...
...
[1] Fulano, F., Ciclano, C. Beltrano, B., Good article in Software Engineering, <adornos adequados>

Observação 3: Um aspecto que será avaliado é a capacidade do aluno de identificar e compatibilizar o uso de diferentes termos para um mesmo conceito e o uso de um mesmo termo para diferentes conceitos. Exemplos: alguns autores usam para um mesmo conceito os termos “falha” e “defeito”. Alguns autores usam o termo “ferramenta de medição” para designar “métodos da estatística” enquanto para outros autores esta mesma expressão significa “programas de computador cujo objetivo é apoiar o processo de medição”. O artigo deve ser particularmente cuidadoso com os termos “processo”, “projeto”, “desenho”, “método”, “metodologia” dentre outros.

------------------

Sugestões de sítios:

ieeexplore.ieee.org

www.acm.org

scholar.google.com

periodicos.capes.gov.br

elos sortidos

SLR_SE_SLR

GREY_Literature

REV

Livro texto:

Engenharia de Software
Fundamentos, Métodos e Padrões
Terceira Edição
Wilson de Pádua Paula Filho
LTC - 2009

Sítio do livro:
http://www.dcc.ufmg.br/~wilson

Avaliação:
Provas, Trabalhos Práticos, testes surpresa, listas.

Material extra:

-Cuidado com os falsos cognatos! A tradução de "requirements" é "requisitos"!
-Cuidado com os falsos cognatos:
a tradução de "Scenario" *não* é "cenário";
"Scenario" é sinônimo de "script"="roteiro";

Os dois livros básicos sobre UML:

The Unified Modeling Language User Guide
2^nd Edition 2005
Grady Booch, James Rumbaugh, Ivar Jacobson
Addison Wesley

Unified Modeling Language Reference Manual
2^nd Edition 2004
James Rumbaugh, Ivar Jacobson, Grady Booch
Addison Wesley

O livro básico do Processo Unificado:
The Unified Software Development Process
Ivar Jacobson, Grady Booch, James Rumbaugh
Addison Wesley

O aluno de Pós-graduação deverá seguir o conteúdo da disciplina de forma similar ao aluno de graduação; Avaliação do aluno de pós será feita através de provas, testes surpresa, listas, artigos, etc mas sem a exigência de trabalho prático em grupo, que é exigido dos alunos de graduação. Ao invés de trabalho prático em grupo o aluno de pós faz trabalhos individuais.

O aluno de Pós-graduação deverá elaborar, para entrega no final do semestre, um artigo. As atividades de elaboração deste artigo irão valer boa parte dos 60 pontos de trabalhos e as provas da disciplina valerão 40 pontos. O aluno que quiser substituir a elaboração do artigo final por alguma outra atividade deve procurar o professor até o dia xx.

O artigo final

O objetivo principal deste trabalho *não* é avaliar o conhecimento que o aluno tem de algum assunto, o objetivo principal deste trabalho é avaliar o conhecimento que o aluno tem dos bons artigos sobre os assuntos a serem discutidos.

O tema base será comum para todos os alunos; título do artigo a ser elaborado:

-----------------------

>>>>>>>>Uma visão do uso do termo “processo” no contexto da Engenharia de Software<<<<<<<

---------------------------

Você deve descobrir os bons artigos (bons autores) e discutir o significado do termo “processo” (adjetivado ou não!)

e mostrar alguns exemplos ou instanciações de cada termo. Exemplos de usos que não podem faltar: “processo de software” um exemplo de processo de software é o RUP (“processo abstrato de software”?). Em casos excepcionais o professor irá aceitar que o aluno desenvolva um tema conforme era comum em semestres passados e que é discutido abaixo. Além deste artigo que deverá ser entregue no final do semestre, deverão ser entregues trabalhos intermediarios que serão detalhados em sala.

Primeira Entrega: até xx/xx/2011, 17:00

Devem ser entregues 4. 5...no máximo 6 páginas de um artigo com o seguinte título:

Capacidade de Processo no Contexto do CMMI-DEV<<<<<<<<<<<<<<

Você deve descobrir bons artigos e discutir (usando estes artigos!) o conceito de capacidade de processo no CMMI-DEV.

Se você não conseguir artigos então fale que não conseguiu artigos e que você teve que usar livros.

Se você não conseguir livros então fale que não conseguiu livros e que você teve que ler e interpretar o Relatório Técnico do

CMMI-DEV:

http://www.sei.cmu.edu/reports/06tr008.pdf (CMMI for Development Version 1.2)

Será avaliado, principalmente, os artigos citados na elaboração do artigo.

entrega: xx/xx/2011 17:00

Devem ser entregues no máximo 5 páginas baseadas no Guia Geral do MPS.BR que pode ser encontrado no sítio WWW do Softex,

nos relatórios técnicos do CMMI e “boas’ referências que o aluno deve encontrar.

Deverá ser entregue um “artigo do tipo resumo” explicando a relação entre as normas ISO15504, ISO12207, e os modelos MPS.BR e o modelo CMMI-DEV, mas este “resumo” deverá dar ênfase para a noção de “processo”, em particular para a questão de “processo de desenvolvimento de software”, ou seja o “resumo não deve ter o carater geral que o CMMI e a ISO-15504 têm seguido. O título do artigo deve ser: “O Software e o Sistema segundo as normas ISO-15504 e ISO-12207 e segundo os modelos CMMI e MPS.BR”

Assunto da mensagem: Entrega 1 01_2010 DCC823

Formato: SBC (pdf)

Nome do arquivo anexo: primeiro nome do aluno seguido de “1” (p.ex. cristiano1.pdf, etc)

(a avaliação seguirá os aspectos discriminados no texto abaixo)

Segunda entrega: xx/xx/2010 17:00

Devem ser entregues no máximo 5 páginas baseadas nas seguintes publicações:

-----------------------

A ênfase agora é na questão de SPI (software Process Improvement).

O Título do artigo deve ser “Melhoria do Processo de Software”.

A entrega deve obedecer o modelo da primeira entrega (mudando onde deve ser mudado!)

Não se esqueça que o artigo é avaliado na extensão da afirmações, citações, referências, e não na capacidade do aluno fazer afirmações sem referência!

A elaboração deste trabalho pressupõe que o aluno vai *ler* artigos; saber diferenciar o que é um bom artigo e o que é um bom veículo (conferência, periódico etc). Porque um periódico é Qualis A, Qualis B, Qualis C? Porque um artigo não é categorizado pela CAPES?

Critério da área & informações:

http://qualis.capes.gov.br/webqualis/ (?)

Existe um documento do critério 2004-2005-2006 p/ Ciência da Computação e deve ser aprovado um documento 2007-2008-2009.

Outras centenas de classificações& discussões podem ser encontradas na internet.

O objetivo deste trabalho é familiarizar o aluno com alguns dos tópicos da metodologia científica, mais particularmente com a questão de como elaborar um artigo científico baseado no contéudo de outros artigos de forma a trazer uma contribuição que seja significativa e diferente das contribuições dos artigos que serviram de base para a elaboração do trabalho.

Um dos objetivos principais é o aluno dar evidências de que sabe consultar a literatura considerada de qualidade e sabe elaborar a partir desta literatura um pensamento analítico. Se você encontrar um artigo com “requisitos” (veja a frente) já prontos então possivelmente o tema deve ser evitado: se você não citar este artigo então não foi feita uma boa pesquisa bibliográfica, se você citá-lo deve esclarecer qual foi a diferença de enfoque!

O conteúdo do artigo deverá tratar de temas da Engenharia de Software, conforme, por exemplo, discutido no SWEBOK. Ao final do trabalho o aluno, além do aprendizado, produzirá um catálogo de requisitos (conceito explicado abaixo) relacionado a algum tópico da área de Engenharia de Software.

Um outro aspecto importante dos objetivos é que o aluno trabalhe com artigos recentes, deste ano, do ano passado, do ano retrasado... não é proibido ter referências dos anos 90 ou anos 80, mas faz parte dos objetivos que o aluno trabalhe com artigos recentes.

Em termos de “empiricismo” na Engenharia de Software é como se o aluno fosse conduzir uma avaliação empírica relacionada a um certo tópico (o aluno tem que negociar com o professor o tópico!). As categorizações mais próximas seriam “desktop survey” ou “laboratory experiment”, entretanto focalizaremos no artefato produzido no levantamento (ou experimento).

A elaboração do artigo deverá obedecer a um modelo pré-estabelecido. O artigo deve levantar “requisitos” (ou “modelo de referência”, veja à frente) de processos ou métodos ou de ferramentas de alguma área da Engenharia de Software. O artigo elaborado pelo aluno deve se espelhar no seguinte artigo base:

Requirements for Requirements Management Tools (Requisitos de Ferramentas de Gestão de Requisitos)

Este artigo investiga os requisitos relacionados com ferramentas de Gestão de Requisitos na área da industria automotiva , de aviação e de defesa. Conforme discutido abaixo este artigo não tem exatamente o mesmo esquema de conteúdo mas deve ficar próximo.

O artigo *não* consiste na elaboração de um documento de requisitos (SRS, ERSw). Um documento de requisitos tem o objetivo de especificar um produto para ser implementado e este artigo não consiste em especificar um processo, produto ou serviço. A idéia é que o artigo discuta necessidades, desejos, expectativas e metas de algumas partes interessadas (“stakeholders”) em um certo tema da área de Engenharia de Software. Um exemplo sobre a diferença entre o artigo e um documento de requisitos: em um documento de requisitos de software os interessados têm que decidir entre requisitos conflitantes, neste artigo podem ser apresentados requisitos conflitantes e deve-se simplesmente discutir as vantagens e desvantagens das diferentes opções. Na avaliação do artigo o termo “requisitos” deverá poder ser substituído por “modelo de referência”.

Um aspecto que também será avaliado é a capacidade do aluno de identificar e compatibilizar o uso de diferentes termos para um mesmo conceito e o uso de um mesmo termo para diferentes conceitos. Exemplos: alguns autores usam para um mesmo conceito os termos “falha” e “defeito”. Alguns autores usam o termo “ferramenta de medição” para designar “métodos da estatística” enquanto para outros autores esta mesma expressão significa “programas de computador cujo objetivo é apoiar o processo de medição”

O artigo do aluno *não* tem que obedecer a estrutura e organização do artigo base (Hoffman e outros), uma boa diferença é a exigência de uma Seção 5 onde devem ser enumerados “produtos ou instâncias” mais representativos do tema escolhido juntamente com uma discussão sobre como fica o atendimento dos requisitos enumerados na Seção 3 Para exemplificar esta Seção 5 considere que o artigo é sobre Requisitos de Ferramentas de Gerência de Projetos, neste caso a seção 5 deve discutir como que o MS-Project, Spring, Xplanner dentre outros atendem aos requisitos listados. Outro exemplo: para um artigo denominado “Requisitos de Processos de Desenvolvimento de Software” a seção 5 deve discutir como que o UP, RUP, Praxis, Mbase, OPEN, etc atendem aos requisitos listados. No caso de um artigo “Requisitos de técnicas de geração automática de testes” talvez não faça sentido utilizar na Seção 5 produtos, daí utilizarmos o termo “instâncias”, neste caso podem ser utilizados conceitos, idéias, entidades que não são produtos comerciais.

. Considerando que o artigo descreve “Requisitos de X”, deve ser obedecida a seguinte organização:

1-Introdução

2-Modelos e caracteristicas de X

3-Requisitos

4-Aspectos práticos e operacionais

5-Avaliação do comprometimento de algumas instâncias de X

5Conclusão

Se você quiser seguir outra organização negocie antecipadamente com o professor.

Alguns *exemplos* de títulos são:

Requisitos de Cooperação em ambientes de suporte aos requisitos de produtos de software

Requisitos de Processos colaborativos em ambientes de suporte aos requisitos de produtos de software

Requisitos de Técnicas de Colaboração em ambientes de suporte ao desenho de software.

Requisitos de Ferramentas de ambientes de suporte ao desenho colaborativo de software.

Requisitos de Engenharia de Ida e volta de desenvolvimento de Software (Requirements for Round-trip Software Development)

Requisitos de Ferramentas de Engenharia de Ida e Volta de desenvolvimento de Software

Requisitos de Metodologias de Teste de software

Requisitos de Ferramentas de Teste de Software

Requisitos de Metodologias e Ferramentas de Teste de Software

Requisitos de desenvolvimento de software baseado em Serviços Web utilizando a linguagem Java

Requisitos de personalização de processos para o uso de MDD.

Requisitos de modelos de maturidade no desenvolvimento de software para processos ágeis sob a perspectiva do desenvolvimento, cadastro e monitoração de requisitos.

Outras sugestões de artigos:

Requirements for an educational software development process

Requirements for Information Systems Model Based Testing

Calendário:

Ao invés de entregar todo o artigo pronto no final da disciplina você deverá fazer entregas parciais conforme detalhado abaixo. O professor poderá divulgar revisões parciais mas isto não é garantido. Os únicos pontos garantidos são a negociação para o tema do artigo e a avaliação final, portanto é possível que você tenha que fazer a entrega 3 sem saber os problemas da entrega 2, ou tenha que fazer a entrega 4 sem saber os problemas da entrega 3.

Observação: Em todas as entregas o estilo do texto do artigo deve ser como se todo o conteúdo estivesse pronto. O artigo deve ser escrito como se todo o trabalho já estivesse feito, portanto não devem ser usados verbos no futuro (irá, será etc).

Confronte os estilos:

(i) “este artigo apresenta um catálogo de requisitos”

(ii) “este artigo apresentará um catálogo de requisitos”

Deve ser utilizada a opção (i).

Observação: Existem muitos estilos de apresentação de citações e referências. Tem se tornando comum um estilo “concreto” de citações onde os autores usam a citação (numérica ou alfabetica) como se fosse um substantivo:

Em [1] é apresentado .... ou //evitar

Em [Fulano et al, 2005] é apresentado ... //evitar

[2] afirma que bla bla. ou //evitar

[Ciclano & Beltrano, 2006] afirmam que .... //evitar

Esta abordagem é apresentada por [3]. ou Esta abordagem é apresentada por [Pessoa, 2008]. //evitar

Deve ser usada uma abordagem conservadora no uso de citações onde a citação não é “substantivada”:

Exemplos:

Fulano e outros apresentam bla bla [1]. ou Fulano e outros [Fulano et al. 2005] apresentam ...

Ciclano e Beltrano afirmam que bla bla [2]. ou Ciclano e Beltrano afirmam que .... [Ciclano& Beltrano, 2006]

Esta abordagem é discutida no trabalho de Fulano[3]. ou

Esta abordagem é apresentada no trabalho de Pessoa [Pessoa, 2008].

----------------------------------------------------

Negociação – Mensagens com assunto :

negociacao de tema 02_2009 DCC823

até o dia xx/xx/2009 (sem anexos!)

Deverá haver acerto com o professor, através de correio eletrônico, sobre o assunto do artigo (Não envie artigos como anexos!) somente o nome e autores) Deverão ser enviados:

-Título do artigo

-Quais serão as contribuições do artigo?

-Quem são as partes interessadas (stakeholders) que se beneficiarão com o catalogo de requisitos?

-De onde virão os requisitos?

O mais importante é a “Base de Referências”: lista dos artigos que servirão de base para discussão dos requisitos. Somente a primeira entrega poderá ter referências que não sejam citadas! Todas as demais entregas (2, 3 e 4) deverão obedecer aos requisitos:

-Toda citação está presente nas referências.

-Toda referência é citada pelo menos uma vez no texto (não existe referência sem citação)

------------------------------------------------------

I- Artigo no formato SBC (entregar PDF, preparar Word ou LaTex, qualquer problema de formato deve ser negociado antecipadamente com o professor) contendo pelo menos o título, introdução e as referências que servirão de base para apresentação dos requisitos. Valor 10%, até dia xx/xx/2009

O artigo “requisitos de X” pode apresentar os conceitos relacionados a “X”, mas este *não* é o foco do artigo! O artigo deve focalizar no catalogo de requisitos. O artigo não tem que copiar a estrutura do artigo base, mas pode se “inspirar” no artigo base e deve dar a ele o devido crédito!!

Enviar o artigo como um anexo de arquivo PDF de mensagem para rodolfo [em] dcc.ufmg.br com o seguinte assunto:
Entrega 1 xx_20xx DCC823

Se o primeiro nome do aluno é Fulano o arquivo deve se chamar:
fulano1.pdf

(isto será avaliado!)

Resultados parciais da negociação:

Aluno	Tema	Entrega1	Forma

O seu artigo será valiado principalmente em função de (i)não conter “afirmações não triviais” sem citação adequada e (ii) ter citações adequadas para “afirmações não triviais”. Em alguns artigos aparece uma afirmação seguida de uma ou mais citações para as referências, mas muitas vezes estas referências são livros ou artigos extensos! Neste trabalho as “afirmações não triviais” devem ter citações e as citações para artigos com mais de 15 páginas deverão obrigatoriamente citar a página!

Sugestões de sítios:

ieeexplore.ieee.org

www.acm.org

scholar.google.com

periodicos.capes.gov.br

II- artigo contendo todas as seções com conteúdo inicial, valor 20% xx/xx/20xx

Neste ponto espera-se que a Seção 3 já liste alguns requisitos (2,3, 4, mais?) e que a Seção 2 defina alguns conceitos necessários e que a Seção 4 contenha alguns dos detalhes necessários e que a Seção 5 já liste alguns dos produtos ou instâncias disponíveis academicamente ou comercialmente, juntamente com uma discussão sobre o atendimento a alguns dos requisitos já considerados; A Introdução deve ser aperfeiçoada e a Conclusão deve ser iniciada, contendo pelo menos um julgamento inicial da literatura e dos produtos ou instâncias relacionados ao tema escolhido.

Mande o artigo como sendo um anexo de mensagem, com nome:
fulano2.pdf
para rodolfo [em] dcc.ufmg.br com o seguinte assunto:
Entrega 2 0x_20xx DCC823

(isto será avaliado!)

Lembre-se que “requisito” deve ter um estilo relacionado a “o que?”, junto à explicação do requisito deve vir material no estilo “como?”. Exemplificando: o requisito deve falar coisas do tipo “os dados devem estar ordenados”, junto a este requisito devem vir comentários dizendo que os dados podem ser armazenados em disco ou em memória, que o armazenamento em memória pode ser feito em arranjos, arranjos podem ser ordenados pelo método de seleção etc.

Novamente lembre-se que você não está produzindo uma ERSw(SRS)! Uma ERSw não deve ter requisitos conflitantes, no seu trabalho você pode exibir requisitos conflitantes e pode discutir critérios para resolução dos conflitos.

A avaliação levará em conta a exemplificação dos requisitos!

III- artigo contendo todas as seções, proposta inicial,, valor 30%, xx/xx/20xx

Nesta entrega ainda não é preciso listar todos requisitos relevantes, mas espera-se que uma boa parte deles esteja presente, também não é necessário listar todas as instâncias ou produtos mais relevantes, mas espera-se que os mais representativos já estejam presentes.

IV-artigo contendo todas as seções, proposta final, valor 40%, xx/xx/20xx

Observe que a avaliação da Entrega 3 não tem expectativa, dentre outros fatores, que todos os requisitos já estejam presentes e com discussão apropriada. Na avaliação da Entrega 4 espera-se que todos os requisitos relevantes estejam presentes juntamente com uma discussão bem fundamentada.

-----------------------------------------------------------------------------------

A avaliação levará em conta, principalmente, as referências que dão suporte ao desenvolvimento do tema.

A avaliação levará em conta a exemplificação dos requisitos!

O que determina “um bom artigo”?

1º. Fator: você deve ler bons artigos para poder ter um senso de apreciação e julgamento. Alguns vícios denunciam o desconhecimento da “cultura” da área:

Utilizar referências inadequadas: o autor deve saber que um relatório técnico tem menos autoridade do que uma dissertação, uma dissertação ou uma tese tem menos autoridade do que um artigo de periódico com corpo de revisores de prestígio.

Fazer afirmações sem citar uma referência apropriada. Tem autores que escrevem, sem nenhum temor, várias afirmativas sem dar referências. É difícil saber o que é pior: (i) referências inadequadas, ou (ii) falta de referências.

O artigo deve trazer exemplos que esclareçam o que está sendo discutido, por outro lado exemplos ruins ou desacoplados do contexto da discussão denunciam pouco conhecimento.

Se o artigo tiver elementos tais como figuras e tabelas explique de maneira adequada estes elementos. Alguns artigos parecem achar que o leitor tem a obrigação de decifrar e advinhar o significado de retângulos, circulos, pentágonos, linhas pontilhadas, linhas tracejadas, linhas duplas, linhas com multiplas variações de setas etc. Acredito que quando o artigo possui frases neste estilo: “A Figura 3 ilustra os conceitos discutidos”, tal artigo está, no mínimo, economizando espaço. Mas certamente muitos autores sabem a importância da boa descrição! O trecho abaixo foi extraido de um artigo onde o autor é cuidadoso:

O artigo será corrigido tanto na forma quanto no conteúdo. Cada erro de forma (ortografia, referência inexistente etc) ou afirmativa de conteúdo discutível sem contextualização e referência adequada valerá 5% da avaliação correspondente. Cada falta de aderência aos requisitos acima também implicarão em perda de 5% dos pontos. Os artigos que forem julgados de boa qualidade poderão ser submetidos a algum periódico ou evento, tendo como autores o aluno e outras pessoas que participarem da adaptação do artigo (p.ex. o professor).

Avaliação II

Aluno	Tema	Entrega2	Revisão	Nota

Os requisitos devem ser enunciados e ENUMERADOS!!!

O leitor do artigo não deve ficar olhando um pedaço de texto e ficar pensando:
“Será que isso é um requisito???”
”Será que isso ainda é alguma discussão sobre algum requisito que já apareceu e eu ainda não consegui visualizar?”
”Será que isso é alguma discussão sobre algum requisito que aparecerá em breve?”

Requisitos de interesse de quem (stakeholder!!)????

Os produtos ou instâncias devem ser enunciados e ENUMERADOS!!!

Aluno	Entrega	Revisão

Avaliação IV entrega

Aluno	Entrega	Revisão

Entrega 1:
Os principais erros estão relacionados à falta de:
1-Discutir quem está interessado nos requisitos ou mais abrangentemente quem relaciona-se com as metas, objetivos, expectativas, beneficios, necessidades, restrições,etc
2-Explicar os critérios de levantamento dos requisitos, por exemplo (i)baseado em trabalhos relacionados (dar referências), se não encontrar referências tem que arcar com o ônus de afirmar “não encontramos trabalhos que possam dar base a este requisito” , (ii)baseado em reuniões com especialistas (iii)etc.
3-Exemplificar o contexto dos requisitos apresentados.

Entrega 2:

Muitos alunos queriam fazer um artigo sobre o assunto X, mas a disciplina especifica um artigo com o título “Requisitos para Y”. Quase todos os artigos estão com sérios problemas de foco, pois o que foi feito foi simplesmente colocar um título “Requisitos para X” e não foi feito um levantamento bibliográfico adequado, e muitos estão com problema com o conceito de “REQUISITO”.

Por favor utilizem o seguinte modelo “mental”: um requisito deve descrever um desejo, uma meta, um objetivo, uma restrição das partes interessadas com relação a algo que deverá ser desenvolvido de forma a satisfazer o requisito. O requisito deve ser um texto de nível mais abstrato que apenas caracteriza um desejo, uma meta, um objetivo, uma restrição das partes interessadas. As formas de como satisfazer o requisito deve ser colocada no artigo como ilustração de como pode ser desenvolvido o requisito. Ou seja para escrever o artigo de forma adequada você tem que ter MUITO CLARO o escopo dos requisitos, além, é claro, de saber quem são as partes interessadas.

Exemplo da relação “O que?” versus “Como?”

Requisito: Os dados devem poder ser apresentados de forma ordenada.

Comentários: os dados devem estar em um arranjo e devem ser ordenados pelo método de seleção; os dados devem estar em uma lista do framework Collection e deve ser definido Comparator adequado para Collections.sort(), etc etc etc [tudo isso com referências adequadas!]