Metodologia de Desenvolvimento de Sistemas do IFPR Campus

Paranaguá

Versão 1.0

Paranaguá

Fevereiro de 2019
 1. O Processo de Desenvolvimento – Nível 1

Desenvolver o
Encontrar Sistema
Orientador

Elaborar
Pré-Projeto

Homologar
Pré-Projeto

Exame de Banca

Figura 1 – Processo de Desenvolvimento de Sistemas nível 1

A Figura 1 apresenta os processos de nível 1 da MDS do IFPR Campus Paranguá, que são
Encontrar um Orientador, Elaborar o Pré-Projeto, Homologar Pré-Projeto, Desenvolver o
Sistema e Exame de Banca. A figura apresenta também os principais produtos de trabalho, que
são o pré-Projeto, o Visão, o Plno de Desenvolvimento e a Monografia. A seguir são descritas
as atividades do nível 1:

1.1 Encontrar um Orientador

O estudante deve procurar um professor do Campus que tenha disponibilidade de orientá-lo
no desenvolvimento do sistema ou aplicativo. Pode ser um professor que desenvolva pesquisa
na área de conhecimento do sistema, que tenha conhecimento da tecnologia a ser empregada
ou simplesmente tenha tempo disponível. Opcionalmente pode ser convidado também um co-
orientador.

1.2 Elaborar o Pré-Projeto (APÊNDICE 1)

Tendo obtido o aceite verbal de um professor, o aluno pode então elaborar o Pré=Projeto já
sob orientação. O Apêndice A apresenta o gabarito do Pré-Projeto, que é o documento que
declara quem executará o projeto (informações do estudante ou equipe), quem será o
orientador, justificativa do desenvolvimento, objetivos, etapas e um cronograma inicial. Trata-
se de um artefato simples que pode ser feito rapidamente, não deve levar mais de um dia. O
documento deve ser entregue assinado pelos executores e orientadores ao coordenador de
Trabalho de Conclusão de Curso (TCC).

1.3 Homologar Pré-Projeto

O Pré-Projeto é o documento que dará início ao projeto, Ainda não foram levantados muitos
detalhes sobre o sistema a ser desenvolvido, mas o documento atesta que estão presentes os
elementos mínimos para se dar início ao TCC: executores, necessidade e orientador. Estando
presentes tais informações, o Coordenador de TCC pode então homologar o documento e
então tem início o projeto. Esse documento é muitas vezes denominado “Charter” na
literatura de gerenciamento de projetos.

1.4 Desenvolver o Sistema

Assim que o Pré-Pojeto for homologado a equipe deve começar a atividade de Desenvolver o
Sistema, que está subdividida em várias sub atividades que podem ser vistas na Figura 2. São
produtos de trabalho dessa grande atividade o documento de Visão, o Plano de
Desenvolvimento e a Monografia, Na Monografia é feita a juntada dos principais produtos de
trabalho para apresentação à banca e compartilhamento d econhecimento.
 2. Processo de Desenvolvimento de Sistemas nível 2

Figura 2 – Processo de Desenvolvimento de Sistemas nível 2

2.1 Exame de Banca

A Monografia é entregue aos integrantes da banca, conforme agendamento do Coordenador
de TCC. A banca verifica a qualidade do trabalho e da apresentação, podendo aprovar o
trabalho, aprovar apontando correções necessárias ou reprovar.

2.2 O Processo de Desenvolvimento – Nível 2

A Figura 2 apresenta a sequência de atividades em nível 2 do processo de desenvolvimento,
que são sub atividades do macro processo Desenvolver o sistema. O desenvolvimento começa
com a atividade Levantar Requisitos, que vai identificar o escopo do sistema com clareza,
produzindo o documento de Visão e o Diagrama de Casos de Uso, Em seguida, é elaborado o
Plano de Desenvolvimento aplicando técnicas de cálculo de tamanho para se obter uma
estimativa de tempo, equipe e custo para então se elaborar um cronograma,
Após o Plano de Desenvolvimento, o processo de desenvolvimento entra em um ciclo
repetitivo de iterações. Em cada iteração deve ser construído um caso de uso ou mais de um,
de acordo com o que consta do planejamento e cronograma. Esse ciclo vai se repetir até que
todos os casos de uso estejam construídos e testados.

Cada ciclo ou iteração de desenvolvimento se compõe das seguintes atividades: Desscrever

