Processos de Desenvolvimento do Projeto

Prévia do material em texto

Brasília-DF. 
Processos de desenvolvimento 
do Projeto
Elaboração
Márcio de Oliveira Miranda Lopes
Max Bianchi Godoy
Produção
Equipe Técnica de Avaliação, Revisão Linguística e Editoração
Sumário
APRESENTAÇÃO ................................................................................................................................. 4
ORGANIZAÇÃO DO CADERNO DE ESTUDOS E PESQUISA .................................................................... 5
INTRODUÇÃO.................................................................................................................................... 7
UNIDADE I
PROJETANDO SISTEMA ........................................................................................................................... 9
CAPÍTULO 1
DESENVOLVIMENTO DO MODELO DE DADOS ........................................................................... 9
CAPÍTULO 2 
CODIFICAÇÃO DO SISTEMA ................................................................................................... 14
UNIDADE II
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO ...................................................................... 19
CAPÍTULO 1
REALIZAÇÃO TESTE EM EQUIPE TÉCNICA ................................................................................. 19
CAPÍTULO 2 
TIPOS DE TESTE ....................................................................................................................... 26
CAPÍTULO 3 
DESENVOLVIMENTO DE VERSÃO-PILOTO .................................................................................. 37
CAPÍTULO 4 
REALIZAÇÃO DE TESTE EM USUÁRIO FINAL ............................................................................... 38
CAPÍTULO 5 
ELABORAÇÃO DE SOLICITAÇÕES DE MUDANÇAS ................................................................... 40
CAPÍTULO 6 
ELABORAÇÃO DE MANUAL DO USUÁRIO ................................................................................ 42
PARA (NÃO) FINALIZAR ..................................................................................................................... 48
REFERÊNCIAS .................................................................................................................................. 49
4
Apresentação
Caro aluno
A proposta editorial deste Caderno de Estudos e Pesquisa reúne elementos que se 
entendem necessários para o desenvolvimento do estudo com segurança e qualidade. 
Caracteriza-se pela atualidade, dinâmica e pertinência de seu conteúdo, bem como pela 
interatividade e modernidade de sua estrutura formal, adequadas à metodologia da 
Educação a Distância – EaD.
Pretende-se, com este material, levá-lo à reflexão e à compreensão da pluralidade dos 
conhecimentos a serem oferecidos, possibilitando-lhe ampliar conceitos específicos 
da área e atuar de forma competente e conscienciosa, como convém ao profissional 
que busca a formação continuada para vencer os desafios que a evolução científico-
tecnológica impõe ao mundo contemporâneo.
Elaborou-se a presente publicação com a intenção de torná-la subsídio valioso, de modo 
a facilitar sua caminhada na trajetória a ser percorrida tanto na vida pessoal quanto na 
profissional. Utilize-a como instrumento para seu sucesso na carreira.
Conselho Editorial
5
Organização do Caderno 
de Estudos e Pesquisa
Para facilitar seu estudo, os conteúdos são organizados em unidades, subdivididas em 
capítulos, de forma didática, objetiva e coerente. Eles serão abordados por meio de textos 
básicos, com questões para reflexão, entre outros recursos editoriais que visam a tornar 
sua leitura mais agradável. Ao final, serão indicadas, também, fontes de consulta, para 
aprofundar os estudos com leituras e pesquisas complementares.
A seguir, uma breve descrição dos ícones utilizados na organização dos Cadernos de 
Estudos e Pesquisa.
Provocação
Textos que buscam instigar o aluno a refletir sobre determinado assunto antes 
mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor 
conteudista.
Para refletir
Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa e reflita 
sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio. É importante 
que ele verifique seus conhecimentos, suas experiências e seus sentimentos. As 
reflexões são o ponto de partida para a construção de suas conclusões.
Sugestão de estudo complementar
Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo, 
discussões em fóruns ou encontros presenciais quando for o caso.
Praticando
Sugestão de atividades, no decorrer das leituras, com o objetivo didático de fortalecer 
o processo de aprendizagem do aluno.
6
Atenção
Chamadas para alertar detalhes/tópicos importantes que contribuam para a 
síntese/conclusão do assunto abordado.
Saiba mais
Informações complementares para elucidar a construção das sínteses/conclusões 
sobre o assunto abordado.
Sintetizando
Trecho que busca resumir informações relevantes do conteúdo, facilitando o 
entendimento pelo aluno sobre trechos mais complexos.
Exercício de fixação
Atividades que buscam reforçar a assimilação e fixação dos períodos que o autor/
conteudista achar mais relevante em relação a aprendizagem de seu módulo (não 
há registro de menção).
Avaliação Final
Questionário com 10 questões objetivas, baseadas nos objetivos do curso, 
que visam verificar a aprendizagem do curso (há registro de menção). É a única 
atividade do curso que vale nota, ou seja, é a atividade que o aluno fará para saber 
se pode ou não receber a certificação.
Para (não) finalizar
Texto integrador, ao final do módulo, que motiva o aluno a continuar a aprendizagem 
ou estimula ponderações complementares sobre o módulo estudado.
7
Introdução
O planejamento corresponde a uma tarefa racional com o intuito de ordenar os 
meios para consecução de resultados. Assim, planejar é organizar. Nesse aspecto, 
o gerenciamento de projetos consiste em antever ações, a fim de alocar recursos e 
processá-los, de modo a se obter resultados anteriormente definidos. 
Apesar de todo o esforço despendido na busca e na organização de informações 
e no aperfeiçoamento dos artefatos conceituais do projeto, o planejamento ainda 
corresponde a uma aposta no futuro. Somente os processos do grupo de processos 
de execução, monitoramento e controle, com o peso dos fatos e da complexidade das 
situações apresentadas, é que conferem validade ao planejamento. 
Dessa forma, mesmo o projeto tendo surgido com o termo de abertura é a execução que 
lhe confere a vida; e o monitoramento e o controle lhe testam o desenvolvimento rumo 
aos resultados que são esperados. 
Assim, ao se debruçarem sobre esse conteúdo teórico, lembrem-se de que buscamos 
inserir no presente trabalho um pouco da experiência da equipe de professores, em sua 
maioria gerentes de projeto, por termos a convicção de que, mesmo com a teoria, é a 
prática que nos ensina como executar um projeto de qualidade.
Objetivos
 » Aprofundar conhecimentos sobre o desenvolvimento de Modelo de 
Dados.
 » Compreender os procedimentos para codificação de Sistema.
 » Conhecer testes em sistema e de desenvolvimento de versão piloto.
 » Conhecer especificações para elaboração de Manual do Usuário.
8
9
UNIDADE IPROJETANDO 
SISTEMA
CAPÍTULO 1
Desenvolvimento do modelo de Dados
O Modelo de Banco de Dados descreve todo o projeto de banco de dados do sistema e 
apresenta a descrição formal dos tipos de dados que estão armazenados em um banco 
de dados.
Antes de desenvolvermos um modelo de dados é necessário conhecer os seguintes 
conceitos:
 » Objeto representa tudo que a mente de um indivíduo pode separar, 
podendo ser ele concreto ou abstrato.
 » Os mecanismos de abstração servem para que os objetos sejam 
identificados, conforme os exemplos a seguir:
 › Classificação – agrupa objetos com o mesmo conjunto de propriedades 
– “ser membro de”.
 › Agregação – define uma nova classea partir de outras que a compõem 
– “ser parte de”.
 › Generalização – define uma classe como subconjunto de outra, mais 
