ES 05 Usabilidade de Software PDF

ISSN 1983127-7
9 771983 127008 00005

Conhecimento
faz diferença!
Capa ESM - Final .pdf 19.02.08 18:15:13
Engenharia de Software
Saiba seu significado e para que serve
magazine
Edição Especial

Entenda os principais conceitos sobre
Testes e Inspeção de Software
Verificação, Validação & Teste

Ferramentas Open Source e melhores
práticas na gestão de defeitos
Requisitos Projeto
Conheça os principais conceitos envolvidos Entenda o conceito de Arquitetura de Software e
na Engenharia de Requisitos como trabalhar com os Estilos Arquiteturais
Especial Processos
Mais de 60 mil downloads
Melhore seus processos através da
análise de risco e conformidade
Veja como integrar conceitos de
Modelos Tradicionais e Ágeis
Veja como integrar o Processo
Unificado ao desenvolvimento Web
na primeira edição!
Faça já sua assinatura digital! | www.devmedia.com.br/es
Faça um up grade em sua carreira.

Em um mercado cada vez mais focado em qualidade ter conhecimentos aprofundados sobre requisitos, metodologia, análises,
testes, entre outros, pode ser a diferença entre conquistar ou não uma boa posição profissional. Sabendo disso a DevMedia
lança para os desenvolvedores brasileiros sua primeira revista digital totalmente especializada em Engenharia de Software.
Todos os meses você irá encontrar artigos sobre Metodologias Ageis; Metodologias tradicionais (document driven);
ALM (application lifecycle management); SOA (aplicações orientadas a servicos); Analise de sistemas; modelagem; Métricas;
orientação à objetos; UML; testes e muito mais. Assine já!
EDITORIAL
engenharia
magazine
“Um produto, seja um sistema de software ou outro qual-
de software
quer, possui usabilidade que é um dos atributos da qualidade
perceptível aos usuários. A usabilidade é uma característica
de um produto que informa quão fácil de usar e aprender esse
produto é. Em outras palavras, serve como um indicador de
Ano 1 - 5ª Edição 2008 Impresso no Brasil quão intuitivo é utilizar aquele produto. Essa característica é
determinante no sucesso desse produto, pois ela influencia
diretamente o interesse do usuário em utilizar ou não esse
Corpo Editorial
produto ou sistema (de software). Para tanto, em sistemas de
Colaboradores software, assim com em outros produtos, a usabilidade é ava-
Rodrigo Oliveira Spínola liada durante o processo de desenvolvimento visando asse-
rodrigo@sqlmagazine.com.br gurar o nível desejado de usabilidade.”
Marco Antônio Pereira Araújo Neste contexto, a Engenharia de Software Magazine destaca
Eduardo Oliveira Spínola nesta edição duas matérias com foco em usabilidade. Em uma
delas, são discutidos os principais conceitos sobre usabilidade
Editor de Arte
Vinicius O. Andrade
como esta pode ser inserida em um processo de desenvolvi-
viniciusoandrade@gmail.com mento de software.
Em complemento a esta matéria, o segundo artigo apresen-
Capa ta um conjunto de definições associadas à avaliação da usa-
Antonio Xavier
bilidade da interface de usuário de sistemas de software ou
antonioxavier@devmedia.com.br
outros produtos. Neste cenário, é apresentado um conjunto
Na Web de métodos de avaliação de usabilidade, classificados como
www.devmedia.com.br/esmag testes, pesquisa e inspeção.
Apoio
Além destas duas matérias, esta quinta edição traz mais seis
artigos:
• Analisando o Desenvolvimento de Software Orientado a
Aspectos no contexto de Extreme Programming;
• Especificação de Requisitos com Casos de Uso;
• Cuidados na Aplicação da Análise de Pontos de Função no
Parceiros: Relacionamento entre Usuário e Desenvolvedores;
• Melhores Práticas na Automação de Testes;
• Modelagem de Processos de Negócio com Uso do NetBeans;
• Gestão de Serviços Operacionais Aplicada à TI.
Desejamos uma ótima leitura!

Equipe Editorial Engenharia de Software Magazine
Atendimento ao Leitor Rodrigo Oliveira Spínola

A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. rodrigo@sqlmagazine.com.br
Se você tiver algum problema no recebimento do seu exemplar ou precisar de Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação
bancas de jornal, entre outros, entre em contato com: (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo mi-
Carmelita Mulin – Atendimento ao Leitor nistrado cursos na área de Qualidade de Produtos e Processos de Software, Requisitos
www.devmedia.com.br/central/default.asp e Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS.BR.
(21) 2220-5375
Kaline Dolabella Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na
Gerente de Marketing e Atendimento COPPE/UFRJ. É Colaborador da Engenharia de Software Magazine.
kalined@terra.com.br
(21) 2220-5375 Marco Antônio Pereira Araújo
Publicidade (maraujo@devmedia.com.br)
Para informações sobre veiculação de anúncio na revista ou no site entre em É Doutorando e Mestre em Engenharia de Sistemas e Computação pela COPPE/
contato com: UFRJ – Linha de Pesquisa em Engenharia de Software, Especialista em Métodos
Kaline Dolabella Estatísticos Computacionais e Bacharel em Matemática com Habilitação em
publicidade@devmedia.com.br Informática pela UFJF, Professor dos Cursos de Bacharelado em Sistemas de
Fale com o Editor!
Informação do Centro de Ensino Superior de Juiz de Fora e da Faculdade Me-
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo
todista Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora. É editor da
você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a
Engenharia de Software Magazine.
vontade para entrar em contato com os editores e dar a sua sugestão!
Eduardo Oliveira Spínola
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
(eduspinola@gmail.com)
entre em contato com os editores, informando o título e mini-resumo do tema que você
É Editor das revistas Engenharia de Software Magazine, SQL Magazine, WebMo-
gostaria de publicar:
bile. É bacharel em Ciências da Computação pela Universidade Salvador (UNI-
Rodrigo Oliveira Spínola - Colaborador
FACS) onde atualmente cursa o mestrado em Sistemas e Computação na linha
editor@sqlmagazine.com.br
de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de
Software e Aplicações).
Caro Leitor,
Para esta quinta edição, temos um conjunto de 10 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da Engenharia de Software
Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
Tipo: Verificação, Validação e Teste manter a qualidade do código fonte de aplicações Java. Tipo: Engenharia de Requisitos
Autor: Marco Antônio Pereira Araújo Autor: Rodrigo Oliveira Spínola
Título: Teste Unitário com Objetos Mock Tipo: Engenharia de Requisitos Título: Introdução à Engenharia de Requisitos - Parte 16
Mini-Resumo: Esta vídeo aula apresenta a aplicação de Autor: Rodrigo Oliveira Spínola Mini-Resumo:Nesta décima sexta parte, finalizaremos
objetos Mock em testes unitários com JUnit, com o objetivo Título: Introdução à Engenharia de Requisitos - Parte 13 o estudo de caso para elaboração de um diagrama de
de substituir classes e métodos ainda não implementados, Mini-Resumo: Esta vídeo aula é parte do curso de intro- casos de uso para um módulo de gestão de usuários de
proporcionando a realização de testes unitários. dução à engenharia de requisitos. Nesta décima terceira um sistema de informação fictício.
parte daremos início à parte mais prática do curso. Nesta
Tipo: Verificação, Validação e Teste aula apresentaremos uma ferramenta case para elabora- Tipo: Engenharia de Requisitos
Autor: Marco Antônio Pereira Araújo ção de diagramas de casos de uso e daremos início a um Autor: Rodrigo Oliveira Spínola
Título: Teste em Bancos de Dados com DBUnit estudo de caso para elaboração de um diagrama de casos Título: Introdução à Engenharia de Requisitos - Parte 17
Mini-Resumo: Esta vídeo aula apresenta a aplicação de de uso para um sistema de locadora de veículos. Mini-Resumo: Esta vídeo aula é parte do curso de intro-
testes unitários em bancos de dados com DBUnit, uma vez dução à engenharia de requisitos. Nesta décima sétima
Tipo: Engenharia de Requisitos parte apresentaremos um estudo de caso para elaboração
que o estado de bases de dados é fundamental na condução
Autor: Rodrigo Oliveira Spínola de um diagrama de casos de uso para um módulo de ges-
de testes de unidade automatizados.
Título: Introdução à Engenharia de Requisitos - Parte 14 tão de usuários de um sistema de informação fictício.
Tipo: Projeto Mini-Resumo: Nesta décima quarta parte finalizaremos
Autor: Rodrigo Oliveira Spínola nosso primeiro estudo de caso referente à elaboração de Tipo: Engenharia de Requisitos
Título: Introdução à Construção de Diagrama de Classes um diagrama de casos de uso para um sistema de locadora Autor: Rodrigo Oliveira Spínola
da UML – Parte 1 de veículos. Título: Introdução à Engenharia de Requisitos - Parte 18
Mini-Resumo: Esta vídeo aula apresenta as definições iniciais Mini-Resumo: Nesta décima oitava parte, finalizaremos
envolvidas na construção de diagramas de classes da UML. Tipo: Engenharia de Requisitos o estudo de caso para elaboração de um diagrama de
Autor: Rodrigo Oliveira Spínola casos de uso para um módulo de gestão de usuários de
Tipo: Projeto Título: Introdução à Engenharia de Requisitos - Parte 15 um sistema de informação fictício.
Autor: Marco Antônio Pereira Araújo Mini-Resumo: Esta vídeo aula é parte do curso de introdução à
Título: Refatoração de código no Eclipse engenharia de requisitos.Nesta décima quinta parte apresentare-
Mini-Resumo: Esta vídeo aula apresenta a utilização de mos um estudo de caso para elaboração de um diagrama de casos
técnicas de refatoração na IDE Eclipse com o intuito de de uso para um sistema de vendas de passagem aérea.
ÍNDICE
06 - Extreme Programming
Rafael do Espírito Santo, Rodrigo P. dos Santos e Paulo Sérgio M. dos Santos
14 - Especificação de Requisitos com Casos de Uso
Rodrigo O. Spínola e Eduardo O. Spínola
24 - Usabilidade de Software
Antonio Mendes da Silva Filho
30 - Avaliação de Usabilidade
Antonio Mendes da Silva Filho
36 - Cuidados na Aplicação da Análise de Pontos de Função

Carlos Eduardo Vazquez
42 - Melhores Práticas na Automação de Testes

Cristiano Caetano
48 - Modelagem de Processos de Negócio com Uso do NetBeans

André Luiz de Castro Leal
56 - Gestão de Serviços Operacionais Aplicada à TI

Alexandre Bartie
4 Engenharia de Software Magazine

Desde 2004 Trazendo Teoria para a Prática
Treinamento e Consultoria
em Engenharia de Software
Profissionais com ampla experiência prática (Consusltores Certificados) e

acadêmica (Professores Universitários, Mestres e Doutores)
Know-how para implementar processos de software de acordo com modelos

de qualidade (MPS e CMMI) e maximizar o retorno de investimento
Cursos 2008: Inscrições Abertas Certificados emitidos pela Kali Software
Outubro | Novembro Testes de Software – 16 horas
Outubro | Novembro Projeto Orientado a Objetos com UML e Padrões – 24 horas
Novembro Engenharia de Requisitos – 24 horas
Novembro | Dezembro Linguagem Java com ênfase na certificação SCJP da Sun – 32 horas
Confira nossos cursos in-company, elaborados de acordo com as necessidades de treinamento de sua empresa
Confira as ementas, investementos e condições de pagamento: www.kalisoftware.com
Inscrição e outras informações: info@kalisoftware.com
kalisoftware.com | info@kalisoftware.com
Extreme Programming
Analisando o Desenvolvimento de Software Orientado a
Aspectos no contexto de Extreme Programming
De que se trata o artigo?

Este artigo apresenta como os conceitos
C
de programação orientada a aspectos
Rafael do Espírito Santo onsiderando que time-to-market influenciam a metodologia XP para desen-
rafael.santo@ufrj.br e volatilidade de requisitos de volvimento de software.
Estudante de Ciência da Computação da Universi- software compreendem fatores
dade Federal do Rio de Janeiro (UFRJ).
Ex-membro da Empresa Júnior de Consultoria em
cruciais para a criação de valor para o Para que serve?
Microinformática da UFRJ (EJCM). processo de desenvolvimento de sof- Indicar pontos positivos e riscos associados
Atua no desenvolvimento de sistemas em proje- tware, cada vez mais novas estratégias do uso destas abordagens em conjunto.
tos de consultoria na COPPE/UFRJ são pesquisadas a fim de atender satis-
fatoriamente os diferentes pontos de Em que situação o tema é útil?
Rodrigo Pereira dos Santos vista dos stakeholders envolvidos [Boehm, Para aqueles que tenham interesse em tra-
rps@cos.ufrj.br 2006]. Neste cenário, destacam-se os balhar com POA no contexto de XP e saber
É bacharel em Ciência da Computação formado processos de desenvolvimento baseados quais são os benefícios e principais riscos
na Universidade Federal do Lavras. Atualmente
em metodologias ágeis [Shore e Warden, do uso destas abordagens em conjunto.
cursa o mestrado na linha de Engenharia de Sof-
tware pela COPPE/UFRJ. 2007] [Beck, 2000], os quais focam em
comunicação constante, projeto mini-
malista e codificação simplificada. Por XP se baseia nos princípios ágeis, que
Paulo Sérgio Medeiros dos Santos essas características, tais processos têm contemplam melhorias nas relações com
pasemes@cos.ufrj.br
despertado o interesse de empresas e de os clientes e entre os membros da equi-
É bacharel em Ciência da Computação formado
na Universidade Federal do Rio de Janeiro. Atual- grupos de pesquisa, com destaque para pe, realçando o ambiente e os recursos
mente cursa o mestrado na linha de Engenharia o Extreme Programming (XP), devido às disponíveis na organização e buscando
de Software pela COPPE/UFRJ onde atua, princi- práticas e aos valores adotados durante “quebrar” problemas grandes em um
palmente, nas áreas de serviços Web, integração o desenvolvimento, tais como integração conjunto de vários sub-problemas, com
de ferramentas, gestão desconhecimento e en-
contínua, programação em pares, refato- o intuito de melhorar a qualidade das
genharia de software experimental.Possui 7 anos
de experiência em desenvolvimento de software ração de código e programação baseada soluções [Teles, 2005].
sendo 5 anos trabalhando com Java e 2 anos com em testes (Test-Driven Development – TDD) Por outro lado, um dos fatores que im-
JavaServer Faces. [Paulk, 2000]. A estrutura do processo pactam o desenvolvimento de software
6 Engenharia de Software Magazine - Extreme Programming

M etodologia s ágeis
está na escolha adequada de metodo- e não é dirigido por planos. Este trabalho porte, através de extensões que enfati-
logias e tecnologias durante a etapa de tem por objetivo analisar características zem feedback constante, projeto de sof-
planejamento de um projeto, sobretudo (valores, princípios e práticas) de XP tware e criação de novos papéis no ciclo
perante o aumento da complexidade dos de forma a confrontá-las com algumas de desenvolvimento [Lipert et al., 2003]
domínios de aplicação [Travassos et al., questões críticas relativas ao DSOA, o [Eckstein, 2006]. Estas extensões foram
2001]. Isso tem levado empresas e grupos que representa um primeiro passo para aplicadas em projetos de diferentes pers-
de pesquisa a voltarem a sua atenção se pensar em avaliar a aplicabilidade de pectivas (web, desktop, processamento
para o desenvolvimento e adoção de DSOA em diferentes contextos, buscan- em batch, dispositivos móveis), localiza-
tecnologias que auxiliem o processo de do por possíveis impactos positivos e/ ção (localizadas dentro das instalações
desenvolvimento. Particularmente em ou negativos. do cliente ou em ambientes externos),
XP, tem-se buscado por tecnologias que número de integrantes e qualificação
melhorem a elaboração e organização de Conhecendo XP dos profissionais envolvidos, e tem como
produtos de software e que aumentem Dado que mudanças, comunicação e objetivo prover meios de lidar com pro-
a produtividade dos desenvolvedores, pessoas representam fatores inerentes jetos de domínio de negócio complexo
evitando desviar a sua atenção dos reais ao desenvolvimento de software de sem limitar as vantagens oferecidas
objetivos do negócio do cliente, repre- qualidade [Sato, 2007], o final da década pelo processo de desenvolvimento ágil
sentados pelos requisitos funcionais de 1990 presenciou o surgimento das de software.
– documentados nas chamadas histórias metodologias ágeis. O desenvolvimento A base de XP está sedimentada sobre
em XP. Nessa linha, o Desenvolvimen- ágil foi criado com o intuito de melhorar quatro valores: (i) comunicação; (ii) simpli-
to de Software Orientado a Aspectos o desempenho de projetos de software cidade; (iii) feedback; e (iv) coragem [Beck
(DSOA) surge como uma abordagem ao buscar a diminuição da ineficiência, e Andres, 2004]. Além destes, recente-
que objetiva ampliar a reusabilidade e da burocracia de métodos dirigidos a mente observou-se a importância de
a manutenibilidade de software, ao se planos e de qualquer outra coisa que não se considerar um novo valor, o respeito.
basear no isolamento de certas funcio- adicione valor ao produto de software XP preza pela comunicação constante
nalidades em unidades encapsuladas [Tichy, 2004]. O conceito de agilidade entre os membros da equipe e destes
[Elrad et al., 2001]. ganhou destaque a partir do Manifesto com os clientes, e pelo desenvolvimento
Na concepção de Kiczales et al. (1997), do Desenvolvimento Ágil de Software do sistema focado no atendimento às
nem as técnicas de programação orien- [Beck et al., 2001], o qual aponta quatro necessidades do cliente da maneira mais
tada a objetos (POO) nem as técnicas da valores principais: (i) indivíduos e intera- simples possível. O processo XP enfatiza
programação procedural são suficientes ções vêm antes de processos e ferramentas; que o feedback agrega três perspectivas:
para implementar com clareza impor- (ii) software funcionando vem antes de do- do sistema (através da utilização cons-
tantes decisões do projeto. A Orientação cumentação abrangente; (iii) colaboração do tante de testes de unidade), do cliente
a Aspectos (OA) estende a orientação a cliente vem antes de negociação de contrato; (por meio de testes de aceitação) e da
objetos (OO) com o intuito de tratar o e (iv) resposta à modificação vem antes do equipe de projeto (através da comu-
entrelaç amento e o espal hamento de plano em andamento. nicação constante). Por outro lado, a
certos requisitos (interesses transversais Dentre as metodologias ágeis mais coragem reforça o fato de que as tarefas
ou crosscutting concerns) [Filman et al., utilizadas, destaca-se o Extreme Pro- não devem ser adiadas, ou seja, devem
2004]. No entanto, apesar das melhorias gramming (XP), atribuído a Kent Beck, ser desempenhadas o quanto antes,
almejadas, alguns pontos podem difi Ron Jeffries e Ward Cunningham [Beck, colaborando para que os desenvolve-
cultar a reutilização e a manutenção, 2000]. XP tem como premissa técnica a dores se sintam mais confortáveis com
tais como a inversão de dependência combinação de: (i) inserção do cliente a refatoração do código. Por fim, o res-
e a inconsciência [Santos et al., 2007], no projeto; (ii) liberações de pequenos peito se mostra, por exemplo, por meio
fato este decorrente do estágio atual do incrementos ao longo das iterações no do respeito mútuo entre os membros
DSOA rumo à aplicabilidade em pro- desenvolvimento; (iii) projeto simples; da equipe, com o objetivo de evitar a
jetos reais e na indústria, visando seu (iv) programação em pares; (v) refatora- desvalorização do trabalho de qualquer
amadurecimento. ção; e (vi) integração contínua, visando membro da equipe de trabalho (e nem
Dessa forma, faz-se necessária uma uma curva mais branda do custo de prejudicá-lo) e almejar uma equipe mais
análise acerca de quais são os possíveis mudanças com relação ao tempo [Beck, confiante e motivada.
impactos positivos e negativos que uma 2000]. XP apresenta maior aplicabilidade Beck e Andres (2004) afirmam que os
abordagem como DSOA provocaria em em pequenos projetos, de risco relativa- cinco valores representam critérios que
ambientes reais (empresas de pequeno mente baixo, envolvendo pessoal alta- visam uma solução de sucesso para
e médio porte), especialmente naqueles mente capacitado e requisitos passíveis projetos de software. Entretanto, eles
que adotam os princípios e práticas de de mudanças [Boehm, 2006]. colocam que esses valores são vagos
XP, onde isso se torna fundamental, dado No entanto, estudos mostram que é demais para auxiliarem na escolha das
que esse processo se baseia na agilidade possível aplicar XP em projetos de maior práticas que suportam XP e apontam
Edição 05 - Engenharia de Software Magazine 7

vários princípios concretos derivados • 40-horas por semana (folga): des- com características de XP. De forma
desses valores. Além disso, XP se utiliza taca a importância da carga horária de sintetizada, os autores entendem que
de determinadas práticas que, se bem or- trabalho não ultrapassar 40 horas por a comunicação é influenciada de forma
ganizadas, oferecem um reforço mútuo semana, sempre que possível, a fim de positiva enquanto os valores coragem e
com o intuito de se complementarem evitar o estresse dado que XP busca ser feedback não sofrem interferência direta
[Beck e Andreas, 2004]: um processo altamente disciplinado. pela adoção de DSOA. Quanto ao valor
• Jogo do planejamento: consiste Horas-extras são permitidas desde que simplicidade, os autores concordam com
na rápida determinação do escopo da não ultrapassem duas semanas seguidas a existência de pontos positivos, mas
próxima release (versão), combinando as e foquem na conclusão das histórias cor- não questionam a existência de possí-
prioridades de negócio com as estimati- respondentes a uma dada iteração; veis pontos negativos. Considerando os
vas técnicas. O cliente define o escopo, a • Cliente presente: busca ter um cliente princípios de XP, notou-se que somente
prioridade e as datas de uma perspectiva (usuário real) integrado à equipe durante alguns deles foram abordados diante de
de negócios, enquanto a equipe técnica o desenvolvimento do projeto, de forma questões de DSOA. Já nas práticas de XP,
estima e rastreia o progresso; que seu papel seja avaliar e mediar as os autores afirmam que a programação em
• Pequenas versões: visa colocar um funcionalidades implementadas. pares não apresenta impacto direto com
sistema simples em operação rapidamen- • Padrões de codificação: objetiva a relação à adoção de DSOA, enquanto a
te, ou seja, liberar novas versões em um definição de regras que enfatizam a legi- publicação de versões curtas é influenciada
tempo muito curto, normalmente duas bilidade e que permitam a comunicação positivamente, devido à possibilidade
semanas; entre os desenvolvedores através do de integração das diferentes versões por
• Histórias (metáfora): pretendem código (padrões sintáticos e semânticos, meio de um conjunto de aspectos. Para
guiar todo o desenvolvimento por meio comentários, etc.), de forma que o código as demais práticas, não houve um ques-
de uma história simples e compartilha- seja visto como a própria documentação tionamento sobre os possíveis impactos
da de como funciona o sistema como do produto de software. negativos acarretados pela adoção de
um todo; DSOA. No entanto, a análise realizada
• Design simples (ou projeto mini- Dessa forma, XP busca explicitar prá- não contempla muitas características
malista): busca manter o projeto o mais ticas conhecidas pelos stakeholders do de XP e não se mostra profunda em seu
simples possível, a qualquer momento; desenvolvimento de software através tratamento.
• Teste: alerta para que desenvolvedo- de propriedades emergentes que, uma Por fim, os autores concluem que cer-
res escrevam continuamente testes de vez utilizadas em conjunto, adicionam tas medidas devem ser adotas a fim de
unidade que devem ser executados com valor e produtividade ao processo de facilitar a integração entre DSOA e XP,
a maior precisão possível. Além disso, os desenvolvimento, conforme demons- tais como treinamento e uso intenso
clientes devem realizar o teste de acei- trado em entrevistas realizadas com de Programação Orientada a Aspectos
tação para demonstrar que as funciona- profissionais da área de Engenharia de (POA), além do uso de ferramentas que
lidades requeridas foram contempladas Software (pesquisadores e analistas) auxiliem na identificação dos aspectos
(i.e., “testar, depois codificar”); [Santos, 2008]. utilizados no produto de software.
• Refatoração de código: implica na Porém, nada impede que empresas ado-
reestruturação do sistema sem modificar tem um pequeno conjunto de práticas de Características de XP diante de
o seu comportamento, para remover XP focadas em resolver os problemas de questões críticas de DSOA
duplicações, melhorar a comunicação, maior impacto no desenvolvimento de Nesta seção, serão analisadas algumas
simplificar ou adicionar flexibilidade; software, desde que a equipe assuma a características do processo XP (valores,
• Programação em par: reflete o fato responsabilidade pela flexibilização do princípios e práticas), visando entender
de que todo o código produzido deve ser processo [Paulk, 2001]. Por outro lado, os possíveis impactos de algumas ques-
escrito por duplas de programadores; Beck (2000) afirma que a aplicação das tões críticas de DSOA, com base nos
• Código coletivo (propriedade co- práticas de XP pode gerar lições apren- trabalhos citados nas seções anteriores
letiva): realça que qualquer desenvol- didas que auxiliam os desenvolvedores a bem como a experiência dos autores
vedor pode melhorar qualquer código dominarem as práticas, mas permitindo no tema abordado. A seguir, cada sub-
do sistema, a qualquer momento e em sua modificação caso necessário. seção destaca uma característica que
qualquer lugar; Estudos já realizados pode ser afetada pela adoção de DSOA
• Integração contínua: consiste em in- Procurando abranger mais caracterís- em projetos que aplicam o processo
tegrar e construir o sistema várias vezes ticas de XP e suas relações com questões XP. Para algumas características de
ao dia (i.e., toda vez que uma tarefa é con- de DSOA, Kircher et al. (2002) realizam XP (valores – comunicação, respeito e
cluída). Nesse sentido, testes de regressão um estudo sobre os impactos da adoção feedback; princípios – benefício mútuo,
contínuos previnem a ocorrência de erros de DSOA em XP, concentrando-se apenas economia, diversidade, falha, fluidez,
na implementação das funcionalidades no levantamento de influências positivas humanismo, oportunidades, reflexão e
quando os requisitos mudam; de DSOA que pudessem ser confrontadas responsabilidade aceita; práticas – build

de dez minutos, ciclo semanal, ciclo se- mediante a separação de interesses do Ambiente informativo
mestral, equipe integral, folga, histórias, sistema, e tornar o código tradicional A todo instante, deve ser possível
trabalho energizado, cliente presente, (OO puro) estruturado, minimizando conhecer o estado das atividades em
e programação em par) que não são o espalhamento e o entrelaçamento de andamento. A POA possibilita a inserção
referidas neste artigo, nenhuma relação requisitos, e impactando o valor de me- de comportamentos no sistema, de forma
direta entre DSOA e XP foi identificada lhoria positivamente, ao serem buscadas que possa alterar o funcionamento do
durante a análise realizada. novas oportunidades de melhorar a orga- sistema. Ambientes de desenvolvimento
nização do produto de software. (e.g., Eclipse) têm reduzido o impacto do
Coragem princípio da inconsciência ao utilizarem
Observa-se que, no início do processo Auto-semelhança marcações no código como forma de
de desenvolvimento, equipes que adotam O principio da auto-semelhança sugere alertar ao desenvolvedor que um aspecto
XP podem ter o grau desse valor dimi- que, uma vez encontrada uma solução está sendo inserido no trecho de código
nuído, devido ao desconhecimento das para determinado contexto, esta solução analisado. Pensando na idéia de radiado-
abstrações da OA influenciaria negativa- deve ser adotada em situações semelhan- res de informação (meio), a identificação
mente no valor da simplicidade. Alguns tes. A utilização de aspectos permite que o de aspectos impactaria esta característica
fatores que interferem nessa diminuição código principal possa ser reutilizado em de forma positiva, já que serviria como
consistem na possível inexperiência dos outras situações bem como outros sistemas, base para prover um mapa entre quais
membros da equipe com programação devido ao baixo acoplamento impactando aspectos estão sendo implementados e
orientada a aspectos (POA), nas dificul- esta característica de forma positiva. No por quais desenvolvedores, melhorando
dades de entendimento e depuração do entanto, é necessária uma atenção extra por o ambiente informativo.
código, no princípio da inconsciência e parte dos desenvolvedores com o intuito de
na forma como a combinação (weaving) identificar comportamentos que possam Design incremental
é realizada. Por exemplo, em POA, du- ser tratados de maneira semelhante, visan- Através do design incremental, pode-se
rante o desenvolvimento dos aspectos do evitar a replicação de código no sistema. entregar o produto de software ao cliente
em si, a criação dos pointcuts deve ser Baseado nesta idéia, existem iniciativas de por etapas. Dado o desenvolvimento das
realizada com cautela, a fim de verificar facilitar o princípio de auto-semelhança, funcionalidades de maior interesse, o
que somente as classes desejadas estejam por meio da utilização de frameworks cliente tem a visibilidade de parte de seu
sendo interceptadas pelo aspecto em transversais (frameworks que encapsulam sistema em uso, enquanto as demais fun-
questão. Por outro lado, após o período um único interesse transversal) [Camargo cionalidades estão em construção. No pro-
de adaptação com o DSOA, as equipes & Masiero, 2005] e dos frameworks Spring e cesso de adaptação do produto de software
se sentem mais seguras, pois passam a JBoss AOP. No entanto, a imaturidade de para o atendimento de novos requisitos,
desenvolver trechos de código melhor metodologias e padronizações no levan- trechos de código podem ser alterados
organizados e com menos tendências a tamento dos aspectos a serem utilizados com freqüência (através da refatoração do
erros. Com isso, novas funcionalidades acarretam em um impacto negativo na código). Com isso, as técnicas de refatoração
(ou requisitos não funcionais) podem ser característica de auto-semelhança. devem ser estendidas ou revistas, a fim de
inseridas no produto de software sem verificar se o aspecto continua produzindo
que haja alteração significativa no código Baby steps o comportamento desejado e impedir a
principal, impactando positivamente na O processo XP prega que a codificação manifestação de impactos negativos como
adoção de DSOA em XP. deve ser feita de forma incremental, modificações dos pointcuts que acarretem
através de “passos de bebê”, em que o na modificação destes comportamentos.
Simplicidade e Melhoria desenvolvedor pode ganhar confiança Por outro lado, novas funcionalidades po-
As novas abstrações introduzidas pela ao ver que cada passo produz o resul- dem ser inseridas no produto de software
OA e as dificuldades de se identificar tado esperado. Nesse ponto, a adoção sem que haja alteração significativa no
requisitos que devem ser implementados de DSOA permite que o desenvolvedor código principal, gerando uma influência
com POA levanta a necessidade de uma insira gradualmente novos comporta- positiva de DSOA nesta característica.
etapa mínima de análise, focada na extra- mentos no sistema até atingir o objetivo
ção de aspectos a partir das histórias de desejado gerando um impacto positivo Integração contínua
XP. No entanto, dado que XP foca na etapa na adoção de DSOA em XP. No entanto, A adoção de DSOA requer o aumento
de implementação, em detrimento da a inversão de dependência em aspectos de disciplina com relação à prática de
produção de documentação extensiva de impacta esta característica de XP de integração contínua, dado que os as-
análise e projeto, a adoção da OA influen- forma negativa devido ao fato de que os pectos interferem em diversas partes do
ciaria negativamente no valor da simpli- desenvolvedores de código em OO, por sistema. De certa forma, isso impacta na
cidade. Por outro lado, se bem realizado, exemplo, podem estranhar resultados maneira de se realizar testes de integra-
o processo de identificação de aspectos errados obtidos após a integração entre ção no sistema, sobretudo em qual or-
permite melhorar o desenvolvimento, o código OO e o código OA. dem as entidades (classes OO e aspectos)

