Verificar qualidade de software, Controle de alterações no software

Verificar qualidade de software

Garantia da qualidade de software é o ponto mais comum de falha nos projetos de software, desde que isto é freqüentemente algo que não se pensa previamente e é algumas vezes tratado por equipes diferentes. O RUP ajuda no planejamento do controle da qualidade e cuida da sua construção em todo processo, envolvendo todos os membros da equipe. 

Nenhuma tarefa é especificamente direcionada para a qualidade; o RUP assume que cada membro da equipe é responsável pela qualidade durante todo o processo. O processo foca na descoberta do nível de qualidade esperado e provê testes nos processos para medir este nível.

Gerenciamento de Qualidade no RUP O gerenciamento de qualidade é feito para estas finalidades: Identificar indicadores adequados (métricas) com qualidade aceitável Identificar medidas adequadas a serem usadas na avaliação da qualidade Identificar e abordar adequadamente questões que afetam a qualidade o mais cedo e eficaz possível O gerenciamento da qualidade é implementado em todas as disciplinas, fluxos de trabalho, fases e iterações do RUP. Em geral, o gerenciamento da qualidade durante o ciclo de vida significa que você implementa, mede e avalia tanto a qualidade do processo como a do produto. Alguns dos esforços gastos para gerenciar a qualidade em cada disciplina estão realçados na lista a seguir: O gerenciamento de qualidade na disciplina Requisitos inclui a análise do conjunto de artefatos de requisitos em busca de consistência (entre padrões de artefatos e outros artefatos), de clareza (comunica as informações claramente a todos os acionistas, envolvidos e outros papéis) e de precisão (o nível adequado de detalhe e precisão). Na disciplina Análise e Design , o gerenciamento da qualidade inclui a avaliação do conjunto de artefatos de design, incluindo a consistência do modelo de design, sua conversão a partir de artefatos de requisitos e sua conversão em artefatos de implementação. Na disciplina Implementação, o gerenciamento da qualidade inclui a avaliação dos artefatos de implementação e a avaliação do código-fonte ou dos artefatos executáveis, com relação aos artefatos de requisitos, de design e de teste adequados. A disciplina Teste é altamente centralizada no gerenciamento da qualidade, uma vez que a maioria dos esforços gastos nessa disciplina aborda as três finalidades de gerenciamento de qualidade identificadas anteriormente. A disciplina Ambiente , como a disciplina Teste, inclui muitos esforços de abordagem das finalidades de gerenciamento da qualidade. Aqui é possível encontrar orientações sobre como configurar melhor o processo para atender às suas necessidades. O gerenciamento da qualidade na disciplina Implantação inclui a avaliação dos artefatos de implementação e de implantação e a avaliação dos artefatos executáveis e de implantação, com relação aos artefatos adequados de requisito, de design e de teste necessários para fornecer o produto ao cliente. A disciplina Gerenciamento de Projeto inclui uma visão geral de vários esforços de gerenciamento da qualidade, incluindo as revisões e as auditorias necessárias para avaliar a implementação, a aderência e o andamento do processo de desenvolvimento.      Gestão e Controle de Mudanças do Software Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, 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. Coordenação de Atividades e de Artefatos  A coordenação das atividades e dos artefatos de desenvolvedores e de equipes envolve o estabelecimento de procedimentos que podem ser repetidos para o gerenciamento de mudanças no software e em outros artefatos de desenvolvimento. Essa coordenação permite uma melhor alocação de recursos, com base nas prioridades e nos riscos do projeto e ela gerencia ativamente o trabalho dessas mudanças entre iterações. Juntamente com o desenvolvimento do software iterativamente, essa prática permite que você monitore as mudanças continuamente, para poder descobrir ativamente e solucionar problemas.  Consulte o Detalhamento do Fluxo de Trabalho: Gerenciar Solicitações de Mudança para obter mais informações sobre este tópico. Coordenação de Iterações e de Releases  A coordenação de iterações e de releases envolve o estabelecimento e a liberação de uma baseline testada na conclusão de cada iteração. A manutenção da rastreabilidade entre os elementos de cada release e entre os elementos de vários releases paralelos é essencial para avaliar e gerenciar ativamente o impacto da mudança.  Consulte o Detalhamento do Fluxo de Trabalho Gerenciar Baselines e Releases para obter mais detalhes. Controle de Mudanças no Software  O controle de mudanças no software oferece várias soluções para as causas originais de problemas de desenvolvimento de software: O fluxo de trabalho da mudança de requisitos é definido e pode ser repetido. As solicitações de mudança facilitam a comunicação clara. Os espaços de trabalho isolados reduzem a interferência entre membros da equipe que trabalham em paralelo. As estatísticas de taxa de mudanças fornecem métricas satisfatórias para avaliar objetivamente o status do projeto. Os espaços de trabalho contêm todos os artefatos, o que facilita a consistência. A propagação da mudança pode ser avaliada e controlada. As mudanças podem ser mantidas em um sistema robusto e personalizável.   Fontes : http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process http://www.wthreex.com/rup/manuals/intro/im_bp.htm

