Anexo VI-Metodologia de to de Sistemas-Do ONS

8/6/2019 Anexo VI-Metodologia de to de Sistemas-Do ONS

1/53

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.

Motivo da Reviso Data de Aprovaopelo ONS

0Este documento foi motivado pela necessidade de padronizao

da metodologia utilizada para desenvolvimento de sistemas.18/07/2005


2/53


Assunto




1 INTRODUO............................................................................................................................ 6

1.1 OBJETIVO .............................................................................................................................. 61.2 DEFINIES,SIGLAS E ABREVIAES ..................................................................................... 61.3 REFERNCIAS ........................................................................................................................ 61.4 NDICE DESCRITIVO ................................................................................................................ 7

2 VISO GERAL DO PROCESSO UNIFICADO .......................................................................... 9

2.1 VISO GERAL......................................................................................................................... 92.1.1 Fases do Processo ....................................................................................................... 92.1.2 Prototipao................................................................................................................ 102.1.3 Fluxos de Trabalho (Seqncias de Atividades)........................................................ 112.1.4 Ciclo de Vida............................................................................................................... 122.1.5 Rastreabilidade........................................................................................................... 152.1.6 Reduo dos Riscos................................................................................................... 162.1.7 Melhores Prticas (Uma Reforando a Outra) ........................................................... 16

2.2 VERIFICAO NO PROCESSO UNIFICADO ............................................................................... 172.3 EXECUTORES DO PROCESSO................................................................................................ 19

2.3.1 Analista de Sistemas .................................................................................................. 192.3.2 Arquiteto ..................................................................................................................... 192.3.3 Desenvolvedor............................................................................................................ 192.3.4 AD (Administrador de Dados) / DBA (Administrador do Banco de Dados)................ 202.3.5 Cliente......................................................................................................................... 20

3 FLUXO DE REQUISITOS......................................................................................................... 21

3.1 CONTEXTO DO FLUXO DE REQUISITOS NAS FASES DO CICLO.................................................. 213.1.1 Na Fase de Concepo.............................................................................................. 213.1.2 Na Fase de Elaborao .............................................................................................. 213.1.3 Na Fase de Construo.............................................................................................. 223.1.4 Na Fase de Transio ................................................................................................ 22

3.2 ATIVIDADES DO FLUXO DE REQUISITOS ................................................................................. 223.2.1 Identificar o Problema................................................................................................. 223.2.2 Analisar o Problema ................................................................................................... 223.2.3 Gerar Especificao Funcional................................................................................... 223.2.4 Validar Especificao Funcional................................................................................. 233.2.5 Planejar Escopo.......................................................................................................... 23

3.3 EXECUTORES DO FLUXO DE REQUISITOS............................................................................... 233.4 PRODUTOS GERADOS PELO FLUXO DE REQUISITOS .............................................................. 23

3.4.1 Glossrio..................................................................................................................... 233.4.2 Definio do Problema ............................................................................................... 233.4.3 Documento de Viso .................................................................................................. 233.4.4 Especificao dos Casos de Uso (Objetivos e Linhas Gerais) .................................. 243.4.5 Diagrama de Casos de Uso ....................................................................................... 243.4.6 Prottipo de Interface com o Usurio......................................................................... 243.4.7 Especificao Suplementar ........................................................................................ 243.4.8 Termo de Aceite da Especificao Funcional ............................................................ 24

4 FLUXO DE ANLISE ............................................................................................................... 25

4.1 CONTEXTO DO FLUXO DE ANLISE NAS FASES DO CICLO ....................................................... 254.1.1 Na Fase de Concepo.............................................................................................. 254.1.2 Na Fase de Elaborao .............................................................................................. 26

4.1.3 Na Fase de Construo.............................................................................................. 264.2 ATIVIDADES DO FLUXO DE ANLISE ....................................................................................... 26


3/53


Assunto




4.2.1 Refinar Casos de Uso................................................................................................. 264.2.2 Definir Classes de Negcio ........................................................................................ 264.2.3 Definir Responsabilidades das Operaes de cada Caso de Uso em Relao aosistema (Contratos do Sistema)................................................................................................ 26

4.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE ANLISE ........................................................... 274.4 PRODUTOS GERADOS .......................................................................................................... 27

4.4.1 Diagramas de Casos de Uso...................................................................................... 274.4.2 Especificao dos Casos de Uso ............................................................................... 274.4.3 Especificao Suplementar ........................................................................................ 274.4.4 Responsabilidades das Operaes de cada Caso de Uso em Relao ao Sistema(Contratos do Sistema) ............................................................................................................. 284.4.5 Termo de Aceite das Responsabilidades das Operaes de cada Caso de Uso emRelao ao Sistema (Contratos do Sistema)............................................................................ 28

5 FLUXO DE PROJETO.............................................................................................................. 29

5.1 CONTEXTO DO FLUXO DE PROJETO NAS FASES DO CICLO...................................................... 295.1.1 Na Fase de Concepo.............................................................................................. 295.1.2 Na Fase de Elaborao .............................................................................................. 305.1.3 Na Fase de Construo.............................................................................................. 30

5.2 ATIVIDADES DO FLUXO DE PROJETO...................................................................................... 305.2.1 Eleger Componentes Arquiteturais Significativos ...................................................... 305.2.2 Descrever a Arquitetura de Software ......................................................................... 305.2.3 Elaborar Prottipo Arquitetural ................................................................................... 315.2.4 Refinar a Arquitetura................................................................................................... 315.2.5 Gerar Modelo do Projeto ............................................................................................ 31

5.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE PROJETO.......................................................... 325.4 PRODUTOS GERADOS .......................................................................................................... 32

5.4.1 Descrio da Arquitetura de Software........................................................................ 325.4.2 Prottipo Arquitetural .................................................................................................. 325.4.3 Modelo do Projeto....................................................................................................... 335.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........................................... 346.1.1 Na Fase de Concepo.............................................................................................. 346.1.2 Na Fase de Elaborao .............................................................................................. 346.1.3 Na Fase de Construo.............................................................................................. 356.1.4 Na Fase de Transio ................................................................................................ 35

