Engenharia de Softwa..

mamfo.dyndns.org

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 pode

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 pode

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

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

dede 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

de casos de testes 141

de ct executados no tempo previsto 110 % 78,01%

de ct executados no tempo adicional 31 % 21,99%

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

More magazines by this user
Similar magazines