genérica – “pertencer/ser um” – ter características: podem herdar 
propriedades de outros objetos.
Um possível artefato referente ao modelo de dados pode incluir diagramas entidade-
relacionamento, dicionário de dados, relação de usuários, papéis e permissões no banco 
de dados, especificações de índices, triggers, Stored procedures e outros elementos 
específicos ao projeto de banco de dados. Devido à diversidade de projetos, não é viável 
termos um modelo (template) definido para esse artefato, podendo ser utilizada uma 
10
UNIDADE I │PROJETANDO SISTEMA
ferramenta de modelagem de banco de dados para sua geração. Tal ferramenta precisa 
ser selecionada/acordada previamente pela equipe de desenvolvimento.
Os Triggers (ou gatilhos) correspondem a pequenos códigos de que são armazenados 
dentro de um banco de dados, em que podem ser definidos blocos de tarefas que podem 
ser executados automaticamente. 
Dessa forma, toda vez que uma instrução for aplicada a uma tabela específica, o trigger 
pode ser acionado e, a partir daí, executar automaticamente determinado evento. Esses 
triggers podem ser usados para garantir a execução de comandos para uma tabela 
específico; contudo, alguns cuidados devem ser tomados ao serem criados, tais como 
evitar criar triggers que dupliquem regras já definidas nas “CONSTRAINTS” do banco 
de dados; algumas linguagens de banco de dados (tais como o Oracle) recomendam que 
os códigos no trigger sejam limitados em até 60 linhas (utilizando as Stored Procedures 
para algo mais complexo); ter muito cuidado ao criar triggers que disparem sob uma 
instrução UPDATE em uma Tabela – não pode alterá-la porque isso iria disparar 
triggers mais de N vezes no sistema, e, nesses casos, poderiam ocorrer problemas de 
memória e/ou resultados errôneos serem gerados.
Os Stored procedures são pequenos trechos de programa de computador, mais 
complexos que os triggers, armazenados diretamente em um SGBD e que podem 
ser chamados frequentemente por um programa principal, tornando mais ágeis os 
procedimentos.
Normalmente, o responsável por modelar o banco de dados é conhecido como projetista 
de Banco de Dados. A atividade realizada por esse profissional, ou por quem estiver 
com essa função, tem por objetivo a elaboração do projeto de banco de dados e, para 
tanto, deverão ser especificados os elementos necessários a fim de suportar os possíveis 
cenários de casos de uso previamente selecionados.
O modelo de Banco de Dados deverá ser desenvolvido com base no Diagrama de Classes, 
que foi elaborado pela equipe de analistas de sistemas, fundamentalmente descritos 
por meio do documento de arquitetura.
Assim, o projeto do banco de dados precisa levar em consideração os requisitos não 
funcionais, sobretudo os referentes ao desempenho necessário e à segurança requerida, 
os quais devem estar estabelecidos na matriz de requisitos do projeto.
Como já citamos, o modelo de banco de dados precisa definir claramente quais serão as 
tabelas do sistema e seus campos, os relacionamentos e seus tipos, as chaves primárias e 
estrangeiras, os possíveis índices, os papéis e tipos de usuários (adicionando informações 
11
PROJETANDO SISTEMA│ UNIDADE I
sobre suas permissões), a especificação de Stored Procedures, de triggers e o Dicionário 
de Dados. Este último apresenta uma descrição textual dos valores armazenados e das 
convenções utilizadas em cada um dos elementos, conforme veremos adiante.
O projeto do banco de dados precisa realizar uma estimativa quanto ao tamanho 
da base de dados no momento da implantação do sistema e elaborar uma 
previsão de crescimento ao longo do tempo, em termos relativos ou absolutos.
Dessa forma, o projeto do banco de dados precisa realizar uma estimativa quanto ao 
tamanho da base de dados no momento da implantação do sistema e elaborar uma 
previsão de crescimento ao longo do tempo, em termos relativos ou absolutos.
Para desenvolvimento do modelo de banco de dados podemos descrever as seguintes 
etapas, que podem ser alteradas de acordo com as especificidades do projeto ou a 
ferramenta escolhida para realização desse artefato:
 » Analisar, mecanismos de projeto definidos no “documento de 
arquitetura”, “diagrama de classes”. Outros elementos importantes a 
serem considerados são os requisitos não funcionais do sistema, presentes 
na “matriz de requisitos” e as especificações dos casos de uso, que estão 
no “modelo de casos de uso”.
 » Identificar, a partir do Diagrama de Classes que foi elaborado, as tabelas 
necessárias para armazenamento dos dados persistentes do sistema.
 » Identificar os relacionamentos e as chaves primárias e estrangeiras das 
tabelas.
 » Com base nos cenários de casos de uso e nos métodos definidos para as 
classes do sistema, identificar as Stored Procedures e triggers necessárias.
 » Com base nos requisitos não funcionais de desempenho e nos acessos 
previstos às tabelas dos sistemas, identificar os índices necessários para 
cada tabela.
 » Com base nos requisitos de segurança e perfis de acesso do sistema, 
identificar os papéis e usuários do banco de dados, com a definição de 
suas permissões.
 » Elaborar o dicionário de dados do sistema.
12
UNIDADE I │PROJETANDO SISTEMA
 » Elaborar o Modelo de Banco de Dados contendo os elementos 
identificados.
 » Revisar o Dicionário de Dados e o Modelo de Banco de Dados junto às 
áreas de homologação. 
 » Analisar a conformidade entre o Modelo de Banco de Dados, o diagrama 
de classes, os requisitos do sistema e os mecanismos de projeto definidos 
no Documento de Arquitetura.
São, portanto, artefatos importantes necessários como input (entradas) desse processo 
de confecção do Modelo de Banco de Dados: o Diagrama de classes, o Documento de 
arquitetura e o Glossário.
Dicionário de dados
O Dicionário de Dados é o elemento que apresenta uma descrição textual dos valores 
armazenados e de todas as convenções que foram utilizadas em cada um dos elementos. 
Dessa forma, um dicionário de dados (data dictionary) corresponde a uma coleção de 
metadados, que apresenta definições e representações de todos os elementos de dados.
Segundo Almeida (1998), são informações que descrevem completamente os dados 
que representam e, dessa forma, permitem que o usuário decida sobre a utilização 
desses dados da melhor forma possível. Assim, os metadados permitem informar as 
pessoas a respeito da existência de um conjunto de dados ligados às suas específicas 
necessidades. Conforme Howe (1996), a palavra metadados foi criada por Jack Myres a 
fim de denominar os dados que descrevem registros em arquivos convencionais.
O Dicionário de Dados corresponde a um documento que apresenta a explicação 
a respeito de todos os objetos nele criados e permite que os analistas obtenham 
informações sobre os objetos do modelo de uma forma textual. Esse documento contém 
explicações que seriam difíceis de serem incluídas em diagramas. Portanto, ele precisa 
ser bastante claro e consistente.
Dentro de um contexto de Sistema Gerenciador de Banco de Dados (SGBD), um 
dicionário de dados corresponde a um grupo de tabelas que foram habilitadas para 
leitura ou consulta, sendo uma base de dados que apresenta as informações sobre: a 
definição dos elementos de dados, os perfis de usuários, papéis e privilégios, a descrição 
de objetos, relações de integridade de restrições, Stored Procedures, informações de 
verificação, estruturas gerais da base de dados, alocações de espaço etc. 
13
PROJETANDO SISTEMA│ UNIDADE I
São benefícios de um dicionário de dados dar consistência entre os itens de dados, 
por meio de diferentes tabelas como, por exemplo, a formatação de campos, a ser 
obedecida em todas as tabelas do banco de dados, e também conferir padronização, 
como definições semânticas a serem adotadas, incluindo formas de representação para 
os elementos de dados. Nesse caso, os componentessemânticos estarão focados na 
criação do significado dos elementos de dados. 
As definições e as representações indicam como os elementos de dados serão 
armazenados na estrutura computacional, de acordo com seu tipo. Esses tipos de dados 
podem ser números inteiros, caracteres textuais ou datas.
Podemos dizer que os dicionários de dados são mais precisos que glossários, pois 
estes apresentam apenas termos e definições e aqueles costumam apresentar várias 
representações de como o dado pode ser estruturado e, por isso, podem envolver 
ontologias completas e lógicas distintas, que podem ser aplicadas a definições de cada 
um desses elementos de dados.
Os Dicionários de Dados são construídos de forma separada do Modelo de Dados, uma 
vez que esse modelo inclui as complexas formas de relacionamentos entre os diferentes 
elementos de dados.
A seguir observaremos um possível modelo para a construção do Dicionário de Dados:
Dicionário de Dados
Definições
[Esta seção define os dados que formam o conteúdo essencial do documento. Eles devem estar relacionados em ordem alfabética para maior 
acessibilidade, podendo ser agrupados por contexto, conforme o caso.].
Termo Definição
[Dado 1] [Definição do Dado 1]
[Dado 2] [Definição do Dado 2]
[Dado 3] [Definição do Dado 3]
[ATENÇÂO: Os textos em azul são para auxiliar o preenchimento do formulário, devendo ser excluídos ao final da elaboração do registro.]
14
CAPÍTULO 2 
Codificação do sistema
Esta fase consiste na criação do código-fonte, que tem por objetivo implementar as 
funcionalidades especificadas nos requisitos, de acordo com os modelos definidos nos 
artefatos do projeto. Assim, essa atividade envolve escrever código, depurá-lo e integrá-lo 
progressivamente. 
Para a realização dessa atividade, os desenvolvedores utilizam artefatos de requisitos e 
de projetos produzidos e interagem com as equipes responsáveis por eles.
A atividade de codificar programas, ou seja, de escrever o código propriamente dito do 
sistema é de importância fundamental. É de responsabilidade dos programadores e tem 
como objetivo a geração de códigos-fontes para os diversos elementos e componentes 
do sistema, visando uma versão operacional do sistema.
Podemos considerar também inclusa nas, atividades de codificação, a programação de 
scripts, Stored Procedures e triggers de banco de dados, sendo que elas, nesta fase 
do projeto, estariam ligadas ao esforço de codificação, que deve estar bastante focado 
na produtividade dos programadores, uma vez que os riscos inerentes ao escopo e a 
arquitetura do sistema já foram mitigados ao longo de todas as fases do projeto.
Podemos caracterizar o código-fonte como sendo qualquer trecho de código 
implementado ao longo do desenvolvimento do sistema. Apesar de representar um 
artefato concreto (código e arquivo-fonte existem), sua representação tem a finalidade 
conceitual de representar a unidade fundamental de um sistema, a qual é desenvolvida 
pela equipe de programadores do projeto.
Assim, o trabalho de codificação é realizado com base nas versões intermediárias do 
sistema, que são estabelecidas ao final da fase de elaboração, e contempla os possíveis 
cenários de casos de uso especificados e projetados. Dessa forma, a codificação deve 
estar calcada nas Especificações de Casos de Uso, no Diagrama de Classes, no Modelo 
de Banco de Dados e no Documento de Arquitetura.
As versões do Sistema, também chamadas de release, representam a criação do sistema 
executável ao final da fase do projeto e, dessa forma, um dos marcos do ciclo de vida do 
projeto. Essa compilação do sistema deve ser formalmente estabelecida pelo gerente de 
configuração. A partir daí, transforma numa versão. 
15
PROJETANDO SISTEMA│ UNIDADE I
Assim, podem ser geradas várias versões intermediárias antes da versão que ficará em 
produção durante todo o ciclo de vida do desenvolvimento do projeto.
Mesmo para a validação efetiva da arquitetura, pode ser gerada uma primeira versão do 
sistema. Ela é representada por um algoritmo executável e que possibilite a realização 
de testes. Essa validação da arquitetura de software definida pode ser citada na 
documentação como sendo a “versão para validação da arquitetura”. Por conseguinte, 
as versões posteriores podem conter expressões como: “versão xx - com arquitetura 
testada e validada”.
 Para fins didáticos, a primeira versão operacional do sistema aparece apenas na 