Projeto de Software PIC Eletrônico

Projeto de Software - PIC Eletrônico

Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2 from Urique Hoffmann


Diagrama de Gantt

Gantt from Urique Hoffmann


Link para Download do Arquivo do diagrama de Gantt feito no Open Projetct..



Os Documentos acima dizem respeito ao Projeto de Software construido na materia de Gerencia de Projetos pelos alunos Urique Hoffmann , Janiel Medeiros, Alison Lemos e Kirmayr Costa

Apresentação PMBOK & RUP

PMBOK & RUP - UFAM 2012/2 - Gerência de Projetos from Urique Hoffmann

Apresentação feita pelos Alunos responsáveis pela criação e manutenção do Blog, feita no contexto da disciplina de Gerencia de Projetos na Universidade Federal do Amazonas

Benefícios e Desafios para Implentação do PMBOK

Após ser apresentado muito sobre o PMBOK e algumas coisas a mais serão apresentadas mostramos aqui um pouco sobre os benefícios e os desafios de adotar o PMBOK

Abaixo Segue quais são os grandes benefícios e os grandes desafios na implementação desse guia:

Benefícios:

Organizações que implementarem a metodologia PMBOK pode esperar os seguintes benefícios:

• Maior produtividade por estar utilizando uma metodologia padrão;

• Aumento da rentabilidade do projeto;

• Redução de recursos aplicados a projetos sem valor agregado;

• Padronização das práticas em todos os departamentos;

• Sistema padronizado entre as empresas e segmentos industriais;

• Sua metodologia orientada a processos define o conhecimento necessário para gerenciar o ciclo de vida de qualquer projeto, programa e portfólio;

•  O guia do PMBOK é um padrão de framework;

• Processo é orientado;

•     Indica o conhecimento necessitado para controlar o ciclo de vida de todo o projeto, programa e Portfolio com seus processos;

•     Define para cada processo a entrada, as ferramentas, as técnicas e a saída necessárias (deliverables);

•     Define um corpo do conhecimento em que toda a indústria pode o construir mais melhores práticas específicas para sua área de aplicação;

Desafios:

Os seguintes desafios podem afetar a empresa nos seus esforços de implantação:

•     Volume de projetos com recursos limitados na empresa;

•     Dificuldade para determinar impactos específicos em comparação com outras iniciativas;

•     Envolver toda a organização na execução do programa;

•     Obter patrocínio e compromisso da alta direção;

•     Manter o processo de desenvolvimento curto;

•     Considerar apenas os benefícios financeiros e não levar em conta os benefícios não-financeiros como o retorno sobre o investimento; 

• Complexo para projetos pequenos;

•    Têm que ser adaptados à indústria da área de aplicação, o tamanho e o espaço do projeto, o tempo e o orçamento e os confinamentes da qualidade.

Referências para a Elaboração do Post:

http://www.softexpert.com.br/norma-pmbok.php

http://www.12manage.com/methods_pmi_pmbok_pt.html
 

Ferramenta - RUP

Apresento uma alternativa de ferramenta que é compatível com o RUP e que não é do suíte de ferramentas na Rational.

Enterprise Architect

Enterprise Architect é uma plataforma de desenvolvimento colaborativa para modelagem, design e gerenciamento baseada em UML 2.1 e padrões similares. Uma solução para visualização, análise, modelagem, teste e manutenção de uma grande variedade de sistemas, softwares, processos e arquiteturas.

Esta ferramenta contempla:

-   Suporte ao ciclo de vida de modelagem de processos, dados e sistemas;     

-    Contempla notações e técnicas como: BPMN, UML, modelagem de dados, SOAML, SysML, ARCGis e outras; 

-    Permite a utilização de técnicas de levantamento e documentação de requisitos; 

- Abordagem em análise e projeto de sistemas conforme a UML; 

-  Automatização na engenharia de código (geração, reversa e sincronização), contemplando múltiplas linguagens de programação; 

-  Integração nativa com Visual Studio.NET e Eclipse; 

- Geração de Documentação de apoio e Relatórios personalizados (em HTML e RTF);

