Engenharia de Software - Edição 25

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

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

SEU DIPLOMA GANHA,O MERCADO GANHA E VOCÊ

GANHA MAIS AINDA.

EDITORIAL

Corpo Editorial

ColaboradoresRodrigo Oliveira Spí[email protected]

Marco Antônio Pereira AraújoEduardo Oliveira Spínola

Capa e DiagramaçãoRomulo Araujo - [email protected]

Coordenação GeralDaniella Costa - [email protected]

Revisor e SupervisorThiago Vincenzo - [email protected]

Na Webwww.devmedia.com.br/esmag

Ano 3 - 25ª Edição - 2010 Impresso no Brasil

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 desenvol-

vimento 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 pro-

cessos 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: pro-

cessos, 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 or-

ganizações. O artigo objetiva apresentar uma revisão sistemática a respeito de nove mo-

delos 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 para-

digma: 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 [email protected] 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 minis-trado 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([email protected])Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-nha 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 Cur-so 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([email protected]) É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Ma-gazine. É 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).

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 Leitorwww.devmedia.com.br/mancad(21) 2220-5338

Kaline DolabellaGerente de Marketing e [email protected](21) 2220-5338

Publicidade

Para informações sobre veiculação de anúncio na revista ou no site entre em

contato com:

Kaline [email protected]

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

[email protected]

ÍNDICEPor trás do obvio

05 - Humanos, Formigas e o Trabalho em EquipeGlênio Cabral

Engenharia

06 - Natureza do software e a necessidade de princípios e processoAntonio Mendes da Silva Filho

14 - Engenharia de sistemas orientada ao conhecimento Viviane Schneider e Ivan Correia Filagrana

Agilidade

21 - Da Gestão à Governança em Tecnologia da Informação e Comunicação – TICAlexandre José de Oliveira, Cleyverson Pereira Costa e Hermano Perrelli de Moura

Planejamento e Gerência

32 - Ferramentas para Gerência de ProjetosMarco Antônio Pereira Araújo , Patrícia Lima Quintão e Jurema Florinda Lembe de Veiga

Desenvolvimento

40 - Reportando de forma simples os resultados dos testesDaniel Scaldaferri Lages

49 - Teste unitário e de cobertura para Java Script com JsUnit e JsCovarage Jenifer Vieira Toledo, Elessandro Rodrigues Marques, Marcelo Santos Daibert e Marco Antônio Pereira Araújo

Tipo: Validação, Verificação & Teste Título: Teste de Interface Autor: Arilo Claudio Dias NetoMini-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 NetoMini-Resumo: Esta vídeo aula aborda o tema de automação dos testes, apresen-tando 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.

Tipo: Validação, Verificação & Teste Título: Teste Baseado em Modelos - Definições e Conceitos - Parte 1Autor: Arilo Claudio Dias NetoMini-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 NetoMini-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.

4 Engenharia de Software Magazine

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 En-genharia de Software Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:

Caro Leitor

Edição 25 - Engenharia de Software Magazine 5

Humanos, Formigas e o Trabalho em Equipe

Pos trás do Óbvio

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 for-miga 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 comporta-mento 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 desprovi-dos 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,

Glênio [email protected]

É Administrador de Empresas, pós-graduado em Gestão de Pessoas e músico.

desmotivação é para o bicho homem, que é um ser racional e por isso tem necessidades insaciáveis a cada estação. As for-migas 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 equi-pe 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

sob

re esta edição

6 Engenharia de Software Magazine - Natureza do Software e a Necessidade de Princípios e Processo

Antonio Mendes da Silva [email protected]

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 Edito-ra Campus/Elsevier, tem mais de 30 artigos publicados em eventos nacionais e inter-nacionais, colunista para Ciência e Tecno-logia 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 Uni-versidade 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.

De que se trata o artigo?Discute a natureza do software e apresenta um conjunto de princípios de engenharia emprega-dos no desenvolvimento de sistemas de softwa-re, 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 softwa-re, 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 ob-tenção do produto.

Natureza do Software e a Necessidade de Princípios e Processo

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 nos-so cotidiano, servindo às mais variadas necessidades das pessoas. Entretanto, você já parou para pensar como o sof-tware é 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

oportunidade de entender a natureza do software e importância do uso de princípios e processo no desenvolvi-mento de software.

Você já percebeu que software está praticamente em todas as coisas de seu cotidiano?

Engenharia

Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros


ENGENhARIA DE SoFt WARE

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 natu-reza do software e princípios e processo de desenvolvimento de software.

Natureza do softwareHá aproximadamente cinco décadas atrás, software consti-

tuía uma pequena, senão ínfima, parcela dos sistemas com-putacionais 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 signi-ficativa 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 utili-zado 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 sof-tware, é uma peça essencial.

Software compreende um conjunto de instruções que, quan-do são executadas em um dispositivo, fornecem funcionali-dades 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,

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, por-

