Projeto. de Des. de Soft. - Vol. 2 PDF

INFORMTICA
PROJETO DE DESENVOLVIMENTO DE SOFTWARE

VOLUME 2
Governador | Eduardo Campos
Vice-Governador | Joo Soares Lyra Neto
Secretrio de Educao | Anderson Stevens Lenidas Gomes
Secretrio Executivo de Educao Profissional | Paulo Dutra
Gerente Geral da Educao Profissional | Luciane Pula
Gestor de Educao a Distncia | Marcos Paulo de Assis Castro
Coordenador do Curso | Almir Pires
Professor Conteudista | Antnio Mendes
Equipe Central de Educao a Distncia

Andria Guerra | Augusto Andrade | Eber Gomes | George Bento |
Jannine Moreno | Marcos Vincius Clemente | Maria de Lourdes Cordeiro
Marques | Maria Helena Cavalcanti | Mauro de Pinho Vieira | Pedro Luna
Imagem da capa: http://www.imagemativa.com.br/

SUMRIO
CONTEDO PROGRAMTICO.................................................................. 6
APRESENTAO DA DISCIPLINA ........................................................... 8
CONTEDO PROGRAMTICO.................................................................. 9
UNIDADE 4 ................................................................................................ 10
4. ESPECIFICAO DE REQUISITOS DE SOFTWARE ........................ 10
4.1 Requisitos de software .......................................................................... 11
4.2 Documento de requisitos ...................................................................... 13
4.3 Elaborao de documento de requisitos ............................................... 14
Termos e convenes ................................................................................. 19
Prioridades dos requisitos ........................................................................... 20
4.4 Especificao de Requisitos de Sofware .............................................. 28
UNIDADE 5 ................................................................................................ 32
5. DESENVOLVIMENTO DE PROJETO DE SOFTWARE ....................... 32
5.1 Anlise e Projeto Parte 1 ................................................................... 34
5.2 Anlise e projeto parte 2 .................................................................... 35
5.3 Anlise e projeto parte 3 .................................................................... 40
UNIDADE 6 ................................................................................................ 61
6. USO DE FERRAMENTAS DE DESENVOLVIMENTO ......................... 61
6.1 Uso de Ferramentas ............................................................................. 62
6.2 Desenvolvimento de software ............................................................... 67
4 Informtica | Projeto de Desenvolvimento de Software | Volume 2

6.3 Elaborao de plano de teste ............................................................... 71
6.4 Realizao de testes de software ....................................................... 100
REFERNCIA .......................................................................................... 106
Informtica | Projeto de Desenvolvimento de Software | Volume 2 5

CONTEDO PROGRAMTICO
Ementa
Desenvolvimento de um estudo de caso para fixao dos conceitos

aprendidos durante o curso relativos ao desenvolvimento de software. O
estudo de caso ser desenvolvido desde a modelagem, at sua
implementao, com o acompanhamento do professor e deve seguir as boas
prticas de programao a fim de promover modularidade, reusabilidade e
extensibilidade.
Objetivo Geral
Capacitar o futuro profissional para compreender e unir os conceitos

aprendidos durante o curso sobre programao, no desenvolvimento de um
projeto prtico integrado e multidisciplinar para fixao dos conhecimentos
adquiridos. O desenvolvimento do projeto visa preencher as lacunas
formativas atravs da interao dos componentes curriculares englobando
atividades de elicitao de requisitos, modelagem e desenvolvimento de
software.

Objetivos Especficos
Entender os conceitos de ciclos de vida e processos de

desenvolvimento de software;
Definir o escopo de um sistema, bem como levantar, analisar e
documentar os requisitos de software de um sistema;
Utilizar a linguagem de modelagem unificada para criar documentos
de anlise e de projeto de um sistema;
Compreender e saber aplicar os conceitos bsicos da orientao a
objetos;
Utilizar ferramentas para apoiar as atividades de modelagem e
desenvolvimento de software;
Considerar as boas prticas da engenharia de software no
desenvolvimento de um sistema de software.

APRESENTAO DA DISCIPLINA
Prezado(a) aluno(a),
Seja bem-vindo(a) disciplina Projeto de Desenvolvimento de Software. O
ensino desta disciplina tem recebido ateno em cursos de nvel mdio e
tambm nas universidades. Esta disciplina objetiva proporcionar aos alunos
do curso de Tcnico em Informtica a Distncia conhecimento necessrio
para que eles possam identificar a necessidades de um sistema de software a
ser desenvolvido atravs do processo de anlise e, em seguida, especificar
por meio da modelagem as funcionalidades e outras caractersticas do
projeto. Esse conhecimento de suma importncia, pois ele apoir a
atividade de desenvolvimento do software. Como em qualquer outro projeto,
torna-se necessrio conhecer antecipadamente qual produto deseja-se
construir. A disciplina ser apresentada em dois volumes, estando o primeiro
concentrado em fazer introduo engenharia de software e modelo de
desenvolvimento de software juntamente com o plano de projeto a ser
seguido para sua execuo. J o foco do segundo volume recai sobre as
atividades de especificao, projeto e desenvolvimento de software. Esta
segunda parte enriquecida com uso de ferramentas apoio ao

desenvolvimento. Todo este contedo apresentado com um balanceamento
de introduo de novos conceitos e uso de exemplos.
CONTEDO PROGRAMTICO
Volume 2
4 Especificao de Requisitos de Software Estudo de Caso

4.1 Requisitos de software
4.2 Documento de requisitos
4.3 Elaborao de documento de requisitos
4.4 Especificao de requisitos de sofware
5 Desenvolvimento de Projeto de Software Estudo de Caso

5.1 Anlise e projeto parte 1
5.2 Anlise e projeto - parte 2
5.3 Anlise e projeto - parte 3
6 Uso de Ferramentas de Desenvolvimento Estudo de Caso

6.1 Uso de Ferramentas
6.2 Desenvolvimento de software
6.3 Elaborao de plano de teste

6.4 Realizao de testes de software
UNIDADE 4
4. ESPECIFICAO DE REQUISITOS DE SOFTWARE
Na unidade anterior, voc teve a oportunidade de estudar os

componentes de um plano de projeto, bem como suas caractersticas e
importncia para o sucesso de um projeto. Adicionalmente, voc tambm
aprendeu como elaborar um plano de projeto (para o desenvolvimento de
software em uma organizao). Nesta unidade, a nfase est na
especificao de requisitos de software.
Um engenheiro de software um profissional que deve ter a habilidade

de antecipar e gerenciar mudanas de requisitos (de um produto). Alm disso,
ele precisa saber se expressar e comunicar bem a fim de capturar e registrar
adequadamente o documento de requisitos. Os principais problemas num
desenvolvimento de um sistema de software decorrem do entendimento
errado entre engenheiro de software (produtor), responsvel em apresentar o
documento de requisitos, e usurio (consumidor). Um documento de
requisitos de software precisa ser claro, consistente e completo, porque esse
documento servir de referncia aos desenvolvedores, gerente de projeto,

engenheiros de software (responsveis pelos testes e manuteno do
sistema), alm de servir de base para definir o escopo das funcionalidades a
serem registradas num contrato. Perceba que os requisitos compreendem o
cerne de qualquer produto e mudanas sobre eles podem ocorrer ao longo do
ciclo de vida de um software. Esta unidade trata da importncia do documento
de requisitos de software e exemplifica como ele pode ser elaborado.
4.1 Requisitos de software
Desenvolver um sistema de software requer um processo, o qual

informa um conjunto de atividades a serem realizadas, quem as executam,
quais artefatos de entrada so necessrios e quais artefatos de sada so
produzidos. Nesse sentido, detectar erros ou quaisquer outros problemas
como, por exemplo, inconsistncia e falta de clareza de suma importncia
de modo a tornar o processo mais efetivo sob ponto de vista de custo.
Adicionalmente, envolver o usurio no processo determinante para o

sucesso do produto e do processo. Dentro deste contexto, entender
adequadamente o requisito essencial e essa tarefa do engenheiro de
software. Um requisito compreende uma caracterstica ou funcionalidade que
o sistema deve possuir ou uma restrio que ele (sistema) deve satisfazer
para atender uma necessidade do usurio. Dessa forma, o engenheiro de
software, desempenhando o papel de engenheiro de requisitos, deve
executar duas atividades essenciais para a elaborao do documento de
requisitos:
Elicitao de requisitos atividade na qual os requisitos do sistema a

ser desenvolvido so levantados;

Anlise de requisitos atividade na qual os requisitos so analisados
e confirmados pelos principais interessados do projeto (isto , os
stakeholders) que inclui cliente, usurio final, gerente de projetos,
dentre outros.
Considera-se ainda que a elicitao de requisitos objetiva definir

caractersticas do sistema sob a perspectiva do cliente, enquanto que a
anlise de requisitos visa obter a especificao de requisitos, do ponto de
vista tcnico, conforme entendimento dos desenvolvedores.
Durante a realizao destas atividades, o engenheiro de software est

preocupado em levantar, entender, analisar e, por fim, documentar os
requisitos. Para tanto, ele deve concentrar-se nas caractersticas do sistema e
atributos de qualidade e no em como obt-los. Aqui, preciso identificar
quais requisitos fazem parte ou no do escopo do sistema a ser desenvolvido,
ou em outras palavras, entender a interface do sistema considerado e o
ambiente externo.
importante ressaltar a necessidade de definir o limite ou tambm
denominado escopo do sistema a fim de tratar os requisitos funcionais e no
funcionais do sistema. Entretanto, quando da elaborao do documento de
requisitos, o engenheiro de software deve levar em considerao os
diferentes pontos de vistas dos stakeholders de modo que o documento
resultante possa comunicar adequadamente o conjunto de requisitos do
sistema a ser construdo.

4.2 Documento de requisitos
O documento de requisitos delimita o escopo do conjunto de

funcionalidade que um sistema deve prover, bem como descreve os atributos
de qualidade que devem ser suportados. Este documento deve ser elaborado
de maneira precisa, completa, consistente e, principalmente, compreensvel
aos stakeholders (isto , os principais interessados no sistema). Note que o
documento de requisitos ser lido por vrias pessoas interessadas no projeto
como, por exemplo, cliente, gerente de projeto, engenheiro de testes e
programadores, e, portanto, precisa comunicar com clareza os requisitos do
sistema. Dessa forma, tem-se que um documento de requisitos:
elaborado pelo engenheiro de software e compreende o conjunto
de requisitos do sistema a ser desenvolvido;
Deve ser analisado e confirmado pelos stakeholders;
Integra e relaciona um conjunto de perspectivas dos interessados
do projeto;
Serve como mecanismo de comunicao para os stakeholders (i.e.
as partes interessadas do projeto);
Captura e documenta os requisitos do projeto e serve de referncia
para testes, manuteno e evoluo do sistema.

O documento de requisitos de um projeto tem o objetivo de documentar
o escopo do sistema a ser desenvolvido. Nesse sentido, o documento de
requisitos deve conter:
Introduo e viso geral do documento
Descrio de requisitos funcionais
Descrio de requisitos no-funcionais
Escopo no contemplado (de funcionalidades)
Documentao de apoio
importante perceber a importncia do documento de requisitos como

determinante para o sucesso de um projeto. Ele identifica quais
funcionalidades fazem parte ou no do escopo do sistema. A seo seguinte
apresenta um exemplo de um documento de projeto ilustrando e
complementando os pontos destacados acima.
4.3 Elaborao de documento de requisitos
O documento de requisitos contm um conjunto de informaes que

so de interesse do cliente, gerente de projeto, gerente de negcios a
programadores, analistas e engenheiros de testes. Nesse sentido, quando um
projetista ou engenheiro de software elabora esse documento, ele busca um
compromisso de comunicar bem as funcionalidades do sistema a ser
desenvolvido e da definio em detalhes com clareza e consistncia para os
programadores e engenheiros de testes (responsveis pela implementao
do sistema e elaborao e execuo de plano de testes, respectivamente).
A Tabela 1 apresenta uma relao de itens considerada imprescindveis em
um documento de requisitos. A relao de itens destacados na Tabela 1 no

Itens de um Documento de Contedo
Requisitos
1. Introduo Contm uma descrio dos objetivos do
documento, o pblico ao qual ele se
destina e em linhas gerais o propsito e
escopo do projeto a ser desenvolvido.
Pode adicionalmente conter termos e
abreviaes usadas, tipos de prioridades
atribudas aos requisitos, alm de
informar como o documento deve evoluir.
pressupe a inteno de ser completo, mas de apontar os itens considerados
como obrigatrios num documento de requisitos de uma empresa. Cabe
destacar que os itens sugeridos para compor um documento de requisitos,
conforme apresentado na Tabela 1, leva em considerao as recomendaes
de documento padro IEEE-Std 830-1998 recomendado pelo IEEE e
referenciado no quadro de links deste artigo.

2. Requisitos Funcionais Esta seo descreve, de maneira
sumarizada, as principais funcionalidades
que o sistema de software ir realizar.
Por exemplo, num sistema de biblioteca,
esta seo deveria conter uma descrio
das funcionalidades de autenticao de
usurio e controle de acesso. Observe
que o sumrio das funcionalidades de um
sistema se faz necessrio para permitir o
entendimento (das funcionalidades do
sistema) por diversos stakeholders. O
engenheiro de software deve organizar o
conjunto de funcionalidades do sistema
de modo a torn-las mais compreensveis
ao clientes e demais stakeholders. Vale
ainda ressaltar que o documento de
requisitos pode ser complementado por
outro documento como, por exemplo,
uma especificao de casos de uso.
3. Requisitos No-Funcionais Apresenta-se uma descrio geral de

