O Processo unificado de desenvolvimento de Software

O Processo Unificado de Desenvolvimento de Software

1. IntroduoO processo unificado de desenvolvimento de software o conjunto de atividades necessrias para transformar requisitos do usurio em um sistema de software. Ele baseado em componentes, o que significa o sistema ser construdo a partir de componentes de software interconectados via interfaces muito bem definidas. O Processo Unificado utiliza a Linguagem de Modelagem Unificada (Unified Modeling Language UML) no preparo de todos os artefatos do sistema. Os aspectos que distinguem o Processo Unificado so capturados em trs conceitos chave: Direcionado a casos de uso; Centrado na arquitetura; Iterativo (repetitivo) e Incremental.1.1 Direcionado a Casos de Uso

Um sistema de software feito para servir aos seus usurios. Portanto, para construir um sistema de sucesso devemos saber quem so seus usurios potenciais e o que eles querem e precisam. O termo usurio representa algum ou alguma coisa (como outro sistema) que interage com o sistema que est sendo desenvolvido.Um caso de uso um pedao de funcionalidade do sistema que d ao usurio um resultado de valor. Casos de uso capturam requisitos funcionais e todos juntos resultam no Modelo de Casos de Uso, o qual descreve a funcionalidade completa do sistema. Este modelo substitui a especificao funcional tradicional, cujo papel responder seguinte questo: o que o sistema faz? A estratgia de casos de uso pode ser caracterizada pela adio de trs palavras no final dessa pergunta: para cada usurio? Estas palavras tm uma implicao muito importante. Foram-nos a pensar em termos dos valores dos usurios, no apenas em funes que poderiam ser interessantes.Os casos de uso direcionam o processo de desenvolvimento, j que, baseados no modelo de casos de uso os desenvolvedores criam uma srie de modelos de projeto e implementao que os realizam efetivamente. Os responsveis pelos testes realizam seu trabalho com o propsito de garantir que os componentes do modelo de implementao cumpram corretamente os objetivos estabelecidos nos casos de uso. Desta forma, os casos de uso no somente iniciam o processo de desenvolvimento, mas, tambm, o mantm coeso. Direcionado a casos de uso significa que o processo de desenvolvimento executa uma seqncia de tarefas derivadas dos casos de uso. Eles so especificados, projetados e servem de base para a construo dos casos de teste.Embora seja verdade que os casos de uso dirigem o processo, eles no so selecionados isoladamente. So desenvolvidos juntamente com a arquitetura do sistema. Ou seja, os casos de uso direcionam a arquitetura do sistema, que por sua vez influencia a seleo dos casos de uso. Portanto, ambos amadurecem no decorrer do ciclo de vida do sistema.1.2 Centrado na Arquitetura

O papel da arquitetura no software de natureza similar ao papel da arquitetura na construo civil. As construes so observadas sob vrios pontos de vista: estrutura, servios, conduo de calor, encanamento, eletricidade, etc. Da mesma forma, a arquitetura em um sistema de software descrita como sendo as diferentes vises desse sistema. O conceito de arquitetura de software incorpora os aspectos estticos e dinmicos mais importantes do sistema. A arquitetura influenciada por muitos fatores, tais como a plataforma de software sobre a qual o sistema vai rodar (sistema operacional, sistema gerenciador de banco de dados, protocolos para comunicao em rede, etc.), blocos de construo reusveis disponveis (por exemplo, um framework para construo de interface grfica com o usurio), consideraes de distribuio, sistemas legado e requisitos no funcionais (performance, confiabilidade, etc.). Ela representa uma viso do projeto como um todo, na qual as caractersticas mais importantes so colocadas em destaque, deixando os detalhes de lado.Como os casos de uso esto relacionados arquitetura? Todo produto tem funo e forma e nenhum desses elementos sozinho suficiente. Essas duas foras devem ser balanceadas para obtermos um produto de sucesso. Neste caso, a funo corresponde aos casos de uso e a forma arquitetura. Por um lado, os casos de uso devem, quando construdos, encaixar-se na arquitetura. Por outro, a arquitetura deve fornecer espao para a construo de todos os casos de uso necessrios, agora e no futuro. Na realidade, ambos devem ser desenvolvidos em paralelo.Para encontrar essa forma, os arquitetos devem trabalhar a partir de uma compreenso geral das funes chave do sistema, isto , dos casos de uso chave. Estes devem ficar em torno de 5 a 10% de todos os casos de uso, mas so os mais significativos, aqueles que constituem o ncleo das funes do sistema. Em termos simplificados, os arquitetos: Criam um esboo da arquitetura iniciando com a parte que no especfica dos casos de uso (por exemplo, a plataforma). Embora seja uma parte independente dos casos de uso, o arquiteto deve ter uma compreenso geral destes antes da criao do esboo.

Depois, o arquiteto trabalha com um subconjunto dos casos de uso identificados, aqueles que representam as funes chave do sistema em desenvolvimento. Cada caso de uso selecionado especificado em detalhes e construdo em termos de subsistemas, classes e componentes.

medida que os casos de uso so especificados e atingem maturidade, mais detalhes da arquitetura so descobertos. Isto, por sua vez, leva ao surgimento de mais casos de uso.

Este processo continua at que a arquitetura seja considerada estvel.1.3 Iterativo e Incremental

O desenvolvimento de um produto comercial de software uma grande tarefa que pode ser estendida por vrios meses, possivelmente um ano ou mais. mais prtico dividir o trabalho em pedaos menores ou mini-projetos. Cada mini-projeto uma iterao que resulta em um incremento. Iteraes so passos em um fluxo de trabalho e incrementos so crescimentos do produto. Os desenvolvedores selecionam o que deve ser feito em cada iterao baseados em dois fatores. Primeiro, a iterao deve trabalhar com um grupo de casos de uso que juntos estendam a usabilidade do produto em desenvolvimento. Segundo, a iterao deve tratar os riscos mais importantes. Um incremento no necessariamente a adio do cdigo executvel correspondente aos casos de uso que pertence iterao em andamento. Especialmente nas primeiras fases do ciclo de desenvolvimento, os desenvolvedores podem substituir um projeto superficial por um mais detalhado ou sofisticado. Em fases avanadas os incrementos so tipicamente aditivos.Em cada iterao, os desenvolvedores identificam e especificam os casos de uso relevantes, criam um projeto utilizando a arquitetura escolhida como guia, implementam o projeto em componentes e verificam se esses componentes satisfazem os casos de uso. Se uma iterao atinge seus objetivos, e isso normalmente ocorre, o desenvolvimento prossegue com a prxima iterao, caso contrrio, os desenvolvedores devem rever suas decises e tentar uma nova abordagem.H vrios benefcios em se adotar um processo iterativo controlado, entre os quais podemos destacar: Reduo dos riscos envolvendo custos a um nico incremento. Se os desenvolvedores precisarem repetir a iterao, a organizao perde somente o esforo mal direcionado de uma iterao, no o valor de um produto inteiro.

Reduo do risco de lanar o projeto no mercado fora da data planejada. Identificando os riscos numa fase inicial o esforo despendido para gerenci-los ocorre cedo, quando as pessoas esto sob menos presso do que numa fase final de projeto.

Acelerao do tempo de desenvolvimento do projeto como um todo, porque os desenvolvedores trabalham de maneira mais eficiente quando buscam resultados de escopo pequeno e claro.

Reconhecimento de uma realidade freqentemente ignorada: as necessidades dos usurios e os requisitos correspondentes no podem ser totalmente definidos no incio do processo. Eles so tipicamente refinados em sucessivas iteraes. Este modelo de operao facilita a adaptao a mudanas de requisitos.

Os trs conceitos apresentados (dirigido a casos de uso, centrado em arquitetura, iterativo e incremental) so igualmente importantes. Remover um deles poderia reduzir drasticamente o valor do Processo Unificado, e agora que eles foram introduzidos, podemos observar seus elementos, o ciclo de vida, e o processo como um todo.2. Elementos do RUP

O RUP possui cinco elementos principais: papis, atividades, artefatos, fluxos de trabalho e disciplinas.

Um papel (ou perfil) define o comportamento e as responsabilidades de um determinado indivduo ou grupo de indivduos trabalhando como uma equipe. Papis no so indivduos e nem ttulos de trabalho. Um indivduo pode assumir vrios papis. So exemplos de papis:

Analista de sistema O indivduo que assume este papel coordena a obteno dos requisitos e a modelagem dos casos de uso, identificando funcionalidades do sistema e estabelecendo limites do sistema;

Projetista Esse indivduo define responsabilidades, operaes, atributos, relacionamentos de uma ou mais classes e determina como elas devem ser ajustadas para serem implementadas no ambiente;

Projetista de testes Responsvel pelo planejamento, projeto, implantao e avaliao de testes, incluindo a gerao de plano e modelo de teste, implementando procedimentos de testes e avaliando a abrangncia dos testes, resultados e a efetividade.

Uma atividade uma unidade de trabalho que um indivduo executa quando est exercendo um determinado papel e produz um resultado importante para o contexto do projeto. Cada atividade pode ser dividida em passos. So exemplos de atividades:

Planejar uma iterao: realizada pelo papel gerente de projeto;

Encontrar casos de uso e atores: realizada pelo papel analista de sistemas;

Rever o projeto: realizada pelo papel revisor de projeto;

Executar um teste de performance: realizado pelo papel testador de performance.

Um artefato um pedao de informao que produzido, modificado ou utilizado em um processo. Os artefatos so os produtos de um projeto. So as coisas produzidas durante o desenvolvimento do projeto. Artefatos so utilizados como entradas de atividades e so produzidos como sada. Os artefatos podem ter vrias formas:

Um modelo, como um modelo de caso de uso, um modelo de projeto;

Um elemento de um modelo, como uma classe, um caso de uso, um sub-sistema;

Um documento, como um caso de negcio, glossrio, viso;

Cdigo fonte;

Executveis.

A enumerao de atividades, papis e artefatos no constituem um processo. necessrio saber a seqncia do desenvolvimento das atividades para que possam ser produzidos artefatos de valor para o projeto. Um fluxo de trabalho uma seqncia de atividades que so executadas para a produo de um resultado valioso para o projeto. Fluxos de trabalho podem ser representados por diagramas de seqncia, diagramas de colaborao e diagramas de atividades da linguagem UML. O RUP utiliza trs tipos de fluxos de trabalho:

Fluxos de trabalho principais, associados com cada disciplina;