atividade denominada “estabelecer versão do sistema”, quando essa é testada 
e homologada e, após isso, colocada uma versão em produção, podendo 
ser utilizada pelos usuários finais. Às vezes, na prática, algumas versões são 
disponibilizadas com partes do sistema a fim de serem testadas previamente, 
porém isso depende do tipo de sistema desenvolvido e do que foi acordado pela 
equipe de desenvolvimento com os clientes.
As fases de realização desse processo, não necessariamente nesta ordem são: – análise 
das especificações de casos de uso (artefato contendo os Modelos de Casos de Uso), - 
verificação dos mecanismos de projeto previamente definidos nos artefatos “Documento 
de Arquitetura”, “Diagrama de Classes” e no Modelo de Banco de Dados. 
Após isso, devem ser codificados os elementos do sistema, tais como os scripts, as 
Stored Procedures e os triggers do banco de dados, se esses forem requeridos. 
Para tanto, é necessário revisar atentamente o código-fonte e os demais componentes 
do código, preferencialmente em conjunto com a área responsável, a fim de homologar 
os elementos já codificados em conformidade com as especificações e requisitos do 
sistema.
Assim, os documentos necessários (input) para a realização dessa fase são os seguintes 
artefatos: Modelo de Casos de Uso, Diagrama de Classes, Modelo de Banco de Dados e 
o Documento de Arquitetura, conforme já mencionado neste caderno. 
16
UNIDADE I │PROJETANDO SISTEMA
Exemplo de um trecho de codificação de um sistema:
Dim dbsNorthwind As DAO.Database
Dim rstOriginal As DAO.Recordset
Dim rstDuplicate As DAO.Recordset
Dim varBookMark As Variant
 Set dbsNorthwind = CurrentDb
 ‘Create the first Recordset.
 Set rstOriginal = dbsNorthwind.OpenRecordset(“Orders”, dbOpenDynaset)
 ‘Save the current record position.
 varBookMark = rstOriginal.Bookmark
 ‘Create a duplicate Recordset.
 Set rstDuplicate = rstOriginal.Clone()
 ‘Go to the same record.
 rstDuplicate.Bookmark = varBookMark
 rstOriginal.Close
Compilação do Sistema (build)
A Compilação do Sistema, também conhecida por build, representa a transformação 
do código fonte em um sistema executável compilado. Ao longo de todo o projeto de 
desenvolvimento podem ser geradas inúmeras compilações do sistema com o intento 
de testar, integrar e/ou validar. A última compilação do sistema será a versão final. Os 
responsáveis por essa importante etapa do processo são os programadores.
Gerência de Versões
É muito importante que as equipes desenvolvedoras do sistema possam seguir uma 
política de numeração das versões do sistema, de forma a permitir, com facilidade, que 
seja identificada a estabilidade dos itens constantes da configuração. 
Tal política deve ser aplicável principalmente no que diz respeito ao sistema completo. 
Contudo, poderão ocorrer situações em que seria necessária uma referência numérica 
em alguns componentes isolados de um determinado sistema. Dessa forma, essa diretriz 
poderá, em alguns casos, ser aplicada a ambos (sistema e determinados componentes), 
ressalvando formalmente sua utilização.
17
PROJETANDO SISTEMA│ UNIDADE I
Formato do Número de Versão
Podem ser atribuídos diferentes formatos. Contudo, convenciona-se a utilização do 
formato padronizado abaixo:
 » maior. menor [.correção] [-rótulo]
 » maior 
Corresponde ao número principal da versão, sendo que a atualização 
desse número sinaliza uma quebra de compatibilidade com a versão 
anterior. Tal situação normalmente ocorre mediante a realização de 
modificações significativas na arquiteturado sistema ou em componentes 
fundamentais.
 » menor 
Equivale ao número secundário da versão, sendo que a atualização desse 
número enseja a realização de alterações no sistema ou em componentes, 
com impacto suave ou relativo em suas funcionalidades, porém com a 
manutenção da compatibilidade com as versões secundárias anteriores.
 » correção (opcional) 
Representa o número de versões de correção disponibilizadas, ou 
seja, quando há a atualização desse número é indicado ao usuário que 
ocorreram correções de problemas detectados na versão anterior, porém 
sendo mantida a total compatibilidade com essa.
 » rótulo (opcional)
Corresponde a um texto, normalmente em letras minúsculas, que 
descreve algumas especificidades da versão disponibilizada. É utilizado 
com as expressões, por exemplo: alfa, beta, data de geração da versão ou 
nome da fase em que está o projeto (quando de sua execução) etc. 
Evolução do Número de Versão
Durante o desenvolvimento de um sistema/componente, convenciona-se chamar 
qualquer versão antes da disponibilização de “0.1” e a primeira a ser disponibilizada 
como “1.0”.
18
UNIDADE I │PROJETANDO SISTEMA
Seguindo essa premissa, a evolução dos números ocorre de acordo com as regras que 
citamos anteriormente.
Rótulos Comuns
Os rótulos são opcionais, sendo os mais comumente utilizados no desenvolvimento de 
sistemas os seguintes:
 » Alfa 
É quando se trata de versão ainda instável, a qual foi disponibilizada para 
testes pelas equipes de testes, de desenvolvimento e/ou de homologação.
 » Beta 
Refere-se a uma versão ainda instável, que é disponibilizada para ser 
testada pelos usuários finais do sistema.
 » RC (ou Release Canditate) 
Trata-se de uma versão estável, podendo ser uma possível versão final do 
sistema, caso nela não sejam identificados, durante os testes, quaisquer 
erros graves ou mesmo que forem impeditivos de sua aceitação pelos 
usuários finais.
19
UNIDADE II
TESTANDO SISTEMA 
E DESENVOLVENDO 
VERSÃO PILOTO
CAPÍTULO 1
Realização Teste em equipe técnica
O teste de sistema valida os aspectos funcionais do sistema, incluindo a análise de 
desempenho, a adequação e a consistência das funcionalidades definidas que serão 
feitas. 
Apesar de ser comum a realização de testes não projetados devidamente (ad hoc) 
durante o processo de codificação, a atividade de teste envolve uma abordagem mais 
sistemática. 
Da mesma forma que o projeto, o teste em equipe pode ser descrito como uma atividade 
progressiva, indo, normalmente, do elemento de menor complexidade para o de maior. 
Dessa forma, por exemplo, enquanto os testes de unidade são utilizados para verificar 
as partes individuais do sistema, que são seus módulos, funções e o interfaceamento 
delas, o teste de integração é responsável por verificar o funcionamento dessas partes, 
uma vez combinadas.
Segundo Reis (2003), entre as atividades fundamentais podem-se destacar como 
importantes do ponto de vista da realização dos testes, a fim de garantir a qualidade da 
peça final de software (sistema):
 » a revisão e auditoria de artefatos, incluindo código-fonte;
 » o levantamento e análise de métricas;
 » os testes (em alguns casos incluindo os testes públicos com grupo 
determinado de usuários);
 » a conformidade com a padronização interna (políticas e regras internas 
da empresa);
 » a padronização e certificação externa (em relação aos padrões 
estabelecidos no mercado).
20
UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO
Antes de iniciar o processo de testes, como vimos, é necessário elaborar o “Plano de 
Testes”, onde são definidas as situações de teste para cada caso de uso, além de serem 
definidas as respostas esperadas em cada um deles.
Além disso, outros testes específicos que devem ser realizados durante a atividade de 
teste, a fim de identificar comportamento do sistema em situações de estresse.
Após essa atividade, poderão ser identificados novos requisitos, que serão propostos 
pela equipe de testes e poderão fazer parte de novo versionamento.
Como citamos, deve ser verificado pelo programador se o código fonte está de acordo 
com os testes parciais definidos anteriormente.
O engenheiro de testes ou outro que exerça esse papel deve estar munido dos artefatos 
previamente gerados e buscar prováveis inconsistências e erros na implementação 
dos requisitos presentes na iteração atual, o que poderá ajudar na identificação das 
atividades que restam para finalizar a iteração atual e a situação identificada no projeto. 
Além disso, posteriormente é realizado um teste global buscando quaisquer inconsistências 
e erros na implementação dos requisitos presentes nas iterações. Ao final desse teste, 
é avaliada se a versão realizada no sistema pode ou não ser disponibilizada para sua 
implantação e utilização pelos usuários, inicialmente como uma “versão-piloto”.
Uma vez liberada a “versão-piloto”, o projeto pode passar para as atividades de 
desenvolvimento de manuais técnicos e de operação do usuário, elaboração de 
pacotes de instalação.
Os testes unitários, realizados pelos programadores da equipe do projeto, têm como 
objetivo avaliar se os elementos do sistema, que foi codificado, realmente atendem as 
respectivas e especificações de requisitos predefinidos.
Assim, a realização de testes unitários precisa considerar a criação de componentes de 
teste para cada um dos elementos do sistema implementado. Como prática recomendada, 
esses componentes de teste devem ser implementados antes da implementação dos 
elementos do sistema que estiverem associados a ele.
Dessa forma, a criação de componentes de teste tende a facilitar os esforços futuros de 
realização de testes de regressão sobre todo o sistema. Tais testes são fundamentais 
a fim de garantir que as novas implementações, sejam por melhoria ou correção, não 
introduzam erros em trechos de código que já foram previamente testados.
21
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
Além dos testes funcionais, algumas outras verificações podem ser também realizadas 
sobre os elementos do sistema, tais como as análises de:
 » cobertura dos testes;
 » código que não foi utilizado;
 » desempenho do código gerado (chamada de profiling);
 » alocações/desalocações de memória.