devem ser construídas e testadas. Ainda, Desenvolvido dirigido a testes (TDD) pode ser um risco ao desenvolvimento
a partir do momento que o desenvolve- TDD deve ser analisado com cuidado de software; (iv) depuração – mecanis-
dor observe que o aspecto codificado irá pelos desenvolvedores, dado que o aco- mos de depuração devem estar presen-
influenciar em outras partes do sistema plamento entre aspectos pode inserir tes para identificar erros no produto
(além daquelas que ele esteja desenvol- comportamentos indesejados, influen- de software, principalmente quando
vendo), ele deverá integrar os aspectos ciando negativamente esta caracterís- vários aspectos podem atuar em um
ao sistema e avisar aos demais membros tica. Alguns pesquisadores levantam a mesmo trecho de código (join point); (v)
da equipe. Este aumento de disciplina, hipótese de que a inserção de chamada inversão de dependência – permite que
aliado às imaturidades de metodologias a métodos em componentes que foram um mecanismo externo controle o fluxo
e padronizações durante a identificação concebidos sem pensar em tal interação de execução de um sistema; (vi) incons-
dos aspectos a serem utilizados e com- poderia apresentar um novo comporta- ciência – consiste em não transparecer,
binado com as dificuldades da utilização mento [Resende & Silva, 2005]. Por outro para o programador desenvolvedor e
de novas abstrações, acarretam em uma lado, a separação de interesses propor- para o código OO e, existência de com-
influência negativa de DSOA em XP. cionada pela POA permite também um portamentos transversais encapsulados
planejamento diferenciado dos testes em aspectos. A Tabela 1 relaciona cada
Código coletivo para as funcionalidades presentes nos questão às características de XP.
A separação de interesses através de aspectos e no código OO puro, acar- As características de DSOA que influen-
aspectos faz com que um mesmo aspecto retando em um impacto positivo da ciam XP de forma positiva e negativa
possa influenciar diversas partes do utilização de DSOA em XP. impactam o esforço e a qualidade da im-
sistema. XP prega que o código pertence plementação. Pode-se observar que os im-
a toda equipe e, assim, todos possuem Combinando XP e DSOA pactos negativos sobre as características
a liberdade de modificá-lo, quando Buscando explorar e entender os desa- de XP se devem aos problemas do DSOA
necessário. Dessa forma, a separação fios inerentes à união entre XP e DSOA, em relação a: rastreabilidade entre projeto
de interesses deve ser realizada com questões de DSOA relacionadas por San- e codificação de aspectos; surgimento de
cautela, a fim de evitar um impacto nega- tos et. al (2007) foram aplicadas diante das comportamentos indesejados; dificulda-
tivo, pois a alteração da estrutura de um características de XP discutidas na seção des de depuração de código; e visão da
aspecto, visando atender um objetivo de anterior. São consideradas seis questões equipe de desenvolvimento sobre os as-
certa parte do sistema, pode modificar críticas de DSOA: (i) utilização de novas pectos utilizados no produto de software.
o comportamento de outras partes do abstrações – envolve o entendimento das A possibilidade de produzir incrementos
sistema e interferir no funcionamento estruturas de OA na projetação de novas de software sem grandes modificações no
do mesmo. Por outro lado, pode-se soluções para construção de produtos de código orientado a objetos puro, a utiliza-
alcançar uma melhor visualização da software; (ii) identificação de aspectos – ção de aspectos para o desenvolvimento
implementação dos requisitos, gerando visa definir o que deve ser um aspecto de testes, a extração de trechos de código
uma influencia positiva, por permitir em um projeto de software; (iii) imaturi- semelhantes e a separação de interesses
maior modularização do produto de dade de metodologias e padrões – a falta trazem impactos positivos quanto à ado-
software produzido. de metodologias e técnicas consolidadas ção de DSOA junto a XP.
DSOA Identificação de Imaturidade de Depuração em Inversão de

Novas abstrações Inconsciência
XP aspectos metodologias POA dependência
Coragem
VALORES
Simplicidade
Auto-semelhança
PRINCÍPIOS Melhoria
Baby steps
Ambiente informativo
Test-Driven Development
PRÁTICAS
Design incremental
PRIMÁRIAS
Integração contínua
Código coletivo
Legendas: Influência positiva de DSOA em XP Influência positiva e negativa de DSOA em XP Influência negativa de DSOA em XP Indiferente (sem influência percebida)
Tabela 1. Lista dos impactos de DSOA sobre características de XP

É possível perceber, através da análise

da tabela, a existência de um maior nú-
mero de impactos negativos (19) frente a
um número expressivamente menor de
impactos positivos (10). Além disto, algu-
mas características são influenciadas de
maneira negativa e positiva (7), ainda que
grande parte das características de XP não
seja influenciada pelas questões de DSOA
(24). Desta forma, o emprego de DSOA
no contexto de XP deve ser avaliado de
maneira cuidadosa, procurando estimar
quando os aspectos positivos de DSOA
agregam mais valor diante dos riscos
associados aos impactos negativos. Neste
sentido, são identificados, na Figura 1,
alguns desafios que devem ser explorados
no sentido de minimizar os riscos da utili- Figura 1. Principais desafios da adoção de DSOA em XP.
zação de DSOA. Estes desafios têm como
objetivo servir como um primeiro passo
em direção à diminuição dos impactos aplicabilidade em pequenos projetos, de novas abordagens e tecnologias asso-
negativos causados pela adoção de DSOA risco relativamente baixo, envolvendo ciadas devem ser analisadas visando
em projetos baseados no processo XP. pessoal altamente capacitado e requi- verificar sua influência em projetos que
sitos passíveis de mudanças [Boehm, utilizam XP, como DSOA. Por outro
Conclusões 2006]. No entanto, estudos mostram lado, apesar de suas vantagens, DSOA
Apesar das vantagens oferecidas pela que é possível aplicar XP em projetos apresenta algumas questões críticas
adoção de XP em projetos de software, de maior porte através de extensões que [Santos et al., 2007], as quais devem ser
não se pode afirmar que seus valores, enfatizam no constante feedback, projeto analisadas a fim de se pensar em avaliar
princípios e práticas se aplicam em todos de software e criação de novos papéis a aplicabilidade de DSOA em diferentes
os cenários, uma vez que seus melho- no ciclo de desenvolvimento [Lipert et contextos, buscando por possíveis im-
res casos de sucesso se referiam à sua al., 2003][Eckstein, 2006]. Nesse sentido, pactos positivos e/ou negativos.

Referências Dessa forma, realizou uma análise
sobre características de XP, visando
Beck, K. (2000) “Extreme Programming Laddad, R. (2003) “AspectJ in Action”.
confrontá-las com algumas questões
Explained”. Addison-Wesley, 190p. Manning Publication, 512p.
críticas relativas ao DSOA, levantadas
Beck, K. et al. (2001) “Manifesto for Agile Lippert, Martin et al. Developing Complex em [Santos et al., 2007]. Essa análise
Software Development”. Disponível em: Projects Using XP with Extensions. IEEE faz-se necessária para que possíveis
www.agilemanifesto.org. Acessado em: Computer, Nova Iorque, v. 36, n.6, Jun 2003. impactos (positivos e negativos) que uma
11/07/2008. p. 57 66.
abordagem como DSOA provocaria em
Beck, K.; Andres, C. (2004) “Extreme Paulk, M. C. (2001) “Extreme Programming ambientes reais sejam bem delineados e
Programming Explained: Embrace Change, from a CMM Perspective”, In: IEEE Software, v. previamente apontados. Em ambientes
Second Edition”. Addison-Wesley, 2ª ed., 224p. 18, n. 6 (November/December), pp. 19-26. que têm maior probabilidade de sucesso
com XP (empresas de pequeno e médio
Boehm, B. (2002) “Get Ready for Agile Resende, A. M. P.; Silva, C. C. (2005)
porte), isso se torna fundamental, dado
Methods, with Care”, In: IEEE Computer, v. 35, “Programação Orientada a Aspectos em
n. 1 (January), pp. 64-69. Java”. Brasport, 1ªed., 208p. que esse processo se baseia na agilida-
de e não é dirigido por planos [Boehm,
Boehm, B. (2006) “A View of 20th and 21st Santos, R. P. (2008) “Uma Visão Sociotécnica 2002]. Seguindo este raciocínio, este tra-
Century Software Engineering”, In: Proc. of the sobre o Desenvolvimento de Software com balho tem como objetivo servir como um
28th ICSE, Shanghai, China, pp. 12-29. Extreme Programming”, In: IV WOSES, VII
complemento aos estudos já realizados
SBQS, Florianópolis/SC, pp. 25-36.
Elrad, T.; Kiczales, G.; Aksit, M.; Lieberher, [Kircher et al., 2002], procurando levantar
K.; Ossher, H. (2001) “Discussing Aspects of Santos, R. P.; Silva, M. C. O.; Werner, C. desafios que auxiliem na diminuição
AOP”. Communications of the ACM, v. 44, n. 10 M. L.; Murta, L. G. P. (2007) “Questões e dos impactos negativos da adoção de
(October), p. 33-38. Desafios de Orientação a Aspectos no DSOA em XP.
Contexto da Reutilização de Software”, In:
A adoção de DSOA em projetos com
Filman, R. E.; Elrad, T.; Clarke, S.; Aksit, M. Proc. of the I Latin-American Workshop on
(2004) “Aspect-Oriented Software Development”. Aspect-Oriented Software Development (LA- XP produz efeitos positivos devido a
Addison-Wesley Professional, 1ª ed., 800p. WASP’2007), João Pessoa/PB, p. 185-185. modularização do software, melhor
divisão de responsabilidades, possibili-
Hanenberg, S.; Oberschulte, C.; Unland, R. Sato, D. T. (2007) “Uso Eficaz de Métricas em dade de estabelecimento de padrões de
(2003) “Refactoring of Aspect-Oriented Métodos Ágeis de Desenvolvimento de Soft
codificação e realização de testes. No
Software”, In: Net.ObjectDays, Erfurt, ware”. Dissertação (Mestrado). IME/USP, São
Germany. Paulo/SP, 139p. entanto, para que essa adoção obtenha
sucesso, é necessário haver investimento
Jutta Eckstein, Agile Software Development Shore, J.; Warden, S. (2007) “The Art of Agile em treinamento da equipe com o intuito
in the Large - OOPSLA 2006 Development”. USA: O’Reilly, 438p. de permitir a identificação dos possíveis
Disponível em: http://www.oopsla.org/2006/
aspectos a serem utilizados no sistema
submission/tutorials/agile_software_ Teles, V. M. (2005) “Um Estudo de Caso da
development_in_the_large.html). Acessado Adoção das Práticas e Valores do Extreme além de ambiente e ferramentas infor-
em 24/08/2008 . Programming”. Dissertação (Mestrado). IM- mativas sobre a existência de aspectos e
NCE/UFRJ, Rio de Janeiro/RJ, 179p. local de atuação.
Kiczales, G.; Lamping, J.; Mendhekar, Dessa forma, para que DSOA seja
A.; Maeda, C.; Lopes, C. V.; Loingtier, Tichy, W. F. (2004) “Agile Development:
adotad o em cenários ágeis, deve ser
J. M.; Irwin, J. (1997) “Aspect-Oriented Evaluation and Experience”, In: Proc. of the
Programming”. In: 11th European Conference International Conference on Software submetido primeiro a aplicações práticas
On Object-Oriented Programming Engineering (ICSE’2004), p. 692. em cenários tradicionais. Ou seja, devido
(ECOOP’1997), Jyväskylä, Finland. LNCS, v. aos riscos envolvidos em XP, suas bases
1241, 531p., pp. 220-242. Travassos, G. H.; Shull, F.; Carver, J. (2001) metodológicas e tecnológicas devem
“Working with UML: A Software Design
estar bem sedimentadas para que suas
Kircher, M.; Jain, P.; Corsaro, A. (2002) “XP Process Based on Inspections for the Unified
+ AOP = Better Software?”, In Proc. of the Modeling Language”. Advances in Computer, promessas sejam garantidas, dado que
eXtreme Programming and Agile Processes v. 54, pp. 36-99. XP se beneficia de experiências e carên-
in Software Engineering (XP’2002), Alghero, cias das abordagens baseadas em planos
Italy, 2002. [Paulk, 2001].

Profissional de TI
Conheça o IBM Rational Team Concert,
a ferramenta que permite a criação de aplicações de
negócio de forma rápida e eficaz, acelerando o seu
ciclo de desenvolvimento.
Disponível em 3 versões, o IBM Rational Team

Concert é gratuíto para até 3 usuários
(versão Community Edition).
Para mais informações, entre em

contato conosco e solicite um
DVD com conteúdo exclusivo!
_______
Endereço:
R. Marquês de São Vicente, 225
Instituto Gênesis, Sala 27B
PUC-Rio, Gávea
Tel: (21) 2512-6005
atendimento@primeup.com.br
ww
www.primeup.com.br
Especificação de Requisitos com Casos de Uso
Alguns exemplos prontos que você pode tomar como
base ao especificar seus requisitos

Este artigo apresenta alguns exemplos
A
reais de especificação de casos de uso.
Rodrigo Oliveira Spínola atividade de identificação e
rodrigo@sqlmagazine.com.br especificação de requisitos do Para que serve?
Doutorando em Engenharia de Sistemas e Com- software é uma atividade bas- Seu objetivo é explicitar de forma prática
putação (COPPE/UFRJ). Mestre em Engenharia
de Software (COPPE/UFRJ, 2004). Bacharel em Ci-
tante desafiadora. É complexo: como estas descrições podem ser efetua-
ências da Computação (UNIFACS, 2001). Colabo- • Identificar as reais necessidades do das em um nível de detalhe tal que infor-
rador da Kali Software (www.kalisoftware.com), cliente; mações importantes para outras etapas
tendo ministrado cursos na área de Qualidade • Lidar com clientes; do desenvolvimento como planejamento
de Produtos e Processos de Software, Requisitos • Formalizar as necessidades do cliente de testes, projeto e desenvolvimento não
e Desenvolvimento Orientado a Objetos. Consul-
tor para implementação do MPS.BR. Atua como
através da especificação de requisitos sejam omitidas.
Gerente de Projeto e Analista de Requisitos em de forma que esta seja de fácil enten-
projetos de consultoria na COPPE/UFRJ. É Colabo- dimento para o cliente e forneça as Em que situação o tema é útil?
rador Engenharia de Software Magazine. informações requeridas pela equipe de O assunto abordado é útil no dia a dia do
desenvolvimento; analista de requisitos na realização de suas
Eduardo Oliveira Spínola • Lidar com domínios desconhecidos. atividades.
eduspinola@gmail.com Entende-se por domínio o contexto para
É Colaborador das revistas Engenharia de Sof- o qual o software está sendo desenvol-
tware Magazine, Java Magazine e SQL Magazine. vido. Por exemplo: contabilidade, medi- desta atividade. Existem diversas abor-
É bacharel em Ciências da Computação pela Uni-
versidade Salvador (UNIFACS) onde atualmente
cina, controle de estoque. Para ilustrar dagens que podem ser trabalhadas em
cursa o mestrado em Sistemas e Computação na esta dificuldade, imagine-se elaborando conjunto para lidar com estas dificulda-
linha de Engenharia de Software, sendo membro a especificação dos requisitos de um des, por exemplo: análise de domínio,
do GESA (Grupo de Engenharia de Software e módulo estatístico para um sistema do prototipação, casos de uso.
Aplicações). mercado financeiro. O objetivo deste artigo não é apresentar
um referencial teórico sobre como lidar
A lista apresentada não é completa, mas com cada questão envolvida nas ativida-
fornece indícios reais da complexidade des diárias de um analista de requisitos.
14 Engenharia de Software Magazine - Especificação de Requisitos com Casos de Uso

Engenharia de Requisitos
Focaremos em um ponto específico A partir de agora serão apresentados de requisitos funcionais apresentada na
de seu trabalho que é a atividade de quatro exemplos de especificação de Tabela 2. O diagrama de casos de uso cor-
descrição (especificação) dos requisitos. casos de uso. Para cada uma delas fare- respondente pode ser visto na Figura 1.
Faremos isto de forma totalmente prática mos comentários adicionais para que o Consideramos para este artigo a espe-
através da apresentação de um conjunto entendimento do requisito descrito faça cificação dos casos de uso: UC 1 – Admi-
de casos de uso especificados que pode- sentido. Por fim, é importante também nistrar Clientes, UC 2 – Consultar Projeto,
rão servir de inspiração para suas ativi- destacar que os exemplos foram esco- UC 3 – Listar Projetos a Vencer, UC 4 –
dades como analista de requisitos. lhidos de forma a contemplar diferentes Listar Propostas de Projeto Criadas.
situações comumente presentes em espe- No caso de uso UC 1 – Administrar
Contextualização dos Exemplos cificações de requisitos (busca, cadastro, Clientes, apresentamos umas das situa-
As especificações de casos de uso apre- envio de e-mail, extensões). ções mais comuns de encontrarmos em
sentadas neste artigo são fruto da experi- sistemas de informação, que é o cadastro
ência prática dos autores como analistas Exemplos de Casos de Uso de alguma entidade no sistema. Neste
de requisitos. Eles não objetivam servir Para os exemplos de casos de uso exemplo, estamos considerando as inter-
de gabarito para futuras atividades de apresentados iremos considerar a lista faces apresentadas nas Figuras 2 e 3 como
especificação, ao invés disso, podem ser
considerados um bom ponto de partida Objetivo: Contém uma breve descrição do objetivo do caso de uso.
para que possamos ver na prática como
Requisitos: Neste campo indicamos a qual requisito funcional o caso de uso em questão está associado (ler Nota 1).
podemos escrever casos de uso efetivos.
Neste campo definimos a lista de atores associados ao caso de uso. Ator é qualquer entidade externa que
Entende-se por efetivo neste caso o fato Atores:
interage com o sistema (neste caso, com o caso de uso em questão).
do caso de uso conter informações ne-
Informação identificada junto ao usuário que auxilia na definição dos casos de uso que serão
cessárias para que as equipes de projeto Prioridade:
contemplados em cada iteração do desenvolvimento do software.
e desenvolvimento possam desempenhar
Neste campo devemos informar as condições que devem ser atendidas para que o caso de uso possa ser
satisfatoriamente suas atividades a partir Pré-condições:
executado.
da descrição dos casos de uso.
É importante estar atento também ao Freqüência de uso:
fato de que os casos de uso apresentados
neste artigo refletem as características Criticalidade:
de escrita dos autores. Estas caracterís-
Condição de Entrada: Neste campo definimos qual ação do ator dará início à interação com o caso de uso em questão.
ticas que envolvem itens como nível de
Esta é uma das seções principais do caso de uso. É onde descrevemos os passos entre o ator e o sistema. O
detalhamento, informações contidas nos Fluxo Principal:
fluxo principal é o cenário que mais acontece no caso de uso e/ou o mais importante.
casos de uso, dentre outras, costumam
Fluxo alternativo é o caminho alternativo tomado pelo caso de uso a partir do fluxo principal, ou seja,
mudar também de organização para
Fluxo Alternativo: dada uma condição de negócio o caso de uso seguirá por outro cenário que não o principal caso essa
organização. Mesmo assim, os exem-
condição seja verdadeira.
plos são bastante válidos uma vez que
Nesta seção colocamos todos os casos de uso que estendem o caso de uso base e em quais pontos eles são
o núcleo básico envolvido na descrição Extensões:
chamados dentro dos fluxos de eventos.
de casos de uso (fluxos principal e alter-
Neste campo devemos informar o estado em que o sistema (ou entidade manipulada no caso de uso)
nativos) está presente. Pós-condições:
estará depois que o caso de uso for executado.
Consideraremos neste artigo o conjun-
Nesta seção descrevemos todas as regras funcionais que o caso de uso deve cumprir durante sua
to de definições apresentadas na Tabela Regras de negócio:
execução.
1 como sendo importantes na descrição
de um caso de uso. Tabela 1. Conceitos envolvidos na descrição de um caso de uso.
Nota 1. Requisito Funcional
São requisitos diretamente ligados a

funcionalidade do software, descrevem as
funções que o software deve contemplar.
Alguns exemplos são:
• O software deve permitir o cadastro de
clientes.
• O software deve permitir a geração de
relatórios sobre o desempenho de vendas
no semestre.
• O software deve permitir o pagamento
das compras através de cartão de crédito.
Figura 1. Diagrama de Casos de Uso.

RF1 O software deve permitir que funcionários adicionem, consultem, removam ou alterem dados de clientes de projetos. base para especificação do caso de uso. A
RF2 O software deve permitir que funcionários acompanhem o ciclo de vida de seus projetos.
especificação pode ser vista na Tabela 3.
No caso de uso UC 2 – Consultar Pro-
O software deve apresentar ao usuário a lista de projetos cuja data de término esteja dentro de parâmetros informados
RF3 jeto, apresentamos também umas das
no sistema.
situações mais comuns de encontrarmos
RF4 O software deve permitir que funcionários visualizem as propostas de projeto que estejam no estado “Proposta Criada“.
em sistemas de informação: consulta a
O software deve permitir que funcionários definam as parcelas que irão compor o projeto, seus valores e eventos que
RF5 uma dada entidade e disponibilização de
serão associados ao pagamento de cada parcela.
opções de manipulação desta entidade.
O software deve permitir que funcionários registrem o envio de Proposta de Projeto ao cliente do projeto, anexando a
RF6 Neste caso, destacamos o uso de pontos
versão final do documento referente à proposta do projeto no sistema.
de extensão com a opção do autor definir
Tabela 2. Lista dos requisitos funcionais. um cronograma de desembolso (defini-
do em outro caso de uso).
Neste exemplo, estamos considerando
as interfaces apresentadas nas Figuras
4, 5 e 6 como base para especificação do
caso de uso. A especificação pode ser
vista na Tabela 4.
No caso de uso UC 3 – Listar Projetos a
Vencer, apresentamos uma situação em
que o sistema retorna o conjunto de pro-
jetos próximos do vencimento. Destaca-
Figura 2. Tela 1 do caso de uso UC 1 – Administrar Clientes
mos neste exemplo o fato de termos uma
funcionalidade de e-mail contemplada e
a necessidade de definir um modelo para
descrição das informações que estarão
presentes no e-mail.
Neste exemplo, estamos considerando
a interface apresentada na Figura 7 como
base para especificação do caso de uso. A
especificação pode ser vista na Tabela 5
e a definição das informações de e-mail
pode ser vista na Tabela 6.
No caso de uso UC 4 – Listar Propostas
de Projeto Criadas, apresentamos uma
situação em que o sistema retorna o
conjunto de propostas de projeto criadas.
Figura 3. Tela 2 do caso de uso UC 1 – Administrar Clientes. Destacamos neste exemplo mais uma vez
o uso de pontos extensão (a opção de Re-
gistro de Envio de Proposta de Projeto).
Neste exemplo, consideramos a inter-
face apresentada na Figura 8 como base
para especificação do caso de uso. A es-
pecificação pode ser vista na Tabela 7.
Considerações Finais
Este artigo apresentou alguns exem-
plos reais de especificação de casos de
uso. Seu objetivo foi explicitar de forma
prática como estas descrições podem
ser efetuadas em um nível de detalhe
tal que informações importantes para
outras etapas do desenvolvimento como
planejamento de testes, projeto e desen-
volvimento não sejam omitidas.
Figura 4. Tela 1 do caso de uso UC 2 – Consultar Projeto

UC 1 Ð Administrar Clientes
Objetivo: Permitir que funcionários adicionem, consultem, removam ou alterem dados de clientes de projetos.
Requisitos: RF1
Atores: Funcionário
Prioridade: Baixa
Pré-condições:
Freqüência de uso: Eventual
Criticalidade: Baixa
Condição de Entrada: O Funcionário seleciona a opção Administrar Cliente.
1. O sistema apresenta formulário de busca de clientes contendo as informações:
- C.N.P.J (campo editável)
- Razão Social (campo editável)
- Estado (lista dos Estados brasileiros)
- As opções Buscar e Cancelar
- A opção Incluir Novo Cliente
2. O ator escolhe a opção Incluir Novo Cliente [A1][A2]

3. O sistema apresenta formulário de cadastro de Clientes contendo os seguintes campos a serem preenchidos:
(Informações Gerais)
- C.N.P.J (campo editável)
- Razão Social (campo editável)
- Inscrição Estadual (campo editável)
- Inscrição Municipal (campo editável)
(Endereços)
- Tabela com os endereços cadastrados para o cliente que está sendo criado (cada endereço adicionado possui as seguintes informações: Indicador de Endereço
de Cobrança, Logradouro, Bairro, Complemento, CEP, Município, Estado e País) e a opção de Excluir Endereço [A5]
Fluxo Principal: - Campos: Indicador de Endereço de Cobrança (opções Sim ou Não), Logradouro (campo editável), Bairro (campo editável), Complemento (campo editável), CEP
(campo editável), Município (campo editável), Estado (lista de estados brasileiros) e País (campo editável) e a opção de Incluir Endereço [A6][RN2] [RN7]
(Contatos)
- Tabela com os contatos cadastrados para o cliente que está sendo criado (cada contato adicionado possui as seguintes informações: Nome, Cargo, Telefone e
e-mail) e a opção de Excluir Contato [A5]
- Campos: Nome (campo editável), Cargo (campo editável), Telefone (campo editável), e-mail (campo editável) e a opção de Incluir Contato [A6][RN3]
(Complemento)
- Setor em que atua (lista de setores previamente cadastrados no sistema) (campo editável)
- Sub-Setor em que atua (lista de sub-setores previamente cadastrados no sistema) (campo editável)
- Tipo de Atuação (lista de tipos de atuação previamente cadastrados no sistema) (campo editável)
- Opções de Confirmação: Salvar e Cancelar
4. O Ator preenche o formulário apresentado

5. O Ator seleciona a opção Salvar [A7]
6. O sistema valida os dados preenchidos [RN4][RN5][A8]
7. O sistema salva os dados do Cliente
8. O caso de uso é encerrado.
Tabela 3 (parte1). Especificação do caso de uso UC 1 – Administrar Clientes.

[A1] O Ator seleciona a opção Cancelar
1. O sistema retorna à tela principal e o caso de uso é encerrado.
[A2] O Ator informa os dados de busca e seleciona a opção Buscar [RN1]
1. O sistema recupera os Clientes e apresenta para cada um, ordenados de forma ascendente pela Razão Social:
- Razão Social (somente leitura)
- CNPJ (somente leitura)
- Município (somente leitura)
- Estado (somente leitura)
- Opção de Editar
- Opção de Excluir
2. O sistema seleciona um dos clientes e clica na opção Excluir [RN6][A3]
3. O sistema apresenta tela de confirmação de Exclusão contendo as opções: Confirmar e Cancelar
4. O Ator seleciona a opção Confirmar [A4]
5. O Sistema efetua a exclusão do Cliente
Fluxo Alternativo 6. O caso de uso retorna ao passo 2 do fluxo alternativo [A2].
[A3] O Ator seleciona a opção Editar
1. O sistema segue a partir do passo 3 do fluxo principal, porém os campos já vêm preenchidos com os dados do Cliente selecionado.
1. O sistema retorna ao passo 2 do fluxo alternativo [A2].
[A5] O Ator seleciona a opção Excluir
1. Sistema solicita a confirmação da exclusão com as opões confirmar e cancelar
2. O ator confirma a exclusão
3. O item é removido da lista e o sistema retorna ao passo 3 do fluxo principal.
[A6] O Ator seleciona a opção Incluir
1. O sistema armazena os dados do item inserido, atualiza a tabela e retorna ao passo 3 do fluxo principal.
1. Sistema retorna ao passo 1 do fluxo principal.
[A8] O Ator preenche dados inválidos
1. Sistema informa quais os campos foram preenchidos incorretamente e retorna ao passo 3 do fluxo principal.
Extensões: Nenhum
Pós-condições: Os dados de clientes estão armazenados no sistema.
[RN1] Todos os campos de filtro para a consulta de Clientes são opcionais.
[RN2] Apenas um endereço cadastrado pode ser indicado como endereço de cobrança.
[RN3] Ao menos um contato deve ser cadastrado para o cliente. Ao inserir um contato, todos os dados são obrigatórios.
Regras de negócio: [RN4] Todos os campos do formulário são obrigatórios.
[RN5] Não podem ser adicionados dois clientes com o mesmo número de CNPJ.
[RN6] Um cliente só pode ser excluído caso ele não esteja associado a nenhum projeto e contrato/convênio.
[RN7] Pelo menos um endereço deve ser inserido. Ao inserir um endereço, todos os dados são obrigatórios, com exceção do campo Complemento.
Tabela 3 (parte2). Especificação do caso de uso UC 1 – Administrar Clientes.

Figura 7. Tela 1 do caso de uso UC 3 – Listar Projetos a Vencer
UC 1 Ð Consultar Projeto
Objetivo: Permitir que Funcionários acompanhem o ciclo de vida de seus projetos.
Requisitos: RF2
Atores: Funcionários
Prioridade: Média
Pré-condições:
Freqüência de uso: Eventual
Criticalidade: Média
Condição de Entrada: Funcionário seleciona a opção Consultar Projeto.
1. O Sistema apresenta as seguintes opções para visualização dos projetos [RN1]:

- Grupo (opção Todos + lista de grupos) (campo editável)
- Programa (opção Todos + lista de programas) (campo editável)
- Número do Projeto (campo editável)
- Título do Projeto (campo editável)
- Coordenador de Projeto (campo editável)
- Cliente (campo editável)
- Lista de status: todas (Projeto Ativo + Projeto Encerrado), Projeto Ativo, Projeto Encerrado. (campo editável)
2. O ator preenche os filtros de busca [RN2].
3. O Sistema apresenta uma lista de projetos, de acordo com os filtros fornecidos, ordenada por Código do Projeto [A1]:
Fluxo Principal:
- Grupo (somente leitura)
- Programa (somente leitura)
- Projeto (Número + Título) (somente leitura)
- Coordenador(es) do Projeto (somente leitura)
- Cliente(s) (somente leitura)
- Data de Início (somente leitura)
- Data de Término (somente leitura)
- Tipo do Projeto (somente leitura)
- A opção Detalhar
- A opção Definir Cronograma de Desembolso [E1]
Tabela 4 (parte1). Especificação do caso de uso UC 2 – Consultar Projeto.

