ATPS 03

Este documento apresenta todos os requisitos necessários para o desenvolvimento e implantação do sistema CLIVET. O aplicativo deve ter interface intuitiva de modo que facilite a interpretação por parte do usuário de suas funções. As funções dispostas pelo software deverão ficar em um lugar padrão para todos as telas.



















































Tiago Ap. Pessoa RA: 0911345828
Wesley S.Dia RA: 0959532446
Evandro D. Oliveira RA: 0919435 437
Marcio S. Oliveira RA: 0920349523









Trabalho apresentado para avaliação na disciplina de Engenharia de Software e análise de projeto de sistema, do curso de Ciência da Computação, período noturno, da Universidade Anhanguera de Campinas FAC III, ministrado pela professora Tânia Ramires.


























1ª ETAPA

































Opções de metodologias de processo









• FDD (Feature Driven Development )
• CASCATA
• SCRUM






































Processo FDD


É 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 modelo clássico ou cascata, que também é conhecido por abordagem “top-down”, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com outros modelos de desenvolvimento de software, este é mais rígido e menos administrativo.




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 SCRUM

Na 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

No início de um projeto Scrum, mesmo que ainda se tenha uma visão superficial no principio, há uma formalização de todas as coisas que se pretende fazer ou que se precisa construir no projeto. A partir dessa visão inicial, elabora-se uma lista enxuta dos principais itens; cada item desta lista representa um requisito funcional, ou requisito não funcional, ou questão de tecnologia ou infraestrutura. Esta lista é denominada Product Backlog.



Podemos traduzir Product Backlog como uma lista de prioridade de entrega que indica o quanto de valor ele gera para o negócio. Esta lista não precisa estar completa logo no começo, ela pode ganhar outros itens no decorrer do projeto, em outras palavras, é qualquer coisa que represente um trabalho que precisa ser feito para o produto.







No projeto real, o Product Backlog nunca é finalizado. Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog.
O Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e capaz de desenvolver todos os requisitos, ou um gerente de projeto, ou um patrocinador do projeto, um membro da equipe de marketing ou um cliente interno. Estas equipes recebem o nome de Scrum Teams. A preparação dos trabalhos é denominada Sprint Planning.
Sprint Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. A mistura são revisões, administração e organização. Os resultados são Sprint Goal e Sprint.
O Scrum Team deve desenvolver os itens separados pelo Product Owner em um determinado prazo previamente combinado. No início de cada iteração a equipe seleciona os itens do Product Backlog, de acordo com as suas prioridades e o prazo previamente combinado, este prazo é definido como Time Box e o trabalho de desenvolver os itens separados neste time box é denominado Sprint. Estes itens separados do Product Backlog fazem parte de uma nova lista. Esta lista, chamada Sprint Backlog, será de total responsabilidade do Scrum Team que deverá mantê-la e organizá-la de tal forma a atender os objetivos do específico Sprint.
É importante que a equipe identifique os itens e tamanho do Sprint Backlog, porque ela estará comprometida a finalizar tais tarefas. Os seus membros são quem deverão escolher com o que irão se comprometer e deverá mantê-la e organizá-la de tal forma a atender os objetivos. Nesse momento as tarefas maiores são subdivididas em partes menores.
Logo após o Sprint Backlog estar concluído, o total de horas trabalhadas é comparado com o total previsto anteriormente no Product Backlog. Caso haja uma diferença significativa, a equipe Scrum deve negociar novamente com o cliente o número correto de horas, para que o Sprint seja realizado com maior probabilidade de sucesso.












Este método de liderança é exercido através de recorrentes tipos de reunião:
• Scrum Planning Meeting: É o início de uma Sprint, onde o Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento e a oportunidade de atualizar a priorização dos itens do Product Backlog e definir juntamente com a equipe um Product Increment a ser entregue ao cliente ao final do Sprint.
Esta reunião é realizada com a presença do Product Owner, Scrum Master (líder facilitador do projeto), de todo Scrum Team (equipe), e quaisquer interessados, diretores ou representantes do cliente. Durante a reunião o Product Owner explica as funcionalidades de maior prioridade para o Scrum Team, e este faz as perguntas que sejam suficientes para que eles possam, depois da reunião, definir quais atividades eles irão mover do Product Backlog para o Sprint Backlog.



A reunião Sprint Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. O Scrum Team reúne-se separadamente para discutir o que foi dito e decidir o quanto eles se comprometem a fazer durante o próximo Sprint. Em alguns casos, haverá negociações com o Product Owner, mas será sempre prerrogativa do Scrum Team determinar o quanto eles podem se comprometer.


• Daily Scrum Meeting: O desenvolvimento de projetos de software é um desafio constante, é uma atividade complexa. Todo processo complexo exige uma intensa comunicação entre todos os membros do projeto. Scrum Daily Meeting é a resposta para promover a comunicação da equipe. É um encontro diário realizado pela equipe e o Scrum Master onde os membros discutem aquilo em que trabalharam, no que irão trabalhar e possíveis impedimentos que estejam atrapalhando o progresso do trabalho. Esta reunião é uma maneira eficiente de manter os membros cientes dos objetivos e impedir que o projeto “saia do rumo”.

