Exemplo - Documentacao de Sistema 000207 - 198631

UNIVERSIDADE FEDERAL DE VIÇOSA
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGICAS

DEPARTAMENTO DE INFORMÁTICA
Mestrado em Ciência da Computação
Documentação de Sistema
EasyPSP
Autores:
André Luiz de Castro Leal
Marcelo Santos Daibert
Viçosa
Minas Gerais – Brasil
Abril / 2007
EasyPSP – Documentação de Sistema 0
Folha de Aprovação
Aprovamos o documento aqui apresentado para o desenvolvimento do

software EasyPSP.
Andre Castro Equipe de Desenvolvimento ________________________
Marcelo S. Daibert Equipe de Desenvolvimento ________________________
Comissão Cliente Cliente ________________________
Auditoria Externa Cliente ________________________
Revisões Anteriores
Revisor Descrição Data

André Castro Primeira Elaboração 24/04/2007
Marcelo Daibert Re-formatação do Documento 26/04/2007
Marcelo Daibert Definição das Limitações, Clientes e Equipe 27/04/2007
Marcelo Daibert Requisitos Específicos RF1 – RF15 30/04/2007
Equipe Matriz de Rastreabilidade e de Dependência 30/04/2007
Equipe Planejamento 30/04/2007
Equipe Especificação de Casos de Uso 30/04/2007
Marcelo Daibert Matriz de Rastreabilidade: Funcional x N Funcional 20/05/2007
Marcelo Daibert Diagrama de Seqüência: UC1 -> UC6 20/05/2007
André Castro Diagrama de Seqüência: UC7 -> UC13 20/05/2007
Equipe Diagrama de Classes 20/05/2007
André Castro Gerência de Projetos: EAP, Gráfico de Gantt, Diagrama 20/05/2007
de Precedências
Marcelo Daibert Formatação do Documento 20/05/2007
Marcelo Daibert Verificação de Entrega Fase 2 20/05/2007
Marcelo Daibert Acerto de textos de descrição dos casos de uso 20/05/2007
Equipe Definição de Métodos e Atributos das Classes 21/05/2007
André Castro Definição dos Contratos do Sistema 16/06/2006
Marcelo Daibert Formatação da Documentação 16/06/2006
Marcelo Daibert Definição das Exceções dos Contratos do Sistema 16/06/2006
Marcelo Daibert Definição do Mapeamento Objeto Relacional 14/07/2007
Marcelo Daibert Diagrama de Tabelas Relacionais e Script SQL 14/07/2007
André Castro Protótipo das Interfaces 14/07/2007
Marcelo Daibert Navegação das Interfaces 15/07/2007
Sumário
1 INTRODUÇÃO ......................................................................................................... 5
1.1 Propósito do Documento .......................................................................................... 5
1.2 Escopo ...................................................................................................................... 5
1.3 Definições e Siglas ................................................................................................... 5
1.4 Contratantes ............................................................................................................. 5
2 DESCRIÇÃO GERAL ............................................................................................... 7

2.1 Visão Geral do Produto ............................................................................................ 7
2.2 Perspectivas do Produto ........................................................................................... 7
2.3 Funções do Produto ................................................................................................. 7
2.4 Componentes de Evolução do Produto .................................................................... 7
2.5 Limitações do Produto .............................................................................................. 7
2.6 Usuários do Sistema ................................................................................................. 8
3 REQUISITOS ESPECÍFICOS .................................................................................. 9

3.1 Requisitos Funcionais ............................................................................................... 9
3.2 Requisitos Não Funcionais ..................................................................................... 12
4 MATRIZ DE RASTREABILIDADE ......................................................................... 14

4.1 Requisitos Funcionais x Requisitos Funcionais ...................................................... 14
4.2 Requisitos Funcionais x Requisitos Não Funcionais .............................................. 14
5 DIAGRAMA DE CASOS DE USO.......................................................................... 15
6 MATRIZ DE DEPENDÊNCIA ................................................................................. 18

6.1 Caso de Uso x Requisitos Funcionais .................................................................... 18
6.2 Caso de Uso x Requisitos Não Funcionais ............................................................ 18
7 PLANEJAMENTO .................................................................................................. 19
7.1 Equipe de Desenvolvimento ................................................................................... 19
7.2 Ciclos de Desenvolvimento .................................................................................... 19
7.3 Cronograma ............................................................................................................ 20
7.4 Gráfico de Gantt ..................................................................................................... 21
7.5 EAP – Estrutura Analítica do Projeto (WBS – Work Breakdown Structure) ........... 22
7.6 Seqüências de Atividades – Diagrama de Precedências ....................................... 23
8 ESPECIFICAÇÃO DE CASOS DE USO ................................................................ 24
8.1 UC1 – Caso de Uso: Gerir Projetos .................................................................... 24
8.2 UC2 – Caso de Uso: Definir Nível PSP ............................................................... 28
8.3 UC3 – Caso de Uso: Definir Fase do Projeto ...................................................... 30
8.4 UC4 – Caso de Uso: Mudar Status da Fase ....................................................... 32
8.5 UC5 – Caso de Uso: Gerir Planejamento ........................................................... 33
8.6 UC6 – Caso de Uso: Gerir Tempo ...................................................................... 36
8.7 UC7 – Caso de Uso: Contabilizar Automaticamente .......................................... 39
8.8 UC8 – Caso de Uso: Contabilizar Manualmente ................................................. 40
8.9 UC9 – Caso de Uso: Totalizar Tempo ................................................................ 42
8.10 UC10 – Caso de Uso: Gerir Defeitos .................................................................. 44
8.11 UC11 – Caso de Uso: Contabilizar LOC ............................................................. 48
8.12 UC12 – Caso de Uso: Gerar Estatísticas ............................................................ 50
8.13 UC13 – Caso de Uso: Gerar Gráficos ................................................................. 51
9 MODELAGEM CONCEITUAL ............................................................................... 54

9.1 Modelo MVC (Model View Controller) .................................................................... 54
9.2 Diagrama de Classes (Interfaces e Controladores) ................................................ 54
9.3 Diagrama de Classes (Modelo) .............................................................................. 55
9.4 Atributos e Métodos das Classes de Domínio ........................................................ 56
9.5 Mapeamento Objeto-Relacional – Diagrama de Tabelas Relacionais ................... 59
10 Contratos do Sistema ........................................................................................... 60
11 PROTÓTIPOS DE INTERFACE ............................................................................. 71

11.1 Navegação Entre Interfaces ................................................................................. 71
11.2 Protótipos.............................................................................................................. 72
12 CÓDIGO FONTE SUGERIDO ................................................................................. 75

12.1 SQL Base de Dados ............................................................................................. 75
13 BIBLIOGRAFIA ...................................................................................................... 78
1. Introdução
1.1. Propósito do Documento
O propósito deste documento é descrever e especificar uma ferramenta de

apoio níveis 0 e 0.1 do Personal Software Process (PSP) proposto pelo Software
Engineering Institute (SEI) para fins de produção de um software, cuja primeira versão
será denominada EasyPSP 1.0.
1.2. Escopo
O objetivo do EasyPSP é fornecer de forma organizada, centralizada e

automatizada as informações necessárias para atender a principal demanda do PSP:
melhoria na qualidade pessoal dos engenheiros e desenvolvedores de software.
PSP0: estabelecimento de práticas de medida e alguns formatos de
relatórios que constituirão uma base (baseline) ou fundação sobre a qual será
implantada a melhoria contínua pessoal: não afeta métodos e práticas pessoais de
design, codificação e teste (apenas serão medidos).
O PSP0.1: acrescenta padrões de programação, práticas de medida de
tamanho de produto de trabalho e o Process Improvement Proposal (PIP — Proposta
de Melhoria de Processo). PIP é uma forma estruturada de registrar problemas nos
processos, experiências e propostas de melhoria
Esse sistema deverá permitir o controle e consulta dos seguintes itens da
etapa de desenvolvimento do projeto:
• relação de projetos desenvolvidos pelos engenheiros de software;
• contagem de tempo de desenvolvimento e paradas;
• registro de erros encontrados;
• contagem de linhas de código de programas desenvolvidos;
• planejamento de tempo de programação e número de linhas do projeto.
• gráficos comparativos de planejamento e realizado.
1.3. Definições e Siglas
EasyPSP Nome dado ao sistema computacional

PSP 0 Engloba registro de tempo, defeitos e padrão de tipos de defeitos
PSP 0.1 Engloba padrão de codificação, medida de tamanho e proposta
de melhoramento de processo
HD Disco rígido.
RAM Memória principal.
MB Megabytes.
MHz Megahertz.
LOC Lines of Code – Linhas de Código.
DTO Data Transfer Objects – Estrutura para Transferência dos Dados
de um Objeto ou vários Objetos.
1.4. Contratantes
O consorcio de empresas denominado TABATA Trust é a solicitante deste

sistema para gestão do PSP nível 0 e 0.1.
Empresas do consórcio e seus representantes:
• Mycro$oft Corporation – Bill Gitus
• TABA Consultancy – Still CCMI
• IBMuitos – Jonh Stuwart
• SunLinux – Bobin BreWindows
2. Descrição Geral
2.1. Visão Geral do Produto
Por definição do SEI, o PSP em seu níves 0 e 0.1 tem por metas medir o
desempenho atual do engenheiro de software a fim de se auxiliar no gerenciamento de
projetos. Portanto, o EasyPSP fará os controles do processo atual de
desenvolvimento, medições básicas de padrões de codificação, propostas de
melhoria, estimativas de tempo e comparações por meio de gráficos de tempos
planejados e realizados.
2.2. Perspectivas do Produto
• O EasyPSP deverá ser desenvolvido em módulo único.

• Deve ser utilizado o sistema de gestão de bancos de dados integrado
(HSQLDB).
• Melhoria do planejamento de tempo das fases do projeto.
• Melhoria na implementação de rotinas de testes.
• Previsão de possíveis defeitos.
• Melhoria no planejamento do número de linhas de código do sistema.
• Meio de auto-avaliação do usuário.
• Possibilita uma melhor documentação do processo por parte do usuário.
2.3. Funções do Produto
• Gestão de Projetos;
• Gestão de Tempo;
• Gestão de Erros;
• Gestão Linhas de Código;
• Impressão de gráficos;
2.4. Componentes de Evolução do Produto
O desenvolvimento deste sistema será realizado levando em consideração

a possível necessidade de integração com outras bases de dados de outros usuários,
a fim de comparar os dados e mais futuramente ter o seu uso em equipe, seguindo o
modelo do TSP.
Minimizar o acoplamento da camada de persistência do sistema, podendo
então alterar este mecanismo facilmente. Suportar futuramente base de dados cliente
servidor, objetivando a utilização de uma única base para vários usuários.
Desenvolvimento baseado em camadas. Neste nível macro, sendo as
seguintes definidas: Camada de Visão, Camada de Controle, Camada de Lógica de
Negócio, Camada de Modelo, Camada de Persistência e Base de Dados.
2.5. Limitações do Produto
O sistema EasyPSP é um sistema independente. Ele será apresentado em