Caso de Uso, Descrever Caso de Teste, Diagramas Estados (se o caso de uso for em tempo
real), Modelar Classes de Anpalise, Modelagem Dinâmica, Modelagem da Persistência,
codificação do caso de uso e Testes. A seguir, cada uma dessas atividades será descrita a
seguir.

2.3 Levantar os Requisitos (APÊNDICE 2)

No levantamento e requisitos é produzido o documento de Visão (Apêndice B). O visão fornece
uma ideia geral do escopo do sistema: qual é o problema que resolve, qual é a solução
concebida, a lista dos interessados ou envolvidos, descrição do ambiente do usuário, requisitos
funcionais, requisitos não funcionais, análise de alternativas e uma revisão da literatura sobre
o negócio a ser informatizado. O Apêndice 2 apresenta o documento de Visão, que lista os
requisitos do sistema.

Com base nos requisitos funcionais é elaborado o Diagrama de Casos de Uso.

2.4 Planejar o Desenvolvimento (APÊNDICE 3)

A atividade de Planejar o Desenvolvimento é elaborado o Plano de Desenvolvimento. Nesse
passo são detalhadas as funções da equipe de desenvolvimento, uma análise de riscos é
elaborada e é feito um cálculo estimativo do tamanho do software. Com base nesses
elementos, pode ser então determinado um cronograma para o projeto, uma análise de
viabilidade e um orçamento. Nessa atividade devem ser planejadas as iterações e casos de uso
que nelas serão construídos, as datas de entrega e data de conclusão do desenvolvimento. As
entregas são marcos que devem ser perseguidos como compromissos a serem honrados. Com
esse artefato, estudante, orientador e corrdenador de TCC têm um instrumento útil para
acompanhar o andamento do projeto e da fase seguinte, em que serão executadas interações
que produzirão mais que documentos: componentes executáveis de software e sempre que
possível, casos de uso implementados que já podem ser testados e validados pelos clientes ou
interessadod.

2.5 Descrever Caso de Uso (APÊNDICE 4)