outros requisitos do produto que limitam
opes de desenvolvimento do sistema.
Isto inclui a descrio de requisitos de
segurana, confiabilidade, timeout de
sesso de usurio, usabilidade, dentre
outros. Esta seo considera os
requisitos do produto, do processo, da
interface grfica e da plataforma
tecnolgica empregada.

4. Escopo No-Contemplado Contm descrio das funcionalidades
no contempladas no escopo do sistema
a ser desenvolvido. Outra denominao
dada a esta seo escopo negativo.
Isto visa garantir s partes interessadas
no sistema (isto , cliente e equipe de
desenvolvimento) quais funcionalidades
fazem parte ou no do conjunto a ser
implementado.
5. Documentao Complementar Exemplos desses documentos

compreende atas de reunies na qual
ocorrero levantamento e validao de
requisitos, bem como plano de projeto.
6. Apndice Trata-se de uma seo que pode conter,

por exemplo, levantamento de perfil de
usurios (do sistema a ser desenvolvido),
descrio do problema a ser
automatizado pelo sistema de software.
importante observar que o apndice no
parte do documento de requisitos e
serve apenas como informao de apoio
para os leitores do documento.
Tabela 1 Relao de itens de um documento de requisitos.

O contedo exato das sees que compem um documento de
requisitos, de um modo geral, varia de empresa para empresa. Entretanto, os
itens acima relacionados acima na Tabela 1 fazem parte da recomendao
padro IEEE-Std 830-1998. As subsees, destacados nos quadros a seguir,

enumerados de 1 5, ilustram o contedo que compe um documento de
requisitos.
1. Introduo
Este documento descreve um sistema que prover notcias e contedo online,

denominado de Sistema Exemplo, a ser desenvolvido para a Empresa XYZ.
Seu propsito prover notcias sobre os mais variados contedos, permitindo
acesso integral a apenas aos usurios leitores cadastrados no sistema. (O
propsito do sistema Exemplo, usado aqui apenas com fins ilustrativos,
similar ao de um sistema como o de portais de jornais e revistas e outros
provedores de contedo que permitem o acesso a contedo, como o portal
UOL, a apenas clientes devidamente cadastrados no sistema).
Viso geral do documento

Esta introduo fornece as informaes necessrias para utilizar este
documento, explicitando seus objetivos e as convenes que foram adotadas
no texto. As demais sees apresentam a especificao do sistema Exemplo
e esto organizadas como descrito abaixo.
Requisitos funcionais: compreende o conjunto de requisitos
funcionais do sistema a ser desenvolvido, descrevendo suas
prioridades.
Requisitos no funcionais: contm os requisitos no funcionais
do sistema a ser desenvolvido, divididos em requisitos de produto,
processo e plataforma tecnolgica.

Escopo no contemplado: descreve as funcionalidades que so
relacionadas com o sistema, mas que no fazem parte do escopo do
mesmo e, portanto, no sero implementadas.
Documentao complementar: compreende um conjunto de
documentos complementares que contm informaes relacionadas
ao projeto.
Termos e convenes
Esta parte do documento explica os conceitos de termos importantes que
sero citados no decorrer deste documento, conforme ilustrado abaixo.
Termo Descrio
Requisitos Requisitos de software que compe o
funcionais sistema, descrevendo aes que o sistema
dever executar quando solicitado.
Requisitos no Requisitos de software que compe o
funcionais sistema, descrevendo atributos (de
qualidade) que o sistema deve possuir ou
restries que ele deve satisfazer.
Requisitos no Requisitos no relacionados ao software
tcnicos como, por exemplo, material de divulgao do
projeto (eventos, relatrios tcnicos e outras
publicaes). Esses requisitos esto fora do
escopo deste documento, podendo ser

includos no Plano do Projeto.
Prioridades dos requisitos
A atribuio de prioridade dos requisitos pode ser de trs tipos: essencial,

importante e desejvel. A prioridade dos requisitos pode ser usada no
gerenciamento do escopo do projeto e na definio das prioridades para o
desenvolvimento do sistema.
Essencial: requisito sem o qual o sistema no entra em
funcionamento. Requisitos essenciais so requisitos imprescindveis,
devendo ser implementados na implantao do sistema.
Importante: requisito sem o qual o sistema entra em funcionamento,
mas de forma no satisfatria. Requisitos importantes no impedem a
implantao do sistema, mas devem ser implementados o mais breve
possvel.
Desejvel: requisito que, embora no implementado, ainda permite
o sistema funcionar de modo satisfatrio sem comprometer as
funcionalidades bsicas do sistema. Requisito desejvel um
requisito que pode ser entregue em qualquer momento sem prejuzo
para os servios oferecidos pelo sistema.
Quadro 1 Exemplo da Seo 1 do Documento de Requisitos.
Note que o quadro 1 acima apresenta uma viso geral do documento e

identifica um subconjunto de termos e convenes que pode caracterizar o
projeto. Todo e qualquer termo, conveno adotada ou abreviaes deveriam

ser apresentadas nesta seo a fim de comunicar s partes envolvidas e
interessadas (i.e. os stakeholders) o seu significado. Isto visa prover os
stakeholders com as denominaes corretas empregadas no projeto.
A seo seguinte apresenta a segunda parte do documento de

requisitos que contm descrio dos requisitos funcionais, conforme ilustrado
na quadro 2.
2. Requisitos Funcionais
2.1 Controle de Acesso

Esta seo apresenta a descrio das funcionalidades de controle de acesso
de usurios alm das funcionalidades para superviso dos acessos ocorridos.
RF01 - Solicitar cadastro no servio de recomendao

Este requisito permite aos usurios solicitar Empresa XYZ o seu
cadastramento no Sistema Exemplo. Essas solicitaes ficam pendentes de
aceitao at que sejam validadas e aprovadas por parte de um funcionrio
da Empresa XYZ.
Prioridade: Essencial Importante Desejvel
RF02 Registrar cadastro de usurio no servio de recomendao

Este requisito permite que um funcionrio da Empresa XYZ valide o cadastro
e libere o acesso de um usurio ao Sistema Exemplo efetuando o seu registro
aps usurio confirmar leitura e aceitao (via Internet) do Termo de
Responsabilidade de Acesso e Uso do Sistema Exemplo.

RF03 - Alterar senha de acesso
Este requisito permite ao usurio trocar sua senha de acesso no sistema.
Para efetivar a troca de senha, os seguintes critrios de segurana sero
verificados: tamanho mnimo e mximo da senha, definio de perodo de
validade da senha e reuso de senhas anteriores. Estes critrios devero ser
definidos no banco de dados. A gerncia dos critrios de segurana da senha
devero ser controladas por um sistema gerenciador de banco de dados
(SGBD).
RF04 Autenticar usurio

Este requisito faz a autenticao do usurio atravs de seu login e senha e,
em seguida, exibe um menu de opes de acordo com as funcionalidades
permitidas ao usurio em conformidade com seu perfil de acesso. Toda vez
que o usurio efetuar um login no sistema, dever ser registrada a abertura
de um log de acesso do usurio.
RF05 Consultar permisses de acesso

Este requisito permite que um funcionrio da Empresa XYZ consulte as
permisses de acesso de usurios ao sistema, obtendo informao sobre o
tipo de acesso e expirao da permisso de acesso ao sistema.
RF06 Cancelar acesso de usurio

Este requisito permite que qualquer usurio autorizado (cadastrado) cancele o
acesso aos contedos do sistema. Os dados dos usurios para cancelar o
acesso ao sistema devem estar definidos no banco de dados.
2.2 Outros Servios

Esta seo descreve as funcionalidades para efetuar alteraes nos
cadastros de usurios, bem como alterao cadastral de dependentes.
RF06 Alterar cadastro de usurio

Este requisito permite que um usurio possa alterar diretamente seus dados
cadastrais no sistema Exemplo, bem como fazer a incluso ou excluso de
usurios dependentes para acesso ao contedo do sistema.
O quadro 2 apresenta a descrio de um conjunto de requisitos

funcionais de um sistema Exemplo. Perceba que o objetivo no foi de ser
completo, mas o de ilustrar como a seo que descreve os requisitos
funcionais de um documento de requisitos poderia ser elaborada. Note
tambm que as informaes apresentadas neste documento tem a inteno
de comunicar s partes envolvidas e interessadas (i.e. os stakeholders) o
conjunto de requisitos funcionais do sistema a ser desenvolvido.

A seo seguinte apresenta a terceira parte do documento de requisitos que
compreende a descrio dos requisitos no funcionais, como ilustrado no
quadro 3.
3. Requisitos No Funcionais
3.1 Requisitos do Produto

Esta seo apresenta a descrio do conjunto de requisitos do Sistema
Exemplo que prover contedo para usurios cadastrados.
RNF01 Segurana
O Sistema Exemplo da empresa XYZ deve dispor de mecanismos de
segurana para a autenticao de usurios e controle de acesso para
contedos e funcionalidades do sistema, garantindo o acesso apenas para
usurios cadastrados. O site dever utilizar protocolo HTTPS, com uso de
certificado digital, garantindo a autenticao do servidor, bem como proteo
e confidencialidade das informaes em trnsito.
RNF02 Senha criptografada

O sistema Exemplo dever prover o usurio com senha criptografada. O
sistema Exemplo deve fazer uso de um algoritmo que no permita obter a
senha criptografada. Este mecanismo de criptografia dever ser
implementado pelo sistema gerenciador de banco de dados (SGBD).

RNF03 Usabilidade
O sistema Exemplo deve prover o usurio com interface simples e intuitiva, de
fcil navegao para facilitar o uso do mesmo por parte dos usurios.
RNF04 Apresentao da interface grfica

O sistema Exemplo deve fazer uso, exclusivamente, da lngua Portuguesa
para todo e qualquer texto apresentado no portal de contedos (isto ,
Sistema Exemplo) e adicionalmente deve ser executado no browser Internet
Explorer, verso 6.0 ou superior , com resoluo 800 x 600.
RNF05 Ajuda online

O sistema Exemplo deve prover os usurios com um Ajuda online para
orient-lo quanto ao acesso e uso das funcionalidades do sistema Exemplo.
3.2 Requisitos do Processo

Esta seo apresenta a descrio dos requisitos relativos ao processo
utilizado no desenvolvimento do sistema Exemplo.
RNF06 Arquitetura de software

A implementao do sistema Exemplo deve empregar uma arquitetura de 3
(trs) camadas: apresentao, negcio e dados.

RNF07 Linguagem de programao adotada
A implementao do sistema Exemplo deve utilizar a linguagem Java,
adotando padro J2EE.
3.2 Requisitos de Tecnologia Adotada

Esta seo apresenta a descrio dos requisitos relativos s tecnologias
adotadas no desenvolvimento do sistema Exemplo.
RNF08 Disponibilidade
O portal de contedos (do sistema Exemplo) dever estar disponvel aos
usurios 24 horas por dia e 7 dias por semana.
O quadro 3 apresenta a descrio de um conjunto de requisitos no

funcionais do sistema Exemplo. Vale ressaltar que apenas alguns requisitos
no funcionais so apresentados para ilustrar como essa seo do
documento de requisitos poderia ser elaborada.
A seo seguinte apresenta a quarta parte do documento de requisitos

que descreve o escopo no contemplado, conforme ilustrado no quadro 4.

4. Escopo No Contemplado
Esta seo apresenta um conjunto de funcionalidades e requisitos que no

esto contemplados no escopo do sistema Exemplo.
4.1 Controle de acesso:

Realizao de bloqueio de acesso aos usurios que possuam
mensalidades em atraso junto empresa XYZ.
Cadastro (incluso, alterao, excluso) de tipos de usurios.
4.2 Outros servios

Atualizao de informaes do portal de contedos.
Mecanismo de FAQ e de busca aos contedos do portal.
Atendimento a consultas atravs de e-mail.
4.3 Segurana
Definio das polticas de segurana necessrias administrao do
sistema.
O quadro 4 apresenta a descrio de um conjunto de funcionalidades e

requisitos no contemplados na implementao do sistema Exemplo.
Finalmente, o quadro 5 apresenta a quinta parte do documento de requisitos
que lista um conjunto de documentos complementares.

Documentao Complementar
Esta seo apresenta documentao de apoio, referenciando um conjunto de

outros documentos que complementam e suportam as informaes contidas
no documento de requisitos.
Ata de Reunio Levantamento de Requisitos do Mdulo A do Sistema

Exemplo, 12/01/2011.
Ata de Reunio Levantamento de Requisitos do Mdulo B do Sistema
Exemplo, 13/01/2011.
Ata de Reunio Levantamento de Requisitos do Mdulo C do Sistema
Exemplo, 14/01/2011.
Ata de Reunio Validao de Requisitos do Sistema Exemplo, 15/01/2011.
Plano de Projeto do Sistema Exemplo.
4.4 Especificao de Requisitos de Sofware
A especificao de requisitos de um sistema de software descreve as

necessidades de usurios do sistema e, mais especificamente, descreve o
conjunto de funcionalidades que o sistema deve fornecer. a partir desta

especificao que o projeto de software desenvolvido para, em seguida, ser
implementado. Quaisquer problemas como, por exemplo, de inconsistncia
ou ambigidade, resultar em possveis erros ou defeitos. que precisaro ser
corrigidos em alguma etapa futura do processo de desenvolvimento.
Adicionalmente ao objetivo acima, uma especificao de requisitos tem

ainda outro objetivo, talvez at mais importante: comunicar de maneira efetiva
quais funcionalidades o sistema deve prover (ou ainda, o que no ir prover).
Perceba que a especificao de requisitos ir apoiar a comunicao entre
usurios (clientes), projetistas, programadores, testadores.
O interesse o de especificar as funcionalidades ou requisitos

