Engenharia de Softwa..

+ 81% de professores mestres e doutores + Opções de cursos também aos sábados + Bolsas, Créditos e Descontos
Especialização (Lato Sensu) nas áreas de:
Ciências Biológicas, Ciências da Saúde, Ciências Jurídicas, Comunicação, Finanças Corporativas,
Gestão Empresarial e Estratégias Corporativas, Letras, Artes e Ciências da Educação e Tecnologia.
Mestrado em:
Arquitetura e Urbanismo, Ciências do Envelhecimento, Educação Física e Filosofia.
Doutorado em Educação Física
O único oferecido por uma instituição privada no Estado de São Paulo.
SEU DIPLOMA GANHA,
O MERCADO GANHA E VOCÊ
GANHA MAIS AINDA.
Butantã: Av. Vital Brasil, 1000 - Ao lado da futura estação Butantã e próxima da estação Pinheiros (CPTM).
Mooca: Rua Taquari, 546 - A poucos minutos da estação Bresser-Mooca. www.usjt.br - Tel.: 11 2799-1972

Ano 3 - 25ª Edição - 2010 Impresso no Brasil
Corpo Editorial
Colaboradores
Rodrigo Oliveira Spínola
rodrigo@sqlmagazine.com.br
Marco Antônio Pereira Araújo
Eduardo Oliveira Spínola
Capa e Diagramação
Romulo Araujo - romulo@devmedia.com.br
Coordenação Geral
Daniella Costa - daniella@devmedia.com.br
Revisor e Supervisor
Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br
Na Web
www.devmedia.com.br/esmag
Apoio
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se você tiver algum problema no recebimento do seu exemplar ou precisar de
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de
bancas de jornal, entre outros, entre em contato com:
Cristiany Queiróz– Atendimento ao Leitor
www.devmedia.com.br/mancad
(21) 2220-5338
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5338
Publicidade
Para informações sobre veiculação de anúncio na revista ou no site entre em
contato com:
Kaline Dolabella
publicidade@devmedia.com.br
Fale com o Editor!
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo
você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a
vontade para entrar em contato com os editores e dar a sua sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o título e mini-resumo do tema que você
gostaria de publicar:
Rodrigo Oliveira Spínola - Colaborador
editor@sqlmagazine.com.br
EDITORIAL
P
ode-se definir Governança em TIC como o alinhamento estratégico de TIC com
o negócio de forma que se obtenha o máximo valor deste através do desenvolvimento
e manutenção de controles efetivos de TIC orientados ao controle de
custos, gestão do retorno dos investimentos relacionados e gestão dos riscos associados
(WEILL e ROSS, 2006).
Pretendendo cumprir este objetivo, são muitos os mecanismos de relação entre os processos
de negócio e os processos de TIC que têm sido gerados pela disciplina de Governança
em TIC. O resultado final é uma infinidade de padrões e boas práticas, envolvendo: processos,
indicadores, perfis, diretrizes, dentre outros, cuja aplicação geralmente exige muito
investimento, tempo e esforço, em função do formalismo adotado por estes padrões.
No artigo IT Governance: Reviewing 17 IT Governance Tools and Analysing the Case
of Novozymes A/S , Holm et al. apresentam uma síntese das intenções de melhoria da
relação entre a TIC e o negócio mediante a classificação de 17 padrões e ferramentas de
melhores práticas existentes em termos de variáveis, como: tipo de processo e organização.
O trabalho citado aborda a investigação de como a Governança em TIC é adotada
no caso de uma companhia líder no mercado mundial de biotecnologia em enzimas e
micro-organismos industriais. Neste processo é realizada a revisão de 17 ferramentas de
Governança em TIC.
Neste contexto, a Engenharia de Software Magazine destaca nesta edição um artigo
muito interessante sobre governança em tecnologia de informação. O objetivo do artigo
não é discutir em detalhes os êxitos ou melhorias que estas ferramentas têm alcançado
(em especial ITIL e COBIT) para os processos de suporte ao core business de nossas organizações.
O artigo objetiva apresentar uma revisão sistemática a respeito de nove modelos
de governança em TIC, procurando permitir ao leitor a criação de uma visão crítica
a respeito do corpo de conhecimento de governança em TIC – ICTGBOK, suas principais
características, carências e limitações. Ao final, identifica o surgimento de um novo paradigma:
Governança Ágil em TIC, que se propõe a sanar as limitações existentes.
Além desta matéria, esta edição traz mais seis artigos:
• Natureza do Software e a Necessidade de Princípios e Processo
• Engenharia de sistemas orientada ao conhecimento
• Ferramentas para Gerência de Projetos
• Reportando de forma simples os resultados dos testes
• Teste unitário e de cobertura para Java Script com JsUnit e JsCovarage
• Humanos, Formigas e o Trabalho em Equipe
Desejamos uma ótima leitura!
Equipe Editorial Engenharia de Software Magazine
Rodrigo Oliveira Spínola
rodrigo@sqlmagazine.com.br
Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação
(UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo ministrado
cursos na área de Qualidade de Produtos e Processos de Software, Requisitos e
Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS.BR. Atua
como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/
UFRJ. É Colaborador da Engenharia de Software Magazine.
Marco Antônio Pereira Araújo - Editor
(maraujo@devmedia.com.br)
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Linha
de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos
Computacionais e Bacharel em Matemática com Habilitação em Informática pela
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em
Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Curso
Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação
Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora,
Colaborador da Engenharia de Software Magazine.
Eduardo Oliveira Spínola
(eduspinola@gmail.com)
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine.
É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS)
onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia
de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).

Caro Leitor
Caro Leitor,
Para esta edição, temos um conjunto de 4 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da Engenharia
de Software Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de aulas
publicadas pode ser vista abaixo:
Tipo: Validação, Verificação & Teste
Título: Teste de Interface
Autor: Arilo Claudio Dias Neto
Mini-Resumo: Esta vídeo aula aborda a aplicação de testes de interface (ou teste
GUI), apresentando sua definição, desafios, estratégias, aplicabilidade e os elementos
que compõem o teste de interface. Ao final, é apresentado um exemplo de teste de
interface aplicado em uma aplicação do SO Windows.
Tipo: Validação, Verificação & Teste
Título: Automação de Testes
Autor: Arilo Claudio Dias Neto
Mini-Resumo: Esta vídeo aula aborda o tema de automação dos testes, apresentando
os diferentes tipos de estratégias de automação, decisões a serem tomadas
para automatizar o processo de testes, a importância da automação para o sucesso
dos testes e um exemplo de cenário de testes automatizado.
ÍNDICE
Por trás do obvio
05 - Humanos, Formigas e o Trabalho em Equipe
Engenharia
06 - Natureza do software e a necessidade de princípios e processo
14 - Engenharia de sistemas orientada ao conhecimento
Agilidade
21 - Da Gestão à Governança em Tecnologia da Informação e Comunicação – TIC
Planejamento e Gerência
32 - Ferramentas para Gerência de Projetos
Desenvolvimento
40 - Reportando de forma simples os resultados dos testes
49 - Teste unitário e de cobertura para Java Script com JsUnit e JsCovarage
4 Engenharia de Software Magazine
Tipo: Validação, Verificação & Teste
Título: Teste Baseado em Modelos - Definições e Conceitos - Parte 1
Autor: Arilo Claudio Dias Neto
Mini-Resumo: Esta vídeo aula aborda o tema de testes baseado em modelos,
apresentando o processo de teste baseado em modelos, técnicas de teste baseado
em modelos, sua aplicabilidade em um projeto de software e a integração entre teste
baseado em modelos e os diagramas UML.
Tipo: Validação, Verificação & Teste
Título: Teste Baseado em Modelos - Exemplo de Técnica: TDE - Parte 2
Autor: Arilo Claudio Dias Neto
Mini-Resumo: Esta vídeo-aula dá continuidade à aula anterior, apresentando um
exemplo de técnica de teste baseado em modelos que utiliza diagramas UML para
viabilizar a geração de casos de teste. Esta técnica será apresentada através de uma
aplicação de exemplo.
Glênio Cabral
Antonio Mendes da Silva Filho
Viviane Schneider e Ivan Correia Filagrana
Alexandre José de Oliveira, Cleyverson Pereira Costa e Hermano Perrelli de Moura
Marco Antônio Pereira Araújo , Patrícia Lima Quintão e Jurema Florinda Lembe de Veiga
Daniel Scaldaferri Lages
Jenifer Vieira Toledo, Elessandro Rodrigues Marques, Marcelo Santos Daibert e Marco Antônio Pereira Araújo

Pos trás do Óbvio
Glênio Cabral
gleniocabral@yahoo.com.br
É Administrador de Empresas, pós-graduado em Gestão de Pessoas
e músico.
Todos nós concordamos que o trabalho em equipe é
fundamental para o desenvolvimento de qualquer
organização. Através da união de competências e
habilidades, a diversidade é direcionada para um objetivo
comum: o progresso do todo. O problema é que para muitos
de nós, seres humanos, trabalhar em equipe é um processo
complexo e penoso.
As formigas, no entanto, não agem dessa forma. Cada formiga
tem um papel muito bem definido no seu formigueiro, e
através de um excepcional trabalho em conjunto elas realizam
atividades complexas como estocagem de alimentos, controle
de natalidade e expansão territorial. Observar o comportamento
desses insetos faz o trabalho em equipe parecer a coisa
mais simples e previsível do mundo. Como insetos irracionais
conseguem tamanha proeza?
Talvez uma possível explicação seja o fato de que as formigas
não têm aspirações individuais. Formigas são seres desprovidos
de vaidades e sonhos, como qualquer ser irracional que
se preze. Por isso elas não sentem a menor necessidade de
serem reconhecidas por seu desempenho, nem de galgarem
andares hierárquicos no formigueiro e muito menos de se
realizarem como insetos. Não há registros de paralisações ou
de revoluções operárias entre as formigas. Já nas organizações
humanas...
Talvez uma outra possível explicação seja o fato de que esses
insetos não são vulneráveis aos ventos da desmotivação. Aliás,
Humanos, Formigas e o
Trabalho em Equipe
desmotivação é para o bicho homem, que é um ser racional e
por isso tem necessidades insaciáveis a cada estação. As formigas
são sempre ativas, pois dentro de cada uma delas arde
a chama implacável da auto-motivação gerada pela ditadura
do instinto animal e perpetuada pela mãe natureza.
Ao contrário dos animais, nós, seres humanos, evoluímos
ao longo da nossa história através das tensões e dos conflitos.
Faz parte da nossa natureza nascer incompletos e evoluir
através das turbulências. Se assim é, chegamos a uma óbvia
conclusão: há uma grande diferença entre o trabalho em equipe
realizado pelas formigas e o trabalho em equipe realizado
pelos seres humanos. No primeiro, a ausência de tensões é
fundamental para a sobrevivência da espécie. No segundo,
a ausência de conflitos é o atestado de óbito da organização.
Nas organizações humanas, os conflitos não devem deixar
de existir, mas devem ser administrados e canalizados para
a promoção do bem comum. A não ser que a sua organização
seja um formigueiro.
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Dê seu Feedback
Edição 25 - Engenharia de Software Magazine 5
sobre esta edição

Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
Natureza do Software e a Necessidade de
Princípios e Processo
Antonio Mendes da Silva Filho
antoniom.silvafilho@gmail.com
Professor e consultor em área de tecnologia
da informação e comunicação com mais
de 20 anos de experiência profissional, é
autor do livros Arquitetura de Software e
Programando com XML, ambos pela Editora
Campus/Elsevier, tem mais de 30 artigos
publicados em eventos nacionais e internacionais,
colunista para Ciência e Tecnologia
pela Revista Espaço Acadêmico com
mais de 80 artigos publicados, tendo feitos
palestras em eventos nacionais e exterior.
Foi Professor Visitante da University of
Texas at Dallas e da University of Ottawa.
Formado em Engenharia Elétrica pela Universidade
de Pernambuco, com Mestrado
em Engenharia Elétrica pela Universidade
Federal da Paraíba (Campina Grande),
Mestrado em Engenharia da Computação
pela University of Waterloo e Doutor em
Ciência da Computação pela Univesidade
Federal de Pernambuco.
Observe a Figura 1 e identifique
o que há de comum nos vários
produtos ilustrados.
Se você respondeu software, então
acertou. É isso mesmo. Software está
praticamente em todas as coisas de nosso
cotidiano, servindo às mais variadas
necessidades das pessoas. Entretanto,
você já parou para pensar como o software
é construído? O que é necessário
para obter um software?
Para construir ou desenvolver um
software, você precisa entender sua
natureza, conhecer a aplicação na qual
será usado, bem como compreender os
princípios e processo para guiar como e
quando as atividades serão realizadas,
além de definir quem vai executálas.
A leitura deste artigo lhe dará a
6 Engenharia de Software Magazine - Natureza do Software e a Necessidade de Princípios e Processo
De que se trata o artigo?
Discute a natureza do software e apresenta um
conjunto de princípios de engenharia empregados
no desenvolvimento de sistemas de software,
destacando a necessidade de um processo.
Para que serve?
Entender a natureza do software e conhecer
os princípios que fundamentam a engenharia
de software, enfatizando a importância de um
processo.
Em que situação o tema é útil?
No desenvolvimento de sistemas de software,
quando o engenheiro precisa conhecer
a natureza do produto a ser desenvolvido, e
como as atividades e princípios que norteiam
seu desenvolvimento são cruciais para a obtenção
do produto.
oportunidade de entender a natureza
do software e importância do uso de
princípios e processo no desenvolvimento
de software.
Você já percebeu que software está
praticamente em todas as coisas de seu
cotidiano?

Figura 1. Conjunto de produtos
Um exemplo disso é a central telefônica que permite às
pessoas conversarem ao telefone. O controle da operação das
centrais telefônicas é, hoje em dia, todo feito por software.
Você já foi a alguma casa lotérica para efetuar um pagamento
de conta de água ou energia? Ou já arriscou jogar na loteria?
Quando você vai a uma casa lotérica, por quaisquer um dos
motivos acima, você está usando o sistema que tem todo seu
controle feito por software e o mesmo acontece quando você
vai ao banco. Perceba que quase todos os sistemas hoje em dia
têm seu controle operacional sendo feito por software. E, com
certeza, você é usuário de computador que possui diversos
tipos de software operando nele.
Observe que o software tem se tornado um companheiro e
sido uma ferramenta fundamental de nosso dia-a-dia. Dessa
forma, as seções subsequentes do artigo apresentam a natureza
do software e princípios e processo de desenvolvimento
de software.
Natureza do software
Há aproximadamente cinco décadas atrás, software constituía
uma pequena, senão ínfima, parcela dos sistemas computacionais
quando comparado ao hardware. Naquela época,
os custos de desenvolvimento e manutenção de software eram
desprezíveis. Hoje, porém, software é responsável por significativa
porção dos sistemas computacionais. Encontramos
software nas mais diversas aplicações. No uso doméstico,
fazemos uso de processadores de texto e planilhas (como,
por exemplo, Word e Excel da Microsoft). Adicionalmente,
software tem sido um componente importante e muito utilizado
em diversos sistemas. Pode-se exemplificar seu uso no
controle e supervisão dos sistemas de geração e distribuição
de energia, bem como em sistemas de telecomunicações, onde
ele é encarregado do controle e roteamento de milhares de
ligações telefônicas.
Cabe destacar que, hoje em dia, empresas e pessoas têm
conseguido otimizar o tempo de realização de suas atividades,
geralmente, fazendo uso de sistemas computacionais, isto é,
sistemas onde o computador e, mais especificamente, o software,
é uma peça essencial.
Software compreende um conjunto de instruções que, quando
são executadas em um dispositivo, fornecem funcionalidades
a seus usuários com desempenho desejado. Todavia,
o software tem uma característica que o diferencia de outros
produtos, e especificamente do hardware. Hardware é um
artefato físico (geralmente tecnológico) como, por exemplo,
ENGENhARIA DE SoFtWARE
um aparelho de TV, um equipamento de som, um aparelho
celular ou um computador propriamente dito. No entanto, via
de regra, os equipamentos (hardware) sofrem desgaste e, como
resultado, começam a apresentar defeitos decorrentes desse
desgaste (físico) causado, por exemplo, por longo período de
uso, poeira, variações na tensão da rede elétrica e umidade.
Todos esses fatores contribuem para o desgaste do hardware,
como mostrado na Figura 2.
Figura 2. Curva de falhas de hardware
E o software? Ele sofre desgaste?
A resposta é não. Software não é uma entidade física e, portanto,
não software qualquer tipo de desgaste (físico) como
ocorre com o hardware. Observe na Figura 3 que, depois que
os defeitos decorrentes do desenvolvimento são corrigidos,
no caso ideal, não haverá mais falhas já que software não se
desgasta. Mas pode haver inserção de novos defeitos devido
às modificações no software.
Figura 3. Curva real e ideal de falhas de software
É importante você observar o comportamento da curva real
de falhas (em função do tempo) de software quando comparada
com a curva ideal de falhas de software. Por exemplo,
toda vez que uma nova funcionalidade é desejada, torna-se
necessário adicionar e/ou modificar as instruções já existentes
no software e, por conta dessas mudanças, novos defeitos
podem ser introduzidos, aumentando o número de falhas
e, portanto, podendo causar a deterioração na qualidade do
software. Então, você pode estar se perguntando: o que seria
Edição 25 - Engenharia de Software Magazine 7

necessário fazer para evitar ou, pelo menos, minimizar esse
aumento do número de falhas?
Nesse momento, antes de responder, é importante lembrar que
algo que o desenvolvimento de qualquer produto ou artefato requer
é saber quais os passos necessários para alcançar o objetivo
de ter o produto pronto (desenvolvido). E, o que seria isso?
A resposta a esta questão é engenharia e, especificamente,
neste caso, engenharia de software, tendo como premissa
assegurar a confiabilidade desejada do sistema. O leitor
pode consultar o artigo sobre confiabilidade de software no
quadro de links no final deste artigo. Contudo, observe que
o desenvolvimento de sistemas de software, similarmente a
outros sistemas (como na analogia com a construção de uma
casa), pode ser decomposto em três fases genéricas – definição,
desenvolvimento e manutenção – conforme ilustrado na
Figura 4.
Figura 4. Fases genéricas no desenvolvimento de software
A fase de definição engloba a identificação de informações
que deveriam ser processadas, funções e desempenho desejados,
tipo de interface a ser utilizada, tarefas que o sistema
deveria prover suporte, perfil de usuários do sistema, dentre
outras.
Já a fase de desenvolvimento concentra-se no projeto de
estruturas de dados e arquitetura de software do sistema
(isto é, como ele está organizado), conversão do projeto para
alguma linguagem de programação (ou seja, implementação),
realização de testes e avaliação.
Finalmente, a manutenção considera modificações e/ou
correções necessárias no sistema a fim de que este atenda
aos requisitos do sistema. Perceba que o processo de desenvolvimento
de um sistema de software tem duas grandes
atividades de interesse que envolve o desenvolvimento da
porção de software que implementa as funcionalidades do
sistema, e a atividade que a antecede e norteia o desenvolvimento,
que é o projeto de software. Essa última atividade é
resultado do levantamento e análise de requisitos que provê
informações para decisões de projeto.
De tudo o que foi discutido acima, você poderá perceber
que há um guia de desenvolvimento de software, o qual é
encarregado de:
• Definir a sequência de aplicação de métodos (em cada uma
das etapas de desenvolvimento);
• Definir os produtos (documentos ou outros artefatos) a
serem entregues;
• Estabelecer as datas de entrega (isto é, os milestones) dos
produtos ou artefatos;
• Assegura qualidade de desenvolvimento.
8 Engenharia de Software Magazine - Natureza do Software e a Necessidade de Princípios e Processo
Esse guia, que define quais atividades devem ser realizadas,
determina a sequência na qual as atividades são realizadas e
as relações entre elas, estabelece critérios para a transição entre
tarefas, compreendendo o processo de desenvolvimento de
software. Em outras palavras, o processo guia o desenvolvimento
desde sua concepção quando os clientes (ou usuários)
expressam quais funcionalidades (ou requisitos do sistema)
eles desejam até a entrega do produto final (software). Isto é
ilustrado na Figura 5.
Figura 5. Papel do processo de desenvolvimento de software
Note que o processo é parte da engenharia de software, cujo
objetivo principal é fazer uso de princípios de engenharia a fim
de produzir, a baixo custo, software que opere corretamente e
com eficiência em equipamentos (como o computador), onde
o software é instalado.
Engenharia de Software
Antigamente (isto é, cerca de quatro décadas atrás), o
desenvolvimento de software era realizado sem qualquer
planejamento, sem uso de técnicas, e podemos até dizer que
era desenvolvido por tentativa e erro. Em outras palavras, não
havia qualquer disciplina de engenharia, faltavam métodos
para o desenvolvimento e havia muitas questões que eram
feitas décadas atrás para pequenos programas (software), que
ainda podem ser feitas hoje em dia para grandes sistemas computacionais
(onde software é parte essencial). Essas questões
levantadas no livro Why Software Cost so Much? (1975) de Tom
DeMarco ainda são atuais:
• “Por que demora tanto tempo para que os programas sejam
concluídos?”
• “Por que os custos são tão elevados?”
• “Por que não descobrimos todos os erros antes de entregarmos
o software ao nosso cliente?”
• “Por que temos dificuldades em medir o progresso enquanto
o software está sendo desenvolvido?”
Responder a essas questões tem sido uma das metas da engenharia
de software a qual tem uma definição clássica dada
por Fritz Bauer em 1969, onde ele a definiu como:
“O estabelecimento e uso de sólidos princípios de engenharia para
que se possa obter economicamente um software que seja confiável e
que funcione eficientemente em máquinas reais.”
Neste momento, você deve perceber que a engenharia de
software consiste de um conjunto de técnicas que visam apoiar
as atividades de levantamento de requisitos, mas também a

análise e especificação dos requisitos do sistema de software a
ser desenvolvido. Essa documentação será então utilizada nas
etapas seguintes do desenvolvimento que engloba o projeto
de software, implementação ou codificação (isto é, a escrita do
programa), testes e manutenção de software.
Vale, contudo, ressaltar que a execução dessas atividades
ocorre de maneira disciplinada, ou seja, guiadas por um
processo (discutido adiante), além de adotar práticas de gerenciamento
de projetos que visam assegurar produtividade
e qualidade do software, bem como redução de custos de
desenvolvimento. Além disso, é necessário um processo que
serve de guia de desenvolvimento de software e:
• Define a sequência de aplicação dos métodos;
• Define os produtos (artefatos) a serem entregues;
• Busca assegurar qualidade de desenvolvimento;
• Ajuda a estabelecer marcos no cronograma (milestones) para
entrega de artefatos.
Perceba que o papel do processo é integrar o uso de métodos
e ferramentas coordenando as atividades de desenvolvimento
de software como planejado. Agora você pode concluir que a
engenharia de software é uma área onde é feita a aplicação
disciplinada e sistemática (ou seja, que considera princípios de
engenharia) para desenvolvimento e manutenção de software.
Então, o papel do engenheiro de software não se restringe a
apenas atividades de programação, mas também ele precisa
saber como conversar com o cliente (a pessoa ou empresa interessada
no software a ser desenvolvido) com o objetivo de
levantar os requisitos de software que serão depois documentados
na especificação de requisitos. E, a partir do momento
que ele estiver com a especificação em mãos, ele poderá iniciar
as atividades seguintes (projeto, implementação e testes).
E o porquê da engenharia de software ou pra que ela
serve?
A engenharia de software visa assegurar:
• A qualidade do software (produto);
• Entrega do software conforme cronograma;
• Desenvolvimento do software conforme orçamento.
Observe que o processo é um elemento essencial, pois se ele
for adequadamente seguido, a qualidade do produto poderá
ser assegurada. A qualidade do produto é determinante para
o sucesso de um software. Há vários atributos da qualidade
que servem de indicativo para aceitação e satisfação do cliente
(usuário do software). Dentre elas, podemos destacar:
• Corretude – Um software é correto se ele satisfaz os requisitos
de funcionalidades descritos na especificação.
• Confiabilidade – Um software é confiável se você pode utilizar
o software por um determinado período de tempo com
probabilidade mínima da ocorrência de falhas.
• Manutenibilidade (ou facilidade de manutenção) – Considera-se
que um software facilita a sua manutenção quando ele
é desenvolvido (ou escrito) de modo que possa evoluir para
ENGENhARIA DE SoFtWARE
atender as necessidades de mudança de requisitos do cliente.
Trata-se de um atributo importante, já que a mudança das características
de um software é algo, praticamente, inevitável.
• Eficiência – Um software é considerado eficiente quando ele
não desperdiça capacidade de memória e de processamento.
Isto é mais facilmente entendido como tempo de processamento
e de resposta de um software.
• Usabilidade – Um software provê usabilidade quando ele
é fácil de usar e de aprender a usar. Se o usuário consegue
utilizar um software sem ajuda de outras pessoas, sem um
treinamento, ou seja, se o software é intuitivo, o usuário conseguirá
utilizá-lo sem dificuldade. Em tal situação, diz-se que
a interface de usuário é amigável.
Há outros atributos da qualidade como disponibilidade,
robustez, modularidade, extensibilidade, reusabilidade. O
intuito aqui não é de apresentar todos, mas destacar aqueles
mais importantes na maioria dos sistemas de software. Adicionalmente,
cabe ainda destacar que, geralmente, podemos
afirmar que se uma especificação de requisitos de software
está correta, então ele é confiável, embora o contrário não
possa ser afirmado, pois um software ser confiável não implica
que sua especificação seja correta, conforme mostrado
na Figura 6.
Figura 6. Atributos da qualidade de software
Princípios de Engenharia
Cabe destacar ainda que a Engenharia de Software se baseia
em princípios de engenharia que são aplicados ao desenvolvimento
de software e, mais especificamente, à análise e
modelagem de sistemas. Estes princípios compreendem:
• Abstração
• Modularidade
• Generalização
• Extensibilidade
• Separação de interesses
• Antecipação de mudanças
• Modelagem (como base ao projeto)
Observe que no momento em que você precisa criar um modelo,
o que precede a essa atividade é entender o problema.
Nesse sentido, você deve entender que uma das principais
características do ser humano, quando deparado com um
problema, é buscar uma solução baseada em alguma solução
existente de problemas similares. Todavia, se nessa busca você
descobre que as soluções existentes não são suficientes para
o problema em mãos, então você procura estender algumas
dessas soluções a fim de solucionar um novo problema.
Edição 25 - Engenharia de Software Magazine 9

