• Nenhum resultado encontrado

Planejamento de Projetos de Software

No documento Lista de Figuras (páginas 88-93)

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.

No documento Lista de Figuras (páginas 88-93)