1658544
Description
Flashcards by Raphael Luiz Fonseca, updated more than 1 year ago
|
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.