Visão Geral sobre Ciclo de Vida de Software, Processos e RUP

1/45

Visão Geral sobre Ciclo de Vida de Software, Processos e RUP

Alexandre Vasconcelos(amlv@cin.ufpe.br)

2/45

Ciclo de Vida e Processo de Desenvolvimento de

Software

3/45

O que é um modelo de ciclo de vida de processo de software? Uma representação abstrata e

simplificada do processo de desenvolvimento software, tipicamente mostrando as principais atividades e dados usados na produção e manutenção de software

4/45

Principais Modelos do Ciclo de Vida de Software Cascata Modelo de Desenvolvimento

Evolucionário Programação Exploratória Prototipagem descartável

Modelo de Transformação Formal Modelos Iterativos

Espiral Incremental

5/45

Modelo Cascata(ou clássico) Derivado de modelos existentes em

outras engenharias Sua estrutura é composta por várias

etapas que são executadas de forma sistemática e seqüencial

Na prática, existe uma interação entre as etapas e cada etapa pode levar a modificações nas etapas anteriores

6/45

Modelo CascataDefinição de Requisitos

Projeto do Sistema e do

Software

Implementação e Testes Unitários

Integração e Teste do Sistema

Operação e Manutenção

7/45

Modelo Cascata na PráticaDefinição de Requisitos

Projeto do Sistema e do

Software

Implementação e Testes Unitários

Integração e Teste do Sistema

Operação e Manutenção

8/45

Modelo de Desenvolvimento Evolucionário Programação Exploratória Prototipagem Descartável

Atividades Concorrentes

Especificação

Desenvolvimento

Validação

Esboço de Descrição

Versão Inicial

Versões Intermediárias

Versão Final

9/45

Programação Exploratória Idéia geral:

Desenvolvimento da primeira versão do sistema o mais rápido possível

Modificações sucessivas até que o sistema seja considerado adequado

Após o desenvolvimento de cada uma das versões do sistema ele é mostrado aos usuários para comentários

Adequado para o desenvolvimento de sistemas onde é difícil ou impossível se fazer uma especificação detalhada do sistema

Principal diferença para os outros modelos é a ausência da noção de programa correto

10/45

Programação Exploratória Tem sido mais usada no

desenvolvimento de sistemas especialistas - geralmente sistemas que tentam emular capacidades humanas

A maioria dos sistemas desenvolvidos com sucesso usando a programação exploratória foi implementada usando pequenos grupos de profissionais altamente qualificados e motivados

11/45

Prototipagem Descartável Como na programação exploratória, a primeira

fase prevê o desenvolvimento de um programa para o usuário experimentar

No entanto, o objetivo aqui é estabelecer os requisitos do sistema

O software deve ser reimplementado na fase seguinte

A construção de protótipos com os quais os usuários possam brincar é uma idéia bastante atrativa:

Para sistemas grandes e complicados Quando não existe um sistema anterior ou um

sistema manual que ajude a especificar os requisitos

12/45

Prototipagem Descartável Os objetivos do protótipo devem estar bem claros

antes do início da codificação. Possíveis objetivos: Entender os requisitos dos usuários Definir a interface com os usuários Demonstrar a viabilidade do sistemas para os

gerentes. Uma decisão importante a ser tomada é escolher o

que será e o que não será parte do protótipo Não é economicamente viável implementar todo

o sistema! Os objetivos do protótipo são o ponto de partida

13/45

Transformação Formal Idéia geral:

Uma especificação formal (definição matemática, não ambígua) do software é desenvolvida e posteriormente “transformada” em um programa através de regras que preservam a corretude da especificação

esp. 2esp. 1 implement.

14/45

Transformação Formal A grande motivação por trás da idéia de

refinamento formal é a possibilidade de gerar automaticamente programas que são corretos por construção O próprio processo de desenvolvimento deve

grantir que o programa faz exatamente o que foi especificado

Este modelo tem sido aplicado ao desenvolvimento de sistemas críticos, especialmente naqueles onde a segurança é um fator crítico (ex: sistema de controle de tráfego aéreo)

15/45

Modelo de Desenvolvimento Baseado em Reuso Baseado no reuso sistemático de componentes

existentes ou sistemas COTS (Commercial-off-the-shelf)

