Anda di halaman 1dari 85

Federao das Indstrias do Estado de Minas Gerais - FIEMG

Processo de
Desenvolvimento de
Software com
UML/RUP I

Belo Horizonte
2010

Presidente da FIEMG
Olavo Machado Jnior

Gestor do SENAI
Petrnio Machado Zica

Diretor Regional do SENAI e


Superintendente de Conhecimento e Tecnologia
Lcio Jos de Figueiredo Sampaio

Gerente de Educao e Tecnologia


Edmar Fernando de Alcntara

Elaborao
Lucas Lemos Costa

Unidade Operacional
Centro Tecnolgico de Eletroeletrnica Csar Rodrigues - CETEL

Sumrio

APRESENTAO ....................................................................................................... 8
1 Problemas do desenvolvimento de software .......................................................... 10
1.1
2

Anlise e Projeto .......................................................................................... 11

Falhas no desenvolvimento de software ............................................................ 12


2.1 Sintomas .......................................................................................................... 12
2.2 Causas............................................................................................................. 13

3. Modelos de ciclo de Vida...................................................................................... 15


3.1 Fase de definio ............................................................................................ 15
3.2 Fases de desenvolvimento .............................................................................. 16
3.2.1Design ........................................................................................................ 17
3.2.2 Implementao .......................................................................................... 18
3.2.3 Verificao e validao ............................................................................. 19
3.3 Fase de Operao ........................................................................................... 19
3.4 Fase de retirada ............................................................................................... 20
4 Classificao do ciclo de Vida ................................................................................ 22
4.1 Modelo constri conserta (catico) .................................................................. 22
4.2 Modelo Cascata ............................................................................................... 22
4.3 Modelo Iterativo .............................................................................................. 23
4.4 Cascata ou Iterativo? ....................................................................................... 25
5 Processo Unificado ................................................................................................ 27
5.1 Fases, Iteraes e Disciplinas ......................................................................... 28
5.1.1 Fases ........................................................................................................ 28
5.1.2 Iteraes ................................................................................................... 29
5.1.3 Disciplinas ................................................................................................. 29
5.1.4 Relacionamento fases e disciplinas .......................................................... 29
6 Disciplinas .............................................................................................................. 31

6.1 Modelagem de Negcio (Business Modeling).................................................. 31


6.2 Requisitos ........................................................................................................ 31
6.3 Anlise e Desenho (Design) ............................................................................ 31
6.4 Implementao ................................................................................................ 31
6.5 Teste ................................................................................................................ 31
6.6 Gesto de configurao e alterao ................................................................ 32
6.7 Gesto de Projetos .......................................................................................... 32
6.8 Ambiente (Environment) .................................................................................. 32
7 Artefatos ................................................................................................................. 33
8. Processo Burocrticos vs geis ....................................................................... 34
9. Papis do Processo Unificado............................................................................... 35
10 Prticas do PU ..................................................................................................... 38
10.1 Alto risco ........................................................................................................ 38
10.2 Envolver usuarios .......................................................................................... 38
10.3 Arquitetura ..................................................................................................... 39
10.4 Verificar qualidade ......................................................................................... 39
10.5Caso de Uso ................................................................................................... 39
11 RUP Rational Unified Process........................................................................... 40
11.1 RUP - Conceitos ............................................................................................ 40
11.2 RUP Melhores Prticas............................................................................... 42
11.2.1 - Desenvolver Iterativamente ...................................................................... 42
11.2.2 Gerenciar Requerimentos ........................................................................... 43
11.3 Utilizar Arquiteturas Baseadas em Componentes ......................................... 43
11.4 Modelar Visualmente ..................................................................................... 43
11.5 Verificao Continua de Qualidade ............................................................... 44
11.6 Controle de Mudanas ................................................................................... 44
11.7 Fases de Desenvolvimento ............................................................................ 44
11.7.1 Concepo .............................................................................................. 44

11.7.2 Elaborao .............................................................................................. 46


11.7.3 Construo ............................................................................................. 48
11.7.4 Transio ................................................................................................ 49
11.8 Iteraes ........................................................................................................ 50
11.8.1Benefcios de uma abordagem iterativa ................................................... 50
11.9 Estrutura Esttica do Processo ...................................................................... 51
11.1 Trabalhador ................................................................................................ 51
11.2 Atividade .................................................................................................... 51
11.3 Artefato....................................................................................................... 52
11.4 Fluxos de trabalho ...................................................................................... 53
12 Requisitos............................................................................................................. 54
12.1 Classificao dos Requisitos ......................................................................... 54
12.2 Os Requisitos Funcionais .............................................................................. 54
12.2.1Requisitos de Negcio (RqN) ou Business Why .................................... 55
12.2.2 Requisitos de Processo (RqP) ou Process What .................................. 55
12.2.3Requisitos Tcnicos (RqT) ou System How ........................................... 56
12.3 Os Requisitos No Funcionais....................................................................... 56
12.3.1 Requisitos do produto ............................................................................. 56
12.3.2 Requisitos organizacionais ...................................................................... 56
12.3.3 Requisitos externos ................................................................................. 57
12.4 Qualidades sistmicas ................................................................................... 57
12.4.1 Qualidade sistmica Desempenho ....................................................... 57
12.4.2 Qualidade sistmica Escalabilidade ..................................................... 58
12.4.3 Qualidade sistmica Usabilidade ......................................................... 59
12.4.4 Qualidade sistmica Segurana ........................................................... 60
12.5 Dos Requisitos para o Cdigo ....................................................................... 60
13 Problema ............................................................................................................. 62
14 Capturando os Requisitos do Sistema ................................................................. 63

14.1 Identificando Fontes de Requisitos ................................................................ 63


14.2 Identificando os Stakeholders ........................................................................ 63
14.3 Preparando para Entrevistar os Stakeholders ............................................... 64
14.4 Questes Detalhadas dos Requisitos Funcionais .......................................... 64
14.5 Questes para Esclarecimento de Requisitos ............................................... 65
14.5.1 Questes para Esclarecimento: Remoo .............................................. 65
14.5.2 Questes para Esclarecimento: Distoro .............................................. 66
14.5.3 Questes para Esclarecimento: Generalizao ...................................... 66
15 Documento Viso ................................................................................................. 68
15.1 Introduo ...................................................................................................... 68
15.2 Oportunidade de negcio............................................................................... 69
15.3 soluo proposta ........................................................................................... 70
15.4 Riscos ............................................................................................................ 70
15.5 Restries ...................................................................................................... 71
16. SRS ..................................................................................................................... 72
16.1Introdo ......................................................................................................... 72
16.2 Restries e suposies ................................................................................ 73
16.3 Riscos ............................................................................................................ 73
16.4 Requisitos funcionais ..................................................................................... 73
16.4.1 atores ...................................................................................................... 74
16.4.2 Casos de uso .......................................................................................... 74
16.5 Requisitos nao funcionais .............................................................................. 75
16.6 Glossrio........................................................................................................ 76
16.7 Resumo ......................................................................................................... 76
17 Disciplina de Anlise de Projeto ........................................................................... 77
17.1 Definir e evoluir uma arquitetura robusta para o sistema............................... 77
17.2 Adaptar o desenho para o ambiente de implementao............................... 77
17.3 Finalizar o desenho das interfaces de usurio ............................................... 78

18 Visualizando Conceitos com o Modelo de Domnio ............................................. 79


18.1 Adicionando Atributos ao Modelo de Dominio ............................................... 79
18.1.1 Identificando atributos ............................................................................. 80
18.2 Concluses a respeito do Modelo de Domnio .............................................. 80
19. Anlise de Robustez ........................................................................................... 81
19.1 Realizando a Anlise de Robustez ................................................................ 81
19.2 Anlise de robustez e o Modelo de Domnio ................................................. 82
20 Metodologia de Desenvolvimento de Software .................................................... 83
20.1 Processo de Software .................................................................................... 83
REFERNCIAS BIBLIOGRFICAS .......................................................................... 85

APRESENTAO

Muda a forma de trabalhar, agir, sentir, pensar na chamada sociedade do


conhecimento.
Peter Drucker

O ingresso na sociedade da informao exige mudanas profundas em todos os


perfis profissionais, especialmente naqueles diretamente envolvidos na produo,
coleta, disseminao e uso da informao.

O SENAI, maior rede privada de educao profissional do pas, sabe disso, e


,consciente do seu papel formativo , educa o trabalhador sob a gide do conceito da
competncia: formar o profissional com responsabilidade no processo
produtivo, com iniciativa na resoluo de problemas, com conhecimentos
tcnicos aprofundados, flexibilidade e criatividade, empreendedorismo e
conscincia da necessidade de educao continuada.

Vivemos numa sociedade da informao. O conhecimento, na sua rea tecnolgica,


amplia-se e se multiplica a cada dia. Uma constante atualizao se faz necessria.
Para o SENAI, cuidar do seu acervo bibliogrfico, da sua infovia, da conexo de
suas escolas rede mundial de informaes internet- to importante quanto
zelar pela produo de material didtico.

Isto porque, nos embates dirios, instrutores e alunos, nas diversas oficinas e
laboratrios do SENAI, fazem com que as informaes, contidas nos materiais
didticos, tomem sentido e se concretizem em mltiplos conhecimentos.

O SENAI deseja, por meio dos diversos materiais didticos, aguar a sua
curiosidade, responder s suas demandas de informaes e construir links entre os
diversos conhecimentos, to importantes para sua formao continuada !

Gerncia de Educao e Tecnologia

1 Problemas do desenvolvimento de software


Neste captulo vamos discutir alguns dos princpios relacionados Engenharia de
software. Sabemos que muitos projetos de software, falham em vrios aspectos:
prazos, custos, tempo, qualidade e etc. Neste cenrio, vamos tentar enquadrar um
processo amplamente utilizado no mundo, o Processo Unificado, para tentar nos
orientar a criar softwares, com mais qualidade e dentro de custos, o que no uma
questo simples.

Nosso objetivo principal com este captulo nos situarmos no contexto de um


processo de desenvolvimento de software, a fim de que possamos entender melhor
a importncia das atividades de levantamento, anlise e desenho, bem como
possamos as demais atividades envolvidas em um processo de desenvolvimento.
De fato, as atividades de anlise tm um papel fundamental em um processo de
software, mas elas no existem por si s: o objetivo final da anlise no a prpria
anlise, mas sim, o desenvolvimento do software como um todo, afetando todas as
outras disciplinas. Os tpicos que sero abordados so:

Modelos de ciclo de vida de um processo de Engenharia de software: cascata


e espiral;

Introduo ao Processo Unificado.

Apresentao dos conceitos de fase, interaes e disciplinas e como essas


esto relacionadas.

Discusso sobre os principais papis envolvidos em um processo de


desenvolvimento.

O que so artefatos e como eles so produzidos.

Os principais problemas no processo de desenvolvimento de software so os


seguintes:

10

O projeto nunca termina no prazo;

O cliente muda de idia antes da concluso do sistema.

A rea comercial vende algo que no possvel implementar.