No mercado existem disponíveis diversas plataformas e ferramentas que podem ser 
utilizadas para realizar testes unitários e de análise de código, sendo que algumas 
dessas ferramentas são ou podem ser integradas, a fim de obter melhores resultados.
A atividade de testes deve ser desenvolvida com base nas especificações de Casos de 
Uso previamente definidos, no Diagrama de Classes, no Modelo de Banco de Dados e 
no Documento de Arquitetura.
Como possíveis passos para a realização da atividade de testes, podemos destacar os 
seguintes:
 » Desenvolvimento de componentes de teste, feitos de acordo com as 
especificações dos elementos implementados.
 » Realização de testes funcionais a partir do código-fonte.
 » A realização de análises sobre o código-fonte dos elementos.
 » Correção de problemas identificados durante os testes e análises conforme 
a necessidade.
 » Disponibilização do elemento testado para integração e compilação.
Objetivo do Processo
O objetivo de um processo de testes é o de possibilitar a verificação do software que 
está sendo construído pela equipe de desenvolvedores. Esse processo tem o intuito de 
conceder maior qualidade ao sistema em desenvolvimento. 
Por meio de um relatório, chamado de “Relatório de Resultado dos Testes”, é possível 
que seja avaliada a conformidade do produto (sistema) em relação aos requisitos 
estabelecidos no projeto de teste, que foram especificados pelos solicitantes. 
22
UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO
A realização dos testes corresponde a uma das partes importantes do desenvolvimento 
de qualquer software. Um processo consistente de teste de software apresentado foi 
desenvolvido, baseado nos conceitos do RUP (RationalUnified Process). 
O Rational Unified Process corresponde a um processo de engenharia de software que 
oferece uma abordagem baseada em algumas disciplinas, de forma a atribuir tarefas 
e responsabilidades dentro de uma sistemática de desenvolvimento. Assim, a meta 
desse processo é a de garantir a produção de sistemas (software) com um alto nível de 
qualidade. 
O RUP apresenta-se com duas dimensões: o tempo (que apresenta os aspectos do ciclo 
de vida do processo à medida que esse se desenvolve) e as disciplinas (que agrupam as 
atividades de maneira lógica, tendo por base a natureza de cada uma). 
Em um processo de desenvolvimento de software, conforme o RUP, é necessarío haver 
as seguintes fases: 
 » Dinâmica – define quando o sistema é aprovado e indica as fases, os 
marcos e as interações do processo. 
 » Estática – indica como o processo está descrito, a partir de atividades, 
fluxos de trabalho, componentes, disciplinas, artefatos e dos papéis 
desempenhados. 
Assim, durante o ciclo de vida do projeto, há a necessidade da existência de pontos de 
verificação, que estão focados em conferir qualidade ao produto. 
Tais procedimentos preestabelecidos desenvolvem e mantêm um processo repetitivo, 
que é iterativo e incremental, em que o produto é constantemente avaliado. Caso 
necessário, alterações são realizadas ao longo do processo, até que o sistema esteja 
maduro e, assim, pronto para ser disponibilizado para o usuário final. 
Durante as fases, existem pontos de controle ou verificação, em que são realizados testes 
diversos, a fim de comparar a conformidade do produto com o que foi estabelecido e 
descrito na documentação do projeto.
Métodos de Teste
Basicamente, apesar de existirem diversas metodologias e classificações de testes, 
conforme descrito no modelo RUP, tais metodologias estão subdivididas nos métodos 
da: 
23
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
Caixa Branca (Estruturais) 
Tem por objetivo analisar e descobrir possíveis falhas ou defeitos na estrutura interna, 
ou seja, no código do software. 
Assim, os testes citados, como sendo de Unidade, geralmente são efetuados por 
programadores da equipe de desenvolvimento ou outra definida para tal a partir dos 
códigos gerados. 
Em testes da Caixa Branca podem ser realizados os referentes à unidade ou testes 
unitários e os testes de integração. 
Esse estágio está focado na verificação dos menores elementos que podem ser testáveis 
no software. Nesse caso, o implementador realiza os testes unitários durante o processo 
de desenvolvimento do sistema. 
Os testes de Integração são executados a fim de garantir que os componentes do modelo 
de implementação possam funcionar adequadamente quando esses forem combinados. 
Esse teste (de integração) é, também, responsável por verificar possíveis erros nas 
especificações estabelecidas para as interfaces. 
Caixa Preta (Funcionais) 
Apresenta como objetivo investigar se os requisitos estabelecidos foram satisfeitos pelo 
software. 
Tem como atribuição verificar os resultados produzidos e, assim, não requerem 
conhecimentos internos a respeito do sistema, apenas se preocupando com os requisitos 
do negócio. 
São exemplos desses testes os do tipo funcional, de usabilidade, de configuração, de 
instalação, de estresse, de desempenho, entre outros.
Em Testes da Caixa Preta podem ser realizados os testes de sistema e os de aceitação. 
Os testes de Sistema são, normalmente, realizados no momento em que o software 
completo já está funcionando. Portanto, seu objetivo é o de verificar se o funcionamento 
de todos os elementos do sistema está de acordo e em perfeita integração. 
Já os testes de aceitação são realizados em momento anterior ao da implantação do 
sistema e têm como objeto a verificação se o software está pronto para ser disponibilizado 
aos usuários finais, a fim de executar as funções e as tarefas que foram previamente 
definidas. 
24
UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO
No próximo capítulo trataremos com mais detalhe dos tipos de testes acima descritos e 
de outros realizados em sistemas. 
Elaborar Casos e Procedimentos de Teste 
Todos os testes precisam ser executados com base nos artefatos “Casos e 
Procedimentos de Teste” (apresentados adiante), construídos previamente pela equipe 
de desenvolvimento, em conjunto com a equipe de realização dos testes e outros 
participantes que foram requeridos nesse processo. 
Neles são desenhados os possíveis testes aplicáveis ao sistema, a descrição dos 
procedimentos de teste e, em alguns casos, os scripts de teste a serem utilizados.
O desenvolver dos casos e procedimentos de teste são realizados a fim de validar os 
requisitos nos possíveis cenários definidos nos Casos de Uso previstos para o sistema. 
Nesse aspecto, para a realização do preenchimento do artefato é necessário que, para 
construí-los, o profissional se baseie nos artefato onde foram definidos os casos de uso 
para o sistema.
Cada um dos testes a ser realizado precisa estar definido no artefato “Casos e 
Procedimentos de Teste”. Nele, podem constar os possíveis exemplos das respostas 
corretas previstas para cada um dos testes estabelecidos.
Assim, quando da realização dos testes, a equipe responsável precisa avaliar 
comparando o que foi previsto para cada teste com os resultados reais obtidos durante 
a sua realização, buscando a conformidade do sistema em teste com os requisitos 
estabelecidos na matriz de requisitos e nas especificações dos casos de uso, a fim de 
obter, futuramente, a aprovação dos representantes dos usuários quanto à validação 
realizada e à adequação da arquitetura aos requisitos estabelecidos.
25
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
26
CAPÍTULO 2 
Tipos de Teste
Testes realizados em Sistemas
Testes de Funcionalidade
Os testes de funcionalidade avaliam o conjunto de características, a capacidade, a 
segurança, e se existem regras que devem ser aplicadas somente a determinadas 
informações consideradas relevantes para a compreensão dos conteúdos ou da 
navegação do sistema. 
Tais testes compreendem a realização de teste funcional; teste de volume; de controle 
de segurança e acesso; e de acessibilidade. 
Teste Funcional 
O teste funcional tem por premissa verificar a aceitação dos dados, do processamento 
e da resposta a ele e da implementação apropriada das regras de negócio. Assim, esse 
tipo de teste está baseado em técnicas citadas como de “caixa-preta”, uma vez que 
tenciona verificar o sistema e seu processamento interno, por meio de sua interação, 
de sua interface com o usuário e da análise das saídas ou de seus resultados. Assim, 
para execução desses tipos de testes funcionais seriam utilizados os procedimentos 
anteriormente definidos como suficientes, nos Casos de Teste dessas respectivas 
funcionalidades. 
O objetivo desse tipo de teste é o de tentar assegurar a funcionalidade do sistema e, para 
tanto, inclui testes de entrada de dados, de resposta e de processamento. 
Como técnica/método, excuta cada caso de uso, seguindo o fluxo previsto nos casos de 
uso, ou ainda, segue as funções. Para tanto, são utilizados dados válidos e inválidos, a 
fim de verificar se os resultados esperados ocorrem quando dados válidos são usados; 
se as mensagens de erro de avisos apropriadas são exibidas quando dados inválidos são 
utilizados, e se cada regra de negócio é corretamente aplicada. 
vanderlei.santos
Realce
vanderlei.santos
Realce
27
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
Teste de Volume 
Nesse tipo de teste é submetida uma grande quantidade de dados (volume) no sistema 
a fim de se determinar quais seriam os limites de bom funcionamento e que quantidade 
poderia causar falhas no software. Assim, esse teste busca identificar a carga máxima 
persistente que o sistema poderia suportar em um dado período pré-estabelecido. 
Objetiva verificar se o sistema pode funcionar com sucesso sob alguns cenários críticos,com grande volume de dados. Por exemplo, determinar um número máximo de 
clientes que podem acessar ou estar conectado ao sistema conjuntamente com uma boa 
performance ou, mesmo, de verificar todos os usuários que podem realizar a mesma 
tarefa ou função e sobre que circunstâncias de desempenho. Além disso, por exemplo, 
esse teste pode buscar a visualização do tamanho máximo alcançado pelo banco de 
dados, sem comprometer o desempenho do sistema, ou mesmo, apurar a quantidade 
máxima de múltiplas consultas ou o número de transações que podem ser executadas 
simultaneamente. 
Para tanto, se utiliza de testes desenvolvidos para esse fim, chamados de testes de 
Desempenho ou testes de Carga. Os resultados são obtidos a partir da utilização de 
múltiplos clientes executando os mesmos testes ou fazendo testes complementares 
para produzir transações de pior desempenho ou transações mistas (de alto e baixo 
desempenho).
Além disso, esse teste busca definir limites para o tamanho do banco de dados e para 
que múltiplos clientes possam executar consultas simultâneas e, até mesmo, reportar 
transações simultaneamente por períodos prolongados de tempo. 
Teste de Controle de Segurança e Acesso
Os testes de controle de segurança e de acesso concentram-se, principalmente, nas 
áreas de segurança em nível de:
 » Sistema – que inclui o acesso ao sistema realizado de forma local ou 