Etapas do processo Especificação dos requisitos Análise de componentes Modificação dos requisitos Projeto de sistema com reuso Desenvolvimento e integração Validação

Esta abordagem está se tornando mais importante, mas há ainda pouca experiência com ela

16/45

Modelo de Desenvolvimento Baseado em Reuso

Especificação de Requisitos

Análise de Componentes

Modificação de Requisitos

Projeto de Sistema com Reuso

Desenvolvimento e Integração

Validação do Sistema

17/45

Modelos Iterativos Requisitos de sistema SEMPRE evoluem

durante curso de um projeto. Assim a iteração do processo sempre faz parte do desenvolvimento de grandes sistemas

Iterações podem ser aplicadas a quaisquer dos modelos de ciclo de vida

Duas abordagens (relacionadas) Desenvolvimento espiral Desenvolvimento incremental

18/45

Desenvolvimento Espiral Acrescenta aspectos gerenciais ao processo de

desenvolvimento de software. análise de riscos em intervalos regulares do processo de

desenvolvimento de software planejamento controle tomada de decisão

O processo é representado como uma espiral em vez de uma seqüência de atividades

Cada volta na espiral representa uma fase no processo Não há fases fixas como especificação ou projeto - voltas

na espiral são escolhidas dependendo do que é requerido Riscos são avaliados explicitamente e resolvidos ao longo

do processo

19/45

Desenvolvimento Espiral

Determinação dos objetivos, alternativas e restrições

Análise de Riscos

  Análise das alternativas e identificação e/ou resolução de riscos

Desenvolvimento e validação da versão corrente do produto

Simulações,modelos e benchmarks

Planejamento

20/45

Desenvolvimento Incremental Em vez de entregar o sistema como um todo, o

desenvolvimento e a entrega são divididos em incrementos, com cada incremento entregando parte da funcionalidade requerida

Requisitos dos usuários são priorizados e os requisitos de mais alta prioridade são incluídos nas iterações iniciais

Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados". Embora os requisitos possam continuar a evoluir para incrementos posteriores

Em certos aspectos é similar à programação exploratória. No entanto, o escopo do sistema deve ser claramente entendido antes de se iniciar o desenvolvimento

21/45

Definiresboço dosrequisitos

Associarrequisitos aincrementos

Projetar aarquitetura dosistema

Desenvolverumincremento

Validar oincremento

Integrar oincremento

Validar osistema

SistemaFinal

Desenvolvimento Incremental

22/45

Processo Conjunto de atividades

bem definidas com responsáveis com artefatos de entrada e saída com dependências entre as mesmas

e ordem de execução com modelo de ciclo de vida

23/45

Processo é uma ação regular e contínua (ou

sucessão de ações) realizada de forma bem definida, levando a um resultado

é um conjunto parcialmente ordenado de atividades (ou passos) para se atingir um objetivo

define quem está fazendo o que, quando e como para atingir um certo objetivo

24/45

Processo versus Metodologia Alguns autores consideram que

processos incluem uma metodologia pessoas tecnologia (suporte de ferramentas)

Outros consideram que uma metodologia é a especialização de um processo com um conjunto de métodos

25/45

Método Descrição sistemática de como

deve-se realizar uma determinada atividade ou tarefa

A descrição é normalmente feita através de padrões e guias

Exemplos: Método para descoberta de atores e casos de uso no RUP.

26/45

Modelo de Processo é uma representação de um

processo, usualmente envolvendo atividades a serem realizadas agentes que realizam as atividades artefatos (produtos) gerados recursos necessários (consumidos)

27/45

Modelo de Processo Um modelo é usado para entendimento

e comunicação do processo, e como base para análise, execução, gerência e melhoria do processo

Idealmente a descrição deve ser formal e completa para permitir, por exemplo, automação

A descrição deve ser apresentada em diferentes níveis de abstração

28/45

Modelo de Processo O formalismo utilizado para representar o

processo é o ingrediente mais importante da modelagem

Não parece haver consenso sobre um formalismo ideal Terminologias distintas

Fase, workflow, domínio, disciplina, Atividade Mas há esforço de padronização (SPEM e

BPMN – OMG)

29/45

Exemplos de processos Processos tradicionais (pesados)

RUP, OPEN, Catalysis Processos ágeis (leves)

