Es22 - MPSBR

Modstia parte, sua melhor opo para se destacar no mercado!
A Escola Superior da Tecnologia da Informao oferece as melhores opes em cursos, formaes, graduaes e ps-graduaes para profissionais de desenvolvimento e programao. So programas voltados para a formao de profissionais de elite, com aulas 100% prticas, corpo docente atuante no mercado, acesso mais atualizada biblioteca de TI do Rio, laboratrios equipados com tecnologia de ponta, salas de estudo e exames.
PS- GRADUAO
Engenharia de Software: Desenvolvimento Java Engenharia de Software: Desenvolvimento .NET

GRADUAO
Engenharia de Computao Anlise e Desenv. de Sistemas

F ORMAES
Desenvolvedor Java Desenv. Java: Sist. Distribudos Gestor de TI Desenvolvedor Web .NET 2008 MCITP Server Administrator SQL Server 2008
r/esti Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti

TURMAS NO RIO DE JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
EDUCAO SUPERIOR ORIENTADA AO MERCADO
H
Ano 2 - 22 Edio - 2010 Impresso no Brasil
EDITORIAL
oje no Brasil, mais de 100 empresas foram avaliadas com sucesso no modelo MPS.BR, e estas avaliaes, mesmos para os nveis menos complexos, podem ser extremamente difceis. Neste cenrio, a Engenharia de Software Magazine
destaca nesta edio uma matria que descreve as experincias prticas de uma instituio na implementao do modelo. Alm disso, desde 1 de Janeiro de 2010 as avaliaes MPS esto seguindo somente o modelo de referncia MR-MPS: 2009. Por este motivo, organizaes que esto implementando o modelo para a futura avaliao ou reavaliao devem levar em considera-
Corpo Editorial
Colaboradores Rodrigo Oliveira Spnola rodrigo@sqlmagazine.com.br Marco Antnio Pereira Arajo Eduardo Oliveira Spnola Capa Romulo Araujo - romulo@devmedia.com.br Diagramao Janete Feitosa Coordenao Geral Daniella Costa - daniella@devmedia.com.br Revisor e Supervisor Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br Na Web www.devmedia.com.br/esmag
Apoio
o as mudanas dos guias da verso 1.2 para a verso 2009, pois isto pode ser decisivo para o sucesso de uma avaliao MPS. Alm das avaliaes, importante lembrar que os guias descrevem requisitos e condies para quem quer se tornar um avaliador adjunto, avaliador lder ou consultor de Aquisio MPS, tambm apresenta orientaes para criao de novas Instituies Implementadoras (II) e Instituies Avaliadoras (IA). Por conta disto, destacamos tambm nesta edio as principais mudanas ocorridas nos guias do modelo MPS verso 2009, alm de apresentarmos os novos guias que descrevem orientaes para organizaes que realizam atividades especficas do processo de software. Por fim, apresentamos atravs do artigo Experincias da Domnio Informtica na Implantao do MPS.BR, a experincia da Domnio Informtica com a definio e implementao dos seus processos de desenvolvimento de software, aderentes ao modelo de maturidade MPS.BR. Alm destas trs matrias, esta edio traz mais cinco artigos: Experincia em automao de testes ITIL: Por onde comear? Arquitetura Orientada a Servios Arquitetura de Software Gerenciamento de Defeitos em Projetos de Software Desejamos uma tima leitura! Equipe Editorial Engenharia de Software Magazine
Atendimento ao Leitor A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se voc tiver algum problema no recebimento do seu exemplar ou precisar de algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de jornal, entre outros, entre em contato com:
Cristiany Queirz Atendimento ao Leitor www.devmedia.com.br/mancad
(21) 2220-5338
Rodrigo Oliveira Spnola

rodrigo@sqlmagazine.com.br Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo ministrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementao do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.
Kaline Dolabella Gerente de Marketing e Atendimento kalined@terra.com.br

(21) 2220-5338
Marco Antnio Pereira Arajo

(maraujo@devmedia.com.br) Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.
Publicidade Para informaes sobre veiculao de anncio na revista ou no site entre em contato com:
Kaline Dolabella publicidade@devmedia.com.br
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para entrar em contato com os editores e dar a sua sugesto! Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine, entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria de publicar: Rodrigo Oliveira Spnola - Colaborador editor@sqlmagazine.com.br
Eduardo Oliveira Spnola

(eduspinola@gmail.com) Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).
Caro Leitor,
Para esta edio, temos um conjunto de 4 vdeo aulas. Estas vdeo aulas esto disponveis para download no Portal da Engenharia de Software Magazine e certamente traro uma significativa contribuio para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
Tipo: Requisitos Ttulo: Diagrama de Casos de Uso na Prtica Partes 8 e 9 Autor: Rodrigo Oliveira Spnola Mini-Resumo: Estas aulas so parte de uma srie sobre a construo de diagrama de casos de uso da UML. O objetivo do conjunto de aulas apresentar de forma prtica como elaborar o diagrama de casos de uso a partir de diferentes estudos de caso. Nestas aulas, sero elaborados diversos diagramas de casos de uso. Tambm ser visto como especificar um caso de uso para um dos diagramas elaborados. Tipo: Validao, Verificao & Teste Ttulo: Introduo a Testes de Software Partes 1 e 2 Autor: Arilo Cludio Dias Neto Mini-Resumo: Nestas aulas iremos discutir os principais conceitos relacionados s atividades de teste, as principais tcnicas e critrios de teste que podem ser utilizados para verificao ou validao de um produto, assim como exemplos prticos da aplicao de cada tipo de tcnica ou critrio de teste.
NDICE
Abordagens geis de Desenvolvimento 05 - Experincia em automao de testes
Eliane Collins e Luana Lobo
Abordagens Tradicionais de Desenvolvimento 11 - Guias 2009 do MPS.BR: o que mudou?

Davi Viana dos Santos
18 - Fatores crticos de sucesso em programas de melhoria de processo

Geovane Nogueira Lima e Marcos Andr Gomes
23 - ITIL: Por onde comear?

Samuel Diniz Casimiro
30 - Arquitetura Orientada a Servios

Jorge Dias Jr.
36 - Arquitetura de Software
Antonio Mendes da Silva Filho
46 - Experincias da Domnio Informtica na Implantao do MPS.BR

Ticiana da Mota Gentil Parente e Adriano Bessa Albuquerque
Validao, Verificao e Teste 52 - Gerenciamento de Defeitos em Projetos de Software

Jenifer Vieira Toledo, Marcelo Santos Daibert e Marco Antnio Pereira Arajo
Engenharia de Software Magazine
Abordagens geis de Desenvolvimento

Esta seo traz artigos que apresentam como e quando utilizar as diferentes abordagens geis de apoio ao desenvolvimento de projetos de software
Experincia em Automao de Testes

Utilizando ferramentas Open Source em Ambiente gil de Desenvolvimento com SCRUM
De que se trata o artigo?
Neste artigo compartilhamos experincias sobre a automao do processo de teste de um Sistema WEB desenvolvido utilizando SCRUM. Mostramos as vantagens e desvantagens de se adotar esta tcnica de qualidade no ambiente de trabalho.
Para que serve? Eliane Collins

elianecollins@gmail.com
Mestranda de Engenharia eltrica pela Universidade Federal do Amazonas, MBA em Gerenciamento de Projetos e Bacharel em Engenharia de Computao pela Universidade Estadual do Amazonas, 7 anos atuando no desenvolvimento de Software, desses 4 anos em Teste de Software. Trabalha atualmente no Instituto Nokia de Tecnologia INdT, como Pesquisadora, onde lidera uma equipe de teste de software e desenvolve sistemas Web.
Luana Lobo
lulobaum@gmail.com
Atua no ramo de tecnologia e teste de software, formanda no curso de Processamento de Dados.Trabalha atualmente no Instituto Nokia de Tecnologia - INdT, com automao de teste em sistemas desenvolvidos na plataforma WEB e Desktop.
ste artigo descreve de maneira prtica a experincia de se adotar ferramentas de automao de teste no processo de desenvolvimento gil Scrum. Ao se adotar um processo de teste nota-se a melhora, estabilidade e o amadurecimento do software. As vantagens de se automatizar esse processo com ferramentas abertas vo desde o ganho em tempo de teste e preveno de defeitos, at a confiabilidade do cliente pelo produto final, sem o aumento de custos. Mais a frente, neste artigo, veremos que foi possvel automatizar o gerenciamento, a elaborao e a execuo dos casos de testes, em um Sistema Web desenvolvido em Ruby on Rails. As metodologias geis de desenvolvimento de software se destacam dos
A Automao de um Processo de Teste, que tem como objetivo garantir a qualidade de projetos de software, oferece notveis vantagens quando o ambiente de desenvolvimento executado a partir de uma Metodologia gil de desenvolvimento como o Scrum.
Em que situao o tema til?

Alm de ser uma boa prtica para se adotar em processos de teste, a automao de casos de teste garante um aumento na qualidade do software sem elevar o custo para isso. Com o auxlio de solues open source possvel chegar a um nvel satisfatrio de qualidade e confiabilidade do projeto de software.
processos de desenvolvimento tradicionais devido, principalmente, ao fato de darem prioridade ao desenvolvimento de funcionalidades atravs de cdigo
Edio 22 - Engenharia de Software Magazine
executvel ao invs da produo de extensa documentao escrita, e ainda, respostas rpidas s mudanas e colaborao com o cliente ao invs de seguir planos rgidos e negociaes contratuais [Leal (2009)]. To importante quanto o processo de desenvolvimento de um projeto de software, o processo de qualidade envolvido requer planejamento e ateno, visto que garantir a qualidade do software desenvolvido to significante quanto a sua codificao. Assim como a qualidade do produto deve ser alcanada em um meio de desenvolvimento clssico, ela tambm precisa ser levada em considerao nos ambientes geis. Tem sido cada vez mais custoso e desafiador o processo de qualidade nos dois modos de desenvolvimento, seja pela complexidade do produto, por questes tcnicas envolvidas, pelo prprio planejamento equivocado do projeto, e algumas vezes pela falta de um processo estruturado de qualidade e de desenvolvimento. Salvo algumas excees, a maioria das empresas opta por garantir um nvel de qualidade atravs de testes manuais, aps o trmino de mdulos especficos ou at mesmo do sistema inteiro [Bernardo e Kon (2008)]. Isso uma escolha que pode acarretar srios problemas, comprometendo o andamento dos processos de desenvolvimento e teste. Este artigo tem como fundamental objetivo compartilhar uma experincia prtica no uso de automao de testes funcionais em um ambiente de desenvolvimento conduzido pelo SCRUM. No decorrer do artigo mostraremos as notveis vantagens e as dolorosas desvantagens de se adotar tal prtica de qualidade no dia-a-dia de trabalho.
Segurana: fazer testes manuais para garantir que o sistema est seguro contra ataques de terceiros custoso e acarreta um esforo e tempo enorme. Testes de vulnerabilidades tcnicas e lgicas podem ser feitos com mais critrios se forem automatizados com o auxlio de ferramentas; Reusabilidade: scripts de teste, se feitos com planejamento e padronizao, so perfeitamente reusveis na maioria das etapas de desenvolvimento. Portanto, o esforo necessrio para a codificao de scripts de teste, no , na sua totalidade, perdido; Manutenibilidade: sistemas que possuem longa vida no mercado podem ter (em algum momento) que passar por manutenes em reas de cdigo e funcionalidades j testadas. Se a lgica e o requisito no mudaram, os casos de teste que foram automatizados anteriormente podero testar o sistema novamente. Nestes casos, melhor fazer manuteno no caso de teste do que escrev-lo novamente ou execut-lo manualmente. Testes melhores e mais elaborados contribuem para um aumento na qualidade do produto final. Porm, construir uma sute de scripts de teste automticos requer uma padronizao de atividades e conhecimento de codificao e anlise por parte do testador. Para fazer testes automticos eficientes, caso o teste seja de unidade, necessrio entender a arquitetura do software e a base do cdigo. Caso o teste seja de sistema, necessrio conhecer as regras de negcio, as funcionalidades e os valores e situaes permitidas como resultado. Em todos os casos de automao, considerando testes de unidade ou testes de sistema, o esforo necessrio maior. Isso ocorre porque necessrio fazer um planejamento para saber O QU, COMO e POR QUE ser automatizado. S depois disso deve-se passar para a confeco dos scripts automticos. H diversas medidas que podem ser tomadas para se obter testes melhores, mais geis, efetivos e baratos. Dentre estas podemos citar: sistematizar as atividades de testes; definir os papis e responsabilidades vinculadas ao teste; antecipar a preparao dos testes j durante as fases de construo; conhecer as tcnicas relacionadas ao tema; testar caractersticas diferentes do software nas diferentes fases de testes; estimar adequadamente os esforos para os testes; ter um controle efetivo das falhas encontradas; e automatizar os processos de testes, tanto planejamento quanto execuo [Costa (2006)].
Automao de Testes
Automatizar testes significa fazer uso de softwares que controlem a execuo dos casos de teste. O uso desta prtica pode reduzir significativamente o esforo necessrio para os testes em um projeto de software, ou seja, executar maiores quantidades de testes em tempo reduzido. Testes manuais que levariam horas para serem totalmente executados poderiam levar minutos caso fossem automatizados [Tuschling (2008)]. Apesar dos testes manuais tambm encontrarem erros em uma aplicao, um trabalho desgastante que consome muito tempo. Automatizar seus testes significa executar mais testes, com mais critrios, em menos tempo e sem muito esforo na execuo. Sem contar as inmeras possibilidades que um script automtico traz, como: cobertura de requisito e profundidade nos testes, alm de ser efetivo quanto quantidade de dados de entrada que podem ser processadas. As principais vantagens de transformar suas rotinas de testes em scripts automticos so: Extensibilidade: diferente de testes manuais, testes automatizados podem prever inmeros fluxos que ficariam inviveis de se fazer manualmente, contribuindo para maior extensibilidade de testes no sistema; Confiabilidade: testes automticos so mais efetivos na procura de erros que envolvem estruturas de cdigo, como classes, mtodos, etc.;
Tcnicas de Automao
Existem basicamente duas abordagens para se automatizar casos de teste, apesar de no se limitar a elas. A primeira utilizar Ferramentas baseadas em Interface Grfica que possuem capacidade de gravar e executar casos de teste. So as ferramentas conhecidas como rec-and-play (Record and Playback). Nessa abordagem a ferramenta interage diretamente com a aplicao, simulando um usurio real. Na medida em que a aplicao est sendo executada, a ferramenta oferece um suporte de gravao: ela captura as aes e as transforma em scripts. Estes podem ser executados posteriormente. bom frisar que para testes utilizando esta abordagem, o software que ser testado no precisa sofrer alterao alguma.
Engenharia de Software Magazine - Experincia em Automao de Testes
Validao, Verificao e Teste
No h necessidade de modificao, no sentido de padronizar o cdigo, para que a aplicao se torne fcil de testar (testabilidade). Os testes nessa abordagem so baseados na mesma interface grfica que o usurio ir utilizar. O trabalho aqui encontrar uma ferramenta que oferea o recurso necessrio para testar sua aplicao especfica. Existem ferramentas rec-and-play para aplicaes Desktop e Web. A maior desvantagem de se utilizar esta tcnica de automao que o script se torna escravo da interface da aplicao. Para que scripts, utilizando esta abordagem, sejam criados, as ferramentas fazem uso dos nomes e das propriedades dos componentes que esto dispostos na interface da aplicao. Se alguma mudana de posio, nome, tipo do componente, ocorrer, o script quebra, ou seja, no funciona mais. A segunda maneira de se automatizar os casos de teste com o uso de Lgica de Negcio (Script Programming). Neste caso so observadas as funcionalidades da aplicao, sem interagir com a interface grfica. Com esta abordagem sero testadas das maiores at as menores pores do cdigo: funes, mtodos, classes, componentes, entre outros. Geralmente pedido que se faa uma alterao no cdigo para que o trabalho de automao fique fcil. Muitas vezes o cdigo melhorado (Refactoring) e padronizado para que se consiga testar mais facilmente e sem muitos problemas. So necessrios profissionais com conhecimento em cdigo e programao para criar os scripts automatizados. O uso deste mtodo traz muitos benefcios, por exemplo, testes que necessitam de centenas de repeties, clculos complexos e at mesmo integrao entre sistemas so feitos facilmente utilizando esta abordagem. Existem bibliotecas, ferramentas e frameworks que suportam esta abordagem. Bons exemplos so: JUnit, para testar unidade de cdigo Java; FitNesse, que um framework para testes de aceitao; MbUnit, para testar a unidade em cdigos .NET; Nester, para fazer testes de mutao em cdigos C#; httpUnit, para testar aplicaes WEB; Cactus, para testar EJB; jfcUnit e Abbot, para testar aplicaes baseadas em interfaces grficas. Entre estas duas maneiras de se automatizar, o presente artigo tem como base a abordagem rec-and-play. com ela que compartilharemos as experincias, destacando suas vantagens e desvantagens em um projeto web que foi desenvolvido utilizando SCRUM.
atividades de desenvolvimento (Sprint). Geralmente empregado um perodo de duas semanas ou um ms para a iterao. Ao final de cada iterao, incrementos do produto so gerados. O crculo menor na figura representa as inspees dirias (daily meeting ou daily Scrum) que ocorrem durante as iteraes. Os membros da equipe se encontram para observarem o que os outros esto fazendo, e fazer adaptaes apropriadas, se necessrias [Schwaber (2004)].
Figura 1. Esqueleto do Scrum
As histrias de usurio (requisitos de funcionalidade) que devero ser feitas vm de um documento chamado Product Backlog, que usado pelo cliente (Product Owner) para gerir os requisitos. No incio de cada iterao feita uma seleo nesse documento para estabelecer quais funcionalidades (histrias) sero desenvolvidas. ento gerado outro documento, chamado Sprint Backlog, que contm apenas as histrias que sero desenvolvidas no ciclo de iterao, ou seja, no Sprint. Processos de teste para softwares desenvolvidos dessa maneira usam geralmente as histrias de usurio como base para a construo dos Casos de Teste. A pessoa responsvel por garantir que esse processo seja cumprido corretamente conhecida como Scrum Master. Ela responsvel por saber todas as regras e prticas do Scrum e passar aos demais. Ela tambm responsvel pela realizao e documentao das reunies, gerenciamento dos impedimentos e facilitao do processo de desenvolvimento.
Viso Geral sobre o Projeto Testado

O projeto que serviu de base para este estudo contava com uma equipe formada por: dois desenvolvedores, um designer, um testador, um Scrum Master e um Product Owner. Este projeto tinha como objetivo ser um sistema capaz de fornecer o resultado sobre Pesquisa de Satisfao do Cliente ao time de desenvolvimento do projeto relacionado. Com ele era possvel o cadastro de projetos, lderes, clientes e dos times de desenvolvimento destes projetos. O sistema se chama On Line Customer Satisfaction Survey OCSS. O OCSS basicamente fornecia informaes sobre: a qualidade dos releases (incremento de software) liberados, comunicao com o cliente, tempo de entrega dos releases e necessidade do cliente. O principal objetivo do OCSS em produo era mandar um relatrio de satisfao para o cliente ao final de cada entrega (release). O cliente ento recebia este relatrio e o respondia. Ao
Ambiente gil de Desenvolvimento SCRUM

Scrum uma metodologia extremamente gil e flexvel, centrada na equipe, utilizada para o desenvolvimento incremental e iterativo de qualquer produto, no caso do nosso artigo, desenvolvimento de software [Bissi (2007)]. Suas principais caractersticas so: auto-organizao da equipe de desenvolvimento, acompanhamento da evoluo do produto, desenvolvimento incremental das funcionalidades do produto [Schwaber (2004)] e gerenciamento dos requisitos atravs do documento chamado backlog do produto. O esqueleto do Scrum mostrado na Figura 1. O crculo maior na figura representa o perodo em que ocorrer a iterao de
Figura 2. Caso de Teste
final, o time que fazia parte do projeto recebia um e-mail com as impresses do cliente sobre o release entregue. A aplicao desenvolvida possui as seguintes caractersticas tcnicas: Plataforma Web; Linguagem Ruby; Rails como framework de desenvolvimento; Aptana St udio como IDE (Ambiente Integrado de Desenvolvimento); MySQL como Banco de Dados.
Experincia no Processo de Automao de Teste

Como no Scrum o desenvolvimento e o teste precisam ser geis, a equipe de teste do OCSS decidiu automatizar os casos de teste sabendo que isso minimizaria custos, aumentaria a produtividade e garantiria sua qualidade, reduzindo principalmente, o tempo de teste. Alm disso, a automao iria ajudar a cobrir as funcionalidades verificadas adequadamente [Pressman (1995)]. Pelo OCSS se tratar de uma aplicao Web, a ferramenta escolhida para os testes de Sistema e Aceitao foi o Selenium Selenium Core e IDE [Selenium], um software open source que utiliza a abordagem rec-and-play e oferece suporte a testes em aplicaes Web. O Selenium IDE um plugin do Mozilla Firefox. Com ele possvel gravar aes do usurio no browser e execut-las posteriormente. Esta ferramenta bastante til e ajuda muito na automao de Casos de Teste, trazendo agilidade na execuo. Os scripts gerados pelo Selenium, a partir da navegao de um usurio pelo browser, so por padro em HTML, porm o Selenium oferece o recurso de ter esse cdigo gerado em Ruby, Java, Perl, Python, Php, C#. Porm, esta no foi a nica automao feita no OCSS. Houve tambm a automao no gerenciamento e elaborao dos testes, visto que os resultados obtidos precisavam tambm ser reportados aos desenvolvedores de maneira rpida e prtica. Para isso foi usada outra ferramenta open source, chamada TestLink [TestLink]. Com esta ferramenta possvel a escrita dos Casos de Teste e a gerao de relatrios com base nos
resultados obtidos a partir da execuo dos testes. A ferramenta escolhida para o controle de bugs (bugtracking) foi o Mantis, que tambm open source e oferece bons recursos para este controle. Para que mtricas de aceitao e qualidade das histrias fossem geradas e tidas como base para os testes, houve a utilizao de uma prtica chamada Desenvolvimento Dirigido por Testes de Histrias (Story-Test Driven Development). Esta prtica diz que antes de comear a desenvolver a histria, a equipe de programadores, analistas, gerentes, testadores e clientes devem colaborar para definir os critrios de aceitao da histria. Critrios esses que foram utilizados pela equipe de teste do OCSS, como base para que a qualidade nos testes e nas funcionalidades testadas fosse alcanada. O ciclo de teste que era executado a cada Sprint se baseava em seis prticas comuns: 1) Fazer regresso dos casos de teste relacionados a histrias desenvolvidas na iterao anterior; 2) Escrever casos de teste (Figura 2) para as histrias (Figura 3) do Sprint atual, se baseando nos critrios de aceitao (Figura 4) de cada histria;
Figura 3. Histria que descreve o Caso de Uso
Figura 4. Critrio de Aceitao para o fechamento da histria
3) Com base neste Caso de Teste, eram criados os scripts de teste. Para isso o sistema desenvolvido foi executado em um browser. Neste momento o Selenium IDE trabalhava gravando toda a ao do browser e transformando-a em scripts HTML. Estes scripts sofriam modificaes para atender a alguma outra condio que pudesse vir a ocorrer. Os casos mais comuns em que ocorriam alteraes nos scripts gerados eram: Acrescentar chamadas da funo pause do prprio Selenium entre as linhas de ao geradas automaticamente pela navegao do browser. Como a execuo do Selenium muito rpida, s vezes casos de teste que estavam certos eram tidos como errados pelo Selenium pelo fato de algum dado do servidor ainda no ter chegado, portanto o uso de um delay ajudava bastante na verificao; Modificar chamadas de funes do Selenium quando os campos relacionados testados eram alimentados por Ajax. Por padro o script automtico do Selenium faz referncia a funo clickAndWait do Selenium, esta funo s retorna o valor atualizado, do servidor, aps um refresh na tela inteira do sistema. Em campos carregados dinamicamente por Ajax, necessrio que seja feita uma chamada a funo waitForValue, esta funo carrega o campo assim que ele recebe um valor novo, sem necessariamente ter que dar refresh na tela inteira; 4) Aps a execuo dos scripts, o testador cadastrava os bugs no Mantis (Figura 5) e os direcionava ao desenvolvedor responsvel pela histria testada;
funcionalidades desenvolvidas e as mtricas de teste geradas pelos grficos e relatrios do TestLink.
Figura 6. Exemplo de execuo de caso de teste que passou
Figura 7. Exemplo de execuo de caso de teste que falhou e gerou um bug no Mantis
Pontos Positivos
A automao trouxe inmeros benefcios para a equipe de teste e para a qualidade do projeto: Quanto equipe foi observado que: Aumentou a segurana da equipe quanto ao teste, j que foram feitos testes mais elaborados e complexos utilizando a opo de exportar para Java os scripts HTML gerados pelo Selenium; No houve sobrecarga de execuo de casos de teste, pois grande parte estava automatizada; Na maioria das vezes, o ciclo de teste era completamente executado em no mximo dois dias de trabalho, levando em considerao a execuo da etapa dos testes de regresso e dos testes das novas funcionalidades; Os testes de regresso foram responsveis por identificar a grande parte dos bugs encontrados no projeto. Estes, na sua maioria, estavam automatizados; Houve uma diminuio considervel com o tempo gasto com a identificao e correo de erros, j que os bugs de regresso eram encontrados mais rapidamente; Os scripts automticos foram na sua grande maioria atualizados e modificados poucas vezes; Foi possvel a montagem de uma Sute de Testes onde todos os scripts automticos eram executados sequencialmente. Isto economizou muito tempo. Quanto qualidade do projeto: Testes manuais, que poderiam contribuir para que erros fossem encontrados tardiamente, foram evitados com o processo de automao. Portanto, os bugs eram encontrados e resolvidos rapidamente, evitando desperdcio de tempo do projeto; Por ser uma aplicao WEB, era satisfatrio que o Sistema executasse perfeitamente em pelo menos dois navegadores. Os mais utilizados pelos clientes eram o Internet Explorer 6 e o Mozilla Firefox. Testes de regresso encontraram inmeros erros de cross-browser. Estes eram identificados rapidamente
Figura 5. Exemplo de bugs cadastrados no Mantis
5) Em seguida o testador informava o resultado da execuo (Figura 6 e Figura 7) dos scripts no TestLink. Isso era necessrio para a prtica seguinte; 6) Gerar relatrios automticos a partir das execues informadas. O TestLink oferece diversas opes para analisar os resultados gerados com base nas execues de casos de Teste. Os relatrios do TestLink mais utilizados foram: General Test Plan Metrics, Failed Test Cases, Charts e Total Bugs For Each Test Case. Eles podem ser acessados a partir da opo Results do menu superior do TestLink. Eram estas as prticas de Teste que ocorriam no Processo de Qualidade do OCSS na medida em que os Sprints aconteciam. Nas reunies de Retropective e Review eram observadas as
e repassados equipe de desenvolvimento, contribuindo largamente para a qualidade do Sistema; A automao serviu como base de estudo para os projetos posteriores. A equipe se focou em conhecer mais sobre automao, no sentido de prticas, de novas ferramentas e novos tipos de teste.
um projeto de software desenvolvido com Scrum, de grande importncia que se faa este tipo de teste, s assim a qualidade entre as iteraes garantida.
Links [Bernardo e Kon (2008)] Bernardo, P. e Kon, F., A Importncia dos Testes Automatizados http://www.ime.usp.br/~kon/papers/EngSoftMagazine-IntroducaoTestes.pdf [Bissi (2007)] Bissi, W., Scrum Metodologia de Desenvolvimento gil http://revista.grupointegrado.br/revista/index.php/campodigital/article/view/312/146 [Correia e Silva 2004] Correia, S. e Silva, A., Tcnicas para Construo de Testes Funcionais Automticos http://paginas.fe.up.pt/~jpf/teach/TQS0405/sc-Quatic2004.pdf [Costa 2006] Costa, M., Estratgia de Automao em Testes: requisitos, arquitetura e acompanhamento de sua implantao http://libdigi.unicamp.br/document/?down=vtls000389004 [Dasso & Funes (2007)] Dasso, A. and Funes, A.,Verification, Validation and Testing in Software Engineering. Idea Group, 2007 [Leal (2009)] Leal, I. Requisitos de Metodologias de Teste de Software para Processos geis http://homepages.dcc.ufmg.br/~rodolfo/dcc823-1-09/Entrega2Pos/igor2.pdf [Presman (1995)] Presman, R. S. Engenharia de Software. So Paulo: Makron Books do Brasil, 1995. [Selenium] Selenium Documentation. Selenium HQ - Web Application Testing System http://seleniumhq.org [Schwaber (2004)] Schwaber, K., Agile Project Management with Scrum. Microsoft Press, 2004 [TestLink] TestLink Documentation. TEAMST - Home of TestLink developers Community http://www.teamst.org/ [Tuschling (2008)] Tuschling, O., Software Test Automation http://www.stickyminds.com/getfile.asp?ot=XML&id=14908&fn=XDD14908filelistfilename1 %2Epdf [Vercauteren (2009)] Vercauteren, T., Agile development and functional testing: friend or foe? http://www.stickyminds.com/getfile.asp?ot=XML&id=15206&fn=XDD15206filelistfilename1 %2Epdf [Wilson (2009)] Wilson, G., The reality of software testing in an Agile Environment Testing Experience - The Magazine for Professional Testers 03/2009 (pg. 94 a 96)
Pontos Negativos
Como toda e qualquer prtica, a automao de testes atravs da abordagem rec-and-play tambm possui pontos negativos. Houve vrios pontos negativos e desgastes quanto adoo desta prtica, que foram: Como no Scrum parte de funcionalidades so feitas separadamente (entre Sprints), alguns scripts tiveram que ser atualizados. Exemplo: pedia-se em um Sprint para desenvolver a parte de cadastro da tela, e no Sprint seguinte a parte de edio da mesma tela. Com as funcionalidades entregues aos pedaos, os scripts deixavam de ser abrangentes; O Scrum tambm possibilita a mudana de requisitos no meio do processo. Assim, houve scripts automticos que foram totalmente perdidos por terem ficado obsoletos aps a mudana de algum requisito; Aplicaes Web so bastante instveis, ento a cada mudana das propriedades de algum componente o script que testava aquilo se tornava invlido, pois na abordagem rec-and-play o Selenium recupera o nome e propriedades do objeto selecionado para gravar o script. Se o componente mudou, naturalmente o script automtico no serve mais;
Concluso
A demanda por solues atravs de software tem crescido progressivamente a cada ano, e softwares cada vez mais complexos so solicitados. Com as metodologias geis, o desenvolvimento destas solues est cada vez mais rpido, exigindo dos profissionais um considervel nvel tcnico alm de comportamentos e caractersticas especficos para uma rpida tomada de deciso e adaptao caso requisitos mudem no meio do processo. A exigncia por qualidade, em um cenrio assim, naturalmente maior. Empresas tm investido em Testes de software com mais frequncia. Como apresentado neste artigo, testar manualmente sistemas complexos que precisam ser desenvolvidos rapidamente invivel. Dessa forma, para maximizar a qualidade e minimizar o tempo de um ciclo de testes, preciso aderir s prticas de automao. Apesar de algumas desvantagens demonstradas aqui, a prtica de automao vantajosa em projetos que utilizam o SCRUM, desde que se tenha um planejamento para isso. A automao garante bons e abrangentes testes de regresso. Em
www.devmedia.com.br/esmag/feedback
10
edio ta
A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link:
D s
D seu feedback sobre esta edio!
Feedback eu
sobre e s
Abordagens Tradicionais de Desenvolvimento