interface própria para o usuário e em bandeja de sistema. É limitado ao nível 0 e 0.1
do PSP.
2.6. Usuários do Sistema
O EasyPSP é desenvolvido para a utilização por desenvolvedores de

software (usuários – programadores, desenvolvedores, engenheiros de software,
analistas de software, arquitetos de software, entre outros).
É aplicado ao uso dos funcionários da empresa consórcio contratante.
3. Requisitos Específicos
3.1. Requisitos Funcionais
Requisito Funcional 1: O sistema deve permitir ao desenvolvedor a

inclusão, alteração, consulta, exclusão e clonagem dos dados do projeto no qual o irá
desenvolver.
Requisitos de Dados: nome do desenvolvedor, nome do projeto e status do
projeto.
RF1: Gerir Projetos Estado: Proposto

Prioridade: Alta Estabilidade: Alta
Descrição: O sistema deve permitir a manutenção dos dados do projeto. Para iniciar a
utilização do software, o desenvolvedor necessita cadastrar o seu projeto.
Requisito Funcional 2: O sistema deve permitir ao desenvolvedor a escolha

do nível do PSP que será utilizado no projeto. O desenvolvedor poderá mudar a
qualquer hora o nível do PSP definido – RNRF2.
Requisitos de Dados: Duas opções de escolha: PSP 0 e PSP 0.1.
RF2: Definir Nível PSP Estado: Proposto

Descrição: O sistema deve permitir a escolha do nível do PSP a ser utilizado no
projeto criado ou escolhido.
Regra de Negócio RNRF2: O desenvolvedor poderá mudar o nível de PSP quando o
mesmo já fora definido, sem a perda de possíveis dados já cadastrados. Os dados já
cadastrados ficarão disponíveis de acordo com os requisitos das fases de cada nível
PSP.
Requisito Funcional 3: O sistema deve permitir ao desenvolvedor a escolha

da fase do projeto, de acordo com o nível PSP definido. O desenvolvedor poderá
voltar a qualquer fase, mesmo que já finalizada – RNRF3.
Requisitos de Dados: Fases: Planejamento, Projeto, Codificação,
Compilação, Teste, Postmorten.
RF3: Definir Fase do Projeto Estado: Proposto

Descrição: O sistema deve permitir a escolha da fase do projeto, de acordo com o
nível PSP definido.
Regra de Negócio RNRF3: O desenvolvedor poderá voltar a qualquer fase a qualquer
momento, mesmo que a fase já esteja finalizada.
Requisito Funcional 4: O sistema deve permitir ao desenvolvedor a

definição de finalizada ou não finalizada de cada fase do projeto. O desenvolvedor
poderá reabrir uma fase já finalizada – RNRF4.
RF4: Mudar Status da Fase Estado: Proposto

Prioridade: Baixa Estabilidade: Alta
Descrição: O sistema deve permitir a definição de status de cada fase do projeto.
Regra de Negócio RNRF4: O desenvolvedor poderá reabrir uma fase já finalizada.
Requisito Funcional 5: O sistema deve permitir ao desenvolvedor a iniciar
um relógio automático de contagem de tempo para cada fase do projeto, permitindo ao
final cadastrar o que foi realizado no tempo contabilizado.
Requisitos de Dados: Hora de início, hora final e descrição.
RF5: Contabilizar Automaticamente o Tempo Estado: Proposto

Descrição: O sistema deve permitir ao desenvolvedor a iniciar um relógio automático
de contagem de tempo para cada fase do projeto, permitindo ao final cadastrar o que
foi realizado no tempo contabilizado.
Requisito Funcional 6: O sistema deve permitir ao desenvolvedor a incluir

manualmente, editar e excluir os registros de tempo contabilizado de cada fase do
projeto.
RF6: Gerir Tempo Estado: Proposto

Prioridade: Média Estabilidade: Alta
Descrição: O sistema deve permitir ao desenvolvedor a incluir manualmente, editar e
excluir os registros de tempo contabilizado de cada fase do projeto.
Requisito Funcional 7: O sistema deve totalizar os tempos contabilizados

por cada fase do projeto, exibindo o tempo gasto em cada fase e no projeto todo.
RF7: Totalizar Tempo Contabilizado Estado: Proposto

Descrição: O sistema deve totalizar os tempos contabilizados por cada fase do
projeto, exibindo o tempo gasto em cada fase e no projeto todo.
Requisito Funcional 8: O sistema deve permitir ao desenvolvedor cadastrar

os defeitos (bugs) encontrados durante as fases de desenvolvimento de cada projeto
em separado. Pode inclusive fazer uma referência cruzada a outro defeito já
cadastrado. Neste caso, o defeito a ser cadastrado foi inserido por recorrência do
defeito anterior. O sistema deve contabilizar o tempo de forma automática ao cadastrar
o defeito.
Requisitos de Dados: Tipo de defeitos (documentação, sintaxe,
compilação, lógica, interface, versionamento, checagem, condicionais, funções,
sistema, linguagem e ambiente), defeito de referência cruzada (não obrigatório),
defeito inserido em qual fase do projeto, defeito removido em qual fase do projeto,
tempo para conserto e descrição.
RF8: Cadastrar Defeitos Estado: Proposto

Descrição: O sistema deve permitir ao desenvolvedor cadastrar os defeitos (bugs)
encontrados durante as fases de desenvolvimento de cada projeto em separado.
Requisito Funcional 9: O sistema deve permitir ao desenvolvedor
visualizar, editar e excluir os defeitos (bugs) cadastrados durantes as fases de cada
projeto em separado.
Requisitos de Dados: Tipo de defeitos (documentação, sintaxe,
compilação, lógica, interface, versionamento, checagem, condicionais, funções,
sistema, linguagem e ambiente), defeito de referência cruzada (não obrigatório),
defeito inserido em qual fase do projeto, defeito removido em qual fase do projeto,
tempo para conserto e descrição.
RF9: Gerir Defeitos Estado: Proposto

Descrição: O sistema deve permitir ao desenvolvedor visualizar, editar e excluir os
defeitos (bugs) cadastrados durantes as fases de cada projeto em separado.
Requisito Funcional 10: O sistema deve permitir ao desenvolvedor

cadastrar o seu planejamento pessoal de tempo para cada fase do projeto e do
número de linhas de código do sistema. Estes dados serão utilizados para
comparação ao final do projeto com os números reais.
Requisitos de Dados: Tempo planejado para cada fase de acordo com o
nível PSP definido. Número de linhas (LOC) de código do sistema.
RF10: Gerir Planejamentos Estado: Proposto

Descrição: O sistema deve permitir ao desenvolvedor cadastrar o seu planejamento
pessoal de tempo para cada fase do projeto e do número de linhas de código do
sistema.
Requisito Funcional 11: O sistema deve fornecer ao desenvolvedor uma

interface para visualização do planejamento pessoal com os números reais
contabilizados. Deve permitir visualizar esta interface mesmo que as fases ou projetos
não tenham sido finalizados.
Requisitos de Dados: Tempo de desenvolvimento de cada fase de acordo
com o nível PSP definido. Número de linhas (LOC) de código do sistema.
RF11: Visualizar Planejamento x Real Estado: Proposto

Descrição: O sistema deve fornecer ao desenvolvedor uma interface para
visualização do planejamento pessoal com os números reais contabilizados.

interface para contabilizar de forma automática o número de linhas de código
existentes no sistema. O sistema contabilizará como uma nova linha de código, toda
linha de código existente no arquivo fonte, desde que não seja uma linha em branco –
RNRF12.
RF12: Contabilizar Linhas de Código Estado: Proposto

Descrição: O sistema deve fornecer ao desenvolvedor uma interface para contabilizar
de forma automática o número de linhas de código existentes no sistema.
Regra de Negócio RNRF12: Será contabilizado como uma nova linha de código, toda
linha de código existente no arquivo fonte, desde que não seja uma linha em branco.
interface para visualização de estatísticas dos defeitos cadastrados. Número e
porcentagem de defeitos inseridos e retirados em cada fase do projeto. Porcentagem
do tipo de defeito.
RF13: Gerar Estatísticas de Defeitos Cadastrados Estado: Proposto

visualização de estatísticas dos defeitos cadastrados.

interface para visualização conjunta das estatísticas de todos os projetos cadastrados.
A finalidade é gerar uma estatística pessoal de desenvolvimento de software seguindo
o PSP. Comparativo entre planejamento e realidade cadastrada no sistema, incidência
de defeitos, tipos de defeitos, local de incidência de defeitos, tempo de
desenvolvimento médio por fase, linhas de código por hora na fase de codificação.
RF14: Gerar Estatísticas de Projetos Cadastrados Estado: Proposto

visualização conjunta das estatísticas de todos os projetos cadastrados.

interface para gerar gráficos comparativos das horas planejadas e trabalhadas de
cada projeto e de todos os projetos cadastrados juntos. Gráfico comparativo entre
planejamento e realidade cadastrada no sistema, incidência de defeitos, tipos de
defeitos, local de incidência de defeitos, tempo de desenvolvimento médio por fase,
linhas de código por hora na fase de codificação.
RF15: Gerar Gráficos Estado: Proposto

Descrição: O sistema deve fornecer ao desenvolvedor uma interface para gerar
gráficos comparativos das horas planejadas e trabalhadas de cada projeto e de todos
os projetos cadastrados juntos.
3.2. Requisitos Não Funcionais
Requisito Não Funcional 1: O sistema deve utilizar um sistema gerenciador

de bancos de dados que possibilite a integração ao sistema a ser desenvolvido
(HSQLDB).
RNF1: Banco de Dados Estado: Proposto

Prioridade: Alta Estabilidade: Baixa Obrigatório
Descrição: O sistema deve utilizar um sistema gerenciador de bancos de dados que
possibilite a integração ao sistema a ser desenvolvido.
Requisito Não Funcional 2: O sistema deve possibilitar que todos os
relatórios e/ou gráficos sejam pré-visualizados antes do envio para a impressora.
RNF2: Pré-Visualização Estado: Proposto

Prioridade: Baixa Estabilidade: Baixa Desejável
Descrição: O sistema deve possibilitar que todos os relatórios e/ou gráficos sejam pré-
visualizados antes do envio para a impressora.
Requisito Não Funcional 3: O sistema deve possuir alta usabilidade,

constituindo facilidade para que os usuários aprendam a operá-lo, tempo e esforço
mínimos para que os usuários atinjam um nível aceitável de desempenho, mínimo
esforço físico e cognitivo dos usuários durante o processo de interação,
disponibilização de help e interfaces auto-explicativas e satisfação dos usuários.
RNF3: Usabilidade Estado: Proposto

Prioridade: Média Estabilidade: Média Desejável
Descrição: O sistema deve possuir alta usabilidade.
Requisito Não Funcional 4: O sistema deve ser desenvolvido utilizando a