6.2 ATIVIDADES DO FLUXO DE IMPLEMENTAO .......................................................................... 356.2.1 Planejar Integrao..................................................................................................... 356.2.2 Preparar Ambiente de Desenvolvimento.................................................................... 356.2.3 Implementar Componentes de Software.................................................................... 356.2.4 Realizar Testes Unitrios ........................................................................................... 356.2.5 Integrar Componentes ................................................................................................ 36

6.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE IMPLEMENTAO .............................................. 366.4 PRODUTOS GERADOS .......................................................................................................... 36

6.4.1 Componentes de Software ......................................................................................... 366.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.............................................................................................. 377.1.2 Na Fase de Elaborao .............................................................................................. 37


4/53


Assunto




7.1.3 Na Fase de Construo.............................................................................................. 387.1.4 Na Fase de Transio ................................................................................................ 38

7.2 ATIVIDADES DO FLUXO DE TESTES ........................................................................................ 387.2.1 Elaborar Plano de Testes do Sistema........................................................................ 387.2.2 Projetar os Testes do sistema .................................................................................... 387.2.3 Preparar Infra-estrutura para os Testes de Sistema .................................................. 397.2.4 Executar os Testes de Sistema.................................................................................. 397.2.5 Executar os Testes de Aceitao de Sistema............................................................ 39

7.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE TESTES ............................................................ 397.4 PRODUTOS GERADOS .......................................................................................................... 39

7.4.1 Plano de Testes.......................................................................................................... 397.4.2 Roteiro dos Testes...................................................................................................... 397.4.3 Scripts de Testes...................................................................................................... 397.4.4 Resultado dos Testes executados ............................................................................. 397.4.5 Testes de Aceitao ................................................................................................... 40

8 FLUXO DE IMPLANTAO .................................................................................................... 41

8.1 CONTEXTO DO FLUXO DE IMPLANTAO NAS FASES DO CICLO ............................................... 418.1.1 Na Fase de Concepo.............................................................................................. 418.1.2 Na Fase de Elaborao .............................................................................................. 418.1.3 Na Fase de Construo.............................................................................................. 428.1.4 Na Fase de Transio ................................................................................................ 42

8.2 ATIVIDADES DO FLUXO DE IMPLANTAO............................................................................... 428.2.1 Elaborar Pano de Entrega .......................................................................................... 428.2.2 Desenvolver Material de Suporte ............................................................................... 428.2.3 Produzir Verso de Homologao (Verso Beta) ...................................................... 428.2.4 Obter Aceitao Formal da Verso ............................................................................ 428.2.5 Produzir Verso de Produo .................................................................................... 438.2.6 Preparar Treinamento................................................................................................. 438.2.7 Estabelecer Infra-estrutura de Suporte ...................................................................... 43

8.3 EXECUTORES DAS ATIVIDADES DO FLUXO DE IMPLANTAO................................................... 438.4 PRODUTOS GERADOS .......................................................................................................... 43

8.4.1 Plano de Entrega ........................................................................................................ 438.4.2 Material de Suporte .................................................................................................... 438.4.3 Verso de Homologao ............................................................................................ 438.4.4 Verso de Produo................................................................................................... 448.4.5 Aceitao de Verso................................................................................................... 448.4.6 Treinamento................................................................................................................ 44

8.4.7 Infra-estrutura de Suporte .......................................................................................... 449 RECOMENDAES E OBSERVAES................................................................................ 45

9.1 FERRAMENTA CASE.............................................................................................................. 459.1.1 Ambiente de Desenvolvimento ................................................................................... 459.1.2 Diagramas UML.......................................................................................................... 469.1.3 Automatizao dos Testes ......................................................................................... 469.1.4 Melhores Prticas ....................................................................................................... 46

10 MODELOS PARA SUPORTE METODOLOGIA............................................................... 47

11 PRODUTOS RESULTANTES DA METODOLOGIA............................................................ 48

11.1 ARTEFATOS X PAPIS ....................................................................................................... 51

12 VALIDAO E ACEITAO DE PRODUTOS.................................................................... 5312.1 LISTAS DE VERIFICAO ................................................................................................... 53


5/53


Assunto





6/53


Assunto




1 INTRODUO

1.1 Objetivo

A proposta deste documento apresentar de forma simples e consolidada a metodologiade desenvolvimento de sistemas do ONS, visando direcionar as equipes dedesenvolvimento e manuteno de software internas ou externas, constituindo um guiade referncia para os grupos.

O produto deste documento teve como referncia o Processo Unificado, que a parteconceitual do Rational Unified Process(RUP), produto da Rational Software Corporation.

O Processo Unificado foi idealizado por Ivar Jacobson, Grady Booch, James Raumbaughe seus colaboradores, para o desenvolvimento de sistemas orientados a objetosutilizando a UML.

O RUP, assim como o Processo Unificado, um frameworkde processo que deve seradaptado para atender as exigncias das organizaes, das reas de aplicao, e dodesenvolvimento de sistemas de tipos e portes diferentes.

Desta forma, o que se pretendeu neste documento foi, a partir de metodologias demercado mundialmente reconhecidas, estabelecer um subconjunto base de processos dedesenvolvimento de software que constitusse uma metodologia padro preliminar,seguindo preceitos universais e de forma a permitir sua posterior evoluo medida quefor sendo alcanada maior maturidade na execuo de seus processos.

Dependendo da natureza de cada projeto, podero ser necessrias adaptaes destametodologia relativamente a caractersticas mais especficas, a fim de melhor adequ-lapara um determinado grupo de projetos. Melhorias decorrentes destas adaptaespodero constituir tambm uma evoluo da metodologia, tornando-a mais apropriadapara novas demandas e realidades.

1.2 Definies, Siglas e Abreviaes

CASE Computer Aided Software Engineering (Ferramenta Computacional de Engenharia deSoftware)

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

