Created by Raphael Luiz Fonseca
over 9 years ago
|
||
Question | Answer |
- Preocupada com todos os aspectos sobre a produção de software | Conceito Engenharia de Software |
- Racionalizam o desenvolvimento de Software | Processos |
- Conhecimento técnico - "Como" fazer | Métodos |
- Suporte automatizado para processos e métodos | Ferramentas |
- É algo maior - Preocupa-se com todos os aspectos de sistemas baseados em computador - Software - Hardware -Processos - Pessoas - Outros sistemas | Engenharia de Sistemas |
- São uma representação abstrata e simplificada do processo de desenvolvimento software, apresentada a partir de uma perspectiva específica - Contém: Esqueleto, Ordem, Produtos gerados | Modelos de Ciclo de Vida |
- Modelo Clássico - Estrutura composta por várias etapas que são executadas de forma sistemática e sequencial - Entregas bem definidas - Atrasa a redução de riscos | Modelos de Ciclo de Vida - Cascata |
- Esboçar escopo e requisitos - Fazer estimativas razoáveis sobre recursos, custos e prazos | Fases do Ciclo de Vida do Software - Planejamento |
- Refinar os requisitos e escopo - Entender o domínio do problema, com comportamento e funcionalidades esperados | Fases do Ciclo de Vida do Software - Análise e Especificação de Requisitos |
- Incorporar requisitos tecnológicos aos requisitos essenciais do sistema - Projetar a arquitetura do sistema | Fases do Ciclo de Vida do Software - Projeto |
- Traduzir o projeto em uma forma passível de execução pela máquina - Codificação | Fases do Ciclo de Vida do Software - Implementação |
- Realizar diversos tipos de testes afim de verificar o software | Fases do Ciclo de Vida do Software - Testes |
- Colocar o software em produção - Treinar Pessoas - Manter o software - Gerenciar serviços | Fases do Ciclo de Vida do Software - Implantação, Operação e Manutenção |
- Pequenas versões são entregues aos clientes. - Trabalhar junto aos clientes - Entregar resultados o mais rápido possível - Começar com os requisitos mais bem compreendidos - Novas funcionalidades são adicionadas à medida que os clientes as propõem | Modelos de Ciclo de Vida - Prototipagem Evolucionária |
- Pequenas versões prototípicas são disponibilizadas aos clientes para avaliação - Serve para entender e clarificar os requisitos - Deve-se começar com os requisitos MAIS difíceis e menos compreendidos. | Modelos de Ciclo de Vida - Prototipagem Descartável |
- Modelo baseado em técnicas matemáticas para especificar, desenvolver e verificar software - Têm sido aplicados apenas ao desenvolvimento de sistemas críticos Ex: Sistemas de avião, tráfego aéreo, etc | Modelos de Ciclo de Vida - Métodos Formais |
- Desenvolver e entregar software em incrementos, com cada incremento contendo parte da funcionalidade requerida - Requisitos são definidor antes do incremento, sendo os mais críticos priorizados - Mini projeto cascata para cada funcionalidade | Modelos de Ciclo de Vida - Incremental |
- Cada volta no espiral representa uma fase no processo - Não há fases fixas - Análise de Riscos | Modelos de Ciclo de Vida - Espiral |
- Indivíduos e Interações - Software funcionando - Colaboração com o cliente - Adaptação e mudanças | Manifesto Ágil |
- Metodologia Ágil para equipes pequenas e médias desenvolvendo software com requisitos VAGOS e em mudança constante | Extreme Programming (XP) |
- Uma história que todos podem contar a cerca de como funciona o sistema - Facilita a comunicação dos interessados | Práticas XP - Metáfora |
- O código está, a qualquer momento, na forma mais simples que passe em todos os testes | Práticas XP - Projeto Simples |
- As entregas são feitas através de pequenos releases de software FUNCIONANDO - Dá confiança ao cliente sobre o progresso geral | Práticas XP - Pequenas Versões |
- O código deve ser constantemente melhorado, tornando-o mais simples e mais genérico, removendo redundâncias e duplicidade | Práticas XP - Refatoração |
- Os programadores trabalham em pares, checando mutuamente o trabalho feito - Mesma máquina, mesmo mouse, mesmo monitor | Práticas XP - Programação em Pares |
- Todos são responsáveis por todo os código e qualquer pessoa está autorizada a fazer mudanças nele | Práticas XP - Propriedade Coletiva do Código |
- Todo código é desenvolvido de acordo com um estilo e formato consistente. | Práticas XP - Padrão de codificação |
- Cada programador trabalha 40 horas por semana, no máximo | Práticas XP - Ritmo Sustentável |
- Reuniões rápidas e diárias com a equipe para discutir somente o essencial | Práticas XP - Reuniões em Pé |
- O cliente, com conhecimento do negócio, deve estar disponível em tempo integral para a equipe | Práticas XP - Cliente Sempre Presente |
- Uma estrutura de teste unitários automatizada é criada e os testes são escritos antes mesmo das funcionalidades serem implementadas | Práticas XP - Desenvolvimento Orientado a Testes |
- Os diversos módulos de software são integrados o mais cedo possível, para evitar evitar problemas de integração no futuro | Práticas XP - Integração Contínua |
- Requisitos são incrementados com estórias dos usuários e priorizados para serem incluídos em uma determinada iteração | Práticas XP - Planejamento Incremental |
- Comunicação - Simplicidade - Feedback - Coragem - Respeito | Valores do XP |
- Metodologia Ágil - Equipes se auto-organizam - Produto evolui em uma série de "Sprints" - Os requisitos são listados em um "Product Backlog" - É um processo gerencial | Características Scrum |
- Uma lista ordenada de tudo que é necessário no produto - Cada item tem sua prioridade dentro dessa lista - É replanejado (repriorizado) no início de cada Sprint | Artefatos Scrum - Product Backlog |
- Uma lista de tarefas que a equipe se compromete a completar dentro de uma determinada sprint - Os itens são derivados a partir do Product Backlog - São considerados: prioridade de itens e tempo/esforço | Artefatos Scrum - Sprint Backlog |
- Define as funcionalidades do produto - Decide as datas de lançamento e conteúdo - Prioriza as funcionalidades de acordo com o valor para empresa - Aceita o rejeita resultados das sprints | Papéis do Scrum - Product Owner (PO) |
- Contém tipicamente entre 5 a 9 pessoas - Equipe Multi-Funcional - Dedicação Integral ao produto - Auto-Organizável - Trocas só na mudanças de Sprints | Papéis do Scrum - Team |
- Responsável pela aplicação dos valores e práticas Scrum - Remove obstáculos, facilita resultados - Garante a plena funcionalidade e produtividade da equipe - Escudo para interferências externas | Papéis do Scrum - Scrum Master |
- Selecionam-se itens do Product Backlog, e as tarefas são identificadas e estimadas - De forma colaborativa, não apenas feito pelo Scrum Master | Eventos da Scrum - Planejamento da Sprint |
- Apenas os membros da equipe, todos os dias, de pé, durante 15 minutos | Eventos da Scrum - Reuniões Diárias ( Daily Scrums) |
- Apresentação dos dados obtidos - Todo o time participa, informalmente - 2 horas de preparação no máximo - Sem slides | Eventos da Scrum - Revisão da Sprint |
- Ocorre antes da revisão da sprint e antes da próxima reunião de planejamento - Inspeciona a última sprint em termos de: Pessoas e Relações / Processos e Ferramentas - Enquanto a revisão da sprint analisa o PRODUTO, a retrospectiva analisa o PROCESSO | Eventos da Scrum - Retrospectiva da Sprint |
- É focada na entrega regular de funcionalidade valiosas para o cliente - As equipes podem variar de 10 a 250 programadores - Não necessita de tanta documentação, não é tão detalhado. | Feature Driven Development (FDD) |
- O líder administrativo do projeto - Planeja orçamento, elabora relatórios e protege a equipe de distrações externas. | Papéis FDD - Project Manager |
- Responsável pelo projeto geral do sistema - Tem a palavra técnica final sobre o software e sua arquitetura | Papéis FDD - Chief Architect |
- Lidera as atividades diárias do desenvolvimento - Lidera a equipe de desenvolvimento através de desafios técnicos | Papéis FDD - Development Manager |
- Desenvolvedores experientes - Lideram pequenas equipes de desenvolvedores individuais. | Papéis FDD - Chief Programmers |
- São os desenvolvedores individuais - Projetam, codificam, testam e documentam as funcionalidades | Papéis FDD - Class Owners |
- Usuários, clientes, patrocinadores - A base de conhecimento para os desenvolvedores | Papéis FDD - Domain Experts |
Ciclo de Vida FDD | |
- São ferramentas que auxiliam o engenheiro de SW em cada atividade associada ao desenvolvimento de SW - Não substituem uma metodologia de desenvolvimento de software sólida | Ferramentas CASES |
- São utilizadas durante todo o processo de desenvolvimento do SW | Ferramentas CASES - Horizontal |
- São específicas para uma disciplina do SW | Ferramentas CASES - Vertical |
- Apóiam as etapas iniciais da criação do sistema: - Fases de planejamento - Análise - Projeto de Aplicação | Ferramentas CASES - Front-End ou Upper CASE |
- Dão apoio à parte física, código, testes e manutenção | Ferramentas CASES - Back-End ou Lower CASE |
- Cobrem todo o ciclo de vida, do início ao fim | Ferramentas CASES - I-CASE ou Integrated CASE |
- Modelode de processo de software incremental que enfatiza um ciclo de desenvolvimento curto. - É uma adaptação "de alta velocidade" do modelo em cascata, no qual o desenvolvimento rápido é conseguido com o uso de uma abordagem de construção baseada em componentes. | Modelo RAD (Rapid Application Development) |
Want to create your own Flashcards for free with GoConqr? Learn more.