Aula 12 - Introdução a Processos de Software

(1)

Qualidade de Software

Processo de Software e o RUP

Marcelo Marinho

(2)

O Processo de Software

• Um Conjunto estruturado de atividades, procedimentos, artefatos e ferramentas necessários para o desenvolvimento de um sistema de software.

Embora exista muitos processos de software diferentes, algumas atividades fundamentais são comuns a todos eles, como:

Especificação; Projeto;

Validação; Evolução;

Eng. de Software - Prof. Marcelo Marinho

(3)

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

(4)

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

(5)

Modelos de Processo de Software

• (Def:) 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

• Cada modelo de processo representa um

processo sob determinada perspectiva;

(6)

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)

(7)

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.

(8)

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)

(9)

Principais Modelos do Processo de

Software

• Cascata

• Modelo de Desenvolvimento Evolucionário

– Programação Exploratória – Prototipagem descartável

• Modelo de Transformação Formal • Modelos Iterativos

– Espiral

– Incremental

(10)

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

(11)

Modelo Cascata

Definiçã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

(12)

Modelo Cascata na Prática

Definiçã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

(13)

Problemas do Modelo em Cascata

• Particionamento inflexível do projeto em estágios distintos, dificulta a resposta aos requisitos de mudança do cliente;

• Documentos “completamente elaborados” são necessários para fazer as transições entre os estágios;

• Poucos sistemas de negócios têm requisitos estáveis;

• O modelo cascata é o mais usado em projetos de engenharia de sistemas de grande porte, onde um sistema é desenvolvido em várias localidades;

(14)

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

(15)

Modelo de Desenvolvimento

Evolucionário - 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

(16)

Modelo de Desenvolvimento

Evolucionário - 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

(17)

Modelo de Desenvolvimento

Evolucionário - 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

(18)

Modelo de Desenvolvimento

Evolucionário - 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

(19)

Problemas da Abordagem

Evolucionária

• O processo não é visível:

– Os gerentes precisam de produtos regulares para medir o progresso;

– Se os sistemas são desenvolvidos rapidamente, não é viável produzir documentos que reflitam cada versão do sistema;

• Os sistemas são freqüentemente mal

estruturados:

– A mudança continua tende a corromper a estrutura do software;

– A incorporação de mudanças torna-se cada vez mais difícil e onerosa;

(20)

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

(21)

Modelo de Desenvolvimento

Baseado em Reuso

Eng. de Software - Prof. Marcelo Marinho 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

(22)

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

(23)

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

(24)

Desenvolvimento Espiral

Eng. de Software - Prof. Marcelo Marinho 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

(25)

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

(26)

Desenvolvimento Incremental

Eng. de Software - Prof. Marcelo Marinho Definir esboço dos requisitos Associar requisitos a incrementos Projetar a arquitetura do sistema Desenvolver um incremento Validar o incremento Integrar o incremento Validar o sistema Sistema Final

(27)

Vantagens do Desenvolvimento

Incremental

• Incrementos podem ser entregues regularmente

ao cliente e, desse modo, a funcionalidade do

sistema é disponibilizada mais cedo;

• O incremento inicial age como um protótipo para

auxiliar a elicitar os requisitos para incrementos

posteriores do sistema

• Riscos menores de falhas gerais do projeto;

• Os serviços de sistemas de mais alta prioridade

tendem a receber mais testes;

(28)

Exemplos de processos

• Processos tradicionais (pesados)

– RUP, OPEN, Catalysis • Processos ágeis (leves)

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

(29)

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

(30)

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

(31)

(32)

Contexto

• Necessidade de software cada vez mais complexo, melhor e mais rápido; • Os métodos de desenvolvimento não evoluíram a contento

– É necessário um processo que integre as muitas facetas do desenvolvimento.

• Não é suficiente apenas a presença de desenvolvedores altamente treinados

(33)

Precisamos de um processo que

• Defina um guia que controle as atividades do time de

desenvolvimento;

• Direcione as tarefas para desenvolvedores específicos;

• Especifique que artefatos precisam ser desenvolvidos nas etapas do desenvolvimento;

• Ofereça critérios para monitorar as atividades e os produtos de um projeto

(34)

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)

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)

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)

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

(38)

O RUP é iterativo e incremental

Minor Milestones: Releases

Inception Elaboration Construction Transition

Transition iteration Preliminary iteration Architect. iteration Architect. iteration Devel.. iteration Devel.. iteration Devel.. iteration Transition iteration  Cada fase é dividida em iterações:

(39)

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)

O RUP é iterativo e incremental

(41)

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)

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)

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