O problema maior e envolve vrias pessoas.

O Cliente no sabe como o processo da empresa dele.

1.1 Anlise e Projeto


Uma anlise tem como objetivo esclarecer os requisitos e seus problemas, a anlise
possibilita identificar qual a melhor forma de inicar um projeto. Uma anlise est
ligada diretamente com a melhoria na qualidade de um projeto, e para se ter um bom
projeto deve ser feito a analise de requisitos, que seria uma investigacao desses
requisitos.

Um projeto vem logo aps uma boa anlise, em um projeto necessrio que os
requisitos da anlise sejam atendidos. Uma boa forma de entender oque anlise e
oque projeto pode ser explicado na seguinte frase: faa a coisa certa (anlise) e
faa certa a coisa (projeto).

Construir softwares demanda muitas habilidades, alem da anlise de requisitos que


deve ser feita. Questes como usabilidade, interface com usurios, desempenho
entre outros devem ser muito bem estudados para garantir o sucesso de um
sistema.

11

2 Falhas no desenvolvimento de software


2.1 Sintomas
Os projetos de desenvolvimento de software podem apresentar diversas falhas,
visveis atravs de sintomas comuns:

As necessidades dos usurios no so atendidas corretamente

Existncia de mdulos que no funcionam juntos

Dificuldade em se adaptar a mudanas de requisitos

Dificuldades de manuteno e extenso do software

Descoberta de srias falhas de projeto

Baixa qualidade

Desempenho inaceitvel

Impossibilidade de identificar quem (membros da equipe) realizou alteraes


no software, quando, onde e por qu

Processo no confivel de gerao e liberao de verses

A figura a seguir ilustra os sintomas e problemas envolvidos ao se conceber um


projeto. Observe que a compreenso tida por cada um dos envolvidos diferente
devidos aos problemas de comunicao, ausncia de especificaes entre
outros.

O cliente fez a seguinte afirmao:


Eu quero um balano para o meu filho brincar que tenha trs tbuas e duas
cordas para ele balanar na rvore. Mas existe variao de interpretao no
processo de desenvolvimento de software.

12

Figura 1 Problemas de comunicao no desenvolvimento de software

2.2 Causas
Tratar os sintomas diretamente, entretanto, no soluciona o problema, pois razes
mais profundas podem existir, principalmente na especificao dos requisitos,
desenho e implementao. As causas principais para estes sintomas so as
seguintes:

Avaliao subjetiva sobre o projeto.

Comunicao imprecisa e ambgua.

Arquiteturas frgeis.

Complexidade subestimada.

Inconsistncias no detectadas nos requisitos, desenho e implementao.

13

Testes insuficientes.

Crescimento descontrolado.

Inaptido da equipe.

Automao insuficiente.

Devido a esse pontos, fundamental estruturarmos um processo de software


adequado, alinhado s melhores prticas, de modo a minimizar os riscos de que um
projeto apresente alguns dos sintomas acima descritos.

14

3. Modelos de ciclo de Vida


O ciclo de vida de um software descreve as fases pelas quais o software passa
desde a sua concepo at ficar sem uso algum. O conceito de ciclo de vida de um
software

muitas

vezes

confundido

com

de

modelo

de

processo.

Existem vrias propostas e denominaes para as fases do ciclo de vida de um


software. Nossa proposta identifica 4 fases que so delimitadas por eventos tpicos
em diversos ciclos de vida. Cada fase inclui um conjunto de atividades ou disciplinas
que devem ser realizadas pelas partes envolvidas. Essas fases so:

Definio

Desenvolvimento

Operao

Retirada

3.1 Fase de definio


A fase de definio do software ocorre em conjunto com outras atividades como a
modelagem de processos de negcios e anlise de sistemas. Nesta atividade,
diversos profissionais buscam o conhecimento da situao atual e a identificao de
problemas para que possam elaborar propostas de soluo de sistemas
computacionais que resolvam tais problemas. Dentre as propostas apresentadas,
deve-se fazer um estudo de viabilidade, incluindo anlise custo-benefcio, para se
decidir qual soluo ser a escolhida.

O resultado desta atividade deve incluir a deciso da aquisio ou desenvolvimento

15

do

sistema,

indicando

informaes

sobre

hardware,

software,

pessoal,

procedimentos, informao e documentao.


Caso seja decidido pelo desenvolvimento do sistema, no escopo da engenharia de
software, necessrio elaborar o documento de proposta de desenvolvimento de
software. Esse documento pode ser a base de um contrato de desenvolvimento.

Profissionais de engenharia de software atuam nesta atividade com o objetivo de


identificar os requisitos de software e modelos de domnio que sero utilizados na
fase de desenvolvimento. Os requisitos so tambm fundamentais para que o
engenheiro possa elaborar um plano de desenvolvimento de software, indicando em
detalhes os recursos necessrios (humanos e materiais), bem como as estimativas
de prazos e custos (cronograma e oramento).

No existe um consenso sobre o que caracteriza o final da fase de definio. Isto


varia de acordo com o modelo de processo adotado. Em algumas propostas, a fase
de definio considerada concluda com a apresentao da proposta de
desenvolvimento apenas. Outros modelos de processo, considera que o software
apenas est completamente definido com a especificao de requisitos e com a
elaborao do plano de desenvolvimento de software.

De acordo com o modelo de processo adotado, pode-se iniciar atividades da fase de


desenvolvimento mesmo que a fase de definio no esteja completamente
concluda.

3.2 Fases de desenvolvimento


A fase de desenvolvimento ou de produo do software inclui todas as atividades
que tem por objetivo a construo do produto. Ela inclui principalmente o design, a
implementao e a verificao e validao do software.

16

3.2.1Design
A atividade de design compreende todo o esforo de concepo e modelagem que
tm por objetivo descrever como o software ser implementado. O design inclui:

Design conceitual

Design da interface de usurio

Design da arquitetura do software

Design dos algoritmos e estruturas de dados

O design conceitual envolve a elaborao das idias e conceitos bsicos que


determinam os elementos fundamentais do software em questo. Por exemplo, um
software de correio eletrnico tradicional inclui os conceitos: mensagem, caixa de
entrada, caixa de sada, etc. A mensagem, por sua vez, inclui os conceitos de para,
cc, assunto, corpo, etc. Embora seja um design adotado pela maioria dos softwares,
novos modelos conceituais podem vir a ser adotados. O conceito de conversao do
Gmail um exemplo.

O design da interface de usurio exerce influncia na interface de usurio e na


arquitetura do software. O design da interface de usurio envolve a elaborao da
maneira como o usurio pode interagir para realizar suas tarefas, a escolha dos
objetos de interfaces (botes, menus, caixas de texto, etc.), o layout de janelas e
telas, etc. A interface deve garantir a boa usabilidade do software e um
fundamental fator de sucesso do software.

O design de arquitetura de software deve elaborar uma viso macroscpica do


software em termos de componentes que interagem entre si. O conceito de
componente em arquitetura varia de acordo com a viso arquitetnica adotada. So

17

exemplos de vises arquitetnicas, a viso conceitual, viso de mdulos, viso de


cdigo e viso de execuo.

Na viso conceitual, os componentes de software so derivados do design


conceitual. Estes componentes so abstraes que devem definir outros elementos
menos abstratos. Exemplos so arquiteturas cliente-servidor e arquitetura em
camadas. Na viso de cdigo, deve-se determinar como as classes e/ou funes
esto organizadas e interagindo entre si. Estas classes implementam os
componentes abstratos ou conceituais.

Na viso de mdulos, deve-se determinar quais so os mdulos que sero utilizados


na implementao e como eles organizam as classes e/ou funes.

Na viso de execuo, a arquitetura deve descrever os diferentes processos que so


ativados durante a execuo do software e como eles interagem entre si. Enquanto
as anteriores oferecem uma viso esttica, esta uma viso dinmica do software.

O design de algoritmos e estrutura de dados, tambm conhecido como design


detalhado, visa determinar, de maneira independente da linguagem de programao
adotada, as solues algortmicas e as estruturas de dados associados. Deve-se
decidir, por exemplo, como as informaes podem ser ordenadas (algoritmo de
bolha ou quicksort) e em qual tipo de estrutura de dados (array, lista encadeada)
elas vo ser armazenados.

3.2.2 Implementao
A implementao envolve as atividades de codificao, compilao, integrao e
testes. A codificao visa traduzir o design num programa, utilizando linguagens e
ferramentas adequadas. A codificao deve refletir a estrutura e o comportamento

18

descrito no design. Os componentes arquiteturais devem ser codificados de forma


independente e depois integrados. Os testes podem ser iniciados durante a fase de
implementao. A depurao de erros ocorre durante a programao utilizando
algumas tcnicas e ferramentas. fundamental um controle e gerenciamento de
verses para que se tenha um controle correto de tudo o que est sendo codificado.

3.2.3 Verificao e validao


Verificao e validao destinam-se a mostrar que o sistema est de acordo com a
especificao e que ele atende s expectativas de clientes e usurios. A validao
visa assegurar se o programa est fazendo aquilo que foi definido na sua
especificao (fazendo a coisa certa). A verificao visa verificar se o programa est
correto, isto , no possui erros de execuo. Existem diferentes formas de
verificao e validao. Inspeo analtica e reviso de modelos, documentos e
cdigo fonte so formas que podem ser usadas antes mesmo que o programa seja
completamente codificado. Os testes de correo, desempenho, confiabilidade,
robustez, usabilidade, dentre outros, visam avaliar diversos fatores de qualidade a
partir da execuo do software. Diferentes tcnicas de testes podem ser aplicadas
para cada um destes fatores.

3.3 Fase de Operao


A fase de operao envolve diferentes tipos de atividades:

Distribuio e entrega

Instalao e configurao

Utilizao

Manuteno

19

A distribuio e entrega pode ser feita diretamente pelo desenvolvedor (em caso de
software personalizado), ou em um pacote a ser vendido em prateleiras de lojas ou
para ser baixado pela Internet (em caso de software genricos).

O processo de instalao e configurao, normalmente, pode ser feito com a ajuda


de software de instalao disponibilizados pelos fabricantes dos ambientes
operacionais.

A atividade de utilizao o objeto do desenvolvimento do software. A qualidade da


utilizao a usabilidade do software.

A manuteno normalmente ocorre de duas formas: corretiva e evolutiva. A


manuteno corretiva visa a resoluo de problemas referentes a qualidade do
software (falhas, baixo desempenho, baixa usabilidade, falta de confiabilidade, etc.).
A manuteno evolutiva ou adaptativa visa a produo de novas verses do
software de forma a atender a novos requisitos dos clientes, ou adaptar-se s novas
tecnologias que surgem (hardware, plataformas operacionais, linguagens, etc).
Mudanas no domnio de aplicao implicam em novos requisitos e incorporao de
novas funcionalidades. Surgimento de novas tecnologias de software e hardware e
mudanas para uma plataforma mais avanada tambm requerem evoluo.

3.4 Fase de retirada


