Processos de Desenvolvimento

do Projeto

Brasília-DF.
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
 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

4
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.

5
 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.

6
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.

7
8
 PROJETANDO UNIDADE I
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 classe a 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

9
 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

10
 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.

11
 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.

12
 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 componentes semâ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.]

13
 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.

14
 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.

15
 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.

16
 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 arquitetura do 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”.

17
 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.

18
 TESTANDO SISTEMA
E DESENVOLVENDO UNIDADE II
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).

19
 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.

20
 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.

21
 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 (Rational Unified 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:

22
 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.
23
 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.

24
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II

25
 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.

26
 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

27
 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
28
 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.

29
 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
integrados a 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.

30
 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.

31
 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.

32
 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

33
 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
sistema irá 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”.

34
TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO│UNIDADE II

35
 UNIDADE II │TESTANDO SISTEMA E DESENVOLVENDO VERSÃO PILOTO

36
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.

37
 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

38
 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.

39
 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
de desenvolvimento 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

40
 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.

41
 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 é

42
 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:

43
 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.

44
 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.

45
 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).

46
 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.

47
 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!

48
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.

49
 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.

50