Esta seo traz artigos que apresentam como e quando utilizar as diferentes abordagens tradicionais de apoio ao desenvolvimento de projetos de software
Guias 2009 do MPS.BR: o que mudou?

Conhea as mudanas na verso 2009 dos guias do modelo MPS
Neste artigo veremos as principais mudanas ocorridas nos guias do modelo MPS verso 2009, alm de apresentarmos os novos guias que descrevem orientaes para organizaes que realizam atividades especficas do processo de software.
Para que serve?
D
Davi Viana dos Santos
davi.viana@gmail.com
Atua no ramo de implementao de programas de melhoria de processo de software tendo como base o programa MPS. BR. Bacharel em Cincia da Computao pela Universidade Federal do Amazonas (UFAM) e Mestrando em Informtica pelo Programa de Ps-Graduao em Informtica (PPGI) da mesma Universidade. Suas pesquisas so focadas em Engenharia de Software, principalmente em Qualidade de Processo de Software.
esde 1 de Janeiro de 2010 as avaliaes MPS esto seguindo somente o modelo de referncia MR-MPS: 2009. Por este motivo, organizaes que esto implementando o modelo para a futura avaliao ou reavaliao devem levar em considerao as mudanas dos guias da verso 1.2 para a verso 2009, pois isto pode ser decisivo para o sucesso de uma avaliao MPS. Alm das avaliaes, importante lembrar que os guias descrevem requisitos e condies para quem quer se tornar um avaliador adjunto, avaliador lder ou consultor de Aquisio MPS, tambm apresenta orientaes para criao de novas Instituies Implementadoras (II) e Instituies Avaliadoras (IA). A
A nova verso dos guias oferece orientaes que passaram a ser utilizadas em avaliaes e MPS desde o dia 1 de Janeiro de 2010. Todas as provas de habilitao para novos avaliadores tambm j utilizam os novos guias.

Alm de ser um modelo atualizado que descreve prticas para obter maturidade em processos de software, utilizado quando se faz necessrio uma reavaliao dos processos j implementados na organizao.
seguir sero apresentadas as mudanas nos guias. Este artigo tem como base os guias do modelo MPS verso 2009 e verso 1.2, que esto disponibilizados no site da SOFTEX. Inicialmente so explanadas as
11
alteraes nos guias de implementao, alm da apresentao dos novos guias. Em seguida, as modificaes no guia de avaliao so apresentadas. Por fim, so verificadas as mudanas no guia de aquisio.
Guias de Implementao
Os guias de implementao que apresentam orientaes de como implementar o modelo de referncia MR-MPS sofreram grandes mudanas: processos foram includos ou alterados, alguns resultados esperados dos processos foram modificados em todos os nveis e aumentou-se o nmero de resultados de atributos de processo (RAPs). As alteraes nos processos especficos e nos resultados de atributos de processo so abordadas por nvel de maturidade que, por sua vez, so descritas nos guias de implementao.
Nvel G Parcialmente Gerenciado
No que diz respeito aos processos deste nvel, podemos destacar uma melhor descrio do resultado esperado para o processo Gerncia de Projetos GPR7. Algumas organizaes no possuem recursos humanos para desempenhar determinadas tarefas do projeto, logo o MPS estabelece a realizao de treinamentos e mentoring para minimizar os riscos em relao competncia do profissional alocado. Outras modificaes verificadas so referentes ao GPR10 e ao GPR13, que possuam outras definies a partir do nvel E, agora passaram a ser vlidos para todos os nveis de maturidade. Os resultados esperados GRE1 e GRE2 do processo Gerncia de Requisitos foram unificados no GRE1. O GRE2 estabelece a necessidade de um comprometimento da equipe tcnica com os requisitos, ou seja, comprometimento dos colaboradores que esto envolvidos diretamente com o desenvolvimento do produto com os requisitos estabelecidos. Este comprometimento deve ser obtido novamente quando houver mudanas nos requisitos. Por fim, no GRE5 apresentado que se deve haver pelo menos um projeto evidenciando mudanas de requisitos, para que seja avaliada a tratativa aplicada a essas mudanas. Neste nvel, as maiores mudanas ocorreram nos RAPs. Primeiramente temos que o RAP 5, RAP7 e o RAP 9 passaram a ser vlidos somente at o nvel F. A partir do nvel E, os mesmos recebem novas definies. Incluiu-se um novo RAP6, que trata a respeito das responsabilidades e autoridades para executar o processo e tambm recebe uma nova definio a partir do nvel E. Por fim, foi incluso um novo RAP10, que descreve que o projeto conduzido a partir da execuo do seu processo planejado, e a partir do nvel F o mesmo recebe uma nova definio. Com a incluso desses dois RAPs, o atributo de processo AP2.1 passou a ter nove RAPs (RAP2 ao RAP10).
Um novo processo foi includo neste nvel de maturidade: Gerncia de Portflio de Projetos (GPP), cujo objetivo gerenciar, de forma estratgica, os projetos que so vitais para a organizao. A diferena entre o processo Gerncia de Projetos e Gerncia de Portflio de Projetos que o primeiro processo gerncia atividades de um projeto e o segundo gerncia o conjunto de projetos que a organizao possui. Este processo obrigatrio, exceto se a atividade da unidade organizacional a ser avaliada for evoluo de produto. Este processo atua em duas frentes: selecionando os projetos que devem ser executados e, depois de comear a execuo, verificar se os mesmos continuam viveis para a organizao. O novo processo possui cinco resultados esperados, que so: GPP1 As oportunidades de negcio, as necessidades e os investimentos so identificados, qualificados, priorizados e selecionados. Neste resultado levado em considerao os objetivos estratgicos da organizao junto com a seleo das oportunidades; GPP2 Os recursos e oramentos para cada projeto so identificados e alocados. Este resultado se difere do GPR7 e GPR8 pelo fato de haver uma anlise dos possveis conflitos de recursos entre os projetos; GPP3 A responsabilidade e autoridade pelo gerenciamento dos projetos so estabelecidas. Neste resultado importante definir e comunicar ao responsvel sua autoridade pelo gerenciamento de cada projeto; GPP4 Os conflitos sobre recursos entre os projetos so tratados e resolvidos. Esses conflitos devem ser resolvidos no mbito organizacional, ou seja, registrar, analisar, tratar e resolver os conflitos referentes aos recursos utilizados pelos projetos em execuo; GPP5 Projetos que atendem aos acordos e requisitos que levaram sua aprovao so mantidos, e os que no atendem so redirecionados ou cancelados. Essa verificao pode ser feita juntamente com o monitoramento ou reviso descritas como resultado esperado do processo de Gerncia de Projetos, ou pode ser criada uma reviso especfica para seleo de projetos. O ponto chave deste resultado analisar se os projetos continuam alinhados aos objetivos estratgicos pretendidos, caso contrrio necessrio tomar medidas em relao a sua continuidade de execuo. No resultado esperado GQA2 do processo Garantia da Qualidade, retratado que h uma interao entre este resultado esperado com o RAP 10 (A partir do nvel F) e, consequentemente a esta interao, necessrio avaliar a aderncia a todos os processos descritos no MR-MPS que a organizao implementa. O MED1 (primeiro resultado esperado do processo Medio) deixa claro que os objetivos de medio so estabelecidos e mantidos a partir dos objetivos de negcio da organizao. O MED4 ainda acrescenta a importncia da definio de metas no auxilio a anlise das medidas. Apesar do ttulo do resultado esperado MED7 ter sido modificado, seu propsito continua o mesmo.
Nvel F - Gerenciado
O processo de Gerncia de Configurao sofreu alterao no resultado esperado GCO5, pois alm de controlar as modificaes nos itens de configurao, este resultado descreve que necessrio, tambm, apresentar essas modificaes s partes interessadas.
12
Engenharia de Software Magazine - Guias 2009 do MPS.BR: o que mudou?
PROcesso
O atributo de processo 2.2 acrescenta um novo RAP cujo objetivo garantir que os requisitos dos produtos de trabalho tenham sido identificados.
infraestrutura e do ambiente de trabalho e, por fim, produtos de trabalho e lies aprendidas so gerenciados na biblioteca de ativos do processo.
Nvel E Parcialmente Definido

Segundo o resultado esperado para o processo Gerncia de Projetos (Evoluo) GPR4, a partir do nvel E, a utilizao de um mtodo parametrizado para dimensionar as tarefas e os produtos de trabalho do projeto obrigatrio. Exemplos de mtodos so: Anlise de Pontos por Funo e Anlise de Pontos por Caso de Uso. J o GPR18 passa a ser implementado para todos os nveis a partir do nvel E. O processo Gerncia de Recursos Humanos (GRH) acrescenta mais resultados esperados: o GRH5 descreve a criao de um plano ttico de treinamento que deve ser definido para suprir as necessidades estratgicas de treinamento da organizao e dos projetos. A mudana no resultado esperado para o processo Gerncia de Reutilizao GRU3 refere-se implementao deste resultado para todos os nveis a partir de onde definido pela primeira vez, ou seja, no nvel E. Ainda neste resultado, feito uma descrio mais detalhada sobre o mesmo quando a organizao quer atingir o nvel C. Novas definies em relao ao RAP5, RAP6, RAP7 e RAP9 so apresentadas: RAP5 (a partir do nvel E): que trata a respeito dos recursos e informaes para executar o processo definido so disponibilizados, alocados e utilizados; RAP6 (a partir do nvel E): garante a atribuio e a comunicao dos papis requeridos, responsabilidades e autoridades s pessoas responsveis pela execuo do processo definido; RAP7 (a partir do nvel E): verifica se as pessoas alocadas para executar o processo definido possuem o perfil adequado; RAP9 (a partir do nvel E): estabelece que conforme o processo padro executado na organizao na forma de processo definido, dados de uso do processo devem ser coletados para formar uma base para acumular conhecimento sobre o comportamento do processo padro. Ainda foram includos dois novos RAPs no atributo de processo 3.1. Ambos tratam de elementos (papis e competncias requeridos e infraestrutura e ambiente de trabalho) que precisam ser identificados como parte do processo padro. J no atributo de processo 3.2 foram acrescidos trs novos RAPs: O primeiro descreve que o processo definido implementado para o projeto baseado nas diretrizes para seleo e/ou adaptao do processo padro; o segundo trata da gerncia da
Nvel D Largamente Definido

Este nvel sofreu poucas modificaes, em relao ao processo Projeto e Construo do Produto (PCP). Seu primeiro resultado esperado PCP1 destaca a importncia dos requisitos definidos em relao ao produto e aos componentes do produto. Verificando o processo Validao (VAL), constatou-se algumas informaes que foram acrescidas nos resultados esperados deste processo, por exemplo: no resultado esperado VAL5 o guia descreve que no necessrio corrigir todos os problemas encontrados, desde que a organizao tenha definido critrios que facilitem essa anlise. Em relao aos atributos de processo, vale lembrar que este nvel no apresenta novidades em relao aos implementados no nvel E. Entretanto, necessrio a definio e implementao dos cinco processos especficos com a mesma capacidade dos processos j implantados. Todas as informaes referentes aos resultados esperados de processos que podem ser excludos do escopo da avaliao so mais bem detalhadas nos novos guias da verso 2009, pois tratam de informaes a cerca de organizaes que realizam atividades especficas do desenvolvimento de software.
13
Nvel C - Definido
Neste nvel a evoluo do processo Gerncia de Reutilizao (GRU) foi retirada. O processo Anlise de Deciso e Resoluo (ADR) foi alterado para processo Gerncia de Decises (GDE), contudo, o propsito, a fundamentao terica e resultados esperados deste processo continuam os mesmos. Por fim, no processo Gerncia de Riscos (GRI), o resultado esperado GRI8 sofreu uma pequena modificao em relao medio dos riscos. Assim como no nvel D, os RAPs no sofreram alteraes.
verificar se as mudanas no processo corrigiram o problema e melhoraram seu desempenho. Essa verificao feita atravs de medies; RAP46 Refere-se ao antigo resultado de processo ACP5, cujo objetivo armazenar os dados de anlise de causas de problemas e resolues para eventuais situaes similares.
Novos guias de implementao

Na verso 2009 foram criados mais trs guias de implementao que possuem o objetivo de melhor orientar organizaes que possuem atividades especficas do processo de software, detalhando quais processos, resultados esperados de processos e de atributos de processos essas organizaes devem implementar. Estes novos guias so apresentados visando o propsito do mesmo, e em seguida descrevendo como os processos do modelo de referncia MR-MPS devem ser implementados ou no em cada tipo de organizao.
Nvel B Gerenciado Quantitativamente
O guia referente ao nvel B no sofreu nenhuma alterao a ponto de modificar o propsito do processo Gerncia de Projetos (Evoluo), logo os resultados esperados deste processo continuam iguais. Os RAPs tambm no sofreram modificaes.
Nvel A Em Otimizao
Na verso 2009 dos guias de implementao, este nvel no possui processos especficos. Anteriormente, o mesmo possua o processo Anlise de Causas de Problemas e resoluo (ACP). Os resultados esperados do processo ACP passaram a incorporar os resultados esperados do Atributo de Processo 5.1 e 5.2. No atributo de processo 5.1 seu propsito foi modificado a fim de tratar das melhorias e no somente das inovaes, alguns RAPs foram modificados e dois outros foram includos (antigos ACP1 e ACP2). Os RAPs modificados so: RAP36 que ao invs de somente definir os objetivos de melhoria, necessrio fazer o levantamento de todas as propostas de melhoria e fazer um estudo em cima dessas propostas; RAP42 este resultado de atributo de processo descreve que, alm de estabelecer uma estratgia de implementao para os objetivos de melhoria do processo, necessrio que essa estratgia tambm seja estabelecida para resolver problemas. Os novos RAPS so: RAP37 Refere-se ao antigo resultado de processo ACP1 que trata sobre a identificao, classificao e seleo para anlise dos defeitos e outros problemas; RAP38 Refere-se ao antigo resultado de processo ACP2 que descreve sobre a anlise de identificao da causa raiz dos defeitos e outros problemas, e anlise sobre solues aceitveis para evitar a ocorrncia futura; No AP 5.2 foram adicionados dois RAPs (antigos ACP4 e ACP5) que se referem gerncia das aes implementadas, so eles: RAP 45 Incorporou o antigo RAP36 cujo objetivo avaliar a efetividade das mudanas, e tambm se refere ao antigo resultado do processo ACP4 cujo objetivo o acompanhamento das aes implementadas para resoluo de problemas para
Organizaes que adquirem software

O primeiro guia referente s organizaes que adquirem software. Este apresenta orientaes de como implementar o processo Aquisio (AQU), explicitando quando este processo obrigatrio ou no em uma organizao e que medidas tomar em relao aos demais processos. Para uma organizao que deseja implementar o n vel G do MPS.BR, deve deixar claro os papis do adquirente e do fornecedor com o objetivo de: especificar as responsabilidades de cada um; o que cada parte tem que fazer; como criar seu cronograma e realizar seu monitoramento; quem responsvel pelas definies do projeto (recursos humanos, infraestrutura, recursos financeiros, entre outros); como ser realizado o acesso aos dados, o fluxo de dados entre todos os envolvidos; como ser realizada as revises do projeto nas partes envolvidas; e como ser obtido o comprometimento do projeto e dos requisitos com as partes envolvidas. Por fim, importante lembrar que nenhum resultado esperado de processo e atributo de processo pode deixar de ser implementado. Quando a organizao deseja implementar o n vel F do MPS.BR necessrio que, alm do processo Aquisio, sejam implementados: o processo gerncia de configurao (onde o adquirente deve estabelecer e manter seu prprio sistema de gerncia de configurao); o processo Garantia da Qualidade (onde o adquirente deve avaliar os produtos de trabalho gerados pela atividade que executa, bem como analisar e aprovar os resultados das avaliaes da qualidade do produto gerados pelo fornecedor); o processo Medio (onde so medidos tanto os produtos de trabalho gerados pelo adquirente quanto os gerados pelo fornecedor). Por fim, pode ser excludo do escopo da avaliao o processo de Gerncia de Portflio de Projetos quando a nica atividade da organizao adquirente seja evoluo do produto. Se a organizao quer implementar o n vel E do MPS.BR necessrio implementar: os resultados esperados da evoluo do processo Gerncia de Projetos; o processo Avaliao e
14
PROcesso
Melhoria do Processo Organizacional; Definio do Processo Organizacional; o processo Gerncia de Recursos Humanos (levando em considerao os recursos humanos da organizao adquirente); o processo Gerncia de Reutilizao (vlidos tanto para reutilizao de ativos da organizao adquirente quanto para os ativos do fornecedor). Para a implementao do nvel D so solicitados: somente um resultado esperado do processo Desenvolvimento de Requisitos (DRE), trata-se do DRE1, os demais resultados esperados podem ser excludos, isto vai depender do tipo de aquisio do projeto; no processo Integrao do Produto (ITP) obrigatrio somente a implementao do ITP9, os demais tambm dependem do projeto; no processo Validao (VAR) apenas os resultados esperados VAL1, VAL6 e VAL7 so obrigatrios. Por fim, podem ser excludos de uma avaliao o processo Projeto e Construo do Produto (PCP) e o processo Verificao (VER). A implementao do n vel C requer que sejam satisfeitas as seguintes condies: os resultados esperados do processo Desenvolvimento para Reutilizao variam conforme o tipo de aquisio que a organizao executa; todos os resultados esperados do processo Gerncia de Decises e do processo Gerncia de Riscos so obrigatrios. Para a implementao dos n veis B, deve-se atentar para os resultados esperados da evoluo do processo Gerncia de Projetos, cujo objetivo estabelecer critrios para o fornecedor visando qualidade do produto e desempenho do processo com base nos objetivos da organizao e do processo. Outro fator relevante a definio de um acordo a cerca dos dados estat sticos dos processos da organizao. Como o n vel A no possui processos especficos, no h processos a serem implementados em uma organizao que adquire software. Contudo, importante ressaltar que os resultados de atributos de processo devem ser implementados no contexto dos processos para este tipo de organizao, assim como para qualquer n vel que se deseja implementar.
ser implementados todos os resultados esperados, pois so processos comuns a todo tipo de organizao; J os processos que permitem a excluso de seus resultados esperados so: Aquisio Este tipo de processo pode no se aplicar s organizaes que possuem como nica atividade fabricar cdigo; Desenvolvimento de requisitos Apenas o resultado esperado DRE1 obrigatrio, pois auxilia a compreenso e a aceitao das especificaes; Integrao de Produto Poder ser excludo caso a organizao no realize atividades de integrao de cdigo desenvolvido; Projeto e Construo do Produto Somente o PCP6 obrigatrio. Caso a Fabrica de Software tambm faa a documentao, o PCP7 e PCP8 podem ser necessrios; Validao Poder ser excludo se a organizao no realizar atividades de teste de homologao/aceitao; Desenvolvimento para Reutilizao A excluso dos resultados esperados deste processo depende das atividades executadas pela organizao do tipo Fbrica de Software.
Organizaes do tipo Fbrica de Teste

O ltimo novo guia da verso 2009 apresenta orientaes para a implementao do MR-MPS em organizaes do tipo Fbrica de Teste. As fabricas de teste devem possuir independncia organizacional para testar seus produtos, ou seja, liberdade e autoridade para realizar os testes e comunicar seus resultados para os interessados. Os processos que no podem ter seus resultados esperados excludos so: Gerncia de Projetos e suas evolues As organizaes deste tipo devem definir seu projeto de acordo com as atividades para as quais foi contratada, ou seja, teste do produto de software; Gerncia de Requisitos Neste tipo de organizao este processo tratado como gerncia dos requisitos de teste. A fbrica de testes responsvel por entender, avaliar e aceitar os requisitos com a utilizao de critrios definidos, incluindo os requisitos para teste; a rastreabilidade bidirecional feita levando em considerao os produtos gerados pela fabrica de testes; quando h mudanas nos requisitos, a maneira como os mesmos so gerenciados e/ou repassados para a Fbrica de Testes estabelecido e declarado pelo adquirente; Gerncia de Configurao, Gerncia de Portflio de Projetos, Garantia da qualidade, Medio, Avaliao e Melhoria do Processo Organizacional, Definio do Processo Organizacional, Gerncia de Recursos Humanos, Gerncia de Reutilizao, Verificao, Gerncia de Decises e Gerncia de Riscos Devem ser implementados todos os resultados esperados, pois so processos comuns a todo tipo de organizao. J os processos que permitem excluso de seus resultados esperados so:
Organizaes do tipo Fbrica de Software

O segundo guia descreve a implementao do MR-MPS em organizaes do tipo Fbrica de Software, pois algumas atividades do processo de software so de responsabilidade da contratante da fbrica, fazendo com que alguns processos no se apliquem a este tipo de organizao. Os processos e resultados esperados onde no so permitidas excluses so: Gerncia de Projetos e suas evolues O gerenciamento de projetos pode ser feito da mesma forma que nos demais tipos de organizao. A diferena geralmente est no escopo do trabalho que prioriza a etapa de construo de cdigo; Gerncia de Requisitos Envolve gerenciar as modificaes nas especificaes provenientes da organizao contratante; Gerncia de Configurao, Gerncia de Portflio de Projetos, Garantia da qualidade, Medio, Avaliao e Melhoria do Processo Organizacional, Definio do Processo Organizacional, Gerncia de Recursos Humanos, Gerncia de Reutilizao, Verificao, Gerncia de Decises e Gerncia de Riscos Devem
15
Aquisio Este tipo de processo pode no se aplicar s organizaes deste tipo, pois as mesmas realizam atividades de teste; Desenvolvimento de requisitos Apenas o resultado esperado DRE1 obrigatrio, pois auxilia a compreenso e a aceitao dos requisitos que sero utilizados para testes; Integrao de Produto e Projeto e Construo do Produto Podero ser excludos totalmente do escopo da avaliao, pois normalmente fabricas de teste no realizam atividades de construo (desenvolvimento) e integrao de cdigo; Validao Poder ser excludo se a organizao no realizar atividades de teste de homologao/aceitao; Desenvolvimento para Reutilizao A excluso dos resultados esperados deste processo depende das atividades executadas pela organizao do tipo Fbrica de Testes. muito importante lembrar que a excluso de qualquer processo ou determinados resultados esperados deve estar bem justificado por parte da organizao. Em relao avaliao MPS, a aprovao das excluses responsabilidade do avaliador Lder.
Guia de Avaliao
Na verso 2009, o guia de avaliao sofreu algumas modificaes no contexto do processo e regras para a execuo da avaliao. Nesta nova verso ficou estabelecido que uma Instituio Avaliadora (IA) no poder ser contratada caso: tenha dado consultoria na organizao a ser avaliada durante os ltimos trs anos, mesmo que tenha sido somente um membro da equipe da IA; algum membro da IA tenha realizado um gap analysis na unidade organizacional a ser avaliada, alm das restries j contidas na verso anterior do modelo. A principal diferena na validade dessas restries (trs anos) que no estava presente no guia de avaliao da verso anterior. Foram adicionados passos na conduo da avaliao inicial do subprocesso de preparar a realizao da avaliao, como: apresentar os processos da unidade organizacional e confirmar a realizao da avaliao final. Em relao equipe de avaliao, detalhado o perfil do representante da organizao avaliada, e a estimativa de tempo para realizao da avaliao tambm foi alterado: nveis A, B, C e D passaram a ter a durao de trs a quatro dias para a avaliao inicial e de trs a cinco dias para a avaliao final; no nvel E, a durao de dois a quatro dias tanto para a avaliao final quanto para a avaliao final; no nvel F dura de dois a trs dias para ambos, e no nvel G a durao de um a dois dias. Ao se tratar do nmero mnimo de membros da equipe de avaliao, o guia descreve que possvel completar a equipe com membros da organizao que atendam s condies estabelecidas ou aumentar a equipe da IA ou, ainda, aumentar o nmero de dias da avaliao. Executar uma dessas medidas importante para manter a seriedade da avaliao no que diz respeito quantidade mnima de membros da equipe.
Quando se trata das entrevistas realizadas na avaliao final, a nova verso dos guias deixa claro que necessrio registrar as afirmaes coletadas na Planilha de Indicadores logo aps as entrevistas, pois outras atividades da avaliao podem comprometer o que foi dito pelos entrevistados. As caracterizaes de atributo de processo para satisfazer os nveis do MR-MPS sofreram pequenas alteraes: o AP 1.1 tem que ser, obrigatoriamente, Totalmente implementado (T) em todos os nveis, o AP 2.1 e AP 2.2 passou a ser T a partir do nvel E, os demais continuam com a mesma caracterizao. J para evitar o descredenciamento de uma IA, alm das condies que j existiam, passou a ser obrigatrio a presena do coordenador da IA anualmente ao workshop de avaliadores (W3-MPS.BR) e na reunio de coordenadores de IA. Para se tornar um avaliador lder inicial foi adicionado mais uma condio que trata a respeito de ser aprovado na prova para implementadores (P2-MPS.BR) e a condio que trata a respeito do nmero de participaes em avaliaes como avaliador adjunto foi acrescido para seis. Agora um avaliador lder intermedirio tem que possuir, como experincia profissional comprovada, envolvimento significativo de processos de software onde a organizao obteve o nvel D ou C do MR-MPS ou CMMI nvel 3 ou superior, e ter liderado pelo menos seis avaliaes de nveis G ou F. Por fim, para se tornar um avaliador lder experiente, foram alterados a formao acadmica no que diz respeito ao conhecimento do controle estatstico de processos.
Guia de Aquisio
O Guia de aquisio descreve um processo de aquisio de Software e Servios Correlatos (S&SC) baseado na Norma Internacional ISO/IEC 12207:2008, complementado pela norma IEEE STD 1062:1998. Porm, importante ressaltar que o processo Aquisio (AQU) a ser verificado em uma avaliao MPS descrito no guia de implementao referente ao nvel F. Neste guia, as mudanas so apresentadas conforme a sequncia das atividades previstas para aquisio de S&SC. Houve algumas mudanas nas tarefas previstas para aquisio de software, por exemplo, na tarefa prevista Desenvolver uma estratgia de aquisio, o guia apresenta opes viveis para aquisio de software e servio correlato (S&SC). Os relacionamentos das tarefas do processo de Aquisio com os demais processos do MR-MPS foram retirados da verso 2009. Para a execuo de algumas tarefas foram includos novos produtos requeridos, como na tarefa prevista de monitorar a aquisio da atividade de monitoramento do contrato, so eles: Resultado da anlise do desempenho do fornecedor e Software e Servio Correlato. Como o processo de Aquisio tambm forma profissionais (consultores de aquisio MPS), as condies para se tornar
16
PROcesso
um consultor sofreram alteraes. Foi includa uma condio que une as condies II, III e IV da verso 1.2 que descreve a necessidade da elaborao de um Plano de Aquisio de Software (PAS) de um projeto real ou terico, com o objetivo de mostrar sua capacidade. Esse PAS dever ser apresentado presencialmente ou via internet para uma banca avaliadora constituda por membros da SOFTEX, e esta banca indicar se o candidato foi aprovado.
muito importante que todos estejam atentos a essas alteraes, pois so mudanas relevantes que podem ser fatores decisivos para um bom desempenho do profissional responsvel pela implementao dos processos, um bom desempenho da organizao em uma avaliao e, por fim, pode ser decisivo para a habilitao de um futuro avaliador do modelo MPS.
Referncias/Links Baseado nos guias, verso 2009. Disponveis em: http://www.softex.br/mpsbr/_guias/default.asp
Concluso
As modificaes, descritas nos guias verso 2009, representam melhorias do modelo MPS, alm de ajustar a conformidade com a norma internacional ISO/IEC 12207:2008 e com a norma ISO/IEC 15504, que tambm tiveram atualizaes. Isto mostra a seriedade de manter no mercado um modelo atualizado, em concordncia com a realidade brasileira e, ao mesmo tempo, compatvel com o modelo mais adotado no mundo, o CMMI.
edio ta
D s
Feedback eu
sobre e s
17