linguagem JAVA.
RNF4: Linguagem Estado: Proposto

Prioridade: Alta Estabilidade: Alta Obrigatória
Descrição: O sistema deve ser desenvolvido utilizando a linguagem JAVA.
Requisito Não Funcional 5: O sistema deve ser desenvolvido utilizando

uma interface semelhante à uma pequena barra fina, com ícone na bandeja de
sistema, para que o desenvolvedor possa manipular a interface com facilidade sem
encher a tela do computador.
RNF5: Interface Pequena Estado: Proposto

Prioridade: Alta Estabilidade: Alta Obrigatória
Descrição: O sistema deve ser desenvolvido utilizando uma interface semelhante à
uma pequena barra fina, com ícone na bandeja de sistema, para que o desenvolvedor
possa manipular a interface com facilidade sem encher a tela do computador.
4. Matriz de Rastreabilidade
4.1. Requisitos Funcionais x Requisitos Funcionais
RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF9 RF10 RF11 RF12 RF13 RF14 RF15
RF1
RF2 x
RF3 x
RF4 x
RF5 x
RF6 x
RF7 x x x
RF8 x
RF9 x
RF10 x
RF11 X
RF12 x
RF13 x x
RF14 x x x x x x x x x x x
RF15 x x x x x x x x x x x
4.2. Requisitos Funcionais x Requisitos Não Funcionais
RNF1 x x x x x x x x x x x x x x x
RNF2 x x x x
5. Diagrama de Casos de Uso
UC1: Gerir Projetos

Ator: Desenvolvedor
Descrição: O caso de uso é utilizado para descrever a primeira ação do
desenvolvedor do sistema para assim incluir os dados do projeto no qual irá trabalhar.
O objetivo deste caso de uso é possibilitar que ocorra a definição do nível de PSP
utilizado para o projeto cadastrado.
UC2: Definir Nível PSP

Ator: Desenvolvedor
Descrição: O caso de uso é utilizado para definir o nível de PSP ao qual o projeto se
encontra. O objetivo deste caso de uso é possibilitar a utilização completa do sistema,
compreendendo a definição de fase do projeto, mudança de status de fase,
gerenciamento de planejamento, tempo, defeitos, contabilização de linhas de código,
geração de estatísticas e gráficos.
UC3: Definir Fase do Projeto

Ator: Desenvolvedor
Descrição: O caso de uso é o utilizado definir a fase (Planejamento, Projeto,
Codificação, Compilação, Teste, Postmortem) que determinado projeto se encontra.
O objetivo deste caso de uso é possibilitar ao desenvolvedor identificar qual fase do
nível de PSP o projeto esta sendo desenvolvido, proporcionando o gerenciamento de
erros e tempo.
UC4: Mudas Status de Fase
Ator: Desenvolvedor
Descrição: O caso de uso é iniciado quando o desenvolvedor solicita ao sistema a
modificação do status da fase (concluído ou em andamento) do projeto. O objetivo
deste caso de uso é possibilitar ao desenvolvedor finalizar ou reabrir uma
determinada fase do projeto.
UC5: Gerir Planejamento

Ator: Desenvolvedor
gestão de planejamento pessoal ao sistema. O objetivo deste caso de uso é
possibilitar ao desenvolvedor cadastrar o planejamento de tempo a ser gasto em cada
fase do projeto e o número final de linhas de código fonte.
UC6: Gerir Tempo

Ator: Desenvolvedor
Descrição: O caso de uso é utilizado para descrever a ação do usuário de
cadastramento dos tempos de parada no sistema em cada fase do projeto. O objetivo
deste caso de uso é possibilitar que ocorra a inclusão de cursos no sistema, a
consulta, a alteração ou a exclusão daqueles já existentes.
UC7: Contabilizar Automaticamente

Ator: Desenvolvedor
Descrição: O caso de uso é iniciado quando o desenvolvedor inicia o relógio
automático para contabilização do tempo de acordo com a fase escolhida. O objetivo
deste caso de uso é prover uma interface para inserção automática dos tempos
medidos de acordo com as atividades exercidas dentro das fases do projeto.
UC8: Contabilizar Manualmente

Ator: Desenvolvedor
inserção manual de um tempo em alguma fase do projeto. O objetivo deste caso de
uso é prover uma interface para inserção manual dos tempos medidos de acordo com
as atividades exercidas dentro das fases do projeto.
UC9: Totalizar Tempo

Ator: Desenvolvedor
Descrição: O caso de uso é iniciado quando o desenvolvedor entra na interface de
gestão de tempo. O objetivo deste caso de uso é totalizar os tempos já cadastrados
de cada fase e totalizar o tempo das fases.
UC10: Gerir Defeitos

Ator: Desenvolvedor
interface de cadastro ou gestão de defeitos. O objetivo deste caso de uso fornecer ao
desenvolvedor uma interface para o cadastro de defeitos e sua manutenção
(visualização, alteração e exclusão).
UC11: Contabilizar LOC

Ator: Desenvolvedor
interface de contabilização de linhas de código. O objetivo deste caso de uso fornecer
ao desenvolvedor uma interface para adicionar os arquivos de código fonte para que
o sistema calcule o número de linhas de código automaticamente.
UC12: Gerar Estatísticas
Ator: Desenvolvedor
geração de estatísticas do projeto ou de todos os projetos cadastrados. O objetivo
deste caso de uso fornecer ao desenvolvedor uma interface gerar, analisar e
comparar as estatísticas dos projeto cadastrados. Número e porcentagem de defeitos
inseridos e retirados em cada fase do projeto. Porcentagem do tipo de defeito.
Comparativo entre planejamento e realidade cadastrada no sistema, incidência de
defeitos, tipos de defeitos, local de incidência de defeitos, tempo de desenvolvimento
médio por fase, linhas de código por hora na fase de codificação.
UC13: Gerar Gráficos

Ator: Desenvolvedor
geração de gráficos do projeto ou de todos os projetos cadastrados. O objetivo deste
caso de uso fornecer ao desenvolvedor uma interface gerar, analisar e comparar as
estatísticas dos projeto cadastrados. Número e porcentagem de defeitos inseridos e
retirados em cada fase do projeto. Porcentagem do tipo de defeito. Comparativo entre
6. Matriz de Dependência
6.1. Casos de Uso x Requisitos Funcionais
UC1 x
UC2 x
UC3 X
UC4 x
UC5 x x x x
UC6 x x x
UC7 x
UC8 x
UC9 x
UC10 x x
UC11 x
UC12 x x x
UC13 x
6.2. Casos de Uso x Requisitos Não Funcionais
UC1 UC2 UC3 UC4 UC5 UC6 UC7 UC8 UC9 UC10 UC11 UC12 UC13
RNF1 x x x x x x x x x x x x x
RNF2 x x
7. Planejamento
7.1. Equipe de Desenvolvimento
Nome Função Valor / Hora

Andre Castro Analista de Sistema / Desenvolvedor R$22,00
Marcelo Daibert Analista de Sistema / Desenvolvedor R$22,00
7.2. Ciclos de Desenvolvimento
A documentação e projeto do sistema será desenvolvido em 4 fases. A

fase 1, contemplará a análise de requisitos, definição dos casos de uso e sua
especificação. A fase 2 apresentará os diagramas de classe e de sequência. Já a fase
3, apresentará os contratos do sistema e o projeto da camada de domínio. Por fim, na
fase 4, serão apresentados os projetos de interface, da camada de persistência e
geração de código fonte.
Para a construção do sistema, serão utilizados 3 ciclos iterativos de 3
semanas (15 dias úteis) e um ciclo final de testes funcionais e de interações entre as
funcionalidades. Os casos de uso com menor índice de dependência na matriz de
dependência serão desenvolvidos primeiros e os demais serão desenvolvidos
seguindo o fluxo da proposta do PSP.
Em cada fase de entrega do sistema, os ciclos definidos serão percorridos
de forma iterativa para sua definição e refinamento.
Ciclo 1
UC1: Gerir Projetos 16h
UC2: Definir Nível PSP 16h
Casos de Uso
UC3: Definir Fase do Projeto 16h
UC4: Mudas Status de Fase 16h
Esforço Estimado Total 64h
Ciclo 2
UC5: Gerir Planejamento 24h
UC6: Gerir Tempo 24h
Casos de Uso UC7: Contabilizar Automaticamente 16h
UC8: Contabilizar Manualmente 16h
UC9: Totalizar Tempo 12h
Esforço Estimado Total 92h
Ciclo 3
UC10: Gerir Defeitos 24
UC11: Contabilizar LOC 64
Casos de Uso
UC12: Gerar Estatísticas 48
UC13: Gerar Gráficos 48
Esforço Estimado Total 184
7.3. Cronograma
7.4. Gráfico de Gantt
7.5. EAP – Estrutura Analítica do Projeto (WBS - Work Breakdown Structure)
7.6. Seqüências de Atividades – Diagrama de Precedências
8. Especificação de Casos de Uso
8.1. UC1 – Caso de Uso: Gerir Projetos
Gerir Projetos
Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é utilizado para descrever a primeira ação do desenvolvedor do sistema
para assim incluir os dados do projeto no qual irá trabalhar. O objetivo deste caso de
uso é possibilitar que ocorra a definição do nível de PSP utilizado para o projeto
cadastrado.
Pré-Condições:
Não Aplicável.
Fluxo Principal:
1. O sistema exibe a tela de projetos.
2. O sistema executa o subfluxo Pesquisa Projeto.
Fluxos Alternativos:
Não Aplicável.
Subfluxo: Operação Incluir

1. O desenvolvedor abre o formulário de Novo Projeto com todos os campos
habilitados;
2. O sistema solicita a entrada dos seguintes dados: nome do desenvolvedor,
descrição do projeto e status do projeto (concluído ou andamento);
3. O desenvolvedor informa ao sistema os dados solicitados;
4. O desenvolvedor confirma os dados informados;
5. O sistema efetua a validação dos dados (RN1 e RN2);
6. O sistema cadastra o projeto.
Subfluxo: Operação Alterar/Visualizar/Excluir

1. O sistema efetua a leitura do registro a partir do projeto escolhido.
2. O sistema exibe os dados do projeto escolhido (nome do desenvolvedor,
descrição do projeto e status do projeto);
3. Se desejar, o desenvolvedor tem a opção de alterar os dados do projeto ou
excluí-lo;
4. O sistema altera ou exclui os dados cadastrais do projeto selecionado.
Subfluxo: Pesquisa Projeto