Fluxos de trabalho de detalhe, para detalhar cada fluxo de trabalho principal;

Planos de iterao, que mostram como a iterao dever ser executada.

Uma disciplina uma coleo de atividades relacionadas que fazem parte de um contexto comum em um projeto. As disciplinas proporcionam um melhor entendimento do projeto sob o ponto de vista tradicional de um processo cascata. A separao das atividades em disciplinas torna a compreenso das atividades mais fcil, porm dificulta mais o planejamento das atividades. O RUP possui nove disciplinas, divididas em disciplinas de processo e de suporte. As disciplinas de processo so: modelagem de negcios, requisitos, anlise e projeto, implementao, teste e implantao. As de suporte so: gerenciamento de configurao e mudanas, gerenciamento de projeto, e ambiente.

3. O ciclo de vida do Processo UnificadoO processo unificado consiste da repetio de uma srie de ciclos durante a vida de um sistema, como mostrado na Figura 1. Cada ciclo concludo com uma verso do produto pronta para distribuio. Essa verso um conjunto relativamente completo e consistente de artefatos, possivelmente incluindo manuais e um mdulo executvel do sistema, que podem ser distribudos para usurios internos ou externos.

Figura 1 Modelo de Ciclo de Vida Proposto pelo RUP

Cada ciclo consiste de quatro fases: Iniciao, Elaborao, Construo e Transio. Cada fase tambm subdividida em iteraes, como discutido anteriormente, vide figura 2.

Figura 2 Um ciclo com suas fases e iteraes

Rational Unified Process: Viso Geral

O Rational Unified Process (tambm chamado de processo RUP) um processo de engenharia de software. Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organizao de desenvolvimento. Sua meta garantir a produo de software de alta qualidade que atenda s necessidades dos usurios dentro de um cronograma e de um oramento previsveis.

A figura acima mostra a arquitetura geral do RUP.

O RUP tem duas dimenses:

O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo medida que se desenvolve

O eixo vertical representa as disciplinas, que agrupam as atividades de maneira naturalmente lgica.

A primeira dimenso representa o aspecto dinmico do processo quando ele aprovado e expressa em termos de fases, iteraes e marcos.

A segunda dimenso representa o aspecto esttico do processo, como ele descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papis do processo (consulte Conceitos-chave)

O grfico mostra como a nfase varia atravs do tempo. Por exemplo, nas iteraes iniciais, dedicamos mais tempo aos requisitos. J nas iteraes posteriores, gastamos mais tempo com implementao.

Rational Unified Process:Fases

As fases e os marcos de um projeto

A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) dividido em quatro fases seqenciais, cada uma concluda por um marco principal, ou seja, cada fase basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase executada uma avaliao (Atividade: Revisar Marcos do Ciclo de Vida) para determinar se os objetivos da fase foram alcanados. Uma avaliao satisfatria permite que o projeto passe para a prxima fase.

Fases de Planejamento

As fases no so idnticas em termos de programao e esforo. Embora isso varie muito de acordo com o projeto, um ciclo de desenvolvimento inicial tpico para um projeto de mdio tamanho deve prever a seguinte distribuio de esforo e programao:

IniciaoElaboraoConstruoTransio

Esforo~5 %20 %65 %10%

Programao10 %30 %50 %10%

que pode ser descrito graficamente como

Para um ciclo de evoluo, as fases de iniciao e de elaborao seriam bem menores. Ferramentas que automatizam parte do esforo de Construo podem amenizar isso, tornando a fase de construo muito menor do que as fases de iniciao e de elaborao juntas.

Uma passagem pelas quatro fases um ciclo de desenvolvimento; cada passagem pelas quatro fases produz uma verso do software. A menos que o produto "desaparea", ele ir se desenvolver na prxima verso, repetindo a mesma seqncia de fases de iniciao, elaborao, construo e transio, mas agora com nfase diferente nas diversas fases. Esses ciclos subseqentes so chamados de ciclos de evoluo. medida que o produto atravessa vrios ciclos, so produzidas novas geraes.

Os ciclos de evoluo podem ser disparados por melhorias sugeridas pelos usurios, mudanas no contexto do usurio, mudanas na tecnologia subjacente, reao concorrncia e assim por diante. Normalmente, os ciclos de evoluo tm fases de Iniciao e Elaborao bem menores, pois a definio e a arquitetura bsicas do produto foram determinadas por ciclos de desenvolvimento anteriores. So excees a essa regra os ciclos de evoluo em que ocorre uma redefinio significativa do produto ou da arquitetura.Fase: Iniciao (Inception)

Objetivos

A meta dominante da fase de iniciao atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto.A fase de iniciao tem muita importncia principalmente para os esforos dos desenvolvimentos novos, nos quais h muitos riscos de negcios e de requisitos que precisam ser tratados para que o projeto possa prosseguir. Para projetos que visam melhorias em um sistema existente, a fase de iniciao mais rpida, mas ainda se concentra em assegurar que o projeto seja compensatrio e que seja possvel faz-lo.

Os objetivos principais da fase Iniciao incluem:

Estabelecer o escopo do projeto do software e as condies limite, incluindo uma viso operacional, critrios de aceitao e o que deve ou no estar no produto.

Discriminar os casos de uso crticos do sistema, os principais cenrios de operao e o que direcionar as principais trocas de design.

Exibir, e talvez demonstrar, pelo menos uma opo de arquitetura para alguns cenrios bsicos.

Estimar o custo geral e a programao para o projeto inteiro (e estimativas detalhadas para a fase Elaborao, imediatamente a seguir).

Estimar riscos em potencial (as origens de imprevistos) (consulte Conceitos: Risco).

Preparar o ambiente de suporte para o projeto.

Atividades bsicas

Formular o escopo do projeto. Isso envolve capturar o contexto, bem como os requisitos e as restries mais importantes, para que seja possvel depreender critrios de aceitao para o produto final.

Planejar e preparar um caso de negcio. Avaliar alternativas para o gerenciamento de riscos, a organizao da equipe, o plano do projeto e as mudanas de custo/programao/lucros.

Sintetizar uma possvel arquitetura, avaliando as mudanas no design e em fazer/comprar/reutilizar, para que seja possvel estimar custo, programao e recursos. O objetivo aqui demonstrar a possibilidade de execuo atravs de alguma forma de prova de conceito. Isso pode ter a forma de um modelo que simula o que exigido, ou de um prottipo inicial que explora as reas consideradas de alto risco. O esforo do prottipo durante a iniciao deve se limitar a ganhar confiana na possibilidade de uma soluo - a soluo ser executada durante a elaborao e a construo.

Preparar o ambiente para o projeto, avaliando o projeto e a organizao, selecionando ferramentas e decidindo quais partes do processo devem ser melhoradas.

Marco: Objetivos do Ciclo de Vida (Lifecycle Objectives Milestone)

No final da fase Iniciao (Inception) est o primeiro marco mais importante do projeto ou Marco dos Objetivos do Ciclo de Vida. Nesse momento, voc analisa os objetivos do ciclo de vida do projeto e decide prosseguir com o projeto ou cancel-lo.

Critrios de Avaliao

Consentimento dos envolvidos sobre a definio do escopo e as estimativas de custo/programao.

Consenso de que o conjunto correto de requisitos foi capturado e de que existe uma compreenso compartilhada desses requisitos.

Consenso de que as estimativas de custo/programao, as prioridades, os riscos e o processo de desenvolvimento so adequados.

Todos os riscos foram identificados e existe uma estratgia de mitigao para cada um.

O projeto poder ser cancelado ou completamente repensado caso ele no atinja este marco.

Artefatos

Artefatos Bsicos (em ordem de importncia) Estado no marco

VisoOs requisitos principais, as caractersticas-chave e as principais restries do projeto foram documentados.

Caso de NegcioDefinido e aprovado.

Lista de RiscosRiscos iniciais do projeto identificados.

Plano de Desenvolvimento de SoftwareIdentificao das fases iniciais, durao e objetivo de cada uma. Estimativas de recursos (particularmente o tempo, o pessoal e os custos com ambiente de desenvolvimento) no Plano de Desenvolvimento de Software devem ser consistentes com o Caso de Negcio.

A estimativa de recursos pode abranger o projeto inteiro at a liberao, ou apenas uma estimativa de recursos necessrios para a fase de elaborao. As estimativas de recursos para o projeto inteiro devem ser vistas como brutas nesse momento. Essa estimativa atualizada em cada fase e cada iterao, e se torna mais exata a cada iterao.

Dependendo das necessidades do projeto, um ou mais artefatos de "Plano" includo pode ser concludo condicionalmente. Um Plano de Aceitao do Produto inicial deve ser analisado e receber uma baseline. O Plano de Aceitao do Produto refinado nas iteraes subseqentes medida que forem descobertos requisitos adicionais.

Alm disso, os artefatos de "Guias" includos normalmente esto pelo menos na forma de "rascunho".

Plano de IteraoO plano de iterao para a primeira iterao de Elaborao concludo e analisado.

Caso de DesenvolvimentoAdaptaes e extenses ao Rational Unified Process, documentadas e analisadas.

FerramentasTodas as ferramentas para suportar o projeto so selecionadas. So instaladas as ferramentas necessrias para o trabalho na Iniciao.

GlossrioTermos importantes definidos; glossrio analisado.

Modelo de Casos de Uso (Atores,Casos de Uso)Atores e casos de uso importantes identificados, e fluxos de eventos descritos apenas para os casos de uso mais crticos.

Repositrio do Projeto, Solicitao de MudanaO ambiente de Gerenciamento de Configurao deve estar configurado.

Artefatos Opcionais Estado no marco

Diretrizes de Modelagem de Casos de UsoCom baseline.

Modelo de Domnio (tambm conhecido como Modelo de Objeto de Negcio)Os conceitos-chave usados no sistema, documentados e analisados. Usado como uma extenso do Glossrio nos casos em que h relacionamentos especficos entre conceitos de captura essencial.

Templates Especficos do ProjetoOs templates de documentos usados para desenvolver os artefatos de documentos.

ProttiposUma ou mais provas de conceitos (prottipos), para suportar a Viso e o Caso de Negcio e para tratar riscos especficos.

Fase: Elaborao (Elaboration)Objetivos