Fatores crticos de sucesso em programas de melhoria de processo de forma cooperada

Este artigo descreve as experincias vivenciadas pelo SOFTEXRECIFE na organizao de programas de melhoria de forma cooperada com base no modelo MPS. BR. O principal objetivo do trabalho compartilhar os aprendizados, analisando os principais pontos que foram determinantes para o sucesso obtido.
Geovane Nogueira Lima

geovane@next.org.br
Marcos Andr Gomes

marcos@recife.softex.br
Bacharel em Cincia da Computao pela Universidade Federal de Lavras (UFLA). Mestre em Engenharia de Software pela Universidade Federal de Pernambuco (UFPE) possui ps-graduao em Melhoria do Processo de Software, e em CMMI pela UFLA. Profissional certificado pelo ISTQB (International Software Testing Qualifications Board) e pelo PROQUALITY (Ncleo de estudos em Engenharia e Qualidade de Software). Possui 10 anos de experincia em TI, tendo atuado em diversos projetos de desenvolvimento de software e em projetos de pesquisa e inovao tecnolgica financiados pelo CNPQ. H 5 anos, atua como consultor e instrutor em Melhoria de Processo de Software, realizando atividades de consultoria e implantao de Melhoria do Processo de Desenvolvimento de Software, com base em diversos modelos: CMMI, ITIL, ISO/IEC 15504, ISO/IEC 12207, MPS.BR, BPM, PMBOK, SCRUM dentre outros. Entre suas principais atuaes como consultor em projetos de melhoria, destacam-se empresas como ATAN/ Accenture, TOTVS, FlagIntelliwan, Procenge e MV Sistemas.
Bacharel em Administrao de Empresas pela Universidade Federal de Pernambuco. Psgraduado em Gesto da Tecnologia da Informao pela UPE (Universidade de Pernambuco). Atua a mais de 25 anos, em empresas de grande porte no setor do comercio, indstria e servios na rea de TI, 15 dos quais como gerente de TI. Implantou processos e metodologias de desenvolvimento de software e gesto de equipes, em diversas empresas. Implementou certificao ISO 9001-2000 em empresas de desenvolvimento de software. Atualmente exerce o cargo de Diretor de Tecnologia do SOFTEX RECIFE, onde dirige projetos, junto a empresas e organismos governamentais (BNDES, FINEP, MCT, SEBRAE e outros). Gestor do projeto de melhoria da qualidade de software em Pernambuco, atravs de convnio para implementao do MPS. BR (Melhoria do Processo de Software) junto com a Sociedade SOFTEX,O MCT(Ministrio da Cincia e Tecnologia) e o BID(Banco Interamericano de Desenvolvimento). Gestor do NEXT (Ncleo de Excelncia em Teste de Sistemas), o laboratrio de teste de software do SOFTEX RECIFE. Diretor regional da ALATS (Associao Latino Americana de Teste de Software).
Para que serve?

Para todos os interessados em implementar melhoria de processo de forma colaborativa, o artigo indica os primeiros passos e desta os principais pontos impactantes no sucesso da implementao.

Este tema de grande utilidade para a melhoria da qualidade e produtividade do software nacional, abordar forma de se implementar modelos de qualidade em grupos de empresa, o que reduz expressivamente os custos de implementao.
ste artigo tem por objetivo compartilhar a experincia bem sucedida vivida pelo SOFTEXRECIFE na organizao de cooperativas para implantao do programa de melhoria com base no modelo MPS.BR. De forma sucinta, esperamos repassar os
18
Engenharia de Software Magazine - Fatores crticos de sucesso em programas de melhoria de processo de forma cooperada
Processo
aprendizados adquiridos, apresentar e discutir os principais pontos determinantes do sucesso da cooperativa, na tica da IOGE (Instituio Organizadora de Grupo de Empresas). O SOFTEXRECIFE em parceria com a SWQuality organizou em 2006 o primeiro grupo de empresas em Recife para a implantao do programa de melhoria, com base no Modelo de Referncia do MPS.BR [MR-MPS.BR] e em 2007 o segundo grupo de empresas, motivado pelo comunicado da Sociedade SOFTEX Nacional para a formao de grupos de empresas para a implantao do MR-MPS.BR no modelo cooperado. Esta primeira cooperativa de empresas teve por objetivo apoiar a implementao do nvel G do modelo em 5 empresas de desenvolvimento de software da regio Nordeste, e a avaliao seguindo o Mtodo de Avaliao do MPS.BR [MA-MPS.BR]. A primeira cooperativa MPS.BR nvel G desenvolveu suas atividades no perodo de abril de 2006 a junho de 2007, quando as ltimas empresas do grupo foram avaliadas obtendo o nvel G. Das 5 empresas que iniciaram o grupo, 4 empresas foram avaliadas e todas foram bem sucedidas com as avaliaes realizadas conforme previsto no projeto. Com isto obtivemos uma taxa de sucesso de 80%, maior do que a prevista inicialmente. Em 2007 foi organizada a segunda cooperativa com 9 empresas organizadas em dois grupos, um grupo com 5 empresas objetivando o nvel G e o outro com 4 empresas objetivando o nvel F. Estes grupos foram finalizados no incio de 2009, com a avaliao oficial de 3 empresas no nvel F e 4 no nvel G. Com estes resultados, obtivemos um ndice de 78% das empresas que iniciaram o grupo avaliadas oficialmente, e com 100% de aproveitamento nas avaliaes, ou seja todas as empresas que se submeteram avaliao oficial obtiveram o nvel pretendido.
com outras instituies, elemento chave de uma estratgia, em curso, para consolidar a cidade do Recife como um plo reconhecido e respeitado de gerao, produo e difuso de Tecnologia da Informao. O SOFTEXRECIFE atuou no papel de IOGE (Instituio Organizadora de Grupo de Empresas) na primeira e segunda cooperativa MPS.BR Recife. Podemos observar que a organizao das cooperativas est totalmente alinhada aos objetivos do SOFTEXRECIFE, e neste ponto todos os esforos foram realizados para ajudar as empresas, na sua busca por competividade.
As cooperativas
A primeira cooperativa foi formada em abril de 2006, com o objetivo de implantao de um programa de melhoria baseado no nvel G do MR-MPS.BR, alm da avaliao oficial neste nvel do modelo de 5 empresas organizadas em grupo. A cooperativa foi organizada em parceria com a SWQuality Consultoria e Sistemas, a qual atuou como II (Instituio Implementadora), ficando responsvel pelas atividades de consultoria, treinamento e comunicao do grupo. As empresas selecionadas para compor esta primeira cooperativa foram: CAPITAL LOGIN, PROCENGE, PROVIDER, MV SISTEMAS e NEUS. Todas as empresas so classificadas como empresas de mdio ou pequeno porte, e esto todas situadas na regio Nordeste do pas. A cooperativa, conforme definido no seu prprio Plano de Projeto, teve como principais objetivos: Avaliar e aprovar 5 empresas de desenvolvimento no nvel G do MPS.BR; Promover a cultura da qualidade em desenvolvimento de software no ecossistema de Pernambuco; Difundir o MPS.BR. Sendo a principal prioridade a avaliao oficial das empresas no nvel G do MPS.BR, num prazo de doze meses. Os resultados alcanados foram bastante expressivos, atingindo todos os objetivos planejados e superando inclusive algumas das expectativas iniciais. Das 5 empresas participantes, 4 foram avaliadas e todas obtiveram resultado positivo na avaliao, obtendo assim o nvel G do modelo. A nica empresa no avaliada deveu-se mudana no seu foco de atuao, extinguindo sua rea de desenvolvimento de software. Assim, obtivemos um indicador de desempenho, com 100% de sucesso. Temos plena convico que todo este sucesso se deve ao esforo conjunto de todos os atores envolvidos na cooperativa: IOGE, II e empresas; e principalmente a harmonia entre estes atores. Os fatores de sucesso da cooperativa dependem da unio, esforo e comprometimento de todos. Por parte da IOGE, entendemos que o principal fator de sucesso foi assumir uma postura pr-ativa, e, sobretudo, valorizar a comunicao entre os envolvidos. O principal desafio enfrentado logo no incio dos trabalhos foi conseguir despertar o interesse das empresas e selecionar
A IOGE
O SOFTEXRECIFE, criado em 1994, o Centro de Tecnologia de Software para Exportao do Recife. Sua misso articular, fomentar e apoiar aes direcionadas excelncia do setor de software em Pernambuco. No momento, o SOFTEXRECIFE conta com mais de 70 empresas a ele associadas, o que significa uma parcela importante das empresas que formam o setor de Tecnologia da Informao e Comunicao em Pernambuco. A principal misso do SOFTEXRECIFE aumentar a competividade das empresas de Tecnologia da Informao e Comunicao, buscando instrumentos para fomentar o desenvolvimento do setor de software no Estado de Pernambuco. O SOFTEXRECIFE tem como viso tornar-se dentro de 2 anos, um centro difusor da cultura da qualidade e referncia em teste de software e, com isso, contribuir para a consolidao do Recife como um plo de excelncia na produo de TI. O SOFTEXRECIFE na verdade uma comunidade viva de empresas da rea de Tecnologia da Informao que dispe de um espao institucional para se aperfeioar e promover o seu crescimento e insero no mercado local, nacional e internacional. Em face desse papel, o SOFTEXRECIFE , junto
19
algumas delas para a formao do grupo. A princpio, poucas empresas se interessaram pelo programa de melhoria de processo com base no MR-MPS.BR, que, de certa forma, j era de se esperar, pois o modelo MPS.BR ainda estava se desenvolvendo e em processo de aceitao pelo mercado. Para superar esta dificuldade o SOFTEXRECIFE atuou fortemente junto gesto das empresas filiadas e vrias rodadas de apresentaes sobre melhoria de processo e do modelo MPS.BR foram promovidas, a fim de que os executivos das empresas tomassem conhecimento do modelo. Esta medida surtiu o efeito desejado e conseguimos formar o primeiro grupo de empresas. A segunda cooperativa foi formada em agosto de 2007 e se mostrou mais complexa do que a primeira, visto que o nmero de empresas significativamente maior, e tambm por ser composta de 2 grupos, a saber: um grupo com 5 empresas trabalhando para obter o nvel G, e outro grupo de 4 empresas trabalhando para obter o nvel F. Estes fatores foram amplamente compensados pela experincia adquirida com a primeira cooperativa. De forma geral todas as aes estruturantes da cooperativa anterior foram mantidas, sendo realizados apenas alguns pequenos ajustes no modelo de gesto. Algumas aes foram reforadas por terem apresentado resultados positivos na cooperativa anterior. Dentre elas, podemos destacar: o incentivo a colaborao e, o reconhecimento das particularidades de cada empresa. Enquanto a primeira ao aumenta o comprometimento da empresa; a segunda diminui a resistncia a mudanas, o que muito comum em projetos desta natureza. Os resultados alcanados, com a aprovao de 7 empresas (4 no nvel G e 3 no nvel F) vem confirmar a efetividade do modelo implementado pelo SOFTEXRECIFE, que tem como principio bsico a integrao entre os atores do projeto (IOGE, II e empresas).
O Aprendizado
Analisamos o desempenho obtido nas cooperativas, buscando identificar algumas das prticas adotadas que tenham contribudo para o sucesso do projeto. Pudemos observar que algumas destas prticas no tm nada de inovador, so apenas boas prticas da Gerncia de Projetos, contudo, trouxeram uma tima contribuio para os resultados obtidos. Desde o incio da formao da cooperativa as atividades foram tratadas como um Projeto. Observamos que algumas prticas so prprias do contexto da organizao de trabalhos de forma cooperada. A seguir apresentaremos e comentaremos estas prticas. Critrio para formao do Grupo: ao selecionar os participantes que iro compor o grupo, importante buscar empresas que tenham uma boa afinidade entre si e que no tenha conflitos de interesse. Deve-se tomar o cuidado de no colocar no mesmo grupo empresas que sejam concorrentes diretas, ou que no tenham um bom relacionamento. Na medida do possvel interessante selecionar empresas no mesmo nvel de maturidade. Para que se possa fazer uma seleo e agrupamento adequado das empresas fundamental conhec-las. Para tal,
foram elaborados e aplicados alguns questionrios s empresas. O processo de seleo ocorreu junto com a participao da II (Instituio Implementadora). Subsdio vinculado ao cumprimento das metas: embora as condies estabelecidas pela Sociedade SOFTEX Nacional permitam que as empresas recebam a primeira parcela na assinatura do convnio, o SOFTEXRECIFE achou por bem adotar outra postura. Foi ento definido que, para se obter os subsdios, as empresas teriam que atingir primeiro as metas estabelecidas (50%, 100% e a avaliao). Embora esta abordagem possa dificultar a participao das empresas, ela serve como incentivo e aumenta significativamente o compromisso com o sucesso do projeto. Pudemos perceber que alm do aumento do compromisso, as empresas ficaram motivadas a atingir as metas no menor espao de tempo possvel. Termo de cooperao tcnica: os acordos para a formao da cooperativa foram tratados como Termo de Cooperao Tcnica Financeira e no simplesmente como um Contrato Comercial entre as partes. Tal abordagem explicita que o sucesso do projeto de responsabilidade de todos, e que depende do desempenho do grupo como um todo. Em outras palavras, o sucesso de uma das partes est estritamente ligado ao sucesso das outras partes, sendo o contrrio tambm verdadeiro. Regras claramente definidas: de extrema importncia estar com todas as regras muito bem definidas e compreendidas por todos, antes do incio dos trabalhos. E to importante quanto a sua definio, sua implementao. Para atender este item, realizamos reunies onde as regras administrativas, financeiras e tcnicas foram apresentadas aos participantes do grupo. Isto foi feito antes mesmo da formao oficial do grupo. Relacionamento estreito com a II: um relacionamento estreito entre a II e a IOGE, desde o incio dos trabalhos, foi sem dvida, um ponto fundamental para o sucesso obtido. A relao entre IOGE e II deve ser vista como uma parceria, e no uma simples contratao de prestao de servio. O alinhamento entre estratgia/metodologia de implantao e a gesto da cooperativa primordial para um bom andamento dos trabalhos. Como a II est mais prxima das empresas, participando do seu dia a dia e consegue identificar as dificuldades to logo estas surjam, este relacionamento permite que a IOGE tome medidas antecipadas e at mesmo preventivas de soluo de problemas. Metodologia de trabalho bem definida: ter uma metodologia de trabalho clara e bem definida importante e passa confiabilidade do processo para as empresas. recomendvel que as etapas/fases da metodologia estejam claramente divididas. Uma diviso bem estruturada permite um acompanhamento da evoluo do projeto de forma mais precisa e menos rdua. A SWQuality apresentou uma metodologia de trabalho dividida em 8 fases bem ntidas, e com os resultados esperados para cada uma delas claramente definidos, o que contribuiu para o acompanhamento do projeto. Outro ponto observado, que a utilizao de uma metodologia facilita o nivelamento das expectativas entre as partes envolvidas, e serve como base para o planejamento das atividades da cooperativa.
20
Processo
Figura 1. Organograma do projeto
Canal de comunicao: logo no incio dos trabalhos foi criada uma intranet para que todos os participantes da cooperativa pudessem trocar informao livremente, gerando assim um canal de comunicao. Pela intranet podemos trocar experincias, divulgar notcias, compartilhar material e enviar os comunicados das atividades do grupo. Foi de suma importncia incentivar a comunicao entre as empresas sem que a mesma dependesse do intermdio da IOGE, especialmente para troca de experincias. Incentivo colaborao: observamos que no incio do projeto as empresas ficam relativamente tmidas e resistentes em compartilhar suas experincias, mas funo da IOGE tentar reverter esta situao. importante que a IOGE atue incentivando a todo o momento a constante troca de experincia. No incio as empresas foram obrigadas a apresentar o andamento dos trabalhos para todo o grupo periodicamente. Ocorreram reunies tcnicas para troca de experincias, aprendizado e debate das dificuldades. Com a evoluo do projeto a colaborao tornou-se bastante natural, no sendo mais necessria uma forte interveno da IOGE. Esta postura da IOGE foi bastante elogiada pelas prprias empresas. Reconhecer a particularidade de cada empresa: embora as atividades ocorram de forma cooperada, as particularidades de cada empresa foram a todo o momento respeitadas. Observamos que as empresas evoluem em ritmos diferentes, seja em funo de suas caractersticas ou de uma situao especfica. de extrema importncia respeitar o ritmo de evoluo individual de cada empresa. Para tanto, cada empresa elabora seu prprio cronograma considerando suas particularidades, mas mantendo os pr-requisitos dos marcos definidos pelo cronograma da cooperativa. Esta abordagem permitiu, por exemplo, que uma das empresas evolusse mais rpido e obtivesse o nvel G em menos de 8 meses, enquanto o planejado pela cooperativa era de aproximadamente 12 meses. Definio clara dos papis e responsabilidades: um projeto de cooperativa envolve vrios atores, e cada um com interesses particulares. Por isso a definio clara dos papis e responsabilidades, faz-se extremamente necessrio. A definio dos papis e responsabilidades ocorreu logo no incio do projeto e foi divulgado e aprovado por todos os envolvidos. A Figura 1 ilustra o organograma do projeto.
Na Tabela 1 apresentado os papis no projeto, e descrito quais so as responsabilidades de cada uma das partes. Observe que por parte da empresa foram definidos trs papis, cada um com suas responsabilidades bem delineadas. Grupo Executivo: foi definido um modelo de gesto da cooperativa que estabelece a criao do Grupo Executivo, o qual constitudo por representantes de todas as partes envolvidas: IOGE, II, e um representante de cada empresa. Como podemos observar no Organograma (Figura 1), este o topo da hierarquia, garantindo assim um processo democrtico cooperativa. O Grupo Executivo responsvel por aprovar requisies de mudanas que afetam custo, prazo e/ou escopo, bem como tratar os problemas escalados, e principalmente acompanhar a evoluo do projeto. Esta prtica foi de fundamental importncia para manter o comprometimento do grupo, a clareza dos trabalhos e garantir certa flexibilidade ao grupo. Reunio de acompanhamento: as reunies de acompanhamento foram realizadas ao longo de todo o projeto, sendo mais frequente nas fases iniciais. Nestas reunies cada empresa elaborava e apresentava um relatrio de andamento do projeto e a II apresentava um acompanhamento de cada empresa em relao aos marcos da cooperativa. Em todas as reunies os principais pontos do projeto eram monitorados, como por exemplo: cronograma, consumo dos recursos (horas de consultoria) e questes financeiras. Com isto podemos observar a importncia destas reunies na reduo de conflitos, comunicao e reforo no comprometimento do grupo.
Concluses
A experincia da primeira cooperativa MPS.BR organizada pelo SOFTEXRECIFE em parceria com a SWQuality foi um projeto que conseguiu alcanar todos os seus objetivos tanto na avaliao das empresas, quanto na divulgao do Modelo MPS.BR. O sucesso desta iniciativa pde ser confirmado com a formao da segunda cooperativa. Atendendo demanda, o SOFTEXRECIFE em parceria com a SWQuality, formaram dois novos grupos de empresa. Um grupo com 5 novas empresas para a implantao do nvel G, e um outro grupo, formado por 4 empresas que participaram da primeira cooperativa, agora com o objetivo de implementar o nvel F do modelo MPS.BR.
21
Definio de Papeis e Responsabilidades Papel Grupo Executivo Aprovar requisies de mudanas que afetem custo, prazo ou escopo; Resolver conflitos e problemas escalados; Acompanhar situao do projeto. Acompanhar atividades; Resolver conflitos e problemas; Gerenciar os riscos do projeto; Promover reunio de acompanhamento; Revisar relatrios de homologao; Gerenciar recursos oriundos do Softex Nacional; Aprovar requisies de mudanas que no afetem custo, prazo ou escopo; Gerenciar aes corretivas e/ou preventivas; Gerenciar a comunicao do projeto; Disponibilizar recursos. Apoiar Gerente do Projeto Softex nas questes tcnicas do projeto Realizar homologao de produtos tcnicos da SWQuality Preparar relatrios de acompanhamento; Participar de reunies de progresso; Reportar conflitos e riscos a qualquer momento ao Gerente do Projeto Softex; Gerenciar aes corretivas e preventivas designadas a ele; Manter site tcnico do projeto atualizado. Executar treinamentos e consultorias; Elaborar documentos tcnicos; Reportar status ao coordenador tcnico SWQuality. No mbito do projeto dentro da empresa: Acompanhar progresso do projeto; Resolver conflitos e problemas; Disponibilizar recursos. No mbito do projeto dentro da empresa: Acompanhar progresso do projeto; Reportar status do projeto ao Patrocinador; Gerenciar os riscos do projeto; Gerenciar aes corretivas e/ou preventivas; Homologar servios e produtos prestados pelo projeto; Participar das reunies de progresso agendadas pelo Softex. No mbito do projeto dentro da empresa: Participar das reunies de consultoria e treinamentos do projeto; Reportar status do projeto; Apoiar na identificao de riscos tcnicos do projeto. Responsabilidades
Gerente do Projeto Softex
Coordenador Tcnico Softex Coordenador Tcnico SWQuality
Equipe Consultores
Patrocinador
Gerente do Projeto Melhoria
Equipe Tcnica
Tabela 1. Definio de Papis e Responsabilidades
22
edio ta
Os dois novos grupos de empresas, nvel G e nvel F, adotaram a mesma abordagem da primeira cooperativa e os primeiros resultados foram bastante positivos, com a aprovao de 7 das 9 empresas envolvidas no modelo MR-MPS. A experincia vivida na primeira e segunda cooperativa nos mostra que o incio das atividades o momento crucial para sucesso ou fracasso do projeto. importante que todas as partes tenham conhecimento dos objetivos do trabalho, o esforo esperado, e que as expectativas estejam bem alinhadas e que tenham conhecimento da metodologia de gesto e de execuo das consultorias. Em outras palavras, fundamental um bom planejamento, e um forte comprometimento de todos os envolvidos.
Referncias [MA-MPS] Associao para Promoo da Excelncia do Software Brasileiro SOFTEX. MPS.BR Guia de Avaliao, v 1.0 2006. Disponvel em www.softex.br. [MR-MPS] Associao para Promoo da Excelncia do Software Brasileiro SOFTEX. MPS.BR - Guia Geral, v 1.1 2006. Disponvel em www.softex.br.
A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback
D s
Feedback eu
sobre e s

ITIL: Por onde comear?

Como dar os primeiros passos na implementao desse framework
Veremos como se pode dar os primeiros passos para implementar os processos ITIL com o objetivo de adotar o gerenciamento de servios de TI proposto por esse framework, que um dos pilares da Governana de TI.
Para que serve?

O propsito do ITIL implementar o gerenciamento de servios de TI com o objetivo de garantir a manuteno dos processos de negcio e o alinhamento entre a rea de TI e as demais reas fins da empresa ou cliente externo. Sem o ITIL fica difcil visualizar os servios providos pela rea de TI e garantir o atendimento dos nveis de servio demandados pelo cliente.
Samuel Diniz Casimiro

samuel.casimiro@gmail.com
servidor pblico e trabalha como analista de sistemas em um grande rgo do governo; trabalhou cerca de 10 anos na rea de desenvolvimento de sistemas de um grande banco brasileiro; certificado SCJP, SCWCD e ITILF; especialista em solues J2EE para intranets; consultor de TI para pequenas e mdias empresas; e crtico ferrenho dos modelos de desenvolvimento adotados atualmente nas grandes empresas.
os ltimos trs anos, o ITIL virou uma febre nas reas de TI. Em uma pesquisa realizada em 2007 pelo ITSMF Internacional, em parceria com o captulo Brasil, revelou que, no universo das empresas que investem em gerenciamento de servios de TI, cerca de 23% disponibiliza recursos para ITIL Cobit o framework que vem em segundo lugar, com 16%. Nesse perodo, a demanda por treinamento aumentou vertiginosamente. Os servios de consultoria para implementao

Empresas que vm enfrentando dificuldades em garantir a disponibilidade de seus servios e problemas para alinhar seus esforos com as reas negociais devem considerar a implementao parcial ou total desse framework.
desse framework (veja o quadro O que um framework?) tambm esto em alta. Executivos, gerentes e tcnicos criam enormes expectativas aps um primeiro contato com o assunto. reas inteiras de
23
TI so treinadas, profissionais so certificados e todos correm para a implementao. Projetos so iniciados, diversas reunies so realizadas, consultores preenchem relatrios e muito dinheiro gasto na compra de ferramentas, assessoramento e treinamento. O tempo vai passando e os projetos de implementao, j atrasados, vo sendo prorrogados. Expectativas so frustradas ou, na melhor das hipteses, adiadas. Contratos de consultoria so revistos, gerentes de projetos so substitudos e novas reunies so marcadas. Quando parecia que quase tudo estava pronto, as pessoas comeam a perceber que quase nada foi feito. Essa a situao de vrias empresas brasileiras que tentaram, ou ainda esto tentando, implementar os processos ITIL nos ltimos anos. No preciso fazer uma pesquisa cientfica para perceber isso. Basta aproveitar os eventos de TI e treinamentos para se relacionar com outros profissionais e chegar a essa concluso. Fruns de discusso, sites de comunidades e at o Twitter esto lotados de desabafos e frustraes relacionadas com a implementao desse framework. Tambm no faltam artigos sobre isso. Diante desses problemas, surgem algumas perguntas. Porque as reas de TI esto se esforando para implementar o ITIL? Porque existe tanta expectativa em torno disso? Porque muitas empresas no esto conseguindo implementar esse framework? Quais so os principais problemas? E como podem ser solucionados? Este artigo vai tentar analisar essas e outras questes com o objetivo de oferecer ao leitor um caminho prtico para comear a implementao do ITIL. A meta ser bem sucedido com o menor custo possvel. Afinal, em tempos de crise financeira, as empresas no podem se arriscar a gastar milhes tentando melhorar seus processos quando no se sabe exatamente qual o benefcio financeiro que tero em retorno. Na dvida, portanto, ou as empresas devero tentar implementar os processos ITIL com o menor esforo possvel ou melhor elas tentarem uma outra abordagem.
O que um framework?
Essa palavra muito comum na rea de informtica. Mas muita gente a usa sem nem saber o que realmente significa. A traduo literal de framework armao ou estrutura. Alguns dicionrios traduzem tambm como esqueleto ou arcabouo. O dicionrio Cambridge traduz como estrutura de sustentao arredor da qual algo pode ser construdo. No caso do ITIL, justamente isso! O ITIL um esqueleto, resultado da unio de diversos ossos que so as boas prticas. Entretanto, como um esqueleto, se trata de algo incompleto. Os livros do apenas linhas gerais dos processos. Polticas, fluxos e procedimentos devem ser construdos. Imagine o ITIL como um grande prdio onde existe apenas a estrutura de sustentao. uma estrutura robusta, no se pode ter dvida. Mas levantar as paredes e terminar a construo fica por conta de cada empresa que vai implementar esse framework.
Antes de comear
Existe muita confuso em torno do ITIL. J presenciei verdadeiras discusses sobre qual framework uma empresa deveria adotar. Alguns defendem o ITIL, outros preferem o CMMI, Cobit, ISO, Six Sigma, etc. Esse tipo de discusso s deixa claro que muitos ainda no sabem do qu realmente se trata cada um desses frameworks. Por isso, a primeira coisa a ser feita antes de se pensar em implementar o ITIL entender claramente o que e o que no .
Entenda o que o ITIL