- Rastreabilidade entre todos os elementos de modelagem (processos, regras, requisitos, casos de uso, classes, componentes, tabelas, etc);  

- Integração com ferramentas de gerenciamento de configuração e versionamento (como   CVS, Subversion, SourceSafe, entre outras);  

- Workgroup, possibilitando uso compartilhado e seguro pelos usuários;  

- Exportação/troca de informações com outras ferramentas via XML; 

- Permite criar protótipos de telas para validação e rastreabilidade de documentação;

Versões e custos:

Corporate  -    $239

Professional - $199

Desktop  -       $135

E também possui a versao Trial (durante 30 dias).

Mais informações: http://www.sparxsystems.com/products/ea/index.html

Estudo de Caso PMBOK - Nacional (Projeto World Cargo)

Apresentamos o estudo de caso do projeto da World Cargo que apostou no PMBOK para gerenciar seus projetos.

O estudo de caso foi obtido da internet e não é de nossa autoria , entretanto no documento é apresentado o autor do estudo. Nele podemos ver que o PMBOK por si só não abrange a todas as atividades do projeto.

Boa leitura! 

Estudo de Caso - PMBOK na empresa World Cargo

Renan st matsushita-2010 from Janiel Medeiros

Melhores Práticas: Modelagem visual do software

A Modelagem visual do software  é a utilização de elementos gráficos e diagramas na modelagem de software, isto é, a representação dos elementos estruturais e comportamentais do sistema através de modelos visuais.

 Porque Modelar ? 

Um modelo é uma visão simplificada do sistema, nesse contexto mostra-se a essência do sistema sobre uma perspectiva particular e esconde detalhes não essenciais que podem confundir na hora de encontrar um caminho para o seu desenvolvimento. Serve para aumentar o entendimento de sistemas complexos, explorar e comparar diferentes projetos, formar uma base para implementação do sistema, capturar os requisitos precisamente e comunicar as decisões de forma não-ambígua.

A modelagem visual de software:

-ajuda a entender sistemas complexos;

-facilita a linguagem e a comunicação entre o mundo real e o que vai ser desenvolvido;

-Explora  e compara alternativas;

-Forma uma base para a implementação;

-Facilita a captura dos requisitos;

-Comunica as decisões sem ambiguidades;

Dessa forma utilizando esta representação, os recursos técnicos podem determinar a melhor forma para implementar um dado conjunto de interdependências lógicas. Isto também constrói uma camada intermediária entre o processo de negócio e o código necessário através da tecnologia da informação. 

A Linguagem modelagem unificada (UML) é um exemplo dessa melhor prática que pode ser usada para modelagem de casos de uso, diagrama de classes e outros objetos.

Linguagem UML

Até a próxima!!

VANTAGENS E DESVANTAGENS DO RUP

Vantagens:

    * Processo robusto e bem definido com a geração de artefatos importantes: O RUP tem como base os princípios de engenharia de software reflectidos na sua abordagem de desenvolvimento iterativa, incremental, orientada a requisitos e baseada em arquitectura

    * Os maiores riscos são atacados primeiro, diminuindo as chances de fracasso do projeto

   * O RUP captura muitas das melhores práticas do desenvolvimento de software moderno, de forma que possam ser adaptadas para uma grande variedade de projetos e de organizações:

• Desenvolver iterativamente;
• Gerenciar Requisitos;
• Usa arquitetura baseada em componentes;
• Modelagem Visual;
• Qualidade de software; 
• Produtividade no desenvolvimento, operação e manutenção de software; 
• Controle sobre desenvolvimento dentro de custos, prazos e níveis de qualidade desejados; 
• Estimativa de prazos e custos com maior precisão. 

Desvantagens:

    * Complexo e trabalhoso para projetos de pequeno porte: Sério investimento em ferramenta de suporte

    * Limitações:  Nas áreas de manutenção, gestão de métricas, gestão de pessoal, gestão de reutilização e testes. Exige experiência da equipe.

    Obs: Apesar dos benefícios, deve-se ter a consciência que os benefícios não virão de maneira imediata. É necessário adquirir treinamento adequado, adaptação da metodologia no contexto ao qual ela será utilizada, apoio especializado para as equipes de desenvolvimento e tempo para a absorção da metodologia.

   

Estudo de Caso PMBOK - Regional (Manaus - AM)

Aqui Apresentamos um Estudo de Caso na Utilização do Pmbok na Cidade de Manaus

O material foi colhido na internet e não é de autoria dos autores do Blog no entanto no documento apresentado é citado os autores do Estudo. 

Estudo de Caso - PMBOK na cidade de Manaus