São tipicamente rápidas e objetivas, realizadas em pé, preferencialmente pela manhã, duram de 15 a 30 minutos, para responder a importantes perguntas:

• O que eu fiz desde a última Scrum Daily Meeting até agora?
• O que eu vou fazer hoje?
• O que pode me impedir?






As Daily Scrum Meeting não representam uma forma de cobrança vinda de um gerente de projetos, mas é uma maneira de sincronizar a equipe às tarefas e relatar os impedimentos que podem estar interferindo no bom andamento do Sprint.
• Criação do Product Increment: A finalização das funcionalidades definidas para um determinado Sprint marca a realização de um Product Increment. Os membros da equipe trabalham de maneira colaborativa de forma a realizar todas as metas definidas para aquele Sprint.
• Sprint Review: é uma reunião tipica de final de Sprint, neste momento a equipe exibe o Product Increment, potencialmente utilizável que foi construído, ao Product Owner, que é responsável por validar e/ou solicitar ajustes para que o projeto se torne adequado aos anseios do cliente. Os participantes desta reunião incluem tipicamente: o Product Owner, o Scrum Team, o Scrum Master, a diretoria, clientes e engenheiros de outros projetos. O ideal é que a equipe tenha concluído todos os itens do Product Backlog alocados para o Sprint.
• Sprint Retrospective: é uma reunião que também acontece ao final do Sprint com o objetivo de fortalecer a unidade de ação da equipe. Acontece apos a revisão do Sprint, o Scrum Master faz uma reunião de retrospectiva com a equipe. Esta objetiva identificar os pontos positivos e negativos do Sprint que entregou o último Product Increment e busca corrigir os problemas encontrados com o propósito de aperfeiçoá-los.

Nessa reunião é debatido o que funcionou na Sprint, o que precisa ser melhorado e quais ações devem ser tomadas para colocar as melhorias em prática. Geralmente o Sprint Retrospective tem de três a quatro horas de duração.
• Atualização do Product Backlog: O Product Owner é responsável por re-priorizar toda lista de itens do Product Backlog para que um próximo Sprint possa ser iniciado de acordo com os itens mais prioritários.
Os principais artefatos produzidos no processo do Scrum são o Product Backlog, Sprint Backlog, Burndown Chart e o TaskBoard.
O Burndown Chart é o gráfico de andamento do Sprint, relacionando horas e data em relação ao restante de tempo hábil para o término do ciclo.

Com o Burndown Chart podemos ver claramente o andamento do projeto ao longo do seu ciclo de desenvolvimento (Sprint). Também, no meio do projeto, podemos calcular facilmente a velocidade com que o projeto está andando e assim estimar uma data para que o Sprint seja concluído.
Este dado estimativo pode ser comparado com o prazo que o Scrum Master definiu para que possamos saber se o projeto vai acabar ou não no prazo.
Este é um dos mais importantes trabalhos que o Scrum Master terá que fazer e o Burndown Chart é o indicador perfeito para ele gerenciar o tempo de projeto e sua equipe de desenvolvimento.
O taskboard é um grande painel onde podem ser colocadas várias informações importantes para o acompanhamento do Sprint. O Sprint Backlog, ou seja, as atividades não iniciadas, as que estão em andamento e as concluídas ficam sempre visíveis e disponíveis para todos os interessados no projeto.
Algumas características das equipes de desenvolvimento são:


































Processo
















Ciclo de Trabalho





























SCRUM FDD CASCATA

REUNIÃO P P P

DOCUMENTAÇÃO P P P

A.REQUISITOS P P P

MUDANÇAS / PLANEJAMENTO PP P PP


PRAZO E CUSTO
NP NP P


























Vantagens Desvantagens
Cascata O modelo em cascata só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. 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 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.

FDD 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 Questionamento a eficácia aplicabilidade de FDD
Controvérsias sobre o tamanha mínimo de um time FDD
Manutenção

Scrum Velocidade.
Motivação maior dos programadores.
Evita surpresas com os resultados.
Diminuição dos Bugs. Prioridade podem ser alteradas.
Funcionalidade que agregam valor, veem primeiro. Sensação de informalidade;
Prazo.
Falta planejamento de escopo








































2ª ETAPA




































TELA PRINCIPAL:


























TELA DE CADASTRO:



























TELA DE BUSCA:


























TELA DE RELATORIO:
























Requisitos do Processo


TIPOS DE REQUISITOS CLASSIFICAÇÃO

Requisitos funcionais Cadastro
Gerenciamento
Geração de relatório
Requisitos não funcionais Funcionalidade/usabilidade