A meta da fase Elaborao criar uma base para a arquitetura do sistema a fim de fornecer sustentabilidade ao esforo da fase Construo. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que tm grande impacto na arquitetura do sistema) e de uma avaliao dos riscos. A estabilidade da arquitetura avaliada atravs de um ou mais prottipos de arquitetura.

Os objetivos primrios da fase Elaborao incluem:

Assegurar que a arquitetura, os requisitos e os planos sejam estveis o suficiente e que os riscos sejam suficientemente diminudos a fim de determinar com segurana o custo e a programao para a concluso do desenvolvimento. Para a maioria dos projetos, ultrapassar essa marca tambm corresponde transio de uma operao rpida e de baixo risco para uma operao de alto custo e alto risco com uma inrcia organizacional freqente.

Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto.

Estabelecer uma arquitetura de base derivada do tratamento dos cenrios significativos do ponto de vista da arquitetura, que normalmente expem os maiores riscos tcnicos do projeto.

Produzir um prottipo evolutivo dos componentes de qualidade de produo, assim como um ou mais prottipos descartveis para diminuir riscos especficos como:

Trocas de design/requisitos

Reutilizao de componentes

Possibilidade de produo do produto ou demonstraes para investidores, clientes e usurios finais

Demonstrar que a arquitetura de base suportar os requisitos do sistema a custo e tempo justos.

Estabelecer um ambiente de suporte.

Para atingir esses objetivos bsicos, tambm importante configurar o ambiente de suporte para o projeto. Isso inclui criar um caso de desenvolvimento, criar templates e diretrizes, e configurar ferramentas.

Atividades bsicas

Definir, validar e criar a arquitetura de base com rapidez e eficincia.

Refinar a Viso, com base nas informaes novas obtidas durante a fase, estabelecendo uma compreenso slida dos casos de uso mais crticos que conduzem as decises de arquitetura e planejamento.

Criar planos de iterao detalhados e bases de referncia para a fase Construo.

Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte de automatizao necessrios para dar assistncia equipe de construo.

Refinar a arquitetura e selecionar os componentes. Os componentes potenciais so avaliados e as decises de fazer/comprar/reutilizar so bem compreendidas para determinar o custo da fase de construo e programar com confiana. Os componentes de arquitetura selecionados so integrados e avaliados em comparao com os cenrios bsicos. As lies aprendidas dessas atividades podem resultar em um novo design da arquitetura, levando em considerao designs alternativos ou reconsiderando os requisitos.

Marco: Arquitetura do Ciclo de Vida (Lifecycle Architecture Milestone)

No final na fase Elaborao est o segundo marco mais importante do projeto, o Marco da Arquitetura do Ciclo de Vida. Nesse momento, voc examina os objetivos e o escopo detalhados do sistema, a opo de arquitetura e a resoluo dos principais riscos. O marco Arquitetura do Ciclo de Vida estabelece uma base de referncia gerenciada para a arquitetura do sistema e permite o escalonamento da equipe do projeto na fase Construo.

Critrios de Avaliao

A Viso e os requisitos do produto so estveis.

A arquitetura estvel.

As abordagens principais a serem usadas no teste e na avaliao foram comprovadas.

O teste e a avaliao de prottipos executveis demonstraram que os principais elementos de risco foram tratados e resolvidos com credibilidade.

Os planos de iterao para a fase de construo tm detalhes e fidelidade suficientes para permitir o avano do trabalho.

Os planos de iterao para a fase Construo so garantidos por estimativas confiveis.

Todos os envolvidos concordam que a viso atual poder ser atendida se o plano atual for executado para desenvolver o sistema completo, no contexto da arquitetura atual.

A despesa real em oposio despesa planejada com recursos aceitvel.

O projeto poder ser cancelado ou completamente repensado caso ele no atinja este marco.

Artefatos

Artefatos Bsicos (em ordem de importncia)Estado no marco

ProttiposUm ou mais prottipos de arquitetura foram criados para explorar a funcionalidade crtica e os cenrios significativos do ponto de vista da arquitetura. Consulte a observao abaixo sobre o papel do prottipo.

Lista de RiscosAtualizada e analisada. Os novos riscos tendem a ser de natureza da arquitetura, relacionados basicamente ao gerenciamento de requisitos no funcionais.

Caso de DesenvolvimentoRefinado com base na experincia inicial do projeto. O ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte automatizado necessrios para dar assistncia equipe de construo j estar posicionada.

FerramentasAs ferramentas usadas para suportar o trabalho de Elaborao so instaladas.

Documento de Arquitetura de SoftwareCriado e com baseline, incluindo descries detalhadas para os casos de uso significativos para a arquitetura (viso de caso de uso), identificao dos mecanismos principais e dos elementos de design (viso lgica), mais a definio da viso de processos e da viso da implantao (do Modelo de Implantao) caso o sistema seja distribudo ou deva lidar com problemas de concorrncia.

Modelo de Design (e todos os artefatos constituintes)Definido e com baseline. Realizaes de caso de uso para cenrios significativos do ponto de vista da arquitetura foram definidas, e o comportamento necessrio foi alocado para os elementos de design apropriados. Os componentes foram identificados, e as decises de fazer/comprar/reutilizar foram compreendidas para determinar o custo da fase de construo e programar com confiana. Os componentes de arquitetura selecionados so integrados e avaliados em comparao com os cenrios bsicos. As lies aprendidas dessas atividades podem resultar em um novo design da arquitetura, levando em considerao designs alternativos ou reconsiderando os requisitos.

Modelo de DadosDefinido e com baseline. Os elementos de modelo de dados principais (por exemplo, entidades, relacionamentos, tabelas importantes) definidos e analisados.

Modelo de Implementao (e todos os artefatos constituintes, incluindo Componentes)Estrutura inicial criada e componentes principais identificados e com prottipos.

VisoRefinada, com base nas informaes novas obtidas durante a fase, estabelecendo uma compreenso slida dos casos de uso mais crticos que conduzem as decises de arquitetura e planejamento.

Plano de Desenvolvimento de SoftwareAtualizado e expandido para cobrir as fases de Construo e Transio.

Guias, como Guia de Design e Guia de ProgramaoOs guias usados para suportar o trabalho.

Plano de IteraoPlano de iterao para a fase de construo concludo e analisado.

Modelo de Casos de Uso (Atores,Casos de Uso)Um modelo de casos de uso (aproximadamente 80% concludo) todos os casos de uso sendo identificados na pesquisa de modelo de casos de uso, todos os atores sendo identificados e a maioria das descries de caso de uso (captura de requisitos) sendo desenvolvida.

Especificaes SuplementaresOs requisitos suplementares abrangendo os requisitos no funcionais so documentados e analisados.

Conjunto de Testes ("teste de regresso")Testes implementados e executados para validar a estabilidade do build para cada release executvel criado durante a fase de elaborao.

Arquitetura para Automatizao de TestesUma composio de baseline de vrios mecanismos e elementos-chave de software que compem as caractersticas fundamentais do sistema de software de automatizao de teste.

Artefatos OpcionaisEstado no marco

Caso de NegcioAtualizado se as investigaes sobre a arquitetura descobrirem problemas que mudem premissas fundamentais do projeto.

Modelo de AnlisePode ser desenvolvido como um artefato formal; freqentemente mantido de forma no formal, evoluindo, em vez disso, para uma verso inicial do Modelo de Design.

Materiais de TreinamentoManuais do Usurio e outros materiais de treinamento. Rascunho preliminar, baseado em casos de uso. Poder ser necessrio se o sistema tiver um forte aspecto de interface de usurio.

Templates Especficos do ProjetoOs templates de documentos usados para desenvolver os artefatos de documentos.

O Papel da Criao de Prottipo

O Rational Unified Process d ao arquiteto de software e ao gerente de projeto a liberdade de construir prottipos de vrios tipos (consulte Conceitos: Prottipos) como uma estratgia de reduo de riscos. Alguns desses prottipos podem ser puramente exploratrios e sero posteriormente descartados. Contudo, provvel (para sistemas grandes e sem precedentes) que a arquitetura tenha sido construda como uma srie de prottipos evolucionrios abrangendo diferentes problemas no decorrer da elaborao e, no fim da elaborao, ter atingido o ponto mximo em uma base de arquitetura estvel e integrada. No queremos sugerir com isso que o esforo de criao de prottipos durante a elaborao deva resultar em um conjunto de fragmentos de arquitetura que no precisam ser integrados.

Fase: Construo (Construction)

Objetivos

A meta da fase Construo esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura definida. A fase Construo de certa forma um processo de manufatura, em que a nfase est no gerenciamento de recursos e controle de operaes para otimizar custos, programaes e qualidade. Nesse sentido, a mentalidade do gerenciamento passa por uma transio de desenvolvimento da propriedade intelectual durante a Iniciao e Elaborao, para o desenvolvimento de produtos que podem ser implantados durante a Construo e Transio.

Os objetivos principais da fase de construo incluem:

Minimizar os custos de desenvolvimento, otimizando recursos e evitando retalhamento e retrabalho desnecessrios.

Atingir a qualidade adequada com rapidez e eficincia.

Atingir as verses teis (alfa, beta e outros releases de teste) com rapidez e eficincia.

Concluir a anlise, o design, o desenvolvimento e o teste de todas as funcionalidades necessrias.

Desenvolver de modo iterativo e incremental um produto completo que esteja pronto para a transio para a sua comunidade de usurios. Isso implica descrever os casos de uso restantes e outros requisitos, incrementar o design, concluir a implementao e testar o software.

Decidir se o software, os locais e os usurios esto prontos para que o aplicativo seja implantado.

Atingir certo paralelismo entre o trabalho das equipes de desenvolvimento. Mesmo em projetos menores, normalmente h componentes que podem ser desenvolvidos um independente do outro, permitindo o paralelismo natural entre as equipes (se os recursos permitirem). O paralelismo pode acelerar bastante as atividades de desenvolvimento; mas tambm aumenta a complexidade do gerenciamento de recursos e da sincronizao dos fluxos de trabalho. Uma arquitetura sofisticada ser essencial para atingir um paralelismo significativo.

Atividades Bsicas

Gerenciamento de recursos, otimizao de controle e processo

Desenvolvimento completo dos componentes e teste dos critrios de avaliao definidos

Avaliao dos releases do produto de acordo com os critrios de aceitao para a viso

Marco: Capacidade Operacional Inicial (Initial Operational Capability)

