1

ANÁLISE E PROJETO NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

PROCESSO: CONCEITO

MODELOS DE PROCESSO

PROCESSO UNIFICADO

HISTÓRIA

CARACTERÍSTICAS

AS QUATRO FASES

OS WORKFLOWS

MODELAGEM NO RUP

2

I . PROCESSO: CONCEITO

Quando elaboramos um produto ou sistema é importante percorrer uma série de passos previsíveis – um roteiro que ajuda a criar um resultado de alta qualidade no tempo que foi previsto.

O roteiro que seguimos é chamado processo de sof tware.

3

É importante termos um processo porque ele f ornece

estabilidade, controle e organização

No entanto, uma abordagem moderna de engenharia de sof tware precisa ser ágil, contendo atividades, controles e documentação adequados à equipe de projeto e ao produto que deve ser produzido.

4

I I . MODELOS DE PROCESSO CASCATA

Análise de requisitos de software: esta etapa tem como objetivo o entendimento da natureza do sof tware a ser desenvolvido. O engenheiro de sof tware deve obter detalhes sobre as informações, as f unções, o comportamento, o desempenho e a interface. Os requisitos devem ser documentados e revistos com o cliente.

Projeto: nesta etapa os requisitos são traduzidos para uma representação do sof tware que pode ser avaliada quanto à qualidade, antes que a codificação seja iniciada. Da mesma forma que na etapa anterior, o projeto deve ser documentado.

Codificação: nesta etapa é elaborado o código Teste: uma vez gerado o código, o teste é iniciado.

Análise Projeto

Codificação Teste

5

Características do modelo:

Linear: o desenvolvimento do sof tware procede linearmente do início ao fi m do processo.

Rígido: Os resultados de cada f ase são congelados antes de se passar para a próxima f ase.

Críticas:

Os projetos raramente seguem o fluxo seqüencial que o modelo propõe.

Tem dificuldade de acomodar a incerteza natural que existe no começo dos projetos.

O cliente deve ter paciência já que uma versão do trabalho só está disponível num ponto tardio do cronograma.

6

I NCREMENTAL

Podemos observar ao desenvolver determinados sistemas que os seus requisitos mudam f reqüentemente ao longo do desenvolvimento. Nesse caso é importante que tenhamos um modelo de processo que não seja rígido, como o modelo cascata

No modelo incremental a abordagem do modelo cascata, que é

seqüencial é combinada com uma abordagem iterativa. É enfatizado um desenvolvimento em fases através da realização de mini-projetos (chamados de incrementos).

Veremos a seguir exemplo de um processo incremental.

7

I I I . PROCESSO UNIFICADO

Processo Unificado – um conjunto de atividades executadas para transformar os requisitos do cliente em um sistema de sof tware.

Também é uma estrutura (f ramework) genérica de

processo que pode ser customizada. De acordo com as características do projeto podem ser adicionadas ou removidas atividades.

RUP (Rational Unifi ed Process) – é uma versão

especializada do Processo Unifi cado. É também um produto que é vendido e está integrado a um conjunto de ferramentas de desenvolvimento de sof tware que podem ser adquiridas separadamente.

8

HISTÓRIA

Final da década de 60 I var J acobson e sua equipe na Ericsson modelaram um sistema de telecomunicações muito grande utilizando vários dos diagramas que hoje f azem parte da UML.

1987 J acobson deixou a Ericsson criando uma

companhia chamada Objectory AB. Lá f oi desenvolvido o Objectory, um processo e um produto, assim como o RUP.

9

Pouco tempo depois a Rational comprou a ObjectoryAB.

Booch e Rumbaugh já estavam na Rational e os três juntos f oram os líderes do projeto do Processo Objectory da Rational em paralelo com o projeto da UML.

A Rational continuou a adquirir ou se fundir com várias empresas que fabricavam ferramentas de desenvolvimento de sof tware.

1998 A Rational mudou o nome de seu processo para

RUP.

Em fi ns de 2003 f oi anunciada a incorporação da Rational pela I BM

10

CARACTERÍSTICAS

É um processo iterativo As atividades enfatizam a criação de modelos É orientado por casos de uso O desenvolvimento é centrado em arquitetura É um processo confi gurável

11

AS QUATRO FASES

A vida de um sistema pode ser representada por uma

série de ciclos. E no Processo Unifi cado cada ciclo contém quatro f ases:

Concepção

Elaboração

Construção

Transição

12

CONCEPÇÃO

Atividades:

Defi nir o escopo do sistema I dentificar os requisitos funcionais e não-funcionais.

I niciar a modelagem de casos de uso. Esboçar uma arquitetura candidata I dentificar os riscos críticos (ameaçam a viabilidade do

sistema) e especificar como a equipe lidará com eles I niciar a análise econômica do projeto, de f orma a

