Professor Emiliano S. Monteiro

Transcrição

1 Professor Emiliano S. Monteiro

2 To-Do Doing Done

3

4

5 Conhecer os processos de desenvolvimento habilita o aluno a realizar uma melhor escolha de processo para uso em projetos futuros. A vantagem de conhecer vários processos permite inclusive evitar futuros problemas com projetos em andamento (o principal seria a mudança da metodologia de trabalho) o que impacta no custo e cronograma do projeto. Também permite conhecer vantagens e desvantagens de cada um possibilitando que se possa inclusive desenvolver um processo próprio e específico para uma empresa ou projeto de software.

6

7 Análise de Requisitos é... A extração dos requisitos de um cliente. A especificação é a tarefa de descrever precisamente o software que será construído, usando notações formais e padronizadas. Para alguns podem ser termos sinônimos. A identificação dos requisitos engloba várias tarefas que podem ser conhecidas como engenharia de requisitos.

8 O que é um Requisito? 1. É a definição documentada de uma propriedade ou comportamento que um produto ou serviço particular deve atender. 2. Informações fundamentais para a fase de projeto de um produto ou serviço, especificando as propriedades e funções necessárias (ou desejáveis) a serem consideradas no desenvolvimento do projeto em questão. 3. É à definição de uma característica, atributo, habilidade ou qualidade que um sistema (ou qualquer um de seus módulos e subrotinas) deve necessariamente prover para ser útil a seus usuários. Análise de requisitos é usada alternadamente com Engenharia de requisitos.

9 Análise de requisitos é usada alternadamente com Engenharia de requisitos... Sinônimos: 1. Levantamento de requisitos 2. Captura de requisitos 3. Especificação de requisitos 4. Análise de requerimentos

10

11 Etapas: 1. Entrevistas (Elicitação) dos requisitos: é a tarefa de comunicar-se com os usuários e clientes para determinar quais são os requisitos de sistema. 2. Análise de requisitos: determina importância e o grau de entendimento do que foi levantado (se o estado do requisitos é obscuro, incompleto, ambíguo, ou contraditório e resolve estes problemas). 3. Documentação dos requisitos: os requisitos podem ser documentados de várias formas, tais como documentos de linguagem natural, casos de uso, ou processo de especificação.

12 Formas de levantamento: 1. Entrevistas e Questionários: é técnica mais simples de utilizar. 2. Workshops de requisitos: promove-se a interação entre todos os elementos presentes (Brainstorming). 3. Cenários: leva pessoas a imaginarem o comportamento de um sistema é o uso de cenários. Através de exemplos práticos descritivos do comportamento de um sistema. 4. Protótipo: Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis. 5. Estudo etnográfico: é a análise de componente social das tarefas desempenhadas numa dada organização, observação pode ser acompanhada de registros áudio/vídeo.

13 Cliente = paga a conta do desenvolvimento do sistema Usuário = trabalha com o sistema

14 Um problema deve ser dividido em partes Os requisitos devem ser entendidos Podem ser usadas abstrações para documentar os requisitos Deve-se ter em mente as fronteiras do sistema

15 O que é SDLC? systems development life cycle Ciclo de vida do desenvolvimento de sistemas

16

17

18

19

20

21 CASE (engenharia de software assistida por computador)

22

23

24

25

26

27 Especificar: 1. Descrição, determinação circunstanciada. 2. Definição das características às quais deve responder uma instalação, uma construção, um material, uma confecção, um produto etc. 3. Enumeração.

28 Especificação de software: Uma especificação de programa é a definição do que se espera que um programa de computador faça. Ela pode ser informal, neste caso ela pode ser considerada como um blueprint ou manual de usuário do ponto de vista do desenvolvedor, ou formal, no caso de ela ser definida principalmente em termos matemáticos ou programáticos. especificação de software em inglês é conhecida pela sigla: SRS - Software Requirements Specification.

29 O SRS (Software Requirements Specification) é basicamente a compreensão de uma organização e cliente (por escrito) de um requisitos do sistema para este potencial cliente e realizado em determinado ponto no tempo (geralmente) antes de qualquer projeto real ou trabalho de desenvolvimento tenha início. É uma apólice de seguro de duas vias, que assegura que tanto ao cliente como para a organização entender as necessidades de ambas as partes. Termo de referência na área pública!

30 O documento SRS afirma em linguagem precisa e explícita as funções e capacidades de um sistema de software (isto é, uma aplicação de software, um site de comércio eletrônico, etc) deve fornecer, bem como estabelece quaisquer restrições exigidas pelo qual o sistema deve respeitar. Dica: ver requisitos funcionais e não funcionais! O SRS é muitas vezes referida como o documento de "pai", porque todos os documentos de gerenciamento de projetos subsequentes, tais como especificações de projeto, instruções de trabalho, especificações de arquitetura de software, testes e planos de validação, e os planos de documentação, estão relacionados a ele.