4. O Sistema apresenta ao final a opção Voltar
5. Ator seleciona a opção Detalhar. [A2]
6. O Sistema apresenta tela contendo as informações:
Identificação
- Grupo
- Programa
- Projeto (Número + Título)
- Coordenador(es) do Projeto
- Cliente(s)
- Data de Início
- Data de Término
- Valor do Projeto
- Moeda
- Tabela com as parcelas já cadastradas para o projeto selecionado (ordenadas pelo número da parcela), onde cada parcela adicionada possui as seguintes
informações:
* Número (somente leitura)
* Descrição (somente leitura)
* Cliente (somente leitura)
* Plano de conta da união (somente leitura)
Fluxo Principal:
* Data prevista (somente leitura)
* Eventos associados (somente leitura)
* Valor da Parcela (somente leitura)
* Percentual da parcela em relação ao valor total (somente leitura)
* Status da parcela (definida, pendente para cobrança, liberada para cobrança ou cobrada) (somente leitura)
Totalização
- Saldo Atual (somente leitura)
- Valor a Receber (somente leitura)
- Valor a Cobrar (somente leitura)
(Saldo por Rubrica) (apenas se o projeto for Vinculado)
- Tabela de Rubricas contendo Rubrica e Saldo (somente leitura)
Minuta de Projeto
- Data de Envio (somente leitura)
- Data de Aprovação (somente leitura)
7. O Sistema apresenta ao final do formulário a opção voltar

8. O Ator seleciona a opção voltar
9. O Sistema retorna ao passo 3 do fluxo principal.
[A1] Projeto não encontrado
1. O Sistema apresenta uma mensagem informando que não foi encontrado nenhum projeto com os dados fornecidos e, em seguida, apresenta o mesmo
formulário com os dados previamente fornecidos
Fluxo Alternativo
2. O sistema retorna ao passo 2 do fluxo principal.
[A2] Ator selecionou a opção voltar
1. Sistema retorna ao passo 1 do fluxo principal.
Extensões: [E1] Abrir caso de uso “UC 5- Definir Cronograma de Desembolso”.
Pós-condições:
[RN1] Caso seja preenchido o Programa e Código do Projeto, a busca será feita usando estas informações, ignorando as demais opções.
Regras de negócio:
[RN2] Nenhum dos filtros de visualização é obrigatório.
Tabela 4 (parte2). Especificação do caso de uso UC 2 – Consultar Projeto.

UC 1 Ð Listar Projetos a Vencer

Objetivo: Apresentar ao funcionário a lista de projetos cuja data de término esteja dentro de parâmetros informados no sistema.
Requisitos: RF3
Prioridade: Baixa
Pré-condições:
Freqüência de uso: Diária
Condição de Entrada: O ator entra no Sistema
1. O Sistema recupera os projetos (ordenado pela data de término – da mais próxima da data corrente, para a mais distante) cujo vencimento se encontre dentro
do período definido, contendo as informações [RN1]:
- Programa (somente leitura)
- Projeto (Número + Título)
- Coordenador(es) do Projeto (Código + Nome)
Fluxo Principal: - Data de Início (somente leitura)
- Data de Término (somente leitura)
- Quantidade de Parcelas Pendentes (somente leitura)
- Valor Total do Projeto (somente leitura)
- Valor Recebido (somente leitura)
- Valor a Receber (somente leitura)
- Opção Notificar Coordenador de Projeto [A1]
2. Caso de uso é encerrado.
[A1] A opção Notificar Coordenador é selecionada
1. O Sistema apresenta tela de confirmação com a mensagem e as opções:
- Mensagem: “Deseja enviar ao Coordenador de Projeto um e-mail indicando que a data de término do projeto está se aproximando e perguntando se há
necessidade de se elaborar um aditivo do projeto?”
Fluxo Alternativo - Opções Sim e Não
2. O Ator seleciona a opção Sim [A2]
3. O Sistema envia e-mail ao Coordenador do Projeto (ver e-mail na Tabela 6).
[A2] A opção Não é selecionada
1. Caso de uso retorna ao passo 1 do fluxo principal.
Extensões:
Pós-condições:
[RN1] Para identificar se o projeto está dentro do período para emissão de aviso, o sistema deve recuperar o parâmetro quantidade de dias de antecedência
Regras de negócio: para aditivo no sistema e verificar se a data do projeto em questão se encontra no intervalo entre a data atual e a data atual subtraída da quantidade de dias de
antecedência.
Tabela 5. Especificação do caso de uso UC 3 – Listar Projetos a Vencer.
Figura 8. Tela 1 do caso de uso UC 4 – Listar Propostas de Projeto Criadas.

Este e-mail é enviado para o Coordenador de Projeto indicando que a data de término do projeto está se aproximando e perguntando se há necessidade de se
Descrição:
elaborar um aditivo do projeto.
Destinatário: Coordenador do Projeto
Sistema X – Solicitação de Aditivo para o Projeto YYY XXX
Assunto: Onde YYY é o código do programa do projeto
Onde XXX é o código do projeto
Caro Coordenador,
O Projeto XXX, descrito abaixo, encontra-se com o vencimento próximo de ocorrer:
- Grupo (código)
- Programa (código)
- Número do Projeto
- Título do Projeto
- Coordenador(es) do Projeto (Nome)
- Cliente(s) (Razão Social)
- Quantidade de Parcelas
Corpo:
- Valor Total do Projeto
- Valor a Receber
- Número de Parcelas Pendentes de Recebimento
- Data de Início
- Data de Término
Caso haja necessidade de geração de aditivo para o projeto, por favor, realizar tal solicitação através do Sistema ou entrando em contato com o setor responsável
pelo acompanhamento do projeto.
Este e-mail foi gerado automaticamente pelo Sistema. Caso necessário, entrar em contato diretamente com o setor responsável pelo acompanhamento do projeto.
XX de XXXXXXX de XXXX
Tabela 6. Detalhamento das informações de e-mail.
UC 1 Ð Listar Propostas de Projeto Criadas

Objetivo: Permitir que Funcionários visualizem as propostas de projeto que estejam no estado “Proposta Criada“.
Requisitos: RF3
Prioridade: Alta
Pré-condições:
Freqüência de uso: Diária
Condição de Entrada: Ator entra no sistema.
1. O Sistema recupera as propostas de projeto que estejam no estado “Proposta Criada” e apresenta cada uma, ordenada por data de solicitação (da mais antiga
para a mais atual):
- Programa (Código + Nome)
- Proposta de Projeto (Número + Título)
Fluxo Principal: - Data de criação da proposta (somente leitura)
- Coordenador(es) do Projeto (número + nome)
- Opção de Registrar Envio de Proposta de Projeto [E1]
- Opção de Rejeitar Proposta de Projeto [A1]
- Opção de Remover Proposta de Projeto [A3]
[A1] O Ator seleciona a opção Rejeitar Proposta de Projeto
1. O Sistema apresenta tela de confirmação de Rejeição de Proposta contendo as opções: Confirmar e Cancelar
2. O Ator seleciona a opção Confirmar [A2]
3. O Sistema registra a proposta com o estado “Proposta Não-Aprovada”
Fluxo Alternativo 4. Caso de uso retorna ao passo 1 do fluxo principal.
[A2] O ator seleciona a opção Cancelar
1. Nada acontece e o caso de uso retorna ao passo 1 do fluxo principal.
[A3] O Ator seleciona a opção Remover Proposta de Projeto
1. O sistema remove todos os registros associados à proposta de projeto selecionada e em seguida retorna ao passo 3 do fluxo principal.
[E1] Ator seleciona a opção Registrar Envio
Extensões:
Ver caso de uso “UC 6 – Registrar Envio de Proposta de Projeto”.
Pós-condições: A lista de propostas criadas e ainda não enviadas ao cliente é apresentada.
Regras de negócio:
Tabela 7. Especificação do caso de uso UC 4 – Listar Propostas de Projeto Criadas.

Usabilidade de Software
A Importância da Usabilidade no Desenvolvimento de Sistemas Interativos

