Plano de Projeto

Projeto: Biblioteca Central da UFES

Versão: 1.0

Responsável: Ricardo de Almeida Falbo

1. Introdução

Este documento apresenta a versão 1.0 do Plano de Projeto para o projeto de desenvolvimento de um novo sistema para a Biblioteca Central da UFES. Na seção 2, é descrito o escopo do projeto, por meio de uma descrição sucinta do problema e uma lista de requisitos do cliente. Na seção 3, é apresentado o processo de desenvolvimento definido para este projeto. A seção 4 apresenta a equipe do projeto. A seção 5 trata das estimativas de tamanho, esforço e duração, apresentando o cronograma do projeto. Por fim, a seção 6 apresenta o plano de gerência de configuração.

2. Escopo do Projeto

A biblioteca central da UFES necessita de um sistema de informação para apoiar a realização de suas atividades principais, a saber: empréstimo de exemplares de livros a usuários e reserva de livros. Para que essas atividades sejam apoiadas, é necessário controlar as informações acerca de livros, exemplares e usuários. Além disso, devem ser fornecidas facilidades de consulta ao acervo da UFES, permitindo consultas por assunto, autor e título. Por fim, para apoiar a aquisição de novos exemplares, deverá ser gerado um relatório gerencial com informações sobre os livros mais reservados e emprestados.

Assim, no contexto do presente projeto, foram identificados os seguintes requisitos funcionais do cliente:

RF1.O sistema deve controlar empréstimos de exemplares a usuários.Devem ser providas funcionalidades permitindo a realização de um novo empréstimo, a devolução de um exemplar emprestado e a consulta a empréstimos.

RF2.O sistema deve permitir a reserva de exemplares a usuários.Devem ser providas funcionalidades permitindo a realização de uma nova reserva, a consulta a reservas e o cancelamento de uma reserva, tanto pelo usuário, quanto automaticamente pelo sistema.

RF3.O sistema deve efetuar o controle do acervo da biblioteca.Devem ser providas funcionalidades para cadastrar livros e exemplares (abrangendo a inclusão de dados de novos livros/exemplares, a alteração de dados de

livros/exemplares já cadastrados, a consulta a livros/exemplares específicos e a exclusão de livros/exemplares).

RF4.O sistema deve efetuar o controle de assuntos para indexação de livros.Devem ser providas funcionalidades para cadastrar assuntos (a inclusão de dados de novos assuntos, a alteração de dados de assuntos cadastrados, a consulta a assuntos específicos e a exclusão de assuntos).

RF5.O sistema deve permitir consultas ao acervo.Devem ser providas funcionalidades para os usuários da biblioteca consultarem livros por título, autor e assunto, apresentando dados do livro, dos assuntos de que tratam, exemplares existentes e sua disponibilidade.

RF6.O sistema deve prover um Relatório Gerencial para Aquisição de Livros.O relatório deve apontar os livros mais emprestados e reservados, e números de exemplares existentes de cada um, indicando os livros que devem ter mais exemplares adquiridos.

Os seguintes requisitos não funcionais do cliente foram inicialmente levantados:

RNF1.O sistema deve controlar o acesso às funcionalidades.Funcionalidades relacionadas à realização de empréstimos, controle de acervo, controle de assuntos e relatórios gerenciais serão restritas a bibliotecários. Funcionalidades de reserva e consultas estarão disponíveis para os usuários.

RNF2.Funcionalidades oferecidas a usuários devem estar disponíveis na Internet.

RNF3.O sistema deve estar integrado aos sistemas acadêmico e de pessoal.Uma vez que os usuários da biblioteca são alunos, funcionários e professores da UFES, o sistema deverá estar integrado aos sistemas acadêmico e de pessoal para ter acesso aos dados de alunos e professores e funcionários, respectivamente.

3. Processo de Software do Projeto

O processo de software definido para o presente projeto foi adaptado a partir do Processo Padrão LabES Especializado para o Desenvolvimento Segundo o Paradigma Estruturado.

No que se refere ao Processo de Desenvolvimento, foi adotado o modelo de ciclo de vida Incremental, em sua variação em que as atividades de Levantamento e Análise de Requisitos, Projeto de Dados e da Arquitetura, são feitas para o sistema como um todo e as demais atividades do processo de desenvolvimento são realizadas em dois incrementos: o primeiro contemplando as funcionalidades de Controle de Assuntos e de Acervo (incluindo as consultas) e o segundo incremento tratando das demais funcionalidades, como mostra a Figura 1.

Figura 1 – Visão Geral do Processo de Desenvolvimento Definido.