A atividade de Descrever Caso de Uso deve seguir o que foi planejado e descrever apenas o
caso de uso que está sendo construído na iteração. Como produto dessa atividade, resulta a
especificação do caso de uso e também o protótipo da interface gráfica do caso de uso (se
houver). O Apêndice 4 apresenta o gabarito de uma especificação de caso de uso, com
orientações para sua elaboração.
2.6 Descrever Caso de Teste (APÊNDICE 5)
Com base na especificação do caso de uso é elaborada a Especificação do Caso de Teste para o
caso de uso que está sendo constru[ido. Este documento detalha a sequênia de passos que o
testador deve executar para testar o caso de uso já construído. É o teste de caixa preta do caso
e uso.

2.7 Diagramar Estados

Se o caso de uso que etá sendo construído na iteração tiver requisitos de tempo real, então é
útil elaborar o diagrama de estados para as classes envolvidas. Para sistemas que não tenham
requisitos de tempo real essa atividade não é necessária.

2.8 Modelar Classes de Análise (APÊNDICE 7)

Nessa atividade são identificadas as classes de fronteira, controle e entidade que participam
do caso de uso. Para cada caso de uso é designada uma classe de controle, para cada par ator-
caso de uso é criada uma classe de fronteira. As classes de entidade são compartilhadas entre
od diversos casos de uso. É elaborado um diagrama de classes com as classes que participam
do caso de uso. Esse diagrama é denominado Visão das Classes Participantes (VCP). Cada caso
de uso deve ter a sua VCP.

2.9 Modelagem Dinâmica (APÊNDICE 6)

Uma vez identificadas as classes que participam do caso de uso, deve deve ser elaborado um
diagrama de sequência para cada cenário do caso de uso. Devem ser seguidos os passos
descritos na especificação do caso de uso. Para cada ação deve se considerara qual classe terá
responsabilidade de a implementar e qual é a mensagem que a desencadeia.

2.10 Modelagem da Persistência (APÊNDICE 8)

As classes de entidade que estiverem vinculadas a um banco de dados relacional devem passar
por uma modelagem de dados para o projeto dos objetos de banco de dados correspondentes.
Esse modelo vai agregando e integrandoas entidades que forem sendo identificadas à medida
em que o projeto for evoluindo.

2.11 Codificação
Na tividade de codificação os programas fonte do caso de uso são escritos e são feitos os
testes de unidade, observando estritamente as especificações.

2.12 Testes (APÊNDICE 9)

Após a codificação do caso de uso devem ser realizados os testes de caixa preta, ou seja, testes
que verificam se os requisitos estão sendo atingidos, sem verificar o código fonte. Nessa
atividade os passos descritos no caso de teste respectivo devem ser seguidos. Se algum
reauisito não estiver sendo atingido ou for identificado algum erro, o caso de uso deve voltar à
atividade de programação.

2.13 Acabou?
Ao finalizar com sucesso os testes de um caso de uso, deve-se verificar se todas existem mais
iterações de construção a serem executadas ou se todos os casos de uso já foram constru[idos.
Caso haja ainda algum caso de uso a construir, volta-se ao passo Descrever Caso de Uso e nova
iteração de construção e executada.
 APÊNDICE 1 – PRÉ-PROJETO

Eixo de Informação e Comunicação

Curso <Nome do Curso>

Pré-Projeto
<O pré-projeto a pode propor o desenvolvimento de um sistema de informação, .o
desenvolvimento de um software aplicativo ou uma pesquisa. Os textos na cor azul
deverão ser substituídos por um texto na cor preta ou eliminados>

<TÍTULO, em fonte Arial ou Times tamanho 16 negrito.

Exemplo: Sistema de Gestão Educacional Eureca>

Alunos: <Aluno 1>

<Aluno 2>

Orientador: Prof. <Nome do professor orientador>

<Local, mês e ano. Exemplo: Paranaguá, março de 2015>
1 Proponentes
O Projeto será desenvolvido pelas seguintes pessoas:
1.1 Alunos
<Escrever o nome do primeiro aluno, em negrito>
Matrícula: <número da matrícula do aluno>
E-mail: <e-mail do aluno>
Telefone: <telefone do aluno>

<Escrever o nome do segundo aluno, em negrito>

Matrícula: <número da matrícula do aluno>
E-mail: <e-mail do aluno>
Telefone: <telefone do aluno>

1.2 Orientador
<Escrever o nome do Professor Orientador. Opcionalmente pode haver,
também, um co-orientador>
Instituição: <instituição a que pertence o orientador. Exemplo: IFPR
Câmpus Paranaguá>
E-mail: <e-mail do orientador>

2 Descrição do Projeto
2.1 Justificativa
<Explique por que o projeto vale a pena ser desenvolvido. Apresente as
necessidades básicas que serão contempladas com o trabalho.>

2.2 Produto do projeto

<Identifique e explique o produto do projeto. Exemplos: Sistema de protestos
com assinatura digital SIPROASD. Sistema que permitirá o protesto de
duplicatas no cartório pela internet, desde que o cliente tenha um token com
assinatura digital validada por autoridade >
2.3 Cronograma básico do projeto
<Apresente um cronograma com as principais atividades, entregas e demais
marcos do projeto.>

2.4 Necessidades iniciais de recursos

<Apresente as necessidades iniciais de recursos humanos, equipamentos e
material. Exemplo: o projeto terá uma equipe composta por dois elementos e o
professor orientador, além de dois notebooks com Linux, em que está instalado
o Eclipse, como recurso de programação e Astah como ferramenta de
modelagem.>

3 Aprovações

__________________________________ Data: ____ / ____ / ________

Prof. Valério Brusamolin
Coordenador de TCC

__________________________________ Data: ____ / ____ / ________

Prof. <Nome do prof. orientador>
Orientador do TCC

__________________________________ Data: ____ / ____ / ________

<Nome do primeiro aluno>
Orientando

__________________________________ Data: ____ / ____ / ________

<Nome do segundo aluno>
Orientando
 APÊNDICE 2

1.
2. 2. VISÃO DO PROJETO

2.1 Ambiente do Usuário

[Detalhe a organização e o ambiente de trabalho do usuário alvo. Seguem algumas sugestões:
Qual é o negócio da organização? Como é o organograma da organização? Número de
pessoas envolvidas na conclusão da tarefa? Isso está mudando?
Quanto tempo dura um ciclo de tarefas? Período de tempo gasto em cada atividade? Isso está
mudando?
Há quaisquer restrições ambientais a serem observadas: móveis, contatos externos, e assim
por diante?
Quais plataformas do sistema estão em uso atualmente? Futuras plataformas?
Quais outros aplicativos estão em uso? O seu aplicativo precisa se integrar a eles?]

2.2 Declaração do Problema

[Explique qual é o problema que será resolvido por esse projeto. Explique também como o
problema foi identificado, se foi por entrevista, observação direta, aplicação de questionário,
etc.]
Em seguida, faça um resumo utilizando o o seguinte formato:]

O problema de [descreva o problema]

afeta [os interessados afetados pelo problema]

o impacto do qual é [qual é o impacto do problema?]

uma solução bem- [liste alguns dos principais benefícios de uma solução
sucedida deveria bem-sucedida]

Quadro 1 – Declaração do Problema

2.3 Declaração da Solução ou

Produto (Hipótese)
[Descreva aqui como o projeto pretende resolver o problema descrito no item anterior.
Apresente a oportunidade identificada no problema para uma solução de TI, quais são os
benefícios que podem ser proporcionados por essa solução e por que vale a pena desenvolver
o projeto, ao invés de utilizar algum outro produto já disponível no mercado, ou simplesmente
permanecer na situação corrente .Em seguida, elabore uma declaração que resuma, num nível
mais alto, a posição exclusiva que o produto pretende ocupar na lacuna identificada utilizando o
seguinte formato:]
 Para [cliente alvo]

Que [identificação da necessidade ou da oportunidade]

O (nome do produto) é uma [categoria do produto]

Que [declaração do principal benefício ou modificação do

ambiente; ou seja, a razão influente para o
desenvolvimento do projeto]

A menos que [alternativa competitiva principal]

Nosso produto [declaração da principal vantagem ou diferença]

Quadro 2 – Declaração da Solução ou Produto (Hipótese)

[Uma eclaração de posição do produto comunica o propósito do aplicativo e a importância do

projeto à toda a equipe interessada.]

2.4 Resumo dos Interessados

Nome Descrição Responsabilidades

[Nome do interessado.] [Descreva resumidamente
o interessado.]
Quadro 3 – Interessados
[Resuma as responsabilidades
principais do interessado em
relação ao sistema sendo
desenvolvido; ou seja, seus
interesses. Por exemplo, esse
envolvido:
assegura que o sistema será
passível de manutenção
assegura que haverá uma
demanda de mercado para os
recursos do produto
monitora o progresso do projeto
aprova o financiamento
possui conhecimentos importantes
e assim por diante]

2.5 Contexto do Produto

[Colocar o produto na perspectiva de outros produtos relacionados e no ambiente do usuário.
Se o produto for independente e totalmente autônomo, indique-o aqui. Se o produto for um
componente de um sistema maior, essa subseção precisará relacionar como esses sistemas se
interagem e precisará identificar as interfaces relevantes entre os sistemas. Uma maneira fácil
de exibir os principais componentes do sistema maior, as interconexões e as interfaces
externas é com um diagrama de bloco.]
2.6 Premissas e Dependências
[Liste cada fator que afeta os recursos indicados. Liste as premissas que, se modificadas,
alterarão o projeto. Por exemplo, uma premissa pode indicar que um sistema operacional
específico estará disponível para o hardware designado para o produto de software. Se o
sistema operacional não estiver disponível, o projeto precisará ser alterado.]

2.7 Requisitos Funcionais e Recursos

[Apresente os requisitos funcionais. Concentre-se nos recursos necessários e no porquê (não
em como) eles devem ser implementados. Na liberação planejada, informe em que data ou
fase do projeto o requisito deve ser atendido.]

Libera
ção
Código Requisito Necessidade Prioridade Recursos
Planeja
da

RF[seq] [Escreva aqui o Requisito] [Justifique por que o requisito [Alta, media [recursos [data ou
é necessário, qual problema ou baixa] necessários] fase da
[seq é a
ele vai resolver] ] liberaçã
sequência,
o]
começand
o com 01]

