Anexo VI-Metodologia de To de Sistemas-Do ONS

Desenvolvimento de Sistemas
Assunto Concorrência nº 002/09

Anexo VI - Metodologia de Desenvolvimento de Software
DESCRIÇÃO DA METODOLOGIA – MDS
Documento de Referência
MDS - Metodologia de
Desenvolvimento de Software
Rev. Motivo da Revisão Data de Aprovação

N.º pelo ONS
Este documento foi motivado pela necessidade de padronização 18/07/2005
0
da metodologia utilizada para desenvolvimento de sistemas.
DAC/GIT – Gerência de Informática e Telecomunicações 1 de 53

Anexo VI - Metodologia de Desenvolvimento de Software –
DESCRIÇÃO DA METODOLOGIA MDS
1 INTRODUÇÃO ............................................................................................................................ 6
1.1 OBJETIVO .............................................................................................................................. 6
1.2 DEFINIÇÕES, SIGLAS E ABREVIAÇÕES ..................................................................................... 6
1.3 REFERÊNCIAS ........................................................................................................................ 6
1.4 ÍNDICE DESCRITIVO ................................................................................................................ 7
2 VISÃO GERAL DO PROCESSO UNIFICADO .......................................................................... 9
2.1 VISÃO GERAL ......................................................................................................................... 9
2.1.1 Fases do Processo ....................................................................................................... 9
2.1.2 Prototipação................................................................................................................ 10
2.1.3 Fluxos de Trabalho (Seqüências de Atividades) ........................................................ 11
2.1.4 Ciclo de Vida............................................................................................................... 12
2.1.5 Rastreabilidade........................................................................................................... 15
2.1.6 Redução dos Riscos................................................................................................... 16
2.1.7 Melhores Práticas (Uma Reforçando a Outra) ........................................................... 16
2.2 VERIFICAÇÃO NO PROCESSO UNIFICADO ............................................................................... 17
2.3 EXECUTORES DO PROCESSO ................................................................................................ 19
2.3.1 Analista de Sistemas .................................................................................................. 19
2.3.2 Arquiteto ..................................................................................................................... 19
2.3.3 Desenvolvedor............................................................................................................ 19
2.3.4 AD (Administrador de Dados) / DBA (Administrador do Banco de Dados)................ 20
2.3.5 Cliente......................................................................................................................... 20
3 FLUXO DE REQUISITOS......................................................................................................... 21
3.1 CONTEXTO DO FLUXO DE REQUISITOS NAS FASES DO CICLO .................................................. 21
3.1.1 Na Fase de Concepção .............................................................................................. 21
3.1.2 Na Fase de Elaboração .............................................................................................. 21
3.1.3 Na Fase de Construção.............................................................................................. 22
3.1.4 Na Fase de Transição ................................................................................................ 22
3.2 ATIVIDADES DO FLUXO DE REQUISITOS ................................................................................. 22
3.2.1 Identificar o Problema................................................................................................. 22
3.2.2 Analisar o Problema ................................................................................................... 22
3.2.3 Gerar Especificação Funcional................................................................................... 22
3.2.4 Validar Especificação Funcional................................................................................. 23
3.2.5 Planejar Escopo.......................................................................................................... 23
3.3 EXECUTORES DO FLUXO DE REQUISITOS............................................................................... 23
3.4 PRODUTOS GERADOS PELO FLUXO DE REQUISITOS .............................................................. 23
3.4.1 Glossário..................................................................................................................... 23
3.4.2 Definição do Problema ............................................................................................... 23
3.4.3 Documento de Visão .................................................................................................. 23
3.4.4 Especificação dos Casos de Uso (Objetivos e Linhas Gerais) .................................. 24
3.4.5 Diagrama de Casos de Uso ....................................................................................... 24
3.4.6 Protótipo de Interface com o Usuário ......................................................................... 24
3.4.7 Especificação Suplementar ........................................................................................ 24
3.4.8 Termo de Aceite da Especificação Funcional ............................................................ 24
4 FLUXO DE ANÁLISE ............................................................................................................... 25
4.1 CONTEXTO DO FLUXO DE ANÁLISE NAS FASES DO CICLO ....................................................... 25
4.2 ATIVIDADES DO FLUXO DE ANÁLISE ....................................................................................... 26

4.2.1 Refinar Casos de Uso................................................................................................. 26

4.2.2 Definir Classes de Negócio ........................................................................................ 26
4.2.3 Definir Responsabilidades das Operações de cada Caso de Uso em Relação ao
sistema (Contratos do Sistema)................................................................................................ 26
4.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE ANÁLISE ........................................................... 27
4.4 PRODUTOS GERADOS .......................................................................................................... 27
4.4.1 Diagramas de Casos de Uso...................................................................................... 27
4.4.2 Especificação dos Casos de Uso ............................................................................... 27
4.4.3 Especificação Suplementar ........................................................................................ 27
4.4.4 Responsabilidades das Operações de cada Caso de Uso em Relação ao Sistema
(Contratos do Sistema) ............................................................................................................. 28
4.4.5 Termo de Aceite das Responsabilidades das Operações de cada Caso de Uso em
Relação ao Sistema (Contratos do Sistema)............................................................................ 28
5 FLUXO DE PROJETO.............................................................................................................. 29
5.1 CONTEXTO DO FLUXO DE PROJETO NAS FASES DO CICLO ...................................................... 29
5.2 ATIVIDADES DO FLUXO DE PROJETO...................................................................................... 30
5.2.1 Eleger Componentes Arquiteturais Significativos ...................................................... 30
5.2.2 Descrever a Arquitetura de Software ......................................................................... 30
5.2.3 Elaborar Protótipo Arquitetural ................................................................................... 31
5.2.4 Refinar a Arquitetura................................................................................................... 31
5.2.5 Gerar Modelo do Projeto ............................................................................................ 31
5.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE PROJETO.......................................................... 32
5.4.1 Descrição da Arquitetura de Software........................................................................ 32
5.4.2 Protótipo Arquitetural .................................................................................................. 32
5.4.3 Modelo do Projeto....................................................................................................... 33
5.4.4 Modelo Lógico do Banco de Dados............................................................................ 33
6 FLUXO DE IMPLEMENTAÇÃO ............................................................................................... 34
6.1 CONTEXTO DO FLUXO DE IMPLEMENTAÇÃO NAS FASES DO CICLO ........................................... 34
6.2 ATIVIDADES DO FLUXO DE IMPLEMENTAÇÃO .......................................................................... 35
6.2.1 Planejar Integração..................................................................................................... 35
6.2.2 Preparar Ambiente de Desenvolvimento.................................................................... 35
6.2.3 Implementar Componentes de Software .................................................................... 35
6.2.4 Realizar Testes Unitários ........................................................................................... 35
6.2.5 Integrar Componentes ................................................................................................ 36
6.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE IMPLEMENTAÇÃO .............................................. 36
6.4.1 Componentes de Software ......................................................................................... 36
6.4.2 Testes de Unidade...................................................................................................... 36
7 FLUXO DE TESTES ................................................................................................................. 37
7.1 CONTEXTO DO FLUXO DE TESTES NAS FASES DO CICLO ........................................................ 37


7.2 ATIVIDADES DO FLUXO DE TESTES ........................................................................................ 38
7.2.1 Elaborar Plano de Testes do Sistema ........................................................................ 38
7.2.2 Projetar os Testes do sistema .................................................................................... 38
7.2.3 Preparar Infra-estrutura para os Testes de Sistema .................................................. 39
7.2.4 Executar os Testes de Sistema.................................................................................. 39
7.2.5 Executar os Testes de Aceitação de Sistema ............................................................ 39
7.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE TESTES ............................................................ 39
7.4.1 Plano de Testes.......................................................................................................... 39
7.4.2 Roteiro dos Testes...................................................................................................... 39
7.4.3 “Scripts” de Testes...................................................................................................... 39
7.4.4 Resultado dos Testes executados ............................................................................. 39
7.4.5 Testes de Aceitação ................................................................................................... 40
8 FLUXO DE IMPLANTAÇÃO .................................................................................................... 41
8.1 CONTEXTO DO FLUXO DE IMPLANTAÇÃO NAS FASES DO CICLO ............................................... 41
8.2 ATIVIDADES DO FLUXO DE IMPLANTAÇÃO ............................................................................... 42
8.2.1 Elaborar Pano de Entrega .......................................................................................... 42
8.2.2 Desenvolver Material de Suporte ............................................................................... 42
8.2.3 Produzir Versão de Homologação (Versão Beta) ...................................................... 42
8.2.4 Obter Aceitação Formal da Versão ............................................................................ 42
8.2.5 Produzir Versão de Produção .................................................................................... 43
8.2.6 Preparar Treinamento................................................................................................. 43
8.2.7 Estabelecer Infra-estrutura de Suporte ...................................................................... 43
8.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE IMPLANTAÇÃO ................................................... 43
8.4.1 Plano de Entrega ........................................................................................................ 43
8.4.2 Material de Suporte .................................................................................................... 43
8.4.3 Versão de Homologação ............................................................................................ 43
8.4.4 Versão de Produção ................................................................................................... 44
8.4.5 Aceitação de Versão................................................................................................... 44
8.4.6 Treinamento................................................................................................................ 44
8.4.7 Infra-estrutura de Suporte .......................................................................................... 44
9 RECOMENDAÇÕES E OBSERVAÇÕES................................................................................ 45
9.1 FERRAMENTA CASE.............................................................................................................. 45
9.1.1 Ambiente de Desenvolvimento................................................................................... 45
9.1.2 Diagramas UML.......................................................................................................... 46
9.1.3 Automatização dos Testes ......................................................................................... 46
9.1.4 Melhores Práticas ....................................................................................................... 46
10 MODELOS PARA SUPORTE À METODOLOGIA............................................................... 47
11 PRODUTOS RESULTANTES DA METODOLOGIA............................................................ 48
11.1 ARTEFATOS X PAPÉIS ....................................................................................................... 51
12 VALIDAÇÃO E ACEITAÇÃO DE PRODUTOS.................................................................... 53
12.1 LISTAS DE VERIFICAÇÃO ................................................................................................... 53


1 INTRODUÇÃO
1.1 Objetivo
A proposta deste documento é apresentar de forma simples e consolidada a metodologia

de desenvolvimento de sistemas do ONS, visando direcionar as equipes de
desenvolvimento e manutenção de software internas ou externas, constituindo um guia
de referência para os grupos.
O produto deste documento teve como referência o Processo Unificado, que é a parte
conceitual do Rational Unified Process (RUP), produto da Rational Software Corporation.
O Processo Unificado foi idealizado por Ivar Jacobson, Grady Booch, James Raumbaugh
e seus colaboradores, para o desenvolvimento de sistemas orientados a objetos
utilizando a UML.
O RUP, assim como o Processo Unificado, é um “framework” de processo que deve ser
adaptado para atender as exigências das organizações, das áreas de aplicação, e do
desenvolvimento de sistemas de tipos e portes diferentes.
Desta forma, o que se pretendeu neste documento foi, a partir de metodologias de

mercado mundialmente reconhecidas, estabelecer um subconjunto base de processos de
desenvolvimento de software que constituísse uma metodologia padrão preliminar,
seguindo preceitos universais e de forma a permitir sua posterior evolução à medida que
for sendo alcançada maior maturidade na execução de seus processos.
Dependendo da natureza de cada projeto, poderão ser necessárias adaptações desta

metodologia relativamente a características mais específicas, a fim de melhor adequá-la
para um determinado grupo de projetos. Melhorias decorrentes destas adaptações
poderão constituir também uma evolução da metodologia, tornando-a mais apropriada
para novas demandas e realidades.
1.2 Definições, Siglas e Abreviações
CASE Computer Aided Software Engineering (Ferramenta Computacional de Engenharia de

Software)
IDE Integrated Development Environment (Ambiente de Desenvolvimento Integrado)
RUP Rational Unified Process (Processo Unificado da Rational Software Corporation - IBM)
UML Unified Modeling Language (Linguagem de Modelagem Unificada)
1.3 Referências