tanto, 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 compa-rada 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á existen-tes 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


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 re-quer é 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 dese-jados, 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 desen-volvimento 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 desenvolvi-mento, 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.

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 desenvolvi-mento 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 SoftwareAntigamente (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 com-putacionais (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 entregar-mos 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 en-genharia 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 ge-renciamento 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 in-teressada no software a ser desenvolvido) com o objetivo de levantar os requisitos de software que serão depois documen-tados na especificação de requisitos. E, a partir do momento que ele estiver com a especificação em mãos, ele poderá iniciar as atividades seguintes (projeto, implementação e testes).

E o porquê da engenharia de software ou pra que ela serve?

A engenharia de software visa assegurar:• A qualidade do software (produto);• Entrega do software conforme cronograma;• Desenvolvimento do software conforme orçamento.

Observe que o processo é um elemento essencial, pois se ele for adequadamente seguido, a qualidade do produto poderá ser assegurada. A qualidade do produto é determinante para o sucesso de um software. Há vários atributos da qualidade que servem de indicativo para aceitação e satisfação do cliente (usuário do software). Dentre elas, podemos destacar:• Corretude – Um software é correto se ele satisfaz os requi-sitos de funcionalidades descritos na especificação.• Confiabilidade – Um software é confiável se você pode uti-lizar o software por um determinado período de tempo com probabilidade mínima da ocorrência de falhas.• Manutenibilidade (ou facilidade de manutenção) – Consi-dera-se que um software facilita a sua manutenção quando ele é desenvolvido (ou escrito) de modo que possa evoluir para

atender as necessidades de mudança de requisitos do cliente. Trata-se de um atributo importante, já que a mudança das ca-racterí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 processamen-to 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 con-seguirá 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. Adi-cionalmente, 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 im-plica que sua especificação seja correta, conforme mostrado na Figura 6.

Figura 6. Atributos da qualidade de software

Princípios de EngenhariaCabe destacar ainda que a Engenharia de Software se baseia

em princípios de engenharia que são aplicados ao desen-volvimento 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 mo-delo, 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.


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 de-senvolvimento 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 cres-cem, 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, comparativa-mente 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 organi-zacional (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: pri-meiro cada componente (isoladamente) deve possuir elevado grau de acoplamento de modo a ser tratado como uma ‘unida-de’. Por outro lado, cada componente deve ter um menor grau

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 pro-blema 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 DesenvolvimentoUm aspecto importante no desenvolvimento de um siste-

ma 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 pro-curam exatamente responder a questão: é viável desenvolver esse software?

Tudo isso visa minimizar custos e assegurar que o desen-volvimento 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 desenvolvi-mento 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 ativi-dades 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 esquer-do da figura, olhando verticalmente de cima para baixo, há um conjunto de disciplinas, como requisitos e implementação, que engloba atividades relaciona-das. É 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 discipli-nas 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 desen-volvido 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 sis-tema não precisam ser identificadas, especificadas, implementadas e testadas de uma única vez. O desenvolvimento se dá de modo incremental, ou

seja, inicialmente, apenas as funcionalidades mais importantes são desen-volvidas e as demais são desenvolvidas em outras iterações, incrementando novas funcionalidades ao sistema. É como se cada iteração fosse um mini-projeto 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 mini-projeto) 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 gran-de 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


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 manu-tençã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 distri-buí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 orga-nizado) 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 fun-cionalidades 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 re-cursos 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.

• 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 rea-lizados treinamentos e assistência aos usuários.

É importante observar que o RUP é uma evolução de propos-tas 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ãoEste artigo trata de uma visão geral da engenharia de sof-

tware, 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.

Processo RUPhttp://www.wthreex.com/rup/portugues/index.htm

História da Indústria de Softwarewww.softwarehistory.org

Software Engineering Body of Knowledgehttp://www.computer.org/portal/web/swebok

Creating a Software Engineering Culturehttp://www.processimpact.com/articles/culture.pdf

Processo de Desenvolvimento de Softwarehttp://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

Links


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

sob

re esta edição



www.infnet.edu.br - [email protected] - Central de Atendimento: (21) 2122-8800

E D U C A Ç Ã O S U P E R I O R O R I E N T A D A A O M E R C A D O

PÓS-GRADUAÇÃO

Engenharia de Software: Desenvolvimento Java

Engenharia de Software: Desenvolvimento .NET

GRADUAÇÃO

Engenharia de ComputaçãoAná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

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.

r/esti

TURMASNO RIO DEJANEIRO

Modéstia à parte, suamelhor opção para

se destacar no mercado!

14 Engenharia de Software Magazine - Engenharia de sistemas orientada ao conhecimento

Ivan Correia [email protected]

Atua há 17 anos com desenvolvimento de Software, é bacharel em Ciência da Compu-tação, Especialista em Gerência de Projetos, Mestrando em Engenharia de Produção, Pa-lestrante, Consultor, Gerente de TI.

Viviane [email protected]

Atua no ramo de gerência de informações de projetos. Bacharel em Sistemas de Informa-ção. Gestora de informações de projetos.

De que se trata o artigo?Este artigo aborda uma nova visão de desenvolvimen-to 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 ferra-menta 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 ne-cessitam gerenciar seu conteúdo organizacional (documentos eletrônicos, processos e capital inte-lectual) visando à tomada de decisões estratégicas e operacionais comprovadamente bem sucedidas em transações anteriores.

Engenharia de sistemas orientada ao conhecimentoSistemas de Gestão de Conteúdo Organizacional - Enterprise Content Manangement (ECM)

