Metodologia de Desenvolvimento de Sistemas-MDS

Desenvolvimento de Sistemas
Assunto DESCRIO DA METODOLOGIA

Concorrncia n 002/09 Anexo VI - Metodologia de Desenvolvimento de Software MDS
Documento de Referncia MDS - Metodologia de Desenvolvimento de Software
Rev. N. 0
Motivo da Reviso Este documento foi motivado pela necessidade de padronizao da metodologia utilizada para desenvolvimento de sistemas.
Data de Aprovao pelo ONS 18/07/2005
DAC/GIT Gerncia de Informtica e Telecomunicaes
1 de 53
INTRODUO ............................................................................................................................ 6 1.1 1.2 1.3 1.4 OBJETIVO .............................................................................................................................. 6 DEFINIES, SIGLAS E ABREVIAES ..................................................................................... 6 REFERNCIAS ........................................................................................................................ 6 NDICE DESCRITIVO ................................................................................................................ 7
VISO GERAL DO PROCESSO UNIFICADO .......................................................................... 9 2.1 VISO GERAL ......................................................................................................................... 9 2.1.1 Fases do Processo ....................................................................................................... 9 2.1.2 Prototipao................................................................................................................ 10 2.1.3 Fluxos de Trabalho (Seqncias de Atividades) ........................................................ 11 2.1.4 Ciclo de Vida............................................................................................................... 12 2.1.5 Rastreabilidade........................................................................................................... 15 2.1.6 Reduo dos Riscos................................................................................................... 16 2.1.7 Melhores Prticas (Uma Reforando a Outra) ........................................................... 16 2.2 VERIFICAO 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
FLUXO DE REQUISITOS......................................................................................................... 21 3.1 CONTEXTO DO FLUXO DE REQUISITOS NAS FASES DO CICLO .................................................. 21 3.1.1 Na Fase de Concepo .............................................................................................. 21 3.1.2 Na Fase de Elaborao .............................................................................................. 21 3.1.3 Na Fase de Construo.............................................................................................. 22 3.1.4 Na Fase de Transio ................................................................................................ 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 Especificao Funcional................................................................................... 22 3.2.4 Validar Especificao 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 Glossrio..................................................................................................................... 23 3.4.2 Definio do Problema ............................................................................................... 23 3.4.3 Documento de Viso .................................................................................................. 23 3.4.4 Especificao dos Casos de Uso (Objetivos e Linhas Gerais) .................................. 24 3.4.5 Diagrama de Casos de Uso ....................................................................................... 24 3.4.6 Prottipo de Interface com o Usurio ......................................................................... 24 3.4.7 Especificao Suplementar ........................................................................................ 24 3.4.8 Termo de Aceite da Especificao Funcional ............................................................ 24
FLUXO DE ANLISE ............................................................................................................... 25 4.1 CONTEXTO DO FLUXO DE ANLISE NAS FASES DO CICLO ....................................................... 25 4.1.1 Na Fase de Concepo .............................................................................................. 25 4.1.2 Na Fase de Elaborao .............................................................................................. 26 4.1.3 Na Fase de Construo.............................................................................................. 26 4.2 ATIVIDADES DO FLUXO DE ANLISE ....................................................................................... 26
2 de 53
Refinar Casos de Uso................................................................................................. 26 4.2.1 4.2.2 Definir Classes de Negcio ........................................................................................ 26 4.2.3 Definir Responsabilidades das Operaes de cada Caso de Uso em Relao ao sistema (Contratos do Sistema)................................................................................................ 26 4.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE ANLISE ........................................................... 27 4.4 PRODUTOS GERADOS .......................................................................................................... 27 4.4.1 Diagramas de Casos de Uso...................................................................................... 27 4.4.2 Especificao dos Casos de Uso ............................................................................... 27 4.4.3 Especificao Suplementar ........................................................................................ 27 4.4.4 Responsabilidades das Operaes de cada Caso de Uso em Relao ao Sistema (Contratos do Sistema) ............................................................................................................. 28 4.4.5 Termo de Aceite das Responsabilidades das Operaes de cada Caso de Uso em Relao ao Sistema (Contratos do Sistema)............................................................................ 28 5 FLUXO DE PROJETO.............................................................................................................. 29 5.1 CONTEXTO DO FLUXO DE PROJETO NAS FASES DO CICLO ...................................................... 29 5.1.1 Na Fase de Concepo .............................................................................................. 29 5.1.2 Na Fase de Elaborao .............................................................................................. 30 5.1.3 Na Fase de Construo.............................................................................................. 30 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 Prottipo 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 PRODUTOS GERADOS .......................................................................................................... 32 5.4.1 Descrio da Arquitetura de Software........................................................................ 32 5.4.2 Prottipo Arquitetural .................................................................................................. 32 5.4.3 Modelo do Projeto....................................................................................................... 33 5.4.4 Modelo Lgico do Banco de Dados............................................................................ 33 6 FLUXO DE IMPLEMENTAO ............................................................................................... 34 6.1 CONTEXTO DO FLUXO DE IMPLEMENTAO NAS FASES DO CICLO ........................................... 34 6.1.1 Na Fase de Concepo .............................................................................................. 34 6.1.2 Na Fase de Elaborao .............................................................................................. 34 6.1.3 Na Fase de Construo.............................................................................................. 35 6.1.4 Na Fase de Transio ................................................................................................ 35 6.2 ATIVIDADES DO FLUXO DE IMPLEMENTAO .......................................................................... 35 6.2.1 Planejar Integrao..................................................................................................... 35 6.2.2 Preparar Ambiente de Desenvolvimento.................................................................... 35 6.2.3 Implementar Componentes de Software .................................................................... 35 6.2.4 Realizar Testes Unitrios ........................................................................................... 35 6.2.5 Integrar Componentes ................................................................................................ 36 6.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE IMPLEMENTAO .............................................. 36 6.4 PRODUTOS GERADOS .......................................................................................................... 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.1.1 Na Fase de Concepo .............................................................................................. 37 7.1.2 Na Fase de Elaborao .............................................................................................. 37 DAC/GIT Gerncia de Informtica e Telecomunicaes 3 de 53
Na Fase de Construo.............................................................................................. 38 7.1.3 7.1.4 Na Fase de Transio ................................................................................................ 38 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 Aceitao de Sistema ............................................................ 39 7.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE TESTES ............................................................ 39 7.4 PRODUTOS GERADOS .......................................................................................................... 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 Aceitao ................................................................................................... 40 8 FLUXO DE IMPLANTAO .................................................................................................... 41 8.1 CONTEXTO DO FLUXO DE IMPLANTAO NAS FASES DO CICLO ............................................... 41 8.1.1 Na Fase de Concepo .............................................................................................. 41 8.1.2 Na Fase de Elaborao .............................................................................................. 41 8.1.3 Na Fase de Construo.............................................................................................. 42 8.1.4 Na Fase de Transio ................................................................................................ 42 8.2 ATIVIDADES DO FLUXO DE IMPLANTAO ............................................................................... 42 8.2.1 Elaborar Pano de Entrega .......................................................................................... 42 8.2.2 Desenvolver Material de Suporte ............................................................................... 42 8.2.3 Produzir Verso de Homologao (Verso Beta) ...................................................... 42 8.2.4 Obter Aceitao Formal da Verso ............................................................................ 42 8.2.5 Produzir Verso de Produo .................................................................................... 43 8.2.6 Preparar Treinamento................................................................................................. 43 8.2.7 Estabelecer Infra-estrutura de Suporte ...................................................................... 43 8.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE IMPLANTAO ................................................... 43 8.4 PRODUTOS GERADOS .......................................................................................................... 43 8.4.1 Plano de Entrega ........................................................................................................ 43 8.4.2 Material de Suporte .................................................................................................... 43 8.4.3 Verso de Homologao ............................................................................................ 43 8.4.4 Verso de Produo ................................................................................................... 44 8.4.5 Aceitao de Verso................................................................................................... 44 8.4.6 Treinamento................................................................................................................ 44 8.4.7 Infra-estrutura de Suporte .......................................................................................... 44 9 RECOMENDAES E OBSERVAES................................................................................ 45 9.1 FERRAMENTA CASE.............................................................................................................. 45 9.1.1 Ambiente de Desenvolvimento................................................................................... 45 9.1.2 Diagramas UML.......................................................................................................... 46 9.1.3 Automatizao dos Testes ......................................................................................... 46 9.1.4 Melhores Prticas ....................................................................................................... 46 10 11 11.1 12 12.1 MODELOS PARA SUPORTE METODOLOGIA............................................................... 47 PRODUTOS RESULTANTES DA METODOLOGIA............................................................ 48 ARTEFATOS X PAPIS ....................................................................................................... 51 VALIDAO E ACEITAO DE PRODUTOS.................................................................... 53 LISTAS DE VERIFICAO ................................................................................................... 53 4 de 53
5 de 53
1 INTRODUO
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 manuteno de software internas ou externas, constituindo um guia de referncia para os grupos. O produto deste documento teve como referncia 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 exigncias das organizaes, das reas de aplicao, 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 constitusse uma metodologia padro preliminar, seguindo preceitos universais e de forma a permitir sua posterior evoluo medida que for sendo alcanada maior maturidade na execuo de seus processos. Dependendo da natureza de cada projeto, podero ser necessrias adaptaes desta metodologia relativamente a caractersticas mais especficas, a fim de melhor adequ-la para um determinado grupo de projetos. Melhorias decorrentes destas adaptaes podero constituir tambm uma evoluo da metodologia, tornando-a mais apropriada para novas demandas e realidades.
1.2
CASE IDE RUP UML
Definies, Siglas e Abreviaes

