Muito bem

Prévia do material em texto

Muito bem, já começamos dizendo que, a análise é o principal fator durante o processo de desenvolvimento. Por que?
Uma análise mal feita, digamos assim, acarreta uma série de problemas e imprevistos durante o desenvolvimento.
A equipe de desenvolvimento se perde, muitos detalhes importantes ficam para trás, recursos e funcionalidades implementadas que fogem da solução que se propõe, enfim, muitas coisas desagradáveis para a empresa.
Por isso, uma análise, deve ser muito bem feita, para que o resultado final seja realmente aquilo que o cliente pediu.
Então observe a imagem abaixo:
No primeiro quadro, o cliente explica o que ele precisa. É normal nessa etapa, o cliente não deixar muito claro o que quer, por isso, o analista deve extrair o máximo de informação e detalhes que puder. Percebe-se que o cliente explica, e dá a entender que quer um balanço com três tábuas.
Como um bom líder de projeto, ele já deveria enxergar esse erro, pois, não é normal um balanço com três tábuas.
Muito bem, no segundo quadro, observamos que o líder do projeto entendeu a explicação do cliente como sendo um balanço em frente ao tronco de uma árvore, ou seja, seria impossível balançar.
Para resolver esse erro, observamos que no terceiro quadro o analista corta o tronco ao meio e coloca duas estacas ao lado para segurar a parte de cima da árvore que está separada, sendo assim, já era mais possível balançar, e mesmo assim, não ficou tão legal a ideia.
No quarto quadro, o programador implementa, amarrando o balanço na árvore, só que no tronco, tornando a tarefa de balançar impossível, e pra piorar, arrastando no chão.
No quinto quadro, o consultor descreve o produto como se fosse o melhor existente no mercado, colocando qualidades e característica que nem possui, apenas para deixar o cliente na expectativa de algo perfeito e que resolveria o seu problema.
No sexto quadro, percebe-se que a documentação nem existe, muitas empresas não documentam nada sobre o projeto, o que pode ser um grande problema no futuro.
No sétimo quadro, as funcionalidades não foram todas implementadas, ou seja, o projeto não estava completo, "redondinho". É um outro grande problema, muitas vezes devido ao erro na estipulação no prazo de entrega, para não atrasar, acaba entregando o produto incompleto para o cliente.
No oitavo quadro, vemos que o ciente foi cobrado bem caro, levando em conta o quinto quadro, ou seja, o cliente paga um produto super, quando na verdade o produto não atinge 50% daquilo que deveria.
No penúltimo quadro, notamos que a manutenção do sistema quase inexiste, e no último quadro, o que o cliente realmente queria era um balanço simples feito com pneu.
Concluímos com isso que, um erro lá no início de tudo, perdura durante todo o processo de desenvolvimento, o cliente não soube explicar de forma clara o que gostaria, o analista não colheu todos os dados necessários, a projeção saiu errado, a implementação mais ainda, sem documentação, faltando recursos, manutenção complicada, e o pior, não era o que o cliente queria.
Quando falamos de um Requisito Funcional estamos nos referindo à requisição de uma função que um software deverá atender/realizar. Ou seja, exigência, solicitação, desejo, necessidade, que um software deverá materializar
REQUISITO DE SOFTWARE
REQUISITO NÃO FUNCIONAL
REQUISITO FUNCIONAL
REGRA DE NEGÓCIO
	Requisitos Funcionais (Identificador e Controle de Cliente)
	RF001 – Incluir nome cliente pessoa física
	RF002 – Alterar nome cliente pessoa física
	RF003 – Consultar nome cliente pessoa física
	RF004 – Excluir nome cliente pessoa física
	RF005 – Incluir cliente pessoa jurídica
	RF006 – Alterar cliente pessoa jurídica
	RF007 – Consultar cliente pessoa jurídica
	RF008- Incluir nome loja cliente
Um analista de requisitos gera casos de uso após a coleta e validação de um conjunto de requisitos funcionais a hierarquia de requisitos funcionais é usuário pedido das partes interessadas
Uma funcionalidade pode realizar um ou mais Requisitos Funcionais. Requisito funcional não é uma funcionalidade, é uma necessidade funcional (uma função) que o software deve atender
Requisitos Não Funcionais são premissas ou restrições que o sistema deverá atender, mas que não são realizados através de funcionalidades. Podem ou não estar associados a Requisitos Funcionais, mas não tem, necessariamente, relação com o negócio, na visão do usuário
	Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas. Estes requisitos dizem respeito a como as funcionalidades serão entregues ao usuário
