Sistema de Paginação de Esportes Universitários
Plano de Desenvolvimento de Software
Versão 1.0
Histórico da Revisão
|
Data |
Versão |
Descrição |
Autor |
|---|---|---|---|
| 5 de outubro de 1999 | 1.0 | Liberação Inicial | Integração de Contexto |
A finalidade desse Plano de Desenvolvimento de Software é definir as atividades de desenvolvimento em termos de fases e iterações requeridas para implementar um Serviço de Paginação de Esportes Universitários para WebNewsOnLine.
Esse Plano de Desenvolvimento de Software descreve o plano geral a ser utilizado pela equipe para desenvolver o sistema. Os detalhes das iterações individuais serão descritos nos Planos de Iteração.
Nenhum.
Esse projeto implementará um sistema customizado para WebNewsOnline. Isso fornecerá a notificação do conteúdo atualizado aos assinantes via pagers, telefones celulares ou correio eletrônico. Em seguida, os assinantes conseguirão visualizar seus conteúdos customizados através da World Wide Web.
O sistema deve estar disponível em tempo para "March Madness" no ano 2000 (Torneio do Campeonato NCAA).
Os seguintes distribuíveis serão produzidos durante o projeto:
Esse plano será atualizado antes de ser o início de cada fase subseqüente ou iteração. As datas de término para o final de cada fase são mostradas abaixo.
A equipe do projeto para as fases Iniciais e de Elaboração será organizada da seguinte forma:
A equipe do projeto trabalhará com a equipe de Edição, a equipe de Anúncio e a equipe Representante de Campo para reunir os requisitos, revisar os protótipos e testar as diversas funções no sistema. O contato principal para WebNewsOnLine será Donna Cram, Diretor das Operações de Negócios.
A tabela a seguir mostra as funções representadas no diagrama do projeto acima e suas responsabilidades principais.
| Função | Responsabilidade |
|---|---|
| Gerente de Projeto | O Gerente de Projeto aloca os recursos, molda as prioridades, coordena as interações com os clientes e os usuários e geralmente tenta manter a equipe do projeto focada no objetivo correto. O Gerente de Projeto também estabelece um conjunto de práticas que assegura a integridade e a qualidade dos artefatos do projeto. |
| Arquiteto | O Arquiteto conduz e coordena as atividades técnicas e os artefatos através do projeto. O Arquiteto estabelece a estrutura geral para cada visualização arquitetônica: a decomposição da visualização, o agrupamento de elementos e as interfaces entre esses agrupamentos maiores. Portanto, em comparação a outros trabalhadores, a visualização do Arquiteto é uma amplitude e não uma profundidade. |
| Analista de Negócios | O analista de negócios conduz e coordena a modelagem de caso de uso de negócios, traçando e delimitando a organização sendo modelada. Por exemplo, estabelecendo quais casos de uso de negócios e de agentes de negócios existem e como eles se interagem. |
| Designer | O Designer define as responsabilidades, as operações, os atributos e os relacionamentos de uma ou várias classes e determina como eles devem ser ajustados para o ambiente de implementação. Além disso, o Designer pode ter a responsabilidade para um ou mais pacotes de design ou subsistemas de design, incluindo todas as classes de propriedade dos pacotes ou subsistemas. |
| Designer Criativo | O designer criativo conduz e coordena o protótipo e o design da interface da Web, capturando os requisitos na interface da Web, incluindo os requisitos de utilidade, construindo protótipos da página da Web Web, envolvendo outros envolvidos na interface da Web, como usuários finais, nas revisões de utilidade e sessões de teste de uso e revisando e fornecendo o feedback apropriado na implementação final da interface da Web (conforme criado por outros desenvolvedores; ou seja, designers e implementadores). |
| Testador | O Testador é responsável por executar o teste, incluindo a configuração e a execução do teste, a avaliação da execução do teste e a recuperação dos erros e avaliação dos resultados do teste e registro dos defeitos identificados |
| Especialista de Requisitos | O Especialista de Requisitos captura a especificação de uma parte da funcionalidade do sistema, descrevendo o aspecto de Requisitos de um ou vários casos de uso e outros requisitos de software de suporte. O Especialista de Requisitos também é responsável por um pacote de caso de uso e pela manutenção da integridade desse pacote. |
A fase Inicial desse projeto levará 3 semanas. As estimativas iniciais das fases subseqüentes podem ser vistas na seção 2.4 acima.
A fase Inicial do projeto pode ser visualizada da seguinte maneira:
|
Tarefa |
Início |
Fim |
|---|---|---|
| INICIAÇÃO | Sex 1/10/99 | Seg 25/10/99 |
| Começar Iniciação | Sex 1/10/99 | Sex 1/10/99 |
| Kick-off da Iniciação | Seg 4/10/99 | Qua 6/10/99 |
| Incluir as tarefas no plano do projeto para a tecnologia específica do projeto utilizando os cartuchos ContextWISE | Seg 4/10/99 | Seg 4/10/99 |
| Montar Quadro de Controle de Mudanças | Seg 4/10/99 | Ter 5/10/99 |
| Criar e Usar o Plano de Controle de Mudanças como Base | Ter 5/10/99 | Ter 5/10/99 |
| Obter Apresentação | Ter 5/10/99 | Ter 5/10/99 |
| Reunião de Kick-off da Iniciação | Ter 5/10/99 | Qua 6/10/99 |
| Preparar-se para Reunião de Kick-off da Iniciação | Ter 5/10/99 | Qua 6/10/99 |
| Suspender Reunião de Kick-off da Iniciação | Qua 6/10/99 | Qua 6/10/99 |
| Kick-off da Iniciação Concluído | Qua 6/10/99 | Qua 6/10/99 |
| Distribuíveis de Iniciação | Qua 6/10/99 | Qui 14/10/99 |
| Suspender Workshop de Requisitos | Qua 6/10/99 | Qui 7/10/99 |
| Visão do Projeto criada, revisada e terminada | Qua 6/10/99 | Qui 7/10/99 |
| Modelo de Caso de Uso Preliminar (10 a 20% concluído) criado e colocado sob o controle de revisão | Qui 7/10/99 | Seg 11/10/99 |
| Relatório Sintético de Uso Preliminar criado, revisado e terminado | Seg 11/10/99 | Ter 12/10/99 |
| Especificações Suplementares Preliminares criadas, revisadas e terminadas | Ter 12/10/99 | Ter 12/10/99 |
| Caso de Negócios criado, revisado e terminado | Ter 12/10/99 | Ter 12/10/99 |
| Glossário de Projeto Preliminar criado, revisado e terminado | Ter 12/10/99 | Ter 12/10/99 |
| Artigo de Design Criativo Preliminar criado, revisado e terminado | Qua 6/10/99 | Qui 7/10/99 |
| Mapa do Site Preliminar & Mapeamento de Navegação de Caso de Uso criado, revisado e terminado | Qui 7/10/99 | Sex 8/10/99 |
| Conceitos de Design Criativos criados, revisados e terminados | Sex 8/10/99 | Seg 11/10/99 |
| Plano de Conteúdo Preliminar criado, revisado e terminado (se aplicável) | Qua 6/10/99 | Qua 6/10/99 |
| Protótipo da Interface com o Usuário (opcional) criado, revisado e terminado | Qua 6/10/99 | Qua 6/10/99 |
| Relata o Protótipo (opcional) criado, revisado e terminado | Ter 12/10/99 | Qui 14/10/99 |
| Desenvolver Alternativas de Tecnologia Preliminar | Qua 6/10/99 | Qui 7/10/99 |
| Estabelecer contato com Gurus de Contexto apropriados | Ter 12/10/99 | Qua 13/10/99 |
| Plano de Transferência de Conhecimento Preliminar & Planejamento criado, revisado e terminado | Qua 13/10/99 | Qua 13/10/99 |
| Validar/Invalidar Hipótese da Proposta de Iniciação | Qua 13/10/99 | Qui 14/10/99 |
| Obter Apresentação | Qui 14/10/99 | Qui 14/10/99 |
| Distribuíveis de Iniciação Completos | Qui 14/10/99 | Qui 14/10/99 |
| Hand-off de Iniciação | Qui 14/10/99 | Seg 25/10/99 |
| Conduzir a Reunião de Verificação de Qualidade com o Cliente | Qui 14/10/99 | Qui 14/10/99 |
| Conduzir a Garantia de Qualidade | Qui 14/10/99 | Sex 15/10/99 |
| Suspender Reunião das Lições de Contexto Aprendidas | Qui 14/10/99 | Qui 14/10/99 |
| Primeiras estimativas de projeto criadas, revisadas e terminadas (+75%, -60%) | Qui 14/10/99 | Seg 18/10/99 |
| Plano de Entrega Iterativa do Projeto Completo criado, revisado e terminado | Seg 18/10/99 | Ter 19/10/99 |
| Criar proposta para Fase de Elaboração | Qui 14/10/99 | Sex 15/10/99 |
| Criar Log do Projeto de Software | Sex 15/10/99 | Sex 15/10/99 |
| Preparar para Ponto de Verificação de Iniciação | Sex 15/10/99 | Seg 18/10/99 |
| A equipe, inclusive o gerente de projetos do cliente, preencheu o formulário de apresentação inicial do trabalho | Seg 18/10/99 | Ter 19/10/99 |
| Fornecer proposta para Fase de Elaboração | Ter 19/10/99 | Qui 21/10/99 |
| Revisão do Ponto de Verificação de Iniciação e Decisão para Avançar/Não Avançar | Qui 21/10/99 | Sex 22/10/99 |
| Mover distribuíveis apropriados da Home page do Projeto para os Artefatos IAN | Sex 22/10/99 | Seg 25/10/99 |
| Iniciação Concluída | Seg 25/10/99 | Seg 25/10/99 |
O desenvolvimento do sistema será conduzido utilizando uma abordagem segmentada em que ocorrem várias iterações dentro de uma fase. As fases e a linha de tempo relativa são mostradas na tabela abaixo:
| Fase | Número 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 marcam o final de cada fase podem ser vistos na tabela abaixo.
| Descrição | Marco |
|---|---|
| Fase de Iniciação | A Fase Inicial desenvolverá os requisitos do produto e estabelecerá o caso de negócios para . Os principais casos de uso serão desenvolvidos bem como o Plano de Projeto de nível superior. Ao final da Fase Inicial, será decidido se é necessário financiar e continuar com o projeto com base no caso de negócios. O Marco de Revisão de Caso de Negócios ao final da fase marca a decisão para Avançar/Não Avançar para o projeto. |
| Fase de Elaboração | A Fase de Elaboração analisará os requisitos e desenvolverá o protótipo de arquitetura. Ao concluir a Fase de Elaboração, todos os casos de uso selecionados para a Liberação 1.0 terão concluído a análise e o design. Além disso, os casos de uso de alto risco para a Liberação 2.0 terão sido analisados e projetados. O protótipo de arquitetura testará a viabilidade e o desempenho da arquitetura necessária para a Liberação 1.0. O Marco do Protótipo de Arquitetura marca o fim da Fase de Elaboração. Esse protótipo significa a verificação dos principais componentes de arquitetura que constituem a Liberação R1.0. |
| Fase de Construção | Durante a Fase de Construção, os demais casos de uso serão analisados e projetados. A versão Beta para a Liberação 1.0 será desenvolvida e distribuída para avaliação. A implementação e as atividades de teste para suportar as liberações R1.0 e R2.0 serão concluídos. O Marco da Capacidade Operacional R2.0 marca o final da Fase de Construção. O software da Liberação 2.0 está pronto para o pacote. |
| Fase de Transição | A Fase de Transição preparará as liberações R1.0 e R2.0 para distribuição. Ela fornece o suporte requerido para assegurar uma instalação tranqüila, incluindo o treinamento do usuário. O Marco da Liberação R2.0 marca o final da Fase de Transição. Nesse ponto, todos os recursos, conforme definidos no Documento de Visão, serão instalados e ficarão disponíveis para os usuários. |
| Fase | Iteração | Descrição | Marcos Associados | Riscos Endereçados |
|---|---|---|---|---|
| Iniciação | Iteração Preliminar | Define o modelo de negócios, os requisitos do produto, o plano de projeto e o caso de negócios. | Revisão de Caso de Negócios | Esclarece os requisitos do usuário antecipadamente.
Desenvolve os planos realistas do projeto e o escopo. Determina a viabilidade do projeto a partir de um ponto de vista dos negócios |
| Fase de Elaboração | Desenvolver Protótipo de Arquitetura | Conclui análise & design para todos os casos de uso. Desenvolve o protótipo de arquitetura. | Protótipo de Arquitetura | Problemas de arquitetura esclarecidos.
Riscos técnicos mitigados. Antigo protótipo para revisão do usuário. |
| Fase de Construção | Iteração C1 - Desenvolvimento Beta | Implementar e testar os casos de uso para fornecer a Versão Beta. | Beta | Todos os principais recursos de um usuário e do
prospecto de arquitetura implementado no Beta.
Feedback do usuário anterior à liberação do software. |
| Iteração C2 - Desenvolver Liberação Inicial | Implementar e testar os casos de uso restantes, corrigir defeitos do Beta e incorporar o feedback do Beta.
Desenvolve o sistema inicial. |
Software | Software totalmente revisado pela comunidade de usuários.
A qualidade do produto deve ser alta. Defeitos minimizados. Custo da qualidade reduzidos. |
|
| Iteração C3 - Desenvolver Liberação Completa | Incorporar aprimoramentos e defeitos da
liberação inicial.
Desenvolve o sistema completo. |
Software | A liberação rápida endereça a satisfação do cliente.
Toda a funcionalidade principal fornecida no Sistema para Liberação completa. |
|
| Fase de Transição | Liberação do Software | Pacote, distribuição e Liberação de instalação. | Software Liberado |
Nesse momento específicos, foram planejadas duas liberações. A primeira deve ser concluída em tempo para March Madness e seu escopo será determinado durante a Fase de Elaboração. Toda funcionalidade restante será incluída em uma liberação subseqüente (se requerido).
O planejamento do projeto preliminar pode ser visto na seção 2.4. Os planos atualizados serão disponibilizados nas datas especificadas nessa seção
Os indivíduos desse projeto são fornecidos pela Integração de Contexto e são nomeados na seção 3.1.
Não Aplicável.
A equipe designada a esse processo possui habilidades apropriadas nesse ponto. Um Plano de Transferência de Conhecimentos será desenvolvido durante a Fase Inicial para assegurar que a equipe adquiriu as habilidades necessárias para suportar o sistema após a Fase de Transição.
O orçamento para a Fase Inicial é de $150.000,00. Um preço para a Fase de Elaboração será desenvolvido durante a Fase Inicial.
Esse documento contém o Plano de Iteração para a Iniciação. Os planos de iteração para as fases subseqüentes serão entregues ao final da fase precedente ou da iteração.
Consulte a referência [1].
Os relatórios de status do projeto serão emitidos semanalmente e incluirão detalhes de Rastreio do Marco para assegurar que o projeto continua em andamento. As alterações no planejamento serão escaladas para os patrocinadores do projeto, que então decidirão se é necessário alterar o escopo para preservar as datas de término.
Os relatórios de status do projeto serão emitidos semanalmente e incluirão detalhes de Rastreio do Marco para assegurar que o projeto continua em andamento. As alterações no planejamento serão escaladas para os patrocinadores do projeto, que então decidirão se é necessário alterar o escopo para preservar as datas de término.
As revisões formais serão executadas para cada design e subsistema de implementação. Isso garantirá que os objetos sob a revisão atenderão aos requisitos especificados.
Os relatórios semanais de status do projeto serão emitidos. Os relatórios de resumo da Fase e da Iteração também serão emitidos nos tempos apropriados.
O esforço e o tempo serão utilizados para rastrear o progresso do projeto. Os relatórios Planejados x Reais serão utilizados pelo gerente de projetos para medir o progresso.
Consulte a referência [2].
Ao final do projeto, uma reunião das Lições Aprendidas será retida para capturar as novas técnicas, ferramentas ou métodos. Os distribuíveis do projeto serão arquivados para o repositório e Knowledge Management para futura referência.
Consulte a referência [3].
As diretrizes padrão no RUP serão utilizadas.
Esse projeto será desenvolvido em um Centro de Solução de Contexto que possui servidores apropriados e software já instalados.
A ser desenvolvido.
Consulte a referência [3].
A ser desenvolvido.
Os documentos a serem desenvolvidos estão listados na referência [3].
Consulte a referência [3].
A ser desenvolvido.
N/D - nenhum subcontratante será utilizado.
Na conclusão de cada fase, uma sessão das Lições Aprendidas será retida para
capturar as melhorias para o processo.
Direitos Autorais 1987 - 2003 Rational Software Corporation