31 É importante notar que uma SRS contém os requisitos funcionais e não-funcionais apenas! A SRS não oferece: sugestões de design as possíveis soluções para questões de tecnologia ou de negócios

32 Se a especificação for bem escrita ela deverá atingir 4 objetivos: 1. Fornece um feedback ao cliente. O SRS é a garantia do cliente de que a equipe de desenvolvimento compreende as questões ou problemas a serem resolvidos e o comportamento software necessário para lidar com esses problemas. Portanto, a SRS deve ser escrito em linguagem natural (simples português), Poderá também incluir: gráficos, tabelas, diagramas de fluxo de dados, tabelas de decisão, etc. 2. Decompõe-se o problema em partes. O simples ato de escrever os requisitos do software em um formato bem projetado resulta em organização de informações, coisas, fronteiras em torno do problema, solidifica ideias e ajuda a quebrar o problema em suas partes componentes de uma forma ordenada. 3. Serve como documento pai de documentos posteriores. Portanto, a SRS deve conter detalhes suficientes nos requisitos funcionais de sistema para que uma solução de projeto possam ser elaboradas. 4. Ele serve como documento para testes e estratégias de validação que serão aplicadas aos requisitos para a verificação... Durante ou no final do projeto.

33 1. Introdução 1.1 Objetivos 1.2 Convenções da documentação (usará DER, UML, etc...) 1.3 Público-alvo 1.5 As informações de contato / membros da equipe com o cliente 2. Descrição geral 2.1 Perspectiva do produto 2.2 Funções do produto (macro funcionalidades) 2.3 As classes(tipos) de usuário 2.4 Ambiente de funcionamento (externo) 2.5 ambiente de usuário 2.6 Pressupostos e dependências 3. Requisitos de interface externa 3.1 Interfaces de usuário (protótipo) 3.2 Hardware requerido 3.3 Software requerido (infra, bd, etc) 3.4 Os protocolos de comunicação e interfaces (troca de dados via web servisse, csv, xml, dbf, xls, etc) 4. Recursos do sistema 4.1 A função do sistema ou recurso Descrição e prioridade (lista de funcionalidades organizada por prioridade) Ação / resultado: o que essa funcionalidade deverá executar e produzir Os requisitos funcionais Funcionalidades mínimas requeridas 5. Outros Requisitos Não Funcionais 5.1 Os requisitos de desempenho 5.2 Requisitos de segurança 5.3 Atendimento a legislação vigente 5.4 atributos de qualidade de software 6. Anexos 6.1. Diagramas 6.2. Telas 6.3. Terminologia / Definições

34 1. Resumo do projeto Este ponto inclui a visão geral do projeto, o escopo e o propósito. Deve apresentar uma breve lista das novas funções (e/ou as mudanças necessárias). 2. Termos e Definições Ponto opcional que descreve todos termos usados na especificação e redefine os já conhecidas (pode virar um anexo!). 3. Ambiente Descreve o ambiente de trabalho do usuário onde o sistema deverá ser executado. 4. requisitos funcionais Funções: 4.1. Caso de Uso "[Título do primeiro usecase]" Desenho do diagrama Descrição textual do primeiro usecase 4.2. Caso de Uso "[Título do primeiro usecase]" Desenho do diagrama Descrição textual do primeiro usecase...descreve quantos casos de uso existirem!! 5. Outros requisitos (não-funcional e do sistema) Este ponto inclui requisitos que impõem restrições sobre o projeto ou implementação (como requisitos de desempenho de engenharia, normas de qualidade, ou restrições de design). 6. Recursos Exemplos, links para documentação de referência, esboços e etc aqui.

35 Análise do problema Descrição do problema Documentação e validação Análise dos requisitos Investigação! Técnicas para realizar as atividades acima: 1. Entrevistas e Questionários 2. Workshops de requisitos 3. Cenários 4. Protótipo Especificação dos requisitos Registros

36 1. Utilizando uma descrição estática (listas de componentes do futuro sistema, utilizando diagramas de classes, expressando condições usando linguagem natural, etc) 2. Utilizando uma descrição dinâmica (utilizando diagramas de transição, descrevendo eventos que mudam o comportamento do sistema, tabelas de eventos, diagramas de atividade e sequência, etc) 3. Prototipação 1. Abordagem evolutiva: aproveita o modelo 2. Abordagem descartável: na fase de codificação é criado um sistema novo que será utilizado pelo cliente

37 A diferença de experiência entre analistas resulta em especificações muito diferentes. Técnicas de escrita diferentes. O nível de detalhamento não pode (não se recomenda) mudar em módulos diferentes de um mesmo sistema. Os requisitos que geralmente são mal especificados ou em alguns casos são ignorados são: ambiente de operação ambiente de treinamento administração do sistema em produção tolerância a falhas Regra de + ou 7 níveis