funcionais de um sistema. Nesse sentido, o sistema ir prover uma
determinada funcionalidade quando solicitado ou quando uma condio for
alcanada. Dessa forma, o que se tem uma interao entre a funcionalidade
(caracterizada pelo caso de uso) e um ator, que pode um usurio (humano),
um componente de software ou algum hardware (ou dispositivo).
Num exemplo simples do conhecimento do leitor, tem-se a

funcionalidade login de um sistema ou aplicao Web, a qual serve para
autenticar o login e senha de usurios e permitir acesso a determinada
aplicao. Para essa funcionalidade, ou caso de uso, h uma interao entre
usurio e o caso de uso login. Para tanto, um conjunto de passos usado
para descrever o fluxo de eventos da interao entre essas duas entidades.
Caso de uso uma tcnica de especificao que descreve uma

seqncia de aes que o sistema deve realizar para produzir uma resposta
para um ator. Na realidade, tem-se uma seqncia da interao entre caso de

uso e ator. O caso de uso detalha o que um sistema deve fazer, descrevendo
como uma determinada funcionalidade utilizada por um ator.
Cabe ainda destacar que um caso de uso compreende duas partes: o

diagrama de caso de uso e a especificao de caso de uso. O diagrama de
caso de uso um dos nove diagramas da UML (Unified Modeling Language)
enquanto que a especificao (ou descrio) de caso de uso consiste de um
template (ou modelo), conforme apresentado na unidade 5, que serve para
detalhar a seqncia de passos de execuo do caso de uso. (Para mais
informaes sobre diagrama de caso de uso da UML, voc pode consultar os
fascculos que tratam sobre anlise e modelagem de sistemas).
Adicionalmente, os casos de uso servem para especificar as interaes

existentes entre o sistema em desenvolvimento e atores (ou entidades
externas ao sistema). Os atores compreendem usurios, estmulos externos
gerados por dispositivos eletrnicos ou outros sistemas computacionais. Os
atores podem ser considerados como entidades externas ao sistema, j que
esto fora da fronteira do sistema, e so responsveis por gerar eventos para
iniciar interao com caso de uso.
Outra recomendao evitar uso de termos especficos de

implementao, procurando manter o nvel de detalhamento compreensvel
ao usurio. preciso considerar que os casos de uso devem levar em conta o
vocabulrio do usurio. Alm disso, um cenrio uma instncia de um caso
de uso e, portanto, um caso de uso pode conter um ou mais cenrios,
conforme apresentado na unidade 5.
Agora, antes de iniciar os estudos da prxima unidade, muito

importante que voc faa os exerccios e participe das atividades de frum.

Essas atividades so complementares e tm o objetivo de solidificar o seu
conhecimento. Para finalizar, recomendo a voc visitar os sites do quadro de
Para Saber Mais, que contm informaes complementares e interessantes
dos assuntos apresentados nesta unidade. Estas referncias servem de apoio
a voc para realizar suas atividades, bem como ampliar conhecimento deste
contedo.
Agora, contudo, hora das atividades. Bons estudos e at a prxima

unidade.
RESUMO
Este texto caracteriza os requisitos de software e apresenta o
documento de requisitos, o qual constitui documento essencial a um sistema
de software. Nesta unidade, voc tambm teve a oportunidade de aprender

como elaborar um documento de requisitos. Esta unidade foi concluda com
a caracterizao das informaes da especificao de requisitos de software
a ser detalhada na unidade 5.
UNIDADE 5
5. DESENVOLVIMENTO DE PROJETO DE SOFTWARE

Na unidade anterior, voc teve a oportunidade de entender a
importncia de obter a especificao de requisitos de software, bem como de
estudar e aprender como elaborar um documento de requisitos de software.
Esse documento essencial para o projeto e ele serve de base para um
contrato de desenvolvimento de sistema. O documento de requisitos lista o
conjunto de requisitos que o(s) desenvolvedor(es) deve entregar ao cliente.
Nesta unidade, o foco recai sobre a especificao de casos de uso, sua
anlise, documentao e projeto.
Desenvolver um sistema de software uma atividade que requer um

conjunto de habilidades com objetivo de entender as necessidades do usurio
e/ou cliente, analis-las, document-las num documento de requisitos
(apresentado na unidade anterior), desenvolver o projeto, implementar e
testar o software. Perceba que um desenvolver ou projetista de software um
profissional que possui um conjunto de competncias e comum
especializar-se em alguma(s) dela(s). As atividades iniciais so importantes,
j que definem quais funcionalidades o sistema deve prover. Portanto, faz-se
necessrio descrever os requisitos de software com objetivo de facilitar as
etapas seguintes (projeto e implementao). Note que um documento de
requisitos de software precisa ser claro, consistente e completo, pois ele
servir de referncia aos desenvolvedores, gerente de projeto, engenheiros
de software (responsveis pelos testes e manuteno do sistema). Requisitos
bem documentados consideram no apenas consistncia, completude e
clareza, mas tambm a evoluo dos requisitos e, portanto, caractersticas do
sistema de software. Dentro deste contexto, esta unidade se concentra na
especificao de casos de uso para detalhamento dos requisitos de software,

bem com de sua anlise projeto. Esta unidade exemplifica como essa
documentao de projeto pode ser elaborada.
5.1 Anlise e Projeto Parte 1
A especificao de requisitos de um sistema de software um

documento que contm a descrio das necessidades de usurios do sistema
e, mais, especificamente, descreve o conjunto de funcionalidades que o
sistema deve fornecer. Para um exemplo, basta voc consultar o material da
unidade 4.
E, a partir que o projeto de software desenvolvido para, em

seguida, ser implementado. Quaisquer problemas como, por exemplo, de
inconsistncia ou ambigidade resultar em possveis erros que precisaro
ser corrigidos em alguma etapa futura do processo de desenvolvimento.
Adicionalmente ao objetivo, acima, a especificao de requisitos tem ainda

outro objetivo, talvez at mais importante: comunicar de maneira efetiva quais
funcionalidades o sistema deve prover. Perceba que a especificao de
requisitos ir apoiar a comunicao entre usurios (clientes), projetistas,
programadores, testadores.
O interesse o de especificar as funcionalidades ou requisitos

funcionais de um sistema. Nesse sentido, o sistema ir prover uma
determinada funcionalidade quando solicitado ou quando uma condio for
alcanada. Dessa forma o que se tem uma interao entre a funcionalidade,

caracterizada pelo que caso de uso, e um ator, que pode um usurio
(humano), um componente de software ou algum hardware (ou dispositivo).
Num exemplo simples do conhecimento do leitor, tem-se a

funcionalidade login de uma sistema Web, a qual serve para autenticar o login
e senha de usurios e permitir acesso a determinada aplicao como, por
exemplo, ter acesso ao correio eletrnico. Para essa funcionalidade ou caso
de uso, h uma interao entre usurio e o caso de uso login. Para tanto, um
conjunto de passos usado para descrever o fluxo de eventos da interao
entre essas duas entidades (usurio e caso de uso login). A seo seguinte
apresenta e mostra como elaborar um dos documentos de um projeto de
software: a especificao de casos de uso.
Esta seo tem o objetivo de apresentar um detalhamento do

documento de requisitos o qual feito uso de casos de uso. Caso de uso
uma tcnica de especificao que descreve uma seqncia de aes que o
sistema deve realizar para produzir uma resposta para um ator. Na realidade,
tem-se uma seqncia da interao entre caso de uso e ator. O caso de uso
detalha o que um sistema deve fazer, descrevendo como uma determinada
funcionalidade utilizada por um ator.
Cabe destacar que um caso de uso compreende duas partes: o

diagrama de caso de uso e o caso de uso propriamente. O diagrama de caso
de uso um dos nove diagramas da UML (Unified Modeling Language)
enquanto que o caso de uso consiste de um template (ou modelo), conforme

apresentado na seo seguinte que serve para detalhar a seqncia de
passos de execuo do caso de uso. Nesta unidade, um dos objetivos tratar
da especificao de casos de uso, isto , de apresentar e ilustrar template de
especificao e, portanto, diagrama de caso de uso no tratado.
Os casos de uso servem para especificar as interaes existentes

entre o sistema (em desenvolvimento) e as entidades externas (ao sistema).
Entidades externas ou atores compreendem usurios, estmulos externos
gerados por dispositivos eletrnicos ou outros sistemas computacionais.
Outra recomendao evitar uso de termos especficos de

implementao, procurando manter o nvel de detalhamento compreensvel
ao usurio. preciso considerar que os casos de uso devem levar em conta o
vocabulrio do usurio. Alm disso, um cenrio uma instancia de um caso
de uso e, portanto, um caso de uso pode conter um ou mais cenrios,
conforme apresentado a seguir.
Exemplificando a Especificao de Casos de Uso

Casos de uso servem para especificar o comportamento de um sistema
de software ou parte dele, isto , descrevem um conjunto de aes que
produzem algum resultado. Note que o objetivo do caso de uso especificar
o o que e no o como um determinado sistema faz. Um exemplo de
diagrama de caso de uso mostrado na Figura 10.

Figura 10 Exemplo do caso de uso ValidarCliente.
A Figura 10 contm um ator (Cliente) e um caso de uso (ValidarCliente)

com o qual o ator interage. Note que podemos ter interaes entre atores
apenas e entre atores e casos de uso. Essas interaes ocorrem atravs da
troca de mensagens onde os atores se comunicam com o(s) caso(s) de uso.
O fluxo que descreve as aes (i.e. mensagens) trocadas entre atores e caso
de uso denominado de fluxo principal e compe o ncleo do documento da
especificao de casos de uso.
Esse documento contm um conjunto de informaes que so de

interesse do cliente, gerente de projeto, gerente de negcios a
programadores, analistas e engenheiros de testes. Nesse sentido, o
engenheiro de software ao elaborar esse documento busca um compromisso
de comunicar bem o conjunto de passos de cada caso uso do sistema, bem
como prover detalhes com suficiente clareza e consistncia para pblico alvo,
ou seja, os programadores e engenheiros de testes (responsveis pela
implementao do sistema e elaborao e execuo de plano de testes,
respectivamente).
A Tabela 1 apresenta uma relao dos itens considerados

imprescindveis em um documento de especificao de casos de uso. A

relao de itens destacados na Tabela 1 no pressupe a inteno de ser
completo, mas de apontar os itens considerados como obrigatrios num
documento da especificao de casos de uso para uma empresa.
Itens de uma Especificao Contedo

de Casos de Uso
1. Introduo Esta seo contm uma descrio dos
objetivos do documento, o pblico ao qual ele
se destina e, em linhas gerais, o propsito
projeto a ser desenvolvido. Essa seo,
adicionalmente, pode apresentar uma viso
geral do sistema a ser desenvolvido,
informando as demais sees do documento.
2. (Descrio de) Atores Esta seo descreve, de maneira sumarizada,

o conjunto de atores que interagem com os
casos de uso do sistema a ser desenvolvido. A
descrio de cada ator, adicionalmente,
caracteriza seu respectivo papel.
3. (Descrio de) Casos de Apresenta-se uma descrio de todos os casos
Uso de uso que fazem parte do sistema a ser

desenvolvido. Tambm, apresentado o
conjunto de informaes que compem cada
caso de uso. As informaes a serem utilizadas
na especificao de caso de uso so obtidas do

documento de requisitos. O engenheiro de
software deve organizar o conjunto de casos de
uso do sistema de modo a torn-los mais
compreensveis.
4. Referncias (Documentos Exemplos desses documentos complementares
Complementares) compreendem o documento de requisitos, atas

de reunies nas quais ocorreram levantamento
e validao de requisitos e, em aplicaes
especficas, um glossrio.
5. Apndice Trata-se de uma seo que pode conter

informaes de apoio para os leitores do
documento como, por exemplo, diagramas de
casos.
Tabela 1 Relao de itens de um documento de requisitos.
O contedo exato das sees que compem um documento de

especificao de casos de uso pode variar de empresa para empresa.
Todavia, os itens acima relacionados acima na Tabela 1, geralmente, fazem
parte de qualquer especificao de caso de uso. Um detalhamento desses
itens apresentado a seguir.

Os itens destacados na Tabela 1 compreendem as informaes para

projeto do documento de especificao de caso de uso. Esses itens so
apresentados nas subsees, destacados nos quadros a seguir, enumerados
de 1 5, ilustram o contedo que compe um documento de especificao de
casos de uso.
1. Introduo
Este documento especifica os casos de uso de um sistema que prover

notcias e contedo online, denominado de Sistema Exemplo, a ser
desenvolvido para a Empresa XYZ. Seu propsito prover notcias sobre os
mais variados contedos, permitindo acesso integral a apenas aos usurios
leitores cadastrados no sistema. Este documento apresenta descrio dos
fluxos de eventos, entradas e sadas de cada caso de uso a ser
implementado.
(Nota que o propsito desse sistema, usado aqui apenas com fins ilustrativos,
provedores de contedo que permitem o acesso ao contedo a apenas
clientes devidamente cadastrados no sistema).

Viso geral do documento
Esta introduo fornece as informaes necessrias para utilizar este

documento, explicitando seus objetivos do sistema a ser desenvolvido. As
sees abaixo complementam este documento.
Seo 2 Descrio de Atores: apresenta um quadro dos atores
que interagem com o sistema com breve descrio sobre cada um.
Seo 3 Descrio de Casos de Uso: apresenta a especificao
do conjunto de casos de uso do sistema.
Seo 4 Referncias: referencia documentos complementares (isto
, referncias) citadas no documento ou necessrias para o entendimento do
mesmo.
Seo 5 Apndice: compreende um conjunto de informaes
complementares para auxiliar no entendimento do projeto.
Quadro 1 Exemplo da Seo 1 do Documento de Especificao de