O ITIL mais antigo do que muitos pensam. Surgiu na dcada de 80. Diz a literatura oficial que ele foi encomendado pelo governo britnico para regular os contratos de terceirizao de TI que existiam na poca. Naquela poca, j existia uma forte dependncia de servios de TI e o governo britnico estava insatisfeito com o custo e com a qualidade desses servios.
Contudo, a literatura no oficial sugere que o ITIL surgiu em decorrncia da Guerra das Malvinas, quando o governo britnico, apesar de vencedor, levou uma surra dos argentinos. Como quase toda guerra, a TI foi determinante para a vitria britnica, mais a rainha no ficou nem um pouco satisfeita com as constantes falhas e indisponibilidades dos diversos servios de TI envolvidos no conflito. Foi a que surgiu o ITIL. O ITIL no uma metodologia, to pouco uma certificao, apesar de profissionais poderem ter o seu conhecimento certificado naquele framework. O ITIL um conjunto de melhores prticas para gerenciar servios de TI, assim como o PMBOK um conjunto de melhores prticas para gerenciar projetos mas uma coisa no tem nada a ver com a outra. O foco , portanto, gerenciamento de servios de TI. E o que um servio de TI? tudo aquilo que as reas de TI oferecem para suportar os objetivos de negcio do cliente, seja ele interno ou externo. Essa abordagem precisa ficar clara. A rea de TI que prov os servios de TI e o cliente quem utiliza esses servios. Assim, note que os servios de TI devem estar alinhados com o negcio. O servio algo que o cliente percebe como sendo importante para a operacionalizao do negcio. Isso deixa claro que o gerenciamento de servios no um objetivo por si s e sim um meio de se atingir os objetivos de negcio do cliente. Como essa viso de servios de TI facilita o alinhamento da TI com os objetivos estratgicos da empresa, o ITIL tido como um dos pilares da Governana de TI. As melhores prticas esto contidas em sete livros. Basicamente, cada livro descreve alguns processos que podem ser implementados para viabilizar um gerenciamento de servios de TI bastante robusto. Cada processo descrito como uma srie de aes ou atividades executadas por papis especficos para obter um ou mais resultados importantes no gerenciamento de servios de TI. Apesar de serem sete livros, o foco do ITIL est contido em apenas dois livros, um que trata do Suporte aos Servios e outro que trata da
24
Engenharia de Software Magazine - ITIL: Por onde comear?
Processo
Entrega dos Servios. O contedo desses livros ser tratado em futuros artigos.
MPS.BR, tm tudo a ver com Gerenciamento de Mudanas e Gerenciamento de Liberaes, do ITIL.
No gerenciamento de projetos
Como j foi dito, o ITIL um conjunto de boas prticas para gerenciar servios de TI assim como o PMBOK o para gerenciar projetos. Mas entenda que uma coisa no tem nada a ver com a outra. De um lado estamos falando de servios de TI, geralmente prestados de forma continuada, em que os objetivos esto relacionados com a manuteno de um ou mais processos de negcio. De outro lado estamos falando de projetos, que tm incio e fim determinados, em que os objetivos so produzir algo de novo. Para exemplificar isso, imaginemos um banco. Para suportar o processo de abertura de conta-corrente, a rea de TI desse banco poder prover um servio de TI, composto de um ou mais sistemas, para informatizar os trabalhos. Mas perceba que um servio pode muito bem nascer de um projeto. Quando esse banco trabalha para criar um novo tipo de conta-corrente e os servios de TI relacionados, estamos falando de projeto. Aps a concluso do projeto, quando a rea de TI comear a prover os servios, os processos ITIL entram em ao. Dessa forma, perceba que esses frameworks, apesar de serem completamente distintos e utilizados em situaes e momentos diferentes do negcio, eles so, ao mesmo tempo, complementares. Mesmo assim, muito provavelmente sua empresa iniciar um projeto para implementar o ITIL. Nesse contexto, os processos e tcnicas propostos pelo PMBOK sero teis para auxiliar a gesto do projeto de implementao do ITIL. Fora isso, esses livros, apesar de falarem de gesto de forma geral, tratam de temas bem distintos.
No uma ferramenta
J vi empresas comprando uma ferramenta e dizendo que esto adotando o ITIL na empresa. Mesmo aquelas empresas que entendem que a implementao do ITIL vai muito alm da utilizao de uma ferramenta acabam focando demais nela. Precisamos entender uma coisa de uma vez por todas: Ferramenta a ltima coisa com a qual voc vai ter que se preocupar. ITIL sobre implementar processos e, antes de mais nada, isso envolve definio de atividades e papis, pessoas, normas e treinamento. A ferramenta s deve ser escolhida quando tudo o mais estiver pronto, ou seja, quando os fluxos dos processos estiverem bem definidos e os papis bem acordados. Alm do mais, existem diversas ferramentas disponveis no mercado. E se a sua estratgia de implementao for de implementar um processo de cada vez, talvez seja interessante adquirir apenas os mdulos da ferramenta referentes aos processos que esto sendo implementados naquele momento. Assim, voc dilui o custo de implementao e obtm retorno financeiro mais cedo. Se a sua empresa j possui um ambiente de desenvolvimento e uma intranet, considere desenvolver a sua prpria ferramenta. Utilizar uma ferramenta que tenha a cara da empresa ajudar a reduzir a resistncia das pessoas bem como a diminuir os custos de integrao de uma ferramenta de mercado ao legado que porventura j exista.
No uma abordagem tudo ou nada

Como j foi dito, o ITIL um conjunto de boas prticas. Infelizmente, assim como ocorre com o PMBOK, alguns pensam que precisam implementar tudo. E isso no verdade por vrios motivos! Primeiro, mesmo que voc implemente tudo, entidade alguma vai certificar que a sua empresa 100% ITIL. Isso porque no existe certificao de empresas, tal como ocorre com o MPS.BR ou ISO, apenas certificao de profissionais como j foi dito. Em segundo lugar, no existe nenhuma garantia que, caso voc implemente todos os processos e funes do ITIL, todos os resultados esperados sero obtidos. Em terceiro lugar, o ITIL um conjunto de boas prticas coletadas em diversos setores da indstria de servios de TI. Ento nem tudo se aplicar a sua empresa ou, mesmo que se aplique, os custos dos controles podem superar os benefcios. Portanto, tenha muita cautela ao escolher os processos que sero implementados na sua empresa. V devagar e, aps cada passo, reavalie os resultados obtidos. Talvez com alguns poucos processos voc consiga resolver os problemas que motivaram a implementao desse framework.
No MPS.BR
Qual o melhor framework a se implementar, o ITIL ou o MPS.BR? Resposta: os dois. Apesar de terem alguns processos em comum, esses frameworks so complementares. No ITIL, o foco gerenciar servios de TI que estejam alinhados ao negcio. No MPS.BR, que baseado no CMMI, o foco produzir um software de qualidade que suportar, depois de pronto, um ou mais servios de TI. No primeiro, o objetivo suportar os processos de negcio e garantir que o cliente esteja satisfeito com o servio. No segundo, o objetivo melhorar o processo de desenvolvimento de software para que se possa produzir de forma mais eficiente e eficaz. Algumas empresas preferem comear pela implantao do MPS.BR, alegando que precisam primeiro por ordem na casa para depois poderem se preocupar com os servios de TI que so oferecidos aos seus clientes. Mas muito vai depender do nvel de maturidade que o seu processo de desenvolvimento de software j apresenta. Na dvida, talvez seja interessante intercalar a implementao de alguns processos do MPS.BR com alguns processos de ITIL. Por exemplo, Gerncia de Projeto e Garantia da Qualidade, do
Levante os problemas a resolver

Como foi dito no ltimo pargrafo, importante monitorar se a implementao do ITIL est resolvendo os problemas
25
da empresa e melhorando o provimento dos servios de TI. O problema que muitas empresas nem sequer sabem quais problemas se espera resolver com a implementao desse framework. Sem conhecer esses problemas fica difcil avaliar a implementao e saber exatamente qual foi o retorno obtido. Para evitar isso, importante levantar todos os problemas que se espera serem sanados com a implementao do ITIL. Rena todas as reas interessadas, faa uma lista de problemas, descreva em detalhe cada um deles, suas causas e consequncias e verifique quais deles podem ser resolvidos e quais os processos envolvidos em cada um deles. Essa anlise servir, inclusive, para que se possa decidir sobre quais processos sero implementados primeiro, pois em geral so priorizados aqueles que resolvero o maior nmero de problemas.
os problemas a serem resolvidos, escolheu os processos que sero adotados e definiu polticas para cada um deles. No foi dito, mas vale a pena ressaltar, que todos os envolvidos nesse trabalho que antecede o incio do projeto precisaram ser treinados no ITIL, de outra forma no teriam o correto entendimento do assunto e no saberiam decidir sobre quais processos seriam adotados. interessante que alguns, em especial os gerentes que vo assumir a responsabilidade pelos processos, recebam um treinamento mais avanado tal como o fornecido para obter a certificao de Practioner. Parece pouco, mas esse incio talvez leve um ou dois anos. O marco dessa fase inicial a concluso das polticas e o compromisso formal dos patrocinadores. O projeto de implementao j pode ser iniciado.
Suas polticas esto definidas?

Certos frameworks, como a ISO, deixam bem claro que melhorar a qualidade de produtos ou servios envolve considerar melhorias em trs camadas ou podemos dizer dimenses: Polticas, processos e procedimentos. Isso algo bsico em qualquer framework de melhoria de processos. O MPS.BR, por exemplo, fora a definio das polticas por meio do primeiro resultado esperado para cada processo. No ITIL, a necessidade de definir polticas nem sempre muito clara. A descrio de alguns processos nem sequer menciona uma poltica. Apesar disso, a definio das polticas deve anteceder a implementao de cada processo. Mesmo sendo o ITIL um framework focado no nvel operacional da empresa, ficar muito difcil para o grupo responsvel pela implementao tomar decises sem uma poltica clara do que a administrao da empresa deseja. A no ser que os executivos estejam diretamente envolvidos no projeto, participando de todas as reunies, o que raramente ocorre. Comear com a definio das polticas permitir tambm que as ideias sejam amadurecidas com antecedncia. Isso evitar muita discusso desnecessria, retrabalho, reduzir os custos de implementao especialmente se uma consultoria for contratada e contribuir para uma viso do ITIL mais alinhada com os objetivos estratgicos da administrao. Na prtica, a definio das polticas vai representar a materializao do compromisso da administrao com a implementao do framework algo vital para o sucesso do projeto. Vale ressaltar que o ITIL, apesar de muito popular, no tem muito contedo. Os livros contm apenas linhas gerais para guiar a implementao dos processos. Como no se trata de uma metodologia, faltam alguns detalhes de implementao. Alm das polticas, os procedimentos de cada processo precisaro ser construdos inteiramente pela empresa. Outra coisa que falta no ITIL um ordem lgica para implementar os processos, coisa que o MPS.BR oferece por meio dos nveis de maturidade.
Iniciando um projeto
Dependendo da estratgia que ser adotada, pode-se tratar a implementao de todos os processos que foram escolhidos em um nico projeto ou dividir esses processos em vrios projetos debaixo de um mesmo programa. Alguns preferem criar um projeto por processo ou reunir um grupo de processos afins em um mesmo projeto. Dividir o trabalho em vrios projetos ajuda a diminuir a complexidade, a obter resultados mais cedo e contribui para evitar a recorrncia de problemas na implementao dos processos seguintes graas s lies aprendidas ao final de cada projeto ou processo. Nesse momento os gerentes de projeto so designados e as equipes que trabalharo nos primeiros projetos so alocadas. Mais uma vez, vale ressaltar que, apesar de ser bom ter uma equipe multidisciplinar, importante que todos que trabalharo diretamente no projeto recebam um treinamento mais profundo sobre os conceitos e prticas ITIL. Se a equipe do projeto envolver representantes de vrias reas, o que timo, sugere-se que eles estejam dedicados integralmente ao projeto. Sugere-se tambm que se envolva a auditoria de TI, caso exista uma.
Defina uma estrutura

Se o ITIL for o primeiro framework que a empresa estiver implementando, bem provvel que ainda no exista uma estrutura no organograma da rea de TI que seja responsvel pela gesto de processos e qualidade da TI como um todo. Empresas que j implementaram o MPS.BR, por exemplo, geralmente j tero um departamento responsvel pela gesto dos processos, qualidade e melhoria contnua. Caso j exista uma rea assim, ela uma tima candidata a assumir a gesto de alguns dos processos do ITIL que sero implementados. Diz-se de alguns, e no de todos, porque alguns processos so tipicamente geridos por reas especficas. O processo de incidentes um deles, sendo tipicamente gerido e executado pela central de servios. De qualquer forma, para garantir que a implementao de um processo no se deteriore com o tempo, importante que exista uma rea responsvel pelo monitoramento e qualidade dos processos ITIL. Quando uma rea assim no existe, comum
Comeando
Considerando o contedo apresentado acima, vamos supor que a empresa obteve o entendimento correto do ITIL, levantou
26
Processo
os membros da equipe do projeto assumirem essas funes aps a concluso da implementao. Como essa uma rea tipicamente de controle, interessante que ela esteja ligada diretamente alta administrao ou tenha pelo menos um executivo responsvel por ela. Deixar de criar uma estrutura organizacional para cuidar dos processos e da qualidade um erro comum nas empresas que implementam ITIL. Nesses casos, os gerentes dos processos implementados acabam sendo funcionrios de outras reas que precisaro dividir o tempo deles entre as atividades que j vinham desempenhando e a gesto dos processos envolvendo o gerenciamento de servios de TI. O problema que esses funcionrios acabam por priorizar suas atividades corriqueiras em detrimento dos processos e muito do que foi implementado acaba ficando apenas no papel. Portanto, a criao de uma estrutura responsvel pela gesto dos processos vital para garantir a institucionalizao deles e promover a melhoria contnua. A definio de indicadores, o monitoramento e controle j muito trabalho para ser dividido com outras funes.
ITIL. Os treinamentos para a certificao ITIL Foundation so timos para esse fim, pois so curtos e relativamente baratos. Se no for possvel promover esse curso para todos, tente realizar palestras e workshops sobre o assunto. Promova debates sobre o tema. Crie fruns de discusso. Incentive a colaborao por meio de artigos para resolver determinados problemas levantados pelas equipes dos projetos durante a implementao e premie as melhores contribuies. Isso vai criar um clima de compromisso e expectativa vitais para o sucesso.
Defina a estratgia
Com base nas polticas que foram definidas e nos problemas que foram levantados, pode-se agora definir qual ser a estratgia de implementao. J se falou sobre a possibilidade de criar projetos para cada processo ou um projeto para todos. Mais ainda restam duas perguntas: Quais processos implementar? E em qual ordem os processos devem ser implementados? Vamos tentar responder primeira pergunta. Como j foi mencionado, o ITIL no utiliza uma abordagem tudo ou nada. Trata-se de um repositrio de boas prticas, de onde se pode selecionar aquelas que melhor se adquam realidade da empresa. Um bom ponto de partida a anlise dos problemas que foram levantados antes do projeto. Quais os principais problemas que a rea de TI vem enfrentando? Como a abordagem de gesto de servios de TI pode contribuir para resolver esses problemas? Quais processos sugeridos pelo ITIL esto diretamente relacionados com esses problemas? As respostas dessas perguntas devem indicar os processos mais importantes. Contudo, aqui vai uma palavra de cautela. Apesar de no ser obrigatria a adoo de todos os processos, importante verificar que existe uma certa dependncia entre alguns deles. Talvez a sua anlise de problemas aponte apenas alguns processos. Mas s vezes no se pode obter todos os resultados esperados implementando apenas um processo isoladamente. claro que os processos definidos como prioritrios podem e devem ser focados. Os processos dependentes podem ficar para depois. Como j foi considerado, processos afins podem ser agrupados em um mesmo projeto. Sabendo quais os processos que sero implementados, agora o momento de decidir a ordem de implementao deles. Em geral, no vivel implementar todos de uma vez s, mesmo que sejam apenas aqueles priorizados pela anlise acima. Implementar muitos processos de uma vez s requer muitas pessoas e pouco provvel que elas possam interromper suas atividades corriqueiras para se dedicarem ao projeto. Tenha em mente que implementar o ITIL geralmente leva de um a dois anos. Portanto, no crie falsas expectativas. D um passo de cada vez, ou seja, cada processo a seu tempo. Independentemente da sua anlise, bem provvel que sua empresa implementar os processos de gerenciamento de incidentes e o de mudanas. Esses so processos chaves que no podem ser desconsiderados por nenhuma empresa.
Traga as pessoas para o seu lado

Preste ateno na Figura 1. A engrenagem people, pessoas, no a maior por mero acaso. As pessoas so a parte mais importante em qualquer framework de melhoria de processos. No adianta desenhar processos perfeitos se as pessoas no souberem ou no estiverem a fim de execut-los. J falamos aqui sobre treinamento de executivos, gerentes e da equipe do projeto de implementao. Mas sero outras pessoas que vo executar as atividades de cada processo, que vo exercer papis nesses processos. Por isso, importante convencer tambm esses de que o ITIL vai trazer melhorias e no simplesmente ordenar-lhes que executem os procedimentos. E, para isso, nada melhor do que uma boa dose de catequizao
Figura 1. Aspectos vitais do ITIL
27
As caractersticas desses dois processos e os timos resultados que podem ser obtidos com a implementao deles os tornam bons candidatos para comear a implementao. o que ser analisado no tpico a seguir.
servio para poder ter um catlogo de servios. A definio do catlogo de servios , portanto, prioridade tambm.
Providenciar uma ferramenta

A pergunta que precisa ser respondida : De que ferramentas precisamos para comear a implementao do ITIL? J foi mencionado que a construo de uma CMDB prrequisito para vrios processos ITIL. Assim, a primeira ferramenta de que precisamos uma soluo para criar e manter uma base de todos os ativos de TI de uma organizao e os relacionamentos entre eles. uma base de metadados e no dos ativos propriamente ditos. Essa base precisa basicamente guardar quatro tipos de informao: descrio do ativo, rea tcnica responsvel, relacionamentos com outros ativos e relacionamentos com os servios. Estruturar uma base assim bem simples. O difcil alimentar os dados. Existem algumas ferramentas disponveis no mercado, comerciais ou open-source, que varrem a estrutura de TI via rede e catalogam automaticamente os ativos encontrados. Outra opo catalogar os ativos de TI medida que incidentes so encontrados ou mudanas so solicitadas. Dado esse primeiro passo, o prximo vai depender da estratgia de implementao. Se uma empresa resolveu comear pelo gerenciamento de incidentes e central de servios, ela vai precisar basicamente de uma ferramenta tpica de help-desk com funes de workflow para repassar as solicitaes. Por outro lado, se a estratgia adotada foi comear pelo gerenciamento de mudanas, de uma ferramenta de controle de mudanas que a empresa vai precisar. E importantssimo que essa ferramenta esteja integrada CMDB. A escolha de uma ferramenta vai depender muito do tamanho da rea de TI. Ao passo que microempresas podem implementar diversos controles em uma simples planilha, empresas maiores acharo por bem adquirir ferramentas comerciais mais robustas. Nesse sentido, os fornecedores mais comuns so a BMC, com a sua sute Remedy, a CA, com o Unicenter, a HP, com o Openview, e finalmente a IBM, com o Tivoli. Mas vale ressaltar a que implementao do ITIL pode envolver diversas outras ferramentas, dependendo dos fluxos que foram definidos para cada processo.
Incidentes x mudanas
Historicamente, a grande maioria das reas de TI tem comeado a implementao pelo gerenciamento de incidentes. Parece uma boa opo, mas em geral ela tomada com base em palpites. O gerenciamento de incidentes permite que os servios de TI de uma empresa sejam rapidamente restabelecidos em caso de indisponibilidades. Assim, por meio desses processos, possvel garantir a satisfao dos clientes com os servios prestados. Esse um dos principais motivos pelo qual empresas no mundo inteiro comeam com o gerenciamento de incidentes. Entretanto, recentemente algumas empresas tm deixado essa abordagem de lado e passaram a iniciar suas implementaes pelo gerenciamento de mudanas. Isso tem ocorrido porque boa parte dos problemas que afetam a disponibilidade dos servios de TI tem sua origem em um gerenciamento de mudanas mal feito e precrio. De fato, com um gerenciamento de mudanas ruim, a rea de TI vai ficar constantemente apagando incndios, ou seja, resolvendo indisponibilidades. E isso acaba sobrecarregando pessoas que, de outra forma, poderiam estar produzindo novas solues e viabilizando mais servios de TI. Por essas e outras, o gerenciamento de mudanas parece ser a escolha mais natural para comear, pois dele dependem o gerenciamento de incidentes, de problemas e de liberao, s para citar alguns.
CMDB
Mas da alguns talvez possam dizer: Ah, mas o gerenciamento de mudanas depende do gerenciamento de configurao, ento melhor comear por ele. Resposta: sim e no. Sim, considerando que o gerenciamento de mudanas s alcanar sua plenitude se trabalhar em cima de uma base de dados de configurao (CMDB) 100% confivel. E no porque no precisamos ter o gerenciamento de configurao para ter uma CMDB. Agora, uma coisa certa, nenhum processo funcionar sem uma CMDB. essa base que apontar os ativos de TI do qual dependem cada servio de TI e isso o que viabilizar vrios outros processos como o gerenciamento de mudanas, de liberao, de disponibilidade, etc. Portanto, se a empresa ainda no tiver uma CMDB, fazer o inventrio dos ativos de TI e mapear os relacionamentos entre eles um timo ponto de partida, algo a se fazer antes de implementar qualquer processo.
Passo-a-passo resumido
Considerando o que foi apresentado acima, chegamos ao seguinte passo-a-passo resumido para comear a implementao dos processos ITIL: Obter a correta compreenso do framework, treinando executivos e gerentes; Levantar os problemas da rea de TI que poderiam ser resolvidos com a implementao; Escolher os processos que sero implementados; Definir polticas para cada processo; Escolher a estratgia de gerenciamento de projetos que ser utilizada na implementao; Definir a equipe do projeto de implementao e fornecer treinamento avanado;
Catlogo de servios
Do catlogo de servios tambm dependem todos os demais processos do ITIL, afinal estamos falando em gerenciamento de servios. Contudo, tal como ocorre com o CMDB, no necessrio implementar o gerenciamento de nvel de
28
Processo
Trazer as demais pessoas para o seu lado por meio de treinamento, oficinas e promoes; Escolher a ordem de implementao dos processos; Montar o CMDB; Publicar o catlogo de servios; Implementar os processos na ordem definida; Rever lies aprendidas ao final de cada projeto ou marco; Providenciar uma ferramenta.
Links 10 things you should know about ITIL http://articles.techrepublic.com.com/5100-10878_11-6134345.html Change management: A better starting point for ITIL http://searchcio.techtarget.com/news/column/0,294698,sid182_gci1242026,00.html ITIL and Configuration Management: Where to begin http://articles.techrepublic.com.com/5100-22_11-6177192.html ITIL Implementation: Where to Start and Pitfalls to Avoid! http://www.kpeak.com/ITIL%20Implementation%20-%20Sept%20%2706%20SIG.pdf ITIL process success: Get people on your side http://searchcio.techtarget.com/news/column/0,294698,sid182_gci1249840,00.html ITIL: Top five tips to kick-start your strategy h t t p : / / s e a rc h c i o. t e c h t a rg e t . c o m / t i p / 0 , 2 8 9 4 8 3 , s i d 1 8 2 _ g c i 1 3 1 5 2 9 8 , 0 0 . html?mboxConv=searchSecurity_RegActivate_Submit& Where to begin implementing service management http://articles.techrepublic.com.com/5100-10878_11-1058518.html
Concluso
Este artigo mostrou a importncia de se obter um correto entendimento do ITIL antes de iniciar a implementao desse framework. Para reduzir o tempo e o custo de implementao, as empresas fazem bem em levantar seus problemas e definir suas polticas antes mesmo de contratar uma consultoria e/ou iniciar um projeto para a implementao de processos ITIL. Outra coisa que vale a pena ser destacada a necessidade de deixar a ferramenta por ltimo, de forma que seja possvel obter uma que se adque a tudo o mais que tenha sido definido. Por fim, mostrou-se que praticamente todos os processos ITIL dependem do CMDB e do catlogo de servios. Por isso, vital que estes sejam providenciados antes da implementao de qualquer processo.
Existem coisas que no conseguimos ficar sem!

...s pra lembrar, sua assinatura pode estar acabando!
Renove J!
AMIGO
www.devmedia.com.br/renovacao
Para mais informaes: www.devmedia.com.br/central
edio ta
D s
Feedback eu
sobre e s
29

Arquitetura Orientada a Servios

Sobre o que voc precisa refletir para adot-la em um contexto empresarial
SOA traz diversos benefcios em um contexto empresarial. Porm no podemos simplesmente comprar uma SOA em uma prateleira. Neste intuito, este artigo discute alguns desafios e ingredientes que devem ser considerados e pensados na adoo de uma SOA.
E
Jorge Dias Jr.
josejorgejr@gmail.com www.jorgediasjr.com
Doutorando em Cincia da Computao (UFPE). Mestre em Cincia da Computao (UFPE). Graduado em Cincia da Computao (UFPB). Desenvolve pesquisas na rea de SOA desde 2005. Possui vrios artigos publicados em conferncias nacionais e internacionais. Tem experincia como analista de TI na indstria, onde desenvolveu sistemas no mbito do governo federal, alm de ter atuado em vrios projetos da iniciativa privada. Atualmente, professor e pesquisador no Departamento de Cincias Exatas da UFPB, Campus IV.
m seu livro, Josuttis faz a seguinte afirmao sobre Arquitetura Orientada a Servio (SOA): O problema que voc no pode simplesmente comprar SOA, voc tem que entend-la e viv-la. SOA um paradigma. SOA uma maneira de pensar. SOA um sistema de valores para a arquitetura e design [Josuttis, 2007]. Isso quer dizer que, assim como o paradigma de Orientao a Objetos, o paradigma Orientado a Servios requer aspectos tecnolgicos e no tecnolgicos para ser bem sucedido. Ou seja, alm do amparo ferramental, necessrio um conjunto de mtodos, tcnicas, processos e boas prticas para adotar uma SOA com sucesso. Este artigo no tem o objetivo de apresentar um passo a passo de como adotar uma SOA em uma empresa, mas de mostrar alguns dos desafios e ingredientes que devemos ter em mente e que precisamos definir para implantarmos uma SOA, minimizando os riscos e as chances de fracasso.
Para que serve?

Mostrar alguns dos desafios e ingredientes que devemos ter em mente e que precisamos definir para implantarmos uma SOA em um contexto empresarial, minimizando os riscos e as chances de fracasso.

Em um contexto empresarial, SOA permite que organizaes com infra-estrutura de aplicaes fragmentadas, sob a administrao de diferentes reas de negcio, possam integrar estas aplicaes no nvel de servio. Alm disso, SOA permite um maior alinhamento da TI com o negcio. Tendo estes benefcios em mente, importante considerar os aspectos tecnolgicos e no tecnolgicos que podem influenciar o sucesso de sua adoo.
Conceitos iniciais
Existem diversas definies sobre SOA e servio, porm nenhuma delas tida como a oficial. Muitas destas definies
30
Engenharia de Software Magazine - Arquitetura Orientada a Servios
PROJETO
vm de fornecedores que as definem de acordo com as solues que eles fornecem. Alguns exemplos de grandes fornecedores so a IBM, Microsoft e Oracle. Iremos definir SOA de uma maneira bem simples: SOA uma forma de se projetar uma arquitetura baseada na composio de servios interoperveis e reutilizveis. A Figura 1 mostra os principais elementos de uma SOA: o fornecedor do servio aquele que implementa e tem domnio sobre um servio; o registro de servio um repositrio onde fornecedores de servio podem registrar seus servios para que eles sejam localizados pelos consumidores; e o consumidor do servio aquele que localiza um servio e o executa. O contrato a especificao do servio que possui as informaes necessrias para que o consumidor possa localiz-lo e invoc-lo.
A Figura 2 ilustra esta idia. Perceba que os diferentes departamentos de uma empresa possuem diferentes sistemas de software que podem ser um CRM, um ERP, ou qualquer outro sistema que automatize processos de negcio do seu departamento. A idia disponibilizar a lgica desses sistemas em forma de servios interoperveis e reutilizveis. Acima desses servios, existe uma camada onde esto os processos de negcio que so executados atravs da invocao dos servios, ou seja, os servios so chamados em uma seqncia lgica de acordo com os processos organizacionais. Neste cenrio, novas aplicaes clientes, com pouca ou nenhuma lgica de negcio, podem ser desenvolvidas em cima destes processos de negcio. Neste caso, estas aplicaes clientes funcionam simplesmente como entrada e apresentao dos dados.
Figura 1. Principais elementos de uma SOA
Esta a idia simplista que temos sobre SOA. A seguir vamos analisar SOA em um contexto empresarial e quais os benefcios que este tipo de arquitetura traz para as organizaes.
Figura 2. SOA em um contexto empresarial
SOA em um contexto empresarial

Atualmente, muitas organizaes possuem um conjunto de diferentes sistemas, aplicaes e arquiteturas com diferentes idades, tecnologias e plataformas. Alm disso, os processos de negcio destas organizaes esto sujeitos a mudanas, ou devido a alguma reestruturao de negcio, ou talvez devido abertura para novos parceiros de negcio. Neste contexto, como os sistemas da organizao conseguiro acompanhar estas mudanas? Este um cenrio ideal para se pensar em adotar uma SOA. Neste contexto empresarial, SOA permite que organizaes com infra-estrutura de aplicaes fragmentadas, sob a administrao de diferentes reas de negcio ou departamentos, possam integrar estas aplicaes no nvel de servio. Portanto, as aplicaes destes departamentos se tornam fornecedores e consumidores de servios de outros departamentos. Alm disso, servios representam bem funes de negcio e, portanto, so considerados uma boa maneira para desenvolver aplicaes que suportam processos de negcio, permitindo assim, alinhar TI s necessidades organizacionais. Cada servio representa uma determinada funcionalidade que mapeada para um passo, ou vrios passos, em um processo de negcio.
O cenrio ideal que analistas de negcio da organizao possam fazer alteraes nos processos e que isso seja refletido automaticamente no sistema empresarial como um todo, sem precisar alterar nenhuma linha de cdigo. Esta a idia Run what I just drew, ou seja, execute o que eu acabei de desenhar. Este um dos focos da rea de BPM (Business Process Management). Atualmente, os conceitos de SOA e BPM esto bem relacionados e, por este motivo, as pessoas os confundem, achando que estas idias de gerenciamento de processos pertencem a SOA. SOA d o suporte tecnolgico e metodolgico para expor servios de negcio. J BPM tem como objetivo capturar, projetar, executar, gerenciar e monitorar processos, geralmente atravs de ferramentas visuais. Como estes temas esto bem interligados, ao longo deste artigo, iremos nos referir apenas ao termo SOA, sabendo que as idias de BPM esto incorporadas a ela. importante dizer que este o cenrio que SOA, juntamente com BPM, pode alcanar. Porm, SOA tambm pode ser utilizado em outros cenrios mais simples que no envolva BPM.
Benefcios na adoo de SOA