No Marco da Capacidade Operacional Inicial, o produto est pronto para ser passado para a Equipe de Transio. Todas as funcionalidades j foram desenvolvidas e todos os alfa-testes (se houver algum) foram concludos. Alm do software, um manual do usurio foi desenvolvido, e existe uma descrio do release atual. O marco Capacidade Operacional Inicial determina se o produto est pronto para ser implantado em um ambiente de teste beta.

Critrios de Avaliao

Os critrios de avaliao para a fase Construo envolvem as respostas para estas questes:

Este release do produto estvel e desenvolvido o suficiente para ser implantado na comunidade de usurios?

Todos os envolvidos esto prontos para a transio para a comunidade de usurios?

As despesas reais com recursos ainda so aceitveis se comparadas com as planejadas?

Talvez a transio tenha de ser adiada por um release se o projeto no atingir esse marco.

Artefatos

Artefatos Bsicos (em ordem de importncia)Estado no marco

"O Sistema"O prprio sistema executvel, pronto para comear o teste "beta".

Plano de ImplantaoVerso inicial desenvolvida, analisada e com baseline. Em projetos menores, isso pode ser embutido no Plano de Desenvolvimento de Software.

Modelo de Implementao (e todos os artefatos constituintes, incluindo Componentes)Expandido a partir daquele criado durante a fase de elaborao; todos os componentes criados no final da fase de construo.

Conjunto de Testes ("teste de regresso")Testes implementados e executados para validar a estabilidade do build de cada release executvel criado durante a fase de construo.

Materiais de TreinamentoManuais do Usurio e outros materiais de treinamento. Rascunho preliminar, baseado em casos de uso. Poder ser necessrio se o sistema tiver um forte aspecto de interface de usurio.

Plano de IteraoPlano de iterao para a fase de transio concludo e analisado.

Modelo de Design (e todos os artefatos constituintes)Atualizado com novos elementos de design identificados durante a concluso de todos os requisitos.

Caso de DesenvolvimentoRefinado com base na experincia inicial do projeto. O ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte automatizado necessrios para dar assistncia equipe de transio j estar posicionada.

FerramentasAs ferramentas usadas para dar suporte ao trabalho de Construo so instaladas.

Modelo de DadosAtualizado com todos os elementos necessrios para suportar a implementao persistente (por exemplo, tabelas, ndices, etc.).

Artefatos OpcionaisEstado no marco

Templates Especficos do ProjetoOs templates de documentos usados para desenvolver os artefatos de documentos.

Especificaes SuplementaresAtualizadas com novos requisitos (se houver) descobertos durante a fase de construo.

Modelo de Casos de Uso (Atores,Casos de Uso)Atualizado com novos casos de uso (se houver) descobertos durante a fase de construo.

Fase: Transio (Transition)

Objetivos

O foco da Fase Transio assegurar que o software esteja disponvel para seus usurios finais. A Fase Transio pode atravessar vrias iteraes e inclui testar o produto em preparao para liberao e pequenos ajustes com base no feedback do usurio. Nesse momento do ciclo de vida, o feedback do usurio deve priorizar o ajuste fino do produto, a configurao, a instalao e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhados muito antes no ciclo de vida do projeto.

No fim do ciclo de vida da fase Transio, os objetivos devem ter sido atendidos e o projeto deve estar em uma posio para fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o incio de outro ciclo de vida no mesmo produto, conduzindo nova gerao ou verso do produto. Para outros projetos, o fim da Transio pode coincidir com uma liberao total dos artefatos a terceiros que podero ser responsveis pela operao, manuteno e melhorias no sistema liberado.

A fase Transio pode ser muito fcil ou muito complexa, dependendo do tipo de produto. Um novo release de um produto de mesa existente pode ser muito simples, ao passo que a substituio do sistema de controle do trfego areo de um pas pode ser excessivamente complexa.

As atividades realizadas durante uma iterao na fase Transio dependem da meta. Por exemplo,ao corrigir erros, normalmente bastam a implementao e o teste. Se, no entanto, novas caractersticas tiverem de ser adicionadas, a iterao ser semelhante a uma fase de construo, exigindo anlise, design, etc.

A fase Transio entra quando uma base estiver desenvolvida o suficiente para ser implantada no domnio do usurio final. Isso normalmente requer que algum subconjunto usvel do sistema tenha sido concludo com nvel de qualidade aceitvel e documentao do usurio, de modo que a transio para o usurio fornea resultados positivos para todas as partes.

Os objetivos principais da fase Transio so:

Teste beta para validar o novo sistema em confronto com as expectativas do usurio

Teste beta e operao paralela relativa a um sistema legado que est sendo substitudo

Converso de bancos de dados operacionais

Treinamento de usurios e equipe de manuteno

Introduo ao marketing, distribuio e equipe de vendas

Engenharia voltada para implantao, como preparao, empacotamento e produo comercial, introduo a vendas, treinamento de pessoal em campo

Atividades de ajuste, como correo de erros, melhoria no desempenho e na usabilidade

Avaliao das bases de implantao tendo como guia a viso completa e os critrios de aceitao para o produto

Obteno de auto-suportabilidade do usurio

Obteno do de acordo dos envolvidos de que as bases de implantao esto completas

Obteno do de acordo dos envolvidos de que as bases de implantao so consistentes com os critrios de avaliao da viso

Atividades bsicas

Executar planos de implantao

Finalizar o material de suporte para o usurio final

Testar o produto liberado no local do desenvolvimento

Criar um release do produto

Obter feedback do usurio

Ajustar o produto com base em feedbacks

Disponibilizar o produto para os usurios finais

Marco: Release do Produto (Product Release)

No fim na fase Transio est o quarto marco mais importante do projeto, o Marco Release do Produto. Nesse momento, voc avalia se os objetivos foram alcanados, e se outro ciclo de desenvolvimento deve ser iniciado. Em alguns casos, esse marco pode coincidir com o fim da fase Iniciao do prximo ciclo. O Marco do Release do Produto o resultado da concluso com xito da Atividade: Reviso da Aceitao do Projeto.

Critrios de Avaliao

Os critrios bsicos de avaliao para a fase de transio envolvem as respostas para estas questes:

O usurio est satisfeito?

As despesas reais com recursos so aceitveis se comparadas com as planejadas?

No Marco do Release do Produto, o produto est em produo e o ciclo de manuteno posterior ao release se inicia. Isso pode envolver o incio de um novo ciclo de desenvolvimento ou de algum release de manuteno adicional.

Artefatos

Artefatos Bsicos (em ordem de importncia)Estado no marco

O Build do ProdutoConcludo de acordo com os requisitos do produto. O produto final deve ser utilizvel pelo consumidor.

Notas de ReleaseConcludas.

Artefatos de InstalaoConcludos.

Material de TreinamentoConcludo para assegurar que o cliente possa ser auto-suficiente na utilizao e manuteno do produto.

Material de Suporte para o Usurio FinalConcludo para assegurar que o cliente possa ser auto-suficiente na utilizao e manuteno do produto.

Artefatos OpcionaisEstado no marco

Conjunto de Testes ("teste de regresso")O conjunto de testes desenvolvidos para validar a estabilidade de cada build pode ser fornecido na situao em que o cliente deseja executar um nvel bsico de teste no local.

Empacotamento Compacto do ProdutoNo caso de criar um produto compacto, o contratante precisar dos artefatos de empacotamento necessrios para ajudar a colocar o produto no varejo.

Estudo das Principais DisciplinasRequisitos

1. Conceitos

Design Centrado no Usurio Gerenciamento de Requisitos Rastreabilidade Requisitos Tipos de Requisitos Viso de Casos de Uso Documento de visoDesign Centrado no Usurio

Gerenciamento de Requisitos

O gerenciamento de requisitos um modelo sistemtico para encontrar, documentar, organizar e rastrear os requisitos variveis de um sistema.

Um requisito definido como uma condio ou uma capacidade com a qual o sistema deve estar de acordo.

Nossa definio formal de gerenciamento de requisitos trata-se de um modelo sistemtico para:

Identificar, organizar e documentar os requisitos do sistema, e

Estabelecer e manter acordo entre o cliente e a equipe do projeto nos requisitos variveis do sistema.

Os principais itens para o gerenciamento eficiente de requisitos incluem manter uma declarao clara dos requisitos, juntamente com atributos aplicveis para cada tipo de requisito e rastreabilidade para outros requisitos e outros artefatos do projeto.

A coleta de requisitos pode parecer uma tarefa bem precisa. Nos projetos reais, contudo, voc encontrar dificuldades por que:

Nem sempre os requisitos so bvios e podem vir de vrias fontes.

Nem sempre fcil expressar os requisitos claramente em palavras.

Existem diversos tipos de requisitos em diferentes nveis de detalhe.

O nmero de requisitos poder impossibilitar a gerncia se no for controlado.

Os requisitos esto relacionados uns com os outros, e tambm com o produto liberado do processo de engenharia do software.

Os requisitos tm propriedades exclusivas ou valores de propriedade. Por exemplo, eles no so igualmente importantes nem igualmente fceis de cumprir.

H vrias partes interessadas, o que significa que os requisitos precisam ser gerenciados por grupos de pessoas de diferentes funes.

Os requisitos so alterados.

Ento, que habilidades voc precisa desenvolver em sua organizao para ajud-lo a gerenciar essas dificuldades? Ns aprendemos que importante dominar as seguintes habilidades:

Anlise do problema

Noes bsicas sobre as necessidades dos envolvidos

Definio do sistema

Gerenciamento do escopo do projeto

Refinamento da definio do sistema

Gerenciamento dos requisitos variveis

Anlise do Problema

A anlise do problema feita para compreender os problemas e as necessidades iniciais dos envolvidos, e propor solues de alto nvel. um ato de ponderao e anlise encontrar "o problema por trs do problema". Durante a anlise do problema, so reconhecidos os problemas reais e quais so os envolvidos. Alm disso, voc define quais so, de uma perspectiva de negcios, as fronteiras da soluo e as restries de negcios da soluo. Voc tambm dever ter analisado o caso de negcio para o projeto, para que haja uma boa compreenso de qual o retorno esperado do investimento feito do sistema que est sendo construdo.

Consulte tambm Detalhamento do Fluxo de Trabalho: Analisar o Problema.

Noes Bsicas sobre as Necessidades dos Envolvidos