A escolha desse modelo de ciclo de vida foi feita com base nas seguintes premissas: O domínio da aplicação é estável, modular e bem conhecido; Não há necessidade de entrega de todas as funcionalidades de uma só vez, tendo

em vista que o usuário só poderá usufruir integralmente de suas potencialidades quando todos os livros, assuntos e exemplares estiverem cadastrados;

O sistema não é muito grande, nem muito complexo, sendo seus requisitos bastante estáveis, permitindo que o levantamento e a análise de requisitos sejam feitos para o sistema como um todo.

Vale ressaltar que, como este é um projeto com a finalidade de exercitar o conteúdo estudado na disciplina de Engenharia de Software, ele não vai ser desenvolvido integralmente. Assim, no que se refere ao processo de desenvolvimento, o processo será conduzido apenas até a atividade de projeto.

Em relação ao Processo de Gerência de Projetos, as seguintes alterações foram feitas neste projeto em relação ao Processo Padrão LabES:

Nas atividades de planejamento e acompanhamento do projeto, não foram incluídas as sub-atividades de Estimativa de Custos e de Gerência de Riscos.

As atividades de acompanhamento são realizadas nos marcos definidos no Processo Padrão LabES, com exceção do marco definido ao término da atividade de Levantamento de Requisitos, quando não será feito um acompanhamento. Isso decorre do fato de, neste projeto, as atividades de Levantamento e Análise de Requisitos estarem programadas para serem

Levantamento de Requisitos

Análise de Requisitos

Projeto de Dados

Projeto da Arquitetura

Projeto Modular de Programas e

IU 1

Implementação e Testes de Unidade 1

Testes de Integração e Validação 1

Entrega 1

Implementação e Testes de Unidade 2

Testes de Integração e Validação 2

Entrega 2Projeto Modular de Programas e

IU 2

realizadas parcialmente em paralelo. Assim, uma única atividade de acompanhamento será realizada ao término da Análise de Requisitos.

O Processo de Garantia da Qualidade segue exatamente o definido no Processo Padrão LabES.

Por fim, no Processo de Gerência de Configuração, a atividade de Controle de Alterações não será formalmente realizada. Assim, apenas um planejamento da gerência de configuração será realizado (durante o planejamento do projeto) e, na medida em que nos documentos forem sendo gerados, versões dos mesmos serão criadas.

A seguir o Processo de Desenvolvimento definido é apresentado.

Processo de Desenvolvimento

I. Levantamento de RequisitosPré-atividades: PlanejamentoSub-atividades:

Identificação de Requisitos FuncionaisIdentificação de Requisitos Não FuncionaisElaboração do Documento de Especificação de Requisitos

Artefatos Insumo: Plano de Projeto (seção Escopo do Projeto)Artefatos Produzidos: Documento de Especificação de RequisitosRecursos Necessários: (aplicáveis a todas as sub-atividades)

Recursos Humanos: Analista, Cliente e UsuárioFerramentas de Software: Editor de Texto, Ferramenta de ModelagemHardware: Micro-computador e Impressora

Procedimentos: Técnica de Modelagem de Casos de Uso, Padrão de Nomenclatura

I.1. Identificação de Requisitos FuncionaisPré-atividades: PlanejamentoSub-atividades: não háArtefatos Insumo: Plano de Projeto (seção Escopo do Projeto)Artefatos Produzidos: Modelo de Casos de Uso.Procedimentos: Técnica de Modelagem de Casos de Uso, Padrão de Nomenclatura

I.2. Identificação de Requisitos Não FuncionaisPré-atividades: Identificação de Requisitos FuncionaisSub-atividades: não háArtefatos Insumo: Plano de Projeto (seção Escopo do Projeto) e

Modelo de Casos de UsoArtefatos Produzidos: Lista de Requisitos Não Funcionais.Procedimentos: Padrão de Nomenclatura

I.3. Elaboração do Documento de Especificação RequisitosPré-atividades: Identificação de Requisitos Funcionais e Identificação de Requisitos

Não FuncionaisSub-atividades: não háArtefatos Insumo: Modelo de Casos de Uso e Lista de Requisitos Não FuncionaisArtefatos Produzidos: Documento de Especificação de Requisitos.Procedimentos: Modelo de Documento de Especificação de Requisitos, Padrão de

NomenclaturaObservação: Esta atividade é um marco. Assim, após sua conclusão, deverá ser realizada a atividade de Garantia da Qualidade “Verificação e Validação da Especificação de Requisitos”. Conforme discutido anteriormente, como essa atividade vai ser realizada parcialmente em paralelo com a Análise de Requisitos, apenas uma atividade de acompanhamento do projeto (processo de Gerência de Projeto) será realizada.