Enterprise Content Management (ECM), em português, Gerencia-dor de Conteúdo Organizacional,

é um novo conceito de tecnologia da informação que surge com a promes-sa 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), siste-mas 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 tec-nologia usada para capturar, gerenciar, armazenar e disponibilizar conteúdo e documentos relacionados com o pro-cesso organizacional. Um sistema ECM integra o gerenciamento da informação

Engenharia

Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros


GEStão DE CoNhECIMENto

estruturada, semiestruturada e não estruturada, como docu-mentos, 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 organi-zaçã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 proporcio-na 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 indi-víduo com a organização para gerar valor à mesma.

Dados, Informação e ConhecimentoDados, 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 conhe-cimento, 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 conheci-mento (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 re-levante 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 necessaria-mente 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 proces-samento 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.

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 pos-sui 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 organi-zaçõ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 conhe-cimento é 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 ConhecimentoA 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 compre-ensã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 trans-versal, 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 rele-vante 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 da-dos 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 tor-na possível que o conhecimento pessoal de um indivíduo possa ser convertido em conhecimento organizacional, que perma-necerá 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, junta-mente 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.


A organização deve manter, segundo os preceitos da gestão do conhecimento, duas visões opostas e ao mesmo tempo usá-las para encontrar o melhor caminho. Neste sentido a gestão do conhecimento ocorre através do conflito, com o chamado raciocínio dialético. O ponto inicial deste raciocínio é a tese de um processo organizacional. Esta tese, que pode ser formulada por um ou mais indivíduos, é negada com a apresentação de uma antítese. Desta dialética ocorre uma síntese, formulada com base nos preceitos da tese e antítese. O resultado desta síntese é uma nova tese de um processo. Com o tempo poderá haver a necessidade de aperfeiçoamento do processo (surgido da síntese), devido às pressões internas e externas sofridas pela organização. Esta tese de processo pode então se tornar a antítese de um processo atualizado, o que promoverá um novo movimento dialético de modo espiralado, conforme demonstrado na Figura 1.

Síntese 6

Tese 1 Antítese 2

Síntese 3 Tese 4

Tese 7

Antítese 5

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 conheci-mento 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 conhe-cimento 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 con-ceito 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 possi-bilitem 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

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 con-correntes, 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 conheci-mento 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 conhecimentoPara 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 princi-pal 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 princi-piantes é 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 alcan-ce 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 computa-dores 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 pro-mover 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 pes-soas 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 conhe-cimento é 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 ar-mazenado em um banco de dados que pode ser acessado por diferentes processos de recuperação. Neste sentido o conhe-cimento produz valor se focado em um determinado objetivo, pois o mesmo possui um modelo com estrutura inata, sendo

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 conhe-cimento, é 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 quan-tidade 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 apro-fundamento. 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 iden-tificar 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


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 pos-sui 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, apre-sentado 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

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 per-mite 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, plani-lhas, 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 siste-mas 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 ECMA escolha da UML para modelar um sistema ECM especia-

lista 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 repre-sentaçã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 interconecta-das através da visão de caso de uso é válida para compreensão do desenvolvimento de um sistema. As cinco visões corres-pondem 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 dia-gramas 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 re-lacionamentos; 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 inte-gração dos diversos módulos que formam um sistema ECM.

Figura 4. Modelagem da arquitetura de um sistema ECM (Fonte: Adaptado de Booch (2005))

Conforme Bezerra (2007) e Teorey (2007), a UML 2.0 pro-porciona a utilização das melhores práticas de modelagem de sistemas, fundamentadas em estudos realizados por es-pecialistas 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

Desenvolvimento

Visões do Projeto Diagramas

Análise Visão de Caso de Uso Diagrama de Caso de Uso

Projeto Visão de Lógica, Visão de

Processo

Diagramas de Objetos, Classes e

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


Segue abaixo o detalhamento de cada etapa de desenvolvi-mento 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 visuali-zaçã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 per-mitam 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 de-senvolvimento 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 conheci-mento 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 abs-traçõ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 vi-sã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: dia-gramas 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õesO 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.

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 co-nhecimento. 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.

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:<http://www.espacoacademico.com.br/058/58silvafilho.htm>.

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: <http://revista.ibict.br/index.php/ciinf/article/viewArticle/1087>

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.

Referências

Palestra “O Papel da Tecnologia da Informação na Gestão do Conhecimento” escrito por Ivan Correia Filagranahttp://gc.ivanfilagrana.com.br/wp-content/uploads/2009/11/Palestra-Sinergia-Gestao-do-Conhecimento.pdf

Links




Dê

seu Feedback

sob

re esta edição


Alexandre José de [email protected]

[email protected]

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). Enge-nheiro Químico pela UFPE (2001). É Analista Con-sultor 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 [email protected]

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 ex-periência na área de testes, tendo atuado como En-genheiro de Testes pelo Motorola Brazil Test Center.

Hermano Perrelli de [email protected]

