Engenharia de Software
Prof. Wilkerson de L. Andrade
Versão resumida e traduzida dos slides originais produzidos por Ian Sommerville, Software Engineering, 7th edition. Chapter 4.
Estes slides foram adaptados dos slides gentilmente cedidos pela professora Patrícia D. L. Machado (DSC/UFCG).
O Processo de Software
• Um conjunto estruturado de atividades necessárias ao desenvolvimento de um software: ▫ Especificação; ▫ Design; ▫ Validação; ▫ Evolução.
• Um modelo de processo de software é uma representação abstrata de um processo.
▫ Apresenta uma descrição de um processo sobre uma perspectiva específica.
Modelos de Processo de Software
Genéricos
• Modelo Cascata
▫ Fases separadas e distintas de especificação e
desenvolvimento.
• Desenvolvimento Evolucionário
▫ Especificação, desenvolvimento e validação são
intercaladas.
• Engenharia de Software Baseada em Componentes
▫ O sistema é montado a partir de componentes.
• Existem muitas variações destes modelos
▫ Desenvolvimento formal onde um processo do tipo
cascata é utilizado, mas a especificação é formal e é refinada através de vários passos até um projeto
Modelo Cascata
Definição de requisitos Projeto de sistema e software Integração e teste de sistema Implementação e teste de unidade Operação e manutençãoModelo Cascata
• A principal desvantagem é a dificuldade de
acomodar mudanças quando o processo está em curso.
• Uma fase precisa ser completada antes de
Modelo Cascata
• Partição inflexível do projeto em fases distintas, dificultando a acomodação de mudanças de
requisitos.
• Assim, este modelo é apropriado apenas
quando os requisitos são bem entendidos e mudanças serão limitadas durante o projeto.
• Poucos sistemas de negócio possuem requisitos estáveis.
• O modelo cascata é mais usado para projetos grandes onde um sistema é desenvolvido em diferentes locais.
Desenvolvimento Evolucionário
• Desenvolvimento Exploratório
▫ O objetivo é trabalhar junto com clientes no
desenvolvimento de um sistema a partir de um esboço inicial de especificação. Deve começar com requisitos bem-entendidos e ir adicionando novas características a medida que são propostas pelo cliente.
• Protótipo Descartável
▫ O objetivo é promover um melhor entendimento
dos requisitos de um sistema. Inicia com requisitos pouco entendidos a fim de identificar o que é
Desenvolvimento Evolucionário
Atividades Simultâneas
Validação Versão final
Desenvolvimento intermediáriasVersões
Especificação Versão inicial
Descrição do esboço
Desenvolvimento Evolucionário
• Falta de visibilidade do processo; • Sistemas usualmente possuem uma
estrutura pobre;
• Habilidades especiais (Ex. em linguagens de prototipagem) podem ser necessárias.
Problemas
• Sistema interativos de tamanho pequeno a médio;
• Para partes de sistemas grandes (Ex. A interface do usuário);
• Para sistemas com tempo de vida curto. Por quê?
Engenharia de Software Baseada em
Componentes
• Baseada no reuso sistemático onde sistemas são integrados a partir de componentes
existentes ou sistemas COTS
(Commercial-off-the-shelf).
• Etapas:
▫ Análise de Componentes;
▫ Modificação de Requisitos;
▫ Projeto do Sistema com Reuso;
▫ Desenvolvimento e Integração.
• Esta abordagem está sendo cada vez mais utilizada a medida que padrões tem sido
Desenvolvimento Orientado a Reuso
Especificação de requisitos Análise de componentes Desenvolvimento e integração Projeto de sistema com reuso Modificação de requisitos Validação de sistemaIteração de Processo
• Requisitos de um sistema SEMPRE evoluem
no curso de um projeto de tal forma que
iterações de processo onde etapas iniciais são re-trabalhadas são sempre
consideradas.
• Iteração pode ser aplicada a qualquer
modelo de processo genérico.
• Existem duas abordagens:
▫ Entrega Incremental;
Entrega Incremental
• Ao invés de desenvolver o sistema como uma única entrega, o desenvolvimento e entregas são quebrados em incrementos, onde cada um é relativo a entrega de uma parte requisitada de funcionalidade.
• Requisitos do usuário são priorizados e os com maior prioridade são incluídos nos primeiros
incrementos.
• Quando se inicia o desenvolvimento de um
incremento, os requisitos deste incremento são congelados. No entanto, requisitos para
incrementos posteriores podem continuar a evoluir.
Desenvolvimento Incremental
Validar incremento Desenvolver incremento de sistema Projetar arquitetura de sistema Integrar incremento Validar sistema Definir requisitos iniciais Atribuir requisitos aos incrementos Sistema incompleto Sistema finalVantagens do Desenvolvimento
Incremental
• Funcionalidades ficam disponíveis para o
cliente mais cedo.
• Incrementos iniciais podem ser considerados
como protótipos para facilitar a elicitação de requisitos de incrementos posteriores.
• Baixo risco de falha geral do projeto.
• Partes mais prioritárias do sistema tendem a
Desenvolvimento Espiral
• O processo é representado como um espiral
ao invés de uma seqüência de atividades com backtracking.
• Cada loop no espiral representa uma fase no
processo.
• Loops no espiral não estão associados a
fases pré-estabelecidas – são escolhidos de acordo com as necessidades do projeto.
• Riscos são avaliados explicitamente e
Modelo Espiral de um Processo de
Software
Risk analysis Risk anal ysis Risk anal ysis Riskanal ysis Proto-type 1 Prototype 2 Prototype 3 Oper a-tional pr otoype Concept of Oper ation
Simula tions , models , benchmar ks S/W requir ements Requir ement validation Design V&V Product design Detailed design Code Unit test Integ ration test Acceptance test
Service Develop , verify next-le vel pr oduct Evalua te alterna tives, identify , resolv e risks Deter mine objecti ves,
alterna tives and constr aints
Plan ne xt phase
Integ ration and test plan Development
plan Requir ements plan
Life-cycle plan REVIEW Definição de Objetivos e Identificação de Riscos Análise de Riscos Desenvolvimento e Validação Planejamento
Setores do Modelo Espiral
• Definição de Objetivos
▫ Objetivos específicos para a fase são identificados.
• Análise de Riscos
▫ Riscos são avaliados e atividades re-colocadas para reduzir riscos chave.
• Desenvolvimento e Validação
▫ Um modelo de desenvolvimento para o sistema é aplicado.
• Planejamento
▫ O projeto é revisado e a próxima etapa do espiral é planejada.
The Rational Unified Process
• Modelo de processo moderno derivado de
pesquisas com o uso de UML e processos associados.
• Normalmente descrito a partir de 3
perspectivas:
▫ Uma perspectiva dinâmica que mostra fases no
tempo;
▫ Uma perspectiva estática que mostra atividades
de processo;
▫ Uma perspectiva prática que sugere boas
Modelo de Fases do RUP
Iteração de fase
Concepção Elaboração Construção Transição
Business Case. Entidades externas e interações. Viabilidade e retorno para o negócio Domínio do Problema, Arquitetura, Planejamento do Projeto e Riscos Design, implementação e teste Implantação
Fases do RUP
• Concepção
▫ Estabelecer os modelos de negócio para o
sistema.
• Elaboração
▫ Desenvolver um entendimento do domínio do
problema e da arquitetura do sistema.
• Construção
▫ Projeto do Sistema, programação e testes.
• Transição
▫ Disponibilização do sistema em seu ambiente
Boas Práticas do RUP
• Desenvolvimento Iterativo;
• Gerenciamento de Requisitos;
• Uso de arquiteturas baseadas em
componentes;
• Modelos visuais do software;
• Verificação de qualidade de software;
Workflows Estáticos
Workflow Descrição
Modelagem de negócios
Os processos de negócios são modelados usando casos de uso de negócios.
Requisitos Os agentes que interagem com o sistema são identificados e os casos de uso são desenvolvidos para modelar os
requisitos do sistema. Análise e
projeto
Um modelo de projeto é criado e documentado usando modelos de arquitetura, modelos de componente, modelos de objeto e modelos de seqüência.
Implementação Os componentes de sistema são implementados e
estruturados em subsistemas de implementação. A geração automática de código com base nos modelos de projeto
Workflows Estáticos
Workflow Descrição
Teste O teste é um processo iterativo realizado em conjunto com a implementação. O teste de sistema segue o término da implementação.
Implantação Uma versão do produto é criada, distribuída aos usuários e instalada no local de trabalho.
Gerenciamento de configuração e mudanças
Este workflow de apoio gerencia as mudanças do sistema (Capítulo 29).
Gerenciamento de projetos
Este workflow de apoio gerencia o desenvolvimento do sistema (Capítulo 5).
Ambiente Este workflow está relacionado à disponibilização de ferramentas apropriadas de software para a equipe de desenvolvimento.
Engenharia de Software com o auxílio de
computador
• Computer-aided software engineering (CASE) é
um software de suporte a processos de desenvolvimento e evolução de software.
• Automação de Atividades
▫ Editores gráficos para o desenvolvimento de modelos de sistema;
▫ Dicionário de dados para gerenciar entidades de design;
▫ Geradores de interfaces gráficas;
▫ Depuradores para dar suporte a localização de faltas;
▫ Tradutores automáticos para gerar novas versões de um programa.
Tecnologia CASE
• Tecnologia CASE tem introduzido melhorias
significativas no processo de software. Porém, a ordem de magnitude destas melhorias é inferior ao que foi previsto.
▫ Engenharia de software requer criatividade – tarefa de difícil automação;
▫ Engenharia de software é uma atividade de
equipe e, para projetos grandes, uma parcela de tempo significativa é gasta com interações entre as equipes. Tecnologia CASE pode dar suporte a estas atividades, porém de forma limitada.
Classificação de CASE
• Classificação nos ajuda a entender os diferentes
tipos de ferramentas CASE e seu suporte a atividades de processo.
• Perspectiva Funcional
▫ Ferramentas são classificadas de acordo com uma
função específica (planejamento, edição, gerenciamento, etc.).
• Perspectiva de Processo
▫ Ferramentas são classificadas de acordo com atividades
de processo as quais dá suporte.
• Perspectiva de Integração
▫ Ferramentas são classificadas de acordo com sua
organização dentro de unidades de integração para dar suporte a uma ou mais atividades de processo.
Perspectiva Funcional
Tipo de ferramenta Exemplos
Ferramentas de planejamento Ferramentas PERT, ferramentas para estimativas, planilhas
Ferramentas de edição Editores de texto, editores de diagramas, processadores de texto
Ferramentas de gerenciamento de mudanças
Ferramentas de controle de requisitos, sistemas de controle de mudanças
Ferramentas de gerenciamento de configurações
Sistemas de gerenciamento de versões, ferramentas de construção de sistemas
Ferramentas de prototipação Linguagens de nível muito alto, geradores de interface com o usuário
Ferramentas de apoio a métodos
Editores de projeto, dicionários de dados, geradores de código
Perspectiva Funcional
Tipo de ferramenta Exemplos
Ferramentas de
processamento de linguagens
Compiladores, interpretadores Ferramentas de análise de
programas
Geradores de referências cruzadas, analisadores estáticos, analisadores dinâmicos
Ferramentas de teste Geradores de dados de teste, comparadores de arquivos
Ferramentas de depuração Sistemas de depuração interativos
Ferramentas de documentação Programas de formatação de páginas, editores de imagens
Ferramentas de reengenharia Sistemas de referência cruzada, sistemas de reestruturação de programas
Perspectiva de Processo
Especificação Projeto Implementação Verificação e validação Ferramentas de reengenharia Ferramentas de teste Ferramentas de depuração Ferramentas de análise de programas Ferramentas de processamento de linguagens
Ferramentas de apoio a métodos Ferramentas de prototipação Ferramentas de gerenciamento de configurações Ferramentas de gerenciamento de mudanças Ferramentas de documentação Ferramentas de edição Ferramentas de planejamento
Perspectiva de Integração
• Ferramentas
▫ Suporte a tarefas de processo individuais tais como checagem de consistência de design, edição de
texto, etc.
• Workbenches
▫ Suporte a uma fase do processo como especificação ou design. Usualmente formada por ferramentas
integradas.
• Ambientes
▫ Suporte ao processo inteiro ou partes substanciais do processo. Normalmente inclui vários workbenches integrados.
Ferramentas, Workbenches, Ambientes
Single-m ethod workbenches General-purpose workbenches Multi-m ethod workbenches Langua ge-specific workbenchesPro gram m ing Testing
Analy sis and design Integ rated en vironm ents Process-centr ed en vironm ents File
com par ators Com pilers Editors Environm ents Wor kbenches Tools CASE technolo g y Tecnologia CASE
Ferramentas Workbenches Ambientes
Editores Compiladores Comparadores de arquivos Ambientes integrados Ambientes centrados em processos Análise e
projeto Programação Teste
Workbenches de vários métodos Workbenches de único método Workbenches de propósito geral Workbenches de ling. específica