II. Análise de RequisitosPré-atividades: Levantamento de RequisitosSub-atividades:

Modelagem de AnáliseElaboração do Documento de Especificação de Análise

Artefatos Insumo: Documento de Especificação de RequisitosArtefatos Produzidos: Documento de Especificação de Análise.Recursos Necessários: (aplicáveis a todas as sub-atividades)

Recursos Humanos: Analista, Cliente e UsuárioFerramentas de Software: Editor de Texto, Ferramenta de ModelagemHardware: Micro-computador e Impressora

Observação: Esta atividade será conduzida parcialmente em paralelo com a atividade de Levantamento de Requisitos. Assim, é necessário que apenas parte do Levantamento de Requisitos tenha sido efetuado para que a Análise de Requisitos possa ser iniciada.

II.1. Modelagem de AnálisePré-atividades: Levantamento de RequisitosSub-atividades:

Modelagem de DadosModelagem de Estados

Artefatos Insumo: Documento de Especificação de RequisitosArtefatos Produzidos: Modelos de Análise, incluindo Modelo de Entidades e

Relacionamentos e Diagramas de Estados, e Dicionário de Projeto.

II.1.1. Modelagem de DadosPré-atividades: Levantamento de RequisitosSub-atividades: não háArtefatos Insumo: Documento de Especificação de RequisitosArtefatos Produzidos: Modelo de Entidades e Relacionamentos e Dicionário de

Dados.Procedimentos: Técnica de Modelagem de Entidades e Relacionamentos, Padrão de

Nomenclatura

II.1.2. Modelagem de EstadosPré-atividades: Modelagem de DadosSub-atividades: não háArtefatos Insumo: Documento de Especificação de Requisitos, Modelo de Entidades

e Relacionamentos e Dicionário de Dados.Artefatos Produzidos: Diagramas de Estados e Dicionário de Dados.Procedimentos: Técnica de Modelagem de Estados, Padrão de Nomenclatura.

II.2. Elaboração do Documento de Especificação de AnálisePré-atividades: Modelagem de AnáliseSub-atividades: não háArtefatos Insumo: Modelos de Análise, incluindo Modelo de Entidades e

Relacionamentos e Diagramas de Estados, e Dicionário de Projeto.

Artefatos Produzidos: Documento de Especificação de Análise.Procedimentos: Modelo de Documento de Especificação de Análise Segundo o

Paradigma Estruturado, Padrão de NomenclaturaObservação: Esta atividade é um marco. Assim, após sua conclusão, deverão ser realizados os Processos de Gerência de Projeto (Acompanhamento de Projeto) e de Garantia da Qualidade (Verificação e Validação da Especificação de Análise).

III. ProjetoPré-atividades: Análise de RequisitosSub-atividades:

Modelagem de ProjetoElaboração da Especificação de Projeto

Artefatos Insumo: Documento de Especificação de Requisitos e Documento de Especificação de Análise

Artefatos Produzidos: Documento de Especificação de Projeto.Recursos Necessários:

Recursos Humanos: Projetista, Analista, Programador, Cliente e UsuárioFerramentas de Software: Editor de Texto, Ferramenta de ModelagemHardware: Micro-computador e Impressora

III.1. Modelagem de ProjetoPré-atividades: Análise de RequisitosSub-atividades:

Projeto de DadosProjeto ArquiteturalProjeto Modular de ProgramasProjeto de Interfaces com o Usuário

Artefatos Insumo: Documento de Especificação de Requisitos, Documento de Especificação de Análise

Artefatos Produzidos: Modelos de Projeto, incluindo: Modelo Relacional de Banco de Dados, Diagramas Hierárquicos de Funções, Diagramas de Estrutura Modular. Interfaces com o usuário. Dicionário de Projeto, incluindo Dicionário de Dados e Especificações de Módulos.

III.1.1. Projeto de DadosPré-atividades: Modelagem de DadosSub-atividades: não háArtefatos Insumo: Documento de Especificação de Análise (Modelo ER e

Dicionário de Dados)Artefatos Produzidos: Modelo Relacional e Dicionário de Dados de Projeto.Recursos Necessários:

Recursos Humanos: Projetista, Analista, Cliente e UsuárioFerramentas de Software: Editor de Texto, Ferramenta de ModelagemHardware: Micro-computador e Impressora

Procedimentos: Técnica de Projeto Relacional de Dados, Padrão de Nomenclatura

III.1.2. Projeto da ArquiteturaPré-atividades: Análise de RequisitosSub-atividades: não háArtefatos Insumo: Documento de Especificação de Requisitos, Documento de