1. O desenvolvedor aciona o comando Projetos;
2. O sistema exibe os projetos já inseridos (nome do desenvolvedor, descrição do
projeto e status (concluído ou em andamento));
3. O sistema apresenta opções para incluir e alterar/visualizar/excluir os projetos.
Fluxos de Exceção:
1. A descrição do projeto, nome do desenvolver e/ou status não foram
preenchidos. Sistema exibe uma mensagem e retorna ao formulário Novo Projeto;
2. Alteração de registro alterado. Sistema exibe uma mensagem informando que
a operação não pode ser realizada indicando o motivo do cancelamento da operação;
3. Alteração de registro excluído. Sistema exibe uma mensagem informando que
4. Exclusão de registro alterado. Sistema exibe uma mensagem informando que a
operação não pode ser realizada indicando o motivo do cancelamento da operação.
Requisitos de interface:
1. Os projetos devem ser exibidos por meio de uma lista de projetos em ordem
alfabética crescente. O desenvolvedor poderá alterar a ordem de classificação dos
projetos na lista;
2. O desenvolvedor poderá pesquisar por descrição de projetos e por status;
3. O status do projeto deve ser exibido em uma caixa de combinação;
4. O nome do desenvolvedor e a descrição do projeto devem estar dispostos em
controles de texto.
Pós-condições:
Possibilitar definir nível de PSP do projeto
Regras de Negócio:
RN1: Os campos obrigatórios são: descrição do projeto, nome do desenvolvedor e
status do projeto;
RN2: Os status do projeto devem estar previamente cadastrados e com o seguinte
conteúdo listados na seguinte ordem: concluído e em andamento.
Diagrama de Seqüência:
8.2. UC2 – Caso de Uso: Definir Nível PSP
<<include>>
Gerir Projetos Definir Nível PSP

Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é utilizado para definir o nível de PSP ao qual o projeto se encontra. O
objetivo deste caso de uso é possibilitar a utilização completa do sistema,
compreendendo a definição de fase do projeto, mudança de status de fase,
gerenciamento de planejamento, tempo, defeitos, contabilização de linhas de código,
geração de estatísticas e gráficos.
Pré-Condições:
Projeto Cadastrado.
Fluxo Principal:
1. O sistema exibe a tela de consulta de projetos definida no subfluxo Consulta de
Projetos do Caso de Uso Gerir Projetos;
2. O sistema apresenta a opção de definir nível de PSP para o projeto;
3. O sistema efetua a leitura do registro a partir do projeto escolhido;
4. O sistema apresenta uma interface exibindo a descrição do projeto e as opções
de escolha para definir o nível do PSP: PSP0 ou PSP0.1.
5. O desenvolvedor escolhe o nível de PSP;
6. O sistema solicita a confirmação dos dados;
7. O desenvolvedor confirma os dados.
8. O sistema registra as a escolha e defini o nível PSP para o projeto;
9. O sistema fecha a interface.
Não Aplicável.
1. O nível de PSP não foi escolhido. Sistema exibe uma mensagem e retorna ao
formulário de escolha de nível de PSP;
2. O desenvolvedor pode cancelar a operação a qualquer momento antes de
confirmar os dados;
1. O nível de PSP deve ser exibido em uma caixa de combinação;
2. A descrição do projeto deve estar disposto em texto simples.
Pós-condições:
Possibilitar a definição de fase do projeto.
Possibilitar a mudança de status de fase do projeto;
Possibilitar o gerenciamento de planejamento;
Possibilitar o gerenciamento de defeitos;
Possibilitar a contabilização de linhas de código fonte;
Possibilitar a geração de estatísticas e gráficos.
Regras de Negócio:
Não Aplicável.
8.3. UC3 – Caso de Uso: Definir Fase do Projeto
Definir Fase do Projeto

Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é utilizado para definir a fase (Planejamento, Projeto, Codificação,
Compilação, Teste, Postmortem) que determinado projeto se encontra. O objetivo
deste caso de uso é possibilitar ao desenvolvedor identificar qual fase do nível de PSP
o projeto esta sendo desenvolvido, proporcionando o gerenciamento de erros e tempo.
Pré-Condições:
Nível de PSP definido.
Fluxo Principal:
1. O sistema exibe a tela principal;
2. O sistema recupera o nível PSP do projeto e exibe as fases de acordo com o
nível.
3. O sistema apresenta a opção de definir a fase que o projeto se encontra
(Planejamento, Projeto, Codificação, Compilação, Teste, Postmortem);
4. O desenvolvedor define a fase do projeto, em concordância com a RN1;
5. O sistema registra a fase do projeto;
Não Aplicável.
1. A fase do projeto deve ser exibido em uma caixa de combinação;
Pós-condições:
Possibilitar a mudança de status de fase do projeto;
Possibilitar o gerenciamento de tempo;
Regras de Negócio:
RN1: O desenvolvedor poderá voltar a qualquer fase a qualquer momento, mesmo que
a fase já esteja finalizada.
8.4. UC4 – Caso de Uso: Mudar Status da Fase
Mudar Status de Fase

Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é iniciado quando o desenvolvedor solicita ao sistema a modificação do
status da fase (concluído ou em andamento) do projeto. O objetivo deste caso de uso
é possibilitar ao desenvolvedor finalizar ou reabrir uma determinada fase do projeto.
Pré-Condições:
Fase do Projeto Definida.
Fluxo Principal:
1. O sistema exibe a tela principal;
2. O sistema apresenta a opção de mudar o status (concluída ou em andamento)
da fase do projeto em uso;
3. O desenvolvedor modifica o status da fase do projeto em uso, em concordância
com a RN1;
4. O sistema registra o status da fase do projeto;
Não Aplicável.
1. O status da fase do projeto deve ser exibida em uma caixa de seleção: Quando
ativado significa concluído, quando não ativado significa em andamento;
Pós-condições:
Não Aplicável.
Regras de Negócio:
RN1: O desenvolvedor poderá reabrir uma fase já finalizada.
8.5. UC5 – Caso de Uso: Gerir Planejamento
Gerir Planejamento
Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é iniciado quando o desenvolvedor solicita ao sistema a gestão de
planejamento pessoal ao sistema. O objetivo deste caso de uso é possibilitar ao
desenvolvedor cadastrar o planejamento de tempo a ser gasto em cada fase do
projeto e o número final de linhas de código fonte.
Pré-Condições:
Nível de PSP Definido.
Fluxo Principal:
1. O sistema exibe interface de visualização do planejamento do projeto
selecionado com os dados reais já cadastrados e contabilizados, divididos por cada
fase do projeto. É disponibilizada também uma interface para cadastro do
planejamento de linhas de código ao sistema a ser desenvolvido. É apresentado
também o número de linhas de código reais já cadastradas no sistema para
comparação;
2. O sistema apresenta a interface para definição do planejamento por cada fase
do projeto - Planejamento, Projeto, Codificação, Compilação, Teste, Postmortem e de
linhas de código fonte do sistema;
3. O desenvolvedor informa os dados solicitados;
4. O sistema solicita a confirmação dos dados;
5. O desenvolvedor confirma os dados;
6. O sistema efetua as validações necessárias de formato de tempo;
7. O sistema registra o os dados apresentados pelo desenvolvedor.
1. Caso já exista um planejamento para o projeto cadastrado, o sistema recupera
este planejamento e disponibiliza a interface para alteração dos dados.
1. As informações de planejamento devem estar dispostas em controles de texto
de forma organizada por cada fase do projeto.
Pós-condições:
Não Aplicável.
Regras de Negócio:
Não Aplicável.
8.6. UC6 – Caso de Uso: Gerir Tempo
Gerir T empo
Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é o utilizado para descrever a ação do usuário de cadastramento dos
tempos de parada no sistema em cada fase do projeto. O objetivo deste caso de uso é
possibilitar que ocorra a inclusão de cursos no sistema, a consulta, a alteração ou a
exclusão daqueles já existentes.
Pré-Condições:
Status da Fase Definida como em Andamento.
Fluxo Principal:
1. O sistema exibe a interface de gestão de tempo. Ela é dividia de acordo com as
fases do projeto. Para cada fase é possível cadastrar vários tempos com suas
descrições.
2. O sistema executa o subfluxo de Pesquisa/Visualizar Tempo.
1. O desenvolvedor cancela a operação. O sistema exibe a interface de gestão de
tempo.
Subfluxo: Pesquisa/Visualizar Tempo

1. O desenvolvedor aciona o comando Tempo;
2. O sistema exibe os tempos já inseridos e contabilizados (hora inicio, hora final,
descrição), devidamente divididos por cada fase do projeto;
3. O sistema apresenta opções para incluir manualmente(Caso de Uso 8) e
alterar/visualizar/excluir os tempos.
Subfluxo: Alterar/Excluir Tempo

1. O desenvolvedor seleciona o tempo a ser alterado/excluído.
2. O desenvolvedor solicita alteração ou exclusão. Para alteração, ele informa os
novos dados;
3. O sistema solicita a confirmação da operação.
3. O sistema altera ou exclui os dados do tempo selecionado.
1. A descrição do tempo, descrição, hora inicial ou final não foram preenchidos ou
não foram preenchidos corretamente. Sistema exibe uma mensagem e retorna ao
formulário de gestão de tempo;
1. A interface de visualização dos tempos deve ser categorizada de acordo com
as fases do projeto.
2. O campo hora inicial e hora final devem ser dispostos com controles de texto
com suporte à máscara de tempo: __:__:__ HH:mm:ss.
3. O campo descrição deve ser disposto com controle de texto com área de
digitação.
Pós-condições:
Não Aplicável.
Regras de Negócio:
Não Aplicável.
8.7. UC7 – Caso de Uso: Contabilizar Automaticamente
<<extend>>
Gerir T empo Contabilizar Automaticamente

Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é iniciado quando o desenvolvedor inicia o relógio automático para
contabilização do tempo de acordo com a fase escolhida. O objetivo deste caso de uso
é prover uma interface para inserção automática dos tempos medidos de acordo com
as atividades exercidas dentro das fases do projeto.
Pré-Condições:
Fluxo Principal:
1. O sistema exibe a interface principal.
2. O desenvolvedor aciona a opção de inicio da contabilização automática de
tempo.
3. O desenvolvedor aciona a opção para finalizar a contabilização automática de
tempo.
4. O sistema apresenta uma interface para cadastrar a descrição do tempo
contabilizado.
5. O desenvolvedor apresenta os dados da descrição solicitada pelo sistema.
6. O sistema registra o novo tempo.
1. O desenvolvedor cancela a operação. O sistema exibe a interface Principal.
1. A descrição do tempo não foi preenchida ou não foram preenchidos
corretamente. Sistema exibe uma mensagem e retorna ao formulário de cadastro
automático de tempo;
digitação.
Pós-condições:
Não Aplicável.
Regras de Negócio:
Não Aplicável.
8.8. UC8 – Caso de Uso: Contabilizar Manualmente
<<extend>>
Gerir T empo Contabilizar Manualmente

Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é iniciado quando o desenvolvedor solicita ao sistema a inserção
manual de um tempo em alguma fase do projeto. O objetivo deste caso de uso é
prover uma interface para inserção manual dos tempos medidos de acordo com as
atividades exercidas dentro das fases do projeto.
Pré-Condições:
Fluxo Principal:
descrições.
2. O desenvolvedor aciona a opção de cadastro de tempo de acordo com a fase
selecionada na interface de gestão de tempo.
3. O sistema apresenta o formulário de cadastro de tempo (hora inicial, hora final
e descrição do tempo).
4. O desenvolvedor preenche os dados solicitados e os envia ao sistema.
6. O sistema registra o novo tempo.
tempo.
1. A descrição do tempo, descrição, hora inicial ou final não foram preenchidos ou
não foram preenchidos corretamente. Sistema exibe uma mensagem e retorna ao
formulário de gestão de tempo;
1. A interface de visualização dos tempos deve ser categorizada de acordo com
as fases do projeto.
2. O campo hora inicial e hora final devem ser dispostos com controles de texto
com suporte à máscara de tempo: __:__:__ HH:mm:ss.
digitação.
Pós-condições:
Não Aplicável.
Regras de Negócio:
Não Aplicável.
8.9. UC9 – Caso de Uso: Totalizar Tempo
<<include>>
Gerir T empo Totalizar T empo

Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é iniciado quando o desenvolvedor entra na interface de gestão de
tempo. O objetivo deste caso de uso é totalizar os tempos já cadastrados de cada fase
e totalizar o tempo das fases.
Pré-Condições:
Fluxo Principal:
descrições.
2. O sistema apresenta as totalizações de todos os tempos já cadastrados por
fase e para o projeto todo.
Não Aplicável.
Não Aplicável.
1. Os tempos totalizados devem ser exibidos ao lado de cada fase do projeto. A
soma total dos tempos de todas as fases deve ser exibidos ao lado do nome do
projeto na interface de gestão de tempos.
2. O formato das totalizações deve ser HH:mm:ss.
Pós-condições:
Não Aplicável.
Regras de Negócio:
Não Aplicável.
8.10. UC10 – Caso de Uso: Gerir Defeitos
Gerir Defeitos
Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é iniciado quando o desenvolvedor solicita ao sistema a interface de
cadastro ou gestão de defeitos. O objetivo deste caso de uso fornecer ao
desenvolvedor uma interface para o cadastro de defeitos e sua manutenção
(visualização, alteração e exclusão).
Pré-Condições:
Fluxo Principal:
1. O sistema exibe a tela de defeitos.
2. O sistema executa o subfluxo Pesquisa Defeitos.
1. O sistema exibe a tela principal.
2. O desenvolvedor solicita ao sistema a inclusão de um defeito.
3. O sistema apresenta a tela de cadastro de defeito.
4. O fluxo segue as operações definidas no subfluxo Operação Incluir.

