A Seguir, mostraremos o OpenUP + MPS-BR Níveis G, F, E, D, C, B e A, aplicados no projeto SolarSex.

Esses níveis foram adicionados progressivamente ao longo de um mês, tendo como base a documentação oficial do MPS-BR fornecida pelo professor Marcondes.

Essa atividade está sendo executada em grupo pelos seguintes integrantes:

Thomas Lopes
Rafael C. Rocha
Danilo Oliveira
Marcelo Honório

Introdução

Desenvolvimento

Nivel G
Nível F
Nível E
Nível D
Nível C
Nível B
Nível A

Conclusão

Histórico da Revisão

Introdução

Este documento visa atender aos aspectos abaixo:

Considerando o OpenUP(http://epf.eclipse.org/wikis/openup/) e o projeto do 4º Semestre, em grupos, para o nível G ao A do MPS-BR:

1. Para cada atributo e resultado esperado, descreva como podem ser implementados.
2. Defina uma estratégia para implementação do MPS.BR começando pelo nível B.
3. Defina pelos menos um artefato direto e um indireto que comprove a implementação de cada resultado esperado.

Desenvolvimento

 Estratégia de Desenvolvimento do projeto SOLARSEX à partir do nível F

Nível G

AP 1.1 – O Processo é executado :

No OpenUP, o levantamento de requisitos é feito principalmente a partir de casos de usos. Inicia-se com um glossário que serve como referência ao desenvolvimento do projeto.

Artefato: Glossário

AP 2.1 O Processo é gerenciado:

O levantamento de requisitos do OpenUP é feito principalmente sobre casos de uso

Artefato:  Diagramas de caso de uso

AP 1.1 – O Processo é executado :

A garantia de que uma gerência de requisitos é executa em um processo usando o OpenUP é a própria existência de um Plano de Projeto (“Project Plan”) que siga as especificações do OpenUP. Esse Plano é uma aproximação em alto-nível que define os objetivos pretendidos com o projeto

O artefato direto que pode comprovar o resultado esperado é o próprio Plano em si.

Artefato: Plano de Projeto

AP 2.1 O processo é gerenciado

Para que a Gerência de Requisitos atinja esse atributo é necessária uma grande responsabilidade por parte do gerente de projeto. É ele quem garante a política organizacional estabelecida (RAP2), no que não for diretamente decorrente da cultura da empresa que desenvolve o projeto.

No caso do Projeto SolarSex, tratam-se de poucas tarefas pelo pequeno porte do processo. Ainda sim, deve ocorrer planejamento (RAP 3), é um monitoramente baseado em medições (RAP4).

Como se trata de um projeto acadêmico, não se pode garantir o treinamento adequado dos participantes do projeto (RAP6) que são estudantes. Porém, já existe uma preocupação com os riscos envolvidos.

Artefato:  Lista de Riscos (“Risk List”)

Nível F:

3) Aquisição – AQU

AP 1.1 – O Processo é executado:  

Não faz sentido um plano de aquisição para o projeto considerado. Tampouco o OpenUP contém artefatos direcionados a este fim por se tratar de um  Processo para pequenos projetos, com pequenas equipes colaborativas.

Logo não deve ser aplicado a um sistema pequeno como o proposto pelo grupo de BSI Solar Sex.

Artefato: Plano de Aquisição do MPS.BR

AP 2.1 O processo é gerenciado:

IDEM

AP 2.2 Os produtos de trabalho do processo são gerenciados:

IBIDEM 

4) Medição – MED

AP 1.1 – O Processo é executado:

As métricas são um ponto fundamental de qualquer processo de desenvolvimento de software. Não é diferente no OpenUP. Como se trata de um processo ágil e incremental, as métricas devem entrar no plano de iteração.

Artefato: Plano de Iteração

Para um projeto como o SolarSex deve-se também ter em vista tais metricas das informações recolhidas nas iterações, apesar de não ter sido aplicado pelo grupo em questão.

 
 
AP 2.1 O processo é gerenciado:

No caso do OpenUp, existe um planejamento nas métricas. As mesmas devem ter um custo - benefício aceitável. Elas devem focar:

Qualidade de Software: Cobertura do código: Porcentagem testada; Log dos defeitos: número de defeitos corrigidos por iteração.

Produtividade: Velocidade: quantidade de pontos desenvolvidos por iteração

Eficiência do Desenvolvimento: Número de propostas x número de efetivas implementações

Custo e Cronograma: Custo da iteração e esforço despendido e remanescente.

Artefato: Plano de Métrica Geral (dentro do Plano do Projeto)

Para o projeto em questão, como não houve um calculo de tais métricas sitadas não houve o planejamento proposto pelo OpenUp.


AP 2.2 Os produtos de trabalho do processo são gerenciados

5) Garantia da Qualidade – GQA

"O propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos e ecursos predefinidos."

AP 1.1 – O Processo é executado:

A aderência dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente, antes dos produtos serem entregues ao cliente e em marcos predefinidos ao longo do ciclo de vida do projeto; (RAP 1 / GQA 1). No OpenUp, esse requisito é cumprido pelos processos de Análise de Requisitos e de Testes.

Artefatos: Test Cases, System-wide Requirements,

AP 2.1 O processo é gerenciado:

A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente; (RAP 2 / GQA 2): No OpenUP, esse requisito é cumprido pelos itens do AP1.1 mais os detalhes feitos pelo Project Manager, ao delegar ordens de padronização dos processos e garantia da qualidade.

Os problemas e as não-conformidades são identificados, registrados e comunicados; (RAP 3 / GQA 3). No OpenUP, esse processo é feito ao armazenar e distribuir logsdos testes diversos.

Artefato: Test Logs

AP 2.2 Os produtos de trabalho do processo são gerenciados:

Ações corretivas para não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões. Quando necessário, escalonamento das ações corretivas para níveis superiores é realizado, de forma a garantir sua solução; (RAP 4 / GQA 4). Garantido pela comunicação interna do OpenUP, e a liberação do acesso aos artefatos necessários pelos membros da equipe.

Artefatos: Development Design, Development test, Test Logs

Com a evolução do desenvolvimento do projeto SolarSex, deveriam ser necessários o desenvolvimento dos artefatos descritos nesse item, para que fosse alcançado o nivel em questão, e o projeto tenha a garantia da qualidade previstas pelo nível. Porém pouco foi visto na produção observada, mas devemos levar em conta também o amplitude do projeto em questão, que talvez seja muito pequeno para se fazer nescessária tais proposições.

6) Gerência de Configuração – GCO

"O propósito do processo de Gerência de Configuração é estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos."

AP 1.1 – O Processo é executado:

Usando OpenUP, o processo atinge o seu propósito estabelecendo-se e mantendo-se de qualquer sistema de controle de versão, como o SVN, ou o CVS, por exemplo (RAP 1 / GCO 1). O OpenUP não especifica qual sistema gerenciador de configurações usar, portanto, fica a cargo da equipe definir qual. Essas tecnologias podem inclusive ser aplicadas em qualquer metodologia que necessite esse tipo de controle.

AP 2.1 O processo é gerenciado

A partir do momento em que o uso do sistema de controle de versões é exigido, e partindo do gerente de projetos, para todos os membros do projeto, o processo de GCO passa a ter uma política organizacional (RAP 2 / GCO 2) e também ser planejado antes de aplicado (RAP 3 / GCO 3). Se o gerente de projetos (ou nesse caso, outra pessoa definida por ele) monitora a execução do processo, fazendo os ajustes no SVN/CVS caso seja necessário, é alcançado o (RAP 4 / GCO 4).

AP 2.2 Os produtos de trabalho do processo são gerenciados

