|
Sistema de Mensagens do Collegiate Sports Plano de Desenvolvimento de Software Versão 1.0 Histórico da Revisão
Índice Analítico
Introdução
|
| Papel | Responsabilidade |
| Gerente de Projeto | O Gerente de Projeto aloca recursos, especifica prioridades, coordena as interações com os clientes e usuários e, geralmente, tenta manter a equipe de projeto centrada na meta correta. O Gerente de Projeto também estabelece um conjunto de práticas que garante a integridade e qualidade dos artefatos do projeto. |
| Arquiteto | O Arquiteto coordena as atividades técnicas e os artefatos no decorrer do projeto. O Arquiteto estabelece a estrutura geral de cada visão de arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces entre esses principais agrupamentos. Sendo assim, diferente dos outros trabalhadores, a visão do Arquiteto é de largura, e não de profundidade. |
| Analista do Negócio | O analista de negócio coordena a modelagem de casos de uso de negócios, descrevendo e delimitando a organização que está sendo modelada. Por exemplo, estabelecendo quais atores de negócio e casos de uso de negócio existem e como eles interagem. |
| Designer | O designer define as responsabilidades, as operações, os atributos e os relacionamentos de uma ou várias classes e determina como elas devem ser ajustadas ao ambiente de implementação. Além disso, o designer pode ser responsável por um ou mais pacotes de design ou subsistemas de design, incluindo quaisquer classes contidas nos pacotes ou subsistemas. |
| Designer Criativo | O designer criativo coordena a criação do protótipo e do design da interface da Web, capturando os requisitos dessa interface, inclusive os requisitos de usabilidade, criando protótipos de página da Web, engajando outros envolvidos da interface da Web, como os usuários finais, nas revisões de usabilidade e nas sessões de teste de uso, e revisando e fornecendo o feedback adequado na implementação final da interface da Web (conforme criada pelos outros desenvolvedores; ou seja, os designers e implementadores). |
| Testador | O Testador é responsável por executar os testes, o que inclui a execução e configuração dos testes, a avaliação da execução dos testes e a recuperação dos erros, por avaliar os resultados de teste e por registrar os defeitos identificados. |
| Especialista em Requisitos | O Especialista em Requisitos captura a especificação de uma parte da funcionalidade do sistema, descrevendo o aspecto Requisitos de um ou vários casos de uso e outros requisitos de suporte de software. O Especialista em Requisitos é responsável também por um pacote de caso de uso e por manter a integridade desse pacote. |
A fase de iniciação deste projeto dura três semanas. As estimativas iniciais das fases subseqüentes estão na seção 2.4 acima.
A fase de iniciação do projeto pode ser visualizada da seguinte maneira:
|
Tarefa |
Início |
End |
| INICIAÇÃO | Sex 01/10/99 | Seg 25/10/99 |
| Início da Fase de Iniciação | Sex 01/10/99 | Sex 01/10/99 |
| Kick-off da Fase de Iniciação | Seg 04/10/99 | Qua 06/10/99 |
| Adicionar tarefas ao plano de projeto para a tecnologia de projeto específica usando cartuchos ContextWISE | Seg 04/10/99 | Seg 04/10/99 |
| Formar Comitê de Controle de Mudança | Seg 04/10/99 | Ter 05/10/99 |
| Criar Plano de Controle de Mudança e Criar Sua Baseline | Ter 05/10/99 | Ter 05/10/99 |
| Finalização | Ter 05/10/99 | Ter 05/10/99 |
| Reunião de Kick-off da Fase de Iniciação | Ter 05/10/99 | Qua 06/10/99 |
| Preparar-se para a reunião de kick-off da fase de iniciação | Ter 05/10/99 | Qua 06/10/99 |
| Administrar Reunião de Kick-off da Fase de Iniciação | Qua 06/10/99 | Qua 06/10/99 |
| Kick-off da Fase de Iniciação Concluída | Qua 06/10/99 | Qua 06/10/99 |
| Produtos Liberados da Fase de Iniciação | Qua 06/10/99 | Qui 14/10/99 |
| Administrar Workshop de Requisitos | Qua 06/10/99 | Qui 07/10/99 |
| Visão de projeto criada, revisada e finalizada | Qua 06/10/99 | Qui 07/10/99 |
| Modelo de Casos de Uso Preliminar (10-20% completo) criado e colocado no controle de revisão | Qui 07/10/99 | Seg 11/10/99 |
| Relatório Sintético de Caso de Uso Preliminar criado, revisado e finalizado | Seg 11/10/99 | Ter 12/10/99 |
| Especificações Suplementares Preliminares criadas, revisadas e finalizadas | Ter 12/10/99 | Ter 12/10/99 |
| Caso de Negócio criado, revisado e finalizado | Ter 12/10/99 | Ter 12/10/99 |
| Glossário de Projeto Preliminar criado, revisado e finalizado | Ter 12/10/99 | Ter 12/10/99 |
| Resumo de Design Criativo Preliminar criado, revisado e finalizado | Qua 06/10/99 | Qui 07/10/99 |
| Site Preliminar e Mapeamento de Navegação de Casos de Uso criados, revisados e finalizados | Qui 07/10/99 | Sex 08/10/99 |
| Comps. de Design Criativo criados, revisados e finalizados | Sex 08/10/99 | Seg 11/10/99 |
| Plano de Conteúdo Preliminar criado, revisado e finalizado (se aplicável) | Qua 06/10/99 | Qua 06/10/99 |
| Protótipo de Interface de Usuário (opcional) criado, revisado e finalizado | Qua 06/10/99 | Qua 06/10/99 |
| Protótipo de Relatórios (opcional) criado, revisado e finalizado | Ter 12/10/99 | Qui 14/10/99 |
| Desenvolver Alternativas de Tecnologia Preliminares | Wed 10/6/99 | Qui 07/10/99 |
| Entrar em contato com os Conselheiros de Contexto apropriados | Ter 12/10/99 | Qui 13/10/99 |
| Programação do Plano de Transferência de Conhecimento & Preliminar criada, revisada e finalizada | Qui 13/10/99 | Qui 13/10/99 |
| Validar/invalidar suposição a partir da proposta da Iniciação | Qui 13/10/99 | Qui 14/10/99 |
| Finalização | Qui 14/10/99 | Qui 14/10/99 |
| Produtos Liberados da Fase de Iniciação Concluídos | Qui 14/10/99 | Qui 14/10/99 |
| Finalização da Fase de Iniciação | Qui 14/10/99 | Seg 25/10/99 |
| Administrar Reunião de Verificação de Qualidade com o Cliente | Qui 14/10/99 | Qui 14/10/99 |
| Administrar Garantia de Qualidade | Qui 14/10/99 | Sex 15/10/99 |
| Administrar Reunião das Lições de Contexto Aprendidas | Qui 14/10/99 | Qui 14/10/99 |
| Primeiras estimativas de projeto criadas, revisadas e finalizadas (+75%, -60%) | Qui 14/10/99 | Seg 18/10/99 |
| Plano Completo de Entrega Iterativa do Projeto criado, revisado e finalizado | Seg 18/10/99 | Ter 19/10/99 |
| Criar proposta para fase de elaboração | Qui 14/10/99 | Sex 15/10/99 |
| Criar Registro do Projeto do Software | Sex 15/10/99 | Sex 15/10/99 |
| Preparar-se para Ponto de Verificação da Iniciação | Sex 15/10/99 | Seg 18/10/99 |
| A equipe, incluindo o gerente de projeto do cliente, deve preencher o formulário de finalização do release de trabalho | Seg 18/10/99 | Ter 19/10/99 |
| Proposta de Entrega da Fase de Elaboração | Ter 19/10/99 | Qui 21/10/99 |
| Revisão do ponto de verificação da Iniciação e decisão que informará se o projeto será ou não levado adiante | Qui 21/10/99 | Sex 22/10/99 |
| Mover os produtos liberados apropriados de Project Homepage para IAN Artifacts | Sex 22/10/99 | Seg 25/10/99 |
| Iniciação Concluída | Seg 25/10/99 | Seg 25/10/99 |
O desenvolvimento será conduzido usando uma abordagem com fases onde várias iterações ocorrem dentro de uma fase. As fases e a linha de tempo relativa são mostradas na tabela a seguir:
| Fase | No. de Iterações | Início | Fim |
| Fase de Iniciação | 1 | Semana 1 | Semana 4 |
| Fase de Elaboração | 1 | Semana 5 | Semana 11 |
| Fase de Construção | 3 | Semana 12 | Semana 27 |
| Fase de Transição | 1 | Semana 28 | Semana 31 |
Os marcos que indicam o fim de cada fase podem ser vistos na tabela a seguir.
| Descrição | Marco |
| Fase de Iniciação | A fase de Iniciação desenvolverá os requisitos do produto e estabelecerá o caso de negócio. Os principais casos de uso serão desenvolvidos, bem como o Plano de Projeto de nível superior. No final da Fase de Iniciação, será decidido se o projeto será custeado e levado adiante com base no caso de negócio. O Marco de Revisão de Caso de Negócio, no final da fase, informará se o projeto será ou não levado adiante. |
| Fase de Elaboração | A Fase de Elaboração analisará os requisitos e desenvolverá o protótipo de arquitetura. Após concluir a Fase de Elaboração, todos os casos de uso selecionados para o Release 1.0 terão análise e design completos. Além disso, os casos de uso de alto risco do Release 2.0 já estarão analisados e projetados. O protótipo de arquitetura testará a viabilidade e o desempenho da arquitetura necessários para o Release 1.0. O Marco de Protótipo de Arquitetura indica o final da Fase de Elaboração. Este protótipo representa a verificação dos principais componentes da arquitetura que compõem o Release R1.0. |
| Fase de Construção | Durante a Fase de Construção, os casos de uso restantes serão analisados e projetados. A versão Beta do Release 1.0 será desenvolvida e distribuída para fins de avaliação. As atividades de implementação e teste que suportarão os releases R1.0 e R2.0 serão concluídas. O Marco de Capacidade Operacional do R2.0 indica o final da fase de construção. O Release 2.0 do software está pronto para ser empacotado. |
| Fase de Transição | A fase de transição preparará os releases R1.0 e R2.0 para distribuição. Ela fornece o suporte necessário para garantir uma instalação sem problemas, incluindo o treinamento do usuário. O Marco do Release R2.0 indica o final da fase de transição. Neste ponto, todos os recursos, conforme definido no Documento de Visão, são instalados e disponíveis para os usuários. |
| Fase | Iteração | Description | Marcos Associados | Riscos Abordados |
| Iniciação | Iteração Preliminar | Define o modelo de negócio, os requisitos do produto, o plano do projeto e o caso de negócio. | Revisão do Caso de Negócio | Esclarece os requisitos do usuário primeiro.
Desenvolve planos e escopo realísticos para o projeto. Determina a viabilidade do projeto do ponto de vista do negócio |
| Fase de Elaboração | Desenvolve o Protótipo de Arquitetura | Conclui a análise e o design de todos os casos de uso. Desenvolve o protótipo de arquitetura. | Protótipo de Arquitetura | As questões de arquitetura são esclarecidas.
Os riscos técnicos são diminuídos. Protótipo inicial para revisão do usuário. |
| Fase de Construção | Iteração C1 - Desenvolver Beta | Implementar e testar casos de uso para fornecer a versão Beta Version. | Beta | Todas as características principais de um possível usuário e arquitetura
implementadas na Versão Beta.
Feedback do usuário antes do release do software. |
| Iteração C2 - Desenvolver Release Inicial | Implementar e testar os casos de uso restantes, corrigir os
defeitos a partir da Versão Beta e incorporar o feedback a partir dessa versão.
Desenvolve o sistema inicial. |
Software | Software completamente revisado pela comunidade de usuários.
A qualidade do produto deve ser alta. Defeitos minimizados. Custo de qualidade reduzido. |
|
| Iteração C3 - Desenvolver o release completo | Incorporar aperfeiçoamentos e defeitos a partir do
release inicial.
Desenvolve o sistema completo. |
Software | Um release rápido satisfaz o cliente.
A principal funcionalidade fornecida no Sistema pelo Release completo. |
|
| Fase de transição | Release de software | Empacotar, distribuir e instalar Release. | Software liberado |
Neste ponto, dois releases estarão planejados. O primeiro deve ser concluído em tempo para o March Madness e seu escopo será determinado durante a fase de elaboração. Qualquer funcionalidade restante será incluída em um release subseqüente (se necessário).
A programação de projeto preliminar está na seção 2.4. Os planos atualizados serão disponibilizados nas datas especificadas nessa seção
Os participantes deste projeto são fornecidos pela Integração de Contexto e são nomeados na seção 3.1.
Não Aplicável.
A equipe atribuída a este projeto possui habilidades apropriadas neste ponto do processo. Um Plano de Transferência de Conhecimento será desenvolvido durante a fase de iniciação para garantir que a equipe possui as habilidades necessárias para suportar o sistema após a fase de transição.
O orçamento da fase de iniciação é de $150,000.00. Um valor para a fase de elaboração será desenvolvido durante a fase de iniciação.
Este documento contém o Plano de Iteração da Iniciação. Os planos de iteração das fases subseqüentes serão entregues no final da fase ou iteração anterior.
Consulte referência [1].
Os relatórios de status de projeto será emitidos semanalmente e incluirão os detalhes do Rastreamento de Marco para garantir que o processo continuará normalmente. As mudanças feitas na programação serão encaminhadas aos responsáveis pelo projeto, que decidirão se o escopo deve ser alterado para preservar as datas de término previstas.
Os relatórios de status do projeto serão emitidos semanalmente e incluirão os detalhes do Rastreamento de Marco para garantir que o projeto continuará normalmente. As mudanças na programação serão encaminhadas aos responsáveis pelo projeto, que decidirão se o escopo deve ser alterado para preservar as datas de término previstas.
As revisões formais serão executadas para cada subsistema de design e de implementação. Isso garantirá que os objetos em revisão atenderão aos requisitos especificados.
Os relatórios de status do projeto serão emitidos semanalmente. Os relatórios resumidos de fase e iteração também serão emitidos nos momentos apropriados.
O esforço e tempo serão usados para rastrear o andamento do projeto. Os relatórios planejados versus reais serão usados pelo gerente de projeto para avaliar o andamento.
Consulte referência [2].
No final do projeto, a reunião de Lições Aprendidas será administrada para capturar novas técnicas, ferramentas e métodos. Os produtos liberados do projeto serão arquivados no repositório de Gerenciamento de Conhecimento para referência futura.
Consulte referência [3].
As diretrizes padrão do RUP serão usadas.
Este projeto será desenvolvido em uma central de solução de contexto que possui servidores e softwares apropriados já instalados.
A ser desenvolvido.
Consulte referência [3].
A ser desenvolvido.
Os documentos a serem desenvolvidos estão listados na referência [3].
Consulte referência [3].
A ser desenvolvido.
N/D - não serão utilizados subcontratantes.
Após a conclusão de cada fase, uma sessão de Lições Aprendidas será administrada para
capturar melhorias para o processo.