Usabilidade e Interação Humano-Compu-
U
tador (IHC) nos sistemas de software. Este
m sistema de software, assim artigo discute a importância da IHC e usa-
como qualquer outro produto, bilidade no processo de desenvolvimento
precisa ser simples, fácil de usar de sistemas de software
e deve otimizar o tempo de seu usuá-
rio de modo que ele(a) possa realizar Para que serve?
uma tarefa de maneira eficiente e com Identificar atributos da usabilidade e as-
satisfação. Um sistema de software ou pectos da interação humano-computador
produto com essas características tem que podem influenciar a facilidade de uso e
Antonio Mendes da Silva Filho usabilidade, um atributo de qualidade aprendizagem de uma aplicação, os quais
antoniom.silvafilho@gmail.com perceptível aos usuários e determinante são determinantes para elevar o desem-
Professor e consultor em área de tecnologia da no sucesso de um produto. O desenvol- penho na realização de tarefas e grau de
informação e comunicação com mais de 20 anos
vimento de sistemas de software coloca satisfação de usuários.
de experiência profissional, é autor do livros Ar-
quitetura de Software e Programando com XML, a usabilidade como um dos atributos
ambos pela Editora Campus/Elsevier, tem mais de qualidade que norteia o processo de Em que situação o tema é útil?
de 30 artigos publicados em eventos nacionais construção do sistema, tópico discutido Essencial no processo de desenvolvimento
e internacionais, colunista para Ciência e Tecnolo- neste artigo. de sistemas interativos, onde objetiva-se
gia pela Revista Espaço Acadêmico com mais de
desenvolver software que torne produtiva
60 artigos publicados, tendo feitos palestras em
eventos nacionais e exterior. Foi Professor Visitan- Usabilidade e satisfatória a realização de tarefas pelos
te da University of Texas at Dallas e da University Hoje em dia, interagir com sistemas usuários.
of Ottawa. Formado em Engenharia Elétrica pela de software não é mais privilégio de
Universidade de Pernambuco, com Mestrado em profissionais de computação e tornou-se
Engenharia Elétrica pela Universidade Federal
uma necessidade comum a toda popu- caracterizados pela interação entre o sis-
da Paraíba (Campina Grande), Mestrado em En-
genharia da Computação pela University of Wa- lação. Os projetistas e desenvolvedores tema e o ser humano) têm sido colocados
terloo e Doutor em Ciência da Computação pela de sistemas de software e, notadamente, em posição de destaque, pois eles são
Univesidade Federal de Pernambuco. dos sistemas interativos (i.e. sistemas os responsáveis pelo desenvolvimento
24 Engenharia de Software Magazine - Usabilidade de Software

proje to
desses produtos. Entretanto, é impera- interface com o usuário, o qual compre- Um sistema interativo pode ser de-
tivo que eles (projetistas e desenvolve- ende parte das atividades do processo composto em duas grandes porções
dores) possam desempenhar bem seu de desenvolvimento de um sistema de de software: o software da aplicação e
papel, especificamente, no projeto de software, discutido a seguir. o software da interface com usuário.
sistemas de software interativos, onde A aplicação compreende toda a fun-
há interação entre ser humano e compu- Desenvolvimento de cionalidade do sistema enquanto que
tador e têm como propriedade essencial Sistemas Interativos o software da interface com usuário é
prover suporte à atividade humana. Tal Desenvolver um sistema interativo encarregado de mediar a comunicação
sistema habilita o ser humano a realizar requer uma equipe de projeto atuando entre o usuário e a aplicação do sistema.
suas tarefas mais rapidamente, com numa variedade de tarefas, as quais são Esta divisão de um sistema interativo é
menos erros, com aprendizado menor, estruturadas num processo. Tal processo ilustrada na Figura 1.
com qualidade resultante e satisfação compreende um conjunto de atividades Uma visão genérica de processo de
maiores. Isto, contudo, depende da usa- que transforma entradas em saídas. Em desenvolvimento que contemplam ape-
bilidade do sistema. determinado instante do processo, pode- nas as principais atividades desses dois
Usabilidade é uma palavra que tem se ter o projetista ou engenheiro de sof- componentes é mostrada na Figura 2.
feito cada vez mais parte do vocabulário tware esboçando parte da interface com A parte superior da figura engloba ati-
dos projetistas de sistemas de software. usuário e/ou realizando uma entrevista vidades pertinentes ao desenvolvimento
A usabilidade é um conceito chave no com possíveis usuários a fim de derivar da aplicação, onde se tem atividades
campo da Interação Humano-Com- algum modelo e, posteriormente, tentar de desenvolvimento de software (en-
putador (IHC), sendo um atributo de definir a arquitetura do sistema. Depois, contradas na Engenharia de Software)
qualidade de sistemas que são fáceis de mudanças de requisitos e projeto, natu- resumidas apenas em três atividades
usar e de aprender. Em outras palavras, rais de acontecer no início do desenvol- (análise de sistema, desenvolvimento e
diz quão intuitiva é a interface gráfica vimento, podem ser incorporadas a um testes de software). Perceba que a parte
de usuário ou, simplesmente, interface protótipo o que permite realizar testes inferior da Figura 2 compreende as ati-
de usuário. Trata-se, portanto, de uma pelos usuários. vidades necessárias ao desenvolvimento
característica pela qual o usuário expres-
sa seu interesse ou não em utilizar um
sistema. Na grande maioria dos casos,
os usuários preferem um sistema de Sistema interativo
fácil uso, mesmo com funcionalidades
mais simples, a um sistema recheado de software da software da
funcionalidades, porém de manipulação interface com usuário aplicação
complexa e não intuitiva. Usuário
É importante também observar que a
usabilidade é determinante no sucesso
ou insucesso de qualquer produto. Por- Figura 1. Decomposição de um sistema interativo.
tanto, o usuário sempre tem a última
palavra ao expressar sua satisfação ou
não no uso de um sistema ou produto.
Perceba que produtos com usabilidade,
resultante de interface (de usuário) bem
projetada, permitem:
• Maior grau de eficiência quando os
usuários realizam suas tarefas;
• Custos reduzidos de apoio ao usuário,
tais como treinamento, ou atendimento
ao usuário;
• A inserção de sistemas ou produtos
mais naturalmente no ambiente de
trabalho do usuário, facilitando a utili-
zação do produto na realização de suas
tarefas.
A usabilidade é uma característica Figura 2. Processo de desenvolvimetno de um sistema interativo (esta figura poderia ser um pouco
da qualidade resultante do projeto de mais explicada no texto).

do software da interface de usuário. Há, processadas, funções e desempenho deseja- Dentre as atividades que compõem o
também, três atividades básicas (análise dos, tipo de interface a ser utilizada, tarefas processo de desenvolvimento ilustrado na
de sistema, desenvolvimento e avaliação que o sistema deveria prover suporte, perfil Figura 4, duas delas têm grande importân-
da interface). Todavia, adicionalmente, de usuários do sistema, dentre outras. cia na qualidade obtida no sistema final.
têm-se atividades de prototipação e ava- A fase de desenvolvimento concentra- Estas são: o projeto de IHC (interação hu-
liação inicial da interface do protótipo. se no projeto de estruturas de dados mano-computador) e projeto de software
Vale ressaltar que não houve qualquer e arquitetura de software do sistema, (de interface de usuário). Associado a essas
intenção em ser completo, mas de desta- conversão do projeto para alguma lin- atividades, tem-se a arquitetura de softwa-
car as atividades essenciais. Isso se deve guagem de programação, realização de re que será dependente das características
ao fato de haver propostas distintas de testes e avaliação. do sistema a ser desenvolvido, bem como
processo de desenvolvimento para dife- Finalmente, a manutenção considera dos atributos de qualidade desejados. Note
rentes tipos de sistemas de software. modificações e/ou correções necessárias que as atividades de desenvolvimento do
Neste contexto, o foco principal do no sistema a fim de que este atenda aos software de interface, mostradas na Figura
desenvolvimento de sistemas interativos requisitos do sistema. 4, podem conter restrições ou problemas
recai sobre o software da interface. Vale Perceba que o processo de desenvol- que motivam retornar à atividade anterior
ressaltar que o processo de desenvolvi- vimento de um sistema interativo tem visando modificação e/ou correção.
mento de sistemas interativos, similar- dois grandes aspectos de interesse, que É comum o uso de ícones em interfaces
mente a de outros sistemas, consiste de envolve o desenvolvimento das porções de usuário que servem como dica para
três fases genéricas – definição, desen- de software relativo à interface com lembrar a qual comando está associado.
volvimento e manutenção – conforme usuário e da aplicação. Uma ilustração Entretanto, se é feito uso de um ícone
ilustrado na Figura 3. de processo que considera o desenvol- que não é do conhecimento dos usuários,
A fase de definição compreende a iden- vimento do componente do software de então eles podem ficar perdidos ou até
tificação de informações que deveriam ser interface é mostrada na Figura 4. mesmo frustrados por não entenderem o
significado do comando. Numa situação
dessas, há a necessidade de modificar
ou corrigir a proposta inicial do uso de
ícone a fim de tratar esse problema. Uma
correção recomendada é usar o ícone
Definição Desenvolvimento Manutenção acompanhado da palavra que denota o
comando, como mostrado na Figura 5,
que ilustra botões de Start e Clear.
Cabe ressaltar que a interação humano-
computador (IHC) é determinante para
Figura 3. Fases genéricas no processo de desenvolvimento de software.
o projeto de interface (de usuário) e,
portanto, para a usabilidade do sistema,
como discutido na seção seguinte.
Levantamento
de requisitos
Interação Humano-
R&P descrição inicial Computador (IHC)
do sistema
Interação Humano-Computador (IHC) é
prototipação
Projeto de IHC rápida
uma área multidisciplinar que envolve as
áreas de Ciência da Computação, Psicolo-
R&P especificação do
projeto de IHC gia, Fatores Humanos, Lingüística, dentre
outras. IHC está voltada para a aplicação
Projeto de software
de interface avaliação inicial
especificação do
R&P projeto de software
Implementação de
software
programa
R&P
correções em função
da usabilidade R&P = Restrições e
Avaliação de Problemas
interface
Figura 4. Desenvolvimento de software de interface. Figura 5. Exemplos de ícones com rótulos.

proje to
do conhecimento destas disciplinas para propositadamente, os problemas com in- utilizar manipulação/comunicação
produzir interfaces ditas “amigáveis” terfaces acontecem. Recentemente, com gráfica no projeto de interface, muito da
(ou user-friendly). Em outras palavras, o lançamento da nova versão do Office informação visual ainda é apresentada
prover interfaces que ofereçam suporte da Microsoft, o botão de apresentação de na forma textual. A leitura - o processo
a usabilidade. Isso é o que diz a Norma slides do Power Point, que era há décadas de extrair informação do texto - é a ati-
9241 da ISO quando diz que a usabilidade no canto inferior esquerdo, foi levado ao vidade chave na maioria das interfaces.
é a capacidade que um sistema interativo canto inferior direito. Os seres humanos precisam decodificar
oferece a seu usuário em determinado Quando consideramos um sistema os padrões visuais e recuperar o signifi-
contexto de uso para realizar tarefas com interativo, o termo fator humano assu- cado das palavras e frases. Para tanto, o
eficácia, eficiência e satisfação. Quando a me vários significados. Dentro do nível processo de leitura tem sua velocidade
interface oferece essa três características, fundamental, deveríamos entender a controlada pelo padrão de movimento
ela é comumente dita “amigável” (tradu- percepção visual, a psicologia cognitiva dos olhos, que escaneia o texto em alta
ção do termo user-friendly). da leitura, a memória humana e os ra- velocidade.
IHC não é uma disciplina essencial- ciocínios dedutivo e indutivo. No outro Adicionalmente, o tipo de caractere
mente voltada para o estudo de com- nível, deveríamos entender o usuário e fonte, o comprimento de linha do texto
putação ou do ser humano, mas para a seu comportamento. Por fim, é preciso e cor(es) afetam a facilidade na qual o
comunicação entre estas duas entidades. entender as tarefas que o software exe- processo de leitura ocorre. Por exemplo,
Conhecimento sobre as limitações da cuta para o usuário e as tarefas que são se considerarmos o uso da cor na busca
capacidade humana e restrições da exigidas do usuário quando da interação e identificação de objetos, pode-se dizer
tecnologia existentes devem ser ponde- com o sistema. Note que o interesse que o uso excessivo de cores aumenta o
rados para oferecer ao usuário um meio recai, especificamente, na importância tempo de busca e dificulta a identificação
adequado através do qual eles podem da percepção humana para o desenvol- e memorização de objetos. Entretanto,
interagir com os computadores. vimento de interface de usuário. a cor é útil na identificação de estados
Um dos fatores relevantes para a inter- Os seres humanos percebem as coisas de objetos. Considere, por exemplo, que
face de usuário é a percepção humana. através de seus sentidos, isto é, visual, você esteja usando o ambiente Windows
Todavia, antes de discuti-la, faz-se ne- auditivo e tato. Estes sentidos habilitam e abre uma pasta de documentos com
cessário explicar a diferença entre IHC o usuário de um sistema interativo a vários arquivos. Neste caso, o ambiente
e Interface de Usuário. É comum ambos perceber a informação, armazená-la permite que você selecione o modo de
os termos serem usados indistintamente (em sua memória) e processar a infor- exibição (ícones grandes, ícones médios,
e erroneamente. IHC é tudo que ocorre mação usando o raciocínio dedutivo ou ícones pequenos, detalhes, lista e lado a
entre o ser humano e um computador indutivo. lado). Em tal situação, quando você clica
utilizado para realizar algumas tarefas, Grande parte da IHC ocorre através sobre um arquivo, selecionando-o, a cor
ou seja, é a comunicação entre estas do sentido da visão, como por exemplo: do objeto selecionado é modificada para
duas entidades. Interface de usuário é o relatórios, gráficos, etc. Neste caso, os identificar o estado do objeto (um arqui-
componente (software) responsável por olhos e o cérebro trabalham juntos a vo) selecionado naquela pasta.
mapear ações do usuário em solicitações fim de receber e interpretar a informa- Quando a informação é extraída da
de processamento ao sistema (aplicação), ção visual baseada no tamanho, forma, interface, ela deve ser armazenada para
bem como apresentar os resultados pro- cor(es), orientação e movimento. Muitos ser recuperada (lembrada) e utilizada
duzidos pelo sistema. elementos discretos de informação são posteriormente. Além disso, o usuário
É comum encontrarmos interfaces apresentados simultaneamente para precisa lembrar-se de comandos e seqü-
que são difíceis de usar, confusas, e até as pessoas absorverem. Assim, uma ências operacionais de uso. Tais infor-
mesmo frustrantes em alguns casos. especificação apropriada de comunica- mações são armazenadas na memória
Apesar de os projetistas gastarem tem- ção visual é o elemento chave de uma humana (que é um sistema complexo)
po para desenvolver essas interfaces e interface amigável. composto de duas partes: a memória de
que seja improvável que eles façam isto Embora haja uma tendência para se curta duração que possui capacidade de
Figura 6. Modelo da memória humana.

armazenamento e tempo de recordação interação humano-computador; Nesse sentido, torna-se necessário
limitado, e a memória de longa duração • Necessidade de seqüenciar tarefas secun- buscar uma metodologia de projeto de
que possui capacidade de armazena- dárias - usuários que desejam realizar interface de usuário que possa ser inte-
mento e tempo de recordação maior e uma tarefa, normalmente, têm a neces- grada às práticas atuais da engenharia
onde se tem o conhecimento do ser hu- sidade de saber uma ordem na qual exe- de software. Dentro desse contexto, há
mano, como ilustrado na Figura 6. cutar as tarefas secundárias relevantes um foco em técnicas de baixo custo.
As três formas de armazenamento mesmo que eles possam e, normalmente, Vale ressaltar que opiniões mais ortodo-
mostradas acima têm capacidades de ar- trabalhem em diversas tarefas de modo xas defendem que o projeto de interfaces
mazenamento de informação distintas, concomitante e assíncrono; deva ser executado por especialistas de
como caracterizado abaixo: • Usabilidade - A abordagem baseada outras áreas, como Psicologia e Ergo-
• Armazenamento sensorial (espe- em tarefas permite ao projetista se con- nomia, para se obter sistemas de maior
cífico para cada sentido – décimos de centrar em especificações precisas de usabilidade. Todavia, tal percepção tem
segundos); tarefas realizadas pelos usuários a fim mudado aos poucos, uma vez que ela não
• Armazenamento da memória de curta de assegurar uma comunicação natural é muito realista para a grande maioria das
duração (informação limitada - poucos entre usuário e computador. empresas de desenvolvimento de softwa-
segundos); re. Dentre as razões, pode-se destacar:
• Armazenamento da memória de Necessidades no Desenvolvimento • É oneroso manter múltiplas equipes
longa duração. de Sistemas Interativos com funções bem delimitadas;
O desenvolvimento de um sistema • Apenas empresas com grande base de
Assim, se o projetista especifica uma interativo possui a peculiaridade de ter usuários podem se dar ao luxo de manter
interface que faz solicitações indevidas na interface de usuário um fator deter- equipes especializadas;
dessas duas memórias (isto é, não le- minante da utilidade e aceitabilidade • Sistemas críticos, onde vidas huma-
vando em conta as limitações humanas), do sistema de software ou produto. nas podem estar em risco, consideram
então o desempenho do usuário quando Portanto, inicialmente, é importante tal premissa.
usando o sistema será degradado. Uma observar que as técnicas desenvolvi-
forma de avaliar a usabilidade é através das em Engenharia de Software não Além disso, mesmo em grandes empre-
do uso métricas (de usabilidade) que são sempre aplicáveis diretamente ao sas, é cada vez mais aceito dispor de uma
funcionam como critérios de medição da desenvolvimento desses sistemas. Isto equipe com integrantes de perfil técnico
usabilidade do sistema considerado. Um ocorre porque a interface de usuário mais abrangente e capaz de executar
conjunto desses critérios é apresentado não é um componente de um sistema múltiplas atividades.
na Figura 7. de software como um componente Outra observação é que múltiplas
Outro aspecto a considerar é que o que implementa uma funcionalidade equipes deparam-se com problemas de
projeto de interface de usuário deve ser de busca, ordenação, controle e auten- comunicação entre elas. Nesse sentido,
centrado nas tarefas do usuário de modo ticação de usuário, ou qualquer outro ocorre passagem de informações com
a tornar mais natural sua implementação componente funcional. A interface de ambigüidades e o produto obtido quase
num sistema. Algumas observações são usuário também requer, adicionalmente sempre não corresponde ao concebido.
apresentadas abaixo: às atividades que se tem num projeto de As propostas atuais reconhecem tais di-
• IHC é baseada em tarefas - quando um software qualquer, o projeto de interação ficuldades e têm o processo orientado para
usuário interage com uma máquina, ou no qual se identifica e define objetos de as tarefas do usuário. Dessa forma, ocorre
mais especificamente com um computa- interação (como menus, botões, caixas apenas o envolvimento de uma equipe
dor, ele está interessado em realizar uma de diálogo, etc.) e definição da sintaxe do com membros ou engenheiros de software
ou mais tarefas. Portanto, pode-se consi- diálogo entre usuário e sistema, dentre multifuncionais. Esses profissionais tanto
derar a tarefa como o elemento central da outras coisas. criam o projeto quanto realizam a imple-
mentação. Eles compreendem, geralmente,
1. Tempo para realizar um tarefa. especialistas em Computação com algum
2. Percentual de tarefa concluído. treinamento adicional em técnicas de
3. Percentual de tarefa concluído por unidade de tempo. projeto de interação.
4. Taxa de sucessos/falhas. Este profissional é responsável por pla-
5. Tempo consumido com erros. nejar e realizar a inserção da tecnologia
6. Percentual de erros. num ambiente de trabalho do usuário.
7. Número de comandos utilizados. O objetivo dele é compreender as tarefas
8. Número de comandos disponíveis não utilizados. realizadas no ambiente de trabalho do
9. Freqüência de uso de ajuda (help) ou documentação.
usuário a fim de levar essa informação
10. Número de vezes que o usuário expressa satisfação ou frustação.
para o sistema a ser desenvolvido. Adi-
Figura 7. Critérios de medição de usabilidade. cionalmente, observa-se que:

proje to
• A usabilidade deve permear todo o O processo de desenvolvimento de in- vários fatores como a facilidade de uso e
processo; terface de usuário, envolvendo projeto de aprendizagem por parte do usuário, bem
• Não existe um método seguro e direto interação e projeto de software de interface como maior desempenho e satisfação do
que garanta uma boa usabilidade já que de usuário, constitui-se num desafio. As usuário na realização de suas tarefas. Es-
muitas variáveis estão envolvidas; razões pelas quais a interface é vista como ses fatores podem ser mensurados através
• O processo é altamente iterativo, sendo a parte mais difícil e desafiadora do de critérios de usabilidade como discutido
onde testes e avaliações representam desenvolvimento de um sistema interativo no artigo. Todavia, enquanto a diversidade
atividades centrais. é, em parte, porque ela requer uma combi- humana é um aspecto positivo no que
nação de diversas áreas de conhecimento tange ao enriquecimento sócio-cultural
Os modelos de desenvolvimento de com respectivos especialistas para desen- e troca de experiências entre os seres hu-
sistemas interativos, via de regra, são volver uma interface de qualidade. manos, ela constitui-se num desafio aos
norteados pela necessidade de ter o É importante observar que desenvolver projetistas de interface. Nesse sentido, um
usuário como participante do processo interface de usuário não é simplesmente conjunto de características que o projetista
de desenvolvimento, além de considerar desenvolver uma fatia do software do deve considerar compreende:
a necessidade de oferecer suporte à usa- sistema. Ela requer, além disso, outras • habilidades de percepção e cognição:
bilidade. Nesse sentido, o processo de atividades, tais como: capacidade de memorização, atenção e
desenvolvimento de sistemas interativos • Projeto da comunicação entre usuá- solução de problemas;
compreende várias atividades de proje- rios e computador; • fatores que afetam o desempenho
to. Dentre elas, as duas mais importantes • Identificação e representação de motor e perceptivo: fadiga, ansiedade,
na qualidade obtida do produto final são tarefas dos usuários e informações medo, envelhecimento;
o projeto IHC e o projeto de software de pertinentes; • diferenças culturais: descrição de
interface de usuário. • Projeto gráfico e textual da interface; datas, horário, unidades de peso (e
Juntamente com estas fases, tem-se a ne- • Projeto de software de interface atra- outras medidas), formas de descrever
cessidade de uso de técnicas de especifi- vés do qual outras decisões de projeto endereços, bem como significado de
cação do projeto. Perceba que o meio pelo serão implementadas; cores e ícones;
qual o projetista de interação comunica o • Avaliação da interface. • deficiências auditiva, motora, cognitiva
projeto IHC ao projetista de software (ou e de fala, nos usuários de equipamentos.
engenheiro de software) é comumente Observe que o desenvolvimento de uma
realizada através de especificações, i.e., interface de usuário é a parte do sistema Considerar os aspectos acima mencio-
um conjunto formal de instruções sobre que mais requer do projeto tanto em termos nados significa orientar o processo de de-
o projeto a partir do qual o código será de tempo de desenvolvimento quanto da senvolvimento para o usuário, buscando
desenvolvido. Objetivando auxiliar o proporção de software dedicada a esta fatia atender as necessidades de trabalho dos
processo do projeto de interação, os se- do sistema. Além disso, tal desenvolvimen- mesmos, o que implica em aumentar as
guintes princípios são considerados: to tem uma atividade essencial que é, geral- chances da aceitabilidade do sistema de
• O desenvolvimento de um sistema de mente, integrada ao processo de desenvol- software ou produto pelo usuário, já que
software deveria incluir teste empírico vimento do sistema de software. Trata-se a usabilidade está sendo considerada no
inicial e contínuo centrado em usuários da avaliação da usabilidade, atributo da processo de desenvolvimento.
apropriados que realizem tarefas repre- qualidade do sistema de software. Três
sentativas de modo a avaliar se os critérios categorias de métodos existem: inspeção, Links
de usabilidade estão sendo atendidos; investigação e teste. Para cada uma dessas
• À medida que o desenvolvimento pro- categorias, há técnicas que são empregadas Human-Computer Interaction (HCI)
Bibliography
cede, deveria incorporar procedimentos para avaliar a usabilidade de um sistema http://hcibib.org/
subseqüentes através de refinamento de software, tema que será abordado num
Bad Human Factors Design
interativo e análise custo/benefício para artigo futuro. Os leitores interessados no
http://www.baddesigns.com/
determinar as modificações mais efetivas tema podem encontrar informações em
sob o ponto de vista do custo a serem http://www.usabilityhome.com/ User Interface Engineering
http://www.uie.com/
realizadas no projeto de interação.
Conclusão Heuristics for User Interface Design
http://www.useit.com/papers/heuristic/
Por outro lado, o projeto de software Para finalizar, deve-se observar que
heuristic_list.html
de interface de usuário visa transformar nesse universo de dispositivos, dos mais
o projeto do domínio do problema em variados tipos e objetivos, um aspecto The History of the Graphical User Interface
http://www.mackido.com/Interface/ui_
um programa de computador. Nesta determinante na aceitabilidade (leia-se history.html
etapa do desenvolvimento é feito, por também adoção) e uso deles é o design de
Usability Evaluation Methods
exemplo, o projeto das estruturas de suas interfaces. Dentro deste contexto,
http://www.usabilityhome.com/
dados e de algoritmos. a usabilidade de uma interface envolve

Avaliação de Usabilidade
Foco no Desempenho de Usuários

Avaliação de Usabilidade e Interação
U
Humano-Computador (IHC) nos sistemas
m produto, seja um sistema de de software.
software ou outro qualquer,
possui usabilidade que é um dos Para que serve?
atributos da qualidade perceptível aos A usabilidade pode ser considerada um
usuários. A usabilidade é uma caracte- elemento norteador do processo de
rística de um produto que informa quão desenvolvimento, isto é, o desenvolvi-
fácil de usar e aprender esse produto é. Em mento acontece sob a óptica do usuário,
outras palavras, serve como um indicador buscando apoiar de maneira natural a
Antonio Mendes da Silva Filho de quão intuitivo é utilizar aquele produ- realização de suas atividades. Neste con-
antoniom.silvafilho@gmail.com to. Essa característica é determinante no texto, percebe-se a importância do uso
Professor e consultor em área de tecnologia da sucesso desse produto, pois ela influencia de técnicas para apoiar a avaliação de
informação e comunicação com mais de 20 anos
de experiência profissional, é autor do livros Ar-
diretamente o interesse do usuário em usabilidade do software.
quitetura de Software e Programando com XML, utilizar ou não esse produto ou sistema
ambos pela Editora Campus/Elsevier, tem mais (de software). Para tanto, em sistemas de Em que situação o tema é útil?
de 30 artigos publicados em eventos nacionais software, assim com em outros produtos, a Essencial no processo de desenvolvimento
e internacionais, colunista para Ciência e Tecnolo- usabilidade é avaliada durante o processo de software onde podemos ter atividades
gia pela Revista Espaço Acadêmico com mais de
60 artigos publicados, tendo feitos palestras em
de desenvolvimento visando assegurar o específicas para apoiar a avaliação da usa-
eventos nacionais e exterior. Foi Professor Visitan- nível desejado de usabilidade. Este artigo bilidade da interface com o usuário.
te da University of Texas at Dallas e da University discute um conjunto de mecanismos de
of Ottawa. Formado em Engenharia Elétrica pela avaliação da usabilidade.
Universidade de Pernambuco, com Mestrado em (consumidores). Este artigo trata da
Engenharia Elétrica pela Universidade Federal
da Paraíba (Campina Grande), Mestrado em En-
Usabilidade usabilidade de produtos e, mais espe-
genharia da Computação pela University of Wa- Usabilidade tem sido um dos fato- cificamente, da usabilidade de sistemas
terloo e Doutor em Ciência da Computação pela res utilizados por diversas empre- de software. Assim, os dois termos serão
Univesidade Federal de Pernambuco. sas para conquistar novos usuários utilizados indistintamente neste texto.
30 Engenharia de Software Magazine - Avaliação de Usabilidade

proje to
A usabilidade é uma característica

através da qual o usuário expressa sua
vontade e satisfação em utilizar um
produto ou serviço como, por exemplo,
a compra de um livro ou DVD numa
loja virtual devido à simplicidade e agi-
lidade. Dentre esses dois motivadores,
a simplicidade predomina e impacta
diretamente na agilidade.
Na maioria das situações, os usuários
preferem um sistema (ou produto) de
fácil uso, mesmo com funcionalidades Figura 1. Atividades do desenvolvimento de interfaces de usuário.
mais simples, a um sistema com mais
funcionalidades, porém de manipulação
1. Tempo para realizar um tarefa.
complexa e não intuitiva. Dessa forma,
2. Percentual de tarefa concluído.
a usabilidade é considerada no processo
3. Percentual de tarefa concluído por unidade de tempo.
de desenvolvimento de software. 4. Taxa de sucessos/falhas.
Embora a usabilidade seja um atri- 5. Tempo consumido com erros.
buto da qualidade perceptível aos 6. Percentual de erros.
usuários quando o sistema está em 7. Número de comandos utilizados.
uso, é trabalhada ao longo do desen- 8. Número de comandos disponíveis não utilizados.
volvimento do software para que este 9. Freqüência de uso de ajuda (help) ou documentação.
suporte as características desejadas. 10. Número de vezes que o usuário expressa satisfação ou frustação.
O conjunto de atividades, geralmente,
Figura 2. Critérios de medição de usabilidade.
encontradas num processo de desen-
volvimento de interface de usuário (IU)
é ilustrado na Figura 1. • Projeto de apresentação: etapa onde se Essas 10 heurísticas servem como re-
Essas atividades podem ser encontradas define o layout da interface e objetos de comendações que um projetista deveria
em alguns processos com outras deno- interação utilizados para apoiar a intera- seguir, as quais compreendem:
minações. A coleta de requisitos tem por ção do usuário com a interface. • exibir o estado do sistema, oferecendo
objetivo identificar o conjunto de funcio- visibilidade do status;
nalidades e perfil de usuários que estarão Ainda considerando a Figura 1, perce- • fazer o mapeamento natural entre o
fazendo uso delas. Trata-se de identificar ba que o projeto de interação é transfor- sistema e o mundo real;
as necessidades dos usuários e como elas mado no projeto de software da interface e, • prover suporte de controle e liberdade
podem ser apoiadas através da interface. posteriormente, implementado. Nesse de escolha para usuários;
O projeto de IHC (interação humano- ínterim, é comum desenvolver o pro- • prover consistência e seguir recomen-
computador) ou simplesmente projeto tótipo da interface, bem como fazer a dações de padrões;
de interação é uma atividade de suma avaliação preliminar da usabilidade da • priorizar a prevenção de erros de
importância no desenvolvimento de interface. Além disso, quando o sistema usuários;
uma interface de usuário. O projeto de de software é finalizado, uma nova ava- • minimizar a necessidade de memo-
interação se apóia na modelagem (ou liação é conduzida a fim de checar se os rização dos usuários, priorizando o
projeto) conceitual, onde um conjunto critérios (ou métricas) de usabilidade ini- reconhecimento à recordação;
de tarefas dos usuários e de mecanismos cialmente definidos foram atendidos. • oferecer recursos de uso eficiente e
de acesso a elas são identificados. No Note que a usabilidade será um ele- rápido da interface, tornando-a flexível
projeto de interação, o projetista faz o mento norteador do processo de desen- e customizada às necessidades dos
mapeamento de tarefas de usuários em volvimento, isto é, o desenvolvimento usuários;
formas específicas de diálogo entre usu- acontece sob a óptica do usuário, bus- • eliminar informações irrelevantes,
ário e a interface do sistema. O projeto cando apoiar de maneira natural a re- visando prover suporte ao projeto mi-
de interação consiste de: alização de suas atividades. Para tanto, nimalista e à estética;
• Modelagem conceitual: onde é feita aná- os projetistas consideram heurísticas de • oferecer aos usuários mecanismos
lise de elementos da aplicação e tarefas projeto de interface. Há um conjunto de de ajuda que lhe permitam reconhecer,
dos usuários. 10 (dez) heurísticas propostas por Jakob diagnosticar e tratar erros;
• Projeto de diálogo: no qual se define Nielsen que estão disponíveis em http:// • prover os usuários de documentação
o conjunto de ações na interface para a www.useit.com/papers/heuristic/heu- e recursos de ajuda baseadas em tarefas
realização de tarefas do usuário. ristic_list.html. dos usuários.

Conforme ilustrado na Figura 1, o pro- Considere a Figura 3 que capturou ape- Há quatro tipos que compreende:
jetista realiza avaliações durante o de- nas parte de um site de uma imobiliária. • teste exploratório realizado no início
senvolvimento da interface para verificar Agora, suponha que temos um grupo de do desenvolvimento de um produto para
se ele tem tido sucesso em atender, por usuários participando de um teste de uma avaliação preliminar da interface;
exemplo, às heurísticas citadas. Para tan- usabilidade, onde eles estão interessados • teste de acompanhamento que ocorre,
to, ele considera o uso de métricas que em alugar um apartamento. Para realizar praticamente, no meio do projeto para
compreendem critérios através dos quais esta tarefa, qual dos botões, dentre os avaliar a interface (novamente antes de
se podem avaliar a interface de usuário. exibidos na Figura 3, eles deveriam clicar finalizar o projeto);
A Figura 2 apresenta um conjunto de para realizar essa tarefa? • teste de comparação que visa compa-
critérios que podem ser utilizados para Num teste feito com poucas pesso- rar dois ou mais projetos;
avaliar a usabilidade. as, familiarizadas com consultas na • teste de validação que tem por obje-
Objetivando avaliar a usabilidade Internet, cerca de 50% sugeriu clicar tivo verificar a usabilidade do produto
da interface de usuário de sistemas de na opção “Como Alugar”, quase 40% (acontecendo no final do projeto).
software ou outros produtos, há um sugeriu clicar em “Localize seu Imó-
conjunto de métodos de avaliação de vel” e os demais optaram por “Busca De um modo geral, os testes de usabi-
usabilidade, classificados como testes, rápida”. Embora esse teste não tenha lidade têm por objetivo interpretar os
pesquisa e inspeção, os quais são apre- sido realizado num ambiente controlado dados que são observados e coletados
sentados nas seções seguintes. (por exemplo, um laboratório), ele serve durante o teste, quando então se procede
para mostrar como testes com usuários a análise desses dados checando:
Testes de Usabilidade podem fornecer dados de quão intuitiva • o desempenho dos usuários (i.e. a
Teste de usabilidade é uma ferramenta (isto é, qual fácil usar e aprender) uma velocidade na qual eles conseguem rea-
de avaliação da usabilidade que visa interface é. Interessante observar que lizar as tarefas);
medir a taxa de sucesso que usuários quase metade dos usuários tenha esco- • a taxa de erros cometidos quando
conseguem utilizar e/ou aprender a lhido a opção correta que era “Localize executando tarefas;
usar um produto, como um sistema de seu Imóvel”. Outra alternativa para esta • o tempo de aprendizagem para uso do
software, para realizar tarefas. Em ou- tarefa é “Busca rápida” que oferece um produto ou software, no qual o usuário
tras palavras, um teste de usabilidade quantidade menor de recursos na busca, começa como iniciante até atingir domí-
objetiva avaliar se o projeto da interface comparativamente com “Localize seu nio no uso do produto ou software;
atende às necessidades dos usuários. Imóvel”, pois essa última oferece recur- • o grau de retenção das informações
Para que um teste de usabilidade seja sos de consulta detalhada. exibidas pela interface ao longo do
realizado, faz-se necessário planejar Note que os dados obtidos com a re- tempo e nível de satisfação subjetiva
as atividades a serem desenvolvidas e, alização de um teste são usados para (quando os usuários testados expressam
para cada atividade de teste, devem-se melhorar o desempenho dos usuários sua satisfação em utilizar o produto ou
elaborar os procedimentos de teste, além por intermédio de um re-projeto, isto é, software).
de preparar o ambiente no qual o teste através da revisão do projeto de modo
será realizado. Outra questão essencial a tratar os critérios de usabilidade cujo Embora o teste de usabilidade ajude
é a seleção dos usuários participantes do resultado não tenha sido satisfatório. o projetista a saber se a interface de
teste. Por fim, os testes são realizados no Dentro desse contexto, as heurísticas usuário atende aos critérios, o grau de
ambiente (controlado) de teste e os resul- de usabilidade, propostas por Nielsen, confiabilidade não é total pois você pode
tados são coletados e analisados. para o projeto de interface servem estar testando usuários atípicos e os
Por exemplo, um teste de usabilidade como parâmetros para guiar tanto o resultados obtidos não podem ser gene-
pode verificar se as cores e layout usado processo de desenvolvimento quanto o ralizados a toda população de usuários.
numa interface são apropriados, se existe de avaliação. Além disso, o teste sempre ocorre num
dificuldade no uso de um site de uma Os testes de usabilidade podem ser ambiente (i.e. numa condição) artificial.
livraria ou imobiliária, por exemplo. classificados ainda quanto ao propósito.
Investigação da Usabilidade
Investigação da usabilidade (ou usa-
bility inquiry) é outro método de avaliar
interfaces de usuários. Trata-se de um
método interpretativo uma vez que o
avaliador faz a avaliação em campo, isto
é, no ambiente do usuário. Diferente-
mente da abordagem anterior (teste de
usabilidade) que privilegia a avaliação
Figura 3. Fragmento de interface de usuário de um site. em ambiente controlado (i.e. laboratório),

proje to
o método investigativo considera:

• observar (geralmente sem qualquer
intervenção) os usuários em seu am-
biente de trabalho quando eles estão
utilizando o produto ou software;
• o avaliador procura observar e incen-
tivar o usuário quando ele está realizan-
do tarefas a expressarem verbalmente
como e porque eles realizam a tarefa
daquela maneira;
• O avaliador também verifica e com- Figura 4. Fragmento de interface de usuário de um site.
para o que o usuário diz com o que ele,
de fato, executar;
situações de erro dos usuários nos ce- como também após o sistema já estar em
Perceba que esta técnica é não intru- nários trabalhados. uso. Em ambas as situações, o objetivo
siva no sentido que o avaliador tem Vale ressaltar que na investigação da é investigar se o produto ou software
papel passivo e cabe a ele apenas ob- usabilidade, o avaliador busca identi- oferece suporte à usabilidade.
servar atentamente as ações do usuário ficar os principais artefatos (como, por
enquanto este faz uso do sistema ou exemplo, objetos de interação e objetos
produto. Adicionalmente, o avaliador físicos) usados pelos usuários quando Inspeção de Usabilidade
estimula o usuário para que ele realize executando tarefas. A intenção é iden- A inspeção de usabilidade compreende
suas tarefas: tificar os objetos usados pelos usuários técnicas como percurso cognitivo (cogni-
• falando, explicando seus passos quando este está trabalhando. Além tive walkthrough) e avaliação heurística,
(quando executando uma tarefa); disso, observação remota pode ocorrer as quais são apresentadas a seguir.
• expressando sua satisfação ou não em se houverem câmeras instaladas no Tratam-se de técnicas onde se confia na
usar o sistema ou produto; ambiente do usuário. Em tal situação, a perícia do avaliador. Neste caso, o ava-
• emitindo sua opinião sobre o produto comunicação entre o avaliador e o usu- liador é um especialista em usabilidade,
ou sistema enquanto interage com ele. ário pode ser feita por telefone. geralmente, chamado de engenheiro de
Outra atividade da investigação de usabilidade.
Uma das formas de realizar a inves- usabilidade é a observação do padrão
tigação da usabilidade é fazendo uma de interação entre usuário e produto ou Avaliação heurística
investigação contextual. Para tanto, o sistema de software, procurando identi- A avaliação heurística é uma técnica que
avaliador deve: ficar as tarefas mais freqüentes, as quais permite o avaliador identificar problemas
• selecionar um conjunto de usuários são candidatas para ficarem em posição de usabilidade no projeto de interface
típicos; mais proeminente da interface ou serem de um produto ou sistema de software.
• visitar e conhecer o ambiente no acessadas por ícones ou teclas de atalho. Baseia-se em heurísticas que compreen-
qual os usuários utilizam o produto ou Essa decisão visa facilitar o uso da inter- dem princípios aceitos em projetos de
sistema de software; face. Considere, por exemplo, a Figura 4 interface. A técnica é considerada econô-
• solicitar aos usuários para eles mos- que ilustra parte de uma interface Web mica, comparativamente com testes de
trarem ao avaliador como eles executam da biblioteca de uma universidade. usabilidade, pois não requer laboratório
suas tarefas (quando estão usando o Durante a observação de um usuário, ou qualquer outro ambiente controlado.
produto ou sistema); foi possível constatar que o usuário não Além disso, é fácil de ser empregada.
• documentar e analisar os resultados conseguia localizar um botão que lhe Essa técnica considera a participação
obtidos. permitisse sair do sistema, já que ele de vários avaliadores. Recomenda-se
teve digitar sua matrícula e senha para que haja de 3 a 5 avaliadores. Inicialmen-
Note que o avaliador necessita entender ter acesso às funcionalidades mostradas te, cada avaliador realiza sua avaliação
e analisar as tarefas dos usuários e, para na Figura 4. A opção encontrada foi um individual e apenas após terminada a
isso, trabalha com cenários de uso dos botão que contém um X (indicado com avaliação é que permite-se a comuni-
usuários e os decompõem inicialmente uma seta vermelha na Figura 4). Entre- cação entre eles. Esse procedimento é
em tarefas discretas e, num segundo tanto, essa opção não é a de sair ou fazer adotado para se obter avaliações inde-
momento, em passos menores, pois um logout, mas sim de fechar o browser pendentes e evitar que sejam viciadas.
esta atitude permite-lhe compreender (ou uma das guias do browser). O procedimento da avaliação heurís-
as necessidades de interação e interface Note que esse tipo de observação pode tica compreende:
dos usuários. Além disso, ao proceder ser feita tanto durante o desenvolvimen- • cada avaliador deve realizar sua ava-
dessa forma, ele busca verificar se há to, quando ainda se tem um protótipo, liação individual;

• a avaliação individual tem duração Percurso Cognitivo • obter um conjunto de cenários de uso
de 60 a 100 minutos; Percurso cognitivo (Cognitive Walkthrou- do produto ou software: um conjunto de
• durante a avaliação individual, o ava- gh) é uma técnica de inspeção da usabili- cenários de uso e respectivas ações para
liador faz uso da interface, navegando dade na qual de 1 a 4 avaliadores percor- executá-los devem estar disponíveis
diversas vezes pela interface com o obje- rem (isto é, interagem com) um conjunto para que eles sejam explorados durante
tivo de entender o escopo do produto ou de tarefas de um sistema de software ou a avaliação. Também, faz-se necessário
software, para perceber o padrão de in- produto avaliando quão compreensível o feedback ou respostas que a interface
teração. Na primeira vez que o avaliador e fácil de aprender essas tarefas são. fornece às ações dos usuários. Isto visa
navega pela interface, sua intenção é de Esta técnica prioriza a avaliação de uma informar aos avaliadores de como as
obter uma percepção global do produto interface de usuário quanto à facilidade funcionalidades podem ser acessadas
ou software. Já num segundo momento de aprendizagem através da exploração. para que eles possam avaliar quão in-
de navegação, o avaliador inspeciona Isto decorre do fato que os usuários, tuitiva é, por exemplo, a seqüência de
os objetos de interação e componentes via de regra, preferem aprender a fun- ações para realizar uma tarefa, tal como
de diálogo, verificando se eles atendem cionalidade de um software através de “Salvar como” quando o usuário inten-
às heurísticas de projeto (como, por tentativas e erros a treinamentos. ciona atribuir um nome a um arquivo
exemplo, as heurísticas de Nielsen apre- A técnica de percurso cognitivo difere que irá salvar;
sentadas no início do artigo). Também, da avaliação heurística porque a primei- • o avaliador percorre a interface do produto
nessa avaliação individual, o especialista ra pode ser feita com um número menor ou software: o avaliador irá percorrer, isto
considera toda sua experiência; de avaliadores podendo, inclusive, ser é, explorar os cenários de uso daquela
• terminada a avaliação individual, os um único avaliador. Naturalmente, interface, verificar a resposta dada à sua
avaliadores se reúnem e discutem suas aplicar o percurso cognitivo com 2 a ação, verificando a existência de proble-
observações. Durante essa reunião, um 4 avaliadores permite que problemas mas de usabilidade;
especialista do domínio da aplicação não percebidos por um avaliador sejam • documentar problemas encontrados e
pode também participar. O objetivo des- identificados por outro. Além disso, o elaborar sugestões: o avaliador irá percor-
sa participação é de esclarecer eventuais percurso cognitivo é considerado uma rer a interface do software, procurando
dúvidas pertinentes ao domínio; técnica exploradora, pois o avaliador identificar problemas de usabilidade
• ao término da reunião dos avaliado- irá ‘percorrer’ a interface do produto ou como, por exemplo, o uso de ícones
res, uma avaliação de consenso consoli- software, explorando as funcionalidades não intuitivos (ou seja, que não trans-
da as observações deles. Essa avaliação oferecidas pela interface quando tenta mitem o significado apropriado da
consolidada relaciona o conjunto de realizar tarefas típicas dos usuários. funcionalidade).
problemas observados e justificativas, Vale ressaltar que esta técnica é mais
isto é, relaciona os problemas aos princí- comumente empregada durante o pro- A identificação de problemas de usa-
pios (ou heurísticas) violados no projeto, jeto de um produto ou software, uma bilidade encontrados em interfaces de
segundo observações dos avaliadores. vez que há o objetivo de verificar se produtos se apóia no conhecimento que
os padrões de interação humano-com- os usuários têm. Este conhecimento vem
Cabe destacar que a motivação para putador atendem ou não aos critérios de estórias ou casos de sucesso e falhas
se ter de 3 a 5 avaliadores é devido ao de usabilidade estabelecidos para o quando usando outras interfaces.
fato que uma pessoa não seria capaz projeto. Todavia, esta técnica pode tam- Considere uma avaliação empregando
de perceber e achar sozinha todos os bém ser aplicada em outras fases como a técnica de percurso cognitivo à inter-
problemas. implementação, testes e durante e após face Web de, por exemplo, uma imobili-
Assim, os avaliadores trabalham implantação do sistema de software no ária, como ilustrada na Figura 5.
com, por exemplo, as heurísticas de ambiente do usuário. Aqui, apenas parte da funcionalidade
usabilidade propostas por Nielsen, com O procedimento do percurso cogniti- é mostrada e verifica-se que a interface
informações do perfil dos usuários e com vo compreende: oferece a funcionalidade de fazer a bus-
cenários de uso dos usuários quando • identificar o perfil dos usuários do ca por um imóvel, que contém layout
estes estão realizando tarefas típicas. produto: isto requer saber o grau de adequado e requer como entrada uma
Adicionalmente, alguns especialistas conhecimento que os usuários têm do pequena quantidade de informações
sugerem que se façam testes usando, produto avaliado e similares, além do do usuário.
por exemplo, a técnica de pensar em voz conhecimento das funcionalidades ofe- Entretanto, observa-se que é feito
alta (Think Aloud) como complemento à recidas pelo produto; uso de dois botões: um com a função
avaliação heurística. Nessa técnica, os • identificar um conjunto de funcionalidade Buscar e outro de Limpar. Enquanto
usuários são requisitados a expressar des representativas: as principais providas no primeiro o projetista usou o termo
verbalmente o que pensam e suas opi- pelo produto ou software devem ser BUSCA (substantivo), no segundo ele
niões à medida que interagem com o conhecidas, dado que elas serão percor- utilizou o termo LIMPAR (verbo).
sistema ou produto. ridas (i.e. exploradas) na avaliação; Embora seja compreensível, não há

proje to
um padrão quanto ao uso de termos (se

verbo indicando ação ou substantivo que
pode representar um objeto ou coisa).
Além disso, ao lado do rótulo BUSCA
o projetista usou a figura de uma lupa,
ícone esse geralmente é usado para este
fim e de conhecimento da maioria dos
usuários. Por outro lado, a figura de um
√, geralmente usado em ações de Con-
firmar e Ok, é utilizada num contexto
não adequado.
Observe que o percurso cognitivo é
uma técnica na qual o avaliador coloca-
se no lugar do usuário e procura ‘ima-
ginar’ a experiência do usuário quando
realizando a tarefa, como discutido
no exemplo acima. No emprego desta
técnica, o avaliador procura identificar
erros ou dificuldades na navegação da Figura 5. Fragmento de interface de usuário de um site.
interface, buscando ter acesso a funcio-
nalidades, bem como detectar uso con-
fuso e inconsistente de ícones, rótulos, da escolha de um produto. Este artigo Links
imagens e opções. discutiu a importância de considerar Usability Net
o emprego de métodos de inspeção da http://www.usabilitynet.org/
Conclusão usabilidade necessários para verificar se Usability Gov
A usabilidade é e continuará sendo o software, assim como qualquer outro, http://www.usability.gov/
um fator determinante na escolha de fornece as funcionalidades demandadas
Bad Human Factors Design
produtos e sistemas de software. Sua pelos usuários de uma maneira fácil de http://www.baddesigns.com/
apreciação não se limita ao apelo visual usar e fácil de aprender, isto é provendo
Heuristics for User Interface Design
e à estética de uma interface de usuário. suporte à usabilidade. Perceba que quão http://www.useit.com/papers/heuristic/
A usabilidade impacta o desempenho e maior for a usabilidade oferecida por um heuristic_list.html
satisfação dos usuários. Estes são aspec- software ou produto, maior a chance de
User Interface Engineering
tos importantes considerados quando sua aceitabilidade. http://www.uie.com/

Cuidados na Aplicação da
Análise de Pontos de Função
Antecipando conflitos e aumentando a consistência
entre contagens de pontos de função

Orientação prática para um uso consisten-
A
te da análise de pontos de função.
técnica de Análise de Pontos de
Função (APF) não é uma novi- Para que serve?
dade nem tão pouco está na sua Para antecipar, senão evitar conflitos, entre
infância, afinal a pesquisa que a originou os diferentes tipos de usuários da técnica
remonta ao ano de 1974 e a publicação e permitir que os benefícios difundidos
do artigo resultante por Allan Albrecht, de sua aplicação possam ser efetivamente
Measuring Application Development alcançados.
Productivity, ao ano de 1979. A novidade
é a velocidade em que essa técnica vem Em que situação o tema é útil?
Carlos Eduardo Vazquez ganhando adeptos para contagem de Em todas as aplicações da análise de pon-
Sócio-fundador da FATTO Consultoria e Sistemas, unidades para fins de remuneração das tos de função, destacando-se para fins de
um dos autores do livro “Análise de Pontos de entregas de fábricas de software, fábricas estimativas e quando os pontos de função
Função: Medição, Estimativas e Gerenciamento
de Projetos de Software”. Possui 20 anos de ex-
de projetos e integradores de sistemas. servem de insumo para monitoramento de
periência em TI, notoriamente na aplicação das No Brasil, originalmente a principal qualidade e produtividade em contratos
disciplinas do desenvolvimento e sustentação aplicação da técnica é a criação de mode desenvolvimento e manutenção de
de sistemas corporativos. Graduado em Processa- delos de estimativa paramétrica e, ainda sistemas.
mento de Dados pela PUC-RJ em 1990, já passou hoje, há quem associe imediatamente a
com sucesso por quatro vezes pelo processo de
certificação de especialista em pontos de função
análise de pontos de função como um
pelo IFPUG – International Function Point Users sinônimo para estimativa. Estimar é parâmetro, em contraste com os mode-
Group, tendo sido um dos primeiros brasileiros a determinar um valor possível para uma los de estimativa direta onde o analista
conquistar essa certificação em 1996.Desde 1993, grandeza de interesse como o esforço estima diretamente o valor da grandeza
vem formando profissionais na aplicação da Aná- para o desenvolvimento ou manutenção de interesse.
lise de Pontos de Função, tendo sido professor da
UFES, atuado como consultor de grandes projetos
de sistemas, por exemplo. Um modelo Um modelo paramétrico típico é aquele
de tecnologia em empresas do setor financeiro, de estimativa paramétrico é aquele em em que a quantidade de pontos de fun-
bancário e de telecomunicações. que esse valor é estimado a partir de um ção estimados é fornecida como entrada,
36 Engenharia de Software Magazine - Cuidados na Aplicação da Análise de Pontos de Função

planejamento
para o modelo fornecer a estimativa do

esforço ou custo a partir dela. O mais
simples desses modelos consiste em
multiplicar essa entrada por uma cons-
tante que representa a produtividade,
expressa normalmente pela taxa de en-
trega (métrica secundária que relaciona
o esforço – quantidade de homens-hora
despendidos na implementação de fun-
ções entregues – e a respectiva quan-
tidade de pontos de função). Sempre
que se trabalha com a taxa de entrega, é
importante qualificar quais atividades
e artefatos referem-se a esse esforço e
observar que, quanto menor a taxa de
entrega, maior a produtividade.
O processo pelo qual se obtém a cons-
Figura 1. Gráfico de dispersão relacionando a quantidade de função entregue e o respectivo
tante de produtividade para um deter-
esforço necessário à sua codificação e teste unitário.
minado contexto é chamado calibração,
existindo diferentes técnicas e critérios
para isso. A Figura 1 ilustra um cenário
onde o resultado da calibração da taxa
de entrega é de 2,82 horas de construção
e teste de unidade por ponto de fun-
ção, utilizando a técnica dos mínimos
quadrados.
Como a necessidade de calibração do
modelo permite depreender, os pontos
de função não representam esforço,
prazo ou custo. Eles representam a
ponderação das funcionalidades de
armazenamento e transação fornecidas
pelo software ou projeto aos seus usuá-
rios. Por esse motivo, a análise de pontos
de função é considerada uma técnica de
Figura 2. Distribuição do esforço total no atendimento de demandas por faixa de produtividade
medição funcional. Além da confusão
sobre o objeto da medição em pontos
de função, os modelos de estimativa individualmente, ou em pequeno nú- de demandas ao longo de um mês, onde
normalmente apresentam uma série de mero, são o objeto da avaliação. Cada há compensação entre as diferentes
vícios na aplicação da técnica. Dentre as função medida nessa última condição produtividades aferidas, é usado para
principais causas para isso está o conhe- provavelmente terá uma produtividade fins de planejamento de prazo e esforço
cimento incompleto da mesma, da falta real específica, senão única, e diferente de cada demanda individual, onde essa
de alguns cuidados em sua aplicação da produtividade geral definida no compensação não acontece. A Figura 2
e a falta de definição de premissas de modelo. Quando há determinada quan- ilustra a distribuição do esforço despen-
contagem. Isto conseqüentemente: tidade de funções em análise, existe uma dido ao longo de um mês em função da
(a) Leva a criação de modelos inade- tendência de haver uma compensação produtividade expressa pela taxa de
quados para os propósitos que deveriam entre aquelas funções com maior pro- entrega. Apesar do indicador de 2,82 h/
endereçar. O uso da APF para fins de dutividade real e aquelas outras onde PF ser adequado para fins de estimar o
estimativa deve cumprir propósitos uma menor produtividade foi aferida. esforço despendido ao longo de um mês
gerenciais e não operacionais. Propó- Essa tendência faz com que, no todo e de trabalho, se esse mesmo indicador
sitos gerenciais referem-se àqueles em se bem calibrada, a produtividade do for usado para estimar os prazos na
que várias funções de um sistema ou modelo aproxime-se da real. implementação daquelas funções que
projeto são avaliadas como um conjun- Por exemplo, um modelo que é adequa- colaboraram com horas à esquerda da
to, enquanto propósitos operacionais do para remunerar um desenvolvedor linha vermelha pontilhada, o resultado
referem-se àqueles onde as funções com base na medição de um conjunto tende a ser subestimado, enquanto os

de conhecer quem são os seus usuários,
definir as fronteiras com base naquilo
que eles entendem e por onde os produ-
tos e solicitações serão tramitados entre
o mundo do usuário e a aplicação objeto
de contagem. Observe que, para fins da
APF, usuário não se restringe ao usuário
final da aplicação, mas também aqueles
que especificam requisitos funcionais e
o que quer que interaja com o sistema –
inclusive outra aplicação.
Além dessas definições intrínsecas à
Figura 3. Processo de Contagem de Pontos de Função própria APF, outras afins à sua aplicação,
à sua institucionalização em uma organi-
zação ou no relacionamento entre orga-
prazos daquelas à direita tentem a ser Alguns Cuidados no Uso da Análise nizações em particular também devem
superestimados. Não basta colocar mais de Pontos de Função ser feitas como: gerência de mudança;
profissionais para compensar essa ten- O processo de análise de pontos de tratamento de requisitos técnicos e de
dência principalmente considerando-se função é apresentado na Figura 3 e qualidade não medidos diretamente pela
projetos ou demandas pequenas como o destaca que existem algumas premissas APF; as fases do ciclo de vida, a relação
caso em análise. A noção de que o prazo que devem ser estabelecidas antes da das atividades e artefatos cujo esforço
é o resultado da simples relação entre o identificação e ponderação das funções para execução ou produção está incluído
esforço e a quantidade de pessoas que em análise (propósito da contagem, tipo no cômputo da produtividade; a definição
despenderão esse esforço é verdadeira de contagem e fronteira da aplicação). dos momentos do ciclo de vida em que
dentro de certos limites. Conforme Contudo, ao aplicar a técnica muitas haverá medição; as particularidades na
diminui a quantidade de funções em vezes, essas premissas não são estabe- aplicação da técnica conforme a seleção
análise, mais estreito é esse limite. Isso lecidas ou então não há a consistência do tipo de contrato-remuneração por esti-
acontece pela dificuldade em subdividir necessária entre diferentes contagens mativa ou por medição; dentre outros.
o trabalho em partes menores e da sobre- no que se refere a elas. Para fins orçamentários, de nada
carga com as atividades de comunicação O estabelecimento dessas premissas mi- adianta saber qual a área de um pro-
necessárias. nimiza a possibilidade de divergências na jeto de construção de uma casa se não
(b) Aumenta a chance de haver um contagem, destacando o posicionamento for conhecido qual o tipo de obra e o
mesmo cenário com diferentes possíveis das fronteiras entre aplicações relaciona- respectivo custo unitário. Principal-
interpretações das regras, procedimen- das, a definição quanto aos seus usuários mente quando se adota um modelo de
tos e práticas de contagem conforme e os propósitos para a contagem. estimativa onde a quantidade de pontos
definidos pelo International Function Um caso típico e que permite o ende função é multiplicada por um indi-
Point Users Group – IFPUG – em seu tendimento da importância disso é a cador de produtividade, é necessário
manual de práticas de contagem (corpo identificação de funções de transação. o planejamento das estratégias para a
de conhecimento da técnica atualmente Por exemplo, imagine uma sala em um estratificação (definição de categorias de
em sua versão 4.2.1 e geralmente cha- prédio e uma pessoa saindo por uma produtividade), calibração e monitora-
mado de CPM – Counting Practices porta dessa sala para atender a uma mento do desempenho dos indicadores
Manual – na comunidade de analistas função do negócio. Se considerarmos a de produtividade.
de métricas). sala como fronteira da aplicação, a saída Por fim, um cuidado para adoção da
Como conseqüência desses dois pontos, dessa pessoa (função “pessoa – sair da APF é a manutenção de cenários com
aqueles que conhecem a técnica apenas sala”) será avaliada em termos de uma contagens exemplo de projetos e siste-
superficialmente julgam-na como muito função e possivelmente considerada mas típicos com a documentação des-
subjetiva ou ineficaz. Esse artigo tem por na ponderação (outros fatores também crevendo os erros mais comuns no uso
objetivo destacar alguns cuidados ao usar devem ser avaliados). Contudo, se a da técnica, acertadas entre todas as or-
pontos de função, principalmente como fronteira da aplicação for o prédio, não ganizações que utilizarão a metrificação.
unidade de medição de contratos e, com haverá função especificamente relacio- Pela própria natureza particular desses
isso, ajudar a evitar que os profissionais nada à pessoa sair da sala. Talvez isso cenários, não é possível tratá-los de
ou organizações habituados a usar a téc- seja parte de alguma outra função que forma geral neste artigo. A idéia de ma-
nica em determinado contexto vejam-se se manifesta para os usuários quando nutenção desses cenários é prover uma
frustrados ao usá-la em outro onde é exi- algum produto ou resposta a uma soli- interpretação local uniforme quanto às
gido um maior rigor em sua aplicação. citação saia do prédio. Daí a importância regras gerais definidas pelo IFPUG.

planejamento
Premissas modificadas conforme a as premissas originais, identificará as funcional, essa parte da técnica é descon-
conveniência de cada contagem funções: siderada. Existem aqueles que defendem
Para que um determinado conjunto de • Faturamento: preparar e enviar que o seu uso aumente a relação entre
atividades possa ser avaliado como uma movimento; tamanho e esforço; outros argumentam
função, esse conjunto deve também inte- • Contábil: processar faturamento; que o fator de ajuste é obsoleto, induz
ragir com usuários da aplicação (lembre- • CRM: processar faturamento; muita subjetividade e que os aspectos não
se que para a APF, outra aplicação pode • Contas a receber: processar faturamento. funcionais devem ser ponderados dire-
também ser considerada usuária desde tamente no esforço pelo uso de modelos
que interaja com aquela em análise). Por Contudo, se quando da contagem dessa como o COCOMO II ou a maior estratifi-
exemplo, surge uma demanda para que demanda todos esses sistemas estiverem cação nos indicadores de produtividade
seja enviado um arquivo com a relação compreendidos numa mesma fronteira utilizados para elaborar estimativas.
dos clientes incluídos, alterados e excluí- da aplicação, provavelmente teríamos Quando de sua adoção, é recomendado
dos de um sistema de vendas para atuali- apenas a função Nota Fiscal – Faturar, que, no guia de contagem, estejam desta-
zação das bases cadastrais de um sistema contada na medida em que será o único cadas as orientações do CPM, preferencial-
de CRM. Na medida em que a informação processo que interage com o usuário. mente com exemplos e casos cotidianos na
está saindo da aplicação Vendas, uma saí- O impacto disso é a invalidação, ou organização e do cenário em que a APF
da ou consulta externa será contabilizada pelo menos grande degradação, de toda a será utilizado. Quando não adotado, isso
e, na medida em que dados estão entrando referência como a produtividade média, também deve estar definido no guia na
na aplicação de CRM, três entradas exter- por exemplo. Afinal, o esforço envolvido medida em que ele é a referência interna
nas serão contabilizadas. Considerar que é o mesmo, independentemente de como a para o uso da APF na organização.
uma aplicação seja usuária de outra em fronteira seja posicionada, porém a quan- Todo processo de desenvolvimento ou
uma determinada contagem e, em outra tidade de pontos de função pode mudar manutenção de sistemas é também um
contagem diferente, considerar que essa drasticamente e isso muda toda relação processo de descoberta. Quando é solici-
mesma aplicação seja parte da outra, é construída anteriormente quando do esta- tada do analista uma estimativa de esforço
um erro. Uma vez estabelecido que CRM belecimento da curva de produtividade. em momentos preliminares do ciclo de
e Vendas são duas aplicações distintas, vida, as funções ainda não descobertas
é um erro ora considerá-las dessa forma Valor do fator de ajuste usado para como requisitos terão um impacto no
e ora considerá-las no conjunto como outros fins que não aqueles para esforço necessário ao empreendimento
uma única aplicação. Por exemplo, surge os quais foi definido em questão. Isso é um risco que deve ser
uma demanda que envolve modificar e O valor do fator de ajuste se propõe a tratado e a esse tratamento é dada a deno-
incluir funções em ambos os sistemas. ponderar os efeitos daqueles requisitos minação de contingência técnica. Os me-
Uma das funções alteradas é o envio do do usuário que não são específicos de canismos para a sua determinação devem
arquivo com as modificações no cadastro uma função, mas gerais à aplicação como também estar definidos, destacando que,
de clientes no sistema de vendas para o um todo (desempenho, processamento pela comparação do tamanho funcional
CRM. Nessa nova contagem essa função distribuído, usabilidade, suporte a vá- em diferentes momentos no ciclo de vida,
não é contabilizada e esse erro em parti- rios protocolos, entre outros). Em termos é possível quantificar quanto foi o cresci-
cular consiste em confundir o conceito de práticos, o fator de ajuste visa ponderar mento em função dessas descobertas em
escopo da contagem com o de fronteira da os requisitos não funcionais, havendo projetos passados. A contingência técnica,
aplicação. Resumindo o problema, frontei- no CPM orientações para a sua determi- referente a esse fenômeno (scope creep),
ras entre as aplicações não são definidas nação. Apesar disso, muitas vezes esse passa a poder ser medida e utilizada no
previamente e usadas consistentemente fator é usado visando à inserção de uma processo de estimativa do tamanho fun-
entre as diferentes contagens. margem de erro na estimativa. Quando cional. Em estimativa, o problema não é
Outro exemplo, fronteiras foram se trabalha com uma estimativa para ela- errar: é desconsiderar que se vai errar!
estabelecidas entre os sistemas de fa- boração de uma cotação de preço global
turamento, contábil, relacionamento fixo isso é necessário, contudo, isso deve Desconsiderar aspectos do
com clientes (CRM) e contas a receber, ser feito em função do conhecimento do software que não são medidos
quando das contagens para calibração do problema, dos riscos de novas descober- pela técnica de Análise de Pontos
modelo de estimativa. Uma demanda do tas implicarem em esforço adicional, e de Função
usuário envolve modificar um programa não a partir de uma margem de teto e Os pontos de função medem os requi-
que prepara e envia dados de fatura- piso fixos de até 35%, arbitrados pelos sitos funcionais e questiona-se a eficácia
mento acrescentando alguns campos criadores da APF para outros fins. do uso do fator de ajuste para fins de
que serão relevantes para os sistemas O próprio uso do valor do fator de ajuste ponderação dos requisitos não funcio-
que processarão esses novos campos: não é um consenso entre a comunidade nais. Existem demandas cujo esforço
Contábil, CRM e Contas a receber. A de analistas de métricas e, quando se necessário ao seu atendimento depen-
contagem dessa demanda, considerando diz que a APF é uma técnica de medição de primordialmente desses últimos.

Existem aquelas que nem podem ser me- não será armazenada, porém o resultado podem ser obtidas pela aplicação da
didas diretamente em pontos de função da avaliação automática armazenada na técnica: novas contagens em momentos
como, por exemplo, uma manutenção ficha do cliente ao final do processo será intermediários entre esse início e o tér-
perfectiva (atividade que não acrescenta multiplicado pelo valor informado nesse mino do projeto, ou mesmo apenas nesse
funcionalidade alguma ao software e novo campo. último momento, não são realizadas.
que visa melhorar aspectos como o seu • Acrescentar uma crítica no campo de Portanto, o modelo não é calibrado con-
desempenho, sua usabilidade, sua facili- limite de crédito, atualmente de preen- siderando a produtividade efetiva obser-
dade de manutenção, entre outros). chimento livre, no cadastro de clientes. A vada naquela organização para aquele
Não se deve deixar de definir como solicitação é que esse campo passe a ser de tipo de projeto, nem tão pouco segrega o
esses aspectos não funcionais devem ser preenchimento obrigatório. O valor infor- que seja risco das descobertas inerentes
ponderados e ter o seu esforço estimado. mado não deve ser superior ao resultado ao processo de desenvolvimento dos
Atualmente tem se tornado quase que um de determinados cálculos. Ao atualizar o riscos que afetam a produtividade;
padrão de fato a utilização de uma tabela cadastro, deve-se comunicar o sistema de • A identificação das funções não é feita
de “itens não mensuráveis”. Por exemplo, gestão de crédito e risco. Apenas deve-se com base na lógica do usuário, mas sim
modificar um layout de uma tela não im- permitir a conclusão da atualização se essa com base nos artefatos tecnológicos uti-
plica em modificar a sua funcionalidade. comunicação for bem sucedida e não deve lizados: por exemplo, duas tabelas que,
Um modelo bastante comum é considerar ser possível enviar uma comunicação em na visão do usuário, de acordo com a sua
que a cada cinco campos cujo layout for separado do próprio cadastramento. lógica, representam um único grupo de
alterado será considerado o equivalente a dados relacionados entre si são contadas
0,20 pontos de função. Contudo, o esforço A segunda tende a demandar mais ho- como duas funções distintas de armazena-
na execução de atividades relacionadas ras de esforço e um maior prazo de entre- mento. Na lógica da modelagem de dados,
aos requisitos não funcionais de um pro- ga que a primeira, independentemente de nada mais natural que segregar os dados
jeto não será medido diretamente e estará ambas pontuarem seis pontos de função. de um pedido em duas tabelas de banco de
incluído no indicador de produtividade Portanto, muita atenção ao aceitar acor- dados, porém na lógica do usuário isso não
aplicado aos requisitos funcionais, se isso dos de níveis de serviço em que o prazo é natural. O usuário não mantém um ar-
não for explícito. seja estabelecido da mesma forma que o quivo apenas com os dados dos cabeçalhos
esforço. Por exemplo, o preço ou meta de dos pedidos e outro arquivo onde mantém
Confundir esforço com prazo produtividade é definida em 2,81 h/PF, os dados dos itens dos pedidos.
A produtividade expressa em pontos mas isso não quer dizer que uma deman- • O uso de um modelo único de estima-
de função reflete uma tendência. A lógica da de 6 PF seja entregue em um prazo de tivas de esforço independentemente do
da utilização de um modelo como esse é cerca de dois dias. Isso é um risco para a tamanho da demanda: o uso da análise de
de que, na média, essa taxa seja represen- administração do contrato por parte do pontos de função para fins de estimativa
tativa da relação entre esforço (custo) e a desenvolvedor e é um fator que incentiva requer uma quantidade de funções tal que
quantidade de pontos de função entregues a coleta de preços mais altos no mercado a produtividade média seja representativa.
numa demanda ou projeto. Mesmo em si- por parte dos clientes. A prática atual Observando pontualmente uma função
tuações em que individualmente não haja é estabelecer limites por patamares ou isolada, a produtividade necessária à sua
a compensação na produtividade, quando então usar o resultado de modelos como entrega pode ser muito diferente da pro-
há muitas pequenas demandas como um o COCOMO II que fornecem um modelo dutividade média. Quando essa mesma
contexto de manutenção intensiva, no con- mais adequado para obtenção do prazo função é analisada conjuntamente com
junto há essa tendência para compensação. como um de seus produtos. outras em um projeto, a partir de certo
Ao longo de um mês, usar um modelo ponto, essas diferenças – a maior ou me-
de estimativas para estimar o esforço é Vícios na Aplicação da APF em nor – tendem a ser compensadas entre si.
válido, contudo isso provavelmente não estimativas Se o escopo daquilo que se deseja estimar
se aplique ao prazo. Duas manutenções, Quando uma organização se propõe a é menor que 50 ou 100 pontos de função,
ambas contando seis pontos de função, trabalhar com pontos de função, alguns dificilmente haverá tal compensação e o
podem individualmente apresentar uma itens também devem ser considerados modelo de estimativas apresentará um
grande variação no esforço e prazo da no que se refere às suas práticas de resultado com maior erro quando compa-
sua entrega. Considere os exemplos de estimativa, afinal o preço do ponto de rado com aqueles obtidos por estimativas
demandas de manutenção: função não deixa de ser baseado numa diretas, que não usam uma unidade de
• Incluir um novo campo na função de estimativa da produtividade média. Este tamanho como parâmetro para estimar
inclusão de cliente. Atualmente, a clas- artigo destaca alguns deles: o esforço. Esses são valores empíricos,
sificação do cliente é feita totalmente de • A contagem dos pontos de função fruto das observações das aplicações da
forma automática pelo sistema. Esse novo habitualmente é feita uma vez e em mo- APF. Para valores menores discrepantes,
campo deve conter uma nota atribuída mentos preliminares do projeto quando ensaios devem ser feitos no contexto em
pelo responsável do cadastramento. Ela apenas estimativas do tamanho final que a técnica será aplicada.

planejamento
Todos esses vícios no contexto de um ela não é completa, ela é parte da exclu- quando esses se deparam com situações
contrato levam a conseqüências para as são de tarifas. O usuário não executa o não usuais, é comum o surgimento de
partes envolvidas. Quando da análise de processo de exclusão de tarifas com o dúvidas. Com a centralização desse co-
sua produtividade, um desenvolvedor propósito de consultar se existe ou não nhecimento, um profissional experiente
incorre nesses erros, corre um risco de algum lançamento para ela. na APF, mas acostumado a medir so-
determinar uma taxa de entrega que não A análise, a aplicação das regras de con- mente sistemas de determinado tipo (por
corresponderá àquela obtida consideran- tagem, nesse caso em particular é bastante exemplo, mainframe-COBOL), será capaz
do a medição da entrega apurada por seu direta e contamos com exemplos e casos de medir mais facilmente sistemas de
cliente. Enquanto para uma demanda o fornecidos pelo IFPUG com orientação natureza distinta (por exemplo, business
desenvolvedor chega a 120 pontos de para isso. Não é o caso de sistemas de con- intelligence).
função, o cliente chega a apenas 80 e trole de tráfego aéreo em que diferentes • Evitar o re-trabalho com a análise de
isso implicará em um impacto na sua camadas de dados são apresentadas ao questões recorrentes: uma vez que deter-
produtividade e, conseqüentemente, em usuário, sistemas com consultas dinami- minada situação tenha gerado dúvida na
seu preço por ponto de função. camente definidas pelo próprio usuário, medição, esta é analisada e decide-se qual
sistemas de workflow, entre outros. a melhor forma de abordá-la. Essa dúvida
Guia de Contagem Também para as situações onde as re- e a abordagem adotada são documenta-
O Guia de Contagem é um documento gras do IFPUG não estão suficientemente das no guia para que todos os envolvidos
particular a uma organização com in- claras ou objetivas (existem pontos da em medições não precisem gastar tempo
terpretações locais das regras, práticas e técnica que ainda são alvo de trabalho analisando situações parecidas e nem
procedimentos de contagem definidos no do comitê de práticas de contagem do correndo o risco de decidirem por uma
CPM e fundamentados na “visão do usu- IFPUG como, por exemplo, a determi- abordagem diferente da adotada previa-
ário”. Isto é, faz com que a técnica possa nação quanto à contagem de diferentes mente. As medições tendem a ocorrer de
ser aplicada em uma ampla variedade de funções quando houver múltiplas mídias forma mais rápida.
situações e independentemente de como envolvidas em seu processamento), o • Criar um modelo de estimativa con-
os seus requisitos funcionais são atendi- guia de contagem irá tratar a situação de sistente com as características da APF,
dos. Por outro lado, dificulta a aplicação forma objetiva. Aproveitando a questão calibrado e definido para os propósitos
destes conceitos em situações em que das múltiplas mídias, um guia local específicos a que ele se destina.
essa visão de negócio do usuário, ou pelo pode definir que diferentes funções de
menos princípios que permitam a sua transação serão contadas quando houver Os cuidados apresentados neste artigo
materialização, não esteja documentada um desenvolvimento específico para cada têm por objetivo servir de base para a
ou definida previamente, principalmente diferente mídia e que apenas uma função definição de uma pauta, de um agenda,
em situações com características distintas será considerada, caso contrário. para o sucesso na adoção da APF na
das fornecidos pelo IFPUG. realidade atual e para os propósitos que
Por exemplo, o IFPUG define que uma Conclusão vêm tão intensamente alavancando a sua
função de transação seja: o menor con- Quando a APF é utilizada para fins utilização.
junto de atividades completo, que deixa de medição da produção na relação
o negócio da aplicação sendo contada entre usuários e desenvolvedores, e não
em um estado consistente; e reconhecido apenas como um instrumento interno à
pelo usuário. Em outras palavras, que organização de planejamento e controle,
Referências
não exista subconjunto desse conjunto de uma série de objetivos devem ser esta-
atividades que também seja completo. A belecidos para: IFPUG – International Function Point Users Group:
manutenção de um cadastro com dados • Aumentar a consistência entre http://www.IFPUG.org
de referência do negócio – tarifas, por contagens feitas por diferentes profis- Vazques, Carlos Eduardo; Simões, Guilherme Siqueira;
exemplo – pode ser considerada completa sionais: uma vez que as situações mais Albert, Renato Machado. Análise de Pontos de Função:
e reconhecida pelo usuário, porém existe comuns nas medições da organização Medição, Estimativas e Gerenciamento de Projetos de
a inclusão, alteração e exclusão de tarifas, estejam exemplificadas, menor a chance Software. Ed. Érica, 2007.
parte da manutenção citada, que também de profissionais diferentes usarem crité-
pode ser considerada completa, portanto, rios distintos nas medições. Glossário Interativo da Análise de Pontos de Função:
a manutenção de tarifas não pode ser con- • Centralizar a experiência da conta- http://apf.locaweb.com.br/mod/glossary/view.php?id=1
siderada uma função de transação. gem envolvendo diferentes tecnologias Mapa Mental Interativo da Análise de Pontos de Função:
Para que uma tarifa seja excluída, é e domínios de problema (por exemplo, http://www.fattocs.com.br/freemind/APF.html
necessária a realização de uma atividade sistemas em mainframe, múltiplas Measuring Application Development Productivity -
de validação. Não deve haver nenhum camadas, workflow, business intelli- Allan J. Albrecht: http://www.fattocs.com.br/artigos/
lançamento referente a essa tarifa. O gence, batch, entre outros): mesmo para MeasuringAplicationDevelopmentProductivity.pdf
usuário reconhece essa atividade, porém profissionais experientes no uso da APF,

Melhores Práticas na Automação de Testes
A
automação de testes é uma A automação de testes não é um
área em franca expansão, no processo de testes
entanto, é uma área ainda Muitas empresas fracassam na implan-
muito imatura. Muitos dos sucessos tação da automação de testes em virtude
nos projetos de automação de testes são da inversão de prioridades causada pela
decorrentes de processos empíricos de busca da qualidade a qualquer preço.
tentativa e erro. Neste cenário, as empresas adquirem
Para piorar a situação, a automação uma ferramenta de automação de testes
de testes ainda é objeto de mitos que prematuramente sem, ao menos, possuí-
geram percepções errôneas sobre os rem um grau mínimo de maturidade no
seus reais benefícios e limitações. processo de testes. O processo de testes
Cristiano Caetano Freqüentemente, as ferramentas de é informal, as responsabilidades não
c_caetano@hotmail.com automação de testes são supervalori- são bem definidas e os profissionais não
É certificado CBTS pela ALATS. Diretor da Tes- zadas gerando falsas expectativas, a possuem o perfil adequado ou não são
tAnywhere, consultoria de teste de software infra-estrutura requerida é subesti- qualificados.
(www.testanywhere.com.br). Possui mais de 10
mada, entre outros problemas comuns Segundo Watts S. Humphrey, criador
anos de experiência, já trabalhou na área de qua-
lidade e teste de software para grandes empresas que serão apresentados ao longo deste do CMM (Capability Maturity Model), a
como Zero G, DELL e HP Invent. Autor dos livros artigo. qualidade do produto final é diretamen-
“CVS: Controle de Versões e Desenvolvimento Nas seções a seguir serão apresen- te proporcional à qualidade do processo
Colaborativo de Software” e“Automação e Geren- tadas algumas boas práticas e conse- utilizado no seu ciclo de vida. A implan-
ciamento de Testes:Aumentando a Produtividade
lhos reunidos pelo autor durante os tação da automação de testes depende de
com as Principais Soluções Open Source e Gratui-
tas”.Criador e mantenedor do portal TestExpert: A últimos anos (à custa do aprendizado testes manuais maduros e consistentes.
sua comunidade gratuita de teste e qualidade de empírico em projetos de automação Os projetos de automação de testes bem
software (www.testexpert.com.br). de testes). sucedidos são aqueles que se baseiam
42 Engenharia de Software Magazine - Melhores Práticas na Automação de Testes

Verificação, Validação e Tes te
em processos de testes formais e estru- validações subjetivas (estes tipos de tes- A experiência tem mostrado que a
turados. Afinal, como é possível esperar tes devem permanecer manuais). Além incorporação de testabilidade na apli-
alguma coisa de testes automatizados disso, muitas vezes o custo e o tempo cação é um fator chave para o sucesso
que são baseados em testes manuais er- para automatizar os testes de um projeto de um projeto de automação de testes.
rados, ambíguos ou inconsistentes. Não são maiores que o custo e o tempo do A testabilidade é um atributo que deter-
é possível automatizar o caos. próprio projeto de desenvolvimento (o mina a capacidade de uma aplicação ser
A rigor, o sucesso na implantação da que inviabilizaria a automação de 100% testada, ou seja, a facilidade de se testar
automação de testes depende do enten- dos testes manuais). uma aplicação está diretamente ligada
dimento de que a automação de testes ou A escolha dos testes automatizados ao nível de testabilidade incorporado
uma ferramenta de automação, por si só, candidatos, ou seja, os mais críticos, nesta aplicação.
não vão melhorar ou organizar os testes deve ser realizada com base no contexto Normalmente é necessário realizar
existentes. É necessário antes, fazer a “fa- do projeto de automação. No entanto, modificações na aplicação para torná-la
xina” e implantar um processo de testes apesar de não existir uma categorização mais fácil de testar. Essas modificações
formal. A necessidade de automatizar os amplamente difundida, a experiência têm o objetivo de incorporar um con-
testes virá naturalmente como resultado tem mostrado que os testes candidatos junto de mecanismos que facilitam a
da evolução da maturidade do processo são normalmente agrupados em quatro observação e o controle do estado dos
de testes. áreas distintas: componentes internos da aplicação. Adi-
• Smoke Tests: Um conjunto mínimo cionalmente, estes mecanismos expõem
Automatize os testes de testes é selecionado com o objetivo de ao mundo exterior as funcionalidades da
críticos primeiro validar um Build ou liberação antes do aplicação por meio de APIs, Interfaces de
Nove em cada dez projetos de automa- início de um ciclo de testes; Linha de Comando, Hooks, etc.
ção de testes cometem o erro de transfor- • Testes de Regressão: Os testes são Isto torna, por sua vez, a aplicação mui-
mar todos os casos de testes manuais em selecionados com o objetivo de executar to mais fácil de se testar, sob o ponto de
scripts de testes automatizados. O leitor o re-teste de uma funcionalidade ou da vista da automação de testes. O objetivo
deve estar se perguntando: Mas este não aplicação inteira; desses mecanismos (APIs, Interfaces de
seria o objetivo principal da automação • Funcionalidades Críticas: Os testes Linha de Comando, Hooks) é fornecer
de testes? – Sim e Não. são selecionados com o objetivo de interfaces para o mundo exterior que
A automação de testes tem o objetivo validar as funcionalidades críticas que não seja dependente da interface gráfica
de reduzir o envolvimento humano em podem trazer riscos ao negócio; da aplicação. Dessa forma, é possível
atividades manuais repetitivas. Entre- • Tarefas Repetitivas: Os testes são criar testes especializados para exercitar
tanto, isto não significa que a automação selecionados com o objetivo de reduzir algumas funcionalidades da aplicação
de testes deve se limitar apenas a fazer o envolvimento dos testadores em ativi- sem que seja necessário utilizar uma
o trabalho repetitivo e chato. Os casos dades manuais repetitivas e suscetíveis interface gráfica.
de testes manuais foram criados num a erros, tais como cálculos matemáticos,
contexto onde os testes seriam execu- simulações, processamentos, compara- As ferramentas de automação de
tados manualmente. É muito provável ções de arquivos ou dados, etc. testes também têm defeitos
que estes casos de testes manuais não A automação de testes é, em última ins-
sejam muito eficientes em um con- Incorpore testabilidade tância, a execução de um software para
texto onde os testes serão executados ao aplicativo testar outros softwares. Dessa forma,
automaticamente. Via de regra, os testes são automatiza- podemos afirmar que as ferramentas de
Freqüentemente, antes de iniciar a dos utilizando a aplicação do jeito que automação de testes sofrem dos mesmos
automação, os testes devem ser re-proje- ela é. Ou seja, os testes são criados sob o tipos de problemas que as aplicações
tados a fim de aumentar a probabilidade ponto de vista da interface gráfica e com convencionais, ou seja: defeitos. É muito
de revelar um defeito que ainda não o único objetivo de automatizar as ações comum ocorrerem atrasos em projetos
tenha sido encontrado. Afinal, o grande dos usuários finais. de automação em virtude de problemas
benefício da automação de testes não é No entanto, testar por meio da interface causados pela ferramenta de automação
a execução dos testes mais rápida e a gráfica nem sempre é a melhor opção de testes. Dentre os problemas mais
qualquer hora do dia ou da noite, mas o para testes que exigem desempenho. comuns, devemos destacar:
aumento da amplitude e profundidade Além disso, às vezes a interface gráfica • Manuais incompletos e ambíguos;
da cobertura dos testes. não fornece evidências de que o teste • Defeitos não reproduzíveis que ocor-
Na prática, a automação de 100% dos foi realizado com sucesso, afinal, nem rem aleatoriamente;
testes manuais nem sempre é a melhor sempre a mensagem “Essa operação foi • Vazamento de memória quando a
estratégia. A automação de testes é pou- realizada com sucesso” significa que a ferramenta é executada durante muitas
co eficaz quando os testes são complexos operação foi realizada com sucesso de horas;
e exigem interações intersistemas ou verdade. • Degradação do desempenho quando

a ferramenta é executada durante muitas contexto, a melhor prática é demonstrar Dimensione a infra-estrutura
horas; os benefícios, limitações e restrições da adequadamente
• Travamentos durante a gravação ou ferramenta por meio de uma prova de Muitos projetos de automação de testes
execução dos testes; conceito. fracassam em virtude do subdimensio-
• Relato incorreto de testes executados Em resumo, você deve escolher os namento da infra-estrutura. As ferra-
com sucesso quando ocorrem problemas testes mais importantes e os mais com- mentas de testes automatizados exigem
ou vice-versa; plexos que serão automatizados no seu computadores de alto desempenho com
• Recursos que não funcionam como projeto de automação e criar todos os processadores rápidos e grandes quan-
deveriam; scripts utilizando uma versão demo ou tidades de memória. Além disso, estes
• Reconhecimento incorreto dos com- trial da ferramenta de automação. computadores devem ser dedicados
ponentes (botões, campos, menus, etc) Conforme mencionado anteriormente, exclusivamente para a automação de
da aplicação em teste; as demonstrações apresentam as princi- testes (durante a execução dos testes o
• Defeitos de regressão (funcionalida- pais funcionalidades da ferramenta de computador não pode ser utilizado para
des que não funcionam mais correta- automação por meio de cenários e testes outro fim).
mente após um upgrade da ferramenta); simples. Uma prova de conceito, por sua Os computadores onde os testes serão
• Defeitos críticos que impedem a uti- vez, tem o objetivo de provar se a ferra- executados devem ser semelhantes ou
lização das principais funcionalidades menta atenderá as reais necessidades do com maior capacidade de processamento
da ferramenta. seu projeto de automação. em relação aos computadores utilizados
Dentre os aspectos que devem ser para criar os scripts de testes automatiza-
Com base no que foi exposto, a expe- analisados numa prova de conceito, dos, caso contrário, ocorrerão problemas
riência tem mostrado que as seguintes devemos destacar: de baixa de performance.
ações devem ser tomadas antes da • Avaliar se as funcionalidades da fer- A execução dos testes automatizados
compra e durante a utilização de uma ramenta de automação funcionam con- é muito sensível a influências externas.
ferramenta de automação de testes: forme apresentado na demonstração; Devemos reforçar que diferenças sutis
• Criar uma prova de conceito antes de • Avaliar se os manuais são adequados no ambiente (sistema operacional, rede,
comprar a ferramenta para certificar-se e informativos; versões dos programas, dados, etc) po-
que ela não tenha defeitos críticos; • Avaliar se existem defeitos críticos dem prejudicar ou impedir a execução
• Utilizar sempre a versão mais atual que impedem a utilização das principais dos testes automatizados.
da ferramenta; funcionalidades da ferramenta; Planejar com detalhes a infra-estrutura
• Não utilizar a versão mais atual da • Avaliar se existe degradação do de- necessária para criar e executar os testes
ferramenta (upgrade) sem realizar um sempenho ou vazamento de memória automatizados é um fator chave para o
teste de regressão (para evitar que a quando a ferramenta é executada du- sucesso de um projeto de automação de
correção de um problema crie problemas rante muitas horas; testes. Dentre os aspectos que devem ser
piores); • Avaliar se a ferramenta reconhece os considerados, devemos destacar:
• Se não houver solução para os pro- componentes e componentes personali- • Computadores de alto desempenho:
blemas ou limitações da ferramenta, zados (botões, campos, menus, etc) da Os computadores que serão usados para
considere a criação de soluções alterna- aplicação que será testada; criar e executar os testes automatizados
tivas (workarounds) utilizando a própria • Avaliar se a ferramenta e a linguagem deve estar em conformidade com os
ferramenta. de script oferecida é robusta o suficiente requerimentos mínimos exigidos pela
para lidar com testes complexos; ferramenta de automação;
Demo não é prova de conceito • Avaliar se a ferramenta é realmente • Computadores dedicados: Os com-
As maravilhas oferecidas pelas fer- fácil de usar e se a ferramenta oferece putadores onde os testes automatizados
ramentas de testes automatizados recursos para a criação de bibliotecas de serão executados devem ser dedicados
normalmente são apresentadas por scripts a fim de facilitar a reutilização; para essa função, caso contrário os testes
demonstrações (Demos). Normalmente, • Avaliar se a ferramenta funciona podem ser prejudicados e pode ocorrer
essas ferramentas são compradas com adequadamente na infra-estrutura/ degradação da performance;
base na boa impressão causada durante ambiente existente e avaliar se será ne- • Ambiente isolado: O ambiente deve
essas apresentações. cessário algum investimento adicional ser restrito ao time de automação de
Triste engano, infelizmente. As de- para adequar a infra-estrutura/ambiente testes para evitar a desestabilização da
monstrações normalmente apresentam aos requerimentos mínimos exigidos integridade do ambiente por meio de
cenários de utilização muito simples em pela ferramenta; influências externas;
um ambiente controlado. Às vezes aque- • Identificar as limitações e restri- • Ambiente controlado: Todos os deta-
la ferramenta perfeita apresentada na ções da ferramenta para evitar falsas lhes do ambiente (sistema operacional,
demonstração pode ser um completo de- expectativas. rede, versões dos programas, dados, etc)
sastre para testar a sua aplicação. Neste devem ser planejados e controlados, sob

pena de prejudicar ou impedir a execu- defeitos (bugtracker) para gerenciar estes comuns usadas pelas empresas fabri-
ção dos testes automatizados; defeitos; cantes das ferramentas de automação,
• Ambiente similar ao de produção: O • Os scripts de testes devem ser sub- devemos destacar:
ambiente onde os testes serão executados metidos a um processo de Gerência de • Desenvolva software de qualidade e
deve ser igual ou similar ao ambiente de Configuração de Software e controle de aumente a receita e a lucratividade da
produção, sob pena de encontrar falsos versões; sua empresa por meio da ferramenta de
positivos, ou seja, os testes são executa- • Durante o desenvolvimento dos testes automatizados XYZ;
dos com sucesso no ambiente de testes, scripts de testes, deve-se aplicar as • Crie testes sofisticados com treina-
mas as funcionalidades apresentam melhores práticas utilizadas em pro- mento mínimo;
defeitos em produção; jetos de desenvolvimento de software • Utilize o recurso XYZ para gravar os
• Massa de dados consistente: Os convencionais; scripts e elimine o tempo de codificação
dados utilizados nos testes devem ser • O Testador-Desenvolvedor deve ter o dos scripts;
conhecidos e representativos, além perfil e interesse em trabalhar com au- • Aumente a produtividade e dimi-
disso, devem ser armazenados numa tomação de testes, nem sempre um bom nua o tempo gasto em manutenção por
linha de base (baseline) a fim de per- testador ou analista de testes se tornará meio do compartilhamento de scripts e
mitir que sejam recuperados todas as um bom Testador-Desenvolvedor; bibliotecas;
vezes que os testes automatizados forem • Os recursos humanos que atuarão no • Identifique os problemas facilmente
executados. projeto de automação de testes devem por meio do recurso XYZ utilizado nos
ser treinados adequadamente. Quanto nossos relatórios;
Encare a automação de testes mais capacitados, maior será a probabi- • Utilize o recurso XYZ de reconheci-
como um projeto lidade de sucesso do projeto. mento automático de objetos e garanta
A automação de testes é uma combi- a execução dos testes mesmo quando a
nação entre teste e desenvolvimento de Alinhe as expectativas e garanta a interface gráfica tenha mudado.
software, afinal, a atividade de criação colaboração de todos os envolvidos
de scripts de teste é uma atividade de pro- Os projetos de automação de testes Em projetos de automação de testes, é
gramação pura. Dessa forma, podemos costumam fracassar porque as pessoas necessário o alinhamento das expectati-
afirmar que a automação de testes deve envolvidas têm percepções diferentes vas e a colaboração entre a alta gerência,
ser encarada como um projeto com ca- sobre os benefícios e as limitações de um desenvolvedores, arquitetos e testadores.
racterísticas próprias, ou seja, exige um projeto de tal natureza. É de suma importância explicar com
planejamento detalhado, assim como, Normalmente a alta gerência acredita detalhes os objetivos e o escopo de um
atividades de projeto, desenvolvimento que a automação de testes é a solução projeto de automação de testes e, acima
e testes, tal qual o desenvolvimento de de todos os problemas. Os arquitetos e de tudo, garantir que as expectativas
um software convencional. desenvolvedores desconhecem a necessi- de todas as partes interessadas sejam
Via de regra, a criação de testes auto- dade da criação de mecanismos para au- realistas. Dessa forma, conseguimos eli-
matizados é realizada por testadores mentar a testabilidade durante o projeto minar o folclore e os mitos criados pelas
especializados em desenvolvimento, e desenvolvimento da aplicação. estratégias de marketing usadas pelas
também conhecidos como Testador- O time de testes, por sua vez, costuma empresas fabricantes das ferramentas
Desenvolvedor ou Automatizador. Este acreditar que a automação dos testes de automação.
profissional deve ter o perfil de desen- é uma tarefa simples que não exige A estratégia recomendada para garan-
volvedor e ser treinado adequadamente capacitação e é resumida apenas pela tir o alinhamento das expectativas com
para utilizar a ferramenta de automação transformação dos testes manuais em relação aos benefícios e limitações de um
de testes. scripts de testes automatizados por meio de projeto de automação de testes deve
Com base no que foi exposto, a expe- dos recursos de gravação (recording) ofe- considerar as seguintes atividades:
riência tem mostrado que os seguintes recidos pelas ferramentas de automação • Demonstrar os benefícios, limitações
aspectos devem ser considerados em de testes. e restrições da ferramenta por meio de
projetos de automação de testes: Essas suposições errôneas são o re- uma prova de conceito;
• O projeto de automação deve ser sultado da falta de conhecimento dos • Planejar com detalhes a infra-estru-
encarado como um projeto com carac- benefícios e limitações de um projeto tura necessária para criar e executar os
terísticas próprias, ou seja, exige um de automação de testes. As campanhas testes automatizados para evitar proble-
planejamento detalhado, assim como, publicitárias das ferramentas de auto- mas de subdimensionamento;
atividades de projeto, desenvolvimento mação, por sua vez, pioram esse cenário • Envolver desenvolvedores e arqui-
e testes; em virtude de que vendem uma imagem tetos no projeto de automação de testes
• Os scripts de testes podem ter de- de que a automação de testes é a solução com o intuito de incorporar mecanis-
feitos, logo, recomenda-se a utiliza- de todos os problemas de qualidade. mos para aumentar a testabilidade da
ção de uma ferramenta de gestão de Dentre as artimanhas de marketing mais aplicação;

Teste Teste Teste para a automação de testes é a compra
Informal Manual Automatizado de uma ferramenta. Entretanto, existem
Pessoal 0 60.000 60.000 muitos outros investimentos necessá-
Infra-estrutura 0 10.000 10.000 rios, tais como:
Investimentos
Ferramentas 0 0 12.500 • Contratação ou capacitação de pes-
TOTAL 0 70.000 82.500 soal para realizar a gestão do projeto de
Fase de Defeitos encontrados 250 250 250 automação de testes;
desenvolvimento Custo para corrigir 2.500 2.500 2.500 • Contratação ou capacitação de pesso-
Defeitos encontrados 0 350 500 al para projetar/criar os casos de testes
Fase de testes
Custo para corrigir 0 35.000 50.000 automatizados;
Produção
Defeitos encontrados 750 400 250 • Compra ou melhoria da infra-estrutu-
Custo para corrigir 750.000 400.000 250.000 ra/ambiente para atingir os requerimen-
Conformidade (investimento em prevenção) 0 70.000 82.500 tos mínimos exigidos pela ferramenta;
Não Conformidade (custo para corrigir os defeitos • Gastos relacionados à incorporação
Custo da Qualidade 752.500 437.500 302.500
encontrados) de testabilidade na aplicação para torná-
TOTAL 752.500 507.500 385.000 la mais fácil de testar;
Retorno de Investimento N/A 350% 445% • Gastos relacionados à criação de pro-
Tabela 1. Retorno do investimento de testes informais, manuais e automatizados. vas de conceitos ou protótipos.
• Envolver os testadores para alinhar desenvolvimento custa cerca de $10, na A automação de testes é um investi-
as expectativas em relação aos objetivos fase de teste custa $100 e em produção mento com retorno garantido quando
e estratégia da automação de testes, custa $1.000, como pode ser visto na aplicada corretamente. No entanto, o
assim como, fomentar o treinamento e Tabela 1. retorno é de longo prazo, ou seja, não
a capacitação; No exemplo proposto por Rex Black, a existe retorno imediato.
• Envolver a alta gerência para alinhar abordagem utilizando testes automatiza- Conforme mencionamos anteriormen-
as expectativas em relação ao retorno de dos garante um retorno de investimento te, a automação dos testes deve começar
investimento, benefícios, limitações e de 445%. A mensagem é clara: a auto- a partir de uma prova de conceito e
restrições de um projeto de automação mação de testes paga o investimento. O gradualmente crescer até atingir maturi-
de testes. grande problema é quanto investimento dade por meio de um conjunto de scripts
é necessário e quando esse investimento robustos e estáveis que garantam uma
A automação de testes é um vai começar a dar retorno. cobertura de testes adequada.
investimento de longo prazo Você poderá notar que o exemplo de O caminho para a maturidade na auto-
A automação de testes, sem dúvida, é Rex Black considera apenas um inves- mação de testes é tortuoso e demorado. É
uma boa prática em um processo de teste timento de $12.500 para a compra da necessária muita persistência para atin-
de software. No entanto, a automação de ferramenta de automação de testes. Por gir a maturidade na automação de testes.
testes não é uma prática que se adota do outro lado, devemos lembrar que uma A melhor prática para aumentar as chan-
dia para a noite. Conforme mencionamos ferramenta é apenas o meio pelo qual ces de sucesso é evoluir iterativamente.
anteriormente, a necessidade de automa- implementamos a automação de testes, Dessa forma, os prejuízos advindos de
tizar os testes virá naturalmente como mas a automação de testes não se limita uma decisão errada numa iteração serão
resultado da evolução da maturidade apenas à utilização de uma ferramenta. baixos e administráveis.
do processo de testes. Como vimos anteriormente, a automa-
Apesar de todos os benefícios advindos ção de testes deve ser encarada como um O teste manual é insubstituível
da automação de testes, os investimen- projeto com características próprias, ou Segundo Cem Kaner, autor do livro
tos são altos. Rex Black, guru na área seja, exige um planejamento detalha- “Lessons Learned in Software Testing”,
de testes de software, no seu famoso do, assim como, atividades de projeto, o propósito da automação de testes
artigo chamado “Successful Investing in desenvolvimento e testes, tal qual o pode ser resumidamente descrito como
Software Testing” apresenta um cenário desenvolvimento de um software con- a aplicação de estratégias e ferramentas
hipotético com os custos requeridos vencional. Ou seja, o investimento em tendo em vista a redução do envolvi-
para realizar testes informais, manuais automação de testes não se limita apenas mento humano em atividades manuais
e automatizados e o retorno de investi- aos custos da ferramenta de automação repetitivas.
mento (ROI) obtido em cada uma dessas de testes. Devemos reconhecer que a automação
abordagens. Infelizmente, muitos projetos de au- de testes não deve ser empregada como
Neste artigo, Rex Black, parte da tomação de testes costumam fracassar um substituto do teste manual. Ela deve
premissa de que o custo para corri- porque a alta gerência costuma acreditar ser introduzida como uma técnica adi-
gir um defeito encontrado na fase de que o único investimento necessário cional cujo objetivo principal é agregar

valor, sem, no entanto, invalidar o teste a intuição, a criatividade e a experiência problemas imprevistos, assunções in-
manual existente. Afinal, testes manu- do testador são indispensáveis para ga- corretas, expectativas não alinhadas,
ais e automatizados são abordagens rantir a eficiência do teste. defeitos na ferramenta de automação,
de testes diferentes que se reforçam O grande benefício da utilização de falta de testabilidade na aplicação, pro-
mutuamente. testes exploratórios está ligado à sua blemas na infra-estrutura/ambiente,
Dessa forma, por meio da automação natureza empírica. Os testes automati- entre outros aspectos discutidos neste
dos testes, os testadores poderão reduzir zados repetem sempre os mesmos testes, artigo. O importante é aprender com os
o seu envolvimento em atividades ma- os mesmos caminhos, as mesmas opera- próprios erros e seguir em frente, afinal,
nuais repetitivas e focar em abordagens ções. Por meio dos testes exploratórios te- aqueles que não conseguem se lembrar
de testes complementares que exigem a mos a oportunidade de empiricamente e dos erros do passado estão condenados a
aplicação da intuição e julgamento. O iterativamente criar novos testes e seguir repetí-los (George Santayanna).
teste exploratório é uma estratégia de novos caminhos, que por sua vez, nos
testes complementar interessante uma leva a descoberta de novos defeitos.
vez que faz uso intensivo da intuição e
julgamento do testador. Conclusão Links
O teste exploratório é, na sua definição A automação de testes não deve ser
mais básica, a criação e a execução ao empregada como um substituto do teste Testes Exploratórios de A a Z
mesmo tempo de um teste. Quando se manual. Ela deve ser introduzida como http://www.linhadecodigo.com.br/Artigo.aspx?id=1102
realiza um teste exploratório, normal- uma técnica adicional cujo objetivo prin- Rex Black - Successful Investing in
mente o testador não tem informações cipal é agregar valor. O enfoque deve ser Software Testing
detalhadas sobre o que vai testar e como na melhoria do processo de testes utili- http://www.rexblackconsulting.com/publications/Investing
vai testar. O testador se baseia na sua zado na sua empresa. A necessidade de in Testing (Slides).pdf
experiência, assim como no conheci- automatizar os testes virá naturalmente
mento que ele vai adquirindo sobre o como resultado da evolução da maturi- Return on Investment Calculator for
aplicativo durante a execução do teste dade do processo de testes. Test Automation
exploratório. Finalmente, devemos lembrar que a http://www.elbrus.com/services/test_automation_roi_calc/
A partir dessa perspectiva, podemos automação de testes é um investimento
Automação e Gerenciamento de Testes:
afirmar que o teste exploratório é uma cujo retorno é de longo prazo. O cami-
Aumentando a Produtividade com as
atividade iterativa e empírica de ex- nho para a maturidade na automação de
Principais Soluções Open Source e Gratuitas
ploração que exige idas e vindas num testes é tortuoso e demorado.
http://www.linhadecodigo.com.br/EBook.aspx?id=2951
processo de investigação contínuo onde Nesta jornada, provavelmente surgirão

Modelagem de Processos de Negócio
com Uso do NetBeans
Modelo prático em Business Process Execution Language (BPEL)

O artigo apresenta uma abordagem prá-
N
tica da utilização da IDE NetBeans para
o artigo da edição anterior da a modelagem de processos de negócio
Engenharia de Software Maga- utilizando o BPEL.
zine, foi discutido a respeito da
modelagem de processos de negócio com Para que serve?
a utilização da notação Business Process Orientar os desenvolvedores, através da
Modeling Notation (BPMn) [BPMN, 2006] conceituação de termos e da apresen-
e a orquestração em linguagens execu- tação de um exemplo prático, de como
táveis como Business Process Execution utilizar a IDE na modelagem de processos
Language (BPEL) [JURI, 2006] e Web Ser- de negócio.
vices for Business Process Design (XLANG)
[WfMC, 2005]. Além da introdução a Em que situação o tema é útil?
conceitos de BPM, foi descrito também O tema tem aplicação na prática para
André Luiz de Castro Leal o estado da arte da abordagem de mo- desenvolvedores que iniciam os estudos
andrecastr@gmail.com delagem de processos de negócio, os de BPM e que podem utilizar uma IDE
É mestrando e especialista em Ciência da Computa- estudos do Gartner Group [NATI, 2006] acessível no mercado para a modelagem e
ção pela Universidade Federal de Viçosa UFV,espe- com relação às expectativas e as “apos- execução dos processos de negócio.
cialista em Gestão das Tecnologias da Informação tas” dos principais players do mercado
pela Faculdade Machado Sobrinho, atua a mais de
14 anos no mercado de informática com projetos
com relação a essa abordagem.
de software e atualmente coordena a equipe de Nesse artigo, será apresentado um para-
desenvolvimento de sistemas computacionais do digma prático dos conceitos apresentados O NetBeans, desde sua versão 5.5, pas-
Grupo Mult unidade de Juiz de Fora. É também anteriormente e utilizada uma IDE ampla- sou a incorporar ferramentas necessárias
professor de disciplinas de Gerência de Projetos e mente difundida no mercado, de fácil aces- para escrever, testar e depurar aplicati-
Banco de Dados da Faculdade Estácio de Sá-JF.
Áreas de Interesse: Engenharia de Software, Qua-
so a todos os desenvolvedores e empresas vos de arquitetura orientada a serviços
lidade de Software, Processos de Desenvolvimen- de pequeno e médio porte para que iniciem (SOA), dinamizando o desenvolvimento
to de Software e SOA. seus estudos a respeito de BPM. e aprimorando a produtividade dos
48 Engenharia de Software Magazine - Modelagem de Processos de Negócio com Uso do NetBeans

bpm
Elemento Conceito
Service Web Definition Language. Fornece um modelo em formato XML para descrição de serviços Web que possibilita uma separação
WSDL da descrição das funcionalidades abstratas, oferecidas por um serviço, dos detalhes concretos, que descrevem um serviço, como “onde” e “como” as
funcionalidades são oferecidas [WSDL 2003]. Dessa forma, permite uma linguagem padrão para a interação entre diferentes aplicativos.
São componentes padronizados de parte de um aplicativo que são utilizados para a integração entre sistemas computacionais distintos. Dessa forma,
Web Services os aplicativos interagem a partir de troca de mensagens em um formato padrão em XML. O principal objetivo da arquitetura WebServices é
conectar aplicações desenvolvidas em diferentes plataformas através de um canal único e padronizado de comunicação.
Process
É o processo principal que está modelado ou será executado, onde estão todas as relações dos elementos participantes do negócio. Atividades, regras,
parceiros e iterações estão centralizados e serão executados em único fluxo. O processo será iniciado com um evento definido como Process Start,
e será finalizado com um evento Process End.
Roles São papéis que alguns elementos desempenham como participantes do processo.
Partners ou
São elementos externos ao processo que através de papéis e regras interagem com o processo principal.
Partner Player
Partner Link
Os Partner Links descrevem a interação entre o processo BPEL e Web Services externos. Nele devem estar descritos os principais papéis de cada
Partner Player para que possam interagir através de troca de mensagens.
Utilizado para criar uma associação entre dois papéis e indicar o que cada papel deve implementar. Dessa forma, o Partner Link Type define as
Partner Link Type
interações entre os diferentes papéis dos Partners no processo.
Sequence
É a ordenação da execução das atividades do processo, as atividades são seqüenciadas e executadas de acordo com a ordem que aparecem no
diagrama. As atividades são finalizadas quando a última atividade seqüenciada for completada. Podem ser adicionadas e seqüenciadas em um
container de Sequence tantas atividades quanto forem necessárias.
Pick
O bloco de elemento Pick é utilizado quando se faz necessário esperar pela execução de um determinado evento. Assim, o bloco só é executado
após um evento específico ocorrer. O Pick possui duas ações: OnMessage e OnAlarm. OnMessage será utilizado para configurar o tipo
de mensagem que é aguardado de um determinado Partner. OnAlarm é configurado com um timer indicando quando tempo o processo irá
esperar um determinado evento.
Invoke
Utilizado para invocar atividades entre o processo BPEL e um serviço do Partner. Esse serviço é invocado e trafegado por um endereço (porta)
definido pelo Partner. Dessa forma, o Invoke permite a troca de mensagens entre o processo BPEL e os Partners envolvidos no processo.
Receive
É utilizada para aguardar a chegada de uma mensagem de um determinado Partner. Enquanto a mensagem não é encaminhada pelo Partner, o
processo entra em estado de espera e fica impedido de continuar ou ser finalizado.
Reply
Utilizado pelo processo para responder uma mensagem ao serviço de um Partner, que tenha enviado uma mensagem anterior (Receive) para
uma comunicação.
Assing
Atribui valores às variáveis do processo. É também utilizado para copiar o conteúdo de uma variável para outra e para calcular expressões.
If .. elseif
São estruturas condicionais que podem ser utilizadas, por exemplo, para a execução de uma determinada atividade caso uma determinada condição
seja satisfeita.
Tabela 1. Principais termos e conceitos utilizados na modelagem BPEL.

principais aspectos dos aplicativos com
a finalidade de SOA. Nesse artigo será
utilizado o NetBeans 6.1 com o objetivo
de se apresentar, de forma introdutória,
os recursos disponíveis nesta versão
para a criação de projetos com foco em
modelagem de processos de negócio.
O artigo irá explicar o processo de
registro de reserva de viagem que vem
como exemplo na própria versão 6.1
[MAY, 2008] e que foi utilizado como
exemplo de aplicação prática dos concei-
tos do artigo de BMP do artigo da edição
anterior da revista. Dessa forma, o leitor
poderá entender alguns dos principais
elementos envolvidos no diagrama do
processo e verificar como é possível ma-
nipular seus elementos com a IDE.
Vocabulário dos Principais

Elemtnos Utilizados no Projeto
É importante, inicialmente, esclarecer
alguns elementos e seus conceitos que
estão direta ou indiretamente relaciona-
dos ao projeto a ser apresentado. Esses
elementos estão disponíveis no NetBeans
e são eles que tratam todo o fluxo da
modelagem do processo de negócios do
registro de reserva de viagem. A Tabela
1 apresenta de forma sucinta esses ele-
mentos e seus conceitos.
Esses elementos estão disponíveis no
NetBeans em uma paleta de ferramentas,
que são utilizadas para modelar um Figura 2. Tela para a criação de um novo projeto em Java.
Figura 1. Paleta de ferramentas BPEL no

NetBeans. Figura 3. O projeto de exemplo.

bpm
projeto a partir de elementos do modelo Principais Elementos do projeto de No processo principal, serão inseridas as
BPEL. A Figura 1 apresenta a paleta de Registro de Reserva de Viagem diversas ferramentas como: de comunica-
ferramentas disponibilizadas pela IDE Para começar a entender o projeto ção, de condição, para invocar o processo,
NetBeans. Caso a paleta de ferramentas BPEL do registro de reserva de viagens para receber mensagens, para dar respos-
não esteja disponível no projeto aberto, é necessário rever do que se trata esse tas a mensagens recebidas, entre outras.
ela poderá ser acessada a partir do menu projeto. O projeto é o modelo de um pro- O modelo, portanto, deve conter todos os
Window no sub-menu Palette, que poderá cesso de registro de reserva de viagens elementos para que a comunicação entre
também ser acessada a partir da tecla de efetuado por um cliente qualquer. Nesse os Partners e o processo principal aconteça
atalho Ctrl + Shift + 8. processo estão envolvidas atividades do e o processo possa ser executado.
tipo fazer a reserva do hotel, da compa- Com o projeto aberto é possível encon-
Disponibilizando o Projeto de nhia aérea e do veículo. trar e abrir o modelo BPEL principal,
Exemplo
O NetBeans traz, em um dos seus exem-
plos, o projeto do registro de reserva de
viagens implementado e disponível para
obtermos as primeiras orientações sobre
a modelagem na IDE.
Para disponibilizar o projeto, basta
seguir os passos descritos adiante:
1) A criação de um novo projeto.
Com o NetBeans aberto, deve-se clicar
no menu File e após essa ação clicar em
New Project. A IDE irá abrir a janela
apresentada na Figura 2.
2) Escolhendo o projeto de registro de
reserva de viagem.
Após a janela aberta, o desenvolvedor
deverá clicar no item do Menu tree view
referente a exemplos do NetBeans. Em
seguida deve escolher o item SOA. O
projeto de registro de reserva de viagem
irá estar disponível e pronto para ser
Figura 4. Parametrizações iniciais do projeto.
aberto. A Figura 3 apresenta a seqüência
de opções até o projeto.
3) Parametrizando o projeto.
Após clicar no botão Next da janela
anterior, o NetBeans irá fornecer uma
tela para a parametrização do nome do
projeto e a localização da pasta local
onde serão criados os arquivos daquele
projeto. As parametrizações podem ser
informadas conforme apresentado na
Figura 4. A pasta local deverá conter uma
pasta física do ambiente do computador
do desenvolvedor. Feitas as devidas con-
figurações iniciais, o projeto estará pronto
para ser aberto bastando, para isso, que o
desenvolver clique no botão Finish.
4) O projeto aberto.
O NetBeans irá disponibilizar o projeto
e todas as suas pastas e arquivos devida-
mente abertos para se iniciar a edição, al-
teração, execução ou qualquer ação neces-
sária. Dessa forma, o projeto irá se iniciar
conforme apresentado na Figura 5. Figura 5. Apresentação de pastas e objetos disponíveis no projeto.

