ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

Transcrição

1 ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão <1.0>

2 Histórico da Revisão Data Versão Descrição Autor <dd/mmm/aa> <x.x> <detalhes> <nome> Página 2 de 9

3 Índice Analítico 1. Introdução Finalidade Escopo Referências Visão Geral Visão Geral do Projeto Finalidade, Escopo e Objetivos do Projeto Suposições e Restrições Produtos Liberados do Projeto Evolução do Organização do Projeto Estrutura Organizacional Interfaces Externas Papéis e Responsabilidades Processo de Gerenciamento Estimativas do Projeto Plano de Projeto Plano de Fase Objetivos das Iterações Programação do Projeto Recursos do Projeto` Monitoramento e Controle do Projeto... 8 Página 3 de 9

4 1. Introdução 1.1 Finalidade A finalidade do é reunir todas as informações necessárias para controlar o projeto. Ele descreve a abordagem dada ao desenvolvimento do software e é o plano de nível mais alto gerado e usado pelos gerentes para coordenar o esforço de desenvolvimento. O é usado por estas pessoas: 1.2 Escopo O gerente de projeto utiliza-o para planejar o cronograma do projeto e as necessidades de recursos e para acompanhar o andamento do projeto em relação ao cronograma. Membros da equipe do projeto utilizam-no para entender o que precisam fazer, quando precisam fazê-lo e quais são as outras atividades das quais eles dependem. Este descreve o plano geral a ser usado pelo projeto Sistema para Gerenciamento de Associações Recreativas, incluindo a implantação do produto. Os detalhes de iterações individuais serão descritos nos Planos de Iteração. Os planos, conforme especificado neste documento, baseiam-se nos requisitos do produto definidos no Documento de Visão. 1.3 Referências Nenhuma 1.4 Visão Geral Este contém as seguintes informações: Visão Geral do Projeto apresenta uma descrição da finalidade, do escopo e dos objetivos do projeto. Também define os produtos que se espera que o projeto libere. Organização do Projeto descreve a estrutura organizacional da equipe do projeto. Processo de Gerenciamento explica o custo estimado e o cronograma, define os principais marcos e fases do projeto e descreve como o projeto será monitorado. Planos e Diretrizes Aplicáveis apresentam uma visão geral do processo de desenvolvimento do software, abrangendo métodos, ferramentas e técnicas a serem seguidos. 2. Visão Geral do Projeto 2.1 Finalidade, Escopo e Objetivos do Projeto Este projeto implementará um Sistema para Gerenciamento de Associações Recreativas. Ele deverá dar suporte ao gerenciamento dos associados e dependentes e suas atividades dentro da associação. 2.2 Suposições e Restrições O projeto deve sem entregue dentro do prazo estabelecido neste Plano. Página 4 de 9

5 2.3 Produtos Liberados do Projeto Os produtos liberados de cada fase do projeto estão identificados no Caso de Desenvolvimento. Os produtos liberados são entregues no final da iteração, conforme especificado na seção Programação do Projeto. 2.4 Evolução do Versão Fase Data-Alvo 2 Iniciação 31/05/ Elaboração 30/06/ Iteração de Construção 1 31/07/ Iteração de Construção 2 31/08/ Iteração de Construção 3 30/09/ Transição 11/11/2011 O será revisado antes do início de cada fase de Iteração. 3. Organização do Projeto 3.1 Estrutura Organizacional A equipe de projeto das fases de iniciação e elaboração será organizada da seguinte maneira: 3.2 Interfaces Externas A equipe se relacionará com os funcionários da ARCO Associação Recreativa dos Correios referente a cada área que o sistema gerenciará. 3.3 Papéis e Responsabilidades Papel Gerente de Projeto Arquiteto Responsabilidade 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. O Arquiteto coordena as atividades técnicas e os artefatos no decorrer do projeto. O Arquiteto estabelece Página 5 de 9

6 Analista do Negócio Designer Testador Especialista em requisitos 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. 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. 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. 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. 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. 4. Processo de Gerenciamento 4.1 Estimativas do Projeto A fase de iniciação deste projeto dura 4 semanas. As estimativas iniciais das fases subseqüentes estão na seção 2.4 acima. 4.2 Plano de Projeto Tarefa Início Fim Definir Contexto de Negócio 02/05/2011 Seg. 05/05/2011 Qui. Definir a Visão e o escopo do Sistema 06/05/2011 Sex. 12/05/2011 Qui. Descrição e esclarecimento das 13/05/2011 Sex 19/05/2011 Qui. funcionalidades Preparar o Ambiente 20/05/2011 Sex 25/05/2011 Qua. Refinar o Plano do Projeto 26/05/2011 Qui. 31/05/2011 Ter. Página 6 de 9

7 4.2.1 Plano de Fase Objetivos das Iterações Fase Iteração Descrição Marcos Associados 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 de Caso de Negócio Riscos Abordados Esclarece os requisitos do usuário primeiro. Desenvolve planos e escopo realísticos para o projeto. Elaboração Construção Transição Desenvolve o Protótipo de Arquitetura Iteração C1 Desenvolver Beta Iteração C2 Desenvolver Release Inicial Iteração C3 Desenvolver Release Completo Release de Software Conclui a análise e o design de todos os casos de uso. Desenvolve o protótipo de arquitetura. Implementar e testar casos de uso para fornecer a versão Beta Version. 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. Incorporar aperfeiçoamentos e defeitos a partir do release inicial. Desenvolve o sistema completo. Empacotar, distribuir e instalar Release. Protótipo de Arquitetura Beta Software Software Software Liberado Determina a viabilidade do projeto do ponto de vista do negócio 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. 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. Software completamente revisado pela comunidade de usuários. A qualidade do produto deve ser alta. Defeitos minimizados. Custo de qualidade reduzido. Um release rápido satisfaz o cliente. A principal funcionalidade fornecida no Sistema pelo Release completo. Página 7 de 9

8 4.2.3 Programação do Projeto A programação de projeto preliminar está na seção 2.4. Os planos atualizados serão disponibilizados nas datas especificadas nessa seção Recursos do Projeto` Os participantes deste projeto serão disponibilizados pela WTG Soluções Tecnológicas, e o critério para a escolha serão as habilidades compatíveis com as necessárias no projeto. Durante o projeto, a WTG poderá desalocar participantes que não estejam rendendo ao projeto, e alocar novos participantes, sempre visando atingir os marcos nas datas-alvos. A WTG também é responsável por treinamentos dos participantes, seja esses nas tecnologias e ferramentas utilizadas no projeto, ou até mesmo treinamentos sobre o processo, para que os participantes estejam adaptados a filosofia do projeto. 4.3 Monitoramento e Controle do Projeto Gerenciamento de Requisitos Os requisitos desse sistema são capturados no Documento de Visão. As mudanças solicitadas nos requisitos são capturadas nas Solicitações de Mudança e são aprovadas como parte do processo de Gerenciamento de Configuração. Controle de Cronograma e Orçamento As despesas são monitoradas pelo gerente de projeto, e reportadas e avaliadas mensalmente. (Consulte Relatórios e Métricas abaixo). O gerente de projeto mantém uma programação mostrando a data esperada de cada marco. Os itens de linha na programação incluem pacotes de trabalho atribuídos a pessoas. Cada pessoa a quem é atribuído um pacote de trabalho fornece ao gerente do projeto informações sobre o percentual de conclusão das tarefas semanalmente. As mudanças na programação ficarão a cargo dos patrocinadores do projeto, que decidirão se o escopo será alterado a fim de preservar as datas-alvo de conclusão. Controle de Qualidade Os defeitos serão registrados e monitorados como Solicitações de Mudança, e as métricas de defeito serão coletadas (consulte Relatórios e Métricas abaixo). Será necessário que todos os produtos liberados sejam submetidos ao processo de revisão adequado, conforme está descrito no Caso de Desenvolvimento. A revisão é necessária para assegurar que cada produto liberado seja de qualidade aceitável, usando as orientações descritas nos pontos de verificação e nas diretrizes de revisão do RUP para Projetos Pequenos. Todos os defeitos encontrados durante a revisão que não forem corrigidos antes da liberação para integração deverão ser capturados como Solicitações de Mudança para que não sejam esquecidos. Relatórios e Métricas Estimativas atualizadas de custo e cronograma e relatórios sumários de métricas serão gerados no final de cada iteração. O Conjunto Mínimo de Métricas, conforme descrito no RUP Guidelines: Metrics, será coletado semanalmente. Isso inclui: O valor atribuído às tarefas concluídas. É usado para refazer a estimativa da programação e do orçamento para o restante do projeto e/ou para identificar a necessidade de mudanças no escopo. Todos os defeitos abertos e fechados mostrados como um gráfico de tendências. São usados para ajudar a estimar o esforço restante necessário para corrigir defeitos. Página 8 de 9

9 Aprovação dos casos de teste de aceitação mostrada como um gráfico de tendências. É usada para demonstrar o progresso para os envolvidos. Além disso, os custos gerais serão monitorados tendo em vista o orçamento do projeto. Gerenciamento de Configuração Serão selecionadas ferramentas apropriadas que fornecem um banco de dados de Solicitações de Mudança e um repositório controlado de versões dos artefatos do projeto. Todo o código-fonte, os scripts de teste e os arquivos de dados serão incluídos nas baselines. A documentação relacionada ao código-fonte também será incluída na baseline como, por exemplo, a documentação de design. Todos os artefatos de produtos liberados do cliente são incluídos na baseline final da iteração, inclusive os executáveis. As Solicitações de Mudança são revisadas e aprovadas pelo membro do projeto responsável pelo papel Gerente de Controle de Mudança. Os backups completos são efetuados mensalmente e os gradativos, durante a noite. Página 9 de 9