Facilmente, modificações em Itens de configuração: (RAP5/GCO5) é alcançado com o SVN/CVS. Também o são o GCO6 e GCO7, “Auditorias de configuração” e “Armazenamento, manuseio e liberação de itens de com figuração”, respectivamente. Os arquivos e todos itens nos quais seja necessário ter um controle de versão podem ser gerenciados pelos sistemas SVN ou CVS, garantindo que os produtos de trabalho do processo também sejam gerenciados.

Artefato em todos AP’s: Sistema de Controle de Versão (SVN/CVS)

Para ser desenvolvido o projeto SolarSex não se faz necessário o desenvolvimento desse item e seus artefatos por representar um projeto pequeno e de baixa complexidade.
 

Nível E

IDEM (ver Nível G)

AP 2.1 O processo é gerenciado

IBIDEM

AP 2.2 Os produtos de trabalho do processo são gerenciados

 IBIDEM

AP 3.1. O processo é definido

Para atingir este nível a equipe já deve possuir uma experiência mais avançada, de desenvolvimento usando o OpenUp. Isso implica que a equipe seguira a risca as especificações que foram definidas do projeto.

Artefato: Planos de projeto.

AP 3.2 O processo está implementado

Este nível exige um conhecimento maior em gerencia de projetos, para conseguir   desenvolver todas as especificações que estão implementadas no artefato, seguindo a organização definida no mesmo, fazendo uso do processo OpenUp. 

Artefato: Planos de projeto.                         

8) Gerência de Reutilização – GRU

AP 1.1 – O Processo é executado:

O projeto poderá utilizar códigos já implementados em processos anteriores, porém sem uma nova documentação. O design pode seguir os padrões ja utilizados em momentos anteriores, fazendo uso de sua implementação assim como da documentação que já foi realizado para o mesmo em outro momento.

Artefato: Design

AP 2.1 O processo é gerenciado

Já existe uma documentação desses códigos que estão sendo usados novamente pelo projeto. Como sitado no intem anterior não haverá iremos utilizar o design já produzido anteriormente, como ele já possui a devida documentação, não se fará necessario refazer todo este trabalho.

Artefato: Design

AP 2.2 Os produtos de trabalho do processo são gerenciados

O produto da reutilização de códigos não terá uma nova documentação, será reutilizado tambem a documentação já gerada. Deve-se apenas documentar as possiveis modificações para deixar os produtos reutilizados compativel para o novo projeto como descrito no OpenUp.

Artefato: Implementation

 AP 3.1. O processo é definido

O conhecimento da equipe é fundamental para poder reutilizar códigos de maneira correta no nível E. As definições de iteração já descritas no plano devem ser levado em conta como podemos ver definido no OpenUp, a forma como será levado em conta vai vir da experiência demonstrada pela equipe.

 Artefato: Plano de iteração

AP 3.2 O processo está implementado

A experiencia terá papel fundamental para implementar o processo. Com o conhecimento já adquirido nos processos anteriores pará a correta reutilização, seguindo o OpenUp.

 Artefato: Plano de projeto

 9) Gerência de Recursos Humanos – GRH

AP 1.1 – O Processo é executado :

Os desenvolvedores envolvidos no projeto já com algum conhecimento nas ferramentas e estratégias utilizadas.  Deverá designar um grupo de pessoas para realizarem os testes do produto final e na faze de desenvolvimento. Para tal procedimento devemos escolher pessoas que devem conhecer a especificação completa do projeto. 

Artefato: Developer Test

AP 2.1 O processo é gerenciado

 Já se tem uma documentação exibindo o conhecimento da equipe de desenvolvedores que participaram do processo. Assim como descrito pelo OpenUp o artefato deve documentar as pessoas que desenvolveram a especificação para possiveis teste em fase de desnvolvimento. 

Artefato : Build

AP 2.2 Os produtos de trabalho do processo são gerenciados

Há uma documentação do desempenho da equipe. Assim como das pessoas aptas a estarem realizando testes no sistema. A priori deve-se utilizar pessoas que fazem parte do desenvolvimento junto com os principais usuários do sistema.

Artefato: System-Wide Requirements

AP 3.1. O processo é definido

Fazendo uso da experiencia em projetos do tipo da equipe, e do conhecimento a fundo dos mesmos pela especificações definidas pelo usuário deve-se definir uma politica de teste assim como apresentadas no site do OpenUp. Testando cada caso definido no artefato, para que não haja nenhum bug nos casos de uso definidos, e que teoricamente, será as unicas operações possiveis a serem realizadas pelos usuários.

Artefato: Test Case

AP 3.2 O processo está implementado

Cada teste descrito pelo artefato sitado é realizado em todas as fases desse projeto, para a validação de cada especificação como nota-se nas definições do artefato pelo OpenUp, e reconhecimento de cada bug em sua fase inicial para nao acarretar problemas em outra fase.               

Artefato: Test Case 

10)Definição do Processo Organizacional – DFP

AP 1.1 – O Processo é executado :

A equipe deve possuir integrantes comopetentes e experientes, para gerarem um setor de organização, que conheçam as capacidades de cada desenvolvedor para discutir as especificações junto ao usuário e gerar especificações para a equipe de modo mais eficiente. Tendo em vista já perceber cada possivel problema nos requisitos solicitados pelo cliente. Discutindo os resultados que devem ser esperados a cada caso de uso.

Artefato: Use Case

AP 2.1 O processo é gerenciado

Já possuimos uma documentação referente a como deve ser especificado as necessidades de cada cliente documento cada possivel utilização para o sistema sem que seja modificado nenhum dos retornos esperados pelo cliente.

Artefato: System-Wide Requirements

AP 2.2 Os produtos de trabalho do processo são gerenciados               

Deve ser documento cada produto esperado pelo usuário e qual deve ser o analizado se o mesmo esta retornando a informação esperada. A equipe de organização deve especificar cada retorno possivel e qual deve ser o retorno correto a ser descrito. Os funcionarios do setor de organização também deve realizar os teste para verificarem cada produto retornado ao usuário.

Artefato: Developer Test

AP 3.1. O processo é definido               

Já é conhecido o modo como deve ser organizado a especificação do projeto, como deve ser definido cada caso de uso do sistema, cada produto resultante a ser esperado pelo usuário, assim como como será realizados os testes para julgar se o projeto esta de acordo com cada especificação descrita e os produtos obtidos estejam todos de acordo com o que já foi definido.

Artefato: System-Wide Requirements

AP 3.2 O processo está implementado

Para atingir este nivel fazendo uso das definições do OpenUp, devemos colocar em pratica cada processo definido anteriormente, para a tradução das especificações colocadas pelo usuário para que seja de pleno entendimento pela equipe, definindo cada caso de uso do sistema, e cada resultado esperado destes casos de uso.              

Artefato: Glossary 

11) Avaliação e Melhoria do Processo Organizacional  – AMP

AP 1.1 – O Processo é executado :

Neste nivel devemos estar sempre a procura de melhorias nas fazes do projeto, na parte gerada pela equipe organizacional deve ser descritos cada problema com a especificação dos projetos, e com a teste realizada em fase desenvolvimento para corrigir tais problemas em projetos posteriores.

Artefato: Risk List

AP 2.1 O processo é gerenciado

Já existe uma documentação especificando como deve ser traduzida, e passada aos desenvolvedores para total compreenção dos mesmos. As especificações devem possuir um padrão já documentado.

Artefato: Project Plan

AP 2.2 Os produtos de trabalho do processo são gerenciados               

Como citado no item anterior a especificação resultante da fase organizacional, deve seguir um padrão já documentado, para compreensão total da equipe de desenvolvedores das solicitações do usuário, e produtos esperados como retorno.

