Fase de Construção, Fase de Transição

 

Fase de Construção

          Nesta fase , começa o desenvolvimento físico do software, produção de códigos, testes alfa. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema, também  é preciso esclarecer os requisitos restantes bem como gerenciar os recursos de controle de operações para otimizar custos, programações e qualidade.

Objetivos

• Minimizar custos de desenvolvimento, otimizar recursos e evitar retrabalho. A palavra chave é eficiência.
• Disponibilizar as versões úteis (alfa, beta e etc) com rapidez. Os testes ALFA são realizados durante a fase de Construção.
• Concluir a análise, o projeto, o desenvolvimento e o teste de todas as funcionalidades.
• Verificar e decidir se o software está pronto para implantação. 
• Atingir a qualidade adequada com rapidez e eficiência.

   

Artefatos

• O Sistema  - O próprio sistema executável, pronto para iniciar os testes beta.

• Plano de Implantação - guia a equipe de implantação e transição para eles disponibilizarem o software. Essa é apenas uma versão inicial do plano, as versões finais são feitas na Transição. Em projetos menores o Plano de Implantação pode estar embutido no Plano de Desenvolvimento de Software.

• Conjunto de Testes - Testes implementados e executados para validação e estabilidade das versões (releases)

• Modelo de Implementação - Expandido a partir daquele criado durante a fase de elaboração; todos os componentes criados no final da fase de construção.

• Materiais de Treinamento - Manuais do Usuário e outros materiais de treinamento. Rascunho preliminar, baseado em casos de uso.  Poderá ser necessário se o sistema tiver um forte aspecto de interface de usuário.

• Plano de Iteração - Plano de iteração para a fase de transição concluído e analisado.

• Modelo de Design - Atualizado com novos elementos de design identificados durante a conclusão de todos os requisitos.

• Caso de Desenvolvimento - Refinado com base na experiência inicial do projeto. O ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte automatizado necessários para dar assistência à equipe de transição já estará posicionada.

• Ferramentas - As ferramentas usadas para dar suporte ao trabalho de Construção são instaladas.

• Modelo de Dados - Atualizado com todos os elementos necessários para suportar a implementação persistente (por exemplo, tabelas, índices, etc.).

Atividades Básicas

• Gerenciamento de recursos, otimização de controle e processo
• Desenvolvimento completo do componente e teste dos critérios de avaliação definidos
• Avaliação dos releases do produto de acordo com os critérios de aceitação para a visão

 

Marco: Capacidade Operacional Inicial 

      O marco Capacidade Operacional Inicial determina se o produto está pronto para ser implantado em um ambiente de teste beta.Quando chegamos aqui podemos nos perguntar se:

• Os modelos de Análise e Design estão estáveis?
• Resolvemos todos os problemas de design?
• Abordamos todos os casos de uso?
• Glossário e SAD estão atualizados?

Fase de Transição

 Nesta fase ocorre a entrega do software ao usuário. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.

Objetivos

• Validar o novo sistema em confronto com as expectativas do usuário treinamento de usuários e equipe de manutenção
• Implantação do sistema
• Correção de erros, melhoria no desempenho e na usabilidade
• Avaliação das baselines de implantação tendo como base a visão completa e os critérios de aceitação para o produto
• Obtenção de auto-suportabilidade do usuário
• Obtenção do consentimento dos envolvidos de que as baselines de implantação estão completas
• Obtenção do consentimento dos envolvidos de que as baselines de implantação são consistentes com os critérios de avaliação da visão

 Artefatos
   

Artefatos Básicos (em ordem de importância)	Estado no marco
O Build do Produto	Concluído de acordo com os requisitos do produto. O produto final deve ser utilizável pelo consumidor.
Notas de Release	Concluídas.
Artefatos de Instalação	Concluídos.
Material de Treinamento	Concluído para assegurar que o cliente possa ser auto-suficiente na utilização e manutenção do produto.
Material de Suporte para o Usuário Final	Concluído para assegurar que o cliente possa ser auto-suficiente na utilização e manutenção do produto.

fonte:http://www.wthreex.com/rup/

Atividades básicas

• Executar planos de implantação
• Finalizar o material de suporte para o usuário final
• Testar o produto liberado no local do desenvolvimento
• Criar um release do produto
• Obter feedback do usuário
• Ajustar o produto com base em feedback
• Disponibilizar o produto para os usuários finais

Marco: Release do Produto

No fim na fase de transição está o quarto marco mais importante do projeto, o Marco do Release do Produto. Nesse momento, você decide se os objetivos foram atendidos, e se outro ciclo de desenvolvimento deve ser iniciado. Em alguns casos, esse marco pode coincidir com o fim da fase de iniciação do próximo ciclo. O Marco do Release do Produto é o resultado da conclusão com êxito de Atividade: Revisão da Aceitação do Projeto. Os critérios básicos de avaliação para a fase de transição envolvem as respostas para estas questões:

• O usuário está satisfeito?
• As despesas reais com recursos são aceitáveis se comparadas com as planejadas?

No Marco do Release do Produto, o produto está em produção e o ciclo de manutenção posterior ao release inicia. Isso pode envolver o início de um novo ciclo ou de algum release de manutenção adicional.

Fontes:

• http://infoblogs.com.br/view.action?contentId=40213&RUP-A-Importancia-dos-Marcos.html
  
• http://www.wthreex.com/rup/portugues/index.htm
• http://brunomarota.blogspot.com.br/2012/06/rup-para-concursos-parte-6-fase-de.html
• http://www.infoescola.com/engenharia-de-software/rup/
• http://tec4rup.wordpress.com/2010/05/13/rup-fases/

As fases do RUP - parte 1 (concepção e elaboração)

As fases do RUP

O ciclo de vida de software do RUP é dividido em quatro fases sequenciais  cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase é executada uma avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase.

Uma passagem pelas quatro fases é um ciclo de desenvolvimento. Cada passagem pelas quatro fases produz uma geração do software. A menos que o produto "desapareça", ele irá se desenvolver na próxima geração, repetindo a mesma seqüência de fases de iniciação, elaboração, construção e transição, mas agora com ênfase diferente nas diversas fases. Esses ciclos subsequentes são chamados de ciclos de evolução. À medida que o produto atravessa vários ciclos, são produzidas novas gerações.

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por diante.

Vamos agora falar sobre as duas fases iniciais do RUP: As fases de Concepção e de Elaboração.

Fase de Concepção

Objetivos

A meta dominante da fase de iniciação é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto. A fase de iniciação tem muita importância principalmente para os esforços dos desenvolvimentos novos, nos quais há muitos riscos de negócios e de requisitos que precisam ser tratados para que o projeto possa prosseguir.

Os objetivos principais da fase de iniciação incluem:

• Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto;
•  Discriminar os casos de uso críticos do sistema, os principais cenários de operação e o que direcionará as principais trocas de design;
•  Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos;
• Estimar o custo geral e a programação para o projeto inteiro;
• Estimar riscos em potencial (as origens de imprevistos);
• Preparar o ambiente de suporte para o projeto.

Atividades básicas

• Formular o escopo do projeto;
• Planejar e preparar um caso de negócio;
• Sintetizar uma possível arquitetura;
• Preparar o ambiente para o projeto.

Marco: Objetivos do Ciclo de Vida

O Marco de Objetivos do Ciclo de Vida avalia a viabilidade básica do projeto.

Fase de Elaboração

Objetivos

A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.

Os objetivos primários da fase de elaboração incluem:

• Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo e a programação para a conclusão do desenvolvimento;
• Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto;
•  Estabelecer uma arquitetura da baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto;
•   Produzir um protótipo evolutivo dos componentes de qualidade de produção, assim como um ou mais protótipos descartados para diminuir riscos específicos como:
•    Trocas de design/requisito;
•    Reutilização de componentes;
• Possibilidade de produção do produto ou demonstrações para investidores, clientes e usuários finais.
•  Demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um custo justo e em tempo justo;
•  Estabelecer um ambiente de suporte;
•  Configurar o ambiente de suporte para o projeto. Isso inclui criar um caso de desenvolvimento, criar templates e diretrizes, e configurar ferramentas.

Atividades básicas      

•  Definir, validar e criar a baseline da arquitetura com rapidez e eficiência;
•  Refinar a Visão, com base nas informações novas obtidas durante a fase;
•  Criar planos de iteração detalhados e baselines para a fase de construção;
•  Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento;
• Refinar a arquitetura e selecionar componentes.

Marco: Arquitetura do Ciclo de Vida

O marco Arquitetura do Ciclo de Vida estabelece uma baseline gerenciada para a arquitetura do sistema e permite o escalonamento da equipe do projeto na fase de Construção.

RUP - Linhas Mestras - Uso de Software de Modelos Visuais, Verificação da qualidade do software, Gestão e Controle de Mudanças do Software

 Uso de Software de Modelos Visuais