RNF001 – O sistema deverá ser integrado ao sistema de internet
	RNF002 – O sistema deverá utilizar o programa de PGadmin para acessar o banco de dados
	RNF003 – O sistema deverá utilizar o banco de dados SQLserve
	RNF004 – O ambiente de desenvolvimento que será utilizado será Java
	RNF005 – O sistema deverá utilizar mecanismo para garantir a integridade dos arquivos transmitidos aos clientes.
	RNF006 – Os arquivos transmitidos devem utilizar o tipo de compactação zip.
	RNF007 – deve ser utilizado o cadastro de usuários da base de dados atual da empresa.
O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre os analistas e o cliente.
Um diagrama de Caso de Uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. 
O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.
DIAGRAMA DE CASOS DE USO
O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre os analistas e o cliente.
Um diagrama de Caso de Uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. 
O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.
Notação
O diagrama de Caso de Uso é representado por:
Atores;
Casos de uso;
Relacionamentos entre estes elementos.
Estes relacionamentos podem ser:
Associações entre atores e casos de uso;
Generalizações entre os atores;
Generalizações, includes entre os casos de uso.
Casos de uso podem opcionalmente estar envolvidos por um retângulo ou círculo que representa os limites do sistema.
Em maiores detalhes:
Atores
	
	Um ator é representado por um boneco e um rótulo com o nome do ator. Um ator é um usuário do sistema, que pode ser um usuário humano ou um outro sistema computacional.
Caso de uso
	
	Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso. Um caso de uso define uma grande função do sistema. A implicação é que uma função pode ser estruturada em outras funções e, portanto, um caso de uso pode ser estruturado.
Relacionamentos
o        Ajudam a descrever casos de uso
Entre um ator e um caso de uso
Associação
	
	Define uma funcionalidade do sistema do ponto de vista do usuário.
Entre atores
Generalização
	
	- Os casos de uso de B são também casos de uso de A
- A tem seus próprios casos de uso
Entre casos de uso
Include
Um relacionamento include de um caso de uso A para um caso de uso B indica que B é essencial para o comportamento de A. Pode ser dito também que B is_part_of A.
Diagrama de caso de classe Em programação, um diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos.
É uma modelagem muito útil para o desenvolvimento de sistemas, pois define todas as classes que o sistema necessita possuir e é a base para a construção dos diagramas de comunicação, sequência e estados.
Conceitos
Classe: Elemento abstrato que representa um conjunto de objetos. A classe contém a especificação do objeto; suas características: atributos (características) e métodos (ações / comportamentos).
Atributo: Define características da classe como:
Visibilidade:
Pública, representada pelosímbolo: +, onde outras classes podem ter acesso ao atributo;
Privada, representada pelo símbolo: -, o atributo somente é acessado diretamente pela própria classe e;
Protegida, representada pelo símbolo: #, ou
Pacote, representada pelo símbolo: ~, que é acessado pelo relacionamento da classe com a classe externa.
Nome: Identificação do atributo.
Tipo de dados: Tipo de dado do atributo.
Multiplicidade: Relacionamentos.
Valor inicial: Depende da linguagem de programação, valor opcional.
Propriedade: Características do elemento, opcional.
Operação: Função requerida a um objeto abstrato.
Nome, Visibilidade e Parâmetros.
Associação: Relacionamentos entre classes.
Nome: Nome da associação.
Multiplicidade.
Navegação: De onde vêm as informações da classe e para onde vão
O Diagrama de atividade é um diagrama definido pela Linguagem de Modelagem Unificada (UML), e representa os fluxos conduzidos por processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. Comumente isso envolve a modelagem das etapas sequenciais em um processo computacional.
Os diagramas de atividade não são importantes somente para a modelagem de aspectos dinâmicos de um sistema ou um fluxograma, mas também para a construção de sistemas executáveis por meio de engenharia de produção reversa.
Cada estado corresponde a uma situação que ocorrerá. Quando verde, os carros podem prosseguir na via. Passado um tempo, é acionada a tarefa de mudar para amarelo. Então o semáforo passa de verde para amarelo. Aqui os carros ficam em estado de atenção e já aguardam a próxima transição.
O próximo passo é passar para vermelho. Nesse estado, os carros estão parados na via. De vermelho, o próximo estado somente será verde, assim, os carros podem voltar a trafegar na via.
Diagrama de maquina de estados
Modelar significa criar um modelo que explique as características de funcionamento e comportamento de um software a partir do qual ele será criado, facilitando seu entendimento e seu projeto, através das características principais que evitarão erros de programação, projeto e funcionamento. É uma parte importante do desenho de um sistema de informação.