A fase retirada um grande desafio para os tempos atuais. Diversos softwares que
esto em funcionamento em empresas possuem excelentes nveis de confiabilidade
e de correo. No entanto, eles precisam evoluir para novas plataformas
operacionais ou para a incorporao de novos requisitos. A retirada desses software
legados em uma empresa sempre uma deciso difcil: como abrir mo daquilo que

20

confivel e ao qual os funcionrios esto acostumados, aps anos de treinamento


e utilizao?

Processos de reengenharia podem ser aplicados para viabilizar a transio ou


migrao de um software legado para um novo software de forma a proporcionar
uma retirada mais suave.

21

4 Classificao do ciclo de Vida


4.1 Modelo constri conserta (catico)
O produto construdo sem qualquer especificao ou projeto. O produto
retrabalhado quantas vezes forem necessrias para satisfazer o cliente. Este modelo
pode funcionar razoavelmente para micro projetos (<400 pessoas-hora). No entanto
para projetos maiores ele inadequado.

4.2 Modelo Cascata


Neste modelo os principais subprocessos so executados em estrita seqncia,
sendo os pontos de controle bem definidos e demarcveis. Sob o ponto de vista da
Gesto de projetos.

um modelo de fcil administrao aparentando ser confivel e aplicvel a qualquer


tipo de projeto. Entretanto, se interpretado de forma rgida, esse modelo se torna
inflexvel e burocrtico. Todos os subprocessos tm que ser dominados por
completo, pois no so permitidos erros.

22

Figura 2 Modelo Cascata

No modelo cascata os requisitos no podem sofrer muitas alteraes, haja vista que
alteraes causam grande impacto. Para o cliente, esse modelo pouco visvel, pois
o produto s entregue quando est totalmente completo. Dispositivos no
removveis que guardam grandes quantidades de informao e podem ser
acessadas rapidamente.

4.3 Modelo Iterativo


Em um processo Iterativo, o desenvolvimento organizado em uma srie de mini
projetos de tamanho definido e de curta durao chamados iteraes. O resultado
de cada iterao um sistema testado, integrado e executvel. Cada iterao
envolve suas prprias atividades de levantamento de requisitos, anlise, projeto
implementao e teste.

23

Figura 3 Modelo Iterativo e incremental

O ciclo de vida de um projeto baseado no crescimento e refinamento do sistema


atravs de vrias interaes, com a realimentao feedback por parte do cliente e
adaptao. O sistema cresce incrementalmente com a evoluo do tempo, por isto
esta abordagem tambm conhecida como iterativa ou incremental.

Mas o modelo iterativo no realmente efetivo se no existir uma gesto sofisticada.


As atividades de manuteno so usadas para identificar problemas, seus registros
fornecem dados para definir requisitos para a prxima interao. necessrio cuidar
dos requisitos e dos riscos bem de perto.

Um modelo de ciclo de vida semelhante ao iterativo o modelo em cascata, aonde


os subprocessos so executados em ciclos. O modelo iterativo apresenta algumas
caractersticas que o diferenciam do modelo em espiral, j que nele as disciplinas

24

so executadas em paralelo no em cascata. Essa distino de modelos em cascata


e interativo, entretanto sutil e alguns autores no fazem distino.

4.4 Cascata ou Iterativo?


Aparentemente o modelo em cascata mais seguro e confivel, pois nele voc tem
o controle completo sobre os requisitos, antes de comear a desenvolver. Certo?
Mas por que os resultados mostram que no bem assim? Existem vrias razes:
Suposies erradas:

Requisitos esto congelados: Essa uma falsa suposio por que os usurios
mudam, o problema muda, a tecnologia muda, o mercado muda e por que ns no
conseguimos capturar todos os requisitos com um nvel suficiente de detalhes e
preciso.

O desenho correto do sistema pode ser feito antes de implementar: Isto falso por
que a definio de correto envolve preciso, eficincia, confiabilidade, etc. E isto s
pode ser garantido com mtodos formais(ex. Modelos matemticos) ou atravs da
codificao. Como mtodos formais so raramente aplicados, a soluo provar
atravs de cdigo, o que nem sempre traz a confirmao do correto.

O Contexto do desenvolvimento de software diferente de outras Engenharias.


Ns falhamos em incorporar alguns fatores humanos. Ns falhamos na tentativa de
usar uma abordagem que funciona em certas circunstncias.

A escolha aps esses contras do modelo cascata, recai sobre o iterativo. Mas ele
tambm tem suas limitaes.

25

muito fcil dizer que se usa um processo XYZ interativo, mas que na verdade
aplicado com se fosse cascata. O processo em cascata mais intuitivo. Boa parte
dos times tem como gerente de projeto um analista de sistema, sem experincia em
Gesto de projetos. O modelo iterativo exigente nos aspectos de gesto.

Existe uma presso nas fbricas de software, para utilizarem o modelo em cascata.
Em geral, as fbricas de software recebem uma especificao 100% pronta e j
partem para a codificao. Uma maneira de suavizar esse problema negociar
previamente a reviso dos requisitos e trabalhar com entregas parciais.

26

5 Processo Unificado
O processo unificado (Unified Process UP) foi criado pelos trs amigos: Ivar
Jacobson, Grady Booch, e James Rumbaugh, em 1999 [JACOBSON, WINDLE] .
Neste curso voc ver uma verso simplificada do Unified Process, enfatizada
principalmente na especificao dos requisitos, anlise e desenho.

O processo no desenvolvimento de software tem como principal objetivo descrever,


construir, implantar e possibilitar a manuteno de software. O processo unificado
surgiu com foco no processo de desenvolvimento de software visando elaborar
sistemas orientados a objetos.

O processo unificado ( PU ) adiciona suas melhores prticas para torna o processo


de software mais eficaz. O Processo Unificado vem sendo aplicado em projetos de
diversos tamanhos e mesmo para descrever sistemas existentes, que no
receberam ateno especial quanto aos requisitos ou mesmo por que evoluem muito
rapidamente. Suas principais caractersticas so:

Iterativo;

Baseado em casos de Uso;

Adaptvel;

Possui controle sobre requisitos, riscos e alteraes;

Continuamente verifica a qualidade;

Existem diferentes adaptaes para o Processo Unificado. Entre elas, podemos citar
o Rational Unified Process, verso comercial, de propriedade da IBM e o Enterprise
Unified Process, criado por um conjunto de consultores. O prprio Processo

27

Unificado tem uma disciplina ( ambiente ) onde uma das atividades justamente
adaptar o processo s necessidades do projeto.

O processo unificado requer trs caractersticas para que ele se torne efetivo.
Primeiro voc sempre deve conhecer o que voc acabou de fazer. Segundo voc
sempre sabe o que fazer a seguir. Terceiro voc tem um arcabouo no qual voc ir
incorporar o que voc aprendeu medida que so realizadas as interaes. Por
exemplo, se voc acabou de atualizar o modelo de casos de uso, voc precisar
rever os modelos da anlise para determinar se alguma alterao necessria.

5.1 Fases, Iteraes e Disciplinas


O processo Unificado define dois conceitos fundamentais para o entendimento do
ciclo de vida de um projeto: fases e disciplinas.

5.1.1 Fases
O Processo Unificado organiza as iteraes em quatro grandes fases:

Concepo: viso aproximada, business case, estimativa de escopo,


estimativas vagas.

Elaborao: Viso refinada, implementao iterativa da arquitetura central,


eliminao dos maiores riscos, identificao da maior parte dos requisitos e
escopo, estimativas mais realistas.

Construo: Implementao Iterativa os elementos de menor risco e/ou mais


simples, preparao para a implementao.

Transio: Testes betas, implantao.

28

5.1.2 Iteraes
Fases so compostas por uma ou mais iteraes. Durante cada iterao, cada uma
das disciplinas poder ser abordada de forma diferente, com maior ou menor
ateno. No processo de iterao o desenvolvimento organizado em uma serie de
miniprojetos, de durao fixa (30 dias), o produto de cada iterao testado,
integrado e executado. Cada iterao inclui suas prprias atividades de anlise de
requisitos, projeto, implementao e teste.
Os benefcios do desenvolvimento iterativo dentro pro Processo Unificado so:
Progresso visvel desde o inicio.
Envolvimento do usurio e adaptaes fazendo com que o sistema atenda as
necessidades dos interessados no projeto.
Menor

complexidade

na

administrao,

pois

equipe

no

fica

sobrecarregada.
O aprendizado em uma iterao pode ser usada para melhorar um outro
processo de iterao.

5.1.3 Disciplinas
As atividades de trabalho do Processo Unificado so descritas atravs de disciplinas.
As disciplinas, anteriormente conhecidas como workflows no Processo Unificado,
so formadas por um conjunto de atividades em uma mesma rea de assunto e seus
respectivos artefatos.

5.1.4 Relacionamento fases e disciplinas


A figura a seguir usada para ilustrar a relao de fases e disciplinas no Processo
Unificado. Note que em cada fase, determinadas disciplinas tm maior nfase. Por
exemplo, o esforo para levantamento de requisitos ocorre nas primeiras fases:

29

Figura 4 Fases do Processo Unificado

30

6 Disciplinas
A seguir descreveremos as disciplinas definidas no Processo Unificado.

6.1 Modelagem de Negcio (Business Modeling)


Quando se desenvolve uma nica aplicao, esta disciplina envolve a criao do
Modelo de Objetos de Domnio. Quando relacionada a uma anlise mais ampla do
negcio ou sua reengenharia, tambm inclui a modelagem de processos de toda a
empresa.

6.2 Requisitos
Levantamento e Anlise dos requisitos, atravs da escrita dos casos de uso e
identificao dos requisitos no-funcionais.

6.3 Anlise e Desenho (Design)


Todos os aspectos do desenho, incluindo a arquitetura , objetos , bases de dados,
comunicao de rede, entre outros.

6.4 Implementao
No processo unificado, significa programao e construo do sistema, no
implantao.

6.5 Teste
Esta disciplina consome artefatos produzidos em outras e tem como objetivo verificar
e validar se o sistema est correto, segundo os requisitos, e com qualidade.
Implantao (Deployment): Refere-se s atividades de instalao e configurao
do sistema e capacitao dos usurios.

31

6.6 Gesto de configurao e alterao


Essa disciplina cuida da estruturao dos artefatos, gerenciamento verses e
dependncias entre eles, propostas de alteraes e seus estados (abertas,
canceladas, concludas, etc).

6.7 Gesto de Projetos


Tem como objetivo garantir o gerenciamento efetivo do projeto, seus recursos e
ciclo de vida.

6.8 Ambiente (Environment)


Refere-se escolha de ferramentas e adaptao do processo, no caso o prprio
Processo Unificado, para atender o projeto.

32

7 Artefatos
Artefatos so produtos de cada disciplina dentro de um processo de software. No
Processo Unificado, um artefato significa um produto do trabalho: diagramas UML,
cdigo fonte, grficos, esquema de banco de dados, diagramas, documentos
texto,etc.