Casos de Uso.
Note que o Quadro 1 acima descreve o propsito do documento e

apresenta uma viso geral do documento do sistema a ser desenvolvido,
informando as sees e contedo que compem o documento. Isto visa
prover os leitores (projetista, programador ou engenheiro de teste) com as
informaes corretas das funcionalidades do sistema.

A seo seguinte apresenta a segunda parte do documento de
especificao de casos de uso, a qual contm relao e descrio dos atores.
Atores podem ser usurios (humanos), outros (sub)sistemas (de hardware ou
software) ou ainda uma entidade abstrata que causa algum tipo de estmulo
como, por exemplo, um determinada horrio ou data que alcanada, e gera
um evento (que interage com um caso de uso do sistema).
Perceba que um caso de uso jamais ir iniciar sozinho qualquer ao.

Eles necessitam de algum ator que atua como inicializador das interaes.
importante ainda entender que no apenas um ator inicializa um caso de uso
como tambm pode ser influenciado pela resposta do caso de uso (como
ocorre com o feedback dado pelo sistema a um usurio). Um exemplo da
descrio de atores ilustrado no Quadro 2.
2. Descrio de Atores
Esta seo apresenta a descrio dos atores pertinentes aos casos de

uso especificados neste documento, os quais esto relacionados no
quadro abaixo.
Ator Descrio
Usurio Internet Qualquer usurio que acesse o site do
sistema que prover notcias e contedo online
e venha consultar algum contedo gratuito.

Este usurio no precisa estar cadastrado no
sistema para ter acesso ao contedo gratuito.
Usurio Interno So os funcionrios da empresa XYZ.
Usurio Externo So os usurios cadastrados no sistema de
notcias, os quais tm acesso a todo contedo
via Internet.
Usurio Principal Usurio interno que tem a responsabilidade
de controlar as liberaes/bloqueio de acesso
ao contedo do sistema.
Usurio Usurio externo que tenha sido autorizado
Autorizado pelo usurio principal para ter acesso as
informaes e contedo do sistema.
Artigos Contedo de artigo do sistema de
informaes, cujo acesso autorizado apenas
aos usurios cadastrados.

Casos de Uso.
O Quadro 2 apresenta a descrio de um conjunto de atores de um

sistema Exemplo qualquer. Perceba que o objetivo no foi de ser completo,
mas o de ilustrar como a seo de atores de uma especificao de casos de
uso poderia ser elaborada. Note ainda que as informaes apresentadas

nesta seo tm a inteno de comunicar s partes envolvidas e interessadas
(isto , projetista, programadores e engenheiro de teste) o conjunto de atores
pertinentes ao sistema a ser desenvolvido.
A seo seguinte apresenta a terceira parte do documento de

especificao de casos de uso que compreende a descrio dos casos de
uso seguindo a um template ou modelo que contem um conjunto de itens
como descrito abaixo. Note que essa relao de itens no tem o objetivo de
ser completa.
Nome do caso de uso

Descrio ou sumrio (do caso de uso)
Fluxo principal (ou bsico) de eventos
Fluxo secundrio (alternativo e de exceo)
Pr-condio
Ps-condio
Ponto de extenso
Autor
Data
Um conjunto de caso de uso mostrado no Quadro 3, objetivando

ilustrar uma descrio de casos de uso poderia ser elaborada.

3. Descrio de Casos de Uso
Um caso de uso compreende uma seqncia de aes que o sistema realiza

produzindo algum resultado para um ator.
Os casos de uso nesse documento so identificados pelo termo UC (que

denomina Use Case) seguido de um nmero seqencial, como [UC001].
Cabe destacar que os identificadores dos casos de uso jamais devem ser
modificados ou reaproveitados, para no invalidar referncias externas feitas
a eles.
O fluxo principal descreve o comportamento normal do caso de uso, isto ,

os eventos bsicos necessrios para que o caso de uso seja executado
(normalmente). Eventualmente, pode-se ter um subfluxo que descreve um
fluxo opcional de eventos. Vale ressaltar que um subfluxo no pressupe sua
execuo j que ele pode ou no ser executado. Adicionalmente, um fluxo
secundrio trata de excees, isto , eventos no cobertos no fluxo principal
do caso de uso. Alm disso, se um passo do fluxo de eventos principal puder
levar execuo de um subfluxo ou de um fluxo secundrio, o identificador
do subfluxo ou do fluxo secundrio dever ser referenciado, colocando-se ao
lado deste passo entre parnteses.
O contedo abaixo apresentado descreve um conjunto de requisitos do

Sistema Exemplo que prover contedo para usurios cadastrados.

[UC001] Solicitar cadastro no sistema
Pr-condies: O usurio deve estar na tela de login.
Ps-condies: Se o caso de uso for realizado com sucesso, um termo de
responsabilidade de acesso ao site do sistema de contedos ser gerado.
Ator: Usurio autorizado e usurio principal
Fluxo de eventos principal

1. O sistema apresenta uma tela contendo os seguintes campos:
a. Nome *
b. Endereo *
c. CPF *
d. Correio eletrnico *
e. Telefone *
f. Indicador se o usurio dever ser usurio principal *
Os campos assinalados com * so obrigatrios
2. O usurio preenche os campos ([FS001] Campos de preenchimento

obrigatrio, [FS002] CPF invlido, [FS003] Formato invlido de correio
eletrnico, [FS004] Telefone invlido, [FS005] Usurio no pode ser o
principal).
3. O sistema executa a validar da incluso de usurio, passando os dados

(nome, endereo, CPF, correio eletrnico, telefone e tipo de usurio) que
devem ser validados. ([FS001] Campos de preenchimento obrigatrio;

[FS002] Campo de CPF invlido; [FS003] Formato de correio eletrnico
invlido; [FS004] Telefone no numrico; [FS005] Usurio no pode ser o
principal).
4. O sistema verifica se o usurio deve ser um usurio principal (SB001

Solicitar usurio principal).
5. O sistema apresenta o termo de responsabilidade de acesso ao site.
6. O sistema retorna para a tela de login.
Subfluxos
[SB001] Solicitar usurio principal
1. O sistema verifica autorizao para usurio principal, passando CPF do
usurio ([FS005] Usurio no pode ser o principal).
2. O sistema apresenta o termo de responsabilidade de acesso ao site do

sistema de contedo e de usurio principal.
3. O sistema volta ao passo 5 do fluxo principal
Fluxos secundrios
[FS001] Campos de preenchimento obrigatrio
1. Se o usurio no preencher algum dos campos obrigatrios da tela, o
sistema exibe mensagem solicitando seu preenchimento.

[FS002] CPF invlido
1. Se o dgito verificador do CPF no estiver correto, o sistema exibe
mensagem informando que o CPF invlido.
[FS003] Formato do correio eletrnico invlido

1. Se o correio eletrnico no tiver apenas um caractere @ e no tiver pelo
menos um caractere antes e pelo menos um depois do @, ento o sistema
exibir uma mensagem de erro: Formato do correio eletrnico invlido.
[FS004] Telefone no numrico

1. Se os dados do telefone no forem numricos, o sistema exibe a
mensagem: Telefone deve ser numrico.
[FS005] Usurio no pode ser o principal

1. O sistema verifica se o retorno do servio foi 0XY e exibe a seguinte
mensagem O CPF do usurio informado no pode ser o usurio principal da
empresa informada.
[UC002] Alterar senha

Pr-condies: O usurio deve estar na tela de login.
Pr-condies: Usurio logado.
Ps-condies: Se o caso de uso for realizado com sucesso, o usurio ter
a sua senha alterada.
Atores: Usurio principal, usurio autorizado e usurio interno.

1. O sistema apresenta uma tela com a identificao do usurio e solicita que
o mesmo informe os seguintes campos:
a. Senha de acesso atual *
b. Nova senha de acesso *
c. Confirmao de nova senha de acesso *
d. Lembrete de senha
2. Os campos assinalados com * so obrigatrios
3. O usurio informa os dados solicitados e confirma a efetivao da

alterao da senha. ([FS001] Campos de preenchimento obrigatrio; [FS002]
Confirmao de senha incorreta).
4. O sistema realiza a alterao de senha, passando como parmetro a nova

senha de acesso e o lembrete de senha ([FS003] Senha invlida; [FS004]
Tamanho de senha invlido; [FS005] Senha igual a uma anterior; [FS006]
Timeout Tempo mnimo para alterao de senha no alcanado; [FS007]
Usurio excludo do sistema).
Fluxos secundrios (alternativos e de exceo)

1. Se o usurio no preencher qualquer dos campos obrigatrios da tela do
site, ento o sistema exibir uma mensagem solicitando seu preenchimento.

[FS002] Confirmao de senha incorreta
1. O sistema verifica se a nova senha digitada e a confirmao de nova
senha esto iguais. Se as senhas no estiverem iguais, ento o sistema
exibir a seguinte mensagem: A confirmao da nova senha est incorreta.
[FS003] Senha invlida

1. O sistema verifica se a senha informada est de acordo com os
parmetros definidos na poltica de segurana do sistema e exibir a
mensagem de Senha invlida caso no esteja em conformidade com esses
parmetros.
[FS004] Tamanho de senha invlido

1. O sistema verifica se o tamanho da senha informada est em
conformidade com os parmetros definidos na poltica de segurana do
sistema e exibir a mensagem de Tamanho de senha invlido, caso no
esteja em conformidade.
[FS005] Senha igual a uma anterior

1. O sistema verifica se a senha informada est igual a alguma senha
anterior j utilizada pelo usurio e exibir a mensagem de Esta senha j foi
utilizada anteriormente, caso isso seja verificado.
[FS006] Timeout - Tempo mnimo para alterao de senha no alcanado

1. O sistema verifica se o tempo mnimo (timeout) para alterao de senha
no foi alcanado e exibir a mensagem de Timeout - Tempo mnimo para
alterao de senha no alcanado, caso isso ocorra.

[FS007] Usurio excludo do sistema
1. O sistema verifica se o retorno do caso de uso foi 0XY e exibir a
mensagem de Usurio inativo e j excludo do sistema.
[UC003] Efetuar login

Pr-condies: O usurio deve ser cadastrado no sistema.
Ps-condies: Se o caso de uso for realizado com sucesso, o usurio ser
logado no sistema e ter acesso as funcionalidades vinculadas ao seu perfil.
Atores: Usurio principal, usurio autorizado e usurio interno.

1. O sistema disponibiliza as seguintes opes ao usurio:
a. Solicitar cadastro no sistema
b. Iniciar sistema de atendimento
c. Solicitar lembrete de senha
2. De acordo com a opo selecionada pelo usurio, o sistema executa um

dos seguintes fluxos:
a. [UC001] Solicitar cadastro no sistema

b. [SB001] Iniciar sistema de atendimento
c. [UC004] Solicitar lembrete de senha

Subfluxos
[SB001] Iniciar sistema de atendimento

1. O sistema exibe uma tela solicitando que o usurio preencha os seguintes
campos:
a. Identificao do usurio*
b. Senha*
Os campos assinalados com * so obrigatrios.
2. O usurio informa os dados solicitados e confirma o login. ([FS001]

Campos de preenchimento obrigatrio).
3. O sistema realiza o login do usurio. ([FS002] Usurio invlido, [FS003]

Senha invlida, [FS004] Usurio no cadastrado, [FS005] Usurio bloqueado,
[FS006] Usurio excludo)
4. Verifica se a condio da senha descartvel do usurio ([SB002] Senha

descartvel expirada).
5. O sistema verifica se a senha de acesso do usurio est expirada.
6. Caso a senha de acesso do usurio tenha expirado, o sistema:

a. O sistema registra o log de acesso do usurio, passando os seguintes
parmetros:

i. A identificao do usurio informada,
ii. O IP da mquina cliente,
iii. O evento 5 (acesso com senha expirada).
b. Executa o caso de uso [UC003] Alterar senha.
7. O sistema verifica funcionalidades vinculadas com o perfil do usurio).
8. O sistema exibe uma tela inicial e contedo vinculado ao perfil do usurio

e destaque de ltima noticias.
[SB002] Senha expirada

1. O sistema alterada a condio de senha descartvel do usurio ([FS007]
Usurio no est com senha descartvel).
Fluxos secundrios (alternativos e de exceo)

1. Se o usurio no preencher qualquer dos campos obrigatrios exigidos
pelo sistema, ento o sistema exibir uma mensagem solicitando seu devido
preenchimento.
[FS002] Usurio invlido

2. O sistema verifica se a nova senha digitada e a confirmao de nova
senha so iguais. Se as senhas no estiverem iguais, ento o sistema exibir
a seguinte mensagem: A confirmao da nova senha est incorreta.

[FS003] Senha invlida
1. O sistema verifica se a senha informada est de acordo com os
parmetros definidos na poltica de segurana do sistema e exibir a
mensagem de Senha invlida caso no esteja em conformidade com esses
parmetros.
[FS004] Usurio no cadastrado

1. O sistema verifica se o retorno dado pelo sistema foi 0XY e exibir a
mensagem de Usurio no cadastrado no sistema. Entre em contato com a
Central de Atendimento 0-800-XYZW, caso nenhum dado seja encontrado no
sistema.
[FS005] Usurio bloqueado

