Plano de Desenvolvimento de Software
Versão 1.0
Histórico da Revisão
|
Data |
Versão |
Descrição |
Autor |
|---|---|---|---|
|
15/Jan/99 |
1.0 |
Versão inicial |
Rick Bell |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1.3 Definições, Acrônimos e Abreviações
2.1 Propósito, Escopo e Objetivos do Projeto
2.3 Produtos de Trabalho do Projeto
2.4 Evolução do Plano de Desenvolvimento de Software
3.3 Funções e Responsabilidades
4.2.5.2 Plano de Aquisição de Recursos
4.4 Monitoramento e Controle do Projeto
4.4.1 Plano de Gerenciamento de Requisitos
4.4.2 Plano de Controle de Planejamento
4.4.3 Plano de Controle de Orçamento
4.4.4 Plano de Controle de Qualidade
4.5 Plano de Gerenciamento de Riscos
5.2 Métodos, Ferramentas e Técnicas
5.4 Plano de Aceitação de Produto
6. Planos de Processo de Suporte
Plano de Desenvolvimento de Software
O objetivo deste Plano de Desenvolvimento de Software é definir as atividades de desenvolvimento em termos das fases e iterações requeridas para implementar um sistema de registro em classe computadorizado para o Wylie College.
Este Plano de Desenvolvimento de Software descreve o plano geral
a ser utilizado pelo departamento de Sistemas de Informações do Wylie College para o desenvolvimento do
C-Registration System para o Wylie College. Os detalhes das iterações
individuais serão descritos nos Planos de Iteração.
Os planos descritos neste documento têm como base os requisitos de produto
definidos no Documento de Visão [1].
Consulte o Glossário [4].
As referências aplicáveis são:
Este Plano de Desenvolvimento de Software contém as seguintes informações:
Visão Geral do Projeto - fornece uma descrição do propósito, escopo e objetivos do projeto. Também define os produtos de trabalho que o projeto espera fornecer.
Organização do Projeto - descreve a estrutura organizacional da equipe do projeto.
Processo de Gerenciamento - explica o custo e o planejamento estimados, define as principais fases e marcos para o projeto e descreve como o projeto será monitorado.
Planos do Processo Técnico - fornece uma visão geral do processo de desenvolvimento de software, incluindo métodos, ferramentas e técnicas a serem seguidos.
Planos do Processo de Suporte - inclui o plano de gerenciamento de configuração.
Este Plano de Desenvolvimento de Software descreve o plano geral a ser utilizado pelo departamento de Sistemas de Informações do Wylie College para o desenvolvimento do C-Registration System para o Wylie College. Os detalhes das iterações individuais serão descritos nos Planos de Iteração.
Os planos descritos neste documento têm como base os requisitos de produto definidos na Visão [1].
O sistema foi planejado para ser o principal meio de registro de estudantes para o período do inverno de 1999. Como o registro em cursos começa em 1º de agosto de 1999, o sistema deve estar totalmente disponível até essa data.
Os seguintes produtos de trabalho serão produzidos durante o projeto e entregues para a organização de manutenção.
Outros produtos de trabalho serão produzidos, conforme descrito no caso de desenvolvimento do projeto, mas não foram projetados para serem entregues para a organização de manutenção.
O Plano de Desenvolvimento de Software será revisado antes do início de cada fase de Iteração.
O Coordenador de Projeto fornecerá a Avaliação do Status, conforme planejado, para o Executivo de TI envolvido (consulte a Visão [1]).
A equipe do projeto também irá interagir com outros envolvidos para solicitar entradas e revisar produtos de trabalho relevantes.
A tabela a seguir identifica as unidades organizacionais que serão responsáveis por cada uma das disciplinas, atividades e processos de suporte.
| Função |
Responsabilidade |
|---|---|
|
Coordenador de Projeto |
Conforme descrito no Rational Unified Process [6]. Responsável pelo gerenciamento da disciplina geral de Gerenciamento de Projeto. Lidera a Equipe de Gerenciamento de Projeto estendida. |
| Engenheiro de Processo | Responsável pelo ambiente de projeto e por fornecer o suporte relacionado ao processo para as equipes no projeto, conforme definido na disciplina Ambiente no Rational Unified Process. Participa em uma Equipe de Gerenciamento de Projeto estendida. |
| Gerenciador de Configuração / Gerenciador de Controle de Mudanças | Responsável pelo Controle da Configuração no projeto e pelo exercício do Processo de Controle de Mudanças do Wylie College no projeto. Participa em uma Equipe de Gerenciamento de Projeto estendida. |
|
Liderança de Equipe de Engenharia de Sistemas |
Liderar a equipe primordialmente responsável pelo gerenciamento das disciplinas de Modelagem de Negócios e Requisitos. Participa em uma Equipe de Gerenciamento de Projeto estendida. |
|
Liderança de Equipe de Engenharia de Software |
Primordialmente responsável pelas disciplinas de Análise, Design e Implementação. Participa em uma Equipe de Gerenciamento de Projeto estendida. |
|
Liderança de Equipe de Teste |
Liderar a equipe responsável pelo gerenciamento da disciplina de Teste. Participa em uma Equipe de Gerenciamento de Projeto estendida. |
| Liderança de Equipe de Implantação | Liderar a equipe responsável pelas atividades de instalação e infra-estrutura no ambiente do usuário final. Participa em uma Equipe de Gerenciamento de Projeto estendida. |
As estimativas do projeto têm como base o Relatório de Análise e Modelo de Custos do C-Registration System [7].
O Sistema de Registro em Cursos é semelhante em complexidade e arquitetura ao Sistema de Biblioteca On-line, construído pelo Wylie College em 1997. O banco de dados do sistema de registro em cursos é aproximadamente 25% mais complexo, e o número e a complexidade dos casos de uso sugerem que o sistema será aproximadamente 20% mais complexo de forma geral. As estimativas de prazo e esforço desse relatório são a base do orçamento e do planejamento do projeto.
Uma Estrutura de Análise de Trabalho está sendo preparada e será fornecida na próxima versão deste documento.
O desenvolvimento do C-Registration System será conduzido utilizando uma abordagem em fases em que múltiplas iterações ocorrem em uma fase. As fases e iterações neste plano não são sobrepostas. Um resumo da linha de tempo relativa é mostrado na tabela a seguir:
|
Fase |
Número de Iterações |
Encerramento |
|---|---|---|
|
Fase de Iniciação |
1 |
Semana 7 |
|
Fase de Elaboração |
1 |
Semana 14 |
|
Fase de Construção |
1 |
Semana 19 |
|
Fase de Transição |
4 |
Semana 32 |
Tabela 4.2.1 Resumo da Linha de Tempo Relativa
A tabela 4.2.2 descreve cada fase e os principais marcos da conclusão da fase.
| Fase |
Descrição |
Marco |
|---|---|---|
|
Fase de Iniciação |
A Fase de Iniciação irá desenvolver os requisitos do produto e estabelecer o caso de negócios para o C-Registration System. Os principais casos de uso serão desenvolvidos, bem como o Plano de Desenvolvimento de Software de nível alto. No final da Fase de Iniciação, o Wylie College decidirá se irá financiar e continuar com o projeto com base no caso de negócios. |
O Marco de Revisão do Caso de Negócios no final da fase marca a decisão Aprovado/Não Aprovado para o projeto. |
|
Fase de Elaboração |
A Fase de Elaboração analisará os requisitos e desenvolverá o protótipo de arquitetura. Na conclusão da Fase de Elaboração, todos os casos de uso selecionados para o Release 1.0 terão concluído a análise e o design. Além disso, os casos de uso de alto risco para o Release 2.0 terão sido analisados e projetados. O protótipo de arquitetura testará a possibilidade e o desempenho da arquitetura requerida para o Release 1.0. |
O Marco do Protótipo de Arquitetura marca o final da Fase de Elaboração. Esse protótipo significa a verificação dos principais componentes de arquitetura que compõem o Release R1.0. |
|
Fase de Construção |
Durante a Fase de Construção, os casos de uso remanescentes serão analisados e projetados. A versão Beta do Release 1.0 será desenvolvida e distribuída para avaliação. As atividades de implementação e teste para suportar os releases R1.0 e R2.0 serão concluídas. |
O Marco de Capacidade Operacional Inicial (conclusão do beta) marca o final da Fase de Construção. |
|
Fase de Transição |
A versão Beta do Release 1.0 será distribuída e avaliada. A Fase de Transição irá 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 de usuários. |
O Marco Release R2.0 marca o final da Fase de Transição. Nesse ponto, todos os recursos, conforme definido no Documento de Visão [1], estarão instalados e disponíveis para os usuários. |
Tabela 4.2.2 Fases do Projeto e Principais Marcos
Cada fase é dividida em iterações de desenvolvimento, conforme descrito na seção 4.3.
A seção 4.2.4 ilustra o planejamento de nível alto do projeto, mostrando fases, iterações e principais marcos.
Cada fase consiste em interações de desenvolvimento, nas quais um subconjunto do sistema é desenvolvido. Em geral, essas iterações:
A tabela a seguir descreve as iterações juntamente com os marcos associados e os riscos tratados.
| Fase |
Iteração |
Descrição |
Marcos Associados |
Riscos Tratados |
|---|---|---|---|---|
|
Fase de Iniciação |
Iteração Preliminar |
Define o modelo de negócios, requisitos de produto, Plano de Desenvolvimento de Software e caso de negócios. |
Revisão do Caso de Negócios |
Esclarece os requisitos do usuário. Desenvolve Planos de Desenvolvimento de Software e escopo realistas. Determina a possibilidade do projeto de um ponto de vista de negócios. |
|
Fase de Elaboração |
Iteração E1 - Desenvolver Protótipo de Arquitetura |
Completa a análise e o design para todos os requisitos de alto risco. Desenvolve o protótipo de arquitetura.
|
Protótipo de Arquitetura |
Questões de arquitetura clarificadas. Riscos técnicos mitigados. Protótipo antecipado para revisão do usuário. |
|
Fase de Construção |
Iteração C1 - Desenvolver Beta de R1 |
Implementar e testar principais requisitos do R1 para fornecer a Versão Beta do R1.
Avaliar se o release está pronto para ir para teste beta. |
Capacidade Operacional Inicial (Código Beta de R1 Concluído) |
Todos os recursos-chave a partir de uma perspectiva do usuário e de arquitetura implementados no Beta.
|
|
Fase de Transição |
Iteração T1 - Desenvolver/Implantar Release R1 |
Implantar o Beta de R1. Corrigir defeitos do Beta e incorporar feedback do Beta.
Implementar e testar requisitos remanescentes de R1. Empacotar, distribuir e instalar o Release R1. Casos de uso de baixo risco remanescentes do R2 totalmente detalhados. |
Teste Beta de R1 Concluído
Código do R1 Concluído
Liberação do Produto R1 |
Feedback do usuário antes da liberação do R1.
A qualidade do produto deve ser alta. Defeitos minimizados. Custo de qualidade reduzido. A liberação em dois estágios minimiza os defeitos. A liberação em dois estágios fornece uma transição mais fácil para os usuários. R1 totalmente revisado pela comunidade de usuários. |
|
|
Iteração T2 - Desenvolver Interno 1 do R2 |
Projetar, implementar e testar os requisitos do Interno 1 do R2. Incorporar aprimoramentos e defeitos do R1. Implantar o Interno 1 do R2. |
Teste do Interno 1 do R2 Concluído |
Se necessário, o Interno 1 do R2 poderia ser liberado para tratar os defeitos de R1, para ajudar a lidar com a satisfação do cliente. |
|
|
Iteração T3 - Desenvolver Interno 2 do R2 |
Projetar, implementar e testar os requisitos do Interno 2 do R2 Incorporar aprimoramentos e defeitos do Interno 2 do R2. Implantar o Interno 2 do R2. |
Teste do Interno 2 do R2 Concluído |
Interno 1 do R2 informalmente revisado pela comunidade de usuários.
Se necessário, o Interno 1 do R2 poderia ser liberado para tratar os defeitos de R1, para ajudar a lidar com a satisfação do cliente. |
|
|
Iteração T4 - Desenvolver/Implantar Release R2 |
Empacotar, distribuir e instalar o Release R2. |
Código do R2 Concluído
Liberação do Produto R2 |
Interno 2 do R2 informalmente revisado pela comunidade de usuários. A liberação em dois estágios fornece uma transição mais fácil para os usuários. |
Este Plano de Desenvolvimento de Software aborda os dois primeiros releases do C-Registration System. Os recursos-chave definidos no Documento de Visão [1] são programados para os primeiros 2 releases. Todos os recursos críticos ao registro de estudantes são planejados para o primeiro release (R1.0).
Espera-se que o conteúdo planejado dos releases seja alterado à medida que o projeto avance. Isso pode ser devido a diversos fatores técnicos e de negócios. Para acomodar as alterações, o Rational RequisitePro será utilizado para gerenciar os requisitos de produto e manter controle do conteúdo do release. Especificamente, os atributos de benefício, esforço e risco são utilizados para determinar a prioridade dos requisitos de produto e, dessa forma, o release de destino.
Existe uma previsão de que o C-Registration System será liberado para uso geral no Wylie College por meio de 2 a 4 liberações principais.
O Release 1 deve conter no mínimo a funcionalidade básica listada a seguir:
O Release 2 deve incluir:
A funcionalidade para o Release 3 ainda não foi determinada. Existe uma previsão de que esse release conterá aprimoramentos para a funcionalidade existente.
A futura substituição do Sistema de Faturamento e do Sistema de Banco de Dados de Cursos legados está planejada para o Release 4 no ano de 2005.
Além disso, um Release Beta precederá o Release do Produto R1.0 e conterá toda a funcionalidade principal do R1. O release Beta será implantado como se fosse o sistema real, com a exceção de que irá interagir com uma cópia isolada dos sistemas legados existentes, para evitar quaisquer perturbação nos sistemas existentes. Um grupo selecionado de estudantes e faculdades será solicitado a avaliar formalmente o beta.
Além disso, existirão releases internos, para manter uma pulsação regular e ajudar a manter o projeto sob controle, permitindo também releases adicionais após o release inicial, se necessário. Os releases internos podem ser revisados informalmente por estudantes e faculdades. A seguir é fornecida uma breve descrição dos objetivos de cada um desses releases internos:
A funcionalidade para o Release 3 ainda não foi determinada. Existe uma previsão de que esse release conterá aprimoramentos para a funcionalidade existente.
A futura substituição do Sistema de Faturamento e do Sistema de Banco de Dados de Cursos legados está planejada para o Release 4 no ano de 2005.
O planejamento de nível alto mostrando as fases, iterações e marcos do projeto está contido no Planejamento de Nível Alto do Projeto C-Registration [5], conforme mostrado a seguir.
|
Os funcionários de TI identificados no Organograma na seção 8.1 estão alocados para o projeto. Não serão contratados recursos adicionais até que o caso de negócios seja revisado no final da Fase de Iniciação e uma decisão Aprovado/Não Aprovado seja tomada sobre o projeto.
A organização de teste contará com o suporte da organização de engenharia de software, conforme mostrado pela linha pontilhada no organograma.
O departamento de TI do Wylie College tem Desenvolvedores e Designers suficientes para atender às necessidades do projeto. O Escritório de Recrutamento do Wylie College está preparado para recrutar um Desenvolvedor Sênior com vários anos de experiência em C++, além de um Integrador de Sistemas experiente e 2 Implementadores/Testadores (Classificação Júnior), com pelo menos 1 ano de experiência em C++.
O treinamento nas seguintes habilidades será conduzido para a equipe do projeto antes do início das atividades de design:
O orçamento do projeto baseado nas estimativas iniciais
Consulte o Plano de Iteração E1 do Sistema de Registro em Cursos [11].
Os requisitos para esse sistema estão capturados nos documentos Visão [1] e Pedidos do Envolvido [3].
O coordenador de projeto mantém um planejamento resumido mostrando a data esperada de cada marco, o que faz parte do Relatório de Avaliação de Status, conforme descrito no plano de relatórios. O Relatório de Avaliação de Status é fornecido ao Executivo de TI, que pode utilizá-lo para definir novas prioridades ou recomendar ação corretiva.
O planejamento resumido é derivado de um planejamento detalhado mantido pelos gerentes de equipe. Os itens de linha no planejamento detalhado são pacotes de trabalho designados a indivíduos. Cada indivíduo que recebe a designação de um pacote de trabalho fornece as informações de % de conclusão para seu/sua gerente de equipe semanalmente.
As despesas são monitoradas pelo coordenador de projeto e relatadas e avaliadas utilizando o Relatório de Avaliação de Status.
É necessário que todos os produtos de trabalho passem pelo processo de revisão apropriado. A revisão é requerida para assegurar que cada produto de trabalho seja de qualidade aceitável, utilizando as diretrizes descritas nas listas de verificação e diretrizes de revisão do Rational Unified Process [6].
Além disso, os defeitos serão registrados e controlados e as métricas de defeito reunidas conforme descrito no Web Site de Processo de Software da Wylie [10].
O Relatório de Avaliação de Status será preparado pelo Coordenador de Projeto pelo menos uma vez por mês. Isso inclui:
- estimativas de planejamento e custos atualizadas
- resumo de métricas
As métricas padrão do projeto, conforme descrito no Web Site de Processo de Software do Wylie College [10], serão reunidas e incluídas no Relatório de Avaliação de Status.
Consulte a Lista de Riscos do C-Registration System [8].
O planejamento mostrará um deslocamento gradual da equipe para outros projetos. Pelo menos um desenvolvedor será mantido em meio-expediente pelo Departamento de TI após a entrega para fornecer manutenção do sistema.
Um Relatório de Conclusão será submetido ao Executivo de TI resumindo as lições aprendidas, incluindo uma avaliação do planejamento e custos reais vs. previstos.
Consulte o Caso de Desenvolvimento do C-Registration System [9].
Consulte o Web Site de Processo de Software do Wylie College [10].
N/D
N/D
Consulte o Web Site de Processo de Software da Wylie [10].
N/D.
N/D.
N/D.