remota. Prevê que apenas os usuários com permissão específica de acesso 
sejam capazes de adentrar ao sistema. No caso de sistemas integrados 
com outros, é necessário realizar testes de integração. 
 » Aplicação – que inclui o acesso aos dados e/ou às funções do negócio. 
Para tanto, prevê que, baseado na segurança requerida/desejada para o 
sistema, os usuários estejam restritos as suas funções específicas definidas 
nos casos de uso, ou estejam limitados aos dados que possam ser a eles 
vanderlei.santos
Realce
vanderlei.santos
Realce
vanderlei.santos
Realce
vanderlei.santos
Realce
28
UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO
disponibilizados, de acordo com o perfil predefinido a eles. Para tanto, 
são identificados e listados cada tipo de usuário, bem como as funções ou 
dados aos quais cada um desses tipos tem permissão de acesso. 
A fim de realizar esses testes, são criados testes específicos para cada tipo de usuário e 
são verificados os acessos de cada permissão, criando transações específicas para cada 
um dos tipos possíveis. 
Também é necessário modificar o tipo de usuário e, a partir disso serem executados 
novamente os testes. Nesses casos, são verificadas as funções adicionais ou se os dados 
foram disponibilizados de forma correta ou não. 
Teste de Acessibilidade 
Os testes de acessibilidade são responsáveis por verificar se a interface do usuário 
está fornecendo acessos apropriados às funções do sistema e à navegação de forma 
adequada. 
Esses testes visam à garantia de que os objetos pertencentes à interface do usuário 
estejam funcionando de acordo com os padrões constantes dos artefatos do projeto, 
que foram definidos pelos clientes. 
O teste de acessibilidade tem por objeto verificar se a navegação do sistema está 
refletindo corretamente as funções e requisitos de negócio. 
Para tanto, busca verificar objetos e características da janela, tais como: menus, 
tamanho, posição, estado e foco, conforme os padrões. 
A fim de realizar esse teste é, normalmente, necessário criar ou modificar diferentes 
testes para cada uma das janelas de acesso. Dessa forma, busca-se verificar se a 
navegação está correta e se os estados de objeto de cada janela do sistema e dos objetos 
previstos também estão corretos, conforme os resultados esperados. 
Nesses casos, é requerida a realização da navegação janela a janela, campo a campo, e 
a utilização de métodos de acesso diversos (teclas de atalho, mouse, tecla de tabulação 
(TAB)). 
Testes de Usabilidade
Os testes de usabilidade são responsáveis por verificar a estética, a acessibilidade 
humana, a consistência da interface de usuário e a pertinência de assistentes e telas 
de ajuda. Verificam a facilidade que o sistema apresenta de ser facilmente operado e 
vanderlei.santos
Realce
vanderlei.santos
Realce
29
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
entendido pelos usuários, assim como o claro entendimento das funções do sistema 
pelos usuários, por meio da utilização de assistentes eletrônicos, manuais, telas de 
ajuda (help on-line) etc. 
Como técnica de teste, pode-se, por exemplo, ser definida a execução de diferentes 
operações do sistema e, para tanto, é requerida a utilização de manuais e das telas de 
auxílio. 
Testes de Confiabilidade
Testes de confiabilidade são os destinados a avaliar a confiança nos resultados obtidos 
pelo sistema, a frequência da ocorrência e da severidade de falhas e sua recuperação e 
o chamado MTBF (tempo entre a ocorrência das falhas).
Com referência à confiabilidade dos sistemas, citamos os tipos de teste mais conhecidos: 
de estresse, de regressão, de integridade e de estrutura.
Teste de Estresse 
Esse tipo de teste de confiabilidade intenta verificar o desempenho do sistema. Para 
tanto, programa e executa procedimentos a fim de entender o comportamento do 
sistema mediante situações-limite, ou mesmo fora da tolerância esperada. 
Tipicamente, envolve recursos baixos ou uma grande concorrência por eles. Assim, 
baixos recursos disponíveis revelariam possíveis defeitos que não são aparentes 
durante o uso do sistema em condições normais. Assim, outros defeitos podem resultar 
de tal concorrência de recursos compartilhados, tais como a possibilidade de ocorrer 
travamento em banco de dados, resultante da utilização de todas as bandas de rede de 
comunicações. 
Alguns desses defeitos são normalmente obtidos a partir de testes funcionais e de carga. 
Esse teste busca verificar se o sistema funcionaria sem apresentar problemas na 
ocorrência das condições de estresse predefinidas, tais como: 
 » Quantidade máxima ou fisicamente suportada de clientes conectados ou 
por meio de simulação.
 » Pouca memória disponível no servidor.
 » Diversos usuários realizando as mesmas transações contra os mesmos 
dados ou contas. 
vanderlei.santos
Realce
vanderlei.santos
Realce
30
UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO
 » Grande volume de transações.