A relação a seguir, apresenta os documentos que foram referenciados ou utilizados como

referência na elaboração deste documento.
Título do Documento Data N.º Responsável

Referência
Kruchten, Philippe.The Rational Unified Process An 2000 Addison Wesley
Introduction, Second Edition
Object-Oriented Project Management, Student Version 1.4 Rational
Manual University
Rational Unified Process Overview, Student Manual Version 5.5 Rational
University
Leffingwell, Dean; Widrig, Don. Managing Software 1999 Addison Wesley
Requirements
1.4 Índice Descritivo
Este documento está organizado da seguinte forma:
• Capítulo 1 “Introdução” – Apresenta uma visão geral deste documento.
• Capítulo 2 “Visão Geral do Processo Unificado” – Apresenta uma visão geral do

Processo Unificado, das fases e fluxos de trabalho que compõem o ciclo de vida do
projeto.
• Capítulo 3 “Fluxo de Requisitos” – Descreve o fluxo de trabalho relativo à

identificação e especificação de Requisitos, com suas atividades, executores e produtos
gerados, além de contextualizá-lo em cada fase do projeto.
• Capítulo 4 “Fluxo de Análise” – Descreve o fluxo de trabalho referente à Análise e

detalhamento dos requisitos, com suas atividades, executores, produtos gerados e
correspondente contextualização do fluxo em cada fase do projeto.
• Capítulo 5 “Fluxo de Projeto” – Descreve o fluxo de trabalho relativo ao Projeto da

visão de arquitetura da análise, com suas atividades, executores, produtos gerados e
devida contextualização em cada fase do projeto.
• Capítulo 6 “Fluxo de Implementação” – Descreve o fluxo de trabalho de

Implementação da solução analisada e projetada, com suas atividades, executores,
produtos gerados e contextualização em cada fase do projeto.
• Capítulo 7 “Fluxo de Testes” – Descreve o fluxo de trabalho necessário para

verificar se a interação entre objetos e componentes está correta, se a integração de todos
os componentes de software está adequada e se todos os requisitos foram corretamente
implementados, bem como para identificar defeitos e assegurar que estes sejam tratados

antes da entrega do software. Descreve ainda as atividades deste fluxo, executores,

• Capítulo 8 “Fluxo de Implantação” – Descreve o fluxo de trabalho para

Implantação dos produtos de software desenvolvidos, com suas atividades, executores,
• Capítulo 9 “Recomendações e Observações” – Apresenta observações e

recomendações relevantes, relativas à metodologia e ao processo de desenvolvimento de
software, de uma maneira geral.
• Capítulo 10 “Modelos Anexos” – Índice com os modelos dos documentos a serem

gerados, de acordo com a recomendação desta metodologia.
• Capítulo 11 “Produtos Resultantes da Metodologia” - Apresenta a consolidação

dos produtos resultantes da metodologia e a relação entre estes e os perfis técnicos
necessários para sua elaboração.
• Capítulo 12 “Validação e Aceitação de Produtos” – Descreve os critérios que

devem ser considerados na validação e aceitação de produtos e subprodutos do ciclo de
desenvolvimento de software.

2 VISÃO GERAL DO PROCESSO UNIFICADO

2.1 Visão Geral
O Processo Unificado é a parte conceitual do Rational Unified Process (RUP), produto da Rational
Software Corporation.
O RUP, assim como o Processo Unificado, é um framework de processo que deve ser adaptado
para atender às exigências das organizações, das áreas de aplicação, e do desenvolvimento de
sistemas de tipos e portes diferentes.
O Processo Unificado foi idealizado por Ivar Jacobson, Grady Booch, James Raumbaugh e seus
colaboradores, para o desenvolvimento de sistemas orientados a objetos utilizando a UML.
É um processo que segue o modelo iterativo e incremental, apresentando por isto características
mais realistas de desenvolvimento. O sucesso da sua aplicação está na definição das iterações
mais adequadas, que vão produzir as versões intermediárias do sistema, permitindo um melhor
entendimento dos requisitos e do sistema, e minimizando o risco de desvio dos objetivos do
projeto.
No ciclo de desenvolvimento de software com a utilização da metodologia do Processo Unificado,

cada fase terá o número de iterações necessárias para a completude do seu objetivo. A
quantidade de iterações será determinada de acordo com a necessidade, complexidade e
estratégia de abordagem, para os requisitos a serem desenvolvidos.
O fluxo de trabalho se repete a cada iteração, dentro de uma fase, para que uma versão do
software com um conjunto de funcionalidades definidas possa ser entregue, garantindo que o
produto reflete os requisitos solicitados pelo cliente e permitindo que o cliente defina se o sistema
deve ou não ir para a próxima fase.
O ciclo de vida do Processo Unificado pode ser entendido por meio de duas perspectivas
diferentes, porém integradas:
• A perspectiva gerencial, através de uma visão dirigida pelas fases do processo;
• A perspectiva da engenharia (ou do conteúdo), através dos fluxos de trabalho, que são
compostos por seqüências específicas de atividades.
2.1.1 Fases do Processo
Concepção (Inception):
É nesta fase que são entendidos os requisitos funcionais do sistema, o escopo que o sistema deve
atender e as condições delimitadoras deste escopo (contexto do negócio). Nesta fase são
determinados os casos de uso e os principais cenários que irão direcionar as principais questões
de análise e projeto do sistema. Na perspectiva gerencial, são aqui considerados os critérios de
sucesso, a avaliação de risco, a estimativa de recursos necessários e o plano para a fase,
mostrando quais serão os produtos entregues. Na fase de concepção é ainda estudada e
demonstrada uma arquitetura “candidata”, relativa aos principais cenários.

Elaboração (Elaboration):
Na fase de elaboração ocorre o entendimento e descrição completos, dos aspectos funcionais do

sistema, bem como a entrega do protótipo final de interface com o usuário que materializa este
entendimento.
Nesta fase é estabelecido o plano de projeto e definida a sua arquitetura.
As metas da fase de elaboração são a análise do domínio do problema, o estabelecimento da
linha básica da arquitetura, e o desenvolvimento do plano de projeto. Aqui são eliminados os
elementos de risco mais alto para o projeto, em decorrência da maioria dos requisitos do sistema
já ter sido descrita.
Construção (Construction):
Nesta fase é desenvolvido o sistema.

Na fase de Construção, o produto resultante poderá ser utilizado pelo cliente, o que implica na
necessidade da descrição dos critérios de aceitação. Ao final desta fase é decidido se o software,
o ambiente e os usuários estão prontos para se tornarem operacionais.
Transição (Transition):
É a fase em que o sistema é fornecido aos seus usuários finais.
2.1.2 Prototipação
A prototipação é um instrumento poderoso que demonstra parte ou a totalidade dos

comportamentos de um sistema, observáveis externamente. Deve ser utilizada para:
• Obter o retorno em relação a uma solução proposta;
• Constituir um “demo” do domínio do problema;
• Validar requisitos conhecidos;
• Descobrir requisitos desconhecidos.
Ferramentas para prototipação incluem:

• Programas para demonstração;
• Simulações.
A prototipação facilita o entendimento dos comportamentos do sistema e deve ser utilizada,

sobretudo em casos de terceirização de serviços, para:
• Validar e entender requisitos;
• Para provar e entender tecnologias;
• Para reduzir riscos;
• Para formar um entendimento compartilhado;
• Para melhorar estimativas de prazo e custo, tornando-as mais confiáveis;
• Para melhorar a definição de características.
Neste documento estaremos trabalhando com dois tipos distintos de protótipo:

• O protótipo de interface com o usuário;
• O protótipo arquitetural.
Protótipos devem ser construídos cedo, tanto durante a fase de Concepção quanto no início
da fase de Elaboração e sempre antes que todo o sistema (incluindo a sua interface com o

usuário definitiva) esteja analisado, projetado e implementado, já que seus principais propósitos
são estarem aptos a expor e testar a funcionalidade e usabilidade do sistema antes que o projeto
real (ou definitivo) e o desenvolvimento comecem.
A fim de obter esta validação antecipada é necessário levar em conta que um protótipo sempre
terá que ser significativamente mais barato para desenvolver do que o seu correspondente
definitivo, ao mesmo tempo em que tem que incluir as capacidades suficientes para alcançar os
seus objetivos.
Protótipos de interface com o usuário podem ser utilizados pelo analista (e projetista) do
sistema, com vários objetivos, em momentos distintos ou em um determinado momento
escolhido:
• Relativamente à elaboração de casos de uso, para entender a interface com o usuário
referente a um caso de uso;
• Relativamente à análise de objetos, para entender como a interface com o usuário
influencia a análise do sistema;
• Relativamente ao projeto, para entender como a interface com o usuário impacta o
sistema e o que ela requer do lado “interno” do sistema;
• Relativamente aos testes das classes, para planejar as atividades de teste.
O protótipo arquitetural ocorre normalmente em menor número que os protótipos de interface

com o usuário e tem um caráter menos descartável do que estes. Ele é utilizado pelo arquiteto
para validar e aprovar as principais decisões arquiteturais e é, geralmente, a base para evolução
visando a arquitetura definitiva.
2.1.3 Fluxos de Trabalho (Seqüências de Atividades)
Fluxo de Requisitos (Requirements):

Descreve o método para a identificação dos requisitos, baseado em casos de uso.
Fluxo de Análise (Analysis):

Descreve a visão de arquitetura com ênfase em “O Quê” vai ser feito.
Fluxo de Projeto (Design):

Descreve a visão de arquitetura com ênfase em “Como” será feito.
Fluxo de Implementação (Implementation):

Considera o desenvolvimento do software, o teste de unidade e a integração.
Fluxo de Teste (Test):

Descreve os casos de teste, os procedimentos e as medidas para acompanhamento de erros.
Fluxo de Implantação:
Descreve os procedimentos para implantar o software no ambiente desejado.

2.1.4 Ciclo de Vida
A seqüência das quatro fases constitui o ciclo de vida do Processo Unificado sendo que o primeiro
ciclo de realização das quatro fases resulta na primeira versão do software.
A menos que o produto não tenha continuidade, os próximos ciclos se repetem com a mesma
seqüência das fases, mas com ênfases diferentes, dependendo das novas versões. Estes ciclos
subseqüentes são chamados de ciclos evolutivos.
À medida que o produto evolui através de iterações dos ciclos, novas versões são produzidas.
Esta evolução organiza o processo na dimensão tempo.
A figura a seguir reflete o processo de evolução através dos ciclos evolutivos:
Concepção
Concepção Elaboração
Elaboração Construção
Construção Transição
Transição Evolução
Evolução
Tempo Versão 1
Ciclo de desenvolvimento inicial
Concepção
Evolução
Tempo Versão 2
Ciclo de evolução 1
Concepção
Evolução
Tempo Versão n...

Ciclo de evolução n...
As iterações ocorrem relativamente ao ciclo como um todo, conforme apresentado na figura

anterior, bem como dentro de cada fase do ciclo, para grupos de casos de uso específicos e
componentes correspondentes.
Um ciclo de desenvolvimento típico tem três níveis de complexidade e, para cada nível, existe a
sugestão da quantidade de iterações que devem existir.
É importante lembrar que estas quantidades são apenas para referência e que a real quantidade
de iterações por fase, em um projeto, vai depender de suas características particulares e da
decisão dos seus participantes. De um modo geral, a fase de construção tem “n” iterações.

O quadro seguinte constitui a referência para a quantidade de iterações por ciclo de

desenvolvimento e de iterações por fase do ciclo:
Ciclo iterativo Total de iterações Número de iterações

em um ciclo por fase [C, E, C, T]
Baixo 3 [0, 1, 1, 1]
Típico 6 [1, 2, 2, 1]
Alto 9 [1, 3, 3, 2]
Pela perspectiva da engenharia (ou do conteúdo), os fluxos de trabalho atravessam as