Ao abstrair a programação do seu código e representá-la utilizando blocos de construção gráfica, o RUP consegue uma maneira efetiva de se ter uma visão geral de uma solução. O uso de modelos visuais também pode permitir que indíviduos de perfil menos técnico (como clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais no projeto como um todo.

A línguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada pelo RUP.


Uso de Software de Modelos Visuais

Ao abstrair a programação do seu código e representá-la utilizando blocos de construção gráfica, o RUP consegue uma maneira efetiva de se ter uma visão geral de uma solução. O uso de modelos visuais também pode permitir que indíviduos de perfil menos técnico (como clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais no projeto como um todo.

A línguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada pelo RUP.

Verificação da Qualidade do Software

Não assegurar a qualidade do software é a falha mais comum em todos os projetos de sistemas computacionais. Normalmente pensa-se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade de uma equipe diferente da equipe de desenvolvimento. O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção de todo o processo e envolvendo todos os membros da equipe de desenvolvimento.


Gestão e Controle de Mudanças do Software

Em todos os projectos de software a mudança é inevitável. O RUP define métodos para controlar e monitorizar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisiveis, o controle de mudanças é essencial para o sucesso de um projeto.

O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.


Fonte:
http://www.guiafar.com.br/portal/index.php/pt/artigos/tecnologia-da-informacao/108-rup

RUP - Linhas Mestras - Gestão de Requisitos e Arquitetura de Componentes

Gestão de Requisitos 

Tem como característica sua eficácia em manter as sentenças dos claras dos requisitos, junto com os atributos aplicáveis. 

A coleta dos requisitos precisá ser uma tarefa que consiga coletar os dados principais sem falhas e ambiguidades. Seus principais  problemas acontecem na coleta de  tais dados pois:

- Nem todavia a fonte é confiável dos dados que foram estabelecidos.

- O linguajar pode dificultar a compreensão do requisito.

- O numero de requisitos pode ser impossível controlar.

-Há várias partes interessadas, nos requisitos que precisam ser gerenciados pelos grupos de pessoas de diferentes funções

De forma que as habilidades que devem ser notadas e averiguadas para identificar uma forma de gerenciar as dificuldades que serão encontradas. Abaixo segue importantes habilidades

Analise do problema

Uma das partes mais interessante do sistema pois uma opinião incorreta pode vir a calhar em graves problemas para o desenvolvimento do sistema. É o momento em que sentamos com o cliente e fazemos uma analise dos que engloba o  problema. Durante a analise, são estabelecidos os problemas reais, as fronteiras do sistema. O que pode ser realizado baseando-se no contexto do grupo, habilidades e o problema. Após toda a analise e um caso de negócio feito, é preciso que exista o entendimento do retorno esperado sobre o investimento feito.

Noções Básicas dos envolvidos.

Para que existe uma compreensão melhor e um bom diálogo com cliente é preciso reconhecer o tipo de cliente que estamos lhe dando. Pois a forma correta para o dialogo e a metodologia que será utilizada deve ser baseada no contexto do cliente. Se por exemplo é uma pessoa da área de Informática, não teremos problemas na identificação dos requisitos e o nível do modelo de negócio. Mas se for um cliente que não tem muito conhecimento sobre a área, protótipos conceituais, entrevista, questionário. Ferramentas que possam ajudar nessa necessidade da retirada dos requisitos

Definição do sistema e escopo do projeto

Pegar os dados recolhidos e converter numa documentação, grau de cada requisito, detalhamento, esforço estimado, nível de risco. Pode incluir também protótipos iniciais geralmente relacionados aos requisitos importantes.O escopo do projeto deve ser priorizado somente os requisitos necessários com o prazo adequado sem a necessidade que tenha de incluir os 'Ovos de pascoa' . Gerenciando com o grupo cada tarefa que foi solicitada.

Arquitetura dos componentes

Os componentes são grupos com interfaces bem definidas e comportamentos que fornecem forte encapsulamento do conteúdo e são, portanto, substituíveis.

Características

Arquitetura

O RUP fornece uma maneira metódica e sistemática de projetar, desenvolver e validar uma arquitetura. Oferecemos templates para descrição da arquitetura, com os conceitos de várias visões arquiteturais, e para a captura de estilo de arquitetura, regras de design e restrições. A disciplina Análise e Design contém atividades específicas orientadas para identificar restrições arquiteturais e para elementos significativos na arquitetura, além de diretrizes sobre como fazer escolhas arquiteturais. O processo de gerenciamento mostra como o planejamento das iterações iniciais considera o design de uma arquitetura e a resolução dos principais riscos técnicos. Consulte a disciplina Gerenciamento de Projeto e todas as atividades associadas ao Papel: Arquiteto de Software para obter mais informações.

A arquitetura é importante por vários motivos:

Ela permite obter e manter controle intelectual do projeto, gerenciar sua complexidade e manter a integridade do sistema.

Um sistema complexo é mais que a soma de suas partes; mais que uma sucessão de pequenas decisões táticas independentes. Ele precisa ter uma estrutura unificadora e coerente para organizar essas partes de modo sistemático e fornecer regras precisas sobre como pode ser aumentado, sem que sua complexidade cresça além da compreensão humana.

A arquitetura determina os meios para se obter melhor comunicação e entendimento em todo o projeto, estabelecendo um conjunto de referências e um vocabulário comuns, com os quais se discutem questões de design.

Componentes

É software pode ser definido como um pedaço não-trivial de software, um módulo, um pacote ou um subsistema, sendo que todos desempenham uma função clara, possuem uma fronteira clara e podem ser integrados em uma arquitetura bem definida. É a realização física de uma abstração do design.

Os componentes vêm de diferentes lugares:

Ao definir uma arquitetura muito modular, você identifica, isola, projeta, desenvolve e testa componentes bem formados. Esses componentes podem ser testados individualmente e gradualmente integrados para formar o sistema inteiro.

Introdução ao RUP

O RUP, abreviação de Rational Unified Process (ou Processo Unificado Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento.

O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.

É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala. Para a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software.

O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de seus "Rational Suites".

Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) como a Programação Extrema (XP-Extreme Programming), Scrum, FDD e outros.

Fonte:
http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Modelagem_visual_de_software

As três últimas áreas do conhecimento do PMBOK

As últimas três áreas do conhecimento do PMBOK que trataremos são: Comunicações, riscos e aquisições.

Gerenciamento das Comunicações

  Área que Identifica os processos relativos à geração, coleta, disseminação, armazenamento e destinação final das informações do projeto de forma oportuna e apropriada. Este área inclui:

· Identificar as partes interessadas;

· Planejar as comunicações - determinação das necessidades de informação e comunicação dos stakeholders: que necessidades, qual informação, quando será necessária e como lhes será dada;

· Distribuir informações - disponibilização das informações necessárias dos stakeholders do projeto na forma adequada;

· Gerenciar as expectativas das partes interessadas - geração, reunião e disseminação da informação para formalizar as expectativas dos interessados;

· Relatar desempenho - coleção e disseminação de informação de desempenho. Isto inclui relatório de situação, medição de progresso e previsões;

Gerenciamento dos Riscos

Área que possui os processos envolvidos na identificação, análise e controle dos riscos do projeto. Esta área inclui:

· Planejar o gerenciamento de riscos - determinação dos riscos que provavelmente afetarão o projeto e documentação das características de cada um;

· Identificar riscos - determinação dos riscos que provavelmente afetarão o projeto e documentação das características de cada um;

· Realizar análise qualitativa de riscos - avaliação dos riscos e das interações entre eles para estimar o rol de possibilidades de resultados do projeto;

· Realizar análise quantitativa de riscos - definição das etapas para maximizar oportunidades e eliminar ameaças;

· Planejar respostas aos riscos - resposta às alterações de riscos internos durante o desenvolvimento do projeto;

· Monitorar e controlar riscos.

Gerenciamento das Aquisições

Área do conhecimento que descreve os processos envolvidos na compra ou aquisição de produtos, serviços ou resultados para o projeto. Esta área inclui:

· Planejar aquisições - determinação do que e quando adquirir;

· Conduzir aquisições - documentação dos requisitos de produto e identificação das potenciais fontes;

· Administrar aquisições - obtenção da cotação, contrato, ofertas ou propostas, quando apropriados;

· Encerrar aquisições - encerramento e liquidação do contrato, inclui a resolução de todos os itens abertos (pendentes).

Até a próxima!!!

PMBOK - Áreas do Conhecimento - Gerência de Tempo

O objetivo da gerência do tempo de projeto é descrever os processos requeridos para o término do projeto, garantindo que o mesmo cumpra com os prazos definidos em um cronograma de atividades.

Os principais processos desta gestão são: as Definições, Seqüenciamento, Estimativa de Recurso e Estimativa de Duração das Atividades e o Desenvolvimento e Controle do Cronograma destas Atividades.

Definições das Atividades: identificação das atividades específicas do cronograma que necessitam ser executadas para produzir os diversos tangíveis do projeto;

Seqüenciar Atividades: identificação e documentação das dependências entre as atividades do cronograma;

Estimativa de Recursos de Atividade: estimativa do tipo e das quantidades dos recursos requeridos para executar cada atividade do cronograma;

Estimativa de Duração de Atividade: estimativa do período que será necessário para conclusão individual de cada atividade do cronograma;

Desenvolvimento do Cronograma: análise das sequências das atividades, suas dependências, durações e recursos requeridos para criar o cronograma;

Controle do Cronograma: controle das alterações efetuadas no cronograma;

A gerência do tempo de projeto e a gerência do custo do projeto são as áreas de maior exigência dentro de um projeto, pois são as mais vísiveis em sua gestão.

Algumas das ferramentas clássicas de Gestão de Tempo de Projeto são o PERT/CPM e o Diagrama de Gantt.

Figura 1 - Project Time management overview

Fonte:
PMBOK - A Guide to the Project Management Body of Knowledge -  Fourth Edition