1.3 Referncias


7/53


Assunto




A relao a seguir, apresenta os documentos que foram referenciados ou utilizados comoreferncia na elaborao deste documento.

Ttulo do Documento Data N.Referncia

Responsvel

Kruchten, Philippe.The Rational Unified Process AnIntroduction, Second Edition

2000 Addison Wesley

Object-Oriented Project Management, StudentManual

Version 1.4 RationalUniversity

Rational Unified Process Overview, Student Manual Version 5.5 Rational

UniversityLeffingwell, Dean; Widrig, Don. Managing SoftwareRequirements

1999 Addison Wesley

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 doProcesso Unificado, das fases e fluxos de trabalho que compem o ciclo de vida doprojeto.

Captulo 3 Fluxo de Requisitos Descreve o fluxo de trabalho relativo identificao e especificao de Requisitos, com suas atividades, executores e produtosgerados, alm de contextualiz-lo em cada fase do projeto.

Captulo 4 Fluxo de Anlise Descreve o fluxo de trabalho referente Anlise edetalhamento dos requisitos, com suas atividades, executores, produtos gerados ecorrespondente contextualizao do fluxo em cada fase do projeto.

Captulo 5 Fluxo de Projeto Descreve o fluxo de trabalho relativo ao Projeto daviso de arquitetura da anlise, com suas atividades, executores, produtos gerados edevida contextualizao em cada fase do projeto.

Captulo 6 Fluxo de Implementao Descreve o fluxo de trabalho deImplementao 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 paraverificar 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 corretamenteimplementados, bem como para identificar defeitos e assegurar que estes sejam tratados


8/53


Assunto




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 paraImplantao 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 erecomendaes relevantes, relativas metodologia e ao processo de desenvolvimento desoftware, de uma maneira geral.

Captulo 10 Modelos Anexos ndice com os modelos dos documentos a seremgerados, de acordo com a recomendao desta metodologia.

Captulo 11 Produtos Resultantes da Metodologia - Apresenta a consolidaodos produtos resultantes da metodologia e a relao entre estes e os perfis tcnicosnecessrios para sua elaborao.

Captulo 12 Validao e Aceitao de Produtos Descreve os critrios quedevem ser considerados na validao e aceitao de produtos e subprodutos do ciclo dedesenvolvimento de software.


9/53


Assunto




2 VISO GERAL DO PROCESSO UNIFICADO

2.1 Viso Geral

O Processo Unificado a parte conceitual do Rational Unified Process(RUP), produto da RationalSoftware Corporation.

O RUP, assim como o Processo Unificado, um frameworkde processo que deve ser adaptadopara atender s exigncias das organizaes, das reas de aplicao, e do desenvolvimento desistemas de tipos e portes diferentes.

O Processo Unificado foi idealizado por Ivar Jacobson, Grady Booch, James Raumbaugh e seuscolaboradores, para o desenvolvimento de sistemas orientados a objetos utilizando a UML.

um processo que segue o modelo iterativo e incremental, apresentando por isto caractersticasmais realistas de desenvolvimento. O sucesso da sua aplicao est na definio das iteraesmais adequadas, que vo produzir as verses intermedirias do sistema, permitindo um melhorentendimento dos requisitos e do sistema, e minimizando o risco de desvio dos objetivos doprojeto.

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. Aquantidade de iteraes ser determinada de acordo com a necessidade, complexidade eestratgia 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 dosoftware com um conjunto de funcionalidades definidas possa ser entregue, garantindo que oproduto reflete os requisitos solicitados pelo cliente e permitindo que o cliente defina se o sistemadeve ou no ir para a prxima fase.

O ciclo de vida do Processo Unificado pode ser entendido por meio de duas perspectivasdiferentes, 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 deveatender e as condies delimitadoras deste escopo (contexto do negcio). Nesta fase sodeterminados os casos de uso e os principais cenrios que iro direcionar as principais questesde anlise e projeto do sistema. Na perspectiva gerencial, so aqui considerados os critrios desucesso, 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.


10/53


Assunto




Elaborao (Elaboration):

Na fase de elaborao ocorre o entendimento e descrio completos, dos aspectos funcionais dosistema, bem como a entrega do prottipo final de interface com o usurio que materializa esteentendimento.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 dalinha bsica da arquitetura, e o desenvolvimento do plano de projeto. Aqui so eliminados oselementos de risco mais alto para o projeto, em decorrncia da maioria dos requisitos do sistemaj 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 nanecessidade 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 doscomportamentos 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 incioda fase de Elaborao e sempre antes que todo o sistema (incluindo a sua interface com o


11/53


Assunto




usurio definitiva) esteja analisado, projetado e implementado, j que seus principais propsitosso estarem aptos a expor e testar a funcionalidade e usabilidade do sistema antes que o projetoreal (ou definitivo) e o desenvolvimento comecem.

A fim de obter esta validao antecipada necessrio levar em conta que um prottipo sempreter que ser significativamente mais barato para desenvolver do que o seu correspondentedefinitivo, ao mesmo tempo em que tem que incluir as capacidades suficientes para alcanar osseus objetivos.

Prottipos de interface com o usurio podem ser utilizados pelo analista (e projetista) dosistema, com vrios objetivos, em momentos distintos ou em um determinado momentoescolhido:

Relativamente elaborao de casos de uso, para entender a interface com o usurioreferente a um caso de uso;

Relativamente anlise de objetos, para entender como a interface com o usurioinfluencia a anlise do sistema;

Relativamente ao projeto, para entender como a interface com o usurio impacta osistema 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 interfacecom o usurio e tem um carter menos descartvel do que estes. Ele utilizado pelo arquitetopara validar e aprovar as principais decises arquiteturais e , geralmente, a base para evoluovisando 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.


12/53


Assunto




2.1.4 Ciclo de Vida

A seqncia das quatro fases constitui o ciclo de vida do Processo Unificado sendo que o primeirociclo 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 mesmaseqncia das fases, mas com nfases diferentes, dependendo das novas verses. Estes ciclossubseqentes 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:

As iteraes ocorrem relativamente ao ciclo como um todo, conforme apresentado na figuraanterior, bem como dentro de cada fase do ciclo, para grupos de casos de uso especficos ecomponentes correspondentes.

Um ciclo de desenvolvimento tpico tem trs nveis de complexidade e, para cada nvel, existe asugesto da quantidade de iteraes que devem existir. importante lembrar que estas quantidades so apenas para referncia e que a real quantidadede iteraes por fase, em um projeto, vai depender de suas caractersticas particulares e dadeciso dos seus participantes. De um modo geral, a fase de construo tem n iteraes.

ConcepoConcepo ElaboraoElaborao ConstruoConstruo TransioTransio EvoluoEvoluo

Tempo Verso 1Ciclo de desenvolvimento inicial


Tempo Verso 2Ciclo de evoluo 1


Tempo Verso n...Ciclo de evoluo n...


Tempo Verso 1Ciclo de desenvolvimento inicial


Tempo Verso 2Ciclo de evoluo 1


Tempo Verso n...Ciclo de evoluo n...


13/53


Assunto




O quadro seguinte constitui a referncia para a quantidade de iteraes por ciclo dedesenvolvimento e de iteraes por fase do ciclo:

Ciclo iterativo Total de iteraesem um ciclo

Nmero de iteraespor fase [C, E, C, T]

Baixo 3 [0, 1, 1, 1]Tpico 6 [1, 2, 2, 1]Alto 9 [1, 3, 3, 2]

Pela perspectiva da engenharia (ou do contedo), os fluxos de trabalho atravessam asdiferentes 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:

O fluxo de atividades relativo Modelagem do Negcio e os fluxos gerenciais relativos aoGerenciamento do Projetoe ao Gerenciamento de Configurao e Verso, no esto sendoconsiderados nesta verso.

ConcepoConcepo ElaboraoElaborao ConstruoConstruo TransioTransio

Iteraes

Preliminares

Iter.

#1

Iter.

#2

Iter.

#n

Iter.

#n+1

Iter.

#n+2

Iter.

#m

Iter.

#m+1

Fases

Iteraes

O rg

an

iza

o

co

m

ba

seno

C o

nte

d

o

Organizao com base no Tempo

Complementariedade

Fluxos de Trabalho

do Processo:

Modelagem do

Negcio

Requerimentos

Anlise e Projeto

Implementao

Testes

Implantao


Iteraes

Preliminares

Iter.

#1

Iter.

#2

Iter.

#n

Iter.

#n+1

Iter.

#n+2

Iter.

#m

Iter.

#m+1

Fases

Iteraes

O rg

an

iza

o

co

m

ba

seno

C o

nte

d

o


Complementariedade


Iteraes

Preliminares

Iter.

#1

Iter.

#2

Iter.

#n

Iter.

#n+1

Iter.

#n+2

Iter.

#m

Iter.

#m+1

Fases

Iteraes

O rg

an

iza

o

co

m

ba

seno

C o

nte

d

o



Iteraes

Preliminares

Iter.

#1

Iter.

#2

Iter.

#n

Iter.

#n+1

Iter.

#n+2

Iter.

#m

Iter.

#m+1

ConcepoConcepo ElaboraoElaborao ConstruoConstruo TransioTransioConcepoConcepo ElaboraoElaborao ConstruoConstruo TransioTransio

Iteraes

Preliminares

Iter.

#1

Iter.

#2

Iter.

#n

Iter.

#n+1

Iter.

#n+2

Iter.

#m

Iter.

#m+1

Iteraes

Preliminares

Iter.

#1

Iter.

#2

Iter.

#n

Iter.

#n+1

Iter.

#n+2

Iter.

#m

Iter.

#m+1

Fases

Iteraes

O rg

an

iza

o

co

m

ba

seno

C o

nte

d

o


Complementariedade

Fluxos de Trabalho

do Processo:

Modelagem do

Negcio

Requerimentos

Anlise e Projeto

Implementao

Testes

Implantao

Fluxos de Trabalho

do Processo:

Modelagem do

Negcio

Requerimentos

Anlise e Projeto

Implementao

Testes

Implantao


14/53


Assunto




Outra modificao em relao figura anterior e adotada neste documento diz respeito ao fluxo detrabalho de Anlise e Projeto. Neste documento, o referido fluxo foi desmembrado em dois fluxosseparados, o Fluxo de Anlise e o Fluxo de Projeto, a fim de deixar mais clara a diferena queexiste 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 osistema far aquilo que foi identificado que teria que fazer. A separao em dois fluxos torna claraesta fronteira, facilitando o entendimento dos objetivos das suas atividades.

Pode ser observado, atravs da figura acima, que os fluxos de trabalho tm maior nfase emmomentos diferentes. O nvel de atividade de cada um deles maior em uma ou mais fases doprocesso.

Assim, pode-se notar que o fluxo de Requisitos tem maior nfase nas fases de Concepo e deElaborao, da mesma forma que o fluxo de Implementao tem maior nfase na fase deConstruo 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 demaior 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.


15/53


Assunto




2.1.5 Rastreabilidade

Uma caracterstica importante deste processo a capacidade de rastreabilidade que o processopermite, desde as demandas iniciais dos clientes at aos componentes de software criados paraconstituir a aplicao.

Os modelos criados no so estanques e influenciam-se mutuamente para agregar valor e refletira evoluo do sistema, conforme mostrado na figura a seguir:

Assim, o processo permite estabelecer que cada necessidade tem caractersticas especficas, quecada 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 seusartefatos correspondentes no modelo de testes e tem relao com os componentes especficosque 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 terrelao de rastreabilidade entre si.

Espao do

Problema

Espao do

Problema

Espao daSoluo

Necessidades

Caractersticas

Requisitos de Software

Modelo de

Casos de Uso

Modelo deTestes

Modelo deImplementao

Modelo de

Anlise e Projeto

Definio do