Computer Aided Software Engineering (Ferramenta Computacional de Engenharia de Software) Integrated Development Environment (Ambiente de Desenvolvimento Integrado) Rational Unified Process (Processo Unificado da Rational Software Corporation - IBM) Unified Modeling Language (Linguagem de Modelagem Unificada)
1.3
Referncias
6 de 53
A relao a seguir, apresenta os documentos que foram referenciados ou utilizados como referncia na elaborao deste documento. Ttulo do Documento Data N. Referncia Responsvel Addison Wesley Version 1.4 Version 5.5 1999 Rational University Rational University Addison Wesley
Kruchten, Philippe.The Rational Unified Process An 2000 Introduction, Second Edition Object-Oriented Project Management, Student Manual Rational Unified Process Overview, Student Manual Leffingwell, Dean; Widrig, Don. Managing Software Requirements
1.4
ndice Descritivo
Este documento est organizado da seguinte forma: Captulo 1 Introduo Apresenta uma viso geral deste documento.
Captulo 2 Viso Geral do Processo Unificado Apresenta uma viso geral do Processo Unificado, das fases e fluxos de trabalho que compem o ciclo de vida do projeto. Captulo 3 Fluxo de Requisitos Descreve o fluxo de trabalho relativo identificao e especificao de Requisitos, com suas atividades, executores e produtos gerados, alm de contextualiz-lo em cada fase do projeto. Captulo 4 Fluxo de Anlise Descreve o fluxo de trabalho referente Anlise e detalhamento dos requisitos, com suas atividades, executores, produtos gerados e correspondente contextualizao do fluxo em cada fase do projeto. Captulo 5 Fluxo de Projeto Descreve o fluxo de trabalho relativo ao Projeto da viso de arquitetura da anlise, com suas atividades, executores, produtos gerados e devida contextualizao em cada fase do projeto. Captulo 6 Fluxo de Implementao Descreve o fluxo de trabalho de Implementao da soluo analisada e projetada, com suas atividades, executores, produtos gerados e contextualizao em cada fase do projeto. Captulo 7 Fluxo de Testes Descreve o fluxo de trabalho necessrio para verificar se a interao entre objetos e componentes est correta, se a integrao 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 7 de 53
antes da entrega do software. Descreve ainda as atividades deste fluxo, executores, produtos gerados e contextualizao em cada fase do projeto. Captulo 8 Fluxo de Implantao Descreve o fluxo de trabalho para Implantao dos produtos de software desenvolvidos, com suas atividades, executores, produtos gerados e contextualizao em cada fase do projeto. Captulo 9 Recomendaes e Observaes Apresenta observaes e recomendaes relevantes, relativas metodologia e ao processo de desenvolvimento de software, de uma maneira geral. Captulo 10 Modelos Anexos ndice com os modelos dos documentos a serem gerados, de acordo com a recomendao desta metodologia. Captulo 11 Produtos Resultantes da Metodologia - Apresenta a consolidao dos produtos resultantes da metodologia e a relao entre estes e os perfis tcnicos necessrios para sua elaborao. Captulo 12 Validao e Aceitao de Produtos Descreve os critrios que devem ser considerados na validao e aceitao de produtos e subprodutos do ciclo de desenvolvimento de software.
8 de 53
2 VISO GERAL DO PROCESSO UNIFICADO

2.1 Viso 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 exigncias das organizaes, das reas de aplicao, 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 caractersticas mais realistas de desenvolvimento. O sucesso da sua aplicao est na definio das iteraes mais adequadas, que vo produzir as verses intermedirias 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 utilizao da metodologia do Processo Unificado, cada fase ter o nmero de iteraes necessrias para a completude do seu objetivo. A quantidade de iteraes ser determinada de acordo com a necessidade, complexidade e estratgia de abordagem, para os requisitos a serem desenvolvidos. O fluxo de trabalho se repete a cada iterao, dentro de uma fase, para que uma verso 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 no ir para a prxima fase. O ciclo de vida do Processo Unificado pode ser entendido por meio de duas perspectivas diferentes, porm integradas: A perspectiva gerencial, atravs de uma viso dirigida pelas fases do processo; A perspectiva da engenharia (ou do contedo), atravs dos fluxos de trabalho, que so compostos por seqncias especficas de atividades.
2.1.1 Fases do Processo

Concepo (Inception): nesta fase que so entendidos os requisitos funcionais do sistema, o escopo que o sistema deve atender e as condies delimitadoras deste escopo (contexto do negcio). Nesta fase so determinados os casos de uso e os principais cenrios que iro direcionar as principais questes de anlise e projeto do sistema. Na perspectiva gerencial, so aqui considerados os critrios de sucesso, a avaliao de risco, a estimativa de recursos necessrios e o plano para a fase, mostrando quais sero os produtos entregues. Na fase de concepo ainda estudada e demonstrada uma arquitetura candidata, relativa aos principais cenrios.
9 de 53
Elaborao (Elaboration): Na fase de elaborao ocorre o entendimento e descrio completos, dos aspectos funcionais do sistema, bem como a entrega do prottipo final de interface com o usurio que materializa este entendimento. Nesta fase estabelecido o plano de projeto e definida a sua arquitetura. As metas da fase de elaborao so a anlise do domnio do problema, o estabelecimento da linha bsica da arquitetura, e o desenvolvimento do plano de projeto. Aqui so eliminados os elementos de risco mais alto para o projeto, em decorrncia da maioria dos requisitos do sistema j ter sido descrita. Construo (Construction): Nesta fase desenvolvido o sistema. Na fase de Construo, o produto resultante poder ser utilizado pelo cliente, o que implica na necessidade da descrio dos critrios de aceitao. Ao final desta fase decidido se o software, o ambiente e os usurios esto prontos para se tornarem operacionais. Transio (Transition): a fase em que o sistema fornecido aos seus usurios finais.
2.1.2 Prototipao
A prototipao um instrumento poderoso que demonstra parte ou a totalidade dos comportamentos de um sistema, observveis externamente. Deve ser utilizada para: Obter o retorno em relao a uma soluo proposta; Constituir um demo do domnio do problema; Validar requisitos conhecidos; Descobrir requisitos desconhecidos. Ferramentas para prototipao incluem: Programas para demonstrao; Simulaes. A prototipao facilita o entendimento dos comportamentos do sistema e deve ser utilizada, sobretudo em casos de terceirizao de servios, 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 confiveis; Para melhorar a definio de caractersticas. Neste documento estaremos trabalhando com dois tipos distintos de prottipo: O prottipo de interface com o usurio; O prottipo arquitetural. Prottipos devem ser construdos cedo, tanto durante a fase de Concepo quanto no incio da fase de Elaborao e sempre antes que todo o sistema (incluindo a sua interface com o DAC/GIT Gerncia de Informtica e Telecomunicaes 10 de 53
usurio definitiva) esteja analisado, projetado e implementado, j que seus principais propsitos so 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 validao antecipada necessrio levar em conta que um prottipo 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 alcanar os seus objetivos. Prottipos de interface com o usurio podem ser utilizados pelo analista (e projetista) do sistema, com vrios objetivos, em momentos distintos ou em um determinado momento escolhido: Relativamente elaborao de casos de uso, para entender a interface com o usurio referente a um caso de uso; Relativamente anlise de objetos, para entender como a interface com o usurio influencia a anlise do sistema; Relativamente ao projeto, para entender como a interface com o usurio 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 prottipo arquitetural ocorre normalmente em menor nmero que os prottipos de interface com o usurio e tem um carter menos descartvel do que estes. Ele utilizado pelo arquiteto para validar e aprovar as principais decises arquiteturais e , geralmente, a base para evoluo visando a arquitetura definitiva.
2.1.3 Fluxos de Trabalho (Seqncias de Atividades)

Fluxo de Requisitos (Requirements): Descreve o mtodo para a identificao dos requisitos, baseado em casos de uso. Fluxo de Anlise (Analysis): Descreve a viso de arquitetura com nfase em O Qu vai ser feito. Fluxo de Projeto (Design): Descreve a viso de arquitetura com nfase em Como ser feito. Fluxo de Implementao (Implementation): Considera o desenvolvimento do software, o teste de unidade e a integrao. Fluxo de Teste (Test): Descreve os casos de teste, os procedimentos e as medidas para acompanhamento de erros. Fluxo de Implantao: Descreve os procedimentos para implantar o software no ambiente desejado.
11 de 53
2.1.4 Ciclo de Vida

A seqncia das quatro fases constitui o ciclo de vida do Processo Unificado sendo que o primeiro ciclo de realizao das quatro fases resulta na primeira verso do software. A menos que o produto no tenha continuidade, os prximos ciclos se repetem com a mesma seqncia das fases, mas com nfases diferentes, dependendo das novas verses. Estes ciclos subseqentes so chamados de ciclos evolutivos. medida que o produto evolui atravs de iteraes dos ciclos, novas verses so produzidas. Esta evoluo organiza o processo na dimenso tempo. A figura a seguir reflete o processo de evoluo atravs dos ciclos evolutivos:
Concepo Concepo Tempo
Elaborao Elaborao
Construo Construo
Transio Transio
Evoluo Evoluo
Verso 1
Ciclo de desenvolvimento inicial
Elaborao Elaborao
Construo Construo
Transio Transio
Evoluo Evoluo
Verso 2
Ciclo de evoluo 1
Elaborao Elaborao
Construo Construo
Transio Transio
Evoluo Evoluo
Verso n...
Ciclo de evoluo n...
As iteraes 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 especficos e componentes correspondentes. Um ciclo de desenvolvimento tpico tem trs nveis de complexidade e, para cada nvel, existe a sugesto da quantidade de iteraes que devem existir. importante lembrar que estas quantidades so apenas para referncia e que a real quantidade de iteraes por fase, em um projeto, vai depender de suas caractersticas particulares e da deciso dos seus participantes. De um modo geral, a fase de construo tem n iteraes.
12 de 53
O quadro seguinte constitui a referncia para a quantidade de iteraes por ciclo de desenvolvimento e de iteraes por fase do ciclo: Ciclo iterativo Baixo Tpico Alto Total de iteraes em um ciclo 3 6 9 Nmero de iteraes por fase [C, E, C, T] [0, 1, 1, 1] [1, 2, 2, 1] [1, 3, 3, 2]
Pela perspectiva da engenharia (ou do contedo), os fluxos de trabalho atravessam as diferentes fases do ciclo e so repetidos para cada iterao, dentro de cada fase. A figura seguinte apresenta a interseo entre as fases e os fluxos de trabalho do processo:
Organizao com base no Tempo Fases