onde podem ser verificados todos os AirLine (companhia aérea), Vehicle (Veí-  Vehicle: faz uma interação com
elementos de negócio envolvidos. Para culo) e Hotel (Hotel). A interação desses agenciadora de veículos para efetuar a
abrir o modelo é necessário clicar na área elementos é efetuada a partir de um reserva de locação de veículo. O Partner
de projetos sobre o nó da tree view que processo único do serviço de reserva irá trabalhar com três operações: a de
contenha a descrição TravelReservation- de viagens cujo nome no projeto é receber um pedido de locação do veículo
Service, após isso, clicar em Process Files TravelReservationService. do processo principal enviado pelo Par-
e encontrar o objeto relativo ao Travel- tner Travel; receber uma mensagem de
ReservationService.bpel. A Figura 6 apre- Descrição do Fluxo do cancelamento da requisição do pedido
senta o nó da tree view correspondente ao Processo Principal da locação, caso haja o esgotamento de
modelo BPEL. Para abrir o modelo, basta Nesta seção será descrito o papel de tempo dessa requisição, e enviar uma
clicar com o botão da direta sobre o nó cada elemento no processo. Serão abor- mensagem de retorno ao processo prin-
do modelo que uma caixa de diálogo irá dadas as principais funcionalidades cipal no caso a locação do veículo seja
aparecer com a opção Open, e em seguida do processo e o que cada Partner Link bem sucedida (Figura 10).
clicar sobre essa opção. aguarda do processo principal.  Hotel: faz uma interação com a rede
O modelo BPEL será exibido conforme hoteleira para efetuar a reserva de hospe-
Figura 7. Note que nem todo o modelo Descrição das Funções dos Partner Links: dagem. O Partner irá trabalhar com três
está disponível para visualização, ape-  Travel: representa um cliente que en- operações: a de receber um pedido de re-
nas o início do processo, os Partners do via uma requisição de viagem para o pro- serva hospedagem do processo principal
processo, uma Sequence de nome HasAir- cesso e, em seguida, espera recebê-la de enviado pelo Partner Travel; receber uma
line, um Pick sem identificação e alguns volta após o processamento (Figura 8). mensagem de cancelamento da requisi-
elementos do processo principal.  Airline: faz uma interação com a ção do pedido de hospedagem, caso haja
Para continuar visualizando o processo companhia aérea para efetuar o serviço o esgotamento de tempo dessa requisição,
é necessário arrastar a barra de rolagem de reservas. O Partner irá trabalhar com e enviar uma mensagem de retorno ao
vertical. À medida que a barra de rolagem três operações: a de receber um pedido processo principal no caso a hospedagem
é arrastada é possível verificar que os de reserva do processo principal en- seja bem sucedida (Figura 11).
Partner Links ficam fixos no modelo e que viado pelo Partner Travel; receber uma
somente o processo principal vai sendo mensagem de cancelamento da requi- Descrição do Fluxo do Processo Principal:
apresentado. Dessa forma, é mais fácil a sição do pedido de reserva, caso haja o  O processo é iniciado quando o
manutenção do projeto como um todo. esgotamento de tempo dessa requisição, Partner Link Travel encaminha uma
Os Partners envolvidos no processo e enviar uma mensagem de retorno ao requisição de reserva de viagem para
do registro de reserva de viagem são: processo principal no caso da reserva ser o Receive denominado ReceiveItinerary,
Travel (agente de viagem ou o cliente), bem sucedida (Figura 9). disponível no processo principal. A
Figura 6. Menu de diálogo com opção para

