Etapas de Modelos de Processos de Software

thiagocarvalhojp
Mind Map by , created over 5 years ago

Mind Map on Etapas de Modelos de Processos de Software, created by thiagocarvalhojp on 06/09/2014.

111
6
0
Tags
thiagocarvalhojp
Created by thiagocarvalhojp over 5 years ago
Rights and Responsibilities Flashcards - Edexcel GCSE Religious Studies Unit 8
nicolalennon12
Globalisation Case Studies
annie
Improve your Learning using GoConqr
Micheal Heffernan
Using GoConqr to learn French
Sarah Egan
Procedimientos Operacionales
Adriana Forero
Chemistry Module C1: Air Quality
James McConnell
Cultural Studies
Emily Fenton
Macbeth Notes
Bella Ffion Martin
Unit 1: Business Studies GCSE
Libby Rose
GCSE REVISION TIMETABLE
rebekahanne11
Etapas de Modelos de Processos de Software
1 Análise e Definição de Requisitos
1.1 A fase de análise de requisitos, no contexto do desenvolvimento de um sistema, é aquela na qual são construídos modelos para representar o sistema a ser construído.
1.2 Principais Diagramas
1.2.1 Modelos baseados em cenários
1.2.1.1 São os casos de usos e histórias de usuários, já detalhados na Engenharia de Requisitos.
1.2.2 Modelos de Fluxo
1.2.2.1 A modelagem orientada a fluxos considera os dados e os processos que os transformam entidades distintas. É a representação da análise estruturada, e seu principal diagrama é o Diagrama de Fluxo de Dados, ou DFD.
1.2.3 Modelos de Comportamento
1.2.3.1 Os modelos comportamentais indicam como o software irá responder a estímulos ou eventos externos. Os diagramas de estado e de sequência representam este tipo de modelo.
1.2.4 Modelos de classe
1.2.4.1 A modelagem baseada em classes representa os objetos que o sistema irá manipular, as operações (também denominada métodos ou serviços) que serão aplicados aos objetos para efetuar a manipulação, alguns relacionamentos entre os objetos e as colaborações que ocorrem entre as classes definidas.
2 Projeto de sistema e software
2.1 A atividade de projeto engloba o conjunto de princípios, conceitos e práticas que conduzem ao desenvolvimento de um sistema ou produto com alta qualidade.
2.2 Características de um Projeto
2.2.1 O projeto deve implementar todos os requisitos
2.2.2 O projeto deve ser um guia legível
2.2.3 O projeto deve dar uma visão completa do software
2.3 Elaboração de um Projeto
2.3.1 Abstração
2.3.1.1 À medida que o nível de abstração migra de um nível mais alto para um nível mais baixo, a solução deixa de ser expressa na linguagem do domínio do problema para ser expressa em uma terminologia técnica.
2.3.2 Arquitetura
2.3.2.1 Uma meta do projeto de software é derivar um quadro da arquitetura de um sistema, que representará a organização a partir da qual atividades mais detalhadas do projeto são conduzidas.
2.3.3 Padrões
2.3.3.1 Os padrões de projeto são soluções comprovadamente eficazes que podem ser aproveitados em projetos de problemática recorrente.
2.3.4 Separação por interesses (por afinidades)
2.3.4.1 Esse conceito afirma que qualquer problema complexo pode ser tratado mais facilmente se decomposto em trechos a ser resolvidos e ou otimizados independentemente.
2.3.5 Modularidade
2.3.5.1 O desafio do projeto é modularizar o problema da melhor forma possível, minimizando custos.
2.3.6 Encapsulamento de informações
2.3.6.1 O princípio do encapsulamento diz que os módulos devem ser capazes de ocultar suas características uns dos outros, disponibilizando apenas os itens que interessam aos outros módulos.
2.3.7 Independência funcional
2.3.7.1 A independência funcional é atingida desenvolvendo-se módulos com função única e que pouco interagem com outros módulos. É medida qualitativamente pela coesão e pelo acoplamento.
2.3.8 Refinamento
2.3.8.1 O refinamento gradual é uma estratégia top-down. Um programa é desenvolvido refinando-se níveis procedurais sucessivamente.
2.3.9 Refatoração
2.3.9.1 Técnica de reorganização que simplifica o projeto ou código, sem mudar sua função ou comportamento. Em projetos de refabricação de software, deve-se examinar o projeto antigo, eliminar redundâncias, corrigir algoritmos eficientes ou desnecessários.
2.4 O Projeto Produz:
2.4.1 Projeto de dados/classes
2.4.1.1 O projeto de dados/classes transforma os modelos de classes em realizações de classes de projeto e nas estruturas de dados dos requisitos necessários para implementar o software.
2.4.2 Projeto de arquitetura
2.4.2.1 O projeto arquitetural define os relacionamentos entre os principais elementos estruturais do software, os estilos arquiteturais e os padrões de projeto que podem ser usados para satisfazer os requisitos definidos para o sistema e as restrições que o afetam.
2.4.3 Projeto de componentes
2.4.3.1 O projeto de componentes destrincha elementos estruturais da arquitetura, em uma descrição procedural dos componentes de software.
2.4.4 Projeto de interface de usuário
2.4.4.1 Conjunto de desenhos detalhados que representa fluxos de informação que entram em saem do sistema, como o sistema de comunica com sistemas externos e com as pessoas que o utilizam.
3 Implementação e teste de unidade
3.1 Reuso de Software
3.1.1 O reuso de software pode trazer vários benefícios, como ganho de tempo (o código já está escrito), confiança, redução de risco (o código já foi utilizado com sucesso anteriormente), dentre outros fatores.
3.2 Na implementação, o sistema é codificado, ou seja, ocorre a tradução da descrição computacional obtida na fase de projeto em código executável, mediante o uso de uma ou mais linguagens de programação.
3.3 Teste de Unidade
3.3.1 O teste de unidade é o teste pontual, realizado pelo programador, que verifica que aquele componente ou módulo que ele desenvolveu realmente faz o que deveria fazer, atendendo às especificações do projeto.
4 Integração e testes de sistema
4.1 Teste de software é uma atividade realizada para descobrir erros que foram produzidos inadvertidamente no momento em que o software foi projetado e construído. Pode ser planejado antecipadamente e conduzido sistematicamente.
4.2 Estratégias de Teste de Software
4.2.1 Teste de unidade
4.2.1.1 Se concentra em cada unidade: componente, classe ou módulo. Usa intensamente técnicas de teste com caminhos distintos, com o objetivo de descobrir erros dentro do módulo testado.
4.2.2 Teste de integração
4.2.2.1 Técnica sistemática para construir a arquitetura do software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces (comunicação entre os módulos, não confundir com interface com o usuário).
4.2.3 Teste de validação
4.2.3.1 A validação de software é conseguida por meio de uma série de testes que demonstram conformidade com os requisitos.
4.2.3.2 Em software para ser usado por muitos clientes:
4.2.3.2.1 Teste Alfa
4.2.3.2.1.1 É conduzido na instalação do desenvolvedor por um grupo representativo de usuários finais. Nele, o desenvolvedor monitora os usuários, registrando os erros e os problemas de uso.
4.2.3.2.2 Teste Beta
4.2.3.2.2.1 É conduzido nas instalações dos usuários finais. Via de regra, o desenvolvedor não está presente, e os erros e problemas encontrados são reportados pelos usuários.
4.2.4 Teste de sistema
4.2.4.1 Teste de recuperação
4.2.4.1.1 Força o sistema a falhar de várias formas e verifica se a recuperação é executada corretamente;
4.2.4.2 Teste de segurança
4.2.4.2.1 Verifica se os mecanismos de proteção incorporados ao sistema protegem contra acesso indevido;
4.2.4.3 Teste de esforço
4.2.4.3.1 Coloca o programa em condições anormais. “Até onde podemos forçar o sistema até que ele falhe?”
4.2.4.4 Teste de desempenho
4.2.4.4.1 Testa o desempenho, em tempo de execução, do software em um contexto de sistema integrado. Pode ser feito em conjunto com testes de esforço;
4.2.4.5 Teste de disponibilização
4.2.4.5.1 Executa o software em cada ambiente no qual ele deve operar, como em vários sistemas operacionais, vários navegadores web, ou várias plataformas.
4.3 Técnicas de Teste de Software
4.3.1 Atributos Desejáveis em um Teste:
4.3.1.1 Alta probabilidade de encontrar erros
4.3.1.2 Não ser redundante
4.3.1.3 O melhor de uma categoria
4.3.1.4 Nem muito simples, nem muito complexo.
4.3.2 Técnicas de Teste
4.3.2.1 Caixa Branca
4.3.2.1.1 Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de caminho básico, teste de ciclos, teste de caminhos lógicos, códigos nunca executados, teste de estrutura de controle.
4.3.2.2 Caixa Preta
4.3.2.2.1 Também chamada de teste funcional, teste comportamental, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido.
5 Operação e manutenção
5.1 Na implantação, o sistema é empacotado, distribuído e instalado no ambiente do usuário. Os manuais do sistema são escritos, os arquivos são carregados, os dados são importados para o sistema, e os usuários são treinados para utilizar o sistema corretamente. Dependendo da situação, pode ocorrer também a migração de sistemas de do software e de dados preexistentes.

Media attachments