Problema

Documento

de Viso

Rastreabilida

de

Espao do

Problema

Espao do

Problema

Espao daSoluo

Necessidades

Caractersticas

Requisitos de Software

Modelo de

Casos de Uso

Modelo de

Casos de Uso

Modelo de

Casos de Uso

Modelo deTestes

Modelo deTestes



Modelo de

Anlise e Projeto

Modelo de

Anlise e Projeto

Definio do

Problema

Documento

de Viso

Documento

de Viso

Rastreabilida

de


16/53


Assunto




2.1.6 Reduo dos Riscos

Talvez a caracterstica mais importante do conceito do processo unificado seja a reduosignificativa do risco, a partir da utilizao do seu processo de desenvolvimento, quandocomparado 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 processounificado antecipar as principais decises do projeto, antecipando tambm as aes de respostas incertezas, conforme mostrado na figura a seguir:

2.1.7 Melhores Prticas (Uma Reforando a Outra)

O processo unificado permite a utilizao das principais melhores prticas para desenvolvimentode software. No caso das melhores prticas apresentadas a seguir, o todo maior que a somadas partes j que cada melhor prtica refora o uso e valor obtido pela seguinte e, em algunscasos, pr-requisito para a sua existncia.

Gerenciar Mudanas

Verificar Continuamente a Qualidade

Modelar Visualmente (UML)

Usar Arquitetura de Componentes

Gerenciar Requisitos

Desenvolver Iterativamente

Melhores Prticas

Gerenciar Mudanas

Verificar Continuamente a Qualidade

Modelar Visualmente (UML)

Usar Arquitetura de Componentes

Gerenciar Requisitos

Desenvolver Iterativamente

Melhores Prticas

Assegurar o envolvimento do usurios emtoda a evoluo dos requisitos

Validar decises arquiteturais cedo no ciclode vida do sistema

Tratar incrementalmente a complexidade deprojeto e implementao

Medir a qualidade muitas vezes e desdecedo no ciclo de vida do sistema

Evoluir as bases de referncia de formaincremental

Assegurar o envolvimento do usurios emtoda a evoluo dos requisitos

Validar decises arquiteturais cedo no ciclode vida do sistema

Tratar incrementalmente a complexidade deprojeto e implementao

Medir a qualidade muitas vezes e desdecedo no ciclo de vida do sistema

Evoluir as bases de referncia de formaincremental

Diminuio dos Riscos:

RISCO

PRAZO

Reduo do Risco

Desenvolvimento Waterfall

Desenvolvimento Iterativo

Melhor entendimento dos requisitos e do sistema

Diminuio dos Riscos:

RISCO

RISCO

PRAZOPRAZO

Reduo do RiscoReduo do Risco

Desenvolvimento Waterfall

Desenvolvimento Iterativo

Melhor entendimento dos requisitos e do sistema


17/53


Assunto




2.2 Verificao no Processo Unificado

O desenvolvimento iterativo permite que a equipe de desenvolvimento melhore o entendimentodos requisitos e dos artefatos, atravs dos incrementos ou verses, detectando, no incio doprojeto, os pontos crucias.

O Processo Unificado, da mesma forma que os demais modelos de processo, prev pontos deverificao ao longo do desenvolvimento do software, para manter a qualidade do processo e doproduto.

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, asseguintes perguntas tm que ser respondidas:

Existe uma arquitetura de componentes que possa implementar estafuncionalidade?

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 betano 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 paraa 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?


18/53


Assunto




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 dedesenvolvimento.

Montar a arquitetura correta, permitindo que o sistema possa ser dividido, de tal forma queos projetistas possam trabalhar de forma independente.

Utilizar componentes que permitam a construo de blocos reutilizveis que possamreduzir o custo de desenvolvimento, diminuir o tempo de entrega do produto e aumentar aqualidade.

Utilizar a UML para a elaborao dos artefatos e para comunicao entre os integrantesda equipe de projeto, de forma a estabelecer um padro de comunicao para a equipe, jque a UML uma linguagem que representa o software nos diversos estgios dodesenvolvimento.

Basear o desenvolvimento em iteraes, em funo de seus produtos oferecemvantagens, 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 respostadecorrentes, visando sua mitigao, transferncia, contingncia ou aceitao, antes quepossam aparecer no processo de desenvolvimento de software.


19/53


Assunto




2.3 Executores do Processo

A fim de obter um processo bem adaptado s estruturas mais comumente existentes nos projetosde desenvolvimento de sistemas, foi identificado um grupo reduzido de executores, os quaisparticiparo das diversas atividades de desenvolvimento dos artefatos (produtos) associados acada fluxo de trabalho desta metodologia.

Estes executores no traduzem cargos ou funes dos profissionais expressando, apenas, ospapis que estes profissionais iro desempenhar em determinados momentos do ciclo do projeto ede acordo com as atividades do fluxo que estiver sendo trabalhado.

A descrio dos papis, a seguir apresentada, deve ser vista como uma orientao sobre ashabilidades ou perfis tcnicos necessrios s responsabilidades associadas a estes papis.

Estas habilidades (ou perfis tcnicos) esto identificadas sob o prisma dos integrantes da equipedesenvolvedora do sistema.

Dentro deste contexto, por exemplo, um usurio (ou qualquer outro profissional) que atue naespecificao de requisitos estar desempenhando o papel de analista de sistemas.

Ainda em relao ao conceito de papel como habilidades ou perfis tcnicos necessrios, convmsalientar que, da mesma forma que seus fluxos correspondentes, nesta verso, os perfis tcnicosrelativos s atividades dos fluxos para Modelagem do Negcio, Gerenciamento do Projeto eGerenciamento de Configurao e Verso, no esto considerados. Os papis referentes s

habilidades necessrias para desempenhar as atividades destes fluxos seriam, respectivamente, oanalista/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 deUso, 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 dosistema.

2.3.3 Desenvolvedor