Possui graduação em Engenharia Eletrônica pela Uni-versidade Federal de Pernambuco (1982), Mestrado em Informática pela Universidade Federal de Pernam-buco (1989) e PhD in Computing Science pela Univer-sity of Glasgow (1993). É certificado PMP (2003) pelo Project Management Institute. Atualmente é Profes-sor 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 re-visã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 li-mitaçõ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 atra-vés do qual a TIC está assumindo o seu papel estra-té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

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 ne-gócio, reduzir os custos de indisponibilidade, assegurar o retorno dos investimentos em TIC, aumentando assim a competitividade orga-nizacional. Neste contexto, a Governança em TIC está intimamente ligada ao alcance destes resultados.

Da Gestão à Governança em Tecnologia da Informação e Comunicação – TIC

Uma Visão Crítica

Com o crescimento populacional, a globalização e o desenvolvi-mento do capitalismo no século

XX, surgem novas necessidades para o ser humano. A quantidade de dados e in-formações para serem armazenas e com-putadas atinge um volume incalculável.

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 atualmen-te, a definição de informática não é tão

Agilidade

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

22 Engenharia de Software Magazine - Da Gestão à Governança em Tecnologia da Informação e Comunicação – TIC

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 computado-res, que são os responsáveis diretos pelo processamento dos dados (ALCALDE, 1991).

Evolução da Informática à TICNa 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 limita-dos e tinham sua aplicação restrita em função da incompatibi-lidade 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 gerencia-mento 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 com-putadores e as telecomunicações se tornam uma base tecno-ló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 drasticamen-te. 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 flexibili-dade 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 potencia-lizaçã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 tec-nologia. 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 com-putacionais 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 ativi-dades 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 inteli-gentes. 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 pro-dutividade 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


GEStão DE tI E AGILIDADE

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 TICCada 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 conside-rar 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 es-tritamente 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 resul-tados 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 im-plementaçã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”, “oti-mizaçã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

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 satis-fazer 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 orga-nização. Caso não obtenha sucesso em efetuar essa mudança, estará correndo o risco de ser considerada como estrategica-mente irrelevante (LOBATO, 2000).

Para o direcionamento deste papel estratégico da TIC é neces-sá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 conheci-mento, 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, carac-terizou 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 TICA 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, execu-tivo 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


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 carac-terí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, costu-mes, políticas, leis e instituições que afetam a forma como uma empresa é dirigida, administrada ou controlada. Gover-nanç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 abran-gência entre as áreas de conhecimento mencionadas. Uma das diferenças mais marcantes entre Gestão em TIC e Gover-nanç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.

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) afir-mam 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 ali-nhamento 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 mecanis-mos 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 investi-mento, 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 clas-sificação de 17 padrões e ferramentas de melhores práticas existentes em termos de variáveis, como: tipo de processo e

Figura 2. Diagrama de inter-relação entre as áreas citadas (Fonte: Elaboração própria)



organização. O trabalho citado aborda a investigação de como a Governança em TIC é adotada no caso de uma companhia líder no mercado mundial de biotecnologia em enzimas e micro-organismos industriais. Neste processo é realizada a revisão de 17 ferramentas de Governança em TIC.

Não se deseja aqui discutir em detalhes os êxitos ou melho-rias 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 TICNesta seção serão abordados oito modelos de Governança

em TIC mais difundidos no mercado, e que são mais frequen-temente 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ís-ticas, carências, dificuldades e limitações dos modelos apresen-tados, 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

especialmente aos provedores de serviço, podendo, inclusive, ser utilizado como um apoio para aqueles que oferecem ter-ceirizaçã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.

ITILITIL é 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 or-ganizados 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 funcionamen-to 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 Tec-nologia 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


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.

COBITO 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éc-nicas 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é proces-sos 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 objeti-vos, 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 expecta-tivas 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 audito-res” (ISACA, 2009a). Para tanto, o COBIT trabalha principal-mente 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 Gover-nanç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 re-forç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.

BSCO Balanced Scorecard – BSC é um modelo de gestão, de-

senvolvido em 1992 por Robert Kaplan e David Norton da Harvard Business School, para avaliar o desempenho estra-té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 Ba-lanceados 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, con-sequentemente 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 empre-sarial 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



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á in-timamente 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 FlexA metodologia IT Flex, com sua proposta de transformação

da área de TI em uma provedora de serviços de forma conti-nuada para a organização, parte da estruturação dos diferen-tes 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 oti-mizados para todo o ciclo de vida do serviço, a organização consegue associar os custos da área de TI ao valor produ-zido 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 necessida-des 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 consistente-mente as necessidades atuais das áreas de negócio e suportan-do 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;

• 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 finan-ceiros 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 Esta-dos 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 sig-nificativa 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 es-trutura 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 Inter-nal Control – Integrated Framework é um modelo de trabalho muito genérico, com visão de auditoria, muitas organizações


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 contro-les 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 20000A 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 inde-pendente, em conformidade com este referencial.

A ISO/IEC 20000 foi desenvolvida para responder às neces-sidades 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 pro-cessos 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 opera-cionais 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 ênfa-se 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 TIO 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 Forne-cimento 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.

MAnGveO 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 En-genharia 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



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, adap-tativa, 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 TICA 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 co-mentado 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

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 abor-dados é a ausência de orientações sobre sua aplicação prática. O que dificulta em muito a sua adoção por parte das orga-nizaçõ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 ser-viç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 minimi-zar 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

ou tamanho do negócio envolvido.

