eng.ª do software - 4. processos de software

ENGENHARIA DO SOFTWARE I

Manuel Menezes de Sequeira

DCTI, ISCTE-IUL

[email protected], D6.02

As apresentações desta série baseiam-se nas apresentações disponibilizadas por Ian Sommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel Menezes de

Sequeira.

mailto:[email protected]

http://www.comp.lancs.ac.uk/computing/resources/IanS/SE8/Presentations/index.html



Engenharia do Software I 2

Sumário

Processos de softwareModelos de processos de softwareIteração de processosActividades de processoRUP (Rational Unified Process)CASE (Computer-Aided Software

Engineering)

2009/2010


Processos de Software

2009/2010


Na aula anterior

Processo da engenharia de requisitosEstudos de viabilidadeEliciação e análise de requisitosValidação de requisitosGestão de requisitos

2009/2010


Processo de software Conjunto estruturado de actividades

necessárias para desenvolver sistema de softwareEspecificaçãoDesenhoValidaçãoEvolução

Modelo de processo de software é representação abstracta de processo, descrevendo-o sob um ponto de vista particular

2009/2010


Modelos genéricos de processo de softwareCascata Fases separadas e distintas de

especificação e desenvolvimento

Desenvolvimento evolutivo

Especificação, desenvolvimento e validação entrelaçadas

Engenharia do software baseada em componentes

O sistema é montado a partir de componentes existentes.

Há muitas variantes destes modelos. Por exemplo, o desenvolvimento formal, que usa um processo semelhante ao do modelo em cascata, mas em que a especificação, que é formal, é refinada ao longo de várias etapas até se atingir um desenho implementável.

2009/2010

7Engenharia do Software I

Modelo em cascataDefinição de

requisitos

Desenho do sistema e do software

Implementação e testes unitários

Integração e testes de sistema

Operação e manutenção

O principal inconveniente deste modelo é que dificulta lidar com mudanças depois do processo estar em andamento. Tem de se completar cada uma das fases antes de avançar para a fase seguinte.

Etapas

2009/2010


Problemas do modelo em cascata Segmentação inflexível do projecto em etapas

distintas dificulta resposta a modificações nos requisitos do cliente

Apropriado apenas quando requisitos são bem compreendidos e modificações se previrem bastante limitadas

Sobretudo grandes projectos de engenharia de sistemas com sistema desenvolvido em vários locais

Poucos negócios têm requisitos estáveis.

2009/2010


Desenvolvimento evolutivoDesenvolvimento exploratório

Objectivo é trabalhar com clientes e evoluir sistema final a partir de esboço de especificação inicial. Começa com requisitos bem compreendidos e adiciona funcionalidades à medida que cliente as propõe.

Prototipagem descartável

Objectivo é perceber requisitos do sistema. Começa com requisitos mal compreendidos e esclarece o que de facto é necessário.

2009/2010


Actividades concorrentes

Desenvolvimento evolutivo

Descrição geral

Especificação

Desenvolvimento

Validação

Versão inicial

Versões intermédias

Versão final

2009/2010


Desenvolvimento evolutivo Problemas

Fala de visibilidade do processoSistemas muitas vezes mal estruturadosPodem ser necessárias competências especiais

(e.g., em linguagens de prototipagem rápida)

AplicabilidadeSistemas interactivos de pequena ou média

dimensãoPartes de sistemas de grande dimensão (e.g.,

interface com utilizador)Sistemas com tempo de vida curto

2009/2010


Engenharia do software baseada em componentes

Baseia-se em reutilização sistemática

Sistemas integrados a partir de componentes existentes ou sistemas comerciais prontos a usar

Etapas do processoAnálise de componentesModificação de requisitosDesenho do sistema com reutilizaçãoDesenvolvimento e integração

COTS (Commercial-Off-The-Shelf)

Abordagem mais usada à medida que a normalização de componentes vai progredindo.

2009/2010


Desenvolvimento orientado pela reutilização

Especificação de requisitos

Análise de componentes

Modificação de requisitos

Desenho do sistema com reutilização

Desenvolvimento e integração

Validação do sistema

2009/2010


Iteração de processos

Requisitos do sistema evoluem sempre ao longo de um projecto…

…logo, para sistemas de grande dimensão, iterações do processo são sempre parte desse processo

Iterações são repetições das etapas iniciais do processo

2009/2010


Iteração de processos

Iteração aplica-se a qualquer modelo genérico de processo

Duas abordagens (relacionadas)Entrega incrementalDesenvolvimento em espiral

2009/2010


Entrega incremental Em vez de entrega única, desenvolvimento e