abertura do modelo BPEL. Figura 7. Modelo BPEL do registro de reserva de viagem.

bpm
Figura 8. Partner
Link: Travel.
Figura 9. Partner Link: Airline. Figura 10. Partner Link: Vehicle. Figura 11. Partner Link: Hotel.
Figura 12. Chamada inicial do processo

contendo as requisições de reserva.
Figura 14. Chamada ao Partner Link Airline.
Figura 12 apresenta a chamada do Travel próxima requisição que é a requisição de

ao processo principal. reserva de veículo. Os detalhes podem
 O ReceiveItinerary comunica com o ser verificados na Figura 14.
elemento CopyItineraryIn (Assign) que co- . O processo principal irá repetir a mes-
pia os dados de entrada para 4 variáveis: ma transação para o pedido de reserva
Figura 13. Passagem de dados de input do uma variável de saída e três variáveis de veículo e o mesmo acontecerá para o
Receive para a atividade de atribuição de que serão processadas para os Partner pedido de reserva de hotel. Da mesma
valores Assign.
Links Airline, Vehicle e Hotel com dados forma anterior, se o Travel tiver feito uma
de pedidos de reserva do Partner Travel. solicitação dessas reservas, o processo
É possível visualizar no destaque da Fi- principal irá fazer uma chamada com
gura 13 o ReceiveItinerary encaminhando o elemento Invoke correspondente ao
os dados para a atividade de atribuição Partner Link Vehicle ou Hotel.
de valores CopyItineraryIn. . Caso as requisições não tenham men-
 O processo principal irá verificar, sagem de reserva, o processo principal