Desenvolve e testa componentes de acordo com os padres adotados para o desenvolvimento dosistema. Quando estes forem testados, outros componentes para suporte aos testes tambmsero criados. Ele tambm poder ajustar as classes, com suas respectivas operaes, atributos erelacionamentos, desde que isto no comprometa a arquitetura.


20/53


Assunto




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, entreoutras 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 partefsica e de implementao do banco.

2.3.5 Cliente

Dirige e formaliza os testes de validao e aceitao do sistema.


21/53


22/53


Assunto




3.1.3 Na Fase de Construo

Nesta fase, alguns requisitos podem ser revistos ou podem, ainda, ser identificados novosrequisitos. De qualquer forma, estes novos requisitos podem significar alterao no escopo dosistema 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 ocorrerpequenos 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 aquais restries preliminares o sistema estar sujeito. Estes aspectos sero capturados utilizandoo documento de definio do problema.

3.2.2 Analisar o Problema

Identificar os colaboradores, envolvidos ou interessados (stakeholders) do projeto, conseguirconsenso das partes envolvidas em relao ao problema a ser resolvido, definir as fronteiras dosistema e identificar a quais restries o sistema estar sujeito. Estes aspectos so capturadosutilizando 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 preliminaresde interface com o usurio, etc.) por meio da utilizao do documento de viso e so consolidadosna 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 deexecuo. 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 evalidar seus requisitos.


23/53


Assunto




Tanto a descrio de cada caso de uso quanto a sua interface correspondente so documentadasem conjunto, em um documento por caso de uso, a fim de facilitar a sua manipulao por mais deuma 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 degarantir a aderncia em relao s impresses iniciais consolidadas, garantindo que estejamcorretas e possibilitando que dirijam o restante do desenvolvimento do sistema. O aceite ter queser formalizado em documento apropriado.

3.2.5 Planejar Escopo

O planejamento do prosseguimento do projeto realizado atravs da decomposio do escopoem 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 umanica definio, independentemente de pessoa ou rea especfica. Observar que o glossrio serpreenchido 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 dosusurios.

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.


24/53


Assunto




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, doispargrafos) 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 decasos de uso de mesma categoria) para facilitar a compreenso.

3.4.6 Prottipo de Interface com o UsurioUm ou mais prottipos de interface com o usurio contendo, dependendo do detalhamento derequisitos 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 sedeseja identificar e validar.

Quanto mais cedo realizado um prottipo mais riscos so eliminados. Por outro lado, h que selevar sempre em conta que, embora importante, um prottipo tem que ser sempresignificativamente mais barato e fcil de construir que seu correspondente definitivo e que, quantomais 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 maneiraclara 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 peloconjunto de produtos anteriormente descritos para este fluxo de trabalho.


25/53


Assunto




4 FLUXO DE ANLISE

Este fluxo de trabalho descreve a viso de arquitetura, com foco No Que deve ser feito e realizao detalhamento dos requisitos, sendo que os modelos de referncia (templates) para osdocumentos a serem utilizados, encontram-se relacionados no captulo 10 MODELOS PARASUPORTE 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 maiornfase em questes especficas (o processo iterativo e incremental), conforme relacionado aseguir 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:

4.1.1 Na Fase de Concepo

O foco, nesta fase, a modelagem do modelo preliminar das classes de negcio identificadaspara o sistema (viso esttica do modelo). Este documento considera que esta modelagemconstitui apenas uma representao das classes de negcio, a partir de processos de negcio doONS 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.

Concepo Elaborao Construo Transio

Modelagempreliminardas classesde negcio

(visoesttica);

Entendimentodo sistema omais completopossvel; Classes deNegcio eAssociaes; Contratos dosistema; Anlise inicialpara oprottipoarquitetural;

Ajustes nomodelo;

Reflexo dasmudanas derequisitos nomodelo;


Modelagempreliminardas classesde negcio

(visoesttica);

Entendimentodo sistema omais completopossvel; Classes deNegcio eAssociaes; Contratos dosistema; Anlise inicialpara oprottipoarquitetural;

Ajustes nomodelo;

Reflexo dasmudanas derequisitos nomodelo;


26/53


Assunto




4.1.2 Na Fase de Elaborao

Nesta fase, o entendimento do sistema tem que ser o mais completo possvel (requisitos bemdetalhados) considerando: O esclarecimento sobre o que o sistema deve fazer; O registro doconjunto de classes de negcio e suas associaes; A anlise das responsabilidades dasoperaes de cada caso de uso em relao ao sistema (contratos do sistema); A anlise inicial doprottipo 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 seobservar 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 aeste 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 quetiverem sido capturados nos casos de uso. So identificadas: a estrutura de herana, associaesentre as classes, seus respectivos papis nestas associaes, assim como eventuais tipos dedados especficos do domnio em questo.

Para clareza e objetividade do modelo, as classes so organizadas em pacotes, estandoagrupadas 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 pequenosdiagramas.

4.2.3 Definir Responsabilidades das Operaes de cada Caso de Uso emRelao ao sistema (Contratos do Sistema)

Para cada caso de uso, so identificadas as suas operaes e o que cada operao secompromete a gerar como resultado, com foco na descrio das suas responsabilidades emrelao ao sistema como um todo, considerando o que o sistema deve fazer (viso caixa preta) eno 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


27/53


Assunto




de sistema, composto basicamente de uma instncia de cada ator, um objeto representando osistema e as operaes que envolvem o caso de uso.

Cada operao identificada possui um contrato de responsabilidades em relao ao sistema, queespecifica e descreve o seu resultado, sendo expresso em termos de pr e ps-condies. A pr-condio apresenta o estado do sistema antes da execuo da operao e a ps-condioapresenta o estado do sistema aps a execuo da operao, descrevendo quais os objetos e asligaes que sero criadas, destrudas e modificadas, bem como os resultados que tero que serretornados.

Observao: O uso da especificao das responsabilidades das operaes de cada caso de usoem relao ao sistema (contratos de sistema) proposto por alguns mtodos de desenvolvimentobaseados em componentes, como Catalysis e UML Components, e tem por objetivo definir oque 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, fluxoprincipal, fluxos alternativos, atores, regras de negcio especficas deste caso de uso e suas pr eps-condies.