Artefato: Use-Case Model

AP 3.1. O processo é definido               

Cada problema detectado na geração dos requisitos realizado pelo setor organizacional, deve relatado para uma analize geral da equipe e ser listados possiveis melhorias na organização dos resultados solicitados pelo usuário em questão, assim como é definido pelo OpenUp.

Artefato: Glossary

AP 3.2 O processo está implementado               

Existe um sistema para armazenamento de cada erro detectado no processo organizacional, sendo futuramente, de tempo em tempo,  analizado e listado possiveis solucições para que nao se repita os mesmos problemas novamente. Tal implementação já possui uma documentação referente ao mesmo.

Artefato: System-Wide Requirements

Nivel D

  5. Desenvolvimento de Requisitos (DRE)

    Identificação de todos os requisitos do produto solicitado pelo cliente.

    5.3.1    -    DRE1:  As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas in    terfaces, são identificadas

        Para atingir tal nível devemos identificar todos os requisitos e possíveis restrições do cliente. Para i        sso se faz necessário realizar entrevistas com o cliente para podermos analizar cada necessidade, espect        ativa, restrição e interface desejada pelo mesmo, tornando possível a identificação de requisitos adicio        nais que não foram colocados diretamente pelo cliente.
        No caso do solarsex devemos realizar uma nova entrevista junto ao cliente para detectarmos os possíveis         requisitos ainda não identificados, verificando cada tela desejada pelo usuário.

    Artefato: Casos de Uso.

    5.3.2    -    DRE2: Um conjunto definido de requisitos do cliente é especificado a partir das necessidades, ex    pectativas e restrições identificadas

        Utilizando a documentação gerada no item acima, devemos traduzir  cada necessidade, restrição, espectati        va e interface identificada em requisitos do cliente.
        Após tal tradução deve ser apresentado cada um a todos as pessoas envolvidas no projeto, para caso neces        sário seja identificado qualquer conflito que possa existir nos requisitos apresentados.

    Artefato: Casos de Uso.

    5.3.3    -    DRE3: Um conjunto de requisitos funcionais e não-funcionais, do produto e dos componentes do pro    duto que descrevem a solução do problema a ser resolvido, é definido e mantido a partir dos requisitos do client    e.

        Analisando cada requisito do cliente devemos identificar cada requisito funcional ou não-funcional. Requ        isitos funcionais são as funções esperadas pelo sistema. Os não-funcionais são os requisitos que determi        nam as restrições ou qualidades do produto. 
        No caso do projeto solarsex podemos dizer que um requisito funcional seria o relatório dos dados que for        am cruzados. Um não-funcional, seria o tempo que o sistema pode levar para cruzar tais dados.

    Artefato: Planos de Projeto.

    5.3.4    -    DRE4: Os requisitos funcionais e não-funcionais de cada componente do produto são refinados, ela    borados e alocados

        Refinação de todos os requisitos, tanto funcionais como não-funcionais. Expressar os mesmos em termos té        cnicos. Neste item os requisitos costumam ser categorizados em grupos através de critérios definidos. N            o caso do solarsex creio que não seja necessário tal separação em grupos, devido a simplicidade do proje        to.

    Artefato: Casos de Uso

    5.3.5     -    DRE5: Interfaces internas e externas do produto e de cada componente do produto são definidas.

        Neste item deve-se especificar e documentar as interfaces internas e externas, assim como de cada compon        ente que o projeto contém. Deve-se também especificar como serão integrados os componentes tanto extern            o como o interno.

    Aretefato: Planos de Projeto.

    5.3.6     -    DRE6: Conceitos operacionais e cenários são desenvolvidos
     
        Desenvolvimento de conceitos operacionais e cenários paro o produto e seus componentes.
        Para a definição de um conceito operacional depende-se do projeto da solução e de um cenário, logo só po        de ser elaborados depois de tomada as decisões do projeto e refinado os requisitos.
        Para descrever um cenário necessita-se considerar o fluxo principal, fluxos alternativos, fluxo de exceç        ão, pré e pós condição. Com isso abrange-se o ambiente que o produto operará, um conceito operacional pa        ra o sistema e seus componentes e revisão dos conceitos operacionais e cenários.

    Artefato: Casos de uso, Plano de iteração.

    5.3.7     -    DRE7: Os requisitos são analisados para assegurar que sejam necessários, corretos, testáveis e s    uficientes e para balancear as necessidades dos interessados com as restrições existentes

        Deve-se ter certeza de que todos os requisitos estão de acordo. Deve-se analisar levando em conta se tod        os os requisitos foram declarados de forma não ambígua, todas as inconsistências e erros tenham já sido         detectados e corrigidos, que todos os requisitos estejam consistentes com todos os níveis.
   
    Artefato: Plano de Projeto.

    5.3.8     -    DRE8: Os requisitos são validados

        Validar todos os requisitos com técnicas adequadas, dando a certeza de que o produto terá um bom desempe        nho quando implantado no ambiente desejado. Com isso obtém-se maior confiabilidade de que os requisitos         são capazes de guiar o desenvolvimento.

    6 - Integração do Produto (ITP)

    6.3.1 ITP1 - Uma estratégia de integração, consistente com o projeto e com os requisitos do produto, é desenvolv    ida para os componentes do produto

        Definição de uma estratégia, contendo procedimentos e critérios para a integração de todos os componente        s. Devemos definir todos os itens a serem integrados, assim como em qual ordem isso será realizado. No c        aso do projeto solarsex do grupo de BSI, isso provavelmente não será muito necessário devido a simplicid        ade do projeto, e um pequeno número de componentes para serem integrados.

    Artefato: Class Diagram

    6.3.2     -    ITP2: Um ambiente para integração dos componentes do produto é estabelecido e mantido

        Definição de um ambiente para integração, assim como de critérios e procedimentos para a verificação des        te ambiente. Como exposto no item acima, no caso do projeto do grupo de BSI pelo qual nós ficamos respon        sáveis por analisar,  contém uma baixa complexidade e por isso um baixo número de componentes a serem in        tegrados, sendo assim não será tão necessário tal ambiente.

    Artefato: Plano de Projeto, Casos de Uso

    6.3.3    -    ITP3: A compatibilidade das interfaces internas e externas dos componentes do produto é assegura    da

        Existem muito problemas de integração que são desconhecidos, ou que não são controladas. Para termos a c        erteza de que as interfaces externas e internas são compatíveis devemos revisa-las, prevenindo assim alg        uns desses problemas.

    Artefato: Implementation

    6.3.4 ITP4 - As definições, o projeto e as mudanças nas interfaces internas e externas são gerenciados para o pr    oduto e os componentes do produto

        Devemos garantir que a consistência de todas as interfaces será mantido no ciclo de vida completo do pro        duto. Além disso devemos tratar os conflitos, não conformidades e questões relativas a modificações. E d        eve ser criada uma documentação de tais mudanças.

    Artefato: Plano de projeto.

    6.3.5 ITP5 - Cada componente do produto é verificado, utilizando-se critérios definidos, para confirmar que este    s estão prontos para a integração

        Verificação de cada componente do sistema, para ter a certeza de que estão todos prontos para a integraç        ão. De acordo com com a sequência já definida. Para esta verificação devemos utilizar critérios já defin        idos.

    Artefatos: Work Items List

    6.3.6    -     ITP6: Os componentes do produto são integrados, de acordo com a seqüência determinada e seguind    o os procedimentos e critérios para integração

        O objetivo descrito nesse item é garantir que os componentes do sistema sejam integrados, seguindo a seq        uência já descritas, e seguindo os procedimentos e critérios já definidos.

    Artefatos: Plano de Projeto

    6.3.7    -    ITP7: Os componentes do produto integrados são avaliados e os resultados da integração são regis    trados

        Garantir que seja avaliado a integração de todos os componentes e que essa avaliação seja documentado. P        ode ser avaliado através de testes de integração e analisando os resultados obtidos.
        Os teste de integração visam descobrir problemas na estrutura do software, definidos na fase de projeto.
        Desenvolve-se um plano de testes de integração, e obtém-se um relatório a ser analisado.

    Artefato: Plano de teste

    6.3.8     -    ITP8: Uma estratégia de regressão é desenvolvida e aplicada para uma nova verificação do produt        o, caso ocorra uma mudança nos componentes do produto (incluindo requisitos, projeto e códigos associados)

        Garantindo que haja uma estratégia de testes de regressão caso haja mudanças nos componentes do produt            o.
        No caso do projeto solarsex que estamos analisando, provavelmente não será necessario uma modificação e            m nenhum componente, requisito projeto ou código assciado, devido a baixa complexidade em questão.

    Artefato: Plano de testes

    6.3.9     -    ITP9: O produto e a documentação relacionada são preparados entregues ao cliente

        Este item visa a organização do produto e sua documentação em uma midia adequada e entregue ao cliente.