Adicionalmente, você (engenheiro), e também ser humano,
tem feito uso da abstração como forma de lidar com situações
de complexidade. Ao explorar a abstração, você identifica
aspectos importantes do problema (ou fenômeno que está
sendo investigado) e ignora os detalhes (na etapa inicial de
levantamento e análise de requisitos). Por exemplo, equações
de circuitos em modelos de engenharia e plantas baixas em
projetos de casas oferecem a você (projetista) modelos (semi-)
formais que lhe permite raciocinar sobre o problema em mãos.
Uma planta baixa de uma casa lhe fornece a disposição dos
cômodos da casa como: quartos, sala de estar, sala de jantar,
cozinha, etc.
Outro princípio essencial e determinante no processo de desenvolvimento
de software é a modularidade. Você, projetista,
precisa fazer uso da modularidade quando lidando com um
problema (ou sistema) grande, o qual precisa ser dividido em
partes menores de modo que permita você resolver as partes
e depois o todo.
Dentro deste contexto, note que à medida que sistemas crescem,
também cresce sua complexidade e torna-se mais difícil
satisfazer a um número cada vez maior de requisitos, muitas
vezes conflitantes. Atualmente, o paradigma de orientação a
objetos tem se mostrado como o mais adequado, comparativamente
aos demais, para ser empregado no desenvolvimento de
sistemas de software complexos e de grande porte.
É importante observar que para resolver problemas ou
implementar sistemas pequenos, nenhum princípio organizacional
(ou paradigma) é necessário. Entretanto, à medida
que os sistemas se tornam maiores e com grande número de
funcionalidades, fica muito mais difícil tratar isso numa única
lista de instruções. Daí, a necessidade de prover suporte à
modularidade. Um sistema que é composto de módulos (ou
componentes) é denominado de modular.
A modularidade também oferece suporte à separação de
interesses, ou seja, quando você (projetista) está lidando com
um componente específico, então você ignora detalhes de
outros componentes. De um modo geral, recomenda-se que os
componentes do sistema possuam baixo nível de acoplamento,
como ilustrado na Figura 7.
Figura 7. Acoplamento entre componentes
Aqui, acoplamento deve ser entendido de duas formas: primeiro
cada componente (isoladamente) deve possuir elevado
grau de acoplamento de modo a ser tratado como uma ‘unidade’.
Por outro lado, cada componente deve ter um menor grau
10 Engenharia de Software Magazine - Natureza do Software e a Necessidade de Princípios e Processo
de acoplamento (ou interação) com os outros componentes,
permitindo serem manipulados ‘quase’ separadamente.
Esses princípios discutidos acima servem para guiar você
durante o processo de desenvolvimento de um sistema. Perceba
que seu papel como engenheiro engloba compreender o problema
que você tem em mãos, analisá-lo e fazer a modelagem,
projeto, implementação e testes. Para tanto, você precisa de um
processo para guiar o desenvolvimento.
Processo de Desenvolvimento
Um aspecto importante no desenvolvimento de um sistema
de software é o contínuo feedback durante o processo. A
importância de ter um feedback (resposta e comentários) do
cliente mais cedo no desenvolvimento implica na necessidade
de fazer um protótipo. Além disso, a necessidade de melhor
planejar o desenvolvimento, fazendo um balanceamento entre
custos e benefícios. Isto requer uma avaliação preliminar se
é viável ou não desenvolver o software desejado pelo cliente.
Como consequência, você pode perceber que duas atividades
importantes são planejamento e análise de riscos, que procuram
exatamente responder a questão: é viável desenvolver
esse software?
Tudo isso visa minimizar custos e assegurar que o desenvolvimento
irá ocorrer da forma como planejada e dentro dos
prazos propostos. Agora, você poderia ainda questionar: Por
que tudo isso?
Se você for analisar cuidadosamente, você perceberá que um
processo requer feedback do cliente, pois isto reduz as chances
de problemas como, por exemplo, do projeto precisar de alterações
à medida que ele avança, além de dar maior visibilidade
do sistema. Portanto, um processo de desenvolvimento de
software é necessário, porque ele:
• Serve de guia para controlar as atividades de desenvolvimento
do sistema;
• Aloca tarefas para desenvolvedores específicos;
• Especifica quais artefatos precisam ser desenvolvidos em
cada uma das etapas de desenvolvimento;
• Oferece critérios para monitorar as atividades de um
projeto.
Para atender essas necessidades de modo mais adequado, um
processo como o RUP (Rational Unified Process), e customizações
dele, tem sido empregado em projetos de software. O RUP é
considerado como um framework ou arcabouço que serve para
gerar processos.
O RUP é um framework porque ele é configurável, ou seja,
você pode customizar ou especializar o processo para diversos
tipos de sistemas. Além disso, o RUP, como processo, agrega os
métodos empregados no desenvolvimento e também faz uso da
linguagem UML (Unified Modeling Language) para modelagem
do sistema a ser desenvolvido.
O RUP é um processo que define bem o conjunto de atividades
a serem executadas, além de informar os responsáveis
pela execução delas. Adicionalmente, o processo explicita a
ordem de execução das tarefas e se existe dependências entre

elas, informando quais os artefatos de entrada e
saída de cada tarefa. A Figura 8 mostra uma visão
geral do RUP.
Figura 8. Visão geral do RUP. (Disponível no site http://
www.wthreex.com/rup/portugues/index.htm, acessado em
abril de 2010)
Observe a parte inferior da figura. Ela informa
que o RUP é composto de quatro fases: concepção,
elaboração, construção e transição. No lado esquerdo
da figura, olhando verticalmente de cima para
baixo, há um conjunto de disciplinas, como requisitos
e implementação, que engloba atividades relacionadas.
É importante destacar que essas disciplinas
compreendem as atividades do ciclo de software,
pois elas são necessárias ao desenvolvimento de
um software. Outras disciplinas foram adicionadas,
como gerenciamento de mudanças e gerenciamento de
projeto, as quais são essenciais no desenvolvimento
de um sistema de software.
Como ressaltado acima, cada uma das disciplinas
envolve várias atividades. Por exemplo, se
considerarmos a disciplina requisitos, então nela o
desenvolvedor deve analisar o problema de um
cliente (ou seja, entender as funcionalidades que
o cliente deseja para o sistema e quais as pessoas
envolvidas) a fim de definir o escopo do sistema que
consiste definir qual o conjunto de funcionalidades
irá fazer parte do sistema. Observe que saber isso é
muito importante, pois permitirá você trabalhar e
gerenciar o escopo do sistema.
O RUP determina como o sistema deve ser desenvolvido
e, portanto, o desenvolvimento de sistema
de software seguindo o processo RUP é:
• Interativo e incremental;
• Guiado por casos de uso (ou use cases);
• Centrado na arquitetura de software.
Se você olhar na parte superior da Figura 8, então
pode observar que o RUP é composto de iterações.
Isto significa que todas as funcionalidades do sistema
não precisam ser identificadas, especificadas,
implementadas e testadas de uma única vez. O
desenvolvimento se dá de modo incremental, ou
ENGENhARIA DE SoFtWARE
seja, inicialmente, apenas as funcionalidades mais importantes são desenvolvidas
e as demais são desenvolvidas em outras iterações, incrementando
novas funcionalidades ao sistema. É como se cada iteração fosse um miniprojeto
no qual você teria de levantar e analisar requisitos, fazer o projeto,
codificar e testar. Concluída parte do sistema, uma nova iteração (ou miniprojeto)
seria feita até que todas as funcionalidades fossem implementadas.
Note também que o RUP é guiado por casos de uso (ou use case).
Um caso de uso é um modelo que define uma funcionalidade do sistema
sob a ótica de um ator, que pode ser um usuário, subsistema de software
ou algum dispositivo de hardware (ou equipamento). Um ator, na grande
maioria dos casos, será um usuário (humano) que interage com uma
funcionalidade do sistema, descrita por um caso de uso.
Um caso de uso descreve o que um usuário deve fazer para utilizar uma
funcionalidade, e como o sistema responde. Um exemplo de caso de uso é
sacar num sistema de caixa eletrônico de um banco. Para sacar, o usuário
precisa antes ter tido seu cartão do banco autenticado e, no momento
que o sistema (caixa eletrônico) solicita que o usuário informe a quantia
que ele deseja sacar, o usuário então digita o valor de saque e aguarda a
realização da operação com sucesso (caso o usuário tem saldo suficiente)
ou não (se ele não possuir saldo).
Um conjunto de casos de uso faz parte da especificação de um sistema
de software e, para tanto, você deve fazer uso de um diagrama de casos
de uso. Entretanto, a apresentação desse assunto está fora do escopo
Edição 25 - Engenharia de Software Magazine 11

deste artigo. Leitores interessados poderão encontrar material
complementar sobre documento de requisitos na edição 10 e
sobre especificação de caso de uso nas edições 11 e 23. Outras
atividades de desenvolvimento como planejamento, análise,
codificação e testes são baseadas e validadas com o modelo de
caso de uso do sistema.
Além disso, o RUP é centrado na arquitetura, o que significa
dizer que o conjunto de funcionalidades vai ditar a forma na
qual o sistema será desenvolvido e como poderá ter manutenção.
Para entender isso, vamos fazer uma analogia com a
planta baixa de uma casa que nos diz como os cômodos estão
distribuídos.
Por exemplo, você tem sala, cozinha, banheiro e três quartos.
Você, olhando uma planta baixa, pode ver como eles estão distribuídos
e, na hora de construir, você pode priorizar por construir
a cozinha, banheiro e um quarto e, só depois, construir os outros
2 quartos. Em outras palavras, a planta baixa orienta o que tem
de ser feito em termos de construção de uma casa, e a arquitetura
(de software) informa como ele deveria ser estruturado (ou organizado)
e orienta como ele deveria ser desenvolvido.
Agora, como você viu na Figura 8, o processo RUP é composto
de quatro fases: concepção, elaboração, construção e transição.
Essas fases acomodam o conjunto de disciplinas discutidas
acima. Mas, qual o objetivo de cada uma dessas fases? Para
responder a essa questão, é apresentada uma lista daquilo que
compreende cada uma delas.
Concepção
• Você estará entendendo e especificando as principais funcionalidades
do software a ser desenvolvido;
• Também, nessa fase, você deverá definir como o software deve
ser organizado (isto é, como o código deve ser estruturado);
• Você deve ainda fazer uma avaliação inicial dos riscos;
• Outra preocupação sua (supondo você como desenvolvedor)
é planejar atividades (a serem realizadas) e estimar custo de
desenvolvimento.
Elaboração
• Você deve levantar, detalhar e especificar a maioria dos
casos de uso;
• Também espera-se que você possa implementar os casos de
uso mais essenciais;
• Projetar a forma na qual o software será estruturado (isto é,
a arquitetura do sistema), buscando validá-la;
• Revisar o planejamento de atividades e estimativa dos recursos
necessários para completar o projeto.
Construção
• Esta é a fase na qual o desenvolvimento (principalmente, a
implementação) do software é feita.
• Refinar o projeto da arquitetura, adicionando detalhes e
fazendo correções.
• Nesta fase, você deve também realizar testes de software,
verificando se ele funciona da forma como foi especificado e,
então, a primeira versão (chamada de versão beta) é gerada.
12 Engenharia de Software Magazine - Natureza do Software e a Necessidade de Princípios e Processo
• Outra atividade nesta fase que você deve fazer é planejar a
implantação do sistema no ambiente do cliente (realizada na
fase de Transição).
Transição
• Nesta fase, você deve implantar o sistema no ambiente do
cliente (ou seja, o software sai do ambiente de laboratório,
onde foi desenvolvido, e é instalado no ambiente do cliente).
Isto também é denominado de evolução do produto da versão
beta para a versão final.
• É natural que possa haver alguns defeitos após a entrega
do software, e quando os usuários relatam a ocorrência de
defeitos, então essas reclamações de problemas e sugestões de
melhorias são classificadas para que defeitos sejam corrigidos
e melhorias possam ser implementadas.
• Em alguns sistemas de software, é nesta fase onde são realizados
treinamentos e assistência aos usuários.
É importante observar que o RUP é uma evolução de propostas
de modelos de desenvolvimento de software. Cabe também
destacar que, ao mesmo tempo em que o RUP procura tratar
questões pertinentes do desenvolvimento de software, ele pode
ser customizado ou configurado para atender a necessidades
específicas de um sistema de software.
Conclusão
Este artigo trata de uma visão geral da engenharia de software,
analisando a natureza do software e levantando a
necessidade de considerar princípios de engenharia e utilizar
um processo no desenvolvimento de software. O foco do artigo
recai em entender e explorar atributos essenciais da qualidade
como corretude e confiabilidade, em conjunto com os princípios
de engenharia de software. Além disso, verificou-se a
importância do processo de desenvolvimento.
Links
Processo RUP
http://www.wthreex.com/rup/portugues/index.htm
História da Indústria de Software
www.softwarehistory.org
Software Engineering Body of Knowledge
http://www.computer.org/portal/web/swebok
Creating a Software Engineering Culture
http://www.processimpact.com/articles/culture.pdf
Processo de Desenvolvimento de Software
http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software
The Nature of Software: What’s So Special About Software Engineering?
http://www.ibm.com/developerworks/rational/library/4700.html
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Dê seu Feedback
sobre esta edição

www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO
ENGENhARIA DE SoFtWARE
Modéstia à parte, sua
melhor opção para
se destacar no mercado!
A Escola Superior da Tecnologia da
Informação oferece as melhores
opções em cursos, formações,
graduações e pós-graduações para
profissionais de desenvolvimento
e programação.
São programas voltados para a
formação de profissionais de elite,
com aulas 100% práticas, corpo
docente atuante no mercado,
acesso à mais atualizada biblioteca
de TI do Rio, laboratórios equipados
com tecnologia de ponta, salas de
estudo e exames.
PÓS-GRADUAÇÃO
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
GRADUAÇÃO
Engenharia de Computação
Análise e Desenv. de Sistemas
FORMAÇÕES
Desenvolvedor Java
Desenv. Java: Sist. Distribuídos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator
SQL Server 2008
Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti r/esti
TURMAS
NO RIO DE
JANEIRO
Edição 25 - Engenharia de Software Magazine 13

Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
Engenharia de sistemas orientada ao
conhecimento
Sistemas de Gestão de Conteúdo Organizacional - Enterprise Content
Manangement (ECM)
Viviane Schneider
viviane.sch@gmail.com
Atua no ramo de gerência de informações de
projetos. Bacharel em Sistemas de Informação.
Gestora de informações de projetos.
Ivan Correia Filagrana
gc@ivanfilagrana.com.br
Atua há 17 anos com desenvolvimento de
Software, é bacharel em Ciência da Computação,
Especialista em Gerência de Projetos,
Mestrando em Engenharia de Produção, Palestrante,
Consultor, Gerente de TI.
Enterprise Content Management
(ECM), em português, Gerenciador
de Conteúdo Organizacional,
é um novo conceito de tecnologia da
informação que surge com a promessa
de suprir algumas necessidades
organizacionais que os sistemas de
gestão empresarial (Enterprise Resource
Planning – ERP), sistemas de gestão de
relacionamento com o cliente (Constumer
Relationship Manangement – CRM), sistemas
de inteligência de negócios (Business
Intelligence – BI), entre outras soluções de
software, não suprem.
Conforme Santos (2007), Enterprise
Content Management (ECM) é uma tecnologia
usada para capturar, gerenciar,
armazenar e disponibilizar conteúdo e
documentos relacionados com o processo
organizacional. Um sistema ECM
integra o gerenciamento da informação
14 Engenharia de Software Magazine - Engenharia de sistemas orientada ao conhecimento
De que se trata o artigo?
Este artigo aborda uma nova visão de desenvolvimento
de software que considera o fator humano, seus
mecanismos de processamento e armazenamento de
informações como ponto de partida para a construção
de um sistema de informação ECM. Através dos
preceitos da gestão do conhecimento, sistemas sob o
conceito ECM realizam o gerenciamento de conteúdos
estruturados (documentos digitais), semiestruturados
(URL, processos) e não estruturados (conhecimento
humano) em uma organização.
Para que serve?
Ferramentas de software sob o conceito ECM servem
para criar valor a uma organização a partir de seus
conteúdos corporativos. Entretanto, para que a ferramenta
obtenha sucesso, seu desenvolvimento deve ser
realizado concomitantemente com uma mudança de
paradigma administrativo que requer da organização
a adoção de uma cultura de gestão do conhecimento.
Em que situação o tema é útil?
Um sistema ECM é útil nas corporações que necessitam
gerenciar seu conteúdo organizacional
(documentos eletrônicos, processos e capital intelectual)
visando à tomada de decisões estratégicas
e operacionais comprovadamente bem sucedidas
em transações anteriores.

estruturada, semiestruturada e não estruturada, como documentos,
informações em qualquer formato de sistemas legados,
textos, páginas WEB, digitalizados, PDF, gráficos, vídeos,
áudio, XML, aplicações WAP, etc.
Neste contexto, ECM é um nome genérico ou o conceito de
um grupo de ferramentas desenvolvidas para possibilitar o
acesso a múltiplos tipos de repositórios de conteúdo com a
finalidade de compartilhar conhecimento independente do
tempo e espaço. A sua principal meta é promover uma organização
lógica em tempo e sequência dos processos operacionais
e estratégicos, bem como de todo o conteúdo oriundo destes,
que estão contidos em arquivos, planilhas, mídias, sites web,
sistemas, entre outros. O conceito de soluções ECM proporciona
uma nova visão na construção de sistemas de informação,
pois visa a árdua tarefa de gerenciar o conhecimento humano,
proveniente de processos de negócio e artefatos oriundos
destes processos, em uma entidade organizacional. Sob este
ponto de vista, os sistemas ECM vão ao encontro de uma nova
abordagem administrativa, que preza a inter-relação do indivíduo
com a organização para gerar valor à mesma.
Dados, Informação e Conhecimento
Dados, informação e conhecimento são elementos base que
formam a comunicação humana. Dados são fragmentos de
informação, Informação é um conjunto de dados que possuem
um significado dentro de um determinado contexto, e conhecimento,
por sua vez, é a compreensão da melhor forma de
uso dos dados e informações. Para que esses três componentes
sejam utilizados de forma otimizada, dentro de um sistema
ECM, algumas considerações são necessárias.
Em uma organização, os dados são considerados registros
estruturados de transações (Davenport, 1998). Dessa forma,
há uma necessidade de tratamento e validação dos mesmos,
tendo em vista que os dados devem ser organizados por meios
confiáveis, além de ter sua origem em fontes seguras, para que
a informação criada pelo seu agrupamento seja válida.
A importância dos dados muitas vezes supera a informação,
quando esta é inconsistente. No gerenciamento do conhecimento
o dado é fundamental para que se possa gerar mais conhecimento
(Cruz, 2007). Os dados formam a base do conhecimento,
e por este motivo devem ter uma estrutura sólida, que sustente
o mesmo. Quanto à informação, para que a mesma forneça relevante
otimização dos processos gerenciais, deve-se ter como
prioridade sua coerência, consolidação e distribuição, além de
continuamente primar pela confiabilidade de sua formação.
Utilizar os dados e informações requer conhecimento que
provém do uso inteligente dos processos organizacionais para
obter o resultado almejado. Uma informação não necessariamente
produz valor para uma organização, pois é encontrada
em praticamente toda corporação sem que produza efeitos
positivos ao setor de origem. A otimização de seu processamento
e forma de armazenamento é o que pode produzir
resultados positivos para uma organização. Portanto, a atenção
no método que processa as informações é o que produz os
melhores ganhos.
GEStão DE CoNhECIMENto
A distinção de informação e dados é sutil, pois um dado pode
ser uma informação quando possui um significado. Partindo
desta visão, qualquer dado pode se tornar uma informação,
desde que acrescente relevância dentro de uma determinada
conjuntura e possa contribuir para a criação de um novo
conhecimento. Dentro de um sistema ECM a informação possui
um ciclo de vida que parte da sua criação, passa por sua
organização, armazenamento, distribuição e utilização, até o
momento que ela perde seu valor, quando então é descartada,
finalizando desta forma o ciclo. O grande desafio das organizações
é a elaboração de métodos que retirem o máximo de
conhecimento que a informação possa oferecer.
No que se refere a este item, o conhecimento, há alguns
aspectos que devem ser analisados para desenvolver um
sistema ECM. No aspecto organizacional, a criação do conhecimento
é um processo complexo, que envolve um conjunto
de variáveis tecnológicas, estruturais e principalmente de
ordem sócio-comportamental, com implicações múltiplas
nas formas de funcionamento da corporação e nas posturas e
ações das pessoas (Holanda, 2009). Para se obter o melhor uso
do conhecimento dentro de um sistema ECM, é necessário
observar que o mesmo está intrinsecamente conectado ao
caráter humano, sendo desta forma útil a consideração dos
complexos mecanismos de construção que o formam, dentro
da mente humana, além dos aspectos inerentes à gestão do
conhecimento corporativo.
Gestão do Conhecimento
A gestão do conhecimento surge com o intuito de apresentar
uma solução de gestão mais abrangente, que considera além
de dados e informações, os mecanismos humanos de compreensão
destes elementos. Esta gestão pode possuir três pilares,
denominados os três “C’s” e que compreendem consultar,
compartilhar e colaborar. Os três pilares atuam de forma transversal,
exigindo a atuação em três dimensões: ferramentas ou
mecanismos, cultura e capital humano (Filho, 2006). Esta visão
da gestão do conhecimento surge para suprir a necessidade de
transformação de dados e informação em conhecimento relevante
para decisões estratégicas na otimização dos processos
organizacionais, sendo desta forma um estágio acima da gestão
da informação, esta que somente prevê o gerenciamento de dados
operacionais que ainda não agregam valor a determinada
situação ou à organização como um todo.
Para Takeuchi e Nonaka (2008), a gestão do conhecimento torna
possível que o conhecimento pessoal de um indivíduo possa
ser convertido em conhecimento organizacional, que permanecerá
agindo de forma produtiva na empresa, independente
da presença do indivíduo. A vivência dos colaboradores com
os processos operacionais, legais e estratégicos diários, juntamente
com as informações oriundas dos ambientes externos,
formam o conhecimento corporativo. Neste ponto a gestão do
conhecimento e seu alinhamento com a tecnologia de informação
pode promover vantagem competitiva, mesmo através das
crescentes contradições, dilemas, inconsistências e polaridades
abundantes numa organização do mundo moderno.
Edição 25 - Engenharia de Software Magazine 15

A organização deve manter, segundo os preceitos da gestão
do conhecimento, duas visões opostas e ao mesmo tempo usálas
para encontrar o melhor caminho. Neste sentido a gestão
do conhecimento ocorre através do conflito, com o chamado
raciocínio dialético. O ponto inicial deste raciocínio é a tese de
um processo organizacional. Esta tese, que pode ser formulada
por um ou mais indivíduos, é negada com a apresentação de
uma antítese. Desta dialética ocorre uma síntese, formulada
com base nos preceitos da tese e antítese. O resultado desta
síntese é uma nova tese de um processo. Com o tempo poderá
haver a necessidade de aperfeiçoamento do processo (surgido
da síntese), devido às pressões internas e externas sofridas
pela organização. Esta tese de processo pode então se tornar
a antítese de um processo atualizado, o que promoverá um
novo movimento dialético de modo espiralado, conforme
demonstrado na Figura 1.
Síntese 3
Antítese
5
Tese 7
Tese 1 Antítese 2
Síntese 6
Tese 4
Figura 1. Espiral Tese – Antítese – Síntese (Fonte: Adaptado de Takeuchi e
Nonaka, 2008)
Com isso se conclui que o conhecimento organizacional
pode ter sua origem nos indivíduos que se contradizem, criam
dilemas, promovem inconsistências e polaridades. Na gestão
do conhecimento a utilização do espiral tese-antítese-síntese
busca converter o conhecimento subjetivo em um conhecimento
consistente e coerente com as várias perspectivas dos
indivíduos referente a um processo, sempre com o intuito de
enriquecer seu mecanismo. Esta transformação do conhecimento
tácito (conhecimento subjetivo) em conhecimento
explícito (conhecimento registrado formalmente) é um dos
alicerces da gestão do conhecimento e uma das técnicas de
criação do conhecimento corporativo.
O método de aperfeiçoamento do conhecimento humano que
possui o intuito de otimizar a gestão organizacional pode ser
automatizado com o uso de ferramentas de software com conceito
ECM. Um sistema ECM pode armazenar, editar e difundir
por toda organização este conhecimento corporativo para
promover sua adaptabilidade aos novos desafios do mercado.
Em um sistema ECM, estes procedimentos são obtidos através
de módulos que suportam o compartilhamento de informações
e permitem sua edição de forma colaborativa.
O desenvolvimento de estratégias organizacionais que possibilitem
a geração de conhecimento espontâneo é algo essencial
na gestão do conhecimento, pois a troca de experiências pode
acarretar na descoberta de caminhos que promovam soluções
para os percalços que as organizações enfrentam no mundo
16 Engenharia de Software Magazine - Engenharia de sistemas orientada ao conhecimento
pós-moderno, sendo o papel de um sistema ECM o de tutor
deste conhecimento.
O ser humano, através do acúmulo e compartilhamento de
conhecimento, foi e é capaz de lidar cada vez melhor com os
percalços do seu meio, transformando sua própria natureza,
criando novas formas de aumentar sua perspectiva de vida
através das descobertas científicas e tecnológicas. O conceito
de um sistema ECM busca justamente a mesma analogia do
sucesso humano, através da criação de procedimentos para
armazenagem, edição e compartilhamento de conhecimentos
que conduzam ao alcance dos objetivos organizacionais. A
gestão do conhecimento realizada através de um sistema ECM
pode colocar uma organização um passo a frente de seus concorrentes,
pois torna possível o armazenamento e socialização
de experiências bem sucedidas, além de seu constante aperfeiçoamento
alinhado com as transformações dos tempos.
Para que a gestão do conhecimento aconteça efetivamente,
a troca de conhecimento deve ser estimulada pelo líder da
organização através da criação de ambientes virtuais (sistema
ECM) e não virtuais (reuniões, ou mesmo conversas informais),
criando assim um terreno fértil para germinação do conhecimento
através da introdução de uma cultura de socialização
de ideias. Dessa forma, as organizações tornarão produtivos
os conhecimentos e terão suporte para enfrentar o desafio de
criar mecanismos que permitam sua evolução.
Engenharia de sistemas baseada no conhecimento
Para desenvolver ferramentas computacionais tendo como
base o conhecimento, novas visões e métodos de engenharia
devem ser adotados com o intuito de favorecer seu conceito
de gestão do conhecimento. Para nortear o desenvolvimento
destes sistemas a modelagem pode partir do foco principal do
negócio, tendo em vista a metodologia de organização humana
dos conteúdos de conhecimento que conduzem o indivíduo ao
alcance de seus objetivos. Assim, os mecanismos de organização
do conhecimento inerentes aos indivíduos da corporação
é o que determinará a engenharia de produção do software.
Esta abordagem coloca a relação cognitiva do indivíduo com
os processos e conteúdos organizacionais como ponto principal
de pesquisa dos requisitos funcionais e não funcionais do
negócio, que modelarão um sistema ECM.
Neste contexto, sistemas sob o conceito ECM devem ser
considerados peritos no gerenciamento do conteúdo específico
de um negócio. Peritos possuem mecanismos estratégicos de
ação muito mais eficazes que principiantes. Para Atkinson
(2002), peritos e principiantes resolvem problemas de maneira
qualitativamente diferente, pois o conhecimento de principiantes
é superficial e não possui planos de ação, enquanto o
conhecimento especializado possui um número muito maior
de representações baseadas em princípios, planejamento antes
da ação, partindo do objetivo para as metas de alcance deste.
O Perito traça uma meta e depois a divide em submetas para
facilitar a identificação de cada ação necessária para o alcance
do objetivo, sendo que cada ação é planejada antes de ser
realizada. Este conceito de funcionamento do conhecimento