1. Caso o usurio esteja bloqueado, o sistema deve:
a. Registrar o log de acesso do usurio, passando os seguintes parmetros:
i. A identificao do usurio
ii. O IP da mquina cliente
iii. O evento 5 (tentativa de acesso com usurio bloqueado).
b. Enviar e-mail para a rea de segurana da Empresa XYZ, relatando a

ocorrncia de tentativa de acesso por usurio bloqueado.
c. Apresentar a mensagem: Usurio bloqueado. Entre em contato com a
Central de Atendimento 0-800-XYZW.

[FS006] Usurio excludo
1. Caso a resposta do sistema seja 0XY, ento o sistema exibir a
mensagem Usurio bloqueado. Entre em contato com a Central de
Atendimento 0-800-XYZW.
[FS007] Usurio no est com senha descartvel

1. Caso a resposta do sistema seja 0XY, ento o sistema exibir a
mensagem Usurio no possui senha descartvel. Entre em contato com a
Central de Atendimento 0-800-XYZW.

Casos de Uso.
O Quadro 3 apresenta a descrio de um conjunto de casos de uso de

um sistema Exemplo. Vale ressaltar que apenas alguns requisitos funcionais
so apresentados para ilustrar como essa seo do documento de
especificao de casos de uso poderia ser elaborada. Veja tambm que
possveis fluxos secundrios, os quais podem existir numa aplicao, foram
ilustrados.
O Quadro 4 apresenta a quarta parte do documento de especificao

de casos de uso que lista um conjunto de documentos complementares, os
quais servem de subsdio ao contedo neste documento.

3. Documentao Complementar
Esta seo apresenta documentao de apoio, referenciando um conjunto de
outros documentos que complementam e suportam as informaes contidas
no documento de requisitos.
1. Documento de Requisitos do Sistema Exemplo, Versao 00.01

22/01/2009.
2. Ata de Reunio Levantamento de Requisitos do Mdulo A do Sistema
Exemplo, 12/01/2009.
3. Ata de Reunio Levantamento de Requisitos do Mdulo B do Sistema
Exemplo, 13/01/2009.
4. Ata de Reunio Levantamento de Requisitos do Mdulo C do Sistema
Exemplo, 14/01/2009.
5. Ata de Reunio Validao de Requisitos do Sistema Exemplo,
15/01/2009.
6. Plano de Projeto do Sistema Exemplo.

Casos de Uso.
Finalmente, a quinta parte do documento de especificao de caso de

uso opcional, podendo ou no fazer parte deste documento. Ela pode
conter, por exemplo, um glossrio de termos usados no documento e tambm
um quadro informando o contedo de cada parte do template da descrio de
caso de uso como ilustrado no Quadro 5.

4. Apndice
Esta seo apresenta contedo do Modelo (Template) de Caso de Uso
utilizado no documento de especificao de casos de uso.
1. Nome do caso de uso trata-se de uma identificao nica do caso de

uso para ser utilizada ou referenciada em todo o documento.
2. Descrio ou sumrio (do caso de uso) Breve descrio do contedo

e propsito do caso de uso.
3. Fluxo principal (ou bsico) de eventos Descrio dos passos que

atores e sistema realizam durante execuo do caso de uso. Trata-se do fluxo
normal de eventos que ocorrem na interao entre ator e sistema para
realizao de um caso de uso.
4. Fluxo secundrio (alternativo e de exceo) Compreendem caminhos

alternativos que podem ser tomados durante a realizao de um caso de uso.
5. Pr-condio Compreende uma lista de condies necessrias para

que um caso de uso acontea.
6. Ps-condio Trata-se uma lista de condies que so consideradas

como atendidas quando um determinado caso de uso encerrado.
7. Ponto de extenso Consiste de uma seqncia opcional de eventos

que includa num caso de uso, podendo ocorrer ou no (j que ela

opcional).
8. Autor Identificao de quem elaborou o documento de especificao

de casos de uso.
9. Data Refere-se a data na qual o documento foi produzido.

Casos de Uso.
Observe que os requisitos compreendem a essncia de um sistema de

software j que eles definem as funcionalidades que o sistema deve fornecer
e sob quais condies o sistema deve operar. Portanto, imprescindvel
documentar adequadamente os requisitos para que o desenvolvimento de
software acontea de modo satisfatrio. Os requisitos so detalhados no
documento de especificao de casos de uso, o qual essencial no projeto.
Isso permite voc construir modelo de projeto que constitui um modelo mais
concreto do que o modelo de anlise, o qual depende da tecnologia
empregada e arquitetura proposta para o sistema. Aqui, voc precisa analisar
seu modelo de classe e implement-lo como apresentado na unidade 6.
Agora, antes de iniciar os estudos da prxima unidade, muito

importante que voc faa os exerccios e participe das atividades de frum.
Essas atividades so complementares e tm o objetivo de solidificar o seu
conhecimento. Para finalizar, recomendo a voc visitar os sites do quadro de
Para Saber Mais, que contm informaes complementares e interessantes
dos assuntos apresentados nesta unidade. Estas referncias servem de apoio

a voc para realizar suas atividades, bem como ampliar conhecimento deste
contedo.

unidade.

RESUMO
Este texto detalha os requisitos de software e apresenta a
especificao de casos de uso, o qual constitui documento essencial para o
projeto de um sistema de software. Nesta unidade, voc tambm teve a
oportunidade de aprender como elaborar uma especificao de casos de uso
essencial no projeto e desenvolvimento de software. A prxima unidade
apresenta detalhamento do projeto de software.

UNIDADE 6
6. USO DE FERRAMENTAS DE DESENVOLVIMENTO
Na unidade anterior, voc teve a oportunidade de estudar atividades

necessrias para o desenvolvimento de sistemas de software, bem como de
estudar e aprender como elaborar um documento de especificao de casos
de uso. Observamos que o referido documento essencial para o projeto e
ele serve de base para um contrato de desenvolvimento de sistema. No
desenvolvimento de software, ferramentas so utilizadas no apoio ao(s)
desenvolvedor(es) em suas atividades. Nesta unidade, o foco recai sobre uso
de ferramentas e atividades de testes para o projeto.
Voc, na condio de projetista (ou desenvolvedor) deve buscar

minimizar seu esforo num projeto de modo a otimizar o tempo com
atividades o que justifica a necessidade de ferramentas de apoio. Mas, qual
ferramenta utilizar? E, onde posso encontrar essas ferramentas?
importante lembrar que voc, como analista e projetista, ao fazer

anlise, voc estar procurando investigar e resolver um problema (modelar
e, depois, desenvolver um sistema). Cabe destacar que o usando uma
ferramenta, voc pode desenhar (ou fazer o design), compartilhar diagramas
(com outras pessoas da equipe), desfazer ou re-fazer diagramas, reutilizar
diagramas e, pode at, gerar cdigo a partir do modelo. Tudo isso justifica o
uso de ferramentas que tm como principal objetivo facilitar o seu trabalho de
projetista.

Dentro deste contexto, esta unidade se concentra na apresentao de
ferramentas e atividades de testes para o desenvolvimento de software.
6.1 Uso de Ferramentas

Agora, observe na hora de escolher uma ferramenta, voc pode
escolher entre um conjunto delas que esto disponveis na Internet e basta
voc fazer o download e instalar em seu computador. Alternativamente, voc
tambm pode adquirir (i.e. comprar) qualquer outra ferramenta proprietria,
que requer que voc pague pelo seu uso. No quadro Para saber mais, no
final desta unidade, voc encontra um link no qual voc tem acesso a uma
lista de ferramentas.
Se voc visitar o Web site que tem a lista de ferramentas, voc ver
que existe dezenas. Este autor, contudo, fez uso de uma delas chamada de
Jude, cujo link tambm est disponvel no quadro Para saber mais.
Por que utilizar a Jude?
Porque ela gratuita, fcil de aprender e usar, alm de permitir ao

usurio criar e alterar diagramas de maneira rpida e intuitiva. Ela no nica
opo que voc tem, mas essas justificativas ajudam na escolha. Voc,
contudo pode explorar qualquer outra da lista de ferramentas.
Primeira coisa que voc tem de fazer fazer o download da ferramenta