7 - Projeto e Construção do Produto (PCP)

    7.3.1    -    PCP1: Alternativas de solução e critérios de seleção são desenvolvidos para atender aos requisitos definidos

        Durante a construção de um projeto existem diversas formas para se chegar a solução, estas devem ser ana        lisadas, e deve-se avaliar a melhor fazendo uso de critérios pré-estabelecidos.
        No caso do projeto proposto pelos alunos de BSI, não deve haver muitas formas de solução, creio que o gr    upo em questão não necessitou de propor tais critérios.

     7.3.2    -    PCP2: Soluções são selecionadas para o produto ou componentes do produto, com base em cenários d    efinidos e em critérios identificados
   
        Com os critérios de seleção identificados, analisa-se as soluções alternativas em busca da que seja mai            s adequado pra o problema em questão.
        A evolução dos cenário existentes durante o projeto, pode ajudar a identificar a alternativa mais releva        nte para a execução do projeto de forma mais eficiênte.

    Artefato: Plano de Projeto

    7.3.3 PCP3 - O produto ou componente do produto é projetado e documentado

        Neste item deve-se projetar o produto de forma que atenda os requisitos já identificados. Criando normal        mente um projeto de arquitetura do sistema e um projeto do software. Tudo isso deve ser muito bem docume        ntado.

    Artefato: Plano de projeto

    7.3.4 PCP4 - As interfaces entre os componentes do produto são projetadas com base em critérios predefinidos

        O projeto deve conter uma descrição das interfaces assim como o critério para seleção das mesmas. Interf        aces entre os componetes de todos os níveis.
        Lembrando que cada interface deve ser definido levando em conta os requisitos já definidos.

    Artefato: Plano de projeto

    7.3.5 PCP5 - Uma análise dos componentes do produto é conduzida para decidir sobre sua construção, compra ou reu    tilização

        Muitas empresas optam por adquirir alguns componentes desenvolvidos por outras empresas. Logo deve ser a        nalisado qual o mais vantajoso: desenvolver um componente internamente na empresa, adquirir de uma empre        sa ou reutilizar um componente já disponível na empresa.
        No caso do solarsex creio que este itém pode ser descartado, pois obviamente está fora do escopo, até me        smo por se tratar de um projeto desenvolvido dentro de uma faculdade, apenas para aprendizagem do grupo.

    7.3.6 PCP6 - Os componentes do produto são implementados e verificados de acordo com o projeto (design)

        Implementação dos componentes da forma especificada e desenvolvimento da documentação referente aos mesm        os.
        A implementação é realizada utilizando um método, como por exemplo POO.
        Há também uma revisão de cada componente.


    7.3.7 PCP7 - A documentação é identificada, desenvolvida e disponibilizada de acordo com os padrões identificado    s

        Desenvolve-se toda a documentação associada ao projeto, de acordo com os padrões. Cria-se um pacote de d        ados técnicos descrevendo todo o projeto, permitindo a todos as pessoas que terão de realizar outros des        envolvimentos ou manutenção no próprio sistema.

    Artefato: Plano de Projeto.

    7.3.8 PCP8 - A documentação é mantida de acordo com os critérios definidos

        A documentação deve ser mantida e revisada de acordo com critérios já estabelecidos. Para facilitar o en        tendimento da documentação em questão pode-se utilizar padrões já estabelecidos.

    Artefato: Plano de Projeto

    8 Validação (VAL)

    8.3.1 VAL1 - Produtos de trabalho a serem validados são identificados

        Identificação dos produtos a serem validados durante o andar do projeto. A escolha de tais componentes d        evem levar em conta as necessidades do cliente, assim como os riscos de cada componente analisado.
        Tal identificação pode ser feita no inicio do projeto com base nos artefatos desenvolvidos.

    Artefato: Plano de Projeto.

    8.3.2 VAL2 - Uma estratégia de validação é desenvolvida e implementada, estabelecendo cronograma, participantes     envolvidos, métodos para validação e qualquer material a ser utilizado na validação

        Garantia de que as atividades de validação sejam planejadas. Devem ser identificados também os métodos             a serem utilizados nesta atividade. Algumas atividades de validação devem ser planejadas, no caso das es        tratégias de testes por exemplo.

    Artefato: Plano de testes

    8.3.3 VAL3 - Critérios e procedimentos para validação dos produtos de trabalho a serem validados são identificad    os e um ambiente para validação é estabelecido

        Garantir que os critérios e procedimentos na fase de validação foram identificados, e existe um ambient            e para os mesmos, semelhante ao operacional.
        Deve ser identificado os critérios para cada produto ou componente do produto.

    Artefato: Plano de testes

    8.3.4 VAL4 - Atividades de validação são executadas para garantir que os produtos de software estejam prontos pa    ra uso no ambiente operacional pretendido

        Ter a certeza de que as atividades de validação foram realizadas seguindo o planejamento, e não ter duvi        das de que o produto esta pronto para ser utilizado no ambiente operacional.
        Isto pode ocorrer através dos testes planejados. No caso do solarsex creio não necessitar deste item, j            á que o mesmo não será implantado em outro ambiente.

    Artefato: Plano de testes.

    8.3.5 VAL5 - Problemas são identificados e registrados

        Garantir que todos os problemas detectados na validação foram identificado e documentados, deve-se també        m definir quais serão tratados.

    8.3.6 VAL6 - Resultados de atividades de validação são analisados e
    disponibilizados para as partes interessadas

        Analisar todos os resultados obtidos com a validação do projeto disponibilizado ao cliente. É feita por         meio de laudos resultantes do processo de avaliação e relatórios dos testes.

    8.3.7 VAL7 - Evidências de que os produtos de software desenvolvidos estão prontos para o uso pretendido são for    necidas

        Depois de verificar que o produto  satisfaz os requisitos descritos devemos realizar testes em seu ambie        nte de prdução.
   
    No projeto solarsex o item 8 não esta muito no escopo já que não existe um ambiente operacional que ser            á implantado o mesmo.