diferentes fases do ciclo e são repetidos para cada iteração, dentro de cada fase.
A figura seguinte apresenta a interseção entre as fases e os fluxos de trabalho do processo:
Organização com base no Tempo

Fases
Fluxos de Trabalho
Organização com base no Conteúdo
do Processo: Concepção Elaboração Construção Transição
Modelagem do
Negócio
Requerimentos Co
mp
le me
Análise e Projeto nt arie
d ade
Implementação
Testes
Implantação
Iterações Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Preliminares #1 #2 #n #n+1 #n+2 #m #m+1
Iterações
O fluxo de atividades relativo à Modelagem do Negócio e os fluxos gerenciais relativos ao

Gerenciamento do Projeto e ao Gerenciamento de Configuração e Versão, não estão sendo
considerados nesta versão.

Outra modificação em relação à figura anterior e adotada neste documento diz respeito ao fluxo de
trabalho de Análise e Projeto. Neste documento, o referido fluxo foi desmembrado em dois fluxos
separados, o Fluxo de Análise e o Fluxo de Projeto, a fim de deixar mais clara a diferença que
existe entre as atividades e artefatos de análise e de projeto. Enquanto no primeiro a preocupação
é com “o Quê” o sistema vai fazer, no segundo esta preocupação está voltada para “Como” o
sistema fará aquilo que foi identificado que teria que fazer. A separação em dois fluxos torna clara
esta fronteira, facilitando o entendimento dos objetivos das suas atividades.
Pode ser observado, através da figura acima, que os fluxos de trabalho têm maior ênfase em
momentos diferentes. O nível de atividade de cada um deles é maior em uma ou mais fases do
processo.
Assim, pode-se notar que o fluxo de Requisitos tem maior ênfase nas fases de Concepção e de
Elaboração, da mesma forma que o fluxo de Implementação tem maior ênfase na fase de
Construção e o de Implantação na fase de Transição.
Podemos verificar também que os fluxos de trabalho são complementares (ou incrementais)
quanto ao conteúdo e que, se traçarmos uma linha reta diagonal imaginária, unindo as partes de
maior atividade de cada fluxo, obtemos uma idéia muito próxima de como o produto do trabalho
(ou seu conteúdo) é incrementado no tempo, por meio dos fluxos de trabalho e através das fases.

2.1.5 Rastreabilidade
Uma característica importante deste processo é a capacidade de rastreabilidade que o processo

permite, desde as demandas iniciais dos clientes até aos componentes de software criados para
constituir a aplicação.
Os modelos criados não são estanques e influenciam-se mutuamente para agregar valor e refletir
a evolução do sistema, conforme mostrado na figura a seguir:
Definição do
Problema
Espaço
Espaçodo
do
Problema
R
as Problema
tr
Necessidades
ea
Documento
bi
de Visão Características
li
Requisitos de Software
da
de
Espaço da
Modelo de Solução
Casos de Uso
Modelo de
Análise e Projeto
Modelo de Modelo de
Testes Implementação
Assim, o processo permite estabelecer que cada necessidade tem características específicas, que
cada uma destas características demanda um conjunto específico de requisitos que, por sua vez,
são representados pelo modelo de casos de uso.
Cada caso de uso tem sua “realização” correspondente no modelo de análise e projeto, tem seus
artefatos correspondentes no modelo de testes e tem relação com os componentes específicos
que o implementam, no modelo de implementação.
O processo tem que ser dirigido pelos casos de uso (que constitui a visão dos requisitos por parte
do usuário) mas, conforme pode ser observado na figura anterior, todos os modelos têm que ter
relação de rastreabilidade entre si.

2.1.6 Redução dos Riscos
Talvez a característica mais importante do conceito do processo unificado seja a redução

significativa do risco, a partir da utilização do seu processo de desenvolvimento, quando
comparado aos processos de desenvolvimento lineares, em cascata (waterfall) ou em espiral.
O fato de ser iterativo, incremental e baseado em componentes, permite ao conceito do processo

unificado antecipar as principais decisões do projeto, antecipando também as ações de resposta
às incertezas, conforme mostrado na figura a seguir:
Desenvolvimento Waterfall
Diminuição dos Riscos:
Desenvolvimento Iterativo
Redução do Risco
RISCO
Melhor entendimento dos requisitos e do sistema
PRAZO
2.1.7 Melhores Práticas (Uma Reforçando a Outra)
O processo unificado permite a utilização das principais melhores práticas para desenvolvimento
de software. No caso das melhores práticas apresentadas a seguir, o todo é maior que a soma
das partes já que cada melhor prática reforça o uso e valor obtido pela seguinte e, em alguns
casos, é pré-requisito para a sua existência.
Melhores Práticas
Desenvolver Iterativamente
Gerenciar Requisitos Assegurar o envolvimento do usuários em

toda a evolução dos requisitos
Usar Arquitetura de Componentes Validar decisões arquiteturais cedo no ciclo

de vida do sistema
Modelar Visualmente (UML) Tratar incrementalmente a complexidade de

projeto e implementação
Verificar Continuamente a Qualidade Medir a qualidade muitas vezes e desde

cedo no ciclo de vida do sistema
Gerenciar Mudanças Evoluir as bases de referência de forma

incremental

2.2 Verificação no Processo Unificado
O desenvolvimento iterativo permite que a equipe de desenvolvimento melhore o entendimento

dos requisitos e dos artefatos, através dos incrementos ou versões, detectando, no início do
projeto, os pontos crucias.
O Processo Unificado, da mesma forma que os demais modelos de processo, prevê pontos de
verificação ao longo do desenvolvimento do software, para manter a qualidade do processo e do
produto.
Ao final da fase de concepção, são respondidas as seguintes questões:

• O escopo do sistema está claro?
• Os requisitos chaves do sistema foram acordados com os participantes?
• Foram identificados os riscos críticos para a execução e sucesso do projeto?
• O produto irá gerar o retorno esperado pelo investimento?
• É válido para a organização continuar com o projeto?
• Os investidores concordam com os objetivos?
O final da fase de elaboração fornece as informações sobre a arquitetura e, portanto, as

seguintes perguntas têm que ser respondidas:
• Existe uma arquitetura de componentes que possa implementar esta
funcionalidade?
• Foi criada uma linha base de arquitetura capaz de atender a funcionalidade proposta?
Esta linha base é robusta? É passível de evolução através do ciclo de vida do produto?
• Os riscos foram identificados e minimizados?
• Foi criado um plano realista de projeto que permita cumprir o cronograma, o custo e a
qualidade?
• O projeto irá fornecer um retorno adequado ao investimento?
A fase de construção estabelece se o produto atende a capacidade operacional inicial e,

portanto, as seguintes perguntas têm que ser respondidas:
• O produto atingiu a estabilidade operacional que permita uma versão para teste beta
no ambiente do usuário?
• Os usuários e os projetistas estão satisfeitos com o sistema?
• Os pré-requisitos do sistema foram atendidos através da seqüência de iterações?
A fase de transição estabelece se o produto está pronto e se a versão final estará disponível para
a comunidade de usuários. Portanto, as seguintes perguntas têm que ser respondidas:
• O produto passou pelo teste de aceitação conduzido pelo usuário?
• Os usuários testaram as funções chave, representadas nos casos de uso?
• A documentação a ser entregue para o usuário tem qualidade aceitável?
• O cliente e usuários estão satisfeitos com o produto?

A seguir estão relacionados os pontos principais a serem observados durante as fases:
• Obter os requisitos de forma correta, através dos modelos de caso de uso e de análise,
bem como a partir da realimentação dos usuários, clientes e da equipe de
desenvolvimento.
• Montar a arquitetura correta, permitindo que o sistema possa ser dividido, de tal forma que
os projetistas possam trabalhar de forma independente.
• Utilizar componentes que permitam a construção de blocos reutilizáveis que possam

reduzir o custo de desenvolvimento, diminuir o tempo de entrega do produto e aumentar a
qualidade.
• Utilizar a UML para a elaboração dos artefatos e para comunicação entre os integrantes
da equipe de projeto, de forma a estabelecer um padrão de comunicação para a equipe, já
que a UML é uma linguagem que representa o software nos diversos estágios do
desenvolvimento.
• Basear o desenvolvimento em iterações, em função de seus produtos oferecem

vantagens, tais como a possibilidade do trabalho ser realizado por um grupo pequeno,
com risco controlado e pontos de verificação e avaliações freqüentes.
• Gerenciar os riscos, identificando-os, analisando-os e realizando os planos de resposta

decorrentes, visando sua mitigação, transferência, contingência ou aceitação, antes que
possam aparecer no processo de desenvolvimento de software.

2.3 Executores do Processo
A fim de obter um processo bem adaptado às estruturas mais comumente existentes nos projetos
de desenvolvimento de sistemas, foi identificado um grupo reduzido de executores, os quais
participarão das diversas atividades de desenvolvimento dos artefatos (produtos) associados a
cada fluxo de trabalho desta metodologia.
Estes executores não traduzem cargos ou funções dos profissionais expressando, apenas, os
papéis que estes profissionais irão desempenhar em determinados momentos do ciclo do projeto e
de acordo com as atividades do fluxo que estiver sendo trabalhado.
A descrição dos papéis, a seguir apresentada, deve ser vista como uma orientação sobre as
habilidades ou perfis técnicos necessários às responsabilidades associadas a estes papéis.
Estas habilidades (ou perfis técnicos) estão identificadas sob o prisma dos integrantes da equipe
desenvolvedora do sistema.
Dentro deste contexto, por exemplo, um usuário (ou qualquer outro profissional) que atue na
especificação de requisitos estará desempenhando o papel de analista de sistemas.
Ainda em relação ao conceito de papel como habilidades ou perfis técnicos necessários, convém
salientar que, da mesma forma que seus fluxos correspondentes, nesta versão, os perfis técnicos
relativos às atividades dos fluxos para Modelagem do Negócio, Gerenciamento do Projeto e
Gerenciamento de Configuração e Versão, não estão considerados. Os papéis referentes às
habilidades necessárias para desempenhar as atividades destes fluxos seriam, respectivamente, o
analista/projetista de negócios (ou solução), o gerente de projetos e o gerente de configuração.
2.3.1 Analista de Sistemas
O Analista de Sistemas lidera e coordena a captura dos requisitos e a modelagem dos Casos de
Uso, delimitando e definindo as linhas gerais das funcionalidades do Sistema.
2.3.2 Arquiteto
O Arquiteto lidera e coordena as atividades e artefatos técnicos ao longo do projeto,

estabelecendo a estrutura completa para cada visão da arquitetura, decompondo a visão e
agrupando os elementos e as interfaces, entre estes e as principais decisões da arquitetura do
sistema.
2.3.3 Desenvolvedor
Desenvolve e testa componentes de acordo com os padrões adotados para o desenvolvimento do

sistema. Quando estes forem testados, outros componentes para suporte aos testes também
serão criados. Ele também poderá ajustar as classes, com suas respectivas operações, atributos e
relacionamentos, desde que isto não comprometa a arquitetura.

2.3.4 AD (Administrador de Dados) / DBA (Administrador do Banco de Dados)
O AD, ou o DBA de acordo com a política que seja estabelecida, define as tabelas, índices,
“constraints”, “triggers”, “stored procedures”, “tablespaces” e parâmetros de armazenamento, entre
outras necessidades específicas da construção de banco de dados.
Geralmente o AD está voltado para as atividades da parte lógica dos dados e o DBA para a parte
física e de implementação do banco.
2.3.5 Cliente
Dirige e formaliza os testes de validação e aceitação do sistema.

