Please enable JavaScript.
Coggle requires JavaScript to display documents.
Ciclo de vida do software - Coggle Diagram
Ciclo de vida do software
Engenharia de requisitos
Requisitos funcionais
Coisas que o sistema deve ter
Comportamento referente a determinadas entradas e saídas
Requisitos não funcionais
Restrições sobre o sistema
Requisitos de usuário
Solicitações do cliente que o sistema deve atender
Requisitos de sistema
Para atender ao cliente, tais tarefas devem ser executadas no software
Regras
Documento de requisitos
Versão oficial contendo o que o desenvolvedor deve implementar
Especificação de requisitos
Descrever requisitos de usuário e de sistema no documento de requisitos
Formas de escrever
Linguagem natural
Linguagem estruturada
Elicitação e análise de requisitos
Obter com clientes informações sobre o domínio da aplicação
Descoberta de requisitos
Classificação e organização de requisitos
Priorização e negociação de requisitos
Especificação de requisitos
Entrevistas
Cenários
Casos de uso
Etnografia
Acompanhar o processo de trabalho pessoalmente para levantar requisitos na prática
Validação de requisitos
Verifica se os requisitos definem o que o cliente realmente quer
Gerencimento de requisitos
Modelagem de sistemas
Modelo de contexto
Um modelo onde se possui uma perspectiva externa, na qual o contexto ou o ambiente do sistema é modelado
Modelo de interação
Um modelo que trás a perspectiva de interação, modelando todas as interações entre um sistema e seu ambiente
Modelo estrutural
No modelo estrutural é modelada a organização de um sistema ou a estrutura dos dados processados por ele
Modelo comportamental
Modelo comportamental trás a perspectiva comportamental, modelando o comportamento dinâmico do sistema e o modo como ele retorna os eventos
Engenharia dirigida por modelo
É uma abordagem para o desenvolvimento na qual os modelos se tornam as saídas principais do processo de desenvolvimento
Arquitetura dirigida por modelo
É uma abordagem para o desenvolvimento onde a arquitetura e o desenvolvimento são feitos com os modelos no centro do processo
Objetivo
Desenvolver modelos diferentes para representar o sistema a partir de perspectivas distintas
Projeto de arquitetura
A utilização de cada tipo de arquitetura e de estrutura dependem dos requisitos não funcionais do sistema
Desempenho
Segurança da informação
Disponibilidade
Manutenibilidade
Segurança
Padrões de arquitetrura
MVC (Model View Controller)
O sistema é estruturado em
3
componentes.
Model
que gerencia os dados.
View
que define e gerencia como os dados são apresentados.
Controller
que gerencia as interações do usuário para os demais componentes.
Camada
O sistema é organizado em
camadas
, onde é associado uma funcionalidade a uma camada. Uma camada fornece serviços para a camada acima dela. Priorizando as funcionalidades essenciais nos níveis mais inferiores
Repositório
Sistema onde tudo é gerenciado por um
repositório
que todos os componentes possuem acesso, tornando a interação entre os componentes somente por meio dele.
Cliente-Servidor
É apresentado como um conjunto de serviços, onde cada serviço é um
servidor
único.
Clientes
são usuários nesse serviço para poder utiliza-lo
Duto e filtro
É organizado de maneira que cada componente de processamento(
filtro
) é discreto e executa um tipo de manipulação de dado, os dados fluem(como em um
duto
) de um componente para outro
Testes de software
Teste de unidade
São testadas
unidades
de programa ou classes individuais
Teste de componentes
São testados
componentes
formados por várias unidades integradas
Teste de sistema
São testados alguns ou todos os componentes que são integrados em um sistema, é realizado um teste do
sistema
como um todo
Objetivo
O teste de desenvolvimento é basicamente um processo de teste dos defeitos,
buscando
descobrir os bugs e as falhas do software
Evolução de software
Objetivo
A utilização de um processo de
evolução de software
é devido a necessidade dos sistemas terem sempre que continuar se adaptando e evoluindo para permanecerem sendo úteis
Manutenção de software
Reparo de bugs e vulnerabilidades
Adaptação de ambiente a novas plataformas
Acréscimo de funcionalidade
Processos de evolução
Processo de identificação de mudança e evolução
Modelo geral de processo de evolução
Implementação da mudança
Processo de reparo emergencial
Sistemas legado
Problemas em migração
Falta de especificação
Processos de negócio e fluxo de funções complexas
Regras de negócio não documentadas
Novo software pode surgir problemas inesperados
Ajustes tendem a ser caros
Estilo de código muito variado devido a quantidade de pessoas que foram responsáveis pelo desenvolvimento ao passar do tempo
Linguagens utilizadas que podem acabar sendo obsoletas
Problema com documentação desatualizada
Anos de manutenção acabam desgastando o código, causando dificuldade em entender o mesmo
Especificação do sistema para um hardware antigo
Fatores de avaliação
Compreensibilidade
Documentação
Dados
Desempenho
Linguagem de programação
Gerenciamento de configuração
Dados de teste
Habilidades do pessoal
Reengenharia de software
Tradução de código-fonte
Engenharia reversa
Melhoria de estrutura do programa
Modularização do programa
Reengenharia de dados
Projeto e implementação
Compreender e definir o contexto e as interações
Projetar a arquitetura
Questões de implementação
Reúso
Gerenciamento de configuração
Optar por open source ou proprietário