Fase de Concepção (Início, Planejamento)

Apresentação em tema: "Fase de Concepção (Início, Planejamento)"— Transcrição da apresentação:

1 Fase de Concepção (Início, Planejamento)

2 Objetivos Conhecer a empresa Levantar requisitos Organizar requisitos
Casos de Uso Manutenção de Entidades Consultas / Relatórios Esboçar o modelo conceitual do sistema Planejar o desenvolvimento Iterações Cronograma Recursos

3 Conhecimento da Empresa
O que a empresa quer com o projeto? Por que ele está sendo proposto? Por que a empresa vai gastar dinheiro com o projeto? O projeto é realizável? A equipe de desenvolvimento tem condições de realizar este projeto? Em caso de uma empresa produtora de software para clientes externos:O cliente tem dinheiro para pagar o desenvolvimento? Há tempo disponível? Comprar ou desenvolver?

4 Conhecimento da Empresa (2)
Se as respostas são positivas, o passo seguinte é elaborar o sumário executivo do projeto Primeiro artefato

5 Artefatos Sumário Executivo Documento de Requisitos Casos de Uso
Modelo Conceitual

6 Sumário Executivo

7 Sumário Executivo É um documento de 3 páginas, no máximo, que responde às seguintes perguntas Por quê? O quê? [Onde?] Também chamado de Visão Geral do Sistema Estudo de Caso: sistema de locação de vídeo

8 Sumário Executivo documento de texto em formato livre

9 Sumário Executivo (2) Exercício: avalie o documento do slide anterior
Ele permitiria responder bem a estas perguntas Por quê? O quê? [Onde?]

10 Documento de Requisitos

11 Levantamento de Requisitos
Entrevistas Análise de Documentos Existentes na Empresa Estudo Bibliográfico Comparativo

12 Requisitos Requisitos funcionais correspondem à listagem de todas as coisas  primitivas ou atômicas  que o sistema deve fazer para bem gerir o negócio do usuário Requisitos não funcionais são restrições que se colocam sobre como o sistema deve realizar seus requisitos funcionais

13 Requisitos Funcionais
Requisitos funcionais evidentes são efetuados com conhecimento do usuário Requisitos funcionais ocultos são efetuados pelo sistema sem o conhecimento explícito do usuário A negação de requisito funcional evidente

14 Requisitos Não Funcionais
Permanentes (o contrário: Transitório) Desejáveis (o contrário: Obrigatório)

15 Requisitos Não Funcionais
Categoria de interface de implementação de eficiência de tolerância a falhas de segurança de compatibilidade etc

16 Requisitos Não Funcionais
Associados a requisitos funcionais Suplementares Associados a qualquer requisito funcional, indistintamente

17 Requisitos Funcionais
Código do requisito funcional (Ex.: F1, F2, F3, ...) Nome do requisito funcional (especificação curta) Descrição (especificação longa, ou detalhamento do requisito) Evidente ou oculto?

18 Requisitos Não Funcionais
Código de requisito não funcional associado (Ex.: NF1.1, NF1.2, ... NF2.1, NF2.2, ...) Nome do requisito não funcional (especificação curta) Restrição: especificação (longa) do requisito não funcional, por categoria de restrição Obrigatório ou Desejável? Permanente ou Transitório?

19 Requisitos Não Funcionais (2)
Suplementares S<índice i >

20 Requisitos Funcionais e Não Funcionais Associados

21 Requisitos Funcionais e Não Funcionais Associados (2)
Com relação a F1 e F2, e para sermos mais precisos (atomicidade) Registrar (1) empréstimo Calcular (1) desconto

22 Requisitos Suplementares

23 Desafios da Análise de Requisitos
Como descobrir os requisitos Como comunicar os requisitos para as outras fases e as equipes do projeto Como lembrar dos requisitos durante o desenvolvimento e verificar se foram todos atendidos Como gerenciar a mudança

24 Organização dos Requisitos
Casos de Uso Manutenção de Conceitos (Entidades) Consultas/Relatórios

25 Casos de Uso

26 Caso de Uso Um cenário de interação usuário-sistema
Ordenação de um subconjunto de requisitos funcionais, e seus requisitos não-funcionais associados, relacionados com a interação Implica em mudança de estado do sistema ( consulta / relatório) Pouco detalhado na fase de concepção Bastante detalhado na fase de elaboração (refinamento de casos de uso)

27 Caso de Uso (2) Um caso de uso pode ser também pensado como um grande  nível de agregação mais alto  requisito funcional Caso de Uso F1 F2 Fi Fn Pelo menos um requisito funcional deve modificar o estado do sistema

28 Caso de Uso (3) O nome de um caso de uso é sempre uma expressão verbal
Emprestar Fitas Devolver Fitas Reservar Fitas

29 Validação de Requisitos Funcionais
Dado um requisito funcional, ele deve aparecer em pelo menos um caso de uso, ou uma manutenção de entidade, ou um relatório / consulta

30 Organizando Requisitos em Casos de Uso
Exercício: Mostre que cada caso de uso modifica, à sua maneira, o estado do sistema

31 Diagrama UML de Casos de Uso (Alto Nível, ou sem Decomposição)

32 Diagrama de Caso de Uso Em geral, na fase de concepção, um caso de uso não é decomposto Decomposição é detalhamento (fase de elaboração) Atores primários e secundários Funcionário: primário Interage diretamente com o sistema Cliente: secundário Interage com o sistema via um ator primário