Jude (http://jude.change-vision.com/jude-web/download/index.html) e instalar
em seu computador. Entretanto, antes de instalar a ferramenta Jude, voc
deve instalar o Java Environment (ambiente Java) para poder executar a
Jude. Para obter o Java Environment, voc deve acessar http://java.sun.com.
Uma vez voc tenha instalado o Java Environment, voc poder, logo em

seguida, instalar a ferramenta Jude. Depois, basta um duplo clique no cone
da ferramenta e voc ir visualizar a tela mostrada na Figura 11.
Figura 11 Tela principal da ferramenta Jude (verso Community).

Fonte: tela capturada pelo prprio autor.
A verso Jude Community (gratuita) oferece suporta, por exemplo, o

desenvolvimento de modelos do projeto, fazendo uso da maioria dos
diagramas da UML, enquanto que a verso Jude Professional (paga) suporta
todos os diagramas, alm de tambm prover suporte a diagramas ER
(Entidade-Relacionamento). Uma vez voc j tenha a ferramenta instalada,
hora de comear a utiliz-la.

Para iniciar o uso da ferramenta, voc deve criar um projeto e, para
tanto, clique com o boto direito do mouse em File e depois clique em New
como ilustrado na Figura 12.
Figura 12 Tela de criao de projeto com Jude.

Uma vez voc tenha feito, voc visualizar a tela mostrada na Figura
13 e ter seu projeto criado como no_title.jude. Observe que os projetos
(contendo diagramas UML) que voc cria com Jude tem extenso de arquivo
.jude e vem com o pacote (package) default Java (vide Figura 13).

Figura 13 Tela aps criao de projeto com Jude.
Complementando as informaes acima, a Figura 14 apresenta o

contedo de um exemplo de diagrama caso de uso (o qual contm dos casos
de uso Sacar, ValidarSenha e ValidarCarto), onde feito destaque para as
quatro reas em que voc pode atuar na ferramenta. Essas reas esto
ilustradas na Figura 14 e compreendem:
Controle na qual voc, projetista, gerencia e controla todo o processo

de modelagem;
Estrutura que prov uma viso estrutural de como o contedo de seu
projeto (modelagem) est hierarquicamente organizado;

Propriedades onde voc pode renomear diagramas, casos de uso,
classes, mtodos, etc, alm de definir diversos outros parmetros;
Edio onde voc constri os diagramas de seu modelo.
rea de controle
rea da estrutura
do diagrama
rea de propriedades
rea de edio
Figura 14 reas de atuao na ferramenta

Vale ressaltar aqui que o procedimento que voc fez para elaborar o
diagrama de caso de uso, mostrado na Figura 14, pode ser repetido para
elaborar o diagrama de classes, diagrama de seqncia, diagrama de
atividades, diagrama de estados, diagrama de componentes e outros
suportados pela ferramenta. E, para tanto, voc pode explorar a ferramenta.

Perceba que utilizar os recursos oferecidos por uma ferramenta como
a Jude ajuda no desenvolvimento de um projeto, pois voc passa a raciocinar
e se comunicar por meio de uma linguagem comum (UML) que descreve seu
projeto. A prxima apresenta atividades de projeto.
6.2 Desenvolvimento de software

Aps a etapa de anlise, voc tem um primeiro modelo do sistema, isto
, o modelo de anlise. Entretanto, este modelo precisa ser detalhado de
modo que possa facilmente levar a implementao do sistema. O modelo
resultante chamado de modelo de Projeto. Enquanto o modelo de anlise
que voc obteve abstrato, o modelo de projeto concreto e depender da
tecnologia de implementao.
Dessa forma, voc precisa detalhar o modelo de classes, alm de

juntar todas as classes em um s diagrama. Perceba que voc tambm deve
analisar se necessrio criar novas classes ou remover classes existentes.
Adicionalmente, voce deve definir os tipos dos atributos e verificar e definir
modificadores de visibilidade aos mtodos e atributos.
Vale ressaltar que ao revisar o modelo de classes, voc deve procurar

detalhar assinatura dos mtodos, definindo todos os parmetros dos
mtodos, seu tipos e o tipo de retorno dos mtodos, mapear associaes em
atributos, bem como considerar a possibilidade de utilizar herana. Isso,
ento resulta numa modelo de projeto (isto , diagrama de classes) como
ilustrado na Figura 15.

Figura 15 Exemplo de modelo de projeto.
O modelo mostrado na Figura 15 parte de um sistema que tem

funcionalidade (ou caso de uso) ControleValidarUsuario, o qual tem classe de
apresentao (ou interface) TelaValidarUsuario com o mtodo (ou funo)
validarUsuario(). Observe ainda que a classe Usuario tem dois atributos Login
e senha, do tipo String.
Observe que uma vez definidos os diagramas diagrama de classes de

projeto (e outros diagramas tenham sido analisados), a prxima etapa do
desenvolvimento a codificao ou gerao de cdigo. No caso especfico da
gerao de cdigo, possvel uma automatizao ou gerao automtica de
cdigo.

Dentro desse contexto, num primeiro momento, voc pode se
concentrar em gerar o cdigo das classes que realizam toda a lgica do
sistema a partir das operaes de sistema e, depois, gerar as classes das
camadas de persistncia apresentao.
Para ilustrar, considere o diagrama da Figura 15. Com a ferramenta

Jude ou astah, voc pode gerar cdigo como ilustrado na Figura 16.
Figura 16 Processo de gerao de cdigo com a ferramenta Jude.

Aps a gerao, obtm-se cdigo para o conjunto de classes do
diagrama mostrado na Figura 15. Por exemplo, abaixo apresentado o
cdigo gerado para a classe Usuario.
public class Usuario {

private string login;
private string senha;
}
J a classe TelaValidarUsuario teve o cdigo seguinte gerado.
public class TelaValidarUsuario {

private ControleValidarUsuario controleValidarUsuario;
private Fachada fachada;
public void validarUsuario() {
}
public void telaValidacao() {
}
}
Perceba a importncia de se dedicar mais tempo para as atividades de

levantamento e anlise de requisitos, que permitir que voc possa obter
modelos de anlise e projeto correto, bem como uma documentao
adequada. Com o modelo de projeto em mos, possvel gerar cdigo de
maneira automtica.

6.3 Elaborao de plano de teste
No contexto de desenvolvimento de software, voc necessitar de
vrios documentos como, por exemplo, plano de projeto, documento de
requisitos e plano de teste. Nesta seo o foco recai sobre o ltimo, isto ,
plano de teste. Trata-se de um documento ou mapa no qual se define escopo
e objetivos, alm de requisitos, estratgias e recursos a serem empregados
nas atividades de testes de software. Nesse sentido, a seo apresenta os
itens que devem fazer parte de um documento de plano de teste,
exemplificando e discutindo esses itens.
Teste de software uma das atividades do processo de
desenvolvimento de sistema de software que visa executar programa de
modo sistemtico com o objetivo de encontrar falhas. Perceba que isto requer
verificao e validao de software. Nesse sentido, definir quando as
atividades de verificao e validao iniciam e terminam, como os atributos
de qualidade sero avaliados e como os releases do software sero
controlados so questes que devem ser acompanhadas ao longo do
processo de software.
Vale ressaltar que teste no a ltima atividade do processo de
desenvolvimento de software. Ela ocorre durante todo o processo, como
apresentado anteriormente na viso geral do processo RUP (Rational Unified
Process).
E, alm de encontrar falhas, testes objetivam aumentar a confiabilidade
de um sistema de software, isto , aumentar a probabilidade de que um
sistema continuar funcionando sem falhas durante perodo de tempo.

Embora seja desejvel testar um sistema por completo, deve-se ter em
mente que atividade de teste assegura apenas encontrar falhas se ela(s)
existirem, mas no asseguram sua ausncia. Portanto, as atividades devem
ser disciplinadas a fim de identificar maioria dos erros existentes. Um aspecto
que pode ser considerado o perfil operacional do sistema, ou seja, um
conjunto completo das operaes do sistema com suas respectivas
probabilidades de ocorrncia. Note que para realizar os testes de software
implica em responder as questes:
1. Quais atributos da qualidade devero ser testados ?

2. Quem realizar os testes ?
3. Quais recursos sero utilizados ?
4. Quais as dependncias entre os atributos de qualidade ?
5. Quais as dependncias entre as atividades de desenvolvimento
?
6. Como o processo e a qualidade do sistema de software ser
acompanhada ?
A seguir, um exemplo do conjunto de sees de um plano de teste

apresentado com o objetivo de ilustrar como as informaes pertinentes ao
teste de software poderiam ser tratadas e documentas. No h, portanto, o
objetivo de ser completo, pois cada sistema possui suas peculiaridades que
devem ser consideradas caso a caso.

O plano de teste um dos documentos produzidos na conduo de
um projeto. Ele funciona como:
Um integrador entre diversas atividades de testes no projeto;

Mecanismo de comunicao para os stakeholders (i.e. a equipe de
testes e outros interessados);
Guia para execuo e controle das atividades de testes.
O plano de testes que pode ser elaborado pelo gerente de projeto ou

gerente de testes visa planejar as atividades a serem realizadas, definir os
mtodos a serem empregados, planejar a capacidade necessria, estabelecer
mtricas e formas de acompanhamento do processo. Nesse sentido, o plano
de testes deve conter:
Introduo com identificao do projeto (definies, abreviaes,

referncias), definio de escopo e objetivos
Conjunto de requisitos a serem testados
Tipos de testes a serem realizados e ferramentas utilizadas
Recursos utilizados nos testes
Cronograma de atividades (e definio de marcos de projeto)
Em outras palavras, um plano de teste deve definir:
1. Os tens a serem testados o escopo e objetivos do plano

devem ser estabelecidos no incio do projeto.
2. Atividades e recursos a serem empregados as estratgias de
testes e recursos utilizados devem ser definidos, bem como
toda e qualquer restrio imposta sobre as atividades e/ou
recursos.

3. Os tipos de testes a serem realizados e ferramentas
empregadas os tipos de testes e a ordem cronolgica de sua
ocorrncia so estabelecidos no plano.
4. Critrios para avaliar os resultados obtidos mtricas devem
ser definidas para acompanhar os resultados alcanados.
Perceba que o planejamento necessrio a fim de antecipar o que

pode ocorrer e, portanto, provisionar os recursos necessrios nos momentos
adequados. Isto significa coordenar o processo de teste de modo a perseguir
a meta de qualidade do produto (sistema de software).
Exemplificando o Plano de Projeto

O plano de teste contm um conjunto de informaes que permite o
gerente de projeto no apenas coordenar as atividades de testes de um
projeto, mas tambm monitorar seu progresso e verificar se o executado est
em conformidade com o planejado. A Tabela 1 apresenta uma relao dos
itens consideradas imprescindveis em um plano de teste. A relao de itens
destacados na Tabela 1 no pressupe a inteno de ser completo, mas de
apontar os itens considerados como obrigatrios num plano de teste de uma
instituio.

Itens de um Plano de Teste Contedo
1. Introduo Contm uma identificao do projeto,
descrio dos objetivos do documento, o
pblico ao qual ele se destina e escopo
do projeto a ser desenvolvido. Pode
adicionalmente conter termos e
abreviaes usadas, alm de informar
como o plano deve evoluir.
2. Requisitos a serem testados Esta seo descreve em linhas gerais o

conjunto de requisitos a serem testados
no projeto a ser desenvolvido,
comunicando o que deve ser verificado.
Exemplos de requisitos a serem testados
so: desempenho, segurana, interface
de usurio, controle de acesso, funcional.
3. Estratgias e ferramentas de Apresenta-se um conjunto de tipos de
teste testes a serem realizados, respectivas

tcnicas empregadas e critrio de
finalizao de teste. Alm disso, listado
o conjunto de ferramentas utilizadas.
4. Equipe e infra-estrutura Contm descrio da equipe e da infra-

estrutura utilizada para o desenvolvimento
do das atividades de testes, incluindo:

pessoal, equipamentos, software de
apoio, materiais, dentre outros. Isto visa
garantir uma estrutura adequada para a
execuo das atividades de testes
previstas no plano.
5. Cronograma de atividades Contm uma descrio de marcos

importantes (milestones) das atividades
(incluindo as datas de incio e fim da
atividade). Apenas marcos relevantes
devem ser listados, ou seja, aqueles que
contribuiro atividades de testes. Por
exemplo: projeto de testes, execuo de
testes ou avaliao de testes.
6. Referncias Apresenta-se uma relao dos

documentos pertinentes ao projeto.
Tabela 1 Relao de itens de um plano de Teste.
O contedo exato das sees que compem um plano de teste,

geralmente, difere de instituio para instituio. Entretanto, os itens acima
apontados existem nas sees do documento. A subsees, destacados nos
quadros a seguir, enumerados de 1 6) ilustram o contedo que compe um
plano de teste.

1. Introduo
Este documento apresenta o planejamento das atividades de testes do

sistema Exemplo o qual ser utilizado como base s atividades de
acompanhamento, reviso, verificao e validao do projeto desde seu incio
at sua concluso, a fim de garantir a anlise comparativa do resultado real
versus planejado. Desta forma, aes corretivas e preventivas podero ser
tomadas, sempre que resultados reais desviarem significativamente do
planejado.
1.1 Termos e acrnimos

Esta seo explica o conceito de um subconjunto de termos importantes que
sero mencionados no decorrer deste documento. Estes termos so descritos
na Tabela 2, estando apresentados por ordem alfabtica.
Termo Descrio
Artefato Tudo que produzido e documentado em qualquer
atividade de qualquer fluxo do projeto. Por exemplo:
documento de requisitos, diagrama de casos de usos e
glossrio.
Milestone Ponto de checagem; marco que indica a concluso de
uma fase ou etapa.
NA No Aplicvel
Reviso Apresentao de produtos de software para os
interessados visando comentrio e aprovao dos
mesmos.
Tabela 2 Termos e acrnimos do projeto.
1.2 Objetivos
Esta seo contm o conjunto de objetivos que orientam as atividades de
testes do sistema a ser desenvolvido. Esse documento do Plano de Testes do
sistema Exemplo possui os seguintes objetivos:
Levantar as informaes de projeto pertinentes e os componentes de
software a serem testados.
Definir o conjunto de requisitos a serem testados (alto nvel).
Definir e detalhar as estratgias de teste a serem utilizadas.
Definir os recursos necessrios e obter uma estimativa dos esforos das

atividades de teste.
Identificar os artefatos resultantes das atividades de testes.
1.3 Sistema Exemplo (de Informaes Online)

Este documento especifica os casos de uso de um sistema que prover
notcias e contedo online, denominado de Sistema Exemplo, a ser
desenvolvido para a Empresa XYZ. Seu propsito prover notcias sobre os
mais variados contedos, permitindo acesso integral a apenas aos usurios
leitores cadastrados no sistema.
(Nota que o propsito desse sistema, usado aqui apenas com fins ilustrativos,
provedores de contedo que permitem o acesso ao contedo a apenas
clientes devidamente cadastrados no sistema).

1.4 Escopo
Este projeto aborda um sistema Exemplo de informao online, com foco
prover contedo online. Este sistema Exemplo necessitar fazer testes
unitrio, de integrao e de sistema. Os testes unitrios e de integrao visam
tratar a qualidade funcional, a interface grfica e controle de acesso. Por outro
lado, os testes de sistema trataro as questes de performance. Para a
execuo dos testes sero utilizadas mquinas o mais idnticas possvel, em
termos de hardware, quelas que sero implantadas no cliente (provedor de
contedo online, como um portal de notcias), a fim de garantir a
previsibilidade de performance e compatibilidade.
Outros testes como de os testes de stress, de volume e de falha/recuperao

no sero realizados por se considerar que o ambiente de implantao do
sistema nao est sujeito a esse tipo de ocorrencia, as quais podem ser
facilmente previstas e tratadas pelo cliente.
1.5 Documentao do projeto

Esta seo contm o conjunto de documentos e respectiva disponibilidade
para uso no desenvolvimento do plano de testes:
Criado ou Recebido ou
Documento
Disponvel Revisado
Especificao de Requisitos Sim No Sim No
Plano de Projeto Sim No Sim No

Modelo de Anlise Sim No Sim No
Modelo de Projeto Sim No Sim No
Documento de Arquitetura Sim No Sim No
Prottipo Sim No Sim No
Manual do Usurio Sim No Sim No
Lista de Riscos Sim No Sim No
Note que a Tabela 2 acima identifica um subconjunto de termos que

pode caracterizar um projeto. Poderamos, por exemplo, adicionar o termo
IBM para se referir a um produto ou soluo da IBM. Todo e qualquer termo,
conveno adotada ou abreviaes deveriam ser apresentadas nesta tabela a
fim de comunicar s partes envolvidas e interessadas (i.e. os stakeholders) o
seu significado. Isto visa prover os stakeholders com as denominaes
corretas empregadas no documento.
A seguir, apresenta-se uma viso geral do projeto trazendo objetivos,

participantes e mecanismos de evoluo do plano de projeto e aceitao. Isto
exemplificado no quadro abaixo.

2. Viso Geral do Projeto
Analisando-se os aspectos tcnicos (mtodos, processos e ferramentas) e

no tcnicos (gerenciamento, planejamento e questes econmicas) de
produo de aplicativos de software baseados em componentes, este projeto
prope construir a infra-estrutura necessria para o desenvolvimento de
componentes e aplicativos, fazendo uso da plataforma tecnolgica orientada
a servios.
Nesse sentido, os componentes orientados a servio a serem desenvolvidos

pela Empresa AM Ltda (desenvolvedora do projeto) serviro de base para
construo de aplicaes pelo cliente direcionadas rea de Turismo. Como
resultado, isto permitir elevar a produtividade e competitividade, promovendo
a posio do cliente no mercado com uso de solues tecnologicamente
avanadas. Este projeto prope ainda realizar pesquisa e desenvolvimento
da infra-estrutura para o desenvolvimento de componentes e aplicativos
orientado a servios a serem usados pelo cliente.
2.1 Participantes
Esta seo lista o conjunto de participantes e parceiros envolvidos no
desenvolvimento do projeto que sero mencionados no decorrer deste
documento. Esta lista apresentada por ordem alfabtica.
Empresa AM Ltda no papel de Executor
Organizao BrasilTur no papel de Cliente

2.2 Objetivos Especficos
De acordo com o plano de trabalho assinado com o Cliente, os
objetivos desse projeto compreendem:
Anlise de plataformas tecnolgicas;
Desenvolvimento de servios para monitorao e controle de
acesso;
Levantamento e avaliao de requisitos de componentes e
aplicaes de negcio para a rea de Turismo;
Desenvolvimento de prottipo: aplicao para rea de Turismo;
2.3 Critrios de Aceitao do Projeto

A aceitao final do projeto est condicionada a:
Todos os artefatos e indicadores fsicos de execuo descritos
na seo 9.1 devem ter sido aprovados pela Diviso de
Qualidade da empresa;
Todos os objetivos listados na seo 2.2 devem ter sido
atingidos.
2.4 Mecanismos de Evoluo do Plano de Projeto
O plano do projeto deve ser mantido atualizado para refletir a situao
corrente do projeto. Dessa forma, as seguintes situaes representam os
gatilhos para atualizao deste documento:
Alteraes de rubricas junto ao patrocinador (Cliente);
Mudanas nos critrios de aceitao do projeto;