3 FLUXO DE REQUISITOS
Descreve o método para a identificação dos requisitos, baseado em casos de uso, sendo que os
modelos de referência (templates) para os documentos a serem utilizados, são encontrados no
capítulo 10 MODELOS PARA SUPORTE À METODOLOGIA.
3.1 Contexto do Fluxo de Requisitos nas Fases do Ciclo
Todas as atividades do fluxo de Requisitos são executadas em todas as fases, tendo maior
ênfase em questões específicas (o processo é iterativo e incremental), conforme relacionado a
seguir e de acordo com a fase em que o desenvolvimento se encontra no ciclo de vida do projeto.
A figura seguinte apresenta o contexto do fluxo de requisitos, nas fases do ciclo de vida do
sistema, mostrando as questões que têm maior ênfase em cada uma das fases:
Concepção Elaboração Construção Transição
• Estabeleci-
mento da
visão do
usuário em
relação ao • Entendimento
problema; completo e
descrição dos
• Delimitação aspectos
do escopo do funcionais do
projeto do sistema;
sistema de • Protótipo
software; Final de
• Revisão dos
• Protótipos Interface com o
requisitos; • Ajuste fino
iniciais de Usuário;
• Mudanças de dos artefatos
Interface com do fluxo de
o Usuário; Requisitos;
requisitos
• WBS do “revisitados”.
Produto.
3.1.1 Na Fase de Concepção
Nesta fase, o fluxo de trabalho Requisitos está centrado em estabelecer a visão do problema, por
parte do usuário, bem como em entender os requisitos funcionais e estabelecer a delimitação do
escopo do projeto do sistema de software.
3.1.2 Na Fase de Elaboração
Nesta fase, o objetivo é obter o mais completo entendimento dos aspectos funcionais do sistema,
através de sua respectiva descrição.

3.1.3 Na Fase de Construção
Nesta fase, alguns requisitos podem ser revistos ou podem, ainda, ser identificados novos
requisitos. De qualquer forma, estes novos requisitos podem significar alteração no escopo do
sistema e têm que ser formalmente tratados e associados.
3.1.4 Na Fase de Transição
Aqui os artefatos do fluxo de Requisitos são novamente “visitados” e poderão ainda ocorrer
pequenos ajustes (ajustes finos).
3.2 Atividades do Fluxo de Requisitos
3.2.1 Identificar o Problema
Identificar o contexto do problema a ser resolvido. Definir as fronteiras do sistema e identificar a

quais restrições preliminares o sistema estará sujeito. Estes aspectos serão capturados utilizando
o documento de definição do problema.
3.2.2 Analisar o Problema
Identificar os colaboradores, envolvidos ou interessados (stakeholders) do projeto, conseguir

consenso das partes envolvidas em relação ao problema a ser resolvido, definir as fronteiras do
sistema e identificar a quais restrições o sistema estará sujeito. Estes aspectos são capturados
utilizando o documento de visão e o documento de especificação suplementar.
3.2.3 Gerar Especificação Funcional
Os requisitos funcionais são capturados de diversas formas (documentos já existentes,

entrevistas, visitas ao ambiente dos usuários, reuniões de JAD, eventuais protótipos preliminares
de interface com o usuário, etc.) por meio da utilização do documento de visão e são consolidados
na visão padronizada de Casos de Uso que reflete a visão funcional das partes interessadas
(stakeholders).
Para esta visão são identificados os atores, os casos de uso, seus objetivos e linhas gerais de
execução. As eventuais saídas (como o formato esperado de um relatório), telas de acesso,
regras de negócio e elementos de dados, também são capturados e registrados.
A especificação de cada caso de uso é composta das seguintes partes:

• Descrição do caso de uso;
• Interface com usuário;
• Regras de negócio e dados, onde as regras de negócio e os dados que sejam comuns a
mais de um caso de uso são capturados em um único documento para todo o sistema;
• Especificação suplementar contendo os requisitos não funcionais, além dos requisitos
funcionais que sejam comuns a mais de um caso de uso.
Deve ser realizada a prototipação da interface gráfica com o usuário, a fim de capturar, entender e
validar seus requisitos.

Tanto a descrição de cada caso de uso quanto a sua interface correspondente são documentadas
em conjunto, em um documento por caso de uso, a fim de facilitar a sua manipulação por mais de
uma pessoa.
3.2.4 Validar Especificação Funcional
As especificações funcionais levantadas são validadas junto às partes interessadas

(stakeholders), através das especificações e dos protótipos de interface com o usuário, a fim de
garantir a aderência em relação às impressões iniciais consolidadas, garantindo que estejam
corretas e possibilitando que dirijam o restante do desenvolvimento do sistema. O aceite terá que
ser formalizado em documento apropriado.
3.2.5 Planejar Escopo
O planejamento do prosseguimento do projeto é realizado através da decomposição do escopo

em pacotes de trabalho (WBS do produto), os quais irão compor os produtos a serem entregues,
de acordo com o plano do projeto.
3.3 Executores do Fluxo de Requisitos
Os executores das atividades do fluxo de Requisitos estarão desempenhando o papel de:

• Analistas de Sistemas;
• Desenvolvedores.
3.4 Produtos Gerados Pelo Fluxo de Requisitos
3.4.1 Glossário
Documento que define e esclarece os principais termos utilizados no projeto, possibilitando uma
única definição, independentemente de pessoa ou área específica. Observar que o glossário será
preenchido e consultado ao longo de todo o projeto.
3.4.2 Definição do Problema
Documento que visa contextualizar o problema e registrar e formalizar as necessidades dos

usuários.
3.4.3 Documento de Visão
O documento de visão expressa a visão geral dos requisitos do projeto, fornecida pelo cliente,
provendo as bases contratuais para os requisitos técnicos mais detalhados.

3.4.4 Especificação dos Casos de Uso (Objetivos e Linhas Gerais)
O propósito deste documento é descrever os objetivos do Caso de Uso (um ou, no máximo, dois
parágrafos) e os principais passos de execução, na forma de tópicos.
3.4.5 Diagrama de Casos de Uso
Representação gráfica dos casos de uso e atores identificados, agrupados em pacotes (grupos de
casos de uso de mesma categoria) para facilitar a compreensão.
3.4.6 Protótipo de Interface com o Usuário
Um ou mais protótipos de interface com o usuário contendo, dependendo do detalhamento de

requisitos existente, apenas o desenho das telas, as telas e navegação correspondente ou, ainda,
as telas, navegação e algumas regras de negócio específicas, de acordo com aquilo que se
deseja identificar e validar.
Quanto mais cedo é realizado um protótipo mais riscos são eliminados. Por outro lado, há que se
levar sempre em conta que, embora importante, um protótipo tem que ser sempre
significativamente mais barato e fácil de construir que seu correspondente definitivo e que, quanto
mais cedo ele é realizado maior é seu caráter descartável.
3.4.7 Especificação Suplementar
Este documento registra os requisitos do sistema que não foram possíveis capturar de maneira
clara nas descrições dos casos de uso, ou que envolvem mais que um caso de uso do sistema.
Este documento possui:
• Requisitos legais, regulamentos e padrões que devam ser utilizados na aplicação.
• Atributos de qualidade do sistema a ser construído, incluindo usabilidade, performance e
requisitos de suporte.
• Outros requisitos como sistema operacional, ambientes de operação, requisitos de
compatibilidade e restrições de projeto.
• Regras de negócio do sistema comuns a mais de um caso de uso.
3.4.8 Termo de Aceite da Especificação Funcional
Documento que formaliza o aceite da especificação funcional, por parte do cliente, constituída pelo
conjunto de produtos anteriormente descritos para este fluxo de trabalho.

4 FLUXO DE ANÁLISE
Este fluxo de trabalho descreve a visão de arquitetura, com foco “No Que” deve ser feito e realiza
o detalhamento dos requisitos, sendo que os modelos de referência (templates) para os
documentos a serem utilizados, encontram-se relacionados no capítulo 10 MODELOS PARA
SUPORTE À METODOLOGIA.
4.1 Contexto do Fluxo de Análise nas Fases do Ciclo
Todas as atividades do fluxo de Análise são executadas na maioria das fases, tendo maior
ênfase em questões específicas (o processo é iterativo e incremental), conforme relacionado a
seguir e de acordo com a fase em que o desenvolvimento se encontra no ciclo de vida do sistema.
A figura seguinte apresenta o contexto do fluxo de análise, nas fases do ciclo de vida do sistema,
mostrando as questões que têm maior ênfase em cada uma das fases:
• Modelagem
preliminar • Entendimento
das classes do sistema o
de negócio mais completo
(visão possível;
estática); • Classes de
Negócio e
Associações;
• Contratos do • Ajustes no
sistema; modelo;
• Análise inicial
• Reflexão das
para o
mudanças de
protótipo
requisitos no
arquitetural;
modelo;
O foco, nesta fase, é a modelagem do modelo preliminar das classes de negócio identificadas
para o sistema (visão estática do modelo). Este documento considera que esta modelagem
constitui apenas uma representação das classes de negócio, a partir de processos de negócio do
ONS que já se encontram definidos e modelados.
O modelo de classes de negócio será útil no desenvolvimento dos diagramas de classes, no

eventual projeto de “workflows” e em outras partes do projeto do sistema.

Nesta fase, o entendimento do sistema tem que ser o mais completo possível (requisitos bem
detalhados) considerando: O esclarecimento sobre o que o sistema deve fazer; O registro do
conjunto de classes de negócio e suas associações; A análise das responsabilidades das
operações de cada caso de uso em relação ao sistema (contratos do sistema); A análise inicial do
protótipo arquitetural.
Nesta fase, as atividades de análise são de ajustes no modelo. Contudo, eventuais demandas
(novas funcionalidades, solicitações de mudanças etc.) são também registradas nesta fase.
Observar que alterações ou ampliações do escopo do sistema têm que ser formalmente tratadas,
para minimizar riscos de não cumprimento do plano do projeto.
4.2 Atividades do Fluxo de Análise
4.2.1 Refinar Casos de Uso
Os casos de uso são investigados profundamente para que se tenha todo o seu fluxo principal,
fluxos alternativos, além das pré e pós-condições para a execução do caso de uso. Há que se
observar que novos casos de uso podem surgir, assim como casos de uso podem deixar de
existir, visto que, com o aprofundamento do entendimento, o modelo estará plenamente sujeito a
este tipo de comportamento.
4.2.2 Definir Classes de Negócio
As classes de negócio do sistema são definidas de acordo com os elementos de dados que
tiverem sido capturados nos casos de uso. São identificadas: a estrutura de herança, associações
entre as classes, seus respectivos papéis nestas associações, assim como eventuais tipos de
dados específicos do domínio em questão.
Para clareza e objetividade do modelo, as classes são organizadas em pacotes, estando

agrupadas de acordo com critérios definidos pela equipe de desenvolvimento. Desta forma, não é
recomendado um grande diagrama com todas as classes do sistema, mas sim vários pequenos
diagramas.
4.2.3 Definir Responsabilidades das Operações de cada Caso de Uso em

Relação ao sistema (Contratos do Sistema)
Para cada caso de uso, são identificadas as suas operações e o que cada operação se
compromete a gerar como resultado, com foco na descrição das suas responsabilidades em
relação ao sistema como um todo, considerando o que o sistema deve fazer (visão caixa preta) e
não como estas responsabilidades serão resolvidas.
Para cada caso de uso, o sistema é visto como “um grande objeto” que recebe os seus estímulos
e respectivos parâmetros. Esta identificação é representada através de um diagrama de seqüência

de sistema, composto basicamente de uma instância de cada ator, um objeto representando o

sistema e as operações que envolvem o caso de uso.
Cada operação identificada possui um “contrato de responsabilidades” em relação ao sistema, que