Os requisitos vm de vrias fontes, como clientes, parceiros, usurios finais e peritos do domnio. Voc precisa saber o melhor modo de determinar quais devem ser as fontes, como obter acesso a essas fontes e qual a melhor forma de levantar as informaes delas. Os indivduos que constituem as fontes primrias para essas informaes so conhecidos como os envolvidos no projeto. Se estiver desenvolvendo um sistema de informaes para ser usado internamente na sua empresa, voc dever incluir na sua equipe de desenvolvimento pessoas com experincia de usurio final e com experincia no domnio do negcio. Com bastante freqncia, voc comear os debates no nvel de um modelo de negcio em vez de no nvel de um sistema. Se estiver desenvolvendo um produto para ser vendido para um estabelecimento comercial, voc dever fazer uso extensivo do seu pessoal de marketing para entender melhor as necessidades dos clientes daquele mercado.

O levantamento de informaes pode ocorrer atravs de tcnicas como entrevistas, discusso de idias, prottipos conceituais, questionrios e anlise competitiva. O resultado do levantamento seria uma lista das solicitaes ou necessidades que foram descritas textual e graficamente, e que receberam prioridade uma em relao outra.

Consulte tambm Detalhamento do Fluxo de Trabalho: Compreender as Necessidades dos Envolvidos.

Definio do Sistema

Definir o sistema significa traduzir e organizar as necessidades dos envolvidos em descries significativas do sistema a ser construdo. No incio da definio do sistema, ocorre o seguinte: as decises sobre o que constitui um requisito, o formato de documentao, a formalidade do idioma, o grau de especificidade dos requisitos (quantos e com que detalhe), a prioridade das solicitaes e o esforo estimado (duas avaliaes bem diferentes em geral atribudas por pessoas diferentes em testes separados), os riscos tcnicos e de gerenciamento, e o escopo inicial. Parte dessa atividade pode incluir modelos de design e prottipos iniciais diretamente relacionados aos mais importantes requisitos dos envolvidos. O resultado da definio do sistema uma descrio do sistema que esteja em idioma natural e tambm seja grfica.

Consulte tambm Detalhamento do Fluxo de Trabalho: Definir o Sistema.

Gerenciamento do Escopo de um Projeto

Para gerenciar com eficincia um projeto, necessrio priorizar os requisitos, com base em retorno dado por todos os envolvidos, e gerenciar o seu escopo. Vrios projetos tm seus desenvolvedores trabalhando nos chamados "ovos de Pscoa" (caractersticas que o desenvolvedor acha interessantes e desafiadoras), em vez de estarem concentrados desde o incio em tarefas que aliviam algum risco no projeto ou estabilizam a arquitetura do aplicativo. Para assegurar que os riscos de um projeto sejam resolvidos ou aliviados o mais cedo possvel, voc deve desenvolver seu sistema de modo incremental, escolhendo cuidadosamente os requisitos para cada incremento que alivia os riscos conhecidos do projeto. Para faz-lo, voc precisa negociar o escopo (de cada iterao) com os envolvidos no projeto. Normalmente, isso requer boas habilidades no gerenciamento de expectativas dos resultados do projeto em suas diferentes fases. Voc tambm precisa ter controle das origens dos requisitos, da aparncia dos produtos liberados pelo projeto e do processo de desenvolvimento propriamente dito.

Consulte tambm Detalhamento do Fluxo de Trabalho: Gerenciar o Escopo do Sistema.

Refinamento da Definio do Sistema

A definio detalhada do sistema precisa ser apresentada de maneira que os envolvidos possam entend-la, concordar com ela e sair dela. Ela precisa abordar no apenas a funcionalidade, mas tambm a compatibilidade com os requisitos legais ou reguladores, a usabilidade, a confiabilidade, o desempenho, a capacidade de suporte e de manuteno. Um erro comum acreditar que o que voc sente complexo para estabelecer necessidades que tenham uma definio complexa. Isso cria dificuldades para explicar a finalidade do projeto e do sistema. As pessoas podem ficar impressionadas, mas elas no daro bons retornos por falta de compreenso. Voc deve se esforar para compreender o pblico destinado aos documentos que voc produz para descrever o sistema. Voc sempre poder produzir vrios tipos de descrio para pblicos diferentes.

J vimos que a metodologia do caso de uso, muitas vezes em combinao com prottipos visuais simples, um modo bem eficiente de comunicar a finalidade do sistema e definir os detalhes do sistema. Os casos de uso ajudam a colocar os requisitos em um contexto, eles contam uma histria de como o sistema ser usado.

Outro componente da definio detalhada do sistema estabelecer como o sistema dever ser testado. Planos de teste e definies dos testes a serem realizados nos dizem quais capacidades do sistema sero verificadas.

Consulte tambm Detalhamento do Fluxo de Trabalho: Refinar a Definio do Sistema .

Gerenciamento dos Requisitos Variveis

No importa o quo cuidadoso voc seja sobre a definio dos seus requisitos, sempre haver mudanas. O que torna complexo o gerenciamento dos requisitos variveis no apenas que um requisito mudado implicar mais ou menos tempo gasto na implementao de uma determinada caracterstica nova, mas tambm que a mudana em um requisito ter impacto em outros requisitos. Voc precisa certificar-se de compor uma estrutura de requisitos que seja adaptvel a mudanas, e de usar vnculos de rastreabilidade para representar as dependncias entre os requisitos e outros artefatos do ciclo de vida do desenvolvimento. O gerenciamento de mudana inclui atividades como estabelecer uma linha de base, determinar quais dependncias so importantes de serem rastreadas, estabelecer a rastreabilidade entre itens correlatos e o controle de mudana.Rastreabilidade

A rastreabilidade a capacidade de rastrear um elemento do projeto junto a outros elementos correlatos, especialmente aqueles relacionados a requisitos. Os elementos do projeto envolvidos em rastreabilidade so chamados de itens de rastreabilidade. Os itens tpicos de rastreabilidade incluem diferentes tipos de requisitos, elementos de modelo de design e de anlise, artefatos de testes (conjuntos de testes, casos de teste, etc.) e material de treinamento e documentao de suporte a usurio final, como mostrado na figura abaixo.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workflow/requirem/images/co_tracg.gif" \* MERGEFORMATINET

A hierarquia da rastreabilidade.

Cada item de rastreabilidade possui seu prprio conjunto exclusivo de atributos associados, que til para rastrear o status, benefcio ou risco associado a cada item.

Finalidade da Rastreabilidade

A finalidade de estabelecer rastreabilidade ajudar a:

Compreender a origem dos requisitos

Gerenciar o escopo do projeto

Gerenciar mudanas nos requisitos

Avaliar o impacto no projeto decorrente da mudana em um requisito

Avaliar o impacto da falha de um teste nos requisitos (isto , se o teste falhar, talvez o requisito no seja atendido)

Verificar se todos os requisitos do sistema so desempenhados pela implementao

Verificar se o aplicativo faz apenas o que era esperado que ele fizesse.

A rastreabilidade o ajuda a compreender e gerenciar como as informaes fornecidas sobre os requisitos, como Regras de Negcios e Solicitaes dos Principais Envolvidos, so convertidas em um conjunto de necessidades-chave dos envolvidos/usurios e caractersticas do sistema, conforme especificado no documento de viso. O modelo de Casos de Uso, por sua vez, descreve como essas caractersticas so convertidas na funcionalidade do sistema. Os detalhes de como o sistema interage com o mundo externo so capturados nos Casos de Uso, com outros requisitos importantes (como requisitos no funcionais, restries de design, etc.) nas Especificaes Suplementares. A rastreabilidade tambm lhe permite acompanhar como essas especificaes detalhadas so traduzidas em um design, como elas so testadas e como elas so documentadas para o usurio. No caso de um sistema grande, os casos de uso e as Especificaes Suplementares podem ser reunidos para definir uma Especificao de Requisitos de Software (SRS) para uma "caracterstica" particular ou outros agrupamentos de subsistemas.

Um conceito-chave para ajudar a gerenciar mudanas nos requisitos o de um vnculo de rastreabilidade "suspeito". Quando um requisito (ou outro item de rastreabilidade) muda em qualquer extremidade do vnculo de rastreabilidade, todos os vnculos associados quele requisito so marcados como "suspeitos". Isso uma marca para que o papel responsvel analise a mudana e determine se os itens associados precisaro mudar tambm. Esse conceito tambm ajuda a analisar o impacto de mudanas potenciais.

As rastreabilidades podem ser configuradas para ajudar a responder o seguinte conjunto de questes de exemplo:

Mostre-me as necessidades dos usurios que no foram vinculadas a caractersticas do produto.

Mostre-me o status dos testes em todos os casos de uso na interao #n.

Mostre-me todos os requisitos suplementares vinculados a testes que possuem status no testado.

Mostre-me os resultados de todos os testes que falharam, em ordem de importncia.

Mostre-me as caractersticas programadas para este lanamento, quais necessidades de usurios elas satisfazem e o status delas.

Exemplo:

Para o sistema de uma Mquina de Reciclagem, o documento de viso especifica a seguinte caracterstica:

CARACT10: A mquina de reciclagem permitir a adio de novos tipos de recipientes.

Essa caracterstica rastreada para um caso de uso "Adicionar Novo Tipo de Recipiente":

O caso de uso Adicionar Novo Tipo de Recipiente permite que o Operador ensine Mquina de Reciclagem a reconhecer novos modelos de recipientes.

Essa rastreabilidade nos ajuda a verificar se todas as caractersticas foram contempladas nos casos de uso e nas especificaes suplementares.

Rastreabilidade Tpica

Os itens de rastreabilidade mais importantes so:

Necessidades dos Usurios/Envolvidos (da Viso, podem ser rastreados para Solicitaes dos Principais Envolvidos individuais)

Caracterstica do Produto (da Viso)

Requisitos Suplementares (das Especificaes Suplementares)

Caso de Uso Seo de Caso de Uso (sees de um caso de uso detalhado)

Elemento de Design (do modelo de design)

Conjunto de Testes (ou potencialmente Caso de Teste)

Tambm pode ser til rastrear outros elementos, como Regras de Negcios e Problemas.

Uma rastreabilidade tpica mostrada no diagrama abaixo:

Esse diagrama s mostra a rastreabilidade para requisitos. Podem existir tambm outras rastreabilidades, mas elas no so mostradas nesse diagrama: elementos de design rastreiam para componentes da implementao, existem casos de teste para design e implementao, etc.Requisitos

Tradicionalmente, os requisitos so vistos como declaraes de texto que se encaixam em uma das categorias mencionadas em Conceitos: Requisitos. Cada requisito define "uma condio ou uma capacidade com a qual o sistema deve estar de acordo".