Não possui método de implantação.

Não contém um mapa detalhado dos processos.

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

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

todos os processos.

Está num nível mais genérico que o ITIL.

Não possui método de implantação.

Não define padrões de implementação, nem passos, técnicas ou

procedimentos para aplicação.

BSC Gerenciamento Estratégico Concentra-se no planejamento e gestão estratégica, através do monitoramento

de indicadores do negócio.

Não desce ao nível tático ou operacional, o que gera dificuldade de

alimentação dos indicadores.

Não possui orientações para sua aplicação.

IT Flex Gerenciamento de TIC Concentra-se em dotar a área de TIC de um elevado grau de flexibilidade

fazendo com que colabore com o aumento da adaptabilidade da organização.

Possui como proposta o conceito de “Fábrica de Serviços de TIC”.

Abordagem superficial e genérica.

Não define passos, técnicas ou procedimentos para aplicação.

COSO Governança Corporativa Modelo de trabalho para controle interno, muito genérico, com visão de

auditoria. Algumas organizações utilizam o COBIT para implantar o COSO.

Consegue ser mais genérico que o COBIT.

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

de TIC. Orienta o processo de certificação organizacional como resultado do

monitoramente face ao padrão documentado.

O alinhamento ao ITIL faz com que herde as mesmas carências e

limitações.

Val IT Governança Corporativa Baseado no COBIT, que provê uma estrutura para a governança de investimentos

de TIC. Complementa o COBIT no que diz respeito à perspectiva financeira e ao

valor de entrega de TIC.

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

orientação à sua aplicação.

CMMI Gerenciamento Processos É uma abordagem de melhoria de processos que fornece às organizações os

elementos essenciais de processos eficazes com a finalidade de melhorar seu

desempenho.

Não é focado em Governança, carecendo de alguma adequação neste sentido.

Possui um guia que orienta a sua aplicação, contudo é muito extenso e

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

prática, flexível, adaptativa e com o foco nas pessoas.

Sua adaptabilidade requer um grau de liderança significativo no papel do

MAnGveMaster

Grau de maturidade e auto-organização da Equipe envolvida.

tabela 1. Comparação entre os modelos revisados (Fonte: Elaboração própria)


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 abor-dagem inovadora e bem-vinda para complementar este próprio ICTGBOK, termo também proposto por Luna (2010).

ConclusõesNos últimos anos a TIC – Tecnologias da Informação e Comu-

nicaçã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 gerenciamen-to 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, abor-dou-se uma sucinta narrativa da evolução da informática até o que se conhece hoje como Tecnologias da Informação e Comu-nicaçã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.

Posteriormente, este artigo conceituou e delimitou o termo “corpo de conhecimento em Governança em TIC”, Information and Communication Technologies Governance Body of Know-ledge – ICTGBOK. Em seguida foram apresentadas nove aborda-gens 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).

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: <http://valuedrivenit.com/downloads/Value-Driven_IT.pdf>. Acesso em: 30/09/2009.

BIS - Bank for International Settlements (2006). Basel II: International Convergence of Capital

Measurementand Capital Standards. Disponível em: <http://www.bis.org/publ/bcbs128.pdf>.

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.

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: <http://computerworld.uol.com.br/gestao/2007/02/14/idgnoticia.2007-02-14.1400978239/ >. 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:

<http://computerworld.uol.com.br/gestao/2007/10/16/idgnoticia.2007-10-16.0083336108/ >.

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: <http://ec.europa.eu/information_

society/newsroom/cf/itemlongdetail.cfm?item_id=2994>, 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: <http://

www.questuspoint.pl/download/Z2Z4L2Fic3RyYWt0eS9wbC9kZWZhdWx0X29waXN5LzMzLzEvMQ

/k014.pdf >. 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.

Referências


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

sob

re esta edição



ISACA (2009). Disponível em: <http://www.isaca.org/ >. 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: <http://www.isoiec20000certification.

com/>. 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: <http://www.itgi.

org/>. Acesso em: 13/01/2009.

ITIL (2009). INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY. Disponível em: <http://www.

itil.co.uk/>.Acesso em: 10/01/2009.

itSMF (2008), IT Service Management Forum; An Introductory Overview of ITIL® V3. Disponível em: <http://www.best-management-practice.com/gempdf/itSMF_An_Introductory_Overview_of_ITIL_V3.pdf>. 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.

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: <www.

mangve.org>. 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: <http:// www.ogc.gov.uk>.

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: <http://papers.ssrn.com/sol3/papers.cfm?abstract_

id=978834>. Acesso em: 22/01/2009.

SEI. Software Engineering Institute (2009). Disponível em: <http://www.sei.cmu.edu/ cmmi/> .

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: <http://news.findlaw.com/hdocs/docs/gwbush/

sarbanesoxley072302.pdf>. 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: <http://www.unescap.

org/huset/gg/governance.htm>. 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.

Continuação: Referências

32 Engenharia de Software Magazine - Ferramentas para Gerência de Projetos

Marco Antônio Pereira Araú[email protected]

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 Ba-charelado 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 Edu-cacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora. Editor da Engenharia de Software Magazine.