especifica e descreve o seu resultado, sendo expresso em termos de pré e pós-condições. A pré-
condição apresenta o estado do sistema antes da execução da operação e a pós-condição
apresenta o estado do sistema após a execução da operação, descrevendo quais os objetos e as
ligações que serão criadas, destruídas e modificadas, bem como os resultados que terão que ser
retornados.
Observação: O uso da especificação das responsabilidades das operações de cada caso de uso
em relação ao sistema (contratos de sistema) é proposto por alguns métodos de desenvolvimento
baseados em componentes, como “Catalysis” e “UML Components”, e tem por objetivo definir o
que o sistema deve fazer.
4.3 Executores das Atividades do Fluxo de Análise
Os executores das atividades do fluxo de trabalho de Análise estarão desempenhando o papel de:
• Analistas de Sistemas.
4.4 Produtos Gerados
4.4.1 Diagramas de Casos de Uso
Representação gráfica dos casos de uso e dos atores identificados, agrupados em pacotes
(grupos de casos de uso de mesma categoria) para facilitar a compreensão.
4.4.2 Especificação dos Casos de Uso
Documento que contém a especificação completa do caso de uso, identificando seu objetivo, fluxo
principal, fluxos alternativos, atores, regras de negócio específicas deste caso de uso e suas pré e
pós-condições.
4.4.3 Especificação Suplementar
Este documento registra requisitos não funcionais do sistema ou requisitos funcionais que
envolvam mais de um caso de uso do sistema. Este documento será preenchido à medida que os
requisitos forem detalhados, esclarecendo as regras do negócio em questão. Ele é decomposto
em:
• Requisitos legais, regulamentos e padrões que devam ser utilizados na aplicação.
• Atributos de qualidade do sistema a ser construído, incluindo usabilidade, performance e
requisitos de suporte.
• Outros requisitos como sistema operacional, ambientes de operação, requisitos de
compatibilidade e restrições de projeto.
• Regras de negócio do sistema comuns a mais de um caso de uso ou para o sistema como
um todo.

4.4.4 Responsabilidades das Operações de cada Caso de Uso em Relação ao

Sistema (Contratos do Sistema)
Documento que formaliza as responsabilidades de cada operação identificada. É constituído pelo

nome da operação e respectivos parâmetros, a referência cruzada com o caso de uso, as pré e
pós-condições.
O preenchimento das pós-condições restringe-se ao vocabulário do modelo estático, ao invés de

descrever o algoritmo, informando-se o estado do sistema resultante da operação.
Neste documento também tem que constar o diagrama de seqüência do sistema, representando
as operações de cada caso de uso e tendo o sistema como um único objeto que recebe os
estímulos dos atores.
4.4.5 Termo de Aceite das Responsabilidades das Operações de cada Caso de

Uso em Relação ao Sistema (Contratos do Sistema)
Documento que formaliza o aceite das responsabilidades das operações de cada caso de uso em
relação ao sistema (contratos do sistema), por parte do cliente.

5 FLUXO DE PROJETO
Descreve a visão de arquitetura, voltada para “Como” as operações do sistema serão resolvidas,
garantindo a definição da arquitetura a ser utilizada antes de ser iniciada a construção. Os
modelos de referência (templates) para os documentos a serem utilizados encontram-se
relacionados no capítulo 10 MODELOS PARA SUPORTE À METODOLOGIA.
5.1 Contexto do Fluxo de Projeto nas Fases do Ciclo
Todas as atividades do fluxo de Projeto são executadas na maioria das fases, tendo maior
ênfase em questões específicas, conforme relacionado a seguir e de acordo com a fase em que o
desenvolvimento se encontra no ciclo de vida do sistema.
A figura seguinte apresenta o contexto do fluxo de projeto, nas fases do ciclo de vida do sistema,
• Eleição
preliminar
dos casos de
uso para o
protótipo
arquitetural; • Projeto e
• Eventual validação da
antecipação arquitetura;
de alguns • Protótipo
aspectos da arquitetural
arquitetura, que
em razão de implemente e
riscos; valide as
decisões de • Complementação
• Primeiras projeto mais e evolução do
restrições / importantes; modelo
definições
arquitetural;
para a
arquitetura;
Este fluxo de trabalho fará uma eleição preliminar dos casos de uso para o protótipo arquitetural e
capturará as primeiras restrições e/ou definições com influência significativa na arquitetura, como
por exemplo, a determinação do uso de uma tecnologia.
Dependendo do contexto, do grau de incerteza e dos riscos associados ao sistema que será
desenvolvido, pode ser necessária a antecipação de alguns aspectos da arquitetura para a fase de
concepção, de maneira a tentar reduzir os riscos associados ao sistema. Neste caso, a fase de
concepção, torna-se, naturalmente, um pouco mais longa.

Nesta fase, este fluxo de trabalho vai construir a arquitetura e validá-la. Há que se observar que a
arquitetura só é considerada completa, com a construção de um protótipo arquitetural, que
implemente as mais importantes decisões de projeto e que seja suficiente para validá-las. Nesta
fase, a construção da arquitetura inclui, também, a elaboração do modelo de dados lógico.
Nesta fase, o modelo do projeto será complementado à medida que o sistema for sendo
construído, representando os detalhes encontrados ao longo da evolução do projeto.
5.2 Atividades do Fluxo de Projeto
5.2.1 Eleger Componentes Arquiteturais Significativos
A partir do conjunto de casos de uso, são eleitos os aspectos que sejam mais relevantes para a
tomada de decisão, do ponto de vista da arquitetura. Estes aspectos relevantes irão traduzir-se em
uma implementação real da decisão tomada, através da implementação de um conjunto
significativo de casos de uso, conforme descrito a seguir.
Para ilustrar, dentro de um conjunto de casos de uso com necessidade de interface com o usuário,
do tipo “mestre-detalhe” (estrutura clássica onde uma série de elementos dependem de um
elemento único, como em nota fiscal e seus itens), sob o ponto de vista da arquitetura, bastaria
escolher um. Os casos em que houvesse necessidade de comunicação com um hardware
específico, ou com um outro sistema ainda não construído, seriam também bons candidatos.
5.2.2 Descrever a Arquitetura de Software
Como um sistema é mais do que a soma de suas partes e do que a sucessão de decisões táticas
tomadas de maneira independente, a arquitetura tem que prover uma unificação coerente da
estrutura do sistema, organizando as partes sistematicamente e providenciando regras sobre
como escalar o sistema sem que sua complexidade se multiplique. Com isto, é possível prover
uma base para reuso em larga escala, bem como dar suporte ao gerenciamento do projeto. O
documento de visão e a especificação suplementar têm já que conter algumas restrições
arquiteturalmente significativas que, em conjunto com as descrições dos casos de uso,
constituirão as principais entradas para a descrição da arquitetura.
A descrição geral da arquitetura do sistema será ser feita de acordo com o modelo 4 + 1 visões.
Este modelo determina que a arquitetura deve ter uma abordagem obrigatória – visão do usuário –
e quatro outras visões opcionais de acordo com a natureza do sistema – Visão Lógica, Visão de
Implementação, Visão de Processo e a Visão de Implantação.
Visão do Usuário – Lista dos casos de uso ou cenários que representem funcionalidades
significativas e centrais do sistema final, ou que tenham uma grande cobertura arquitetural, isto é,
que exercitem vários elementos de arquitetura, exijam intensamente ou exemplifiquem pontos
arquiteturais delicados.

Visão Lógica – Descreve as partes arquiteturais significativas do modelo de projeto,

apresentando classes significativas e a descrição de suas responsabilidades, assim como
importantes relacionamentos, operações e atributos.
Visão de Processo – Descreve a decomposição do sistema em processos simples (simples

“threads” de controle – “thread”: parte de um programa que pode ser executada
independentemente de outras partes) e processos pesados (agrupamento de processos), que
formam os mecanismos de concorrência e sincronismo do sistema, incluindo os principais modos
de comunicação entre os processos, como as interrupções ou passagem de mensagens. Aborda
também questões de desempenho e escalabilidade.
Visão de Implementação – descreve de maneira abrangente o modelo de implementação, a

decomposição do software em camadas e subsistemas, além de componentes arquiteturais
significativos.
Visão de Implantação - Descreve uma ou mais configurações de redes físicas, mostrando como
os vários elementos do software (executáveis e outros componentes considerados em tempo de
execução) serão implantados e executados entre as plataformas e computadores, podendo existir
referência aos processos que foram mapeados na visão de processos.
A descrição geral da arquitetura irá ainda considerar as estratégias de tratamento dos

mecanismos gerais, tais como: persistência, tratamento de exceções, distribuição, interface com o
usuário e comunicação com outros sistemas.
A arquitetura é mais do que um planejamento do sistema que será desenvolvido. Para validar a
arquitetura e atestar suas qualidades em termos de performance, flexibilidade e robustez, tem que
ser criado um protótipo arquitetural não descartável, que aplique todas as decisões registradas
e que evolua para o sistema final.
5.2.3 Elaborar Protótipo Arquitetural
O protótipo da arquitetura é elaborado a fim de validar as decisões e realimentar o sistema, para

os ajustes necessários, até que o modelo de arquitetura esteja pronto e maduro para refletir as
funcionalidades requeridas pelo cliente.
5.2.4 Refinar a Arquitetura
Nesta atividade serão ajustadas as decisões arquiteturais sempre que necessário, ou

simplesmente evoluídas a partir da arquitetura existente, mesmo porque estas decisões poderão
ser reaproveitadas entre projetos diferentes.
5.2.5 Gerar Modelo do Projeto
Com base nas definições arquiteturais, os componentes de software irão sendo modelados,
implementados e testados, gerando um ciclo ágil de criação dos componentes. Eventualmente
poderão surgir ajustes para o próprio modelo, nas definições do sistema (um novo fluxo alternativo
no caso de uso, por exemplo) ou ainda ajustes da arquitetura.
O modelo do projeto irá compreender algumas visões para facilitar o entendimento do sistema.
Para a construção destas visões são utilizados os diagramas da UML.

Visão do usuário: Representa o sistema a partir da perspectiva dos usuários. Um diagrama de

caso de uso representa a funcionalidade provida pelo sistema para seus usuários externos, sendo
composto por atores, casos de uso e seus relacionamentos. Suporte UML: diagrama de casos de
uso.
Visão estrutural: Representa aspectos estáticos do sistema, na forma como são declarados.
Suporte UML: diagrama de classes e de objetos.
Visão Comportamental: Representa aspectos dinâmicos do sistema. Suporte UML: diagramas de

seqüência, colaboração, estados e atividades.
Visão de implementação: Representa aspectos estruturais e comportamentais da realização do

sistema, tendo como base os componentes de implementação. Suporte UML: diagrama de
componentes.
Visão de Ambiente: Representa o espaço físico em que se deseja que o sistema seja realizado,
contemplando a rede de recursos de processamento e a configuração de componentes de
software em cada elemento físico. Suporte UML: diagrama de implantação.
Nesta atividade é gerado o modelo do projeto, que compreende:

• O projeto detalhado das classes;
• A criação dos elementos necessários para o banco de dados, tais como o diagrama de
entidades e relacionamentos;
• O conjunto de componentes que serão implementados;
• Os diagramas que se façam necessários.
5.3 Executores das Atividades do Fluxo de Projeto
Os executores das atividades do fluxo de trabalho de Projeto estarão desempenhando o papel de:
• Arquiteto;
• Desenvolvedor;
• AD (Administrador de Dados) / DBA (Administrador de Banco de Dados).
5.4.1 Descrição da Arquitetura de Software
Documento que registra as decisões arquiteturais do sistema.
5.4.2 Protótipo Arquitetural
Protótipo para o entendimento e validação das principais decisões arquiteturais.

5.4.3 Modelo do Projeto
Composto por todos os diagramas e respectivas especificações, necessários para esclarecer as

visões do sistema que está sendo desenvolvido. Tipicamente são construídos, os diagramas de
classe e o diagrama de seqüência.
Os diagramas de classes têm que conter ao menos as classes, os atributos e relacionamentos,

organizados em pacotes e oferecendo visões em diferentes níveis, para análise e projeto, e o
diagrama de seqüência tem que apresentar a seqüência de mensagens trocadas entre os objetos
de um determinado contexto.
5.4.4 Modelo Lógico do Banco de Dados
Diagrama de entidades e relacionamentos representando a estratégia de tabelas adotada para as

classes identificadas.
Este produto terá que estar em consonância com a padronização de banco de dados vigente no
ONS. A referida padronização encontra-se relacionada no capítulo 10 MODELOS PARA

