Processo De Software

Get Started. It's Free
or sign up with your email address
Rocket clouds
Processo De Software by Mind Map: Processo De Software

1. CLÁSSICOS

1.1. Iinterativos

1.2. Cascata

1.2.1. O modelo cascata configura-se como um modelo de engenharia projetado para ser usado no desenvolvimento de diferentes tipos de software. O objetivo principal deste sistema é que as diferentes fases de desenvolvimento seguem uma sequência: A primeira etapa se direciona para a segunda e esta se movimenta para a terceira e assim por diante.

1.2.1.1. Sequenciais

1.2.2. Análise e Definição dos Requisitos

1.2.2.1. Nesta fase, são estabelecidos os requisitos do produto que o idealizador almeja desenvolver, o que normalmente se baseia nos serviços que precisam ser fornecidos, nas limitações aceitáveis e os objetivos do software.

1.2.3. Projeto do Sistema

1.2.3.1. O projeto de elaboração do sistema é composto por vários processos que se centralizam em quatro atributos diferentes do sistema, sendo: a estrutura de dados, a arquitetura do software, caracterização das interfaces e detalhes procedimentais.

1.2.4. Implementação

1.2.4.1. A etapa de implementação é quando os programas são criados. Caso o projeto tenha um nível de detalhamento mais avançado, a etapa de codificação pode ser implementada de maneira automática.

1.2.5. Teste do Sistema

1.2.5.1. Após o fim da etapa de codificação, inicia-se a fase da realização de teste do sistema. Este processo de teste é focado em dois pontos principais, que são as lógicas internas do software e as suas funcionalidades externas.

1.2.6. Manutenção

1.2.6.1. A fase da manutenção se baseia na correção de erros que não detectados durante os testes, em melhorias funcionais e de preferência com os demais tipos de suporte.

1.3. OpenUP

1.3.1. A Open UP, por si só, é um Processo Unificado leve que aplica as abordagens iterativa e incremental em um ciclo de vida estruturado, abordando uma filosofia ágil e pragmática que foca na natureza colaborativa do desenvolvimento de software.

1.3.2. Iniciação

1.3.2.1. fase em que se enfatiza o processo de análise de negócios e análise de requisitos do negócio analisado, dando uma ênfase menor a arquitetura e implementação;

1.3.3. Elaboração

1.3.3.1. fase em que se enfatiza o processo de desenvolvimento da análise arquitetural da solução proposta;

1.3.4. Construção

1.3.4.1. fase em que se enfatiza o processo de implementação da solução proposta, bem como, testes e integração;

1.3.5. Construção

1.3.5.1. fase em que se enfatiza o processo de implantação do release, com importante foco na realização do teste beta e reconfiguração necessária do sistema, além de foco no processo de treinamento do usuário e conversão dos dados legados.

2. ÁGEIS

2.1. Scrum

2.1.1. Scrum é um framework para organizar e gerenciar trabalhos complexos, tal como projetos de desenvolvimento de software.

2.1.2. Sprint Planning

2.1.2.1. O product backlog pode representar muitas semanas ou até meses de trabalho, o que é muito mais do que pode ser concluído em um único e curto sprint.

2.1.3. Daily Scrum

2.1.3.1. Todos os dias, idealmente no mesmo horário, os membros da equipe de desenvolvimento devem realizar uma reunião com tempo definido (15 minutos ou menos), chamado Daily Scrum.

2.1.4. Execução do Sprint

2.1.4.1. A criação de um sprint envolve um trabalho constante de comunicação entre os times de desenvolvimento, o Scrum Master e o Product Owner. Eles devem compartilhar suas necessidades, sua capacidade de produção e sua evolução no alcance das metas, a fim de evitar a quebra de expectativas ao final de cada etapa.

2.1.5. Revisão Sprint

2.1.5.1. Na Sprint Review, a equipe de desenvolvimento apresenta o tudo o que foi desenvolvido do Backlog, o que não foi desenvolvido e as dificuldades presenciadas. Normalmente, é feita uma apresentação formal em slides e reservado um tempo para o teste das plataformas já desenvolvidas.

2.1.6. Retrospectiva Sprint

2.1.6.1. Enquanto o objetivo do Sprint Review é verificar necessidades de adaptações no produto, o Sprint Retrospective tem como objetivo verificar necessidades de adaptações no processo de trabalho.

2.2. Feature Driven Development (FDD)

2.2.1. Desenvolver um Modelo Abrangente

2.2.1.1. Pode envolver desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção.

2.2.2. Construir uma Lista de Funcionalidades

2.2.2.1. decomposição funcional do modelo do domínio, em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da atividade (funcionalidades).

2.2.3. Planejar por Funcionalidade

2.2.3.1. abrange a estimativa de complexidade e dependência das funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a construção.

2.2.4. Detalhar por Funcionalidade

2.2.4.1. já dentro de uma iteração de construção, a equipe detalha os requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.

2.3. eXtreme Programming (XP)

2.3.1. Sobre o XP

2.3.1.1. O XP é um método sistêmico para desenvolvimento de software. O processo inicia por um plano geral, ou seja, entender o problema como um todo, mas sem muitos detalhes e, posteriormente, reparte o problema em partes, para dar início ao seu desenvolvimento.

2.3.2. Planejamento

