ATPS - Etapas: I, II e III

Índice

Tópico Página(s):

• Metodologia de desenvolvimento 2

• Comparação entre metodologias 3

• Desenvolvimento do software / solução 4

• Qualidades do projeto 4, 5

• Interface do cliente 5

• Análise dos requisitos (funcionais e não funcionais) 5, 6

• Grupos de usuários / permissões de acesso 7

• Glossário apresentado ao clientes e aos desenvolvedores 8, 9

• Etapa I 2, 3

• Etapa II 4, 5, 6

• Etapa III 7, 8, 9

• Tabela I 2

• Tabela II 3

• Tabela III 6

• Tabela IV 6

• Tabela V 7

• Tabela VI 8, 9

• Equipe 9

• Dados da Disciplina 9

ATPS de Engenharia de Software

Etapa I

Introdução

Tentamos agendar duas reuniões com o cliente CLIVET, para discutirmos as características do projeto, como necessidades e tempo de entrega do mesmo, porém, como o mesmo estava muito ocupado, ambas reuniões não puderam ser realizadas.

Devido a tal fato, e a nossa vontade e competência em entregar um produto que agregue mais valor aos serviços da CLIVET e, à maior ou total satisfação de nosso cliente, resolvemos trabalhar com algum método/metodologia que nos permita entregar: ou protótipos ou fazer com quem nosso software seja facilmente modificado.

Mediante à impossibilidade de entrevistarmos nosso cliente, perguntando ao mesmo sobre as características desejadas do software, complexidade, integração com qual tipo de banco de dados (se necessário), tamanho da base de dados do mesmo, necessidade (ou não) de ser acessado via web, ser expansível para possíveis filiais, vontade do mesmo em ter um software que possa ser atualizado facilmente, etc, resolvemos seguir nossa intuição, e trabalharmos com algum método que nos permita entregar um protótipo ou então, que possa ser facilmente modificado (não temos um escopo inicial por parte de nosso cliente).

Desenvolvimento

Diagramamos duas tabelas, para a apresentação ao nosso cliente; mesmo ele não podendo comparecer às reuniões e discutir sobre tais metodologias, nós resolvemos escolher entre as 3 metodologias inicialmente propostas, a que julgamos ser melhor pelo comportamento de nosso cliente, e pelo que julgamos que o cliente quer / espera do software.

	Clássico (cascata)	Prototipação	Metodologia Ágil / Scrum
Exige extensa documentação:	P	P	PP*
Software é facilmente modificado / expansível:	PP	P	P
Gerar um protótipo / beta:	NP	P	P
Exige excelentes/experientes programadores:	NA**	NA**	P
Cálculo do fator risco:	NP	NP	P
Fácil cálculo do tempo de entrega do software	PP	NA	P

Tabela I: requisitos das metodologias.

Onde: P = possui; PP = possui parcialmente; NA = não se aplica ;NP = não possui.

* = se o cliente desejar, é feito; porém não é uma característica da metodologia

** = a menos que a empresa já conte com excelentes programadores; em teoria, não é necessário.

Vamos, agora, apresentar uma tabela comparativa entre as três metodologias:

	Vantagens	Desvantagens
Clássico (cascata)	*É antigo; *É muito utilizado; *Minimiza o tempo de planejamento; *Funciona bem com equipes tecnicamente mais fracas; *É linear.	*Perde-se muito tempo com documentações, nem sempre necessárias; *Projetos chegam a levar muitos meses para serem concluídos; *Cliente só vê o programa em funcionamento ao final de todo o processo; *Não necessita de uma equipe bem integrada, o que pode gerar falhas ou incapacidade do programa ser atualizado; *Não tem análise de risco.
Prototipação	*Trabalha com um protótipo do software; *Cliente recebe uma versão protótipo do mesmo, para utilização e testes; *Pode ser utilizado quando a comunicação com o cliente não é completa; *Facilmente atualizável; *Bom para softwares com mudanças de requisitos constantes.	*Cliente pode se contentar com o protótipo, e esquecer a versão final; *Impossível determinar com exatidão o tempo que o processo vai durar; *Não há formas de saber o número de iterações necessárias; *Mutias vezes, o protótipo acaba atrapalhando o desenvolvimento da versão final; *Não há análise de risco..
Ágil / Scrum	*É ágil; *Utiliza análise de risco; *Focado na negociação interna e com clientes; *Agrega muito valor ao produto e ao cliente; *Geralmente, traz alto grau de satisfação do cliente com o produto; *Time pequeno.	*Necessita de um time bem entrosado; *Necessita de bons programadores; *Ambiente que facilite a fácil comunicação entre os membros; *Quebra de paradigmas é complicado; *Difícil de gerenciar projetos que precisam de muitas pessoas.