Artefatos so iniciados em algumas fases e refinados nas fases posteriores. Para um


projeto concludo, o artefato que melhor reflete o que foi desenvolvido o cdigofonte.

Cada iterao gera um artefato ou um conjunto deles. Lembre-se que artefato no


ainda o produto final.

33

8. Processo Burocrticos vs geis


No PU temos dois tipos de processos: o processo burocrtico (pesado) e o
processo gil.
Um processo burocrtico possui uma dessas caractersticas:

Possui muitos artefatos, criando a impresso de burocracia.

Aparenta rigidez e excesso de controle.

elaborado com planejamento detalhado em longo prazo;

especulativo, ao invs de reativo, isto , tenta predizer;

Geralmente tem um ciclo de vida em cascata ou seqencial: primeiro so


definidos todos os requisitos; depois do feitos a anlise e o projeto de forma
detalhada, por fim feita a implementao.

Certamente, os autores do Processo Unificado no o conceberam para ser


burocrtico e especulativo. Entretanto, dado o seu grande nmero de artefatos e
atividades, compreensivo que sejamos levados a esta impresso.

J um processo gil implica em um processo adaptativo e leve, ligeiro nas respostas


s necessidades de alterao. Esse processo busca planejar e prever atividades e
alocaes de recursos com mais detalhes ao longo de um intervalo de tempo. Um
processo gil tende a ter respostas rpidas as necessidades de mudanas.

34

9. Papis do Processo Unificado


No Processo Unificado, os papis no projeto de software so definidos em termos de
trabalhadores (workers). Voc pode imaginar os papis como sendo chapus que as
pessoas podem usar durante o projeto ou como um papel em uma pea teatral,
onde vrios atores podem encen-lo.

Disciplina
Modelagem
negcio

Aspecto Geral

Aspecto Especfico

de Analista de processo de Projetista de Negcios


negocio descobre todos (analista)
os

casos

de

uso

de negcio.

Analista
Descobre

Anlise e Desenho

um

do conjunto de casos de uso

negcio.

Requisitos

Detalha

de

sistemas Especificador
todos

de

os Requisitos (analista)

requisitos e casos de uso.

Detalha um conjunto.

Arquitetura de software

Projetista (analista)

Decide

quais

as Detalha

anlise

tecnologias sero usadas projeto para um conjunto

Implementao

no projeto.

de casos de uso.

Integrador

Desenvolvedor

Possui

Teste

plano

de Implementador

construo

que

como

classes

as

ou

mostra Codifica um conjunto de


se classes ou conjunto de

integram entre si.

operaes.

Gerente de Teste

Projetista de teste

Garante que os testes Implementa

os

esto completos e so automatizados


conduzidos corretamente.

testes
definidos

para a iterao.

35

Analista de Teste

Testador

Define o que ser testado.

Executa

Projetista de Teste

especfico.

um

teste

Decide quais testes sero


manuais

cria

automao.

Implantao

Gerente de implantao

Escritor

Tcnico

Prev a implantao para desenvolvedor


todas

Gesto de Projeto

as

de

unidades Cursos Artista Grfico.

envolvidas

(pessoas, Cria

material

detalhado

computadores,

sistemas, para garantir o sucesso da

etc).

implantao.

Gerente de Projeto

Gerente de Projeto

Cria o business case e um Planeja,


plano

geral.

Toma

rastreia

as gerencia riscos para uma

decises ir /no ir, sim / nica iterao.


no.

Ambiente

Engenheiro de Processo
Responsvel

Especialista

em

pelo Ferramenta

processo do projeto.

Cria as recomendaes
para usar uma ferramenta
especfica.

Gesto de Alterao Gerente de configurao Gerente de configurao


e Configurao

Configura o ambiente de Realiza auditorias.


gesto

de

alterao, Gerente de Controle de

define polticas e planos.

Alteraes

Gerente de controle de Rev


alteraes

gerencia

solicitaes de alteraes.

36

Define

processos

de

gesto de alteraes.

37

10 Prticas do PU
Uma boa forma de por em prtica o Processo Unificado utilizar o desenvolvimento
iterativo com tempos curtos e para isto algumas boas prticas e conceitos sao
importantes.

10.1 Alto risco


Quando se envolve questes de alto risco em um projeto, uma boa forma de garantir
sucesso concentar em projetar, programar e demonstrar os componentes mais
importantes do software e sua arquitetura. Imagine por exemplo um sistema para
atender mais de 2.000 clientes concorrentes com tempo/resposta com transaes
simultaneas. Este tipo de situao caracteriza alto risco, ou seja, deve-se planejar e
projetar este requisito de alto risco.
O objetivo elimiar os altos riscos na fase inicial de iteraes, para que o projeto
nao falhe. Os riscos em um projeto podem vir de muitas formas como, por exemplo:
falta de habilidades ou recursos, desafios tecnicos, usabilidade, polticas etc.

10.2 Envolver usuarios


O desenvolvimento iterativo e o PU procuram envolver os interessados no negcio
para garantir que suas necessidades sejam atendidas. So necessrios ateno
continua de envolvimento dos interessados e de especialistas com o fim de
esclarecer e direcionar o projeto. Existem grandes falhas em projetos por descuido
quanto ao envolvimento entre as partes interessadas. Esta aproximao d ao
negcio a habilidade de moldar o software conforme o cliente realmente deseja.

38

10.3 Arquitetura
O Processo Unificado centrado na arquitetura, isto porque o PU trata os assuntos
de alto risco em iteraes iniciais, pois comear estabelecer uma arquitetura
geralmente um risco ou elemento crtico no projeto.

10.4 Verificar qualidade


A qualidade inclui detectar os requisitos em um processo repetitivo, com software
que possa ser mantido. Testes realsticos e avaliaes contnuas sao atividades
crticas que podem auxiliar na forma de garantir a qualidade. No PU, a verificao da
qualidade continuamente integrada desde o incio, de modo que no haja grandes
surpresas prximo ao fim do projeto. A avaliao se aplica tambem equipe.

10.5Caso de Uso
Casos de uso sao histrias escritas de uso de um sistema. Sao mecanismos para
explorar e registar requisitos funcionais do sistema. O PU utiliza casos de uso como
forma de

capturar requisitos para

planejar, desenhar, testar e

escrever

documentao de usurio final.

39

11 RUP Rational Unified Process


O RUP (Rational Unified Process) uma metodologia para desenvolvimento de
software criado pela Rational Software, IBM. O RUP pode ser encontrado na forma
de um software, fornecido pela Rational Software, e como um conjunto de
processos.
uma estrutura de processo abrangente, que fornece as prticas da indstria para
software testado e entrega de sistemas e implementao e para a gesto eficaz do
projecto. um dos muitos processos contidos na Biblioteca Processo Rational, que
oferece orientao de melhores prticas adequada ao seu desenvolvimento
particular ou necessidade do projeto.
Neste trabalho iremos cobrir apenas aspectos relativos ao conjunto de processos
referentes ao RUP, incluindo:

Conceitos
Best practices (melhores prticas)
Fases de desenvolvimento

11.1 RUP - Conceitos


Como citado anteriormente, o RUP mais do que um software para auxiliar no
desenvolvimento, uma metodologia de desenvolvimento, com uma estrutura formal
e bem definida. Como qualquer metodologia, composta de conceitos, prticas e
regras.

40

O Rational Unified Process um processo de engenharia de software, esse


processo aumenta a produtividade da equipe e proporciona melhores prticas de
software atravs de diretrizes, modelos e mentores de ferramentas por todas as
atividades do ciclo de vida crticas software. A base de conhecimento permite que as
equipes de desenvolvimento obtenham plenos benefcios da Linguagem de
Modelagem padro da indstria Unificada (UML).
Um dos principais pilares do RUP o conceito de best practices (melhores prticas),
que so regras/prticas que visam reduzir o risco (existente em qualquer projeto de
software) e tornar o desenvolvimento mais eficiente. O RUP define seis best
practices, sendo elas:
Desenvolver iterativamente
Gerenciar requerimentos
Utilizar arquiteturas baseadas em componentes
Modelar visualmente
Verificao contnua de qualidade
Controle de mudanas

O RUP, ainda entrelaa o conceito de best practices em quatro definies, sendo


elas:
Funes: grupos de atividades executadas.
Disciplinas: reas de esforo na engenharia de software.
Atividades: definies de como (objetos/artefatos) construdo e avaliado.

41

Objetos/artefatos: resultado do trabalho, produzido ou modificado durante o


processo.

Alm destas definies, esta metodologia de desenvolvimento divide o processo de


desenvolvimento de software em quatro fases (as quais sero discutidas com mais
detalhes posteriormente). So elas:
Concepo: definio do escopo do projeto.
Elaborao: elaborao bsica do software.
Construo: desenvolvimento.
Transio: Implantao e monitoramento.

11.2 RUP Melhores Prticas


O RUP tenta diminuir os riscos do desenvolvimento e efetivamente deixar o
desenvolvimento mais eficiente, atravs de seis prticas bsicas (conhecidas por
best

practices)

serem

executadas

durante

todo

processo

de

desenvolvimento.Logo abaixo temos as descries das seis melhores prticas.

11.2.1 - Desenvolver Iterativamente


Desenvolver iterativamente significa desenvolver em ciclos. Cada ciclo contm um
objetivo que deve ser alcanado (lanamento de um pre-release ou beta, correo
de um bug, etc). Esta prtica acaba dando ao RUP uma srie de vantagens, como a
possibilidade de identificar/modificar requerimentos com mais facilidade; integrao
progressiva (quase continua) de elementos ao software, ocasionando uma melhora
no descobrimento e endereamento de riscos; desenvolvimento iterativo prov aos
gerentes maneiras de fazer mudanas tticas aos produtos; etc.

42

11.2.2 Gerenciar Requerimentos


Gerenciamento de requerimentos prov uma maneira prtica de produzir, comunicar
e organizar os requerimentos de um projeto. Adicionalmente, os casos de uso e
cenrios descritos nos processos so uma excelente forma de capturar e assegurar
requisitos. O gerenciamento de recursos acarreta um melhor controle sobre projetos
complexos, alm de maior qualidade e reduo de custos.

O RUP uma metodologia dirigida-a-casos-de-uso (use-driven-case), de modo que


possvel utilizar os mesmos casos de uso definidos no sistema como base para o
resto do processo.

11.3 Utilizar Arquiteturas Baseadas em Componentes


Foca o desenvolvimento na modularizao, atravs do uso de componentes, de
modo a criar um sistema flexvel, adaptvel, intuitivamente entendvel e reutilizvel.
O RUP entende componentes como mdulos no triviais e/ou subsistemas com uma
funo clara e especfica. Entre os benefcios podemos citar a facilidade para
identificar, isolar, manipular e desenvolver componentes maior do que para um
sistema inteiro; componentes podem ser desenvolvidos com a reutilizao em
mente; etc.

11.4 Modelar Visualmente


A modelagem visual permite melhor entender no s a concepo e a complexidade
do sistema, mas tambm dimensionar (no sentido de qual a forma do sistema),
alm de facilitar a identificao e soluo de problemas.