São utilizados diferentes testes desenvolvidos e acordados previamente a fim de verificar 
o desempenho ou estabelecer testes de carga de dados/usuários. 
A fim de poder testar a limitação de recursos, eles podem ser executados em uma 
máquina simples, com memória RAM e drives de disco no Servidor de tamanho mínimo 
requerido ou que sejam limitadas a condições passíveis de serem encontradas pelos 
usuários. 
Para que os testes de estresse sejam pertinentes, devem ser utilizados múltiplos clientes 
(de forma real ou simulada), executando os mesmos testes ou testes complementares, 
a fim de produzir volumes de transação limite ou de transações mistas (alto e baixo 
desempenho). 
Observamos que, para estressar redes, pode ser necessário o uso de ferramentas 
adicionais a fim de carregá-la com mensagens ou pacotes. Além disso, o armazenamento 
persistente a ser utilizado pelo sistema deve ser reduzido temporariamente a fim de que 
seja restringido o espaço disponível para o crescimento do banco de dados. 
Teste de Regressão 
O teste de regressão consiste em realizar um teste, com caráter seletivo, de um 
software que foi modificado ou de interações anteriores. Tem como propósito garantir 
que qualquer falha tenha sido reparada e que nenhuma operação que funcionava 
anteriormente tenha falhado após os reparos, ou seja, que as novas características 
adicionadas não criaram problemas com as versões anteriores ou com outros sistemas. 
Tal teste objetiva verificar que alguma das alterações que foram realizadas no software 
gerou qualquer tipo de inconsistência no aplicativo ou em outros sistemas que estejam 
integradosa ele. 
Como método, são utilizados scripts especialmente desenvolvidos para serem 
executados de forma progressiva a fim de verificar se alguma falha foi encontrada após 
terem sido realizadas alterações. 
Teste de Integridade
O teste de integridade prevê que os bancos de dados e as regras de negócio precisam ser 
verificados de forma independente. Assim, esse tipo de teste não deve ser realizado por 
meio da interface de usuário definida para o acesso aos dados. 
vanderlei.santos
Realce
vanderlei.santos
Realce
31
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
Tem por objetivo executar os métodos de acesso à base de dados e regras de negócio 
de forma independente da interface do usuário, de forma que seja possível observar e 
registrar o comportamento funcional incorreto ou a corrupção de dados. 
Como técnica, busca que sejam examinados os bancos de dados a fim de garantir que os 
dados tenham sido povoados de acordo com o planejado e que todos os eventos possam 
ocorrer de forma própria e correta. Para tanto, são revisados os dados retornados a fim 
de verificar se estão corretos. 
Para que isso ocorra, são executados métodos de acesso e processos, utilizando, em 
cada um, dados válidos e inválidos ou solicitações de dados. 
Observa-se que os testes podem exigir disponibilização de ambiente específico, com 
drivers e sistema gerenciador de banco de dados próprio, para que os dados sejam 
diretamente incluídos na base e os resultados obtidos possam ser livremente comparados 
com os requeridos. Nesse caso, se existirem processos de suporte para a realização do 
teste, esses precisam ser acionados de forma manual.
Teste de Estrutura 
São testes destinados a avaliar a adequação do objetivo do teste em relação a seu 
design e sua formação. Em geral, são realizados em aplicativos habilitados para a Web, 
garantindo que todos os links estejam conectados, que o conteúdo apropriado seja 
exibido e que não haja conteúdo órfão. 
Testes de Desempenho
Os testes de desempenho avaliam a eficiência, o tempo de resposta, a vazão e o consumo 
de recursos pelo sistema. Compreendem a realização dos testes de desempenho, de 
carga, de contenção, de perfil de desempenho.
Teste de Desempenho (propriamente dito)
O teste de desempenho mede e avalia o tempo de resposta, o número de transações e 
outros requisitos sensíveis ao tempo.
Esse teste intenta verificar o comportamento do sistema para funções de transações 
ou de negócio, designadas sob as condições em carga normal de trabalho e em caso de 
carga limite de trabalho. 
vanderlei.santos
Realce
vanderlei.santos
Realce
vanderlei.santos
Realce
32
UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO
Utiliza procedimentos de teste desenvolvidos para avaliar a funcionalidade em cada 
ciclo de negócio. Para tanto, modifica os arquivos de dados a fim de aumentar o número 
de transações ou de scripts com o propósito de aumentar o número de iterações em que 
cada transação pode ocorrer. 
Tais scripts precisam ser executados, normalmente, em uma máquina, (essa é a melhor 
forma de verificar) utilizando um simples usuário e por meio de transações simples, 
podendo ser repetido para múltiplos clientes de forma real ou virtual. 
Observamos que os testes de desempenho incluem a presença de uma carga de 
trabalho no servidor. Para tanto, existem muitos métodos que podem ser utilizados: as 
transações realizadas diretamente para o servidor, normalmente na forma de SQL; a 
criação de carga de usuário virtual a fim de simular muitos clientes; as ferramentas de 
Emulação de Terminais remotos são usadas para sobrecarregar a rede de mensagens; o 
uso de múltiplos clientes físicos executando scripts de teste a fim de aumentar a carga 
do sistema. Os testes de desempenho podem ser realizados em máquina ou tempo 
dedicados, permitindo o controle máximo e com medidas mais precisas. 
Recomenda-se, para testes de desempenho, a utilização de bancos de dados com 
tamanho real ou aproximado. 
Teste de Carga 
Este teste submete o sistema à grande variação de carga de trabalho a fim de 
verificar o comportamento de desempenho e a habilidade de continuar funcionando 
corretamente sob a exposição em diferentes cargas de trabalho. 
Além disso, avalia as características de desempenho, as taxas de transações, o tempo de 
resposta etc. 
Objetiva verificar o comportamento do sistema em condições de carga de trabalho 
variante e, para tanto, utiliza testes desenvolvidos para testes funcionais ou de ciclo 
de negócio, por meio de modificar arquivos de dados a fim de aumentar o número de 
transações, testes para aumentar o número de vezes que as transações ocorrem ou 
variações quanto ao número de usuários que estão conectados ao sistema. 
Observamos que tais testes, preferencialmente, devem ser realizados em máquina 
ou ambiente dedicado, simulando as condições reais de trabalho ou em determinado 
tempo dedicado. Tais procedimentos permitem o máximo controle e medidas mais 
precisas, preferencialmente apresentando bancos de dados de teste com tamanho real 
ou aproximado ao utilizado. 
vanderlei.santos
Realce
33
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
Teste de Contenção 
Esse tipo de teste está direcionado a verificar a habilidade de um componente em 
suportar demandas múltiplas por meio de um recurso. 
Teste Perfil de Desempenho 
Teste em que o perfil de andamento do seu objetivo é monitorado (inclusive fluxo de 
execução, acesso a dados e chamadas de função e de sistema), a fim de identificar e lidar 
com gargalos de desempenho e processos ineficientes. 
Testes de Suportabilidade
Os testes de suportabilidade verificam a facilidade de instalação e os requisitos de 
configuração, de compatibilidade e de adaptabilidade. Tais testes comportam os testes 
de instalação e de configuração do sistema.
Teste de Instalação 
O teste de instalação busca garantir que o software possa ser instalado completamente, 
de forma personalizada, ou ser atualizado (conforme o objetivo desses) sob condições 
apropriadas, e procura verificar que, uma vez instalado, o sistema funcionará 
corretamente.
Seu objetivo é, portanto, verificar se o software é instalado corretamente em cada 
configuração de hardware exigida, sob a condição de que:
 » novas instalações em novas máquinas possam ser realizadas onde o 
sistema não tenha sido instalado antes (detecção de versões/instalações 
anteriores); 
 » atualizações sejam efetuadas em máquinas onde o sistema tenha sido 