A adoo de SOA traz alguns benefcios devido s suas caractersticas. Esta lista de benefcios no est completa, e
31
apenas uma indicao do potencial que essa plataforma arquitetural pode oferecer. Flexibilidade Como foi dito, todo sistema empresarial est sujeito a mudanas. Ele precisa continuamente ser adaptado para suportar novos requisitos devido s necessidades que envolvem o mercado, mudanas na lei, ou mesmo reorganizaes de negcio. Portanto, a arquitetura empresarial deve ser configurada de maneira flexvel. As caractersticas de SOA possibilitam o desenvolvimento de novos servios de negcio e permitem que uma organizao reuse estes servios a fim de responder a estas mudanas. Manutenabilidade A comunicao entre o consumidor e o fornecedor baseada em interfaces bem definidas e padronizadas. Esta caracterstica aumenta o poder de manutenabilidade dos sistemas empresariais porque os detalhes de implementao ficam escondidos. Reusabilidade Reusabilidade tem sido um dos maiores objetivos da engenharia de software nos ltimos anos, com diferentes graus de sucesso. Na SOA, a habilidade de compor novos servios a partir de servios existentes fornece uma maior possibilidade para o reuso e uma vantagem distinta para uma organizao que tem que ser gil para responder s necessidades de negcio. Desta maneira, o desenvolvimento das aplicaes atravs do reuso de servios torna mais rpido, aumenta a qualidade e diminui os custos de desenvolvimento e tempo de entrega. Integrao Como j foi dito, muitas organizaes possuem uma infraestrutura de aplicaes fragmentadas na qual uma variedade de aplicaes clientes tm que ser criadas utilizando mltiplas plataformas de programao e comunicao. Neste contexto, SOA pode facilitar a integrao de sistemas heterogneos j que a idia disponibilizar a lgica desses sistemas em forma de servios interoperveis.
os modelos de processos de negcio destas reas organizacionais. Alm disso, importante que estejam claras as expectativas e necessidades de cada rea em relao implantao da SOA. Como foi explicado, SOA uma boa soluo para integrao. Mas no adianta tentar integrar sistemas de diferentes unidades organizacionais se estas no esto integradas no nvel de negcio. Portanto importante, primeiramente, integrar as reas de negcio e seus processos. Processo Para desenvolver servios que atendam os princpios da abordagem orientada a servios, so necessrios tcnicas, mtodos e boas prticas de design especficas. O processo de desenvolvimento de servios envolve duas etapas: desenvolvimento para reuso e desenvolvimento com reuso. O primeiro se preocupa em desenvolver servios para que eles se tornem os mais reutilizveis possveis. O segundo criar aplicaes reutilizando os servios existentes. Existem algumas metodologias encontradas na literatura. Algumas delas tentam dar suporte a todo o ciclo de vida de SOA, incluindo atividades de planejamento, anlise e projeto, construo, teste, implantao e governana, enquanto outras limitam seu escopo a um subconjunto destas atividades. Entretanto, este artigo no tem o objetivo de detalhar nenhuma dessas metodologias, mas de apenas dar uma noo geral de atividades que podem fazer parte de uma metodologia orientada a servios. comum, em um contexto empresarial, existirem diferentes reas de negcio onde cada uma possui seu prprio time de desenvolvimento. Neste contexto, sob a perspectiva de processo de desenvolvimento, um dos principais benefcios de usar SOA, que ela possibilita um alto grau de modularizao. Esta caracterstica permite que os servios possam ser implementados por diversos times. Evidentemente, estes times devem respeitar os contratos de servios. A Figura 3 ilustra um processo de desenvolvimento para SOA. O processo possui duas fases. A primeira fase objetiva especificar a SOA empresarial como um todo, definindo, entre outras coisas, os servios que iro compor a SOA. Uma vez definidos os servios, estes so alocados para os diferentes times de desenvolvimento que tem a responsabilidade de construir os servios sob sua responsabilidade [Dias, 2009].
Ingredientes para adoo

Como foi dito anteriormente, SOA no s tecnologia. SOA um conceito amplo, que envolve outros aspectos para que sua adoo tenha sucesso em um contexto empresarial. Neste sentido, podemos citar quatro ingredientes fundamentais para o sucesso de uma SOA: organizao, processo, tecnologia e governana. Organizao No adianta tentar implantar uma SOA sem alinhar a TI com o negcio. Para tanto, necessrio entender a estrutura organizacional, suas reas e unidades, assim como os processos de negcio de cada uma delas. Neste sentido, necessrio revisar, caso existam, ou criar, caso no existam,
Figura 3. Processo de desenvolvimento de uma SOA em um contexto empresarial
32
PROJETO
As prximas subsees discutem algumas atividades que devemos considerar ao projetar uma arquitetura de sistema baseado em SOA. Porm, no significa que estas atividades so o suficiente para projetar uma SOA com sucesso, mas apenas um indicativo para mostrar que, para termos uma SOA de sucesso, no precisamos apenas de tecnologia, mas tambm de uma arquitetura bem projetada. Identificao de servios Esta uma das mais importantes atividades do projeto orientado a servios. O objetivo descobrir os servios que compe a SOA. Em um contexto empresarial onde existem diversas reas de negcio, importante a participao de todos os interessados, no s dos que fazem parte da rea tecnolgica, mas tambm daqueles que so especialistas nos processos de negcio de sua rea. Isto porque os servios precisam representar bem as funes de negcio destes processos. A maioria das tcnicas para identificar servios baseada nos modelos de processos de negcio. Por isso importante ter estes modelos bem especificados. Aplicao dos princpios da orientao a servios Da mesma forma que o paradigma orientado a objetos possui um conjunto de princpios que devem ser satisfeitos, o paradigma orientado a servios tambm possui princpios especficos que devem ser seguidos. Depois que os servios so identificados, importante garantir que eles atendam a estes princpios da orientao a servio. Entretanto, no existe uma lista oficial destes princpios. Thomas Erl, em seu livro SOA Princpios de design de servios, lista um conjunto de princpios que devem ser atendidos, tais como: contratos, acoplamento, abstrao, capacidade de reuso, autonomia, independncia de estado, visibilidade e composio de servios. Especificao dos atributos de qualidade Escolher uma arquitetura que satisfaa aos requisitos funcionais e aos requisitos no funcionais (atributos de qualidade) vital para o sucesso de qualquer sistema. Para SOA no diferente. importante entender como uma SOA suporta os diferentes atributos de qualidade e quais so suas implicaes para criar um projeto com sucesso. Neste sentido, as pessoas interessadas e envolvidas na definio da SOA precisam definir e priorizar os atributos de qualidade que iro ser satisfeitos pela SOA. Alguns atributos de qualidade so: interoperabilidade, performance, segurana, confiabilidade, disponibilidade, escalabilidade, testabilidade, adaptabilidade e reusabilidade. Para cada atributo definido, necessrio especificar como ele ser garantido, seja atravs de aplicao de boas prticas de projeto, seja atravs de tecnologias. Especificao dos contratos de servios Uma vez conhecidas as interfaces dos servios e seus respectivos fornecedores e consumidores em potencial,
importante definir os contratos destes servios. Um contrato de servio contm os termos acordados pelo fornecedor e consumidor do servio. Algumas informaes importantes que o contrato deve abranger so as seguintes: interface do servio: o nome e as operaes do servio; mensagens do servio: as mensagens que o consumidor e o fornecedor iro trocar para executar o servio; os tipos de dados tambm devero ser especificados; pr e ps condies: as pr e ps condies de cada operao do servio; atributos de qualidade: os atributos de qualidade que o servio dever satisfazer; consumidores potenciais : a lista dos consumidores conhecidos; fornecedor: a entidade, a rea, o sistema que ir fornecer o servio; SLA: se houver um Service-Level Agreement envolvido no contrato, ele dever ser especificado. Projetar e construir servios Depois de projetar a arquitetura baseada em SOA, os servios identificados sero alocados para os times de desenvolvimento. Cada time de desenvolvimento deve analisar, projetar, construir e testar os seus servios. Para tanto, importante observar os atributos de qualidade especificados na fase de definio da SOA. Alm disso, o contrato de servio deve ser respeitado. A equipe dever tomar decises de como expor as funcionalidades dos seus sistemas (caso existam) em forma de servio. Tecnologia Atualmente, existe uma variedade de tecnologias relacionadas SOA. Porm, no necessrio utilizar todas as tecnologias para dizer que est implementando uma SOA. Por outro lado, o fato de apenas utilizar uma das tecnologias no quer dizer necessariamente que est usando SOA. Outra questo importante que SOA no est presa a nenhuma tecnologia. Porm, evidente que algumas tecnologias j conhecidas so ditas como a melhor forma de se implementar uma SOA, como por exemplo Web Services. Abaixo seguem algumas das tecnologias relacionadas SOA [Davis, 2009]: Web Services Para descrever Web Services, podemos seguir as definies de alguns fornecedores e institutos de pesquisa, como o Gartner: so componentes de software com baixo fator de acoplamento, utilizados por meio de padres de tecnologia Internet. Um Web Service representa uma funo de negcio ou um servio que pode ser acessado por uma outra aplicao, sobre redes pblicas e, geralmente, disponibilizado por protocolos conhecidos. Web Service pode ser visto como um framework de tecnologias que permite a comunicao entre aplicaes heterogneas atravs de servios interoperveis,
33
onde estes servios podem ser localizados e executados atravs de protocolos padronizados. As trs especificaes conhecidas do Web Services so o SOAP como protocolo de comunicao, o WSDL como padro de descrio de servios e o UDDI como padro de registro de servio. Enterprise Service Bus (ESB) Um ESB pode ser visto como um middleware que tem o objetivo de facilitar a integrao de sistemas. Geralmente um ESB possui as seguintes funcionalidades: prover segurana, prover transparncia de localizao, transformar mensagens, rotear e monitorar as mensagens, gerenciar os servios, entre outros. Existem muitos produtos de ESB disponveis no mercado atualmente de fornecedores como IBM, TIBCO, Microsoft e Oracle. A maioria desses produtos tem um background do mercado de EAI (Enterprise Application Integration). Porm tambm existem solues open source tais como Mule, ServiceMix, OpenESB e JBossESB. Para quem quer se especializar mais nestes ESBs open source recomendo o livro Open Source ESBs in Action [Rademakers, 2009]. Business Process Management System (BPMS) Esta ferramenta permite a gesto automatizada dos processos de negcio da organizao. Como foi dito, os servios representam funes de negcio na organizao. Neste sentido, os servios podem ser orquestrados representando fluxos de execuo dos processos de negcio. O BPMS fornece estes recursos, permitindo a execuo, controle e monitorao desses fluxos. Geralmente uma ferramenta de BPMS possui as seguintes caractersticas: ferramenta para modelagem e desenho do processo; engenho de execuo do processo; orquestrao de Web Services e interface de workflow para usurios. Enterprise Decision Management (EDM) Um sistema EDM incorpora uma mquina de regra de negcio para execuo de regras de negcio definidas e um sistema para gerenciar estas regras. Uma regra de negcio uma instruo bem definida relacionada ao negcio, que faz alguma afirmao sobre algum aspecto de como o negcio deve funcionar. A idia de um sistema baseado em regras, ou EDM, separar as regras do cdigo do programa, deixando estas regras centralizadas, permitindo que as aplicaes ou servios utilizem-nas. Repositrio Os artefatos gerados em uma SOA devem ser registrados dentro de um repositrio para proporcionar o reuso e fornecer infra-estrutura para gerenciamento dos ativos. Estes ativos podem incluir servios, processos de negcio, orquestraes, regras de negcio, entre outros. Para pequenas organizaes, repositrios informais podem ser utilizados, como por exemplo um wiki ou uma base de
dados simples que descrevem os diversos ativos. Porm, para grandes organizaes, interessante ter um repositrio mais profissional e focado nos ativos da SOA. Governana A Gartner declarou que a carncia de planejamento relacionado governana ser o principal motivo dos fracassos em SOA. Um estudo realizado pelo SOA Forum mostra que as polticas de governana so insuficientes em 88% das organizaes, o que pode comprometer o projeto. Ainda segundo a Gartner, Governana SOA est relacionada garantia de que os ativos de software e artefatos da sua arquitetura esto operando como esperado e dentro de um certo nvel de qualidade. Na SOA, consumidores de servio e fornecedores de servio so executados em diferentes processos, so desenvolvidos e gerenciados por diferentes departamentos e exigem um grande esforo de coordenao para trabalharem juntos com sucesso. Para SOA ter xito, mltiplas aplicaes precisam compartilhar servios, o que significa que eles precisam ser coordenados para se tornarem comuns e reutilizveis. Estes so os problemas de governana e eles so muito mais complexos do que nos dias de aplicaes monolticas ou mesmo nos dias de componentes e cdigos reutilizveis [InfoQ, 2009]. Para o sucesso da governana numa organizao importante a combinao de pessoas, processos e tecnologias. Alm disso, estando presente essa preocupao desde o incio da implantao da SOA, a transio mais confortvel para a empresa, alm de ajudar no estabelecimento do alinhamento necessrio entre as reas de negcio e a rea de TI, to importante para pontos como a reduo de custos e retorno de investimento.
Desafios
De acordo com um estudo feito pela InformationWeek [InformationWeek, 2008], 32% dos projetos SOA no atenderam s expectativas. Como qualquer mudana de paradigma, a adoo de SOA envolve muitos riscos e desafios. Alm do desafio de se definir os aspectos discutidos anteriormente como organizao, processos, tecnologias e governana, existem alguns outros que devem ser considerados. Abaixo segue alguns dos limitadores para se adotar SOA. Cultura Todas as empresas possuem sua prpria cultura, suas crenas e suas formas de executar suas atividades. A implantao de uma SOA em uma organizao far com que algumas pessoas tenham que mudar um pouco sua forma de pensar em relao a algumas atividades que elas executam. Qualquer mudana de paradigma passvel a resistncia. Neste sentido, importante primeiro convencer as pessoas envolvidas e interessadas no projeto SOA sobre seus benefcios. importante que todas as pessoas envolvidas estejam motivadas e interessadas na transio para SOA.
34
PROJETO
Falta de conhecimento Muitas pessoas acham que para adotar uma SOA necessrio comprar uma caixa com uma soluo SOA pronta. Mas como vimos ao longo deste artigo, a adoo de SOA exige outros conhecimentos para ter sucesso. Neste sentido, importante que a empresa que queira adotar uma SOA busque estes conhecimentos necessrios ou ento contrate uma consultoria externa. Falta de um projeto piloto Como diz o ditado popular: a pressa inimiga da perfeio. Quando queremos realizar grandes mudanas em uma empresa, importante que elas sejam feitas de maneira planejada e que primeiro se realize um projeto piloto, diminuindo assim os riscos. Com SOA no diferente. Deve-se escolher um projeto piloto e execut-lo de maneira controlada para analisar os riscos. Falta de comprometimento Como foi dito, a adoo de SOA envolve muitas mudanas em uma organizao. Por esta razo importante ter uma equipe ou uma pessoa totalmente envolvida nestas questes.
Links Site do DCE/UFPB http://www.ccae.ufpb.br/dce SOA Forum http://www.soaforum.org Referncias [InformationWeek, 2008] Smith Roger. A simpler approach to SOA (2008). Disponvel em http://www.informationweek.com/news/software/soa/showArticle. jhtml?articleID=209904293 [Josuttis, 2007] Josuttis, N. SOA in Practice The Art of Distributed System Design. OReilly, 2007. [Erl, 2008] Erl, Thomas. SOA Princpios de design de servios. Prentice Hall, 2008. [Davis, 2009] Davis, Jeff. Open Source SOA. Manning, 2009. [Rademakers, 2009] Rademakers, T., Dirksen, J. Open Source ESBs in Action. Manning, 2009. [Dias, 2009] Dias, J. J.; Almeida, E. S.; Meira, S. R. L. A Systematic SOA-based Architecture Process, 21st International Conference on Software Engineering and Knowledge Engineering (SEKE), Service Oriented Architecture Track, Boston, U.S., 2009. [InfoQ, 2009] Artigo da InfoQ. Como Alinhar Processos de TI e Governana SOA para suportar Iniciativas BPM? (2009) Disponvel em http://www.infoq.com/br/ news/2009/02/process-it-soa-governance.
Consideraes Finais
Vimos neste artigo que a adoo de SOA em um contexto empresarial pode trazer vrios benefcios, porm envolve tambm muitos desafios, sendo necessrio um bom conhecimento no s das tecnologias que do suporte a SOA, mas tambm de todo o ciclo de desenvolvimento de uma SOA. Entretanto, SOA no a soluo para todos os problemas. Cada caso deve ser analisado de forma apropriada para que seja avaliado o seu custo e se o retorno do investimento interessante.
edio ta
D s
Feedback eu
sobre e s
35

Arquitetura de Software
Atributos para decises do projeto arquitetural
Apresenta um conjunto de informaes que podem subsidiar decises de projeto arquitetural de sistemas de software.
Para que serve?

Entender o papel do projeto arquitetural dentro do processo de desenvolvimento de software orientado para arquitetura e identificao de informaes necessrias s decises de projeto.
Antonio Mendes da Silva Filho

antoniom.silvafilho@gmail.com
Professor e consultor em rea de tecnologia da informao e comunicao com mais de 20 anos de experincia profissional, autor do livros Arquitetura de Software e Programando com XML, ambos pela Editora Campus/Elsevier, tem mais de 30 artigos publicados em eventos nacionais e internacionais, colunista para Cincia e Tecnologia pela Revista Espao Acadmico com mais de 80 artigos publicados, tendo feitos palestras em eventos nacionais e exterior. Foi Professor Visitante da University of Texas at Dallas e da University of Ottawa. Formado em Engenharia Eltrica pela Universidade de Pernambuco, com Mestrado em Engenharia Eltrica pela Universidade Federal da Paraba (Campina Grande), Mestrado em Engenharia da Computao pela University of Waterloo e Doutor em Cincia da Computao pela Univesidade Federal de Pernambuco.

Identificao de informaes e critrios que apiam as atividades de anlise e projeto de arquitetura de software.
oftware uma entidade que se encontra quase permanentemente sendo modificado. Tais mudanas ocorrem devido necessidade de corrigir erros existentes no software ou de adicionar novos recursos e funcionalidades. Igualmente, os sistemas computacionais (isto , aqueles que tm software como um de seus elementos) tambm esto sujeito a mudanas frequentes. Isso pode motivar um sistema de software a se tornar no confivel e predisposto a defeitos, bem como ocasionar atraso na entrega e elevao de custos acima do estimado. Concomitante com esses fatos, o crescimento em tamanho e complexidade dos sistemas de software exige que
os profissionais da rea raciocinem, projetem, codifiquem e se comuniquem por meio de componentes de software. Como resultado, qualquer projeto ou soluo de sistema requer decises arquiteturais (de projeto) que podem impactar o produto final. A necessidade da arquitetura de software prover suporte a um conjunto de requisitos, geralmente conflitantes, exige que decises arquiteturais sejam tomadas ainda durante o projeto, tema esse tratado neste artigo.
36
Engenharia de Software Magazine - Arquitetura de Software
PROJETO
Projeto da Arquitetura de Software

Um projetista desenvolve um projeto considerando um conjunto de decises de projeto. Para tomar decises, ele leva em conta os requisitos arquiteturais que motivam e justificam suas decises. Por trs disto, tambm esto metas de qualidade desejadas para o sistema a ser desenvolvido, bem como cenrios de uso, estilos arquiteturais existentes e padres de projeto. A Figura 1 ilustra essa viso do projeto arquitetural.
estilos arquiteturais cenrios de uso padres de projeto requisitos arquiteturais Projeto arquitetural Documentao da arquitetura
A interao existente entre as fases de projeto e anlise arquitetural permite o refinamento da documentao da arquitetura do sistema que culminar com sua implementao. importante observar ainda que, durante a implementao, pode haver necessidade de reconsiderar decises de projeto tomadas anteriormente. Uma vez que a arquitetura de software tenha sido obtida, essa pode evoluir e, portanto, requer que novos requisitos arquiteturais sejam elicitados a fim de satisfazer s mudanas desejadas. Deste modo, caractersticas so adicionadas e/ou modificadas.
Dimenses e Regras de Projeto

Projetos inovadores so, geralmente, desenvolvidos para resolver novos tipos de problemas ou at mesmo prover soluo a algum problema com requisitos bem especficos. Entretanto, os custos associados podem ser elevados. Nesse sentido, a comunidade de engenharia de software e, mais especificamente, de arquitetura de software, tem procurado organizar o conhecimento de projeto de sistemas de software. Uma forma de fazer isto desenvolvendo um vocabulrio, englobando conceitos e padres de projetos que possam ser facilmente compreendidos e reutilizveis. Como resultado deste esforo, tem-se: 1. A possibilidade de desenvolver um projeto de sistema a partir de blocos estruturais. 2. Entendimento e antecipao das propriedades de um projeto. 3. Reduo do esforo necessrio para compreender o projeto de outra pessoa. Um exemplo de organizao de conhecimento atravs de um vocabulrio a codificao de estruturas de controle do fluxo de instrues em um algoritmo, onde dispomos de estruturas sequenciais, de deciso e repetio. Isto oferece um entendimento sobre os padres de fluxo de controle no qual feito uso desses blocos estruturais. Uma forma de organizar o conhecimento a ser utilizado no projeto arquitetural obtendo um conjunto de solues de projeto em termos de dimenses de projeto. Cada dimenso nesse conjunto soluo descreve uma caracterstica do sistema ou deciso de projeto. Considere, por exemplo, que o tempo de resposta de um sistema seja uma dimenso no conjunto soluo. Similarmente, o mecanismo de sincronizao entre processos tambm pode ser visto como outra dimenso. A Figura 3 ilustra essas duas dimenses envolvendo dois sistemas exemplo quaisquer. A figura sugere que o mecanismo de mensagens oferece um tempo de resposta melhor quando comparado a semforos. A existncia de diferentes dimenses no implica que elas sejam independentes. Na realidade, de suma importncia identificar correlaes entre as dimenses. Como resultado, isto permite a criao de regras de projeto que especificam quo adequada a combinao de opes. Uma forma emprica de determinar a existncia de correlaes checando se h agrupamento de solues de projeto em uma regio do conjunto soluo e sua ausncia verificada em outras regies.
Figura 1. Elementos de deciso do projeto arquitetural
Perceba que o projeto arquitetural uma fase iterativa do processo de desenvolvimento de sistema software sobre a qual o projetista ou arquiteto de software precisa raciocinar a fim de tomar decises, levando em considerao os requisitos arquiteturais e cenrios de uso, por exemplo. O arquiteto pode ainda fazer uso de tcnicas de anlise arquitetural para apoiar seu raciocnio sobre o comportamento de atributos de qualidade. Tais tcnicas podem acrescentar informaes aos estilos arquiteturais de modo a possibilitar o raciocnio qualitativo e quantitativo. Perceba que h uma interao entre as fases de anlise e projeto de arquitetura de software. Tal interao surge da necessidade de refinar os requisitos arquiteturais elicitados na fase anterior do processo de desenvolvimento orientado para arquitetura, como ilustrado na Figura 2.
Elicitao de requisitos arquiteturais
Projeto arquitetural
Documentao da arquitetura
Anlise arquitetural
Implementao da arquitetura
Figura 2. Desenvolvimento orientado para arquitetura de software
37
tempo de resposta
rpido mdio lento sistema X sistema Y
mensagens
semforos monitores
rendezvous
outro
sincronizao entre processos
Figura 3. Exemplo simples de conjunto soluo de projeto
Um aspecto essencial no conjunto soluo escolher algumas dimenses que reflitam requisitos no funcionais (desempenho, confiabilidade), ao passo que outras dimenses reflitam a organizao do sistema. A existncia de correlaes entre essas dimenses servir orientao do projeto, ou seja, elas mostraro como opes de projeto podem satisfazer aos requisitos de um sistema. O conjunto soluo, juntamente com as regras de projeto (derivadas das correlaes existentes entre as dimenses do sistema), compreende alternativas de projeto arquitetural para o sistema a ser desenvolvido. Nas sees subsequentes, toma-se um sistema interativo como exemplo para ilustrar dimenses e regras de projeto. Antes, contudo, um modelo arquitetural e estruturas associadas a ele discutido.
Modelo Arquitetural
Conforme ilustrado na Figura 2, o projeto arquitetural uma atividade iterativa onde decises de projeto importantes so tomadas. Os requisitos arquiteturais, juntamente com cenrios de uso, so utilizados na tomada dessas decises. Um modelo arquitetural utilizado para descrever um sistema decomposto em um conjunto de mdulos ou componentes conectados por meio de conectores. Tanto os componentes quanto os conectores possuem propriedades que so utilizadas para diferenciar tipos de componentes e tipos de conectores, bem como oferecer informaes teis s diversas anlises realizadas. Exemplos incluem as anlises de confiabilidade e desempenho. O modelo arquitetural pode ainda ser descrito em termos de estruturas bsicas. Essas estruturas so consideradas como representaes fundamentais da informao arquitetural, ou seja, elas representam os artefatos resultantes de projeto e implementao. Exemplos compreendem classes, objetos, funes, arquivos, bibliotecas, e assim por diante. Abaixo, apresentamos um conjunto de cinco estruturas que podem ser utilizadas para descrever um modelo arquitetural. Estrutura funcional refere-se decomposio de funcionalidade que o sistema precisa suportar. Os componentes so entidades funcionais enquanto que os conectores servem passagem de dados entre os componentes. Essa estrutura til para entender as interaes existentes entre os componentes e para planejar a funcionalidade do sistema. Estrutura de cdigo est relacionada com as abstraes de cdigo usadas no desenvolvimento do sistema. Componentes so entidades que empacotam funcionalidades do sistema em vrios nveis de abstrao, tais como: classes, objetos, funes,
procedimentos e mtodos. Os tipos de conexo envolvem passagem de controle, passagem de dados, compartilhamento de dados, dentre outras. Estrutura de concorrncia refere-se concorrncia lgica. Os componentes dessa estrutura compreendem entidades de concorrncia que so refinadas em processos e threads (ou processos leves). Alguns tipos de conexes incluem: enviar dados para, ter prioridade maior do que, sincronizar com, dentre outras. Adicionalmente, as propriedades associadas a essa estrutura envolvem, por exemplo, tempo de execuo e prioridade. Essa estrutura de suma importncia para entender desempenho. Tambm, ela considerada essencial para confiabilidade e segurana. Informaes relevantes associadas a essa estrutura compreendem o nmero de processos e threads, o tempo de execuo, bem como prioridades dos processos e threads. Estrutura fsica est intimamente associada ao hardware do sistema. Inclui a unidade central de processamento (CPU), barramentos, memria, dispositivos de entrada e sada (E/S). Propriedades relevantes estrutura compreendem capacidade e disponibilidade. Estrutura de desenvolvimento refere-se aos arquivos e diretrios. As metas dessa estrutura incluem gerenciar e assegurar o controle administrativo do sistema medida que ele evolui. Isso envolve gerenciamento de configurao e diviso de tarefas entre membros da equipe. Perceba que, durante o desenvolvimento de um sistema ou, mais especificamente, durante o projeto da arquitetura de um sistema, um projetista ou arquiteto de software pode recorrer a uma ou mais estruturas, podendo expor as informaes necessrias e ocultar as desnecessrias. Assim, se ele analisa, por exemplo, a funcionalidade e facilidade de modificaes de um sistema, a distribuio no constituir um fator relevante. Note que a estrutura de cdigo abstrai questes associadas distribuio. Todavia, se o arquiteto est raciocinando sobre o desempenho, ento a distribuio passa a ser fator relevante, enquanto que a parte funcional passa a ter importncia secundria. Nesse caso, considera-se a estrutura de concorrncia como sendo a mais adequada. A Tabela 1 ilustra um conjunto de requisitos no funcionais e estruturas relevantes associadas a eles.
Requisito no funcional Desempenho Manutenibilidade Confiabilidade Disponibilidade Estruturas relevantes concorrncia, fsica funcional, cdigo, desenvolvimento fsica, concorrncia fsica, concorrncia
Tabela 1. Requisitos no funcionais e estruturas relevantes
Dimenses Funcionais e Arquiteturais