Tabela II: comparação entre as metodologias.

Conclusão

Resolvemos optar, mesmo não sendo excelentes programadores, pelo método Scrum, pois temos uma boa comunicação, um time pequeno, e visamos a total satisfação de nosso cliente, em um curto período de tempo, visando, também, um software que possa ser facilmente atualizável, e, sem uma extensa documentação.

Etapa II

Introdução

Vamos apresentar o documento de requisitos do software da veterinária CLIVET. Procuramos seguir passos para uma adequada elaboração dos requisitos necessários para o bom desenvolvimento e funcionamento da aplicação voltada à tal empresa.

Desenvolvimento

Basicamente, dividimos todo o programa de desenvolvimento em 3 etapas, podendo estas, serem subdivididas em outras “n” etapas.

As 3 principais etapas são:

*Desenvolvimento do aplicativo em PHP;

*Integração do mesmo com o banco de dados MySQL;

*Integração da base de dados com o sistema operacional Linux.

Apresentaremos os motivos pelos quais escolhemos tais conjuntos de ferramentas, abaixo.

*PHP mostra uma excelente integração com bases de dados, é muito portável (rodas em inúmeras diferentes plataformas), e é muito leve, no que diz respeito à necessidade de um hardware / investimento em hardware;

*MySQL é uma ferramenta livre e grátis, e, muito poderosa; tem uma excelente performance para bases de dados pequenas e médias, mantendo um excelente controle e segurança dos dados arquivados; além disso, é bem leve, mais uma vez, contribuindo com o baixo custo do projeto, no que diz respeito ao hardware;

*Um navegador web (ex: Firefox, Google Chrome, etc), livres, sem custo;

*Como servidor, utilizaremos um Linux, Debian GNU; muitíssimo leve, grátis, altamente configurável e seguro. Tal sistema rodará a base de dados SQL escolhida, um servidor web APACHE local integrado ao PHP, e um firewall.

Nosso sistema (analisando o hardware) precisará de:

*Um roteador (simples) de 4 portas (preço em torno de 60 reais);

*Um computador (servidor) com 512MB RAM (mínimo), cerca de 50 GB de Hard-Disk (hdd), com um processador Pentium 3 ou Pentium 4 (hardware simples), com uma placa de rede;

*Um computador (cliente) que consiga rodar um browser (Firefox, por exemplo), com monitor, teclado, mouse e uma placa de rede;

*3 cabos de rede (tipo CAT-5, pelo menos).

*Impressora (pode ser qualquer uma, porém, uma impressora com placa de rede seria ótimo).

Qualidades do software / sistemas

Com um setup destes, fica fácil expandir o software; caso necessário, podemos adicionar mais clientes ao servidor; caso seja necessário a empresa expandir (filiais), basta contratar um link de internet com um provedor, e linkar os novos clientes/filiais ao servidor; backups de dados podem ser feitos facilmente; acessos podem ser controlados por regras de firewall e permissões de usuário (segurança praticamente garantida); pode-se ainda criar um disaster-recovery, bastando clonar o servidor de dados! Com um setup destes, fica claro o motivo da escolha feita por tais aplicativos

O cliente (computador cliente) fica sendo um mero detalhe; só precisa de um navegador, com uma página de acesso bem feita, bem diagramada e auto-explicativa, que registra os dados, mandando-os em tempo-real ao servidor.

Com um no-break conectado ao servidor, pode-se ainda contar com muito mais segurança de dados, disponibilidade e escalabilidade do sistema.

Característica da página, no(s) computador(es) cliente(s)

Será apresentada uma página inicial, com o logotipo da empresa, e campos de nome e senha; nesta página, pode-se entrar como usuário com privilégios de consulta (apenas), cadastro de clientes e animais, e diagnósticos/vacinas/compras de produtos, etc.

