5 Avaliando RUP Baseado no CMM
5.2 Áreas-Chave do CMM - Nível 2
5.2.2 Planejamento de Projetos de Software
(2/3) As atividades para gerenciamento dos requisitos alocados são revisadas periodicamente e em determinados eventos com o gerente de projeto.
O Gerente do Projeto faz avaliações periódicas do status do projeto e estas são documentadas na Avaliação de Status.
(3/3) O grupo de qualidade de software revisa e/ou audita as atividades e os produtos de trabalho para gerenciar os requisitos alocados e informa os resultados.
RUP descreve a elaboração de um Plano de Garantia de Qualidade, pelo Gerente do Projeto. Neste plano devem ser descritas todas as informações necessárias para realizar as atividades de garantia de qualidade para o projeto. O plano é usado para planejar as revisões e as auditorias que verificarão se processo definido para o projeto está sendo seguido corretamente.
O RUP recomenda que a Autoridade de Processo de Engenharia de Software (APES) deva ter responsabilidade pelos aspectos de qualidade e conduza as revisões e auditorias, descritas no Plano de Garantia de Qualidade.
Resumo da Avaliação
A macro-atividade de Requisitos do RUP, descreve a seqüência de atividades que devem ser executadas para gerenciar os requisitos do sistema, e como devem ser realizadas alterações nestes requisitos.
Os requisitos do sistema são documentados na Especificação dos Requisitos do Software, e os requisitos não-técnicos são documentados na Solicitação dos Interessados e na Visão. RUP descreve no Plano de Medição, as medidas relacionadas a requisitos.
O Conselho de Controle de Alteração é responsável por aprovar e revisar as alterações propostas nos requisitos. Revisor de Requisitos revisa os requisitos do software, e as verificações de implementação são realizadas pelo Revisor de Projeto, Gerente de Projeto e APES.
As atividades e compromissos do projeto de software são planejados e documentados.
Meta 3/3
Grupos e pessoas envolvidas concordam com seus compromissos relacionados ao projeto de software.
Características-comum Compromisso de Executar
(1/2) Um gerente de projeto de software é responsável por negociar compromissos e por desenvolver o plano de desenvolvimento do projeto de software.
RUP descreve o papel Gerente de Projeto, o que é responsável por negociar compromissos e desenvolver o Plano de Desenvolvimento de Software (PDS), dentre outras atividades.
(2/2) O projeto segue uma política organizacional para planejar um projeto de software.
RUP descreve na macro-atividade de Gerenciamento de Projetos, as atividades que devem ser executadas para planejar o projeto, os artefatos que devem ser gerados e os cargos associados a cada atividade.
O Caso de Desenvolvimento, elaborado pelo Engenheiro de Processo, no início do projeto, adapta as atividades descritas pelo RUP para um projeto específico.
Habilidade para Executar
(1/4) Uma declaração aprovada e documentada de trabalho existe para o projeto de software.
O artefato Visão, descreve a visão geral dos requisitos do projeto, e provê a base contratual para os requisitos técnicos, e o Caso de Negócio descreve uma análise econômica do projeto. Estes artefatos são revisados pelo Revisor do Projeto, e são gerenciados e controlados.
(2/4) Responsabilidades para desenvolver o plano de desenvolvimento de software estão determinadas.
O RUP descreve os cargos associados a cada atividade e o Plano de Iteração assinala a responsabilidade a pessoa que ocupa o cargo. A elaboração do Plano de Desenvolvimento de Software, segundo o RUP, é de responsabilidade do Gerente de Projeto.
(3/4) Estão disponíveis os recursos e fundos necessários para planejar o projeto de software.
Essa prática-chave não é englobada pelo RUP. A proposta 1, descrita no capítulo 6, propõe uma alteração no RUP buscando satisfazer essa prática-chave.
(4/4) Os gerentes de software, engenheiros de software, e outros indivíduos envolvidos no planejamento são treinados em procedimentos de planejamento e estimativas aplicáveis em suas áreas de responsabilidades.
O RUP não cobre essa prática-chave, no capítulo 6 é descrita a macro-atividade de Treinamento, que propõe uma alteração no RUP para satisfazer essa prática-chave.
Atividades Executadas
(1/15) O grupo de engenharia de software participa da equipe que propõe o projeto.
O grupo de engenharia de software é composto por trabalhadores com diferentes perfis que participam desde a proposta do projeto até a implantação .
(2/15) O planejamento do projeto de software é iniciado nos estágios iniciais, e em paralelo com o planejamento completo do projeto.
Não se aplica, o escopo do Processo Unificado Rational limita-se a gerenciamento de projetos de software.
(3/15) O grupo de engenharia de software participa, com outros grupos afetados, no planejamento global do projeto ao longo do ciclo de vida do projeto.
Não se aplica, o escopo do Processo Unificado Rational limita-se a gerenciamento de projetos de software.
(4/15) Os compromissos do projeto de software, feitos a indivíduos e grupos externos à organização, são revisados com o gerenciamento sênior de acordo com o procedimento documentado.
Os compromissos do projeto, tais como: orçamento, cronograma e recursos, são documentados no Plano de Desenvolvimento de Software, que é revisado pelo Revisor do Projeto, conforme procedimento descrito na atividade Revisar Planejamento do Projeto.
(5/15) O ciclo de vida do software com estágios pré-definidos e de tamanho gerenciável é identificado e definido.
O RUP propõe um ciclo de vida iterativo e incremental. O projeto é dividido em iterações sucessivas para facilitar seu gerenciamento, diminuir os riscos e acelerar seu desenvolvimento. O Caso de Desenvolvimento descreve o ciclo de vida específico para o projeto, considerando o número de iterações do projeto e a duração de cada iteração e fase.
(6/15) O plano de desenvolvimento de software do projeto é desenvolvido conforme um procedimento documentado.
O Plano de Desenvolvimento de Software é desenvolvido de acordo com os procedimentos descritos na atividade Desenvolver Plano de Desenvolvimento de Software, da macro-atividade de Gerenciamento de Projetos.
(7/15) O plano para o projeto de software é documentado.
O plano de projeto de software é documentado no artefato Plano de Desenvolvimento de Software. Os procedimentos, métodos e padrões de desenvolvimento são documentados e mantidos no Caso de Desenvolvimento.
(8/15) Produtos de trabalho de software que são necessários para estabelecer e manter o controle do projeto de software são identificados.
O RUP identifica artefatos que serão desenvolvidos para controlar o projeto no Caso de Desenvolvimento.
(9/15) Estimativas de tamanho dos produtos de trabalho de software (ou mudanças no tamanho dos produtos de software) são derivados conforme um procedimento documentado.
Segundo o RUP, o tamanho dos produtos e alterações pode ser estimado por analogia ou análise. Na estimativa de tamanho por analogia, o novo produto que será desenvolvido é comparado com produtos desenvolvidos anteriormente. Várias características do produto podem ser comparadas como: número de casos de uso, número de atores, tamanho/complexidade da base de dados, número de programas online e batch [RAT 2001].
Quando se têm mais informações sobre o produto, é possível utilizar técnicas analíticas para estimar o tamanho do produto. Estas técnicas se baseiam na descrição funcional do produto de software e na aplicação de regras de contagem padrão, para determinar medidas de tamanho para estas descrições. Como exemplo, pode-se citar pontos por função, pontos por casos de uso, etc [RAT 2001].
Os procedimentos para estimar tamanho são descritos na atividade Planejar Fases e Iterações, da macro-atividade de Gerenciamento de Projetos. As estimativas devem ser documentadas no Plano de Desenvolvimento de Software.
(10/15) Estimativas de esforço e custos do projeto são derivadas conforme um procedimento documentado.
O RUP sugere o uso de modelos científicos já estabelecidos para estimar esforço e custos de um projeto, tais como: o Constructive Cost Model (COCOMO), desenvolvido por Barry Boehm, e da Putnam Methodology de Larry Putnam [RAT 2001].
Os dados históricos dos projetos são armazenados no artefato Medidas dos Projetos.
(11/15) Estimativas de recursos computacionais críticos para o projeto são derivados conforme um procedimento documentado.
RUP não descreve procedimentos para estimar recursos computacionais críticos. A proposta 2, descrita no capítulo 6 deste trabalho, propõe como essa atividade pode ser realizada.
(12/15) O cronograma de software do projeto é derivado de acordo com um procedimento documentado.
O cronograma de software é um dos elementos constituintes do Plano de Desenvolvimento de Software, e sua elaboração é descrita na atividade Planejar Fases e Iterações, da macro-atividade de Gerenciamento de Projetos.
O cronograma é revisado na atividade Revisar Planejamento do Projeto, da macro-atividade de Gerenciamento de Projeto, e acompanhado nos marcos do projeto.
(13/15) Os riscos de software associados com os custos, recursos, cronograma e aspectos técnicos do projeto são identificados, estimados e documentados.
O Plano de Gerenciamento de Riscos, englobado pelo PDS, especifica como gerenciar riscos associados ao projeto e inclui uma lista de riscos conhecidos, associados com ações de suavização e contingência.
(14/15) Planos para infra-estrutura de engenharia de software do projeto e ferramentas de suporte são preparados.
Na macro-atividade de Ambiente é desenvolvido o Caso de Desenvolvimento. Este artefato descreve, entre outros, as ferramentas de apoio às atividades, guias de como usar as ferramentas, e modelos específicos por ferramentas.
RUP falha na revisão dos planos por todos os grupos interessados.
(15/15) Dados do planejamento do software são registrados.
Os dados do planejamento são registrados no Plano de Desenvolvimento de Software, e o acompanhamento é registrado na Avaliação do Status e no Registro de Revisão. Os dados do planejamento são registrados e controlados por meio dos procedimentos descritos na macro-atividade de Gerenciamento de Configuração e Alteração. Os dados históricos são armazenados no artefato Medidas dos Projetos.
Medição e Análise
(1/1) Medições são feitas e usadas para determinar o status das atividades de planejamento de software.
Na atividade Definir Processos de Controle e Monitoramento, são descritos indicadores e processos usados para monitorar e controlar o progresso, qualidade e riscos do projeto.
Verificação da Implementação
(1/3) As atividades para planejamento do projeto de software são revisadas periodicamente junto à gerência sênior.
As atividades de planejamento são revisadas de acordo com o PDS, em pontos pré-definidos, que são os marcos de conclusão de iterações (marcos menores) e de fases (marcos maiores), pelo Revisor do Projeto.
(2/3) As atividades para planejamento do projeto são revisadas periodicamente e em determinados eventos com o gerente de projeto.
O Gerente de Projeto faz avaliações periódicas do status do projeto e estas são documentadas na Avaliação de Status.
(3/3) O grupo de garantia da qualidade de software revisa e/ou audita as atividades e produtos de trabalho de software para o planejamento do projeto de software e informa os resultados.
RUP descreve a elaboração de um Plano de Garantia de Qualidade, pelo Gerente do Projeto. Neste plano devem ser descritas todas as informações necessárias para realizar as atividades de garantia de qualidade para o projeto. O plano é usado para planejar as revisões e auditorias que verificarão se processo definido para o projeto está sendo seguido corretamente.
O RUP recomenda que a Autoridade de Processo de Engenharia de Software (APES) deva ter responsabilidade pelos aspectos de qualidade e conduza as revisões e auditorias, descritas no Plano de Garantia de Qualidade.
Resumo da Avaliação
RUP descreve na macro-atividade de Gerenciamento de Projetos, as atividades que devem ser executadas para planejar o projeto, dentre elas cita-se: Desenvolver Plano de Desenvolvimento de Software, Planejar Fases e Iterações, Revisar Planejamento do Projeto e Definir Processos de Controle e Monitoramento. O RUP propõe um ciclo de vida iterativo e incremental.
O artefato Plano de Desenvolvimento de Software (PDS) descreve o planejamento do projeto, a Visão descreve a visão geral dos requisitos do projeto, o Caso de Negócio descreve uma análise econômica do projeto, o Plano de Gerenciamento de Riscos descreve os riscos associados ao projeto, o Caso de Desenvolvimento descreve os planos de infra-estrutura e as ferramentas, a Avaliação de Status descreve os dados de acompanhamento e o Registro de Revisão descreve o resultado da revisão.
O Gerente de Projeto, é responsável por negociar compromissos e desenvolver o PDS. Os dados históricos dos projetos são armazenados no artefato Medidas dos Projetos.
As verificações de implementação são realizadas pelo Revisor de Projeto, Gerente de Projeto e APES.