4.4.3 Especificao Suplementar

Este documento registra requisitos no funcionais do sistema ou requisitos funcionais queenvolvam mais de um caso de uso do sistema. Este documento ser preenchido medida que osrequisitos forem detalhados, esclarecendo as regras do negcio em questo. Ele decompostoem:

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.


28/53


Assunto




4.4.4 Responsabilidades das Operaes de cada Caso de Uso em Relao aoSistema (Contratos do Sistema)

Documento que formaliza as responsabilidades de cada operao identificada. constitudo pelonome da operao e respectivos parmetros, a referncia cruzada com o caso de uso, as pr eps-condies.

O preenchimento das ps-condies restringe-se ao vocabulrio do modelo esttico, ao invs dedescrever o algoritmo, informando-se o estado do sistema resultante da operao.

Neste documento tambm tem que constar o diagrama de seqncia do sistema, representandoas 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 deUso em Relao ao Sistema (Contratos do Sistema)

Documento que formaliza o aceite das responsabilidades das operaes de cada caso de uso emrelao ao sistema (contratos do sistema), por parte do cliente.


29/53


Assunto




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. Osmodelos de referncia (templates) para os documentos a serem utilizados encontram-serelacionados 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 odesenvolvimento 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:


Este fluxo de trabalho far uma eleio preliminar dos casos de uso para o prottipo arquitetural ecapturar as primeiras restries e/ou definies com influncia significativa na arquitetura, comopor exemplo, a determinao do uso de uma tecnologia.

Dependendo do contexto, do grau de incerteza e dos riscos associados ao sistema que serdesenvolvido, pode ser necessria a antecipao de alguns aspectos da arquitetura para a fase deconcepo, de maneira a tentar reduzir os riscos associados ao sistema. Neste caso, a fase deconcepo, torna-se, naturalmente, um pouco mais longa.


Eleiopreliminardos casos deuso para oprottipo

arquitetural; Eventualantecipaode algunsaspectos daarquitetura,em razo deriscos;

Primeirasrestries /definiespara aarquitetura;

Projeto evalidao daarquitetura; Prottipoarquiteturalqueimplemente evalide asdecises deprojeto maisimportantes;

Complementaoe evoluo domodeloarquitetural;


Eleiopreliminardos casos deuso para oprottipo

arquitetural; Eventualantecipaode algunsaspectos daarquitetura,em razo deriscos;

Primeirasrestries /definiespara aarquitetura;

Projeto evalidao daarquitetura; Prottipoarquiteturalqueimplemente evalide asdecises deprojeto maisimportantes;

Complementaoe evoluo domodeloarquitetural;


30/53


Assunto





Nesta fase, este fluxo de trabalho vai construir a arquitetura e valid-la. H que se observar que aarquitetura s considerada completa, com a construo de um prottipo arquitetural, queimplemente as mais importantes decises de projeto e que seja suficiente para valid-las. Nestafase, 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 sendoconstrudo, 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 atomada de deciso, do ponto de vista da arquitetura. Estes aspectos relevantes iro traduzir-se emuma implementao real da deciso tomada, atravs da implementao de um conjuntosignificativo 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 umelemento nico, como em nota fiscal e seus itens), sob o ponto de vista da arquitetura, bastariaescolher um. Os casos em que houvesse necessidade de comunicao com um hardwareespecfico, 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 tticastomadas de maneira independente, a arquitetura tem que prover uma unificao coerente daestrutura do sistema, organizando as partes sistematicamente e providenciando regras sobrecomo escalar o sistema sem que sua complexidade se multiplique. Com isto, possvel proveruma 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 restriesarquiteturalmente 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 deImplementao, Viso de Processo e a Viso de Implantao.

Viso do Usurio Lista dos casos de uso ou cenrios que representem funcionalidadessignificativas e centrais do sistema final, ou que tenham uma grande cobertura arquitetural, isto ,que exercitem vrios elementos de arquitetura, exijam intensamente ou exemplifiquem pontosarquiteturais delicados.


31/53


Assunto




Viso Lgica Descreve as partes arquiteturais significativas do modelo de projeto,apresentando classes significativas e a descrio de suas responsabilidades, assim comoimportantes relacionamentos, operaes e atributos.

Viso de Processo Descreve a decomposio do sistema em processos simples (simplesthreads de controle thread: parte de um programa que pode ser executadaindependentemente de outras partes) e processos pesados (agrupamento de processos), queformam os mecanismos de concorrncia e sincronismo do sistema, incluindo os principais modosde comunicao entre os processos, como as interrupes ou passagem de mensagens. Abordatambm questes de desempenho e escalabilidade.

Viso de Implementao descreve de maneira abrangente o modelo de implementao, adecomposio do software em camadas e subsistemas, alm de componentes arquiteturaissignificativos.

Viso de Implantao - Descreve uma ou mais configuraes de redes fsicas, mostrando comoos vrios elementos do software (executveis e outros componentes considerados em tempo deexecuo) sero implantados e executados entre as plataformas e computadores, podendo existirreferncia aos processos que foram mapeados na viso de processos.

A descrio geral da arquitetura ir ainda considerar as estratgias de tratamento dosmecanismos gerais, tais como: persistncia, tratamento de excees, distribuio, interface com ousurio e comunicao com outros sistemas.

A arquitetura mais do que um planejamento do sistema que ser desenvolvido. Para validar aarquitetura e atestar suas qualidades em termos de performance, flexibilidade e robustez, tem queser criado um prottipo arquitetural no descartvel, que aplique todas as decises registradase 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, paraos ajustes necessrios, at que o modelo de arquitetura esteja pronto e maduro para refletir asfuncionalidades requeridas pelo cliente.

5.2.4 Refinar a Arquitetura