São 3 graus de privilégios de usuário, sendo eles, do menor grau de privilégios, para o maior:

Consulta < Cadastro < Completo

*Consulta é auto-explicativo; serve apenas para consulta de dados (de clientes, animais, produtos e horários livres para consultas, geralmente acessado pela secretária/recepcionista); é acessado pelo veterinário, para a impressão de receitas, e, pela secretária, para a impressão de boletos/cobranças;

*Cadastro é utilizado pela secretária/recepcionista, para cadastrar novos clientes, animais, e agendar consultas;

*Completo pode ser utilizado pelo próprio veterinário, para atualizar os dados dos animais, carteira de vacinação, internação, ficha veterinária, compra de produtos, etc; pode-se ser escalonado para utilização, também, da secretária, para anexar estes dados, caso o veterinário esteja em um dia muito cheio.

Temos, ainda, um último grau de usuário, que é o admin; este login é de exclusividade do administrador dos sistemas, utilizado para o upgrade dos softwares, e manutenção dos mesmos e da base de dados.

Análise dos requisitos não-funcionais

Quanto aos itens abaixo, temos:

*Manutenibilidade: simples, rápida, fácil e eficiente; caso seja necessário adicionar/remover algum campo na base de dados, basta replicar isso à página PHP; pode-se utilizar novas formas de “select” na base de dados, para melhor organização e visualização de dados; o sistema todo, em si, é de uma facilidade enorme de manutenção; além disso, MySQL proporciona recuperação de dados com facilidade; pode-se ainda fazer backups regulares do disco, no período da madrugada, etc;

*Eficiência: altíssima; todos os softwares utilizados são reconhecidos mundialmente, grátis e extremamente qualificados para um altíssimo desempenho;

*Segurança: enorme; um Debian sempre atualizado é um dos sistemas mais seguros do mundo;

*Confiabilidade: altíssima, e, pode ser expansível para um grau “paranóico” de segurança e disponibilidade de serviços; funcionamento 24/7 praticamente garantido;

*Portabilidade: o cliente pode rodar em quase qualquer plataforma, até celulares, caso queiram utilizar uma rede wireless/3G; o servidor é transparente ao usuário do sistema.

Por seguir o modelo “cliente-servidor”, tal sistema é otimizado ao máximo, podendo passar por manutenções, novo escalonamento, etc, sem a necessidade da interrupção de serviços do mesmo!

Tabela de definição de prioridades dos requisitos (funcionais e não-funcionais)

Prioridade	Grau
Urgente	0
Alta	1
Média	2
Baixa	3
Futuras	4

Tabela III: prioridades dos requisitos (Códigos)

Tabela dos requisitos (a serem garantidos e desenvolvidos):

Nome	Tipo	Grau
Efetuar login no sistema	Funcionais	1
Segurança no login	Não-Funcionais	1
Cadastro de dados no sistema	Funcionais	0
Segurança de dados do cadastro	Não-Funcionais	0
Backup de dados/cadastros	Misto	0
Rotate/exclusão programada dos backups	Misto	2
Gerência de usuários	Funcionais	1
Portabilidade do “computador cliente”	Não-Funcionais	1
Segurança do servidor	Não-Funcionais	1
Expansibilidade	Misto	1
Manutenibilidade	Misto	0
Disponibilidade	Misto	0
Suporte ao cliente	Não-Funcionais	1
Tela para inserção/remoção/consulta de dados	Funcionais	0
Apresentação da aplicação	Funcionais	0
Firewall	Não-Funcionais	3

Tabela IV: requisitos do projeto

PS: Misto engloba requisitos funcionais e não-funcionais

Etapa III

Passo 1

Introdução

Conforme sugere a Etapa III, devemos descrever os usuários que irão interagir com o sistema da CLIVET. Tal descrição fora previamente apresentada na Etapa II, de antemão, porém, iremos reapresentá-la aqui (apesar de julgar ser um desperdício de papel e bytes de arquivo...).

Desenvolvimento

Segue, abaixo, a Tabela V, referente aos usuários (nível de privilégio dos usuários, ou, permissão de acesso dos grupos de usuários) do sistema CLIVET.

