fase de concepção (início, planejamento). objetivos conhecer a empresa levantar requisitos...
TRANSCRIPT
Fase de Concepção (Início, Planejamento)
Objetivos
Conhecer a empresaLevantar requisitosOrganizar requisitos
Casos de UsoManutenção de EntidadesConsultas / Relatórios
Esboçar o modelo conceitual do sistemaPlanejar o desenvolvimento
IteraçõesCronogramaRecursos
Conhecimento da EmpresaO 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?
Conhecimento da Empresa (2)Se as respostas são positivas, o passo seguinte é elaborar o sumário executivo do projeto
Primeiro artefato
Artefatos
Sumário Executivo Documento de RequisitosCasos de UsoModelo Conceitual
Sumário Executivo
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
Sumário Executivodocumento de texto em formato livre Sistema Videolocadora Visão Geral do Sistema É proposto o desenvolvimento de um sistema de controle de
videolocadora, que vai informatizar as funções de empréstimo, devolução e reserva de fitas. O objetivo do sistema é agilizar o processo de empréstimo e garantir maior segurança, ao mesmo tempo que possibilita um melhor controle das informações por parte da gerência. Deverão ser gerados relatórios de empréstimos por cliente, empréstimos por fita e empréstimos no mês. O sistema deverá calcular automaticamente o valor dos pagamentos a serem efetuados em cada empréstimo inclusive multas e descontos devidos. A cada devolução de fitas corresponderá um pagamento, não sendo possível trabalhar com sistema de créditos. A impossibilidade de efetuar um pagamento deve deixar o cliente suspenso, ou seja, impossibilitado de emprestar novas fitas até saldar a dívida.
Sumário Executivo (2)
Exercício: avalie o documento do slide anterior
Ele permitiria responder bem a estas perguntas
Por quê?O quê?[Onde?]
Documento de Requisitos
Levantamento de Requisitos
EntrevistasAnálise de Documentos Existentes na EmpresaEstudo Bibliográfico Comparativo
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
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
Requisitos Não Funcionais
Permanentes (o contrário: Transitório)Desejáveis (o contrário: Obrigatório)
Requisitos Não Funcionais
Categoriade interfacede implementaçãode eficiênciade tolerância a falhas de segurançade compatibilidadeetc
Requisitos Não Funcionais
Associados a requisitos funcionaisSuplementares
Associados a qualquer requisito funcional, indistintamente
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?
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?
Requisitos Não Funcionais (2)
SuplementaresS<índice i >
Requisitos Funcionais e Não Funcionais Associados
F1 Registrar empréstimos Oculto ( ) Descrição: O sistema deve registrar empréstimos de fitas, indicando o cliente e as fitas que foram emprestadas, bem como a data do empréstimo e valor previsto para pagamento na devolução. Requisitos Não Funcionais Nome Restrição Categoria Desejável Permanente NF1.1 Controle de Acesso
A função só pode ser acessada por usuário com perfil de operador ou superior.
Segurança ( ) (x)
NF1.2 Identificação de Fitas
As fitas devem ser identificadas por um código de barras
Interface ( ) (x)
NF1.3 Identificação do cliente
O cliente deverá ser identificado a partir de seu nome Interface ( ) ( )
NF1.4 Tempo de registro
O tempo para registro de cada fita deve ser inferior a um segundo.
Performance (x) ( )
NF1.5 Janela única Todas as funções relacionadas a empréstimos devem ser efetuadas em uma única janela
Interface (x) (x)
... ... ... ... ...
F2 Calcular descontos Oculto ( x ) Descrição: O sistema deve calcular descontos nos empréstimos em função da política da empresa. Requisitos Não Funcionais Nome Restrição Categoria Desejável Permanente NF2.1 Desconto de fim de semana
Nos fins de semana, usuários que levam 4 fitas pagam apenas 3.
Especificação ( ) ( )
... ... ... ... ...
Requisitos Funcionais e Não Funcionais Associados (2)
Com relação a F1 e F2, e para sermos mais precisos (atomicidade)
Registrar (1) empréstimoCalcular (1) desconto
Requisitos Suplementares
Nome Restrição Categoria Desejável Permanente
S1 Tipo de Interface As interfaces do sistema devem ser implementadas como formulários acessíveis em um browser html.
Interface ( ) ( )
S2 Armazenamento de dados
A camada de persistência deve ser implementada de forma que diferentes tecnologias de bancos de dados possam vir a ser utilizadas no futuro
Persistência ( ) ( x )
S3 Perfis de usuário Os perfis de usuário para acesso ao sistema são: 3. Administrador - pode efetuar todas as operações. 2. Operador - pode efetuar as operações de empréstimo, devolução, pagamento e cadastramento. 1. Convidado - pode efetuar apenas consultas nos próprios dados (cliente).
Segurança ( ) ( )
... ... ... ... ...
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
Organização dos Requisitos
Casos de UsoManutenção de Conceitos (Entidades)Consultas/Relatórios
Casos de Uso
Caso de Uso
Um cenário de interação usuário-sistemaOrdenação de um subconjunto de requisitos funcionais, e seus requisitos não-funcionais associados, relacionados com a interaçãoImplica em mudança de estado do sistema ( consulta / relatório)
Pouco detalhado na fase de concepçãoBastante detalhado na fase de elaboração (refinamento de casos de uso)
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 deUso
FiF1 F2 Fn
Pelo menos um requisito funcional deve modificaro estado do sistema
Caso de Uso (3)
O nome de um caso de uso é sempre uma expressão verbal
Emprestar FitasDevolver FitasReservar Fitas
Validação de Requisitos Funcionais
Dado um requisito funcional, ele deve aparecer em pelo menos
um caso de uso, ouuma manutenção de entidade, ouum relatório / consulta
Organizando Requisitos em Casos de Uso
Nome Atores Descrição Referências Cruzadas Emprestar Fitas
Cliente, Funcionário
O cliente se identifica e identifica as fitas que deseja levar. O funcionário faz o registro e libera as fitas para empréstimo.
F1, F3, F5, F9, F10
Devolver Fitas
Cliente, Funcionário
O cliente entrega ao funcionário as fitas. O funcionário faz o registro da devolução e o cliente efetua o pagamento devido.
F2, F4, F6, F7, F8
Reservar Fitas
Cliente, Funcionário
O cliente solicita a reserva de um ou mais filmes. O funcionário registra a reserva.
F11, F12
Exercício: Mostre que cada caso de uso modifica, à sua maneira, o estado do sistema
Diagrama UML de Casos de Uso (Alto Nível, ou sem Decomposição)
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áriosFuncionário: primário
Interage diretamente com o sistemaCliente: secundário
Interage com o sistema via um ator primário
‘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
‘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
Modelo Conceitual Preliminar
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 UMLDiagrama 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
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 substantivosRelacionamentos (não exaustivamente)
Cliente Fez EmpréstimoCliente Solicitou ReservaEmpréstimo Locou FitaReserva 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
Diagrama Preliminar
Diagrama Preliminar (2)
Note que o diagrama está incompletoFaltando 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
Diagrama Preliminar (3)
Note também que faltam as multiplicidades dos relacionamentos
1:11:NM:N
As multiplicidades devem aparecem já no modelo conceitual preliminar
Diagrama Preliminar (4)
ExercíciosQual a diferença entre Modelo e Diagrama?Modifique o diagrama para só contemplar um empréstimo ou uma reserva correntes
Inclua as multiplicidades dos relacionamentosModifique o diagrama para contemplar históricos de empréstimos e reservas
Inclua as multiplicidades dos relacionamentos
Manutenção de Conceitos ou Entidades
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
Manutenção (Estudo de Caso)Conceit
oI A E C Obs Ref.
Cruzadas
Cliente X X X X Só é possível excluir se não houver empréstimos associados
F13, F14, F20, F21
Fita X X X X Só é possível excluir se não houver empréstimos associados
F18, F30, F31, F32
Reserva X I, A e E: dentro dos casos de uso Reservar Fitas (I e A) e Emprestar Fitas (E)
F15, F16
Empréstimo
X A: não é possívelI e E: dentro dos casos de uso Emprestar Fitas (I) e Devolver Fitas (E)
F17, F19
Consultas / Relatórios
Organização de Requisitos em Consultas / Relatórios
Muitos requisitos funcionais não mudam o estado do sistemaEles podem ser organizados em consultas / relatórios
Não incluem consultas a entidades simplesConsultas / relatórios são importantes para validar modelos conceituaisImportante: qualquer sistema de informação tem um conjunto relativamente diverso de consultas / relatórios
Organização de Requisitos em Consultas / Relatórios (Estudo de Caso)
Nome Referências Cruzadas Vendas Mensais F20, F21, F22 Clientes Suspensos F13, F23, F1 ... ...
Planejamento das Iterações
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
Estabelecendo Prioridades
Prioridade #1: Casos de Uso CríticosDefinidos pelo cliente
Prioridade #2: Casos de Uso Não-críticosPrioridade #3: Manutenção de ConceitosPrioridade #4: Consultas / Relatórios
Estabelecendo Prioridades (2)
Fase de ElaboraçãoRequisitos funcionaisAlguns requisitos não-funcionais associados a requisitos funcionais
Fase de ConstruçãoRequisitos não-funcionais associados a requisitos funcionaisRequisitos não-funcionais suplementares
Planejamento dos Ciclos Iterativos (Fase de Elaboração)
Ciclo Casos de
Uso Manutenção de Informações
Consultas Observações Esforço estimado
1 Emprestar Fita (550)
- - Neste ciclo ainda não será implantado o mecanismo de persistência
550 horas
2 Devolver Fita (300)
- - Implementar mecanismo de persistência (300 horas)
600 horas
3 Reservar Filme (270)
Fita (100), Cliente (100) e Reserva (100)
- - 570 horas
4 - Emprestimo (100) todas (400) - 500 horas
Cronograma de Execução
ConsiderarTempo total estimado para o projeto (em hora/pessoa) Tempo disponível (em semanas ou meses) Tamanho da equipe Estruturação em equipes
Planejamento com 4 equipes
Dias: 1-10 11-20 21-30 31-40 41-50 51-60 61-70 70-90 Ciclo 1 análise projeto implementação testes Ciclo 2 análise projeto implementação testes Ciclo 3 análise projeto implementação testes Ciclo 4 análise projeto implementação testes Implantação implantação
Planejamento com 2 equipes
Dias: 1-20 21-40 41-60 61-80 81-100 101-120 121-140 141-160 161-180 181-200 201-220 Ciclo 1 análise projeto impl. testes Ciclo 2 análise projeto impl. testes Ciclo 3 análise projeto impl. testes Ciclo 4 análise projeto impl. testes Implantação implant.
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
Projeto do Curso
Projeto
Fase Início (Concepção, Planejamento)Documento constando de:
Sumário ExecutivoRequisitos Funcionais e Não-funcionais AssociadosRequisitos suplementaresCasos de usoModelo ConceitualManutenção de EntidadesConsultas / RelatóriosPlanejamento das Iterações
Prazo de entrega: 20/07