As dimenses funcionais e arquiteturais de um sistema descrevem requisitos associados funcionalidade e organizao do sistema que compreende o conjunto soluo de um projeto. Uma dimenso pode ser vista como uma alternativa
38
PROJETO
ou opo de projeto. Assim, cada dimenso descreve uma alternativa na caracterizao ou deciso de projeto de um sistema. Objetivando caracterizar essas dimenses, tomaremos como exemplo um sistema interativo. Um sistema interativo, como o prprio nome indica, oferece suporte comunicao bidirecional entre usurio e computador. O sistema reage s aes de usurios, exibindo alguma informao, ou ativando algum dispositivo para execuo de um servio. Tudo isto ocorre atravs da interface com usurio que fornece acesso s funcionalidades e recursos do sistema. O modelo arquitetural de um sistema interativo, no qual a interface com usurio o principal componente, pode ser decomposto em trs componentes, conforme mostrado na Figura 4.
Componente dependente de dispositivo
interface com dispositivo
Requisitos Externos
Um exemplo de requisito externo o tratamento de eventos externos. Em outras palavras, essa dimenso indica se a aplicao necessita responder a eventos externos (definidos como eventos que no se originam na interface com usurio). Desse modo, no conjunto soluo de projeto, h trs alternativas: Sem eventos externos a aplicao no afetada por eventos externos ou ento em funo da execuo de comandos especficos dos usurios. Um exemplo disso ocorre no programa de correio eletrnico que apenas checa se h mensagens novas quando recebe comando especfico para realizar esta tarefa. Assim, no h necessidade de prover suporte a eventos externos. Processar eventos enquanto aguarda entrada a aplicao deve tratar os eventos externos. Todavia, os requisitos de tempo de resposta no so to severos de modo a interromper a execuo de comandos de usurios. Nesse caso, o sistema responde a eventos externos enquanto aguarda por algum comando. Eventos externos interrompem comandos de usurios o atendimento a eventos externos tem prioridade maior do que a execuo de comandos de usurios, a qual interrompida quando algum evento externo ocorre. Esse requisito comum de ser encontrado em sistemas de tempo real. Um segundo exemplo de requisito externo a customizao de usurio. O conjunto soluo de projeto pode decompor a customizao de usurio de uma interface em trs nveis: Alta o usurio pode adicionar novos comandos ou redefinir os existentes. Alm disso, ele poderia modificar detalhes da interface com usurio. Mdia o usurio pode alterar detalhes da interface com usurio que no afetem a semntica como, por exemplo, modificar o tamanho de janelas, cores, dentre outros. Baixa nesse caso, pouca ou nenhuma customizao exigida do usurio. Outro exemplo de dimenso a adaptabilidade da in terface com usurio a dispositivos, a qual depende da quantidade esperada de dispositivos de entrada e sada que a interface com usurio precisa oferecer suporte. Essa dimenso indica o grau de mudana no comportamento da interface com usurio em funo da modificao no dispositivo de entrada e sada. Nenhuma todos os aspectos de comportamento permanecem os mesmos em todos os dispositivos de entrada e sada. Isso pode ocorrer quando apenas um nico conjunto de dispositivos de entrada e sada suportado. Modificaes locais no comportamento aqui, h apenas alteraes de poucos detalhes no comportamento da interface com usurio. Um exemplo disso a alterao da aparncia de menus. Modificaes globais no comportamento h mudanas maiores no comportamento da interface com usurio. Uma modificao de interface baseada em menus para interface baseada em linguagem de comando um exemplo.
Componente compartilhado de interface com usurio

interface com aplicao
Componente especfico da aplicao
Figura 4. Modelo arquitetural de um sistema interativo
O componente especfico da aplicao compreende o cdigo que especfico ao programa de uma aplicao, no sendo reutilizado em qualquer outra aplicao. Especificamente, este componente incorpora o ncleo funcional da aplicao. Ele pode ainda incluir o cdigo da interface de usurio que especfica da aplicao. O componente compartilhado de interface com usurio engloba o cdigo que prov suporte interface com usurio de mltiplos programas de aplicao. Se o sistema de software pode acomodar diferentes tipos de dispositivos de entrada e sada (E/S), ento apenas a parte do cdigo que associado aos tipos de dispositivos incorporada aqui. O componente dependente de dispositivos compreende o cdigo que pertinente a uma classe especfica de dispositivos de entrada e sada (E/S), no sendo especfico da aplicao.
Dimenses Funcionais em Sistemas Interativos

As dimenses funcionais identificam os requisitos de um sistema interativo que mais afetam a organizao do sistema, ou seja, elas identificam as especificaes que precedem o projeto arquitetural do sistema. Estas dimenses podem ser divididas em trs categorias: 1. Requisitos externos engloba requisitos de aplicaes, usurios, dispositivos de entrada e sada, bem como restries impostas ao sistema. 2. Comportamento da interface inclui decises sobre o comportamento da interface com usurio que afetam a organizao do sistema. 3. Consideraes prticas consideraes de custo de desenvolvimento bem como nvel de adaptabilidade do sistema so enquadradas aqui.
39
Modificaes na semntica da aplicao nesse caso, h mudana na semntica de comandos. Um exemplo ocorre numa alterao de exibio contnua de um estado e exibio sob comando. Um quarto exemplo de dimenso organizao do sistema de software. Essa dimenso categoriza a natureza bsica da organizao global do sistema em: Uniprocessamento apenas uma aplicao executada de cada vez. Multiprocessamento mltiplas aplicaes podem ser executadas concorrentemente. Processamento distribudo aqui o ambiente envolve uma rede de computadores com mltiplas CPUs e custos de comunicao associados. Outra dimenso compreende os mecanismos existentes para mltiplas threads de controle. Essa dimenso depende do sistema operacional o qual pode oferecer suporte aos seguintes mecanismos para mltiplas threads de controle: Processos estes so processos padres com proteo entre processos (tipicamente, espao de endereamento distintos). Processos leves estes constituem processos que podem ser executados de forma independente, sem proteo entre processos. Processos no preemptivos so processo que no so interrompidos durante sua execuo. Rotinas de servios de interrupo refere-se ao tratamento de eventos a nvel de hardware. Nesse caso, execues de rotinas de servio de interrupo podem ser vistas como threads de controle. Nenhum ocorre quando o sistema no oferece suporte a mltiplas threads de controle.
quantidade maior de aplicaes, embora ele possa ter um custo mais elevado. Os termos adaptabilidade e portabilidade so utilizados algumas vezes indistintamente. Aqui, fazemos opo pelo segundo. Um exemplo de dimenso a portabilidade da aplicao junto a estilos de interao. Nesse caso, estamos interessados em saber o nvel de portabilidade de aplicaes que utilizaro os estilos de interao. Assim, pode-se ter: Alta as aplicaes deveriam ser portveis em estilos de interao distintos como, por exemplo, seleo de menus ou linguagem de comandos. Mdia as aplicaes no deveriam ser dependentes de pequenas variaes no estilo. Um exemplo a aparncia de menus. Baixa variaes na interface com usurio no um fator preponderante, implicando que uma aplicao pode sofrer mudanas desde que a interface com usurio possa ser modificada, tambm. Outra dimenso nessa categoria a portabilidade da aplicao junto a sistemas operacionais. Aqui, o interesse recai em saber o nvel de portabilidade exigido pelas aplicaes que usaro o software de interface junto a vrios sistemas operacionais. O nvel de portabilidade pode ser: Alta as aplicaes deveriam ser portveis em diferentes sistemas operacionais e hardware distintos. Mdia nesse caso, as aplicaes deveriam ser portveis em variantes de um sistema operacional como, por exemplo, diferentes verses do Unix. Baixa aqui, a portabilidade no constitui um fator relevante.
Comportamento da Interface
Esta categoria de dimenso funcional identifica o tipo de interao que sistema interativo suporta. O conjunto soluo, nesse caso, pode englobar os seguintes mecanismos de interao: Seleo de menu este tipo de interao baseado na seleo repetida de um conjunto de opes. Em caso passo, as opes so mostradas. Manipulao direta faz uso de representao grfica e manipulao de dados do programa. Formulrios nesse tipo de interao o usurio entra com dados (geralmente na forma textual) em um conjunto de campos associados a variveis. Linguagem de comando esse tipo de interao baseado em linguagem simblica. Normalmente, pode-se ter uma extenso de definies de procedimentos similares queles encontrados em linguagens de programao. Linguagem natural faz uso de um subconjunto de alguma lngua como, por exemplo, o Ingls.
Dimenses Arquiteturais em Sistemas Interativos

As dimenses estruturais representam as decises que determinam a organizao global de um sistema computacional. As dimenses estruturais podem ser enquadradas em trs classes: 1. Diviso de funes e conhecimento entre componentes aqui, o interesse maior encontra-se em saber como a funcionalidade dividida e associada a componentes, bem como se d a interao entre componentes. 2. Comunicao, sincronizao e fluxo de controle referese ao comportamento dinmico do software da interface com usurio. 3. Representao de informao refere-se representao de dados utilizados pelo sistema. Esses dados compreendem tanto os dados passados interface com usurio bem como os dados que especificam a aparncia e comportamento da interface.
Consideraes Prticas
Outra categoria da dimenso funcional especifica o nvel de adaptabilidade exigido pelo sistema. Geralmente, um sistema que oferece um maior nvel de adaptabilidade suporta uma
Diviso de funes e conhecimento entre componentes

A Figura 4 ilustra as principais divises encontradas num sistema interativo. Aqui, o principal interesse recai em saber como as funes so associadas a componentes e como estes componentes interagem uns com os outros. Perceba que h
40
PROJETO
duas divises importantes no sistema interativo mostrado na figura: a interface com aplicao e a interface com dispositivo. O conjunto soluo engloba alguns tipos de interface com aplicao. Essa dimenso baseada no nvel de abstrao da comunicao, dentre os quais destacamos: Programa monoltico nesse caso, no h separao entre o cdigo especfico da aplicao e o cdigo compartilhado. Portanto, no existe qualquer interfaceamento entre eles. Este pode ser adequado em programas menores. Toolkit a parte do cdigo que compartilha fornece uma biblioteca de mecanismos de interao, tais como menus e barras deslizantes. Desse modo, a aplicao encarregada de escolher os elementos adequados do toolkit (ou kit de ferramentas) a fim de compor a interface com usurio. Sendo assim, a parte do cdigo que compartilhada pode controlar apenas aspectos locais do estilo da interface com usurio, ficando o comportamento global sob o controle da aplicao. Gerente de interao se existe a necessidade de prover suporte portabilidade da aplicao junto a dispositivos e estilos de interao, ento dispor de um gerente de interao constitui uma boa opo. O gerente de interao permite fazer a separao entre o comportamento da interface com usurio e a aplicao. Alm disso, o gerente de interao faz com que a aplicao tenha menos controle sobre a interface com usurio.
A terceira dimenso a granulosidade de comunicao da aplicao. Essa dimenso refere-se frequncia na qual se d a comunicao entre a aplicao e componente da interface com usurio. A granulosidade pode ser: Fina uma vez para cada evento de entrada. Nesse caso, a aplicao fortemente acoplada s aes de usurios e, tambm, participa na gerao de resposta ou feedback. Grossa ocorre uma vez a cada comando completo, sendo a aplicao desacoplada de aes de usurios e gerao de feedback. Outra dimenso importante o mecanismo de comunicao por eventos. Esse mecanismo deveria ser oferecido para suportar a comunicao atravs da passagem de eventos entre componentes. Podem-se ter os seguintes mecanismos de comunicao por eventos: Nenhum quando eventos no so utilizados. Se isso ocorre, tem-se a comunicao baseada simplesmente em estados. Chamada direta de procedimentos trata-se do mecanismo padro de chamada de procedimentos. Isso inclui chamada de procedimentos remoto, contanto que a parte chamada do cdigo seja diretamente informada. Chamada indireta de procedimentos refere-se chamada de procedimentos na qual a parte do cdigo chamado no totalmente especificada. Ao invs, determinada dinamicamente como ocorre numa chamada de um mtodo em orientao a objetos. Mensagem assncrona ocorre quando um evento passado de uma thread de controle para outra sem que a origem do evento aguarde o recebimento do evento. Mensagem sncrona diferentemente de uma mensagem assncrona, aqui o evento passado de uma thread de controle para outra e a thread que originou a mensagem fica bloqueada at que a thread de destino tenha recebido e respondido a mensagem. Note que, embora o mecanismo de comunicao utilizando mensagem sncrona tenha menor custo de implementao, quando comparado ao uso de mensagem assncrona, pode se deparar com problemas de sincronizao devido s dependncias de tempo entre as threads de controle.
Comunicao, Sincronizao e Fluxo de Controle

Similarmente s classes de dimenses anteriormente vistas, aqui o interesse est sobre a comunicao entre componentes. Tambm, o comportamento da interface com usurio considerado. Essa classe pode englobar as dimenses abaixo. O fluxo de controle da aplicao refere-se forma na qual se d o processamento de entrada no fluxo de controle da aplicao. Pode ser: Ponto de entrada nico o sistema possui um lao de eventos que constitui o nico ponto no qual qualquer entrada do usurio aceito. Dessa forma, quando um evento de entrada recebido, ele processado e depois o controle devolvido ao lao de evento que aguardar o prximo evento. Mltiplos pontos de entrada a entrada aceita em mltiplos pontos do fluxo de controle da aplicao. Geralmente, cada um desses pontos pode tratar apenas um subconjunto de entradas. Outra dimenso o tratamento de entradas assncronas. Est relacionada com a forma na qual eventos ou aes de usurios so tratados quando as aplicaes esto ocupadas. Nesse caso, elas podem ser: Ignoradas a entrada assncrona , simplesmente, ignorada. Enfileirada antes do processamento os eventos de entrada so colocados numa fila sem que haja processamento. Com isso, no h resposta imediata (ou feedback) at que a aplicao esteja habilitada. Ter um processamento parcial e serem enfileiradas algum processamento realizado para fornecer feedback. Depois, os eventos so colocados numa fila do tipo FIFO (First-In, First-Out).
Representao da Informao
Como o foco principal d-se na organizao global do sistema, o interesse maior recai sobre as representaes que so compartilhadas entre os componentes do sistema. Desse modo, as representaes utilizadas para dados da interface com usurio so consideradas. Pode-se ento vislumbrar duas dimenses associadas a tipos de representao: Representao para definio da interface com usurio - uma dimenso que permite classificar as tcnicas utilizadas a fim de definir tanto o comportamento quanto a aparncia da interface com usurio. Representao de informao semntica - classifica as tcnicas usadas para definir a informao semntica da aplicao
41
necessria interface com usurio. Esse tipo representao inclui notaes declarativa e procedimental.
Regras de Projetos para Sistemas Interativos

Esta seo discute um conjunto de regras de projeto para sistemas interativos que relacionam as dimenses funcionais e arquiteturais do conjunto soluo. As regras apresentadas a seguir no constituem um conjunto completo. A inteno de ilustr-las, tomando como exemplo os sistemas interativos. So descritas em forma de narrativa de uma maneira informal, podendo serem vistas como um conjunto de diretrizes de projeto. Abaixo, apresenta-se o conjunto dessas diretrizes. Requisitos mais restritos para a portabilidade da interface com usurio junto a dispositivos favorecem a nveis mais elevados da abstrao da interface de aplicao de modo a desacoplar o componente de aplicao do componente de interface com usurio, uma vez que este ltimo pode sofrer modificaes em funo da necessidade de conectar com dispositivos. Note que, se existe um requisito de comportamento global ou se a semntica da aplicao muda, ento dispositivos abstratos parametrizados so favorecidos. Isto decorre do fato de que tais mudanas precisam ser implementadas numa parte do cdigo compartilhado da interface com usurio ou no cdigo da aplicao, ao invs de ser implementado no driver do dispositivo. importante observar que a informao sobre o dispositivo em considerao no pode ser ocultada em nveis mais elevados de abstrao (da forma como outras classes de dispositivos abstratos tentam fazer). Um requisito de portabilidade da aplicao junto a estilos de interface com usurio favorece a opo por nveis mais elevados da abstrao da interface de aplicao. Tambm favorece a mecanismos de comunicao baseado em eventos. Por outro lado, um mecanismo de comunicao hbrido no seria o mais adequado desde que ele atenda a padres de comunicao que podem sofrer alterao quando o estilo de interface muda. Se existe a necessidade de tratar eventos externos, ento devem-se fornecer threads de controle separadas, objetivando desacoplar a lgica de tratamento de eventos da lgica de interface com usurio. Os mecanismos de threads de controle mais comuns so processos, processos leves e tratadores de eventos. Para suportar as atividades das interfaces com usurio, o uso de processos leves mais apropriado. Se o tempo mximo de execuo de comando curto, ento a alternativa mais simples utilizar uma nica thread de controle. Todavia, para comandos com tempos maiores, h a necessidade de usar mltiplas threads de controle a fim de possibilitar que o processamento de solicitaes de usurio continue. Acima, algumas diretrizes a serem seguidas no projeto arquitetural de um sistema interativo foram discutidas. A seguir, apresenta-se um conjunto de regras de projeto baseadas na correlao das dimenses discutidas anteriormente. Note que essas regras constituem recomendaes e o conjunto apresentado no completo. Entretanto, serve como uma
contribuio no esforo de codificar o conhecimento sobre projeto de sistemas interativos. Adicionalmente, as regras de projeto apresentadas abaixo se encontram expressas na forma narrativa. Uma alternativa a esta apresentao seria coloc-las numa descrio mais formal com pesos associados de modo a combinar as diferentes dimenses, identificando as correlaes existentes e atribuindo escores a elas. Assim, por exemplo, uma combinao envolvendo o uso de uma nica thread de controle e a inexistncia de eventos externos receberia um escore positivo. Esse escore positivo indicaria que utilizar uma nica thread de controle uma boa soluo para o requisito dado (ou seja, a inexistncia de eventos externos). Perceba que, uma vez um escore seja obtido em cada deciso arquitetural, ento a combinao de regras de projeto utilizadas com os respectivos escores resultam no escore geral que reflete o escore obtido para o projeto do sistema em desenvolvimento. Se um conjunto de regras for desenvolvido para uma classe de aplicaes, ento se torna possvel automatizar o processo de determinar as decises de um projeto arquitetural. Neste caso, o sistema automatizado iria apresentar um conjunto de recomendaes de projeto que poderiam ser comparadas com as decises que o projetista ou arquiteto de software tenha tomado.
Diviso de Funcionalidade
A Figura 4 ilustra um modelo arquitetural de um sistema interativo composto de trs componentes: componente de aplicao, componente de interface com usurio e componente especfico de dispositivos. Esses componentes so agrupados atravs de duas interfaces: interface de aplicao e interface de dispositivos.
Interface de Aplicao
Programa monoltico essa uma soluo adequada em sistemas pequenos onde a aplicao tem maior controle sobre o componente de interface com usurio e dispe de pouca capacidade de processamento. Essa opo no deveria ser selecionada se h estrito requisito de flexibilidade, tais como: flexibilidade de estilos de interao da interface com usurio, variabilidade de dispositivos de entrada e sada ou customizao pelo usurio. Essa opo pode atender aos requisitos de interfaces de manipulao direta, embora o esforo de desenvolvimento seja maior. Toolkit essa alternativa recomendada quando um nvel moderado de flexibilidade desejado. Alm disso, essa soluo oferece economia significativa de esforo de desenvolvimento, bem como suporta flexibilidade ao sistema. O toolkit pode ser desconsiderado quando necessrio. Tambm, se existe a meta de que um estilo de interao de interface com usurio padronizado seja implementado, ento constitui um boa opo uma vez que alguns componentes padres como menus podem ser mais facilmente suportados pelo toolkit, tornando desnecessrio qualquer esforo adicional de implementao.
42
PROJETO
Gerente de interao se existe um requisito de que o sistema deve prover portabilidade junto a estilos de interao e dispositivos, ento uma soluo dispor de um gerente de interao que permite a separao entre o componente da aplicao e comportamento de interface com usurio. Adicionalmente, o gerente de interao faz com que a aplicao tenha menos controle sobre a interface com usurio. Dispositivo abstrato se existe um requisito de que o sistema deve prover portabilidade junto a estilos de interao da interface com usurio, ento essa soluo no uma boa opo. Essa soluo recomendada quando a portabilidade da aplicao desejada junto a uma pequena quantidade de dispositivos. Note, contudo, que a maior parte do controle da interface com usurio fica sob responsabilidade do componente de aplicao. Essa soluo no deveria ser utilizada quando se deseja suportar uma quantidade maior de dispositivos de entrada e sada, pois isto exigir um esforo muito maior de desenvolvimento, devido necessidade de tratar uma quantidade maior de casos, bem como pode se perder o controle sobre aspectos da interface com usurio, caso o driver oculte muitos detalhes).
interesse est sobre as relaes de controle existentes entre os componentes do sistema e a maneira como ocorre a sincronizao da sequncia de eventos. Alm disso, h ainda interesse na maneira como ocorre a comunicao entre os diversos componentes do sistema. Uma forma conveniente de analisar isso visualizar o fluxo de controle em termos de threads de controle. Uma thread de controle um entidade capaz de realizar, de modo independente, computaes e esperar pela ocorrncia de eventos. Assim, thread de controle um termo mais genrico que pode ser usado para designar, por exemplo, processos e processos leves.
Comunicao
Interface de Dispositivos
Dispositivo ideal nessa opo, todas as questes da variabilidade de dispositivos so ocultadas do software no nvel acima do driver de dispositivo. Dessa forma, h suporte portabilidade da aplicao. Essa alternativa no adequada se existe a necessidade de grandes mudanas no comportamento da interface com usurio para atender as diferenas entre os dispositivos. Em outras palavras, essa opo satisfaz apenas a um pequeno nmero de dispositivos. Dispositivo parametrizado essa soluo acomoda uma quantidade maior de dispositivos de entrada e sada e possibilita modificaes no comportamento da interface com usurio junto a dispositivos. Uma desvantagem que a parte do cdigo independente de dispositivo pode precisar fazer anlises complexas a fim de atender a um espectro maior de dispositivos. Essas anlises podem requerer uma significativa capacidade de processamento. Se isso tiver de ser feito em cada aplicao, ento seu custo ser elevado. Assim, uma alternativa reduzir a quantidade de casos a serem suportados nessa abordagem. Dispositivo com operaes variveis se as operaes de dispositivos so selecionadas num nvel elevado de abstrao para permitir que o driver de dispositivo tenha liberdade de escolha, ento esta uma boa soluo. Nesse caso, apenas mudanas locais no comportamento da interface com usurio podem ser suportados a nvel do driver de dispositivo. Entretanto, mudanas na semntica da aplicao no podem ser suportadas. Se essas condies casam com as metas do sistema, ento essa soluo pode oferecer suporte a uma quantidade maior de dispositivos. Alm disso, os custos na capacidade de processamento dessa alternativa so relativamente baixos.
Comunicao, Sincronizao e Fluxo de Controle

O foco dessa seo est em questes que englobam mecanismos de comunicao e fluxo de controle. Dessa forma, o
Comunicao atravs de estado compartilhado a comunicao entre componentes pode depender do estado compartilhado ou evento (uma transferncia de informao que ocorre num tempo discreto atravs, por exemplo, de uma mensagem ou chamada de procedimento). A comunicao atravs de variveis de estado compartilhadas muito diferente porque o recebedor do evento no precisa usar a informao na mesma ordem na qual ela foi enviada. Essa soluo apropriada para guiar os dispositivos que exibem estados persistentes. Por outro lado, se no h uma caracterizao de estados, ento a comunicao baseada em eventos mais adequada. Entretanto, deve-se observar que os sistemas baseados em estado so mais simples do que os sistemas baseados em eventos, embora sejam menos eficientes. J um sistema hbrido, combinando eventos com estados compartilhados, oferece um desempenho melhor ao custo de complexidade maior. Uma grande desvantagem da comunicao baseada em estado que ela exige acesso eficiente memria compartilhada (o qual pode no ser disponvel em sistemas de multiprocessamento). Comunicao baseada em eventos esse mecanismo de comunicao requer a passagem de eventos entre componentes. Na comunicao com uma nica thread de controle, h duas alternativas: chamada direta de procedimento e chamada indireta de procedimento. As chamadas indiretas de procedimento oferecem separao desejvel entre os componentes. Alm disso, caso a linguagem de programao suporte chamadas indiretas, ento essa soluo mais apropriada visto que ela possui menor tempo de execuo. Por outro lado, se a comunicao ocorrer entre threads de controle, ento existem duas alternativas: mensagens assncronas e mensagens sncronas. Mensagens assncronas tm a vantagem de reduzir problemas de sincronizao. J as mensagens sncronas possuem semntica mais simples e podem ser implementadas mais facilmente. Para os propsitos de sistemas interativos, a soluo mais adequada utilizar mensagens assncronas. Mecanismo de fluxo de controle refere-se thread de controle. Dentre as formas de oferecem a noo de thread de controle, tem-se: processos, processos leves, tratadores de eventos e rotinas de servio de interrupes. As trs primeiras formas so mais comumente usadas. Os processos podem ser utilizados em ambientes de rede onde pode ser til colocar processos em mquinas distintas. Entretanto, especificamente para sistemas
43
interativos, o uso de processos leves a soluo mais apropriada. Agora, se nenhuma dessas situaes ocorre e as limitaes de tempo de resposta so aceitveis, ento os tratadores de eventos podem ser uma opo.
Fluxo de Controle e Sincronizao

Fluxo de controle da aplicao refere-se forma na qual se d o processamento de entrada no fluxo de controle da aplicao. Existem dois tipos: (i) ponto de entrada nico, onde o sistema possui um lao de eventos que constitui o nico ponto no qual qualquer entrada do usurio aceito, e (ii) mltiplos pontos de entrada, onde a entrada aceita em mltiplos pontos do fluxo de controle da aplicao. O primeiro tipo a soluo mais apropriada uma vez que permite desacoplar o componente de aplicao de detalhes do sequenciamento da interface com usurio. Alm disso, suporta requisito de portabilidade da aplicao. Nmero de threads de controle como o prprio nome designa, est relacionado quantidade de threads de controle. Uma soluo adequada em sistemas simples, onde h um nico ponto de entrada, utilizar apenas uma nica thread. Entretanto, se h o requisito de desacoplar o fluxo de controle da interface com usurio da aplicao, ento a alternativa mais apropriada utilizar uma thread para interface com usurio e uma thread para aplicao. Duas threads so suficientes para permitir que as operaes da interface com usurio possam ser executadas concorrentemente com a aplicao. Isso permite que aes do usurio sejam processadas e telas com resposta sejam atualizadas enquanto comandos esto sendo processados. Alm disso, eventos externos podem ser tratados sem que haja interrupo na resposta da interface. O resultado que o componente de aplicao fica mais independente do sequenciamento de eventos da interface com usurio. Uma outra alternativa dispor de mltiplas threads de interface com usurio, pois isto simplificaria o tratamento de interaes paralelas logicamente independentes, quando mltiplos dispositivos de entrada so utilizados. Uma quarta soluo usar mltiplas threads de aplicao. Esse tipo de soluo seria apropriado para tratar mltiplos eventos externos. Tratamento de entradas assncronas a interface com usurio deve dispor de algum mecanismo para tratar eventos de entrada assncronos, ou seja, eventos que ocorrem enquanto a aplicao est fazendo alguma computao. Se os eventos no permanecerem numa fila longa, a soluo mais adequada enfileirar os eventos antes de efetuar o processamento. Entretanto, se a execuo de comandos tomam um longo perodo, ento essa soluo no seria apropriada, pois a falta de resposta do sistema compromete sua usabilidade. Outra soluo que oferece mais flexibilidade fazer o processamento parcial junto com enfileiramento. Essa soluo, contudo, requer mltiplas threads de controle e preocupaes com a sincronizao. Granulosidade de comunicao da aplicao - refere-se frequncia na qual se d a comunicao entre a aplicao e componente da interface com usurio. Se a frequncia de comunicao de uma vez a cada comando completo, sendo
a aplicao desacoplada de aes de usurios e gerao de feedback, ento se tem que a granulosidade grossa. Essa soluo apropriada se a aplicao possui comandos com longo tempo de execuo ou precisa lidar com eventos externos. Agora, se a aplicao fortemente acoplada s aes de usurios e, tambm, participa na gerao de resposta ou feedback, tem-se que a granulosidade fina. Essa segunda soluo adequada em interfaces de manipulao direta. Note que nessa opo os custos de comunicao e portabilidade da aplicao ficam comprometidos. Assim, essa soluo no deveria ser adotada a menos que estritamente necessria.
Desenvolvimento do Projeto Arquitetural