43

11.5 Verificao Continua de Qualidade


O RUP no toma a qualidade como responsabilidade de apenas uma pessoa ou
grupo, mas como uma responsabilidade de todos os integrantes do projeto.
A qualidade focada especialmente em duas reas:
Qualidade de produto: a qualidade do produto sendo desenvolvido (software
ou sistema) e todas as partes envolvidas (componentes, subsistemas,
arquitetura, etc).
Qualidade de processo: a qualidade dos processos dentro do projeto de
desenvolvimento.

11.6 Controle de Mudanas


Como resultado de um processo de desenvolvimento iterativo, muitas so as
mudanas ocorridas no decorrer do projeto. Controlar as mudanas durante todo o
projeto prtica fundamental para manter a qualidade do projeto.

11.7 Fases de Desenvolvimento


O processo de desenvolvimento dividido em ciclos, sendo que o ciclo de
desenvolvimento subdividido em 4 fases consecutivas.
Estas fases so concludas to logo uma milestone alcanada. Uma milestone
define uma etapa, na fase, na qual decises crticas so feitas ou objetivos so
alcanados.

11.7.1 Concepo
Durante a fase inicial, voc estabelece o business case para o sistema e delimitar o
escopo do projeto. Para conseguir isso, voc deve identificar todas as entidades

44

externas com as quais o sistema ir interagir (atores) e definir a natureza dessa


interao em alto nvel. Isso envolve identificar todos os casos de uso e descrevendo
alguns mais significativos. O caso de negcios inclui critrios de sucesso, avaliao
de risco e estimativa do recursos necessrios, e um plano de fase mostrando as
datas de marcos principais.

O resultado da fase de iniciao :


Um documento de viso: uma viso geral dos requisitos do projeto ncleo,
principais caractersticas e principais constrangimentos.
Um modelo de casos de uso inicial (10% -20%) completa.
Um glossrio inicial do projeto (pode, opcionalmente, ser parcialmente
expresso como um modelo de domnio).
Um caso de negcio inicial, que inclui contexto do negcio, critrios de
sucesso (projeo de receitas, o mercado reconhecimento, e assim por
diante), e previso financeira.
Uma avaliao inicial dos riscos.
Um plano de projeto, mostrando as fases e iteraes.
Um modelo de negcios, se necessrio.
Um ou vrios prottipos

No final da fase de iniciao temos um primeiro grande marco do projeto: o Marco


dos Objetivos do Ciclo de Vida.
Os critrios de avaliao para a fase de iniciao so:
Stakeholder concordncia sobre a definio do escopo e de custo /
programao estimativas.
Requisitos compreenso como evidenciado pela fidelidade dos principais
casos de uso.

45

Credibilidade das estimativas de custo / programao, as prioridades, riscos e


processo de desenvolvimento.
Profundidade e amplitude de qualquer prottipo arquitectnico que foi
desenvolvido.
Gastos reais com despesas previstas.

O projeto pode ser cancelado ou completamente repensado se ele no passar por


este marco.

11.7.2 Elaborao
O propsito desta fase analisar o domnio do problema, desenvolver o plano de
projeto, estabelecer a fundao arquitetural e eliminar os elementos de alto risco.
Os elementos de risco a serem analisados, nesta fase, so os riscos de
requerimentos, tecnolgicos (referentes a capacidade das ferramentas disponveis),
de habilidades (dos integrantes do projeto) e polticos.

Esta a fase mais crtica de todas, pois ao final desta fase a engenharia
considerada completa e os custos para modificao do sistema aumentam medida
que o projeto avana. Do ponto de vista administrativo, ao final desta fase que um
projeto deixa de ser uma operao de baixo risco e baixo custo para se tornar uma
operao de alto risco e alto custo.
O resultado da fase de elaborao a seguinte:
Um modelo de caso de uso (pelo menos 80% concludo) - todos os casos de
uso e atores foram identificados, e mais uso das descries de casos tem
sido desenvolvido.

46

Requisitos suplementares - capturar os requisitos no funcionais e de todos


os requisitos que no so associados a um caso de uso especfico.
A Descrio de Arquitetura de Software.
Um prottipo arquitetural executvel.
A lista de riscos revista.
Um plano de desenvolvimento para o projeto global.
Um caso de desenvolvimento atualizadas especificando o processo para ser
usado.
Um manual do usurio preliminar (opcional).

No final da fase de elaborao temos o segundo projeto marco importante: o Marco


Arquitetura do Ciclo de Vida.

Neste ponto, voc examina os objetivos e o escopo detalhados do sistema, a


escolha da arquitetura, e a resoluo dos principais riscos.
Os principais critrios de avaliao para a fase de elaborao envolvem as
respostas a estas perguntas:
a viso do foco do produto?
a arquitetura estvel?
A demonstrao executvel mostra que os principais elementos de risco
foram abordados e resolvidos?
o plano para a fase de construo suficientemente detalhadas e precisas?
apoiada por uma credvel com base em estimativas?
o gasto de recursos reais versus despesas previstas aceitvel?

O projeto poder ser anulado ou completamente repensado se ele no passar este


marco.

47

11.7.3 Construo
Esta fase compreende a fase de modelagem e a fase de desenvolvimento em si,
aquela em que o sistema efetivamente programado. A fase de modelagem deve
utilizar alguma notao definida pela UML.

O resultado da fase de construo um produto pronto para colocar nas mos de


seus usurios finais. No mnimo, ele consiste em:
O produto de software integrado para as plataformas adequadas.

Os manuais do usurio.

Uma descrio da verso atual.

No final da fase de construo temos o terceiro maior marco: o Marco da


Capacidade Operacional Inicial.

Neste ponto, voc decide se o software est pronto para uso, sem expor o projeto
para riscos elevados. Esta verso freqentemente chamado de uma liberao
"beta".
Os critrios de avaliao para a fase de construo envolvem responder a estas
perguntas:
esta verso do produto estvel e maduro o suficiente para ser implantado
na comunidade de usurios?
Todos os envolvidos esto prontos para a transio para a comunidade de
usurios?
Os gastos de recursos reais versus despesas previstas ainda aceitveis?

Transio pode ter de ser adiada por um release se o projeto no atinja este marco.

48

11.7.4 Transio
A partir desta fase, o sistema j est pronto, comea a implantao do sistema para
o usurio (ou a comunidade de usurios do mesmo). Nesta fase deve ser utilizado o
lanamento de verses beta, operao paralela com o sistema legado, treinamento
dos usurios e mantenedores do sistema, etc.

A fase de transio enfoca as atividades necessrias para colocar o software nas


mos

dos

usurios. Normalmente.

Considervel

esforo

dispendido

no

desenvolvimento de documentao de utilizador, treinamento de usurios, suporte a


usurios no seu uso inicial do produto, e reagindo a comentrios do usurio.

Neste ponto do ciclo de vida, no entanto, feedback do usurio deve ser confinado
principalmente para ajuste de produtos, configurao, instalao e problemas de
usabilidade.
Os objetivos primrios da fase de transio incluem:
Suporte ao usurio
Atingir o consentimento dos envolvidos de que as baselines de implantao
so completos e coerentes com critrios da viso
Atingir baseline do produto final, rapidamente e com baixo custo como prtica.

Esta fase pode variar em ser muito simples ou muito complexa, dependendo do tipo
de produto. Por exemplo, uma nova verso de um produto de mesa existente pode
ser muito simples, enquanto que a substituio de controle de um software de
trfego areo sistema seria muito complexo.

No final da fase de transio temos o quarto marco importante: o Marco do Release


do Produto.

49

Neste ponto, voc decide se os objetivos foram cumpridos, e se voc deve comear
um outro ciclo de desenvolvimento. Em alguns casos, esse marco pode coincidir
com o final da fase de iniciao para o prximo ciclo.
Os critrios bsicos de avaliao para a fase de transio envolvem as respostas
para estas perguntas:
O usurio est satisfeito?
Os gastos reais dos recursos contra despesas previstas ainda aceitvel?

11.8 Iteraes
Cada

fase

no

Rational

Unified

Process

podem

ser

subdivididas

em

iteraes. Uma iterao um completo ciclo de desenvolvimento, resultando em um


release (interno ou externo) de um produto executvel, um subconjunto do produto
final em desenvolvimento, que cresce de forma incremental de iterao para iterao
para se tornar o sistema final.

11.8.1Benefcios de uma abordagem iterativa


Comparado com o processo em cascata tradicional, o processo iterativo tem as
seguintes vantagens:
Riscos so reduzidos mais cedo
Mudar mais gerencivel
Maior nvel de reutilizao
A equipe de projeto pode aprender ao longo do caminho
Melhor qualidade geral

50

11.9 Estrutura Esttica do Processo


Um processo descreve quem est fazendo , como est sendo feito, o que est
sendo feito e quando ser feito. O Rational Unified Process representada usando
quatro principais elementos de modelagem:
Os trabalhadores, o 'quem'
Atividades, o 'como'
Artefatos, o "o qu"
Os fluxos de trabalho, o 'quando'

11.1 Trabalhador
Um trabalhador define o comportamento e as responsabilidades de um indivduo ou
um grupo de indivduos que trabalham juntos como uma equipe. Voc poderia
considerar um trabalhador como um "chapu" que um indivduo pode usar no
projeto. Um indivduo pode usar muitos chapus diferentes.

Esta uma distino importante porque natural que se pense de um trabalhador


como o indivduo ou a prpria equipe, mas no Unified Process o trabalhador mais
um

papel

definindo

como

os

indivduos

devem

realizar

trabalho. As

responsabilidades so atribudas a um trabalhador que inclui tanto a executar um


determinado conjunto de atividades, bem como ser proprietrio de um conjunto de
artefatos.

11.2 Atividade
Uma atividade de um trabalhador especfico uma unidade de trabalho que um
indivduo em que o papel pode ser solicitado a executar. A atividade tem um
propsito claro, normalmente expressa em termos de criao ou atualizao de
alguns artefatos, como um modelo, uma classe, um plano.

51

Toda atividade atribuda a um trabalhador especfico. A granularidade de uma


atividade geralmente algumas horas a alguns dias, ele geralmente envolve um
trabalhador, e afeta um ou apenas um pequeno nmero de artefatos.
Uma atividade deve ser usada como um elemento de planejamento e progresso, se
ele for muito pequeno, ele vai ser negligenciado, e se for muito grande progresso,
teria que ser expressa em termos de partes de uma atividade.
Exemplo de atividades:
Planejar uma iterao, para o Trabalhador: Gerente de Projeto
Encontrar casos de uso e atores, para o Trabalhador: Analista de Sistemas
Rever o design, para o Trabalhador: Revisor de Design
Executar teste de desempenho, para o Trabalhador: Performance Tester