humano especializado permite a construção de sistemas ECM
que processam informações complexas, porém apresentam
resultados simplificados, que acrescentam valor para ações
estratégicas e operacionais de uma organização.
Segundo a autora: a analogia entre computadores e mentes
humanas continua sendo atraente porque estes dois tipos de
entidades são os sistemas de processamento de informações
mais complexo que conhecemos. Além disso, à medida que
os cientistas computacionais continuam a projetar computadores
para funcionar como pessoas, a analogia entre mente e
computador irá tornar-se ainda mais forte.
Com base nestas considerações, um sistema ECM deve promover
familiaridade com os processos internos da mente dos
usuários através de sua interface propícia e busca de conteúdo
compatível com esta analogia. Porém, compreender os difíceis
mecanismos que formam o conhecimento não é tarefa trivial,
pois exige um estudo aprofundado que conduza a compreensão
dos processos de cognição que constituem a mente humana.
Apesar disso, este entendimento é de suma importância para
a criação de tecnologias de informação análogas aos processos
de formação de conhecimento.
Para Davenport (1998), o conhecimento é uma mistura de
experiência sucinta, valores, informação contextual e insight
experimentado, a qual proporciona uma estrutura para a
avaliação e incorporação de novas experiências e informações.
O conhecimento tem origem e é aplicado na mente dos
conhecedores, pois toda experiência que forma o conhecimento
pressupõe um experimentador que a vivencia. Sendo assim,
é no indivíduo que se encontra a metodologia adequada de
formação e recepção do conhecimento, pois é através das pessoas
e da sua interação com o ambiente organizacional que o
conhecimento corporativo é produzido. Importante observar
que os valores e as crenças das pessoas também exercem forte
impacto sobre a formação do conhecimento humano.
A mente humana é um sistema de órgãos de computação,
com componentes especializados, que, segundo Pinker (1998),
foi projetado pela seleção natural para resolver os tipos de
problemas que nossos ancestrais enfrentavam. Em especial,
entender e superar em estratégia os objetos, animais, plantas
e outras pessoas. A inteligência, que cria o conhecimento,
consiste na especificação de um objetivo, posterior avaliação
da situação vigente, com o intuito de conhecer como ela
difere deste objetivo, para só então por em prática uma série
de processos para reduzir a discrepância entre o objetivo e a
situação presente, sendo que tudo deve ocorrer em sintonia
com as crenças e valores do indivíduo.
Com isso é possível constatar uma “pista” para a revelação
do funcionamento da mente, quando se percebe que o conhecimento
é envolvido ao longo dos pesos de suas conexões de
pensamentos, símbolos e estereótipos, ligando a camada de
perguntas com a camada das respostas, ao invés de ser armazenado
em um banco de dados que pode ser acessado por
diferentes processos de recuperação. Neste sentido o conhecimento
produz valor se focado em um determinado objetivo,
pois o mesmo possui um modelo com estrutura inata, sendo
GEStão DE CoNhECIMENto
talhado para uma meta específica. Desta forma, sistemas ECM
podem possuir algoritmos de busca de conteúdo que partam
de princípios de indexação de objetivos específicos, em vez de
indexação de dados sem direcionamento.
O conhecimento humano formou-se ao longo de séculos
de soluções de problemas através de tentativas e erros, ou
pela ordem superior de raciocínio criado por gênios raros em
nossa cultura. As pessoas formam este conhecimento através
da imensa quantidade de treinamento social que recebem
ao juntar palavras e sentenças de forma a conduzir a solução
adaptativa de obstáculos ao objetivo (Pinker, 1998). Nesta
perspectiva os sistemas ECM podem ser desenvolvidos com
base em uma analogia com o sistema humano de conservação
e recuperação de conhecimento, que preservam seus conteúdos
de forma não aleatória. Um sistema ECM, em vez de se tornar
um repositório de dados, é construído de forma que sua base
consiga identificar o local onde o conteúdo armazenado possa
ser editado, levando em consideração sua posição dentro dos
procedimentos descritos de forma algorítmica estruturada
para a obtenção de um objetivo. Este objetivo generalizado
poderá ser desde um simples procedimento, até um objetivo
mais amplo da organização. Assim, um sistema ECM obterá
uma gama imensa de dados indexados por seus respectivos
objetivos, que formarão o conhecimento que visa diversos
outros objetivos, que por sua vez tencionam alcançar o objetivo
primordial de uma corporação, o sucesso da mesma.
Sob este ponto de vista, um modelo de sistemas de informação
ECM, baseado nas estruturas humanas de formação do conhecimento,
é composto por um elemento primordial que molda
e conduz os processos que impelem a ação, o objetivo (Hall,
2000). Neste contexto, o objetivo de um processo organizacional
será o nó indexador dos conteúdos corporativos (documentos
e ações) geridos por um sistema de software ECM.
Para que um sistema ECM possa suportar a imensa quantidade
de informações e transformá-las em conhecimento
válido para uma organização, alguns aspectos da formação do
conhecimento humano devem receber o devido estudo e aprofundamento.
Neste ponto o indivíduo recebe importância no
sentido de fornecer os aspectos que produzirão a metodologia
para construção de um sistema de informação ECM.
O mecanismo de formação do conhecimento humano parte
do indivíduo, que deseja solucionar determinado problema.
Para alcançar tal objetivo o sujeito simboliza o contexto da
meta de alcance e a situação presente, justamente para identificar
a discrepância entre ambas. Depois de assimilar essa
inconsistência ele formula estratégias de ajustes que irão
nivelar as duas situações. Após o cumprimento desta ação,
todo esse mecanismo é registrado através da memória. O
registro em memória é fator essencial para preservação deste
conhecimento específico, que será novamente utilizado em
situações semelhantes no futuro. Um indivíduo pode formular
várias estratégias para alcançar um mesmo objetivo, porém
ele escolherá apenas a estratégia que melhor se enquadra nas
suas prioridades de crenças e valores. Supõe-se então que cada
indivíduo possui uma estratégia eficaz, e vários indivíduos, no
Edição 25 - Engenharia de Software Magazine 17

caso de uma organização, possuem várias estratégias eficazes
para um mesmo objetivo. Para que a identificação da melhor
estratégia aconteça, é essencial haver, entre os membros da
organização, a socialização destes conhecimentos.
Assim, para alcançar um objetivo os indivíduos definem
uma meta principal, que compreende o caminho total a ser
percorrido até o seu alcance, e para que o caminho seja mais
fácil de ser cursado ele é subdividido em pequenas partes
(submetas). Esta descrição está exemplificada na Figura 2, onde
um indivíduo divide o caminho a ser percorrido pelo balão em
submetas, com o intuito de traçar todos os pontos que deverá
voar até alcançar seu objetivo. Ao lado da abstração da vida real
é exemplificada uma analogia computacional para um sistema
ECM especializado, baseado nos mecanismos humanos de
formação e preservação do conhecimento.
Figura 2. Modelo abstração vida real & abstração sistema ECM
(Fonte: Modelo dos autores inspirado nas teorias de Atkinson (2002),
Pinker (1988) e Hall (2000))
A implementação de sistemas ECM deve seguir os preceitos
básicos de gestão do conhecimento, e no caso de sistemas ECM
especializados, alguns conceitos característicos da especialização
do conhecimento humano. O conhecimento tácito, que possui
papel de destaque em um sistema ECM, deve ser registrado
de forma que possa ser editado até se tornar um consenso entre
os operantes do processo. Para tanto, é necessária a existência
de campos tipo Texto que permitam a edição destes conteúdos,
conforme demonstrado no campo conhecimento tácito, apresentado
na Figura 3, que se refere à tela de ETAPA no sistema
ECM. Esses campos são locais onde os usuários que realizam
determinadas ações possam indicar suas percepções acerca
do sucesso de um procedimento, e estas percepções possam
ser atualizadas sempre que necessário, favorecendo assim a
preservação e aperfeiçoamento do conhecimento tácito que
se transforma, dentro de um sistema ECM, em conhecimento
explícito. Estes campos, análogos aos processos humanos de
18 Engenharia de Software Magazine - Engenharia de sistemas orientada ao conhecimento
formação do conhecimento, podem ser editados até que os
colaboradores, que executam estes procedimentos, cheguem
a um consenso de aprovação de seu conteúdo, que, dentro de
um sistema ECM se tornará um conhecimento explícito (ver
espiral tese-antítese-síntese na Figura 1). A Figura 3 representa
a entidade ETAPA visualizada na Figura 2 na abstração do
sistema ECM. Esta entidade é a abstração que efetivamente
armazena o conteúdo do negócio, o descreve, preserva e permite
a edição do conhecimento a ele relacionado.
Importante salientar que cada etapa deve comportar somente
um anexo de conteúdo explícito (documentos, mídias, planilhas,
imagens, etc.) para facilitar a descrição dos processos
do negócio a ele relacionado, além de permitir que o sistema
funcione sob um conceito que concatene os preceitos de sistemas
GED (Gerenciador Eletrônico de Documentos) e Workflow
(Sistema de Gerenciamento de Processo) aliado à gestão do
conhecimento (Cruz, 2007).
Cada etapa referencia uma ação que deve ser realizada
pela pessoa responsável (ver campo responsável na Figura 3)
para que o objetivo do negócio específico seja alcançado. O
desenvolvimento de softwares que gerenciam conhecimento
busca a concretização de um formato sistêmico e coeso com a
realidade do negócio, tendo em vista os processos e fontes de
onde surge o conhecimento.
Modelagem de software sob o conceito ECM
A escolha da UML para modelar um sistema ECM especialista
pode ser a mais adequada, pois conforme Booch (2005),
modelos explícitos elaborados com uso de UML facilitam a
comunicação e a compreensão para o desenvolvedor. A UML
é uma linguagem para especificação de software que possui
um vocabulário escrito através de símbolos e regras para sua
combinação, totalmente focada na comunicação de uma representação
conceitual e física de um software complexo. Desta
forma, sistemas de informação implementados com base nos
conceitos ECM podem fazer uso de métodos e tecnologias que
promovam a construção de modelos precisos, desprovidos de
ambiguidades e que sejam completos.
Para Booch (2005), a utilização das cinco visões interconectadas
através da visão de caso de uso é válida para compreensão
do desenvolvimento de um sistema. As cinco visões correspondem
a: visão de lógica, visão de implementação, visão de
interação, visão de implantação, onde todas as visões estão
integradas pela visão de caso de uso. Cada visão constitui uma
projeção na organização da estrutura do sistema, conforme
apresentado na Figura 4.
Na Figura 4 é possível observar que cada visão produz diagramas
que são a captura da abstração de alto nível do sistema.
Neste contexto são utilizados os diagramas de objetos, onde é
demonstrado um conjunto de objetos com seus respectivos relacionamentos;
diagramas de classes, que mostra um conjunto
de classes, interfaces e suas respectivas interações; diagrama de
pacotes, que demonstra de forma estrutural a organização do
modelo em pacotes; e diagrama de componentes, que apresenta
de maneira espacial as partes internas interconectadas. Vale

Figura 3. Tela de etapa de um sistema ECM especializado (Fonte: Protótipo Sistema ECM Projeto)
ressaltar que quando um componente é instanciado as cópias
de suas partes internas também são.
Outros diagramas que podem favorecer o desenvolvimento de
sistemas baseados nos conceitos ECM são os diagramas de caso
de uso, que demonstram um conjunto de casos de uso e seus
respectivos atores; diagrama de atividades, que constitui um
digrama comportamental que mostra um processo com ênfase
no fluxo de uma atividade para outra; e diagrama de implantação,
cujo objetivo é demonstrar as relações entre conjuntos de
nós, artefatos, classes manifestadas e componentes. As visões de
desenvolvimento, demonstradas na Figura 4, permitem que se
observe um sistema ECM a partir de perspectivas operacionais e
estratégicas. Estas visões de desenvolvimento também permitem
que engenheiros, analistas e usuários finais compreendam a integração
dos diversos módulos que formam um sistema ECM.
Figura 4. Modelagem da arquitetura de um sistema ECM
(Fonte: Adaptado de Booch (2005))
GEStão DE CoNhECIMENto
Conforme Bezerra (2007) e Teorey (2007), a UML 2.0 proporciona
a utilização das melhores práticas de modelagem
de sistemas, fundamentadas em estudos realizados por especialistas
que criaram uma linguagem de modelagem que
pudesse ser usada por humanos e máquinas, além de que o
desenvolvimento de um software, utilizando o paradigma de
orientação a objetos, permite a visualização do sistema como
um conjunto de atores que se relacionam, chamados objetos.
Essa visualização é válida por permitir abstrações de modelos
de funcionalidades de negócios, bem como funcionalidades
de sistemas, condizentes com a realidade percebida por seres
humanos no mundo real. Neste paradigma, os objetos realizam
tarefas específicas interagindo entre si, sendo que cada objeto
possui características próprias (atributos) e capacidades de
realizar determinadas tarefas (métodos).
Para Silva (2007), o processo de desenvolvimento de um software
é um conjunto de soluções adotadas por um grupo para criar uma
solução de automação, sendo que o autor divide o ciclo de vida do
sistema em análise, projeto, implementação e testes, onde todo o
processo é norteado pelo paradigma de orientação a objetos.
Baseado nestes conceitos, o desenvolvimento de um sistema
ECM pode seguir os passos descritos na Tabela 1.
Etapas de
Visões do Projeto Diagramas
Desenvolvimento
Análise Visão de Caso de Uso Diagrama de Caso de Uso
Projeto Visão de Lógica, Visão de
Diagramas de Objetos, Classes e
Processo
Atividades
Implementação Visão de Implementação Diagramas de Componentes e Pacotes
Finalizações e Testes Visão de Implantação Diagramas de Interações
tabela 1. Etapas de desenvolvimento de ferramentas ECM
(Fonte: Elaborado pelos autores, com base nas interpretações da UML 2.0
de Bezerra (2007), Silva (2007), e Teorey (2007))
Edição 25 - Engenharia de Software Magazine 19

Segue abaixo o detalhamento de cada etapa de desenvolvimento
de um sistema ECM, conforme descrito na Tabela 1:
• Análise: nessa etapa são descritos os requisitos do negócio
considerando as necessidades do usuário e compreensão dos
desenvolvedores do software ECM. Para auxiliar na visualização
das funcionalidades do sistema ECM, modelos de caso
de uso podem ser utilizados para demonstrações de funções
como cadastros e busca de informações. Em um sistema ECM
estes modelos também podem demonstrar abstrações que permitam
a visualização do compartilhamento de informações em
grupo e envio e recebimento de ações previamente moldadas
pelo conhecimento de processos anteriores. Modelos de casos
de uso são informações essenciais para atividades de análise,
design e testes em um projeto de software e, no caso do desenvolvimento
de sistemas ECM, podem também possibilitar
uma reorganização dos processos do negócio. A implantação
de uma cultura baseada nos preceitos da gestão do conhecimento
pode acontecer justamente nesta primeira etapa, onde
os processos do negócio são reformulados respectivamente
com o planejamento de construção do sistema ECM;
• Projeto: essa etapa constitui a concepção dos diagramas
de classe, na visão de lógica, e os diagramas de atividades
numa visão de processo. Ambas as visões são utilizadas para
desenhar o sistema ainda independente da linguagem de
implementação. Importante observar que o sucesso de um
projeto de software ECM depende concomitantemente da
correta análise dos requisitos do negócio e de um estudo de
formação do conhecimento humano, sob a perspectiva de uma
determinada organização;
• Implementação: essa etapa ocorre após os modelos do projeto
estarem suficientemente refinados. A representação das abstrações
é desenhada utilizando-se diagramas de componentes
e pacotes, através da visão de implementação, que considera a
linguagem de programação orientada a objetos;
• Finalizações e Testes: nessa etapa são descritos os diagramas
de interações, e sua arquitetura é definida dentro de uma visão
de implantação. Os testes são realizados e o sistema pode
finalmente ser implantado.
Ao todo são implementados sete diagramas, sendo eles: diagramas
de caso de uso, diagramas de objetos, diagramas de
classes, diagramas de atividades, diagramas de componentes,
diagramas de pacotes e diagramas de interações.
Conclusões
O aumento exponencial de informações a disposição de todos
aconteceu repentinamente, expondo dessa forma o ambiente
corporativo a falhas e a inabilidade de lidar com tal fato. Os
formatos de gestão organizacional que norteavam a construção
de sistemas de informação já não são mais suficientes
para garantir o efetivo gerenciamento de processos de uma
organização. As novas abordagens de gestão, como a gestão
do conhecimento, podem ser um caminho que conduza as
organizações ao efetivo gerenciamento do aparato de conteúdo
corporativo.
20 Engenharia de Software Magazine - Engenharia de sistemas orientada ao conhecimento
Neste contexto, a implementação de soluções de software ECM
baseado no conhecimento humano pretende potencializar a
aquisição, o armazenamento e a disseminação do conhecimento
dentro das organizações, o que promoverá o alinhamento da
tecnologia de informação com os preceitos da gestão do conhecimento.
Esta nova abordagem de engenharia de sistemas
poderá ser uma alternativa às metodologias de engenharia
vigentes, pois busca colocar uma organização em sintonia com
a realidade vivenciada pelo mundo, que sofre um processo veloz
de profunda transformação em todos os campos.
Links
Palestra “O Papel da Tecnologia da Informação na Gestão do Conhecimento” escrito
por Ivan Correia Filagrana
http://gc.ivanfilagrana.com.br/wp-content/uploads/2009/11/Palestra-Sinergia-Gestao-do-
Conhecimento.pdf
Referências
ATKINSON, Rita L; ATKINSON, Richard C.; SMITH, Edward E.; BEM, Dary J.; NOLEN-HOEKSEMA,
Susan e SMITH, Carolyn D. Introdução à psicologia de Hilgard. Tradução de Daniel Bueno. 13ed.
Porto Alegre: Artmed, 2002.
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar; Tradução de Fábio Freitas da Silva e Cristina
de Amorim Machado. UML: guia do usuário. Rio de Janeiro: Elsevier, 2005.
CRUZ, Tadel. Gerência do Conhecimento. 2.ed. Rio de Janeiro: E-papers, 2007.
DAVENPORT, Thomas H.; PRUSAK, Laurence. Conhecimento empresarial: como as organizações
gerenciam o seu capital intelectual. Tradução Lenke Peres. Rio de Janeiro: Campus, 1998
FILHO, Antônio Mendes Da Silva. Os Três Pilares da Gestão do Conhecimento. (Artigo Revista
Espaço Acadêmico, nº 58, Março de 2006 – ISSN 1519.6186). Consulta em 08/02/2010 no
site:.
HALL, Calvin S.; LINDZEY, Gardner; CAMPBELL, John B. Teorias da personalidade. 4 ed. Porto
Alegre: Artmed, 2000.
HOLANDA, Lucyanno Moreira Cardoso; FRANCISCO, Antonio Carlos de; KOVALESKI, João Luiz.
A percepção dos alunos do mestrado em engenharia de produção sobre a existência de
ambientes de criação do conhecimento. Ci. Inf., Brasília, v. 38, n. 2, p. 96-109, maio/ago. 2009.
(Artigo científico) Consulta em 10/02/2010 no site:
PINKER, Steven. Como a mente funciona. Tradução Laura Teixeira Motta. São Paulo: Companhia
da Letras, 1998.
SILVA, Ricardo Pereira. UML: Modelagem Orientada a Objetos. Florianópolis: Visual Books, 2007.
TAKEUCHI, Hirotaka; NONAKA, Ikujiro; tradução Ana Thorell. Gestão do Conhecimento. Porto
Alegre: Bookman, 2008.
TEOREY, Toby J; LIGHTSTONE, Sam; NADEAU, Tom. Projeto e modelagem de banco de dados.
Tradução de Daniel Vieira. Rio de Janeiro: Elsevier, 2007.
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Dê seu Feedback
sobre esta edição

Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
Da Gestão à Governança em Tecnologia da
Informação e Comunicação – TIC
Uma Visão Crítica
Alexandre José de Oliveira
ajhol@cin.ufpe.br
alexluna@mangve.org
Doutorando em Ciência da Computação pelo CIn-
UFPE em Governança em TIC (em andamento).
Mestre em Ciência da Computação pelo CIn-UFPE
em Gerenciamento de Projetos (2009). MBA em
Gestão Estratégica de TIC, FACIPE (2003). Engenheiro
Químico pela UFPE (2001). É Analista Consultor
da ATI-PE, Gestor de Infraestrutura de TIC da
Secretaria Estadual de Educação e Pesquisador do
NUTES-HC-UFPE e GP2-CIn-UFPE.
Cleyverson Pereira Costa
cpc@cin.ufpe.br
Mestre em Ciência da Computação pelo CIn-UFPE
(2009). Especialista em Engenharia de Software
com Ênfase em Teste de Software pelo CIn-UFPE
(2007). Graduado em Ciência da Computação
(2005). Pesquisador do GP2-CIn-UFPE. Possui experiência
na área de testes, tendo atuado como Engenheiro
de Testes pelo Motorola Brazil Test Center.
Hermano Perrelli de Moura
hermano@cin.ufpe.br
Possui graduação em Engenharia Eletrônica pela Universidade
Federal de Pernambuco (1982), Mestrado
em Informática pela Universidade Federal de Pernambuco
(1989) e PhD in Computing Science pela University
of Glasgow (1993). É certificado PMP (2003) pelo
Project Management Institute. Atualmente é Professor
Adjunto e Vice-Diretor do Centro de Informática da
Universidade Federal de Pernambuco.
De que se trata o artigo?
Este artigo tem por objetivo apresentar uma revisão
sistemática a respeito de nove modelos de
governança em TIC, procurando permitir ao leitor
a criação de uma visão crítica a respeito do corpo
de conhecimento de governança em TIC – ICTG-
BOK, suas principais características, carências e limitações.
Ao final, identifica o surgimento de um
novo paradigma: Governança Ágil em TIC, que se
propõe a sanar as limitações existentes.
Para que serve?
A Governança em TIC está se tornando o meio através
do qual a TIC está assumindo o seu papel estratégico
nas organizações, através do alinhamento
das iniciativas de TIC e dos objetivos estratégicos
do negócio das organizações. Outro aspecto que
torna o tema relevante é o fato de que empresas
Com o crescimento populacional,
a globalização e o desenvolvimento
do capitalismo no século
XX, surgem novas necessidades para o
ser humano. A quantidade de dados e informações
para serem armazenas e computadas
atinge um volume incalculável.
que desejam ter suas ações negociadas na Bolsa
de Valores precisam adotar Governança em TIC,
de acordo com a SOX, o que transforma o assunto
num tema essencial aos negócios. Para quem está
envolvido com aspectos de gestão, ou desejando
fazê-lo, desenvolver uma visão crítica sobre o tema
e adquirir conhecimento a respeito das alternativas
disponíveis é essencial.
Em que situação o tema é útil?
Este tema é útil às organizações que precisam
garantir a continuidade dos processos de negócio,
reduzir os custos de indisponibilidade,
assegurar o retorno dos investimentos em TIC,
aumentando assim a competitividade organizacional.
Neste contexto, a Governança em
TIC está intimamente ligada ao alcance destes
resultados.
A informática surge, neste contexto, para
superar a necessidade do ser humano de
registrar e manipular dados em grandes
quantidades com precisão e rapidez
(NORTON, 1997).
Apesar de bastante presente atualmente,
a definição de informática não é tão
Edição 25 - Engenharia de Software Magazine 21

simples, pois envolve conceitos abstratos. O termo informática
foi criado em 1957, pelo cientista Karl Steinbuch, em um artigo
que trata do processamento automático da informação (STEIN-
BUCH, 1957). A partir daí o termo foi traduzido para o francês,
espanhol e português, sendo mais usado em idiomas latinos. A
informática refere-se ao conjunto das Ciências da Computação
e da Informação que, por sua vez, dedicam-se ao estudo da
informação desde a sua gênese até o processo de transformação
de dados em informação, e desta, em conhecimento.
O termo informática começou a ser amplamente difundido
a partir de 1962, na França, e sua conotação mais conhecida é
a divulgação da contração das palavras INFORmation e auto-
MATIQUE (INFORMAÇÃO AUTOMÁTICA). O objetivo inicial
dessa ciência é auxiliar o ser humano nos trabalhos rotineiros
e repetitivos, em geral cálculos e gerenciamento. Atualmente,
o termo informática é comumente utilizado para se referir à
manipulação e gênese da informação por meio de computadores,
que são os responsáveis diretos pelo processamento dos
dados (ALCALDE, 1991).
Evolução da Informática à TIC
Na década de 1960, conhecida como a era do Processamento
de Dados, os computadores começaram a se tornar importantes
para grandes e médias empresas, mas se apresentavam limitados
e tinham sua aplicação restrita em função da incompatibilidade
entre si. Os avanços da informática eram impulsionados
pelo hardware com avanços de redução de custo e aumento
na velocidade de processamento, mas as aplicações (softwares)
eram limitadas, seu desenvolvimento restrito e seu gerenciamento
extremamente centralizado nos chamados Centros de
Processamento de Dados – CPD (FOINA, 2001).
Em meados da década de 1970 as linhas telefônicas de voz
passaram a permitir o acesso a terminais remotos de computadores
e as telecomunicações se tornam uma base tecnológica,
levando diversas empresas a automatização de suas
operações. Nesta época, conhecida como a era dos Sistemas
de Informações, as transformações tecnológicas começaram
a abrir novas alternativas para a transformação de dados em
informações e na melhoria dos sistemas de acordo com as
necessidades das organizações, mas ainda num enfoque de
grande centralização. Surgem então os pacotes de software
que combinados à flexibilidade do uso de terminais, permite
ao computador processar diversas tarefas simultaneamente.
De acordo com Ken (KENN, 1996), a maior evolução técnica
deste período foi a passagem do processamento de transações
para o gerenciamento de banco de dados. Surgem, então, os
Sistemas Gerenciadores de Bancos de Dados – SGBDs.
Na década seguinte, 1980, ocorreram mudanças tecnológicas
e a popularização dos microcomputadores (PCs ou Personal
Computers), que iniciaram um processo de descentralização
e maior difusão da informática nas organizações de qualquer
tamanho. Assim, o termo “Tecnologia da Informação – TI”
passou a ser mais frequentemente empregado, ampliando o
contexto do que era conhecido como informática. Este período
ficou conhecido como era da Inovação e Vantagem Competitiva.
Os softwares para microcomputadores se popularizaram e o
seu custo de produção e distribuição reduziu-se drasticamente.
As telecomunicações e os microcomputadores ajudaram a
difundir o uso da TI nas organizações, criando programas de
conscientização gerencial para os executivos e os centros de
suporte ao usuário, conhecidos como Help Desk, para apoiar
e disseminar o uso da TI nas organizações como diferencial
e vantagem competitiva. Mesmo com todos os avanços como
as redes locais (Local Area Network – LAN), ainda persistia o
problema da incompatibilidade entre os computadores, o que
dificultava a integração dos sistemas e uma maior e flexibilidade
ao negócio das organizações (FOINA, 2001).
Na era da Integração e Reestruturação do Negócio, iniciada
em meados de 1990, sistemas abertos, integração e modelos
se tornam itens essenciais nas unidades de TI. A integração
tecnológica flexibilizou e simplificou o intercâmbio e o acesso
às informações otimizando o funcionamento das organizações.
A TI passa a ser reconhecida como fator crítico de potencialização
do negócio das organizações, principalmente através
das telecomunicações, que possibilita a eliminação de barreiras
físicas e temporais, nas atividades de serviços e colaboração.
Segundo Ken (KEN, 1996), de modo súbito estas mudanças
se aceleraram em quase todas as áreas de negócio e da tecnologia.
A convergência das tecnologias, as transformações
e a utilização das ferramentas da TI se tornam globais e as
distinções entre computador e comunicação desaparecem.
Desta forma, o termo TI também se transforma assumindo
sua denominação mais recente “Tecnologias da Informação e
Comunicação – TIC”.
O termo Tecnologias da Informação e Comunicação – TIC
serve para designar o conjunto de recursos tecnológicos e computacionais
para geração e uso da informação. A TIC também
é comumente utilizada para designar o conjunto de recursos
dedicados ao armazenamento, processamento e comunicação
da informação, por meio das funções de hardware, software
e telecomunicações, assim como o modo como esses recursos
estão organizados. A TIC não se restringe a equipamentos
(hardware), programas (software) e comunicação de dados.
Existem tecnologias relativas: ao planejamento de informática,
ao desenvolvimento de sistemas, ao suporte ao software, aos
processos de produção e operação, ao suporte de hardware,
todas essenciais no apoio aos processos de negócio, pesquisa
científica e de ensino e aprendizagem (NORTON, 1997).
A Figura 1 ilustra bem a linha do tempo dos acontecimentos
descritos neste artigo.
Sob uma ótica mais ampla, a sigla TIC abrange todas as atividades
desenvolvidas na sociedade com o apoio dos recursos da
informática. É a difusão social da informação em larga escala
de transmissão, a partir destes sistemas tecnológicos inteligentes.
Seu acesso pode ser de domínio público ou privado,
na prestação de serviços das mais variadas formas. Pequenas
e grandes empresas dependem dela para alcançar maior produtividade
e competitividade (FOINA, 2001).
Neste trabalho, adota-se o conceito mais amplo de Tecnologias
da Informação e Comunicação (TIC), incluindo os sistemas de
22 Engenharia de Software Magazine - Da Gestão à Governança em Tecnologia da Informação e Comunicação – TIC