A Figura 2 ilustra o contexto no qual se d o desenvolvimento do projeto arquitetural. Um conjunto de elementos, tais como requisitos arquiteturais, cenrios de uso e estilos arquiteturais, fornecem informaes que objetivam subsidiar o projeto arquitetural de um sistema. Isso mostrado na Figura 1. Inicialmente, feita a suposio que dispomos de uma lista de requisitos arquiteturais e um conjunto de funcionalidades derivadas dos requisitos funcionais. Note que as dimenses de projeto (ou caractersticas do sistema) servem de suporte identificao desses requisitos. A meta desse passo inicial identificar um conjunto de subsistema e/ou componentes candidatos a serem usados na arquitetura do sistema. Todas as funcionalidades derivadas dos requisitos funcionais so vislumbrados como subsistemas. Outros possveis subsistemas so derivados dos requisitos arquiteturais. Para cada requisito arquitetural, enumeram-se as possveis alternativas arquiteturais que satisfazem quele requisito. Para tanto, o arquiteto pode desenvolver regras de projeto para a classe de sistemas que pretende desenvolver. Considere, por exemplo, que um requisito arquitetural seja possibilitar a mudana de sistema operacional. Uma soluo para atender esse requisito dispor de um adaptador de sistema operacional. importante observar que os requisitos arquiteturais podem ter, possivelmente, mltiplas solues, ao passo que outros podem possuir apenas uma. Essa enumerao fruto de considerar os estilos arquiteturais existentes, padres de projeto bem, como a experincia do arquiteto. Com a lista de alternativas de soluo em mos, o arquiteto de software pode minimizar a lista de solues existentes, selecionando aquelas que satisfazem os requisitos de forma consistente. Essa seleo pode fazer uso de regras de projeto. Perceba que, uma vez o arquiteto disponha de um conjunto de regras de projeto para uma categoria de sistema, essas podem ser reutilizadas em novos desenvolvimentos. Deve-se procurar reduzir o nmero de opes de modo a resultar num nmero menor de componentes, o que exigir menor esforo de implementao e manuteno. Cada opo selecionada adicionada lista de subsistemas candidatos. O passo seguinte escolher os subsistemas. Cada candidato a subsistema ser classificado como um subsistema real podendo aglutinar componentes e sendo incorporado arquitetura do sistema.
44
PROJETO
Assim, uma vez que o conjunto de subsistemas seja obtido, o prximo passo verificar a estrutura de concorrncia. Essa estrutura pode ser obtida analisando a necessidade de distribuio e paralelismo. Cada subsistema pode ser distribudo em vrios ns fsicos. Nesse caso, uma unidade de distribuio pode acomodar os componentes pertencentes a um subsistema. Alm disso, unidades de paralelismo podem ser identificadas analisando as threads existentes, bem como a necessidade de sincronizao dessas threads. Ao final do projeto, os subsistemas e os relacionamentos existentes tero sido identificados. H ento um passo de validao, bem como refinamento dos subsistemas. A estrutura de concorrncia novamente analisada. Esse passo de validao pode requerer que as etapas iniciais sejam repetidas. Note que o projeto arquitetural altamente interativo, conforme ilustra Figura 1. Durante a validao da arquitetura do sistema de software, cenrios de qualidade so utilizados como mecanismo de validao. A arquitetura proposta examinada, buscando checar se os cenrios de uso so realizveis a nvel de projeto. Se a arquitetura atende aos cenrios, o processo de refinamento prossegue. Caso contrrio, a arquitetura proposta reconsiderada a fim de checar em qual subsistema e/ou conexo entre subsistemas os cenrios de qualidade no so alcanados. importante observar que durante a atividade de projeto, so feitas vrias anlises arquiteturais a fim de validar a arquitetura proposta. Nesse contexto, os cenrios servem para estruturar o processo de anlise. Uma vez que a arquitetura tenha sido obtida, importante que avaliadores externos faam uma avaliao a fim de confirmar os resultados obtidos durante o projeto arquitetural.
a reuso, considerando tanto o aspecto econmico quanto a produtividade, alm de sua incorporao nos processos de desenvolvimento de software. Neste artigo, foi visto que a estrutura global ou modelo arquitetural de sistemas de software pode ser estudada atravs do uso de dimenses de projeto. Uma dimenso de projeto identifica as opes funcionais e arquiteturais feitas durante o projeto de um sistema e classifica as alternativas existentes para cada escolha. Alm disso, regras podem ser formuladas, objetivando correlacionar as opes existentes a uma dimenso de projeto. Esse conjunto de regras constitui ferramenta de projeto e pode ser empregada como orientao do projeto arquitetural. Exemplos de regras de projeto para sistemas interativos foram apresentados.
Links Histria da Indstria de Software www.softwarehistory.org An introduction to software architecture http://www.cs.cmu.edu/afs/cs/project/able/www/paper_abstracts/intro_softarch.html SEIs Software Architecture Technology Initiative www.sei.cmu.edu/architecture/sat_init.html Worldwide Institute of Software Architects www.wwisa.org/wwisamain/index.htm The Software Architecture Portal http://www.softwarearchitectureportal.org/ SEIs Software Architecture Technology Initiative www.sei.cmu.edu/architecture/sat_init.html
Concluso
Arquitetura de software e, mais especificamente, decises de projeto arquitetural, tm grande importncia no contexto atual para desenvolvimento de sistemas de software. Essa importncia vem em parte da necessidade de prover suporte
45
edio ta
D s
Feedback eu
sobre e s

Experincias da Domnio Informtica na Implantao do MPS.BR

Ticiana da Mota Gentil Parente
ticianagentil@yahoo.com.br

Este artigo relata a experincia da Domnio Informtica com a definio e implementao dos seus processos de desenvolvimento de software, aderentes ao modelo de maturidade MPS.BR. Para tanto, discorre sobre a estratgia usada, as aes necessrias para se alcanar estes objetivos, os aprendizados obtidos, suas dificuldades, fatores de sucesso e os benefcios iniciais a partir desta experincia.
Bacharel em Economia pela Universidade Federal do Cear, ps-graduada em Processamento de Dados pela Universidade de Fortaleza - UNIFOR, participou dos seguintes cursos: Curso de Gerenciamento de Projetos baseado no PMBOK, Curso Oficial de Introduo ao MPS.BR e Curso de Auditoria da Qualidade ISO 9001:2000. Foi coordenadora do projeto de implantao do MPS.BR na Domnio Informtica, bem como, responsvel pela implantao da fbrica de software e responsvel pela incluso no escopo da ISO do item referente a desenvolvimento de sistemas e fbrica de software na Domnio Informtica. Atualmente trabalha na Secretaria do Planejamento e Gesto do Governo do Estado do Cear na Coordenadoria de Gesto Estratgica de TIC.
Adriano Bessa Albuquerque

adriano.ba@terra.com.br
Doutor em Engenharia de Sistemas e Computao pela Universidade Federal do Rio de Janeiro (2008). Atualmente professor do Mestrado em Informtica Aplicada da Universidade de Fortaleza, estando envolvido com a linha de pesquisa de Engenharia de Software. Atua principalmente nos seguintes temas: qualidade de software, avaliao e melhoria de processos de software, mtricas, normas iso e modelos de maturidade de software, sendo, tambm, implementador e avaliador oficial dos modelos de maturidade de software: CMMI e MPS.BR.
Domnio Informtica uma empresa especializada em Terceirizao de Tecnologia da Informao e Comunicao e mo-de-obra especializada para todos os segmentos de informtica como: Desenvolvimento de Sistemas, Suporte Tcnico, Consultoria e Treinamento. uma empresa full service, ou seja, fornece aos seus clientes infra-estrutura completa de suporte, manuteno e acompanhamento de servios e produtos. Em 1998, a Domnio iniciou o desenvolvimento de uma metodologia de trabalho prpria, tendo sempre a preocupao de adequar seus servios s reais demandas dos clientes. Em 1999, obteve a certificao ISO 9001 em
Para que serve?

Este artigo importante para que outras empresas possam conhecer as dificuldades enfrentadas pela Domnio Informtica para conseguir dois nveis de maturidade do MPS.BR, bem como os fatores de sucesso de tal empreitada.

O tema til, tendo em vista estar crescendo a procura das empresas brasileiras pelas avaliaes MPS.BR.
desenvolvimento de sistemas, recrutamento e seleo de pessoal especializado, e projetos de comrcio eletrnico
46
Engenharia de Software Magazine - Experincias da Domnio Informtica na Implantao do MPS.BR
processo
na Internet. A certificao foi feita pelo BVQI (Bureau Veritas Quality International), que tem reconhecimento do INMETRO (Instituto Nacional de Metrologia, Normalizao e Qualidade Industrial) e ANSI/RAB (American National Standards Institute/Registrar Accreditation Board). A partir de 2006, as recertificaes passaram a ser realizadas pelo BRTV, organismo certificador, credenciado tambm pelo INMETRO. No final do primeiro semestre de 2007, a empresa contratou a Universidade de Fortaleza - UNIFOR como instituio implementadora, no intuito de orient-la e ajud-la na definio e implementao dos processos do nvel G e F do MPS.BR Melhoria de Processo do Software Brasileiro (SOFTEX, 2007). Como resultado inicial deste trabalho, em fevereiro de 2008, a empresa foi avaliada com sucesso no nvel G, tendo como unidades organizacionais avaliadas o setor de desenvolvimento da prpria Domnio Informtica e o site do Departamento de Edificaes e Rodovias do Estado do Cear (DER-CE), cliente da empresa. Em relao ao nvel F, em setembro de 2008, houve a avaliao inicial da Fbrica de Software da Domnio, tendo sua avaliao final prevista para Outubro de 2008. O fato de a empresa ter optado por obter as avaliaes do nvel G e do nvel F no mesmo ano, com um intervalo de apenas seis meses, exigiu um alto investimento, alm de uma grande dedicao e tempo dos profissionais. A Fbrica de Software, que um conjunto de recursos humanos e materiais, processos e metodologias estruturadas, de forma semelhante s indstrias tradicionais, utiliza-se das melhores prticas para o processo de desenvolvimento, teste e manuteno dos softwares. Alm disso, utiliza em sua operao, indicadores de qualidade e produtividade em cada etapa do ciclo de desenvolvimento de software, bem como busca maximizar a reutilizao de componentes anteriormente desenvolvidos. A qualidade dos produtos e servios da Fbrica de Solues de Software da Domnio Informtica baseada no modelo MPS. BR (SOFTEX, 2007), no processo interno de desenvolvimento de sistemas certificado pela ISO desde 1999, bem como no PMBOK (PMI, 2004).
Como a empresa tambm faz terceirizao, decidiu-se implementar os processos tambm em um cliente, o Departamento de Edificaes e Rodovias do Estado do Cear (DER-CE). L, a empresa responsvel por todo o desenvolvimento e manuteno de sistemas, possibilitando grande autonomia nos processos da rea terceirizada. Esta deciso teve como objetivo disseminar o conhecimento e buscar uma maior qualidade em seus servios.
Aes Necessrias
Outros fatores que tambm motivaram a empresa a implementar o MPS.BR (SOFTEX, 2007) foram: a expectativa de reduo do retrabalho, o aumento da produtividade, a reduo do tempo de entrega do produto, a otimizao da previsibilidade e o aumento da satisfao do cliente (VARKOI, 2002). Para o que a empresa se propunha em termos da melhoria continua dos seus processos foi necessrio: Disponibilizar recursos suficientes (HEFNER e TAUSER, 2001, DYBA, 2003), visto que o sucesso de um Programa de Melhoria depende do investimento em pessoal, em ferramentas de apoio e do apoio de consultorias especializadas. Analisar freqentemente, o retorno do investimento (ROI) com as melhorias dos processos de software e torn-las visveis (ERDOGMUS et al., 2004). Com isto, a organizao se motiva e diminui o risco de parar o processo de melhoria contnua, visto que percebe os ganhos obtidos e que esto influenciando positivamente os seus negcios. Adaptar o Programa de Melhoria s caractersticas da organizao (HEFNER e TAUSER, 2001, DYBA, 2003), visto que a eficincia e aderncia aos processos dependem do quo os processos esto em sintonia com a cultura organizacional da empresa. Existir, por parte da empresa, uma viso e compromisso de longo prazo com o investimento em melhoria (VARKOI, 2002), de forma que as dificuldades enfrentadas e os prazos de cada passo rumo melhoria contnua dos processos, que nem sempre so curtos, no venham desmotivar a organizao. Existir uma alta gerncia comprometida e que fornea o devido suporte (DYBA, 2003, BASILI et al., 2002), visto que o incio e continuidade do Programa de Melhoria depende dos recursos disponibilizados pelos dirigentes da organizao. Definir uma baseline dos resultados do Programa de Melhoria desde o seu incio (BASILI et al., 2002), para que a empresa no perca a noo do quanto a melhoria dos processos est sendo benfica para a organizao e seus negcios. Ajustar os objetivos de melhoria aos objetivos de negcio da organizao (HEFNER e TAUSER, 2001). Com isto, espera-se que o foco do Programa de Melhoria seja o crescimento dos negcios da empresa e que a melhoria dos processos no se torne uma iniciativa parte e desvinculada das outras reas da organizao. Considerar no apenas os fatores tcnicos da organizao (HEFNER e TAUSER, 2001, DYBA, 2003). importante analisar fatores relacionados cultura da empresa, bem como sua estrutura organizacional, pois alguns destes fatores podem inviabilizar o incio e a continuidade do Programa de Melhoria.
Estratgia Utilizada
Como diferencial competitivo, a Domnio procurou identificar uma metodologia que otimizasse seus processos de trabalho, objetivando melhorar a qualidade de seus produtos e servios, aumentar a competitividade e reduzir custo. Desta forma, identificou no MPS.BR (SOFTEX, 2007) a melhor opo, visto o atual reconhecimento nacional deste modelo de maturidade, a possibilidade de um menor investimento e a empresa ter sua atuao ainda restrita ao mercado interno. Assim, contratou uma instituio implementadora que pudesse auxili-la nesta mudana e iniciou o processo de capacitao do seu quadro tcnico. Inicialmente, a Universidade de Fortaleza (UNIFOR) realizou um diagnstico da situao atual da empresa, para que pudesse definir de uma forma mais rpida e eficaz o quanto os processos da Domnio estavam aderentes ao MPS.BR (SOFTEX, 2007).
47
Ter o envolvimento de todos os colaboradores (DYBA, 2003), j que so eles que iro executar os processos implementados. Investir em melhoria de pessoal (contratao, melhoria de habilidades, ambientes de trabalho, entre outras) em paralelo ao Programa de Melhoria (BASILI et al., 2002). Talvez, este deve ser o maior orientador de qualquer Programa de Melhoria, visto que a qualidade do pessoal da empresa o principal diferencial na definio e execuo dos processos, ou seja, a maturidade dos processos da empresa est diretamente relacionada maturidade dos colaboradores da organizao. Aproveitar conhecimentos j existentes na organizao (DYBA, 2003), para que a empresa no parta da estaca zero e os processos definidos sejam mais adequados organizao e possam ser executados de maneira mais aderente. Ser apoiado por um ambiente ou abordagens de gesto de conhecimento (SCHNEIDER e VON HUNNIUS, 2003). Dessa forma a organizao poder implementar melhorias mais teis s necessidades dos processos e alm disso, a partir do reuso de conhecimentos, agilizar a implementao e execuo dos processos. Alm destes fatores de sucesso, a empresa, juntamente com a consultoria, buscou definir claramente as responsabilidades dos envolvidos no processo, bem como garantir um bom nvel de usabilidade da definio dos processos, selecionando o tipo de representao mais adequada (MENDONA, 2006). Para isto, utilizou a ferramenta EPF Composer, que permite uma eficaz representao grfica dos processos, descrio das atividades, tarefas e passos, bem como a definio dos papis responsveis por cada tarefa, conforme apresentado na Figura 1. Esta ferramenta tambm um repositrio dos templates que devem ser utilizados durante a execuo dos processos. Alm disso, foram definidos os artefatos de entrada e sada para cada tarefa, os quais fossem de fcil utilizao (com informaes claras, com diretrizes de preenchimento, com sees bem distribudas) e ao mesmo tempo aderentes ao MPS.BR (SOFTEX, 2007). A organizao e a consultoria definiram os mtodos e tcnicas que poderiam apoiar de maneira mais adequada os processos, como por exemplo, a utilizao de Pontos de Casos de Uso para estimar o esforo dos projetos. Foram definidas tambm as ferramentas que melhor poderiam apoiar a execuo dos processos. Finalmente, no incio da implantao do Programa de Melhoria na empresa, foram realizados treinamentos e principalmente reunies com os colaboradores, para sensibiliz-los em relao: (i) importncia de iniciativas de melhoria contnua de processos para uma organizao, (ii) relevncia de executar os processos de forma aderente e (iii) importncia para a vida profissional de cada um dos colaboradores, por estarem participando de um Programa de Melhoria, tendo em vista que aumentaria seu nvel de conhecimento em Engenharia de Software e sua empregabilidade.
Figura 1. Processo representado no EPF Composer
Aprendizados e Ajustes
Na fase de implementao dos processos, o aprendizado terico unido prtica, quando do incio do desenvolvimento dos projetos, propiciou um maior grau de maturidade, no apenas da equipe, mas de toda a empresa, uma vez que efetivamente houve uma maior e melhor gesto nos seus projetos. Inicialmente, foram realizados treinamentos para que houvesse um nivelamento do conhecimento entre a equipe de trabalho e possibilitasse um maior senso crtico durante a etapa de definio dos processos de Gerncia de Projetos e Gerncia de Requisitos (nvel G do MPS.BR). Em seguida, aps vrias reunies para definir os processos e os respectivos templates, estes foram divulgados e institucionalizados na organizao. Em paralelo a isso, para facilitar a implementao dos processos, a Domnio deu incio ao desenvolvimento de uma ferramenta que pudesse apoiar o processo de Gerncia de Projetos e de Requisitos, funcionando como um workflow. Porm, com a implementao dos novos processos do nvel F, mais especificamente, da Gerncia de Configurao, em que passou a utilizar a ferramenta Team Foundation, esta idia foi abandonada, visto que esta ferramenta permite que o mtodo de trabalho fique mais claro, permitindo, assim, um maior e melhor entendimento do processo, bem como um repositrio nico de dados. Alm disso, a ferramenta veio apoiar de forma
48
processo
significativa tambm a Gerncia de Projetos e Garantia da Qualidade, uma vez que se instituiu na empresa a cultura do uso de tarefas (tasks), em que se identifica o responsvel, projeto e situao da mesma, permitindo um maior controle destas.
Principais Dificuldades
No incio, at por falta de um maior grau de maturidade, a empresa passou por um momento de adequao, havendo certa resistncia, por considerar algumas etapas muito burocrticas. No decorrer dos trabalhos, percebeu-se que se poderia ter um maior controle e conseqentemente uma melhor gesto dos projetos. Porm, era necessrio um trabalho em conjunto em que ocorressem reunies de analises crticas que permitissem revises e identificao de melhorias. Atrelado a isso, como o ser humano tem uma resistncia natural mudana, o que dificulta a implantao de um novo processo de trabalho, uma vez que isso implica na sada de uma zona de conforto, j totalmente conhecida, para uma nova, as quais muitas vezes expem as pessoas a um desafio, que nem sempre elas esto preparadas, alguns colaboradores se colocaram, muitas vezes, contra a execuo de algumas tarefas e utilizao de alguns mtodos e tcnicas. Uma outra dificuldade enfrentada foi com a implantao do novo processo de trabalho, o qual gera novas atribuies para do dia a dia, sem que as tarefas em andamento possam ser colocadas em stand by. Desta forma, conciliar o que deveria ser feito na rotina diria e ao mesmo tempo executar novas tarefas dos processos implementados foi um esforo rduo, que exigiu uma determinao muito grande dos colaboradores para mudar. Em relao a esta dificuldade, as iniciativas para motivar os envolvidos de forma que consegussemos torn-los uma verdadeira equipe de trabalho foi fundamental. Assim, viabilizar treinamentos, analisar casos de sucesso, realizar reunies de analises crticas, ver as tendncias mercadolgicas, identificar oportunidades de negcio para empresa, foram algumas das aes que motivaram a equipe. Outra grande dificuldade enfrentada pela empresa foi definir os processos de forma que, quando executados, preservassem a agilidade das entregas aos clientes e, ao mesmo tempo, atendessem aos resultados esperados do MPS.BR (SOFTEX, 2007). Nesse momento, ficou clara a importncia de uma consultoria, onde os implementadores j tivessem tido oportunidades de participar de avaliaes MPS.BR e conhecessem a realidade e os processos de outras empresas (Benchmark). Percebeu-se que uma orientao bem qualificada facilita a definio de processos mais adequados aos objetivos de negcio da empresa e mais aderentes ao modelo de maturidade.
rigoroso, (iii) sensibilizar os envolvidos em relao aos benefcios do Programa de Melhoria, (iv) disseminar a cultura de processos na empresa, (v) existir um colaborador dedicado para desenvolver as iniciativas de melhoria de processos na organizao e, principalmente, (vi) contar com um forte apoio da alta direo (patrocinador do Programa de Melhoria). Como o custo de implementao e avaliao de processos alto e o prazo para se enxergar os benefcios obtidos longo, se a alta direo no der o devido respaldo, e se no existir uma boa coordenao do projeto de implementao dos processos aderentes ao modelo MPS.BR (SOFTEX, 2007), poder ocasionar um aumento do custo de implementao e at mesmo comprometer o sucesso e a continuidade do Programa de Melhoria. Como fator de sucesso, vale ressaltar ainda, a estratgia de realizar uma avaliao informal na Domnio Informtica, antes da avaliao inicial do MPS.BR em todos os seus nveis, de forma que a empresa pudesse conhecer a atual realidade dos seus processos em relao aos resultados esperados e atributos de processos definidos pelo modelo. Esta avaliao foi realizada por uma avaliadora adjunta oficial do MPS.BR e que no tinha participado da implementao dos processos na empresa.
Benefcios Alcanados
Vrios foram os benefcios obtidos com a implantao dos processos, porm, vale destacar o aumento do grau de maturidade dos profissionais da empresa, bem como o rigor com que os projetos passaram a ser gerenciados. Atualmente, no h dvidas do que deve ser feito, quando e por quem. Isso por si s, j representa uma grande vantagem competitiva da organizao. Alm disso, podemos citar a institucionalizao dos processos, deixando-os cada vez menos pessoais, uma vez que todos sabem que passos devem ser seguidos. A viso de comeo, meio e fim de um processo facilmente entendida e visualizada atravs do que foi definido. Como os softwares passaram a ser extremamente bem documentados, isto propiciou uma maior e melhor continuidade dos servios, visto que mesmo com a mudana de um profissional no projeto, outro que entenda a forma de trabalho e que tenha acesso documentao poder dar continuidade ao mesmo com maior facilidade, permitindo assim um aumento da produtividade e segurana do projeto. Outro beneficio advindo da implementao do processo de Gerncia de Projetos foi a utilizao de Pontos de Casos de Uso para estimar o esforo necessrio dos projetos. Com isto, a empresa vem melhorando o nvel de previsibilidade do esforo dos seus projetos e conseqentemente, dos custos envolvidos, embora ainda no considere que tenha uma calibrao adequada, visto o nmero de projetos, os quais utilizaram esta tcnica. Porm, considerando ser um mtodo universal, e com a nova prtica que ser adotada na concluso dos projetos em andamento, em que ser feita uma comparao do que foi estimado, com o efetivamente realizado, a empresa espera colher ainda mais frutos. A comparao entre os resultados obtidos
Fatores de Sucesso
No caso da Domnio Informtica, podemos definir os seguintes fatores de sucesso: (i) ter contratado uma consultoria, (ii) tratar o Programa de Melhoria como um projeto, onde as fases so bem definidas e realizado um acompanhamento
49
com Pontos de Caso de Uso e com o mtodo utilizado anteriormente no foi realizada, uma vez que no tnhamos uma base histrica confivel. Alm disso, com esta nova forma de estimar, de planejar e de monitorar seus projetos, a organizao passou a ter uma maior viso da sua lucratividade. Outro ponto importante a se destacar com a implantao dos processos foi a utilizao de abordagens de captura de conhecimentos a fim de que pudessem ser reutilizados, aumentando, assim, a produtividade dos projetos da organizao. Um exemplo disto foi a realizao das avaliaes post-mortem no final dos projetos, que permitiram identificar pontos fortes e fracos e, a partir de sua anlise, propor melhorias para os processos.
conhecimento e pela maior e melhor gesto de seus negcios. O cliente, por ter uma ferramenta de trabalho implantada em sua organizao sem custo adicional ao seu contrato. O profissional, por conseguir um maior grau de maturidade e empregabilidade. E o mercado, por dispor de empresas com uma maior capacitao em gesto e qualidade de software.
Referncias BASILI, V. et al., 2002,Lessons learned from 25 years of process improvement: The Rise and Fall of the NASA Software Engineering Laboratory , In: Proceedings of International Conference on Software Engineering (ICSE 2002), pp. 69-79, Orlando. DYBA, T., 2003, Factors of Software Process Improvement Success in Small Organizations: An Empirical Study in the Scandinavian Context , In: Proceedings of the Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/ FSE03), pp. 148-157, Helsinki. ERDOGMUS, H. et al., 2004,Return on Investment , IEEE Software, pp. 18-22, May/June 2004. HEFNER, R., TAUSER, J., 2001,Things They Never Taught You in CMM School , In: Proceedings of the 26th Annual NASA Goddard Software Engineering Workshop, pp. 27-29, November. MENDONA, R. M. L. O., 2006, Usabilidade de Processos , In: Anais do II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software (WOSES), pp. 13-26, Vila Velha, Junho. PMI - Project Management Institute, 2004, PMBOK A guide to Project Management Body of Knowledge . 3 ed. Pennsylvania: PMI Project Management Institute Inc. SCHNEIDER, K., VON HUNNIUS, J-P., 2003, Effective Experience Repositories for Software Engineering , In: Proceedings of the International Conference on Software Engineering (ICSE03), pp. 534-539, Portland, May. SOFTEX, 2007, Melhoria de Processo de Software Brasileiro - Guia Geral verso 1.2, disponvel em: http://www.softex.br/mpsbr, acessado em: 08/10/2007. VARKOI,T., 2002,Management of Continuous Software Process Improvement , In: Proceedings of the International Engineering Management Conference (IEMC 02), pp. 334-337, Cambridge, August.
Concluso
A empresa entende a melhoria contnua dos processos como uma iniciativa sem volta e de grande valor agregado ao negcio. Dando continuidade ao Programa de Melhoria, a empresa tem a inteno de ser avaliada no nvel E. Indo mais alm ainda, neste perodo, a organizao entende que pode adquirir mais maturidade, bem como explorar um nicho de mercado internacional, que ir exigir uma certificao CMMI. Assim, somente aps galgar para o nvel E, a empresa tem como estratgia se capacitar e solicitar uma avaliao CMMI nvel 3. Adicionalmente, com a implementao dos processos, os projetos passaram a ser melhor gerenciados, permitindo uma maior qualidade dos produtos e servios. Com isso, a empresa pde se destacar diante de outras empresas ao implementar processos tambm no seu cliente, DER-CE, propiciando, desta forma, um grande diferencial, visto que a terceirizao passou a no ser uma mera mobilizao de mo-de-obra. A Domnio Informtica passou a oferecer aos seus clientes um processo de desenvolvimento aderente ao MPS.BR e disponibilizar profissionais capacitados em engenharia de software, sem nenhum custo adicional aos seus contratos, possibilitando, dessa forma, o desenvolvimento de um produto e uma prestao de servio com melhor qualidade. Assim, no apenas a empresa que se beneficia quando implementa a metodologia e obtm sucesso em uma avaliao que comprove o uso efetivo da mesma, mas tambm seus clientes, profissionais e o prprio mercado. A empresa, pelo
50
edio ta
D s
Feedback eu
sobre e s
processo
51

Esta seo traz artigos que apresentam como e quando utilizar as diferentes abordagens de VV&T no apoio ao desenvolvimento de projetos de software
Gerenciamento de Defeitos em Projetos de Software

Introduo Ferramenta BugZilla
Jenifer Vieira Toledo
jenifer@jenifer.eti.br

Gesto de bugs de software com a utilizao da ferramenta BugZilla. O artigo apresenta a utilizao da ferramenta para rastrear defeitos, desde a sua identificao feita pelo usurio at a sua correo. Aspectos gerenciais da ferramenta tambm so apresentados, desde a instalao, configurao de um novo produto de software e a evoluo do defeito observada pela equipe de desenvolvimento.
com qualidade e a relao do controle e identificao de bugs na busca por qualidade.
graduada em Cincia da Computao pela Faculdade Governador Ozanam Coelho (FAGOC), ps-graduanda em Gerncia de Projetos em Engenharia de Software pelo Centro de Ensino Superior de Juiz de Fora (CES/JF) e Tcnica de Hosting da Optical Solues em Informtica Ltda.

O rastreio de defeitos fornece equipe de desenvolvimento um importante diferencial para buscar qualidade em seus produtos. Esta tcnica permite que os defeitos sejam catalogados, desde sua identificao at sua resoluo. Para este fim, a ferramenta BugZilla utilizada para controlar e automatizar o processo de rastreio dos defeitos, o que diminui o tempo de resposta para a correo, deixando o processo de verificao de bugs mais organizado, aumentando assim a qualidade do produto de software e satisfao dos usurios, auxiliando a organizar a fase de manuteno de software.
Marcelo Santos Daibert

marcelo@daibert.pro Twitter: @MSDaibert
Para que serve?

Fornecer conhecimentos para verificar, na prtica e de forma organizada, bugs de software rastreados pela ferramenta BugZilla. Estabelecer uma viso crtica sobre a necessidade de se desenvolver software
professor e coordenador do Curso de Bacharelado em Cincia da Computao da FAGOC - Faculdade Governador Ozanam Coelho, Mestrando e Especialista em Cincia da Computao pela Universidade Federal de Viosa, Bacharel em Sistemas de Informao pela Faculdade Metodista Granbery e Gerente Tcnico da Optical Solues em Informtica Ltda.
Marco Antnio Pereira Arajo