entrega divididos em incrementos, cada um entregando parte da funcionalidade

Requisitos do utilizador prioritizados; requisitos prioritários desenvolvidos primeiro

Logo que se inicia desenvolvimento de um incremento, seus requisitos são congelados; requisitos de incrementos posteriores continuam a evoluir

2009/2010


Desenvolvimento incremental

Definir visão geral dos requisitos

Atribuir requisitos a incrementos

Desenhar arquitectura do sistema

Desenvolver incremento do sistema

Validar incremento

Integrar incremento

Validar sistema

Sistema final

Sistema incompleto

2009/2010


Vantagens do desenvolvimento incremental Cada incremento entrega valor ao cliente;

funcionalidade do sistema disponível mais cedo

Incrementos iniciais como protótipos ajudam eliciação de requisitos para novos incrementos

Menor risco de falha global do projecto

Serviços prioritários do sistema tendem a ser os mais testados

2009/2010


XP – Extreme Programming Abordagem ao desenvolvimento

Baseada no desenvolvimento e entrega de pequenos incrementos de funcionalidade

Assenta em Melhorias constantes do códigoUtilizador envolvido na equipa de

desenvolvimentoProgramação em pares

Capítulo 17 do livro. Ver também http://www.extremeprogramming.org/.

2009/2010

http://www.extremeprogramming.org/


Desenvolvimento em espiral Processo como espiral e não sequência de

actividades com retrocesso

Espiras representam fases do processo

Sem fases fixas como especificação ou desenho – espiras escolhidas segundo necessário

Riscos avaliados e resolvidos explicitamente ao longo do processo

2009/2010


Modelo em espiral

2009/2010

CUSTO CUMULATIVO

PROGRESSO AO LONGO DOS PASSOS

ANÁLISE RISCO

PROTÓTIPO1

ANÁLISE DE RISCO

ANÁLISE DE RISCO

ANÁLISE DE RISCO

PROTÓTIPO2

PROTÓTIPO3

PROTÓTIPO OPERACIONAL

SIMULAÇÕES

DESENHO DE PORMENOR

CÓDIGO

MODELOSBENCHMARKS

TESTES UNITÁRIOS

TESTES DE INTEGRAÇÃO

TESTES DE ACEITAÇÃOIMPLEMEN-

TAÇÃO

VALIDAÇÃO E VERIFICAÇÃO DO DESENHO

DESENHO DO PRODUTO DE SOFTWARE

REQUISITOS DO SOFTWARE

VALIDAÇÃO DE REQUISITOS

PLANEAMENTO DE DESENVOLVIMENTO

PLANEAMENTO DE INTEGRAÇÃO E TESTES

PLAN- REQ.E CICLO

VIDA

CONCEITO DE OPERAÇÃO

REVISÃO

Partição de compromisso

Planeamento das próximas fases

Determinação de objectivos, alternativas e restrições

Desenvolvimento e verificação do produto do próximo nível

Avaliação de alternativas, identificação e resolução de riscos.


Sectores do modelo espiralEstabelecimento de objectivos

Identificar objectivos específicos para a fase

Avaliação e redução de riscos

Avaliar riscos e pôr em prática actividades para reduzir os riscos chave

Desenvolvimento e validação

Escolhe-se modelo de desenvolvimento para o sistema (pode ser qualquer dos modelos genéricos)

Planeamento Rever o projecto e planear a próxima fase (espira) da espiral.

2009/2010


Actividades do processo

Especificação de software Desenho e implementação de software Validação de software Evolução de software

2009/2010


Especificação do software Processo de estabelecer serviços

requeridos e restrições à operação e desenvolvimento do sistema

Processo de engenharia de requisitosEstudo de viabilidadeEliciação e análise de requisitosEspecificação de requisitosValidação de requisitos

2009/2010


Desenho e implementação do software Processo de converter especificação do sistema

em sistema executável

Desenho de software – Desenhar estrutura de software realizando especificação

Implementação – Traduzir estrutura de software em programa executável

Estas actividades estão intimamente relacionadas e podem ser entrelaçadas

2009/2010


Actividades do processo de desenho Desenho arquitectural Especificação abstracta Desenho de interfaces Desenho de componentes Desenho de estruturas de dados Desenho de algoritmos

2009/2010


Processo de desenho de software

2009/2010


Desenho arquitectural

Especificação abstracta

Desenho de

interfaces

Desenho de componentes

Desenho de algoritmos

Desenho de estruturas de dados

Arquitectura do sistema

Especificação do software

Especificação da interface

Especificação dos

componentes

Especificação das estruturas