Organizao com base no Contedo
Fluxos de Trabalho do Processo: Modelagem do Negcio Requerimentos Anlise e Projeto
Concepo Elaborao
Construo
Transio
Co mp le
me nt
arie d
ade
Implementao Testes Implantao Iteraes Preliminares Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1
Iteraes
O fluxo de atividades relativo Modelagem do Negcio e os fluxos gerenciais relativos ao Gerenciamento do Projeto e ao Gerenciamento de Configurao e Verso, no esto sendo considerados nesta verso.
13 de 53
Outra modificao em relao figura anterior e adotada neste documento diz respeito ao fluxo de trabalho de Anlise e Projeto. Neste documento, o referido fluxo foi desmembrado em dois fluxos separados, o Fluxo de Anlise e o Fluxo de Projeto, a fim de deixar mais clara a diferena que existe entre as atividades e artefatos de anlise e de projeto. Enquanto no primeiro a preocupao com o Qu o sistema vai fazer, no segundo esta preocupao est voltada para Como o sistema far aquilo que foi identificado que teria que fazer. A separao em dois fluxos torna clara esta fronteira, facilitando o entendimento dos objetivos das suas atividades. Pode ser observado, atravs da figura acima, que os fluxos de trabalho tm maior nfase em momentos diferentes. O nvel 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 Concepo e de Elaborao, da mesma forma que o fluxo de Implementao tem maior nfase na fase de Construo e o de Implantao na fase de Transio. Podemos verificar tambm que os fluxos de trabalho so complementares (ou incrementais) quanto ao contedo e que, se traarmos uma linha reta diagonal imaginria, unindo as partes de maior atividade de cada fluxo, obtemos uma idia muito prxima de como o produto do trabalho (ou seu contedo) incrementado no tempo, por meio dos fluxos de trabalho e atravs das fases.
14 de 53
2.1.5 Rastreabilidade
Uma caracterstica 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 aplicao. Os modelos criados no so estanques e influenciam-se mutuamente para agregar valor e refletir a evoluo do sistema, conforme mostrado na figura a seguir:
Definio do Problema Espao do Espao do Problema Problema
Necessidades Documento de Viso Caractersticas Requisitos de Software
Modelo de Casos de Uso
Modelo de Anlise e Projeto Modelo de Testes Modelo de Implementao
Assim, o processo permite estabelecer que cada necessidade tem caractersticas especficas, que cada uma destas caractersticas demanda um conjunto especfico de requisitos que, por sua vez, so representados pelo modelo de casos de uso. Cada caso de uso tem sua realizao correspondente no modelo de anlise e projeto, tem seus artefatos correspondentes no modelo de testes e tem relao com os componentes especficos que o implementam, no modelo de implementao. O processo tem que ser dirigido pelos casos de uso (que constitui a viso dos requisitos por parte do usurio) mas, conforme pode ser observado na figura anterior, todos os modelos tm que ter relao de rastreabilidade entre si. DAC/GIT Gerncia de Informtica e Telecomunicaes 15 de 53
R R a as tr tr ea ea bi bi i li da da de de
Espao da Soluo
2.1.6 Reduo dos Riscos

Talvez a caracterstica mais importante do conceito do processo unificado seja a reduo significativa do risco, a partir da utilizao 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 decises do projeto, antecipando tambm as aes de resposta s incertezas, conforme mostrado na figura a seguir:
Diminuio dos Riscos:
Desenvolvimento Waterfall Desenvolvimento Iterativo
RISCO
Reduo do Risco
Melhor entendimento dos requisitos e do sistema
PRAZO
2.1.7 Melhores Prticas (Uma Reforando a Outra)

O processo unificado permite a utilizao das principais melhores prticas para desenvolvimento de software. No caso das melhores prticas apresentadas a seguir, o todo maior que a soma das partes j que cada melhor prtica refora o uso e valor obtido pela seguinte e, em alguns casos, pr-requisito para a sua existncia.
Melhores Prticas Desenvolver Iterativamente Gerenciar Requisitos Usar Arquitetura de Componentes Modelar Visualmente (UML) Verificar Continuamente a Qualidade Gerenciar Mudanas
Assegurar o envolvimento do usurios em toda a evoluo dos requisitos Validar decises arquiteturais cedo no ciclo de vida do sistema Tratar incrementalmente a complexidade de projeto e implementao Medir a qualidade muitas vezes e desde cedo no ciclo de vida do sistema Evoluir as bases de referncia de forma incremental
16 de 53
2.2
Verificao no Processo Unificado
O desenvolvimento iterativo permite que a equipe de desenvolvimento melhore o entendimento dos requisitos e dos artefatos, atravs dos incrementos ou verses, detectando, no incio do projeto, os pontos crucias. O Processo Unificado, da mesma forma que os demais modelos de processo, prev pontos de verificao ao longo do desenvolvimento do software, para manter a qualidade do processo e do produto. Ao final da fase de concepo, so respondidas as seguintes questes: O escopo do sistema est claro? Os requisitos chaves do sistema foram acordados com os participantes? Foram identificados os riscos crticos para a execuo e sucesso do projeto? O produto ir gerar o retorno esperado pelo investimento? vlido para a organizao continuar com o projeto? Os investidores concordam com os objetivos? O final da fase de elaborao fornece as informaes sobre a arquitetura e, portanto, as seguintes perguntas tm 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? passvel de evoluo atravs 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 construo estabelece se o produto atende a capacidade operacional inicial e, portanto, as seguintes perguntas tm que ser respondidas: O produto atingiu a estabilidade operacional que permita uma verso para teste beta no ambiente do usurio? Os usurios e os projetistas esto satisfeitos com o sistema? Os pr-requisitos do sistema foram atendidos atravs da seqncia de iteraes? A fase de transio estabelece se o produto est pronto e se a verso final estar disponvel para a comunidade de usurios. Portanto, as seguintes perguntas tm que ser respondidas: O produto passou pelo teste de aceitao conduzido pelo usurio? Os usurios testaram as funes chave, representadas nos casos de uso? A documentao a ser entregue para o usurio tem qualidade aceitvel? O cliente e usurios esto satisfeitos com o produto?
17 de 53
A seguir esto relacionados os pontos principais a serem observados durante as fases: Obter os requisitos de forma correta, atravs dos modelos de caso de uso e de anlise, bem como a partir da realimentao dos usurios, 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 construo de blocos reutilizveis que possam reduzir o custo de desenvolvimento, diminuir o tempo de entrega do produto e aumentar a qualidade. Utilizar a UML para a elaborao dos artefatos e para comunicao entre os integrantes da equipe de projeto, de forma a estabelecer um padro de comunicao para a equipe, j que a UML uma linguagem que representa o software nos diversos estgios do desenvolvimento. Basear o desenvolvimento em iteraes, em funo de seus produtos oferecem vantagens, tais como a possibilidade do trabalho ser realizado por um grupo pequeno, com risco controlado e pontos de verificao e avaliaes freqentes. Gerenciar os riscos, identificando-os, analisando-os e realizando os planos de resposta decorrentes, visando sua mitigao, transferncia, contingncia ou aceitao, antes que possam aparecer no processo de desenvolvimento de software.
18 de 53
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 participaro das diversas atividades de desenvolvimento dos artefatos (produtos) associados a cada fluxo de trabalho desta metodologia. Estes executores no traduzem cargos ou funes dos profissionais expressando, apenas, os papis que estes profissionais iro desempenhar em determinados momentos do ciclo do projeto e de acordo com as atividades do fluxo que estiver sendo trabalhado. A descrio dos papis, a seguir apresentada, deve ser vista como uma orientao sobre as habilidades ou perfis tcnicos necessrios s responsabilidades associadas a estes papis. Estas habilidades (ou perfis tcnicos) esto identificadas sob o prisma dos integrantes da equipe desenvolvedora do sistema. Dentro deste contexto, por exemplo, um usurio (ou qualquer outro profissional) que atue na especificao de requisitos estar desempenhando o papel de analista de sistemas. Ainda em relao ao conceito de papel como habilidades ou perfis tcnicos necessrios, convm salientar que, da mesma forma que seus fluxos correspondentes, nesta verso, os perfis tcnicos relativos s atividades dos fluxos para Modelagem do Negcio, Gerenciamento do Projeto e Gerenciamento de Configurao e Verso, no esto considerados. Os papis referentes s habilidades necessrias para desempenhar as atividades destes fluxos seriam, respectivamente, o analista/projetista de negcios (ou soluo), o gerente de projetos e o gerente de configurao.
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 tcnicos ao longo do projeto, estabelecendo a estrutura completa para cada viso da arquitetura, decompondo a viso e agrupando os elementos e as interfaces, entre estes e as principais decises da arquitetura do sistema.
2.3.3 Desenvolvedor
Desenvolve e testa componentes de acordo com os padres adotados para o desenvolvimento do sistema. Quando estes forem testados, outros componentes para suporte aos testes tambm sero criados. Ele tambm poder ajustar as classes, com suas respectivas operaes, atributos e relacionamentos, desde que isto no comprometa a arquitetura.
19 de 53
2.3.4 AD (Administrador de Dados) / DBA (Administrador do Banco de Dados)