9 Verificação (VER)

    9.3.1 VER1 - Produtos de trabalho a serem verificados são identificados

        Devemos analisar os produtos que serão produzidos e identificar qual deverá se verificado. Os produtos q        ue devem ser verificados são selecionado levando em conta sua contribuição para se atingir os requisito            s, e levando em conta os riscos do mesmo para o projeto.

    Artefato: Plano de Projetos

    VER2 - Uma estratégia de verificação é desenvolvida e implementada, estabelecendo cronograma, revisores envolvid    os, métodos para verificação e qualquer material a ser utilizado na verificação.

        Criar uma estratégia de verificação, descrevendo os procedimentos, a infra-estrutura e as responsabilida        des.
        Criar as métricas a serem utilizados na verificação dos produtos.

    Artefato: Plano de testes

    VER3 - Critérios e procedimentos para verificação dos produtos de trabalho a serem verificados são identificado        s e um ambiente para verificação é estabelecido.

        Definir todos os critério e procedimentos a serem utilizados na verificação, disponibilizando toda infra        -estrutura necessária para a verificação de cada produto.

    Artefato: Plano de testes

    VER4 - Atividades de verificação, incluindo testes e revisões por pares, são executadas.

        Garantir que as atividades de verificação foram realisadas da forma planejada.
   
    Artefato: Plano de Testes.

    VER5 - Defeitos são identificados e registrados.

        Documentação e registro de todos os defeitos identificados durante as atividades de verificação. Classif        icar os defeitos, analisando-os e identificado os que devem ser removidos do sistema. Realizar uma nova         verificação para ter a certeza de que foram todos removidos.

    VER6 - Resultados de atividades de verificação são analisados e disponibilizados para as partes interessadas.

        Analisar os resultados obtidos nas atividades de verificação e disponibiliza-las aos clientes. Analisand        o os laudos de avaliação e os relatórios de testes.

    Artefato: Plano de testes.

    Creio que o item 9 também não engloba o projeto do grupo de BSI em questão até mesmo pela baixa complexi        dade do sistema proposto.

Nível C

Análise de Decisão e Resolução – ADR

O propósito do processo Análise de Decisão e Resolução é analisar possíveis decisões usando um processo formal, com critérios estabelecidos, para avaliação das alternativas identificadas.

No Nível C do MPS-BR, o processo de Análise de Decisão e Resolução deve ser executado, gerenciado, Seus produtos de trabalho do processo Gerenciados, o processo é definido e implementado (alcançando finalmente o AP 3.2). Para alcançar esse nível, os seguintes itens devem ser atendidos:

AP 1.1 - O processo é executado

• Atividades de analise e verificação das decisões que serão tomadas em situações não identificadas no inicio do projeto ou durante seu planejamento/andamento.

• São definidas ações para corrigir problemas e incompatibilidades encontradas no desenvolver do código.

AP 2.1 - O processo é gerenciado

• Analises são realizadas, reportadas e exigidas periodicamente, tendo um controle de todas as decisões tomadas e todas as resoluções definidas no desenvolver do projeto.

AP 2.2 - Os produtos de trabalho do processo são gerenciados

• Planilhas de controles e tempos médios de cronograma para analises já estão prontos e definidos.

AP 3.1 - O processo é definido

• Um local para armazenamento é definido para o controle de todas as decisões e resoluções que serão necessárias para a realização do projeto.

• Um cronograma com as datas em que as analises deverão ser realizadas e prazos para que as decisões e resoluções sejam definidas.

AP 3.2 - O processo está implementado

• Os produtos de trabalhos gerados estão sendo utilizados
• Planilhas sendo preenchidas nos períodos definidos
• Os prazos estipulados para as decisões e resoluções são cumpridos.

Dentro dessas itens, os seguintes artefatos estão relacionados:

Artefatos no OpenUP:

• Project Plan

• System-WideRequirements (analisados quando ocorrerem situações não identificadas no começo do projeto)

• Iteration Plan

• Risk List
  
  
  

Produzido no SolarSex: No projeto SolarSex não foram clarificados como serão resolvidos esses tipos de resoluções. Eles possuem O Plano de Projeto e um repositório online onde os documentos e relatórios são armazenados, mas não o fazem de maneira organizada.

Nem todas as ações necessárias para a completude desse item estão sendo implementadas. Então, a seguir, definimos estratégias de implantação para cada um dos itens necessários dentro do Nível C para o ADR, sendo cada item em negrito um dos resultados esperados do processo, e sua respectiva estratégia:

ADR 1 - Guias organizacionais para a análise de decisão são estabelecidos e Mantidos: Essas guias são baseadas no processo de análise de decisão adotado pelo projeto/empresa. Devem ter um modelo conciso e prático, permitindo que o identificador do problema consiga encaminhar a análise de decisão rapidamente. Pode ser utilizado para problemas técnicos como para problemas não técnicos, então deve refletir a cultura da empresa e o estilo de gestão dos Project Managers. Também devem ser fortemente embasadas nos SystemWide-Requirements. Sugestões para essas Guias:

• Definição de Ferramentas

• Definição de Componentes

• Definição de Possíveis Problemas

ADR 2 - O problema ou questão a ser objeto de um processo formal de tomada e decisão é definido: Para iniciar o processo de tomada de decisão, devesse iniciar pela definição do problema que será resolvido, pois esta definição decidirá sobre as soluções que serão adotadas para a solução. Algumas técnicas que julgamos essenciais para definição do problema e trabalho na sua solução são:

• Descrever o problema de forma clara e precisa;

• Definir o escopo do problema;

• Formular o problema como pergunta;

• Focar no problema raiz;

• Listar os objetivos que devem ser atingidos para solucionar o problema, fortemente embasados nos requisitos do projeto.

ADR 3 - Critérios para avaliação das alternativas de solução são estabelecidos e mantidos em ordem de importância, de forma que os critérios mais importantes exerçam mais influência na avaliação: Os critérios de avaliação, influenciam na hora de escolher uma solução ideal para o problema. A priorização ou a ponderação desses critérios pode ser realizada registrando o resultado do trabalho com os motivos da escolha dos critérios. Deve-se também ser registrado o motivo que algum critério foi recusado, para que seja aplicado em futuros projetos.

ADR 4 - Alternativas de solução aceitáveis para o problema ou questão são Identificadas: Sempre devem ser fornecidas alternativas para a solução do mesmo problema. As alternativas das soluções devem ser feitas de uma forma que seja possível realizar uma avaliação prévia, em reuniões, para que possa ser aplicada corretamente e de comum acordo de todas as pessoas envolvidas. Quando feito, os envolvidos no problema devem estar presentes na execução das atividades. Outras atividades estratégias:

• Fazer registros históricos

• Utilizar o Plano de Gerência e Mitigação de Riscos

• Realizar Avaliações Quantitativas e Qualitativas

ADR 5 - Os métodos de avaliação das alternativas de solução são selecionados de acordo com sua viabilidade de aplicação: Os métodos para serem utilizados na avaliação das soluções podem mudar conforme os fatores que estes dependem. Entre eles, pode-se adotar:

• Reunião e apresentação das soluções (diagramas, fluxogramas, estudos de casos semelhantes)

• Executar Simulações, utilizar modelos, até chegar em situações onde cheguem ao desenvolvimento de sistemas para situações mais especificas.

• O Nível de detalhamento e complexidade dos métodos, deve ser avaliado em relação à necessidade.

ADR 6 - Soluções alternativas são avaliadas usando os critérios e métodos estabelecidos: As alternativas das soluções devem ser avaliadas, realizando o trabalho necessário para aplicar os métodos selecionados para as soluções propostas.

• Comparar os resultados obtidos em cada uma das alternativas com relação aos critérios estabelecidos

• Verificar também se está adequada com as restrições impostas pelo problema como pela alternativa em questão

• Elaborar um documento com os resultados obtidos após a aplicação dos critérios da alternativa escolhida.

• Podem ser usadas avaliações com base nas alternativas do ADR4 também.

ADR 7 - Decisões são baseadas na avaliação das alternativas utilizando os critérios de avaliação estabelecidos: A partir das alternativas avaliadas, escolher aquela onde se encaixam melhor os critérios estabelecidos, e que também resolvam o problema.