11.3 Artefato
Um artefato um pedao de informao que produzido, modificado ou usado por
um processo. Artefatos so os tangveis produtos do projeto, algo utilizado no
projeto enquanto no chegava no produto final.
Artefatos so usados como entrada dos trabalhadores para realizar uma atividade, e
so o resultado ou sada de tais atividades. Em um projeto orientado a objeto termos
de design, como as atividades so operaes em um objeto ativo (o trabalhador), os
artefatos so os parmetros dessas atividades como:
Um modelo, como o Modelo de Casos de Uso ou o Modelo de Design
Um elemento do modelo, ou seja, um elemento dentro de um modelo, como
uma classe, um caso de uso ou de um subsistema
Um documento, como o Business Case ou Documento de Arquitetura de
Software
O cdigo-fonte
executveis

52

11.4 Fluxos de trabalho


A simples enumerao de todos os trabalhadores, atividades e artefatos no
chegam a constituir um processo. Precisamos de um caminho para descrever as
seqncias significativas de atividades que produzem algum resultado valioso, e
para mostrar as interaes entretrabalhadores.
Um fluxo de trabalho uma seqncia de atividades que produz um resultado de
valor observvel.

Em termos da UML, um fluxo de trabalho pode ser expressa como um diagrama de


seqncia, um diagrama de colaborao, ou um diagrama de atividades.

53

12 Requisitos
So um conjunto de caractersticas, condies e capacidades que o sistema deve
abranger e realizar. Ele tem o papel de descrever as funcionalidades que o sistema
deve ter, bom como o sistema deve fazer para atender a estas funcionalidades. O
conjunto de requisitos dinmico e envolve identificao contnua.

12.1 Classificao dos Requisitos


Os requisitos podem ser classificados em cinco grupos:
Funcionais: recursos, capacidades, segurana;
Usabilidade: fatores humanos, ajuda, documentao;
Confiabilidade: freqncia de falhas, capacidade de recuperao e de prover
problemas;
Desempenho: tempo de resposta, preciso, disponibilidade e uso de
recursos;
Suporte: capacidade de adaptao, de manuteno e configurao.

Alguns desses requisitos so chamados de requisitos de qualidade. De forma mais


abrangente os requisitos so classificados em funcionais (comportamentais) e nofuncionais(todos os outros).

12.2 Os Requisitos Funcionais


So as descries das diversas operaes que clientes e usurios querem
(conhecidos tambm como requisitos de usurio), ou precisam que sejam realizadas
pelo sistema. Esse requisito est relacionado com as facilidades que o sistema deve
oferecer a seus usurios.
Os requisitos funcionais so classificados como:

54

12.2.1Requisitos de Negcio (RqN) ou Business Why


Os Requisitos de Negcio fornecem a razo para o desenvolvimento de sistemas e
software, so derivados a partir dos objetivos de negcio e visa o que precisa ser
entregue para agregar valor ao negcio do Cliente. Este requisito est focado no
entendimento do POR QUE e PARA QUE o projeto/sistema requerido e, como
contribuir para os objetivos do negcio e do usurio.

Os Requisitos de Negcio devem ser escritos do ponto de vista do solicitante


(usurio). Este requisito a base para os requisitos de sistemas.
Algumas perguntas devem ser respondidas para levantar um bom Requisito de
Negcio :
Por que vamos gastar dinheiro com este projeto?
O que o nosso negcio ganha com isso?
O que devemos entregar para gerar valor ao negcio?
12.2.2 Requisitos de Processo (RqP) ou Process What
Requisitos de Processo descreve o qu deve ser disponibilizado pelo
processo/sistema/software para atender ao requisito de negcio. Define tambm as
funcionalidades esperadas sob o ponto de vista de funes.

Este requisito deve atender a um comportamento na qual usurio espera que ele
faa traduzindo o que o sistema/produto precisa fazer para atender as

suas

necessidades onde tal necessidade est relacionada a um problema de negcio. O


Requisito de Processo determina O QUE requerido (sem a preocupao do
COMO ser feito).

55

12.2.3Requisitos Tcnicos (RqT) ou System How


Requisitos Tcnicos so derivados dos requisitos de sistemas. Este requisito est
focado no COMO os requisitos sero construdos e disponibilizados.O requisito
Tcnico escrito sob a tica dos desenvolvedores.

12.3 Os Requisitos No Funcionais


So restries ou atributos de qualidade de um software ou de um processo de
desenvolvimento de software. necessrio que estes requisitos sejam considerados
na fase inicial do processo de desenvolvimento de software.
Restries sobre a operao;
Como o sistema deve se comportar;
Restries sobre o desenvolvimento;
Como uma facilidade deve ser implementada;

Os requisitos no funcionais so classificados como:

12.3.1 Requisitos do produto


Os Requisitos do produto devem especificar que o produto a ser desenvolvido e logo
a ser entregue se comporte de uma determinada forma pela qual foi produzido.
Exemplo: velocidade de execuo, confiabilidade, estabilidade etc.

12.3.2 Requisitos organizacionais


Este requisito elaborado visando quais

so as polticas e procedimentos

Organizacionais de uma empresa, buscando respeitar tais polticas.


Por exemplo: Processos standard utilizados, requisitos de implementao, forma de
trabalho implantada, etc.

56

12.3.3 Requisitos externos


Requisitos externos esto relacionados aos fatores que so externos ao sistema e
ao

seu

processo

de

desenvolvimento.

Por

exemplo:

requisitos

de

interoperacionalidade, requisitos legais, etc.

12.4 Qualidades sistmicas


Os Requisitos No-Funcionais determinam as qualidades sistmicas do sistema de
software, determinam quo bem o sistema se comporta no limite entre o ator e o
sistema.

Questes sobre Requisitos No-Funcionais so frequentemente ambguas. Pode ser


difcil encontrar a pessoa certa para perguntar.
Eis algumas dicas:
Saber quais qualidades sistmicas so importantes ao sistema.
Saber quem perguntar sobre estas qualidades.
Saber quais frases chaves escutar e que questes perguntar para
determinao de quais Requisitos No-Funcionais para uma determinada
qualidade sistmica.
12.4.1 Qualidade sistmica Desempenho
Questes sobre desempenho aparecem em entrevistas de requisitos. Veja algumas
questes que voc deve procurar:
Em alguns casos o usurio menciona quo rpido uma operao deve
ocorrer.

57

Gerentes de usurios normalmente possuem expectativas pr-definidas


sobre a velocidade de operaes individuais bem como o tempo total para
completar um caso de uso.

Administradores de sistema frequentemente conhecem a vazo esperada do


sistema e a capacidade de vrios recursos (nmero de usurios, tamanho dos
arquivos, nmero de registros no banco de dados, nmero de transaes,
etc...).

Usurios fornecem sentenas relacionadas com desempenho, tais como:


Quando eu clico neste boto o sistema atual demora muito para responder;
Eu preciso de uma resposta dentro de 5 segundos.
Este relatrio demora muito a ser gerado, mas isto no tem problema, porque
ele gerado automaticamente noite.

Voc pode fazer perguntas relacionadas desempenho, tais como:


Quo rpido esta operao necessita ser?
Quantas transaes ocorrem no banco de dados em horrios normais e de
pico?
Quantos usurios simultneos usaro o sistema?
12.4.2 Qualidade sistmica Escalabilidade
Escalabilidade relacionada ao desempenho, mas a capacidade de se aumentar a
quantidade de processamento de dados com o passar do tempo.
Por exemplo, uma aplicao web necessita atender 20 usurios simultneos este
ano, mas dever aumentar para 50 usurios dentro de 5 anos.

58

Determinar a escalabilidade frequentemente um trabalho de adivinhao e


depende muito do crescimento planejado do negcio. Portanto, os donos e gerentes
do negcio frequentemente possuem a melhor perspectiva sobre questes de
expanso.
Entretanto, administradores do sistema, rede e banco de dados sempre possuem
informaes sobre tendncias em suas reas:
Carga do sistema em perodos normais e de pico.
Uso da rede em perodos normais e de pico.
Mdia de crescimento das tabelas do banco de dados.
Atualizaes planejadas de Hardware.
12.4.3 Qualidade sistmica Usabilidade
Esta qualidade sistmica difcil de ser quantificada, mas o objetivo determinar
consideraes sobre a facilidade de uso do sistema.
A primeira coisa a fazer analisar as habilidades dos atores.
Algumas destas anlises podem ser obtidas observando o ator durante as
entrevistas de coleta de requisitos e os observando no local de trabalho.
Voc tambm pode perguntar ao gerente do ator sobre suas capacidades.

59

Um segundo passo determinar consideraes especficas de usabilidade


baseadas nas habilidades dos atores.

Observe algumas consideraes sobre usabilidade:


Consistncia do sistema proposto com sistemas similares ou em uso
atualmente.
Look and feel: local dos botes, espaamento, vrias janelas, janelas com
abas, etc...
Localizao e internacionalizao.
Facilidade de navegao e workflow.
Acessibilidade.
12.4.4 Qualidade sistmica Segurana
A maioria das aplicaes, em especial as aplicaes corporativas, requer forte
controle sobre quem acessa determinadas funes do sistema. O papel dos atores
normalmente define os papis iniciais de segurana do sistema.
Porm, considere estas outras questes de segurana:
Como sero armazenadas informaes do usurio e senhas?
Quais ameaas externas (e internas) podem existir?
Que granularidade de controle necessria?
Se existe uma aplicao Web, que dados crticos (senhas, carto de crdito,
etc..) so transmitidos pela internet?

12.5 Dos Requisitos para o Cdigo


O analista precisa falar duas lnguas diferentes: a do usurio e a do desenvolvedor.
O usurio est interessado no negcio, enquanto o desenvolvedor quer entender a

60

estrutura e o comportamento do software para garantir que o mesmo atenda ao


usurio.

O modelo de caso de uso registra um subconjunto dos requisitos funcionais do


sistema. Esse modelo formado pelos Diagramas de Caso de Uso que modela o
ambiente e as funcionalidades do sistema e pela especificao descrevendo os
atores e caso de uso.

61

13 Problema
O grande desafio para se identificar e modelar requisitos de um sistema se deve ao
fato de que eles so dinmicos, e podem mudar durante um projeto. Softwares so
construdos todos os dias baseados em requisitos que freqentemente mudam. Mas
quais so as causas dessa mudana? Entre os fatores, podem ser citadas as
alteraes nos planos do cliente e ainda o fato de que a noo completa dos
requisitos s fica mais clara nas fases finais do projeto.

Um bom levantamento de requisitos traz muitos benefcios que tem impacto direto
na produtividade, teste, qualidade e organizao. Esses benefcios podem ser
aproveitados tanto durante o desenvolvimento quanto durante a manuteno do
sistema:
Uma boa especificao permite ao analista identificar conflitos entre os
requisitos do usurio no inicio, coletando respostas para as dvidas e
evitando que uma direo errada faa com que um produto errado seja
construdo.
Uma boa especificao ajuda a diminuir a curva de aprendizado para novos
integrantes do time de desenvolvimento.
A especificao de requisitos tambm facilita e acelera o processo de testes.
O testador pode aprender a usar o sistema e explorar suas funcionalidades
to rpido quanto novos integrantes.
Finalmente uma boa especificao uma rea segura de armazenamento da
propriedade intelectual da empresa.