previamente instalado e a versão seja compatível com elas. 
São métodos de efetuar o teste: a realização da instalação e a observância dos resultados. 
Para tanto, podem ser utilizados conjuntos predeterminados de scripts de testes 
funcionais. 
Teste de Configuração do Sistema
Esse tipo de teste verifica a operação do sistema em diferentes configurações de software 
e hardware, ou seja, se o sistema-alvo do teste pode funcionar corretamente nas 
vanderlei.santos
Realce
vanderlei.santos
Realce
vanderlei.santos
Realce
vanderlei.santos
Realce
vanderlei.santos
Realce
34
UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO
configurações de hardware e software exigidas. Para tanto, pode fazer uso de scripts 
de testes funcionais e pode abrir e fechar diferentes softwares relacionados e que não 
sejam os alvos de teste durante e antes da sua execução para avaliar o desempenho do 
sistema. 
Além disso, se for o caso, pode buscar a repetição desses processos e/ou diminuir a 
capacidade de memória disponível para avaliar situações extremas. Busca efetuar os 
testes nos ambientes definidos e em especificações que forem suplementares. 
Observa-se a viabilidade de se investigar quais seriam as aplicações adicionais que 
poderiam ser tipicamente utilizadas pelos usuários do sistema e quais dados essas 
aplicações estariam administrando, tais como planilhas, bancos de dados, documentos 
etc. Além disso, verificar quais serão os sistemas operacionais utilizados na rede onde o 
sistemairá funcionar, as informações sobre os servidores da rede, os bancos de dados, 
os sistemas gerenciadores de bancos de dados e aspectos relacionados às situações reais 
de uso do sistema, que precisam ser relacionados como parte desses testes.
Como artefatos requeridos (input) para a realização dessa atividade citamos: o código-fonte; 
o Modelo de casos de uso; o Diagrama de classes; o Modelo de banco de dados e o Documento 
de arquitetura.
A seguir, mostramos um exemplo de Artefato de “Relatório Final de Testes”.
35
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
36
UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO
37
CAPÍTULO 3 
Desenvolvimento de Versão-Piloto
Após terem sido realizados todos os testes predefinidos e obtidos os resultados esperados 
para a peça de software, alguns problemas ainda podem ser descobertos ou por não 
terem sido previstos ou devido a situações novas que poderão vir a surgir.
Para tanto, é extremamente recomendável que se disponibilize uma “versão-piloto”, 
que deve ser submetida a um número selecionado de usuários, suficientes para oferecer 
uma prova real de como o sistema se comporta frente ao uso.
Tal fase é importante e, em casos de sistemas que estejam sendo substituídos por outros 
ou de serviços que passarão a ser suportados pelo novo sistema, é fundamental que 
o sistema ou formato de realização dos serviços seja mantido em paralelo, seja pela 
continuidade do serviço em caso de problemas ou pela correta análise dos resultados 
fornecidos pelo sistema.
A versão-piloto, uma vez aprovada, se não for detectada qualquer restrição ou problema, 
poderá passar a ser utilizada para uso definitivo e, a partir daí, distribuída para todos 
os usuários.
Para esse teste piloto, é recomendável que seja estabelecido um tempo adequado de 
teste e, também, situações reais de utilização do sistema. Poderão ser simulados testes 
extremos e outros tipos que simulem períodos de picos e vales de utilização.
Assim, as atividades do grupo de processos de monitoramento e controle são constituídas, 
também, pela verificação do escopo, ocorrendo de forma paralela à execução do projeto.
38
CAPÍTULO 4 
Realização de Teste em usuário final
Como já observado, antes de disponibilizar o teste para os usuários, normalmente, 
visando à qualidade do produto final, uma série de testes já foram realizados e algumas 
possíveis correções já foram feitas. 
O ato de testar o código significa verificar se as funcionalidades atendem ao que foi 
especificado pelos usuários e, por isso, trata-se de uma análise das pré-condições e 
pós-condições diante do contexto no qual está inserido o sistema ou módulo, objeto 
dos testes. É fundamental definir e realizar todos os testes julgados como necessários, 
aplicando-os em situações e condições próximas ao ambiente e à realidade que o 
sistema irá enfrentar, a fim de que seja garantida a qualidade, eficiência e, até mesmo, 
resguardar a imagem da equipe de desenvolvedores antes que seja disponibilizada uma 
versão de teste para os usuários finais. Essa é uma prática correta, seguida pela maioria 
das equipes de desenvolvimento e grandes empresas de software no mundo.
Apesar de, aparentemente, todos os itens que foram solicitados pelos clientes já terem 
sido checados e todas as funcionalidades formalizadas já devem estar de acordo 
com o que foi pedido, em face dos testes já realizados e da comparação com o que 
está formalizado nos artefatos e em outros documentos assessórios do processo de 
desenvolvimento, nesse tipo de teste podem surgir outros problemas advindos de testes 
que não foram previamente estabelecidos – porém eram necessários, de aspectos que 
não foram considerados e até mesmo de problemas que não foram identificados nos 
testes previstos.
Assim, normalmente, para a realização desses testes é escolhido um grupo de usuários 
finais que possam representar bem os diferentes tipos de usuários finais do sistema. 
Esse grupo começará a utilizá-lo – em condições normais, porém assistido e reportando 
sazonalmente suas observações à equipe de desenvolvimento ou à responsável pela 
consecução de tais testes.
Esses testes, além de verificar a operacionalização normal do sistema, podem estar 
focados também na estrutura interna das funções de segurança do software, a fim de 
verificar se os subsistemas, módulos ou outros sistemas que estão integrados estão 
atendendo plenamente às especificações que foram definidas por esses usuários.
Assim, o teste em usuários finais preconiza, também, a verificação de que o software 
está de acordo com o que era esperado por esses usuários. Se ele atende plenamente 
39
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
suas necessidades ou se ainda existe algo necessário que não foi inicialmente previsto 
quando da realização do projeto. Nesse ponto, com a utilização do sistema em condições 
reais, às vezes são verificadas novas funcionalidades que seriam necessárias e que não 
foram previstas ou são abertas novas possibilidades que não haviam sido vislumbradas 
pelos usuários e solicitantes do sistema. Nesses casos, deve ser avaliada a realização de 
correções, um versionamento (realização de nova versão) ou, mesmo, a confecção de 
novo projeto que contemple as novas necessidades apresentadas.
Podem ser detectadas vulnerabilidades no sistema, que podem ser oriundas de 
uso de funcionalidades ou conduta de operação não prevista da realização de 
configurações diferentes das previstas e de outros aspectos que preconizem a 
realização de correções ou adaptações diversas, bem como a possibilidade de 
implementação de novos aspectos de segurança, permutacionais (senhas) etc.
Podemos verificar que a realização desse teste com os usuários finais é fundamental a 
fim de buscar a garantia da qualidade do software e da boa aceitação do sistema junto 
aos usuários.
40
CAPÍTULO 5 
Elaboração de solicitações de 
mudanças
Uma vez realizados os testes, durante o processo podem surgir solicitações de alterações 
necessárias, de correções ou de mudanças tidas como importantes. Mesmo nos casos 
em que todas as solicitações formalizadas tenham sido plenamente atendidas, outras 
funcionalidades não previstas pelos usuários finais podem ter sido detectadas por eles 
quando tiveram contato com o sistema. Assim, como houve interesse desses usuários 
em realizar um pedido que venha a ensejar mudanças no sistema, elas deverão ser 
formalizadas com uma “Solicitação de Mudança”.
Apesar de a metodologia que estamos tratando ter como fim aproximar bastante as 
requisições dos usuários das possibilidades de realização do corpo técnico são observados 
aspectos que antes não puderam ser planejados, que não foram lembrados ou, mesmo, 
de algumas alterações que poderiam melhorar significativamente a performance e 
operação do software.
Alguns dos exemplos mais comuns de alterações que podem surgir, quando da 
disponibilização de testes com os usuários finais são as oriundas de situações mal 
previstas ou não previstas, tais como uma mera alteração na disposição de campos em 
telas de inserção de dados (que, ao serem submetidas às reais condições de uso, pelos 
usuários finais ou digitadores, com a interação com os clientes ou condições reais de 
inserção, verifica-se que uma disposição diferente dos campos facilitaria o uso e tornaria 
mais rápido o serviço); a inserção de dados faltantes que poderiam ser requeridos em 
estatísticas; e outras situações, derivadas da necessidade de novas funcionalidades, 
como a inserção de uma calculadora que transfira os valores para o sistema ou que 
localize CEPs, a partir da digitação de endereços etc.
Em um projeto de desenvolvimento é fundamental a figura do cliente, nesse caso 
representado pelo usuário, uma vez que é para ele que o sistema está sendo desenvolvido. 
Este passa a ser o papel de maior importância em todo o processo de desenvolvimento. 
Assim, a participação ativa dos usuários, na maioria das atividades de um projeto 
dedesenvolvimento de um sistema, é extremamente benéfica e recomendável, seja 
na definição do escopo do produto, no levantamento de requisitos e, sobretudo, na 
validação do produto final.
Sua concordância e satisfação quanto aos rumos de um projeto, assim como, o seu 
retorno quanto à realização dos testes de utilização e à velocidade de implementação 
41
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
dos ajustes por eles requeridos como necessários visam garantir que os objetivos sejam 
atendidos e melhoram a satisfação desses usuários com o resultado final. Dessa forma, 
as proposições de ajustes devem ser encaradas como oportunidades de melhorias no 
sistema e formas de aproximação desses usuários com os realizadores e, com isso, obter 
melhor índice de aprovação e sucesso do projeto.
Um grupo muito importante nessa fase é a “gerência de mudanças”, que busca garantir 
que todas as mudanças realizadas no projeto ao longo do seu desenvolvimento possam 
seguir um processo formal de análise, avaliação de impacto e autorização/aprovação 
pelas partes interessadas ou por aquelas que estão de alguma forma envolvidas no 
projeto. Dessa forma, a equipe do projeto deve estabelecer um processo que propicie 
o acompanhamento de todas as requisições de mudança, desde a sua criação até a sua 
conclusão, sobretudo logo após a implementação dos diversos tipos de artefatos.
Em um processo de melhoria contínua do desenvolvimento, esse contato deve ser 
encarado como um ciclo vivo dentro de um projeto, uma vez que vários aspectos estão 
em constante mudança, seja no que diz respeito à tecnologia, ao conhecimento ou aos 
usuários.
Assim, todos os processos precisam ser analisados regularmente e avaliados quanto a 
eventuais problemas que possam vir a surgir, a fim de serem mitigados ou corrigidos. 
E, ainda, que novas necessidades que surgiram durante a realização do projeto possam 
ser eficazmente atendidas.
42
CAPÍTULO 6 
Elaboração de manual do usuário
Sabemos que qualquer usuário de um sistema precisa de informações exatas sobre a 
forma correta de usá-lo. Se a informação for disponibilizada de forma conveniente, e se 
for de fácil compreensão, os usuários poderão utilizar de forma adequada o produto e, 
consequentemente, ficarão mais satisfeitos. 
Assim, uma documentação bem produzida auxilia os usuários, proporciona redução de 
custos em treinamento e com suporte. Além disso, agrega valor ao produto (sistema) 
frente aos seus clientes. 
Normalmente, os usuários de software de aplicação conhecem (ou pelo menos deveriam 
conhecer) as regras de negócio e as tarefas destinadas ao sistema. Contudo, inicialmente, 
não dispõem de versatilidade ao operá-lo. Portanto, um projeto de documentação 
voltado para as necessidades e especificidades dos usuários pode ser fundamental para 
o sucesso de um projeto, tornando-se uma das primeiras referências concretas entre o 
usuário e o software. Oportunidade em que, são estabelecidas as primeiras impressões 
dos usuários em relação ao sistema. 
A documentação constitui uma parte fundamental, integrante de qualquer sistema 
criado, sendo muito importante também no que se refere à segurança, pois, sem a 
devida documentação, a localização e a correção de alguns pontos vulneráveis no 
sistema seriam prejudicadas.
A estrutura de uma documentação de usuário do software, impressa ou eletrônica, 
inclui sua segmentação, organização e forma de apresentação. 
Pode ser organizada em um único volume ou em módulos que auxiliem o usuário a 
localizar e a compreender como operar o sistema e por que tais funcionalidades são 
disponibilizadas, para que elas sejam corretamente exploradas e utilizadas. 
Para tanto, a documentação técnica manuais, apostilas ou referências on-line (Help ou 
telas de ajuda) deve estar voltada para as necessidades dos usuários, para seu nível de 
conhecimento e linguagem e estar direcionada ao usuário final e/ou administradores 
do sistema. Precisam informar como o software deve ser usado, o que se pode esperar 
dele e como devem ser recebidas as informações necessárias.
Assim, como vemos, um dos aspectos fundamentais da realização do projeto de um 
sistema é sua documentação. Esse aspecto ainda hoje é, por vezes, negligenciado ou é 
43
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
dada pouca prioridade. Porém, mesmo no caso do manual do usuário, além de permitir 
uma melhor exploração e uso dos recursos do sistema pelos usuários, são fundamentais 
para a realização de versionamentos (novas versões) por outros que não os realizadores 
do sistema.
Nossa metodologia prevê, para tanto, a utilização do artefato “Documentação de 
Usuário”, que representa um conjunto de documentos que são elaborados com foco no 
usuário final do sistema. Eles incluem os manuais, a ajuda (nas telas do sistema), os 
guias rápidos, os releases notes, entre outros. 
O processo de Documentação de Sistemas precisa ser realizado por uma equipe 
capacitada e que utilize ferramentas adequadas para a elaboração desses 
artefatos.
Produtos que envolvem o processo de documentação de sistemas
 » Visão Geral 