Patrícia Lima Quintã[email protected]

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 Fa-culdade Metodista Granbery e do curso de Tecnolo-gia em Redes de Computadores da Faculdade Está-cio de Sá de Juiz de Fora. Supervisora de Segurança da Informação da Prefeitura de Juiz de Fora.

Jurema Florinda Lembe de Veiga [email protected]

Graduada em Sistemas de Informação pela Fa-culdade Metodista Granbery.

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 po-dem 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, aumen-tando a qualidade do gerenciamento e as chan-ces de alcançar os objetivos traçados.

Ferramentas para Gerência de ProjetosConheça as principais características das ferramentas mais populares

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 envol-vidas 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 gerenciamen-to de projetos existentes no mercado: o MS Project - um sistema desktop desenvolvido pela Microsoft; o Gantt Project - um sistema desktop, gratuito de

código aberto; o dotProject - um sistema desktop e distribuído sob a licença GNU-GPL; e o Project Open - um aplicativo de

Planejamento e Gerência

Nesta seção você encontra artigos voltados para o planejamento e gerência de seus projetos de software


GEStão DE PRojEtoS

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 ProjetosA adoção de ferramentas de gerenciamento de projetos pelas

organizações efetivamente gera resultados positivos, propi-ciando 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 fer-ramentas de gerenciamento de projetos propostas para este artigo. São elas: o MS Project, o Gantt Project, o dotProject e o Project Open.

Gantt ProjectO Gantt Project é uma ferramenta de gerenciamento de pro-

jeto 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 in-terface. É recomendada para situações em que a definição e

acompanhamento do cronograma é importante, assim como a necessidade de usá-lo em diversos sistemas operacionais e sua facilidade de uso.

dotProjectO 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 ma-nipulação de cronograma.

Project OpenO 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


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 proje-tos/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.

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 ativi-dades, 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 mes-mo 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 re-corrente, 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 progra-madas 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 ge-renciar 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 fi-nanç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 FerramentasNa Tabela 1 é feito um comparativo das ferramentas apre-

sentadas, 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 pos-suem 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 Pro-ject e MS Project são acessíveis através do desktop, enquanto dotProject e Project Open necessitam de um servidor Web. Por


GEStão DE PRojEtoS

RECURSOSFERRAMENTA

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 Desktop

Intercâmbio MS Project Não

Gantt

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áticoAgora 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 coman-dos 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 utili-zadas pelo usuário.• Área de Tabelas: é onde são cadastradas as tarefas do pro-jeto, 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 ProjetoAntes 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 ProjetoPara 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


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 TrabalhoDepois 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,

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, é orga-nizar 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


GEStão DE PRojEtoS

As datas das tarefas podem ser alteradas sempre que neces-sário sem afetar o projeto, pois o Project reagendará automati-camente 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 TarefasApós seguir todos os passos descritos anteriormente, deve-

se 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 depen-dências que o Project oferece. Após isso, devem-se selecionar as tarefas dependentes e clicar no tipo de dependência dese-jada. 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 ProjetoApó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

programa abrirá uma tela com informações sobre a tarefa. Na aba Resources (Recursos), em Resources Name (Nome do Recur-so) é 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 ProjetoA 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, pode-se usar o projeto simulado neste estudo, o custo inicial da areia, que poderia aumentar por motivos de inflação, fa-zendo 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 pro-cedimentos 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 proje-to, pois é possível que o anterior tenha ficado obsoleto.

Diagrama de Rede e Uso de TarefasNo MS Project, o projeto pode ser visualizado de várias for-

mas, 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 demons-trados 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.


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 alo-cados 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 acrescen-tar 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.

