Engenharia de Software - Questões

Cascata Cascata Modelo V Cascata Desenvolvimento Paralelo Incremental Evolucionário CBSE Métodos Formais Orientado a Aspectos RUP Scrum Rad Extreme Programming Definição de requisitos Início do processo Início do processo Início do processo Início com ajustes feitos durante Durante pois continuamente recebe os feedbacks Inicialmente definidos e refinamentos conforme integração Início do processo Durante o processo Início do processo e depois são refinados em cada iteração Durante o processo feito com os sprints Início do processo e depois são ajustados por meio de feedbacks rápidos Durante o processo via stories e feedback constante Tipos de sistemas Sistemas críticos Sistemas de tempo real Sistemas embarcados Sistemas críticos Sistemas de tempo real Sistemas embarcados Sistemas críticos Sistemas de tempo real Sistemas embarcados Sistemas comerciais Sistemas comerciais e de mercado Sistemas de grande escala e comerciais Sistemas críticos Sistemas críticos e de alta Segurança Sistemas corporativos e de larga escala Sistemas comerciais Sistemas corporativos e de grande porte Sistemas comerciais Sistemas corporativos Sistemas comerciais Sistemas comerciais Exemplo de sistemas Software de controle de voo Airbus A380 Sistemas de controle de equipamentos médicos como um tomógrafo Grandes sistemas de gestão empresarial ERP da SAP O sistema operacional Windows da Microsoft Aplicativos de redes sociais como o Instagram EJB COM CORBA arquiteturas LEGOlike Sistemas de controle de trens Eurostar Qualquer sistema empresarial com requisitos de Segurança e auditoria como um sistema bancário O sistema de controle de tráfego aéreo da FAA Federal Aviation Administration Spotify Sistemas internos de gestão de estoque para empresas de varejo Plataformas de e commerce de grande porte como a Amazon Análise de risco Sim na fase inicial mas não de forma contínua Sim na fase inicial de planejamento com foco em controle e validação Sim na fase de planejamento com ênfase na dependência entre os módulos e de integração Sim implícita e contínua entre iterações Sim implícita e contínua entre iterações Sim na fase inicial de seleção de componentes e na integração Sim desde a especificação inicial até a verificação do código Sim ela é incorporada na arquitetura do sistema para mitigar riscos de segurança e vulnerabilidades Sim nas fases de concepção e elaboração Sim nas discussões diárias e revisões nos finais de cada sprint Sim na fase de planejamento e requisitos Sim a análise de riscos ocorre de forma iterativa e contínua ao longo do ciclo de vida do projeto Reutilização e Modularização Modularização pode ocorrer na etapa de design e sem reutilização explicita sendo uma das questões fora da metodologia Não contempla explicitamente Modularização sim e reutilização em componentes comuns entre os subsistemas Modularização a cada incremento pois subdivide o sistema e reutilização não é tão utilizada mas em casos de implementações futuras Modularização durante os protótipos e reutilização de entregas já aprovadas mas não é base para o funcionamento Modularização e a reutilização são as bases do processo o processo se baseia em reutilização para criar sistemas Não explicitamente mas a modularização pode ser usada na prova de correção matemática subdividindo o sistema e a reutilização não é utilizada Modularização e reutilizção na composição dos aspectos Modularização e reutilização são bases para a dinâmica do rup seja pela arquitetura interdependente ou da utilização de componentes reutilizáveis Não é utilizado no scrum talvez em situações excludentes mas não é base do sistema A metodologia adota uma abordagem iterativa e incremental que depende fortemente da modularidade e a reutilização é facilitada pela construção de protótipos e modelos rápidos Modularização na refatoração contínua e no design simples Reutilização usável já que vive de ciclos Uso de prototipação Não contempla Não contempla Não contempla Contempla nos ciclos para validar um sistema Permitido mas não é base do modelo protótipos podem ser usados para validar incrementos novos Não contempla Não contempla Não contempla Contempla na fase de concepção do RUP pode incluir a criação de um protótipo para que o cliente possa aprovar a ideia e viabilidade do projeto Não explicitamente mas isso não impede de prototipar através dos sprints backlogs Sim essencial ao método já nas primeiras fases até entregar produto Contempla implicitamente nas fases de entrega ao cliente Usuário no processo ocorre durante o levantamento de requisitos análise e implementação Participação limitada nos requisitos e testes de aceitação Participação limitada nos requisitos e testes de validação Sim contínua após os incrementos com os feedbacks Sim contínua após os incrementos com os feedbacks Participação quase nula com exceção do levantamento de requisitos Participação quase nula com exceção do levantamento de requisitos Participação quase nula com exceção do levantamento de requisitos Sim nas fases de requisitos e treinamentos Sim nas reuniões diárias assim como através da figura do product owner Sim muito ativa nas fases de planejamento até as entregas de protótipos Sim ativamente nos feedbacks contínuos na história do usuário e no ambiente de desenvolvimento Testes Contempla na fase de implementação Contempla os testes são incorporados em cada fase de desenvolvimento como requisitos do usuário projeto de alto nível e projeto de baixo nível tem uma fase de teste correspondente teste de aceitação teste de sistema etc Contempla a cada fase de desenvolvimento de forma paralela ao processo Contempla os testes logo antes da integração Contempla os testes logo antes da integração Contempla implicitamente em cada teste de componentes O teste é substituído ou complementado por verificação matemática e prova de correção Não contempla em fases formais mas deve ser verificado se os aspectos estão implementados de forma correta por todo o sistema Sim parte de cada iteração com foco em testes de unidade integração sistema e aceitação sendo que cada um é planejado e executado nas iterações apropriadas Sim contínuo durante cada sprint passando por uma validação das funcionalidades entregues Sim em prototipagem especificamente em protótipos rápidos Sim central ao processo em várias fases são elas unitários aceitação e integração contínua Alto Custo Sim principalmente nas fases finais de manutenção e correção de bugs Sim o custo está na mão de obra e no tempo gastos na criação e revisão de todos os artefatos de design Sim coordenação entre equipes paralelas e integração de módulos Custos menores inicialmente mas podem crescer com complexidade arquitetural em iterações posteriores Sem eventual controle na fase de refinamentos iterativos Além disso pode haver um custo adicional em gerenciamento de projeto pois cada iteração precisa ser planejada e executada de forma correta Alto seja comprando componentes ou investindo tempo e recursos para desenvolver componentes reutilizáveis internamente o custo inicial é elevado O alto custo é predominante nas fases de especificação e verificação As ferramentas e o tempo necessários para realizar as provas formais são significativamente mais caros do que as técnicas de desenvolvimento e teste tradicionais Pode possuir em caso de necessidade de refatorar o código além da curva de aprendizado para aprender a ferramenta utilizada O custo elevado ocorre principalmente nas fases de elaboração e construção A natureza iterativa e o grande volume de documentação e artefatos exigem um esforço significativo Se não for controlado pode ocorrer nas fases de planejamento de sprints e reuniões diárias O custo mais alto ocorre na contratação e alocação de pessoal O RAD exige uma equipe de desenvolvedores altamente qualificada e experiente que pode ser mais cara O custo elevado está nas práticas de pareamento e desenvolvimento O pareamento duplica o custo de mão de obra para cada linha de código Ciclo de vida Linear Linear Linear com implementações em paralelo Iterativo e incremental Iterativo e incremental Iterativo e incremental Linear Paralelo Iterativo e incremental Iterativo e incremental Iterativo e incremental Iterativo e incremental Pouco tempo para desenvolvimento Não recomendado Não recomendado Não recomendado Aplicável Aplicável Aplicável Não recomendado Não recomendado Não recomendado Recomendado Recomendado Recomendado Atividade Construa uma tabela similar a do slide 82 para cada modelo de processo abordado nessa aula considerando os seguintes critérios Pode inserir outros critérios que achar importante Exemplos de critérios 1 Definição de requisitos no início eou durante o processo 2 Tipos de sistemas críticos de uso específico geral etc 3 Análise de risco se contempla ou não 4 Reutilização e Modularização se contempla ou não 5 Uso de prototipação se contempla ou não 6 Usuário no processo no início eou durante o processo 7 Testes durante eou final do processo 8 Custo qual etapa do processo tem maior custo 9 Curto prazo se aplicado ou não 10 Ciclo de vida linear iterativo incremental etc 11 Exemplo de sistema