Quadro 4 – Requisitos Funcionais e Recursos

2.8 Alternativas
[Identifique as alternativas das percepções do interessado, conforme disponíveis. Explique
como fez a busca por alternativas. Elas podem incluir a compra de um produto do concorrente,
a compra de uma solução desenvolvida internamente ou simplesmente a manutenção do status
quo. Liste todas as opções competitivas conhecidas existentes ou que possam se tornar
disponíveis. Inclua as principais forças e fraquezas de cada concorrente, conforme percebido
pelo envolvido ou usuário final.]

2.9 Outros Requisitos da Solução

[Lliste os padrões aplicáveis, o hardware ou os requisitos de plataforma; requisitos de
desempenho; requisitos de segurança, usabilidade, confiabilidade, suportabilidade, estabilidade
e outros que sejam importantes para o sistema.
Defina as faixas de qualidade para desempenho, robustez, tolerância a falhas, utilidade e
características semelhantes que não sejam capturadas no Conjunto de Recursos.
Observe quaisquer restrições de design, restrições externas ou outras dependências.
Defina qualquer requisito específico da documentação, incluindo manuais do usuário, ajuda on-
line, instalação, identificação e requisitos de embalagem.
Defina a prioridade desses outros requisitos do produto.

Código Requisito Tipo Prioridade

RNF[seq] [Escreva aqui o Requisito] [plataforma; desempenho; [Alta, media ou

segurança, usabilidade, baixa]
[seq é a
confiabilidade, suportabilidade,
sequência,
estabilidade ou outro tipo]
começand
o com 01]
2.10 Equipamentos e Tecnologias necessárias (Materiais e métodos)
[Descreva os equipamentos e tecnologias que são necessários para o desenvolvimento do
projeto. Faça uma pesquisa bibliográfica sobre as tecnologias a serem aplicadas no projeto.]

2.11 Revisão da Literatura

[Elabore uma pesquisa abordando o negócio a ser informatizado, privilegiando fontes de
informação recentes, ou seja, mostre qual é o estado da arte. Apresente ao leitor um bom
resumo dos conhecimentos mínimos necessários para bem entender o sistema.]
 APÊNDICE 3

3. PLANO DO PROJETO

3.1 Estrutura Organizacional da Equipe do Projeto

[Organograma da equipe que construirá o sistema. Elaborar um diagrama (organograma) e um
texto explicativo, listando as funções e detalhando suas responsabilidades]

3.2 Interfaces Externas

[Descreva como o projeto faz a interface com grupos externos. Para cada grupo externo,
identifique nomes de contatos internos e externos. Isso deve incluir as responsabilidades
relacionadas à implementação e à aceitação do produto.]

3.3 Funções e Responsabilidades da Equipe do Projeto

[Identifique a pessoa que possui uma responsabilidade no projeto e quais funções elas
desempenham.]

Pessoa Função

Coordenador de Projeto
Gerente de Implementação
Davi Moreno Revisor de Requisitos
Revisor de Arquitetura
Gerenciador de Configuração
Gerenciador de Controle de Mudanças
Roberta Nemoy Revisor de Projeto
Revisor de Requisitos
Analista de Sistemas
Especificador de Requisitos
Designer da Interface com o Usuário
Antonio Barela Arquiteto de Software
Revisor de Design
Gerente de Testes
Analista de Teste
Projetista
Mário Eli Implementador
Revisor de Código
Carla Tirol Projetista de Teste
Testador
Responsável por manter o site do projeto na Web,
ajudar o Gerente do Projeto no
planejamento/programação de tarefas e ajudar o
Pedro Silva
Gerente de Controle de Mudança a controlar
mudanças nos produtos de trabalho. Também pode
ajudar em outras funções conforme necessário.

Quadro x – Funções e Responsabilidades

3.4 Análise de Riscos
[Identificação dos riscos do projeto e planejamento das ações preventivas e de contingência.
Preencher um quando como o a seguir para cada risco identificado. A ação preventiva visa
evitar que o risco aconteça, e a ação de contingência, o que fazer caso o risco ocorra. Dano é o
estrago que o risco provoca e impacto é o reflexo que ele traz para o projeto.]
Risco Risco: [Escrever aqui o nome do risco]
1
Probabilidade: Id Dano Impacto

[alta, média ou baixa] 1

...

Id Ações Preventivas Responsável

...

Id Ações de Contingência Responsável

...

Quadro x – Risco de xxxxxxxx

3.5 Análise de Pontos de Caso de Uso

[Com base no diagrama de casos de uso, calcule o tamanho do sistema e tempo necessário
para realizá-lo. Caso tenha sido necessário reduzir o escopo para que seja viável no prazo de
um ano, declare os casos de uso que não serão contemplados no projeto.]

3.5.1 Total de Pesos não Ajustados de Atores

[Calcule o Total de Pesos não Ajustados de Atores. Preenchendo a tabela a seguir]
Tipo de Ator Peso Quantidade Resultado
Ator Simples 1
Ator Médio 2
Ator Complexo 3
Total (TPNAA)
Tabela x – Pesos não Ajustados de Atores

3.5.2 Total de Pesos Não Ajustados dos Casos de Uso

[Calcule o Total de Pesos não Ajustados dos Casos de Uso Preenchendo a tabela a seguir]
Tipo de Caso de Uso Peso Quantidade Resultado
UC Simples
 UC Médio
UC Complexo
Total (TPNAUC)
Tabela x – Pesos não Ajustados dos Casos de Uso

3.5.3 Fator de Ajuste Técnico

[Para cada requisito listado na tabela, deve ser atribuído um valor que determina a influência
do requisito no sistema, variando entre 0 e 5. Multiplique a influência pelo peso e obtenha o
resultado]

Fator Requisito Peso Influência Resultado

T1 Sistema distribuído 2
T2 Tempo de resposta 2
T3 Eficiência 1
T4 Processamento complexo 1
T5 Código reusável 1
T6 Facilidade de instalação 0,5
T7 Facilidade de uso 0,5
T8 Portabilidade 2
T9 Facilidade de Mudança 1
T10 Concorrência 1
T11 Recursos de segurança 1
T12 Acessível a terceiros 1
T13 Requer treinamento 1
especial
Fator T
Tabela x – Fator de Ajuste Técnico

 Fator de Complexidade Técnica (FCT) = xxxx [FCT = 0,6 + (0,01 x

Fator T)]

3.5.4 Fator de Ajuste Ambiental

[Para cada requisito listado na tabela, deve ser atribuído um valor que determina a influência do
requisito no sistema, variando entre 0 e 5]

Fator Descrição Peso Influência Resultado

A1 Familiaridade com Processo Unificado ou 1,5
outro processo formal
A2 Experiência com a aplicação em 0,5
desenvolvimento
A3 Experiência com Orientação a Objetos 1
A4 Presença de analista experiente 0,5
A5 Motivação 1
A6 Requisitos Estáveis 2
A7 Desenvolvedores trabalhando em tempo -1
parcial
A8 Dificuldade com a linguagem de programação -2
Fator A
Tabela x – Fator de Ajuste Ambiental
  Fator de Complexidade Ambiental (FCA) = xxxxx [FCA = 1,4 + (-0,03 x
Fator A)]

3.5.5 Estimativas

 Pontos de Casos de Uso (PCU) = xxx [PCU = (TPNAA + TPNAUC)xFCTxFCA]

 Tempo de Trabalho Estimado (TTE) = xxxx h [PCU x 20]

 Custo da Mão de Obra Estimado = R$ xxx,xx [TTE x custo homem hora]

3.5.6 Casos de Uso que não serão implementados

[Listar os casos de uso que não serão implementados para reduzir o escopo a um tamanho
viável para o prazo de um ano. Caso o escopo não tenha sido reduzido, escreva “Não se
aplica”]

3.6 Cronogramas
[Diagramas ou tabelas que mostram as datas de término para conclusão das iterações e fases,
pontos de liberação, demos e outros marcos

3.6.1 Entregáveis
[Liste aqui os produtos de trabalho que serão entregues ao longo do projeto. As entregas
listadas deverão constar dos cronogramas como marcos. A Elaboração deve se encerrar no
primeiro semestre]
Produto de trabalho Quem recebe Quando
Pré-projeto Coordenador TCC Início dos
trabalhos
Visão Orientador Iniciação
Modelo de Casos de Uso (sem Orientador Iniciação
especificações)
Validação do Escopo com os interessados Interessados Iniciação
Plano de Desenvolvimento Orientador Final Iniciação
Validação do Plano de Desenvolvimento Interessados Final Iniciação
com os interessados
Ambiente de Desenvolvimento Configurado Orientador Elaboração
Especificação UC da fase de Elaboração Orientador Elaboração E1..En
Protótipos de tela dos UC da Elaboração Orientador Elaboração E1..En
Especificação Caso de Teste do UC Orientador Elaboração E1..En
Elaboração
Resolução do UC da Elaboração Orientador Elaboração E1..En
Codificação UC da Elaboração Orientador Elaboração E1..En
Teste do UC da Elaboração Orientador Elaboração E1..En
Monitoramento de riscos na Elaboração Orientador Elaboração E1..En
Diagrama de Classes Orientador Final da
Elaboração
Modelo de Dados Orientador Final da
Elaboração
Descrição das Tabelas Orientador Final da
Elaboração
Validação da Arquitetura Orientador, Final da
Interessados Elaboração
 Especificação UC da fase de Construção Orientador Construção
C1..Cn
Protótipos de tela dos UC da Construção Orientador Construção
C1..Cn
Especificação Caso de Teste do UC Orientador Construção
Construção C1..Cn
Resolução dos UC da Construção Orientador Construção
C1..Cn
Codificação UC da Construção Orientador Construção
C1..Cn
Teste do UC da Elaboração Orientador Construção
C1..Cn
Monitoramento de riscos na Construção Orientador Elaboração
C1..Cn
Apresentação do UC construído aos Interessados Construção
interessados C1..Cn
Validação do sistema com o Usuário Usuário Final da
Construção
Instalação do sistema no ambiente de Usuário Transição
produção
Treinamento dos interessados Interessados Transição
Monitoramento de riscos na Transição Orientador Transição
Monografia Banca examinadora Transição
Apresentação à banca examinadora Banca examinadora Transição
Entrega trabalho corrigido ao Coordenador Coordenador TCC Final da Transição
de TCC
Quadro x – Lista de Entregáveis

3.6.2 Cronograma inicial

[Os cronogramas devem apresentar as atividades a serem realizadas e os marcos. Preveja,
como um marco, uma reunião a cada mês com o orientador para acompanhamento, entregas e
revisão do cronograma. As reuniões semanais com o orientador não precisam constar do
cronograma. O cronograma deve também indicar as dependências entre as tarefas. Deve
existir no mínimo um cronograma, o inicial. A cada mudança que impacte em prazo ou escopo,
o cronograma deve ser ajustado e uma nova versão é elaborada. Apresente também tais
cronogramas, destacando em texto o que foi modificado.]

Data Data
Iteração

Objetivo Primário (riscos/casos de Depen-

Fase Responsável
uso abordados) dências
Início Conclusão

Iniciação I1

Elaboração E1

Construção C1

C2

Transição T1

T2

Quadro x – Cronograma Inicial do Projeto

3.6.3 Cronograma realizado
[Apresente aqui a versão final do cronograma. Caso existam outras mudanças que tenham tido
impacto no cronograma, apresente-as antes desse último]

3.7 Recursos do Projeto

[Identifique a quantidade necessária de cada perfil já apresentado, acrescentando quaisquer
habilidades especiais ou experiência. Planejar o emprego do recurso por fase de projeto ou
iteração.
Descreva como os recursos humanos necessários para o projeto serão obtidos.
Liste qualquer treinamento especial que os membros da equipe do projeto necessitarão, com
as datas de término para quando esse treinamento deveria ser concluído.]

3.8 Orçamento
[Descreva o tamanho do orçamento financeiro, como ele está alocado e como ele será
monitorado.]

3.9 Repositório
[Indicar o local em que os programas fonte, executáveis, modelos, documentos e outros
produtos de trabalho estão armazenados. Explicitar também se o acesso é público ou privado.
Listar também as ferramentas e versões das mesmas são necessárias para acessar os
produtos de trabalho.].

3.10 Análise de viabilidade

[Avaliar a viabilidade de atingir os objetivos do projeto, considerando restrições e recursos
disponíveis. Se necessário, realize ajustes para adequar o projeto às restrições de tempo,
recursos financeiros, recursos humanos e outras solicitadas pelo cliente].
 APÊNDICE 4
4. MODELO DE CASOS DE USO

4.1 Diagrama de Casos de Uso

[Colocar aqui o diagrama de casos de uso do sistema]

4.2 Lista de Atores

[Listar os atores e fornecer uma breve descrição de cada um deles]

4.3 Lista de Casos de Uso

[Listar os Casos de Uso e fornecer uma breve descrição para cada um deles]

4.4 Detalhamento dos Casos de Uso

[Para cada caso de Uso, elaborar um quadro como a seguir]

Nome do Caso de Uso Coloque o nome do Caso de Uso

Descrição Descreva brevemente o propósito o Caso de Uso
Pré Condições Se existir uma ou mais pré-condições, descreva-as aqui
Pós Condições Se existir uma ou mais pós-condições, descreva-as aqui
Atores Liste os atores que se relacionam com este Caso de Uso (observe
o diagrama de casos de uso)
Requisitos vinculados [Escrever os códigos dos requisitos funcionais e não funcionais
que se aplicam ao caso de uso ex: RF01, RNF03]
Fluxo Principal
Ações do Ator Ações do Sistema
1. O ator X inicia o fluxo principal ( ou fluxo 2. O processo recebe a entrada, avalia e envia
ótimo). ao controle.
3. O controle trata a informação.
4. Após tratar a informação os dados são
apresentados ao ator.
Fluxo Alternativo N
Ações do Ator Ações do Sistema
1. O ator X inicia a fluxo alternativo N 2. O processo recebe a entrada, avalia e envia
ao controle.
( ou fluxo de erro, ou fluxo opcional, etc).
3. O controle trata a informação.
4. Após tratar a informação os dados são
apresentados ao ator.
Quadro x – Caso de Uso xxxxxxxx
 5. APÊNDICE 5 - INTERFACES GRÁFICAS

5.1 Interface Caso de Uso xxx

[Colocar aqui figura com esboço da tela do caso de uso. Explicar cada campo da interface,
definindo seu significado, tipo de dado e tamanho. Fazer isso para cada um dos casos de uso,
cada um com seu subtítulo]
 6. APÊNDICE 6 - REALIZAÇÕES DOS CASOS DE USO

6.1 Realização do Caso de Uso [Nome do caso de Uso]

6.1.1 Diagrama de Classes de Análise do UC
[Figura com as classes de análise do caso de uso, ou seja, classes de entidade, fronteira e
controle específicas do caso de uso]

6.1.2 Diagrama de Sequência para o Fluxo xxxx

[Figura com o diagrama de sequência do fluxo xxxx]

6.1.3 Diagrama de Sequência para o Fluxo yyyy

[Figura com o diagrama de sequência do fluxo yyyy]
 7. APÊNDICE 7 - DIAGRAMA DE CLASSES

[Colocar aqui o diagrama geral de Classes, com todas as classes de Entidade do Sistema e
suas associações (Não colocar classes de fronteira nem de controle)]
 8. APÊNDICE 8 - PERSISTÊNCIA

8.1 Banco de Dados

[Descrever a tecnologia empregada para a persistência dos dados, especificando o SGBD
selecionado, explicando por que foi escolhido, versão e detalhes de configuração]

8.2 Modelo de Entidades e Relacionamentos

[Figura com o MER do sistema]

8.3 Descrição das Tabelas

[Descrever as tabelas do sistema com suas colunas, detalhando tipo e tamanho, conforme
quadro a seguir, elaborando um para cada tabela do sistema.]

Tabela <nome da tabela>

Coluna Descrição Tipo Nulo PK FK Tabela de
referência

Quadro x – Tabela xxxxxxxxx

[Coluna: nome da coluna ou campo
Descrição: significado da coluna
Tipo: tipo da coluna e tamanho (entre parênteses)
Nulo: S se admtir valores nuls, N caso contrário
PK: S se a coluna for ou fizer parte da chave primária
FK: S se a coluna for chave estrangeira
Tabela de referência: tabela origem da chave estrangeira]
 9. APÊNDICE 9 - PLANO DE TESTES

[Este tópico deve relacionar os testes que devem ser aplicados antes de qualquer liberação]

9.1 Casos de uso a serem testados

[Liste aqui os casos de uso e explique por que devem ser testados antes da liberação de uma
nova versão do produto. Selecione para essa lista, os casos de uso cujo mal funcionamento
podem levar a prejuízos ou comprometer a credibilidade no sistema]

Caso de uso Justificativa

[Escreva aqui o nome do caso de uso. [Explicar por que o caso de uso deve ser testado.
Exemplo: “Cadastrar Usuário”] Por exemplo: “Verificar as funcionalidades da
interface de cadastro do usuário”]

Quadro x – Casos de uso a serem testados para a liberação de novas versões

9.2 Casos de Teste

[Elaborar um quadro para cada caso de uso a ser testado, descrevendo as ações a serem
realizadas e os resultados que devem ser obtidos para verificar as situações a serem testadas.]

9.2.1 Caso de Teste UC [nome do caso de uso]

Ite Descrição do teste Resultado esperado
m
[Descrever a ação a ser realizada, [Descrever o resultado esperado, por exemplo:
por exemplo: “Não preencher “Exibir mensagem solicitando preenchimento
todos os campos obrigatórios e dos campos obrigatórios, permanecendo na
acionar o botão OK”. Para definir interface de cadastro”. Os resultados
tais ações, analise o detalhamento esperados devem ser coerentes com o
do caso de uso] detalhamento do caso de uso]
Quadro x – Caso de Teste UC [nome do caso de uso]