defeitos.
Subfluxo: Operação Incluir

1. O desenvolvedor abre o formulário de Novo Defeito com todos os campos
habilitados;
2. O sistema solicita a entrada dos seguintes dados: Tipo de defeitos
(documentação, sintaxe, compilação, lógica, interface, versionamento, checagem,
condicionais, funções, sistema, linguagem e ambiente), defeito de referência cruzada
(não obrigatório), defeito inserido em qual fase do projeto, defeito removido em qual
fase do projeto, tempo para conserto e descrição;
3. O desenvolvedor informa ao sistema os dados solicitados;
4. O sistema oferece ao desenvolvedor a opção de contabilizar o tempo para
conserto do defeito de forma automática. É disponibilizada uma opção que quando
acionada ativa um relógio do sistema que contabiliza o tempo. Ao ser desativado o
sistema entrega à interface o tempo gasto de forma automática.
5. O desenvolvedor confirma os dados informados;
6. O sistema cadastra o defeito.
Subfluxo: Operação Alterar/Visualizar/Excluir

1. O sistema efetua a leitura do registro a partir do defeito escolhido.
2. O sistema exibe os dados do defeito escolhido (Tipo de defeitos
condicionais, funções, sistema, linguagem e ambiente), defeito de referência cruzada
(não obrigatório), defeito inserido em qual fase do projeto, defeito removido em qual
fase do projeto, tempo para conserto e descrição);
3. Se desejar, o desenvolvedor tem a opção de alterar os dados do defeito ou
excluí-lo;
4. O sistema altera ou exclui os dados do defeito selecionado.
Subfluxo: Pesquisa Defeitos

1. O desenvolvedor aciona o comando Defeitos;
2. O sistema exibe os defeitos já inseridos (descrição, tipo de defeitos
condicionais, funções, sistema, linguagem e ambiente), defeito inserido em qual fase
do projeto, defeito removido em qual fase do projeto e tempo para);
3. O sistema apresenta opções para incluir e alterar/visualizar/excluir os defeitos.
1. O tipo de defeitos (documentação, sintaxe, compilação, lógica, interface,
versionamento, checagem, condicionais, funções, sistema, linguagem e ambiente),
defeito de referência cruzada (não obrigatório), defeito inserido em qual fase do
projeto, defeito removido em qual fase do projeto, tempo para conserto e descrição
não foram preenchidos ou não foram preenchidos corretamente. Sistema exibe uma
mensagem e retorna ao formulário de gestão de tempo;
1. Os tipos de defeito, fase de inserção e remoção do defeito devem ser exibidos
em uma caixa de combinação;
2. O defeito de referência cruzada deve apresentar um controle texto, com a
possibilidade de buscar por outro defeito já cadastrado. Ao escolher, o ID do defeito
referenciado irá aparecer no controle de texto.
3. O campo de tempo de conserto deve ser dispostos com controles de texto com
suporte à máscara de tempo: __:__:__ HH:mm:ss.
4. O campo descrição deve ser exibido em um controle de texto com área exposta
para o texto.
Pós-condições:
Não Aplicável.
Regras de Negócio:
Não Aplicável.
8.11. UC11 – Caso de Uso: Contabilizar LOC
Contabilizar LOC
Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é iniciado quando o desenvolvedor solicita ao sistema a interface de
contabilização de linhas de código. O objetivo deste caso de uso fornecer ao
desenvolvedor uma interface para adicionar os arquivos de código fonte para que o
sistema calcule o número de linhas de código automaticamente.
Pré-Condições:
Fluxo Principal:
1. O sistema exibe a tela cadastro de linhas de código com todos os campos
habilitados.
2. O sistema solicita ao desenvolvedor os seguintes dados: Local dos arquivos
para contabilização automática das linhas de código.
3. O usuário apresenta os arquivos e confirma para o sistema.
4. O sistema contabiliza as linhas de código dos arquivos apresentados, seguindo
a RN1.
5. O sistema exibe o resultado e solicita a confirmação.
6. O desenvolvedor confirma o número de linhas de código fonte contabilizados.
7. O sistema registra o número de linhas de código fonte contabilizadas para o
projeto.
1. O desenvolvedor cancela a operação. O sistema exibe a interface de principal.
1. O arquivo ao ser lido não esta disponível pelo sistema operacional. Sistema
exibe uma mensagem informando que a operação não pode ser realizada indicando o
motivo do cancelamento da operação;
1. Interface para selecionar múltiplos arquivos.
Pós-condições:
Não Aplicável.
Regras de Negócio:
RN1: É considerada uma linha de código, toda linha de código existente no arquivo
fonte, desde que não seja uma linha em branco.
8.12. UC12 – Caso de Uso: Gerar Estatísticas
Gerar Estatísticas
Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é iniciado quando o desenvolvedor solicita ao sistema a geração de
estatísticas do projeto ou de todos os projetos cadastrados. O objetivo deste caso de
uso fornecer ao desenvolvedor uma interface gerar, analisar e comparar as
estatísticas dos projeto cadastrados. Número e porcentagem de defeitos inseridos e
retirados em cada fase do projeto. Porcentagem do tipo de defeito. Comparativo entre
Pré-Condições:
Fluxo Principal:
1. O sistema exibe a tela de estatísticas.
Não Aplicável.
Não Aplicável.
1. O sistema deve apresentar as estatísticas de forma clara e ampla para análise
dos dados pelo desenvolvedor.
Pós-condições:
Não Aplicável.
Regras de Negócio:
Não Aplicável.
8.13. UC13 – Caso de Uso: Gerar Gráficos
Gerar Gráficos
Desenvolvedor
Ator Principal:
Desenvolvedor
Sumário:
O caso de uso é iniciado quando o desenvolvedor solicita ao sistema a geração de
gráficos do projeto ou de todos os projetos cadastrados. O objetivo deste caso de uso
fornecer ao desenvolvedor uma interface gerar, analisar e comparar as estatísticas
dos projeto cadastrados. Número e porcentagem de defeitos inseridos e retirados em
cada fase do projeto. Porcentagem do tipo de defeito. Comparativo entre planejamento
e realidade cadastrada no sistema, incidência de defeitos, tipos de defeitos, local de
incidência de defeitos, tempo de desenvolvimento médio por fase, linhas de código por
hora na fase de codificação.
Pré-Condições:
Fluxo Principal:
1. O sistema exibe a tela de gráficos.
Não Aplicável.
Não Aplicável.
1. O sistema deve apresentar as estatísticas de forma clara e ampla para análise
dos dados pelo desenvolvedor.
Pós-condições:
Não Aplicável.
Regras de Negócio:
Não Aplicável.
9. Modelagem Conceitual
9.1. Modelo MVC (Model View Controller)
Interfaces (View) Controladores (Controller) Classes de Domínio (Model)
9.2. Diagrama de Classes (Interfaces e Controladores)
9.3. Diagrama de Classes (Modelo)
0..1 TipoDefeito
CodigoFonte
0..1
0..1 1
Planejamento
Estatistica 0..1 0..*
0..* Defeito
0..* 1
0..* 0..*
1 0..* 0..*
1
1
1 Projeto NivelPSP FaseProjeto
0..* 0..1 * *
1 0..* 0..* 1
1
00 01
0..*
0..* Tempo
9.4. Atributos e Métodos das Classes de Domínio
Classe: Projeto Tipo: Persistente

Atributos
oid GUID: String
descrição varchar
nome_desenvolvedor varchar
status boolean
Métodos
criar boolean
persitir boolean
atualizar boolean
recuperaObjeto(oid:string) Projeto
recuperaObjetos list Projeto
excluir boolean
setDados – Métodos set void
getDados – Métodos get void
setNivelPSP(NivelPSP) – Associação boolean
getNivelPSP - Associação NivelPSP
registraFases boolean
ativarFaseProjeto boolean
mudarStatus boolena
Classe: FaseProjeto Tipo: Persistente de Sistema

Atributos
oid GUID: String
nome varchar
descricao varchar
Métodos
criar boolean
persitir boolean
atualizar boolean
recuperaObjeto(oid:string) FaseProjeto
recuperaObjetos list FaseProjeto
excluir boolean
Classe: Tempo Tipo: Persistente

Atributos
oid GUID: String
hora_inicio timestamp
hora_final timestamp
descricao varchar
Métodos
criar boolean
persitir boolean
atualizar boolean
recuperaObjeto(OID:String) Tempo
recuperaObjetosPorFase(OIDFase: string) list Tempo
recuperaObjetos list Tempo
excluir boolean
Classe: Defeito Tipo: Persistente