de dados

Especificação dos algoritmos

Actividades de desenho

Produtosde desenho


Métodos estruturados Abordagens sistemáticas ao

desenvolvimento de desenhos de software

Desenho normalmente documentados como conjunto de modelos gráficosModelo de objectosModelo de sequênciaModelo de transição de estadosModelo estruturalModelo de fluxo de dados

2009/2010


Programação e depuração Tradução de desenho em programa e

remoção de erros do programa

Programação é actividade pessoal – não há processo genérico de programação

Programadores efectuam alguns testes para revelar falhas no programa e as remover no processo de depuração

2009/2010

No entanto, XP prescreve programação em pares e TDD.


Processo de depuração

2009/2010

Localizar erroDesenhar correcção

do erroCorrigir erro

Testar programa de

novo


Validação de software Verificação e validação (V & V) mostra que

sistema está conforme especificação e cumpre requisitos do cliente

Inclui processos de verificação e revisão, bem como testes de sistema

Testes de sistema incluem execução do sistema com casos de teste resultantes da especificação dos dados reais a processar

2009/2010


Processo de teste

2009/2010

Testes de componentes

Testes de sistema

Testes de aceitação


Etapas de testeTestes unitários ou de componentes

Componentes individuais testados de forma independente. Componentes podem ser funções, objectos ou grupos coerentes destas entidades.

Testes de sistema

Testes do sistema como um todo. Testes a propriedades emergentes é particularmente importante.


Testes com dados do cliente para verificar que o sistema satisfaz as necessidades do cliente.

2009/2010



Desenho de pormenor

Codificação e teste de módulos e unidades


Testes de integração de subsistemas

Testes de integração de sistema

Fases de teste (modelo em V)

2009/2010

Serviço

Especificação de sistema

Desenho de sistema

Plano de testes de integração

de subsistemas

Plano de testes de integração de sistemas

Plano de testes de aceitação


Evolução de software

Software inerentemente flexível e mutável

Requisitos mudam devido a alterações nas circunstâncias do negócio, logo software de suporte tem de evoluir e mudar também

Demarcação entre desenvolvimento e evolução (manutenção) torna-se menos clara à medida que há menos sistemas totalmente novos

2009/2010


Evolução de sistema

2009/2010

Definição de requisitos do

sistema

Proposta de modificações ao sistema

Modificação dos sistemas

Sistemas existentes

Novo sistema

Aferição dos sistemas existentes


Rational Unified Process

Modelo moderno de processo com origem no trabalho no UML e processo associado

Descrito normalmente segundo três perspectivasDinâmica – Mostra fases ao longo do tempoEstática – Mostra as actividades do processoPrática – Sugere boas práticas

2009/2010


Rational Unified Process

Produto/infra-estrutura que organizações de desenvolvimento de software podem personalizar

Combina os três modelos de processo de software genéricosEm cascataEvolutivoBaseado em componentes

2009/2010


Modelo de fases do RUP

2009/2010

Começo Elaboração Construção Transição

Iteração de fase


Fases do RUPComeço Estabelecimento do caso de negócio para o sistema.

Elaboração Desenvolvimento de compreensão acerca do domínio do problema e da arquitectura do sistema.

Construção Desenho do sistema, programação e testes.

Transição Implantação do sistema no seu ambiente de operação.

2009/2010


O RUP

Disciplinas

Fases

Começo Elaboração Construção Transição

Modelação do negócio

Requisitos

Análise e desenho

Implementação

Teste

Implantação

Gestão de mudanças e de configurações

Gestão de projectos

Ambiente

Inicial E1 E2 C1 C2 C3 T1 T2

Iterações

2009/2010


Boas práticas RUP

Desenvolver o software iterativamente Gerir os requisitos Usar arquitecturas baseadas em

componentes Modelar visualmente o software Verificar a qualidade do software Controlar modificações ao software

2009/2010


Fluxos de trabalho estáticosFluxo de trabalho

Descrição

Modelação do negócio

Modelam-se os processos do negócio usando casos de uso do negócio.

Requisitos Identificam-se actores que interagem com o sistema e desenvolvem-se casos de uso para modelar requisitos do sistema.

Análise e desenho

Cria-se um modelo de desenho que se documenta usando modelos arquitecturais, modelos de componentes, modelos de objectos e modelos de sequência.

Implementação Implementam-se os componentes do sistema que são estruturados em subsistemas de implementação. A geração automática de código a partir dos modelos de desenho ajuda a acelerar este processo.

2009/2010


Fluxos de trabalho estáticosFluxo de trabalho

Descrição