33 ‘Tamanho’ de um Caso de Uso
Um caso de uso deve ser uma unidade lógica de trabalho Critérios de tamanho de um caso de uso De 3 a 10 passos Um passo é um elemento descritivo, não necessariamente um requisito Duração de minutos a 1 hora Um caso de uso deve ser interativo, com informações fluindo para dentro e para fora do sistema Um caso de uso deve produzir uma alteração consistente na informação armazenada Uma seqüência de consultas puras ao sistema não caracteriza um caso de uso

34 ‘Tamanho’ de um Caso de Uso (2)
Algumas operações relativamente simples e elementares (de um único passo), como o registro de uma fita, ou de um pagamento, não devem ser consideradas como casos de uso por si só (um único passo) Outra maneira de dizer: nestas casos, o caso de uso reduz-se a um requisito funcional

35 Modelo Conceitual Preliminar

36 Modelo Conceitual A entrada para o modelo conceitual são os casos de uso Cada conceito ou entidade, assim como seus relacionamentos, deve aparecer direta ou indiretamente nas descrições dos casos de uso Terminologia UML Diagrama de Classes em Alto Nível, ou Diagrama de Entidades e Relacionamentos ‘Mais tarde’, conceitos ou entidades se tornam classes de software Diagrama de Classes

37 Caso de Uso: Diagrama Preliminar de Entidades e Relacionamentos
Entidades (não exaustivamente) Cliente, Empréstimo, Reserva, Fita Note que entidades são designadas por substantivos Relacionamentos (não exaustivamente) Cliente Fez Empréstimo Cliente Solicitou Reserva Empréstimo Locou Fita Reserva Referenciou Fita Note que relacionamentos são designados por verbos Estes relacionamentos e entidades foram extraídos dos casos de uso Emprestar Fitas e Reservar Fitas

38 Diagrama Preliminar

39 Diagrama Preliminar (2)
Note que o diagrama está incompleto Faltando contemplar o caso de uso Devolver Fitas Esta situação é normal, na fase de concepção Os refinamentos e detalhamentos são feitos principalmente durante a fase de elaboração

40 Diagrama Preliminar (3)
Note também que faltam as multiplicidades dos relacionamentos 1:1 1:N M:N As multiplicidades devem aparecem já no modelo conceitual preliminar

41 Diagrama Preliminar (4)
Exercícios Qual a diferença entre Modelo e Diagrama? Modifique o diagrama para só contemplar um empréstimo ou uma reserva correntes Inclua as multiplicidades dos relacionamentos Modifique o diagrama para contemplar históricos de empréstimos e reservas

42 Manutenção de Conceitos ou Entidades

43 O Padrão Manutenção de Caso de Uso
Cada conceito normalmente tem operações associadas de inserção (I) alteração (A) exclusão (E) consulta a um conceito (C) Isso configura um padrão de caso de uso Manter Conceitos ou Entidades Cada caso de uso do padrão é uma manutenção de entidade Recebe um tratamento específico e simplificado

44 Manutenção (Estudo de Caso)
Conceito I A E C Obs Ref. Cruzadas Cliente X Só é possível excluir se não houver empréstimos associados F13, F14, F20, F21 Fita F18, F30, F31, F32 Reserva I, A e E: dentro dos casos de uso Reservar Fitas (I e A) e Emprestar Fitas (E) F15, F16 Empréstimo A: não é possível I e E: dentro dos casos de uso Emprestar Fitas (I) e Devolver Fitas (E) F17, F19

45 Consultas / Relatórios

46 Organização de Requisitos em Consultas / Relatórios
Muitos requisitos funcionais não mudam o estado do sistema Eles podem ser organizados em consultas / relatórios Não incluem consultas a entidades simples Consultas / relatórios são importantes para validar modelos conceituais Importante: qualquer sistema de informação tem um conjunto relativamente diverso de consultas / relatórios

47 Organização de Requisitos em Consultas / Relatórios (Estudo de Caso)

48 Planejamento das Iterações

49 Planejamento do Desenvolvimento
Alocar o desenvolvimento em ciclos iterativos de mesma duração Observar as fases do processo UP (“Major milestones”) Estimativa de esforço para cada iteração

50 Estabelecendo Prioridades
Prioridade #1: Casos de Uso Críticos Definidos pelo cliente Prioridade #2: Casos de Uso Não-críticos Prioridade #3: Manutenção de Conceitos Prioridade #4: Consultas / Relatórios

51 Estabelecendo Prioridades (2)
Fase de Elaboração Requisitos funcionais Alguns requisitos não-funcionais associados a requisitos funcionais Fase de Construção Requisitos não-funcionais associados a requisitos funcionais Requisitos não-funcionais suplementares

52 Planejamento dos Ciclos Iterativos (Fase de Elaboração)

53 Cronograma de Execução
Considerar Tempo total estimado para o projeto (em hora/pessoa) Tempo disponível (em semanas ou meses) Tamanho da equipe Estruturação em equipes

54 Planejamento com 4 equipes

55 Planejamento com 2 equipes

56 Observações Note que, associando requisitos não-funcionais a requisitos funcionais, uma parte dos requisitos não-funcionais é implementada na fase de elaboração Fase de construção: os demais requisitos não-funcionais e os requisitos suplementares Note também que, trabalhando com várias equipes, somente as atividades de implementação-testes são seqüênciais Atividades de análise-projeto podem ocorrer em paralelo

57 Projeto do Curso

58 Projeto Fase Início (Concepção, Planejamento) Documento constando de:
Sumário Executivo Requisitos Funcionais e Não-funcionais Associados Requisitos suplementares Casos de uso Modelo Conceitual Manutenção de Entidades Consultas / Relatórios Planejamento das Iterações Prazo de entrega: 20/07