Atributos
oid GUID: String
hora_inicio timestamp
hora_final timestamp
descricao varchar
Métodos
criar boolean
persitir boolean
atualizar boolean
recuperaObjeto(OID:String) Defeito
recuperaObjetosPorProjeto(OIDProjeto:String) list Defeito
recuperaObjetos list Defeito
excluir boolean
Classe: TipoDefeito Tipo: Persistente de Sistema

Atributos
oid GUID: String
nome varchar
descricao varchar
Métodos
criar boolean
persitir boolean
atualizar boolean
recuperaObjeto(OID:String) TipoDefeito
recuperaObjetos list TipoDefeito
excluir boolean
Classe: Planejamento Tipo: Persistente

Atributos
oid GUID: String
tempo_desenvolvimento time:array
numero_LOC longint
Métodos
criar boolean
persitir boolean
atualizar boolean
recuperaObjeto(OID:String) Planejamento
recuperaObjetos list Planejamento
excluir boolean
Classe: NivelPSP Tipo: Abstrata de Sistema

Atributos
oid GUID: String
nome varchar
descricao varchar
Métodos
persitir boolean
atualizar boolean
recuperaObjeto(OID:String) NivelPSP
recuperaObjetos list NivelPSP
excluir boolean
Classe: Estatistica Tipo: Persistente

Atributos
oid GUID: String
descrição time:array
dados_grafico stream
dados_estatistica stream
Métodos
gerarGraficosTodosProjeto(tipoGrafico:int) stream
gerarGrafico(tipoGrafico:int) stream
gerarEstatisticasTodosProjeto(tipoEst:int) stream
gerarEstatisticas(tipoEst:int) stream
Classe: CodigoFonte Tipo: Persistente

Atributos
oid GUID: String
descrição time:array
numero_LOC longint
Métodos
criar boolean
persitir boolean
atualizar boolean
recuperaObjeto(OID:String) Estatistica
recuperaObjetos list Estatistica
excluir boolean
getDados – Métodos get Void
contabilizarLOC longint
9.5. Mapeamento Objeto-Relacional – Diagrama de Tabelas Relacionais
10. Contratos do Sistema
Classe: Projeto Operação: criar

Pré-Condições:
- Existir dados nos campos descrição, nome_desenvolvedor e status do projeto.
Pós-Condições:
- Foi incluído uma linha na base para persistir novos registros.
Exceções:
- Retorna mensagem de erro ao usuário caso não tenha êxito na instanciação do objeto.
Classe: Projeto Consulta: recuperaObjeto(oid: string)

Pré-Condições:
- Existe um projeto indicado em obterProjeto();
- Existe o projeto indicado gravado na base de dados com mesma chave de oid do parâmetro.
Retorno:
- Retorna descrição, nome_desenvolvedor e status do projeto.
Exceções:
- Retorna mensagem de informação ao usuário caso não exista o objeto solicitado.
Classe: Projeto Consulta: recuperaObjetos()

Pré-Condições:
- Existem projetos cadastrados.
Retorno:
- Retorna lista de projetos com os campos descrição, nome_desenvolvedor e status do projeto.
Exceções:
- Retorna mensagem de informação ao usuário caso não existam objetos persistidos.
Classe: Projeto Operação: excluir

Pré-Condições:
- Existe Projeto selecionado e instanciado.
Pós-Condições:
- O Projeto foi excluído da base de dados;
- Todos os registros associados ao Projeto em outras classes foram excluídos da base de
dados.
Exceções:
- Retorna mensagem de erro ao usuário caso algum problema ocorra.
- Ocorre um rollback na base de dados em caso de erro.
Classe: Projeto Operação: setDados()

Pré-Condições:
- Existir descrição, nome_desenvolvedor e status do projeto digitados pelo Usuário.
Pós-Condições:
- descrição, nome_desenvolvedor e status do projeto são associados nos respectivos atributos
da Classe Projetos.
Exceções:
- Não se aplica.
Classe: Projeto Operação: persistir

Pré-Condições:
- Execução da operação Criar;
- descrição, nome_desenvolvedor e status do Projeto estão setados em SetDados();
Pós-Condições:
- Foi criado Projeto e adicionado ao cadastro;
- É exibida mensagem ao Usuário de confirmação de gravação.
Exceções:
- Exibe mensagem de erro ao usuário ao não conseguir persistir o objeto.
Classe: Projeto Operação: atualizar
Pré-Condições:
- descrição, nome_desenvolvedor e status do projeto.do Projeto estão configurados em
SetDados().
Pós-Condições:
- descrição, nome_desenvolvedor e status do projeto são atualizados no cadastro;
- É exibida mensagem ao Usuário de confirmação de atualização.
Exceções:
- Exibe mensagem de erro ao usuário ao não conseguir atualizar o objeto.
Classe: Projeto Operação: setNivelPSP(NivelPSP)

Pré-Condições:
- oidNivelPSP da classe NivelPSP ser igual a NivelPSP do parâmetro.
Pós-Condições:
- Nível PSP é gravado para o Projeto;
- “Nível PSP atualizado”: O sistema exibe mensagem de confirmação de cadastramento do
nível do PSP para o projeto.
Exceções:
- Exibe mensagem de erro ao usuário ao não conseguir configurar o nível de PSP ao usuário.
Classe: Projeto Operação: registraFases

Pré-Condições:
- Haver fases Cadastradas na Classe FaseProjeto.
Pós-Condições:
- São exibidas as fases do PSP (Planejamento, Projeto, Codificação, Compilação, Teste,
Postmortem) para a identificação no Projeto.
Exceções:
- “Fases Não Cadastradas.”: O sistema exibe mensagem caso não haja fase cadastrada.
Classe: Projeto Operação: ativarFaseProjeto

Pré-Condições:
- O Usuário selecionar uma fase listada pelo método registraFases.
Pós-Condições:
- Fase PSP é gravada para o Projeto;
- “Fase PSP atualizada”: O sistema exibe mensagem de confirmação de cadastramento da
fase do PSP para o projeto;
Exceções:
- Exibe mensagem de erro ao usuário ao não conseguir ativar determinada fase de projeto.
Classe: Projeto Operação: mudarStatus

Pré-Condições:
- O Usuário selecionar Projeto com FasePSP identificada.
Pós-Condições:
- O Status (Concluído ou Em Andamento) é gravado para a Fase do Projeto;
- “Status da Fase PSP atualizada”: O sistema exibe mensagem de confirmação de atualização
do Status da Fase do PSP para o projeto.
Exceções:
- Exibe mensagem de erro ao usuário ao não conseguir mudar o status de determinada fase.
Classe: FaseProjeto Operação: criar

Pré-Condições:
- Existir Projeto selecionado.
Pós-Condições:
Exceções:
Classe: FaseProjeto Operação: persistir
Pré-Condições:
- descrição da Fase.do Projeto esta setada em SetDados().
Pós-Condições:
- A fase é adicionada ao Projeto;
Exceções:
Classe: FaseProjeto Operação: atualizar

Pré-Condições:
- descrição da Fase do PSP do Projeto está setada em SetDados();
Pós-Condições:
- descrição da Fase do PSP do Projeto é atualizada no cadastro;
Exceções:
Classe: FaseProjeto Consulta: recuperaObjeto(oid: string)

Pré-Condições:
- Existe uma Fase PSP do Projeto indicado em obterProjeto();
- Existe o projeto indicado gravado na base de dados com mesma chave de oid do parâmetro.
Retorno:
- Retorna descrição, nome_desenvolvedor e status do projeto.
Exceções:
Classe: FaseProjeto Consulta: recuperaObjetos()

Pré-Condições:
- Existem Fases do PSP cadastradas.
Retorno:
- Retorna lista de Fases do PSP para os Projetos com campo descrição.
Exceções:
Classe: FaseProjeto Operação: excluir

Pré-Condições:
- Existe Projeto selecionado;
- Existe Fase PSP associada ao Projeto.
Pós-Condições:
- A Fase PSP do Projeto foi excluída da base de dados;
- Todos os registros associados à Fase PSP do Projeto em outras classes foram excluídos da
base de dados.
Exceções:
- Retorna mensagem de erro ao usuário caso algum problema ocorra.
- Ocorre um rollback na base de dados em caso de erro.
Classe: FaseProjeto Operação: setDados()

Pré-Condições:
- Existir descrição da Fase PSP do Projeto selecionada pelo Usuário.
Pós-Condições:
- descrição, nome_desenvolvedor e status do projeto são associados nos respectivos atributos
da Classe Projetos.
Exceções:
- Não se aplica.
Classe: Tempo Operação: criar

Pré-Condições:
- Existir dados informados para a descrição, a data, hora inicial e final do Tempo setados em
SetDados();
Pós-Condições:
- Foi incluída uma linha na base para persistir novos registros.
Exceções:
Classe: Tempo Operação: persistir

Pré-Condições:
- Execução da operação Criar.
- a descrição, a data, hora inicial e final do Tempo setados em SetDados();
Pós-Condições:
- a descrição, a data, hora inicial e final do Tempo são cadastradas para a Fase do Projeto;
Exceções:
Classe: Tempo Operação: atualizar

Pré-Condições:
- dados do Tempo da Fase do PSP do Projeto estão configurados em SetDados();
Pós-Condições:
- os dados do Tempo da Fase do PSP do Projeto são atualizados no cadastro;
Exceções:
Classe: Tempo Consulta: recuperaObjeto(oid: string)

Pré-Condições:
- Existe o tempo da Fase PSP do Projeto indicado em obterTempo();
- Existe o projeto e fase indicados gravados na base de dados com mesma chave de oid do
parâmetro.
Retorno:
- Retorna descrição, data, hora inicial e final da fase do projeto.
Exceções:
Classe: Tempo Consulta: recuperaObjetosPorFase(OIDFase:

string)
Pré-Condições:
- Existem tempos cadastrados por fase para os projetos
Retorno:
- Retorna lista de tempos sumarizados por fase do projeto totalizando por dia o número de
horas gastos em cada fase.
Exceções:
Classe: Tempo Consulta: recuperaObjetos

Pré-Condições:
- Existem tempos cadastrados por fase para os projetos
Retorno:
- Retorna lista de tempos sumarizados do projeto totalizando por dia o número de horas gastos
do projeto como um todo.
Exceções:
Classe: Tempo Operação: excluir

Pré-Condições:
- Existe Projeto selecionado;
- Existe Tempo cadastrado na Fase PSP associada ao Projeto.
Pós-Condições:
- Os tempos indicados na Fase PSP do Projeto foi excluída da base de dados.
Exceções:
- A Fase PSP do Projeto foi excluída da base de dados;
- Todos os registros associados à Fase PSP do Projeto em outras classes foram excluídos da
base de dados.
Classe: Tempo Operação: setDados()