informação, o uso de hardware e software, telecomunicações,
automação e recursos multimídia, utilizados pelas organizações
para fornecer dados, informações e conhecimento, para
menção a todas as tecnologias relacionadas com o contexto da
informação e comunicação, hoje em processo de convergência
em um conceito único (LUFTMAN et al., 1993). Contudo, para
evitar interpretações errôneas, serão utilizadas neste artigo as
siglas TI e TIC como sinônimos.
Figura 1. Timeline da TIC (Fonte: Elaboração própria)
Relevância da Gestão em TIC
Cada vez mais, as organizações tornam-se mais dependentes
das Tecnologias da Informação e Comunicação a fim de atender
seus objetivos estratégicos e para satisfazer às necessidades do
negócio em que atuam. Uma unidade de TIC que não considerar
os objetivos estratégicos da organização em que se insere
como os seus próprios objetivos, será uma unidade que deseja
apenas ser um simples provedor de tecnologia. Ainda assim,
até mesmo os provedores de tecnologia, atualmente, tendem
a preocupar-se com a estratégia de negócio de seus clientes,
condição básica para a venda de serviços sob demanda (MA-
GALHÃES e PINHEIRO, 2007).
O aumento da importância da área de TIC para a execução
da estratégia de negócio faz com que ela seja vista como uma
parte essencial da organização, possuindo sua estratégia estritamente
interligada com a do negócio, de modo que todas
as iniciativas de TIC possam ser demonstradas na forma de
obtenção de valor para a organização. Assim, a área de TIC
passa a se comportar como uma “acionista”, focada nos resultados
que pode trazer para o negócio, e desenvolvendo uma
relação de parceria com as demais áreas.
O papel desempenhado pela área de TIC em uma organização
que deseja ser líder em seu segmento de atuação, move-se da
“eficiência e eficácia” para a “efetividade e a economicidade”
em relação à estratégia de negócio. Esta mudança força a implementação
de um Gerenciamento de Serviços de TIC que
leve à exteriorização da contribuição da área de TIC para a
geração de valor para a organização, maximizando o retorno
para o negócio dos investimentos e das despesas efetuadas em
Tecnologia da Informação (BERG, 2008).
Neste novo cenário, jargões como “melhores práticas”, “otimização
de processos”, “qualidade do serviço” e “alinhamento
estratégico dos serviços de TI ao negócio” deixam de ser mero
discurso e passam a ser parte integrante do novo estilo de vida
das unidades de TIC. Sendo assim, tais unidades tendem a
GEStão DE tI E AGILIDADE
adotar processos guiados pelas melhores práticas do mercado
com o objetivo de não terem de aprender e crescer de “forma
experimental”, por meio de tentativas, erros e atribulações já
vivenciadas e superadas por outras organizações.
Evolução do Papel da TIC nas Organizações
À medida que estas organizações começaram a reconhecer
a sua dependência crescente da TIC para conseguirem satisfazer
os objetivos do negócio, caminhando no encontro às
necessidades da organização, muitos autores determinaram
como fundamental a garantia de uma maior qualidade dos
serviços de TIC, e a sua gestão efetiva (MAGALHÃES e PI-
NHEIRO, 2007).
Neste cenário, a tecnologia deve, essencialmente, mudar o
modo de atuação a fim de agregar valor aos negócios da organização.
Caso não obtenha sucesso em efetuar essa mudança,
estará correndo o risco de ser considerada como estrategicamente
irrelevante (LOBATO, 2000).
Para o direcionamento deste papel estratégico da TIC é necessário
a existência de um processo estruturado para gerenciar
e controlar as iniciativas de TIC nas organizações, a fim de
garantir o retorno de investimentos e adição de melhorias nos
processos organizacionais. Desta forma, o termo Governança
em TIC é utilizado como forma de obter controle e conhecimento,
assegurando mais transparência na gestão estratégica
(KOSHINO, 2004).
Neste contexto surge o Ato Sarbanes Oxley como um novo
impulso para as iniciativas já fomentadas há algum tempo
pela área de TIC, formalizando a necessidade da abordagem
da TIC na camada estratégica das organizações através da
Governança (COMPUTERWORLD, 2005).
O ato Sarbanes Oxley foi promovido pelo Congresso dos
EUA e liderado pelo Senador Paul S. Sarbanes (Democrata de
Maryland) e pelo Deputado Michael G. Oxley (Republicano de
Ohio), no intuito de evitar o esvaziamento dos investimentos e
a fuga dos investidores. Esta lei, promulgada em 2002, caracterizou
os crimes financeiros e definiu penas severas, além de
uma série de procedimentos de governança que passariam a
ser adotados pelas empresas que desejassem abrir seus capitais
no mercado de ações (SOX, 2002).
Governança em TIC
A palavra de origem francesa “gouvernance”, vem, nestes
últimos anos, adquirindo bastante notoriedade por intermédio
da sua tradução para o inglês: governance. Foram as instituições
que participaram dos acordos da Conferência de Bretton
Woods (BRETTONWOODS, 1944) – Banco Mundial e Fundo
Monetário Internacional – que a difundiram mundialmente.
Esta palavra engloba o conjunto dos poderes legislativo, executivo
e judiciário, a administração, o governo, o parlamento, os
tribunais, as coletividades locais, a administração do Estado, a
Comissão Europeia e o sistema das Nações Unidas.
De um ponto de vista amplo, a governança é a capacidade das
sociedades humanas se dotarem de sistemas de representação,
de instituições e processos, de corpos sociais, para elas mesmas
Edição 25 - Engenharia de Software Magazine 23

se gerirem, em um movimento voluntário. Esta capacidade
de consciência (o movimento voluntário), de organização (as
instituições, os corpos sociais), de conceituação (os sistemas
de representação) e de adaptação a novas situações são características
das sociedades humanas. É um dos traços que as
distinguem das outras sociedades de seres vivos, animais e
vegetais (UNESCAP, 2009).
Governança corporativa é o conjunto de processos, costumes,
políticas, leis e instituições que afetam a forma como
uma empresa é dirigida, administrada ou controlada. Governança
corporativa inclui também as relações entre as várias
partes envolvidas e os objetivos para os quais a sociedade é
governada. Os principais intervenientes são os acionistas, da
gestão e do conselho de administração. Outros participantes
incluem clientes, credores (por exemplo, bancos, portadores/
proprietários de apólices/títulos), fornecedores, entidades
reguladoras e da comunidade em geral (CALAME e TAL-
MANT, 2001).
Já Governança de Tecnologia da Informação, Governança
de TI ou Governança em TIC, é definida por alguns autores
(ITGI, 2008; ISACA, 2009; ITSMF, 2008) como um subconjunto
da disciplina Governança Corporativa, centrado na tecnologia
da informação (TI) e seus sistemas de desempenho e gestão
de risco. O crescente interesse em governança de TI é, em
parte, devido a uma série de iniciativas que visam garantir
a criação de mecanismos de auditoria e segurança confiáveis
nas empresas, de modo a mitigar riscos aos negócios e
evitar a ocorrência de fraudes (ou assegurar que haja meios
de identificá-las), garantindo a transparência na gestão das
empresas, como, por exemplo, Sarbanes-Oxley (REZZY, 2007)
nos EUA e Basileia II (BIS, 2006) na Europa. Movimentos como
estes demonstram como instituições de referência no mercado
mundial reconhecem que os projetos de TIC podem facilmente
sair de controle e afetar profundamente o desempenho de
uma organização.
O termo Governança em TI é definido como uma estrutura
de relações e processos que dirige e controla uma organização
a fim de atingir seu objetivo de adicionar valor ao negócio
através do gerenciamento balanceado do risco com o retorno
do investimento de TI. Criar estruturas de governança significa
definir uma dinâmica de papéis e interações entre membros
da organização, de tal maneira a desenvolver a participação e
o engajamento dos membros no processo decisório estratégico,
valorizando estruturas descentralizadas. A governança de
TI, como forma de obter controle e conhecimento em TI, é o
modelo que assegura mais transparência na gestão estratégica
(KOSHINO, 2004).
A Figura 2 procura ilustrar a relação de pertinência e abrangência
entre as áreas de conhecimento mencionadas. Uma
das diferenças mais marcantes entre Gestão em TIC e Governança
em TIC pode ser considerada como o fato da primeira
se concentrar em aspectos táticos e operacionais, enquanto
a segunda procura alavancar a primeira para um nível de
atuação estratégico, no alinhamento de suas iniciativas com
o negócio da organização.
Figura 2. Diagrama de inter-relação entre as áreas citadas (Fonte: Elaboração
própria)
Com adoção de um modelo de Governança de TI espera-se
que as estruturas e processos venham a garantir que a TI
suporte e maximize os objetivos e estratégias da organização,
permitindo controlar a medição, auditagem, execução
e a qualidade dos serviços. Possibilitando ainda viabilizar o
acompanhamento de contratos internos e externos definindo
as condições para o exercício eficaz da gestão com base em
conceitos consolidados de qualidade. Weill e Ross (2006) afirmam
que o desempenho da governança avalia a eficácia da
governança de TI em cumprir quatro objetivos ordenados de
acordo com a sua importância para a organização: i) uso da
TI com boa relação custo/benefício; ii) uso eficaz da TI para a
utilização de ativos; iii) uso eficaz da TI para o crescimento;
iv) uso eficaz da TI para flexibilidade dos negócios.
Finalmente pode-se definir Governança em TIC como o alinhamento
estratégico de TIC com o negócio de forma que se
obtenha o máximo valor deste através do desenvolvimento e
manutenção de controles efetivos de TIC orientados ao controle
de custos, gestão do retorno dos investimentos relacionados e
gestão dos riscos associados (WEILL e ROSS, 2006).
Pretendendo cumprir este objetivo, são muitos os mecanismos
de relação entre os processos de negócio e os processos
de TIC que têm sido gerados pela disciplina de Governança
em TIC. O resultado final é uma infinidade de padrões e boas
práticas, envolvendo: processos, indicadores, perfis, diretrizes,
dentre outros, cuja aplicação geralmente exige muito investimento,
tempo e esforço, em função do formalismo adotado
por estes padrões.
Holm et al. (2006) apresenta uma síntese das intenções de
melhoria da relação entre a TIC e o negócio mediante a classificação
de 17 padrões e ferramentas de melhores práticas
existentes em termos de variáveis, como: tipo de processo e
24 Engenharia de Software Magazine - Da Gestão à Governança em Tecnologia da Informação e Comunicação – TIC

organização. O trabalho citado aborda a investigação de como
a Governança em TIC é adotada no caso de uma companhia
líder no mercado mundial de biotecnologia em enzimas e
micro-organismos industriais. Neste processo é realizada a
revisão de 17 ferramentas de Governança em TIC.
Não se deseja aqui discutir em detalhes os êxitos ou melhorias
que estas ferramentas têm alcançado (em especial ITIL e
COBIT) para os processos de suporte ao core business de nossas
organizações, contudo pretende-se explorar alguns contextos
de potencialização destas, na nova abordagem de Governança
Ágil em TIC proposta neste trabalho, como fator catalisador
do rompimento do gap entre a TIC e o negócio.
Os mais difundidos modelos de Governança em TIC
Nesta seção serão abordados oito modelos de Governança
em TIC mais difundidos no mercado, e que são mais frequentemente
mencionados em pesquisas especializadas (MAGA-
LHÃES E PINHEIRO, 2007; COMPUTERWORLD, 2007b), além
do modelo recentemente proposto por Luna (2009), totalizando
nove modelos.
Este trabalho utilizará a denominação genérica proposta por
Luna (2010): “corpo de conhecimento de governança em TIC”,
ou, em inglês, Information and Communication Technologies
Governance Body of Knowledge – ICTGBOK, para o conjunto
de informações disponíveis no domínio de Governança em
TIC, que em parte está representado, neste artigo, de forma
sucinta.
Para cada modelo abordado nesta seção serão vistos: definição,
histórico, foco e considerações sobre sua adoção.
Ao final desta seção serão abordadas as principais características,
carências, dificuldades e limitações dos modelos apresentados,
que motivaram o desenvolvimento deste trabalho.
Antes de prosseguir, vale a pena mencionar que algumas
outras abordagens que aparecem em pesquisas sobre modelos
adotados por organizações para iniciativas de governança em
TIC (COMPUTERWORLD, 2007b) não serão abordados neste
artigo pelos seguintes motivos:
• Modelos do Project Management Institute (PMI): trata-se
do PMBOK e do PMgBOK, que na análise realizada por este
trabalho foram considerados como sendo metodologias de
Gerenciamento de Projetos e Gerenciamento de Programas
e Portfólio de Projetos, respectivamente. E, portanto, apoiam
projetos de governança, mas não fazem parte do contexto
central abordado neste tópico (PMI, 2008);
• Six Sigma (6σ): não foi considerado por tratar-se de um
modelo de qualidade, expresso através de um conjunto de
práticas originalmente desenvolvidas pela Motorola para
melhorar sistematicamente os processos ao eliminar defeitos.
Apresenta baixa representatividade nas pesquisas e também
não faz parte do contexto central abordado neste tópico (HAR-
RY et al., 2000);
• eSourcing Capability Model for Service Providers (e-SCM-
SP): não foi abordado em função da baixa representatividade
com que aparece nas pesquisas e também por se tratar de um
framework recente de abordagem específica, que é destinado
GEStão DE tI E AGILIDADE
especialmente aos provedores de serviço, podendo, inclusive,
ser utilizado como um apoio para aqueles que oferecem terceirização
(COMPUTERWORLD, 2007a);
• PRINCE2 – Project In a Controlled Environment: também
não foi considerado por ser um método (não proprietário)
para gerenciamento de projetos, desenvolvido pelo governo
britânico em 1996. Foi criado em 1989 a partir do PROMPTII,
o qual, por sua vez, surgiu em 1975 e foi adotado em 1979
como padrão para gerenciamento dos projetos de sistemas de
informação do governo inglês. Contudo o PRINCE2 “não é” um
modelo de Governança em TIC, muito embora a OGC – Office
of Government Commerce – sugira a sua aplicação como apoio
à implantação de ITIL (BRADLEY, 2002). Além disso, também
apresenta baixa representatividade nas pesquisas.
ITIL
ITIL é a abreviação para “Information Technology Infrastructure
Library”, um framework de processos de gestão de TI que surgiu
no fim da década de 1980 da necessidade de se ter processos organizados
e claros. Percebeu-se que as organizações estão cada
vez mais dependentes da área de TI e que é necessário organizar
os fluxos de processos neste departamento (ITGI 2009).
Esse modelo de gestão foi formulado pelo British Central
Computer and Telecommunication Agency (CCTA), que
posteriormente foi assimilado pela Secretaria de Comércio
do Governo Inglês – Office of Government Commerce (OGC,
2009), a partir de pesquisas realizadas com especialistas em
gestão de TI, para definir uma melhor forma de funcionamento
e gestão das Tecnologias da Informação e Comunicação
(ITSMF, 2009).
ITIL é uma compilação das melhores práticas e processos na
planificação, aprovisionamento e suporte de serviços de Tecnologia
de Informação (ITSMF, 2008) e pode ser considerado
um conjunto de boas práticas de governança organizado de
forma sistemática, e, portanto um framework. À medida que as
empresas reconheceram a sua dependência crescente nas TIC
para conseguirem satisfazer os objetivos do negócio e irem ao
encontro às necessidades da empresa, muitos determinaram
que a maior qualidade dos serviços de TI, e a sua gestão efetiva,
era necessária (EUROCOM, 2006).
A principal vantagem do ITIL, no contexto das “boas práticas”
de gestão em TIC, é que os processos descritos são
genéricos – aplicam-se independentemente da tecnologia,
plataforma, tipo ou tamanho do negócio envolvido. Quase
todas as organizações das TIC de qualquer tamanho têm um
“help desk”, um método de lidar com problemas ou mudanças,
alguma compreensão de gestão de configuração, níveis
de serviço de acordo com os clientes, uma maneira de lidar
com problemas de capacidade e disponibilidade e uma forma
de plano de contingência. O foco primário da metodologia
ITIL é possibilitar que área de TI seja mais efetiva e proativa,
satisfazendo assim clientes e usuários (ITIL, 2009).
Com a versão atual do ITIL, Versão 3, lançada em 2007, uma
das principais deficiências corrigidas foi um incremento em
matérias que ajudem a identificar o retorno dos investimentos
Edição 25 - Engenharia de Software Magazine 25

em TI. Um problema muito frequente em governança de TI que
era normalmente indicado como um problema para a adoção
efetiva do ITIL. A nova versão é ainda mais concisa do que a
versão anterior, reduzida de oito para cinco livros principais
que compõem seu núcleo e vários outros livros que poderão
complementar o ITIL posteriormente.
Seu foco é: em Gerenciamento de Serviços de TIC.
COBIT
O COBIT – Control Objectives for Information and related
Technology é um framework de governança de TI apoiado
por um conjunto de ferramentas que permite aos gestores
fazer a ponte entre as exigências de controle, questões técnicas
e riscos do negócio. Ele permite o desenvolvimento de
políticas claras e boas práticas de controle de TI em toda a
organização. Além disso, o COBIT enfatiza a conformidade
regulamentar, ajuda as organizações a aumentar o valor
obtido através da TI, permite o alinhamento e simplifica
sua implementação.
O COBIT representa a visão de um grupo de experts focado
no estudo de Governança em TIC. Trata-se de um conjunto
de boas práticas sobre processos de gerenciamento da TI nas
organizações, que aborda desde aspectos técnicos, até processos
e pessoas. Sua estrutura é organizada em processos que
são interligados com o objetivo de controlar a TI, através da
formação de um framework de controle que tem o propósito
de assegurar que os recursos de TI estarão alinhados com os
objetivos da organização.
O COBIT é baseado na premissa de que a TI precisa entregar
a informação que a empresa necessita para atingir seus objetivos,
e por isso, tem como objetivo otimizar os investimentos e
garantir a entrega dos serviços com as devidas métricas.
O princípio do framework do COBIT é vincular as expectativas
dos gestores de negócio com as responsabilidades dos
gestores de TI. Assim, busca fazer com que a TI seja mais capaz
de responder às necessidades do negócio. O COBIT não se
trata de um padrão definitivo, ele tem que ser adaptado para
cada organização.
Segundo o ISACA – Information Systems Audit and Control
Association, a missão do COBIT é “Pesquisar, desenvolver,
publicar e promover um conjunto de objetivos de controle para
tecnologia que seja embasado, atual, internacional e aceito em
geral para o uso do dia-a-dia de gerentes de negócio e auditores”
(ISACA, 2009a). Para tanto, o COBIT trabalha principalmente
dentro do seguinte conjunto de atividades:
• Alinhamento da TI com o negócio da empresa;
• Definição do papel da TI TI Estratégica ou TI
Operacional;
• Auxilia na organização das atividades da TI a partir da
adoção de um modelo de gestão;
• Ajuda identificar quais recursos de TI devem ser alavancados
com maior efetividade;
• Define os objetivos e controles gerenciais a serem
observados;
• Estabelece claramente papeis e responsabilidades.
É importante destacar que os princípios básicos da Governança
de TI adotados pelo COBIT são:
• Responsabilidade corporativa: trata-se de pensar e agir pela
perenidade da organização, com responsabilidade social e
ambiental;
• Prestação de contas: relacionado à obrigação de prestar
contas;
• Equidade: ligado ao tratamento justo e igualitário;
• Transparência: relacionado ao desejo de informar.
Em sua versão atual, 4.1, o COBIT pode ser usado para reforçar
o trabalho já feito com base em versões anteriores, mas
isso não invalida os trabalhos anteriores. Quando as principais
atividades estão previstas com iniciativas de governança de
TI, ou quando uma revisão do quadro de controle da empresa
é esperada, recomenda-se começar de novo com a versão mais
recente do COBIT (ISACA, 2009a).
Seus focos são: Alinhamento entre a TI e o negócio, Controle
Interno e Métricas.
BSC
O Balanced Scorecard – BSC é um modelo de gestão, desenvolvido
em 1992 por Robert Kaplan e David Norton da
Harvard Business School, para avaliar o desempenho estratégico
e, consequentemente, gerir o sistema de estratégias de
uma organização, sendo considerada uma das ferramentas
de grande importância na área de planejamento estratégico
com o objetivo de traduzir estratégia em ação (KAPLAN e
NORTON, 1997).
BSC é uma sigla que pode ser traduzida para Indicadores Balanceados
de Desempenho, ou ainda para Campos (CAMPOS,
1994), Cenário Balanceado. O termo “Indicadores Balanceados”
se dá ao fato da escolha dos indicadores de uma organização
não se restringirem unicamente no foco econômico-financeiro,
as organizações também se utilizam de indicadores focados
em ativos intangíveis como: desempenho de mercado junto
a clientes, desempenhos dos processos internos e pessoas,
inovação e tecnologia. Isto porque a somatória destes fatores
alavancará o desempenho desejado pelas organizações, consequentemente
criando valor futuro.
Os requisitos para definição desses indicadores tratam dos
processos de um modelo da administração de serviços e a
busca pela maximização dos resultados baseados em quatro
perspectivas que refletem a visão e estratégia empresarial:
• Financeira;
• Clientes;
• Processos internos;
• Aprendizado e crescimento.
O BSC não só direciona comportamentos dentro de uma
organização, como também monitora o desempenho empresarial
em prol da estratégia. Ele é difundido com sucesso em
várias organizações privadas, públicas e não governamentais
no mundo inteiro. O BSC tem como uma de suas funções
traduzir a criação de valor financeiro (tangível) a partir dos
26 Engenharia de Software Magazine - Da Gestão à Governança em Tecnologia da Informação e Comunicação – TIC

ativos intangíveis (não financeiros), que se baseia em um
sistema de medição de desempenho, através da utilização
de indicadores e objetivos financeiros derivados da visão e
da estratégia organizacional (KAPLAN e NORTON, 1997).
A relação do BSC com o contexto de Gestão em TIC está intimamente
associada à definição de metas estratégicas para
organização e ao acompanhamento de seu cumprimento por
meio de indicadores de negócio.
Seu foco é em: Planejamento Estratégico e Gestão por
Indicadores.
IT Flex
A metodologia IT Flex, com sua proposta de transformação
da área de TI em uma provedora de serviços de forma continuada
para a organização, parte da estruturação dos diferentes
processos da área em correspondência com a estratégia
de negócio da organização. Desta forma, o modelo procura
prover um mecanismo de gerenciamento do desempenho que
possibilita a ela a oportunidade de fornecer serviços de TI com
toda a qualidade que os seus clientes requerem, com custos e
níveis de serviço associados que alinhem TI às necessidades
das diferentes áreas de negócio da organização (MAGALHÃES
E PINHEIRO, 2007).
Quando os serviços de TI estão alinhados aos objetivos
estratégicos estabelecidos pela estratégia de negócio e otimizados
para todo o ciclo de vida do serviço, a organização
consegue associar os custos da área de TI ao valor produzido
para o negócio, enxergando a verdadeira contribuição
da área de TI. Isto é obtido, segundo Magalhães e Pinheiro
(2007), através da aplicação da metodologia IT Flex conforme
descrito a seguir:
• Responsabilidade da área de TI pelos serviços de TI, por meio
da alocação de custos baseada na utilização real dos diferentes
serviços de TI disponibilizados para as áreas de negócio;
• Maior produtividade e satisfação do usuário final, advinda
da automação dos processos de TI e do estabelecimento do
autoatendimento;
• Menores custos e maior eficiência, integrando o Service Desk
a toda a infraestrutura de TI e gerenciando proativamente o
portfólio de serviços de TI;
• Relações de cooperação entre a área de TI e as áreas de
negócio, através do fornecimento de informações sobre como
escolher níveis de serviços que melhor atendam às necessidades
da estratégia de negócio (não pagando taxas mais altas por
99,99 % de disponibilidade se o usuário não necessita realmente
desse nível de disponibilidade) e do gerenciamento de nível
de serviço em tempo real para evitar violações dos Acordos de
Nível de Serviço estabelecidos com as áreas de negócio;
• Crescimento mais rápido e constante, atendendo consistentemente
as necessidades atuais das áreas de negócio e suportando
novas iniciativas do negócio, como a participação em novos
mercados através de uma maior capacidade de escalabilidade
da estrutura de entrega e suporte aos serviços de TI, baseada
em um processo de gerenciamento de suprimentos adequado
à estratégia do negócio;
GEStão DE tI E AGILIDADE
• Governança de TI, possibilitando o gerenciamento de
mudanças e a padronização dos processos mais complexos
relacionados com a área de TI.
Seu foco é em: Gerenciamento de Serviços de TI
COSO
Em 1985, foi criada, nos Estados Unidos, a National Commission
on Fraudulent Financial Reporting (Comissão Nacional sobre
Fraudes em Relatórios Financeiros) e seu primeiro objeto de
estudo foram os controles internos das organizações. Em 1992,
através de uma iniciativa privada de cinco grupos (American
Accounting Association, The American Institute of Certified Public
Accountants, The Financial Executives Institute, The Institute of
Internal Auditors e The Institute of Management Accountants), foi
publicado o trabalho “Internal Control – Integrated Framework”
(Controles Internos – Um Modelo Integrado).
Esta publicação tornou-se referência mundial para o estudo
e aplicação dos controles internos. Posteriormente a Comissão
transformou-se em Comitê, que passou a ser conhecido como
C.O.S.O. – The Comitee of Sponsoring Organizations (Comitê
das Organizações Patrocinadoras). O C.O.S.O. é uma entidade
sem fins lucrativos e dedicada à melhoria dos relatórios financeiros
através da ética, efetividade dos controles internos e
governança corporativa (COCURULLO, 2006).
Em 2002, o ato de Sarbanes-Oxley foi criado para restaurar
a confiança de investidores dos mercados públicos dos Estados
Unidos, devastados por escândalos e lapsos nos negócios
envolvendo governança corporativa. Embora reescrevessem
literalmente as regras de contabilização corporativa, bem como
a sua divulgação, as páginas inumeráveis do ato da sustentação
legal seguem uma premissa simples: a governança corporativa
e as práticas éticas de negócio já não são mais opcionais em
TI, mas são leis.
O ato Sarbanes-Oxley – SOX representa a parte a mais significativa
de uma legislação sobre os negócios, desde a última
metade do século, pois evidencia a contabilização corporativa.
Entretanto, é importante enfatizar que a seção 404 não requer
apenas que as empresas estabeleçam e mantenham uma estrutura
interna adequada ao controle, mas avaliem também
sua eficácia anualmente. Em outras palavras, esta abordagem
é extremamente relevante para aquelas organizações que
começaram o processo de conformidade e que a TI exerce um
papel vital suportando os componentes de sistemas, de dados
e de infraestrutura, e que são críticos no processo de relatório
financeiro (COSO, 2006).
Em 2003 o PCAOB emitiu um padrão propondo que fosse
discutida a importância da TI no contexto de controles internos.
A natureza e as características de uma empresa de TI que faz
uso de seu sistema de informação afeta o controle interno da
mesma sobre relatórios de desempenhos financeiros.
Recentemente vem se usando também a descrição Control
Objectives of Sarbanes Oxley, para a sigla COSO. Como o Internal
Control – Integrated Framework é um modelo de trabalho
muito genérico, com visão de auditoria, muitas organizações
Edição 25 - Engenharia de Software Magazine 27