Grupo	Requisitos Funcionais	Ações
Consulta (Monitor)	Autoexplicativo; serve apenas para consulta de dados (de clientes, animais, produtos e horários livres para consultas, geralmente acessado pela secretária/recepcionista); é acessado pelo veterinário, para a impressão de receitas, e, pela secretária, para a impressão de boletos/cobranças; além disso, pelo pessoal do suporte, para análise do DB / BD.	Consultar e imprimir;
Recepção	Utilizado pela secretária/recepcionista, para cadastrar novos clientes, animais, e agendar consultas;	Cadastro básico;
Veterinário	Utilizado para atualizar os dados dos animais, carteira de vacinação, internação, ficha veterinária, compra de produtos, etc; pode-se ser escalonado para utilização, também, da secretária, para anexar estes dados, caso o veterinário esteja em um dia muito cheio; por padrão, pode ser “apenas” consultado pelo grupo Recepção, porém, pode-se adicionar permissões de escrita para tal grupo, ou um usuário de outro grupo neste grupo;	Cadastro completo de dados;
Admin	Utilizado para o upgrade dos softwares, manutenção dos mesmos e da base de dados; criação de novas tabelas e modelos de select.	Completo / desenvolvimento e suporte.

Tabela V: grupos de usuários.

Passo 2

Introdução

Devemos gerar um glossário com pelo menos 15 termos que poderiam gerar dúvidas de interpretação por parte do cliente ou de nossa equipe. Para cada termo, elaboramos uma descrição do seu significado e também, em alguns deles, quais os sinônimos relacionados ao mesmo, com uma visão do mundo veterinários.

Desenvolvimento

Segue, abaixo, a Tabela VI, referente ao glossário de termos que podem levar as pessoas (cliente e nossa equipe) a dúvidas.

Termo	Descrição	Sinônimos
Documentação	Textos/diagramas que auxiliam no desenvolvimento e uso das aplicações;	Fluxogramas, help, dicas, treinamento.
Software Expansível	Inserção de novos módulos e funções nos produtos, após os mesmos terem sido entregues ao cliente;	Updates, novas versões;
Protótipo / versão alfa ou beta	Versão teste, de desenvolvimento;
Atualização	Visa corrigir erros dos produtos, e melhorias de segurança e performance;	Revisão;
Modelo “Cliente Servidor”	Analogia com “matriz e filiais” em uma empresa; uma concentra os dados e gerências; as demais, atuam, informando a matriz;
Banco/Base de Dados	Aplicação que “guarda” todos os dados dos animais, clientes, produtos, consultas, etc, em tabelas;
Browser/Navegador	Refere-se ao aplicativo onde serão feitas consultas e inserções de dados na base de dados	Firefox, Internet Explorer
Servidor	Analogia à matriz de uma empresa;
Cliente	Analogia às filiais de uma empresa;
Disaster-Recovery	Backups/cópias de segurança dos dados, feitas em um local distinto;
Backup da base de dados	Cópia de segurança dos dados da CLIVET, de seus clientes, etc;
Operação em tempo-real	A partir de um tempo muito curto, informações salvas podem ser consultadas, impressas e alteradas;
Confiabilidade	Capacidade dos sistemas e dados manterem-se disponíveis;
Segurança dos dados	Sigilo da informação; confiança que os dados somente serão acessados por pessoas/grupos autorizados;	Backup, Disaster-Recovery, Firewall, controle de acessos;
Dados do Cliente	Endereço, nome, telefone, sexo, etc;
Dados do(s) animal(is)	Nome, raça, tipo (cachorro, gato, ave, silvestre, etc), histórico de consultas, etc;
Vacina(s)	Tabela com todas as vacinas e datas, aplicadas aos animais;
Produtos	Controle de estoque da CLIVET;
Horário de Consultas	Gerência de horários da CLIVET;
Cálculo de lucro e gastos	Relação das consultas e gastos com produtos e salários.

Tabela VI: glossário.

Alunos:

Samir Piccolotto RA: 0943486061

Nathalia Elias RA: 0832494

Jean Pavanelli RA: 0945489169

Gustavo Chinaglia RA: 0901348552

Cesar Cardoso RA: 0901412846

Ciência da Computação

FAC-3, 5º Semestre, 2011

Engenharia de Software

Campinas, Abril de 2011