ATPS






ENGENHARIA








DE







SOFTWARE








Nome: Bruno Luiz M. de Oliveira RA:0919440340
Nome: Ronaldo Cezar Cavalcanti RA: 0901395323



Introdução
Este Documento tem o principal objetivo é relatar as características do sistema de forma mais detalhada possível, para que tanto a equipe, quanto o cliente tenham uma visão geral, clara e detalhada da ferramenta a ser produzida.




Perguntas do Cliente
1) Meus funcionários vão poder administrar o programa sem dificuldades?
R: Sim, pois é um sistema interativo e fácil de usar.
2) Minha clinica e de médio/grande porte, preciso que neste projeto possua índice pra interligar outra clinica futuramente?
R: Sim, pois, um sistema integrado facilita o acesso de todas as unidades.
3) Corro o risco de perder meu dado caso ocorra uma queda de energia?
R: Sim, mas pode-se prevenir com um no-break
4) Como ocorre a atualização desse programa?
R: ocorre sempre que houver solicitação por parte do cliente.
5) O sistema salva todos meus clientes em um dispositivo de segurança evitando uma futura invasão no sistema?
R: Não só salva mais também gera um backup mensalmente para evitar futuros danos a empresa.
Opções de metodologias de processo
• FDD (Feature Driven Development )
• CASCATA
• SCRUM

Processo FDD
A FDD é, classicamente, descrita por cinco processos:
• Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção.
• Construir uma Lista de Funcionalidades: decomposição funcional do modelo do domínio, em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog, ou lista de espera do produto).
• Planejar por Funcionalidade: abrange a estimativa de complexidade e dependência das funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a construção.
• Detalhar por Funcionalidade: já dentro de uma iteração de construção, a equipe detalha os requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.
• Construir por Funcionalidade: cada esqueleto de código é preenchido, testado e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário
É uma metodologia ágil para gerenciamento e desenvolvimento de software.

Vantagens
Recomendado para qualquer tipo de desenvolvimento.
Foco em características de valor para o cliente
FDD prioriza aquilo que o cliente prioriza
FDD possui requisito maus formais

Desvantagens
Questionamento a eficácia aplicabilidade de FDD
Controvérsias sobre o tamanha mínimo de um time FDD
Manutenção
Funcionalidade
Pequena o suficiente para ser implementada no máximo
em 2 semanas
Oferece valor para o cliente
Às vezes pode ser o próprio caso de uso
Conceito muito próximo ao de um requisito funcional
Exemplos: Calcular o total de uma venda
Autorizar uma transação com cartão de um cliente



Processo CASCATA
O Antigo e bem conhecido processo é o Modelo em cascata, onde os desenvolvedores (a grosso modo) seguem estes passos em ordem. Eles estabelecem os requisitos, os analisam, projetam uma abordagem para solução, arquitetam um esboço do software, implementam o código, testam (inicialmente os testes unitários e então os testes de sistema), implantam e mantêm. Depois que cada passo é terminado, o processo segue para o próximo passo, tal como construtores que não revisam as fundações de uma casa depois que as paredes foram erguidas. Se as iterações não são incluídas no planejamento, o processo não tem meios para corrigir os erros nas etapas inicias (por exemplo, nos requisitos), então o processo inteiro da engenharia de software deve ser executado até o fim, resultando em funcionalidades de software desnecessárias ou sem uso.Para isso tem que se fazer o implemento dos requisitos anteriormente analisados pelo programador.

Vantagens
O modelo em cascata só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas idéias sobre o sistema não sejam aproveitadas.
Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores;
∙ Não suporta modificações nos requisitos;
∙Não prevê a manutenção;
∙Não permite a reutilização;
∙É excessivamente sincronizado;
∙Se ocorrer um atraso todo o processo é afetado;
∙ Faz aparecer o software muito tarde.

Desvantagens
O risco desta abordagem é que, na ausência de um processo de gestão do projeto e de controlo das alterações bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar.

Comparação com o modelo em cascata
O desenvolvimento ágil tem pouco em comum com o modelo em cascata. Na visão de alguns este modelo é desacreditado, apesar de ser um modelo de uso comum. O modelo em cascata é uma das metodologias com maior ênfase no planejamento, seguindo seus passos através da captura dos requisitos, análise, projeto, codificação e testes em uma seqüência pré-planejada e restrita. O progresso é geralmente medido em termos de entrega de artefatos—especificação de requisitos, documentos de projeto, planos de teste, revisão do código, e outros. O modelo em cascata resulta em uma substancial integração e esforço de teste para alcançar o fim do ciclo de vida, um período que tipicamente se estende por vários meses ou anos. O tamanho e dificuldade deste esforço de integração e teste é uma das causas das falhas do projeto em cascata. Métodos ágeis, pelo contrário, produzem um desenvolvimento completo e teste de aspectos (mas um pequeno subconjunto do todo) num período de poucas semanas ou meses. Enfatiza a obtenção de pequenos pedaços de funcionalidades executáveis para agregar valor ao negócio cedo, e continuamente agregar novas funcionalidades através do ciclo de vida do projeto.
Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata inteiro em cada iteração. Outras equipes, mais especificamente as equipes de Programação extrema, trabalham com atividades simultaneamente.