a partir da atribuição de valores às irá transpor o processamento para a
variáveis, se o Partner Travel fez alguma próxima atividade que é efetuar uma
solicitação de reserva. resposta através de uma mensagem para
. Se o Travel tiver feito uma solicitação o Partner Travel informando da situação
de reserva de companhia aérea, o pro- que reservas não foram sucedidas e, para
cesso principal irá fazer uma chamada isso, irá acionar o elemento Reply deno-
com o elemento Invoke, denominado minado ReturnItinerary (Figura 15).
ReserveAirline, para o Parter Link Airli-  Para as reservas que forem bem
ne, caso contrário o processo principal sucedidas a partir de uma solicitação
irá transpor o processamento para a positiva de reserva do Partner Travel,

o processo principal irá proceder da retornar ao Partner Link Travel, através do ao requisitante Travel.
seguinte forma: Reply, todas as mensagens recebidas dos . No elemento Pick duas atividades
. Para os três Partner Links (Airline, parceiros externos ao processo. serão executadas, no caso de uma confir-
Vehicle e Hotel), o processo principal mação de reserva, o elemento Pick irá re-
irá acioná-los com uma mensagem de A Figura 16 apresenta o recebimento ceber a mensagem positiva em sua ação
pedido de reserva. da chamada pelo Partner Link Airline de OnMessage, onde o elemento Pick irá
. Cada Partner irá processar a mensagem e sua respectiva resposta ao processo atribuir o valor da mensagem recebida
de solicitação, verificar disponibilidade principal. do Partner Link à variável de saída para
de reserva e proceder com uma mensa-  No processamento das solicitações que o processo principal possa efetuar
gem de resposta ao Travel. Os três Partner de reserva, cada elemento Partner Link a resposta ao Travel.
Links têm suas respectivas atividades de está vinculado a um elemento Pick. . Cada elemento Pick irá também tra-
Receive, para o recebimento da solicitação Dessa forma, as respostas positivas ou balhar com uma ação de temporização
do processo principal, e suas atividades negativas de confirmação de reserva para aguardar uma resposta externa
de Invoke, para proceder com a resposta serão encaminhadas a esse elemento e, dos Partners, se essa resposta não for
da solicitação para o processo principal. em seguida, seguirão no fluxo do pro- retornada em 20 segundos, a solicitação
Dessa forma o processo principal poderá cesso até o elemento Reply, de retorno de reserva será cancelada.
Figura 15. Retorno de resposta do Partner Link Travel. Figura 16. Fluxo de recebimento de mensagem e retorno pelo Partner Link Airline.
Figura 17. Comunicação entre Airline e elemento Pick do Figura 18. Menu de execução do projeto.
processo principal.

bpm
Referências
[BPMN, 2006]
Business Process Modeling Notation Specification
(2006). OMG Final Adopted Specification. February.
A Figura 17 apresenta a transação entre A execução do modelo poderá ser feita
o Partner Link Airline e o elemento Pick através do acionamento do menu sobre [JURI, 2006]
disposto no processo principal. o item selecionado no projeto, conforme JURIC, M. B. (2006) Business Process Execution
 Após efetuado o Reply para o ele- exibido na Figura 18. Language for Web Services BPEL and BPEL4WS. 2nd
mento Travel, o processo principal será Edition. 372p. Packt Publishing Ltd.
encerrado. Considerações Finais
O artigo trata de uma explicação a [MAY, 2008]
Execução do Modelo respeito dos principais elementos envol- MAY, B. (2008). Understanding the Travel Reservation
A exec ução do modelo irá fa zer vidos no processo de registro de reserva Service, Maio 2008. Disponível em: http://www.
com que o processo principal faça a de viagem. Seu objetivo foi esclarecer netbeans.org/features/soa/index.html. Consultado em:
comunicação entre Partner Travel com alguns conceitos utilizados na tecnolo- 23/08/2008.
os diferentes parceiros representados gia de modelagem em BPEL e utilizar
pelos Partners Airline, Vehicle e Hotel. Ou a IDE NetBeans para exemplificar esses [NATI, 2006]
seja, independente da arquitetura de conceitos. NATIS, Y. (2006). Predicts 2007: SOA Advances. EUA:
sistemas em que os parceiros externos Pelo objetivo do artigo e pela limitação Gartner, id: G00144445, Novembro.
ao processo estejam construídos, todos de espaço desse meio de divulgação fo-
[WfMC, 2005]
terão disponíveis mensagens em um ram deixados de lado muitos elementos
Process Definition Interface - XML Process
padrão único de comunicação. Dessa e conceitos. Mas a partir das explanações
Definition Language (2005). Workflow Management
forma, a execução do modelo BPEL apresentadas, o desenvolvedor poderá
Coalition Workflow Standard. October.
permitirá uma interoperabilidade fa- iniciar a exploração da IDE NetBeans de
zendo com que diferentes plataformas forma mais rápida e avançar nos estu- [WSDL, 2003]
se comuniquem, disponibilizando para dos dos conceitos de outros elementos Web Service Description Language (2003), http://www.
ambos os lados um padrão de mensa- que não estão sendo utilizados nesse w3.org/TR /2003/WD-wsdl12-20030303, Outubro 2003.
gens em XML. exemplo.

Gestão de Serviços
Operacionais Aplicada à TI
De que se trata o artigo? Estabelecer uma relação balanceada entre a

Apesar da crescente importância da área de área de negócios e a área de TI possibilitará
TI na estratégia de crescimento e ampliação uma melhor otimização dos recursos huma-
dos negócios corporativos, executivos ainda nos e financeiros da empresa, reduzindo os
encaram com muitas ressalvas o aumento dos riscos de solicitação de projetos de menor
custos dos projetos de tecnologia, dificultan- importância, pois todos serão cobrados pelo
do a ampliação de investimentos que trarão cumprimento das metas estabelecidas.
mais agilidade e controle operacional a toda
organização. Em que situação o tema é útil?
Empresas que buscam novos modelos de
Para que serve? gestão e necessitam alinhar seus projetos
Com a tendência dos custos de TI serem cada internos com as metas organizacionais,
vez maiores, as organizações necessitam de garantindo que o Planejamento Estratégico
mecanismos de tomada de decisões mais Corporativo está sendo seguido por todas as
precisos, sobre pena de executar projetos de áreas da organização, buscando maior efici-
baixo valor agregado e deixar de executar ência e rentabilidade operacional, forçando
projetos que trarão resultados financeiros as áreas a requisitar “apenas” o que realmente
mais significativos. trará ganhos financeiros.
Alexandre Bartie
alexandre_bartie@hotmail.com
T
Atua há 17 anos no gerenciamento de processos
ente imaginar uma empresa estrutura gigantesca de profissionais,
voltados à Qualidade e Engenharia de Software.
Pós-Graduado em Capacitação Gerencial pela atuando em qualquer segmento tornando a troca de informações um pro-
FEA-USP e em Gestão Empresarial pelo Instituto de mercado, gerenciando o atual cesso lento e altamente sujeito a falhas,
Trevisan. É Bacharel em Administração de Empre- patamar de qualidade e complexidade resultando numa organização ineficiente
sas pela Fundação Santo André. Diretor de Ino- exigidas pelos clientes, sem recorrer a e com alto nível de re-trabalho.
vação da ALATS (Associação Latino-Americana
nenhum tipo de estrutura computacio- Apesar da evidente relevância da área
de Teste de Software) e Engenheiro de Software
responsável pelo Framework X-Zone. Autor do nal disponibilizada pela área de TI. de TI neste novo contexto econômico,
Livro Garantia da Qualidade de Software. Esta empresa ir ia requerer uma existe um permanente descontentamento
56 Engenharia de Software Magazine - Gestão de Serviços Operacionais Aplicada à TI

Gestão de ti
da organização em relação ao nível de As indústrias perceberam que as estabelecer um maior equilíbrio entre
serviço prestado pela TI. Por mais avan- empresas mais lucrativas não eram Negócios e TI.
ços tecnológicos e conquistas alcançadas, as que mais produziam, mas aquelas É objetivo deste artigo demonstrar
parece que nunca conseguimos atingir que inovavam suas formas de gestão como o modelo de Gestão de Serviços
o patamar de produtividade desejado operacional, estabelecendo uma relação Operacionais enquadra-se perfeitamen-
pelos executivos. mais equilibrada entre o mercado e suas te não apenas na dinâmica de serviços
Na verdade, algo muito semelhante áreas operacionais, produzindo apenas da TI, mas em todas as demais áreas
ocorreu no início do século XX, quando o necessário. operacionais da organização.
a mão de obra profissional começou a ser Foi a partir dos anos 50, com o co-
substituída por máquinas automatiza- lapso da gestão industrial, que vários Transformando a TI
das. A linha de montagem idealizada por modelos foram criados para suportar numa Fábrica de Serviços
Henry Ford organizou a cadeia produti- uma nova dinâmica industrial voltada Nossa tendência é acreditar que o au-
va em mini-etapas de simples realização, integralmente à rentabilidade e efici- mento da produtividade gerado pelas
que foi gradativamente substituída por ência corporativa: Kanban, Just-In- evoluções tecnológicas derrubaria os
uma máquina especializada. Time, TOC (Teoria das Restrições), ABC custos de produção, quando na verda-
Apesar da infra-estrutura de produção (Custos baseado em Atividades), TQM de, estes se tornaram cada vez maiores.
automatizada ser muito mais cara e com- (Gerenciamento da Qualidade Total) Na verdade, os custos operacionais
plexa, o nível de produtividade, veloci- entre outros modelos, todos criados aumentam em função da demanda do
dade e precisão deste novo modelo era para otimizar toda a cadeia produtiva. mercado por produtos e serviços mais
incomparável. Mesmo assim, a área de Apesar de existirem a décadas, estes especializados e inovadores, forçando
produção era constantemente massacra- modelos ainda são a base das modernas sua rápida obsolescência.
da pela organização, exigindo níveis de formas de gestão industrial empregadas Este comportamento pode ser observa-
produção cada vez maiores, exatamente atualmente. do nos mais variados setores da econo-
para justificar os altos investimentos Esta experiência ensinou às organiza- mia - na indústria (com a produção de
realizados. Fatores como falta de quali- ções industriais a aceitarem com mais carros, aviões e navios), na agricultura
dade, re-trabalho, eficiência operacional naturalidade os altos investimentos em e pecuária (produção de soja, milho
eram ignorados pelos executivos, pois o infra-estrutura para ampliar e flexibili- e gado), na medicina (procedimentos
que interessava eram apenas os sucessi- zar sua capacidade de produção, valori- cirúrgicos, exames e diagnósticos) ou
vos recordes de produção. zando o modelo de gestão operacional na engenharia (civil, aeroespacial e mi-
O resultado desta pressão desenfreada como estratégia fundamental para maxi- litar). Os custos operacionais de um setor
por “produção sem controle” foi o cres- mizar a rentabilidade organizacional. sempre serão maiores que no passado
cente aumento do estoque nas indústrias, Como podemos observar, este fenôme- e tendem a tornarem-se ainda maiores
mesmo quando estes não eram encomen- no repete-se novamente, agora focado com o passar dos anos.
dados, gerando uma grave crise de ren- diretamente na área de TI. Assim como O mesmo acontece com os custos
tabilidade organizacional. Com excesso a área de produção no passado, nossos operacionais da TI, onde manter os
de produtos em estoque, foi necessário custos operacionais foram aumentando processos corporativos e agregar novas
baixar os preços para acelerar as vendas ano após ano e a pressão por produtivi- funcionalidades sem interromper as
e recuperar parte dos investimentos. En- dade é cada vez maior. transações comerciais já estabelecidas,
quanto isso, outros produtos que estavam Da mesma forma que no passado, a exige uma maior infra-estrutura de
sendo efetivamente solicitados pelo mer- área de TI deverá estabelecer um novo profissionais, ferramentas e processos
cado não podiam ser produzidos por falta modelo de gestão operacional, nos mes- de gerenciamento.
de matéria-prima específica ou indisponi- mos moldes realizados pela área de pro- Na Figura 1, podemos ver que à medi-
bilidade de recursos e máquinas. dução no passado, de forma a conseguir da que os projetos de TI tornam-se mais
complexos, existe uma demanda por
novos tipos de controles operacionais,
que exigem da TI uma nova gama de
Projeto
B
conhecimento e técnicas a serem incor-
Projeto
poradas nos futuros projetos.
Projeto Projeto
A
A C
ESTRUTURA A necessidade de áreas especializadas

Projeto
D TI
Projeto
D Estrutura TI apoiando internamente a TI passa a ser
cada vez mais estratégica ao longo dos
Projeto Projeto
Projeto F D
C
anos, reduzindo a relevância das equipes
Projeto
E de desenvolvimento e reforçando a im-
portância estratégica das demais áreas
Figura 1. Tendência de aumento da estrutura da TI no longo prazo operacionais.

Isto indica que as estruturas de apoio Mesmo adotando todas as estratégias significativas e que estejam alinhados
tendem a ser maiores e mais espe- de ampliação do mercado de consumo, com as necessidades e exigências do
cializadas, oferecendo cada vez mais grande parte dos consumidores já pos- mercado é o caminho para o sucesso
suporte, controle e qualidade a cada suem produtos e serviços equivalentes, organizacional.
novo projeto de TI. reduzindo as chances de novas receitas
Entender isto como uma tendência operacionais. Desta maneira, as orga- Priorizando as Inovações
que afeta todas as organizações permite nizações necessitam reduzir o ciclo de Corporativas
que executivos encarem o crescimento vida de produtos e serviços, criando Quanto maior importância e signifi-
dos custos operacionais da TI não ne- condições favoráveis dos consumidores cado estratégico uma inovação traz aos
cessariamente como algo negativo ou substituírem seus atuais produtos e negócios, mais prioritária ela apresenta-
ligado a práticas inadequadas de gestão serviços por algo mais moderno e sofisti- se aos olhos da organização, tornando-se
administrativa, mas como um custo ne- cado. Trata-se de criar uma organização vital sua implementação. Do mesmo
cessário para manter-se competitivo. totalmente voltada à inovação. modo, as inovações de pouca relevân-
A inovação é o resultado de um esforço cia estratégica devem ser descartadas,
A Inovação como Estratégia coletivo, envolvendo diversas áreas e evitando que estas concorram com ino-
Corporativa profissionais, que se materializa como vações que efetivamente trarão maiores
A solução para o fenômeno econômico uma vantagem competitiva da empresa. resultados financeiros.
chamado de custos operacionais cres- Poderá ser um novo produto ou serviço, Portanto, todas as inovações devem ser
centes é ampliar a base de consumo, um novo processo interno mais rápido selecionadas e organizadas seguindo
objetivando incrementar as receitas cor- e controlado, uma nova arquitetura um critério de priorização, levando em
porativas. Empregando algumas estraté- de testes mais sofisticada e confiável, consideração não apenas os benefícios
gias de atuação de mercado, as empresas uma nova forma de reutilização de gerados, mas também o esforço neces-
podem arcar com o crescente aumento componentes, um novo acordo comer- sário para materializá-las.
dos custos operacionais, possibilitando cial. Enfim, a inovação é qualquer coisa Para facilitar o planejamento das inova-
manter a empresa lucrativa, sem perder que mantenha a empresa competitiva e ções, muitas empresas utilizam-se de uma
sua competitividade. pronta para o futuro. matriz de prioridades (Figura 2) para ser
Segue algumas estratégias adotadas A capacidade de inovação torna-se a empregada no planejamento estratégico
mundialmente pelas empresas: característica mais importante das or- com a intenção de sistematizar o processo
• segmentação de mercado (criação de ganizações do futuro, pois será através de decisão, auxiliando executivos a decidi-
produtos e serviços diferenciados); dela que as empresas irão surpreender rem quais inovações devem ser prioriza-
• atuação em novos mercados (interna- seus concorrentes e ganhar espaço num das e quais devem ser descartadas.
cionalização do mercado de consumo); mercado mais exigente e dinâmico. Dis-
• fusões corporativas (incorporar seu ponibilizar rapidamente novos produtos Os Cuidados na Redução dos
mercado e reduzir a concorrência). e serviços, que agreguem melhorias Custos Operacionais
Ao longo das últimas décadas, é ine-
gável a contribuição da área de TI no
aperfeiçoamento da qualidade e pro-
Alto
1 2 dutividade alcançada atualmente pelas
organizações. Da mesma forma que as
Investir Agora Investir Agora máquinas revolucionaram os meios de
para ganhar no para ganhar no produção, a tecnologia da informação
Curto Prazo Longo Prazo revolucionou a forma do gerenciamento
Benefício dos serviços.
Alcançado
3 4
Mesmo assim, a TI ainda possui o
estigma de ser um grande custo-fixo
Investir apenas Não investir organizacional, associando sua imagem
se sobrar em hipótese à de despesas permanentes que oneram
Tempo e Recursos nenhuma a lucratividade. Portanto, é natural ob-
Baixo
servarmos executivos gerando uma forte
pressão na redução dos custos de TI.
O fato dos custos serem ainda o alvo
Esforço preferido dos executivos demonstra que
Baixo Alto
Necessário estes ainda estão presos aos paradigmas
de uma economia de mercado pouco
Figura 2. Matriz de Prioridades (Esforço X Benefício) voltada à inovação.

Gestão de ti
No entanto, empregar uma política

de redução de custos sem um critério Projeto
B Despesa
adequado pode produzir um efeito Projeto Projeto Operacional
A C
devastador na organização. Isto ocorre
pelo fato de existir naturezas de custos Custo Perda
ESTRUTURA Operacional Operacional
operacionais diferentes, que devem ser Projeto Projeto
F TI D
compreendidas e avaliadas no momento Investimento
de planejarmos uma redução dos custos Projeto
E
Operacional
corporativos.
Conforme podemos ver na Figura 3,
Figura 3. Classificação errada dos Custos podem afetar a Inovação Organizacional
existe uma grande diferença entre as
despesas operacionais, necessárias
para realização dos projetos e manter em locais e regiões que não era vantajoso problemas geravam novas versões que
os níveis de qualidade estabelecidos, e manter uma infra-estrutura própria. necessitam ser reavaliadas, tornando
as perdas operacionais, vinculadas à Porém, este sistema de auto-atendi- mais frágil toda a dinâmica de validação
queda de produção, re-trabalhos cons- mento compartilhado agregava uma alta do aplicativo, pois novos erros poderiam
tantes, erros de implementação e atrasos complexidade tecnológica, pois reprodu- ser inseridos em transações anterior-
nas entregas. zir todas as condições de operação das mente testadas.
Mesmo para reduzir as perdas opera- várias instituições financeiras num úni- Alocar mais profissionais não resolveria
cionais, executivos devem estar dispos- co software exigiria uma aplicação única o problema, pois além da baixa produtivi-
tos a aumentar seus custos operacionais, que suportasse um número crescente dade da execução de testes manuais, seria
realizando investimentos no setor que de novas funcionalidades, aumentando necessário ampliar o número de ATM´s
promoverão melhoria nos processos riscos de falhas e não-conformidades disponíveis e revisar toda a infra-estrutu-
de trabalho, reduzindo as variações de nos serviços compartilhados. ra disponível. Repensar completamente a
qualidade e produtividades, além de Num contexto onde novos clientes e forma de como os testes eram organiza-
inibirem falhas e erros operacionais. novas transações são incorporadas per- dos e executados era a única saída para
Em resumo, focar exclusivamente na manentemente, as modificações no códi- este gargalo organizacional.
redução dos custos corporativos pode go-fonte eram freqüentes, aumentando Para viabilizar o crescimento de longo
afetar diretamente na capacidade de os riscos de erros durante o processo de prazo da organização e estabelecer um
inovação das diversas áreas opera- implantação. Garantir a conformidade processo de testes e homologação mais
cionais, impossibilitando a empresa do sistema exigiria testar todas as tran- escalável, rápido e confiável, a área de
de gerar melhorias e alavancar novas sações, o que demandava prazos cada Qualidade da TI estabeleceu uma nova ar-
oportunidades que seriam revertidas vez mais longos de homologação (mais quitetura de testes e homologação baseada
num significativo aumento da receita de 20 dias). O atual processo de testes em simuladores de dispositivos físicos e
operacional, compensando todos os e homologação restringia diretamente ferramentas de automação de testes.
custos operacionais envolvidos. a capacidade da TI em gerenciar mais Com isto, a empresa poderia executar
complexidades de forma rápida e esca- todos os tipos de testes e combinações de
Inovações Tendem a Aumentar lável, impedindo o crescimento da rede forma contínua, construir novos casos de
Custos Operacionais compartilhada de auto-atendimento. testes e incorporá-los a um inventário de
Este é um exemplo real de como uma A única forma de validar uma nova testes, executar todas as funcionalidades
organização deve estar aberta a ampliar versão do sistema de auto-atendimento mapeadas, coletar evidências dos testes e
seus custos operacionais, em troca de compartilhado era exercitando o maior compará-las a “baselines” já aprovados,
significativas vantagens no controle e número de funcionalidades, incluindo as identificando automaticamente todas as
agilidade de seus processos, permitindo pré-existentes, possibilitando comprovar não-conformidades.
gerenciar mais projetos e informações quais transações estão ou não em confor- Apesar da nova arquitetura de testes
no longo prazo. midade com os requisitos contratados. ser muito mais eficiente, ela traz uma
Neste exemplo, temos a área de TI de Porém, todos os testes eram feitos direta- carga de complexidade adicional que
uma importante empresa brasileira, que mente na máquina ATM (passar o cartão, impacta diretamente no aumento dos
possuía um gargalo operacional em seu digitar a senha, sacar o dinheiro, retirar o custos operacionais do processo de
processo de testes e homologação nas suas comprovante), o que tornava a realização testes e homologação. Foi necessário
máquinas de auto-atendimento (ATMs). dos testes lenta e sujeita a erros. estabelecer um processo de testes total-
O serviço mais rentável desta empresa Durante todo o período de homolo- mente automatizado e gerenciado por
era oferecer a integração de sua infra- gação do sistema, existia uma contínua ferramentas, num ambiente controlado
estrutura disponível, ampliando a cober- interação entre as áreas de homologação e de alta precisão, igual ao encontrado
tura de auto-atendimento de seus clientes e desenvolvimento, pois os relatos de num ambiente industrial.

Antes, os testes eram executados Aumentar o quadro de profissionais é pelos executivos com muito entusiasmo,
manualmente por profissionais que apenas uma forma simplista de aumen- uma vez que se trata de uma fonte reno-
necessitavam passar dias em pé, diante tar o volume de produção, colocando vada de recursos financeiros.
de máquinas para executar um número mais profissionais para executar mais Como a área de negócios é avaliada de
reduzido de casos de testes (400/dia). atividades sem nenhum compromisso acordo com o volume financeiro envol-
Agora, uma única pessoa conseguiria no aperfeiçoamento operacional. vido em cada contrato negociado, suas
gerenciar facilmente 4.000 testes por Recomenda-se não ampliar o quadro metas internas direcionam seus profis-
dia, além de trabalhar com um processo de profissionais em ambientes com sionais a buscarem novas oportunidades
totalmente controlado, padronizado e baixa produtividade, pois além de um e ampliarem seu mercado de atuação,
confiável. O prazo de homologação caiu péssimo negócio, premia as áreas com mantendo uma perfeita sintonia com a
pela metade e o nível de cobertura dos menor eficiência e penaliza as áreas que estratégia corporativa de ampliação das
testes subiu para mais de 20 vezes. buscaram melhorar seu desempenho receitas financeiras.
Foram incorporados à estrutura ope- operacional. Este é um dos erros mais Na contramão desta tendência, a área
racional da TI novos elementos como clássicos que podemos observar nas de TI recebe este novo contrato com um
simuladores e ferramentas de automa- organizações e demonstra uma total peso adicional à sua estrutura-fixa, pois
ção, que possuem custos de manuten- ausência de mecanismos de controle e será mais um projeto a ser somado a ou-
ção e licenciamento que encareceram a aferição do desempenho operacional. tras dezenas em andamento. Mesmo os
área de testes e homologação. Também profissionais de TI tendo consciência de
foram necessários investimentos de Entendendo o Conflito entre que mais projetos negociados significam
consultoria para possibilitar incorporar Negócios e TI mais recursos financeiros para toda a
conhecimentos e técnicas desconhecidas Com o aumento da dependência tecno- empresa, eles entendem que deverão
como automação e arquiteturas de testes lógica dos negócios, a organização tende arcar com toda a responsabilidade pelas
baseadas em simuladores e processos a perceber a área de TI como um bem novas entregas.
automatizados. comum corporativo, que pode ser ampla- Como os executivos de TI possuem
Apesar dos custos totais tornarem-se mente acionado, sem restrições, uma vez uma estrutura fixa de recursos (humana
mais altos, as inovações reduziram as que sua estrutura de profissionais, ferra- e financeira), eles têm consciência de
restrições operacionais e deram um novo mentas e tecnologias estão à disposição sua capacidade de produção limitada.
fôlego organizacional. Atingir este mesmo da empresa. Este comportamento faz com Mesmo com a possibilidade de acionar
patamar de qualidade, empregando o que a estrutura TI seja paga na forma de empresas terceirizadas, será a própria TI
modelo operacional de testes anterior, tor- custo-fixo, sem levar em consideração a que deverá negociar este “aumento de
naria os custos proibitivos, inviabilizando fonte geradora das solicitações. custos”, o que pode gerar alguns meses
sua implantação. Por isto, a melhor forma No modelo tradicional, as áreas que de análise e justificativas, até que venha
de avaliar os resultados de uma inovação acionam a TI não contabilizam os custos a aprovação da diretoria.
é comparando os resultados alcançados quando consomem os serviços, caracte- Como a área de negócios pode acionar
analisando os custos unitários - ou seja, rizando como “algo grátis” oferecido infinitamente a área de TI, temos esta
produzir um novo teste estava agora muito pela organização. Desta forma, quem situação de forma recorrente dentro
mais barato, o que permitiu a área ampliar paga pelos projetos TI são todas as áreas, das organizações, onde novos contratos
em 20 vezes sua cobertura de testes. quando na verdade deveria ser apenas a passam a concorrer com o andamento
Este exemplo demonstra como as ino- área solicitante. dos demais projetos já existentes.
vações podem acarretar no aumento dos Porém, percebemos que encarar a TI Trata-se de uma inconsistência do
custos operacionais, sendo necessário como um custo-fixo organizacional atual modelo de relacionamento, pois
sempre avaliar as vantagens competiti- impossibilita nosso entendimento so- a TI deveria ter uma estrutura finan-
vas que a organização obterá com este bre a real natureza de seus custos. Isto ceira variável, que possibilita imediata
investimento, atacando as principais res- gera uma inconsistência no sistema de adequação às flutuações de demandas,
trições operacionais que comprometem gerenciamento dos custos operacio- sem a necessidade de aprovações finan-
a qualidade e desempenho dos serviços nais da empresa, uma vez que as áreas ceiras de executivos e dos acionistas da
disponibilizados. solicitantes recebem os serviços da TI organização.
Também demonstra que aumentar cus- gratuitamente. O atual modelo de gestão torna a orga-
tos operacionais não significa necessa- nização muito vulnerável às variações
riamente ampliar o quadro de profissio- O Modelo de Relacionamento como de demandas, que podem acontecer a
nais. Na verdade, as inovações buscam Explicação do Conflito qualquer momento, com a negociação e
sempre aumentar a produtividade, atra- Cada novo contrato de prestação de ser- fechamento de novos contratos.
vés da implementação de ferramentas, viços estabelece uma nova relação Clien- A cultura da TI como um “serviço
técnicas e metodologias que ampliam a te-Fornecedor entre nossa organização e grátis” leva inevitavelmente à “cultura
capacidade dos profissionais. o mercado. Este novo contrato é recebido do desperdício”, pois incentiva as áreas

Gestão de ti
de negócios a demandarem serviços

que espelham mais “desejos” do que Serviços Prestados
propriamente “necessidades”, o que