Para realizar um gerenciamento de requisitos eficiente, ns aprendemos que isso ajuda estender o que mantemos como requisitos somente alm dos "requisitos de software" detalhados. Introduzimos a noo de tipos de requisitos para ajudar a separar os diversos nveis de abstrao e finalidades dos nossos requisitos.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workflow/requirem/images/co_tracg.gif" \* MERGEFORMATINET

Convm controlarmos "desejos" ambguos, bem como solicitaes formais, dos principais envolvidos para verificarmos se sabemos como eles esto sendo cuidados. O documento de viso nos ajuda a controlar as principais "necessidades do usurio" e as "caractersticas" do sistema. O modelo de casos de uso um modo eficiente de expressar os "requisitos de software" funcionais e detalhados, portanto, os casos de uso talvez precisem ser rastreados e mantidos como requisitos, bem como talvez declaraes isoladas dentro das propriedades que definem as "condies ou capacidades com as quais o sistema deve estar de acordo". As Especificaes Suplementares podem conter outros "requisitos de software", como restries de design ou requisitos jurdicos ou reguladores do nosso sistema. Para obter uma definio completa dos requisitos de software, os casos de uso e as Especificaes Suplementares podem ser reunidos para definir uma Especificao de Requisitos de Software (SRS) para uma "caracterstica" particular ou outros agrupamentos de subsistemas.Quanto maior e mais confuso o sistema desenvolvido, mais expresses ou tipos de requisitos aparecero e maior ser o volume de requisitos. Declaraes de "regras de negcios" e de "viso" para um projeto levam a "necessidades do usurio", a "caractersticas" ou a outros "requisitos do produto". Casos de uso ou outras formas de modelagem e outras Especificaes Suplementares conduzem os requisitos de design, que podem ser decompostos em "requisitos de software" funcionais e no funcionais representados em diagramas e modelos de anlise e design.

Tipos de Requisitos

Um requisito definido como "uma condio ou uma capacidade com a qual o sistema deve estar de acordo".

Existem vrios tipos de requisitos. Um modo de categoriz-los descrito como o modelo FURPS+ [GRA92], usando o acrnimo FURPS para descrever as principais categorias de requisitos com subcategorias como mostrado abaixo.

Funcionalidade

Usabilidade

Confiabilidade

Desempenho

Suportabilidade

O "+" em FURPS+ para lembr-lo de incluir requisitos como:

restries de design

requisitos de implementao

requisitos de interface

requisitos fsicos.

Os requisitos funcionais especificam aes que um sistema deve ser capaz de executar, sem levar em considerao restries fsicas. Geralmente, isso mais bem descrito em um modelo de casos de uso e em casos de uso. Os requisitos funcionais especificam, portanto, o comportamento de entrada e sada de um sistema.

Os requisitos que no so funcionais, como os listados abaixo, s vezes so chamados de requisitos no funcionais. Vrios requisitos no so funcionais e descrevem apenas atributos do sistema ou atributos do ambiente do sistema. Embora alguns deles possam ser capturados em casos de uso, aqueles que no puderem talvez estejam especificados em Especificaes Suplementares. Os requisitos no funcionais so aqueles que dizem respeito a questes como as descritas abaixo.

Uma definio completa dos requisitos do software, dos casos de uso e das Especificaes Suplementares pode ser reunida para definir uma Especificao de Requisitos de Software (SRS) para uma "caracterstica" particular ou outros agrupamentos de subsistemas.

Funcionalidade

Os requisitos funcionais podem incluir:

Conjuntos de recursos

Habilidades Segurana Usabilidade

Os requisitos de usabilidade podem incluir subcategorias como:

Fatores humanos (consulte Conceitos: Design Centrado no Usurio)

Esttica Consistncia na interface do usurio (consulte Diretrizes: Interface do Usurio)

Ajuda on-line e contextual

Assistentes e agentes

Documentao do usurio

Materiais de treinamento

Confiabilidade

Os requisitos de confiabilidade a serem considerados so:

Freqncia e gravidade de falha

Possibilidade de recuperao

Possibilidade de previso

Exatido Tempo mdio entre falhas (MTBF)

Desempenho

Um requisito de desempenho impe condies aos requisitos funcionais. Por exemplo, para uma determinada ao, ele pode especificar parmetros de desempenho para:

Velocidade Eficincia Disponibilidade Exatido Taxa de transferncia

Tempo de resposta

Tempo de recuperao

Uso de recurso

Suportabilidade

Os requisitos de suporte podem incluir:

Possibilidade de teste

Extensibilidade Adaptabilidade Manutenibilidade Compatibilidade Possibilidade de configurao

Possibilidade de servio

Possibilidade de instalao

Possibilidade de localizao (internacionalizao)

Requisito de Design

Um requisito de design, freqentemente chamado de uma restrio de design, especifica ou restringe o design de um sistema.

Requisito de Implementao

Um requisito de implementao especifica ou restringe o cdigo ou a construo de um sistema. Como exemplos, podemos citar:

Padres obrigatrios

Linguagens de implementao

Polticas de integridade de banco de dados

Limites de recursos

Ambientes operacionais

Requisito de Interface

Um requisito de interface especifica:

um item externo com o qual o sistema deve interagir

restries de formatos, tempos ou outros fatores usados por tal interao

Requisito Fsico

Um requisito fsico especifica uma caracterstica fsica que um sistema deve possuir, por exemplo:

Material Forma Tamanho Peso Esse tipo de requisito pode ser usado para representar requisitos de hardware, como as configuraes fsicas de rede obrigatrias.Viso de Casos de Uso

Uma viso de arquitetura chamada viso de casos de uso utilizada na disciplina Requisitos para fornecer uma base para o planejamento do contedo tcnico de iteraes. S existe uma viso de casos de uso do sistema, que ilustra os casos de uso e cenrios que englobam o comportamento, as classes ou os riscos tcnicos significativos do ponto de vista da arquitetura. A viso de casos de uso refinada e considerada inicialmente em cada iterao.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workflow/requirem/images/co_ucv1.gif" \* MERGEFORMATINET

A viso de casos de uso mostra um subconjunto do modelo de casos de uso, um subconjunto de casos de uso e atores significativos para a arquitetura.

A anlise, o design e as atividades de implementao subseqentes aos requisitos so centrados na noo de uma arquitetura. A produo e a validao dessa arquitetura so o foco principal das iteraes iniciais, especialmente durante a fase Elaborao. A arquitetura representada por vrias vises de arquitetura, que, na essncia, so fragmentos que ilustram os elementos dos modelos "significativos do ponto de vista da arquitetura".

Existem quatro vises adicionais: Viso Lgica, Viso de Processos, Viso de Implantao e Viso de Implementao. Essas vises so tratadas nas disciplinas Anlise e Design e Implementao.

As vises de arquitetura esto documentadas em Documento de Arquitetura de Software. Voc pode incluir diferentes vises como, por exemplo, uma viso de segurana para comunicar outros aspectos especficos da arquitetura do software.

Assim, as vises de arquitetura podem ser vistas como abstraes ou simplificaes dos modelos construdos, nas quais voc torna as caractersticas importantes mais visveis, deixando os detalhes de lado. A arquitetura um importante meio de aumentar a qualidade de qualquer modelo criado durante o desenvolvimento do sistema.

Documento de Viso

O Documento de Viso tem por objetivo definir a viso que os envolvidos tm do produto a ser desenvolvido, em termos de necessidades e caractersticas mais importantes. Por conter uma descrio dos requisitos centrais pretendidos, ele proporciona a base contratual para requisitos tcnicos mais detalhados.

O Documento de Viso fornece uma base de alto nvel - algumas vezes contratual - para os requisitos tcnicos mais detalhados. Tambm pode conter uma especificao formal de requisitos. O documento de Viso captura restries de design e requisitos de nvel muito elevado para que o leitor possa compreender o sistema a ser desenvolvido. Ele fornece informaes para o processo de aprovao do projeto e, portanto, est intrinsecamente relacionado ao Caso de Negcio. Ele comunica os principais questionamentos relacionados ao projeto e funciona como um regulador com base no qual todas as decises futuras devero ser validadas.

O documento de Viso ser lido pelos papis de gerentes e autoridades financeiras da modelagem de casos de uso e pelos desenvolvedores em geral.

Ocorrncia

O documento de Viso criado no incio da fase de Iniciao e usado como base para o Caso de Negcio (consulte Artefato: Caso de Negcio) e para o primeiro esboo da Lista de Riscos (consulte Artefato: Lista de Riscos).

O documento de Viso serve como base para a modelagem de casos de uso. Ele atualizado e mantido como um artefato separado durante todo o projeto.

Responsabilidade

O analista de sistemas responsvel pela integridade do documento de Viso, garantindo que:

O documento seja atualizado e distribudo.

As informaes fornecidas por todas as partes interessadas sejam consideradas.

Informaes Adicionais

A viso de um projeto pode ser alterada medida que aumenta a compreenso dos requisitos, da arquitetura, dos planos e da tecnologia. Entretanto, o ritmo dessa mudana deve ser lento e normal durante a fase inicial do ciclo de vida.

importante expressar a viso em termos de seus casos de uso e principais cenrios medida que eles so desenvolvidos, para que voc possa verificar como a viso realizada pelos casos de uso. Os casos de uso so tambm uma base eficaz para a evoluo de um conjunto de casos de teste.

O autor original pode ser qualquer pessoa, mas, quando o projeto estabelecido, o documento de Viso passa a ser responsabilidade do analista de sistemas.

Outro nome usado para esse documento Documento de Requisitos do Produto.

Adaptao

As adaptaes so necessrias para que as necessidades de seu projeto sejam atendidas. Geralmente, uma boa prtica ter um documento de Viso sucinto, que possa ser entregue aos envolvidos o mais rpido possvel e que possa ser revisado e compreendido facilmente por eles. Para fazer isso, inclua apenas as solicitaes e caractersticas mais importantes definidas pelos envolvidos e evite requisitos detalhados. Os detalhes podero ser capturados em outros artefatos de requisitos ou em apndices.

Decida se os atributos dos recursos sero documentados aqui ou no Plano de Gerenciamento de Requisitos. Decida quais informaes (atributos) sero includas no documento de Viso e quais sero gerenciadas com ferramentas de gerenciamento de requisitos, como Rational RequisitePro (consulte Mentor de Ferramentas: Desenvolvimento de uma Viso Usando o Rational RequisitePro).

