Atividade:
| ||||||||||||||||||||||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Uma vez por projeto. | |
| Papel: Gerente de Projeto | |
| Detalhamentos do Fluxo de Trabalho: |
Finalidade
|
Durante a Fase de Iniciação, você deve preparar as estimativas para o trabalho proposto no projeto (para obter uma discussão geral sobre a estimativa do projeto de software, consulte [BOE81], [PUT92] e [MCO96]). A estimativa do projeto de software baseia-se em uma matemática complexa. Portanto, você não encontrará aqui nenhuma informação técnica detalhada. A estimativa é um processo de quatro etapas:
Esta é a entrada principal para o processo de estimativa. Se você não puder estimar a grandeza do trabalho a ser feito, qualquer programação criada estará provavelmente longe da realidade. Existem duas abordagens para estimar o tamanho do software que pode ser usado no início do projeto: Dimensionamento por Analogia e Dimensionamento por Análise. É claro que, posteriormente no projeto (durante a fase de elaboração), você poderá preparar estimativas mais rigorosas (de baixo para cima), com base em uma Estrutura de Divisão do Trabalho detalhada do projeto.
Dimensionamento por Analogia
Ao estimar o escopo do projeto usando a abordagem Dimensionamento por Analogia, você compara o novo produto que estará desenvolvendo com os produtos (de tamanho conhecido) desenvolvidos em projetos anteriores. Você deve comparar as várias características dos produtos que estão sendo comparados, como o número de casos de uso de negócios, o número de atores, o tamanho/complexidade do banco de dados e, provavelmente, a quantidade de programas on-line e em lotes.
Comparando essas características, você poderá estimar o tamanho relativo do novo produto em relação aos antigos e, em seguida, poderá usar o tamanho conhecido do produto antigo para calcular o tamanho estimado do novo. Lembre-se de que é importante comparar os produtos de complexidade similar, desenvolvidos por meio de abordagens parecidas, já que as variações em itens, como o nível de detalhe em descrições de casos de uso, podem invalidar as comparações.
Dimensionamento por Análise
Posteriormente na fase de iniciação, é provável que você precise coletar informações suficientes sobre o novo produto para usar técnicas analíticas a fim de estimar o tamanho do produto. Essas técnicas baseiam-se em uma descrição funcional do produto de software que está sendo disponibilizado (por exemplo, Especificação dos Requisitos de Software, Documento de Arquitetura de Software) e aplicam regras de contagem padrão para determinar um tamanho com base nessas descrições. Provavelmente, a mais conhecida dessas técnicas é a Contagem de Pontos de Função, embora uma série de outras medidas tenha sido desenvolvida, incluindo os Pontos de Característica (uma modificação de Pontos de Função para aplicativos em sistemas de tempo real) e os Pontos de Objeto Previsto (uma métrica para sistemas orientados a objetos baseada em uma análise das complexidades e hierarquias de classe).
Além disso, também há artigos disponíveis na Central de Recursos do RUP que descrevem os métodos de estimativa de tamanho com base nos Casos de Uso. Ao usar esses artigos, você deve estar ciente de que, para fazer estimativas iniciais de tamanho com base nos Casos de Uso, você deve executar uma calibragem para adequar o estilo de Caso de Uso da organização, pois os Casos de Uso podem variar muito no nível de abstração e na maneira de expressão entre as organizações e, até mesmo, em uma mesma organização. Após a calibragem, é importante manter o estilo padrão selecionado para escrever Casos de uso, pois, do contrário, as estimativas de tamanho poderão ser completamente erradas.
Estimar o Esforço e Custo Totais do Projeto
O esforço total da equipe e a programação de um projeto podem ser calculados com base na estimativa de tamanho de produto, usando modelos científicos estabelecidos. Os dois modelos proeminentes em uso atualmente são o modelo de custo construtivo (COCOMO, COnstructive COst MOdel), desenvolvido por 
Barry Boehm, e a metodologia Putnam, de Larry Putnam. Os dois modelos foram validados com base nos dados do setor. Para obter mais informações sobre a última versão do COCOMO, consulte o site da Web COCOMOII.
Deixando de lado a entrada de tamanho, a outra entrada importante é uma métrica da produtividade da equipe. Esse valor determina o esforço geral do projeto. O programa total do projeto está relacionado de modo não linear ao esforço total. Infelizmente, os modelos são matematicamente complexos e, portanto, é melhor usar as ferramentas de software para auxiliar nos cálculos.
Aplicar Restrições e Prioridades
Quase todos os projetos estão sujeitos a algumas restrições (por exemplo, devem ser entregues em uma determinada data ou o custo não pode exceder R$850.000) ou prioridades (por exemplo, a urgência de um produto). Dado um tamanho fixo de produto, eles são afetados por ajustes no tamanho da equipe. Ele reporta que o relacionamento entre o tamanho da equipe e a programação não é linear. Portanto, você precisará usar os modelos científicos para gerar uma série de cenários com base nos tamanhos de equipe variáveis. O software de estimativa automatizado é muito útil para este exercício.
Selecionar a Estimativa Ideal de Programação, Esforço e Custo
Agora que você tem uma variedade de cenários para o projeto, revise e selecione o cenário que melhor se adapta às necessidades do projeto. Isso lhe dará uma visão inicial da duração geral do projeto conforme proposto e indicará o tamanho da equipe e o orçamento necessários.
Finalidade
|
O Plano de Desenvolvimento de Software define primeiro as datas e a natureza dos principais marcos (consulte Fases). Essa parte do Plano de Desenvolvimento de Software serve como "roteiro" para o projeto e é criada no início do projeto (fase de iniciação).
Para planejar as fases de um projeto no ciclo de desenvolvimento inicial, talvez seja necessário fazer algumas suposições disciplinadas sobre os marcos, tendo como base:
Usando estimativas com base nas suas próprias experiências em outros projetos de natureza similar, você cria o orçamento de projeto inicial alocando as partes apropriadas do esforço e os custos totais estimados para cada fase do projeto.
Para obter mais informações sobre como definir o tamanho e o número de iterações, consulte Diretrizes: Plano de Desenvolvimento de Software.
Finalidade
|
Cada marco está centrado em um produto liberado específico; cada um deles fornece um ponto de transição bem definido na próxima fase.
Fase |
Marco |
Finalidade |
| Iniciação | Objetivo do Ciclo de Vida | Engajar recursos no projeto |
| Elaboração | Arquitetura do Ciclo de Vida | Estabilizar a arquitetura do produto |
| Construção | Capacidade Operacional Inicial | Concluir o desenvolvimento do produto |
| Transição | Release do Produto | Implantar o produto com sucesso |
Cada marco representa um obstáculo crítico que o projeto deve transpor; em cada marco, o projeto se depara com uma decisão difícil.
Finalidade
|
Depois que o tamanho das fases do projeto for determinado, o número de iterações e seus respectivos tamanhos também precisarão ser especificados. Para obter mais informações sobre como definir o tamanho e o número de iterações, consulte Diretrizes: Plano de Projeto. Existem vários padrões de iteração que podem ser aplicados, dependendo do tipo de projeto, do domínio problemático e da inovação do domínio problemático (consulte também Conceitos: Iteração).
Cada iteração gera um produto liberado, um release (que é um produto executável utilizado para avaliar o andamento) e a qualidade. Como cada iteração tem um enfoque diferente, a funcionalidade e a abrangência do produto liberado da iteração variam. As metas da iteração devem ser específicas o suficiente para que seja possível avaliar, no final da iteração, se essas metas foram atingidas. Nas iterações iniciais, as metas são geralmente expressas em termos de riscos diminuídos. Nas iterações finais, as metas são expressas em termos de medidas de conclusão e qualidade funcionais.
Finalidade
|
No final da fase de iniciação, as fases podem ser planejadas de forma mais precisa, levando em consideração:
Esse plano simples é atualizado durante a fase de elaboração. Ele serve como base para a criação do restante do plano de projeto.
Finalidade
|
Com base nas estimativas de esforço e na programação de projeto derivada dessas estimativas, agora você pode definir os recursos necessários para a realização do projeto. Para cada fase/iteração, identifique quais papéis precisam ser envolvidos e quantos de cada um deles.
Finalidade
|
O Plano de Finalização do Projeto está documentado na Seção 5.6 Plano de Finalização do Plano de Desenvolvimento de Software. A Finalização do Projeto é a série de atividades realizadas para finalizar o projeto seqüencialmente, garantindo que quaisquer métricas e lições aprendidas serão capturadas para fins de referência futura.
O processo de finalização começa quando as seguintes condições forem atendidas:
Em primeiro lugar, liste o plano das atividades que você executará durante a finalização do projeto. Geralmente, essas atividades incluem:
Em seguida, identifique no plano quem será envolvido em cada uma das atividades de finalização.
Depois, defina a programação das atividades de finalização. Geralmente, esse detalhe é adicionado ao Plano de Desenvolvimento de Software no final do projeto.
|
Rational Unified Process
|