Alteraes dos objetivos previstos no Plano de Trabalho aprovado
pelo cliente;
Mudanas na gerncia do projeto da empresa ou do cliente.
Perceba que os objetivos do projeto so peculiares a cada projeto.

Alm disso, os critrios de aceitao final do projeto resultado de acordo
entre as parte envolvidas (i.e. empresa desenvolvedora e cliente). O quadro
seguinte caracteriza a seo dos requisitos do sistema.
A seguir, apresenta-se uma viso geral do projeto trazendo objetivos,

participantes e mecanismos de evoluo do plano de projeto e aceitao. Isto
exemplificado no quadro abaixo.
3. Requisitos do Sistema
Esta seo apresenta os requisitos do sistema que serviro de base ao seu
planejamento, bem como do escopo no contemplado (ou escopo negativo).
Mudanas nestes requisitos devem ser submetidas ao controle de mudanas
estabelecido para o projeto, descrito no plano de gerencia de configurao.
3.1 Requisitos Tcnicos

Os requisitos a seguir representam uma viso dos produtos a serem
desenvolvidos nesse projeto. Estes requisitos sero descritos em detalhes no
Documento de Requisitos do Projeto, que ser complementado e refinado no
decorrer do ciclo de vida do projeto.

3.1.1 Requisitos Funcionais
Os requisitos funcionais considerados compreendem:
A infra-estrutura de desenvolvimento de componentes e aplicativos
ser baseada na plataforma orientada a servios (web services) e
compreender:
o Servios de controle de acesso;
o Servios para rea de Turismo;
Desenvolvimento de servios para uma subrea de aplicao de
Turismo. A definio da subrea de Turismo ser realizada na etapa
inicial deste projeto.
3.1.2 Requisitos No Funcionais

Os requisitos no funcionais considerados neste projeto compreendem:
O modelo de desenvolvimento de servios dever considerar uma
infra-estrutura que permita o desenvolvimento rpido de componentes
e aplicativos baseado na plataforma orientada a servios. O conjunto
de componentes orientados a servios resultantes deste projeto
servir de base a construo de vrias aplicaes para o setor de
turismo.
O processo de validao se encerrar com a verso final dos
servios.
3.4 Mecanismos de Evoluo do Plano de Projeto
O plano do projeto deve ser mantido atualizado para refletir a situao
corrente do projeto. Abaixo, o conjunto de situaes caracteriza os gatilhos

para atualizao deste documento apresentado:
Alteraes de rubricas junto ao cliente;
Mudanas nos critrios de aceitao do projeto;
Alteraes dos objetivos previstos no Plano de Trabalho aprovado
pelo cliente;
Mudanas na gerncia do projeto da empresa ou do cliente.
3.2 Requisitos No Tcnicos

Os requisitos no tcnicos compreendem:
Todo e qualquer material de divulgao resultante da execuo deste
projeto dever conter informao do suporte financeiro do cliente e,
especialmente, no caso de:
o Seminrios e eventos cientficos e tecnolgicos;
o Publicaes tcnicas e cientficas em revistas especializadas;
o Relatrios tcnicos publicados ou divulgados em qualquer
mdia.
3.3 Escopo No Contemplado

O escopo do projeto no contempla a realizao das seguintes atividades:
Elaborar e/ou realizar treinamento no uso dos servios desenvolvidos
no projeto;
Correo de bugs, identificados em qualquer um dos produtos, aps
a durao prevista do projeto perante o cliente.
Quaisquer outros artefatos no previstos na seo de produtos deste plano.

A motivao da seo acima caracterizar as principais
funcionalidades a serem implementadas (as quais so detalhadas no
documento de requisitos), alm de informar o que no faz parte do escopo do
projeto. A seo seguinte apresenta uma viso organizacional do projeto e os
principais atores dessa estrutura.
4. Organizao do Projeto
Esta seo apresenta o organograma utilizado no projeto juntamente
com seus papis e responsabilidades.
4.1 Organograma
Esta seo visa apresentar um organograma do projeto, incluindo os
papis exigidos para realizao do projeto e a relao entre os
mesmos.
4.2 Papis e Responsabilidades

A Tabela 3 descreve um conjunto de papis e respectivas
responsabilidades.
Papel Responsabilidades

Diretor Divulgar as diretrizes estratgicas;
Tomar decises estratgicas;
Garantir o cumprimento de
responsabilidades estabelecidas entre as
partes, possibilitando o sucesso do projeto.
Gerente de Prover todos os recursos necessrios para a
Operaes execuo do projeto (capital humano,
hardware, software, treinamento, etc.);
Realizar acompanhamento tcnico,
financeiro, de escopo, riscos e cronograma
do projeto, conjuntamente com o gerente de
projeto;
Posicionar o cliente sobre o andamento dos
servios junto ao gerente do projeto.

Gerente de Projeto Realizar planejamento do projeto;
Gerenciar a equipe do projeto;
Gerenciar o oramento do projeto;
Garantir o andamento adequado do projeto
com relao ao planejado, gerenciando
riscos e tomando aes preventivas e
corretivas;
Posicionar o cliente sobre o andamento dos
servios;
Elaborar relatrio de acompanhamento e
concluso do projeto;
Coordenar a interao da equipe com o
cliente.
Analista de Negcios Realizar modelagem do negcio, quando
apropriado;
Elicitar requisitos e realizar anlise e projeto
do sistema, elaborando modelos associados;
Elaborar projeto de testes e conduzir testes
de sistema;
Elaborar documentao tcnica necessria,
por exemplo, ajuda (help), guia de usurio,
material de treinamento;
Acompanhar atividades dos engenheiros de
software, assegurando integridade com
requisitos e casos de uso especificados.

Engenheiro de Implementar componentes do sistema;
Software Realizar testes unitrios dos componentes
de software, de acordo com os padres
adotados pelo projeto;
Participar da fase de projeto, quando
apropriado;
Participar dos testes integrados do sistema.
Engenheiro de Auditar o uso do processo;
Qualidade Participar de revises quando adequado.
Tabela 3 - Papis e Responsabilidades do Projeto.
A seo seguinte destaca o quantitativo da equipe e sua respectiva

alocao. Tambm, informaes especficas de cada um dos membros da
equipe e possveis ferramentas utilizadas no projeto so apresentadas.
5. Equipe e Infra-Estrutura do Projeto

Esta seo define a composio da equipe e lista a relao de
ferramentas necessrias ao ambiente de desenvolvimento do projeto,
com o objetivo de garantir uma estrutura adequada para a execuo
das atividades previstas neste plano.
5.1 Planejamento da Alocao de Pessoal

A Tabela 4 apresenta o planejamento de alocao de pessoal do
projeto.
Funo Quantidade % Alocao

Gerente de projeto 1 100
Analista de negcios 3 100
Arquiteto de software 1 50
Engenheiro de software 5 100
Web designer 1 50
Engenheiro de Qualidade 1 20
Engenheiro de Configurao 1 20
Administrador de Banco de 1 10
Dados
Administrador de Sistemas 1 10
Tabela 4 Planejamento de Alocao de Pessoal.
5.2 Equipe de Projeto