2. Finalidade

A finalidade da disciplina Requisitos :

Estabelecer e manter concordncia com os clientes e outros envolvidos sobre o que o sistema deve fazer.

Oferecer aos desenvolvedores do sistema uma compreenso melhor dos requisitos do sistema.

Definir as fronteiras do sistema (ou delimitar o sistema).

Fornecer uma base para planejar o contedo tcnico das iteraes.

Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema.

Definir uma interface de usurio para o sistema, tendo como objetivo as necessidades e metas dos usurios.

Para atingir essas metas, importante, antes de tudo, compreender a definio e o escopo do problema que tentamos resolver com este sistema. As Regras de Negcios, o Modelo de Casos de Uso de Negcios e o Modelo de Objetos de Negcios desenvolvidos durante a Modelagem do Negcio serviro como informaes importantes nesse trabalho. Os envolvidos so identificados e as Solicitaes dos Principais Envolvidos so recolhidas, reunidas e analisadas.

Um documento de viso, um modelo de casos de uso, casos de uso e a Especificao Suplementar so desenvolvidos para descrever integralmente o sistema - o que o sistema far - em um trabalho em que todos os envolvidos, incluindo clientes e usurios potenciais, so vistos como fontes de informaes (alm dos requisitos do sistema).

As Solicitaes dos Principais Envolvidos so recolhidas e reunidas a partir de fontes existentes para obter uma "lista de desejos" do que as diversas pessoas envolvidas no projeto (clientes, usurios, defensores do produto) esperam e desejam que o sistema contenha, juntamente com informaes de como cada solicitao foi considerada pelo projeto.

O documento de viso fornece uma viso completa do sistema em desenvolvimento e serve de suporte ao contrato entre o cliente patrocinador e a organizao desenvolvedora. Todo projeto precisa de uma fonte para capturar as expectativas entre os envolvidos. O documento de viso escrito pelo Analista de Sistemas com base na perspectiva dos clientes, focalizando as caractersticas essenciais do sistema e os nveis aceitveis de qualidade. A Viso deve incluir uma descrio de quais caractersticas sero includas, bem como aquelas que foram consideradas, mas no includas. Ela tambm deve especificar as capacidades operacionais (volumes, tempos de resposta, precises), os perfis dos usurios (quem usar o sistema) e as interfaces inter-operacionais com entidades externas ao sistema, quando for o caso. O documento de viso fornece uma base contratual para os requisitos visveis dos envolvidos.

O modelo de casos de uso escrito pelo Analista de Sistemas e deve servir como um meio de comunicao e pode, tambm, servir como contrato entre o cliente, os usurios e os desenvolvedores do sistema sobre as funcionalidades do sistema, e permite que:

Clientes e usurios validem que o sistema ficar como eles esperam.

Os desenvolvedores do sistema construam o que esperado.

O modelo de casos de uso consiste em casos de uso e atores. Cada caso de uso do modelo descrito detalhadamente, mostrando passo a passo como o sistema interage com os atores, e o que o sistema faz no caso de uso. Os casos de uso funcionam como um thread unificador no decorrer do ciclo de vida do software; o mesmo modelo de casos de uso utilizado nas atividades de anlise, design, implementao e teste do sistema.

As Especificaes Suplementares so um complemento importante para o modelo de casos de uso, porque juntos eles capturam todos os requisitos do software (funcionais e no funcionais) que precisam ser descritos para servir como uma especificao de requisitos de software completa. As Especificaes Suplementares capturam os requisitos de sistema que no so capturados imediatamente nos casos de uso do modelo de casos de uso. Entre os requisitos esto includos:

Requisitos legais e de regulamentao e padres de aplicativo.

Atributos de qualidade do sistema a ser criado, incluindo requisitos de usabilidade, confiabilidade, desempenho e suportabilidade.

Outros requisitos, como sistemas operacionais e ambientes, requisitos de compatibilidade e restries de design.

Uma definio completa dos requisitos do software descritos nos casos de uso e nas Especificaes Suplementares pode ser reunida para definir uma Especificao de Requisitos de Software (SRS) para uma "caracterstica" particular ou agrupamentos de subsistemas.

Um Plano de Gerenciamento de Requisitos especifica as informaes e controla os mecanismos que sero coletados e usados para avaliar, relatar e controlar mudanas nos requisitos do produto.

A finalidade do Plano de Gerenciamento de Requisitos descrever como o projeto ir configurar documentos de requisitos, tipos de requisitos e seus respectivos atributos de requisitos e rastreabilidade.

Para complementar os artefatos mencionados acima, tambm foram desenvolvidos os artefatos a seguir:

Glossrio

Encenao de Caso de Uso

Prottipo da Interface do Usurio

O Glossrio importante porque define uma terminologia comum que usada de forma consistente no projeto ou na organizao.

A Encenao de Caso de Uso e o Prottipo da Interface do Usurio resultam da elaborao de modelo e prottipo de interface de usurio, feitos paralelamente a outras atividades dos requisitos. Esses artefatos fornecem importantes mecanismos de feedback nas iteraes posteriores para descobrir requisitos desconhecidos ou no especficos.

3. Atividades, Artefatos e Papis

Atividades

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workflow/requirem/images/wfov_req.gif" \* MERGEFORMATINET

Artefatos

INCLUDEPICTURE "http://www.wthreex.com/rup/process/artifact/images/ars_req.gif" \* MERGEFORMATINET

Os papis e os artefatos desenvolvidos na disciplina Requisitos.

Papis

O analista de sistemas lidera e coordena a identificao de requisitos e a modelagem de casos de uso, delimitando o sistema e definindo suas funcionalidades; por exemplo, estabelecendo quais so os atores e casos de uso existentes e como eles interagem.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workers/images/wk_sysan.gif" \* MERGEFORMATINET

b) Arquiteto de Software

O arquiteto de software lidera e coordena as atividades e os artefatos tcnicos no decorrer do projeto. O arquiteto de software estabelece a estrutura geral de cada viso de arquitetura: a decomposio da viso, o agrupamento dos elementos e as interfaces entre esses principais agrupamentos. Portanto, comparado aos outros papis, a viso do arquiteto de software ampla, e no detalhada.

INCLUDEPICTURE "http://www.wthreex.com/rup/addin_realtime/process/workers/images/wk_archt_rt.gif" \* MERGEFORMATINET

c) Especificador de Requisitos

O especificador de requisitos detalha a especificao de uma parte das funcionalidades do sistema, descrevendo o aspecto Requisitos de um ou de vrios casos de uso e outros requisitos de software de apoio. O especificador de requisitos tambm pode ser responsvel por um pacote de casos de uso e por manter a integridade desse pacote. recomendvel que o especificador de requisitos responsvel por um pacote de casos de uso tambm seja responsvel pelos casos de uso e atores contidos no pacote.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workers/images/wk_ucaut.gif" \* MERGEFORMATINET

d) Designer de Interface de Usurio

O designer de interface de usurio lidera e coordena a construo do prottipo e o design da interface do usurio da seguinte forma:

Capturando os requisitos da interface do usurio, incluindo requisitos de usabilidade

Construindo prottipos de interface do usurio

Incluindo outros envolvidos da interface de usurio, como usurios, nas revises de usabilidade e nas sesses de teste de uso

Revisando e fornecendo o feedback apropriado sobre a implementao final da interface do usurio, se criada por outros desenvolvedores, ou seja, designers e implementadores.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workers/images/wk_uides.gif" \* MERGEFORMATINET

e) Revisor de Requisitos

O revisor de requisitos planeja e conduz a reviso formal do modelo de casos de uso.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workers/images/wk_reqrv.gif" \* MERGEFORMATINET

Anlise e Projeto1. Conceitos

Arquitetura de Software

Diviso em Camadas

Eventos e Sinais

Mecanismos de Anlise

Mecanismos de Design e Implementao

Padres de Arquitetura da Web

Padres de Distribuio

Representao de Interfaces com Sistemas Externos

Representao de Interfaces Grficas do Usurio

Simultaneidade

Teste Anterior ao Design

Viso de Processos

Viso de Implantao

Viso Lgica

Viso de Processos

Uma viso de arquitetura chamada viso de processos utilizada na disciplina Anlise e Design para fornecer uma base que permitir compreender a organizao do processo do sistema. A viso de processos do sistema ilustra a decomposio do processo do sistema, incluindo o mapeamento das classes e dos subsistemas para processos e threads. A viso de processos refinada durante cada iterao. Como declara [BOO98]: "Com a UML, os aspectos estticos e dinmicos desta viso so capturados nos mesmos tipos de diagramas que a viso de design, ou seja, em diagramas de classes, diagramas de interao, diagramas de atividades e diagramas de estados, mas com um enfoque nas classes ativas que representam esses threads e processos." O que interessa na construo e uso da viso de processos , por exemplo, as questes de simultaneidade, o tempo de resposta, o deadlock, a taxa de transferncia de dados, a tolerncia a falhas e a escalabilidade.

possvel projetar a simultaneidade sem utilizar o suporte direto ao sistema operacional bsico usando, por exemplo, um programa especialmente escrito ou outro suporte em tempo de execuo. Nesses casos, a simultaneidade simulada no nvel da infra-estrutura do aplicativo, e no no sistema operacional. Se necessrio, outros esteretipos (alm dos threads e processos padro) podem ser usados para fazer essa distino (a fim de conduzir a implementao). Por exemplo, a linguagem de programao Ada contm seu prprio modelo de simultaneidade, baseado em tarefas Ada. O tempo de execuo da linguagem Ada deve fornecer isso, independentemente de o sistema operacional em que ela executada ter ou no um equivalente apropriado (os threads, por exemplo) que possa ser utilizado para oferecer suporte s tarefas Ada.

Nos sistemas em tempo real, o Rational Unified Process recomenda o uso de Cpsulas para representar as classes ativas na viso de processos. As cpsulas possuem uma semntica forte para simplificar a modelagem da simultaneidade:

Elas usam uma comunicao assncrona baseada em mensagens por meio de Portas que utilizam Protocolos bem definidos; Elas usam uma semntica de execuo-concluso no processamento de mensagens;

Elas encapsulam objetos passivos (assegurando que no pode ocorrer a interferncia do thread).

A viso de processos mostra a organizao do processo do sistema.

Viso de Implantao