Pré-Condições:
- Existir Tempo da Fase PSP do Projeto selecionada pelo Usuário.
Pós-Condições:
- descrição do tempo, data, hora inicial e final são associados nos respectivos atributos da
Classe Tempo.
Exceções:
- Não se aplica.
Classe: Defeito Operação: criar

Pré-Condições:
- Existir dados informados para o tipo e descrição do defeito, a data, tempo que o defeito foi
removido, fase em que o defeito foi removido setados em SetDados().
Pós-Condições:
Exceções:
Classe: Defeito Operação: persistir

Pré-Condições:
- tipo e descrição do defeito, tempo que o defeito foi removido, fase em que o defeito removido
estão setados em SetDados().
Pós-Condições:
- tipo e descrição do defeito, data, tempo que o defeito foi removido, fase em que o defeito
removido são cadastrados para a Fase do Projeto;
Exceções:
Classe: Defeito Operação: atualizar

Pré-Condições:
- os dados do Defeito da Fase do PSP do Projeto estão setados em SetDados();
Pós-Condições:
- os dados do Defeito da Fase do PSP do Projeto são atualizados no cadastro;
Exceções:
Classe: Defeito Consulta: recuperaObjeto(oid: string)

Pré-Condições:
- Existe o defeito da Fase PSP do Projeto indicado em obterDefeito();
- Existe o defeitos para a fase indicados gravados na base de dados com mesma chave de oid
do parâmetro.
Retorno:
- Retorna tipo e descrição do defeito, data, tempo que o defeito foi removido, fase em que o
defeito removido do projeto.
Exceções:
Classe: Defeito Consulta: recuperaObjetosPorProjeto(OIDFase:
string)
Pré-Condições:
- Existem defeitos cadastrados por fase para os projetos
Retorno:
- Retorna lista de defeitos por fase do projeto indicando o tipo de defeito, sua descrição, a data
e o tempo de remoção do projeto.
Exceções:
Classe: Defeito Consulta: recuperaObjetos

Pré-Condições:
- Existem defeitos cadastrados por fase para os projetos
Retorno:
- Retorna lista de defeitos por fase do projeto indicando o tipo de defeito, sua descrição, a data
e o tempo de remoção do projeto.
Exceções:
Classe: Defeito Operação: excluir

Pré-Condições:
- Existe Defeito selecionado;
- Existe Defeito cadastrado na Fase PSP associada ao Projeto.
Pós-Condições:
- Os Defeitos indicados na Fase PSP do Projeto foram excluídos da base de dados.
Exceções:
- “Defeito não pode ser Excluído.”: o defeito não poderá ser excluído quando houver algum
projeto associado a ele.
Classe: Defeito Operação: setDados()

Pré-Condições:
- Existir Defeito da Fase PSP do Projeto selecionada pelo Usuário
Pós-Condições:
- o tipo de defeito, sua descrição, a data e o tempo de remoção do projeto são associados nos
respectivos atributos da Classe Defeito.
Exceções:
- Não se aplica.
Classe: Tipo de Defeito Operação: criar

Pré-Condições:
- Existir dados informados para a descrição do tipo do defeito setados em SetDados();
Pós-Condições:
Exceções:
Classe: Tipo de Defeito Operação: persistir

Pré-Condições:
- Execução da operação Criar.
- descrição do tipo do defeito está setado em SetDados();
Pós-Condições:
- descrição do tipo de defeito é cadastrada para a Fase do Projeto;
Exceções:
Classe: Tipo de Defeito Operação: atualizar
Pré-Condições:
- os dados do Tipo de Defeito estão setados em SetDados();
Pós-Condições:
- os dados do Tipo de Defeito são atualizados no cadastro;
Exceções:
Classe: Tipo de Defeito Consulta: recuperaObjeto(oid: string)

Pré-Condições:
- Existe o tipo de defeito indicado em obterTipoDefeito();
- Existe o tipo de defeito gravado com mesma chave de oid do parâmetro.
Retorno:
Exceções:
Classe: Tipo de Defeito Consulta: recuperaObjetos

Pré-Condições:
- Existem tipos de defeitos cadastrados.
Retorno:
- Retorna lista de tipos de defeitos a sua descrição.
Exceções:
Classe: Tipo de Defeito Operação: excluir

Pré-Condições:
- Existe Tipo de Defeito selecionado;
- Existe Tipo de Defeito cadastrado.
Pós-Condições:
- Os Tipos de Defeitos são excluídos da base de dados.
Exceções:
- “Tipo de Defeito não pode ser Excluído.”: o tipo de defeito não poderá ser excluído quando
houver algum defeito associado a ele.
Classe: Tipo de Defeito Operação: setDados()

Pré-Condições:
- Existir Defeito da Fase PSP do Projeto selecionada pelo Usuário
Pós-Condições:
- o tipo de defeito, sua descrição, a data e o tempo de remoção do projeto são associados nos
respectivos atributos da Classe Tipo de Defeito.
Exceções:
- Não se aplica.
Classe: Planejamento Operação: criar

Pré-Condições:
- Existir dados informados para tempo e número de linhas de código para as fases do projeto
estão setados em SetDados().
Pós-Condições:
Exceções:
Classe: Planejamento Operação: persistir

Pré-Condições:
- tempo e número de linhas de código para as fases definidas para o projeto estão setados em
SetDados().
Pós-Condições:
- tempo e número de linhas de código são cadastrados para a Fase do Projeto;
Exceções:
Classe: Planejamento Operação: atualizar

Pré-Condições:
- os dados do Planejamento estão setados em SetDados();
Pós-Condições:
- os dados do Planejamento são atualizados no cadastro;
Exceções:
Classe: Planejamento Consulta: recuperaObjeto(oid: string)

Pré-Condições:
- Existe planejamento indicado em obterPlanejamento();
- Existe planejamento gravado com mesma chave de oid do parâmetro.
Retorno:
- Retorna tempo e número de linhas planejadas por Fase do Projeto.
Exceções:
Classe: Planejamento Consulta: recuperaObjetos

Pré-Condições:
- Existe planejamento cadastrado por fase do projeto.
Retorno:
- Retorna lista dos planejamentos cadastrados por fase do projeto, contendo tempo e número
de linhas de código planejadas.
Exceções:
Classe: Planejamento Operação: excluir

Pré-Condições:
- Existe Planejamento selecionado;
- Existe Planejamento cadastrado.
Pós-Condições:
- Os Planejamentos são excluídos da base de dados.
Exceções:
- Não se aplica.
Classe: Planejamento Operação: setDados()

Pré-Condições:
- Existir Planejamento da Fase PSP do Projeto selecionada pelo Usuário
Pós-Condições:
- o tempo e o número de linhas de código planejados por projeto são associados nos
respectivos atributos da Classe Planejamento.
Exceções:
- Não se aplica.
Classe: NivelPSP Operação: persistir

Pré-Condições:
- Nível do PSP selecionado pelo Usuário para o projeto.está setado em SetDados();
Pós-Condições:
- Nível do PSP é cadastrado para o Projeto;
Exceções:
Classe: NivelPSP Operação: atualizar

Pré-Condições:
- o Nível do PSP é setado em SetDados().
Pós-Condições:
- o Nível do PSP é atualizado no cadastro;
- É exibida mensagem ao Usuário de confirmação de atualização
Exceções:
Classe: NivelPSP Consulta: recuperaObjeto(oid: string)

Pré-Condições:
- Existe Nível PSP indicado em obterNivelPSP();
- Existe Nível PSP gravado com mesma chave de oid do parâmetro.
Retorno:
- Retorna o Nível PSP do Projeto.
Exceções:
Classe: NivelPSP Consulta: recuperaObjetos

Pré-Condições:
- Existe Nível PSP cadastrado para o projeto.
Retorno:
- Retorna o Nível PSP do Projeto.
Exceções:
Classe: NivelPSP Operação: excluir

Pré-Condições:
- Existe Nível PSP selecionado;
- Existe Nível PSP cadastrado.
Pós-Condições:
- O Nível PSP é excluído da base de dados.
Exceções:
- “O Nível PSP não pode ser Excluído do Projeto.”: quando houver planejamento, lançamento
de defeitos, ou tempos cadastrados para a fase do projeto o Nível PSP não poderá ser
excluído.
Classe: NivelPSP Operação: setDados()

Pré-Condições:
- Existir NivelPSP do Projeto selecionado pelo Usuário.
Pós-Condições:
- o NívelPSP é associado nos respectivos atributos da Classe Projeto.
Exceções:
- Não se aplica.
Classe: Estatistica Consulta: gerarGraficosTodosProjeto(tipoGrafico:int)

Pré-Condições:
- Existem dados de tempo, defeitos, planejamento, número de linhas de código cadastrados
para todos os projetos do sistema.
Retorno:
- Retorna Gráficos dos projetos cadastrados no sistema.
Classe: Estatistica Consulta: gerarGrafico(tipoGrafico:int)
Pré-Condições:
para um projeto;
- Usuário selecionar um projeto.
Retorno:
- Retorna Gráficos de um projeto selecionado.
Classe: Estatistica Consulta: gerarEstatisticasTodosProjeto(tipoEst:int)

Pré-Condições:
para todos os projeto do sistema.
Retorno:
- Retorna Estatísticas dos projetos cadastrados no sistema.
Classe: Estatistica Consulta: gerarEstatisticas(tipoEst:int)

Pré-Condições:
para um projeto.
Retorno:
- Retorna Estatísticas de um projeto selecionado.
Classe: ContabilizarLOC Operação: criar

Pré-Condições:
- Existir dados informados para número de linhas de código para as fases do projeto setados
em SetDados().
Pós-Condições:
Exceções:
Classe: ContabilizarLOC Operação: persistir

Pré-Condições:
- Existir número de linhas de código informado para as fases definidas para o projeto setados
em SetDados();
Pós-Condições:
- número de linhas de código é cadastrado para a Fase do Projeto.
Exceções:
Classe: ContabilizarLOC Operação: atualizar

Pré-Condições:
- o número de linhas de código está setado em SetDados();
Pós-Condições:
- o número de linhas de código é atualizado no cadastro.
- É exibida mensagem ao Usuário de confirmação de atualização
Exceções:
Classe: ContabilizarLOC Consulta: recuperaObjeto(oid: string)

Pré-Condições:
- Existe o número de linhas de código gravado com mesma chave de oid do parâmetro.
Retorno:
- Retorna o número de linhas de código planejadas por Fase do Projeto.
Exceções:
Classe: ContabilizarLOC Consulta: recuperaObjetos

Pré-Condições:
- Existe o número de linhas de código cadastrado por fase do projeto.
Retorno:
- Retorna lista do número de linhas de código cadastradas por fase do projeto.
Exceções:
Classe: ContabilizarLOC Operação: excluir

Pré-Condições:
- Existe o número de linhas de código selecionado;
- Existe o número de linhas de código cadastrado.
Pós-Condições:
- O número de linhas de código são excluídos da base de dados.
Exceções:
- Não se aplica.
Classe: ContabilizarLOC Operação: setDados()