O AD, ou o DBA de acordo com a poltica que seja estabelecida, define as tabelas, ndices, constraints, triggers, stored procedures, tablespaces e parmetros de armazenamento, entre outras necessidades especficas da construo de banco de dados. Geralmente o AD est voltado para as atividades da parte lgica dos dados e o DBA para a parte fsica e de implementao do banco.
2.3.5 Cliente
Dirige e formaliza os testes de validao e aceitao do sistema.
20 de 53
3 FLUXO DE REQUISITOS
Descreve o mtodo para a identificao dos requisitos, baseado em casos de uso, sendo que os modelos de referncia (templates) para os documentos a serem utilizados, so encontrados no captulo 10 MODELOS PARA SUPORTE METODOLOGIA.
3.1
Contexto do Fluxo de Requisitos nas Fases do Ciclo
Todas as atividades do fluxo de Requisitos so executadas em todas as fases, tendo maior nfase em questes especficas (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 questes que tm maior nfase em cada uma das fases:
Concepo Estabelecimento da viso do usurio em relao ao problema; Delimitao do escopo do projeto do sistema de software; Prottipos iniciais de Interface com o Usurio; WBS do Produto. Elaborao Construo Transio
Entendimento completo e descrio dos aspectos funcionais do sistema; Prottipo Final de Interface com o Usurio;
Reviso dos requisitos; Mudanas de Requisitos;
Ajuste fino dos artefatos do fluxo de requisitos revisitados.
3.1.1 Na Fase de Concepo

Nesta fase, o fluxo de trabalho Requisitos est centrado em estabelecer a viso do problema, por parte do usurio, bem como em entender os requisitos funcionais e estabelecer a delimitao do escopo do projeto do sistema de software.
3.1.2 Na Fase de Elaborao

Nesta fase, o objetivo obter o mais completo entendimento dos aspectos funcionais do sistema, atravs de sua respectiva descrio.
21 de 53
3.1.3 Na Fase de Construo

Nesta fase, alguns requisitos podem ser revistos ou podem, ainda, ser identificados novos requisitos. De qualquer forma, estes novos requisitos podem significar alterao no escopo do sistema e tm que ser formalmente tratados e associados.
3.1.4 Na Fase de Transio

Aqui os artefatos do fluxo de Requisitos so novamente visitados e podero 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 restries preliminares o sistema estar sujeito. Estes aspectos sero capturados utilizando o documento de definio do problema.
3.2.2 Analisar o Problema

Identificar os colaboradores, envolvidos ou interessados (stakeholders) do projeto, conseguir consenso das partes envolvidas em relao ao problema a ser resolvido, definir as fronteiras do sistema e identificar a quais restries o sistema estar sujeito. Estes aspectos so capturados utilizando o documento de viso e o documento de especificao suplementar.
3.2.3 Gerar Especificao Funcional

Os requisitos funcionais so capturados de diversas formas (documentos j existentes, entrevistas, visitas ao ambiente dos usurios, reunies de JAD, eventuais prottipos preliminares de interface com o usurio, etc.) por meio da utilizao do documento de viso e so consolidados na viso padronizada de Casos de Uso que reflete a viso funcional das partes interessadas (stakeholders). Para esta viso so identificados os atores, os casos de uso, seus objetivos e linhas gerais de execuo. As eventuais sadas (como o formato esperado de um relatrio), telas de acesso, regras de negcio e elementos de dados, tambm so capturados e registrados. A especificao de cada caso de uso composta das seguintes partes: Descrio do caso de uso; Interface com usurio; Regras de negcio e dados, onde as regras de negcio e os dados que sejam comuns a mais de um caso de uso so capturados em um nico documento para todo o sistema; Especificao suplementar contendo os requisitos no funcionais, alm dos requisitos funcionais que sejam comuns a mais de um caso de uso. Deve ser realizada a prototipao da interface grfica com o usurio, a fim de capturar, entender e validar seus requisitos. DAC/GIT Gerncia de Informtica e Telecomunicaes 22 de 53
Tanto a descrio de cada caso de uso quanto a sua interface correspondente so documentadas em conjunto, em um documento por caso de uso, a fim de facilitar a sua manipulao por mais de uma pessoa.
3.2.4 Validar Especificao Funcional

As especificaes funcionais levantadas so validadas junto s partes interessadas (stakeholders), atravs das especificaes e dos prottipos de interface com o usurio, a fim de garantir a aderncia em relao s impresses 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 atravs da decomposio do escopo em pacotes de trabalho (WBS do produto), os quais iro 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 estaro desempenhando o papel de: Analistas de Sistemas; Desenvolvedores.
3.4
Produtos Gerados Pelo Fluxo de Requisitos
3.4.1 Glossrio
Documento que define e esclarece os principais termos utilizados no projeto, possibilitando uma nica definio, independentemente de pessoa ou rea especfica. Observar que o glossrio ser preenchido e consultado ao longo de todo o projeto.
3.4.2 Definio do Problema

Documento que visa contextualizar o problema e registrar e formalizar as necessidades dos usurios.
3.4.3 Documento de Viso

O documento de viso expressa a viso geral dos requisitos do projeto, fornecida pelo cliente, provendo as bases contratuais para os requisitos tcnicos mais detalhados.
23 de 53
3.4.4 Especificao dos Casos de Uso (Objetivos e Linhas Gerais)

O propsito deste documento descrever os objetivos do Caso de Uso (um ou, no mximo, dois pargrafos) e os principais passos de execuo, na forma de tpicos.
3.4.5 Diagrama de Casos de Uso

Representao grfica dos casos de uso e atores identificados, agrupados em pacotes (grupos de casos de uso de mesma categoria) para facilitar a compreenso.
3.4.6 Prottipo de Interface com o Usurio

Um ou mais prottipos de interface com o usurio contendo, dependendo do detalhamento de requisitos existente, apenas o desenho das telas, as telas e navegao correspondente ou, ainda, as telas, navegao e algumas regras de negcio especficas, de acordo com aquilo que se deseja identificar e validar. Quanto mais cedo realizado um prottipo mais riscos so eliminados. Por outro lado, h que se levar sempre em conta que, embora importante, um prottipo tem que ser sempre significativamente mais barato e fcil de construir que seu correspondente definitivo e que, quanto mais cedo ele realizado maior seu carter descartvel.
3.4.7 Especificao Suplementar

Este documento registra os requisitos do sistema que no foram possveis capturar de maneira clara nas descries dos casos de uso, ou que envolvem mais que um caso de uso do sistema. Este documento possui: Requisitos legais, regulamentos e padres que devam ser utilizados na aplicao. Atributos de qualidade do sistema a ser construdo, incluindo usabilidade, performance e requisitos de suporte. Outros requisitos como sistema operacional, ambientes de operao, requisitos de compatibilidade e restries de projeto. Regras de negcio do sistema comuns a mais de um caso de uso.
3.4.8 Termo de Aceite da Especificao Funcional

Documento que formaliza o aceite da especificao funcional, por parte do cliente, constituda pelo conjunto de produtos anteriormente descritos para este fluxo de trabalho.
24 de 53
4 FLUXO DE ANLISE
Este fluxo de trabalho descreve a viso de arquitetura, com foco No Que deve ser feito e realiza o detalhamento dos requisitos, sendo que os modelos de referncia (templates) para os documentos a serem utilizados, encontram-se relacionados no captulo 10 MODELOS PARA SUPORTE METODOLOGIA.
4.1
Contexto do Fluxo de Anlise nas Fases do Ciclo
Todas as atividades do fluxo de Anlise so executadas na maioria das fases, tendo maior nfase em questes especficas (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 anlise, nas fases do ciclo de vida do sistema, mostrando as questes que tm maior nfase em cada uma das fases:
Concepo Modelagem preliminar das classes de negcio (viso esttica); Elaborao Construo Transio
Entendimento do sistema o mais completo possvel; Classes de Negcio e Associaes; Contratos do sistema; Anlise inicial para o prottipo arquitetural;
Ajustes no modelo; Reflexo das mudanas de requisitos no modelo;

O foco, nesta fase, a modelagem do modelo preliminar das classes de negcio identificadas para o sistema (viso esttica do modelo). Este documento considera que esta modelagem constitui apenas uma representao das classes de negcio, a partir de processos de negcio do ONS que j se encontram definidos e modelados. O modelo de classes de negcio ser til no desenvolvimento dos diagramas de classes, no eventual projeto de workflows e em outras partes do projeto do sistema.
25 de 53

Nesta fase, o entendimento do sistema tem que ser o mais completo possvel (requisitos bem detalhados) considerando: O esclarecimento sobre o que o sistema deve fazer; O registro do conjunto de classes de negcio e suas associaes; A anlise das responsabilidades das operaes de cada caso de uso em relao ao sistema (contratos do sistema); A anlise inicial do prottipo arquitetural.

Nesta fase, as atividades de anlise so de ajustes no modelo. Contudo, eventuais demandas (novas funcionalidades, solicitaes de mudanas etc.) so tambm registradas nesta fase. Observar que alteraes ou ampliaes do escopo do sistema tm que ser formalmente tratadas, para minimizar riscos de no cumprimento do plano do projeto.
4.2
Atividades do Fluxo de Anlise
4.2.1 Refinar Casos de Uso

Os casos de uso so investigados profundamente para que se tenha todo o seu fluxo principal, fluxos alternativos, alm das pr e ps-condies para a execuo 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 Negcio

As classes de negcio do sistema so definidas de acordo com os elementos de dados que tiverem sido capturados nos casos de uso. So identificadas: a estrutura de herana, associaes entre as classes, seus respectivos papis nestas associaes, assim como eventuais tipos de dados especficos do domnio em questo. Para clareza e objetividade do modelo, as classes so organizadas em pacotes, estando agrupadas de acordo com critrios definidos pela equipe de desenvolvimento. Desta forma, no recomendado um grande diagrama com todas as classes do sistema, mas sim vrios pequenos diagramas.
4.2.3 Definir Responsabilidades das Operaes de cada Caso de Uso em Relao ao sistema (Contratos do Sistema)
Para cada caso de uso, so identificadas as suas operaes e o que cada operao se compromete a gerar como resultado, com foco na descrio das suas responsabilidades em relao ao sistema como um todo, considerando o que o sistema deve fazer (viso caixa preta) e no como estas responsabilidades sero resolvidas. Para cada caso de uso, o sistema visto como um grande objeto que recebe os seus estmulos e respectivos parmetros. Esta identificao representada atravs de um diagrama de seqncia
26 de 53
de sistema, composto basicamente de uma instncia de cada ator, um objeto representando o sistema e as operaes que envolvem o caso de uso. Cada operao identificada possui um contrato de responsabilidades em relao ao sistema, que especifica e descreve o seu resultado, sendo expresso em termos de pr e ps-condies. A prcondio apresenta o estado do sistema antes da execuo da operao e a ps-condio apresenta o estado do sistema aps a execuo da operao, descrevendo quais os objetos e as ligaes que sero criadas, destrudas e modificadas, bem como os resultados que tero que ser retornados. Observao: O uso da especificao das responsabilidades das operaes de cada caso de uso em relao ao sistema (contratos de sistema) proposto por alguns mtodos 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 Anlise
Os executores das atividades do fluxo de trabalho de Anlise estaro desempenhando o papel de: Analistas de Sistemas.
4.4
Produtos Gerados
4.4.1 Diagramas de Casos de Uso

Representao grfica dos casos de uso e dos atores identificados, agrupados em pacotes (grupos de casos de uso de mesma categoria) para facilitar a compreenso.
4.4.2 Especificao dos Casos de Uso

Documento que contm a especificao completa do caso de uso, identificando seu objetivo, fluxo principal, fluxos alternativos, atores, regras de negcio especficas deste caso de uso e suas pr e ps-condies.
4.4.3 Especificao Suplementar

Este documento registra requisitos no 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 negcio em questo. Ele decomposto em: Requisitos legais, regulamentos e padres que devam ser utilizados na aplicao. Atributos de qualidade do sistema a ser construdo, incluindo usabilidade, performance e requisitos de suporte. Outros requisitos como sistema operacional, ambientes de operao, requisitos de compatibilidade e restries de projeto. Regras de negcio do sistema comuns a mais de um caso de uso ou para o sistema como um todo.
27 de 53
4.4.4 Responsabilidades das Operaes de cada Caso de Uso em Relao ao Sistema (Contratos do Sistema)
Documento que formaliza as responsabilidades de cada operao identificada. constitudo pelo nome da operao e respectivos parmetros, a referncia cruzada com o caso de uso, as pr e ps-condies. O preenchimento das ps-condies restringe-se ao vocabulrio do modelo esttico, ao invs de descrever o algoritmo, informando-se o estado do sistema resultante da operao. Neste documento tambm tem que constar o diagrama de seqncia do sistema, representando as operaes de cada caso de uso e tendo o sistema como um nico objeto que recebe os estmulos dos atores.
4.4.5 Termo de Aceite das Responsabilidades das Operaes de cada Caso de Uso em Relao ao Sistema (Contratos do Sistema)
Documento que formaliza o aceite das responsabilidades das operaes de cada caso de uso em relao ao sistema (contratos do sistema), por parte do cliente.
28 de 53
5 FLUXO DE PROJETO
Descreve a viso de arquitetura, voltada para Como as operaes do sistema sero resolvidas, garantindo a definio da arquitetura a ser utilizada antes de ser iniciada a construo. Os modelos de referncia (templates) para os documentos a serem utilizados encontram-se relacionados no captulo 10 MODELOS PARA SUPORTE METODOLOGIA.
5.1
Contexto do Fluxo de Projeto nas Fases do Ciclo
Todas as atividades do fluxo de Projeto so executadas na maioria das fases, tendo maior nfase em questes especficas, 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, mostrando as questes que tm maior nfase em cada uma das fases:
Concepo Eleio preliminar dos casos de uso para o prottipo arquitetural; Eventual antecipao de alguns aspectos da arquitetura, em razo de riscos; Primeiras restries / definies para a arquitetura; Elaborao Construo Transio
Projeto e validao da arquitetura; Prottipo arquitetural que implemente e valide as decises de projeto mais importantes;
Complementao e evoluo do modelo arquitetural;

Este fluxo de trabalho far uma eleio preliminar dos casos de uso para o prottipo arquitetural e capturar as primeiras restries e/ou definies com influncia significativa na arquitetura, como por exemplo, a determinao do uso de uma tecnologia. Dependendo do contexto, do grau de incerteza e dos riscos associados ao sistema que ser desenvolvido, pode ser necessria a antecipao de alguns aspectos da arquitetura para a fase de concepo, de maneira a tentar reduzir os riscos associados ao sistema. Neste caso, a fase de concepo, torna-se, naturalmente, um pouco mais longa.
29 de 53

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 construo de um prottipo arquitetural, que implemente as mais importantes decises de projeto e que seja suficiente para valid-las. Nesta fase, a construo da arquitetura inclui, tambm, a elaborao do modelo de dados lgico.

Nesta fase, o modelo do projeto ser complementado medida que o sistema for sendo construdo, representando os detalhes encontrados ao longo da evoluo do projeto.
5.2
Atividades do Fluxo de Projeto
5.2.1 Eleger Componentes Arquiteturais Significativos

A partir do conjunto de casos de uso, so eleitos os aspectos que sejam mais relevantes para a tomada de deciso, do ponto de vista da arquitetura. Estes aspectos relevantes iro traduzir-se em uma implementao real da deciso tomada, atravs da implementao 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 usurio, do tipo mestre-detalhe (estrutura clssica onde uma srie 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 comunicao com um hardware especfico, ou com um outro sistema ainda no construdo, seriam tambm 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 sucesso de decises tticas tomadas de maneira independente, a arquitetura tem que prover uma unificao 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, possvel prover uma base para reuso em larga escala, bem como dar suporte ao gerenciamento do projeto. O documento de viso e a especificao suplementar tm j que conter algumas restries arquiteturalmente significativas que, em conjunto com as descries dos casos de uso, constituiro as principais entradas para a descrio da arquitetura. A descrio geral da arquitetura do sistema ser ser feita de acordo com o modelo 4 + 1 vises. Este modelo determina que a arquitetura deve ter uma abordagem obrigatria viso do usurio e quatro outras vises opcionais de acordo com a natureza do sistema Viso Lgica, Viso de Implementao, Viso de Processo e a Viso de Implantao. Viso do Usurio Lista dos casos de uso ou cenrios que representem funcionalidades significativas e centrais do sistema final, ou que tenham uma grande cobertura arquitetural, isto , que exercitem vrios elementos de arquitetura, exijam intensamente ou exemplifiquem pontos arquiteturais delicados.
30 de 53
Viso Lgica Descreve as partes arquiteturais significativas do modelo de projeto, apresentando classes significativas e a descrio de suas responsabilidades, assim como importantes relacionamentos, operaes e atributos. Viso de Processo Descreve a decomposio 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 concorrncia e sincronismo do sistema, incluindo os principais modos de comunicao entre os processos, como as interrupes ou passagem de mensagens. Aborda tambm questes de desempenho e escalabilidade. Viso de Implementao descreve de maneira abrangente o modelo de implementao, a decomposio do software em camadas e subsistemas, alm de componentes arquiteturais significativos. Viso de Implantao - Descreve uma ou mais configuraes de redes fsicas, mostrando como os vrios elementos do software (executveis e outros componentes considerados em tempo de execuo) sero implantados e executados entre as plataformas e computadores, podendo existir referncia aos processos que foram mapeados na viso de processos. A descrio geral da arquitetura ir ainda considerar as estratgias de tratamento dos mecanismos gerais, tais como: persistncia, tratamento de excees, distribuio, interface com o usurio e comunicao 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 prottipo arquitetural no descartvel, que aplique todas as decises registradas e que evolua para o sistema final.
5.2.3 Elaborar Prottipo Arquitetural

O prottipo da arquitetura elaborado a fim de validar as decises e realimentar o sistema, para os ajustes necessrios, 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 sero ajustadas as decises arquiteturais sempre que necessrio, ou simplesmente evoludas a partir da arquitetura existente, mesmo porque estas decises podero ser reaproveitadas entre projetos diferentes.
5.2.5 Gerar Modelo do Projeto

Com base nas definies arquiteturais, os componentes de software iro sendo modelados, implementados e testados, gerando um ciclo gil de criao dos componentes. Eventualmente podero surgir ajustes para o prprio modelo, nas definies do sistema (um novo fluxo alternativo no caso de uso, por exemplo) ou ainda ajustes da arquitetura. O modelo do projeto ir compreender algumas vises para facilitar o entendimento do sistema. Para a construo destas vises so utilizados os diagramas da UML.
31 de 53
Viso do usurio: Representa o sistema a partir da perspectiva dos usurios. Um diagrama de caso de uso representa a funcionalidade provida pelo sistema para seus usurios externos, sendo composto por atores, casos de uso e seus relacionamentos. Suporte UML: diagrama de casos de uso. Viso estrutural: Representa aspectos estticos do sistema, na forma como so declarados. Suporte UML: diagrama de classes e de objetos. Viso Comportamental: Representa aspectos dinmicos do sistema. Suporte UML: diagramas de seqncia, colaborao, estados e atividades. Viso de implementao: Representa aspectos estruturais e comportamentais da realizao do sistema, tendo como base os componentes de implementao. Suporte UML: diagrama de componentes. Viso de Ambiente: Representa o espao fsico em que se deseja que o sistema seja realizado, contemplando a rede de recursos de processamento e a configurao de componentes de software em cada elemento fsico. Suporte UML: diagrama de implantao. Nesta atividade gerado o modelo do projeto, que compreende: O projeto detalhado das classes; A criao dos elementos necessrios para o banco de dados, tais como o diagrama de entidades e relacionamentos; O conjunto de componentes que sero implementados; Os diagramas que se faam necessrios.
5.3
Executores das Atividades do Fluxo de Projeto
Os executores das atividades do fluxo de trabalho de Projeto estaro desempenhando o papel de: Arquiteto; Desenvolvedor; AD (Administrador de Dados) / DBA (Administrador de Banco de Dados).
5.4
Produtos Gerados
5.4.1 Descrio da Arquitetura de Software

Documento que registra as decises arquiteturais do sistema.
5.4.2 Prottipo Arquitetural

Prottipo para o entendimento e validao das principais decises arquiteturais.
32 de 53
5.4.3 Modelo do Projeto

Composto por todos os diagramas e respectivas especificaes, necessrios para esclarecer as vises do sistema que est sendo desenvolvido. Tipicamente so construdos, os diagramas de classe e o diagrama de seqncia. Os diagramas de classes tm que conter ao menos as classes, os atributos e relacionamentos, organizados em pacotes e oferecendo vises em diferentes nveis, para anlise e projeto, e o diagrama de seqncia tem que apresentar a seqncia de mensagens trocadas entre os objetos de um determinado contexto.
5.4.4 Modelo Lgico do Banco de Dados

Diagrama de entidades e relacionamentos representando a estratgia de tabelas adotada para as classes identificadas. Este produto ter que estar em consonncia com a padronizao de banco de dados vigente no ONS. A referida padronizao encontra-se relacionada no captulo 10 MODELOS PARA SUPORTE METODOLOGIA.
33 de 53
6 FLUXO DE IMPLEMENTAO
Este fluxo de trabalho leva em considerao o desenvolvimento do software, formado por seus componentes, os testes de unidade e a integrao com os componentes j existentes. Os modelos de referncia (templates) para os documentos a serem utilizados encontram-se relacionados no captulo 10 MODELOS PARA SUPORTE METODOLOGIA.
6.1
Contexto do Fluxo de Implementao nas Fases do Ciclo
Todas as atividades do fluxo de implementao so executadas em todas as fases, tendo maior nfase em questes especficas (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 implementao, nas fases do ciclo de vida do sistema, mostrando as questes que tm maior nfase em cada uma das fases:
Concepo Elaborao Construo Transio
Principais restries para o ambiente de desenvolvimento.
Planejamento da Integrao do Sistema. Modelo Fsico Inicial do BD.
Implementao dos componentes; Modelo Fsico Atualizado do BD. Manuteno dos componentes criados;

Nesta fase so obtidas as principais restries para a estrutura do ambiente de desenvolvimento.

Na fase de elaborao planejada a integrao do sistema e seus subsistemas, e realizada a implementao inicial dos componentes de banco de dados (modelo fsico).
34 de 53

Nesta fase ocorre a implementao dos componentes do sistema em questo, incluindo aqueles relativos ao banco de dados fsico.

Na fase de transio ocorrem as eventuais manutenes dos componentes de sistema que foram criados e entregues.
6.2
Atividades do Fluxo de Implementao
6.2.1 Planejar Integrao

Planejar os subsistemas que sero implementados e a ordem de integrao. 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 integrao.
6.2.2 Preparar Ambiente de Desenvolvimento

O ambiente de desenvolvimento preparado de acordo com os padres definidos para serem utilizados pela equipe. Os principais aspectos a se considerar so: IDE de mesmo fornecedor, verso e plug-ins; Estaes de trabalho; Servidor (ou servidores de desenvolvimento); Instalaes fsicas; Definir estratgia de atualizao dos cdigos fonte.
6.2.3 Implementar Componentes de Software

Conforme planejado, os componentes de software so desenvolvidos, respeitando as determinaes 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 gerao de banco de dados e seu modelo fsico, a referncia cruzada de permisses por tabela e por campo, e a referncia cruzada de constraints, triggers e stored procedures com as regras de negcio que estes mecanismos implementam.
6.2.4 Realizar Testes Unitrios

Sempre que um componente de software implementado, o seu teste unitrio realizado e fica devidamente armazenado para futuras execues. O desenvolvedor tem que garantir que os testes do componente foram executados em sua totalidade e sem erros.
35 de 53
6.2.5 Integrar Componentes

Esta integrao realizada de forma automtica, com o apoio de uma ferramenta integrada ao ambiente de desenvolvimento. O ambiente e ferramenta tm que permitir o retorno situao anterior do sistema, no caso da entrada de um componente que ocasionou erro.
6.3
Executores das Atividades do Fluxo de Implementao
Os executores das atividades do fluxo de trabalho de Implementao estaro desempenhando o papel de: Arquiteto; Desenvolvedor; AD (Administrador de Dados) / DBA (Administrador de Banco de Dados).
6.4
Produtos Gerados
6.4.1 Componentes de Software

Artefatos de software criados (Classes; Interfaces com usurio; scripts e modelo fsico do banco de dados; referncia cruzada de permisses por sistema, por entidade/tabela e por campo; referncia cruzada de constraints, triggers e stored procedures, com as regras de negcio que estes mecanismos implementam; etc.) respeitando o planejamento e, principalmente, as decises de arquitetura, devidamente integrados aos outros componentes j criados. Os produtos relativos ao banco de dados tero que estar em consonncia com a padronizao de banco de dados vigente no ONS. A referida padronizao encontra-se relacionada no captulo 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 avaliao de seus resultados a partir da emisso de Certificados de Testes Unitrios conforme previsto no documento Roteiro dos Testes.
36 de 53
7 FLUXO DE TESTES
Este fluxo de trabalho descreve casos de teste, procedimentos e medidas para acompanhamento de erros e certificao do funcionamento do Sistema. Os modelos de referncia (templates) para os documentos a serem utilizados encontram-se relacionados no captulo 10 MODELOS PARA SUPORTE METODOLOGIA.
7.1
Contexto do Fluxo de Testes nas Fases do Ciclo
Todas as atividades do fluxo de testes so executadas em todas as fases do ciclo de vida do sistema, tendo nfase em questes especficas a cada iterao. A figura seguinte apresenta o contexto do fluxo de testes, nas fases do ciclo de vida do sistema, mostrando as questes que tm maior nfase em cada uma das fases:
Concepo Criao do Plano de Testes;
Elaborao
Construo
Transio
Ajustes do Plano de Testes; Criao dos Roteiros de Testes;
Ajustes dos Roteiros de Testes; Execuo dos Roteiros de Testes, medida que os pacotes vo sendo terminados;
Execuo dos Testes de Aceitao restantes at que se possa disponibilizar o sistema para implantao.

Nesta fase o plano de testes criado.

Nesta fase, o plano de testes pode sofrer algum ajuste e os roteiros de teste so criados.
37 de 53

Aqui os roteiros de testes podem sofrer ajustes. Cada roteiro de teste executado e seu resultado gerado. Os testes para aceitao iro ocorrendo conforme os pacotes de trabalho forem sendo terminados.

Os testes para aceitao que restarem so executados at que se possa disponibilizar o sistema para a sua implantao
7.2
Atividades do Fluxo de Testes
7.2.1 Elaborar Plano de Testes do Sistema

O plano de testes visa determinar a seqncia de realizao dos testes, e a descrio das verificaes. O documento tem que conter o objetivo do teste, tcnicas a serem utilizadas no teste, alm de critrios de finalizao e condies especiais, se aplicveis. Tambm tero que ser considerados os recursos e materiais de apoio necessrios. Os tipos de testes so: Testes Funcionais; Teste de Integridade dos Dados; Teste do Ciclo de negcio; Teste de Interface com Usurio; Teste de Desempenho e Performance; Teste de Carga; Teste de Resistncia Stress; Teste de Volume; Teste de Controle de Acesso e Segurana; Teste de Tolerncia falha e recuperao; Teste de Instalao; Teste de Configurao.
7.2.2 Projetar os Testes do sistema

O projeto dos testes tem o objetivo de identificar e comunicar a informao necessria para se preparar e executar os testes para cada caso de uso, respeitando as determinaes do plano de testes e gerando os roteiros de teste. Para cada ator que interage com o caso de uso, so identificados os valores de entrada, os resultados esperados e formas de verificao que podem ir, desde simples observao visual, at combinao de atividades complexas envolvendo aspectos no visuais. Os principais documentos de suporte a esta atividade so a descrio dos casos de uso e as responsabilidades das operaes de cada caso de uso em relao ao sistema (contratos do sistema).
38 de 53
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 no triviais como cargas especficas de dados, gerao de scripts para automatismo de execuo e preparao do ambiente operacional para os testes.
7.2.4 Executar os Testes de Sistema

Todos os testes planejados so executados, registrando-se os sucessos e fracassos de cada passo previsto para o teste. Os fracassos tm que direcionar as correes necessrias da implementao para se atingir o sucesso na totalidade.
7.2.5 Executar os Testes de Aceitao de Sistema

So conduzidos pelo cliente (juntamente com seus usurios) e realizados com base no documento de testes do sistema. Esta atividade resulta no termo de aceitao do sistema, liberando-o para implantao em produo.
7.3
Executores das Atividades do Fluxo de Testes
Os executores das atividades do fluxo de trabalho de Testes estaro desempenhando o papel de: Analista de sistemas; Desenvolvedor; Cliente.
7.4
Produtos Gerados
7.4.1 Plano de Testes

Documento que contm as linhas gerais dos testes que tero 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 necessria para a execuo de cada caso de uso.
7.4.3 Scripts de Testes

Scripts contendo as atividades automatizadas para a execuo dos testes.
7.4.4 Resultado dos Testes executados

Documento contendo os resultados (evidncias) dos testes e consideraes para eventuais correes e ajustes.
39 de 53
7.4.5 Testes de Aceitao

Resultados (evidncias) dos testes realizados pelo cliente (juntamente com seus usurios), com consideraes para eventuais correes e ajustes, alm do registro da aceitao do teste.
40 de 53
8 FLUXO DE IMPLANTAO
Este fluxo de trabalho descreve os procedimentos para preparar e implantar o software no ambiente desejado. Os modelos de referncia (templates) para os documentos a serem utilizados encontram-se relacionados no captulo 10 MODELOS PARA SUPORTE METODOLOGIA.
8.1
Contexto do Fluxo de Implantao nas Fases do Ciclo
As atividades do fluxo de implantao so executadas em todas as fases, tendo maior nfase em questes especficas 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 implantao, nas fases do ciclo de vida do sistema, mostrando as questes que tm maior nfase em cada uma das fases:
Concepo Planejamento Preliminar da Implantao; Plano de Entrega p/ esta fase; Restries para as entregas da prxima fase. Elaborao Reviso do Planejamento de Implantao; Estabelecimento da Infra-estrutura de Suporte; Plano de Entrega p/ esta fase; Restries para as entregas da prxima fase. Construo Reviso do Planejamento de Implantao; Desenvolvimento do Material de Suporte; Produo do Material de Apoio; Produo de Verso Beta; Plano de Entrega p/ esta fase; Restries para as entregas da prxima fase. Transio Reviso do Planejamento de Implantao; Desenvolvimento do Material de Suporte; Produo do Material de Apoio; Produo de Verses Beta; Aceitaes das Verses; Entrega das Verses de Produo; Plano de Entrega p/ esta fase;

Nesta fase realizado o planejamento preliminar da implantao, elaborado o plano de entrega para os produtos gerados dentro da fase e so obtidas as restries a serem consideradas para as entregas da prxima fase.

Na fase de elaborao feita a reviso do planejamento de implantao, estabelecida a infraestrutura de suporte, elaborado o plano de entrega para os produtos gerados dentro da fase e so obtidas as restries a serem consideradas para as entregas da prxima fase.
41 de 53

Nesta fase feita a reviso do planejamento de implantao, desenvolvido o material de suporte, produzido o material de apoio, produzida a verso beta (ao menos uma), elaborado o plano de entrega para os produtos gerados dentro da fase e so obtidas as restries a serem consideradas para as entregas da prxima fase.

Nesta fase realizada a reviso do planejamento de implantao, desenvolvido do material de suporte, produzido o material de apoio, so produzidas verses beta, so realizadas as aceitaes das verses, so entregues as verses de produo e elaborado o plano de entrega para os produtos gerados dentro da fase.
8.2
Atividades do Fluxo de Implantao
8.2.1 Elaborar Pano de Entrega

Planejar as entregas que ocorrero para os subprodutos do projeto e em cada fase do ciclo, que podem ir desde a entrega de simples documentos at verses completas da aplicao. O plano de entrega, para as entregas de cada fase, tem que ser validado com o cliente o mais cedo possvel, no incio da fase em questo.
8.2.2 Desenvolver Material de Suporte

Elaborar material de suporte implantao, para a efetiva entrega do sistema aos usurios. Os materiais de suporte tm que cobrir todas as informaes que possam ser requisitadas pelos usurios finais para instalar, operar ou utilizar o sistema entregue, alm de eventuais materiais de treinamento sobre estas demandas.
8.2.3 Produzir Verso de Homologao (Verso Beta)

Criar uma verso beta do sistema, a fim de solicitar retorno do cliente e usurios, relativo ao produto ainda em evoluo. Este retorno pode ser composto de novas solicitaes dos usurios, as quais podem resultar em novas caractersticas do produto, gerando uma solicitao de mudana.
8.2.4 Obter Aceitao Formal da Verso

O cliente precisa aceitar formalmente a verso de software produzida. Parte desta aceitao pode ser obtida com os testes de aceitao do sistema e a parte restante, com a entrega dos materiais de suporte, previstos de acordo com o plano.
42 de 53
8.2.5 Produzir Verso de Produo

Produzir a verso final do sistema a ser colocado no ambiente de produo do usurio, contendo o software e os artefatos necessrios para uso e instalao efetivos. O nmero de verses de produo depender do nmero de ciclos de vida evolutivos do sistema e das verses iterativas disponibilizadas.
8.2.6 Preparar Treinamento

Alm do material de suporte necessrio para o treinamento, o prprio treinamento tem que ser preparado com a identificao 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 verso para o ambiente de produo, j ter que estar estabelecida a estratgia de suporte e de controle de verses em produo. Caso esta estrutura no esteja criada, o projeto poder ficar comprometido, em funo do surgimento de demandas no controladas.
8.3
Executores das Atividades do Fluxo de Implantao
Os executores das atividades do fluxo de trabalho de Implantao estaro desempenhando o papel de: Analista de sistemas; Desenvolvedor.
8.4
Produtos Gerados
8.4.1 Plano de Entrega

Documento que constitui o planejamento das entregas que ocorrero para o projeto em cada fase do ciclo, contendo o escopo, o agendamento, o suporte necessrio, o processo e os resultados esperados da entrega.
8.4.2 Material de Suporte

O material de suporte requisitado para atendimento ao usurio, como: guia do usurio, guia de operao, demo on-line, help on-line, e apostilas de treinamento.
8.4.3 Verso de Homologao

Verso do sistema contendo os componentes de software, scripts de instalao e materiais de apoio, para avaliao do cliente (juntamente com seus usurios) relativa ao sistema.
43 de 53
8.4.4 Verso de Produo

Verso do sistema contendo os componentes de software, scripts de instalao e materiais de apoio, para ser implantada no ambiente de produo.
8.4.5 Aceitao de Verso

Documento formalizando o aceite do cliente para a verso em questo.
8.4.6 Treinamento
a execuo do treinamento, com infra-estrutura adequada, material didtico, instrutor qualificado e plano de aulas.
8.4.7 Infra-estrutura de Suporte

As decises relativas infra-estrutura de suporte estaro no plano do projeto.
44 de 53
9 RECOMENDAES E OBSERVAES
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 construo do software. Uma ferramenta C.A.S.E. (Computer Aided Software Engineering) deve ser considerada para este apoio. Ela no deve apenas servir para a modelagem de diagramas. As seguintes caractersticas devem ser tambm consideradas: Uso de repositrio para os elementos criados; Integrao entre os diagramas (alteraes em um elemento refletem em qualquer diagrama onde ele esteja presente); Gerao automtica de cdigo na linguagem que ser utilizada no Sistema; Capacidade de engenharia reversa (l programas e os transforma em diagramas); Facilidade de exportar diagramas como figuras; Gerao de arquivo em formato padro de intercmbio entre aplicaes XMI; Suporte a UML; Suporte a trabalho em equipe; Controle de verso; Gerao de relatrios a partir do seu repositrio; Integrao 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 caractersticas 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. imprescindvel o uso de um repositrio comum para os cdigos fonte, a fim de suportar a dinmica de desenvolvimento, permitindo o retorno de verso, check-in e check-out dos fontes. Algumas caractersticas relevantes de IDEs: Interface Grfica; Debug; Integrao com repositrio de cdigos fonte; Integrao com servidores de aplicao e servidores WEB; Complementao de cdigo; Facilidade de uso por parte da equipe de desenvolvimento; Agilidade no desenvolvimento. O repositrio de cdigos fonte, deve oferecer: Controle de verses; Check-in e check-out de documentos; Facilidade de backup e de restore; Controle de segurana de acesso.
45 de 53
9.1.2 Diagramas UML

A UML Unified Modeling Language ou Linguagem Unificada de Modelagem - foi criada para representar as diversas vises de um sistema de maneira grfica, de modo a tornar universal o modelo do sistema, independentemente do processo de desenvolvimento utilizado. No existe a obrigatoriedade do uso de todos os diagramas, e devem ser levados em considerao, no momento da modelagem, os seguintes pontos: Use tantos diagramas quantos forem necessrios para comunicar a viso do sistema; A criao de diagramas tem por objetivo facilitar o entendimento do sistema e prover vantagens para a sua implementao, e deve agregar valor. Somente o uso de diagramas no esgota a semntica de um modelo. Por isto, informaes textuais devero ser sempre acrescentadas para esclarecer o modelo; Um diagrama com 200 classes difcil de entender, organize os diagramas em pacotes. (pequenos grupos).
9.1.3 Automatizao dos Testes

Quanto maior e mais complexo for o sistema, mais complicada se torna a realizao de testes. Os testes so realizados em dois momentos: quando uma funcionalidade nova criada ou quando uma nova funcionalidade acrescentada ao sistema existente. Existem dois grupos bsicos de testes: os testes unitrios 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 manuteno. Testes intensos garantiro uma melhor qualidade do sistema. Os testes de sistema vo envolver aspectos complexos como, teste de carga, acessos simultneos e navegao, entre outros. Dependendo da criticidade envolvida no sistema, estes testes podem ser fundamentais para a sua aceitao. O uso de ferramentas para automatizar este tipo de teste fortemente recomendado. Deve ser observado que a necessidade dos testes existe independentemente da opo por um tipo de processo de desenvolvimento. A execuo de testes sem o suporte de ferramentas ter mais custo em tempo de preparao, execuo e certificao de seus resultados.
9.1.4 Melhores Prticas

Aspectos observados neste documento, que estejam criando trabalho desnecessrio, podem indicar que a metodologia deve ser revisada. A aplicao da metodologia deve conduzir a melhores prticas no processo de desenvolvimento, beneficiando o grupo de desenvolvimento de projetos e a empresa como um todo.
46 de 53
10 MODELOS PARA SUPORTE METODOLOGIA

Anexo 1: Modelo para Definio do Problema (Para acessar o modelo clique Definio do Problema.); Anexo 2: Modelo para Glossrio (Para acessar o modelo clique Glossrio.); Anexo 3: Modelo para Documento de Viso (Para acessar o modelo clique Documento de Viso.); Anexo 4: Modelo para Descrio de Caso de Uso (Para acessar o modelo clique Descrio de Caso de Uso); Anexo 5: Modelo de Especificao Suplementar (Para acessar o modelo clique Especificao Suplementar); Anexo 6: Modelo de Diagramas (Para acessar o modelo clique Diagramas); Observao: Este modelo utilizado sempre que necessrio enviar alguns diagramas para o cliente, em um documento formatado e sem que exista um outro meio, como por exemplo, gerao automtica a partir da ferramenta CASE, pgina WEB publicada para o cliente acessar e navegar pelo modelo do sistema, acesso direto e controlado do cliente prpria ferramenta CASE, ou algum outro meio acordado entre as partes. Anexo 7: Modelo para Termo de Validao e Aceitao de Produtos (Para acessar o modelo clique Termo de Validao e Aceitao de Produtos) Anexo 8: Modelo para as responsabilidades das operaes de cada caso de uso em relao ao sistema (Contratos de Sistema) (Para acessar o modelo clique Contratos de Sistema); Anexo 9: Modelo para Descrio da Arquitetura de Software (Para acessar o modelo clique Descrio da Arquitetura); Anexo 10: Manual de Procedimentos Padro do ONS para Banco de Dados (Para acessar o manual clique Padronizao 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);
47 de 53
11 PRODUTOS RESULTANTES DA METODOLOGIA

A figura seguinte apresenta os produtos resultantes da metodologia e como estes se encontram agrupados, para efeito de validao e aceitao, 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 validao/aceitao visando a monitorao dos riscos, a confirmao de um entendimento comum da soluo, o estabelecimento de bases para gerenciamento de mudanas e a comprovao de que os marcos estabelecidos para as fase foram alcanados, foi estabelecido o agrupamento a seguir de acordo com as fases em que a elaborao destes produtos tem maior nfase:
Para os produtos acima sublinhados existe um modelo de referncia disponvel sendo que, para o Termo de Aceite da Especificao Funcional, para o Termo de Aceite da Especificao Tcnica, para a Aceitao dos Testes e para a Aceitao de Verso, utilizado o mesmo modelo, que o Termo de Validao e Aceitao de Produtos.
48 de 53
O Prottipo Arquitetural contm as decises consideradas para modelo de arquitetura e como os diversos componentes estaro distribudos nesta. O prottipo da arquitetura elaborado a fim de validar as decises e realimentar o sistema para os ajustes necessrios, at que o modelo de arquitetura esteja pronto e maduro para refletir as funcionalidades requeridas pelo cliente. Sua verso final estar expressa na Descrio da Arquitetura de Software conforme modelo correspondente. O modelo de nome Diagramas ser utilizado para os produtos Modelo do Projeto, Modelo Lgico do Banco de Dados e Modelo Fsico do Banco de Dados, na eventualidade de no ser possvel entreg-los por meio de gerao automtica a partir da ferramenta CASE, de pgina WEB publicada para o cliente acessar e navegar pelo modelo do sistema, de acesso direto e controlado do cliente prpria ferramenta CASE, ou algum outro meio estabelecido para a questo. A Padronizao para Banco de Dados do ONS, anexo 10 deste documento, expressa os procedimentos padro, a serem seguidos, na elaborao dos Modelos Lgico e Fsico do Banco de Dados e correspondentes Permisses e Regras de Negcio. Estes produtos sero atualizados ao longo do ciclo, at ser estabelecida sua verso final. Os Certificados dos Testes de Unidade, assim como os Scripts de Testes e os Resultados dos Testes para os testes de integrao, sistema e aceitao, ou para os testes de aceitao das verses de homologao e de produo, so emitidos por quem realiza os testes e serviro para demonstrar as evidncias de sua elaborao e ratificar sua aderncia em relao 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 realizao. O Material de Suporte o material requisitado para atendimento ao usurio, como guia do usurio, guia de operao, 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 tambm no conta com um formato padro j que dever variar de acordo com o objeto de treinamento e de acordo com a estratgia definida com o cliente deste treinamento. Os Componentes de Software e as Verses de Homologao e de Produo constituem respectivamente os componentes individuais de cdigo ou o conjunto integrado destes componentes para uma determinada verso do sistema que esteja sendo entregue. Ainda conforme a figura anteriormente apresentada, os produtos devero ter sua aceitao formal realizada ao final de cada fase, porm a validao destes ocorre ao longo da fase de acordo com o que estiver previsto no Plano de Entrega que elaborado no incio da mesma. Assim, os produtos vo sendo validados medida que vo sendo elaborados, mas sua aceitao formal ocorre no final de cada fase. O Plano de Entrega fundamental para a entrega das verses na fase de transio, mas deve ser elaborado tambm um plano de entrega para cada fase do ciclo.
49 de 53
Os produtos da metodologia a serem entregues para cada fase do ciclo de vida do processo, so os seguintes: Na Concepo (produtos que constituem a Especificao Funcional): Plano de Entrega; Glossrio; Definio do Problema; Documento de Viso; Especificao dos Casos de Uso; Prottipo de Interface com o Usurio; Especificao Suplementar; Plano de Testes. Estes produtos sero aceites formalmente por meio do Termo de Aceite da Especificao Funcional. Na Elaborao (produtos que constituem a Especificao Tcnica): Especificao Funcional revisada e atualizada; Plano de Entrega; Contratos do Sistema; Modelo do Projeto; Modelo Lgico do Banco de Dados; Modelo Fsico do Banco de Dados; Permisses e Regras de Negcio do Banco de Dados; Prottipo Arquitetural; Descrio da Arquitetura de Software; Roteiros de Testes; Estes produtos sero aceites formalmente por meio do Termo de Aceite da Especificao Tcnica. Na Construo: Especificao Funcional revisada e atualizada; Especificao Tcnica revisada e atualizada; Plano de Entrega; Componentes de Software; Testes de Unidade; Certificados dos Testes de Unidade; Modelo Fsico do Banco de Dados (atualizado); Permisses e Regras de Negcio do Banco de Dados (atualizadas); Scripts de Testes; Testes de Aceitao (integrao, sistema e verses beta); Resultados dos Testes Executados; Estes produtos sero aceites formalmente por meio da Aceitao dos Testes.
50 de 53
Na Transio: Especificao Funcional revisada e atualizada; Especificao Tcnica revisada e atualizada; Plano de Entrega; Material de Suporte; Modelo Fsico do Banco de Dados (atualizado); Permisses e Regras de Negcio do Banco de Dados (atualizadas); Scripts de Testes; Verses de Homologao e Produo; Treinamento; Resultados dos Testes de Aceitao das Verses; Estes produtos sero aceites formalmente por meio da Aceitao das Verses.
11.1 Artefatos x Papis

A figura mostrada na pgina seguinte apresenta a relao entre os artefatos produzidos atravs da metodologia e os perfis tcnicos (ou papis) necessrios para sua elaborao. Conforme j foi explicitado, estes perfis tcnicos no traduzem cargos ou funes dos profissionais expressando, apenas, os papis que estes profissionais iro desempenhar em determinados momentos do ciclo do projeto e de acordo com as atividades do fluxo de trabalho que estiver sendo trabalhado. Os papis representados na figura a seguir, devem ser vistos como uma orientao sobre os perfis necessrios, de acordo com as responsabilidades associadas a estes papis.
51 de 53
M etodologia de D esenvolvim ento de S istem as: A rtefatos x P apis
Analista de Sistemas
D efin i o d o P roblem a
D oc um ento de V is o
E s pe cifica o de C as os de U s o
E s pec ific a o S uplem e ntar
T erm o A ce ita o E s pec if. Fun ciona l
P la no de E ntre ga C o ntra tos do S iste m a T erm o A c eit. E sp ecif. tcn ic a T erm o A c eit. tes tes Treinam en to
G los s rio
P lano d e T es tes
R oteiro dos Tes tes
Arquiteto
M od elo do P ro jeto
D es cri o da A rquitetura
P rottipo A rq uitetural
AD / DBA
M o delo Lg ic o d o B anc o de D ado s M odelo F s ic o Inic ia l do B D
M od elo Fs ico do B anc o d e D ados
P rot tip o de Interfac e c / o U s urio
S c rip ts de T este s V ers es do S oftw are T es tes de A c eita o
Desenvolvedor
C ertifica dos Tes tes U nit.
Tes tes de U n id ade
C om p onen tes de S oftware
M a terial de S u porte
Usurio / Cliente
Fo rm aliza o dos term os de V a lida o e A ce ita o
52 de 53
12 VALIDAO E ACEITAO DE PRODUTOS

Para todas as entregas de subprodutos e produtos, do ciclo de desenvolvimento de software, tem que ser previamente definido o conjunto de critrios para validao ou aceitao dos mesmos. Estes critrios tm sempre que incluir: As clusulas previstas no contrato; O escopo definido e acordado; Uma lista de verificao das caractersticas do subproduto ou produto em questo; Os subprodutos e produtos previamente validados ou aceitos, com os quais o subproduto ou produto a ser validado/aceito tenha relaes de dependncia; A rastreabilidade entre os artefatos do sistema.
12.1 Listas de Verificao

As seguintes listas de verificao foram produzidas para apoiar os processos de validao e aceitao de produtos, constituindo anexos a este documento: Anexo 14: Lista de verificao de conformidade dos produtos da metodologia, para a fase de Concepo, relativa aos produtos que constituem a Especificao Funcional (Para acessar esta lista clique em Conformidade Concepo ); Anexo 15: Lista de verificao de conformidade dos produtos da metodologia, para a fase de Elaborao, relativa aos produtos que constituem a Especificao Tcnica (Para acessar esta lista clique em Conformidade Elaborao ); Anexo 16: Lista de verificao de conformidade dos produtos da metodologia, para a fase de Construo, relativa aos produtos que constituem os Testes Unitrios e as Verses Beta de Software (Para acessar esta lista clique em Conformidade Construo ); Anexo 17: Lista de verificao de conformidade dos produtos da metodologia, para a fase de Transio, relativa aos produtos que constituem as Verses de Software para Homologao (Para acessar esta lista clique em Conformidade Transio );
53 de 53

Metodologia de Desenvolvimento de Sistemas-MDS

Enviado por

Dados do documento

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

Metodologia de Desenvolvimento de Sistemas-MDS

Enviado por

Direitos autorais:

Formatos disponíveis

Desenvolvimento de Sistemas

Assunto DESCRIO DA METODOLOGIA

Documento de Referncia MDS - Metodologia de Desenvolvimento de Software

Data de Aprovao pelo ONS 18/07/2005

DAC/GIT Gerncia de Informtica e Telecomunicaes

DAC/GIT Gerncia de Informtica e Telecomunicaes

DAC/GIT Gerncia de Informtica e Telecomunicaes

DAC/GIT Gerncia de Informtica e Telecomunicaes

Definies, Siglas e Abreviaes

DAC/GIT Gerncia de Informtica e Telecomunicaes

DAC/GIT Gerncia de Informtica e Telecomunicaes

DAC/GIT Gerncia de Informtica e Telecomunicaes

2 VISO GERAL DO PROCESSO UNIFICADO

2.1.1 Fases do Processo

DAC/GIT Gerncia de Informtica e Telecomunicaes

2.1.3 Fluxos de Trabalho (Seqncias de Atividades)

DAC/GIT Gerncia de Informtica e Telecomunicaes

2.1.4 Ciclo de Vida

Concepo Concepo Tempo

Concepo Concepo Tempo

Concepo Concepo Tempo

DAC/GIT Gerncia de Informtica e Telecomunicaes

Organizao com base no Tempo Fases

DAC/GIT Gerncia de Informtica e Telecomunicaes

DAC/GIT Gerncia de Informtica e Telecomunicaes

Definio do Problema Espao do Espao do Problema Problema

Necessidades Documento de Viso Caractersticas Requisitos de Software

Modelo de Casos de Uso

Modelo de Anlise e Projeto Modelo de Testes Modelo de Implementao

2.1.6 Reduo dos Riscos

Melhor entendimento dos requisitos e do sistema

2.1.7 Melhores Prticas (Uma Reforando a Outra)

DAC/GIT Gerncia de Informtica e Telecomunicaes

Verificao no Processo Unificado

DAC/GIT Gerncia de Informtica e Telecomunicaes

DAC/GIT Gerncia de Informtica e Telecomunicaes

2.3.1 Analista de Sistemas

DAC/GIT Gerncia de Informtica e Telecomunicaes

2.3.4 AD (Administrador de Dados) / DBA (Administrador do Banco de Dados)

DAC/GIT Gerncia de Informtica e Telecomunicaes

Contexto do Fluxo de Requisitos nas Fases do Ciclo

Reviso dos requisitos; Mudanas de Requisitos;

Ajuste fino dos artefatos do fluxo de requisitos revisitados.

3.1.1 Na Fase de Concepo

3.1.2 Na Fase de Elaborao

DAC/GIT Gerncia de Informtica e Telecomunicaes

3.1.3 Na Fase de Construo

3.1.4 Na Fase de Transio

Atividades do Fluxo de Requisitos

3.2.1 Identificar o Problema

3.2.2 Analisar o Problema

3.2.3 Gerar Especificao Funcional

3.2.4 Validar Especificao Funcional

3.2.5 Planejar Escopo

Executores do Fluxo de Requisitos

Produtos Gerados Pelo Fluxo de Requisitos

3.4.2 Definio do Problema

3.4.3 Documento de Viso

DAC/GIT Gerncia de Informtica e Telecomunicaes

3.4.4 Especificao dos Casos de Uso (Objetivos e Linhas Gerais)

3.4.5 Diagrama de Casos de Uso

3.4.6 Prottipo de Interface com o Usurio

3.4.7 Especificao Suplementar

3.4.8 Termo de Aceite da Especificao Funcional