determinar a viabilidade do projeto

13

ELABORAÇÃO

Atividades:

Especifi car os casos de uso que não f oram tratados na f ase de Concepção

Criar uma base arquitetônica sólida I dentificar os riscos signifi cativos, já que os críticos

f oram tratados na f ase anterior. Os riscos signifi cativos podem causar atrasos signifi cativos no cronograma e gastos maiores que os previstos no orçamento

Especifi car a qualidade desejada para o sistema considerando os requisitos não funcionais.

Atualizar a análise econômica e o plano de projeto com informações mais detalhadas obtidas durante esta f ase.

14

CONSTRUÇÃO

Atividades:Concluir o modelo de casos de usoConcluir os demais modelos.CodificaçãoModificar a arquitetura se for necessárioMonitorar os riscos críticos e os significativos e tomar as medidas necessárias para atenuá-los.

Nesta fase é construída uma versão operacional do sistema que possa ser entregue a clientes que realizarão testes.

15

TRANSI ÇÃO

Atividades:

Preparar a divulgação do sistema Divulgar o sistema Realizar ajustes quando for necessário para acertar

dif erenças em ambientes dos clientes Coletar informações sobre os defeitos e f azer as

correções

Nesta f ase é entregue uma versão operacional do sistema aos clientes que irão testar o sistema

16

I TERAÇÕES

Cada fase é dividida em uma ou mais iterações. I teração é um mini-projeto que resulta em uma versão

liberada interna ou externamente

Concepção

Elaboração

Construção

Transição

Iteração 1Iteração 2

Iteração x

Iteração x+1

Iteração y

Iteração y+1

Iteração z

. . . . . . . . .

17

OS WORKFLOWS

Cada iteração passa pelos workflows em maior ou menor grau.

Modelagem de negócio Requisitos Análise e Projeto I mplementação Teste I mplantação Gerência de confi guração Gerência de projeto Ambiente

18

19

Cada workflow tem os seguintes elementos:

Artef atos Trabalhadores Atividades

A seguir são descritos os workflows relacionados mais diretamente ao assunto deste curso: requisitos, análise e projeto e implementação

20

REQUISITOS

Objetivo: obter os requisitos dos vários interessados no sistema e negociar estes requisitos até que esteja claro que os clientes e a equipe de desenvolvedores concordam sobre as características do sistema que está sendo defi nido.

21

ANÁLISE e PROJ ETO

Objetivo: traduzir os requisitos numa especificação que descreva como implementar o sistema. O envolvimento do cliente é necessário quando precisa ocorrer uma negociação sobre os requisitos mas neste workflow o f oco está no trabalho dos desenvolvedores que precisam a partir dos requisitos construir o sistema.

22

Análise e Projeto:

Na análise o f oco maior está em assegurar que os requisitos f uncionais estão sendo atendidos.

J á o projeto é um refi namento da análise. Devem ser

considerados os requisitos não-funcionais.

23

Nível de detalhamento:

Há situações em que o projeto deve ser detalhado a ponto de se poder realizar uma tradução do projeto para o código.

Há outras situações em que não é necessário esse detalhamento.

O grau de detalhamento dependerá da experiência do desenvolvedor, da complexidade do projeto e dos riscos envolvidos.

24

Artef atos da Análise:

Modelo de Análise: é um pacote de pacotes de

análise.

Pacote de Análise: contém classes de análise e realizações de casos de uso e pode conter outros pacotes de análise.

25

Classes de Análise: É uma classe especifi cada no nível de detalhe próprio a este workflow. Contém por exemplo, atributos mas não operações.

Há três tipos de classes de análise:

Classes de interface Classes de entidade Classes de controle

26

Objeto de interface – um objeto com o qual um ator interage. Pode ser uma janela, página HTML, menu, etc. Um ator não-humano pode interagir com um objeto de interface como API s. Objeto entidade – geralmente é um objeto persistente, mas também pode ser um objeto que contenha dados transientes, resultado de uma pesquisa. Costuma vir do modelo de domínio. Objeto de controle – incorpora a lógica da aplicação. Atuam como coordenadores.

27

Realização de Análise: é uma colaboração que

descreve como o(s) ator(es) e o sistema realizarão um caso de uso em termos de classes de análise.

Colaboração: uma coleção de classes e outros

elementos que trabalham juntos para fornecer algum comportamento.

28

A equipe de desenvolvimento gera as realizações de análise ef etuando uma análise que envolve examinar cada sentença de um caso de uso, determinando os objetos de interface, entidade e controle necessários para se chegar a um determinado comportamento.

29

Artef atos de Projeto:

Modelo de projeto: é um detalhamento do modelo de análise

Modelo de instalação: especifi ca a distribuição

geográfica do hardware.

30