Uma viso de arquitetura chamada viso de implantao usada no fluxo de trabalho Anlise e Design para fornecer uma base que permitir compreender a distribuio fsica do sistema em um conjunto de ns de processamento. A viso de implantao ilustra a distribuio do processamento em um conjunto de ns do sistema, incluindo a distribuio fsica dos processos e threads. Ela refinada durante cada iterao.

A viso de implantao mostra a distribuio fsica do processamento no sistema.

Viso Lgica

Uma viso de arquitetura chamada Viso Lgica utilizada no fluxo de trabalho Anlise e Design para fornecer uma base que permitir compreender a estrutura e a organizao do design do sistema. Existe somente uma viso lgica do sistema, que ilustra as principais realizaes de caso de uso, subsistemas, pacotes e classes que abrangem o comportamento significativo em termos de arquitetura. A viso lgica refinada durante cada iterao.

A viso lgica mostra um subconjunto do modelo de design significativo em termos de arquitetura, ou seja, um subconjunto das classes, subsistemas, pacotes e realizaes de caso de uso.

2. Finalidade

As finalidades da disciplina Anlise e Projeto so:

Transformar os requisitos em um projeto do sistema a ser criado.

Desenvolver uma arquitetura sofisticada para o sistema.

Adaptar o projeto para que corresponda ao ambiente de implementao, projetando-o para fins de desempenho.

3. Anlise e Projeto - Atividades, Artefatos e Papis

Atividades

INCLUDEPICTURE "http://www.wthreex.com/rup/addin_realtime/process/workflow/ana_desi/images/ovu_and.gif" \* MERGEFORMATINET

Artefatos

INCLUDEPICTURE "http://www.wthreex.com/rup/addin_realtime/process/artifact/images/ars_dsg_rt.gif" \* MERGEFORMATINET

Os papis envolvidos e os artefatos produzidos na disciplina Anlise e Design.

Papis

a) Arquiteto de Software

O papel do arquiteto de software liderar e coordenar as atividades e os artefatos tcnicos no decorrer do projeto. O arquiteto de software estabelece a estrutura geral de cada viso de arquitetura: a decomposio da viso, o agrupamento dos elementos e as interfaces entre esses principais agrupamentos. Portanto, comparado aos outros papis, a viso do arquiteto de software ampla, e no detalhada.

INCLUDEPICTURE "http://www.wthreex.com/rup/addin_realtime/process/workers/images/wk_archt_rt.gif" \* MERGEFORMATINET

b) Designer

O designer define as responsabilidades, as operaes, os atributos e os relacionamentos de uma ou de vrias classes e determina como eles sero ajustados para o ambiente de implementao. Alm disso, o designer pode ser responsvel por um ou mais design de pacotes ou de subsistemas, incluindo todas as classes pertencentes aos pacotes ou subsistemas.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workers/images/wk_dsgnr.gif" \* MERGEFORMATINET

c) Projetista de Banco de Dados

O projetista de banco de dados define tabelas, ndices, vises, restries, triggers, store procedures, parmetros de armazenamento ou tablespaces e outras construes especficas de um banco de dados necessrias para armazenar, recuperar e excluir objetos persistentes. Essas informaes so mantidas no Artefato: Modelo de Dados.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workers/images/wk_dbdsr.gif" \* MERGEFORMATINET

d) Revisor de Arquitetura

O revisor de arquitetura planeja e conduz as revises formais da arquitetura de software em geral.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workers/images/wk_arvwr.gif" \* MERGEFORMATINET

e) Revisor de Design

O revisor de design planeja e conduz as revises formais do Artefato: Modelo de Design.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workers/images/wk_desrv.gif" \* MERGEFORMATINET

Gerncia de Projeto

1. Conceitos

Plano de Desenvolvimento de Software Plano de Iterao Lista de Riscos

Avaliao da Qualidade

Contexto Organizacional do Rational Unified Process

Iterao

Medio da Qualidade

Mtricas

Prottipos

Risco

Plano de Desenvolvimento de Software

O Plano de Desenvolvimento de Software um artefato composto e abrangente que rene todas as informaes necessrias ao gerenciamento do projeto. Ele inclui vrios artefatos separados, desenvolvidos durante a Fase de Iniciao, e mantido durante todo o projeto.

Finalidade

A finalidade do Plano de Desenvolvimento de Software reunir todas as informaes necessrias ao controle do projeto. Ele descreve a abordagem dada ao desenvolvimento do software e o plano de nvel mais alto gerado e usado pelos gerentes para direcionar o esforo de desenvolvimento.

O Plano de Desenvolvimento de Software usado por:

Pelo gerente de projeto, para planejar a programao do projeto e as necessidades de recursos e para acompanhar o progresso com relao programao.

Pelos membros da equipe de projeto, para poderem saber quais so suas funes, quando elas devem ser executadas e de que outras atividades eles dependem.

Detalhamento do Fluxo de Trabalho

A finalidade deste detalhamento do fluxo de trabalho desenvolver os componentes e o material incluso no Plano de Desenvolvimento de Software, e revis-los formalmente, para obter exeqibilidade e aceitabilidade entre os envolvidos, e servir como base para o plano de pequenos ajustes da prxima iterao (o Plano de Iterao ). O maior esforo na criao desses artefatos ocorre logo na fase de iniciao; depois disso, quando o detalhamento do fluxo de trabalho chamado no incio de cada iterao, ele ocorre para revisar o Plano de Desenvolvimento de Software (e o material incluso) com base na experincia da iterao anterior e no Plano de Iterao para a prxima fase. O Gerente de Projeto tambm coleta todas as outras contribuies para o Plano de Desenvolvimento de Software e as rene na Atividade: Compilar Plano de Desenvolvimento de Software.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workflow/manageme/images/wfg_sdp.gif" \* MERGEFORMATINET

Orientaes de Trabalho

A estimativa deve ser baseada preferencialmente na prpria experincia da organizao, que usada para aferir um modelo de estimativa, como o COCOMO. (Consulte [BOE81] para obter uma descrio do modelo original, ou visite o site http://sunset.usc.edu/research/cocomosuite/index.html para obter o trabalho mais recente.) Se o Gerente de Projeto estiver comeando do zero, usando os valores padro dos coeficientes de modelo, ser importante usar outros mtodos para validar as estimativas. Tambm importante obter a equipe e outro acordo dos envolvidos para que as estimativas sejam realistas e alcanveis. Entretanto, o Gerente de Projeto deve levar em conta a experincia da equipe para fornecer um feedback sobre as estimativas. A equipe jnior pode estar apenas adivinhando nmeros e, portanto, adicionando largas margens de erro; inversamente, as suas estimativas de esforo podem ser ingenuamente inferiores. O Gerente de Projeto deve ser prudente ao lidar com as estimativas da equipe jnior, estar preparado para aconselh-los quando necessrio e oferecer a assistncia de um profissional mais experiente. Consulte Atividade: Planejar Fases e Iteraes para obter mais informaes sobre estimativa.

Todos os planos e sees includos no Plano de Desenvolvimento de Software devem ser avaliados por meio de inspees tcnicas internas e revises, antes que ocorra a Reviso do Planejamento do Projeto.

Plano de Iterao

O Plano de Iterao um conjunto de atividades e tarefas divididas por seqncias de tempo, com recursos atribudos e dependncias de tarefas, para a iterao. O Plano de Iterao da prxima iterao elaborado na iterao atual. Ele modificado quando necessrio durante a iterao. Um Plano de Iterao a entrada para o prximo Plano de Iterao. Ele fica obsoleto aps a iterao. O Gerente de Projeto responsvel pela integridade dos Planos de Iterao. necessrio que o Plano de Iterao detalhe minuciosamente o que ser feito, a fim de reduzir a possibilidade de imprecises sobre a posio ou responsabilidades verdadeiras a qualquer momento. Geralmente, alguma ferramenta de planejamento de projeto (como o Microsoft Project) usada.

Finalidade

A finalidade deste detalhamento do fluxo de trabalho criar um Plano de Iterao, que um plano de pequenos ajustes para orientar a prxima iterao. Depois de criar o plano, os ajustes podem ser necessrios para o Caso de Negcio (por exemplo, se os custos so alterados, ou se o clculo de retorno do investimento afetado pelas mudanas de datas de disponibilidade dos recursos importantes no software). O Plano de Iterao deve ser revisado pelo cliente e outros envolvidos, e, se satisfatrio, deve ser aprovado por meio da Reviso do Plano de Iterao. Essa reviso tambm fornece ao cliente a visibilidade das expectativas do projeto de participao do cliente e de recursos particularmente se a iterao pretende liberar os artefatos ou implantar o software, de maneira que o cliente possa fazer planos apropriados.

INCLUDEPICTURE "http://www.wthreex.com/rup/process/workflow/manageme/images/wfg_plan.gif" \* MERGEFORMATINET

Orientaes de Trabalho

O Gerente de Projeto deve trabalhar junto com o Arquiteto de Software para definir o contedo da iterao. O Plano de Iterao deve ser avaliado internamente, por meio de inspeo tcnica e reviso, antes de ser apresentado para a Reviso do Plano de Iterao, particularmente:

Para avaliar a clareza da expresso dos critrios de avaliao da iterao

Para alcanar o acordo interno de maneira que os artefatos planejados possam ser criados com o esforo e o tempo disponveis

Para garantir que os resultados da iterao sero testveis ou demonstrveis de outra maneira; ou seja, a iterao ter um resultado tangvel

2. Introduo

O Gerenciamento de Projeto de Software a arte de confrontar os objetivos da concorrncia, gerenciar riscos e superar obstculos para liberar com xito um produto que atenda s necessidades dos clientes (que pagaram por ele) e dos usurios. O fato de que to poucos projetos sejam indiscutivelmente bem-sucedidos o comentrio suficiente sobre a dificuldade da tarefa.

3. Finalidade

A meta desta seo facilitar a tarefa fornecendo algum contexto para o Gerenciamento de Projeto. No se trata de uma receita de sucesso, mas apresenta uma abordagem para gerenciar o projeto que melhora notadamente a desigualdade da liberao de software bem-sucedido.

A finalidade do Gerenciamento de Projeto :

Fornecer um framework para gerenciar projetos intensivos de software.

Fornecer diretrizes prticas para planejar, montar a equipe, executar e monitorar os projetos.

Fornecer um framework de gerenciamento de risco.

Entretanto, essa disciplina do Rational Unified Process (RUP) no ten