Emitir Relatórios do ProjetoOs 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 expli-car 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 Re-ports (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 (Vi-sã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.


GEStão DE PRojEtoS

ConclusãoAs 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, do-tProject e Project Open. Alem disso, com um pouco mais de



www.devmedia.com.br/esmag/feedbackD

ê se

u Feedback

sob

re esta edição

DotProject - http://dotproject.net/

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/

Referências

detalhas, observamos o uso da ferramenta MS Project, que é um poderoso instrumento na gerência de projetos.

COMIDA

Existem coisasque não conseguimosficar 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

40 Engenharia de Software Magazine - Reportando de forma simples os resultados dos testes

Daniel Scaldaferri [email protected]

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 Ba-charel em Ciência da Computação pela UFMG. Atualmente é Coordenador da equipe de Qua-lity Assurance da CPM Braxis, filial BH. Sua ex-periê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 do-cê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.

De que se trata o artigo?Este artigo apresenta uma maneira simples e ob-jetiva para reportar os resultados dos testes fun-cionais, sejam eles diários ou finais, assim como os benefícios que podem ser extraídos a partir das in-formaçõ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 de-finição do conteúdo necessário e suficiente.

Reportando de forma simples os resultados dos testesTécnicas simples e objetivas para reportar os resultados das atividades de testes

Para todas as atividades planeja-das e executadas dentro de um projeto, seja ele de desenvolvi-

mento 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 infor-mações, entre eles, o cliente, o gerente do projeto, o patrocinador e as equipes responsáveis pelas demais etapas do processo de desenvolvimento do softwa-re. 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 perio-dicidade ideal irá depender da duração do projeto e do custo do controle, pois quanto maior o controle maior o custo),

os envolvidos terão base para a tomada de decisões, uma vez que será possível comparar o status atual com o planejado.

Desenvolvimento

Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software


VALIDAção, VERIFIC Ação & tEStE

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 Tes-tes, 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 pro-jeto 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

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 ati-vidade de testes. Cada uma das categorias será apresentada nos próximos itens.

Relatório Corrente dos TestesEsta 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 andamen-to 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 interessan-te, 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 inseri-dos 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árioComo 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ãoEste é o item principal do status report. Todos os demais aju-

darã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


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 alter-nativos, 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



Data 10/4/2010

Nome dos testadores Karla Lages

Nome UC Nº CTsEXECUTADOS COM

SUCESSO

NÃO EXECUTADOS ou COM

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 per-centual 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% executa-dos 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 quantida-de 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

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 TestesO progresso dos testes mostra a evolução da atividade ao

longo dos dias reservados para a realização da mesma. A Fi-gura 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.

Figura 3. Forma tabular para conclusão da atividade de execução dos testes

Faltando apenas dois dias para terminar, apenas 19% da ati-vidade 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 pro-

gresso 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


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 é bastan-te 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 con-trolar 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 re-alizados está bastante próximo ao dos casos de testes possíveis

de serem executados, ou seja, dos liberados. A diferença recai sobre os casos de testes que falharam, estão bloqueados, ou re-almente 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 IncidentesA quantidade de falhas registradas, e suas características, como

por exemplo, criticidade, prioridade e localização, são fatores im-portantes 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 tam-bé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 AcumuladoOutra informação importante a respeito das falhas regis-

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

O eixo x representa o tempo, ou seja, os dias. O eixo y repre-senta a quantidade de falhas registradas. No primeiro dia de testes, dia 07/03 foram registradas 17 falhas. O gráfico apre-senta 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, manten-do 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, principal-mente 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 regis-tradas, 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 res-ponsá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 interes-sante, 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 ocorri-dos 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.


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 corri-gido. 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. Aguar-dando 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 ve-rificar 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 indisponibilida-de do servidor através da planilha da Figura 12. Poderão ser registradas as interrupções voluntárias, ou seja, para-das 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.

Relatório Final dos TestesEste relatório normalmente é emitido no final da ativida-

de de execução dos testes. Ele irá apresentar o resultado, consolidando várias informações coletadas durante o an-damento 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 proces-so 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, identi-ficando 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

Nome do Sistema ESMAG



Evidências colhidas? Sim

Período de testes previsto DE: 04/01/2010 ATÉ: 29/01/2010

Quantidade de horas de testes previsto 352

Período dos testes realizados DE: 04/01/2010 ATÉ: 05/02/2010

Quantidade de horas dos testes realizados 440

Diferença entre previsto e realizado 88 % 25,00%

Nome dos testadores Karla Lages, Felipe Lages

Nº de casos de testes 141

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

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

Nº de ct não executados no tempo realizado 0 % 0,00%

Qualidade do Plano de Teste Sistema Boa

Qualidade da Especificação EF Boa

tabela 3. Informações gerais do Relatório de Finalização dos Testes



Figura 12. Controle de Indisponibilidade do Servidor

Resumo de Incidentes

Total de incidentes 110Taxa de incidente por hora

Ex.: 1 incidente a cada X horas4,00

Total de falhas

(Exceto ‘Não é um caso’, sugestões e ‘Duplicado’)100

Taxa de falhas por hora

Ex.: 1 falha a cada X horas4,40

Falhas dentro do escopo 100

Falhas fora do escopo 0

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

o processo, como por exemplo, reabertura de falhas, falhas abertas indevidamente (testador também erra!) e falhas registradas duplicadamente.

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


é 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õesAo 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 encon-trados 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 pro-cesso de testes, maior será o custo das suas atividades, pois as tarefas de coleta, preparação e análise dos dados, assim como

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.

Referências




Dê

seu Feedback

sob

re esta edição

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.


Elessandro Rodrigues Marques [email protected]

É 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 em-presa Colchões Paropas.

Jenifer Vieira Toledo [email protected]

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 En-sino Superior de Juiz de Fora (CES/JF) e Técnica de Hosting da empresa Optical Soluções em Informática Ltda.

Marco Antônio Pereira Araújo [email protected]

É Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Computacionais e Bacha-rel em Informática pela UFJF, Professor dos Cur-sos 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 Pre-feitura de Juiz de Fora, Editor da Engenharia de Software Magazine.

Marcelo Santos Daibert [email protected]

Twitter: @msdaibert

É Mestre e Especialista em Ciência da Compu-tação pela Universidade Federal de Viçosa, pro-fessor e coordenador do Curso de Bacharelado em Ciência da Computação da FAGOC (Facul-dade 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.

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 utili-zação da abordagem baseada em testes no desen-volvimento 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. Nes-se 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.

Teste unitário e de cobertura para Java Script com JsUnit e JsCovarage

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

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.

Desenvolvimento

Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software

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

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 res-ponsabilidade 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 con-trolar 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 bi-lhõ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,

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: Refac-toring 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 disponibi-lidade dos sistemas com testes integrados automatizados. Desta forma, permite aos desenvolvedores serem mais ou-sados nas modificações do software alcançando um desen-volvimento 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 é ana-lisado, e um fundamental conceito é o de caso de teste, que representa uma instância de teste para aquela funcionalida-de 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 CoberturaO teste de cobertura é responsável por verificar se o teste

unitário está verificando todos os caminhos possíveis do al-goritmo 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.



JsUnitJsUnit é 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. Algu-mas 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 combi-naçõ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 compo-nente de software escrito na linguagem Java Script que dis-ponibiliza 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.htmlpágina web configurada como um painel para a execução dos testes unitários

com o JsUnit.

appdiretório onde o núcleo da ferramenta é apresentado e onde o arquivo

jsUnitCore.js é disponibilizado.

cssdiretó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

javadiretó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 “tes-te_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 tes-teB retorna falso (false). Já as funções teste_verificacao1 e teste_verificacao2 aferem o resultado das funções testeA e

testeB. No exemplo, o primeiro caso de teste afere o resul-tado 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. <html>2. <head>3. <title>Teste Unitário 1</title>4. <script type=”text/javascript” src=”app/jsUnitCore.js”> </script>5. <script type=”text/javascript”>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. </script>19. </head>20. <body>21. </body>22. </html>

Para a execução dos testes, é necessário executar o testRun-ner.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


Na tela de resultado é possível observar o erro que foi inten-cionalmente 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 <true> but was <false>” – Esperado <verdadeiro> mas foi <falso>. 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

JsCoverageJsCoverage é uma ferramenta que faz testes de cobertura em

programas escritos na linguagem JavaScript. Para conseguir

Figura 2. Resultado do Teste no testRunner

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 instrumen-tar 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á den-tro 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 dire-tó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 ser-vidor 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 arqui-vo 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 jscoverage-server 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 configu-raçã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. <html>2. <head>3. <title>Teste de Cobertura</title>4. <script type=”text/javascript” src=”script.js”> </script>5. </head>6. <body>7. <form name=”frmTeste” action=”” onSubmit=”enviaJavaScript()” method=”post”>8. Valor: <input type=”text” name=”inptValor”>9. <input type=”submit” value=”Enviar...”> 10. </form>11. </body>12. </html>

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 instru-mentaçã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 inter-face, digitando, por exemplo, o valor 200. O Java Script irá ser

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 inter-face 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 fi-nal (notaFinal) e a freqüência, como pode ser observado pela Listagem 4.


O calcularAprovacao verifica inicialmente se a frequência do aluno é menor que 75%. Caso seja, o aluno é reprovado de ime-diato, 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 Ci-clomá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 informa-dos. 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 calcula-rAprovacao, na Listagem 4. A função basicamente captura os

Figura 7. Cobertura da Função enviaJavaScript()

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

1. <html>2. <head>3. <title>JsUnit Test Aprovação </title>4. <link rel=”stylesheet” type=”text/css” href=”css/jsUnitStyle.css”>5. <script type=”text/javascript” src=”app/jsUnitCore.js”></script>6. <script type=”text/javascript” src=”avaliarAluno.js”></script>7. <script type=”text/javascript”>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. </script>24. </head>25. <body>26. <h1>Teste com as Assertivas JsUnit</h1>27. <p>Esta página contém testes para as funções assertivas do JsUnit.</p>28. <form name=”frmTeste” onsubmit=”return executaJS()” action=””>29. Nota 1: <input type=”text” name=”edtNota1” /> <br>30. Nota 2: <input type=”text” name=”edtNota2” /> <br>31. Nota Final: <input type=”text” name=”edtNotaFinal” /> <br>32. Frequência: <input type=”text” name=”edtFrequencia” /> <br><br>33. <input type=”submit” value=”Enviar”>34. </form>35. </body>36. </html>



valores do formulário e invoca a função calcularAprovacao(), exibindo o resultado final ao usuário.

Execução dos TestesCom 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 à ferra-menta 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 fer-ramenta 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 so-mente 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, apre-sentando 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_AprovacaoDiretoPorNo-ta). Buscando investigar, foi acionada a opção de visualizar o relatório do jsCoverage (Coverage Report) e o resultado é exibido na Figura 9.

Na Figura 9 são apresentados os resultados do teste de cober-tura 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 visuali-zado, está sendo mostrado em vermelho.

Como foi dito, o caso de teste testVericarAprovacao_Apro-vacaoDiretoPorNota 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 calcularApro-vacao para que sejam aprovados os alunos com média supe-rior 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 FinaisUma 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 Figura 8. Resultado do jsUnit – Estudo de Caso

Figura 9. Resultado do jsCoverage – Estudo de Caso


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 xUnithttp://xunitpatterns.com/

JsUnithttp://www.jsunit.net/

JsCoveragehttp://siliconforks.com/jscoverage/

Links




Dê

seu Feedback

sob

re esta edição

Figura 11. Resultado do jsCoverage – Estudo de Caso – Erro Resolvido

Figura 10. Resultado do jsUnit – Estudo de Caso – Erro Resolvido

Para isso, uma outra técnica conhecida como Particionamento por Classes de Equivalência, auxiliada por outra técnica cha-mada 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 desen-volvedores 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.



Documents

Engenharia de Software - Edição 25