Apresenta os objetivos e funcionalidades principais do sistema. Precisa 
descrever as características que sustentam as funcionalidades do software 
desenvolvido. Um cuidado nesse aspecto é o de adequar a linguagem ao 
nível de entendimento dos usuários (não podendo ser a de técnicos da 
área de sistemas) e não entrar em detalhes muito técnicos.
 » Manual de Operação 
Esse documento precisa mostrar, em maior nível de detalhamento, as 
funcionalidades disponíveis ao usuário, sendo que as tais funcionalidades 
do sistema podem estar agrupadas de forma lógica em Manuais de 
Operação.
Considerando que esse tipo de documento é visto como um dos mais 
importantes pelos usuários e demais partes envolvidas no sistema, a 
seguir, apresentamos uma sugestão de modelo, a fim de auxiliá-lo na 
construção do “Manual de Operação” de um sistema:
44
UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO
 » Manual de Relatórios
Busca descrever quais as informações que podem ser apresentadas em 
cada um dos relatórios disponíveis pelo software.
45
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
 » Manual de Instalação e de Administração 
Apresenta informações importantes, tais como as de instalar, configurar 
e manter o produto de software operacional.
 » Release Note
Tem por objetivo descrever de forma sucinta a versão do produto que 
está sendo liberada, relacionando as novidades dessa nova versão, que 
são oriundas de requisitos funcionais e não funcionais. Esse documento 
relaciona, também, as correções que foram efetuadas. Corresponde a 
uma fonte primária de informação que permite que se tenha uma ideia 
do histórico da evolução do sistema. Assim, o que estiver descrito nesse 
documento precisa refletir com detalhes a documentação do produto, 
caracterizando-se, dessa forma, a atividade de manutenção e evolução da 
documentação desse software.
 » Guia Rápido 
Trata-se de um manual de referência rápida. Nele são descritos os 
comandos e conceitos principais do sistema, de forma bem sucinta, que 
facilitem ao usuário a utilização ou resolução de problemas de forma 
mais rápida que na leitura de outros manuais.
Documentos de Apoio
Alguns documentos caracterizados são apoio para auxiliar no desenvolvimento do 
projeto. Podem ser oriundos de diversas fontes ou, mesmo serem externos ao processo. 
De forma contrária aos artefatos, esses documentos de apoio não necessitam de 
preenchimento, uma vez que podem servir de padrão para qualquer projeto e, por isso, 
se enquadram nas necessidades dos desenvolvedores.
Plano de Gerência de Configuração
Tem por objetivo descrever todas as atividades relacionadas com a gerência de 
configuração e ao controle das mudanças do projeto, que são realizadas durante o 
ciclo de vida do produto. Esse documento precisa relacionar as responsabilidades 
dos membros da equipe do projeto e, também,os recursos necessários de software, 
hardware e de usuários.
46
UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO
Perfis de Segurança
Os perfis de segurança são os que descrevem os requisitos funcionais de segurança 
que precisam estar implementados nos sistemas e que tenham sido classificados pelos 
usuários, de acordo com seu nível de segurança e acesso aos dados do sistema.
Tipos de Sistemas
Os principais tipos de sistemas podem ser classificados como operacionais, financeiros 
e os gerenciais: 
Operacionais
São os tipos de sistemas que lidam com informações a respeito de usuários do sistema e 
dos procedimentos associados. O principal objetivo da segurança nesse perfil é garantir 
o sigilo das informações e a privacidade dos usuários, bem como o acesso dos usuários 
apenas às informações necessárias para sua operação, ou de acordo com seu nível de 
acesso previamente definido pelos administradores.
Financeiros 
São sistemas com a função específica de administrar os valores financeiros, os estoques, 
o patrimônio. São utilizados na gestão de empresas e apresentam como principal objetivo 
da segurança o de garantir o sigilo máximo das informações financeiras e cadastrais 
apenas a um seleto grupo de usuários da empresa, definidos pela alta administração. 
Gerenciais
Tem como finalidade o suporte à tomada de decisão dos gestores e, portanto, fornecem 
informações de forma condensada e ágil. Para tanto, apresentam perfil extremamente 
restrito, pois têm acesso a informações sigilosas da empresa, sendo acessados pela alta 
administração ou funcionários designados por ela para esse fim.
Tais sistemas, segundo o seu tipo, apresentam características específicas. Ao se construir 
o sistema com as características específicas a quem ele se destina deve-se ter o cuidado 
de adequar seus manuais a ele (por exemplo: um sistema gerencial apresenta menos 
detalhes e relatórios mais concisos e com um número reduzido de informações muito 
relevantes apresentadas de forma sintética, enquanto nos sistemas operacionais deve 
ser ter, conforme o caso, muito detalhamento e relatórios analíticos). 
47
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II
Possíveis documentos de Apoio Internos 
São os sistemas de apoio e infraestrutura das empresas ou internos e administrativos 
em geral.
Recomendações de Segurança para Web Services
Os Web Services (serviços disponibilizados via Internet) são os que definem uma 
nova tecnologia criada com o objetivo de permitir a troca de informações em formato 
padronizado entre diferentes aplicações. Tal troca realiza-se utilizando a rede, podendo 
esta ser a intranet da empresa, um canal protegido por criptografia em rede aberta ou, 
mesmo, pela Internet.
O objetivo desse documento é mostrar os requisitos de segurança corporativos na 
implementação de Web Services (WS). Diante dessa necessidade, foram descritos 
alguns cenários possíveis de uso e evolução dessa tecnologia, buscando orientar sua 
implantação de forma segura no ambiente corporativo.
Além disso, o documento apresenta as principais vulnerabilidades encontradas na 
utilização dessa tecnologia, e as recomendações (opcionais e mandatórias) para cada 
uma delas, com o intuito de prevenir ataques em cada um dos cenários apresentados.
48
Para (não) Finalizar
O conteúdo apresentado neste Caderno teve o propósito de aprofundar seus 
conhecimentos sobre o desenvolvimento de Modelo de Dados, a codificação de 
Sistema, a realização de testes e, ainda, entre outros de grande valor nesta disciplina, os 
procedimentos para elaboração do Manual do Usuário, considerados de fundamental 
importância para o manuseio do Sistema e o alcance dos objetivos pretendidos.
Esperamos que os conhecimentos aqui trabalhados tenham contribuído no sentido de 
incrementar suas habilidades no trato com Processo de Desenvolvimento do Projeto, 
bem como acirrado seu desejo de buscar outras fontes de pesquisa com vista ao seu 
aprimoramento profissional.
Boa sorte!
49
Referências
ALMEIDA, Luís Fernando Barbosa. A metodologia de disseminação da 
informação geográfica e os metadados. Rio de Janeiro: UFRJ, 1999
CARDOSO, Caíque. UML na prática: do problema ao sistema, ciência moderna: Rio 
de Janeiro, 2003.
COAD, Peter; YOURDON, Edward. Análise baseada em objetos. Rio de Janeiro: 
Campus, l992.
COCKBURN, Alistair. Escrevendo casos de uso eficazes: Um guia prático para 
desenvolvedores de software. São Paulo: Bookman, 2005.
DAVENPORT, Thomas H.; MARCHAND, Donald A.; DICKSON, Tim et al. Dominando 
a gestão da informação. 1. ed. Porto Alegre: Bookman, 2004.
DINSMORE, Paul Campbell; supervisão. CAVALIERI, Adriane; Coordenação. Como 
se tornar um profissional em gerenciamento de projetos: livro-base de 
“Preparação para Certificação PMP – Project Management Professional”. 1. ed. Rio de 
Janeiro: Qualitymark, 2003.
JORDAN, Lee; tradução Edson Furmankiewicz; Carlos Schafranski. Gerenciamento 
de projetos com dotProject: guia de instalação, configuração, customização e 
administração do dotProject. Revisão técnica Diego Viegas. São Paulo: Pearson Prentice 
Hall, 2008.
HELDMAN, Kim. Gerência de projetos: guia para o exame oficial do PMI. 2. ed. Rio 
de Janeiro: Elsevier, 2005.
HOWE, D. Free on-line dictionary of computing (foldoc). Url: <htto://wombat.
doc.ic.ac.uk>. Acessado em: 20.11.2009.
LIMA, Adilson da Silva. UML 2.0 – Do requisito à solução. São Paulo: Érica, 2007.
PAULA FILHO, Wilson de Pádua. Engenharia de software – Fundamentos, Métodos 
e Padrões. 2. ed. Livros Técnicos e Científicos, 2002.
PRESSMAN, Roger. Engenharia de software. 6. ed. Editora: McGraw-Hill 
Interamericana do Brasil, 2006.
50
REFERÊNCIAS
REIS, Christian Robottom. Caracterização de um modelo de processo para 
projetos de software livre. São Paulo: USP, 2003.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. Prentice-Hall: São Paulo, 
2002.
VALERIANO, Dalton L. Gerenciamento estratégico e administração por 
projetos. 1. ed. São Paulo: Makron Books, 2001.