Uma abordagem a ser adotada é a de que o modelo de análise evolua para o modelo de projeto e não seja preservado. Caso haja necessidade é possível, no entanto, guardar o modelo de análise. A vantagem de se ter um modelo em um nível de abstração mais alto pode, no entanto, não compensar o trabalho de se manter a consistência entre os dois modelos.

31

IMPLEMENTAÇÃO

Objetivo: construir uma versão operacional do sistema. São realizados testes de unidade dos componentes criados. O modelo gerado neste workflow deve conter todos os componentes e subsistemas necessários para realizar a f uncionalidade especifi cada pelos casos de uso contidos no modelo de casos de uso e os requisitos complementares.

32

Componentes – O componente é f ísico e está

instalado em alguma parte do hardware. A classe é conceitual e é fi sicamente realizada por um componente.

Há componentes que são uma parte executável do sistema e outros que correspondem a partes não executáveis, como um tabela, um arquivo ou um documento.

Diagrama de Componentes – mostra uma coleção de componentes relacionados.

Neste diagrama é enf atizada a dependência entre os vários componentes.

33

O ESFORÇO DE CADA WORKFLOW AO LONGO DAS FASES

Dependendo da f ase em que o incremento é elaborado um workflow pode ser mais ou menos explorado.

Concepção Elaboração Construção

Transição

Iteração 1Iteração 2

Iteração x

Iteração x+1

Iteração y

Iteração y+1

Iteração z

. . . . . . . . .

34

A Fase de Concepção Requisitos – o maior esforço desta f ase ocorre neste workflow.

Análise e Projeto Análise – é construída uma versão inicial do modelo de análise baseada no conjunto inicial de casos de uso Projeto – são construídas as versões iniciais dos modelos de projeto e instalação I mplementação – só no caso de algum protótipo ser construído é que as atividades de implementação são realizadas.

Concepção

Elaboração

Construção

Transição

Iteração 1Iteração 2

Iteração x

Iteração x+1

Iteração y

Iteração y+1

Iteração z

. . . . . . . . .

35

A Fase de Elaboração Requisitos – busca-se capturar a maior parte dos requisitos funcionais Análise e Projeto Análise – a maior parte do trabalho de análise ocorre nesta f ase de elaboração. A descrição dos casos de uso é melhorada, o que aumenta o entendimento que os desenvolvedores têm sobre requisitos funcionais. Projeto – como a Análise, o Projeto também é muito importante nesta f ase. São construídos os modelos de projeto e instalação I mplementação – o objetivo é construir uma versão do sistema com as características chave do sistema

Concepção

Elaboração

Construção

Transição

Iteração 1Iteração 2

Iteração x

Iteração x+1

Iteração y

Iteração y+1

Iteração z

. . . . . . . . .

36

A Fase de Construção Requisitos – são descritos requisitos funcionais que possam ainda surgir. Análise e Projeto Análise – a partir do levantamento de novos casos de uso são acrescentados elementos ao modelo de análise. Projeto – a partir do levantamento de novos casos de uso são acrescentados elementos ao modelo de projeto. I mplementação – a maior parte do trabalho desta f ase encontra-se neste workflow. O objetivo é construir uma versão executável do sistema

Concepção

Elaboração

Construção

Transição

Iteração 1Iteração 2

Iteração x

Iteração x+1

Iteração y

Iteração y+1

Iteração z

. . . . . . . . .

37

A Fase de Transição O objetivo principal desta f ase é entregar uma versão operacional do sistema aos clientes. Pode, no entanto, ser observado algum problema, que deverá ser corrigido. E assim atividades dos workflows de Requisitos, Análise e Projeto e I mplementação podem ser realizadas.

Concepção

Elaboração

Construção

Transição

Iteração 1Iteração 2

Iteração x

Iteração x+1

Iteração y

Iteração y+1

Iteração z

. . . . . . . . .

38

MODELAGEM NO RUP No RUP são elaborados modelos com a perspectiva

conceitual no workflow de requisitos No RUP há um único workflow para análise e projeto. A

idéia é que seja construído um modelo de projeto não havendo a necessidade de se guardar um modelo intermediário entre o gerado no workflow de requisitos e o modelo de projeto. Mas se f or o caso pode ser guardado o modelo de análise que dá origem ao modelo de projeto.

A perspectiva de implementação é realizada no workflow de análise e projeto e é completada no workflow de implementação.

39

XP

-Planning Process / Planning Game-Short Releases-Stand Up Meetings-Pair Programming-Refactoring-Test Driven Development-Code Standard-Collective Code-Mataphor-Simple Design-Continuous Integration-Dedicated Consumer-Sustenaible Pace

40

Exercício: Listar as iterações, enquadradas conforme a fase e detalhando os

Artefatos, Trabalhadores e Atividades de cada workflow