2.3.2.1. Seu objetivo é determinar rapidamente o escopo da próxima Release, combinando prioridades do negócio e estimativas técnicas.

2.3.3. Projeto "Designing"

2.3.3.1. A prática de teste no XP é bastante técnica, e envolve a presença do cliente no desenvolvimento e na validação de testes. O cliente compartilha com o desenvolvedor sobre o funcionamento do sistema. Os testes também se tornam as especificações da programação, visto que o teste diz o que deve estar de acordo e o que não deve estar de acordo, é como uma especificação.

2.3.4. Codificação

2.3.5. Testes

2.4. Microsoft Solutions Framework (MSF)

2.4.1. Idealização

2.4.1.1. Desenvolver uma compreensão clara do que é necessário dentro do contexto de restrições do projeto.

2.4.1.2. Montar a equipe necessária para imaginar as soluções com opções e abordagens que melhor atendam a essas necessidades, satisfazendo de forma ideal essas restrições.

2.4.2. Planejamento

2.4.2.1. Transformar a solução conceitual em projetos e planos tangíveis para que ela possa ser compilada em uma Trilha de Compilação.

2.4.3. Compilação

2.4.3.1. Compilar os vários aspectos de uma solução de acordo com as entregas da Trilha de Planejamento, tais como projetos, planejamentos, cronogramas e requisitos.

2.4.4. Estabilização

2.4.4.1. Melhorar a qualidade da solução para atender aos critérios de liberação para implantação na produção.

2.4.4.2. Confirmar que a solução atende às necessidades e expectativas dos participantes.

2.4.4.3. Validar a usabilidade da solução a partir de uma perspectiva do usuário.

2.4.4.4. Maximizar o sucesso e minimizar os riscos associados à implantação da solução e às operações nos ambientes de destino da solução.

2.4.5. Implantar

2.4.5.1. Integrar uma solução bem-sucedida na produção dentro dos ambientes designados.

2.4.5.2. Transferir a responsabilidade da entrega da solução restante de uma equipe de projeto até as equipes de operações e suporte da forma mais suave e rápida possível.

2.5. Dynamic System Development Model (DSDM)

2.5.1. Análise

2.5.1.1. Análise de viabilidade

2.5.1.1.1. Estágio onde a utilização do DSDM é avaliada. Analisando o tipo de projeto, problemas organizacionais e de pessoas, é tomada a decisão de se utilizar ou não o DSDM.

2.5.1.2. Análise de negócio

2.5.1.2.1. Onde são analisadas características essenciais do negócio e tecnologias a serem empregadas.

2.5.2. Interação do modelo funcional

2.5.2.1. Identificar o protótipo funcional

2.5.2.1.1. Determinar as funcionalidades que serão implementadas é o resultado desta iteração.

2.5.2.2. Agenda

2.5.2.2.1. Definir quando e como as funcionalidades serão implantadas.

2.5.2.3. Criação do protótipo funcional

2.5.2.3.1. Desenvolver um PROTÓTIPO FUNCIONAL, de acordo com a Agenda e o MODELO FUNCIONAL.

2.5.2.4. Revisão do Protótipo funcional

2.5.2.4.1. Efetuar correções do protótipo desenvolvido. Isto pode ser feito através de testes dos usuários finais ou por análise da documentação.

2.5.3. Iteração de desenho e construção

2.5.3.1. Identificar o modelo do desenho

2.5.3.1.1. Identificar requisitos funcionais e não-funcionais que devem estar no sistema testado.

2.5.3.2. Agenda

2.5.3.2.1. Como e quando serão realizados estes requisitos.

2.5.3.3. Criação do protótipo do desenho

2.5.3.3.1. Criar um sistema (PROTÓTIPO) que pode tranquilamente ser manipulado pelos usuários finais no uso diário, também para razões de teste.

2.5.3.4. Revisão do protótipo

2.5.3.4.1. Efetuar correções no sistema desenhado. Novamente testando e revisando através das técnicas mais utilizadas.

2.5.4. Implantação

2.5.4.1. Orientação e Aprovação do usuário

2.5.4.1.1. Usuários finais aprovam o sistema testado (APPROVAL) pela implantação e orientação fornecida pelo respectivo sistema criado.

2.5.4.2. Treinamento

2.5.4.2.1. Treinar futuros usuários finais no uso do sistema.

2.5.4.3. Implantação

2.5.4.3.1. Implantar o sistema testado e liberar aos usuários finais, chamado SISTEMA ENTREGUE.

2.5.4.4. Revisão de negócio

2.5.4.4.1. Rever o impacto que o sistema implantado causa sobre o negócio, pode-se utilizar o cruzamento dos objetivos iniciais com a análise atual como termômetro.

3. MISTOS

3.1. Rup

3.1.1. Especificação de Requisitos

3.1.1.1. tradução da necessidade ou requisito operacional para uma descrição da funcionalidade a ser executada.

3.1.2. Projeto de Sistema

3.1.2.1. tradução destes requisitos em uma descrição de todos os componentes necessários para codificar o sistema

3.1.3. Programação (Codificação)

3.1.3.1. produção do código que controla o sistema e realiza a computação e lógica envolvida.

3.1.4. Verificação e Integração (Verificação)

3.1.4.1. verificação da satisfação dos requisitos iniciais pelo produto produzido.