usam o COBIT (Control Objectives for Information and Related
Technology) para aplicar o COSO. Na prática, o que acontece
é que empresas adotam o COSO de forma geral, para controles
internos, principalmente financeiros. A área de TI, por
sua vez, adota o COBIT como guarda-chuva para diversas
metodologias e melhores práticas indicadas para tecnologia
da informação.
Seu foco é: em Governança Corporativa e Controle Interno.
ISO/IEC 20000
A ISO/IEC 20000 é a primeira norma editada pela ISO
(International Organization for Standardization) e pela IEC
(International Electrotechnical Commission), que versa sobre
gerenciamento de serviços de TIC. A ISO/IEC 20000 é um
conjunto que define as melhores práticas de gerenciamento
de serviços de TIC. O seu desenvolvimento foi baseado na BS
15000 (British Standard) e tem a intenção de ser completamente
compatível com o ITIL. A sua primeira edição ocorreu em
dezembro de 2005.
O referencial ISO/IEC 20000 identifica os requisitos da Gestão
de Serviços e é relevante para os responsáveis pela preparação,
implementação ou gestão continuada dos serviços de TIC na
organização. As organizações podem assegurar a certificação
dos seus Sistemas de Gestão de Serviços de TIC de modo independente,
em conformidade com este referencial.
A ISO/IEC 20000 foi desenvolvida para responder às necessidades
de uma audiência global e fornecer um entendimento
comum da gestão de serviços de tecnologias de informação e
comunicação em todo o mundo. O escopo desta norma cobre
os aspectos responsáveis por 80% do investimento total em
tecnologias de informação e comunicação da grande maioria
das organizações. O ISO/IEC 20000 é publicado em duas partes
e permite aos prestadores de serviços compreenderem como
podem alcançar a qualidade no serviço prestado aos seus
clientes, internos e externos. A certificação é o resultado da
monitoração do nível de serviço face ao padrão, acrescentando
valor real para as organizações não só porque demonstram a
qualidade dos serviços internos como lhes permite selecionar
parceiros externos adequados (ISO/IEC20000, 2005).
Seu foco é em: certificação de organizações sob o aspecto de
Governança em TIC.
VAL IT
O Val IT é um framework baseado no COBIT e o complementa
desde a fase de negócios até as perspectivas financeiras, além
de auxiliar a todos que têm interesse no valor de entrega de TI.
Trata-se de um framework de governança que consiste em um
conjunto de princípios orientadores e em um número de processos
em conformidade com esses princípios, que estão mais
definidos como um conjunto de boas práticas de gestão.
O Val IT é suportado por publicações e ferramentas operacionais
e fornece orientações para:
• Definir o relacionamento entre a TI e o negócio, além
das funções da organização com as responsabilidades de
governança;
• Gerenciar o portfólio de uma organização de TI e permitir
investimentos empresariais;
• Maximizar a qualidade dos processos de negócios para TI,
permitindo investimentos em negócios com particular ênfase
para a definição dos principais indicadores financeiros, a
quantificação de “suaves” prestações e à avaliação global do
risco de queda.
O Val IT endereça pressupostos, custos, riscos e resultados
relacionados a um portfólio equilibrado de investimentos de
negócios. Ele também fornece a capacidade de benchmarking
e permite às empresas trocar experiências sobre as melhores
práticas para gestão de valor (ISACA, 2009).
Seu foco é em: Gerenciamento dos Investimentos em TI.
CMMI sob a Perspectiva de Governança em TI
O CMMI – Capability Maturity Model Integration é uma
evolução do CMM e procura estabelecer um modelo único
para o processo de melhoria corporativo, integrando diferentes
modelos e disciplinas (SEI, 2009).
É um Modelo de referência, criado em 2000 e mantido pela
SEI – Software Engineering Institute, que contém práticas
necessárias à evolução da maturidade em disciplinas específicas,
como: Engenharia de Sistemas, Engenharia de Software,
Desenvolvimento integrado de Produtos e Processos, e Fornecimento
de Código (subcontratação).
Adota uma abordagem de melhoria de processos que fornece
às organizações os elementos essenciais de processos eficazes
com a finalidade de melhorar seu desempenho.
A metodologia CMMI pode ser vista sob uma perspectiva de
Governança de TI, como um modelo de gestão que organiza
práticas já consideradas efetivas em uma estrutura que visa o
auxílio da organização no estabelecimento de prioridades para
melhoria, como também no fornecimento de um guia para a
implementação dessas melhorias.
Seu foco é em: Melhoria de processos.
MAnGve
O MAnGve – Modelo Ágil no Apoio à Governança em TIC,
é um modelo ágil para implantação e melhoria dos processos
e serviços de governança em TIC direcionado a organizações
de qualquer natureza e tamanho e que provê uma abordagem
de ação prática.
Foi concebido por Luna, em 2009, para minimizar a carência
de foco prático encontrada nos modelos existentes. Sua grande
“ambição” é a de complementar o “corpo de conhecimento de
Governança em TIC” já existente e se tornar uma alternativa
à aplicação deste ICTGBOK.
O MAnGve pode ser lido como um modelo baseado em um
ciclo de vida ágil, através da transição de princípios, valores
e boas práticas das Metodologias Ágeis do paradigma da Engenharia
de Software para o domínio de Governança em TIC.
Com isso, Luna (2009) sugere que o MAnGve possa atuar como
referência prática para implantação e melhoria de processos e
serviços de governança em TIC, em organizações de qualquer
28 Engenharia de Software Magazine - Da Gestão à Governança em Tecnologia da Informação e Comunicação – TIC

natureza e magnitude, com base no alinhamento dos objetivos
estratégicos da TIC com o negócio da organização.
O MAnGve provê uma abordagem de ação prática, adaptativa,
orientada a pessoas, de maneira flexível e iterativa
buscando continuamente a simplicidade, e se concentra na
contínua reflexão sobre a necessidade de adaptação à realidade
das organizações e sobre o enfoque comportamental da equipe
comprometida (MANGVE, 2009).
Seu foco é em: Implantação e melhoria de Governança em
TIC.
Uma análise crítica sobre Governança em TIC
A Tabela 1 é o resultado de um estudo comparativo dos
modelos explorados neste artigo. Nesta análise procurou-se
evidenciar as características e diferenciais de cada modelo
apontando o foco primário, as principais características e as
carências identificadas entre os métodos aqui apresentados.
Conforme pode ser percebido no resultado deste estudo
comparativo, muitos dos modelos aqui apresentados findam
não sendo modelos cujo foco primário é a Governança em
TIC, apesar do filtro realizado no início desta pesquisa e comentado
no início da seção anterior. Alguns, inclusive, sequer
estão no contexto de Governança. Contudo, todos abordam
aspectos extremamente significativos do contexto desta área
GEStão DE tI E AGILIDADE
do conhecimento, o que sugere que possam ser aplicados com
sucesso de forma articulada e combinada, quando necessário.
Cita-se como exemplo a relevância da abordagem do BSC para
a fase de preparação da implantação de governança, ou ainda
o caso do CMMI quando se trata da melhoria dos processos
de governança, uma vez implementados.
Por outro lado, como pode ser visto na Tabela 1, uma das
carências mais frequentes nos primeiros oito modelos abordados
é a ausência de orientações sobre sua aplicação prática.
O que dificulta em muito a sua adoção por parte das organizações.
Esta carência de orientação à ação ocasiona uma
grande dificuldade nas organizações em identificar por onde
começar as iniciativas de implantação de Governança em TIC
(MENDEL & PARKER, 2005). Em muitos casos, esta situação
conduz inevitavelmente a organização à contratação de serviços
de consultoria especializada, o que, com efeito, requer
altos investimentos e muitas vezes faz com que o processo se
torne moroso.
Ainda é importante observar que o último modelo abordado –
o MAnGve, além de ser recente, foi originado com o objetivo de
eliminar ou minimizar as carências já identificadas nos demais
modelos, o que é um ponto extremamente positivo e relevante.
Neste contexto observam-se iniciativas com o intuito de minimizar
as mencionadas limitações ou carências dos modelos citados.
Métodos Foco primário Principais Características Limitações/ Carências
ITIL Governança em TIC Concentra-se no Gerenciamento de Serviços de TIC. Os processos descritos são
genéricos – aplicam-se independentemente da tecnologia, plataforma, tipo
Não possui método de implantação.
Não contém um mapa detalhado dos processos.
ou tamanho do negócio envolvido.
Não fornece instruções de trabalho.
COBIT Governança em TIC Concentra-se no alinhamento da TIC com o negócio, controle e auditoria dos Está num nível mais genérico que o ITIL.
processos de TIC. Abrangente aplicável para a auditoria e controle de processos
de TIC, desde o planejamento da tecnologia até a monitoração e auditoria de
Não possui método de implantação.
Não define padrões de implementação, nem passos, técnicas ou
todos os processos.
procedimentos para aplicação.
BSC Gerenciamento Estratégico Concentra-se no planejamento e gestão estratégica, através do monitoramento Não desce ao nível tático ou operacional, o que gera dificuldade de
de indicadores do negócio.
alimentação dos indicadores.
IT Flex Gerenciamento de TIC Concentra-se em dotar a área de TIC de um elevado grau de flexibilidade
Não possui orientações para sua aplicação.
Abordagem superficial e genérica.
fazendo com que colabore com o aumento da adaptabilidade da organização.
Não define passos, técnicas ou procedimentos para aplicação.
COSO Governança Corporativa
Possui como proposta o conceito de “Fábrica de Serviços de TIC”.
Modelo de trabalho para controle interno, muito genérico, com visão de Consegue ser mais genérico que o COBIT.
auditoria. Algumas organizações utilizam o COBIT para implantar o COSO. Não define passos, técnicas ou procedimentos para sua aplicação.
ISO/IEC 20000 Governança em TIC Concentra-se na definição das melhores práticas de gerenciamento de serviços O alinhamento ao ITIL faz com que herde as mesmas carências e
de TIC. Orienta o processo de certificação organizacional como resultado do
de TIC. Complementa o COBIT no que diz respeito à perspectiva financeira e ao
valor de entrega de TIC.
limitações.
Val IT Governança Corporativa
monitoramente face ao padrão documentado.
Baseado no COBIT, que provê uma estrutura para a governança de investimentos O alinhamento ao COBIT faz com que herde parte das mesmas carências
e limitações.
Contudo, apresenta um estudo de caso completo que pode servir de
CMMI Gerenciamento Processos É uma abordagem de melhoria de processos que fornece às organizações os
orientação à sua aplicação.
Não é focado em Governança, carecendo de alguma adequação neste sentido.
elementos essenciais de processos eficazes com a finalidade de melhorar seu
Possui um guia que orienta a sua aplicação, contudo é muito extenso e
desempenho.
precisa ser instanciado em cada organização para um resultado efetivo.
MAnGve Governança em TIC Implantação e Melhoria de Governança em TIC através de uma abordagem Sua adaptabilidade requer um grau de liderança significativo no papel do
prática, flexível, adaptativa e com o foco nas pessoas.
tabela 1. Comparação entre os modelos revisados (Fonte: Elaboração própria)
MAnGveMaster
Grau de maturidade e auto-organização da Equipe envolvida.
Edição 25 - Engenharia de Software Magazine 29

Estas iniciativas estão no estado da arte da Governança em TIC.
O diferencial desta abordagem propõe a aplicação de princípios,
valores e boas práticas de metodologias ágeis da Engenharia de
Software para implantação e melhoria de Governança em TIC
nas organizações sob o conceito de “Governança Ágil em TIC”
(LUNA, 2010). Esta proposta pode ser considerada uma abordagem
inovadora e bem-vinda para complementar este próprio
ICTGBOK, termo também proposto por Luna (2010).
Conclusões
Nos últimos anos a TIC – Tecnologias da Informação e Comunicação
tem sido objeto de investimentos e pesquisa crescente
tanto do meio acadêmico quanto no ambiente organizacional,
demandando altos esforços no aperfeiçoamento de modelos de
gestão e implantação de práticas que trouxessem uma maior
competitividade às organizações. Neste cenário a Governança
em TIC tem se destacado como uma opção para o gerenciamento
e controle efetivo das iniciativas de TIC nas organizações,
garantindo o retorno de investimentos e adição de melhorias
aos processos organizacionais.
Este artigo apresentou um breve resgate do surgimento da
Informática, como área do conhecimento. Na sequência, abordou-se
uma sucinta narrativa da evolução da informática até o
que se conhece hoje como Tecnologias da Informação e Comunicação
– TIC. Num momento seguinte, tratou-se a relevância
da Gestão de TIC e a evolução do seu papel nas organizações,
chegando até o conceito de Governança em TIC.
Referências
ALCALDE, E. L.(1991). Informática básica. São Paulo: Makron Books, 1991.
BERG, C. (2008). Value-DrivenIT,valuedrivenit.com. Cliff Berg Imprints, Reston VA, USA. Disponível
em: . Acesso em: 30/09/2009.
BIS - Bank for International Settlements (2006). Basel II: International Convergence of Capital
Measurementand Capital Standards. Disponível em: .
Acesso em: 22/01/2009.
BRADLEY, K. (2002). Understanding PRINCE 2. - SPOCE Project Management Limited - rsms.ac.uk,
2002. Disponível em: < http://www.rsms.ac.uk/up2-may2-2002.pdf >. Acesso em: 03/10/2009.
BRETTONWOODS (1944), Conferência Internacional Monetária de Bretton Woods. Disponível em:
http://www.unificado.com.br/calendario/07/bretton.htm>. Acesso em: 22/01/2009.
C.O.S.O. (2006). INTERNAL Control – Integrated Framework. The Committee of Sponsoring
Organizations of the Treadway Commission. Disponível em: < http://www.snai.edu/cn/service/
library/book/0-Framework-final.pdf>. Acesso em: 08/09/2009.
CALAME, P.I.; TALMANT, A. (2001). Questão do Estado no Coração do Futuro - O mecano da
governança. São Paulo. Editora Vozes.
CAMPOS, Vicente Falconi. (1994). Gerenciamento pelas Diretrizes. Revista de Administração de
Empresas. São Paulo, 1994. V. 34, n. 6, p 6-11.
COCURULLO, A. (2006). Gerenciamento de Riscos Corporativos. IBGC – Instituto Brasileiro
de Governança Corporativa. Disponível em: < http://www.ibgc.org.br/biblioteca/Download.
aspx?CodAcervo=2093 >. Acesso em: 08/09/2009.
COMPUTERWORLD (2005). Notícia: SARBOX é considerada um presente para área de TI.
Posteriormente, este artigo conceituou e delimitou o termo
“corpo de conhecimento em Governança em TIC”, Information
and Communication Technologies Governance Body of Knowledge
– ICTGBOK. Em seguida foram apresentadas nove abordagens
diferentes no domínio de Governança em TIC, apontando
suas principais características, foco, carências e limitações.
Ao final desta revisão sistemática elaborou-se um quadro
comparativo ressaltando as características essenciais e as
principais limitações ou carências de cada modelo abordado.
Por fim, identificou-se o surgimento de um novo paradigma:
“Governança Ágil em TIC”, proposto e conceituado por Luna
(2009) com o objetivo de minimizar ou eliminar boa parte das
carências percebidas nos modelos existentes. A consolidação
desta proposta fica evidenciada pela caracterização do nono
modelo abordado neste artigo, o MAnGve, cuja proposta é ser
uma alternativa ágil para implantação e melhoria do “Corpo
de Conhecimento de Governança em TIC” ou ICTGBOK,
existente. Esta proposta pode ser considerada uma abordagem
inovadora e bem-vinda para complementar o ICTGBOK, termo
também proposto por Luna (2009).
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Computerworld, 24 de novembro de 2005 - 14h54. Disponível em: < http://computerworld.uol.
com.br/gestao/2005/11/24/idgnoticia.2006-03-29.9247266501/>. Acesso em: 05/10/2009
COMPUTERWORLD (2007a). Notícia: e-SCM: novo aliado para a governança convergente de TI.
Computerworld, 14 de fevereiro de 2007 - 12h53. Disponível em: . Acesso em: 03/10/2009.
COMPUTERWORLD (2007b). Notícia: Pesquisa revela que 85% das empresas já usam modelos
de governança de TI no Brasil. Computerworld, 16 de outubro de 2007 - 11h48. Disponível em:
.
Acesso em: 03/10/2009.
EUROCOM (2006). EUROPEAN COMISSION. Europe’s Information Society. “Research: 9 billion
injection to boost European ICT research”. Disponível em: , Bruxelas. Acesso em: 13/01/2009.
FOINA, P.R. (2001). Tecnologia de informação: planejamento e gestão / Paulo Rogério Foina. –
São Paulo: Atlas.
HARRY, MJ; SCHROEDER, R; LINSENMANN, DR. (2000). Six Sigma. questuspoint.pl, 2000. Disponível em: . Acesso em: 03/10/2009.
HOLM, M.L.; KÜHN, M.P.; VIBORG, K.A. (2006). IT Governance: Reviewing 17 IT Governance Tools and
Analysing the Case of Novozymes A/S. HICSS’06 - Proceedings of the 39th Hawaii International
Conference. Disponível em: < http://itu.dk/~petermeldgaard/B19/5_Case_Novozymes_
HICSSpaper.pdf>. Acesso em: 30/09/2009.
30 Engenharia de Software Magazine - Da Gestão à Governança em Tecnologia da Informação e Comunicação – TIC
Dê seu Feedback
sobre esta edição

Continuação: Referências
ISACA (2009). Disponível em: . Acesso em: 04/09/2009.
ISACA (2009a). COBIT Case Studies by Industry. Disponível em:< http://www.isaca.org/
Template.cfm?Section=Case_Studies3&Template=/ContentManagement/ContentDisplay.
cfm&ContentID=50973>. Acesso em: 18/10/2009.
ISO/IEC 20000 Certification web site (2005). Disponível em: . Acesso em: 08/09/2009.
ITGI (2007). Information Technology Governance Institute. CobiT - Control Objectives for
Information and related Technology. 4.1. ed. Rolling Meadows: ITGI.
ITGI (2009). Information Technology Governance Institute. Disponível em: . Acesso em: 13/01/2009.
ITIL (2009). INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY. Disponível em: .Acesso em: 10/01/2009.
itSMF (2008), IT Service Management Forum; An Introductory Overview of ITIL® V3. Disponível
em: . itSMF . Acesso em: 23/01/2009.
ItSMF (2009). Information Technology System Management Forum web site.Disponível em: <
http://www.itsmf.net)>. Acesso em: 01/10/2009.
KAPLAN, R.S.; NORTON, D.P. (1997). A Estratégia em Ação: Balanced Scorecard. 22. Edição. Rio de
Janeiro: Campus.
KENN, Peter G. W. (1996). Guia Gerencial para a tecnologia da informação: Conceitos essenciais e
terminologia para empresas e gerentes. Rio de Janeiro: Campus, 1996.
KOSHINO, L. (2004). SERPRO apresenta no Congresso Nacional de Informática Pública, em Brasília,
suas soluções em governança de TI. Revista Tema - Ano XXVIII - Edição 175, p. 23-25, setembro/
outubro 2004.
LOBATO, D. M. (2000). Administração Estratégica uma visão orientada para a busca de vantagens
competitivas. Rio de Janeiro: Editoração.
LUFTMAN, J.N.; LEWIS, P.R. e OLDACH, S.H. (1993):“Transforming The Enterprise: The Alignment Of
Business And Information Technology Strategies”. IBM Systems Journal, v.32, n.1, p.198-221, 1993.
LUNA, A. J. H. de O. (2009). MAnGve: Um Modelo para Governança Ágil em Tecnologia da Informação
e Comunicação. Programa de Pós-graduação stricto sensu em Ciência da Computação. Centro de
Informática, Universidade Federal de Pernambuco. Dissertação de Mestrado. Disponível em: <
www.cin.ufpe.br/~ajhol/mangve>. Acesso em: 17/12/2009.
GEStão DE tI E AGILIDADE
LUNA, Alexandre J. H. de O.; COSTA, Cleyverson P.; de MOURA, Hermano P.; NOVAES, Magdala A.;
do NASCIMENTO, César A. D. C. ; (2010). Governança Ágil de TIC: rompendo paradigmas. JISTEM
- Journal of Information Systems and Technology Management; 2009. Disponível em: < http://
www.jistem.fea.usp.br/index.php/jistem/issue/archive >. Acesso em: 17/11/2009.
MAGALHÃES, I. L. E PINHEIRO W. B. (2007). Gerenciamento de Serviços de TI na Prática: Uma abordagem
com base na ITIL – Editora Novatec – 1ª edição, Cap.2 p86, p214 - ISBN: 978-85-7522-106-8.
MANGVE (2009). Portal do Movimento de fomento à Governança Ágil em TIC. Disponível: . Acesso em: 30/09/2009.
MENDEL, T. & PARKER, A. (2005). “Not all ITIL processes are created equal”. Network World, March
16. Disponível em: < http://itpapers.techrepublic.com/abstract.aspx?docid=148585&promo=300
111&tag=wpr.7106,6202>. Acesso em: 02/10/2009.
NORTON, P. (1997). Introdução à Informática. São Paulo: Makron Books.
OGC (2009). Office of Government Commence web site. Disponível em: .
Acesso em: 01/10/2009.
PMI (2008). Guide to the Project Management Body of Knowledge (PMBOK® Guide, 2008, 4th
Edition), Project Management Institute, Newtown Square, PA, vol. 1.
REZZY, O. (2007). Sarbanes-Oxley: Progressive Punishment for Regressive Victimization. Houston
Law Review, Vol. 44, No. 1, p. 95. Disponível em: . Acesso em: 22/01/2009.
SEI. Software Engineering Institute (2009). Disponível em: .
Acesso em: 05/09/2009.
SOX (2002). SARBANES , Paul; OXLEY, Michael. Sarbanes-Oxley Act. Congress of United States
of America, 30/07/2002. Disponível em: . Acesso em: 05/10/2009.
STEINBUCH, K. Informatik: Automatische Informationsverarbeitung. (SEG-Nachrichten)
(Technische Mitteilungen der Standard). Berlin, 1957.
UNESCAP – United Nations (2009). An Introduction to good governance by the United Nations
Economic and Social Commission for Asia and the Pacific. Disponível em: . Acesso em: 22/01/2009.
WEILL, P. & ROSS, J. W. (2005). “GOVERNANÇA DE TI - TECNOLOGIA DA INFORMAÇÃO”. 1ª. Edição. São
Paulo. M.Books do Brasil. ISBN: 8589384780.
Edição 25 - Engenharia de Software Magazine 31

Planejamento e Gerência
Nesta seção você encontra artigos voltados para o planejamento
e gerência de seus projetos de software
Ferramentas para Gerência de Projetos
Conheça as principais características das ferramentas mais populares
Marco Antônio Pereira Araújo
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e
Computação pela COPPE/UFRJ. Especialista em
Métodos Estatísticos Computacionais e Bacharel
em Matemática com Habilitação em Informática
pela UFJF. Professor e Coordenador do curso de Bacharelado
em Sistemas de Informação do Centro de
Ensino Superior de Juiz de Fora. Professor do curso
de Bacharelado em Sistemas de Informação da
Faculdade Metodista Granbery. Professor do curso
de Bacharelado em Ciência da Computação da
Faculdade Governador Ozanam Coelho. Professor e
Diretor do Curso Superior de Tecnologia em Análise
e Desenvolvimento de Sistemas da Fundação Educacional
D. André Arcoverde, Analista de Sistemas
da Prefeitura de Juiz de Fora. Editor da Engenharia
de Software Magazine.
Patrícia Lima Quintão
pquintao@gmail.com
Mestre em Engenharia de Sistemas e Computação
pela COPPE/UFRJ. Especialista em Gerência de
Informática e Bacharel em Informática pela UFV.
Professora e Coordenadora Pedagógica do curso
de Pós Graduação em Segurança da Informação da
Faculdade Metodista Granbery. Professora do curso
de Bacharelado em Sistemas de Informação da Faculdade
Metodista Granbery e do curso de Tecnologia
em Redes de Computadores da Faculdade Estácio
de Sá de Juiz de Fora. Supervisora de Segurança
da Informação da Prefeitura de Juiz de Fora.
Jurema Florinda Lembe de Veiga
jurveiga@hotmail.com
Graduada em Sistemas de Informação pela Faculdade
Metodista Granbery.
No desenvolvimento de um
projeto existe a necessidade de
um gerenciamento de projetos
adequado, aplicando técnicas para o
auxílio do controle das pessoas envolvidas
e dos serviços atribuídos a elas,
preocupando-se com os prazos, custos
e benefícios de cada produto.
Para tanto, o uso de ferramentas para
gerenciamento de projetos é indispensável,
uma vez que contribui para auxiliar
e prover de forma rápida e eficiente as
informações necessárias para o correto
controle e acompanhamento on-line do
trabalho realizado.
Nesse contexto, este artigo destaca
quatro ferramentas para gerenciamento
de projetos existentes no mercado:
o MS Project - um sistema desktop
desenvolvido pela Microsoft; o Gantt
Project - um sistema desktop, gratuito de
32 Engenharia de Software Magazine - Ferramentas para Gerência de Projetos
De que se trata o artigo?
Este artigo apresenta uma visão abrangente das
ferramentas de gerenciamento de projetos MS
Project, Gantt Project, dotProject e Project
Open.
Para que serve?
Apresentar essas ferramentas, destacando como podem
auxiliar e prover de forma rápida e eficiente as
informações necessárias para um efetivo controle e
acompanhamento on-line do trabalho realizado.
Em que situação o tema é útil?
Conhecer ferramentas de gerenciamento de
projetos é cada vez mais importante na medida
em que uma organização avança em seu nível de
maturidade de gerenciamento de projetos. Nesse
contexto, a utilização desse tipo de ferramenta
propicia padronização de métodos e processos e
a disponibilização de informações em tempo real
ao alcance de toda a equipe do projeto, aumentando
a qualidade do gerenciamento e as chances
de alcançar os objetivos traçados.
código aberto; o dotProject - um sistema
desktop e distribuído sob a licença GNU-
GPL; e o Project Open - um aplicativo de

código aberto baseado na Web, ressaltando sua importância
no auxílio para a gerência de projetos.
Serão apresentadas as características principais de cada
ferramenta, como calendários, definição de tarefas, gráficos
utilizados, serviço de envio de e-mail e o tipo de licenciamento,
além de traçar um comparativo entre elas.
Ferramentas para Gerenciamento de Projetos
A adoção de ferramentas de gerenciamento de projetos pelas
organizações efetivamente gera resultados positivos, propiciando
padronização de métodos e processos de trabalho,
além da disponibilização de informações em tempo real ao
alcance de toda a equipe envolvida no projeto, aumentando
a qualidade do gerenciamento e as chances de alcançar os
objetivos traçados.
A seguir são apresentadas de forma sucinta as quatro ferramentas
de gerenciamento de projetos propostas para este
artigo. São elas: o MS Project, o Gantt Project, o dotProject e
o Project Open.
Gantt Project
O Gantt Project é uma ferramenta de gerenciamento de projeto
de acesso gratuito, de código aberto, baseado no gráfico de
Gantt. O software é um sistema desktop que possui interface
de fácil entendimento, conforme mostrado na Figura 1, que
representa a tela inicial do Gantt Project, com todos os seus
recursos iniciais para começar a cadastrar as informações de
um projeto.
Figura 1. Tela inicial do Gantt Project
Esta ferramenta possui o recurso de dividir o projeto em
uma árvore de tarefas e atribuí-las ao responsável de cada
uma, podendo criar dependências entre as tarefas, além da
geração de relatórios nos formatos PDF e HTML, associação
com aplicativos de planilha eletrônica, intercâmbio com o
Microsoft Project, envio de e-mail para pessoas diretamente
envolvidas no projeto, definição de calendários com feriados,
e definição de novos atributos para as atividades.
O Gantt Project está traduzido para o português do Brasil,
e trata-se de uma aplicação desenvolvida em Java e que roda
em Windows, Linux, MacOSX e outros sistemas operacionais
que suportem a linguagem Java. O grande destaque dessa
ferramenta é sua grande facilidade de uso e a clareza da interface.
É recomendada para situações em que a definição e
GEStão DE PRojEtoS
acompanhamento do cronograma é importante, assim como
a necessidade de usá-lo em diversos sistemas operacionais e
sua facilidade de uso.
dotProject
O dotProject é uma ferramenta de gerência de projetos de
software livre e código aberto, distribuído sob a licença GNU-
GPL, ou seja, os seus usuários podem copiar gratuitamente a
ferramenta, fazer a instalação, fazer alterações para melhorá-la
e até mesmo distribuí-la novamente desde que a licença seja
mantida.
O dotProject tem como objetivo proporcionar ao gerente
de projeto uma ferramenta para gerenciar e compartilhar as
tarefas, horários, datas, e-mail e comunicação, dentre outras,
conforme mostra a Figura 2. Esta ferramenta é utilizada em
várias aplicações e ambientes, desde pequenos escritórios,
pessoas que querem gerir a sua própria carga de trabalho,
empresas, departamentos governamentais, organizações sem
fins lucrativos e escolas.
Figura 2. Tela de um projeto no dotProject
Essa ferramenta é baseada na Web, e foi desenvolvida em
PHP, mas também pode ser instalada em Windows, e pode
ser utilizada em diferentes sistemas operacionais. Tem como
diferencial a sua operação via Web e o uso de um banco de
dados SQL, proporcionando bastante flexibilidade no uso
dos dados.
O seu funcionamento requer um servidor Web integrado com
suporte PHP e MYSQL e um navegador Web. O dotProject é
recomendado para departamentos ou empresas em situações
cujo o foco é a agenda de tarefas dos membros da equipe,
gerenciamento da documentação associada aos projetos e
apropriação de horas trabalhadas, com menos ênfase na manipulação
de cronograma.
Project Open
O Project Open é um aplicativo de código aberto baseado na
Web, e é usado por várias empresas que utilizam o sistema para
gerenciar seus negócios. O software permite o monitoramento
Edição 25 - Engenharia de Software Magazine 33