Nesta atividade sero ajustadas as decises arquiteturais sempre que necessrio, ousimplesmente evoludas a partir da arquitetura existente, mesmo porque estas decises poderoser 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. Eventualmentepodero surgir ajustes para o prprio modelo, nas definies do sistema (um novo fluxo alternativono 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.


32/53


Assunto




Viso do usurio: Representa o sistema a partir da perspectiva dos usurios. Um diagrama decaso de uso representa a funcionalidade provida pelo sistema para seus usurios externos, sendocomposto por atores, casos de uso e seus relacionamentos. Suporte UML: diagrama de casos deuso.

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 deseqncia, colaborao, estados e atividades.

Viso de implementao: Representa aspectos estruturais e comportamentais da realizao dosistema, tendo como base os componentes de implementao. Suporte UML: diagrama decomponentes.

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 desoftware 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.1 Descrio da Arquitetura de SoftwareDocumento que registra as decises arquiteturais do sistema.

5.4.2 Prottipo Arquitetural

Prottipo para o entendimento e validao das principais decises arquiteturais.


33/53


Assunto




5.4.3 Modelo do Projeto

Composto por todos os diagramas e respectivas especificaes, necessrios para esclarecer asvises do sistema que est sendo desenvolvido. Tipicamente so construdos, os diagramas declasse 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 odiagrama de seqncia tem que apresentar a seqncia de mensagens trocadas entre os objetosde um determinado contexto.

5.4.4 Modelo Lgico do Banco de Dados

Diagrama de entidades e relacionamentos representando a estratgia de tabelas adotada para asclasses identificadas.

Este produto ter que estar em consonncia com a padronizao de banco de dados vigente noONS. A referida padronizao encontra-se relacionada no captulo 10 MODELOS PARASUPORTE METODOLOGIA.


34/53


Assunto




6 FLUXO DE IMPLEMENTAO

Este fluxo de trabalho leva em considerao o desenvolvimento do software, formado por seuscomponentes, os testes de unidade e a integrao com os componentes j existentes. Os modelosde referncia (templates) para os documentos a serem utilizados encontram-se relacionados nocaptulo 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), conformerelacionado a seguir e de acordo com a fase em que o desenvolvimento se encontra no ciclo devida do sistema.

A figura seguinte apresenta o contexto do fluxo de implementao, nas fases do ciclo de vida dosistema, mostrando as questes que tm maior nfase em cada uma das fases:


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 aimplementao inicial dos componentes de banco de dados (modelo fsico).


Planejamentoda Integrao doSistema. Modelo FsicoInicial do BD.

Implementaodoscomponentes;

Modelo FsicoAtualizado doBD.

Manutenodoscomponentescriados;

Principaisrestries para o

ambiente dedesenvolvimento.


Planejamentoda Integrao doSistema. Modelo FsicoInicial do BD.

Implementaodoscomponentes;

Modelo FsicoAtualizado doBD.

Manutenodoscomponentescriados;

Principaisrestries para o

ambiente dedesenvolvimento.


35/53


Assunto





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


Na fase de transio ocorrem as eventuais manutenes dos componentes de sistema que foramcriados 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 noprojeto 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 asdeterminaes 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, areferncia 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 ficadevidamente armazenado para futuras execues. O desenvolvedor tem que garantir que ostestes do componente foram executados em sua totalidade e sem erros.


36/53


Assunto




6.2.5 Integrar Componentes

Esta integrao realizada de forma automtica, com o apoio de uma ferramenta integrada aoambiente de desenvolvimento. O ambiente e ferramenta tm que permitir o retorno situaoanterior 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 opapel de:

Arquiteto; Desenvolvedor; AD (Administrador de Dados) / DBA (Administrador de Banco de Dados).


6.4.1 Componentes de Software

Artefatos de software criados (Classes; Interfaces com usurio; scripts e modelo fsico do bancode 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 queestes mecanismos implementam; etc.) respeitando o planejamento e, principalmente, as decisesde arquitetura, devidamente integrados aos outros componentes j criados.

Os produtos relativos ao banco de dados tero que estar em consonncia com a padronizao debanco de dados vigente no ONS. A referida padronizao encontra-se relacionada no captulo 10MODELOS PARA SUPORTE METODOLOGIA.

6.4.2 Testes de Unidade

Artefatos de testes, scripts e documentos, que permitam os testes de unidade e a avaliao deseus resultados a partir da emisso de Certificados de Testes Unitrios conforme previsto nodocumento Roteiro dos Testes.


37/53


Assunto




7 FLUXO DE TESTES

Este fluxo de trabalho descreve casos de teste, procedimentos e medidas para acompanhamentode erros e certificao do funcionamento do Sistema. Os modelos de referncia ( templates) paraos documentos a serem utilizados encontram-se relacionados no captulo 10 MODELOS PARASUPORTE METODOLOGIA.

7.1 Contexto do Fluxo de Testes nas Fases do Ciclo

Todas as atividades do fluxo de testes so executadas em todas as fasesdo 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:


Nesta fase o plano de testes criado.


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


Criao doPlano deTestes;

Ajustes do

Plano deTestes; Criao dosRoteiros deTestes;

Ajustes dosRoteiros deTestes;

Execuo dosRoteiros deTestes, medida que ospacotes vosendoterminados;

Execuo dosTestes deAceitaorestantes atque se possadisponibilizar osistema paraimplantao.


Criao doPlano deTestes;

Ajustes do

Plano deTestes; Criao dosRoteiros deTestes;

Ajustes dosRoteiros deTestes;

Execuo dosRoteiros deTestes, medida que ospacotes vosendoterminados;

Execuo dosTestes deAceitaorestantes atque se possadisponibilizar osistema paraimplantao.


38/53


Assunto





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 sendoterminados.


Os testes para aceitao que restarem so executados at que se possa disponibilizar o sistemapara 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 dasverificaes. 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 serconsiderados 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 Interfa

Anexo VI-Metodologia de to de Sistemas-Do ONS

Documents

Transcript of Anexo VI-Metodologia de to de Sistemas-Do ONS