Teste Processo iterativo que decorre em conjunto com a implementação. Os testes do sistema têm lugar após completa a implementação.

Implantação Cria-se uma versão de lançamento que se distribui pelos utilizadores e se instala nas suas estações de trabalho.

Gestão de mudanças e de configurações

Este fluxo de trabalho de suporte gere as modificações ao sistema.

Gestão de projectos

Este fluxo de trabalho de suporte gere o desenvolvimento do sistema.

Ambiente Este fluxo de trabalho lida com a disponibilização à equipa de desenvolvimento de software de ferramentas de software apropriadas.

2009/2010


CASE (Computer-Aided Software Engineering) Software de suporte aos processos de

desenvolvimento e evolução de software

Automação de actividadesEditores gráficos para desenvolvimento de modelos do

sistemaDicionários de dados para gestão das entidades de

desenhoConstrutores de interfaces gráficas com o utilizadorDepuradores para suportar a descoberta de falhas nos

programasTradutores automatizados para gerar novas versões de

um programa

2009/2010


Tecnologia CASE Levou a melhorias significativas no processo

de software, mas não tão grandes se havia previsto

Engenharia do software exige pensamento criativo, que não se automatiza facilmente

Engenharia do software é uma actividade de equipa passando-se muito tempo em interacções dentro da equipa quando o projecto é de grande dimensão. A tecnologia CASE não suporta estas interacções.

2009/2010


Classificação CASEPerspectiva funcional

Ferramentas classificadas de acordo com a sua função específica

Perspectiva de processo

Ferramentas classificadas de acordo com as actividades de processo que suportam

Perspectiva de integração

Ferramentas classificadas de acordo com a sua organização em unidades integradas

2009/2010


Classificação funcionalTipo Exemplos

Planeamento Ferramentas PERT, de estimação e folhas de cálculo

Edição Editores de texto e de diagramas, processadores de texto

Gestão de mudanças

Ferramentas para rastreamento de requisitos, sistemas de controlo de modificações

Gestão de configurações

Sistemas de gestão de versões, ferramentas de construção de sistemas

Prototipagem Linguagens de muito alto nível, geradores de interfaces com o utilizador

Suporte de métodos

Editores de desenho, dicionários de dados, geradores de código

2009/2010


Classificação funcionalTipo Exemplos

Processamento de linguagens

Compiladores, interpretadores

Análise de programas

Geradores de referências cruzadas, analisadores estáticos, analisadores dinâmicos

Teste Geradores de dados de teste, comparadores de ficheiros

Depuração Sistemas interactivos de depuração

Documentação Programas de composição de páginas, editores de imagens

Reengenharia Sistemas de referências cruzadas, sistemas de reestruturação de programas

2009/2010


Classificação por actividade

Especificação Desenho Implementação Verificação e validação

Reengenharia ●

Teste ● ●

Depuração ● ●

Análise de programas ● ●

Processamento de linguagens ● ●

Suporte de métodos ● ●

Prototipagem ● ●

Gestão de configurações ● ●

Gestão de mudanças ● ● ● ●

Documentação ● ● ● ●

Edição ● ● ● ●

Planeamento ● ● ● ●

2009/2010


Classificação por integração

Ferramentas Suportam tarefas individuais de processos, tais como a verificação da consistência do desenho ou a edição de texto.

Bancadas de trabalho

Suportam fases de processo, tais como a especificação ou o desenho. Normalmente incluem um conjunto de ferramentas integradas.

Ambientes Suportam todo um processo de software ou uma sua parte substancial. Normalmente incluem várias bancadas de trabalho integradas.

2009/2010


A reter Processos de software são actividades envolvidas na

produção e evolução de sistemas de software

Modelos de processos de software são representações abstractas desses processos

Actividades gerais são especificação, desenho e implementação, validação e evolução

Modelos genéricos de processos descrevem organização dos processos de software. Exemplos: em cascata, desenvolvimento evolutivo e engenharia do software baseada em componentes

2009/2010


A reter Modelos de processos iterativos descrevem

processo de software como ciclo de actividades

Engenharia de requisitos é processo de desenvolvimento de especificações de software

Processos de desenho e implementação transformam especificação em programa executável

Validação envolve verificar que sistema satisfaz especificação e necessidades dos utilizadores

2009/2010


A reter

Evolução respeita a modificações no sistema depois de em produção

RUP é modelo genérico de processo que separa actividades de fases

Tecnologia CASE suporta actividades do processo de software

2009/2010

A ler

Ian Sommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006

Capítulo 4

2009/2010 55Engenharia do Software I

eng.ª do software - 4. processos de software

Education