6 FLUXO DE IMPLEMENTAÇÃO
Este fluxo de trabalho leva em consideração o desenvolvimento do software, formado por seus
componentes, os testes de unidade e a integração com os componentes já existentes. Os modelos
de referência (templates) para os documentos a serem utilizados encontram-se relacionados no
capítulo 10 MODELOS PARA SUPORTE À METODOLOGIA.
6.1 Contexto do Fluxo de Implementação nas Fases do Ciclo
Todas as atividades do fluxo de implementação são executadas em todas as fases, tendo

maior ênfase em questões específicas (o processo é iterativo e incremental), conforme
relacionado a seguir e de acordo com a fase em que o desenvolvimento se encontra no ciclo de
vida do sistema.
A figura seguinte apresenta o contexto do fluxo de implementação, nas fases do ciclo de vida do
• Principais
restrições para o
ambiente de
desenvolvimento. • Planejamento
da Integração do
Sistema.
• Modelo Físico • Implementação
Inicial do BD. dos
componentes;
• Modelo Físico • Manutenção
Atualizado do dos
BD. componentes
criados;
Nesta fase são obtidas as principais restrições para a estrutura do ambiente de desenvolvimento.
Na fase de elaboração é planejada a integração do sistema e seus subsistemas, e é realizada a

implementação inicial dos componentes de banco de dados (modelo físico).

Nesta fase ocorre a implementação dos componentes do sistema em questão, incluindo aqueles
relativos ao banco de dados físico.
Na fase de transição ocorrem as eventuais manutenções dos componentes de sistema que foram
criados e entregues.
6.2 Atividades do Fluxo de Implementação
6.2.1 Planejar Integração
Planejar os subsistemas que serão implementados e a ordem de integração. Este planejamento é

realizado enquanto a arquitetura está sendo estabelecida. Há que considerar que os ajustes no
projeto e na arquitetura podem influenciar o planejamento da integração.
6.2.2 Preparar Ambiente de Desenvolvimento
O ambiente de desenvolvimento é preparado de acordo com os padrões definidos para serem

utilizados pela equipe. Os principais aspectos a se considerar são:
• “IDE” de mesmo fornecedor, versão e “plug-ins”;
• Estações de trabalho;
• Servidor (ou servidores de desenvolvimento);
• Instalações físicas;
• Definir estratégia de atualização dos códigos fonte.
6.2.3 Implementar Componentes de Software
Conforme planejado, os componentes de software são desenvolvidos, respeitando as

determinações da arquitetura estabelecida, tais como linguagens e tecnologias envolvidas.
Entende-se por componente de software, desde um programa isolado até um conjunto de classes
implementadas, ou mesmo scripts de geração de banco de dados e seu modelo físico, a
referência cruzada de permissões por tabela e por campo, e a referência cruzada de “constraints”,
“triggers” e “stored procedures” com as regras de negócio que estes mecanismos implementam.
6.2.4 Realizar Testes Unitários
Sempre que um componente de software é implementado, o seu teste unitário é realizado e fica
devidamente armazenado para futuras execuções. O desenvolvedor tem que garantir que os
testes do componente foram executados em sua totalidade e sem erros.

6.2.5 Integrar Componentes
Esta integração é realizada de forma automática, com o apoio de uma ferramenta integrada ao
ambiente de desenvolvimento. O ambiente e ferramenta têm que permitir o retorno à situação
anterior do sistema, no caso da entrada de um componente que ocasionou erro.
6.3 Executores das Atividades do Fluxo de Implementação
Os executores das atividades do fluxo de trabalho de Implementação estarão desempenhando o

papel de:
• Arquiteto;
• Desenvolvedor;
• AD (Administrador de Dados) / DBA (Administrador de Banco de Dados).
6.4.1 Componentes de Software
Artefatos de software criados (Classes; Interfaces com usuário; scripts e modelo físico do banco
de dados; referência cruzada de permissões por sistema, por entidade/tabela e por campo;
referência cruzada de constraints, triggers e stored procedures, com as regras de negócio que
estes mecanismos implementam; etc.) respeitando o planejamento e, principalmente, as decisões
de arquitetura, devidamente integrados aos outros componentes já criados.
Os produtos relativos ao banco de dados terão que estar em consonância com a padronização de
banco de dados vigente no ONS. A referida padronização encontra-se relacionada no capítulo 10
MODELOS PARA SUPORTE À METODOLOGIA.
6.4.2 Testes de Unidade
Artefatos de testes, scripts e documentos, que permitam os testes de unidade e a avaliação de

seus resultados a partir da emissão de Certificados de Testes Unitários conforme previsto no
documento Roteiro dos Testes.

7 FLUXO DE TESTES
Este fluxo de trabalho descreve casos de teste, procedimentos e medidas para acompanhamento
de erros e certificação do funcionamento do Sistema. Os modelos de referência (templates) para
os documentos a serem utilizados encontram-se relacionados no capítulo 10 MODELOS PARA
7.1 Contexto do Fluxo de Testes nas Fases do Ciclo
Todas as atividades do fluxo de testes são executadas em todas as fases do ciclo de vida do
sistema, tendo ênfase em questões específicas a cada iteração.
A figura seguinte apresenta o contexto do fluxo de testes, nas fases do ciclo de vida do sistema,
• Criação do
Plano de
Testes;
• Ajustes do
Plano de • Ajustes dos
Testes; Roteiros de
• Criação dos Testes;
Roteiros de • Execução dos
Testes; Roteiros de
• Execução dos
Testes, à
Testes de
medida que os
Aceitação
pacotes vão
restantes até
sendo
que se possa
terminados;
disponibilizar o
sistema para
implantação.
Nesta fase o plano de testes é criado.
Nesta fase, o plano de testes pode sofrer algum ajuste e os roteiros de teste são criados.

Aqui os roteiros de testes podem sofrer ajustes. Cada roteiro de teste é executado e seu resultado
é gerado. Os testes para aceitação irão ocorrendo conforme os pacotes de trabalho forem sendo
terminados.
Os testes para aceitação que restarem são executados até que se possa disponibilizar o sistema
para a sua implantação
7.2 Atividades do Fluxo de Testes
7.2.1 Elaborar Plano de Testes do Sistema
O plano de testes visa determinar a seqüência de realização dos testes, e a descrição das
verificações. O documento tem que conter o objetivo do teste, técnicas a serem utilizadas no teste,
além de critérios de finalização e condições especiais, se aplicáveis. Também terão que ser
considerados os recursos e materiais de apoio necessários.
Os tipos de testes são:

• Testes Funcionais;
• Teste de Integridade dos Dados;
• Teste do Ciclo de negócio;
• Teste de Interface com Usuário;
• Teste de Desempenho e Performance;
• Teste de Carga;
• Teste de Resistência – Stress;
• Teste de Volume;
• Teste de Controle de Acesso e Segurança;
• Teste de Tolerância à falha e recuperação;
• Teste de Instalação;
• Teste de Configuração.
7.2.2 Projetar os Testes do sistema
O projeto dos testes tem o objetivo de identificar e comunicar a informação necessária para se
preparar e executar os testes para cada caso de uso, respeitando as determinações do plano de
testes e gerando os roteiros de teste.
Para cada ator que interage com o caso de uso, são identificados os valores de entrada, os
resultados esperados e formas de verificação que podem ir, desde simples observação visual, até
à combinação de atividades complexas envolvendo aspectos não visuais.
Os principais documentos de suporte a esta atividade são a descrição dos casos de uso e as
responsabilidades das operações de cada caso de uso em relação ao sistema (contratos do
sistema).

7.2.3 Preparar Infra-estrutura para os Testes de Sistema
Toda a infra-estrutura dos testes é criada nesta atividade. Esta infra-estrutura, devidamente
documentada no roteiro de testes, pode envolver aspectos não triviais como cargas específicas de
dados, geração de scripts para automatismo de execução e preparação do ambiente operacional
para os testes.
7.2.4 Executar os Testes de Sistema
Todos os testes planejados são executados, registrando-se os sucessos e fracassos de cada

passo previsto para o teste. Os fracassos têm que direcionar as correções necessárias da
implementação para se atingir o sucesso na totalidade.
7.2.5 Executar os Testes de Aceitação de Sistema
São conduzidos pelo cliente (juntamente com seus usuários) e realizados com base no documento
de testes do sistema. Esta atividade resulta no termo de aceitação do sistema, liberando-o para
implantação em produção.
7.3 Executores das Atividades do Fluxo de Testes
Os executores das atividades do fluxo de trabalho de Testes estarão desempenhando o papel de:
• Analista de sistemas;
• Desenvolvedor;
• Cliente.
7.4.1 Plano de Testes
Documento que contém as linhas gerais dos testes que terão que ser executados. Cada tipo de
teste tem que ser avaliado quanto à sua necessidade para o sistema a ser desenvolvido.
7.4.2 Roteiro dos Testes
Documento que detalha todos os passos, resultados esperados e infra-estrutura necessária para a
execução de cada caso de uso.
7.4.3 “Scripts” de Testes
“Scripts” contendo as atividades automatizadas para a execução dos testes.
7.4.4 Resultado dos Testes executados
Documento contendo os resultados (evidências) dos testes e considerações para eventuais

correções e ajustes.

7.4.5 Testes de Aceitação
Resultados (evidências) dos testes realizados pelo cliente (juntamente com seus usuários), com
considerações para eventuais correções e ajustes, além do registro da aceitação do teste.

8 FLUXO DE IMPLANTAÇÃO
Este fluxo de trabalho descreve os procedimentos para preparar e implantar o software no
ambiente desejado. Os modelos de referência (templates) para os documentos a serem utilizados
encontram-se relacionados no capítulo 10 MODELOS PARA SUPORTE À METODOLOGIA.
8.1 Contexto do Fluxo de Implantação nas Fases do Ciclo
As atividades do fluxo de implantação são executadas em todas as fases, tendo maior ênfase
em questões específicas conforme relacionado a seguir e de acordo com a fase em que o
desenvolvimento se encontra no ciclo de vida do projeto.
A figura seguinte apresenta o contexto do fluxo de implantação, nas fases do ciclo de vida do
• Planejamento • Revisão do • Revisão do • Revisão do

Preliminar da Planejamento de Planejamento de Planejamento de
Implantação; Implantação; Implantação; Implantação;
• Estabelecimento
• Plano de • Desenvolvimento • Desenvolvimento do
da Infra-estrutura
Entrega p/ esta do Material de Material de Suporte;
de Suporte;
fase; Suporte;
• Produção do
• Plano de
• Restrições • Produção do Material de Apoio;
Entrega p/ esta
para as Material de Apoio;
fase; • Produção de
entregas da
• Produção de Versões Beta;
próxima fase. • Restrições para
Versão Beta;
as entregas da • Aceitações das
próxima fase. • Plano de Versões;
Entrega p/ esta
• Entrega das
fase;
Versões de Produção;
• Restrições para
• Plano de Entrega p/
as entregas da
esta fase;
próxima fase.
Nesta fase é realizado o planejamento preliminar da implantação, é elaborado o plano de entrega

para os produtos gerados dentro da fase e são obtidas as restrições a serem consideradas para
as entregas da próxima fase.
Na fase de elaboração é feita a revisão do planejamento de implantação, é estabelecida a infra-

estrutura de suporte, é elaborado o plano de entrega para os produtos gerados dentro da fase e
são obtidas as restrições a serem consideradas para as entregas da próxima fase.

Nesta fase é feita a revisão do planejamento de implantação, é desenvolvido o material de

suporte, é produzido o material de apoio, é produzida a versão beta (ao menos uma), é elaborado
o plano de entrega para os produtos gerados dentro da fase e são obtidas as restrições a serem
consideradas para as entregas da próxima fase.
Nesta fase é realizada a revisão do planejamento de implantação, é desenvolvido do material de