e o planejamento do projeto, permite a utilização de gráficos
de Gantt através de interface com outras ferramentas, como a
Gantt Project, calcula perdas e lucros por projetos e clientes, e
define os orçamentos do projeto baseados em tempo ou custo
absoluto.
O software tem como principais objetivos a administração
dos custos de um projeto e a colaboração entre os membros da
equipe, possuindo uma área colaborativa do tipo Wiki (página
Web editável pelo usuário; ideal para trabalho colaborativo) e
chat. Os projetos podem ser estruturados em qualquer nível
de subprojetos e projetos-tarefas. Alguns destes componentes
são mostrados na Figura 3.
Figura 3. Tela ProjectOpen
Os projetos e subprojetos permitem atribuir permissões de
acesso para os membros envolvidos, enquanto que os projetos/tarefas
servem para monitorar o projeto e para registrar
o avanço e dedicação dos colaboradores. A ferramenta possui
ainda um importador de contatos do Outlook, arquivo de
armazenamento do projeto, chat, notícias, pesquisa de texto
completo, dentre outras funcionalidades.
A ferramenta trabalha com os bancos de dados PostgreSQL
e Oracle, não está disponível em português, mas como se
trata de software livre, pode ser adaptada às necessidades
da empresa. O Project Open é uma ferramenta apropriada
para empresas que estão dispostas a investir em tecnologias
alternativas e procuram um sistema sólido, focado nos custos
e na colaboração das equipes.
Microsoft Project
O Microsoft Project (MS Project) é um software desenvolvido
pela Microsoft, cuja primeira versão foi lançada em 1985, e
desde então tem sofrido inúmeras modificações que vão desde
o layout a requisitos funcionais, aumentado assim a oferta de
serviços e recursos com relação à gerência de projetos.
34 Engenharia de Software Magazine - Ferramentas para Gerência de Projetos
O MS Project é um software desktop desenvolvido para
gerenciar projetos simples ou complexos, e permite planejar,
organizar e gerenciar as tarefas e recursos para alcançar um
objetivo definido com restrições de tempo, custos e recursos.
É uma ferramenta utilizada para o gerenciamento de projetos,
e oferece vários recursos para auxiliar o usuário nessa tarefa,
fornecendo a possibilidade de melhor controle de suas atividades,
mais segurança, agilidade e eficácia em seus processos,
além de possuir uma interface gráfica simples e de fácil uso,
mesmo para quem não conheça a ferramenta (FIGUEIREDO
e FIGUEIREDO, 2001).
O software possui um ambiente padrão de trabalho chamado
Gráfico de Gantt, a partir do qual se pode ter uma visualização
mais ampla e detalhada do projeto, que se baseia no modelo
de diagrama de rede, utiliza tabelas no processo de entrada
de dados, e as relações de procedência entre as tarefas são do
tipo fim-início (a segunda tarefa é iniciada quando a primeira
estiver concluída), fim-fim (as duas tarefas terminam ao mesmo
tempo), início-início (ambas as tarefas iniciam ao mesmo
tempo) e início-fim (acontece quando o término de uma tarefa
depende do início da tarefa seguinte).
O MS Project permite que as tarefas ocorram de forma recorrente,
possui um recurso que permite agrupar, classificar e
filtrar tarefas, um conjunto padrão de relatórios, mas o usuário
pode criar seus próprios relatórios, e permite a inclusão de
campos do usuário.
O software permite ainda que sejam definidos a semana e
expediente de trabalho, os feriados e o uso de datas programadas
para as tarefas. Os recursos, assim como os custos do
projeto, estão ligados diretamente às tarefas. Como padrão, o
MS Project agenda todas as tarefas a começarem na data de
início do projeto (a menos que se especifique algo diferente),
e calcula a data de término como base na última tarefa a ser
concluída.
Outras características principais são a capacidade de gerenciar
e entender efetivamente as agendas do projeto, obter
produtividade rapidamente, aproveitar dados existentes, criar
gráficos e diagramas profissionais, comunicar informações
com eficiência, obter maior controle sobre os recursos e finanças,
acessar rapidamente informações diversas, controlar
os projetos e personalizar a ferramenta de acordo com suas
necessidades, além de obter ajuda quando necessário.
Quadro Comparativo entre as Ferramentas
Na Tabela 1 é feito um comparativo das ferramentas apresentadas,
no qual é possível ver as informações básicas de
cada uma delas.
Percebe-se que as quatro ferramentas possuem igualmente
recursos de calendário, relatórios e envio de e-mail. Enquanto
o MS Project possui tipo de licença paga, os outros três possuem
licença gratuita. Quanto à interface, a do Project Open
é de uso mais complexo, comparada às demais. Em relação à
instalação, o Gantt e o MS Project são mais simples. Gantt Project
e MS Project são acessíveis através do desktop, enquanto
dotProject e Project Open necessitam de um servidor Web. Por

RECURSOS
FERRAMENTA
GEStão DE PRojEtoS
Gantt Project dotProject Project Open MS Project
Interface Gráfica Simples Simples Complexa Simples
Instalação Simples Complexa Complexa Simples
Tipo de Licença Gratuita Gratuita (GNU-GPL) Gratuita Paga
Acessibilidade Desktop Web Web
Gantt
Desktop
Intercâmbio MS Project Não
Project Gantt Project
Gráfico Utilizado Gráfico de Gantt Gráfico de Gantt Não Gráfico de Gantt
Calendário Sim Sim Sim Sim
Relatórios Sim Sim Sim Sim
Envio de e-mail Sim Sim Sim Sim
tabela 1. Quadro comparativo entre as ferramentas
fim, enquanto o Project Open não disponibiliza diretamente
o Gráfico de Gantt para a realização de sequência de tarefas,
este gráfico é utilizado pelas três outras ferramentas.
Um exemplo prático
Agora que os conceitos relativos às ferramentas já foram
apresentados, poderemos entender como eles são aplicados
na prática através de um projeto no MS-Project.
Como o gerenciamento de projetos envolve muitas etapas,
o gerente de projetos deve saber controlar todas as etapas do
projeto desde o planejamento até a sua conclusão. O MS Project
vem auxiliar o gerente no seu trabalho, possibilitando planejar,
controlar e comandar o projeto de forma rápida e eficiente,
aumentando as chances de sucesso e oferecer um produto de
qualidade ao usuário final.
A Figura 4 destaca os principais elementos do ambiente MS
Project:
• Menu Principal: é a barra que contém todos os comandos
do MS Project.
• Barra de Ferramentas: é a barra que contém todos os comandos
mais utilizados, e pode ser personalizada pelo usuário de
acordo as suas necessidades.
• Barra de Tarefas: contém opções para as tarefas mais utilizadas
pelo usuário.
• Área de Tabelas: é onde são cadastradas as tarefas do projeto,
com nome, duração, data de início e de fim, e tarefas de
precedência.
• Gráfico de Gantt: nessa área aparecem as visualizações
gráficas das tarefas à medida que são descritas e vinculadas
umas às outras.
Iniciar um Projeto
Antes de iniciar o projeto, é necessário conhecer alguns
conceitos básicos e importantes da ferramenta que ajudarão
a entendê-la melhor:
• Tarefas são todas as fases do projeto, e possuem código, nome,
duração, tarefa precedente, data de início e fim, e podem ser
do tipo fim-fim, fim-início, início-início e início-fim.
• Recurso é toda pessoa que trabalha diretamente no
projeto.
• Custo é o valor gasto na compra de material que será usado
no projeto, e deve ser definido diretamente na tarefa.
• Duração é o tempo necessário para completar a tarefa, que
pode exigir horas, dias, semanas ou meses, e quanto maior o
tempo, maior será o custo do projeto.
Figura 4. Ambiente do MS Project
Para criação do projeto, será usado o exemplo da Tabela 2,
que se refere às etapas de construção da fundação de uma casa.
Este exemplo está apresentado em dias, mas poderia estar em
horas, semanas ou meses.
Definir o Projeto
Para criar o projeto, basta clicar em Define the Project (Definir
o Projeto) na barra de tarefas. O programa irá abrir uma tela
pedindo que seja informada a data de início do projeto. Como
Edição 25 - Engenharia de Software Magazine 35

padrão, o MS Project usa a data atual como data de início
do projeto, caso contrário, outra data deve ser informada. A
Figura 5 apresenta o calendário para escolha da data de
início do projeto.
Figura 5. Definir a data de início do projeto
CÓDIGO NOME DA TAREFA DURAÇÃO PRECEDÊNCIA
1 Preparar o terreno 1d 0
2 Desenhar a planta no chão terreno 1d 1
3 Cavar o terreno conforme o desenho 2d 2
4 Preparar a massa 1d 3
5 Colocar a massa nos buracos 2d 4
6 Esperar a massa secar 3d 5
7 Fim fundação 0d 6
tabela 2. Tarefas do projeto
Definir as Horas de Trabalho
Depois de definida a data de início, pode-se definir as horas de
trabalho clicando em Define General Working Times (Definir Horas
de Trabalho) na barra de tarefas, conforme mostra a Figura 6.
Figura 6. Definir as horas de trabalho do projeto
Como padrão, o MS Project usa o calendário de oito horas
diárias de trabalho de segunda a sexta-feira, contudo, as horas
de trabalho podem variar de acordo as necessidades do projeto,
36 Engenharia de Software Magazine - Ferramentas para Gerência de Projetos
ou seja, fica a critério do gerente definir as horas e os dias
de trabalho. Nessa fase são definidos ainda os dias de folga,
feriados, semanas de trabalho, que são editáveis diretamente
no próprio calendário ou ainda criar um novo calendário de
acordo as necessidades do projeto.
Listar as Tarefas do Projeto
Conforme descrito anteriormente, tarefas são todas as fases
do projeto e podem ser do tipo fim-fim, fim-início, início-fim e
início-início. Para listar as tarefas basta clicar em List the Tasks
in the Project (Listar as Tarefas do Projeto) na barra de tarefas,
depois é só começar a cadastrar as tarefas. A Figura 7 mostra
as tarefas do projeto que foram cadastradas.
Figura 7. Listar as tarefas do projeto
À medida que as tarefas do projeto forem sendo listadas na
área correspondente, elas serão representadas graficamente
no gráfico de Gantt de acordo com a sua duração, conforme
mostra a Figura 8.
Figura 8. Tarefas do projeto e gráfico de Gantt
O próximo passo, dentro da fase de listar tarefas, é organizar
o projeto de acordo com a hierarquia das tarefas; para
isso, é necessário selecionar a opção Organize Tasks Into Phases
(Organizar as Tarefas em Fases), e selecionar as tarefas que se
tornarão subtarefas. Com as tarefas selecionadas, clique na seta
que se encontra no lado esquerdo da Barra de Tarefas, que elas
se ajustarão automaticamente (Figura 9).
Figura 9. Hierarquia das tarefas

As datas das tarefas podem ser alteradas sempre que necessário
sem afetar o projeto, pois o Project reagendará automaticamente
a duração das tarefas caso a data de início, a duração
ou data de término forem alteradas.
Criar Dependência Entre as Tarefas
Após seguir todos os passos descritos anteriormente, devese
criar as dependências entre as tarefas. Na Barra de Tarefas
deve-se clicar na opção Schedule Tasks (Dependência Entre
Tarefas), e será aberta uma lista explicando os tipos de dependências
que o Project oferece. Após isso, devem-se selecionar
as tarefas dependentes e clicar no tipo de dependência desejada.
Dessa maneira, as tarefas se ajustarão automaticamente
no gráfico de Gantt, conforme a Figura 10.
Para quebrar a dependência já criada, basta selecionar as
tarefas desejadas e clicar no ícone de quebra de dependência
que se ajustará automaticamente no gráfico. Com a criação
das dependências entre as tarefas, é possível ter uma visão
mais abrangente do planejamento do projeto e saber também
quantos dias durará a sua execução.
Figura 10. Dependência entre tarefas
Adicionar Recursos ao Projeto
Após a criação das tarefas, pode-se adicionar os recursos às
tarefas para que elas possam ser executadas. Para isso, deve-se
clicar na opção Resource Sheet na Barra de Tarefas, que abrirá
uma tela com todas as informações dos recursos. A Figura 11
mostra alguns recursos inseridos com as informações básicas,
tais como nome, tipo do recurso, unidade máxima, custo por uso
do recurso, dentre outras informações que podem ser editáveis
pelo usuário.
Figura 11. Adicionar recursos ao projeto
Com os recursos adicionados ao projeto, o próximo passo é
adicioná-los às tarefas. Para isso, basta dar um duplo clique
na tarefa em que se quer adicionar o recurso, em seguida, o
GEStão DE PRojEtoS
programa abrirá uma tela com informações sobre a tarefa. Na
aba Resources (Recursos), em Resources Name (Nome do Recurso)
é possível escolher o recurso inserido anteriormente para a
tarefa desejada, e também outras opções oferecidas. Os recursos
alocados às tarefas aparecerão no gráfico de Gantt, conforme a
Figura 12.
Figura 12. Recursos alocados as tarefas
Após a conclusão de todo o planejamento descrito, deve-se
salvar as informações do projeto que serão utilizadas em sua
fase de execução. Para isso, basta clicar em File (Arquivo) no
menu principal, e em seguida clicar Save (Salvar).
Salvar a Linha de Base do Projeto
A linha de base do projeto é uma maneira de salvar o
projeto a fim de fazer futuras comparações, ou seja, se salva
o projeto de forma que no decorrer, ou término do projeto,
seja possível fazer uma comparação do previsto/realizado
do planejamento inicial com o atual. Como exemplo, podese
usar o projeto simulado neste estudo, o custo inicial da
areia, que poderia aumentar por motivos de inflação, fazendo
assim com que ocorram mudanças no planejamento
inicial do projeto.
Para salvar a linha de base do projeto, basta clicar em
Track (trilha), em seguida, escolher a opção Save a Baseline
Plan to Compare With Later Versions (Salvar Linha de Base do
Projeto para Comparar com Futuras Versões). Na barra de
tarefas aparecerá uma tela explicando por que é importante
fazer esse procedimento, em seguida clica-se no botão Save
Baseline (Salvar Linha de Base). A Figura 13 mostra os procedimentos
descritos.
É importante lembrar que o MS Project permite salvar até
onze linhas de base do projeto. Na próxima vez que o projeto
for aberto, o Project irá perguntar se é necessário salvar uma
nova linha de base, ou atualizar a base já existente do projeto,
pois é possível que o anterior tenha ficado obsoleto.
Diagrama de Rede e Uso de Tarefas
No MS Project, o projeto pode ser visualizado de várias formas,
uma delas é através do Diagrama de Rede, ou Diagrama
de Precedências, que exibe a precedência entre as tarefas. Para
acessar o diagrama, clique em Network Diagram (Diagrama de
Rede) na barra de modos. Os passos descritos estão demonstrados
na Figura 14.
No diagrama de rede é possível visualizar informações como
a data de início e fim de cada tarefa, a duração, bem como o
responsável por ela.
Edição 25 - Engenharia de Software Magazine 37

Outra forma de visualização do projeto é através do Uso
das Tarefas, em que é possível visualizar com mais detalhes
as informações de cada uma delas. Esse recurso permite
uma visualização mais abrangente da alocação dos recursos
disponíveis para a execução de cada tarefa. Para acessar esse
recurso, basta clicar em Task Usage (Uso da Tarefa) na Barra
de Tarefas, em seguida aparecerá a tela com as informações
de cada tarefa. Como exemplo, pode-se observar a tarefa seis,
na Figura 15, cujas informações são as seguintes: estão alocados
João e Tiago, cada um com total de horas trabalhadas
de 16h, sendo 8 horas diárias totalizando 32h de trabalho
no projeto, a duração da tarefa que é de dois dias, sendo que
começa no dia treze e termina no dia dezesseis.
Figura 13. Salvar linha de base
Figura 14. Diagrama de rede
O MS Project deixa a critério do usuário o acréscimo de
outras colunas, além das consideradas padrão. Para acrescentar
outra coluna, basta selecionar uma coluna, clicar o botão
direito do mouse e escolher a opção Insert Column (Inserir
Coluna). O programa abrirá uma janela com várias opções de
campos, como mostrado na Figura 16. Após isso, se escolhe a
coluna que se deseja acrescentar e clica-se em ok.
38 Engenharia de Software Magazine - Ferramentas para Gerência de Projetos
Emitir Relatórios do Projeto
Os relatórios são de grande importância para o projeto, pois
através deles é possível ter uma visão geral do projeto, e explicar
aos participantes algumas informações que não aparecem
nos diagramas. Para acessar as opções de relatórios deve-se
clicar em Report (Relatório), em seguida selecionar a opção Reports
(Relatórios) que abrirá uma janela como a da Figura 17.
Figura 15. Uso das tarefas
Figura 16. Adicionar coluna
Figura 17. Emitir relatório
Como se pode observar pela figura, são várias as opções de
relatórios que o Project pode emitir, dentre elas: Overview (Visão
Geral), na qual o usuário tem uma visão geral do projeto;
Current Activities (Tarefas Atuais), que dá uma visão das tarefas
sendo executadas; Costs (Custos), que dá uma visão do custo
geral do projeto e Assignments (Atribuições), que oferece a visão
das atribuições de cada recurso envolvido no projeto.

Conclusão
As ferramentas apresentadas vieram para ajudar os gerentes a
ter um melhor controle do andamento de seus projetos. Neste
artigo, foi apresentada uma visão abrangente das ferramentas
de gerenciamento de projetos MS Project, Gantt Project, dotProject
e Project Open. Alem disso, com um pouco mais de
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
COMIDA
Dê seu Feedback
sobre esta edição
DotProject - http://dotproject.net/
GEStão DE PRojEtoS
detalhas, observamos o uso da ferramenta MS Project, que é
um poderoso instrumento na gerência de projetos.
Referências
FIGUEIREDO, Francisco Constant de; FIGUEIREDO, Hélio Carlos. Dominando gerenciamento de
projetos com MS Project 2000. Rio de Janeiro: Ciência Moderna, 2001.
Microsoft Project - http://www.microsoft.com/brasil/pr/ms_project.htm
Open Project - http://www.project-open.org
Gantt Project - http://ganttproject.biz/
Existem coisas
que não conseguimos
ficar sem!
...só pra lembrar,
sua assinatura pode
estar acabando!
Renove Já!
www.devmedia.com.br/renovacao
Para mais informações:
www.devmedia.com.br/central
Edição 25 - Engenharia de Software Magazine 39

Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Reportando de forma simples os resultados
dos testes
Técnicas simples e objetivas para reportar os resultados das atividades de testes
Daniel Scaldaferri Lages
dlages@gmail.com
Possui MBA em Gerência de Projetos pela
Fundação Getúlio Vargas, é pós-graduado em
Gerência de T.I. pela Universidade FUMEC e Bacharel
em Ciência da Computação pela UFMG.
Atualmente é Coordenador da equipe de Quality
Assurance da CPM Braxis, filial BH. Sua experiência
profissional inclui o cargo de Analista
de Testes no Synergia (núcleo de engenharia
de software do Departamento de Ciência da
Computação da UFMG), Gerente da fábrica de
software na Unitech (hoje CPM Braxis) e docência
no curso de graduação de Sistemas de
Informação na PUC-MG. Possui a certificação
ITIL para gerenciamento de serviços de T.I. É
certificado em testes de software pela ISTQB e
em qualidade de software pela IBM.
Para todas as atividades planejadas
e executadas dentro de um
projeto, seja ele de desenvolvimento
de software, ou de qualquer outra
natureza, existe a necessidade de que o
progresso das atividades seja reportado
e os resultados finais ou parciais sejam
apresentados às pessoas envolvidas.
São vários os interessados nessas informações,
entre eles, o cliente, o gerente
do projeto, o patrocinador e as equipes
responsáveis pelas demais etapas do
processo de desenvolvimento do software.
Com as informações do progresso,
seja um status report diário, semanal, ou
com alguma outra periodicidade que
seja interessante para o projeto (a periodicidade
ideal irá depender da duração
do projeto e do custo do controle, pois
quanto maior o controle maior o custo),
40 Engenharia de Software Magazine - Reportando de forma simples os resultados dos testes
De que se trata o artigo?
Este artigo apresenta uma maneira simples e objetiva
para reportar os resultados dos testes funcionais,
sejam eles diários ou finais, assim como os
benefícios que podem ser extraídos a partir das informações
e estatísticas geradas por um resultado
ou por um conjunto deles.
Para que serve?
O artigo poderá auxiliar, de uma maneira prática, os
profissionais de testes que necessitam reportar os
seus resultados, apresentando exemplos simples e
de fácil implementação, para que possam agregar
ao seu processo. Serve também para mostrar os
motivos e benefícios do reporte dos resultados.
Em que situação o tema é útil?
Com os recursos do flashback é possível:
Para empresas e profissionais que possuem
interesse em criar mecanismos (ou apenas
complementá-los) para reportar os resultados
das atividades de testes, juntamente com a definição
do conteúdo necessário e suficiente.
os envolvidos terão base para a tomada
de decisões, uma vez que será possível
comparar o status atual com o planejado.

Já as informações referentes aos resultados servirão como
lições aprendidas (positivas ou negativas) para os próximos
projetos ou para as próximas fases do projeto.
Para as atividades de Teste de Software não é diferente. De
acordo com o Quality Assurance Institute [QAI] os testadores
devem possuir habilidades para reportarem suas atividades
de forma clara e precisa. Eles devem se basear no Plano de Testes,
pois as informações apresentadas não podem estar soltas,
e sim dentro de um contexto, que envolve algumas variáveis
importantes, como prazo, esforço, complexidade, ambiente,
escopo, equipe etc. Essa questão é reforçada por [MARICK]
no seu artigo “Classic Testing Mistakes”, que classifica como
um erro clássico os gráficos e relatórios que são apresentados
fora de um contexto.
Um exemplo trivial é apresentado através da comparação
entre dois projetos, A e B. Ambos apresentam percentual de
conclusão igual a 80%. Mas esse valor não diz nada sozinho. De
nada adianta apresentar o percentual de conclusão dos testes
se não sabemos qual o prazo para conclusão, pois nada indica
se essa data será ou não cumprida. Para ajudar a encontrar
um indício das chances de sucesso, os gráficos da Figura 1
apresentam duas novas variáveis: a data final e o histórico do
progresso dos testes. Com essas informações a chance de se
“prever o futuro” aumenta. É possível deduzir que o projeto A
não cumprirá o prazo, pois resta apenas um dia e o histórico
do progresso é de 5% ao dia. Já o projeto B, de acordo com
o mesmo histórico de progresso de 5% ao dia, será possível
chegar aos 100% no dia 16/12.
Figura 1. Progresso dos testes para os projetos A e B
Mas existem outras variáveis que não são apresentadas no
gráfico e que podem mudar todo o diagnóstico realizado. Por
exemplo, pode ser que os casos de uso a serem testados no projeto
B ainda não estejam liberados para testes, ou seja, ainda não
foram construídos. Só serão liberados na manhã do dia 16/12.
Considerando as mesmas condições de esforço de execução
dos testes (número de testadores) e o progresso de 5% ao dia,
este cenário indicará um atraso para o projeto B. Desta forma,
é interessante que esse gráfico seja apresentado juntamente
com as informações de liberação de casos de uso para testes.
Outra variável é o esforço de execução dos testes. Para o projeto
A foram disponibilizados mais três testadores. Assim, será
possível atingir os 100% no dia 13/12, levando em consideração
que é possível dividir os testes entre os testadores.
Outras variáveis ainda podem influenciar os prognósticos,
como por exemplo, a complexidade e a qualidade dos casos
de uso a serem testados. Nada impede que os casos de uso do
Projeto B a serem liberados sejam triviais e possam ser testados
VALIDAção, VERIFICAção & tEStE
rapidamente, principalmente se nenhuma falha for encontrada.
O inverso poderá se revelar no Projeto A, que mesmo com
muitos testadores, não conseguirá finalizar os testes no prazo
definido devido à complexidade dos casos de uso.
A mensagem principal aqui é que os relatórios e gráficos
devem estar dentro de um contexto muito bem definido,
apresentando o maior número de informações (variáveis)
possíveis.
De acordo com o [QAI] existem duas categorias principais de
relatórios que podem ser apresentados: relatórios correntes
dos testes e relatórios finais dos testes. A primeira categoria
trata-se da apresentação do andamento atual dos testes, ou
seja, resultados apresentados durante as atividades de testes.
Já a segunda, como o próprio nome diz, no final de uma atividade
de testes. Cada uma das categorias será apresentada
nos próximos itens.
Relatório Corrente dos Testes
Esta categoria de relatórios é bastante importante para o
gerenciamento do projeto. Os responsáveis pela tomada de
decisões precisam ser munidos de informações do andamento
e da qualidade do projeto. Nada mais interessante do que
obtê-las através da perspectiva dos testadores. Esses relatórios
devem ser gerados com uma periodicidade que seja interessante,
servindo como ferramenta pró-ativa para o projeto. O status
report não precisa ser complexo, mas precisa ser claro, objetivo
e, como já dito, contextualizado. As sugestões e os exemplos
apresentados a seguir consideram uma frequência diária.
Antes de seguir, é bom frisar que, apesar de estarem inseridos
dentro desta categoria, os relatórios individuais sobre as
falhas encontradas durante a execução dos testes que estão
em processo de análise/correção não serão abordados nesse
artigo. Apenas um resumo geral do conjunto das falhas é
informado no status report. Boas práticas para o registro e
acompanhamento das falhas rendem assunto suficiente para
outro artigo inteiro.
Status Report Diário
Como já informado, o objetivo principal desse status report é
munir os líderes, gerentes e demais envolvidos de informações
sobre a situação atual da atividade. É um retrato da atividade.
Com ele torna-se possível comparar a situação atual com a
planejada. Caso exista uma longa distância entre elas, ou a
presença de sintomas de potenciais problemas, ações de modo
a contorná-los e eliminá-los devem ser tomadas. Abaixo, são
apresentados e exemplificados alguns itens sugeridos para a
composição do status report. Tudo que será apresentado são
sugestões, que podem ou não serem aceitas, ou adaptadas em
outros processos.
Percentual de Conclusão
Este é o item principal do status report. Todos os demais ajudarão
a contextualizá-lo. Trata-se do percentual de conclusão
da atividade. A Tabela 1 apresenta uma planilha que mostra o
percentual de conclusão para a atividade de Elaboração de Casos
Edição 25 - Engenharia de Software Magazine 41