Especificação de Análise.Artefatos Produzidos: Diagramas Hierárquicos de Função.Recursos Necessários:

Recursos Humanos: Projetista, Analista, Cliente e UsuárioFerramentas de Software: Editor de TextoHardware: Micro-computador e Impressora

Procedimentos: Método de Projeto Estruturado de Sistemas, Padrão de Nomenclatura

III.1.3. Projeto Modular de Programas - 1Pré-atividades: Projeto da ArquiteturaSub-atividades: não háArtefatos Insumo: Documento de Especificação de Requisitos, Documento de

Especificação de Análise e Diagramas Hierárquicos de Função.Artefatos Produzidos: Diagramas de Estrutura Modular.Recursos Necessários:

Recursos Humanos: Projetista e ProgramadorFerramentas de Software: Editor de TextoHardware: Micro-computador e Impressora

Procedimentos: Método de Projeto Estruturado de Sistemas, Padrão de Nomenclatura

III.1.4. Projeto de Interfaces com o Usuário -1 Pré-atividades: Projeto Modular de Programas - 1Sub-atividades: não háArtefatos Insumo: Documento de Especificação de Requisitos, Documento de

Especificação de Análise, Diagramas Hierárquicos de Função e Diagramas de Estrutura Modular.

Artefatos Produzidos: Interfaces com o Usuário.Recursos Necessários:

Recursos Humanos: Analista, Projetista, Programador, Cliente e Usuário.Ferramentas de Software: Editor de Texto, Ambiente de ProgramaçãoHardware: Micro-computador e Impressora

Procedimentos: Padrão de Nomenclatura.

III.2. Elaboração do Documento de Especificação de Projeto -1 Pré-atividades: Projeto de Dados, Projeto da Arquitetura, Projeto Modular de

Programas – 1, Projeto de IU – 1.Sub-atividades: não háArtefatos Insumo: Modelos de Projeto, incluindo Modelo Relacional, Diagramas

Hierárquicos de Função e Diagramas de Estrutura Modular, Interfaces com o Usuário e Dicionário de Projeto.

Artefatos Produzidos: Documento de Especificação de Projeto.Recursos Necessários:

Recursos Humanos: Projetista.Ferramentas de Software: Editor de Texto, Ambiente de Programação,

Ferramenta de ModelagemHardware: Micro-computador e Impressora

Procedimentos: Modelo de Documento de Especificação de Projeto, Padrão de Nomenclatura

Observação: Esta atividade é um marco. Assim, após a sua conclusão, deverão ser realizados os Processos de Gerência de Projeto (Acompanhamento de Projeto) e de Garantia da Qualidade (Verificação e Validação da Especificação de Projeto)

IV. Implementação e Teste de Unidade - 1Pré-atividades: ProjetoSub-atividades:

CodificaçãoTestes de Unidade

Artefatos Insumo: Documento de Especificação de ProjetoArtefatos Produzidos: Código Fonte, Relatório de TesteRecursos Necessários (aplicáveis a todas as sub-atividades)

Recursos Humanos: Programador e ProjetistaFerramentas de Software: Ambiente de ProgramaçãoHardware: Micro-computador

IV.1. Codificação -1Pré-atividades: ProjetoSub-atividades: não háArtefatos Insumo: Documento de Especificação de ProjetoArtefatos Produzidos: Código FonteProcedimentos: Padrão de Programação para a Linguagem de Programação AdotadaObservação: Esta atividade é um ponto de controle, no qual deverá ser feita uma atividade de Garantia da Qualidade (Verificação e Validação da Implementação -1)

IV.2. Testes de Unidade -1Pré-atividades: Codificação -1Sub-atividades: não háArtefatos Insumo: Documento de Especificação de Projeto, Código FonteArtefatos Produzidos: Código Fonte com Unidades Testadas, Relatório de TesteProcedimentos: Técnicas de Teste, Roteiro para Relatório de Testes.Observação: Esta atividade é um marco. Assim, após a sua conclusão, deverá ser realizada uma atividade de acompanhamento do Processo de Gerência de Projeto

V. Testes de Integração e Validação - 1Pré-atividades: Implementação e Teste de Unidade - 1Sub-atividades:

Testes de IntegraçãoTestes de Validação

Artefatos Insumo: Código Fonte com Unidades Testadas, Documento de Especificação de Requisitos, Documento de Especificação de Análise, Documento de Especificação de Projeto

Artefatos Produzidos: Sistema Validado, Relatórios de TesteRecursos Necessários

Recursos Humanos: Engenheiro de Testes, Cliente, Usuário, Analista, Projetista e Programador