suporte, é produzido o material de apoio, são produzidas versões beta, são realizadas as
aceitações das versões, são entregues as versões de produção e é elaborado o plano de entrega
para os produtos gerados dentro da fase.
8.2 Atividades do Fluxo de Implantação
8.2.1 Elaborar Pano de Entrega
Planejar as entregas que ocorrerão para os subprodutos do projeto e em cada fase do ciclo, que
podem ir desde a entrega de simples documentos até versões completas da aplicação.
O plano de entrega, para as entregas de cada fase, tem que ser validado com o cliente o mais
cedo possível, no início da fase em questão.
8.2.2 Desenvolver Material de Suporte
Elaborar material de suporte à implantação, para a efetiva entrega do sistema aos usuários.
Os materiais de suporte têm que cobrir todas as informações que possam ser requisitadas pelos
usuários finais para instalar, operar ou utilizar o sistema entregue, além de eventuais materiais de
treinamento sobre estas demandas.
8.2.3 Produzir Versão de Homologação (Versão Beta)
Criar uma versão beta do sistema, a fim de solicitar retorno do cliente e usuários, relativo ao
produto ainda em evolução. Este retorno pode ser composto de novas solicitações dos usuários,
as quais podem resultar em novas características do produto, gerando uma solicitação de
mudança.
8.2.4 Obter Aceitação Formal da Versão
O cliente precisa aceitar formalmente a versão de software produzida. Parte desta aceitação pode
ser obtida com os testes de aceitação do sistema e a parte restante, com a entrega dos materiais
de suporte, previstos de acordo com o plano.

8.2.5 Produzir Versão de Produção
Produzir a versão final do sistema a ser colocado no ambiente de produção do usuário, contendo o
software e os artefatos necessários para uso e instalação efetivos. O número de versões de
produção dependerá do número de ciclos de vida evolutivos do sistema e das versões iterativas
disponibilizadas.
8.2.6 Preparar Treinamento
Além do material de suporte necessário para o treinamento, o próprio treinamento tem que ser
preparado com a identificação do(s) instrutor(es), das aulas e do ambiente do treinamento.
8.2.7 Estabelecer Infra-estrutura de Suporte
A partir do momento em que seja disponibilizada uma versão para o ambiente de produção, já terá
que estar estabelecida a estratégia de suporte e de controle de versões em produção. Caso esta
estrutura não esteja criada, o projeto poderá ficar comprometido, em função do surgimento de
demandas não controladas.
8.3 Executores das Atividades do Fluxo de Implantação
Os executores das atividades do fluxo de trabalho de Implantação estarão desempenhando o

papel de:
• Analista de sistemas;
• Desenvolvedor.
8.4.1 Plano de Entrega

Documento que constitui o planejamento das entregas que ocorrerão para o projeto em cada fase
do ciclo, contendo o escopo, o agendamento, o suporte necessário, o processo e os resultados
esperados da entrega.
8.4.2 Material de Suporte
O material de suporte requisitado para atendimento ao usuário, como: guia do usuário, guia de
operação, “demo on-line”, “help on-line”, e apostilas de treinamento.
8.4.3 Versão de Homologação
Versão do sistema contendo os componentes de software, “scripts” de instalação e materiais de

apoio, para avaliação do cliente (juntamente com seus usuários) relativa ao sistema.

8.4.4 Versão de Produção
Versão do sistema contendo os componentes de software, “scripts” de instalação e materiais de

apoio, para ser implantada no ambiente de produção.
8.4.5 Aceitação de Versão
Documento formalizando o aceite do cliente para a versão em questão.
8.4.6 Treinamento
É a execução do treinamento, com infra-estrutura adequada, material didático, instrutor qualificado

e plano de aulas.
8.4.7 Infra-estrutura de Suporte
As decisões relativas à infra-estrutura de suporte estarão no plano do projeto.

9 RECOMENDAÇÕES E OBSERVAÇÕES
9.1 Ferramenta Case
Quanto maior e mais complexo for o sistema, maior será a necessidade de se utilizar uma
ferramenta automatizada para se agilizar a construção do software. Uma ferramenta C.A.S.E.
(Computer Aided Software Engineering) deve ser considerada para este apoio. Ela não deve
apenas servir para a modelagem de diagramas. As seguintes características devem ser também
consideradas:
• Uso de repositório para os elementos criados;
• Integração entre os diagramas (alterações em um elemento refletem em qualquer
diagrama onde ele esteja presente);
• Geração automática de código na linguagem que será utilizada no Sistema;
• Capacidade de engenharia reversa (lê programas e os transforma em diagramas);
• Facilidade de exportar diagramas como figuras;
• Geração de arquivo em formato padrão de intercâmbio entre aplicações – XMI;
• Suporte a UML;
• Suporte a trabalho em equipe;
• Controle de versão;
• Geração de relatórios a partir do seu repositório;
• Integração com IDE (Integrated Development Environment - ambiente de desenvolvimento
integrado).
A equipe de desenvolvimento deve considerar a escolha de uma ferramenta CASE para apoio ao
seu trabalho, observando as características do sistema a ser desenvolvido.
9.1.1 Ambiente de Desenvolvimento
O uso de um ambiente de desenvolvimento integrado (IDE - Integrated Development Environment)

é fundamental. Esta ferramenta deve ser escolhida de acordo com a linguagem de
desenvolvimento e padronizada para toda equipe.
É imprescindível o uso de um repositório comum para os códigos fonte, a fim de suportar a

dinâmica de desenvolvimento, permitindo o retorno de versão, “check-in” e “check-out” dos fontes.
Algumas características relevantes de IDEs:

• Interface Gráfica;
• “Debug”;
• Integração com repositório de códigos fonte;
• Integração com servidores de aplicação e servidores WEB;
• Complementação de código;
• Facilidade de uso por parte da equipe de desenvolvimento;
• Agilidade no desenvolvimento.
O repositório de códigos fonte, deve oferecer:

• Controle de versões;
• “Check-in” e “check-out” de documentos;
• Facilidade de “backup” e de “restore”;
• Controle de segurança de acesso.

9.1.2 Diagramas UML
A UML – Unified Modeling Language ou Linguagem Unificada de Modelagem - foi criada para
representar as diversas visões de um sistema de maneira gráfica, de modo a tornar universal o
modelo do sistema, independentemente do processo de desenvolvimento utilizado.
Não existe a obrigatoriedade do uso de todos os diagramas, e devem ser levados em

consideração, no momento da modelagem, os seguintes pontos:
• Use tantos diagramas quantos forem necessários para comunicar a visão do sistema;
• A criação de diagramas tem por objetivo facilitar o entendimento do sistema e prover
vantagens para a sua implementação, e deve agregar valor.
• Somente o uso de diagramas não esgota a semântica de um modelo. Por isto,
informações textuais deverão ser sempre acrescentadas para esclarecer o modelo;
• Um diagrama com 200 classes é difícil de entender, organize os diagramas em pacotes.
(pequenos grupos).
9.1.3 Automatização dos Testes
Quanto maior e mais complexo for o sistema, mais complicada se torna a realização de testes. Os
testes são realizados em dois momentos: quando uma funcionalidade nova é criada ou quando
uma nova funcionalidade é acrescentada ao sistema existente.
Existem dois grupos básicos de testes: os testes unitários e os testes de sistema ou integrados. A
forma de garantir que o sistema possui qualidade é submetê-lo a testes, sempre que houver algum
ajuste ou manutenção. Testes intensos garantirão uma melhor qualidade do sistema.
Os testes de sistema vão envolver aspectos complexos como, teste de carga, acessos
simultâneos e navegação, entre outros. Dependendo da criticidade envolvida no sistema, estes
testes podem ser fundamentais para a sua aceitação. O uso de ferramentas para automatizar este
tipo de teste é fortemente recomendado.
Deve ser observado que a necessidade dos testes existe independentemente da opção por um
tipo de processo de desenvolvimento. A execução de testes sem o suporte de ferramentas terá
mais custo em tempo de preparação, execução e certificação de seus resultados.
9.1.4 Melhores Práticas
Aspectos observados neste documento, que estejam criando trabalho desnecessário, podem
indicar que a metodologia deve ser revisada.
A aplicação da metodologia deve conduzir a melhores práticas no processo de desenvolvimento,

beneficiando o grupo de desenvolvimento de projetos e a empresa como um todo.

10 MODELOS PARA SUPORTE À METODOLOGIA

Anexo 1: Modelo para Definição do Problema
(Para acessar o modelo clique Definição do Problema.);
Anexo 2: Modelo para Glossário

(Para acessar o modelo clique Glossário.);
Anexo 3: Modelo para Documento de Visão

(Para acessar o modelo clique Documento de Visão.);
Anexo 4: Modelo para Descrição de Caso de Uso

(Para acessar o modelo clique Descrição de Caso de Uso);
Anexo 5: Modelo de Especificação Suplementar

(Para acessar o modelo clique Especificação Suplementar);
Anexo 6: Modelo de Diagramas

(Para acessar o modelo clique Diagramas);
Observação: Este modelo é utilizado sempre que é necessário enviar alguns diagramas para o
cliente, em um documento formatado e sem que exista um outro meio, como por exemplo,
geração automática a partir da ferramenta CASE, página WEB publicada para o cliente acessar e
navegar pelo modelo do sistema, acesso direto e controlado do cliente à própria ferramenta CASE,
ou algum outro meio acordado entre as partes.
Anexo 7: Modelo para Termo de Validação e Aceitação de Produtos

(Para acessar o modelo clique Termo de Validação e Aceitação de Produtos)
Anexo 8: Modelo para as responsabilidades das operações de cada caso de uso em relação ao
sistema (Contratos de Sistema)
(Para acessar o modelo clique Contratos de Sistema);
Anexo 9: Modelo para Descrição da Arquitetura de Software

(Para acessar o modelo clique Descrição da Arquitetura);
Anexo 10: Manual de Procedimentos Padrão do ONS para Banco de Dados

(Para acessar o manual clique Padronização Para Banco de Dados);
Anexo 11: Modelo para Plano de Testes

(Para acessar o modelo clique Plano de Testes.);
Anexo 12: Modelo para Roteiro de Testes

(Para acessar o modelo clique. Roteiro de Testes);
Anexo 13: Modelo para Plano de Entrega

(Para acessar o modelo clique. Plano de Entrega);

11 PRODUTOS RESULTANTES DA METODOLOGIA

A figura seguinte apresenta os produtos resultantes da metodologia e como estes se encontram
agrupados, para efeito de validação e aceitação, relativamente aos marcos do final de cada fase
do ciclo de vida do sistema.
Note que, a partir do momento em que surge, a maioria dos produtos vai sendo atualizada ao
longo de todo o ciclo do projeto. Entretanto, para efeito de validação/aceitação visando a
monitoração dos riscos, a confirmação de um entendimento comum da solução, o estabelecimento
de bases para gerenciamento de mudanças e a comprovação de que os marcos estabelecidos
para as fase foram alcançados, foi estabelecido o agrupamento a seguir de acordo com as fases
em que a elaboração destes produtos tem maior ênfase:
Para os produtos acima sublinhados existe um modelo de referência disponível sendo que, para o
Termo de Aceite da Especificação Funcional, para o Termo de Aceite da Especificação Técnica,
para a Aceitação dos Testes e para a Aceitação de Versão, é utilizado o mesmo modelo, que é o
Termo de Validação e Aceitação de Produtos.

O “Protótipo Arquitetural” contém as decisões consideradas para modelo de arquitetura e como os

diversos componentes estarão distribuídos nesta. O protótipo da arquitetura é elaborado a fim de
validar as decisões e realimentar o sistema para os ajustes necessários, até que o modelo de
arquitetura esteja pronto e maduro para refletir as funcionalidades requeridas pelo cliente. Sua
versão final estará expressa na “Descrição da Arquitetura de Software” conforme modelo
correspondente.
O modelo de nome “Diagramas” será utilizado para os produtos “Modelo do Projeto”, “Modelo
Lógico do Banco de Dados” e “Modelo Físico do Banco de Dados”, na eventualidade de não ser
possível entregá-los por meio de geração automática a partir da ferramenta CASE, de página
WEB publicada para o cliente acessar e navegar pelo modelo do sistema, de acesso direto e
controlado do cliente à própria ferramenta CASE, ou algum outro meio estabelecido para a
questão.
A Padronização para Banco de Dados do ONS, anexo 10 deste documento, expressa os