A Tabela 5 lista a relao de participantes do projeto e informaes de
perodo de participao e formas de contato.
Nome Papel Perodo E-mail
Nome do Gerente de 03/2011 a (

nome@empresa.com.br
gerente Projetos 12/2011 9

Nome do Analista de 03/2011 a (
nome@empresa.com.br
analista Negcio 12/2011 9
Nome do Engenheiro de 03/2007 a nome@empresa.com.br (
engenheiro Software 12/2007 9
A definir Engenheiro de 03/2007 a nome@empresa.com.br (
qualidade 12/2007 9
Engenheiro Web designer 03/2007 a nome@empresa.com.br (
12/2007 9
Tabela 5 - Equipe da empresa.
5.3 Ferramentas do Projeto
Funcionalidade Ferramenta N Licenas

Necessrias
Gerncia de projetos MSProject 1
Gerncia de CVS 0
configurao
Anlise e projeto Rational Rose 6
Implementao JBuilder 6
Testes A ser definido -

SGBD A ser definido -
Tabela 6 - Ferramentas do projeto.
6. Treinamentos do Projeto
O treinamento da equipe tcnica envolvida no desenvolvimento do projeto j

faz parte do planejamento corporativo de capacitao de pessoal, de acordo
com o plano de cargos em vigor na empresa, o qual descreve os perfis
necessrios para a execuo de diferentes papis. Desta forma, os
profissionais selecionados j possuem perfil necessrio para o cumprimento
dos compromissos firmados. Uma vez que o projeto no incorpora nenhuma
tecnologia desconhecida pela equipe tcnica, no sero necessrios
treinamentos adicionais. Entretanto, qualquer treinamento necessrio
equipe ser relatado no primeiro relatrio de acompanhamento de projeto.
7. Acompanhamento do Projeto
Esta seo apresenta as atividades de acompanhamento e verificao do
projeto, envolvendo a equipe do projeto, gerente de projeto da empresa,
gerente de operaes e representante do cliente. Estas atividades incluem a
realizao de reunies e gerao de relatrios descrevendo informaes
sobre o progresso do projeto, questes no resolvidas, dentre outras. A
Tabela 7 contempla as atividades de acompanhamento planejadas para o
projeto.

Reunio / Relatrio Realizao Participantes / Interessados
Reunio de Semanal Gerente de projeto da
acompanhamento de empresa;
atividades Equipe de desenvolvimento
da empresa.
Relatrio de progresso do Mensal Gerente de Operaes;
projeto Gerente de projeto da
empresa;
Representante do cliente,
se apropriado.
Reviso formal do projeto Semestral Gerente de projeto da
empresa;
Representante do cliente,
se apropriado.
Reunio de fechamento Ao final do Gerente de projeto da
do projeto com a equipe projeto empresa;
Equipe do projeto da
empresa;
Engenheiro de qualidade da
empresa.
Reunio de fechamento Ao final do Gerente de projeto da
do projeto com o cliente projeto empresa;
Representante(s) do cliente.
Tabela 7 Reunies e Relatrios de Acompanhamento do Projeto

As reunies e relatrios apresentados possuem o seguinte objetivo:
Reunio de acompanhamento de atividades: tem por objetivo coletar
periodicamente informaes junto equipe, cliente e demais reas
envolvidas, alm de tomar aes corretivas quando forem identificados
desvios do planejado.
Relatrio de progresso do projeto: tem por objetivo comunicar
mensalmente os principais interessados sobre o andamento do projeto.
Reviso formal do projeto: visa principalmente comunicar a gerncia da
empresa e representantes do cliente sobre status das atividades do
projeto. Adicionalmente, deve-se verificar se o trabalho essencial da etapa
anterior foi completado com sucesso (planejado vs. realizado),
determinando pr-condies para o sucesso da prxima etapa, resolver
questes do projeto, reafirmar compromissos e reavaliar riscos. Estas
reunies devero ser realizadas a cada semestre e servem como
prestao de contas para o cliente.
Reunio de fechamento do projeto com a equipe: visa comunicar o
feedback do cliente equipe, alm de discutir as lies aprendidas com o
projeto e avaliar o feedback da equipe.
Reunio de fechamento do projeto com o cliente: tem por objetivo avaliar
a realizao dos compromissos firmados entre as partes e obter o aceite
formal do projeto pelo cliente. Esta formalizao deve ser realizada
atravs do formulrio de aceitao do produto/servio.
8. Controle de Mudanas do Escopo de Projeto

O controle de mudanas de escopo do projeto considera solicitaes
referentes a alteraes nas especificaes funcionais ou tcnicas, adio de
novos requisitos, servios adicionais de consultoria ou apoio tcnico,
alteraes de cronograma e/ou na administrao do projeto como um todo.
Tais solicitaes podem ser propostas pelo cliente ou pela equipe de projeto
da empresa, sendo passveis de um novo dimensionamento do esforo e
custo necessrios a sua implementao. As solicitaes de mudana devem
ser registradas na ferramenta de controle de mudanas.
O controle de mudanas permite ainda a realizao de acordo entre as

partes, considerando o impacto sobre o projeto, sobre os acordos e
compromissos previamente estabelecidos, e sobre os cronogramas fsico e
financeiro do projeto. Os custos associados mudana devero ser apoiados
pelo cliente.
9. Cronograma
O cronograma do projeto contempla as atividades, milestones, dependncias
e recursos humanos alocados. Para obter detalhes sobre o mesmo, o
documento do Cronograma do Projeto deve ser consultado.
9.1 Marcos Significativos do Projeto

A Tabela 8 apresenta os marcos significativos do projeto, bem como os
artefatos importantes que sero entregues ao cliente nestes marcos, quando
aplicvel. Mudanas acordadas nas datas alvo sero acompanhadas e
registradas, atravs das reunies de acompanhamento do projeto.
Marco / Artefatos/ Responsvel Data Alvo

Meta Fsica Indicadores
Fsicos de
Execuo
Estudo e anlise de Relatrio tcnico de Empresa 02/10/2011
solues tecnolgicas estudo e anlise
para infra-estrutura
orientada a servios
Definio de um Relatrio tcnico de Empresa 27/10/2011
modelo de modelo
desenvolvimento de
servios web.
Desenvolvimento de Documento de Empresa 25/01/2011
servios para controle requisitos de
de acesso servios de controle
de acesso;
Documento de
anlise e projeto;
Cdigo fonte
implementado;
Documento do
plano de testes e
dos resultados de

testes.
Desenvolvimento de Documento de Empresa 25/03/2011
servios para rea de requisitos de
Turismo servios para rea
de Turismo;
Documento de
anlise e projeto;
Cdigo fonte
implementado;
Documento do
plano de testes e
dos resultados de
testes.
Tabela 8 - Marcos Significativos do Projeto
Perceba que o cronograma apresentado na seo 9 destaca apenas as

principais atividades e elas se encontram agrupadas, caracterizando os
principais marcos do projeto. No h, contudo, a inteno aqui em ser
completo, mas a de ressaltar como as informaes podem ser apresentadas
no plano de projeto. As sees seguintes tratam de informaes que so
detalhadas em outros documentos como indicado.
10. Gerncia de Riscos

Os riscos identificados para o projeto sero detalhados nos relatrios de
acompanhamento, bem como na planilha de acompanhamento do projeto.

Estes documentos contm a lista de riscos identificados, seus impactos e
informaes relevantes para definir estratgia de controle e atenuao (ou
mitigao) do risco. Todo o acompanhamento dos riscos do projeto (riscos
previamente identificados e riscos surgidos no decorrer do andamento do
projeto) ser registrado nos documentos supracitados.
11. Gerncia de Configurao

A gerncia de configurao do projeto ser detalhada no Plano de Gerncia
de Configurao do Projeto. A gerncia de configurao visa estabelecer e
manter a integridade dos produtos de um projeto de software durante o seu
ciclo de vida. Suas atividades envolvem identificar a configurao do
software, manter sua integridade durante o projeto e controlar
sistematicamente as mudanas.
Os artefatos do projeto devero ser disponibilizados no repositrio do projeto.
Alm disso, os documentos de interesse do cliente e dos nossos gestores
snior da empresa sero disponibilizados no site do projeto, cujo acesso ser
restrito aos principais envolvidos.
12. Testes do Projeto

Os testes so aplicveis apenas para a implementao de servios. Os testes
de performance, carga, estresse e segurana e controle de acesso s se
aplicam, quando pertinente, aos servios web.

12.1 Estgios de Testes
A Tabela 9 apresenta os estgios de testes do projeto e seus objetivos.
Estgio de Objetivo
Testes
Teste Unitrio Visa validar individualmente os menores componentes
(classes bsicas e componentes) que sero utilizados
na implementao das funcionalidades do sistema.
Teste de Objetiva validar a integrao entre componentes e dos
Integrao diversos pacotes na implementao das
funcionalidades.
Teste de Sistema Objetiva validar se todos os elementos do sistema
foram adequadamente integrados e se realizam
corretamente as funes especificadas.
Teste no Visa assegurar que tudo est realmente pronto para ser
Ambiente de utilizado pelo usurio. Estes testes so realizados pela
Aceitao equipe de projeto da empresa antes da entrega do
sistema ao cliente. Deve ser realizado em uma
ambiente o mais prximo possvel do ambiente de
produo.
Teste de Teste realizado pelo cliente objetivando aceitar ou
Aceitao homologar o sistema. Depois de realizado este teste
com sucesso, o sistema estar pronto para ser
implantado no ambiente de produo.
Tabela 9 - Estgios de Testes do Projeto

O conjunto de sees apresentados acima servem para ilustrar pontos
que importantes num plano de projeto. No houve aqui a inteno de ser
completo, mas de informar quais itens deveriam compor o plano de projeto,
bem como a de ilustrar o contedo que pode ser encontrado nesse
documento.
6.4 Realizao de testes de software
Teste de software uma das atividades do processo de

desenvolvimento de sistema de software que visa executar programa de
modo sistemtico com o objetivo de encontrar falhas. Perceba que isto requer
verificao e validao de software. Nesse sentido, definir quando as
atividades de verificao e validao iniciam e terminam, como os atributos
de qualidade sero avaliados e como os releases do software sero
controlados so questes que devem ser acompanhadas ao longo do
processo de software.
Os testes de software e, mais especificamente, teste de unidade, visam

investigar a qualidade de componentes individuais (ex: mtodos, classes).
Nesse sentido, o objetivo testar comportamento (especificao) e estrutura
interna (lgica e fluxo de dados).
Observe que casos de teste podem ser gerados usando apenas a

especificao. Neste caso, tal procedimento de teste no influenciado pela
implementao e os resultados dos testes podem ser avaliados por pessoas
sem conhecimento da linguagem de programao. Um exemplo de caso de
teste mostrado a seguir.
[CT01] EfetuarLogin - Usurio
Identificador do requisito RF-01 (EfetuarLogin Usurio)

Requisitos associados RF-08 (Cadastro de usurio)
Procedimento associado PT25
Entradas Resultados esperados

Entrada Pr- Descrio da Ps-condies Sadas
condies entrada
Dados de Usurio Informar matrcula Usurio vlido Menu de
login para cadastrado na e senha de um servios exibido
logado e sesso
o usurio. base de usurio do sistema. na tela.
dados do registrada no
sistema. sistema
Uma maneira de criar testes de unidade utilizar o framework JUnit

(http://www.junit.org/) para desenvolvimento e execuo de testes de unidade
em programas Java. JUnit define um modelo de programao para a criao
de testes de unidade com classes Java. JUnit permite a criao de testes
unitrios para mtodos pertencentes a uma determinada classe, alm de
possibilitar a execuo de um conjunto de testes unitrios, bem como o
xrelato de problemas ocorridos e onde especificamente ocorreram os erros.
Para utilizar o JUnit, voc deve fazer o download no Web site , o qual atua
com um plugin para o ambiente Eclipse. Uma vez voc tenha ele instalado,
voc deve:
1. Para cada classe a ser testada criar uma classe de teste. Por exemplo, a
classe Calculo ter como classe de teste CalculoTest, apresentadas abaixo.
1
public class Calculo {
public static float ExecutaCalculo1(float Valor1, float Valor2)
{
float Soma = Valor1 + Valor2;
return Soma;
}
public static float ExecutaCalculo2(float Valor1, float Valor2)

{
float Subtracao = Valor1 - Valor2;
return Subtracao;
}
}
import junit.framework.TestCase;
public class CalculoTest extends TestCase {

public void testExecutaCalculo() {
// define os valores a serem calculados e testados
float PassaValor1 = 10;
float PassaValor2 = 5;
float RetornoEsperado = 15;
// Dispara o metodo "ExecutaCalculo" da classe "Calculo"
// resultado em uma variavel
boolean condicao = false;

float RetornoFeito = (condicao) ?
Calculo.ExecutaCalculo1(PassaValor1, PassaValor2) :
Calculo.ExecutaCalculo2(PassaValor1, PassaValor2) ;
//Compara o valor retornado com o que era esperado

assertEquals(RetornoEsperado, RetornoFeito, 0);
}
Observe que a classe de Teste deve herdar da classe TestCase do

framework JUnit.
2. Voc pode criar mtodos de teste cujos nomes iniciam com a palavra test
e possuem tipo de retorno void. Exemplo para a classe ContaTest:
3. E, para cada mtodo de teste, voc pode definir seu comportamento com a
invocao de mtodos da classe do sistema a ser testada ou com a avaliao
do resultado dos mtodos sendo testados usando os mtodos assertEquals(),
fail(), assertNull(), assertNotNull() do framework JUnit, como ilustrado no
exemplo acima da classe CalculoTest.
Vale ressaltar que um projeto compreende um conjunto de atividades

inter-relacionadas com datas de incio e fim alm de metas especficas.
Tambm, define-se o que ser entrada e sada para cada atividade. Tudo isso
precisa estar muito bem orquestrado num documento (que o plano de

3
projeto) para que o projeto possa ser conduzido de maneira adequada,
alcanar seus objetivos e atender a metas de qualidade e cronograma.
Agora, muito importante que voc faa os exerccios e participe das

atividades de frum. Essas atividades so complementares e tm o objetivo
de solidificar o seu conhecimento. Para finalizar, recomendo a voc visitar os
sites do quadro de Para Saber Mais, que contm informaes
complementares e interessantes dos assuntos apresentados nesta unidade.
Estas referncias servem de apoio a voc para realizar suas atividades, bem
como ampliar conhecimento deste contedo.

unidade.
RESUMO
Este texto detalha a importncia de priorizar as atividades iniciais do
desenvolvimento de software com o objetivo de fazer anlise bem feita para
obter um modelo de projeto que retrate corretamente os requisitos de
software. Isto possibilita menor chance de re-trabalho, o que pode resultar
num projeto com melhor qualidade e passvel de menor custo. Nesta unidade,
voc tambm teve a oportunidade de aprender como elaborar um plano de
teste e conhecer ferramentas de apoio ao desenvolvimento de software.

Para saber mais
Histria da Indstria de Software

www.softwarehistory.org
Engenharia de software na Wikipedia

http://pt.wikipedia.org/wiki/Engenharia_de_software
Driving Development with Use Cases

http://www.parlezuml.com/tutorials/usecases/usecases.pdf
Requirements Engineering A Roadmap

http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf
Understanding Use Case Modeling

http://www.methodsandtools.com/archive/archive.php?id=24
5
Use Case An Introduction
http://www.parlezuml.com/tutorials/usecases/usecases_intro.pdf
A Guide to the Software Engineering Body of Knowledge

http://www.swebok.org/
Lista de ferramentas UML

http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
JUDE Ferramenta de modelagem UML

http://jude.change-vision.com/jude-web/index.html
astah* community - FREE UML Modeling Tool

http://astah.change-vision.com/en/product/astah-community.html
Lista de ferramentas de testes

http://www.opensourcetesting.org
REFERNCIA
R. Pressman, Engenharia de Software, Ed. McGraw-Hill, 2006.

Sommerville, Engenharia de Software, Ed. Pearson, 2007.

Projeto. de Des. de Soft. - Vol. 2 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Projeto. de Des. de Soft. - Vol. 2 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

INFORMTICA

PROJETO DE DESENVOLVIMENTO DE SOFTWARE

Vice-Governador | Joo Soares Lyra Neto

Secretrio de Educao | Anderson Stevens Lenidas Gomes

Secretrio Executivo de Educao Profissional | Paulo Dutra

Gerente Geral da Educao Profissional | Luciane Pula

Gestor de Educao a Distncia | Marcos Paulo de Assis Castro

Coordenador do Curso | Almir Pires

Professor Conteudista | Antnio Mendes

Equipe Central de Educao a Distncia

Imagem da capa: http://www.imagemativa.com.br/

4.2 Documento de requisitos ...................................................................... 13

4.3 Elaborao de documento de requisitos ............................................... 14

Termos e convenes ................................................................................. 19

Prioridades dos requisitos ........................................................................... 20

4.4 Especificao de Requisitos de Sofware .............................................. 28

5.2 Anlise e projeto parte 2 .................................................................... 35

5.3 Anlise e projeto parte 3 .................................................................... 40

6.2 Desenvolvimento de software ............................................................... 67

4 Informtica | Projeto de Desenvolvimento de Software | Volume 2

6.4 Realizao de testes de software ....................................................... 100

REFERNCIA .......................................................................................... 106

Informtica | Projeto de Desenvolvimento de Software | Volume 2 5

Desenvolvimento de um estudo de caso para fixao dos conceitos

Capacitar o futuro profissional para compreender e unir os conceitos

6 Informtica | Projeto de Desenvolvimento de Software | Volume 2

Entender os conceitos de ciclos de vida e processos de

Informtica | Projeto de Desenvolvimento de Software | Volume 2 7

8 Informtica | Projeto de Desenvolvimento de Software | Volume 2

4 Especificao de Requisitos de Software Estudo de Caso

5 Desenvolvimento de Projeto de Software Estudo de Caso

6 Uso de Ferramentas de Desenvolvimento Estudo de Caso

Informtica | Projeto de Desenvolvimento de Software | Volume 2 9

4. ESPECIFICAO DE REQUISITOS DE SOFTWARE

Na unidade anterior, voc teve a oportunidade de estudar os

Um engenheiro de software um profissional que deve ter a habilidade

10 Informtica | Projeto de Desenvolvimento de Software | Volume 2

4.1 Requisitos de software

Desenvolver um sistema de software requer um processo, o qual

Adicionalmente, envolver o usurio no processo determinante para o

Elicitao de requisitos atividade na qual os requisitos do sistema a

Informtica | Projeto de Desenvolvimento de Software | Volume 2 11

Considera-se ainda que a elicitao de requisitos objetiva definir

Durante a realizao destas atividades, o engenheiro de software est

12 Informtica | Projeto de Desenvolvimento de Software | Volume 2

O documento de requisitos delimita o escopo do conjunto de

Informtica | Projeto de Desenvolvimento de Software | Volume 2 13

importante perceber a importncia do documento de requisitos como

4.3 Elaborao de documento de requisitos

O documento de requisitos contm um conjunto de informaes que

14 Informtica | Projeto de Desenvolvimento de Software | Volume 2

Informtica | Projeto de Desenvolvimento de Software | Volume 2 15

3. Requisitos No-Funcionais Apresenta-se uma descrio geral de

16 Informtica | Projeto de Desenvolvimento de Software | Volume 2

5. Documentao Complementar Exemplos desses documentos

6. Apndice Trata-se de uma seo que pode conter,

Tabela 1 Relao de itens de um documento de requisitos.

Informtica | Projeto de Desenvolvimento de Software | Volume 2 17

Este documento descreve um sistema que prover notcias e contedo online,

Viso geral do documento

18 Informtica | Projeto de Desenvolvimento de Software | Volume 2

Informtica | Projeto de Desenvolvimento de Software | Volume 2 19

Prioridades dos requisitos