maraujo@acessa.com
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF, Professor dos cursos de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora e da Faculdade Metodista Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora e Editor da Engenharia de Software Magazine.
m dos primeiros grandes marcos da histria da qualidade foi a revoluo industrial, iniciada em meados do sculo XVIII, quando houve um grande crescimento no nmero de indstrias substituindo o processo de fabricao manual pelo industrial. Esse processo permitiu a criao de produtos iguais, j que no processo manual manter este padro nem sempre era possvel. Com os avanos tecnolgicos
e culturais, motivados pelo fenmeno da revoluo industrial, houve a necessidade da criao de produtos com algum diferencial, j que nascia ali a concorrncia entre empresas, servios e produtos. Muitas empresas buscaram ento aprimorar seus mtodos de produo, para que minimizassem as despesas e maximizassem os lucros. Nascia ali um conceito hoje chamado de processo de melhoria contnua de produtos. Mais
52
Engenharia de Software Magazine - Gerenciamento de Defeitos em Projetos de Software
Validao, Verificao & Teste
tarde, a partir da dcada de 20, a produo industrial passou a se preocupar mais ainda com a qualidade dos produtos, com a finalidade de impedir que produtos com qualquer tipo de defeito chegassem s mos dos clientes. Nos dias atuais, a qualidade o grande diferencial para qualquer produto ou servio que uma empresa possa produzir ou oferecer. No atual contexto de desenvolvimento de software a qualidade j no mais um fator de diferenciao no mercado, mas sim, uma condio essencial para que as empresas e profissionais sejam bem-sucedidos. As empresas de software vm buscando certificaes ISO (International Organization for Standardization) e certificaes dos modelos de maturidade CMMI (Capability Maturity Model Integration) e MPS. BR (Melhoria de Processos do Software Brasileiro) como meio de comprovar sua qualidade no processo de desenvolvimento de software (ler Nota 1). Assim, torna-se importante a utilizao de mtodos e tcnicas que permitam avaliar de maneira abrangente a qualidade dos processos e dos produtos de software, garantindo que o usurio receba produtos dentro das especificaes definidas e esperadas por ele. Desde o surgimento da tarefa de desenvolvimento de software, grande parte dos recursos, seja financeiro ou esforo, so gastos na fase de manuteno do software. Segundo Roger Pressman, autor de um dos livros mais famosos de Engenharia de Software, a fase de manuteno pode ser responsvel por mais de 70% de todo o esforo despendido para a produo do software. Outros autores, e a experincia de algumas empresas, taxam nmeros semelhantes, o que nos fazem refletir sobre a importncia de padres e processos nas fases anteriores para minimizar esses gastos e esforo com manuteno. Na fase de manuteno onde so feitas melhorias e otimizao de um software j finalizado. Nessa fase so feitos os reparos de defeitos / bugs encontrados. Segundo Pressman, o custo da manuteno de software tem aumentado firmemente durante os ltimos 20 anos. Durante a dcada de 1970, a manuteno era responsvel por um ndice entre 35% e 40% do oramento de Software para uma organizao de sistemas de informao. Esse valor pulou para aproximadamente 60% durante a dcada de 1980. O autor ainda estima que, se nada for feito para minimizar os problemas nos software e conseqentemente minimizar os custos na fase de manuteno, muitas empresas gastaro 80% de seus oramentos de software em manuteno. Quanto mais eficiente for a fase de manuteno do software, mais fcil de mant-lo, e por conseqncia mais barato (seja mais barato financeiramente ou de esforo). Estes dados no levam em considerao uma importante parte envolvida no processo: o usurio e sua satisfao. A satisfao do usurio est diretamente ligada funcionalidade correta da aplicao. Um software com muitos defeitos, alm de causar prejuzos financeiros, gera insatisfao, mitigando a possibilidade de sucesso do processo de desenvolvimento de software. Ou seja, os custos de manuteno no se resumem ao gasto de dinheiro e esforo, mas tambm em atrasos no desenvolvimento, quebra de cronograma, insatisfao dos
clientes, reduo da qualidade global do software e tambm insatisfao dos funcionrios / desenvolvedores (envolvidos na tarefa de desenvolvimento). Diante dos fatos apresentados e da dificuldade em identificar e manter o controle sob os bugs / defeitos de um software (seja durante o desenvolvimento do software ou aps a finalizao do desenvolvimento, especialmente na fase de manuteno), este artigo tem como objetivo apresentar conceitos relacionados ao tema e introduzir a utilizao da ferramenta BugZilla para auxiliar nessa tarefa. Essa ferramenta utilizada para o controle e manuteno de bugs em projetos de software, e permite acompanhar / rastrear o bug desde a sua identificao, reporte e correo. So apresentados, durante o artigo, quais os requisitos necessrios para instalao da ferramenta, bem como o seu funcionamento como um sistema Web. Tambm so apresentadas as principais configuraes e as vises de utilizao do sistema sob a tica do administrador, usurio do software (software este cadastrado no sistema para receber os bugs relatados) e a equipe de desenvolvimento.
Bugs
O primeiro bug foi citado por Thomas Edison em 1878, quando um pequeno inseto identificado em seu fongrafo causou problemas de leitura. Nos Estados Unidos, em 1957, encontraram uma traa entre os circuitos do primeiro computador digital automtico de larga escala, o que causou um erro nos clculos da mquina. Este foi considerado o primeiro bug de um computador.
Nota do DevMan 1
ISSO, CMMI, MPS.BR ISO significa International Organization for Standardization (Organizao Internacional de Normalizao) e seu objetivo promover o desenvolvimento de normas, testes e certificao, com o objetivo de padronizar e encorajar o desenvolvimento de comrcio de bens e servios. uma organizao formada por mais de 90 pases e as normas da srie ISO 9000 so as principais normas internacionais sobre o gerenciamento e a garantia da qualidade. O CMMI um modelo de referncia que apresenta boas prticas necessrias maturidade em reas de conhecimento especficas, como, por exemplo, a engenharia de software. uma evoluo do CMM (Capability Maturity Model) e procura integrar os processos de melhoria corporativo em um nico modelo, integrando diferentes modelos e disciplinas. dividido, de acordo com a representao contnua, em nveis crescentes de maturidade, at o 5, sendo o nvel 5 o mais elevado da escala. Esses nveis de maturidade definem o grau de melhoria de processo para um pr-determinado conjunto de processos no qual todos os resultados esperados do processo e dos atributos dos processos so atendidos. Assim como o CMMI, O MPS.BR um modelo para melhoria de processo do software brasileiro e est em desenvolvimento desde 2003. dividido em sete nveis de maturidade: A (em otimizao), B (gerenciado quantitativamente), C (definido), D (largamente definido), E (parcialmente definido), F (gerenciado) e G (parcialmente gerenciado). A escala de maturidade se inicia no nvel G e evolui at o nvel A.
53
Por conta destes episdios, at hoje, ainda so chamados de bugs os defeitos de um software. Um defeito considerado um erro no funcionamento comum do programa ou uma falha na lgica da aplicao que causa impossibilidade de realizao de uma determinada ao ou tarefa. Um modelo de bug conhecido e que ficou muito famoso, especialmente pelo potencial dos problemas que causaria, o Bug do Milnio, onde na virada do ano de 1999 para 2000, devido ao armazenamento de datas com apenas 2 dgitos para o ano, fez com que o computador entendesse que estava no ano de 19 + 00, ou seja, 1900 e no no ano 2000. Vrios so os exemplos de defeitos em software que causaram prejuzos. Em 4 de junho de 1996, foi lanado o primeiro foguete Ariane e, aps decorrer 40 segundos da sequncia de lanamento e a uma altitude de 3700 metros, o foguete se desviou de sua trajetria e se autodestruiu com uma exploso. O custo desse desastre foi avaliado em mais de 300 milhes de dlares, quantia suficiente para pagar um salrio de 2,5 mil dlares a 100 programadores que trabalhassem durante um sculo. As investigaes sobre o acidente apontaram falhas no software de navegao, que causou um erro no clculo da velocidade horizontal do foguete. A gravidade de uma falha de software relativa. Existem falhas com as quais usurios podem conviver, a tal ponto que o sucesso de aplicao de um produto no seja afetado. Entretanto h outros casos, onde a falha do programa representa um completo fracasso comercial. H ainda os casos em que os bugs podem colocar em risco inclusive a segurana fsica de pessoas. Um exemplo so os softwares que controlam avies, to questionados nos ltimos anos por conta dos ltimos acidentes / incidentes noticiados pela mdia. Nota-se que, apesar do relato de um defeito ser um dos principais passos do processo de gesto de defeitos, normalmente ele relegado para segundo plano. O mito de software perfeito, sem defeitos, est longe de ser uma realidade. Se nenhum defeito foi encontrado em um software, certamente os defeitos no foram procurados de forma correta. Para encontr-los e identific-los preciso um mtodo e adoo de processos para este suporte, j que, so diversos os profissionais que dedicam seu tempo na tarefa de encontrar defeitos em aplicaes dos mais diferentes portes. Neste sentido, a ferramenta BugZilla atua como suporte a estas operaes, provendo um mecanismo eficiente de se reportar os bugs.
Bugzilla
O Bugzilla uma ferramenta de apoio tarefa de manuteno de software, sendo utilizada principalmente como centralizador para reporte de defeitos em software. um ambiente onde o desenvolvedor pode avaliar os bugs descobertos e traar metas para corrigi-los, registrando as solues de forma a possibilitar o acompanhamento do status do sistema e seus problemas. Foi desenvolvido inicialmente em TCL (Tool Command Language) por Terry Weissmam. Hoje a ferramenta
distribuda gratuita e com cdigo fonte aberto (freeware e opensource) e foi portada para a linguagem PERL. O seu cdigo fonte licenciado atravs do NPL (Netscape Public License) ou MPL (Mozilla Public License), junto com GNU ou GPL (Gnu Public License). Por ser uma ferramenta Web, o Bugzilla deve rodar em um servidor Web, configurado com suporte ao PERL em modo CGI. O desenvolvedor sugere (fortemente) a utilizao do APACHE (http://httpd.apache.org) como servidor Web. H uma srie de requisitos relacionados a mdulos PERL que devem ser instalados, como o CGI, DATA::FORMAT, EMAIL::SEND, EMAIL::MIME::MODIFIER, GD, entre outros. H uma relao completa destes mdulos requeridos e opcionais no manual de instalao da ferramenta, que pode ser encontrado na prpria pgina do Bugzilla. A ferramenta suporta o MySQL, PostgreSQL e Oracle como banco de dados. No contexto deste artigo foi utilizado o MySQL, entretanto o processo de instalao similar para qualquer dos bancos. O processo de instalao um pouco complexo, uma vez que os requisitos da ferramenta so vastos, especialmente com relao aos mdulos PERL. Entretanto, o desenvolvedor disponibilizou um script que busca automatizar este processo, mas para execut-lo necessrio ter acesso ao shell do servidor (SSH no Linux ou prompt do MS-DOS / telnet / terminal service no Windows), seja o servidor Windows ou Linux, uma vez que a ferramenta compatvel com qualquer um desses ambientes. Infelizmente nem todos os provedores de hospedagem comercial disponibilizam acesso shell ao servidor, o que dificultar a configurao. Mas, para os casos onde h esta possibilidade, ou at mesmo quando se for instalar a ferramenta na mquina local, a utilizao deste script facilitar o processo. O script se chama checksetup.pl e automatiza o processo de configurao inicial do Bugzilla. Para rod-lo, necessrio j ter configurado o servidor web para hospedar os scripts do Bugzilla, o PERL, os mdulos PERL, e ter criado uma base de dados no servidor de banco de dados escolhido. necessrio tambm j ter associado um usurio ao banco de dados criado com as devidas permisses na base. Com isso, o script, ao rodar, ir verificar se todos os mdulos Perl esto de fato configurados e caso falte algum, o script ir emitir um alerta e impedir a instalao. Caso todos os mdulos estejam instalados corretamente, o script ir perguntar o nome do banco de dados criado, o usurio associado ao banco e ir criar as tabelas necessrias para que o BugZilla rode. Neste processo, pelo script, possvel criar um usurio no sistema, que ser o usurio administrador do BugZilla, onde ter acesso interface administrativa da ferramenta. Feito isso, basta rodar a ferramenta via navegador no link que foi configurado no servidor web. Caso tudo tenha sido feito com sucesso, a tela que ser visualizada a apresentada na Figura 1. Esta interface representa a interface inicial da ferramenta na sua verso 3.4.4, ltima verso estvel liberada quando este artigo foi escrito.
54
Viso Administrador
O usurio administrador possui todas as permisses no sistema e quem tem acesso interface de configurao do BugZilla. Nela so definidas todas as configuraes e personalizaes da ferramenta. Este usurio criado no processo de configurao para utilizao da ferramenta. Para se logar na ferramenta, basta clicar em Log in na interface inicial. Assim que estiver autenticado, o administrador levado para a interface centralizadora de configuraes, que exibida na Figura 2. Sempre que qualquer usurio est logado, inclusive o Administrador, exibido no topo da pgina uma srie de links para aes genricas no sistema. As opes so: Home (Principal) Volta para a interface principal da ferramenta; New (Novo) Reporta um novo defeito; Search (Busca) Exibe uma interface de busca para defeitos reportados; Reports (Reportes) Exibe os defeitos j reportados, inclusive com a opo de visualizao grfica dos defeitos; My Votes (Meus Votos) Apresenta os votos feitos pelo usurio em algum defeito com o objetivo de confirm-lo como um defeito; Preferences (Preferncias) Disponibiliza uma interface para configurao personalizada especfica para o usurio autenticado; Administration (Administrao) Somente o usurio Administrador tem acesso a esta interface, que disponibiliza um centralizador de todas as configuraes e personalizaes da ferramenta. Ao clicar nesta opo, exibida a interface exibida na Figura 2;
Figura 1. Interface Inicial do BugZilla
Nas prximas sees deste artigo so apresentadas trs ticas diferentes de utilizao do sistema. Inicialmente apresentada a tica de configurao do sistema, atravs do Administrador do BugZilla. Aps isso, apresentada a viso do usurio comum, responsvel por reportar defeitos, pesquisar defeitos j reportados, entre outros. Por fim, apresentada a viso do desenvolvedor, onde pode visualizar os bugs j reportados, classificar estes defeitos e ento traar metas para corrigi-los. No artigo apresentado o BugZilla na sua interface oficial e em ingls. No site do desenvolvedor h uma srie de pacotes de traduo, inclusive Portugus-BR. Entretanto, a ltima verso do pacote de traduo BR somente compatvel com a verso 3.0 da ferramenta.
Figura 2. Interface Administrativa do BugZilla
55
Log out (Sair) Encerra a sesso do usurio autenticado na ferramenta. Na interface de Administrao (Administration), onde somente o usurio administrador tem acesso, so disponibilizadas as seguintes opes: Parameters (Parmetros) Viabiliza a configurao das principais propriedades e parmetros da ferramenta. Default Preferences (Preferncias Padro) Altera as preferncias padro dos usurios. Os valores definidos nesta interface so utilizados por todos os usurios da ferramenta. Entretanto, o usurio aps se autenticar, pode acessar a interface Preferences (Preferncias) para personalizar essas variveis conforme seu gosto, e no ao gosto do Administrador. Sanity Check (Checagem de Sanidade) Executa um teste de sanidade no sistema, especialmente na base de dados, verificando se tudo est funcional. Users (Usurios) Possibilita a administrao dos usurios no sistema. Criao de novos usurios, edio, excluso e visualizao dos j cadastrados. Ainda possvel manipular as permisses dos usurios cadastrados. Products (Produtos) Onde so definidos os produtos que podero receber reportes de defeitos. Geralmente um software. Flags (Bandeiras) - Flags so marcadores que identificam se um defeito ou anexo tenha sido autorizado ou negado algum status da ferramenta. Custom Fields (Campos Personalizados) Permite a configurao de campos personalizados para o cadastro de produtos (software) e defeitos.
Field Value (Valor dos Campos) Define um valor padro para os campos padro do sistema ou campos personalizados definidos pelo administrador na opo Custom Fields (Campos Personalizados). Bug Status Workflow (Fluxo de Trabalho dos status dos bugs) Cada bug reportado no sistema ir ter um status que ser apresentado ainda neste artigo. Esta opo permite estabelecer um fluxo de trabalho entre esses status, inclusive a ordem que eles podem ser alterados, desde a sua criao at seu fechamento. Groups (Grupos) Permite a definio de grupos para usurios que estabelecem permisses de acesso ao sistema. A prpria ferramenta j define um padro, mas que pode ser personalizado conforme a preferncia do administrador. Keywords (Palavras Chaves) Define palavras chaves para serem usadas com os bugs. usada para estabelecer uma TAG para os bugs, facilitando a sua manipulao e classificao futura. Whining (Uma espcie de tarefas agendadas) Permite definir operaes para serem executadas em dia e hora programados. Ao selecionar a opo Parameters (Parmetros) apresentada a interface exibida pela Figura 3. Como j apresentado, essa opo permite a edio das preferncias e propriedades da ferramenta, como o email do administrador do sistema, qual a URL que o sistema est configurado, como feita a autenticao dos usurios, como os emails so enviados pela ferramenta (sendmail, smtp, entre outros), onde e como so armazenados os anexos que os usurios podem enviar quando reportam um bug, entre outros.
Figura 3. Interface Administrativa de Parmetros de Sistema
56
A Figura 4 apresenta a interface de Usurios, onde possvel configurar os usurios da ferramenta. Nessa interface, o Administrador pode editar os usurios j cadastrados, alterando inclusive suas permisses de acesso, e incluir novos usurios. Entretanto, qualquer usurio pode se cadastrar no sistema pela interface inicial (Principal) do Bugzilla, sem a necessidade que o Administrador o cadastre. Mas caso seja da vontade do Administrador, possvel restringir os cadastros, sendo necessria a aprovao do Administrador para que o usurio cadastrado tenha permisso de reportar bugs. J a Figura 5 apresenta a interface de edio de um usurio cadastrado, onde possvel alterar seus dados, e especialmente seus Grupos, onde so definidas suas permisses de acesso ao sistema. Esses grupos so definidos na opo Groups (Grupos) na interface de Administrao do Administrador. No exemplo apresentado, observe que o usurio est no grupo admin: Administrators, que possui permisso de acesso total no sistema. Na opo Products (Produtos) onde so definidos os produtos (geralmente softwares) que o Bugzilla ir rastrear os defeitos. Assim que selecionada, exibida a interface onde so visualizados os
produtos cadastrados, como na Figura 6. Nessa mesma interface disponibilizada uma opo para cadastrar um novo produto, editar um produto existente ou exclu-lo. Veja que, no exemplo, h um produto cadastrado com o nome Software Teste Bugzilla. Este produto est aberto para recepcionar novos bugs dos usurios. Foi ainda configurado um limite de 10000 votos para cada bug reportado, e um mnimo de 3 votos para confirmar um bug. Essa opo de confirmar um determinado bug especialmente importante, pois permite alterar automaticamente o status de um bug de Novo para Confirmado de acordo com os votos dos usurios. Ou seja, se mais de 3 usurios estiverem reportando o mesmo bug, este est confirmado e merece uma ateno maior da equipe de desenvolvimento e correo de defeitos.
Figura 6. Interface Administrativa de Visualizao dos Produtos
Figura 4. Interface Administrativa de Visualizao de Usurios
Figura 5. Interface Administrativa de Edio de Usurios
Ao selecionar um bug cadastrado, ou ento clicar em adicionar um novo produto (Add a product), exibida a interface apresentada na Figura 7. Nela possvel configurar os parmetros do produto, como nome do produto, uma descrio, se ele est aberto ou fechado para recepcionar novos reportes, qual o mximo de votos que um usurio pode dar no produto, globalmente, e em um defeito especfico, o mnimo de votos para confirmar o defeito, o componente do produto (pode haver vrios componentes, como por exemplo, interface do sistema, mdulo de pagamento em um sistema de vendas, entre outros), a verso do sistema (define a baseline do software) e o grupo que este produto est inserido. J na opo Bug Status Workflow (Figura 8) onde so definidos os status dos defeitos no sistema. Especificamente nessa interface configurado o fluxo de trabalho entre os status. Os principais status so definidos abaixo: Unconfirmed: no confirmado, geralmente o estado inicial de todo bug. Significa que ningum ainda verificou a validade do bug (confirmao). Usurios com permisso podem passar um bug de Unconfirmed para New. Geralmente o responsvel pelo bug ou outra pessoa tenta reproduzir o bug e, se ele realmente ocorrer, marcado como New. O bug nesse estado pode passar por votao para mudar para New (quantidade mnima de votos), e ser um novo bug. O bug nesse estado pode ser diretamente resolvido e marcado Resolved. Para todos os estados existe possibilidade de loop;
57
pela Figura 10. Nessa figura, possvel identificar o grupo admin, que possui todas as permisses de acesso. Entre as principais permisses destacam-se a possibilidade de editar um bug, editar uma classificao de um bug, poder confirmar um bug (geralmente atribuda a um membro da equipe de desenvolvedores, por exemplo), editar usurios, editar componentes dos produtos, entre outros.
Figura 7. Interface Administrativa de Configurao dos Produtos
New: o bug novo, pertence lista de bugs pessoais do responsvel pelo bug, e deve ser processado. O responsvel (desenvolvedor), em conjunto com outras pessoas ou no, analisa o bug e decide se o aceita. Se for aceito, o bug deve ser passado para o status Assigned. Se no for aceito, a responsabilidade pelo bug pode ser atribuda outra pessoa e ele ser mantido como New. Bugs nesse estado podem ser diretamente solucionados e marcados como Resolved; Assigned: nesse estado, o bug foi aceito por alguma pessoa, que responsvel por ele. Essa pessoa pode resolv-lo sozinha ou com participao de mais pessoas, e ento o bug passado para Resolved. Esse estado o principal e, geralmente, o bug encontra-se nesse estado quando algum est trabalhando em uma soluo para ele. Se necessrio, a responsabilidade pelo bug pode ser atribuda (Reassigned) para outra pessoa, e ento ele passa para estado New; Resolved: uma soluo foi dada ao bug, para algum dos tipos de soluo. A partida desse estado pode acontecer da soluo dada ser incorreta ou conter falhas e o bug precisar ser reaberto (passar para Reopened). Se a soluo estiver correta, ele pode ser fechado e passar para Closed. Se for necessrio esse bug ser verificado por algum ou por um grupo de pessoas antes de ser fechado, isso deve ser feito e ele pode passar para Verified ou ser reaberto. Nesta opo de workflow, so definidos os estados em que so permitidos a transio. Com isso o Administrador pode proibir, por exemplo, que um bug no confirmado (Unconfirmed) passe diretamente para o estado Assigned. Ou seja, definido um workflow para estes estados. Por fim, temos a interface de administrao (Figura 9) responsvel por gerir os grupos de usurios e suas permisses. Nesta interface so apresentados os grupos existentes e suas descries, alm de uma opo de adicionar um novo grupo. Ao clicar em um grupo existente exibida a interface de edio de grupo (mesma quando se clica ao cadastrar um novo). Nela permitido configurar o grupo e atribuir permisses a usurios deste grupo, como apresentado
Figura 8. Interface Administrativa de Fluxo de Trabalho dos Status de Defeitos
Figura 9. Interface Administrativa de Visualizao de Grupos
Figura 10. Interface Administrativa de Configurao de Grupos
58
Viso Usurio
Esta seo tem como objetivo apresentar a viso de um usurio comum que se registra na ferramenta para reportar algum bug em algum produto j previamente cadastrado pelo administrador. Ao entrar na URL da ferramenta que foi configurada, o usurio ir visualizar exatamente a mesma pgina apresentada na Figura 1. Nesta interface o usurio possui a possibilidade de procurar algum bug j reportado em Search (Busca), reportar um novo defeito (New / File a Bug), se autenticar no sistema (Log In) ou criar uma nova conta (New Account / Open a New Account). Para criar uma nova conta, o processo bem simples. Basta acessar a opo correta que na interface seguinte ser solicitado o seu email. O Bugzilla ento ir enviar um email para o que foi digitado como forma de verificar se o email vlido. Neste email enviado haver um link com informaes para finalizar o cadastro. Com seu cadastro ativo, o usurio pode se autenticar no sistema para reportar algum bug. Assim que solicita esta opo, o usurio levado para a interface apresentada na Figura 11. Nela possvel escolher o produto a qual se refere o reporte, o componente do produto, sua verso, a severidade do defeito encontrado, qual hardware foi utilizado ao encontrar o defeito e o sistema operacional. Abaixo solicitado um breve sumrio do defeito bem como sua descrio. H ainda a opo de anexar algum arquivo como, por exemplo, algum log do sistema ou um screenshot da tela, como forma a auxiliar o desenvolvedor a identificar o bug.
acompanhar a evoluo do defeito reportado por ele atravs da opo de busca. Ao encontrar o seu bug reportado, exibida uma interface com todos os detalhes do bug e a possibilidade de adicionar comentrios. Qualquer usurio pode adicionar qualquer comentrio ao bug, mesmo que seja um bug que ele no tenha reportado.
Viso Desenvolvedor
O desenvolvedor, ao se autenticar no sistema, tem a opo de pesquisar por bugs de um determinado produto e ver todos os bugs reportados, como visualizado na Figura 12. Ao clicar no bug escolhido, ele ir visualizar os detalhes daquele bug, poder interagir com o usurio que reportou e com os demais usurios que esto acompanhando o reporte. L possvel tambm evoluir o status do bug at corrigi-lo ou ento no o confirmar, como podemos ver na Figura 13.
Figura 12. Visualizao dos Defeitos Reportados
Figura 11. Interface de Reporte de Defeito
Assim que cadastrado o defeito, mantido sob o status New (novo). Este poder ser alterado automaticamente para confirmado se alcanar o nmero mnimo de votos ou ento manualmente pela equipe de desenvolvimento responsvel por analisar os reportes enviados pela ferramenta. O usurio pode
Figura 13. Visualizao dos Detalhes de um Defeito
Consideraes Finais
O Bugzilla uma ferramenta de apoio tarefa de manuteno de software. Por ser em ambiente Web, permite que qualquer usurio facilmente reporte um defeito encontrado
59
60
edio ta
em qualquer tipo de aplicao. Apesar da instalao ser um pouco complicada, a ferramenta amplamente utilizada pelas empresas de desenvolvimento de software como plataforma de registro de defeitos. Existem uma srie de ferramentas de bug tracking, como o Bugzilla. Destacamos: Eventum (http://dev.mysql.com/downloads/other/eventum/ ), FogBugz (http://www.fogcreek.com/ FogBUGZ/ ), Jira (http://www.atlassian.com/software/jira/ ), Mantis (http://www.mantisbt.org/ ), Trac (http://trac.edgewall.org/ ), Zephyr (http://www.getzephyr.com/ ), entre outras. Mesmo com tantas outras opes, o Bugzilla a ferramenta mais famosa e amplamente usada, especialmente por est presente no sistema de rastreio de defeitos de gigantes como Mozilla, Gnome, Nasa, Wikipedia, entre outros. A Ferramenta Bugzilla foi construda com suporte a adies, chamadas de Bugzilla Additions. Esses additions so realmente adies na ferramenta que permitem que qualquer desenvolvedor possa desenvolver uma nova funcionalidade a ser agregada. Um que merece especial destaque o Addition chamado Bugzilla Test Runner. Ele adiciona a
funcionalidade de gerenciador de casos de teste no Bugzilla, permitindo ao desenvolvedor cadastrar seus casos de teste na ferramenta e associar estes a defeitos reportados por usurios. Esse em especial importante para empresas de desenvolvimento que mantm prticas de teste de software no seu processo de desenvolvimento.
Links Site Oficial da Ferramenta Bugzilla http://www.bugzilla.org
D s
Feedback eu
sobre e s
62

Es22 - MPSBR

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Es22 - MPSBR

Hochgeladen von

Copyright:

Verfügbare Formate

Modstia parte, sua melhor opo para se destacar no mercado!

Engenharia de Software: Desenvolvimento Java Engenharia de Software: Desenvolvimento .NET

Engenharia de Computao Anlise e Desenv. de Sistemas

r/esti Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti

EDUCAO SUPERIOR ORIENTADA AO MERCADO

Rodrigo Oliveira Spnola

Kaline Dolabella Gerente de Marketing e Atendimento kalined@terra.com.br

Marco Antnio Pereira Arajo

Fale com o Editor!

Eduardo Oliveira Spnola

Abordagens Tradicionais de Desenvolvimento 11 - Guias 2009 do MPS.BR: o que mudou?

18 - Fatores crticos de sucesso em programas de melhoria de processo

23 - ITIL: Por onde comear?

30 - Arquitetura Orientada a Servios

46 - Experincias da Domnio Informtica na Implantao do MPS.BR

Validao, Verificao e Teste 52 - Gerenciamento de Defeitos em Projetos de Software

Engenharia de Software Magazine

Abordagens geis de Desenvolvimento

Experincia em Automao de Testes

Para que serve? Eliane Collins

Em que situao o tema til?

Edio 22 - Engenharia de Software Magazine

Engenharia de Software Magazine - Experincia em Automao de Testes

Validao, Verificao e Teste

Figura 1. Esqueleto do Scrum

Viso Geral sobre o Projeto Testado

Ambiente gil de Desenvolvimento SCRUM

Edio 22 - Engenharia de Software Magazine

Figura 2. Caso de Teste

Experincia no Processo de Automao de Teste

Figura 3. Histria que descreve o Caso de Uso

Figura 4. Critrio de Aceitao para o fechamento da histria

Engenharia de Software Magazine - Experincia em Automao de Testes

Validao, Verificao e Teste

funcionalidades desenvolvidas e as mtricas de teste geradas pelos grficos e relatrios do TestLink.

Figura 6. Exemplo de execuo de caso de teste que passou

Figura 5. Exemplo de bugs cadastrados no Mantis

Edio 22 - Engenharia de Software Magazine

Engenharia de Software Magazine - Experincia em Automao de Testes

D seu feedback sobre esta edio!

Abordagens Tradicionais de Desenvolvimento

Guias 2009 do MPS.BR: o que mudou?

Para que serve?

Em que situao o tema til?

Edio 22 - Engenharia de Software Magazine

Nvel G Parcialmente Gerenciado

Engenharia de Software Magazine - Guias 2009 do MPS.BR: o que mudou?

Nvel E Parcialmente Definido

Nvel D Largamente Definido

Edio 22 - Engenharia de Software Magazine

Novos guias de implementao

Nvel B Gerenciado Quantitativamente

Organizaes que adquirem software

Engenharia de Software Magazine - Guias 2009 do MPS.BR: o que mudou?

Organizaes do tipo Fbrica de Teste

Organizaes do tipo Fbrica de Software

Edio 22 - Engenharia de Software Magazine

Engenharia de Software Magazine - Guias 2009 do MPS.BR: o que mudou?

Edio 22 - Engenharia de Software Magazine

D seu feedback sobre esta edio!

Abordagens Tradicionais de Desenvolvimento

Fatores crticos de sucesso em programas de melhoria de processo de forma cooperada

Geovane Nogueira Lima