procedimentos padrão, a serem seguidos, na elaboração dos “Modelos Lógico e Físico do Banco
de Dados” e correspondentes “Permissões e Regras de Negócio”. Estes produtos serão
atualizados ao longo do ciclo, até ser estabelecida sua versão final.
Os “Certificados dos Testes de Unidade”, assim como os “Scripts de Testes” e os “Resultados dos
Testes” para os testes de integração, sistema e aceitação, ou para os testes de aceitação das
versões de homologação e de produção, são emitidos por quem realiza os testes e servirão para
demonstrar as evidências de sua elaboração e ratificar sua aderência em relação aos requisitos
definidos. O formato destes produtos tem que estar de acordo com o que foi estabelecido nos
“Roteiros de Testes” que foram entrada para a sua realização.
O “Material de Suporte” é o material requisitado para atendimento ao usuário, como guia do

usuário, guia de operação, “demo on-line”, “help on-line”, ou apostilas de treinamento e seu
formato dependerá dos requisitos que foram previamente especificados para este material.
O “Treinamento” também não conta com um formato padrão já que deverá variar de acordo com o
objeto de treinamento e de acordo com a estratégia definida com o cliente deste treinamento.
Os “Componentes de Software” e as “Versões de Homologação e de Produção” constituem

respectivamente os componentes individuais de código ou o conjunto integrado destes
componentes para uma determinada versão do sistema que esteja sendo entregue.
Ainda conforme a figura anteriormente apresentada, os produtos deverão ter sua aceitação formal
realizada ao final de cada fase, porém a validação destes ocorre ao longo da fase de acordo com
o que estiver previsto no “Plano de Entrega” que é elaborado no início da mesma. Assim, os
produtos vão sendo validados à medida que vão sendo elaborados, mas sua aceitação formal
ocorre no final de cada fase. O “Plano de Entrega” é fundamental para a entrega das versões na
fase de transição, mas deve ser elaborado também um plano de entrega para cada fase do ciclo.

Os produtos da metodologia a serem entregues para cada fase do ciclo de vida do processo, são
os seguintes:
Na Concepção (produtos que constituem a Especificação Funcional):
• Plano de Entrega;
• Glossário;
• Definição do Problema;
• Documento de Visão;
• Especificação dos Casos de Uso;
• Protótipo de Interface com o Usuário;
• Especificação Suplementar;
• Plano de Testes.
Estes produtos serão aceites formalmente por meio do “Termo de Aceite da Especificação
Funcional”.
Na Elaboração (produtos que constituem a Especificação Técnica):
• Especificação Funcional revisada e atualizada;

• Contratos do Sistema;
• Modelo do Projeto;
• Modelo Lógico do Banco de Dados;
• Modelo Físico do Banco de Dados;
• Permissões e Regras de Negócio do Banco de Dados;
• Protótipo Arquitetural;
• Descrição da Arquitetura de Software;
• Roteiros de Testes;
Estes produtos serão aceites formalmente por meio do “Termo de Aceite da Especificação
Técnica”.
Na Construção:

• Especificação Técnica revisada e atualizada;
• Componentes de Software;
• Testes de Unidade;
• Certificados dos Testes de Unidade;
• Modelo Físico do Banco de Dados (atualizado);
• Permissões e Regras de Negócio do Banco de Dados (atualizadas);
• Scripts de Testes;
• Testes de Aceitação (integração, sistema e versões beta);
• Resultados dos Testes Executados;
Estes produtos serão aceites formalmente por meio da “Aceitação dos Testes”.

Na Transição:

• Especificação Técnica revisada e atualizada;
• Material de Suporte;
• Modelo Físico do Banco de Dados (atualizado);
• Permissões e Regras de Negócio do Banco de Dados (atualizadas);
• Scripts de Testes;
• Versões de Homologação e Produção;
• Treinamento;
• Resultados dos Testes de Aceitação das Versões;
Estes produtos serão aceites formalmente por meio da “Aceitação das Versões”.
11.1 Artefatos x Papéis
A figura mostrada na página seguinte apresenta a relação entre os artefatos produzidos através da
metodologia e os perfis técnicos (ou papéis) necessários para sua elaboração.
Conforme já foi explicitado, estes perfis técnicos não traduzem cargos ou funções dos
profissionais expressando, apenas, os papéis que estes profissionais irão desempenhar em
determinados momentos do ciclo do projeto e de acordo com as atividades do fluxo de trabalho
que estiver sendo trabalhado.
Os papéis representados na figura a seguir, devem ser vistos como uma orientação sobre os
perfis necessários, de acordo com as responsabilidades associadas a estes papéis.

Anexo VI - Metodologia de Desenvolvimento de
DESCRIÇÃO DA METODOLOGIA Software – MDS
M etodologia de D esenvolvim ento de S istem as: A rtefatos x P apéis

Analista de
P la no de
Sistemas
D efin iç ão d o D oc um ento de E s pe cifica ção de E s pec ific aç ão E ntre ga

P roblem a V is ão C as os de U s o S uplem e ntar T erm o A ce itaç ão
E s pec if. Fun ciona l T erm o T erm o A c eit.
C o ntra tos do A c eit. tes tes
S iste m a E sp ecif.
P lano d e R oteiro dos
G los s ário técn ic a Treinam en to
T es tes Tes tes
M od elo do D es criçã o da
Arquiteto
P ro jeto A rquitetura
P rotótipo
A rq uitetural
AD / DBA
M o delo Lóg ic o d o
B anc o de D ado s
M od elo Fís ico
M odelo F ís ic o
do B anc o d e
Inic ia l do B D
D ados
P rotó tip o de
Interfac e c / o S c rip ts de
U s uário T este s
Desenvolvedor
V ers ões do
S oftw are
T es tes de
A c eitaç ão
C ertifica dos Tes tes de C om p onen tes
Tes tes U nit. U n id ade de S oftware
M a terial de
S u porte
Usuário /
Cliente
Fo rm alizaç ão dos term os de

V a lidaç ão e A ce ita ção

12 VALIDAÇÃO E ACEITAÇÃO DE PRODUTOS

Para todas as entregas de subprodutos e produtos, do ciclo de desenvolvimento de software, tem
que ser previamente definido o conjunto de critérios para validação ou aceitação dos mesmos.
Estes critérios têm sempre que incluir:

• As cláusulas previstas no contrato;
• O escopo definido e acordado;
• Uma lista de verificação das características do subproduto ou produto em questão;
• Os subprodutos e produtos previamente validados ou aceitos, com os quais o subproduto
ou produto a ser validado/aceito tenha relações de dependência;
• A rastreabilidade entre os artefatos do sistema.
12.1 Listas de Verificação
As seguintes listas de verificação foram produzidas para apoiar os processos de validação e

aceitação de produtos, constituindo anexos a este documento:
Anexo 14: Lista de verificação de conformidade dos produtos da metodologia, para a fase de
Concepção, relativa aos produtos que constituem a Especificação Funcional
(Para acessar esta lista clique em Conformidade Concepção );
Elaboração, relativa aos produtos que constituem a Especificação Técnica
(Para acessar esta lista clique em Conformidade Elaboração );
Construção, relativa aos produtos que constituem os Testes Unitários e as Versões Beta de
Software
(Para acessar esta lista clique em Conformidade Construção );
Transição, relativa aos produtos que constituem as Versões de Software para Homologação
(Para acessar esta lista clique em Conformidade Transição );

Anexo VI-Metodologia de To de Sistemas-Do ONS

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Anexo VI-Metodologia de To de Sistemas-Do ONS

Enviado por

Direitos autorais:

Formatos disponíveis

Desenvolvimento de Sistemas

Assunto Concorrência nº 002/09

Rev. Motivo da Revisão Data de Aprovação

DAC/GIT – Gerência de Informática e Telecomunicações 1 de 53

DAC/GIT – Gerência de Informática e Telecomunicações 2 de 53

4.2.1 Refinar Casos de Uso................................................................................................. 26

DAC/GIT – Gerência de Informática e Telecomunicações 3 de 53

7.1.3 Na Fase de Construção.............................................................................................. 38

DAC/GIT – Gerência de Informática e Telecomunicações 4 de 53

DAC/GIT – Gerência de Informática e Telecomunicações 5 de 53

A proposta deste documento é apresentar de forma simples e consolidada a metodologia

Desta forma, o que se pretendeu neste documento foi, a partir de metodologias de

Dependendo da natureza de cada projeto, poderão ser necessárias adaptações desta

1.2 Definições, Siglas e Abreviações

CASE Computer Aided Software Engineering (Ferramenta Computacional de Engenharia de

DAC/GIT – Gerência de Informática e Telecomunicações 6 de 53

A relação a seguir, apresenta os documentos que foram referenciados ou utilizados como

Título do Documento Data N.º Responsável

1.4 Índice Descritivo

Este documento está organizado da seguinte forma:

• Capítulo 1 “Introdução” – Apresenta uma visão geral deste documento.

• Capítulo 2 “Visão Geral do Processo Unificado” – Apresenta uma visão geral do

• Capítulo 3 “Fluxo de Requisitos” – Descreve o fluxo de trabalho relativo à

• Capítulo 4 “Fluxo de Análise” – Descreve o fluxo de trabalho referente à Análise e

• Capítulo 5 “Fluxo de Projeto” – Descreve o fluxo de trabalho relativo ao Projeto da

• Capítulo 6 “Fluxo de Implementação” – Descreve o fluxo de trabalho de

• Capítulo 7 “Fluxo de Testes” – Descreve o fluxo de trabalho necessário para

DAC/GIT – Gerência de Informática e Telecomunicações 7 de 53

antes da entrega do software. Descreve ainda as atividades deste fluxo, executores,

• Capítulo 8 “Fluxo de Implantação” – Descreve o fluxo de trabalho para

• Capítulo 9 “Recomendações e Observações” – Apresenta observações e

• Capítulo 10 “Modelos Anexos” – Índice com os modelos dos documentos a serem

• Capítulo 11 “Produtos Resultantes da Metodologia” - Apresenta a consolidação

• Capítulo 12 “Validação e Aceitação de Produtos” – Descreve os critérios que

DAC/GIT – Gerência de Informática e Telecomunicações 8 de 53

2 VISÃO GERAL DO PROCESSO UNIFICADO

No ciclo de desenvolvimento de software com a utilização da metodologia do Processo Unificado,

• A perspectiva gerencial, através de uma visão dirigida pelas fases do processo;

2.1.1 Fases do Processo

DAC/GIT – Gerência de Informática e Telecomunicações 9 de 53

Na fase de elaboração ocorre o entendimento e descrição completos, dos aspectos funcionais do

Nesta fase é desenvolvido o sistema.

É a fase em que o sistema é fornecido aos seus usuários finais.

A prototipação é um instrumento poderoso que demonstra parte ou a totalidade dos

Ferramentas para prototipação incluem:

A prototipação facilita o entendimento dos comportamentos do sistema e deve ser utilizada,

Neste documento estaremos trabalhando com dois tipos distintos de protótipo:

DAC/GIT – Gerência de Informática e Telecomunicações 10 de 53

O protótipo arquitetural ocorre normalmente em menor número que os protótipos de interface

2.1.3 Fluxos de Trabalho (Seqüências de Atividades)

Fluxo de Requisitos (Requirements):

Fluxo de Análise (Analysis):

Fluxo de Projeto (Design):

Fluxo de Implementação (Implementation):

Fluxo de Teste (Test):

DAC/GIT – Gerência de Informática e Telecomunicações 11 de 53

2.1.4 Ciclo de Vida

A figura a seguir reflete o processo de evolução através dos ciclos evolutivos:

Tempo Versão n...

As iterações ocorrem relativamente ao ciclo como um todo, conforme apresentado na figura

DAC/GIT – Gerência de Informática e Telecomunicações 12 de 53

O quadro seguinte constitui a referência para a quantidade de iterações por ciclo de

Ciclo iterativo Total de iterações Número de iterações