de Testes de um projeto fictício, que contém cinco casos de uso.
Para que o percentual seja bem preciso, é sugerido que os casos
de uso sejam detalhados em termos dos itens que deverão ser
testados. No exemplo, os itens são: Fluxo Alternativo, Fluxo de
Exceção, Requisitos Especiais e Regras de Negócio. Para o UC_01
– Efetuar Conferência existem 14 itens ao todo: 3 fluxos alternativos,
4 fluxos de exceção, 1 requisito especial e 6 regras de
negócio. A coluna CTs Elaborados mostra a quantidade de itens
que já tiveram seus casos de testes elaborados. Para o UC_01,
foram finalizados 7 casos, o que significa 50% de conclusão
deste UC. O mesmo cálculo é feito com os demais casos de uso,
e com a atividade como um todo.
A Tabela 2 sugere uma planilha para apresentar o percentual
de conclusão da Execução dos Casos de Testes. Além de mostrar o
percentual de conclusão, levando em conta a unidade “Casos
de Testes”, apresenta também o número de falhas registradas
por cada caso de uso.
Status de Elaboração de Casos de Testes
Nome do Sistema Sistema Fictício
Número da Demanda 30450
Tipo do teste Teste de Sistema
Data 20/3/2010
Responsável Daniel Lages
Nome UC Fluxo Alternativo Fluxo de Exceção Requisitos Especiais Regra de Negócio CTs Elaborados Perc. Por UC
UC_01 - Efetuar Conferência 3 4 1 6 7 50,00%
UC_02 - Cadastrar Oportunidades 2 2 0 5 8 88,89%
UC_03 - Alterar Oportunidades 2 4 0 6 12 100,00%
UC_04 - Criar Atividades 3 3 0 5 11 100,00%
UC_05 - Enviar Oportunidades 5 5 2 10 5 22,73%
Total 15 18 3 32 43
Percentual Geral Casos de Uso Elaborados 63,24%
tabela 1. Planilha de percentual de conclusão da atividade de Elaboração de Casos de Testes
Status de Execução de Testes
Nome do Sistema Sistema Fictício
Número da Demanda 30450
Tipo do teste Teste de Sistema
Data 10/4/2010
Nome dos testadores Karla Lages
Nome UC Nº CTs
EXECUTADOS COM
SUCESSO
NÃO EXECUTADOS ou COM
42 Engenharia de Software Magazine - Reportando de forma simples os resultados dos testes
FALHAS
Falhas
Pendentes
Perc. Por UC
UC_01 - Efetuar Conferência 14 10 4 3 71,43%
UC_02 - Cadastrar Oportunidades 9 9 0 0 100,00%
UC_03 - Alterar Oportunidades 12 4 8 2 33,33%
UC_04 - Criar Atividades 11 5 6 2 45,45%
UC_05 - Enviar Oportunidades 22 0 22 0 0,00%
Total 68 28 40 7
Percentuais 41,18% 58,82%
tabela 2. Planilha de percentual de conclusão da atividade de Execução dos Testes
A Figura 2 mostra outra forma de apresentação do percentual
de conclusão da execução dos testes extraídas da
ferramenta Testlink. O primeiro gráfico mostra que 29% dos
casos de testes foram executados com sucesso e 5% executados
com falhas. Os demais 66% ainda não foram executados.
No segundo gráfico, 1% dos casos de testes está bloqueado,
ou seja, por algum motivo (por exemplo, falta de dados na
base ou dependência da correção de alguma falha) não é
possível executá-los. A visualização desses gráficos é melhor.
Entretanto, não exibem informações por caso de uso, e sim
de forma geral.
A Figura 3 apresenta os dados do primeiro gráfico de forma
tabular, complementando com informações sobre a quantidade
de casos de testes em cada situação em valores absolutos.
Como pode ser visto, são 58 casos de testes. Desses, 17 foram
executados com sucesso, 3 falharam e 38 ainda não foram
executados.

Figura 2. Gráfico de pizza para conclusão da atividade de execução dos
testes
Figura 3. Forma tabular para conclusão da atividade de execução dos testes
Como ressaltado na introdução, apenas essas informações
sozinhas não dizem muita coisa. A seguir, os demais itens que
ajudam na contextualização.
Progresso das atividades de Testes
O progresso dos testes mostra a evolução da atividade ao
longo dos dias reservados para a realização da mesma. A Figura
4 apresenta o gráfico gerado no dia 18/03, um dia antes
do prazo final, 19/03. É possível perceber que essa atividade
transcorreu sem muitos problemas, com boa evolução até o dia
15/03. Apenas um aperto entre os dias 15/03 e 16/03, e também
entre 17/03 e 18/03. A partir dessa informação, é possível agir
proativamente devido à identificação de uma evolução de
apenas 1% do dia 17/03 para 18/03. A pouca evolução ao final
da atividade é natural, uma vez que problemas encontrados ao
longo da atividade se tornam pendências que são resolvidas
somente na conclusão, gerando esse comportamento.
Figura 4. Progresso das atividade de testes com boa evolução
Já a Figura 5 apresenta um cenário de alerta, pois ocorreu um
pequeno atraso no início da atividade. Apesar do atraso, houve
uma boa evolução de 58% em quatro dias (média de 14,5% ao
dia). Se essa média continuar assim, será possível concluir a
atividade no prazo final, pois no dia 19/03 teríamos 72,6%; dia
22/03, 87,1%, e por fim, 100% no dia 23/03.
A Figura 6 apresenta um cenário onde será praticamente
impossível realizar a atividade dentro do prazo determinado.
VALIDAção, VERIFICAção & tEStE
Faltando apenas dois dias para terminar, apenas 19% da atividade
foi concluída. Neste exemplo, já no primeiro dia era
possível observar sintomas de potenciais problemas. Pois como
são apenas seis dias para executar a atividade, era esperado
no mínimo 17% de conclusão. Portanto, alguma ação já teria
que ter sido tomada no primeiro dia.
Figura 5. Progresso das atividades de testes com atraso no início da tarefa
Figura 6. Progresso das atividades de testes com atraso previsto
Durante a execução da atividade de testes pode ser que novos
casos de uso sejam acrescentados ou removidos, resultando
no aumento ou diminuição de casos de testes. Como consequência,
pode ser que o percentual de conclusão diminua de um
dia para o outro. Nesse caso, basta colocar uma observação no
relatório para que a diferença negativa seja justificada. Esse
relatório pode ser aplicado tanto para execução dos testes
quanto para a elaboração dos casos de testes.
Progresso de Liberação dos Casos de Uso
É bastante interessante para os gerentes controlarem o progresso
da liberação dos casos de uso para execução dos testes.
Com esse controle é possível comparar o percentual concluído
em relação ao percentual disponibilizado. É uma situação
diferente para o projeto, por exemplo, quando 40% dos testes
estão concluídos com 100% dos casos de uso disponíveis, de
quando 40% dos testes estão concluídos com apenas 42% de
casos de testes disponíveis. Para facilitar essa comparação deve-se
converter os casos de uso liberados em casos de testes liberados.
Por exemplo, caso existam 10 casos de uso no projeto, sendo que
os cinco primeiros possuem 5 casos de testes cada, os outros
cinco possuem 10 casos de testes cada, e apenas os 4 primeiros
casos de uso estejam liberados, teríamos 26,67% de casos de
testes disponíveis. Conta: (4*5) / (5*5 + 5*10) * 100. No primeiro
caso (100% disponível) é possível, caso o gerente opte e possua
testadores disponíveis, adiantar os testes, uma vez que existem
Edição 25 - Engenharia de Software Magazine 43

funcionalidades prontas a serem testadas. No segundo caso (42%
disponível), mesmo que o gerente possua dois ou três testadores
disponíveis, de nada adianta, pois não existem funcionalidades a
serem testadas, apenas 2%. Caso as próximas liberações estejam
planejadas para uma data distante, é sinal que o testador ficará
ocioso nesse projeto (logicamente, dependendo da quantidade
de falhas registradas que terá que verificar).
Como foi demonstrado acima, a informação gerada pela
comparação entre o que foi realizado e o disponível é bastante
importante. Esse controle da liberação dos casos de uso é
bastante semelhante ao do progresso das atividades de testes.
Da mesma forma que se controla a disponibilidade dos casos
de uso implementados para execução dos testes, pode-se controlar
a disponibilidade dos casos de uso especificados para
elaboração dos casos de testes. A Figura 7 apresenta o par de
gráficos que mostra a evolução do percentual de conclusão dos
testes e a evolução do percentual de liberação de casos de uso,
já convertidos em casos de testes.
Figura 7. Gráfico de Evolução de Testes comparado à Liberação de Casos
de Testes
Logicamente outras opções de gráficos podem ser utilizadas
para facilitar a comparação, como o apresenta a Figura 8.
Figura 8. Gráfico unificado de Evolução de Testes X Liberação de Casos
de Testes com pouca diferença entre liberados e executados
A comparação mostra que o percentual dos casos de testes realizados
está bastante próximo ao dos casos de testes possíveis
44 Engenharia de Software Magazine - Reportando de forma simples os resultados dos testes
de serem executados, ou seja, dos liberados. A diferença recai
sobre os casos de testes que falharam, estão bloqueados, ou realmente
ainda não foram executados. A informação sobre essa
diferença poderá ser obtida no gráfico apresentado na Figura 2.
Nessa situação, não é possível adiantar as atividades de testes.
Provavelmente o projeto irá atrasar, pois faltando apenas cinco
dias dos 17 planejados, apenas 55% dos casos de uso foram
implementados. A Figura 9 apresenta um cenário que, desde
o primeiro dia, os testes poderiam ter sido adiantados.
Figura 9. Gráfico unificado de Evolução de Testes X Liberação de Casos
de Testes com grande diferença entre liberados e executados
Resumo dos Incidentes
A quantidade de falhas registradas, e suas características, como
por exemplo, criticidade, prioridade e localização, são fatores importantes
e que influenciam o rumo da execução dos testes (em
empresas responsáveis, o rumo do projeto como um todo). Caso
muitas falhas estejam registradas, ou poucas falhas, mas sendo
críticas, a entrega do produto deverá ser renegociada, ao invés de
se fazer vista grossa para as falhas apenas para cumprir o prazo.
No momento da homologação ou já em operação, a empresa
poderá pagar caro o preço dos irresponsáveis. Vale ressaltar que
quanto mais tarde a falha for encontrada, mais custosa torna-se a
correção. Portanto, é bastante recomendado relatar no status report
a quantidade atual das falhas, assim como sua criticidade, e outras
informações importantes para o projeto. A Figura 10 exemplifica
esse resumo, informando a situação das falhas por status e também
por gravidade. A ferramenta utilizada é o MANTIS.
Figura 10. Quadros retirados do MANTIS com informações das falhas Por
Status e Por Gravidade

O primeiro quadro mostra: a quantidade de falhas atribuída
a algum desenvolvedor; a quantidade de falhas que já foi
admitida por um desenvolvedor (pode-se estabelecer que
este status indique que as falhas já estão sendo corrigidas); a
quantidade de falhas que já foram corrigidas e estão prontas
para verificação da correção; além da quantidade que já foi
verificada, e, portanto, fechada. Já o segundo quadro detalha
a quantidade de falhas nos status Aberto, Resolvido e Fechado
por gravidade.
Gráfico de Correção Acumulado
Outra informação importante a respeito das falhas registradas
é a situação da correção dos mesmos. O ideal é que
essa atividade não se acumule, pois a correção, como é uma
intervenção em código, pode desmascarar novas falhas ou
impactar outras partes do sistema. E se feita muito tarde,
não existirá tempo hábil para novas descobertas. Além disso,
falhas registradas podem impedir a coleta das evidências. Se
a correção for tardia, acumula-se a verificação e a coleta das
evidências. O responsável pelos testes e o gerente do projeto
deverão estabelecer a frequência e o tempo destinado para a
correção das falhas ao longo da execução dos testes, para que
os problemas citados acima não aconteçam.
O gráfico de correção acumulado ajudará a monitorar a
correção das falhas registradas. A Figura 11 exemplifica
a evolução da correção das falhas de um projeto, cuja
ferramenta de gerenciamento de incidentes utilizada é o
MANTIS.
Figura 11. Gráficos retirados do MANTIS com a evolução da correção das
falhas
VALIDAção, VERIFICAção & tEStE
O eixo x representa o tempo, ou seja, os dias. O eixo y representa
a quantidade de falhas registradas. No primeiro dia de
testes, dia 07/03 foram registradas 17 falhas. O gráfico apresenta
três linhas. São elas: azul, que representa a quantidade
acumulada de falhas registradas ao longo dos dias; preta, que
representa a quantidade de falhas corrigidas; e vermelha, que
é a diferença entre a linha azul e preta, representando as falhas
que ainda não foram corrigidas.
O ideal é que a linha preta siga de perto a linha azul, mantendo
a vermelha oscilando com amplitude baixa no gráfico. Isso
significa que a correção está sendo feita, sem acúmulo. Pelo
último gráfico, é possível perceber que até o dia 28/03 nunca
mais do que 20 falhas ficaram sem corrigir, e que nesse dia, já
existem quase 30 falhas ainda não corrigidas. Um alerta para o
projeto. Outra informação interessante que pode ser percebida
é que os dias 14/03, 18/03 e 20/03 foram os dias onde a correção
estava mais “em dia”, que são os vales da linha vermelha, ou
o quase encontro das linhas preta e azul.
Registro de Ocorrências
Este tipo de relatório nada mais é que um diário de bordo da
atividade que está sendo realizada. O objetivo é registrar os
eventos que impactam o andamento da atividade, principalmente
os negativos. Os que impactam positivamente também
podem ser registrados. Eventos como “paradas” do ambiente
de testes, não existência de dados específicos na massa de
dados, inexistência de recursos para correção das falhas registradas,
bugs de travamento que impedem o prosseguimento da
atividade, etc. são comuns nesse relatório. Ou seja, tudo que
atrasa o andamento da atividade. Cada ocorrência registrada
deverá conter a data e a hora do registro, assim como o responsável
pelo seu cadastramento. O ideal é que não se escreva
muito, apenas uma linha de texto, no máximo.
O relatório gerado a partir dessas ocorrências é bem interessante,
pois apresenta os principais eventos ocorridos durante
a atividade, um histórico de onde é possível tirar conclusões
dos pontos que impactaram o andamento da atividade. Serve
para os testadores se resguardarem, pois os problemas ocorridos
que não foram causados por eles estarão registrados. Mas
também pode apresentar suas falhas, caso tenham cometido
alguns erros, como testar uma versão incorreta do software ou
consultar uma especificação de requisitos desatualizada por
falta de atenção.
A partir de um conjunto de relatórios de ocorrências pode-se
identificar os problemas mais recorrentes. Com essa informação
torna-se possível atacar a causa raiz desses problemas,
visando eliminá-los nas próximas atividades. Esse relatório
pode ser enviado semanalmente, ou, dependendo do número
de ocorrências registradas, numa periodicidade menor. Abaixo,
um exemplo básico de um relatório de ocorrências:
22/02/2010 - 08:12:20 - fulano.silva - Sistema ainda não
liberado.
22/02/2010 - 16:30:00 - fulano.silva - Sistema liberado para
iniciar os testes.
Edição 25 - Engenharia de Software Magazine 45

23/02/2010 - 08:05:18 - fulano.silva - Sistema fora do ar. Cicrano
irá verificar.
23/02/2010 - 09:35:40 - fulano.silva - Sistema no ar. O servidor
foi reiniciado.
24/02/2010 - 10:12:22 - fulano.silva - Bug blocante registrado.
Aguardando correção para prosseguir.
24/02/2010 - 10:20:20 - fulano.silva - Cicrano só irá corrigir
no final do dia.
25/02/2010 - 08:00:08 - fulano.silva - Bug ainda não foi corrigido.
Testes continuam parados.
25/02/2010 - 09:40:20 - fulano.silva - Nova versão liberada com
correção para prosseguir com os testes.
25/02/2010 - 14:15:15 - fulano.silva - Testes finalizados. Aguardando
correção dos bus para verificá-los.
26/02/2010 - 11:42:45 - fulano.silva - Todos bugs corrigidos.
O diário acima é um exemplo básico. Mas é possível verificar
que houveram paralisações no período destinado
à atividade. Para começar, houve um atraso na liberação
do sistema para o início dos testes de quase oito horas. O
servidor ficou parado durante uma hora e meia. Os testes
ficaram parados devido a uma falha de travamento das
10h12min do dia 24/02 até as 09h40min do dia seguinte.
Totalizando, aproximadamente, 17 horas de interrupção
dos testes.
Caso seja necessário, pode-se controlar a indisponibilidade
do servidor através da planilha da Figura 12. Poderão
ser registradas as interrupções voluntárias, ou seja, paradas
para subir novas versões do sistema. O ideal é que esse
tipo de interrupção seja planejado, realizado em “janelas”.
O outro tipo diz respeito às interrupções involuntárias,
que são causadas por problemas técnicos inesperados.
Esse controle, ao longo das demandas, poderá identificar
pontos fracos na infraestrutura dos testes, gerando ações
preventivas para os próximos testes.
Nome do Sistema ESMAG
Número da Demanda 22767
Tipo do teste Teste de Sistema
Evidências colhidas? Sim
46 Engenharia de Software Magazine - Reportando de forma simples os resultados dos testes
Relatório Final dos Testes
Este relatório normalmente é emitido no final da atividade
de execução dos testes. Ele irá apresentar o resultado,
consolidando várias informações coletadas durante o andamento
da atividade, como por exemplo, quantidade de
falhas e suas causas principais, casos de testes executados
no tempo previsto, no tempo adicional, ou não executados,
e qualquer outra informação que seja interessante para o
projeto e para a organização.
Estes relatórios servem como entrada para um processo
de lições aprendidas visando à melhoria contínua
do processo. Através da identificação dos pontos fracos
reportados no relatório, deve-se procurar entender suas
causas e estabelecer ações para que os problemas não
voltem a acontecer.
O relatório deverá iniciar com informações gerais, identificando
a atividade, as datas e os responsáveis. É possível
saber se o planejamento foi ou não atendido. No exemplo, o
esforço previsto foi de 352 horas, entre os dias 04/01 e 29/01.
Entretanto, o prazo se estendeu até o dia 05/02, resultando
numa diferença de 25% para mais. Esse tipo de informação
é interessante para que ações sejam tomadas objetivando
uma estimativa mais precisa. Há espaço também para
uma avaliação subjetiva da qualidade do Plano de Testes
e da Especificação, conforme os dois últimos campos do
formulário apresentado na Tabela 3.
A Tabela 4 mostra informações sobre o resumo dos
incidentes. Esta parte do relatório é dividida em quatro
partes. A primeira delas, Resumo de Incidentes, separa os
incidentes em falhas e sugestões, pois nem tudo que foi
registrado realmente é uma falha. Falhas que poderiam ser
detectadas caso um checklist de testes fosse utilizado, falhas
dentro e fora do escopo de uma manutenção, e sugestões de
melhorias aceitas e não aceitas também são contabilizadas.
A segunda, Retrabalho, diz respeito a situações que oneram
Período de testes previsto DE: 04/01/2010 ATÉ: 29/01/2010
Quantidade de horas de testes previsto 352
Período dos testes realizados DE: 04/01/2010 ATÉ: 05/02/2010
Quantidade de horas dos testes realizados 440
Diferença entre previsto e realizado 88 % 25,00%
Nome dos testadores Karla Lages, Felipe Lages
Nº de casos de testes 141
Nº de ct executados no tempo previsto 110 % 78,01%
Nº de ct executados no tempo adicional 31 % 21,99%
Nº de ct não executados no tempo realizado 0 % 0,00%
Qualidade do Plano de Teste Sistema Boa
Qualidade da Especificação EF Boa
tabela 3. Informações gerais do Relatório de Finalização dos Testes

o processo, como por exemplo, reabertura de falhas, falhas
abertas indevidamente (testador também erra!) e falhas
registradas duplicadamente.
Figura 12. Controle de Indisponibilidade do Servidor
Total de incidentes 110
Total de falhas
(Exceto ‘Não é um caso’, sugestões e ‘Duplicado’)
100
Falhas dentro do escopo 100
Falhas fora do escopo 0
VALIDAção, VERIFICAção & tEStE
Resumo de Incidentes
Taxa de incidente por hora
Ex.: 1 incidente a cada X horas
Taxa de falhas por hora
Ex.: 1 falha a cada X horas
Total de falhas referente ao checklist 20 % 20,00%
Total de sugestões Aceitas 4
Total de sugestões Não Aceitas 3
Retrabalho
Total de reaberturas 10
Total de “Duplicado” 0
Total de “Não é um caso” 3 % 2,91%
Total de “Não será corrigido” 0 % 0,00%
Total de “Incapaz de reproduzir” 0 % 0,00%
Resumo por Gravidade das Falhas
Gravidade TOTAL %
Layout 9 9 9,00%
Texto 6 6 6,00%
Normal 70 70 70,00%
Grande 10 10 10,00%
Blocante 5 5 5,00%
TOTAL 100 100 100,00%
Resumo por Causa da Falhas
Causa da Falha TOTAL %
Ambiente 5 5 5,00%
Banco de Dados 5 5 5,00%
Código-fonte 76 76 76,00%
Especificação 14 14 14,00%
Integração 0 0 0,00%
TOTAL 100 100 100,00%
tabela 4. Informações sobre os incidentes do Relatório de Finalização dos Testes
As duas últimas partes dizem respeito à gravidade e a causa
das falhas. A causa da falha normalmente é fornecida pelo
desenvolvedor no momento da correção. Com esses dados
4,00
4,40
Edição 25 - Engenharia de Software Magazine 47

é possível avaliar a qualidade da especificação, do ambiente
e BD de testes. Entretanto, a grande maioria das falhas está
mesmo no código-fonte.
É interessante que exista um espaço aberto para observações,
caso seja necessário reportar alguma situação específica, por
exemplo, quando algum caso de testes apresentou problemas
e não pode ser executado.
Conclusões
Ao longo do tempo esses relatórios poderão ser consolidados,
gerando informações da qualidade durante o semestre, ou ano,
por exemplo. Ferramentas de qualidade, como por exemplo, os
gráficos de Pareto e de Controle, podem e devem ser utilizadas
para se analisar as causas e as tendências dos problemas encontrados
nos processos, mirando a melhoria contínua e a garantia
de qualidade, e não apenas o controle da qualidade.
Vale ressaltar que quanto maior o controle inserido no processo
de testes, maior será o custo das suas atividades, pois as
tarefas de coleta, preparação e análise dos dados, assim como
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Dê seu Feedback
sobre esta edição
48 Engenharia de Software Magazine - Reportando de forma simples os resultados dos testes
a comunicação dos resultados, exigem um esforço a mais dos
analistas de testes. Em contrapartida, quanto menor for o
controle, maior o risco de problemas no projeto. Dessa forma,
esse compromisso tem que ser muito bem pensado, para que
reflita no planejamento dos testes.
Referências
QAI, Guide to the CSTE Common Body of Knowledge. Quality Assurance Institute, Version 6.1.1
– 2006, http://www.softwarecertifications.org
MARICK, Brian; Classic Testing Mistakes, STQE, 1997.
KOLAWA, A.; HUIZINGA, D. (2007). Automated Defect Prevention: Best Practices in Software
Management. Wiley-IEEE Computer Society Press. p. 74. ISBN 0470042125.
MARICK, B. “When Should a Test Be Automated?”. StickyMinds.com. Acessado em 10/03/2010.
PRETSCHNER, A. (2005), “Model-based testing”, Proceedings of 27th International Conference
on Software Engineering, (ICSE‘05), pp. 722-723.
UTTING, M.; LEGEARD, B.; (2007), “Practical Model-Based Testing: A Tools Approach”, ISBN-13:
978-0-12-372501-1, Morgan-Kaufmann.
CRAIG, R.D., JASKIEL, S. P., “Systematic Software Testing”, Artech House Publishers, Boston, 2002.
PRESSMAN, R. S., “Software Engineering: A Practitioner’s Approach”, McGraw-Hill, 6th ed, Nova
York, NY, 2005.
ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. et al., “Qualidade de software – Teoria e prática”,
Prentice Hall, São Paulo, 2001.

Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Teste unitário e de cobertura para Java
Script com JsUnit e JsCovarage
Jenifer Vieira Toledo
jenifer@jenifer.eti.br
Twitter: @Jenifer_Vieira
É Graduada em Ciência da Computação pela
Faculdade Governador Ozanam Coelho (FA-
GOC), Pós-graduanda em Gerência de Projetos
em Engenharia de Software pelo Centro de Ensino
Superior de Juiz de Fora (CES/JF) e Técnica
de Hosting da empresa Optical Soluções em
Informática Ltda.
Elessandro Rodrigues Marques
elessandrorm@gmail.com
É Licenciado em Informática pela Unipac Ubá/
MG. Especialista em Administração de Banco
de Dados e Pós-graduando em Gerência de
Projetos em Engenharia de Software pelo
Centro de Ensino Superior de Juiz de Fora
(CES/JF). Tem experiência de 6 anos como
programador Clipper, Delphi e Java, há 2 anos
trabalha como Analista de Sistemas pela empresa
Colchões Paropas.
Marcelo Santos Daibert
marcelo@daibert.pro
Twitter: @msdaibert
É Mestre e Especialista em Ciência da Computação
pela Universidade Federal de Viçosa, professor
e coordenador do Curso de Bacharelado
em Ciência da Computação da FAGOC (Faculdade
Governador Ozanam Coelho) e Bacharel
em Sistemas de Informação pela Faculdade
Metodista Granbery. Gerente técnico da Optical
Soluções em Informática Ltda.
Marco Antônio Pereira Araújo
maraujo@devmedia.com.br
É Doutor e Mestre em Engenharia de Sistemas e
Computação pela COPPE/UFRJ, Especialista em
Métodos Estatísticos Computacionais e Bacharel
em Informática pela UFJF, Professor dos Cursos
de Bacharelado em Sistemas de Informação
do Centro de Ensino Superior de Juiz de Fora e
da Faculdade Metodista Granbery, Professor do
curso de Bacharelado em Ciência da Computação
da FAGOC, Professor do Curso Superior de
Tecnologia em Análise e Desenvolvimento de
Sistemas da FAA, Analista de Sistemas da Prefeitura
de Juiz de Fora, Editor da Engenharia de
Software Magazine.
O
conceito de teste de software
surgiu no final dos anos 50
como uma atividade isolada da
Engenharia de Software. Era aplicado de
forma manual pelos desenvolvedores
com o objetivo de revisar seus códigos
fonte. Com o passar dos anos, com esta
abordagem sendo aplicada, os projetos
passaram a apresentar melhora na
qualidade do produto final quando
comparados a projetos de software que
não aplicavam nenhuma etapa de testes.
Mesmo assim, a tarefa de efetuar testes
em software foi considerada secundária
De que se trata o artigo?
Teste Unitário e de Cobertura com a utilização das
ferramentas JsUnit e JsCovarage para a linguagem
de programação Java Script.
Para que serve?
Fornecer conhecimentos teóricos e práticos na utilização
da abordagem baseada em testes no desenvolvimento
com a linguagem Java Script. Definir o
passo a passo para a utilização da ferramenta JsUnit
e JsCoverage.
Em que situação o tema é útil?
A abordagem de desenvolvimento baseado em
testes é hoje um importante diferencial para a
busca de qualidade em qualquer software. Nesse
contexto, o JsUnit se apresenta como uma
ferramenta para automatizar os testes unitários
no ambiente de desenvolvimento JavaScript. Já
o JsCoverage é uma ferramenta para execução
dos testes de cobertura.
por algum tempo, chegando a ser vista
até mesmo como uma punição para os
programadores, ou como uma tarefa
onde não se deveria gastar muito tempo
e despender grandes investimentos.
Edição 25 - Engenharia de Software Magazine 49