Pré-Condições:
- Existir o número de linhas de código para Fase PSP do Projeto selecionada pelo Usuário
Pós-Condições:
- o número de linhas de código por fase do projeto é associado no respectivo atributo da
Classe Fases Projeto.
Exceções:
- Não se aplica.
Classe: ContabilizarLOC Consulta: contabilizarLOC

Pré-Condições:
- Existe Projeto selecionado pelo Usuário;
- Existe número de linhas de código cadastradas por fase do projeto.
Retorno:
- Retorna o número de linhas de código total do projeto.
11. Protótipos de Interface
11.1. Navegação Entre Interfaces
Principal
Inicio Fim
Projeto Gráficos
Selecionar Projeto Estatísticas
Planejamento Defeitos
Tempo
11.2. Protótipos
12. Código Fonte Sugerido
12.1. SQL Base de Dados

CREATE TABLE FaseProjeto (
idNivelPSP INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
nome VARCHAR NULL,
descricao VARCHAR NULL,
PRIMARY KEY(idNivelPSP)
);
CREATE TABLE NivelPSP (

idNivelPSP INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
nome VARCHAR NULL,
PRIMARY KEY(idNivelPSP)
);
CREATE TABLE TipoDefeito (

idTipoDefeito INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
nome VARCHAR NULL,
PRIMARY KEY(idTipoDefeito)
);
CREATE TABLE Projeto (

idProjeto INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
NivelPSP_idNivelPSP INTEGER UNSIGNED NOT NULL,
nome_desenvolvedor VARCHAR NULL,
statusProjeto BOOL NULL,
PRIMARY KEY(idProjeto),
INDEX Projeto_FKIndex1(NivelPSP_idNivelPSP),
FOREIGN KEY(NivelPSP_idNivelPSP)
REFERENCES NivelPSP(idNivelPSP)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
CREATE TABLE CodigoFonte (

idCodigoFonte INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
Projeto_idProjeto INTEGER UNSIGNED NOT NULL,
numero_LOC VARCHAR NULL,
PRIMARY KEY(idCodigoFonte),
INDEX CodigoFonte_FKIndex1(Projeto_idProjeto),
FOREIGN KEY(Projeto_idProjeto)
REFERENCES Projeto(idProjeto)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
CREATE TABLE Estatistica (

idEstatistica INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
dados_grafico VARCHAR NULL,
dados_estatistica VARCHAR NULL,
PRIMARY KEY(idEstatistica),
INDEX Estatistica_FKIndex1(Projeto_idProjeto),
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
CREATE TABLE Tempo (
idTempo INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
FaseProjeto_idNivelPSP INTEGER UNSIGNED NOT NULL,
hora_inicio TIME NULL,
hora_final TIME NULL,
PRIMARY KEY(idTempo),
INDEX Tempo_FKIndex1(Projeto_idProjeto),
INDEX Tempo_FKIndex2(FaseProjeto_idNivelPSP),
ON DELETE NO ACTION
ON UPDATE NO ACTION,
FOREIGN KEY(FaseProjeto_idNivelPSP)
REFERENCES FaseProjeto(idNivelPSP)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
CREATE TABLE Defeito (

idDefeito INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
Defeito_idDefeito INTEGER UNSIGNED NOT NULL,
TipoDefeito_idTipoDefeito INTEGER UNSIGNED NOT NULL,
hora_inicio TIME NULL,
hora_final TIME NULL,
PRIMARY KEY(idDefeito),
INDEX Defeito_FKIndex1(FaseProjeto_idNivelPSP),
INDEX Defeito_FKIndex2(TipoDefeito_idTipoDefeito),
INDEX Defeito_FKIndex3(Defeito_idDefeito),
ON DELETE NO ACTION
FOREIGN KEY(TipoDefeito_idTipoDefeito)
REFERENCES TipoDefeito(idTipoDefeito)
ON DELETE NO ACTION
FOREIGN KEY(Defeito_idDefeito)
REFERENCES Defeito(idDefeito)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
CREATE TABLE NivelPSP_FaseProjeto (

NivelPSP_idNivelPSP INTEGER UNSIGNED NOT NULL,
PRIMARY KEY(NivelPSP_idNivelPSP, FaseProjeto_idNivelPSP),
INDEX NivelPSP_has_FaseProjeto_FKIndex1(NivelPSP_idNivelPSP),
INDEX NivelPSP_has_FaseProjeto_FKIndex2(FaseProjeto_idNivelPSP),
FOREIGN KEY(NivelPSP_idNivelPSP)
REFERENCES NivelPSP(idNivelPSP)
ON DELETE NO ACTION
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
CREATE TABLE Planejamento (

idPlanejamento INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
CodigoFonte_idCodigoFonte INTEGER UNSIGNED NOT NULL,
tempo_desenvolvimento TIME NULL,
numero_LOC INTEGER UNSIGNED NULL,
PRIMARY KEY(idPlanejamento),
INDEX Planejamento_FKIndex1(Projeto_idProjeto),
INDEX Planejamento_FKIndex2(CodigoFonte_idCodigoFonte),
ON DELETE NO ACTION
FOREIGN KEY(CodigoFonte_idCodigoFonte)
REFERENCES CodigoFonte(idCodigoFonte)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
CREATE TABLE Planejamento_FaseProjeto (

Planejamento_idPlanejamento INTEGER UNSIGNED NOT NULL,
PRIMARY KEY(Planejamento_idPlanejamento, FaseProjeto_idNivelPSP),
INDEX Planejamento_has_FaseProjeto_FKIndex1(Planejamento_idPlanejamento),
INDEX Planejamento_has_FaseProjeto_FKIndex2(FaseProjeto_idNivelPSP),
FOREIGN KEY(Planejamento_idPlanejamento)
REFERENCES Planejamento(idPlanejamento)
ON DELETE NO ACTION
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
13. Bibliografia
WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação Orientados a

Objetos. Editora Campus. Rio de Janeiro: Elsevier, 2004.
FIGUEIREDO, F. C.; FIGUEIREDO, H. C. M. Dominando gerenciamento de

projetos com o MS Project 2002. Ciência Moderna, Rio de Janeiro, RJ, 2003.
PMBOK 2004, Um Guia do Conjunto de Conhecimentos em Gerencia de Projetos.

3rd Edition. 2004.
BOGGS, W; BOGGS, M. Mastering UML with Rational Rose 2002. Sybex; Pap/Cdr
edition. 2002.
ERIKSSON, H. E; PENKER, M. UML Toolkit. Wiley. 1997.
FOWLER, M; KOBRYN, C; BOOCH, G. Uml Essencial. Bookman. 3rd Edition. 2000.
RUMBAUG, J; JACOBSON, I; BOOCH, G. The Unified Modeling Language

Reference Manual. Addison-Wesley. 1999.
AMBLER, S. The Elements of UML Style. Cambridge University Press. 2003.

Exemplo - Documentacao de Sistema 000207 - 198631

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Exemplo - Documentacao de Sistema 000207 - 198631

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDADE FEDERAL DE VIÇOSA

CENTRO DE CIÊNCIAS EXATAS E TECNOLOGICAS

Mestrado em Ciência da Computação

Aprovamos o documento aqui apresentado para o desenvolvimento do

Andre Castro Equipe de Desenvolvimento ________________________

Marcelo S. Daibert Equipe de Desenvolvimento ________________________

Comissão Cliente Cliente ________________________

Auditoria Externa Cliente ________________________

Revisor Descrição Data

2 DESCRIÇÃO GERAL ............................................................................................... 7

3 REQUISITOS ESPECÍFICOS .................................................................................. 9

4 MATRIZ DE RASTREABILIDADE ......................................................................... 14

5 DIAGRAMA DE CASOS DE USO.......................................................................... 15

6 MATRIZ DE DEPENDÊNCIA ................................................................................. 18

9 MODELAGEM CONCEITUAL ............................................................................... 54

10 Contratos do Sistema ........................................................................................... 60

11 PROTÓTIPOS DE INTERFACE ............................................................................. 71

12 CÓDIGO FONTE SUGERIDO ................................................................................. 75

1.1. Propósito do Documento

O propósito deste documento é descrever e especificar uma ferramenta de

O objetivo do EasyPSP é fornecer de forma organizada, centralizada e

1.3. Definições e Siglas

EasyPSP Nome dado ao sistema computacional

O consorcio de empresas denominado TABATA Trust é a solicitante deste

2.2. Perspectivas do Produto

• O EasyPSP deverá ser desenvolvido em módulo único.

2.3. Funções do Produto

2.4. Componentes de Evolução do Produto

O desenvolvimento deste sistema será realizado levando em consideração

2.5. Limitações do Produto

O sistema EasyPSP é um sistema independente. Ele será apresentado em

O EasyPSP é desenvolvido para a utilização por desenvolvedores de

Requisito Funcional 1: O sistema deve permitir ao desenvolvedor a

RF1: Gerir Projetos Estado: Proposto

Requisito Funcional 2: O sistema deve permitir ao desenvolvedor a escolha

RF2: Definir Nível PSP Estado: Proposto

Requisito Funcional 3: O sistema deve permitir ao desenvolvedor a escolha

RF3: Definir Fase do Projeto Estado: Proposto

Requisito Funcional 4: O sistema deve permitir ao desenvolvedor a

RF4: Mudar Status da Fase Estado: Proposto

RF5: Contabilizar Automaticamente o Tempo Estado: Proposto

Requisito Funcional 6: O sistema deve permitir ao desenvolvedor a incluir

RF6: Gerir Tempo Estado: Proposto

Requisito Funcional 7: O sistema deve totalizar os tempos contabilizados

RF7: Totalizar Tempo Contabilizado Estado: Proposto

Requisito Funcional 8: O sistema deve permitir ao desenvolvedor cadastrar

RF8: Cadastrar Defeitos Estado: Proposto

RF9: Gerir Defeitos Estado: Proposto

Requisito Funcional 10: O sistema deve permitir ao desenvolvedor

RF10: Gerir Planejamentos Estado: Proposto

Requisito Funcional 11: O sistema deve fornecer ao desenvolvedor uma

RF11: Visualizar Planejamento x Real Estado: Proposto

Requisito Funcional 12: O sistema deve fornecer ao desenvolvedor uma

RF12: Contabilizar Linhas de Código Estado: Proposto

RF13: Gerar Estatísticas de Defeitos Cadastrados Estado: Proposto

Requisito Funcional 14: O sistema deve fornecer ao desenvolvedor uma

RF14: Gerar Estatísticas de Projetos Cadastrados Estado: Proposto

Requisito Funcional 15: O sistema deve fornecer ao desenvolvedor uma

RF15: Gerar Gráficos Estado: Proposto

3.2. Requisitos Não Funcionais

Requisito Não Funcional 1: O sistema deve utilizar um sistema gerenciador

RNF1: Banco de Dados Estado: Proposto

RNF2: Pré-Visualização Estado: Proposto