• As soluções devem ser documentadas para que se mantenha um controle e futuros esclarecimentos possam ser solucionados rapidamente.
• Estabelecendo um processo para analises futuras, tendo uma boa pratica em registrar as justificativas da alternativa escolhida
• Após a escolha da alternativa da solução do problema, aconselha-se descrever algumas recomendações para seu desenvolvimento, traçar as linhas gerais de como a solução escolhida deve ser desenvolvida.

Desenvolvimento para Reutilização – DRU

O propósito do processo Desenvolvimento para Reutilização é identificar oportunidades de reutilização sistemática na organização e, se possível, estabelecer um programa de reutilização para desenvolver ativos a partir de engenharia de domínios de aplicação.

No Nível C do MPS-BR, o processo de Desenvolvimento para Reutilização deve ser executado, gerenciado, seus produtos de trabalho do processo Gerenciados, o processo é definido e implementado (alcançando finalmente o AP 3.2). Para alcançar esse nível, os seguintes itens devem ser atendidos:

AP 1.1 - O processo é executado

• Metodologias de desenvolvimento de códigos reutilizáveis adotadas

• Modularizando e organizando os componentes de maneira adequada.

AP 2.1 - O processo é gerenciado

• Versionamento do desenvolvimento dos módulos

• Desenvolvimentos nos projetos pelos projetistas da empresa.

• Verificação se a reescrita de código está alta, comparando assinaturas e retornos dos códigos desenvolvidos.

• Tomar ações baseadas nos itens anteriores

AP 2.2 - Os produtos de trabalho do processo são gerenciados

• Repositório com todos os códigos desenvolvidos.

• Um controle de versionamento é utilizado para conseguir rastrear as alterações que foram necessárias em cada modulo.

• Os Standards de desenvolvimento estão sendo criados e catalogados

AP 3.1 - O processo é definido

• Documentos com as metodologias para desenvolvimento de códigos reutilizáveis estão disponíveis para os desenvolvedores

• Criação do repositório e liberação de acesso aos programadores (Standards)

• Definir verificações periódicas de duplicação entre os módulos desenvolvidos

AP 3.2 - O processo está implementado

• O reaproveitamento de módulos é alto

• Constante utilização do repositório criado

• Pouca duplicidade de código

• Versionamento eficiente de módulos possibilitando rastrear as novas funcionalidades implementadas e reaproveitá-las em outros módulos/projetos.

Dentro dessas itens, os seguintes artefatos estão relacionados:

Artefatos no OpenUP:

• Implementation (Software code files, data files)
• Architecture Notebook (apenas em alguns casos)
• Design (Documentação das Funcionalidades do Sistema)
• Project Plan
• Iteration Plan
  

Produzido no SolarSex: O projeto tem o Implementation, o Design, e o Project Plan, porém , eles ainda nào estão devidamente integrados e organizados para receber o grau do Nível C.

Nem todas as ações necessárias para a completude desse item estão sendo implementadas. Então, a seguir, definimos estratégias de implantação para cada um dos itens necessários dentro do Nível C para o DRU, sendo cada item em negrito um dos resultados esperados do processo, e sua respectiva estratégia:

DRU 1 - Domínios de aplicação em que serão investigadas oportunidades de reutilização ou nos quais se pretende praticar reutilização são identificados, detectando os respectivos potenciais de reutilização: É necessário:

• verificar se os ganhos da implantação de um programa de reutilização serão maiores que os custos planejados

• Será necessário identificar os domínios de atuação da organização baseado em projetos passados, onde devem estar alinhadas com as metas e o objetivo organizacional

DRU 2 - A capacidade de reutilização sistemática da organização é avaliada e ações corretivas são tomadas, caso necessário:

• Na implantação de programas de reutilização, o fator importante é a capacidade da organização em executar o programa, tendo pessoas capacitadas para executar o programa, a organização deve estar ciente que o retorno dos investimentos em um programa de reutilização será obtido em longo prazo

• Um programa de reutilização demanda recursos apropriados para a sua execução e os aspectos culturais também devem ser considerados/moldados

• Adoção de um programa de reutilização, as equipes passarão a utilizar ativos de domínio construídos e mantidos por outras equipes dentro da organização.

DRU 3 - Um programa de reutilização, envolvendo propósitos, escopo, metas e objetivos, é planejado com a finalidade de atender às necessidades de reutilização de domínios:

• Este programa de reutilização deve ter um propósito e suas metas que devem ser atingidas,

• Deve explicar os recursos necessários e disponíveis para que as metas sejam alcançadas

• Para definir um programa de reutilização deve-se estabelecer estágios intermediários para serem atingidos

• Definir suas atividades a serem executadas junto com o procedimento

• Definir o cronograma e as pessoas responsáveis pelo desenvolvimento

• Definir os indicadores que serão utilizados e o escopo
  
  

DRU 4 - O programa de reutilização é implantado, monitorado e avaliado:

• Deve ser implantado este programa de reutilização de acordo com o planejado.

• O programa deve ser monitorado considerando os indicadores planejados.

• O monitoramento do programa de reutilização deve ser comparado com o planejamento realizado.

DRU 5 - Propostas de reutilização são avaliadas de forma a garantir que o resultado da reutilização seja apropriado para a aplicação alvo:

• Se o projeto necessitar de ativos de domínio, estes devem ser criados em forma de propostas de reutilização.

• Estas propostas de reutilização podem estar na forma de solicitação de reutilização de ativos existentes, ou na forma de solicitações de construção ou aquisição de novos ativos.

• Esta proposta deve ser analisada, medindo o esforço dos ativos.
  
  

DRU 6 - Formas de representação para modelos de domínio e arquiteturas de domínio são selecionadas:

• Adoção de notações de representação dos modelos de domínio e das arquiteturas de domínio adequados.

• Modelos de domínio: a notação deve representar a fronteira entre domínios e capturar características que devem fazer parte de todas as aplicações desenvolvidas para um dado domínio.

• Nível de arquiteturas de domínio: a notação deve representar as restrições definidas no nível de modelos de domínio.
  
  

DRU 7 - Um modelo de domínio que capture características, capacidades, conceitos e funções comuns, variantes, opcionais e obrigatórios é desenvolvido e seus limites e relações com outros domínios são estabelecidos e mantidos:

• O modelo de domínio deve ser definido para todos os domínios do escopo de reutilização, acompanhando as notações estabelecidas.

• Este modelo deve ser desenvolvido em um alto nível de abstração, considerando ativos reutilizáveis

• Utilizar biblioteca de reutilizações

• Verificar por um processo formal de Gerência de Configuração (uma vez que os ativos construídos a partir deles, serão utilizados por diferentes projetos).

DRU 8 - Uma arquitetura de domínio descrevendo uma família de aplicações para o domínio é desenvolvida e mantida por todo seu ciclo de vida:

• Detalhar os modelos de domínio e Identificar famílias de aplicações para um dado domínio.

• Essas famílias de aplicações devem ser representadas via arquitetura de domínio utilizando a notação previamente estabelecida.

• Essa arquitetura de domínio possibilita identificar quais são os ativos de domínio e como eles se relacionam.

• Cada ativo de domínio pertencente à arquitetura de domínio deve ser analisado com o intuito de perceber a sua importância para a organização.

• A partir dessa análise, uma priorização deve ser estabelecida para a especificação dos ativos de domínio.

 

DRU 9 - Ativos do domínio são especificados; adquiridos ou desenvolvidos, e mantidos por todo seu ciclo de vida:

• Os ativos de domínio identificados na arquitetura devem ser especificados de acordo com a priorização previamente definida.