Além disso, testar software para descobrir os defeitos que
desqualificam os produtos para os consumidores era visto
como um trabalho tedioso e cansativo, a ser evitado pelos mais
artificiosos dos especialistas em tecnologia. Entretanto, a responsabilidade
com a qualidade do produto final desenvolvido
deve ser levada em consideração e justamente por isso o tema
teste de software está em evidência.
Nos dias atuais, teste de software é visto como um subitem
dentro da Qualidade de Software, sendo que para conseguir
tal qualidade é necessário definir padrões de trabalho, métodos
e melhorar o processo de desenvolvimento, assegurando de
fato que os defeitos sejam identificados o mais cedo possível
durante o processo de desenvolvimento de software. O custo
de um defeito em um software não deve ser avaliado somente
pelo aspecto financeiro. Os softwares são escritos para controlar
equipamentos com propósitos mais variados possíveis,
como dosagens de medicamentos, exames médicos, construção
e controle de aviões, aeronaves espaciais, satélites, entre outros
vários sistemas. E, em muitos casos, um defeito pode causar
a destruição total de um caro equipamento ou até mesmo em
perda de vidas humanas. Veja abaixo alguns exemplos de
problemas causados por defeitos de software:
• Intel: gastou 475 milhões dólares na correção do erro da
vírgula flutuante do Pentium em 1994 (Computer Science,
Springer Verlag - 1995);
• Prime Personal Communications: cancelou contrato de US$
500 milhões com a Motorola por causa de falhas de Software
(Wall Street Journal - 24/02/1998);
• Ariane 5: 10 anos de desenvolvimento no valor de US$ 7 bilhões,
com uma carga de US$ 500 milhões em equipamentos,
explodiu 40 segundos após lançamento (ESA - 1996);
• Therac-25: seu software ministrou doses de radiação em
pacientes entre 1985 e 1987 resultando em seis óbitos (IEEE
Computer - 07/07/1993).
Existem vários outros exemplos e relatos onde defeitos de
software foram decisivos para a ocorrência de algum problema
ou acidente, o que motiva a busca e identificação prematura
destes defeitos, evitando assim a sua manifestação através das
falhas que podem impactar as vidas de seus usuários.
O autor Alexandre Bartie, em seu livro sobre Garantia da
Qualidade, apresenta um quadro estatístico sobre projetos
americanos de desenvolvimento de software relatando que
mais de 30% dos Projetos de Software são cancelados antes
de serem finalizados. Mais de 70% dos Projetos de Software
falham nas entregas das funcionalidades esperadas. Os custos
extrapolam mais de 180% os valores originalmente previstos e
os prazos excedem em 200% os cronogramas originais.
Neste sentido, o teste de software é um componente a mais
dentro do processo de desenvolvimento de software que
busca contribuir para a busca de qualidade. O objetivo deste
artigo é apresentar as técnicas de teste unitário e de cobertura
no contexto de desenvolvimento Web, mais especificamente
para a linguagem Java Script. Para isso, são apresentadas
as ferramentas JsUnit e JsCoverage para, respectivamente,
50 Engenharia de Software Magazine - Teste unitário e de cobertura para Java Script com JsUnit e JsCovarage
auxiliarem na tarefa de teste unitário e de cobertura, ambos
de forma automatizada.
Teste Unitário
O Teste de Unidade, ou Teste Unitário, classificado como
teste caixa-branca por ser baseado na estrutura lógica do
código, é responsável por testar a unidade de codificação da
aplicação. Em um sistema orientado a objetos essa unidade
pode ser representada pelos métodos das classes, ou outro
nível de granularidade, dependendo da complexidade dos
elementos a serem testados. Esta técnica testa apenas o código
da aplicação, e podem-se testar todas as regras de negócio
da mesma.
Gerard Meszaros, em seu livro “xUnit Test Patterns: Refactoring
Test Code Hardcover”, relata muito bem a importância
dos testes unitários, definindo-o para os dias atuais como um
ponto de importância em métodos de desenvolvimento ágil,
como Extreme Programming (XP), reforçando a disponibilidade
dos sistemas com testes integrados automatizados.
Desta forma, permite aos desenvolvedores serem mais ousados
nas modificações do software alcançando um desenvolvimento
evolutivo do que com entregas incrementais de
funcionalidades, acelerando assim, o feedback dos usuários
que contribuem para a qualidade do produto.
Praticamente todas as abordagens ágeis de desenvolvimento
evidenciam o teste como principal aliado para absorver o
não formalismo da documentação de software e garantir
assim que a funcionalidade correta está sendo desenvolvida
e entregue ao cliente.
Por testar a lógica da funcionalidade, o código fonte é analisado,
e um fundamental conceito é o de caso de teste, que
representa uma instância de teste para aquela funcionalidade
que percorre um determinado caminho no algoritmo de
acordo com seus valores de teste. Um algoritmo pode possuir
vários casos de teste, cada um deles contendo os valores que
devem ser testados para analisar e percorrer os caminhos
do algoritmo.
Para definir o número mínimo de casos de teste para cobrir
todas as possibilidades de caminhos de processamento de um
trecho de código, é possível utilizar uma métrica de software
chamada Complexidade Ciclomática. Esta técnica define o
número de caminhos independentes que um algoritmo deve
percorrer para efetuar todos os processamentos. Juntamente
com esta técnica, pode-se utilizar outra chamada Análise do
Valor Limite que define os valores limites que serão utilizados
para efetuar os testes.
Teste de Cobertura
O teste de cobertura é responsável por verificar se o teste
unitário está verificando todos os caminhos possíveis do algoritmo
de alguma funcionalidade do software. Apresenta a
porcentagem de cobertura de um teste unitário, por exemplo,
sob um determinado método. O objetivo é ter a maior cobertura
possível identificando áreas do projeto que ainda não estão
cobertas pelos testes automatizados.

JsUnit
JsUnit é um framework open-source para testes unitários em
Java Script e que segue as conformidades e padrões do pacote
xUnit frameworks.
A família xUnit possui variantes que são especializações
para diversas outras linguagens e outros propósitos. Algumas
destas ramificações são cUnit para a linguagem C, dUnit
para a linguagem Delphi, csUnit para o C# ou qualquer
linguagem .NET, jUnit para a linguagem Java, PyUnit para
a linguagem Python, DBUnit para teste em banco de dados,
PHPUnit para a linguagem PHP, entre outras.
JsUnit foi criada em 2001 e roda nas mais variadas combinações
de browser/plataformas (navegadores), conseguindo
assim, um vasto número de utilizadores, além de ter sua
configuração considerada simples. O JsUnit é um componente
de software escrito na linguagem Java Script que disponibiliza
todo o ambiente necessário para o teste unitário.
Para utilizá-lo, basta fazer download deste componente de
software e estender sua utilização às funcionalidades do
Java Script.
Com o JsUnit baixado (http://www.jsunit.net/) e tendo
descompactado o arquivo em um diretório qualquer, cabe
descrever a estrutura e principais diretórios e arquivos da
ferramenta, conforme apresentado na Tabela 1.
Elemento Descrição
testRunner.html
página web configurada como um painel para a execução dos testes unitários
com o JsUnit.
app
diretório onde o núcleo da ferramenta é apresentado e onde o arquivo
jsUnitCore.js é disponibilizado.
css
diretório que contém arquivos de folhas de estilos que são utilizados na página
testRunner.html.
doc diretório que contém toda a documentação da ferramenta
java
diretório que contém o código fonte Java e bibliotecas (JARs) para rodar o JsUnit
diretamente em um ambiente Java.
Licenses diretório que contém os termos e licença de uso da ferramenta.
logs diretório que contém os logs de um servidor JsUnit.
tabela 1. Estrutura de Diretórios e Arquivos do JsUnit
Os testes unitários em JsUnit recebem o nome de funções de
testes e são inseridas em páginas HTML que fazem referência
(include) a uma biblioteca específica que fica dentro do diretório
“app” de nome “jsUnitcore.js”. Esta biblioteca contém funções
e métodos que permitem a aplicação dos testes unitários
nos códigos escritos em Java Script.
A seguir é apresentado um exemplo utilizando o JsUnit.
É possível observar que dentro do trecho de código exibido
na Listagem 1 existem quatro funções: duas chamadas “teste_verificacao1”
e “teste_verificacao2” que foram criadas para
executar os testes (se configuram como dois casos de teste), a
terceira é a função “testeA” e, por fim, a função “testeB”, que
representam os testes propriamente ditos.
A função testeA retorna verdadeiro (true) e a função testeB
retorna falso (false). Já as funções teste_verificacao1 e
teste_verificacao2 aferem o resultado das funções testeA e
VALIDAção, VERIFICAção & tEStE
testeB. No exemplo, o primeiro caso de teste afere o resultado
de testeA como verdadeiro, e o segundo também para
a função testeB. Entretanto, a função testeB retorna falso
(linha 10), configurando assim um erro com base no valor
que seria esperado. Erro este que é capturado pelo teste
unitário como é apresentado a seguir.
Listagem 1. Código Exemplo para o JsUnit.
1.
2.
3. Teste Unitário 1
4.
5.
6. function testeA() {
7. return true;
8. }
9. function testeB() {
10. return false;
11. }
12. function teste_verificacao1() {
13. assertEquals(true, testeA());
14. }
15. function teste_verificacao2() {
16. assertEquals(true, testeB());
17. }
18.
19.
20.
21.
22.
Para a execução dos testes, é necessário executar o testRunner.html.
Esse arquivo fica armazenado dentro do diretório
app da ferramenta. Assim que é executado, é apresentada
a interface exibida na Figura 1, que possui uma opção para
se carregar o arquivo HTML com os testes unitários. Onde
é exibida a opção “Enter the location of the Test Page/Test
Suite Page to be run”, entre com o local da página de teste
para executar. Basta adicionar no campo o local completo do
endereço do arquivo e clicar em Run para executar os testes.
O resultado do exemplo é exibido pela Figura 2.
Figura 1. Interface do testRunner.html do JsUnit
Edição 25 - Engenharia de Software Magazine 51

Figura 2. Resultado do Teste no testRunner
Na tela de resultado é possível observar o erro que foi intencionalmente
adicionado no código para o exemplo. Além de
apresentar a barra vermelha, é possível verificar detalhes do
erro na parte de baixo da interface. Ao clicar na opção com
erro é exibido um detalhamento: “Expected but was
” – Esperado mas foi . Fazendo
uma clara alusão à função testeB que retorna falso e o caso de
teste espera por verdadeiro. Fazendo uma pequena alteração
no caso de teste teste_verificacao2 para que ele espere falso,
alterando a linha 16 da Listagem 1 para assertEquals(false,
testeB());, o resultado é exibido na Figura 3, sem erros desta
vez, conforme esperado.
Figura 3. Resultado do Teste no testRunner – sem erros
JsCoverage
JsCoverage é uma ferramenta que faz testes de cobertura em
programas escritos na linguagem JavaScript. Para conseguir
52 Engenharia de Software Magazine - Teste unitário e de cobertura para Java Script com JsUnit e JsCovarage
analisar um código, o JsCoverage instrumenta a biblioteca que
está sendo referenciada pela página HTML, acrescentando
chamadas a funções específicas do JsCoverage que visam
retornar o número de execuções de cada linha de código da
biblioteca, conseguindo assim apresentar uma análise de
cobertura completa da biblioteca utilizada.
Assim como a JsUnit, a JsCoverage é disponibilizada em um
pacote compactado (http://siliconforks.com/jscoverage/). A
organização dos diretórios também é simples e disponibiliza
na pasta principal os executáveis responsáveis por instrumentar
as bibliotecas que são jscoverage.exe e jscoverage-server.
exe. O diretório DOC contém a documentação da ferramenta
e exemplos de utilização.
Como apresentado, a JsCoverage precisa instrumentar os
códigos Java Script para poder identificar a cobertura da sua
execução. Há, basicamente, três formas essenciais para essa
atividade.
A primeira é utilizar o utilitário jscoverage.exe que está dentro
da pasta principal. A sua utilização é simples e basta digitar
o comando abaixo no prompt de comandos do MS-DOS, onde o
DIRETORIO-FONTE é o diretório que possui os códigos fonte
a serem instrumentados e o DIRETORIO-DESTINO será o diretório
onde os códigos instrumentados serão enviados. Observe
que serão instrumentados todos os arquivos com a extensão .js
de todo o diretório e subdiretórios do diretório fonte.
jscoverage.exe DIRETORIO-FONTE DIRETORIO-DESTINO
A segunda forma é usar o jscoverage-server, que é um servidor
Web simples que instrumenta os códigos Java Script
automaticamente, não sendo necessária a execução de qualquer
comando adicional. Para se iniciar o servidor, basta executar
jscoverage-server.exe no prompt do MS-DOS que o servidor
será instanciado em memória. Ele abrirá o servidor na porta
8080 e, portanto, se houver algum outro aplicativo no servidor
que esteja utilizando essa porta, o JsCoverage não irá funcionar
nas suas configurações padrão.
Para testar, basta acessar em qualquer navegador o endereço
http://127.0.0.1:8080/jscoverage.html. Ao abrir este link, uma
interface para a instrumentação dos códigos Java Script é
exibida ao usuário conforme pode ser visto na Figura 4. Para
desligar o servidor, basta fechar a janela do prompt do MS-
DOS. Quando os códigos são instrumentados na primeira
forma (a forma manual), é gerada no diretório destino a mesma
interface exibida nesta segunda forma – basta para isso acessar
o arquivo jscoverage.html no diretório destino.
Um detalhe que merece destaque é quanto à necessidade dos
arquivos de código fonte do seu site (HTML, Java Script, entre
outros) a serem testados estarem no mesmo diretório do arquivo
jscoverage-server, ou então ser chamado pelo diretório dos
códigos fonte do site. Mas, nesse caso, é necessário configurar
a ferramenta na variável PATH das variáveis de ambiente do
sistema operacional.
E há ainda uma terceira forma, que é utilizando o jscoverageserver
com a opção de proxy ativada. Com essa forma, os
códigos são instrumentados de forma automática ao serem

acessados pelo proxy. Entretanto, é necessária uma configuração
de portas para o proxy, não sendo essa opção tratada
neste artigo.
Figura 4. Interface do JsCoverage-server
Para exemplificar a sua utilização, é apresentado um exemplo
nas Listagens 2 e 3. Na Listagem 2 é exibido um código HTML
de uma pequena página que possui um campo de texto para
inserção de qualquer valor. Há também um botão que submete
o formulário com o valor digitado pelo usuário da página. O
formulário, no evento onSubmit, faz acesso à uma função Java
Script definida na Listagem 3.
Listagem 2. Código Exemplo HTML para o JsCoverage.
1.
2.
3. Teste de Cobertura
4.
5.
6.
7.
8. Valor:
9.
10.
11.
12.
Listagem 3. Código Exemplo Java Script para o JsCoverage.
1. function enviaJavaScript(){
2. var vValor = document.frmTeste.inptValor.value;
3. alert(“Resultado: “+vValor);
4. if (vValor > 100){
5. alert(“Valor maior que 100”);
6. }else{
7. alert(“Valor menor ou igual que 100”);
8. }
9. }
A função enviaJavaScript, definida na Listagem 3, captura
o valor do campo do HTML e o exibe com o comando alert.
Após isso, verifica se o valor é maior que 100. Se for, informa
ao usuário e, caso seja menor ou igual que 100, uma mensagem
também é exibida.
Tanto utilizando a primeira ou a segunda forma de instrumentação,
o resultado é exibido na Figura 5. Em URL, basta
digitar o nome do arquivo HTML e acionar a função Open in
frame (Abrir no frame). Esta função abre a página HTML no
frame da interface do JsCoverage. Após, basta testar a interface,
digitando, por exemplo, o valor 200. O Java Script irá ser
VALIDAção, VERIFICAção & tEStE
acionado e irá informar o valor digitado juntamente com a
informação que o valor é maior que 100.
Figura 5. Exemplo JsCoverage – Interface Principal
Após ser executado ao menos uma vez, basta acessar a aba
Summary na interface do JsCoverage para visualizar a interface
exibida na Figura 6. Ela apresenta todos os arquivos Java
Script da página executada e as respectivas coberturas de cada
um dos arquivos. Para o exemplo, somente há um arquivo, o
script.js, apresentando 83% de cobertura. Ao clicar no nome
do arquivo, o JsCoverage exibe linha a linha a cobertura do
código fonte. Desta forma, foi possível observar que a linha
que identifica a mensagem de menor ou igual que 100 não foi
executada, como apresentado na Figura 7.
Figura 6. Sumário de Cobertura dos Arquivos Java Script
Estudo de Caso
Buscando exemplificar o uso das ferramentas jsUnit e js-
Coverage, é proposto um estudo de caso criado utilizando
a linguagem Java Script. Nele é criada uma função chamada
calcularAprovacao, responsável por verificar se um aluno, por
exemplo, foi aprovado ou não em uma disciplina. A função
recebe por parâmetro a nota 1, nota 2, nota de uma prova final
(notaFinal) e a freqüência, como pode ser observado pela
Listagem 4.
Edição 25 - Engenharia de Software Magazine 53

Figura 7. Cobertura da Função enviaJavaScript()
O calcularAprovacao verifica inicialmente se a frequência do
aluno é menor que 75%. Caso seja, o aluno é reprovado de imediato,
fazendo com que a função retorne falso. Caso contrário, é
verificada a média da nota1 com a nota2. Caso essa média seja
menor que 30, o aluno também é reprovado. Caso contrário,
se a média for maior ou igual a 70, o aluno é aprovado. Se a
média for maior ou igual a 30 e menor que 70, o aluno estará
em prova final e será aprovado caso o valor da média de sua
nota de prova final com a média anterior for superior ou igual
a 50. Caso contrário, ele será reprovado.
Com a função definida, o objetivo agora é criar os casos de
teste, buscando testar as regras descritas pela função. Os casos
de teste são definidos em um documento HTML que importa
o core do jsunit e o arquivo Java Script que define o método
calcularAprovacao. Esse documento HTML é apresentado na
Listagem 5. Para isso, pode-se calcular sua Complexidade Ciclomática
(CC) utilizando alguma ferramenta de métricas, ou
então pode-se descobrir quais são as possibilidades de retorno
de valor para este método, de acordo com os dados informados.
Observando atentamente a função calcularAprovacao(), é
possível identificar cinco possibilidades de retorno, de forma
a percorrer todos os caminhos do algoritmo:
• Frequência inferior a 75, a função retorna falso;
• Frequência igual ou superior a 75 e média inferior a 30, a
função retorna falso;
• Frequência igual ou superior a 75 e média igual ou superior
a 70, a função retorna verdadeiro;
• Frequência igual ou superior a 75 e média final igual ou
superior a 50, retorna verdadeiro;
• Frequência igual ou superior a 75 e média final inferior a 50,
a função retorna falso.
Ainda na Listagem 5, é possível identificar um formulário
para o teste manual. Esse formulário, ao ser submetido, invoca
a função Java Script executaJS(). Esta, por sua vez, está sendo
definida no arquivo avaliarAluno.js, abaixo da função calcularAprovacao,
na Listagem 4. A função basicamente captura os
Listagem 4. Código da Função calcularAprovacao
1. function calcularAprovacao (nota1, nota2, notaFinal, frequencia) {
2. var media;
3. media = 0;
4. if (frequencia < 75) {
5. return false;
6. }
7. else {
8. media = (nota1 + nota2) / 2;
9. if (media < 30) {
10. return false;
11. }
12. else {
13. if (media > 70) {
14. return true;
15. }
16. else {
17. if (((media + notaFinal) / 2) >= 50) {
18. return true;
19. }
20. else {
21. return false;
22. }
23. }
24. }
25. }
26. }
27. function executaJS(){
28. var vForm = document.frmTeste;
29. var vNota1 = vForm.edtNota1.value;
30. var vNota2 = vForm.edtNota2.value;
31. var vNotaFinal = vForm.edtNotaFinal.value;
32. var vFrequencia = vForm.edtFrequencia.value;
33. if (calcularAprovacao(vNota1, vNota2, vNotaFinal, vFrequencia)){
34. alert(“Aprovado”);
35. }else{
36. alert(“Reprovado”);
37. }
38. }
Listagem 5. Casos de Teste e HTML - jsUnitTestAvaliarAluno.html
54 Engenharia de Software Magazine - Teste unitário e de cobertura para Java Script com JsUnit e JsCovarage
1.
2.
3. JsUnit Test Aprovação
4.
5.
6.
7.
8. function testVericarAprovacao_ReprovacaoFrequencia() {
9. assertEquals(false, calcularAprovacao(0, 0, 0, 74))
10. }
11. function testVericarAprovacao_ReprovacaoDiretoPorNota() {
12. assertEquals(false, calcularAprovacao(30, 29, 0, 75))
13. }
14. function testVericarAprovacao_AprovacaoDiretoPorNota() {
15. assertEquals(true, calcularAprovacao(70, 70, 0, 75))
16. }
17. function testVericarAprovacao_AprovacaoComNotaFinal() {
18. assertEquals(true, calcularAprovacao(30, 30, 70, 75))
19. }
20. function testVericarAprovacao_ReprovacaoComNotaFinal() {
21. assertEquals(false, calcularAprovacao(30, 30, 69, 75))
22. }
23.
24.
25.
26. Teste com as Assertivas JsUnit
27. Esta página contém testes para as funções assertivas do
JsUnit.
28.
29. Nota 1:
30. Nota 2:
31. Nota Final:
32. Frequência:
33.
34.
35.
36.

valores do formulário e invoca a função calcularAprovacao(),
exibindo o resultado final ao usuário.
Execução dos Testes
Com os testes unitários criados, é possível executá-los de
forma automatizada pelo jsUnit e posteriormente verificar a
cobertura dos testes com o jsCoverage. Entretanto, para que
as ferramentas funcionem juntas é necessária uma adaptação
no jsUnit de forma a enviar a execução dos testes à ferramenta
de cobertura. O jsCoverage disponibiliza, dentro de
um dos exemplos oficiais (o exemplo com nome jsunit), uma
versão modificada do jsUnit que sofreu alguns ajustes para
funcionar em conjunto com a ferramenta de cobertura. A
principal modificação que pode ser observada visualmente
é que a página testRunner.html, responsável pela execução
dos testes unitários, agora traz um botão que chama a ferramenta
jsCoverage após os testes terem sido executados. É
com essa versão modificada do jsunit que este estudo de caso
irá ser executado.
Durante os testes para o desenvolvimento deste artigo, esta
integração do jsUnit e jsCoverage foi testada com as três formas
de instrumentação apresentadas. Entretanto, a integração somente
foi funcional com a segunda forma de instrumentação,
na qual utiliza o jscoverage-server.
Com o servidor do jscoverage rodando, abre-se a página:
http://127.0.0.1:8080/testRunner.html e acionam-se os casos de
teste no arquivo jsUnitTestAvaliarAluno.html: 127.0.0.1:8080/
jsUnitTestAvaliarAluno.html. Os testes são executados, apresentando
o resultado exibido na Figura 8. Importante destacar
que os arquivos do estudo de caso devem estar no mesmo
diretório que o servidor do jscoverage (jscoverage-server.exe).
É possível observar que um dos casos de teste apresentou
problema (o testVericarAprovacao_AprovacaoDiretoPorNota).
Buscando investigar, foi acionada a opção de visualizar
o relatório do jsCoverage (Coverage Report) e o resultado é
exibido na Figura 9.
Figura 8. Resultado do jsUnit – Estudo de Caso
VALIDAção, VERIFICAção & tEStE
Figura 9. Resultado do jsCoverage – Estudo de Caso
Na Figura 9 são apresentados os resultados do teste de cobertura
com os trechos do código fonte que estão sendo cobertos
ou não. Quando coberto, o trecho é marcado em verde. Caso
contrário, em vermelho. Nesse caso, o calcularAprovacao não
está sendo coberto onde a variável média está sendo testada
com o valor 70. Esse trecho de código, como pode ser visualizado,
está sendo mostrado em vermelho.
Como foi dito, o caso de teste testVericarAprovacao_AprovacaoDiretoPorNota
falhou sua execução. Isso se deve ao fato
que se esperaria que alunos com média 70 fossem aprovados
e, na realidade, estão sendo reprovados. De acordo com o
código-fonte, quem possuir média entre 30 e 70 (inclusive)
deve fazer prova final.
Como esse aluno possui valor 0 na sua prova final, o mesmo
foi reprovado, sendo retornado o valor falso, onde o valor
esperado deveria ser verdadeiro, falhando assim o caso de
teste. Com isso, foi possível identificar uma falha no código
fonte, uma vez que o aluno com média de valor 70 deveria
ser aprovado.
Deve-se então fazer uma alteração no método calcularAprovacao
para que sejam aprovados os alunos com média superior
ou IGUAL a 70. A alteração deve ser realizada na linha
referente à verificação da média ser maior que 70. Modifique-a
para “media >= 70”.
As Figuras 10 e 11 apresentam os resultados do jsUnit e
jsCoverage, respectivamente, após a modificação. Observe
que todos os casos de teste são executados de forma correta e
a função Java Script possui cobertura de 100%.
Considerações Finais
Uma questão importante ao se trabalhar com testes unitários
é a definição do número de casos de teste necessários
para avaliar os caminhos possíveis de um algoritmo. Como é
impossível testar todas as situações, torna-se primordial não
construir casos de teste desnecessários, testando as mesmas
situações.
Uma importante técnica é conhecida como Complexidade
Ciclomática de McCabe, já citada, que avalia o número de
Edição 25 - Engenharia de Software Magazine 55

Figura 10. Resultado do jsUnit – Estudo de Caso – Erro Resolvido
Figura 11. Resultado do jsCoverage – Estudo de Caso – Erro Resolvido
caminhos possíveis em um algoritmo, indicando o número de
casos de teste necessários para avaliar as suas possibilidades.
Contudo, essa técnica apenas determina o número de casos
de teste, não os valores que devem ser utilizados no mesmo.
Família xUnit
http://xunitpatterns.com/
JsUnit
http://www.jsunit.net/
JsCoverage
http://siliconforks.com/jscoverage/
56 Engenharia de Software Magazine - Teste unitário e de cobertura para Java Script com JsUnit e JsCovarage
Para isso, uma outra técnica conhecida como Particionamento
por Classes de Equivalência, auxiliada por outra técnica chamada
Análise do Valor Limite, podem ser úteis, mas fogem
ao escopo deste artigo.
O sucesso de uma abordagem de desenvolvimento apoiada
por testes dá-se em função da qualidade dos casos de teste. Se
um sistema não falha nos testes planejados, fica a dúvida se
o sistema é de boa qualidade ou se os casos de teste é que são
de baixa qualidade. Portanto, investir num bom planejamento
de testes é fundamental para essa estratégia.
O ambiente de execução de testes deve ser cuidadosamente
planejado. É importante garantir que o ambiente seja o mesmo
a cada execução do teste, preocupando-se, por exemplo, com
o estado das informações no banco de dados.
A utilização de técnicas de teste proporciona aos desenvolvedores
um menor índice de defeitos no código fonte e,
consequentemente, uma maior confiabilidade do sistema no
ambiente de produção e maior qualidade da aplicação. Nesse
sentido, vimos nesse artigo que o jsUnit é um framework de
testes unitários e o jsCoverage de testes de cobertura, ambos
para a linguagem Java Script, que buscam automatizar o
processo de testes, tornando possível a implantação de uma
política de testes na prática.
Links
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Dê seu Feedback
sobre esta edição

Edição 25 - Engenharia de Software Magazine 57

58 Engenharia de Software Magazine - Teste unitário e de cobertura para Java Script com JsUnit e JsCovarage