28814776 from Urique Hoffmann

RUP - Princípios e Melhores Práticas - Uso de Arquitetura Baseada em Componentes

Um Breve Resumo e Contextualização:

A arquitetura baseada em componentes cria um sistema que pode ser facilmente extensível, promovendo a reutilização de software e um entendimento intuitivo. Um componente normalmente se relaciona com um objeto na programação orientada a objetos.
O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala.
Estes componentes são normalmente incluidos em infraestruturas existentes como o CORBA e o COM (Modelo de Componentes de Objectos).

O que significa Arquitetura de Componentes?

Os componentes são grupos de código coesos, na forma de código fonte ou executável, com interfaces bem definidas e comportamentos que fornecem forte encapsulamento do conteúdo e são, portanto, substituíveis. As arquiteturas baseadas em componentes tendem a reduzir o tamanho efetivo e a complexidade da solução e, portanto, são mais robustas e flexíveis.

Ênfase Arquitetural

Os casos de uso orientam o Rational Unified Process (RUP) durante todo o ciclo de vida, mas as atividades de design são centralizadas na noção da arquitetura do sistema e em sistemas intensivos de software, arquitetura de software. O foco principal das iterações iniciais do processo, principalmente na fase de elaboração, é produzir e validar uma arquitetura de software, que no ciclo de desenvolvimento inicial toma a forma de um protótipo arquitetural executável que gradualmente evolui até se tornar o sistema final em iterações posteriores.

Arquitetura executável significa uma implementação parcial do sistema criada para demonstrar funções e propriedades selecionadas do sistema, em particular aquelas que satisfazem requisitos não funcionais. A finalidade da arquitetura executável é diminuir os riscos relacionados a desempenho, taxa de transferência, capacidade, confiabilidade, etc. para que a capacidade funcional completa do sistema possa ser adicionada na fase de construção de uma forma segura, sem perigo de quebra.

Para obter uma introdução da noção de arquitetura, mais especificamente arquitetura de software, e para uma explicação de por que essa noção é crucial, consulte Conceitos: Arquitetura de Software.

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.

    É uma base efetiva para reutilização em larga escala.

    Ao articular claramente os principais componentes e as interfaces críticas entre eles, uma arquitetura permite que você raciocine sobre a reutilização, tanto a reutilização interna que é a identificação das partes comuns, como a reutilização externa que é a incorporação de componentes desenvolvidos internamente e adquiridos prontos para serem usados. No entanto, também permite a reutilização em uma escala maior: a reutilização da própria arquitetura, no contexto de uma linha de produtos que aborda funcionalidades diferentes em um domínio comum.

    Ela fornece uma base para gerenciamento de projeto.

    Planejamento e formação de equipe estão organizados de acordo com os principais componentes. Decisões estruturais fundamentais são tomadas por uma equipe pequena e coesa de arquitetura. Elas não são distribuídas. O desenvolvimento é dividido entre um conjunto de equipes pequenas, cada uma sendo responsável por uma ou várias partes do sistema.


Desenvolvimento Baseado em Componentes


Um componente de 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.
    Além disso, alguns desses componentes podem ser desenvolvidos para serem reutilizáveis, especialmente os componentes que fornecem soluções comuns para uma ampla variedade de problemas comuns. Esses componentes reutilizáveis, que podem ser maiores que apenas conjuntos de utilitários ou de bibliotecas de classes, formam a base de reutilização dentro de uma organização, aumentando a produtividade e a qualidade geral do software.
    Mais recentemente, o advento das infra-estruturas de componentes comercialmente bem-sucedidas, como CORBA, a Internet, ActiveX e JavaBeans, desencadeou uma indústria completa de componentes desenvolvidos internamente e adquiridos prontos para serem usados para vários domínios, permitindo comprar e integrar componentes, em vez de desenvolvê-los internamente.

O primeiro ponto na lista precedente explora os conceitos antigos de modularidade e de encapsulamento, tornando ainda mais importantes os conceitos subjacentes à tecnologia orientada a objetos. Os últimos dois pontos da lista alteram o desenvolvimento de software da programação: de uma linha por vez para a composição do software através da montagem de componentes.

O RUP suporta desenvolvimento baseado em componentes destas maneiras:

    A abordagem iterativa permite identificar componentes progressivamente e decidir quais desenvolver, quais reutilizar e quais comprar.
    O foco na arquitetura de software permite montar a estrutura, os componentes e como eles se integram, incluindo os padrões e os mecanismos fundamentais através dos quais eles interagem.
    Conceitos como pacotes, subsistemas e camadas são utilizados durante a disciplina Análise e Design para organizar componentes e especificar interfaces.
    Os testes são primeiramente organizados em componentes e, em seguida, em conjuntos maiores de componentes integrados.