62

14 Capturando os Requisitos do Sistema


Para que um software seja bem definido e planejado, necessrio fazer um bom
levantamento dos requisitos, pois so eles que tornam possvel que um software
realmente consiga atingir um determinado problema ou soluo, e assim atender de
fato as necessidades do cliente. Fazer um planejamento para o Levantamento de
Requisitos, identificar fontes de requisitos e identificar todos os stakeholders a serem
entrevistados so uns dos passos importantes.

14.1 Identificando Fontes de Requisitos


Os Requisitos de um sistema podem surgir de vrias fontes. Eis algumas
importantes:
Entrevista com os stakeholders,
Observando os usurios em servio,
Analisando e documentando polticas e procedimentos,
Analisando o sistema existente,
Analisando e documentando entradas e sadas.

Temos ento algumas maneiras de identificar os requisitos para iniciar um projeto de


software.

14.2 Identificando os Stakeholders


A lista inicial de stakeholders fornecida pelo dono do negcio. Todavia, esta lista
deve ser expandida assim que comear as entrevistas.
So stakeholders:
Principais usurios do sistema,
Usurios

operacionais

do

sistema,

administradores

do

sistema

administradores de rede,

63

Gerentes dos usurios principais e operacionais,


Especialistas do domnio,
Gerente de marketing

Crie uma lista de stakeholders para cada ator como por exemplo:

14.3 Preparando para Entrevistar os Stakeholders


Com uma lista dos principais stakeholders, importante elaborar uma lista inicial de
questes sobre Requisitos Funcionais que seja possvel verificar a viso do dono do
negcio para aquele caso de uso. Descubra o prximo nvel de detalhamento. Para
cada stakeholder, determine um conjunto de perguntas sobre Requisitos No
Funcionais. Com uma entrevista bem elaborada possvel identificar os requisitos
mais importantes.

14.4 Questes Detalhadas dos Requisitos Funcionais


Para que seja possvel capturar dos entrevistados (stakeholders) informaes mais
detalhadas de como o software utilizado, o interessante , que para cada ator seja
elaborado algumas questes do tipo:
O caso de uso xyz necessrio para seu trabalho?
Explique todos os passos que voc realiza para executar xyz.

64

Que dados so coletados em cada passo?


Que dados so obrigatrios e quais so opcionais?
Se atualmente voc usa algum software para suportar xyz, voc pode
fornecer as imagens das telas?

Voc pode fornecer um cenrio concreto do caso de uso xyz?

O seu trabalho na realizao de xyz inclui a gerao de relatrios?

Seu trabalho requer a interao com algum sistema externo no caso de uso
xyz?
O seu trabalho utiliza dados externos para a execuo do caso de uso xyz?

importante que essas informaes adicionais sejam bem guardadas, pois sero
muito teis no processo de desenvolvimento.

14.5 Questes para Esclarecimento de Requisitos


Por basear os requisitos atravs de entrevistas, natural que alguns atores
(stakeholders) sejam frequentemente imprecisos ao repassar algumas informaes.

Existem trs questes fundamentais usadas para tentar solucionar esse problema:
Remoo: Informao no fornecida.
Distoro Informao modificada por criao ou engano.
Generalizao A criao de regras.

14.5.1 Questes para Esclarecimento: Remoo


A informao no fornecida.

Agente de Reservas: Quando eu fao uma reserva, anoto o quarto que est sendo
reservado.
Problema: O agente esquece o fato que vrios quartos podem ser reservados.

65

Soluo: Pergunte o stakeholder por esclarecimento.


ACME: possvel reservar mais que um quarto?
Agente de Reservas: Oh sim, eu esqueci isto. No acontece com muita freqncia,
mas acontece. H poucos meses atrs, um casal acabara de se casar no nosso
imvel em Sonoma B&B. Eles reservaram quatro quartos para os familiares.

14.5.2 Questes para Esclarecimento: Distoro


Informao modificada por criao ou engano.

Agente de Reservas: Uma reserva pode ser mantida sem a confirmao com o
carto de crdito. Mas cancelada se o cliente no confirm-la dentro de duas
semanas.
Problema: O Agente de Reservas forneceu uma informao incorreta ao
entrevistador sobre a poltica de cancelamento, pois o cancelamento dado dois
dias antes da data de chegada do hspede.
Soluo: Pergunte outros stakeholders para validao e esclarecimento.

14.5.3 Questes para Esclarecimento: Generalizao


Regras gerais so criadas de forma inapropriada

Recepcionista: Eu sempre passo o carto de crdito do cliente quando ele faz o


check-in.
Problema: O recepcionista diz que sempre passa o carto de crdito como parte do
procedimento para check-in.
Soluo: Pergunte o stakeholder para esclarecimento.

ACME: Existe alguma situao na qual o cliente no necessita de carto de crdito


para efetuar uma reserva?

66

Recepcionista: Sim, eu esqueci. Ocasionalmente atendemos clientes empresariais


que confirmam suas reservas com um vale da empresa.

67

15 Documento Viso
O Documento Viso desenvolvido aps a coleta e anlise dos requisitos
preliminares. O documento Viso contm a viso do dono sobre o sistema de
software. O propsito deste documento expor as necessidades e funcionalidades
gerais do sistema.
Seu foco est nas necessidades dos patrocinadores (stakeholders) no motivo da
existncia destas necessidades e tambm documenta os riscos e restries.

Para determinar a viso do projeto, devemos entrevistar o dono do negcio para


determinar os requisitos funcionais de alto-nvel. O dono do negcio qualquer um
que solicita a confeco do projeto.

Existem cinco sees no documento Viso:


Introduo (incluindo enunciado do problema)
Oportunidade de negcio
Soluo proposta (inclui RFs e RNFs)
Riscos
Restries

Mantenha o documento Viso no menor tamanho possvel e o mais claro possvel.

15.1 Introduo
O enunciado do problema um resumo sucinto do problema do negcio. Ele no
inclui todos os RFs ou casos de uso, mas pelo menos os principais.

68

Exemplo:

O Sistema de Reserva de Hotel ser responsvel por gerenciar as reservas para


vrias filiais, que incui (mas no limitado) quartos, caf da manh e salas de
reunies. O sistema dever incluir uma aplicao web que permite que clientes
visualizem as filiais e quartos, visualizem reservas atuais e passadas, e faam novas
reservas.

15.2 Oportunidade de negcio


Esta seo do documento Viso registra a viso do dono do negcio sobre a
empresa (presente e futuro) e como o software atender o negcio. A oportunidade
de negcio descreve os fatores principais que motivam o gasto na construo do
sistema.
Isto expresso como um problema do negcio resultando em no satisfao,
ineficincia, perda de mercado, redefinio de mercado, etc.

Exemplo:

Bay View B&B uma empresa hoteleira inaugurada em 1987, em Santa Cruz, CA,
por vrios scios, dentre eles, Peter e Mary Jane Parker. Em 2005, eles adquiriram
outra B&B em Sonoma, CA. Os negcios estavam indo bem quando Mary Jane e
Peter estavam de frias no Resort Sierra Madre em 2008, eles conversaram com o
scio majoritrio e descobriram que ele estava pronto para se aposentar. Esta era a
oportunidade que eles estavam esperando para expandir o negcio. Eles esto
atualmente trabalhando no fechamento deste acordo. O Sistema de Reserva de
Hotel est sendo proposto para fornecer uma integrao destes imveis.

69

15.3 soluo proposta


Esta seo do documento Viso registra todos os requisitos (tanto RF quanto RNF)
identificados pelo dono do negcio.
Liste RFs em sentenas curtas que descrevem como um ator utiliza o sistema. Por
exemplo:
O sistema dever incluir um sistema web, em vrios idiomas, incluindo fotos
dos quartos e dos imveis.
O sistema dever integrar reservas entre todos os imveis.
O recepcionista dever ser capaz de efetuar o check-in e check-out de um
cliente.
Separe RFs em categorias de prioridades.
Descreva de maneira sucinta todos RNFs identificados durante as entrevistas
com o dono do negcio.

15.4 Riscos
Esta seo do documento Viso registra todos os riscos que foram identificados nas
entrevistas com o dono do negcio. Descreva qualquer risco relativo com questes
tecnolgicas, problemas de equipe de desenvolvimento, problemas polticos, etc.

Exemplo:

O principal risco do projeto determinar uma estratgia para converso de dados


existentes (planilhas e arquivos textos do Resort) no novo formato de dados. Outro
risco em potencial a relao custo/benefcio de se terceirizar o desenvolvimento do
sistema ou constru-lo com a equipe de desenvolvimento local. A minimizao

70

destes estar presente no documento SRS(System Requirements Specification


Especificao dos Requisitos do Sistema).

15.5 Restries
Esta seo do documento Viso registra todas as restries que foram identificadas
em entrevistas com o dono do negcio.
Exemplo:

Devido ao custo de se comprar o imvel utilizado para o Resort, os Parkers no


podem gastar com ferramentas caras tais como servidor de banco de dados ou
servidor de aplicao. Devem-se usar ferramentas Open Source, estveis, na
medida do possvel.

71

16. SRS
SRS (Especificao de Requisitos de Software ) controla a evoluo do sistema em
toda a fase de desenvolvimento do projeto. Quando novos recursos so adicionados
ou modificados no documento Viso, eles so elaborados dentro do SRS.
O documento SRS contm seis sees:
Introduo
Restries e suposies
Riscos
Requisitos Funcionais
Requisitos No Funcionais
Glossrio do projeto
O documento SRS deve ser detalhado sem perda de claridade ou foco.

16.1Introdo
O propsito da introduo do documento de descrever o objetivo e contexto do
documento e no o propsito da aplicao. A introduo deve ser muito breve e
direta ao ponto.
A seo introdutria inclui:
Objetivo
Escopo
Contexto do sistema
Principais Stakeholders
Acrnimos e abreviaes
Organizao do documento
Descrio de como as mudanas de requisitos sero tratatadas
Referncias

72

16.2 Restries e suposies


Defina todas as restries externas ( fatos que no podem ser alterados ou decises
feitas previamente que no so esperadas para serem reconsideradas durante o
projeto) que restrinjam os requisitos, projeto, implementao ou aceitao
especialmente incluindo custos e limitaes de tempo. As restries aqui so as
mesmas que as restries descritas no documento viso, a diferena que nesta
seo as restries so mais detalhadas.

16.3 Riscos
Esta seo fornece uma lista completa dos riscos de projeto mais estratgia, para
minimizao do risco. O conjunto de riscos deve incluir todos os riscos listados no
documento viso, mas pode tambm incluir riscos adicionais identificados durante
entrevistas para coleta de requisitos.
Riscos Tecnolgicos.
Risco de Recursos e Habilidades
Riscos Polticos

16.4 Requisitos funcionais