Ferramentas de Software: Ambiente de ProgramaçãoHardware: Micro-computador

V.1. Testes de Integração -1Pré-atividades: Implementação e Teste de Unidade - 1Sub-atividades: não háArtefatos Insumo: Código Fonte com Unidades Testadas, Documento de

Especificação de Requisitos, Documento de Especificação de Análise, Documento de Especificação de Projeto

Artefatos Produzidos: Sistema Integrado, Relatórios de TesteRecursos Necessários

Recursos Humanos: Engenheiro de Testes, Programador e ProjetistaFerramentas de Software: Ambiente de ProgramaçãoHardware: Micro-computador

Procedimentos: Técnicas de Teste, Roteiro para Relatório de Testes

IV.2. Testes de Validação -1Pré-atividades: Testes de Integração -1Sub-atividades: não háArtefatos Insumo: Sistema Integrado, Documento de Especificação de Requisitos,

Documento de Especificação de AnáliseArtefatos Produzidos: Sistema Validado, Relatório de TesteRecursos Necessários

Recursos Humanos: Engenheiro de Testes, Cliente, Usuário, Analista, Projetista

Ferramentas de Software: Ambiente de ProgramaçãoHardware: Micro-computador

Procedimentos: Técnicas de Teste, Roteiro para Relatório de Testes.Observação: Esta atividade é um marco. Assim, após a sua conclusão, deverá ser realizada uma atividade de acompanhamento do Processo de Gerência de Projeto

VI. Entrega - 1Pré-atividades: Testes de Validação - 1Sub-atividades:

Testes de AceitaçãoElaboração da Documentação do UsuárioTreinamento de Usuário

Artefatos Insumo: Sistema Validado, Documento de Especificação de Requisitos, Documento de Especificação de Análise, Documento de Especificação de Projeto

Artefatos Produzidos: Sistema para Operação, Relatórios de Teste, Documentação para o Usuário

Recursos NecessáriosRecursos Humanos: Engenheiro de Testes, Cliente, Usuário, Analista,

InstrutorFerramentas de Software: Editor de TextosHardware: Micro-computador, Plataforma de Operação do Sistema

VI.1. Testes de Aceitação -1Pré-atividades: Testes de Validação - 1Sub-atividades: não háArtefatos Insumo: Sistema Validado, Documento de Especificação de RequisitosArtefatos Produzidos: Sistema para Operação, Relatórios de TesteRecursos Necessários

Recursos Humanos: Engenheiro de Testes, Usuário, ClienteFerramentas de Software: Editor de TextosHardware: Micro-computador, Plataforma de Operação do Sistema

Procedimentos: Técnicas de Teste, Roteiro para Relatório de Testes

VI.2. Elaboração da Documentação do Usuário -1Pré-atividades: Projeto de Interface com o Usuário -1Sub-atividades: não háArtefatos Insumo: Documento de Especificação de Requisitos, Documento de

Especificação de Análise, Documento de Especificação de Projeto, Sistema para OperaçãoArtefatos Produzidos: Documentação para o UsuárioRecursos Necessários

Recursos Humanos: Cliente, Usuário, Analista, Ferramentas de Software: Editor de TextoHardware: Micro-computador

Observação: Esta atividade pode ser iniciada em paralelo com o projeto.

VI.3. Treinamento de Usuário -1Pré-atividades: Elaboração da Documentação do Usuário -1Sub-atividades: não háArtefatos Insumo: Documentação para o Usuário, Sistema para OperaçãoArtefatos Produzidos: não háRecursos Necessários

Recursos Humanos: Instrutor Hardware: Plataforma de Operação do Sistema

Observação: As atividades marcadas com 1 (referente à primeira iteração do modelo incremental adotado) se repetem na segunda iteração, dando origem a novas atividades com a mesma definição. Vide Figura 1.

4. Equipe do Projeto

A equipe do projeto é composta pelos seguintes membros, atuando nos seguintes papéis:

Gerente de Projeto: Ricardo Cliente: Maria Usuários: Ana e Marcos Analistas de Sistemas: João e

Patrícia

Projetistas de Sistemas: José e Tadeu

Programador: José, Breno e Caio Engenheiro de Testes: Patrícia Grupo de Garantia da Qualidade:

Pedro, Celso e Ana

5. Estimativas

5.1 – Estimativa de Tamanho em Pontos de Função

Para a realização das estimativas de tamanho por pontos de função, foi considerada a abordagem da Contagem Estimativa da NESMA, pela qual o número de PFs não ajustados é dado por:

nPF = 7* nALI + 5* nAIE + 4* nEE + 5* nSE + 4*nCE.

Tomando por base o escopo definido na seção 2, temos o seguinte conjunto de funções:

Funções de Dados: 5 ALIs, 3 AIEs Livro (ALI) Exemplar (ALI) Assunto (ALI) Aluno (AIE) Professor (AIE) Funcionário (AIE) Empréstimo (ALI) Reserva (ALI)

Funções Transacionais: 13 EEs, 3 SEs, 5CEs Cadastrar Livro: Incluir (EE), Alterar (EE), Consultar (CE), Excluir (EE) Cadastrar Exemplar: Incluir (EE), Alterar (EE), Consultar (CE), Excluir (EE) Cadastrar Assunto: Incluir (EE), Alterar (EE), Consultar (CE), Excluir (EE) Consultar Acervo (SE) Gerar Relatório Gerencial para Aquisição de Livros (SE) Controlar Empréstimo: Novo Empréstimo (EE), Devolução (EE), Consulta (CE) Controlar Reserva: Nova Reserva (EE), Consulta (CE), Cancelamento (EE) Consultar Usuário (SE)

Assim, o número de PFs não ajustados para o sistema é:

nPF = 7* 5 + 5* 3 + 4* 13 + 5* 3 + 4* 5 = 137 PFs.

Serão tratadas na primeira iteração as funções destacadas em negrito. As demais serão tratadas na segunda iteração. Assim, o número de pontos de função por iteração é:

Primeira iteração: nPF = 7* 3 + 5* 0 + 4* 9 + 5* 1 + 4* 3 = 74 PFs (≈ 54%)Segunda iteração: nPF = 7* 2 + 5* 3 + 4* 4 + 5* 2 + 4* 2 = 63 PFs (≈ 46%)

5.2 – Estimativa de Esforço

Tomando-se por base dados de projetos similares realizados no LabES, tem-se um fator de produtividade de 4hh / PF. Esse fator de produtividade é para a classe de projetos com as seguintes características: requisitos bem definidos e estáveis, projeto modular, baixa complexidade e equipe inexperiente.

Usando o fator de produtividade estabelecido, chega-se à seguinte estimativa de esforço:

E = nPF * FP = 137 PFs * 4 hh/PF = 548hh

É importante distribuir esse esforço pelas atividades a serem realizadas, conforme definido no processo de software do projeto, apresentado na seção 3. Tomando por base uma distribuição média de esforço pelas principais atividade de desenvolvimento em projetos similares do LabES, a saber Gerência de Projeto ≈ 9%, Levantamento e Análise de Requisitos ≈ 22%, Projeto ≈ 25%, Implementação e Teste de Unidade ≈ 18% e Testes e Entrega ≈ 26%, chega-se à seguinte distribuição de esforço mostrada na Tabela 1:

Tabela 1 – Distribuição de esforço pelas principais atividades do processo.Gerência de

ProjetoLevantamento e

Análise de RequisitosProjeto Implementação e

Teste de UnidadeTestes e Entrega

50hh 120hh 136hh 100hh 142hh

Vale destacar que o esforço necessário para realizar as atividades do processo de garantia da qualidade está distribuído nas correspondentes atividades do processo de desenvolvimento.

Agora considerando o processo definido na seção 3, temos a Estrutura Analítica de Trabalho associada com o esforço requerido mostrada na Tabela 2. Vale destacar que, como foi adotado um modelo de ciclo de vida incremental, as atividades de planejamento, levantamento de requisitos, análise, projeto de dados e da arquitetura serão realizadas para o sistema como um todo. As demais serão realizadas para cada incremento (vide Figura 1 na seção 3).

Tabela 2 – Estrutura Analítica de Trabalho e Esforço Associado.Escopo Atividade Esforço

(hh)Todo Sistema Gerência do Projeto 50

Levantamento de Requisitos (incluindo Revisão) 60Análise de Requisitos (incluindo Revisão) 60Projeto de Dados e da Arquitetura (incluindo Revisão) 36

1ª Iteração Projeto Modular de Programas e Projeto de Interface – 1 (incluindo Elaboração do Documento de Especificação de Projeto e Revisão)

54

Implementação e Teste de Unidade – 1 54Testes e Entrega – 1 76

2ª Iteração Projeto Modular de Programas e Projeto de Interface – 2 (incluindo Elaboração do Documento de Especificação de Projeto e Revisão)

46

Implementação e Teste de Unidade – 2 46Testes e Entrega – 2 66

5.3 – Alocação de Recursos