Referências para a Elaboração do Post:

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

http://www.wthreex.com/rup/manuals/intro/im_bp3.htm

http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Uso_de_arquitetura_baseada_em_componentes_2

 

Melhores Práticas: Desenvolvimento Iterativo

O que é o Desenvolvimento Iterativo? 

Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que consiste em várias iterações. Uma iteração incorpora um conjunto quase sequencial de atividades em modelagem de negócios, requisitos, análise e design, implementação, teste e implantação, em várias proporções, dependendo do local em que ela está localizada no ciclo de desenvolvimento. 

As iterações nas fases de iniciação e de elaboração se concentram nas atividades de gerenciamento, requisitos e design. As iterações na fase de construção se concentram no design, na implementação e no teste. E as iterações na fase de transição e concentram no teste e na implantação. A programação de uma iteração deve ser considerada fixa e o escopo do conteúdo da iteração gerenciado ativamente para atender a essa programação.

Por que Desenvolver Iterativamente? 

Todos os projetos têm um conjunto de riscos envolvidos. Quanto mais cedo você puder verificar que evitou um risco no ciclo de vida, mais precisos serão seus planos. Muitos riscos nem são descobertos até que você tente integrar o sistema. É impossível prever todos eles, por mais experiente que seja a equipe de desenvolvimento.

Em um ciclo de vida iterativo, a seleção do incremento a ser desenvolvido em uma iteração é feita com base em uma lista dos principais riscos. Como a iteração produz um executável testado, você poderá verificar os riscos diminuiram.

Vantagens de uma Abordagem Iterativa 

Geralmente, uma abordagem iterativa é superior a uma abordagem linear ou em cascata, por vários motivos.

• Os riscos são reduzidos mais cedo, pois os elementos são integrados progressivamente.
• As táticas e os requisitos variáveis são acomodados. 
• A melhoria e o refinamento do produto são facilitados, resultando em um produto mais robusto.
• As organizações podem aprender a partir dessa abordagem e melhorar seus processos. 
• A capacidade de reutilização aumenta.

Uma vez, um cliente disse: "Com a abordagem em cascata, tudo parece bem até quase no final do projeto; às vezes, até a metade da integração. Aí, tudo desmorona. Com a abordagem iterativa, é muito difícil esconder a verdade durante muito tempo."

Geralmente, os gerentes de projeto resistem à abordagem iterativa, pois consideram-na um infindável refinamento. No Rational Unified Process (RUP), a abordagem interativa é muito controlada; o número, a duração e o objetivo das iterações são planejados. As tarefas e as responsabilidades dos participantes são definidas. São capturadas medidas de progresso objetivas. Ocorre algum retrabalho de uma iteração para a outra, mas isso também é cuidadosamente controlado.

Diminuição de riscos

Uma abordagem iterativa permite que você diminua os riscos mais cedo, pois muitos deles são descobertos somente durante a integração. Durante a iteração inicial, você verifica todas as  disciplinas, considerando muitos aspectos do projeto: ferramentas, softwares desenvolvidos internamente e adquiridos prontos para serem usados, habilidades das pessoas e assim por diante. Pode ser que riscos aparentes demonstrem que não são riscos, e riscos novos e inesperados aparecerão.

Acomodação de mudanças

A abordagem iterativa permite que você considere os requisitos variáveis, já que eles normalmente serão alterados durante o processo.

Forçar os usuários a aceitarem o sistema como o imaginaram originalmente está errado. Eles mudam de idéia porque o contexto está sendo alterado; eles aprendem mais sobre o ambiente e a tecnologia e enxergam uma demonstração intermediária do produto durante o seu desenvolvimento.

Busca de melhor qualidade 

Uma abordagem iterativa resulta em uma arquitetura mais robusta, pois os erros são corrigidos após várias iterações. As falhas iniciais são detectadas conforme o produto amadurece, durante as iterações iniciais. Os gargalos de desempenho são descobertos e podem ser reduzidos, em vez de aparecerem na véspera da liberação.

Aumento de reutilização 

O uso de uma abordagem iterativa facilita o aproveitamento dos produtos desenvolvidos internamente e adquiridos prontos para serem usados. Você terá várias iterações para selecioná-los, integrá-los e confirmar que eles são adequados à arquitetura.

Referência Ao Post:

http://www.wthreex.com/rup/manuals/intro/im_bp1.htm

http://www.wthreex.com/rup/OpenUP/index.htm

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