XP, Agile modeling, Crystal, pragmatic programming, Internet Speed, Scrum, ...

30/45

Exemplos de processos Consenso em torno de

Iteratividade Participação de usuários Flexibilidade de configuração para

projetos específicos Comunicação entre membros da

equipe

31/45

Exemplos de processos Divergências em torno de

Detalhamento de atividades a serem seguidas Critério de conclusão da execução das atividades

Arquitetura robusta (RUP) Arquitetura para o contexto da iteração atual (agile

modeling) Rigor na atribuição de tarefas a responsáveis

workers (RUP) alocação sob demanda e interesse (XP)

Artefatos (documentação) gerados Nível de Automação Nível de (im)pessoalidade

32/45

Polêmica Se a tendência é processos leves, afinal o

desenvolvimento de software é Arte+Sociologia+Psicologia+...

ou Lógica+Modelos+Engenharia+...???

E todo o esforço de consolidação da Engenharia de Software como uma ciência exata???

Compromisso Balancing agility and discipline

33/45

Visão Geral do RUP

34/45

O que é o RUP? O nome é uma abreviação de

Rational Unified Process mas na verdade é

Processo + Métodos + Linguagem (UML) e os autores argumentam que é

Framework para gerar processos

35/45

O que é o RUP? Conjunto de atividades

bem definidas com responsáveis com artefatos de entrada e saída com dependências entre as mesmas e ordem

de execução com modelo de ciclo de vida descrição sistemática de como devem ser

realizadas guias (de ferramentas ou não), templates utilizando diagramas de UML

36/45

Características Principais do RUP O desenvolvimento de sistemas

seguindo o RUP é Iterativo e incremental Guiado por casos de uso (use cases) Centrado na arquitetura do sistema

37/45

O RUP é iterativo e incremental O ciclo de vida de um sistema consiste

de quatro fases:

Concepção (define o escopo do projeto) Elaboração (detalha os requisitos e a

arquitetura) Construção (desenvolve o sistema) Transição (implanta o sistema)

tempo

concepção elaboração construção transição

38/45

O RUP é iterativo e incremental Cada fase é dividida em iterações:

Minor Milestones: Releases

Inception Elaboration Construction Transition

Transitioniteration

Preliminaryiteration

Architect.iteration

Architect.iteration

Devel..iteration

Devel..iteration

Devel..iteration

Transitioniteration

39/45

O RUP é iterativo e incremental Cada iteração

é planejada realiza uma seqüência de atividades

(de elicitação de requisitos, análise e projeto, implementação, etc.) distintas

geralmente resulta em uma versão executável do sistema

é avaliada segundo critérios de sucesso previamente definidos

40/45

O RUP é iterativo e incremental

41/45

O RUP é guiado por casos de uso Os casos de uso não servem apenas

para definir os requisitos do sistema Várias atividades do RUP são guiadas

pelos casos de uso: planejamento das iterações criação e validação do modelo de

projeto planejamento da integração do sistema definição dos casos de teste

42/45

O RUP é centrado na arquitetura do sistema Arquitetura

visão geral do sistema em termos dos seus subsistemas e como estes se relacionam

A arquitetura é prototipada, definida e validada nas primeiras iterações da fase de elaboração

O desenvolvimento consiste em complementar a arquitetura

A arquitetura serve para definir a organização da equipe de desenvolvimento e identificar oportunidades de reuso

43/45

Organização do RUP Fluxos de atividades Atividades

passos entradas e saídas guias (de ferramentas ou não),

templates Responsáveis (papel e perfil, não

pessoa) Artefatos

44/45

Exemplo de Fluxo: Planejamento e Gerenciamento

Gerente de projeto

Arquiteto

Contratante

Iniciar Projeto

Aprovar Projeto

Estudar Viabilidade

Atestar Conclusão do Projeto

Identificar Riscos

Desenvolver Plano de Projeto

Desenvolver Plano de Iteração

Executar Plano de Iteração

Avaliar Iteração

Finalizar Projeto

Reavaliar Riscos

Priorizar Casos de

Uso

45/45

Referências Ivar Jacobson, Grady Booch e

James Rumbaugh. The Unified Software Development Process. Capítulos 1 a 5.

Philippe Kruchten. The Rational Unified Process – an Introduction.