• Essa especificação tenta detalhar as funcionalidades do ativo de domínio, viabilizando tanto o seu desenvolvimento quanto a sua aquisição.
  

Gerência de Riscos – GRI

O propósito do processo Gerência de Riscos é identificar, analisar, tratar, monitorar e reduzir continuamente os riscos em nível organizacional e de projeto.

No Nível C do MPS-BR, o processo de Gerencia de Risco sdeve ser executado, gerenciado, seus produtos de trabalho do processo Gerenciados, o processo é definido e implementado (alcançando finalmente o AP 3.2). Para alcançar esse nível, os seguintes itens devem ser atendidos:

AP 1.1 - O processo é executado.

• Analise dos riscos que podem ocorrer no decorrer do desenvolvimento do projeto

• Decisões antecipadas para evitar riscos desnecessários são tomados

• A analise periodicamente do projeto é realizada pelos analistas e desenvolvedores.

AP 2.1 - O processo é gerenciado.

• Reuniões são definidas

• Análises em etapas criticas do projeto são identificados

• Análises são definidas para verificar possíveis riscos

• Métricas são criadas para mensurar os riscos encontrados.

AP 2.2 - Os produtos de trabalho do processo são gerenciados.

• As métricas parta mensurar os riscos são constantemente aprimoradas e adequadas as situações e projetos.

AP 3.1 - O processo é definido.

• Definir as etapas e a periodicidade em que os riscos serão avaliados no projeto

• Definir os principais riscos e suas principais resoluções

• Definir os pontos que deverão ser mensurados pelas métricas definidas

AP 3.2 - O processo está implementado.

• Riscos são encontrados e reduzidos a tempo, evitando atrasos e problemas no desenvolvimento do projeto

• As métricas definidas estão precisas e mensuram com eficiências características e situações que são riscos para o desenvolvimento do projeto.

Dentro dessas itens, os seguintes artefatos estão relacionados:

Artefatos no OpenUP:

• Risk List

• Project Plan
  
  
  

Produzido no SolarSex: O projeto tem Risk List. Ele não está de todo ruim, mas precisa se adequar ao plano de métricas para que o nível AP3.2 seja concluído.

Nem todas as ações necessárias para a completude desse item estão sendo implementadas. Então, a seguir, definimos estratégias de implantação para cada um dos itens necessários dentro do Nível C para o GRI, sendo cada item em negrito um dos resultados esperados do processo, e sua respectiva estratégia:

GRI 1 - O escopo da gerência de riscos é determinado:

• Deve-se definir claramente a abrangência de aplicação do processo de gerência de riscos na organização em relação à sua estrutura organizacional e de processos

GRI 2 - As origens e as categorias de riscos são determinadas, e os parâmetros usados para analisar riscos, categorizá-los e controlar o esforço da gerência do risco são definidos:

• Para facilitar e garantir a completude da identificação de possíveis riscos, assim como para garantir uma homogeneidade na forma de análise dos mesmos, a organização deve definir uma classificação e critérios para determinação da probabilidade e da severidade dos riscos.

GRI 3 - As estratégias apropriadas para a gerência de riscos são definidas e Implementadas:

• A estratégia de gerência de riscos deve ser definida, relacionando aspectos como: escopo da gerência de riscos;

• Métodos e ferramentas a serem utilizados na identificação, análise, mitigação e monitoração dos riscos e para a comunicação necessária; técnicas de mitigação a serem utilizadas;

• Medidas para monitorar os riscos; periodicidade de monitoração e avaliação dos riscos.

GRI 4 - Os riscos do projeto são identificados e documentados, incluindo seu contexto, condições e possíveis conseqüências para o projeto e as partes interessadas:

• Para identificação dos riscos, podem utilizar as abordagens de uso de checklists pré-definidos com os possíveis riscos.

• Reuniões com o gerente, para analise dos cenários e as lições aprendidas ao longo dos projetos anteriores.

• Com base nas abordagens de riscos definidas, deve ser identificado o potencial riscos para a organização.

GRI 5 - Os riscos são priorizados, estimados e classificados de acordo com as categorias e os parâmetros definidos:

• Para identificar os riscos é possível que se tenha uma lista numerosa, sendo necessário organizá-los em categorias e determinar uma prioridade para os mesmos.

• Escolher um subconjunto dos mesmos, talvez não seja possível realizar ações para tratar e monitorar todos os riscos com boa relação de custo/benefício

GRI 6 - Planos para a mitigação de riscos são desenvolvidos:

• Desenvolvimento de planos de contingência para garantir que se esteja preparado para a ocorrência de um determinado risco

• Pode-se escolher evitar um risco através de planos de mitigação ou aceitá-lo mas, para isso, deve-se estar preparado

• Os planos de contingência devem ser colocados em prática apenas caso o risco torne-se uma realidade.

GRI 7 - Os riscos são analisados e a prioridade de aplicação dos recursos para o monitoramento desses riscos é determinada:

• Deve ser otimizados os recursos materiais e humanos para a execução das tarefas, para garantir que os riscos a serem tratados pela gerencia de riscos possam ser escolhidos a partir de uma analise onde descreve a prioridade para aplicação dos recursos

GRI 8 - As medições do risco são definidas, aplicadas e avaliadas para determinar mudanças na situação do risco e no progresso das atividades para seu tratamento:

• A estratégia de gerência de riscos deve ser seguida, garantindo que os riscos sejam monitorados e reavaliados periodicamente, e que os planos de mitigação e contingência estabelecidos sejam executados, quando necessário. Estes planos também devem ser revistos, pois alterações nos riscos podem demandar alterações nas ações de mitigação ou de contingência.

GRI 9 - Ações apropriadas são executadas para corrigir ou evitar o impacto do risco, baseadas na sua prioridade, probabilidade, conseqüência ou outros parâmetros definidos:

• Realizar a monitoria dos riscos encontrados.

• Ao longo das atividades de monitoramento deve ser verificada a necessidade da execução de ações de mitigação

• Garantir que estas ações sejam julgadas se necessárias, de acordo com na estratégia definida, e estas executadas até sua conclusão.
  

Gerência de Reutilização – GRU (evolução)

O propósito do processo Gerência de Reutilização é gerenciar o ciclo de vida dos ativos reutilizáveis.

No Nível C do MPS-BR, o processo de Gerencia de Reutilização deve ser executado, gerenciado, seus produtos de trabalho do processo Gerenciados, o processo é definido e implementado (alcançando finalmente o AP 3.2). Para alcançar esse nível, os seguintes itens devem ser atendidos:

AP 1.1 O processo é executado

• Para que o objetivo do processo seja seguido, todos os integrantes do projeto devem estar a par de suas tarefas, e

• Respeitando todas as regras para que nada errado seja armazenado e reutilizado de forma errada.

AP 2.1 O processo é gerenciado

• O processo deve ser gerenciado e supervisionado por uma pessoa que conheça todas as regras e os ativos para que nada se perca ao ser gravado de forma errônea, para que no futuro todas as informações sejam seguras, e a reutilização seja feita corretamente.

AP 2.2 Os produtos de trabalho do processo são gerenciados

• Os produtos dos trabalhos executados devem ser gerenciados por uma equipe, onde tem o objetivo de garantir os objetivos finais.

AP 3.1. O processo é definido

• A Empresa deve ter processos padrão que cubram todos os processos do MRMPS até o nível E, de forma a atender às necessidades dos projetos e da empresa. Como a Gerencia de Reutilização que poupa tempo e mantém um histórico de integridade de processos.

AP 3.2 O processo está implementado

• Será necessário definir o processo, armazenar suas medidas obtidas no repositório de medidas da empresa.
  
  

Dentro dessas itens, os seguintes artefatos estão relacionados:

Artefatos no OpenUP:

• Project Plan

• Architecture Notebook (apenas em alguns casos)

• Design (Documentação das Funcionalidades do Sistema)
  
  

Produzido no SolarSex: O projeto tem o Project Plan, porém, ele ainda não define como será feita a reutilização para receber o grau do Nível C.

Nem todas as ações necessárias para a completude desse item estão sendo implementadas. Então, a seguir, definimos estratégias de implantação para cada um dos itens necessários dentro do Nível C para o GRU, sendo cada item em negrito um dos resultados esperados do processo, e sua respectiva estratégia:

GRU 3 - Os dados de utilização dos ativos reutilizáveis são Registrados:

• A informação de uma determinada liberação do ativo deve ser registrada para manter um elo entre os produtores e consumidores.
  

• Este elo é importante para que notificações acerca do ativo sejam feitas, além de ser possível a observação da utilização dos ativos reutilizáveis, isto é, obter informações que caracterize alguma tendência ou comportamento específico deste procedimento.

• Após o levantamento inicial deve ser identificada a oportunidade de reutilização sistemática na organização, estabelecendo um programa de reutilização para desenvolver o produto a não tendo duplicidade de informações e reduzindo trabalho.

Nível B

Abaixo será descrito os processos do Nível B e os resultados esperados. O processo adotado é o GPR.

Gerencia de Projetos – GPR

 

O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. O propósito deste processo evolui à medida que a organização cresce em maturidade. No nível B a gerência de projetos passa a ter um enfoque quantitativo refletindo a alta maturidade que se espera da organização. Novamente alguns resultados evoluem e outros são incorporados.

GPR18 - (Nos níveis A e B) Os subprocessos mais adequados para compor o processo definido para o projeto são selecionados com base na estabilidade histórica, em dados de capacidade e em outros critérios previamente estabelecidos:

• Analisar um projeto que seja parecido com o projeto.

GPR 20 - (A partir do nível B) Os objetivos para a qualidade e para o desempenho do processo definido para o projeto são estabelecidos e mantidos:

• Levantar e mesclar as necessidades de qualidade do projeto com as diretivas locais e consolidar de forma única

GPR 21 - (A partir do nível B) Subprocessos do processo definido para o projeto e que serão gerenciados estatisticamente são escolhidos e são identificados os atributos por meio dos quais cada subprocesso será gerenciado estatisticamente:

• Selecionar os atributos dos subprocessos relevantes objetivando a qualidade e desempenho

GPR22 - (A partir do nível B) O projeto é monitorado para determinar se seus objetivos para qualidade e para o desempenho do processo serão atingidos. Quando necessário, ações corretivas são identificadas:

• Organizar reuniões com o cliente para o acompanhamento do projeto

GPR 23 - (A partir do nível B) O entendimento da variação dos subprocessos escolhidos para gerência quantitativa, utilizando medidas e técnicas de análise estatística previamente selecionadas, é estabelecido e mantido:

• Utilizar uma medida consistente e com uma coleta de dados simples e econômica, facilitando assim análises posteriores.

GPR 24 - (A partir do nível B) O desempenho dos subprocessos escolhidos para gerência uantitativa é monitorado para determinar a sua capacidade de satisfazer os seus objetivos para qualidade e para o desempenho. Ações são identificadas quando for necessário tratar deficiências dos subprocessos:

• Verificar se os subprocessos atendem as expectativas mínimas e as chances de atender seus
  objetivos. Caso seja detectada alguma inconsistência, tomar
  medidas corretivas

GPR 25 - (A partir do nível B) Dados estatísticos e de gerência da qualidade são incorporados ao repositório de medidas da organização:

• Guardar os dados do projeto para análise futura.

Nível A

Análise de Causas de Problemas e Resolução – ACP

ACP 1. Defeitos e outros problemas são registrados, identificados, classificados e selecionados para análise

AP 1.1 O processo é executado

• Implementar BugList onde os desenvolvedores mantenham registro dos erros.

AP 2.2 O processo é gerenciado

• Estão definidas as funções do Desenvolvedor e Testador

AP 3.1 O processo é definido

• Deve-se seguir o Plano Geral

AP3.2 O processo está implementado

• Existe a Lista de Risco como produto desta análise? Implementar.

AP 4.1 O processo é medido

• Manter métricas relativas a erros

AP 4.2 O processo é controlado

• Existem estimativas que funcionam?

AP 5.1 O processo é objeto de inovações

• Novas métricas

ACP 2. Defeitos e outros problemas são analisados para identificar sua causa raiz e soluções aceitáveis para evitar sua ocorrência futura;

AP 1.1 O processo é executado

• O Plano da Iteração deve ter algum conteúdo que tenha sido produto de uma análise de problemas

AP 2.2 O processo é gerenciado

• Estão definidas as funções do Analista e Gerente de Projeto?

AP 3.1 O processo é definido

• O Plano Geral deve contemplar a análise de defeitos, incluindo os momentos em que ela ocorre.

AP3.2 O processo está implementado

• Artefato como BUGZilla usado corriqueiramente.

AP 4.1 O processo é medido

• Existe uma métrica de qualidade do reuso de uma solução.

AP 4.2 O processo é controlado

• Os erros são corretamente estimados?

AP 5.1 O processo é objeto de inovações

• Deve existir boa comunicação entre os desenvolvedores e os gerentes

AP 5.2 O processo é otimizado continuamente

• Existe um plano de inovações por parte do gerente e do analista?
  
  

ACP 3. Ações para resolução do problema são selecionadas e implementadas;

AP 1.1 O processo é executado

• Documentação do código pelos desenvolvedores

AP 2.2 O processo é gerenciado

• Deve haver integração entre os papeis

AP 3.1 O processo é definido

• O Plano de Iteração identifica o momento do reuso de uma solução

AP3.2 O processo está implementado

• Existe um script de Testes?

AP 4.1 O processo é medido

• Existe uma estatística de reuso?

AP 4.2 O processo é controlado

• Existem metas de qualidade? Elas são próximas da realidade?

AP 5.1 O processo é objeto de inovações

• Os Testes são recriados?

AP 5.2 O processo é otimizado continuamente

• Reflexo na documentação do desenvolvedor
  
  

ACP 4. As ações implementadas para resolução de problemas são acompanhadas com medições, para verificar se as mudanças no processo corrigiram o problema e melhoraram o seu desempenho;

AP 1.1 O processo é executado

• A Estimativa ágil deve levar em conta o fator médio (variável) de eficiência na resolução do código

AP 3.1 O processo é definido

• Documentação sobre as métricas

AP 5.2 O processo é otimizado continuamente

• Métricas evoluem?

 

 

ACP 5. Dados das ações para análise de causas de problemas e resolução são armazenados para uso em situações similares.

AP 1.1 O processo é executado

• Existem componentes que podem armazenar essas ações. Seguem-se padrões de arquitetura?

AP 2.2 O processo é gerenciado

• Comunicação entre o Testador e o Gerente de Projeto

AP 4.2 O processo é controlado

• Plano de Risco

AP 5.1 O processo é objeto de inovações

• Plano de cada Iteração

AP 5.2 O processo é otimizado continuamente

• Arquitetura de componentes
  
  

Dentro de todos esses itens, os seguintes artefatos estão relacionados:

Artefatos no OpenUP:

• Project Plan

• Risk List

• Bug List

• Architecture Notebook

• Iteration Plan

Produzido no SolarSex: O projeto tem o Project Plan e a Risk List, porém, eles ainda não definem como será feita a Análise de Causas de Problemas e Resolução – ACP, para receber o grau do Nível A.

Conclusão

Comentarios (0)

RSS feed Comments

Nome

Email

Website

Titulo

Comentario