Confiabilidade/Desempenho

Suportabilidade
Suplementares
Acessibilidade deficiência visual
































































3ª ETAPA



















Níveis de acesso

Usuário Requisito funcional Ações
Proprietário Gerenciamento, geração de relatório, Usabilidade, suporte Incluir, alterar, excluir, consultar
Secretaria Gerenciamento, geração de relatório, Usabilidade, suporte Incluir, alterar, excluir, consultar
Veterinário Usabilidade Alterar, consultar
Balconista Usabilidade Consulta

Termo Descrição sinônimos
Tipo de animal Qual a espécie do animal exemplo (cão, gato, passarinho, etc Espécie de animal
Tipo de medicação Qual a medicação usada, se medicação controlada ou não Remédio
Tipo de ração Qual a ração especifica para o animal Comida
Peso , idade Dosagem de medicação Magro, ideal, gordo, novo ou velho
Agenda Agenda completa de serviço Calendário
Cadastro do cliente Dados do cliente Informação do dono
Cadastro de usuário Identificar qual usuário esta usando Informação do funcionário
Balancete Abertura e fechamento do caixa Saber o quanto foi vendido e quanto tinha em caixa
Relatório de contas Saber o que vai pagar ou receber Quem vai receber e para quem vai pagar
Geração de boleto Gera boleto bancário para pagamento Pagamento no banco
Reajuste de preço Atualização de preço Alteração de preço
Produtos adversos Tipo coleira, bolinha, etc Outras produtos diferentes do citado dom brinquedos e outro
Relatório Entrada e saída de produtos Saber o que tem o que foi vendido e o que comprou
Backup Copia de segurança dos dados copia
Modulo de clinica veterinária Emissão e documentação para uso veterinário Receitas veterinária e outro do mesmo










Engenharia de Software e análise de projeto de sistema






Projeto de gestão Veterinária

























Entrevista com Cliente CLIVET

Campinas 18 de abril, 2011




Clivet; Meus funcionários vão poder administrar o programa sem dificuldades?

R: Sim, Além de o software possuir uma interface amigável, após a conclusão do software oferecemos uma palestra detalhada ao responsável da área.



Clivet; A empresa desenvolvedora do software garante o sigilo e segurança da informação do sistema?

R: Não só garante, mas firmamos um contrato de responsabilidade junto ao cliente como prova do sigilo absoluto ao mesmo.

Clivet; Meu sistema deve possuir um código único aos clientes da clinica.

R: Pensamos e desenvolvemos todo o sistema voltado a uma chave única para cada cliente da clinica, onde através deste pode ser alterado e modificado com um usuário com permissões especiais.
























Documento de Requisitos


Requisitos Funcionais:

Cadastro de cliente: criar cadastro de cliente de forma que os campos seja dinâmicos, ou seja do momento que o cliente queira alterar os campos do cadastro, ele possa habilitar ou desabilitar os campos preestabelecidos. Cada cliente cadastro terá uma chave de identificação única, onde este não pode ser alterada.

Cadastro de Animal; criar cadastro do animal de forma que os campos seja dinâmicos, ou seja do momento que o cliente queira alterar os campos do cadastro, ele possa habilitar ou desabilitar os campos preestabelecidos.



Relatório; Gerar relatório de todo o sistema que contenha todos os dados do cliente e serviços comprados pelo mesmo, sendo que após o termino da exibição este relatório possa ser impresso.


Disponibilidade; O sistema estará disponível vinte e quatro horas por dia nos sete dias da semana para caso de extensão do horário por parte dos funcionários ou caso de acesso externo a qualquer hora do dia por parte dos funcionários ou ainda no caso de trabalhar nos finais de semana.


Treinamentos do usuário; o tempo de treinamento ia depender do grau de conhecimento do usuario com a utilização de softwares e a capacitação de absorção. Para usuários simples o tempo Maximo de treinamento será de seis horas, podendo estender no Maximo mais uma hora. Para usuários com conhecimento em outros sistemas o tempo Maximo de treinamento será de três horas.

Confiabilidade: Os dados informados pelos sistema devem ser consistentes em qualquer modulo apresentado, não podendo jamais mostrar a mesma informação com valores distintos em um mesmo instante.













Tempo Médio para reparo;



Tabela de Dificuldades;





Interface do usuário; o usuário é quem comandará o sistema, portanto seu entendimento quanto ao sistema deverá ser pleno.







Sumário



Opções de metodologias de processo 4
Processo FDD 5
Vantagens 5
Desvantagens 5
Funcionalidade 5
Processo CASCATA 7
Vantagens 7
Desvantagens 7
Comparação com o modelo em cascata 8
Processo SCRUM 9
Ciclo do Processo do Scrum 9
Ciclo de Trabalho 15
Requisitos do Processo 23
Níveis de acesso 25
Engenharia de Software e análise de projeto de sistema 26
Entrevista com Cliente CLIVET 27