Os membros da equipe do projeto foram alocados às atividades do processo de software definido na seção 3, conforme apresentado na Tabela 3. Nesta tabela, a dedicação dos envolvidos é apresentada com a seguinte legenda:

(TP) Dedicação de Tempo Parcial: até 4 horas por dia.(TI) Dedicação de Tempo Integral: até 8 horas por dia.

Tabela 3 – Tabela de Alocação de Recursos.Processo Atividade Papel PessoasDesenvolvimento Levantamento de

RequisitosAnalista Patrícia (TI)Cliente Maria (TP)Usuário Ana e Marcos (TP)

Análise de Requisitos Analista Patrícia (TP) e João (TI)

Cliente Maria (TP)Usuários Ana e Marcos (TP)

Projeto Analista João (TP)Projetista José (TI),

Tadeu (Projeto de Dados) (TI)

Programador Caio (TI)Cliente Maria (TP)Usuários Ana e Marcos (TP)

Implementação e Testes de Unidade

Programador Caio (TI)Projetista José (TP)

Testes de Integração e Validação e Entrega

Engenheiro de Testes

Patrícia (TI)

Analista João (TP)Projetista José (TP)Cliente Maria (TP)Usuários Ana e Marcos (TP)

Gerência de Projetos

Todas as atividades Gerente de Projeto Ricardo (TP)Analista Patrícia (TP)Cliente Maria (TP)

Garantia da Qualidade

Verificação e Validação de Requisitos

Grupo de Garantia da Qualidade

Pedro (TP)

Analista Patrícia (TP)Cliente Maria (TP)Usuário Ana e Marcos (TP)

Verificação e Validação de Análise

Grupo de Garantia da Qualidade

Pedro (TP)

Analista Patrícia (TP) e João (TP)

Cliente Maria (TP)Usuário Ana e Marcos (TP)

Verificação e Validação de Projeto

Grupo de Garantia da Qualidade

Pedro (TP)

Analista João (TP)Projetista José (TP) e Tadeu

(TP)Cliente Maria (TP)Usuário Ana e Marcos (TP)

5.4 – Estimativa de Duração

Uma vez estimado e distribuído o esforço total de desenvolvimento e alocados os recursos para as várias atividades do processo, é possível estimar a duração das atividades. O primeiro passo consiste em transformar as estimativas de esforço em estimativas de tempo cronológico (dias, por exemplo). Para tal, foi utilizada a distribuição de esforço por fases do processo mostrada na Tabela 2, na qual o esforço das atividades de garantia da qualidade está distribuído nas correspondentes atividades de desenvolvimento.

A Tabela 4 apresenta as estimativas de duração das atividades do processo de software. As atividades dos processos de gerência de projeto e de garantia da qualidade são destacadas em amarelo e verde, respectivamente. Além disso, tendo em vista que os esforços empreendidos por clientes e usuários não são contabilizados como parte do esforço de desenvolvimento, eles são apresentados apenas para registro da necessidade de dedicação e destacados em letras vermelhas. Finalmente, é bom lembrar que se considerou uma jornada de 8 horas por dia para se chegar aos valores da Tabela 4.

Tabela 4 – Atividades e Estimativas de Duração

Atividade Esforço Total (hh)

Esforço por Pessoa (h) Duração (em dias)

G1. Planejamento 14 Gerente de Projeto: 12 (TP)Analista: 1Projetista: 1Cliente: 4

3

D1. Levantamento de Requisitos

48 Analista: 48 (TI)Cliente: 6Usuários: 12

6

D2. Análise de RequisitosD2.1 – Modelagem de Dados 32 Analistas: 8 (TP) + 24 (TI)

Cliente: 2Usuários: 4

3

D2.2 – Modelagem de Estados

16 Analista: 4 (TP) + 12 (TI)Usuários: 2

1,5

D2.3 – Elaboração da Especificação de Análise

8 Analista: 8 (TI) 1

Q1. Verificação e Validação de Requisitos e Análise

16 Grupo de Garantia da Qualidade: 12 (TP)Analistas: 4 (TI)Cliente: 4Usuários: 8

3

G2. Acompanhamento de Projeto

4 Gerente de Projeto: 3 (TP)Analista: 1Cliente: 1

2

D3. ProjetoD3.1 – Projeto de Dados 20 Projetista: 16 (TI)

Analista: 4Cliente: 1Usuário: 2

2

D3.2 – Projeto da Arquitetura 16 Projetista: 12 (TI)Analista: 4Cliente: 1Usuário: 2

1,5

D3.3 – Projeto Modular de Programas e Projeto de Interface I

34 Projetista: 22 (TI)Programador: 12 (TP)Cliente: 4Usuários: 8

4

