ENGENHARIA DE SOFTWARE II
ENGENHARIA DE SOFTWARE II
Simone Maria Viana Romano
Simone Maria Viana Romano
Se eu tivesse oito horas para derrubar Se eu tivesse oito horas para derrubar uma árvore, passaria seis afiando uma árvore, passaria seis afiando meu machado
meu machado (Abraham Lincoln)(Abraham Lincoln)..
2º SEMESTRE DE 2013 2º SEMESTRE DE 2013
S S S Suuuummmmáááárrrriiiioooo INFORMAÇÕES IMPORTANTES INFORMAÇÕES IMPORTANTES ... ... 7... 7 OBJETIVOS: OBJETIVOS: ... 7 ... 7 Sugestã Sugestão de Lo de L iivrvros, Revios, Revistas e Sstas e Siites tes ... 7 ... 7
Softwares Softwares ... 7 ... 7
Quant Quantidade de idade de aulaul as as ssemanais e emanais e QuanQuantitidade dade de de ffaltas pealtas perrmimi titidas das ... 7 ... 7
Abono de Abono de FF altas altas ... 8... 8
Contato Contato ... 8... 8
Avisos Avisos ... 8 ... 8
Con Con teúteúdo ddo das Aas Avalval iiaçaçõões es ... 8... 8
F F oror mma de Aa de Avalval iiaçaçãão o ... 8... 8
Di Di scsciplipl inin asas, Di, Di as as e Hore Hor áárrios que me eios que me encontrncontr o na Fo na F atec atec ... 8... 8
Er Er ros da ros da AposApostiltil a: a: ... 8... 8
TRABALHO SEMESTRAL TRABALHO SEMESTRAL ... ... ... 9... 9
TAREFA 01 - REV TAREFA 01 - REVISÃO DE ENGENHARIA DE SOFTWARE I ISÃO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5(VALOR : 0,5) ) ... 10... 10
1ºBIMESTRE 1ºBIMESTRE R REEQQUUIISSIITTOOS DS DE SE SOOFFTTWWAARRE E ... .... 1616 IMPORTÂNCIA IMPORTÂNCIA DOSDOS REQUISITOS REQUISITOS ... 17... 17
QUALIDADE QUALIDADE DOSDOS REQUISITOS REQUISITOS ... 18... 18
TIPOS TIPOS DEDE REQUISITOS REQUISITOS ... 19... 19
EXEMPLO DE REQUISITOS FUNCIONAIS EXEMPLO DE REQUISITOS FUNCIONAIS ... 20... 20
EXEMPLO DE REQUISITOS NÃO FUNCIONAIS ... 20
EXEMPLO DE REQUISITOS NÃO FUNCIONAIS ... 20
EXEMPLO DE REQUISITOS DE DOMINIO EXEMPLO DE REQUISITOS DE DOMINIO ... 20... 20
PROBLEMAS COMUNS NOS REQUISITOS ... PROBLEMAS COMUNS NOS REQUISITOS ... ... ... 2020 CLASSES DE CLASSES DE REQUISITOS REQUISITOS ... 20... 20
E ENNGGEENNHHAARRIIA DE RA DE REEQQUUIISSIITTOOS .S ... ... 2121 OBJETIVOS OBJETIVOS DADA ENGENHARIAENGENHARIA DEDE REQUISITOS ... 22REQUISITOS ... 22
TAREFA 02 - QUESTÕES DE REQUISITOS (0,5) ... 23
TAREFA 02 - QUESTÕES DE REQUISITOS (0,5) ... 23
E ELLIICCIITTAAÇÇÃÃO DE RO DE REEQQUUIISSIITTOOS ....S ... .... 2626 OBJETIVOS OBJETIVOS DADA ELICITAÇÃOELICITAÇÃO DEDE REQUISITOS ... 28REQUISITOS ... 28
PASSOS PASSOS PARAPARA AA ELICITAÇÃOELICITAÇÃO DEDE REQUISITOS REQUISITOS ... 28... 28
QUESTÕES QUESTÕES QUEQUE PRECISAMPRECISAM SER SER RESPONDIDAS RESPONDIDAS ... 29... 29
DOCUMENTAÇÃO DOCUMENTAÇÃO DODO ELICITAÇÃOELICITAÇÃO DEDE REQUISITOS ... 29REQUISITOS ... 29
IDENTIFICAÇÃO IDENTIFICAÇÃO EE ELICITAÇÃOELICITAÇÃO DEDE REQUISITOS ...REQUISITOS ... 30... 30
IDENTIFICAÇÃO DOS REQUISITOS ... IDENTIFICAÇÃO DOS REQUISITOS ... ... 30... 30
PROBLEMAS NA IDENTIFICAÇÃO DOS REQUISITOS PROBLEMAS NA IDENTIFICAÇÃO DOS REQUISITOS ... ... 3131 EXEMPLO DE DECLARAÇÃO DO PROBLEMA EXEMPLO DE DECLARAÇÃO DO PROBLEMA ... 31... 31
CARACTERÍSTICAS CARACTERÍSTICAS DADA ELICITAÇÃOELICITAÇÃO DEDE REQUISITOS... 31REQUISITOS... 31
DIFERENÇA ENTRE UMA BOA E UMA MÁ ELICITAÇÃO DE REQUISITOS ... 32
DIFERENÇA ENTRE UMA BOA E UMA MÁ ELICITAÇÃO DE REQUISITOS ... 32
TAREFA 03 TAREFA 03 – – ELICITAÇÃO DE REQUISITOS (0,5) ... 33 ELICITAÇÃO DE REQUISITOS (0,5) ... 33
TÉCNICAS PARA ELICITAÇÃO DE REQUISITOS ... TÉCNICAS PARA ELICITAÇÃO DE REQUISITOS ... ... 34... 34
ETNOGRAFIA ... 36 ETNOGRAFIA ... 36 ENTREVISTAS ... 37 ENTREVISTAS ... 37 Etapas Etapas ... 37 ... 37 Forma de Entrevistar ... Forma de Entrevistar ... 37 ... 37
Perguntas que devem ser respondidas ... Perguntas que devem ser respondidas ... ... ... 37 37 BRAINSTORMING BRAINSTORMING ... 38... 38 BRAINSWRITING BRAINSWRITING ... 39... 39 EXERCÍCIOS ... EXERCÍCIOS ... ... 4040 JAD ... 41 JAD ... 41 DESENVOLVIMENTO DESOFTWARE ... 14 DESENVOLVIMENTO DESOFTWARE ... 14
E
ETAPAS PARA PREPARAR UMA REUNIÃOTAPAS PARA PREPARAR UMA REUNIÃOJAD... 41JAD... 41
PREPARAÇÃO PREPARAÇÃO ... ... 4242 SESSÃO ... 46 SESSÃO ... 46 REVISÃO REVISÃO ... 51... 51 PAPEIS PAPEIS DEDE CADACADA UMUM DENTRODENTRO DADA REUNIÃO ... 52REUNIÃO ... 52
O CLIENTE (PATROCINADOR) ... O CLIENTE (PATROCINADOR) ... ... ... 5252 ENGENHEIRO DE SOFTWARE ENGENHEIRO DE SOFTWARE... 52... 52 EQUIPE ... EQUIPE ... 53... 53 OBSERVADOR OBSERVADOR ... 53... 53 DOCUMENTADOR ... DOCUMENTADOR ... 53... 53
LÍDER DE SESSÃO OU FACILITADOR LÍDER DE SESSÃO OU FACILITADOR ... 53... 53
FIGURINHAS DIFÍCIEIS NA REUNIÃO ... 54
FIGURINHAS DIFÍCIEIS NA REUNIÃO ... 54
TAREFA 04 TAREFA 04 – – TECNICA JAD (1,0) TECNICA JAD (1,0) ... 57 ... 57
ESPECIFICAÇÃO DE ESPECIFICAÇÃO DE REQUISITOS REQUISITOS ... ... 58... 58
M MODELO DE ESPECIFICAÇÃO DE REQUISITOSODELO DE ESPECIFICAÇÃO DE REQUISITOS... 58... 58
PASSOS PARA ESPECIFICAR OS REQUISITOS PASSOS PARA ESPECIFICAR OS REQUISITOS ... 58... 58
VISÃO E ESCOPO VISÃO E ESCOPO ... 60 ... 60
EXERCÍCIOS ... EXERCÍCIOS ... ... 6060 TAREFA 05 TAREFA 05 – – ESPECIFICAÇÃO DE REQUISITOS (0,5) ... 61 ESPECIFICAÇÃO DE REQUISITOS (0,5) ... 61
VERIFICAÇÃO E VALIDAÇÃO DE REQUISITOS ... 62
VERIFICAÇÃO E VALIDAÇÃO DE REQUISITOS ... 62
TIPOS TIPOS DEDE DEFEITO ... 63DEFEITO ... 63
OMISSÃO ... 64 OMISSÃO ... 64 AMBIGUIDADE AMBIGUIDADE ... ... 6464 INCONSISTÊNCIA INCONSISTÊNCIA ... ... 6464 FATO INCORRETO FATO INCORRETO ... ... 6464 INFORMAÇÃO ESTRANHA ... INFORMAÇÃO ESTRANHA ... ... ... 6464 DOCUMENTO DE REQUISITOS DOCUMENTO DE REQUISITOS ... 64 ... 64
DEFEITOS NO DOCUMENTO DE REQUISITOS... DEFEITOS NO DOCUMENTO DE REQUISITOS... 65... 65
CONSEQUENCIAS ... 65
CONSEQUENCIAS ... 65
PEQUENO PEQUENO CHECKLIST CHECKLIST DEDE REQUISITOS... 65REQUISITOS... 65
TÉCNICAS TÉCNICAS DEDE VALIDAÇÃOVALIDAÇÃO DEDE REQUISITOS REQUISITOS ... 65... 65
REVISÃO DE REQUISITOS ... REVISÃO DE REQUISITOS ... 65... 65
REVISÕES REVISÕES DEDE SOFTWARE SOFTWARE ... 66... 66
TIPOS DE TIPOS DE REVISÃO DE REVISÃO DE SOFTWARE SOFTWARE ... 66 ... 66
PROCESSO DE INSPEÇÃO DE SOFTWARE PROCESSO DE INSPEÇÃO DE SOFTWARE ... 67 ... 67
PROCESSO TRADICIONAL DE INSPEÇÃO PROCESSO TRADICIONAL DE INSPEÇÃO ... 68... 68
GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE MUDANÇA DE REQUISITOS DE REQUISITOS ... ... 69... 69
EVOLUÇÃO EVOLUÇÃO DOSDOS REQUISITOS ... 71REQUISITOS ... 71
REQUISITOS REQUISITOS PERMANENTESPERMANENTES EE VOLÁTEIS VOLÁTEIS ... 71... 71
CLASSIFICAÇÃO DOS REQUISITOS... 71
CLASSIFICAÇÃO DOS REQUISITOS... 71
PLANEJAMENTO DO GERENCIAMENTO DE REQUISITOS ... 72
PLANEJAMENTO DO GERENCIAMENTO DE REQUISITOS ... 72
RASTREABILIDADE RASTREABILIDADE ... ... 7272 SUPORTE À FERRAMEN SUPORTE À FERRAMENTA: TA: ... 72... 72
ETAPAS PARA O RASTREAMENTO ETAPAS PARA O RASTREAMENTO ... 73... 73
EXERCÍCIOS ... EXERCÍCIOS ... ... 7474 MATRIZ DE RASTREABILIDADE ... 76 MATRIZ DE RASTREABILIDADE ... 76 RASTREABILIDADE RASTREABILIDADE ... 76... 76 OBJETIVOS... 76 OBJETIVOS... 76 M MATRIZ DEATRIZ DER R ASTREABILIDADEASTREABILIDADEDDEFINIDASEFINIDAS... 78... 78
EXERCÍCIOS ... EXERCÍCIOS ... ... 7979 ORIENTAÇÃO A OBJETOS ... ORIENTAÇÃO A OBJETOS ... ... 80... 80 HISTÓRIA ... 80 HISTÓRIA ... 80 C CONCEITOS FUNDAMENTAISONCEITOS FUNDAMENTAIS... 81... 81
OBJETO ... 82
OBJETO ... 82
ATRIBUTO ATRIBUTO ... 83... 83
OPERAÇÃO X MÉTODO ... 83 CLASSE ... 84 ESTADO ... 84 MENSAGEM ... 84 ENCAPSULAMENTO ... 84 HERANÇA ... 85 POLIMORFISMO ... 86
ANÁLISE ORIENTADA A OBJETOS ... 87
EXERCÍCIOS ... 88 2º BIMESTRE UML ... ... ... 91 HISTÓRIA ... 91 CONCEITO ... 92 UTILIZAÇÃO ... 93 NOTAÇÃO ... ... 94 VANTAGENS ... 94
FASES DO DESENVOLVIMENTO UML ... 94
COMPONENTES DA UML ... 95 MODELOS DE ELEMENTOS ... 95 CLASSES ... 95 OBJETOS ... 95 ESTADOS ... 96 PACOTES ... 96 COMPONENTES ... 96 RELACIONAMENTOS ... 97 MECANISMOS GERAIS ... 101 DIAGRAMAS... 101
DIAGRAMAS ESTRUTURAIS (ESTÁTICOS) ... 101
DIAGRAMAS COMPORTAMENTAIS (DINÂMICOS) ... 102
EXERCÍCIOS ... 103
DIA PORTABLE ... ... 105
MICROSOFT VISIO 2003 ... ... 107
DIAGRAMA DE MODELO UML... 107
ATIVIDADE DE UML ... 108
COLABORAÇÃO DE UML ... ... 108
COMPONENTE UML ... 109
IMPLANTAÇÃO DE UML ... ... 109
SEQUÊNCIA DE UML ... 109
GRÁFICO DE ESTADO DE UML ... 109
ESTRUTURA ESTÁTICA DE UML ... 110
CASO DE USO ... 110
PROPRIEDADES DA FORMA ... 110
OBSERVAÇÕES ... 111
DIAGRAMA DE CASO DE USO ... ... 112
CASOS DE USO ... 112
ATOR ... 113
COMO IDENTIFICAR OS ATORES ... 113
CASO DE USO ... 113
COMO IDENTIFICAR CASOS DE USO ... 114
CENÁRIO ... 114
RELACIONAMENTO DEEXTENSÃO ... 114
RELACIONAMENTO DEINCLUSÃO ... 115
RELACIONAMENTO DEESPECIALIZAÇÃO ... 115
RELACIONAMENTO ENTRE CASOS DE USO ... 115
EXEMPLO: ESTUDO DE CASO – LOCADORA DE VEÍCULOS ... 117
ANÁLISE DE CASOS DE USO ... 118
EXERCÍCIOS ... 118
DIAGRAMA DE CLASSES ... ... ... 124 CLASSE ... 124 CONVENÇÕES ... 125 ATRIBUTOS... 125 OPERAÇÕES ... 125 VISIBILIDADE... 125 RELACIONAMENTOS ... 125 ASSOCIAÇÃO ... ... 126 AGREGAÇÃO ... 126 COMPOSIÇÃO ... 127 CLASSE DE ASSOCIAÇÃO ... 127 HERANÇA ... 128 DIAGRAMA DE CLASSE ... 129
COMO FAZER UM DIAGRAMA DE CLASSES ... 130
IDENTIFICANDO AS CLASSES ... 130
IDENTIFICANDO OS ATRIBUTOS ... ... 131
IDENTIFICANDO O COMPORTAMENTO ... 131
IDENTIFICANDO GENERALIZAÇÕES ... 131
IDENTIFICANDO ASSOCIAÇÃO ... 131
EXEMPLO – ESTUDO DE CASO: LOCADORA DE VEÍCULOS ... 131
EXERCÍCIOS ... 132
DIAGRAMA DE OBJETOS ... ... 136
EXERCÍCIOS ... 137
TAREFA 07 – DIAGRAMA DE CLASSES E DIAGRAMA DE OBJETOS (1,0) ... 138
DIAGRAMA DE SEQUENCIAS ... ... 139
EXEMPLO: ESTUDO DE CASO: SISTEMA GESTOR DE VOTAÇÃO INTERNA ... 142
EXERCÍCIOS ... 147
TAREFA 8 – DIAGRAMA DE SEQUENCIAS (1,0) ... 148
ANEXO - SOLUÇÕES PARA PROBLEMAS NA ENGENHARIA DE REQUISITOS ... 150
ELICITAÇÃO DE REQUISITOS ... 151
PROBLEMAS ... ... 151
DESAFIOS... 151
PROBLEMA: ENVOLVER INTERESSADOS INAPROPRIADOS ... ... 152
PROBLEMA: POLÍTICA NA ORGANIZAÇÃO ... 152
PROBLEMA: A LINGUAGEM NATURAL E A ABSTRAÇÃO DOS REQUISITOS DE ALTO NÍVEL DIFICULTAM O MAPEAMENTO DAS CAPACIDADES MACRO EM REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS. ... 152
PROBLEMA: SEPARAR PREMISSAS RELACIONADAS AO DESENVOLVIMENTO DO SISTEMA DOS SEUS REQUISITOS ... 152
CASOS DE USO ... 153
PROBLEMA: DIFICULDADE NA DESCRIÇÃO DE REQUISITOS FUNCIONAIS E NÃ O-FUNCIONAIS. ... 153
PROBLEMA: COMPLEXIDADE NO DETALHAMENTO DOS CASOS DE USO PARA DEFINIÇÃO DA SOLUÇÃO ... 153
PROBLEMA: DETALHAMENTO TÉCNICO DESNECESSÁRIO DURANTE A ESPECIFICAÇÃO FUNCIONAL DO SISTEMA. ... 154
GERÊNCIA DE REQUISITOS ... 154
PROBLEMA: DIFICULDADES DE ESTABELECER UMA ESTRATÉGIA PARA A ATUALIZAÇÃO E REUTILIZAÇÃO DE CASOS DE USO ... ... 154
PROBLEMA: REPRESENTAR A ATUALIZAÇÃO DE CASOS DE USO ... 154
PROBLEMA: DIFICULDADE DE INTEGRAÇÃO DAS PRÁTICAS DE GERÊNCIA DE REQUISITOS COM GERÊNCIA DE CONFIGURAÇÃO. ... 155
PROBLEMA: TRABALHAR COM O BACKLOG DE CASOS DE USO INEXISTENTES PARA SISTEMAS EM MANUTENÇÃO. ... 155
PROBLEMA: DIFICULDADE DE IMPLANTAÇÃO E MANUTENÇÃO DA RASTREABILIDADE DOS REQUISITOS. ... 155
PROBLEMA: DIFICULDADES DE ESTABELECIMENTO RETROATIVO DE RASTREABI LIDADE DOS REQUISITOS... 155
IINNFFOOR R MMAAÇÇÕÕEESS IIMMPPOOR R TTAANNTTEESS
OBJETIVOS:
Aplicar um processo de desenvolvimento de software, ênfase na definição e
elicitação dos requisitos:
Apresentar e discutir o Ciclo de Requisitos de Software: Identificação,
Elicitação, Análise, Especificação e Validação;
Apresentar e discutir as atividades de Identificação e elicitação de requisitos; Apresentar e discutir as atividades da análise de requisitos de software;
Apresentar as principais técnicas para especificação de requisitos de software; Apresentar as principais técnicas para validação de requisitos de software; Apresentar as principais técnicas para processo de gerenciamento de
mudança de requisitos de software. EMENTA:
Contexto atual das empresas em relação aos projetos de tecnologia de
informação. Modelagem de Negócio para o desenvolvimento de software. Conceitos, evolução e importância da Engenharia de Requisitos. Entendendo e analisando os problemas e as necessidades dos usuários, clientes e envolvidos no projeto. Técnicas de elicitação. Requisitos, seus tipos e matriz de rastreabilidade. Definição do sistema a partir dos requisitos. Gerenciamento de requisitos
Sugestão de Livros, Revistas e Sites
ENGENHARIA DE SOFTWARE – Fundamentos, Métodos e Padrões – 3ª Edição
– Editora GEN LTC – Autor: Wilson de Pádua Paula Filho – 2010;
ESPECIFICAÇÃO DE SISTEMAS DE SOFTWARE UTILIZANDO ANALISE E
PROJETO ESTRUTURADOS – Editora UNICAMP – Autor: Thelma C. dos Santos Chiossi e Regina Lúcia O. Moraes – 2006;
ENGENHARIA DE SOFTWARE – 6ª Edição – Editora MH - MCGRAW
HILL/NACIONAL – Autor: Roger S. Pressman – 2006;
AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements,
Springer-Verlag, 2005. REVISTAS E SITES:
Revista Engenharia de Software: www.devmedia.com.br; http://engenhariadesoftware.blogspot.com/; http://www.sigsoft.org/; http://rildosan.blogspot.com/; http://www.yuml.me; http://www.wthreex.com/rup/; http://www.engenharia-software.com http://www.facebook.com/connect/uiserver.php?app_id=318148321616976& method=permissions.request&redirect_uri=http%3A%2F%2Fapps.facebook.c om%2Fpromonlogicalisestag%2F%3Ffb_source%3Dsearch%26ref%3Dts%26f ref%3Dts&response_type=none&display=page&auth_referral=1 Softwares
Dia Portable, Visio (Fatec), Word.
Máquina Virtual na Fatec : Engenharia de Software.
Quantidade de aulas semanais e Quantidade de faltas permitidas
Abono de Faltas
Abono de faltas somente com atestado médico.
No final do semestre, no caso do aluno ter nota e ter entregue no mínimo
70% das atividades poderá eliminar as faltas em excesso da seguinte forma: para cada 2 horas/aula excedida deverá ser entregue manuscrito um relatório
de apresentação de TCC (DEIXAR NA SECRETARIA).
Contato
Email: simone_viana@yahoo.com.br e/ou simone@fatecpg.com.br
Obs. O email: simonemviana@gmail.com é usado somente para envio
de formulários no Google Docs não há acesso da caixa postal.
TODOS OS EMAILS ENVIADOS PELO YAHOO OU PELO FATECPG SERÃO
RESPONDIDOS EM UM PRAZO DE 48 HORAS. CASO NÃO HAJA RESPOSTA, FAVOR ENVIAR NOVAMENTE.
Solicito que todos deixem o email atualizado na secretaria da Fatec
pois é por este email que consta no seu cadastro que eu entro em contato, avisando faltas, reposições, assuntos gerais, etc.
Avisos
Na página de ENGENHARIA DE SOFTWARE sempre terá avisos pertinentes ao conteúdo da disciplina.
Conteúdo das Avaliações
Sempre o conteúdo das avaliações será o apresentado até uma semana antes
das provas bimestrais, podendo ter eventualmente uma revisão antes da avaliação.
Forma de Avaliação
Haverá duas provas bimestrais que poderão ser dissertativas ou objetivas
com valor de 10,0 pontos;
Haverá tarefas avaliativas em sala de aula que pode ter valor até 3,0 pontos
que serão acrescidos a nota do bimestre;
Estas tarefas poderão ser feitas em laboratório, em casa com data de entrega
estipulada ou em sala de aula, realizadas em grupo ou individualmente, participação em sala de aula, relatórios a partir de vídeos assistidos, estudos de casos, entre outros.
ATENÇÃO!!!! CASO O ALUNO FALTE – INDEPENDENTE DE TER
ATESTADO OU TER ATESTADO – NÃO SERÁ ACEITO A TAREFA POIS O MESMO NÃO ASSISTIU A AULA.
Disciplinas, Dias e Horários que me encontro na Fatec
Engenharia de Software II – quinta-feira (13h10 as 16h40);
quarta-feira (19h as 22h30);
Banco de Dados – quarta-feira (13h10 as 16h40);
quinta-feira (19h as 22h30);
Laboratório de Banco de Dados – quarta e quinta-feira (16h50 as 18h30)
Sábado (8h as 11h30).
Erros da Apostila:
Caso seja encontrado erro na apostila, favor enviar por email.
T
TR R AABBAALLHHOO SSEEMMEESSTTR R AALL
O trabalho semestral deverá ser entregue na última aula
do segundo semestre (antes da prova de avaliação do
segundo bimestre) e deverá ter:
Capa contendo o nome dos alunos (máximo 5), o ciclo e o
período;
Estudo de caso descritivo;
Agenda da reunião
–
JAD;
Ata contendo o resultado da reunião JAD;
Especificação de Requisitos (mínimo 4);
Diagrama de Caso de Uso (contendo todo o projeto);
Diagrama de Classes (contendo todo o projeto);
Diagrama de Objetos (com base no diagrama de classes);
Diagrama de Sequência (de um caso de uso).
Obs. Poderá ser feito manuscrito ou utilizando um software e
não é necessário entregar encadernado.
Aviso: eu sou cliente. Portanto quero ver o trabalho pronto e não tiro
dúvidas do mesmo. Bom Trabalho!!!!
TAREFA 01 - REVISÃO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5)
1. Segundo a IEEE Computer Society , a engenharia de software é a aplicação de uma abordagem sistemática, disciplinada e quantificável ao desenvolvimento, à operação e à manutenção de software, isto é, a aplicação da engenharia ao software. Acerca dos princípios da engenharia de software, assinale a opção correta. (CESPE 2010 -SAD-PE - Analista de Controle Interno – Tecnologia da Informação) a) A engenharia de requisitos de um software, em geral, precede a
engenharia dos requisitos do sistema de informações no qual o software será usado.
b) A manutenção de software é uma atividade da engenharia de software que necessita do emprego de recursos que drenam cerca de 50% do investimento total em um software durante todo o seu ciclo de vida.
c) A gerência de configuração de software é uma atividade que envolve o emprego de conceitos e práticas, tais como identificação de itens de configuração, controle, contabilização e auditoria.
d) É desejável que o valor da coesão e o do acoplamento, duas importantes propriedades da arquitetura de um software, sejam maximizados durante a engenharia de software.
e) Em ferramentas CASE, como refactoring, é melhor adotar-se uma abordagem formal que uma abordagem heurística.
2. Um requisito de software expressa as necessidades e restrições colocadas em um produto de software que contribuem para a solução de algum problema do mundo real. Acerca desse assunto, assinale a opção correta. (CESPE - 2010 - SAD-PE - Analista de Controle Interno
– Tecnologia da Informação)
a) Os contratantes ou clientes são os principais colaboradores envolvidos no fornecimento de informações para o processo de levantamento ou elicitação de requisitos de software, os demais grupos de pessoas que podem fornecer informações são considerados de importância secundária.
b) As necessidades dos usuários a serem atendidas por um produto de software constituem a classe de requisitos funcionais, e as restrições mencionadas na definição de requisitos constituem a classe de requisitos não funcionais.
c) Entre as fontes de informação para a elicitação de requisitos, destacam-se, além dos colaboradores, o conhecimento do domínio de aplicação em que o software funcionará, o ambiente operacional do software e o ambiente organizacional.
d) A negociação de requisitos, de forma similar à observação do ambiente organizacional, é uma atividade típica da fase de elicitação de requisitos.
e) A técnica de casos de uso, empregada em alguns modelos de desenvolvimento de software atuais, é mais aderente à construção
de cenários durante a construção de protótipos que durante a elicitação de requisitos.
3. O conjunto de atividades e resultados associados que resulta em um produto de software recebe o nome de (UFG - 2010 - UFG - Analista de TI - Desenvolvimento de Sistemas):
a) engenharia de software. b) processo de software. c) especificação de software. d) implantação de software.
4. Assim como a Engenharia de Software, existe também na área de informática a chamada Ciência da Computação. Assinale a alternativa que melhor apresenta a diferença entre Engenharia de Software e Ciência da Computação. (FUNIVERSA 2009 IPHAN Analista -Tecnologia da Informação)
a) A Ciência da Computação tem como objetivo o desenvolvimento de teorias e fundamentações. Já a Engenharia de Software se preocupa com as práticas de desenvolvimento de software.
b) A Engenharia de Software trata da criação dos sistemas de computação (softwares) enquanto a Ciência da Computação está ligada ao desenvolvimento e criação de componentes de hardware. c) A Engenharia de Software trata dos sistemas com base em
computadores, que inclui hardware e software, e a Ciência da Computação trata apenas dos aspectos de desenvolvimento de sistemas.
d) A Ciência da Computação trata dos sistemas com base em computadores, que inclui hardware e software, e a Engenharia de Software trata apenas dos aspectos de desenvolvimento de sistemas.
e) A Ciência da Computação destina-se ao estudo e solução para problemas genéricos das áreas de rede e banco de dados e a Engenharia de Software restringe- se ao desenvolvimento de sistemas.
5. Para garantir o desenvolvimento de qualidade, é suficiente que a equipe tenha as ferramentas mais atuais de engenharia de software e os melhores computadores. (CESPE 2010 BASA Técnico Científico -Tecnologia da Informação - Arquitetura de -Tecnologia)
_____ Certo ____ Errado
6. Sobre a engenharia de software, considere:
I. Atualmente todos os problemas na construção de software de alta qualidade no prazo e dentro do orçamento foram solucionados.
II. Ao longo dos últimos 50 anos, o software evoluiu de um produto de indústria para um ferramental especializado em solução de problemas e análise de informações específicas.
III. Todo projeto de software é iniciado por alguma necessidade do negócio.
IV. O intuito da engenharia de software é fornecer uma estrutura para a construção de software com alta qualidade. (FCC - 2010 - TRE-RS - Analista Judiciário - Analista de Sistemas Suporte)
Está correto o que consta em a) III e IV, somente.
b) II e III, somente. c) I, II e IV, somente. d) II, III e IV, somente. e) I, II, III e IV.
7. De acordo com Pressman, a engenharia de software é baseada em camadas, com foco na qualidade: (FGV - 2010 - BADESC - Analista de Sistemas - Desenvolvimento de Sistemas): Essas camadas são:
a) métodos, processo e teste.
b) ferramentas, métodos e processo.
c) métodos, construção, teste e implantação.
d) planejamento, modelagem, construção, validação e implantação. e) comunicação, planejamento, modelagem, construção e implantação. 8. O objetivo da Engenharia de Software é estabelecer uma sistemática
abordagem de desenvolvimento, através de ferramentas e técnicas apropriadas, dependendo do problema a ser abordado, considerando restrições e recursos disponíveis. A Engenharia de Software: (FCC -2008 - METRÔ-SP - Analista Trainee - Ciências da Computação)
I. não se confunde com a Ciência da Computação, pois enquanto esta visa o desenvolvimento de teorias e fundamentações, a Engenharia de Software se preocupa com as práticas de desenvolvimento de software.
II. tem como foco único o tratamento dos aspectos de desenvolvimento de software, o que a diferencia da Engenharia de Sistemas, que trata dos sistemas baseados em computadores, incluindo hardware e software.
III. tem como métodos as abordagens estruturadas para o desenvolvimento de software que incluem os modelos de software, notações, regras e maneiras de desenvolvimento.
IV. segue princípios, tais como, o da Abstração, que identifica os aspectos importantes sem ignorar os detalhes e o da Composição, que agrupa as atividades em um único processo para distribuição aos especialistas.
É correto o que consta em: a) I e II, apenas.
b) III e IV, apenas. c) I, II e III, apenas. d) II, III e IV, apenas. e) I, II, III e IV.
9. No processo de engenharia de software, os requisitos funcionais podem ser também definidos como requisitos de (FCC 2008 METRÔSP -Analista Trainee - Ciências da Computação):
a) qualidade. b) capacidade. c) segurança. d) desempenho. e) manutenção.
10. Analise as seguintes afirmações relativas à Engenharia de Software: I. A análise de requisitos é responsável pela especificação dos
requisitos de software e hardware que serão utilizados durante o processo de desenvolvimento de um sistema.
II. A análise de requisitos define a metodologia de programação a ser utilizada no desenvolvimento do sistema.
III. A especificação de requisitos fornece ao desenvolvedor e ao cliente os parâmetros para avaliar a qualidade logo que o sistema for construído.
IV. A análise de requisitos possibilita que o engenheiro de software especifique a função e o desempenho do sistema e estabeleça quais são as restrições de projeto que o sistema deve atender.
Estão corretos os itens: (ESAF - 2004 - CGU - Analista de Finanças e Controle - Área - Tecnologia da Informação - Prova 3):
a) I e II b) II e III c) III e IV d) I e III e) II e IV
1
1ºº B
BIIM
ME
ES
ST
TR
R E
E
DE
D
ES
SE
EN
NV
VO
OL
LV
VIIM
ME
EN
NT
TO
O D
DE
E S
SO
OF
FT
TW
WA
AR
R E
E
Processo de software é um conjunto de atividades que objetivam o desenvolvimento e a evolução de software.
Principais atividades são:
ESPECIFICAÇÃO: define o que o sistema deverá fazer, considerando
as suas restrições.
DESENVOLVIMENTO: produção do software.
VALIDAÇÃO: checagem se o software faz o que o usuário deseja.
EVOLUÇÃO: mudanças no software para atender às novas
demandas.
O processo de engenharia de requisitos envolve criatividade, interação de diferentes pessoas, conhecimento e experiência para transformar informações diversas (sobre a organização, sobre leis, sobre o sistema a ser construído etc.) em documentos e modelos que direcionem o desenvolvimento de software (KOTONYA; SOMMERVILLE, 1998).
Figura 1 – Processo de Engenharia de Requisitos (Fonte: adaptado de (KOTONYA;SOMMERVILLE, 1998))
Já desenvolvimento de software é um conjunto de atividades para especificar, projetar, implementar e testar sistemas de software.
As atividades necessárias para o desenvolvimento de software são: especificação, projeto, validação e evolução.
O que é processo de software? O que é desenvolvimento de software?
Para o sucesso do desenvolvimento do software é necessário um entendimento dos requisitos de software. Não importa se foi bem projetado e/ou codificado; se o software tiver tido uma análise e uma especificação mal feita, o usuário se sentirá frustrado.
Análise de requisitos é um processo de descoberta, especificação, modelagem e refinamento.
O analista de sistema ou engenheiro de software estabelece o escopo1 do software e durante o planejamento do projeto de software vai
sendo refinado e seus detalhes sendo aperfeiçoados e através da criação de diagramas, fluxos e modelos, o problema torna-se compreensível.
O analista/engenheiro e o usuário possuem um papel ativo na análise e especificação de requisitos.
O cliente ou usuário tenta reformular um conceito de função e desempenho de software, sem detalhes concretos. Já o analista, indaga, consulta e soluciona os problemas.
Porém, a análise e a especificação de requisitos parece ser uma tarefa simples, mas não é bem assim...
A comunicação é um fator importante, pois as interpretações erradas e informações falsas surgem a todo momento. A ambigüidade é provável.
Podemos entender o dilema, repetindo a declaração de um cliente anônimo:
1
ESCOPO: entendimento dos objetivos do projeto, dos resultados esperados e à descrição
sumária do trabalho a ser realizado. É feita na etapa de iniciação do projeto e detalhada na etapa de planejamento. Descreve as características do produto e o trabalho necessário para realizá-lo. O consenso inicial sobre o escopo do projeto é estabelecido entre pessoas, organizações ou departamentos de organizações, sendo uma pessoa, empresa, o cliente, o demandante do serviço, o prestador de serviços designado ou outra pessoa, para fazê-lo.
―Sei que você acredita que entendeu o
que acha que eu disse, mas não estou certo que percebeu que aquilo que ouviu
não é o que eu pretendia dizer...‖
ESCOPO
É O QUE ESTÁ SENDO PROJETADO!!!!
R
R E
EQ
QU
UIIS
SIIT
TO
OS
S D
DE
E S
SO
OF
FT
TW
WA
AR
R E
E
Figura 2 – Levantamento de Requisitos (Fonte: Web)
Segundo o IEEE, define requisitos de software como:
―Uma condição ou uma capacidade de que o usuário
necessita para solucionar um problema ou alcançar um objetivo;
Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos formalmente;
Uma representação documentada de uma condição ou capacidade‖ .
Outros conceitos de requisitos de software...
Requisitos de um sistema são descrições dos serviços que devem ser
fornecidos por esse sistema e as suas restrições operacionais (SOMMERVILLE, 2007);
Um requisito de um sistema é uma característica do sistema ou a
descrição de algo que o sistema é capaz de realizar para atingir seus objetivos (PFLEEGER, 2004);
Um requisito é descrito como uma propriedade que o software deve
exibir para resolver algum problema no mundo real (SWEBOK, 2004);
Um requisito é alguma coisa que o produto tem de fazer ou uma
qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006).
Existem em diversos níveis:
Figura 3 – Requisitos (extraído da WEB)
IMPORTÂNCIA DOS REQUISITOS
Quanto mais cedo no ciclo de desenvolvimento do sistema se descobre um erro, mais barato fica para acertá-lo.
FASE CUSTO DE ERRO
REQUISITO 1 ANÁLISE 5 PROJETO 10 IMPLEMENTAÇÃO 20 TESTE 50 MANUTENÇÃO 200
Figura 4 – Custo dos erros nas fases
A dificuldade de descobrir erros na fase de requisitos está no fato de neste momento da análise, o analista está descobrindo o funcionamento do negócio que ele desconhece, e ainda a relação analista X usuário é muito recente, fazendo com que a relação de confiança ainda esteja em avaliação de ambas as partes. Ambiguidades decorrentes de nossa linguagem, omissões e fatos incorretos, são as principais causas.
O uso de inspeções, validação dos requisitos através de encontros sucessivos com o usuário, ajudam a minimizar estes problemas.
Pesquisa realizada na Standish Group com 350 companhias e 8.000 projetos diferentes, onde:
Sucesso é quando cobre todas as funcionalidades em tempo e
Problemático é quando não cobre todas as funcionalidades
exigidas, custo maior e atraso;
Fracasso é quando o projeto foi cancelado durante o
desenvolvimento.
Figura 5 – Pesquisa de projetos
As causas podem ser:
Figura 6 – Tipos de Fatores
Precisamos dos requisitos para entender o que o cliente quer, para documentar o que o cliente quer e para assegurar a qualidade e a satisfação do cliente. Também podemos entender o problema do negócio, documentar o escopo do projeto e definir suas restrições e definir os critérios de aceitação e gerenciar as expectativas do cliente.
QUALIDADE DOS REQUISITOS
As qualidades ―desejáveis‖ para um requisito são:
Verificável : Tem que existir uma maneira de verificar se o
Priorizável : Se todos os requisitos têm a mesma prioridade, há
algum problema, etc.;
Modificável : As ideias sempre mudam, logo os requisitos
devem mudar também (Scott Ambler);
Inteligível, Rastreável, Completo, Claro (não ambíguo).
TIPOS DE REQUISITOS
FUNCIONAIS: os requisitos funcionais descrevem o que o sistema
deve fazer, isto é, as funções necessárias para atender os objetivos do sistema. Exemplos: Cadastrar Clientes; Fazer Análise de Crédito; Fazer uma Transação com Banco de Dados; Cadastrar um Registro de Atendimento; Imprimir Relatório, etc.
Outras Definições:
o Segundo SOMMERVILLE (2007), são declarações de serviços que
o sistema deve prover, descrevendo o que o sistema deve fazer;
o PFLEEGER (2004), diz que um requisito funcional descreve uma
interação entre o sistema e o seu ambiente;
o Ainda em SOMMERVILLE (2007) seria como o sistema deve
reagir a entradas específicas, como o sistema deve se comportar em situações específicas e o que o sistema não deve fazer.
NÃO FUNCIONAIS (RNF ou Suplementares): Declaram as
características que o sistema deve possuir e que estão relacionadas às suas funcionalidades. Com as características: performance, portabilidade, segurança, usabilidade, qualidade do serviço (QoS),
confidencialidade, confiabilidade, portabilidade, precisão,
integridade, eficiência, entre outras. Estes tipos de requisitos são as causas as principais insatisfações dos usuários com relação ao software.
o Os requisitos não funcionais têm origem nas necessidades dos
usuários, em restrições de orçamento, em políticas organizacionais, em necessidades de interoperabilidade com outros sistemas de software ou hardware ou em fatores externos como regulamentos e legislações (SOMMERVILLE, 2007).
DOMÍNIO: muito relacionado as regras de negócio ou
comportamento próprio do sistema numa determinada aplicação ou no contexto funcionando para uma empresa.
Outras Definições:
o SOMMERVILLE (2007) diz que descrevem restrições sobre os
serviços ou funções oferecidos pelo sistema;
o Ou ainda, as quais limitam as opções para criar uma solução
EXEMPLO DE REQUISITOS FUNCIONAIS
―O software deve permitir que o atendente consulte o relatório com os resultados dos testes clínicos de um paciente.‖
[RF01] O software deve permitir que o atendente efetue cadastro de clientes;
[RF02] O software deve permitir que o caixa efetue o registro de itens vendidos;
[RF03] O software deve permitir que o administrador gere o um relatório de vendas por mês.
EXEMPLO DE REQUISITOS NÃO FUNCIONAIS
CONFIABILIDADE: O sistema deve estar disponível 99% das
vezes;
SEGURANÇA: dados devem ser protegidos;
DESEMPENHO: sistema deve processar x requisições por segundo;
CAPACIDADE: deve suportar x usuários concorrentemente.
EXEMPLO DE REQUISITOS DE DOMINIO
[RN1] os campos referente a orçamento projeto vinculado só
estarão ativos se o tipo de projeto for vinculado;
[RN2] o campo valor total orçado para o projeto é calculado
somando-se os valores definidos para todas as rubricas incluídas no orçamento do projeto, seja ele vinculado ou não-vinculado.
[RN3] A soma dos percentuais a ser distribuído entre os fundos
incluídos no plano de aplicação deve ser entre 0 e 100%.
PROBLEMAS COMUNS NOS REQUISITOS
Nem sempre são óbvios;
São originados de várias fontes (=conflitos de interesse);
Nem sempre retratam um problema que é possível ser expressado
por palavras;
Sempre mudam;
Os usuários nem sempre sabem o que desejam;
Os usuários têm uma tendência de privilegiar a sua área ou o seu
ponto de vista;
Os analistas pensam que entendem os problemas melhor do que os
próprios usuários!
CLASSES DE REQUISITOS
Os requisitos podem ser vistos em três classes distintas:
o Essenciais;
o Importantes;
o Desejáveis.
Em princípio, sistema deve resolver todos os requisitos de essenciais para requisitos desejáveis.
E
EN
NG
GE
EN
NH
HA
AR
R IIA
A D
DE
E R
R E
EQ
QU
UIIS
SIIT
TO
OS
S
A Engenharia de Requisitos é o processo pelo qual os requisitos de um produto de software são coletados, analisados, documentados e gerenciados ao longo de todo o ciclo de vida do software (AURUM; WOHLIN, 2005).
Pode ser descrita como o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema (SOMMERVILLE, 2003).
Em resumo, podemos dizer que tratamento de requisitos envolve
atividades de desenvolvimento (Levantamento, Análise e
Documentação de Requisitos), gerência (Gerência de Requisitos) e controle da qualidade (Verificação, Validação e Garantia da Qualidade de Requisitos).
Figura 7– Etapas da Engenharia de Requisitos (Fonte: extraído da Web)
RECORDANDO!!!!! A especificação de um requisito funcional deve determinar O QUE o sistema deve fazer sem a
Ao conjunto de atividades relacionadas a requisitos, dá-se o nome de Processo de Engenharia de Requisitos.
Descreve as atividades relacionadas à INVESTIGAÇÃO e DEFINIÇÃO DE ESCOPO de um sistema. É um processo sistemático de desenvolvimento de requisitos através de um processo cooperativo de análise onde os resultados das observações são codificados em uma variedade de formatos e as observações são constantemente verificadas.
Pode ser classificada em:
PRODUÇÃO: levantamento, registro, obtenção de
comprometimento e verificação;
A produção de requisitos é responsável por:
Levantar Requisitos; Registrar Requisitos;
Obter Comprometimento;
Verificar requisitos.
GERÊNCIA: controle de mudanças, gerência de configuração,
rastreabilidade e gerência da qualidade de requisitos. A gerência de requisitos é responsável por:
Controlar Mudanças;
Gerenciar Configuração;
Implementar Rastreabilidade;
Gerenciar Qualidade.
OBJETIVOS DA ENGENHARIA DE REQUISITOS
Estabelecer uma visão comum entre o cliente e a equipe de
projeto em relação aos requisitos que serão atendidos pelo projeto de software;
Registrar e acompanhar requisitos ao longo de todo o processo
de desenvolvimento;
Documentar e controlar os requisitos alocados para
estabelecer uma baseline para uso gerencial e da equipe de desenvolvimento;
Manter planos, artefatos e atividades de software consistentes
TAREFA 02 - QUESTÕES DE REQUISITOS (0,5)
1) Segundo Ian Sommerville, existe uma série de técnicas de validação de requisitos que podem ser utilizadas em conjunto ou individualmente. São elas:
a) geração de casos de teste, revisões de requisitos, gerenciamento de mudanças e prototipação.
b) revisões de requisitos, prototipação, geração de casos de teste e análise automatizada da consistência.
c) prototipação, análise automatizada da consistência, revisões de requisitos e gerenciamento de mudanças.
d) gerenciamento de mudanças, análise automatizada da consistência, revisões de requisitos e geração de casos de teste.
e) análise automatizada da consistência, prototipação, gerenciamento de mudanças e geração de casos de teste
2) Um requisito de software expressa as necessidades e restrições colocadas em um produto de software que contribuem para a solução de algum problema do mundo real. Acerca desse assunto, assinale a opção correta.
a) Os contratantes ou clientes são os principais colaboradores envolvidos no fornecimento de informações para o processo de levantamento ou elicitação de requisitos de software, os demais grupos de pessoas que podem fornecer informações são considerados de importância secundária.
b) As necessidades dos usuários a serem atendidas por um produto de software constituem a classe de requisitos funcionais, e as restrições mencionadas na definição de requisitos constituem a classe de requisitos não funcionais.
c) Entre as fontes de informação para a elicitação de requisitos, destacam-se, além dos colaboradores, o conhecimento do domínio de aplicação em que o software funcionará, o ambiente operacional do software e o ambiente organizacional.
d) A técnica de casos de uso, empregada em alguns modelos de desenvolvimento de software atuais, é mais aderente à construção de cenários durante a construção de protótipos que durante a elicitação de requisitos.
e) A negociação de requisitos, de forma similar à observação do ambiente organizacional, é uma atividade típica da fase de elicitação de requisitos.
3) Sobre os processos de engenharia de requisitos, na elicitação e na análise ocorre total interação com os stakeholders no sistema, sendo o principal objetivo:
a) obtenção dos requisitos. b) homologação do sistema.
d) conversão de especificações em requisitos. e) execução do estudo de viabilidade do sistema.
4) A respeito de análise de requisitos, julgue os itens a seguir.
I O usuário deve ser capaz de pesquisar tanto no banco de dados inteiro como em uma parte dele.
II A interface de usuário para o sistema deve ser implementada em HTML sem frames ou em applets Java.
III O sistema deve fornecer visões apropriadas para que o usuário possa ler documentos.
IV Cada ordem deve ter um identificador único (OSID), que o usuário deve poder copiar na área permanente de armazenamento da conta.
V O processo de desenvolvimento do sistema e os documentos devem ser realizados conforme o padrão interno da empresa.
São requisitos funcionais apenas os itens: a) I, II e III.
b) I, II e V. c) ) I, III e IV. d) II, IV e V. e) III, IV e V.
5) Identifique com V as afirmativas verdadeiras e com F, as falsas.
( ) Os requisitos não funcionais restringem o sistema que está sendo desenvolvido e o processo de desenvolvimento que deve ser usado e estão, frequentemente, relacionados às propriedades emergentes do sistema de modo que se aplicam ao sistema em sua totalidade.
( ) A prototipação não é considerada uma técnica usada para validação de requisitos, pois ocorre na fase final do processo de desenvolvimento, representado a entrega do sistema aos usuários finais e clientes.
( ) Pode-se considerar que a entrada para o estudo de viabilidade consiste em um conjunto preliminar de requisitos de negócios, um esboço da descrição do sistema e como esse sistema pretende apoiar os processos de negócios.
A alternativa que contém a sequência correta, de cima para baixo, é a:
a) V V F
b) V F V
c) F F V
d) F V F
e) V V V
6) A engenharia de requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui um conjunto de tarefas que levam a um entendimento de qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software. A função de negociação no processo de engenharia de requisitos:
a) especifica, revisa e valida o problema de modo a garantir que seu entendimento e o entendimento do cliente sobre o problema coincidam.
b) refina e modifica os requisitos. É uma ação de modelagem de análise composta de várias tarefas de modelagem e refinamento. c) define quais são as prioridades, o que é essencial, o que é
necessário. Clientes, usuários e outros interessados são solicitados a ordenar os requisitos e depois discutir os conflitos de prioridade.
d) ajuda o cliente a definir o que é necessário.
e) define o escopo e a natureza do problema a ser resolvido.
7) Requisitos não-funcionais estão diretamente relacionados com a satisfação dos usuários. Assinale a alternativa que não indique um requisito não-funcional:
a) O sistema de arquivos deve ser protegido, para acesso, apenas, de usuários autorizados.
b) O software deve ser implementado usando os conceitos de orientação a objetos.
c) O tempo de desenvolvimento do software não deve ultrapassar seis meses.
d) O software poderá ser executado em plataforma windows e linux. e) O software deve emitir relatórios de vendas a cada quinze dias.
8) As declarações de serviços que o sistema deve fornecer, de como ele deve reagir a entradas específicas ou se comportar em determinadas situações, são chamadas de requisitos:
a) Não-funcionais b) De domínio. c) De sistema.
d) Funcionalidades. e) De usuário.
9) Considerando-se a especificação de requisitos de um software, é incorreto afirmar:
a) a fase de especificação de requisitos pode ser iniciada logo após as fases de análise e projeto. Por essa razão, é fundamental que haja a participação ativa do usuário.
b) há técnicas para a elicitação dos requisitos; entre elas, está o uso de entrevista e brainstorm com os potenciais usuários.
c) quanto mais cedo for identificado um problema na fase de análise de requisitos, menor será o custo de corrigi-lo.
d) o gerenciamento de requisitos contempla um conjunto de atividades que auxiliam no controle e alterações dos requisitos durante a execução projeto.
e) o seu objetivo é representar as necessidades e restrições dos
E
EL
LIIC
CIIT
TA
AÇ
ÇÃ
ÃO
O D
DE
E R
R E
EQ
QU
UIIS
SIIT
TO
OS
S
― A parte mais árdua na construção de um
software consiste exatamente em identificar o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar
correções posteriores." — Fred Brook
Uma das partes mais críticas do processo de desenvolvimento de software é a elicitação (levantamento) de requisitos.
Há estudos que indicam que os requisitos detectados depois do software implementado ou erros de análise custam até vinte vezes mais caros que qualquer outro tipo de erro.
FASES DE UMA ELICITAÇÃO DE REQUISITOS
Um projeto de elicitação de requisitos têm as seguintes fases:
Figura 8 – Etapas de uma Elicitação de Requisitos (Fonte: extraído da Web)
Nesta etapa um dos artefatos2 principais é a criação do documento
visão.
2 Produto de trabalho do processo: os papéis usam os artefatos para executar atividades e
produzem artefatos ao executarem as atividades (http://www.wthreex.com/rup/manuals/intro/kc_artifact.htm acessado em 08/12/2011)
Figura 9 – Esquema para criação do documento visão (Fonte: extraído da Web)
Figura 10 – Erros de Requisitos (Fonte: extraído da Web)
A elicitação de requisitos corresponde a identificar junto aos stakeholders3 quais são os objetivos do sistema ou produto, o que deve
ser acompanhado, como o sistema ou produto se 'encaixa no contexto das necessidades do negócio e, finalmente, como será a utilização do sistema ou produto no dia-a-dia.
É um processo complexo, porém simples.
Há diversas razões para a complexidade, dentre elas, destacam-se os seguintes problemas:
3 Qualquer pessoa ou organização que tenha interesse, ou seja, afetado pelo projeto. A palavra
Escopo: Os limites do sistema são geralmente definidos de
forma incompleta, ou os clientes4 ou usuários especificam
detalhes técnicos desnecessários;
Compreensão: Os clientes ou usuários geralmente não estão
completamente certos das necessidades, têm uma pouca compreensão ou do domínio do seu negócio, omitem informações que julgam óbvias, etc.;
Volatilidade: Os requisitos mudam o tempo todo.
OBJETIVOS DA ELICITAÇÃO DE REQUISITOS
O objetivo da elicitação de requisitos é obter conhecimento relevante para o problema e prover o mais correto entendimento de o que é esperado do software/sistema.
PASSOS PARA A ELICITAÇÃO DE REQUISITOS
Avaliar a viabilidade técnica e de negócio para o sistema proposto; Identificar as pessoas que vão auxiliar a especificar os requisitos e
compreender seus preconceitos organizacionais;
Definir o ambiente técnico no qual o sistema será instalado;
Identificar regras de domínio que limitam a funcionalidade ou
desempenho do software que será construído;
Definir um ou mais métodos de elicitação de requisitos;
Solicitar participação de várias pessoas para que os requisitos sejam
definidos a partir de diversos pontos de vista;
Identificar claramente a justificativa de existência para cada
requisito registrado;
Identificar requisitos ambíguos que serão candidatos a prototipação.
4 Há uma diferença entre cliente e usuário. O primeiro refere-se a quem contratou o
QUESTÕES QUE PRECISAM SER RESPONDIDAS
Figura 11 – Questões que precisam ser respondidas
DOCUMENTAÇÃO DO ELICITAÇÃO DE REQUISITOS
Os documentos criados através da elicitação de requisitos irão depender do tamanho do sistema que será construído.
Estes documentos incluem as seguintes informações:
As necessidades e viabilidade estruturadas; O limite de escopo do software/sistema;
Lista de clientes, usuários e outros stakeholders que
participaram da atividade de elicitação de requisitos;
Descrição do ambiente técnico do sistema;
Lista de requisitos e as regras de domínio aplicáveis a cada
um.
Conjunto de cenários de uso capazes de prover uma ideia do
uso do sistema ou produto sob diferentes condições de operação;
Qualquer protótipo que eventualmente tenha sido
desenvolvido para melhor definir os requisitos.
Cada um destes documentos deve ser revisado por todas as pessoas que tenham participado da elicitação de requisitos.
IDENTIFICAÇÃO E ELICITAÇÃO DE REQUISITOS
O sucesso no desenvolvimento de um projeto de software depende basicamente da elicitação de requisitos, pois, é a base que permitirá ao Analista tirar conclusões sobre as situações, problemas ou fenômenos e, assim, sugerir propostas que possam contribuir para a solução do problema.
Entretanto, esta atividade, nem sempre está presente no processo de desenvolvimento, raramente ela é elaborada de forma metodológica, geralmente tem uma abordagem intuitiva.
As informações podem ser identificadas ou encontradas em diversas fontes, como: analista de negócio, clientes, documentos,
Domain Experts5 especificações técnicas, sistemas
legados-patrocinadores ou usuários.
IDENTIFICAÇÃO DOS REQUISITOS
Também chamada de descoberta de requisitos, tem o objetivo de identificar os requisitos é a ideia inicial do sistema para compreender o domínio do problema.
Identificar as funcionalidades do software que deve ter para atender as necessidades do usuário.
Para identificar podemos fazer as seguintes perguntas para identificar também as principais características do software:
5Especialista em uma ou mais área de negócio.
O que o software deve fazer? Quais
funcionalidades ele deve ter? Quanto a performance, qual é tempo de resposta adequado? Quais são os requisitos de segurança que o software recisa? Quanto à usabilidade, o software identifica visualmente a empresa e possui interface ami ável?
Os requisitos encontrados não devem ser descritos neste momento, precisamos apenas identificá-los (informação de alto nível).
Os requisitos de software podem ser identificados no texto da
―declaração do problema‖ (geralmente são verbos que identificam algumas ações). Este documento classifica os requisitos em dois tipos.
PROBLEMAS NA IDENTIFICAÇÃO DOS REQUISITOS
ESCOPO: Limite do sistema é mal definido ou detalhes técnicos
desnecessários confundem os objetivos globais;
ENTENDIMENTO: Clientes/usuários não estão completamente certos
dos que é necessário, não tem pleno entendimento do domínio do problema, têm dificuldade de comunicar as necessidades, têm pouca compreensão das capacidades;
VOLATILIDADE: Requisitos mudam com o tempo.
EXEMPLO DE DECLARAÇÃO DO PROBLEMA
Acompanhamento das estatísticas de aprendizado do aluno e da
turma (professor);
Informação: Relatório de aproveitamento do aluno e da turma(s).
REQUISITOS FUNCIONAIS:
o Sistema deve registrar as principais ações de cada usuário; o O sistema deve fornecer um relatório do aproveitamento do
aluno;
O relatório de aproveitamento do aluno deve conter o tempo de uso do software, o número de exercícios feitos, o número de acertos e o de erros.
o O sistema deve fornecer um relatório do aproveitamento da
turma.
O relatório de aproveitamento da turma deve conter a média e o desvio-padrão dos seguintes dados: tempo de uso do software, número de exercícios feitos, número de acertos e erros de cada exercício.
REQUISITOS NÃO-FUNCIONAIS:
o O sistema deve usar gráficos comparativos do aproveitamento
do aluno com a média da turma;
o O sistema deve usar cores na construção dos gráficos;
o O tempo de resposta na elaboração do relatório não pode ser
superior a 15 segundos.
CARACTERÍSTICAS DA ELICITAÇÃO DE REQUISITOS
Definir as técnicas de coleta de requisitos baseadas em fatores
Criar um planejamento com objetivo de alcançar as metas
estabelecidas, tais como: Prazos, Custos e Qualidade;
Promover a integração e o comprometimento de todos os
envolvidos no processo, por exemplo: Clientes, Fornecedores, Usuários e o Patrocinador;
Identificar os documentos e procedimentos que definem as
políticas de negócios da empresa.
DIFERENÇA ENTRE UMA BOA E UMA MÁ ELICITAÇÃO DE REQUISITOS
TAREFA 03 – ELICITAÇÃO DE REQUISITOS (0,5)
T
TÉÉCCNNIICCAASS PPAAR R AA EELLIICCIITTAAÇÇÃÃOO DDEE R R EEQQUUIISSIITTOOSS
Não existe maneira única de especificar os requisitos.
A identificação e elicitação de requisitos é uma tarefa que parece simples, mas, não devemos nos enganar, às vezes, para obtermos algumas informações é exigida muita dedicação, persistência e técnica. Esta parte apresenta e discute as principais técnicas para identificação e elicitação de requisitos de software.
Cenários: representar tarefas que executam e as que desejam
executar;
Técnicas tradicionais: questionários, entrevistas, análise de
documentação existente;
Técnicas de elicitação de grupo: Dinâmica de grupo;
Prototipação: quando existe alto grau de incerteza e necessita de
um rápido feedback
.
Tipos de TécnicasExistem várias técnicas para a elicitação de requisitos, todas elas possuem seus próprios conceitos, vantagens e desvantagens. Dentre
elas, destacam-se (KENDALL; KENDALL, 2010; KOTONYA;
SOMMERVILLE, 1998; AURUM; WOHLIN, 2005):
WORKSHOP DE REQUISITOS: idealizado para encorajar o
consenso acerca dos requisitos da aplicação e acerca das ações a serem tomadas em um curto intervalo de tempo. Formato: reunião intensiva (máximo 2 dias) com pessoas chaves visando criar ou revisar as principais funcionalidade do sistema em desenvolvimento, com a participação de um mediador;
QUESTIONÁRIOS: o uso de questionários possibilita ao
analista obter informações como postura, crenças,
comportamentos e características de várias pessoas que serão afetas pelo sistema;
Quem são os usuários (ou perfis de usuário)? Quem é o cliente?
Eles têm necessidades diferentes em relação ao sistema?
Onde mais pode ser encontrada uma solução para este pr oblema?
Estas questões nos forçam a ouvir antes de sair propondo uma solução para o problema.
OBSERVAÇÃO: consiste em observar o comportamento e o
ambiente dos indivíduos de vários níveis organizacionais. Utilizando-se essa técnica, é possível capturar o que realmente é feito e qual tipo de suporte computacional é realmente necessário. Ajuda a confirmar ou refutar informações obtidas com outras técnicas e ajuda a identificar tarefas que podem ser automatizadas e que não foram identificadas pelos interessados;
ANÁLISE DE DOCUMENTAÇÃO: pela análise de documentos
existentes na organização, analistas capturam informações e detalhes difíceis de conseguir por entrevista e observação. Documentos revelam um histórico da organização e sua direção.
CENÁRIOS: com o uso desta técnica, um cenário de interação
entre o usuário final e o sistema é montado e o usuário simula sua interação com o sistema nesse cenário, explicando ao analista o que ele está fazendo e de que informações ele precisa para realizar a tarefa descrita no cenário. O uso de cenários ajuda a entender requisitos, a expor o leque de possíveis interações e a revelar facilidades requeridas;
PROTOTIPAGEM (PROTOTIPAÇÃO): um protótipo é uma
versão preliminar do sistema, muitas vezes não operacional e descartável, que é apresentada ao usuário para capturar informações específicas sobre seus requisitos de informação, observar reações iniciais e obter sugestões, inovações e informações para estabelecer prioridades e redirecionar planos; VANTAGENS:
o permitem aos clientes e usuários do sistema
experimentar o sistema;
o entendendo melhor como o sistema pode ser usado para
dar suporte aos seus trabalhos;
o mal-entendidos entre projetistas e usuários podem ser
identificados quando a funcionalidade do sistema é demonstrada usando o protótipo;
o funções que estão faltando podem ser detectadas usando
o protótipo;
o durante o desenvolvimento de um protótipo, requisitos
incompletos e inconsistentes são descobertos. DESVANTAGENS:
o custo do desenvolvimento de um protótipo;
o tempo requerido para desenvolver um protótipo (que
pode aumentar o tempo de entrega ao usuário);
o o uso de um protótipo pode induzir os usuários a
prestarem mais atenção na interface com o usuário do que nos requisitos da aplicação;
o os usuários podem tornar-se familiares com uma
interface com o usuário antes da versão final do sistema estar desenvolvida.
LINGUAGEM NATURAL: na maioria das organizações, os
requisitos são escritos como parágrafos de linguagem natural, adicionados por diagramas e equações.
o Vantagem: Linguagem natural é a única notação que é
geralmente entendível por todos os leitores potenciais dos requisitos.
o Desvantagem: Os requisitos em linguagem natural podem
o Exemplo: Casos de Uso e Lista de Características
(sentenças).
DINÂMICAS DE GRUPO: há várias técnicas de levantamento
de requisitos que procuram explorar dinâmicas de grupo para a descoberta e o desenvolvimento de requisitos, tais como: brainstorming, brainswriting e JAD.
ETNOGRAFIA
Técnica de observação que pode ser utilizada para compreender os requisitos sociais e organizacionais, ou seja, entender a política organizacional bem como a cultura de trabalho com objetivo de familiarizar-se com o sistema e sua história. Os cientistas sociais e antropólogos usam técnicas de observação para desenvolver um entendimento completo e detalhado de culturas particulares.
Nesta técnica, o analista se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho diário é observado e são anotadas as tarefas reais em que o sistema será utilizado. O principal objetivo da etnografia é que ela ajuda a descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, onde as pessoas estão envolvidas.
Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:
1. Os requisitos derivados da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar;
2. Os requisitos derivados da cooperação e conscientização das atividades de outras pessoas.
Alguns itens importantes que devem ser executados antes, durante e depois do estudo de observação:
Antes, é necessário identificar as áreas de usuário a serem
observadas; obter a aprovação das gerências apropriadas para executar as observações; obter os nomes e funções das pessoas chave que estão envolvidas no estudo de observação; e explicar a finalidade do estudo;
Durante, é necessário familiarizar-se com o local de trabalho
que está sendo observado. Para isso é preciso observar os agrupamentos organizacionais atuais; as facilidades manuais e
automatizadas; coletar amostras de documentos e
procedimentos escritos que são usados em cada processo específico que está sendo observado; e acumular informações estatísticas a respeito das tarefas, como: frequência que ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está sendo observada. Além de observar as operações normais de negócios acima é importante observar as exceções;
Depois, é necessário documentar as descobertas resultantes das
observações feitas. Para consolidar o resultado é preciso rever os resultados com as pessoas observadas e/ou com seus superiores.
A análise de observação tem algumas desvantagens como, consumir bastante tempo e o analista ser induzido a erros em suas observações. Mas em geral a técnica de observação é muito útil e frequentemente usada para complementar descobertas obtidas por outras técnicas.
ENTREVISTAS
Técnica amplamente utilizada, que consiste em conversas
direcionadas com um propósito específico e com formato ―pergunta
-resposta‖. Seu objetivo é descobrir problemas a serem tratados, levantar procedimentos importantes e saber a opinião e as expectativas do entrevistado sobre o sistema. Deve ser bem planejada e preparada cuidadosamente para saber quem foi entrevistado, definir os objetivos da entrevista, preparar antecipadamente as questões que serão formuladas (ou parte delas).
Etapas
Apresentar-se;
Repassar a agenda (objetivos, patrocinador, motivo da escolha do
entrevistado);
Postura do entrevistador: credibilidade, isenção, discrição; não criar
ressentimentos;
Deixar o entrevistado falar (redução da interferência); Direcionar a discussão para os objetivos;
Evitar perguntas fechadas; Não ultrapassar o tempo; Notar sinais de impaciência.
Forma de Entrevistar
Relacione a parte da entrevista c/ partes do sistema; Obtenha pontos de vista alternativos;
Solicite detalhes do item que você estiver interessado; Estabeleça a dependência do assunto com outros;
Confirme os dados obtidos;
Focalize os requisitos (não os problemas técnicos);
Não confunda sintomas com o problema.
Perguntas que devem ser respondidas
Quem são o cliente e o usuário?
Possuem necessidades diferentes?
Quais são suas: Capacidades, Backgrounds, Ambientes, etc.
Como é resolvido atualmente? Qual a razão para resolvê-lo?
Qual o valor de uma solução bem-sucedida?
Onde mais uma solução pode ser encontrada?
BRAINSTORMING
Representantes de diferentes grupos de interessados engajam-se em uma discussão informal para rapidamente gerarem o maior número possível de ideias focadas em um objetivo claro e pré-definido.
Regras devem ser seguidas em uma sessão de Brainstorm:
• Não permitir críticas ou debate; • Deixar a imaginação voar;
• Gerar tantas ideias quanto for possível; • Mudar e combinar ideias;
• Sessão consiste em duas fases: GERAÇÃO DE IDEIAS e
CONSOLIDAÇÃO;
• Processo relativamente não estruturado que pode ou não
produzir a mesma qualidade ou nível de detalhe de outros processos.
TECNICAS PARA CONDUZIR
Inicie a sessão divulgando CLARAMENTE os objetivos;
Certifique-se que cada participante compreendeu exatamente os objetivos (obter feedback);
Convide ―escriba‖ para anotar cada ideia no flip-chart; Anote com clareza e precisão – evite ―telegrafar‖ ;
Não deixe que se percam as ideias – havendo várias ideias
simultâneas, peça que cada um anote as suas ideias numa folha para depois passá-las para o flip-chart.
Incentive a participação de todos;
Evite que ideias sejam discutidas, seja qual for o pretexto; Não tente esmiuçar, detalhar ou entender uma ideia;
Não permita que hajam justificativas para uma ideia; A sessão deve durar entre 15 e 60 minutos;
O clima deve ser descontraído, mas não é CIRCO!
Após uma sessão de Brainstorming as pessoas PRECISAM relaxar!
Após a sessão de brainstorming, deve haver um estudo de
viabilidade e adequação para cada ideia (organizar as ideias). BALDE DE ÁGUA GELADA
Isso não é possível...
Não temos tempo para...
Tudo isso já foi tentado...
Na prática as coisas são diferentes...
Se isso fosse útil, alguém já teria tido a ideia... Isso é muito antiquado...
Isso é moderno demais...
Vamos voltar a conversar no início do próximo ano... Já temos muitos projetos...
Você sabe que isso não funciona...
Vamos nomear uma comissão para cuidar disso...
Não temos nada com isso...
Não é problema do nosso departamento...
Vamos esperar os acontecimentos...
Melhor seria pensarmos um pouco mais... Outra vez você com essas suas ideias...
Se você acha que no nosso País isso vai funcionar... Isso é contra o regulamento...
Parece bom, mas... duvido que funcione... Isso só vai dar mais trabalho prá gente ...
Acho que alguém vai ficar furioso quando souber disso...
Exemplos:
1) Contexto: automação de iluminação.
Aspecto surgido no brainstorming: Configuração de iluminação automática.
Sentença descritiva: O dono de casa deve poder definir uma programação da iluminação da casa baseado nos horários do dia.
2) Contexto: Sistema de entrada de ordens de venda. Aspecto surgido no brainstorming: Rapidez.
Sentença descritiva: O tempo de resposta deve ser suficientemente bom para não interferir na realização das ações do processo de venda. 3) Contexto: Sistema de rastreamento de falhas.
Aspecto surgido no brainstorming: Notificação automática.
Sentença descritiva: Todos os grupos cadastrados devem ser notificados por email quando houver alguma modificação no processo de fabricação.
BRAINSWRITING
Dividir os participantes em grupos de 4 ou 5 pessoas. Os grupos recebem uma questão.
O trabalho:
- Escrever a sua opinião sobre a questão;
- Ao terminar, colocar a folha no centro da mesa;
- Pegar a folha de respostas de outro integrante do grupo; - Criticar as colocações encontradas;