Processo SCRUMNa indústria de software, devido á alta complexidade e ao desenvolvimento, impulsionada pela necessidade de obter resultados diferentes dos obtidos pelos métodos tradicionais, quando os processos definidos eram menos adequados para obter a alta produtividade e qualidade no produto final, verificou-se que pessoas válidas estavam propondo métodos sérios e factíveis. Desta forma, determinadas práticas ágeis começaram a ser utilizadas em projetos de software sem a agressividade pela adoção plena de uma metodologia ágil.
As empresas de software começaram a estudar essa metodologia, que propõe novos métodos em substituição aos métodos praticados tradicionalmente, pois o mercado de tecnologia da Informação está cada vez mais competitivo.
Os métodos ágeis, como uma alternativa aos processos tradicionais em decorrência da insatisfação dos profissionais de desenvolvimento de software, com a rigidez e resultados limitados obtidos através do uso de práticas tradicionais de gestão de projetos. Tais projetos partem da premissa de que se devem permitir mudanças nos requisitos a qualquer tempo.
• Interação entre indivíduos é mais importante que processos e ferramentas;
• Produto em funcionamento mais que documentação extensa;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.
.
Ciclo do Processo do Scrum
O que é Scrum?
Scrum é uma metodologia ágil para gerência de projetos. Ela é baseada em ciclos de 30 dias chamados Sprints, onde se trabalha para alcançar objetivos bem definidos. Estes objetivos são representados no Product Backlog, uma lista de coisas para fazer que é constantemente atualizada e repriorizada.

Quais são os papéis?

• Equipe: responsável por entregar soluções, geralmente é formada por um grupo pequeno (entre 5 e 9 pessoas) e que trabalha de forma auto-gerenciada;
• Product Owner: responsável pela visão de negócios do projeto, é ele quem define e prioriza o Product Backlog. Geralmente é o papel desempenhado pelo cliente;
• Scrum Master: é uma mistura de gerente, facilitador e mediador. Seu papel é remover obstáculos da equipe e assegurar que as práticas de Scrum estão sendo executadas com eficiência.
•
• Como funciona?
• Definição do Backlog: todas as funcionalidades ou mudanças no produto são definidas pelo Product Owner no Product Backlog. Esta lista é priorizada para refletir a necessidade dos clientes ou demandas do mercado. Os itens do topo da lista são destacados para serem entregues no final do próximo Sprint.
• Andamento do Sprint: durante o Sprint, os itens do Product Backlog que devem ser entregues são agora tratados no Sprint Backlog. As tarefas agora são responsabilidade da Equipe, que tem autonomia para decidir como elas devem ser executadas.
• Reuniões Diárias: o Scrum Master se reune diariamente com a Equipe num mesmo horário, para que se reporte:
o O que foi feito ontem?
o O que se pretende fazer hoje?
o Quais são os impedimentos que estão atrapalhando a execução das tarefas?
• Revisões: no final do Sprint a Equipe demonstra os resultados para o Product Owner e demais interessados, de forma que os itens do Backlog sejam considerados prontos e então possa se iniciar um novo Sprint.







Processo













ETAPA 2



























ETAPA 3
Níveis de acesso


Glossário






Logo da clinica veterinária CLIVET




Requisitos Funcionais

Cadastro e alteração: Cadastro e alteração é um requisito com a função de cadastrar os dados do cliente como endereço, telefone, etc, e é uma função em que o funcionário pode atualizar/alterar os dados do cliente.
Pesquisa: Pesquisa é uma função onde pode-se realizar buscas como cadastro dos clientes, telefones, endereços, e outros dados do cliente.

Impressão e Relatório. Função responsável por gerar relatórios e impressões.

Requisitos não Funcionais
UsabilidadeA usabilidade de um sistema é um conceito que se refere à qualidade da interação de sistemas com os usuários e depende de vários aspectos. Alguns destes fatores são:
- Facilidade de aprendizado do sistema: tempo e esforço necessários para que os usuários atinjam um determinado nível de desempenho;
- Facilidade de uso: avalia o esforço físico e cognitivo do usuário durante o processo de interação, medindo a velocidade de uso e o número de erros cometidos durante a execução de uma determinada tarefa; Pressupõe a existência de Help, manuais de usuário e boa documentação
- Satisfação do usuário: avalia se o usuário gosta e sente prazer em trabalhar com este sistema;
- Flexibilidade e Nível de Parametrização: avalia a possibilidade de o usuário acrescentar e modificar as funções e o ambiente iniciais do sistema. Assim, este fator mede também a capacidade do usuário utilizar o sistema de maneira inteligente e criativa, realizando novas tarefas que não estavam previstas pelos desenvolvedores;
- Produtividade: avalia se o uso do sistema permite ao usuário ser mais produtivo do que seria se não o utilizasse.
- Consistência de interface
- Cuidado com a navegabilidade
- Tolerância a erro



DesempenhoÉ medido avaliando-se a velocidade de processamento, o tempo de resposta, o consumo de recursos, o throughput e a eficiência

Segurança
Premissas e Restrições para o controle e segurança do software além da disponibilidade de mecanismos que controlam ou projetam programas e dados. Este requisito está relacionado aos fatores como: necessidade de criptografia, autenticação de usuários, etc…

- Controle de acesso e manipulação de recursos
- Autenticação
- Autorização/permissão
- Integridade dos dados e confiabilidade
- Privacidade e confidencialidade



Sumário
Introdução................................................... 2
Perguntas do Cliente......................................... 3
Tabela de Prioridade......................................... 14
Níveis de acesso............................................. 15
Glossário.................................................... 16
Requisitos Funcionais........................................ 17
Requisitos não Funcionais.................................... 18