D3.4 – Elaboração da Especificação de Projeto I

8 Projetista: 8 (TI) 1

Q2. Verificação e Validação de Projeto I

12 Grupo de Garantia da Qualidade: 6 (TP)Analistas: 2 Projetista: 4Cliente: 4Usuários: 2 x 4 = 8

3

G3. Acompanhamento de Projeto

4 Gerente de Projeto: 3 (TP)Projetista: 1Cliente: 1

2

D4. Implementação e Testes de Unidade I

54 Programador: 40Projetista: 14

5

G4. Acompanhamento de Projeto

4 Gerente de Projeto: 3 (TP)Programador: 1Cliente: 1

2

D5. Testes de Integração e Validação I

38 Engenheiro de Teste: 30Projetista: 4Analista: 4Cliente: 4Usuários: 8

4

D6. Entrega I 38 Engenheiro de Teste: 20Analista: 18Cliente: 8Usuários: 12

7

G5. Acompanhamento de Projeto

4 Gerente de Projeto: 3 (TP)Projetista: 1Cliente: 1

2

D7. Projeto IID7.1 - Projeto Modular de Programas II e Projeto de Interface com o Usuário II

34 Projetista: 22 (TI)Programador: 12 (TP)Cliente: 2Usuários: 6

3

D7.2 – Elaboração da Especificação de Projeto II

4 Projetista: 4 (TI) 0,5

Q3. Verificação e Validação de Projeto II

8 Grupo de Garantia da Qualidade: 4 (TP)Analistas: 1 Projetista: 3Cliente: 3Usuários: 6

3

G6. Acompanhamento de Projeto

4 Gerente de Projeto: 3 (TP)Projetista: 1Cliente: 1

2

D8. Implementação e Testes de Unidade II

46 Programador: 36Projetista: 10

4,5

G7. Acompanhamento de Projeto

4 Gerente de Projeto: 3 (TP)Programador: 1Cliente: 1

2

D9. Testes de Integração e Validação II

32 Engenheiro de Teste: 24Projetista: 4Analista: 4Cliente: 2Usuários: 6

4

D10. Entrega II 34 Engenheiro de Teste: 18Analista: 16Cliente: 4Usuários: 6

5

G8. Encerramento do Projeto 12 Gerente de Projeto: 6 (TP)Analista: 2Projetista: 2Programador: 2

2

Para se definir o caminho crítico do projeto, a rede de tarefas mostrada na Figura 2 foi elaborada. Com base nessa rede, pode-se perceber que o tempo cronológico do projeto é de, no mínimo, 59,5 dias úteis.

Figura 2 – Rede de Tarefas.

Finalmente, a Tabela 5 mostra o cronograma do projeto na forma de um Gráfico de Gantt. Para se trabalhar com uma margem de segurança, estabeleceu-se como prazo limite 13 semanas (65 dias úteis) contados da data de início do projeto. Na Tabela 5, as entradas para o acompanhamento de projeto são marcadas com a letra A.

3

Q1

3G1 D1

Início

3 6D2.1 D2.2

1,5D2.3

1

D3.12

D3.21,5

D3.34

G22

G3 G4 G5 G6 G7

Q2

3

2 2

4

2 2 2

D3.41

D45

D5 D67

D7.13

D7.2

Q3

3

0,5D8

4,5

D94

D105

G82 0

Fim

Tabela 5 – Cronograma do ProjetoAtividade Semana

1 2 3 4 5 6 7 8 9 10 11 12 13G1. Planejamento xxxD1.Levantamento de Requisitos xx xxxxD2.1- Modelagem de Dados xxx xxD2.2- Modelagem de Estados xx D2.3- Elaboração Esp. Análise xAQ2. V&V Análise x xxD3.1- Projeto de Dados xxD3.2- Projeto da Arquitetura xxD3.3- Projeto Modular e de IU I x xxxD3.4- Elaboração Esp. Projeto I xAQ3- V&V Projeto x xxD4. Implementação/ Teste Unid I x xxxxAD5. Testes Integração/Validação I x xxxD6. Entrega I xx xxxxx AD7.1. Projeto Modular e de IU II xxxD7.2- Elaboração Esp. Projeto II xA Q4- V&V Projeto II x xxD8. Implementação/ Teste Unid II xx xxxAD9. Testes Integração/ValidaçãoII xx xxD10. Entrega II xxx xxG8. Encerramento xx

6. Plano de Gerência de Configuração

Os seguintes artefatos terão sua configuração gerenciada:

Plano de Projeto Documento de Especificação de Requisitos Documento de Especificação de Análise Documento de Especificação de Projeto