Empresa Empresa
significa que muitas das solicitações A Pagamento nas Entregas B
podem gerar pouco retorno financeiro
A A
para a organização.
Existe uma frase muito conhecida
Figura 4. Relação Cliente-Fornecedor empregado entre Empresas
e citada no mundo da administração
chamada “não existe almoço-grátis”,
onde reforça exatamente que qualquer e cliente” os conduziram inconsciente- possibilitando que flutuações de deman-
esforço produz um custo e este deverá mente para esta situação. Comparando das do Cliente sejam automaticamente
ser repassado, numa analogia direta aos os grupos de controle, fica fácil eviden- repassadas ao Fornecedor de serviços.
modelos de gestão de Custos ABC e mo- ciar que o modelo de relacionamento
delos equivalentes de gestão de custos. pode gerar maior ou menor nível de Classificando os Modelos de
Talvez a forma mais simples de apre- desperdício, mesmo que de forma in- Relacionamento
sentar a natureza de conflito entre as voluntária e inconsciente. Ao compararmos a dinâmica de rela-
áreas de Negócios e TI seja demonstrar cionamento entre empresas, com a di-
como o modelo de relacionamento pode A Dinâmica de um Relacionamento nâmica entre as áreas de Negócios e TI,
gerar comportamentos indesejáveis e Equilibrado observamos que alguns fundamentos da
prejudiciais à organização. Podemos descrever a dinâmica do relação Cliente-Fornecedor não são res-
Para exemplificar a chamada “cultura mercado como uma relação de trocas peitados – a remuneração proporcional
do desperdício”, podemos realizar um contínuas entre empresas que buscam ao serviço executado.
pequeno estudo estatístico, avaliando atender suas necessidades diversas. O A remuneração proporcional (também
dois grupos de controle distintos. No sucesso de uma organização pode ser chamada de variável) é o mecanismo
primeiro grupo, 50 pessoas terão R$ medida pela capacidade de atender que equilibra a relação entre as partes,
10,00 para gastar num restaurante onde adequadamente necessidades geradas pois onera o cliente proporcionalmente
é cobrado por quilo, enquanto que outras pelo mercado. à sua exigência, enquanto que o forne-
50 pessoas entrarão no mesmo restauran- Ao atender uma necessidade, a or- cedor receberá de acordo com o serviço
te e pagarão os mesmos R$ 10,00, porém ganização estabelece uma relação de demandado.
poderão consumir tudo o que quiserem troca, fornecendo o serviço requerido Não existindo a proporcionalidade,
(bebida, comida e sobremesa). e sendo adequadamente remunerado as exigências do cliente tendem ao
O resultado deste estudo será sempre o pelo esforço demandado. Para manter infinito, enquanto que a estrutura do
mesmo. O primeiro grupo apesar de ter a competitividade na prestação de ser- fornecedor mantém-se limitada. Este
os mesmos R$ 10,00 para gastar, necessi- viços, as organizações investem mais tipo de relacionamento desequilibrado
tou fazer uma análise de custo-benefício na qualificação de seus profissionais, de é chamado de Patrão-Empregado, pois
e pedir apenas o necessário, otimizando forma a atender cada vez mais o nível lembra os contratos CLT, onde profissio-
sua solicitação e requisitando apenas o de qualidade, produtividade e controle nais recebem um valor fixo no final do
essencial. Após a refeição, as pessoas exigidos pelos clientes. mês, independentemente de seu volume
apresentam-se satisfeitas, pois pediram Neste modelo de relacionamento, as de produção.
tudo que precisavam – em alguns casos empresas possuem um perfeito relacio- Abaixo, aprofundaremos mais sobre as
receberam até o troco. namento, pois possuem um mecanismo características e comportamentos asso-
No segundo grupo, não havia restrições de troca equilibrado. Quanto maior ciados às duas formas de relacionamento
estabelecidas, e as pessoas sentiram-se o volume de projetos solicitados pelo identificadas:
totalmente à vontade em experimentar Cliente, mais recursos financeiros serão
de tudo. Isto ocorre porque as pessoas repassados ao Fornecedor. Aumentar Relacionamento Patrão-Empregado
buscaram maximizar financeiramente o escopo e complexidade das solicita- (Modelo Atual)
seu pedido, ou seja, quanto mais itens ções também irá encarecer o projeto do As relações Patrão-Empregado são
consumiam, maior valor teria seus Cliente, criando um natural mecanismo baseadas no modelo ganha-perde, onde
R$ 10,00. Após a refeição, as pessoas de limitação de exigências para quem independente do volume de serviços
apresentam-se satisfeitas, pois pediram solicita os serviços. prestados pelo empregado, o Patrão re-
tudo que desejavam. Conforme podemos observar na Figura aliza periodicamente pagamentos de va-
Isto demonstra claramente que os 4, o conceito de Gestão de Serviços é lor fixo, em troca apenas da permanente
dois grupos adotaram comportamentos naturalmente adotado entre as em- disponibilidade do Empregado.
diferentes por que o modelo de relacio- presas, exatamente por propiciar uma Na perspectiva do Patrão, a relação mais
namento estabelecido entre “restaurante relação financeira justa e equilibrada, vantajosa será adotar uma estratégia de

maximizar sua capacidade produtiva, Portanto, o Empregado assume inte- Como outras empresas também bus-
criando um ambiente onde o Empregado gralmente o risco de ampliar seu traba- cam ampliar suas receitas financeiras, o
possa produzir cada vez mais, sem que o lho e promover algum tipo de inovação Fornecedor sempre buscará encontrar
preço-fixo estabelecido seja alterado. para a organização. O Patrão define o formas mais eficientes de execução dos
Já na perspectiva do Empregado, a momento da avaliação, estabelecendo serviços prestados. Por iniciativa pró-
relação mais vantajosa será adotar a os critérios que quantificam o valor da pria, o Fornecedor buscará melhorar seu
estratégia de minimizar seu esforço inovação, julgando o mérito ou não da desempenho, implementando sempre
produtivo, exatamente o oposto do recompensa. inovações que agreguem maior valor
que objetiva o Patrão. Neste contexto, aos seus projetos.
o Empregado busca criar um ambiente Relacionamento Cliente-Fornecedor A relação Cliente-Fornecedor é natu-
onde possa produzir o mínimo possível, (Modelo Proposto) ralmente estabelecida entre empresas,
uma vez que sua remuneração já estar As relações Cliente-Fornecedor são exatamente por incorporar uma dinâ-
estabelecida. baseadas no modelo ganha-ganha, mica financeira que oscila em sintonia
Neste tipo de relação, existe um con- onde o volume de serviços prestados é com as demandas de serviços – quanto
flito permanente entre Patrão e Empre- proporcional ao volume financeiro a ser mais serviços forem executados, mais
gado, pois ambos buscam maximizar os repassado, estabelecendo uma relação pessoas são necessárias para realizar
ganhos desta relação. Desta forma, ape- balanceada entre aumento de demanda os projetos, maiores serão os esforços
nas um terá uma relação mais favorável, e readequação da infra-estrutura para e custos envolvidos, maiores serão as
uma vez que o modelo financeiro não é manter os níveis de serviços exigidos. receitas financeiras previstas.
dinâmico, pois não está vinculado aos Neste tipo de relação, o Fornecedor
níveis de serviços estabelecidos. procura continuamente oportunidades Demonstrando os diferentes
Na relação Patrão-Empregado, existe e novos serviços para oferecer ao seu Modelos de Alocação de Custos
sempre a promessa de recompensa fu- Cliente, pois necessita manter-se viável Para que possamos demonstrar como
tura para o bom desempenho, apesar de financeiramente, ampliando seu merca- os modelos de relacionamento influen-
tratar-se sempre de uma análise subjeti- do de atuação e reforçando sua atuação ciam diretamente no modo de alocação
va e não formalizada entre as partes. nos Clientes já conquistados. dos custos, vamos empregar um exemplo
Cenário Hipotético para Estudo de Caso

1) São alocados os custos dos profissionais e infra-estrutura de cada área (2 milhões para Negócios e 20 milhões para TI);
2) A área de negócios recebe uma verba de R$ 20 milhões para atender as demandas do mercado;
3) São negociados 4 projetos com Clientes. Os projetos foram passados à TI e orçados em R$ 18 milhões, pois consumem 90%
de toda infra-estrutura da área – trata-se de uma operação de rateio de custos convencional.
4) A TI contrata um projeto de R$ 5 milhões, visando automatizar suas operações e aumentar em 100 % sua produtividade;
5) Os Clientes pagam pelos projetos finalizados – R$ 40 milhões que caem na conta da área de Negócios;
Início Gestão Negócios Gestão TI Consultorias

Semestre #1
Crédito Débito Crédito Débito Crédito Débito
1 (2) $ 20.000,00 (1) $ 2.000,00 (3) $ 18.000,00 (1) $ 20.000,00 - (4) $ 5.000,00
Provisão (5) $ 40.000,00 (3) $ 18.000,00 (4) $ 5.000,00
Salários
2
Verba 3
Vendas Solicitação 4
4 Projetos Projeto
5 Inovação
Pagamento
4 Projetos
Término
Semestre #1 $ 60.000,00 $ 20.000,00 $ 18.000,00 $ 25.000,00 - $ 5.000,00
Figura 5. Cenário Inicial para análise do comportamento da Alocação dos Custos de TI

Gestão de ti
de uma empresa que oferece serviços ao

mercado e necessita da área de TI para
atender seus Clientes. Início Gestão Negócios Gestão TI
Na Figura 5, descrevemos um cenário Semestre #2
Crédito Débito Crédito Débito
que permitirá estabelecer uma base 1
Provisão (2) $ 20.000,00 (1) $ 2.000,00 (3) $ 18.000,00 (1) $ 20.000,00
inicial financeira e compará-la com os Salários (5) $ 80.000,00 (3) $ 18.000,00
demais modelos existentes, possibili-
2
tando analisar como um inadequado Verba 3
modelo de alocação de custos pode Vendas Solicitação
8 Projetos
prejudicar a análise financeira das áreas
da organização. 4
Pagamento
Com este cenário estabelecido, vamos 8 Projetos
simular um 2º. semestre empregando as
duas diferentes abordagens de alocação Término
Semestre #2 $ 80.000,00 - - $ 2.000,00
de custos, porém respeitando as seguin-
tes premissas: Rentabilidade Financeira
• Custos Operacionais das áreas per- R$ 78.000,00
manecem inalterados;
• Ve r b a de Ve nd a s p e r m a n e c e Figura 6. Alocação de Custos TI no modelo Tradicional
inalterada;
• A Produtividade da TI aumenta em
100% (projeto de inovação); ser apenas uma fonte de rateio para a Desta forma, os serviços de TI continu-
• Projetos Contratados saltam de 4 para área de negócios. am sendo cobrados de forma fixa pelos
8 no novo semestre; Na Figura 6, é fácil perceber que os seus serviços executados, independente-
• Projetos são equivalentes na comple- ganhos de produtividade da TI não mente do aumento dos custos internos ou
xidade dos anteriormente contratados. foram contabilizados em seu centro de das variações de produtividade da área.
custo, mas sim repassados diretamente O exemplo da Figura 7 demonstra
Dinâmica de Alocação de Custos no Modelo ao centro de custos da área de negócios, como é possível gerenciar a relação
Tradicional distorcendo a rentabilidade de um Cliente-Fornecedor empregando este
No modelo tradicional, a TI é encarada produto ou serviço oferecido pela orga- modelo, transformando as áreas da
como um “custo-fixo operacional” e ser- nização, o que pode acarretar prejuízos empresa em centros de custos inde-
ve apenas como critério de rateio para as significativos em relação à análise e pendentes. A alocação das receitas e
unidades de negócio existentes e auxiliar formação de preços no mercado. das despesas operacionais permite aos
na composição dos custos dos serviços executivos acompanharem mais facil-
oferecidos ao mercado. Alocação de Custos no Modelo Proposto mente a dinâmica de troca de serviços,
Apesar do conceito deste modelo ser No modelo proposto, a TI deixa de ser possibilitando identificar áreas com
atrativamente simples, ele gera uma encarada como um “custo-fixo operacio- maior volume de solicitações e melhor
grave inconsistência dos custos opera- nal” e passa a desempenhar um papel rentabilidade.
cionais, dificultando identificar quais ativo dentro da estrutura financeira Os gerentes das áreas passam a ad-
áreas estão sendo mais produtivas – a organizacional. Seu centro de custos ministrar seus centros de custos como
TI ou a área de Negócios. passa a absorver todos os ganhos de pro- se fossem executivos de empresas,
O problema está no fato de que o custo dutividade, evidenciando os benefícios possibilitando negociar adiantamentos,
do serviço está sendo contabilizado de que investimentos em TI podem gerar prêmios de produtividade, punições em
acordo com o nível de esforço e não por no desempenho da organização. atrasos ou quebras de contrato, reembol-
sua produção. Como a produtividade da Para entender a precificação dos ser- so por falhas na prestação de serviço e
área de TI aumentou em 100%, executar viços da TI foi estabelecido, devemos diversos outros mecanismos contratuais,
o dobro dos projetos continua consumin- lembrar dos 4 projetos repassados pela possíveis apenas quando operamos en-
do os mesmos 90% da estrutura interna TI no 1º semestre, que custaram para a tre empresas.
da área, mantendo-se em R$ 18 milhões área de negócios R$ 18 milhões.
o custo interno da TI. Isto equivale a dizer que qualquer projeto Integrando o Modelo com o
Isto significa que apesar de sua luta TI, com nível de complexidade semelhante, Planejamento Estratégico
contínua para aperfeiçoar a qualidade custaria para a área de negócios R$ 4,5 mi- Todas as empresas deveriam organizar
e produtividade de seus projetos, a lhões. Como foram contratados 8 projetos periodicamente o Planejamento Estraté-
área de TI sempre será contabilizada de simultaneamente, o custo foi proporcional gico Corporativo visando definir quais
forma negativa (custo-fixo), pois deverá ao serviço solicitado – R$ 36 milhões. serão as metas corporativas (financeiras

e operacionais) a serem alcançadas pela
organização num determinado prazo
Início Gestão Negócios Gestão TI estabelecido.
Semestre #2
Na Figura 8 podemos ver como o
Crédito Débito Crédito Débito
1 Planejamento Estratégico deixa claro
Provisão (2) $ 20.000,00 (1) $ 2.000,00 (3) $ 36.000,00 (1) $ 20.000,00
Salários (5) $ 80.000,00 (3) $ 36.000,00 para todos da organização quais são as
metas planejadas e qual será o montante
2
Verba 3 financeiro que a empresa está disposta a
Vendas Solicitação investir para alcançar este objetivo.
8 Projetos
Uma vez estabelecido o Planejamento
4 Estratégico, este deverá ser desmem-
Pagamento
8 Projetos brado em planos mais detalhados
(Planejamento Tático e Operacional)
Término até que consigamos visualizar todos os
Semestre #2 $ 62.000,00 - $ 16.000,00 -
projetos e distribuí-los para todas as
Rentabilidade Financeira áreas operacionais, visando criar um
R$ 78.000,00 alto grau de colaboração de todos para
o cumprimento das metas. A previsão
de uma premiação reforça a idéia de que
Figura 7. Alocação de Custos TI no modelo Proposto
todos ganham atingindo os objetivos
da empresa.
Com o planejamento financeiro esta-
belecido, sabemos quais são as verbas
Meta #1 Meta #2 Meta #3 disponibilizadas para cada área de ne-
Manter em 90 % os Aumentar em 30% o Reduzir em 15% os
gócio existente, podendo estabelecer o
atuais serviços de auto- volume de projetos de custos operacionais de
atendimento auto-atendimento qualquer natureza limite de gastos operacionais (internos
ou externos) para atingir determinada
R$ 250 milhões R$ 75 milhões R$ 18 milhões
meta organizacional. Cada vez que um
serviço é solicitado, o valor do serviço é
Previsão para Previsão para Previsão para
debitado da área-cliente e creditado na
Manutenção Evolução Investimento área-fornecedora.
Legado Legado Legado
Neste cenário, a área de negócios
deverá avaliar bem, antes de solicitar
qualquer serviço para a TI, pois sua
Orçamento #1 Orçamento Orçamento
R$ 120 milhões R$ 50 milhões R$ 35 milhões premiação não dependerá apenas da
meta corporativa alcançada (modelo
Premiação Premiação Premiação tradicional), mas no desempenho finan-
ceiro de sua área (custos realizados para
Bônus Bônus Bônus alcançar a meta).
R$ 10 milhões R$ 10 milhões R$ 15 milhões Na verdade, todas as áreas passam a
ser avaliadas pelo fluxo financeiro de
Figura 8. Exemplo de Planejamento Estratégico baseado em Metas e Orçamentos pré-definidos entradas e saídas gerados pelas trocas
de serviços. Será como trazer a dinâ-
mica das empresas para dentro da
organização.
Manutenção do Legado Identificando a Natureza dos

Serviços de TI
Estrutura Estrutura Por maiores que sejam os investimen-
Negócios Evolução do Legado TI
tos corporativos em processos, meto-
A A dologias, profissionais, treinamento,
Inovação da TI ferramentas e consultorias, o perfil de
relacionamento entre as áreas torna-se
o principal freio na produtividade e
Figura 9. Natureza de Serviços de TI
inovação empresarial, gerando enorme

Gestão de ti
impacto nos resultados corporativos. vigência anual (Manutenção de Equipa- incluindo todas as modificações tec-
Todas as organizações que desejam mentos, Monitoração de Redes, Suporte nológicas, reestruturação de sistemas,
alcançar maior agilidade e controle Técnico e Problemas de Produção). Seu incorporação de novas técnicas, inserção
operacional deveriam escolher modelos objetivo será englobar custos perma- de novos procedimentos de controle
de relacionamento mais equilibrados e nentes e cobrar anualmente por estes operacional, adequações metodológi-
voltados à inovação, de forma a garantir serviços prestados, sendo o valor a ser cas, auditorias internas, treinamento e
o melhor desempenho e qualidade nos pago ajustado diretamente pelas os- capacitação profissional, entre outras
serviços disponibilizados. Com isto, cilações de indicadores como nível de demandas.
torna-se necessário institucionalizar disponibilidade dos serviços e volume No modelo tradicional, os projetos
a relação Cliente-Fornecedor entre as de transações. de inovação da TI são negociados e
áreas de Negócios e TI, de forma a ge- Para os custos eventuais (Homologa- priorizados em conjunto com as demais
renciarmos a área de TI como se fosse ção de Produtos e Novos Clientes), os demandas da organização, concorrendo
uma empresa independente. projetos devem ser negociados conforme com projetos das áreas de negócio, que
Com a possibilidade de cobrar pelos a natureza e complexidade do serviço, são claramente mais importantes que as
serviços prestados às áreas de negócio, sempre cobrando da área de negócio o necessidades da TI, sobrando pouco para
a TI tem a oportunidade de atuar como serviço prestado. discutir sobre o aperfeiçoamento da TI.
um centro de lucros, possibilitando até No modelo proposto, o Plano de Ino-
gerar um superávit e financiar seus Evolução do Legado vação da TI será financiado tanto pela
próprios projetos de inovação, sem de- Trata-se de todos os custos de TI vol- organização, que prevê um volume de
pender da disponibilidade financeira da tados única e exclusivamente para mo- investimentos para inovações, quanto
organização. dificar ou ampliar as funcionalidades pelo superávit operacional da TI, pos-
Como podemos observar na Figura dos sistemas legados, incluindo todo e sibilitando que a mesma fique compro-
9, existem três tipos diferenciados de qualquer tipo de modificação de layout, metida com o aumento da produtividade
serviços que deverão ser contabilizados inserção de novos campos e consistên- e melhorias, incorporando apenas os
e controlados de forma independente cias de negócios, novas telas e transa- custos realmente necessários.
dentro da TI. ções comerciais, ajustes tributários ou Com o superávit operacional, a TI po-
financeiros provenientes de adequações derá promover e elaborar programas de
Manutenção do Legado legais, correção de “bugs”, confecção de incentivos financeiros totalmente apar-
Trata-se do somatório de todos os cus- relatórios, automação de processos, entre tados das demais áreas corporativas,
tos de TI voltados única e exclusivamen- outras solicitações. criando metas e políticas de incentivo
te para manter a estrutura tecnológica Normalmente, a área de Negócios próprias à sua realidade, reforçando o
em funcionamento, incluindo todas as preocupa-se apenas com estes tipos nível de autonomia e responsabilidade
atividades relacionadas à monitoração de projetos, pois entendem que estes financeira dado a profissionais e execu-
dos ambientes de produção, manutenção irão agregar melhorias e inovações aos tivos da TI.
corretiva e preventiva dos sistemas de produtos e serviços oferecidos pela orga-
comunicação e infra-estrutura, apoio nização, gerando mais oportunidades de Impacto da Gestão de Serviços nas
tecnológico a clientes e fornecedores vendas e comercialização dos mesmos. Áreas Operacionais
que compartilham o sistema de infor- Inconscientemente, a área de Negócios A Gestão de Serviços Operacionais
mações da empresa, homologação de acredita que toda estrutura de TI está é uma modalidade de gestão baseada
novos produtos e serviços de clientes focada exclusivamente para atender este no desempenho financeiro das áreas
que desejam ser incorporados ao atual tipo de demanda. operacionais, possibilitando equilibrar
sistema legado. A área de Negócios negligencia os automaticamente os recursos empre-
A principal característica do custo de projetos de Manutenção do Legado, pois sariais de acordo com a alocação dinâ-
manutenção do legado é ser acumulati- acredita que seja uma obrigação da TI mica financeira gerada pelas trocas de
vo. À medida que a empresa cresce, toda manter esta estrutura em perfeito fun- serviços.
a estrutura legada suportada pela TI cionamento, mesmo que o sistema lega- Este conceito é uma adaptação do
aumenta com os anos. Muitas empresas do exista exclusivamente para viabilizar modelo de custeio por atividades
ainda são oneradas por terem que manter as transações comerciais que beneficiam (Custo ABC) aplicada nas industriais
estruturas antiquadas de processamento diretamente a área de negócios. e uma evolução do modelo de Gestão
(mainframe) e tecnologias ultrapassadas de Centros de Custos, para o de Gestão
(Unix, OS-2, DOS), ampliando mais os Inovação da TI de Centros de Lucros. Neste modelo,
custos do legado. Trata-se de todos os custos de TI volta- evitamos a aplicação do rateio e transfor-
A melhor forma de lembrar a área de dos única e exclusivamente para renovar marmos as áreas em centros financeiros
Negócios da existência deste custo reas técnicas, processos e tecnologias a independentes, podendo gerar lucro ou
corrente é estabelecer alguns projetos de serem empregadas nos futuros projetos, prejuízo.

A Gestão de Serviços Operacionais restrições sistêmicas corporativas, ou Neste modelo, os próprios profissionais
empregam métricas para estabelecer a seja, não afeta diretamente a “corrente buscam manter uma estrutura compatível
tabela de preços referentes aos serviços crítica” da organização. e balanceada com a realidade das deman-
prestados (transações dia, pontos de O indicador financeiro é tão eficiente das de serviços. Ter muitos profissionais
função, casos de testes, scripts automa- como mecanismo de avaliação que provoca aumento dos custos operacionais
tizados, eventos de negócio, ou outros disciplina tanto as áreas que conso- e inviabiliza aumentos salariais e bonifi-
indicadores que possam dimensionar o mem quanto aquelas que fornecem os cações. Ter poucos profissionais impede o
volume do serviço a ser executado). serviços. total atendimento dos serviços solicitados
Porém, a avaliação das áreas opera- e restringem as receitas operacionais.
cionais ocorre apenas com um único Disciplina quem consome os serviços
indicador financeiro, a lucratividade No modelo tradicional, todas as re- Conclusão
local, gerada pela diferença entre as quisições de serviços eram gratuitas, Para suportar o maior nível de exi-
receitas e despesas produzidas. Desta o que não exige nenhuma contrapartida gência e profissionalismo, a área de TI
forma, existe uma total transparência do financeira ao centro de custo solicitante, deve deixar de ser encarada como uma
mecanismo de avaliação do desempenho não exigindo dos gerentes de áreas uma simples área de apoio para tornar-se efe-
das áreas, sendo facilmente entendido e preocupação com o melhor aproveita- tivamente uma área estratégica dentro
acompanhado pelos profissionais, requi- mento dos serviços prestados. das organizações.
sito fundamental para garantir o enga- Neste modelo, cada área solicitante Para isto, a área de TI deverá adotar
jamento de todos na busca da eficiência passa a avaliar mais criteriosamente o padrões de governança mais ade-
corporativa. A transparência do modelo que pede, estabelecendo sempre uma quados à sua dinâmica operacional,
revela as áreas que estão sendo mais relação custo-benefício e administrando livrar-se do tradicional orçamento fixo
focadas no aumento da produtividade e o saldo de investimentos que sua área e remunerar-se de acordo com o volume
redução de custos operacionais. ainda possui, alinhando suas requisi- de solicitações requeridas pelas áreas
Para exemplificar, quando a TI melhora ções às metas corporativas. de negócio, deixando de lado a relação
sua produtividade, ela tem maiores con- Este modelo inibe as solicitações patrão-empregado e apostar na relação
dições de atender mais solicitações sem desnecessárias, evitando que tempos e cliente-fornecedor.
aumentar seus custos internos, o que cria recursos sejam alocados para realizar A solução aqui proposta é transfor-
um superávit financeiro no seu Centro projetos que geram pouco ou nenhum mar a área de TI como uma “empresa
de Custo, o que seria um bom sinal de valor agregado, afetando diretamente independente” e adotar o conceito de
desempenho. Da mesma forma, a área a rentabilidade corporativa. Afinal, não “Fábrica de Serviços”, cobrando por todo
de TI poderia ter optado pela decisão existe esforço sem custo financeiro. e qualquer acionamento e atendendo da
mais simples, de aumentar a capacida- forma mais rápida e controlada possível.
de de produção através da contração Disciplina quem executa os serviços Desta maneira, mesmo sendo uma área
de terceiros ou aumento do quadro de Ao contrário do modelo tradicional, interna da organização, ela terá o mes-
funcionários, gerando um aumento de todos os gerentes administram suas mo comportamento de uma estrutura
seus custos internos. áreas como se fossem empresas, tendo terceirizada, remunerada pelo volume
Portanto, este modelo revela as conse- um interesse real em tornar seu centro de solicitações demandadas.
qüências financeiras das decisões das li- de custo rentável, trabalhando na forma Desta forma, a área de TI passa a ter
deranças, quando focam exclusivamente mais rápida, eficiente e econômica pos- não apenas condições de adaptar-se com
no aumento da produção (curto-prazo), sível, sem desperdícios. eventuais oscilações de demanda de ser-
quando deveriam focar no aumento da Assim, cada área buscará novas formas viços, mas garantir as inovações internas
produtividade (longo-prazo). de ampliar suas receitas com o objetivo necessárias para suportar os futuros
Não adianta melhorarmos os indica- de bancar sua infra-estrutura, cursos de projetos da organização, investindo
dores (atender mais solicitações) sem aperfeiçoamento, salários, bonificações, no aperfeiçoamento e controle de seus
que consigamos melhorar nosso desem- aquisições e licenciamento de ferramentas processos de manutenção e evolução
penho financeiro. Isto evita que sejam e outras despesas que podem gerar impac- dos sistemas, trazendo maior vantagem
feitos investimentos que não ataquem as to direto na produtividade da área. competitiva a toda organização.

AMIGO
...só pra lembrar,
Existem coisas sua assinatura pode
estar acabando!
que não
conseguimos
ficar sem!
Renove Já!
www.devmedia.com.br/renovacao
Para mais informações:
www.devmedia.com.br/central

ES 05 Usabilidade de Software PDF

Enviado por

Direitos autorais:

Formatos disponíveis

ES 05 Usabilidade de Software PDF

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ES 05 Usabilidade de Software PDF

Enviado por

Direitos autorais:

Formatos disponíveis

ISSN 1983127-7

9 771983 127008 00005

Capa ESM - Final .pdf 19.02.08 18:15:13

Verificação, Validação & Teste

Faça já sua assinatura digital! | www.devmedia.com.br/es

Faça um up grade em sua carreira.

Desejamos uma ótima leitura!

Atendimento ao Leitor Rodrigo Oliveira Spínola

36 - Cuidados na Aplicação da Análise de Pontos de Função

42 - Melhores Práticas na Automação de Testes

48 - Modelagem de Processos de Negócio com Uso do NetBeans

56 - Gestão de Serviços Operacionais Aplicada à TI

4 Engenharia de Software Magazine

Profissionais com ampla experiência prática (Consusltores Certificados) e

Know-how para implementar processos de software de acordo com modelos

Cursos 2008: Inscrições Abertas Certificados emitidos pela Kali Software

Outubro | Novembro Testes de Software – 16 horas

Outubro | Novembro Projeto Orientado a Objetos com UML e Padrões – 24 horas

Novembro Engenharia de Requisitos – 24 horas

De que se trata o artigo?

6 Engenharia de Software Magazine - Extreme Programming

Edição 05 - Engenharia de Software Magazine 7

8 Engenharia de Software Magazine - Extreme Programming

Edição 05 - Engenharia de Software Magazine 9

DSOA Identificação de Imaturidade de Depuração em Inversão de

10 Engenharia de Software Magazine - Extreme Programming

É possível perceber, através da análise

Edição 05 - Engenharia de Software Magazine 11

12 Engenharia de Software Magazine - Extreme Programming

Disponível em 3 versões, o IBM Rational Team

Para mais informações, entre em

Tel: (21) 2512-6005

De que se trata o artigo?

14 Engenharia de Software Magazine - Especificação de Requisitos com Casos de Uso

Nota 1. Requisito Funcional

São requisitos diretamente ligados a

Edição 05 - Engenharia de Software Magazine 15

16 Engenharia de Software Magazine - Especificação de Requisitos com Casos de Uso

Figura 5. Tela 2 do caso de uso UC 2 – Consultar Projeto

2. O ator escolhe a opção Incluir Novo Cliente [A1][A2]

4. O Ator preenche o formulário apresentado

Tabela 3 (parte1). Especificação do caso de uso UC 1 – Administrar Clientes.

Edição 05 - Engenharia de Software Magazine 17

18 Engenharia de Software Magazine - Especificação de Requisitos com Casos de Uso

Figura 6. Tela 2 do caso de uso UC 2 – Consultar Projeto

Figura 7. Tela 1 do caso de uso UC 3 – Listar Projetos a Vencer

1. O Sistema apresenta as seguintes opções para visualização dos projetos [RN1]:

Tabela 4 (parte1). Especificação do caso de uso UC 2 – Consultar Projeto.

Edição 05 - Engenharia de Software Magazine 19

7. O Sistema apresenta ao final do formulário a opção voltar

20 Engenharia de Software Magazine - Especificação de Requisitos com Casos de Uso

UC 1 Ð Listar Projetos a Vencer

Figura 8. Tela 1 do caso de uso UC 4 – Listar Propostas de Projeto Criadas.

Edição 05 - Engenharia de Software Magazine 21

UC 1 Ð Listar Propostas de Projeto Criadas

22 Engenharia de Software Magazine - Especificação de Requisitos com Casos de Uso

De que se trata o artigo?

24 Engenharia de Software Magazine - Usabilidade de Software