Fornece uma exaustiva discusso de RF s, comparado com as discusses de alto
nvel no Documento Viso no mesmo tpico. A seo de Requisitos Funcionais inclui
as seguintes subsees:
Caractersticas Principais
Atores
Casos de Uso
Aplicaes
Requisitos detalhados dos casos de uso

73

16.4.1 atores
Fornece um resumo sucinto das habilidades do ator.
Por exemplo:
Esta pessoa gerencia reservas de clientes por telefone; assim sendo, Ela,
normalmente, o primeiro ponto de contato com o Gerenciamento de imveis da
Bay View.
Esta pessoa no precisa de grande escolaridade (o ensino mdio recomendado),
mas essa pessoa precisa ser familiar com o Sistema Operacional Windows e dever
ser bom digitador. Esta pessoa ser treinada nos imveis da Bay View.

16.4.2 Casos de uso


A seo Casos de Uso fornece uma tabela com todos os casos de usos com sua
prioridade, identificador nico e descrio.
Por exemplo:

16.4.3 Aplicaes
A seo Aplicaes fornece uma tabela de todas as aplicaes independentes que
formam o sistema.
Por exemplo:

74

16.4.4Requisitos detalhados
A seo de detalhamento de requisitos uma lista completa de Requisitos
Funcionais detalhados que compe cada caso de uso.
Cada Requisito Funcional possui um identificador baseado no cdigo do caso
de uso. O cdigo do caso de uso o cdigo de prioridade concatenada com o
nmero nico do caso de uso.
Cada Requisito Funcional possui uma descrio.
Por Exemplo:

16.5 Requisitos nao funcionais


A seo requisitos no-funcionais uma lista completa de RNFs detalhados,
agrupados por qualidade sistmica.
Cada Requisito No-Funcional possui um identificador baseado no cdigo

75

do Caso de Uso.
Cada Requisito No-Funcional possui uma descrio.
Por exemplo:

16.6 Glossrio
O glossrio no documento SRS deve incluir:
Termos do Domnio
Sinnimos
Termos Tecnolgicos
Termos usados no desenvolvimento do software

16.7 Resumo
A Coleta ou Levantamento de Requisitos essencial a um projeto de software de
sucesso porque os requisitos especificam o comportamento do sistema a ser
implementado. Requisitos so adquiridos de vrias fontes com vimos, p.e entrevistas
com stakeholders so as principais ferramentas para coleta de requisitos.
O Documento SRS estende o Documento Viso e fornece requisitos detalhados.

76

17 Disciplina de Anlise de Projeto


A atividade de Anlise foca a investigao do problema e dos requisitos, ao invs da
soluo. O termo analise amplo, sendo melhor qualificado como anlise de
requisitos.

A Disciplina de anlise de projeto tem como objetivo modelar o sistema. O principal


insumo para essa disciplina so os artefatos produzidos pela disciplina de requisitos.
A partir deles, sero aplicadas tcnicas de modelagem de classes, sero criados
diagrama de seqncia, colaborao, estado e componente.

As principais atividades dessa disciplina esto listadas a seguir:

17.1 Definir e evoluir uma arquitetura robusta para o sistema.


A prtica mostra que a maneira mais eficiente de desenvolver um software definir
sua arquitetura para o sistema, depois realizar a modelagem e implementaes
baseadas nessa arquitetura. O projeto de arquitetura deve refletir tanto os requisitos
do sistema, quanto os padres arquitetnicos existentes na empresa.

17.2 Adaptar o desenho para o ambiente de implementao


O desenho deve refletir tambm o ambiente de implementao escolhido. Por
exemplo, no faz sentido escolher uma tecnologia que a linguagem de programao
escolhida no suporte. Alm disto, as plataformas de programao, como Java e
.Net, tem suas prprias recomendaes e boas prticas, que iro influenciar
diretamente o desenho.

77

17.3 Finalizar o desenho das interfaces de usurio


O desenho de interfaces de usurio abordado em duas disciplinas: a de Requisitos
e a de Anlise e Desenho. Na disciplina de Anlise e Desenho, a criao de
interfaces de usurio j parte integrante do esforo e no ser mais apenas uma
prototipao.

78

18 Visualizando Conceitos com o Modelo de


Domnio
O modelo de domnio amplamente usado no Processo com base na construo de
vrios outros artefatos durante o processo. Ele pode ser entendido com uma
representao visual dos conceitos, quer servira para embasar o desenho do
sistema.

Geralmente, os analistas tem uma formao voltada principalmente para a


construo do banco de dados, atravs do modelo de entidade de relacionamento.
No modelo de domnio, o foco so as classes conceituais. Juntamente com o medelo
de caso de uso, o medelo de domnio so os principais artefatos para as fases
iniciais do processo.

A idia principal do medelo de domnio ser uma representao do mundo real


atravs de classes conceituais. Ele no um conjunto de diagramas descrevendo
classes de software.

Na UML, o modelo de domnio representado como um conjunto de Diagrama de


Classes,onde so representados classes conceituais, sem operaes e com
atributos.

18.1 Adicionando Atributos ao Modelo de Dominio


Ao criar o Modelo de Domnio, devemos tambm identificar aos atributos das classes
conceituais. Atributos ou propriedades contm o estado ou caractersticas de um
objeto. O valor esttico, uma lista de valores ou ainda um valor calculado ou
recuperado de um banco de dados.

79

18.1.1 Identificando atributos


Inclua no Modelo de Domnio os atributos que, segundo os requisitos, devem ser
mantidos por algum perodo. Para identificar os atributos:

Utilize a especificao de caso de uso, outras documentaes, por exemplo, o


glossrio. O proprio texto ir apontar vrios atributos.

Para cada classe, proucure atributos comuns. Por exemplo, toda empresa no Brasil
tem CNPJ, geralmente um aluno tem um nmero de mtricula, um livro tem ISBN,
etc. Atributos contm o estado ou caractersitcas de um objeto.

18.2 Concluses a respeito do Modelo de Domnio


Com todos os recursos que foram vistos nas ltimas sees, podemos dizer que no
existe um unico modelo de domnio que seja correto. Todo os modelos so
aproximaes do que estamos tentando entender. Um bom modelo de domnio
captura abstraes essenciais necessrias para entender o contexto dos requisitos e
ajudar as pessoas a compreenderem os conceitos e relacionamentos.

Existe um longo caminho para que se saa do modelo de domnio e atinja o cdigo.
Em projetos maiores, necessario criar um ou mais modelos mais prximos ao
cdigo, como os modelos de anlise de projeto, antes de atingi-lo. Porm, para
projetos mais simples, o modelo de domnio, poder ser suficiente. Existem vrios
software no mercado que geram cdigo a partir de um modelo de domnio.

Lembre-se, o modelo de domnio est mais prximo ao mundo real do que da


implementao, pois apenas uma representao grfica. Sendo assim, ele no
deve conter aspectos de implementao.

80

19. Anlise de Robustez


A anlise de robustez feita atravs de um diagrama de robustez. Esse diagrama
no existe na UML. Na verdade, ele geralmente um diagrama de colaborao
adaptado e que faz uso de esteretipos, entity, boudary e control.

Processos de softwares, usam o diagrama de robustez para passar da anlise (o


que) para o desenho (o como).

Atravs da anlise de robustez, podemos fazer a verificao se o texto do caso de


uso est correto e que ele especifica um comportamento para o sistema que no
razovel ou impossvel. Podemos ainda verificar se o texto est completo e correto,
como resultado, ser possvel encontrar novas classes que no foram identificadas
durante a criao do Modelo de Domnio.

19.1 Realizando a Anlise de Robustez


A anlise de robustez envolve analisar o texto de cada caso de uso e identificar, de
forma preliminar, o conjunto de objetos que iro participar do caso de uso. Em
seguida, cada objeto classificado segundo um estereotipo (entity, boudary e
control). Percorra cada passo do texto do caso de uso, uma sentena de cada vez,
desenhando os atores, os objetos de fronteira e entidade apropriados, os
controladores e a conexo entre vrios elementos do diagrama. Voc dever ser
capaz de representar todos os fluxos do caso de uso, inclusive os fluxos alternativos,
em um diagrama. As seguintes regras devero se obedecidas:
Atores interagem apenas com objetos de fronteira (boundary)
Objetos de fronteira podem interagir com atores e com controladores

81

Controladores interagem com qualquer outro tipo de objeto e tambm com


outros controladores, mas nunca com atores.

19.2 Anlise de robustez e o Modelo de Domnio


Principais benefcios da anlise de robustez:
Ela fora a escrever casos de uso usando estilo consistente;
Ela fora a escrever casos de uso com a voz de narrao correta;
Ela permite aplicar regras de sintaxe (por exemplo, atores interagem com
objetos de fronteira);
Ela ajuda a dividir os objetos em camadas;
Ela fornece um mecanismo de rastreabilidade entre o que o sistema faz (caso
de uso) e com ele faz (diagrama de seqncia).

82

20 Metodologia de Desenvolvimento de Software


O desenvolvimento de software uma atividade de crescente importncia na
sociedade contempornea. A utilizao de computadores nas mais diversas reas
do conhecimento humano tem gerado uma crescente demanda por solues
computadorizadas.

Entretanto, chega-se a um ponto em que, dado o tamanho ou a complexidade do


problema que se pretende resolver, essa abordagem individual, centrada na
programao no mais indicada. De fato, ela s aplicvel para resolver
pequenos problemas, tais como calcular mdias, ordenar conjuntos de dados etc,
envolvendo basicamente o projeto de um nico algoritmo. Contudo, insuficiente
para problemas grandes e complexos, tais como aqueles tratados na automao
bancria, na informatizao de portos ou na gesto empresarial. Em tais situaes,
uma abordagem de engenharia necessria.

20.1 Processo de Software


Um processo de software pode ser visto como o conjunto de atividades, mtodos,
prticas e transformaes que guiam pessoas na produo de software. Um
processo eficaz deve, claramente, considerar as relaes entre as atividades, os
artefatos produzidos no desenvolvimento, as ferramentas e os procedimentos
necessrios e a habilidade, o treinamento e a motivao do pessoal envolvido.

H vrios aspectos a serem considerados na definio de um processo de software.


No centro da arquitetura de um processo de desenvolvimento esto as atividadeschave desse processo: anlise e especificao de requisitos, projeto, implementao
e testes, que so a base sobre a qual o processo de desenvolvimento deve ser
construdo. Entretanto, a definio de um processo envolve a escolha de um modelo

83

de ciclo de vida, o detalhamento (decomposio) de suas macro-atividades, a


escolha de mtodos, tcnicas e roteiros (procedimentos) para a sua realizao e a
definio de recursos e artefatos necessrios e produzidos.

84

REFERNCIAS BIBLIOGRFICAS
Larman, Craig. Utilizando UML e padres: Uma introduo a analise e ao projeto
orientados a objetos e ao Processo Unificado 2 . ed. Bookman,2004.

Disponvel em: <http:// www.ibm.com> Acesso em: 10 junho. 2011.


ETEG Tecnologia da Informao Ltda xxxxxx ,2010.268p

85