Melhoria de Processos de Software

Carlos Diego Cavalcanti Pereira1, Luiz Vieira e Silva Filho1, Paulo Lins Rodrigues Junior1, Ubiracy dos Santos Rego Jnior1
1

Centro de Informtica Universidade Federal de Pernambuco (UFPE) Recife Pernambuco Brasil

cdcp@cin.ufpe.br; lvsf@cin.ufpe.br; plrj@cin.ufpe.br; usrj@cin.ufpe.br

Abstract. The purpose of this survey article is to analyze and compile publications related to models of software processes improvement. This paper considers national and international periodicals, congresses and annuals, in the period between 1995 and 2012. Resumo. O objetivo deste artigo de reviso bibliogrfica analisar e compilar publicaes relevantes no que tange a modelos de melhoria de processos de software. Este trabalho considera peridicos, congressos e anurios nacionais e internacionais, entre o perodo de 1995 e 2012.

1. Introduo Em sua essncia, um processo um conjunto de atividades realizadas a fim de produzir um resultado. Considerando uma viso mais moderna e multidisciplinar, processo considera a integrao entre atividades, insumos e infraestrutura requeridos para adio de valor. Na Engenharia de Software, o processo descreve o fluxo necessrio para produo e entrega de um sistema de maneira eficiente, previsvel e que corresponda aos requisitos especificados pelo negcio. O SWEBOK (IEEE, 2004), Software Engineering Body of Knowledge, guia de conhecimento de Engenharia de Software mantido pelo IEEE (Institute of Electrical and Electronics Engineers) descreve o processo de software:
The Software Engineering Process Knowledge Area is concerned with the definition, implementation, assessment, measurement, management, change, and improvement of the software engineering process itself.

De acordo com Reis (2003), construir software uma atividade cooperativa que depende da qualidade de comunicao entre os envolvidos no desenvolvimento. Esse contexto evidencia a importncia de diversos fatores que envolvem a construo de ambientes e ferramentas que atuam na modelagem, execuo simulao e evoluo de processos de desenvolvimento de software. Portanto, processos de software correspondem ao conjunto de atividades realizadas desde a concepo at a liberao do produto de software. Com a competitividade crescente no mercado atual, as empresas de software tm buscado formas de melhorar a qualidade de seus produtos visando atingir um diferencial no mercado e atender a clientes cada vez mais exigentes. Essa busca pela melhor

qualidade est relacionada diretamente a melhoria do seu modelo de processos. Grande parte dos projetos de software entregue, porm invariavelmente fora dos custos e prazos previamente estabelecidos e pior: no atendendo as expectativas e requisitos institudos pelo cliente, o que gera retrabalho em anlise e codificao das solues (Ambler, 2002). Segundo Reis (2003), estudos publicados por Weber et al. (1995) mostram que a indstria nacional de software ainda adota em muitos casos prticas artesanais durante o processo de desenvolvimento. Para Moitra apud Reis (2001), um dos grandes obstculos para favorecer o crescimento de uma indstria de software em pases em desenvolvimento a disponibilizao de infraestrutura necessria gerncia dos processos implantados nas organizaes. Essa infraestrutura, alm de prover a gerncia dos processos j existentes, fornece o suporte necessrio para a anlise de pontos de melhoria. Casos de sucesso em pases como a ndia, evidenciam os diversos benefcios provenientes da maturidade dos processos de Software. Segundo Reis (2003), esses benefcios variam desde a simples soluo de dificuldades especficas atravs da melhoria contnua, at a certificao a partir de avaliaes formais, onde as empresas participantes atingem um reconhecimento internacional da qualidade dos seus produtos e processos. Para Pfleeger apud Rocha (2005), o desenvolvimento das solues de software e apoio s necessidades dos clientes devem, entre outros fatores, ser mais produtivas e diminuir o custo dos projetos. Em virtude dessas necessidades, as empresas esto adotando prticas de reengenharia de processos para aumentar seu nvel de maturidade. Decorrente desse contexto, diversos modelos de referncia e normas internacionais de qualidade de processos foram definidos para atender as necessidades das empresas em melhoria de processos de software (Rocha, 2005). Esses modelos servem no s para a melhoria dos processos de uma empresa, como tambm servem para titulao perante o mercado, dando aos clientes uma forma de avaliar seus possveis fornecedores.
Tem sido de grande importncia para a rea a definio de modelos de avaliao do processo de engenharia de software em organizaes. As organizaes de desenvolvimento de software tm procurado atender aos requisitos de tais modelos, a fim de terem seu processo de desenvolvimento avaliado de forma positiva frente ao mercado. (Reis, 2003)

Os modelos de maturidade descrevem os estgios de maturidade pelos quais as organizaes devem passar, atravs de avaliao contnua, identificao de problemas e aes corretivas, de modo a melhorar continuamente seus processos. Para permitir uma adequada anlise e comparao entre modelos existentes, necessria a utilizao de ferramentas adequadas que possibilitem a visualizao do processo de desenvolvimento de uma empresa, dando suporte tomada de deciso dos profissionais da rea de processos. Segundo Reis (2003), a rea de Engenharia de Software tem produzido ferramentas para auxlio ao desenvolvimento, assim como tem estudado e desenvolvido formas de controlar o processo de produo de software. Porm, as ferramentas existentes possuem limitaes, principalmente por no considerar caractersticas

importantes dos processos de software, como a flexibilidade e aspectos humanos envolvidos. Melhorar os processos de uma organizao implica em fazer ajustes, implantar novos processos e muitas vezes executar mudanas radicais na forma de trabalho de uma empresa. Em pesquisa realizada por Rocha (2005), foram levantados os principais fatores determinantes do sucesso ou insucesso da implantao de processos nas organizaes, esses fatores vo desde aspectos motivacionais at ao nvel de competncias dos envolvidos. Os principais fatores de sucesso so: Comprometimento dos colaboradores da organizao e da alta gerncia; Motivao da equipe da empresa; Disponibilidade de tempo para acompanhamento pela equipe implementadora; Grau de experincia da equipe de implementadores; Alinhamento dos processos com as estratgias de negcio da empresa; Relacionamento dos resultados da melhoria com a melhora dos resultados de negcios da empresa.

Sobre os principais fatores de insucesso, foram elencados: Competncia da equipe da empresa em engenharia de software; Mudana da cultura organizacional; Dificuldades encontradas a respeito da estratgia de implementao; Falta de comprometimento da alta gerncia; Ausncia de ferramentas de apoio execuo dos processos.

As empresas tm enfrentado grandes desafios na execuo de suas melhorias. Estudos publicados por Rocha (2005) e Reis (2003) deixam claras as dificuldades encontradas na implantao de novos processos de software, dificuldades essas que vo desde problemas de infraestrutura (ferramentas) a questes de resistncia e metodologia adotada para conduzir a estratgia de implementao. De acordo com o SWEBOK, o processo de mudana constitui um caso de mudana organizacional, e os mais bemsucedidos esforos de mudana organizacional tratam a mudana como um projeto, com planos adequados, monitoramento e reviso. A melhoria de processos de software uma ao contnua, realizadas atravs de aes para alterar os processos j existentes para que os mesmos atendam de forma mais eficiente a necessidades de negcio da organizao. Por serem contnuas e envolverem desafios nos mais diversos nveis, essas mudanas devem ser incorporadas atravs de motivao, esforo e colaborao de todos os envolvidos no processo. 2. Definio de Processos de Software Quando se aborda a expresso Processo de Software, comum que tanto clientes como desenvolvedores sejam remetidos mesmo que no integralmente a algo burocrtico, limitador e principalmente, que no contribui para o produto fim: o software. Parte desse sentimento justificada pelo fato de que os responsveis pelos processos de software esquecem que o objetivo primrio no desenvolvimento de software produzir sistemas da forma mais eficiente e efetiva possvel, e que

principalmente atenda as necessidades dos seus usurios (Ambler, 2002). Com essa prerrogativa, um bom processo de software fundamental para garantir que os sistemas sejam desenvolvidos da forma mais eficiente e eficaz, atendendo no s as expectativas dos usurios como tambm dos desenvolvedores. As dificuldades que surgem em projetos de software tm como causa raiz o desalinhamento entre a perspectiva do negcio tanto do cliente como da desenvolvedora quanto estruturao do processo de desenvolvimento de forma a atender as expectativas das partes. Dessa assertiva surge a demanda pela definio de um processo formal para o desenvolvimento, de forma a propiciar esse alinhamento.
De maneira geral, as organizaes selecionam um modelo como guia para definio de seus processos, quer estejam buscando certificaes, quer estejam em busca do estabelecimento de novas prticas, organizao e melhoria de seus processos de trabalho. A dinmica deste trabalho compreende, em linhas gerais, a definio de metas de melhoria a serem atingidas pela organizao a partir das prticas sugeridas pelo modelo selecionado. Com base nestas metas e em suas caractersticas particulares (tipo de software desenvolvido, equipe, natureza da organizao, cultura preexistente), cada organizao se v em face de definir a forma de implementao das prticas escolhidas seus processos. O conjunto de processos e seu uso institucionalizado pela organizao correspondero, em grosso modo, ao principal resultado da iniciativa. Arajo et al., 2002.

Desenvolver sistemas no puramente codifica-los, pois envolve uma srie de etapas, atividades e especialistas convergindo para este fim a produo do software. Quando se utiliza essa prerrogativa, inerentemente se atribui que previamente codificao, o bom entendimento dos requisitos do negcio fundamental. Ou seja, assume-se que sem compreender bem o contexto em que o software ser submetido, e que funes ele exercer, praticamente impossvel produzir um sistema que atenda dita necessidade. Olhando pela perspectiva da organizao produtora do software, essa assertiva reveladora. Quando se discute a importncia da adoo de processos de softwares estruturados, busca-se em primeiro lugar compreender como se d o negcio de quem produz as solues, a fim de que essa organizao estruture seus processos de forma tal que sejam concebidos sistemas de qualidade. Ou seja, esse um sinal caracterstico de que um bom processo de software corrobora bastante para o desenvolvimento de um bom produto. A definio de um processo de software no , porm, uma tarefa simples de proceder. Devem-se analisar as especificidades de cada projeto, levando-se em considerao a adaptao com as tecnologias envolvidas, o contexto do negcio, o tipo de software desejado, o grau de conhecimento dos envolvidos na rea da engenharia de software e as peculiaridades da organizao (Rocha et al., 2001). Contudo, no uma boa estratgia definir um processo novo para cada projeto a ser desenvolvido, ainda que cada projeto tenha sua particularidade, podem-se determinar grupos de elementos ou ativos que sejam utilizados em todos os processos da organizao. Esses elementos viabilizam a

criao de processos padro da organizao, que podem ser instanciados com as especialidades das vrias categorias de projetos existentes na organizao. A indicao dos elementos de um processo de software baseia-se nos modelos e normas de qualidade, que so delineadores para a definio de processos de qualidade. A crescente necessidade de estruturao, documentao e padronizao de processos de software vem sendo uma prtica entre as empresas que passam a ser avaliadas atravs de normas e modelos de qualidade, como por exemplo, ISO/IEC 12207 (ISO, 1995), CMMI (Chrissis et al., 2003) e o MPS.BR (Softex, 2005). O principal elemento encontrado nas normas e modelos de qualidade a definio de um processo padro que elenca as atividades a serem executadas nos projetos de software de uma instituio e indicam os ativos envolvidos no processo, como artefatos, ferramentas, procedimentos e papis. O planejamento de um processo de software especfico tendo como embasamento um processo padro facilita aos gerentes a criao de planos que estejam em concordncia com os padres de qualidade, procedimentos e polticas da organizao (Berger, 2003). Para que um processo obtenha resultados satisfatrios, ou seja, resulte em produtos de qualidade, ele deve estar adaptado s caractersticas particulares do projeto, como o tipo de software que ser desenvolvido, o tamanho, a complexidade e as caractersticas dos membros da equipe. Mas o processo padro da organizao no ser capaz de dar suporte exclusivamente s atividades de um dado projeto, haja vista que ele deve ficar em um nvel de abstrao que englobe todas as iniciativas de projetos de desenvolvimento. Portanto, ser preciso utilizar uma abordagem flexvel para a definio de processos, que venha promover a adequao dos processos padro da organizao s caractersticas exclusivas de cada projeto. A Figura 1 representa esta abordagem flexvel estruturada em nveis (Rocha et al., 2001).

Figura 1 Representao em Nveis para a Definio de Processos (Rocha et al., 2001).

Nesta abordagem, primeiramente definido um processo de software padro para a organizao, baseado em modelos de qualidade, como por exemplo, CMMI e ISO/IEC 12207. Esse processo padro considera somente os elementos fundamentais, como atividades, recursos, artefatos e procedimentos, que podero ser utilizados em qualquer processo da organizao. Esse processo obtido estar em um nvel de abstrao que dificultar o trabalho de um gerente de projeto adequ-lo a um projeto especfico.

E como na mesma organizao podero surgir projetos para o desenvolvimento de um mesmo tipo de software, com mesmo domnio ou projetos que adotem um mesmo paradigma, ento esse processo padro poder ser particularizado para considerar essas caractersticas. Nesta fase de adequao, os ativos do processo podem ser adicionados ou alterados de acordo o contexto da mudana. Por fim, o processo padro especializado poder ser adaptado a um determinado projeto, levando em considerao caractersticas especficas do projeto e da equipe. Nessa etapa, define-se o modelo de ciclo de vida, novas tarefas, recursos, artefatos e procedimentos que podero ser incorporados. Ressalta-se que, no garantia de qualidade no produto resultante quando se estabelece um processo bem estruturado, mas influencia bastante na possibilidade de obter ao fim da execuo do processo um produto de software que esteja de acordo com os requisitos. 2.1. Modelos de Ciclo de Vida de Processos A definio de um processo de software abrange a escolha de um modelo de processo, que pode ser entendido como um esquema abstrato que inclui algumas atividades principais, a organizao de precedncia entre as mesmas e os artefatos consumidos e gerados. Generalizando, um modelo de processo descreve uma estrutura de organizao das atividades dos processos em fases e como essas fases se relacionam. De forma geral os modelos de processos envolvem as fases de Requisitos, Projeto, Implementao, Testes, Entrega e Implantao. A escolha de um modelo de processo est diretamente ligada s caractersticas do projeto. A seguir so apresentados os principais modelos de Ciclo de Vida de Processos previstos na literatura (Sommerville, 2000; Pressman, 2002): Modelo Cascata Esse modelo tambm chamado de modelo de ciclo de vida clssico e caracterizado por organizar as atividades do processo de desenvolvimento em uma sequncia linear de fases, onde cada fase engloba a confeco de um ou vrios documentos. Uma vez aprovados, dar-se incio a prxima fase, ou seja, a fase subsequente s iniciada aps o trmino da fase que a antecede. A entrega do produto de software acontece no fim da fase de Implantao. Cada fase considerada como uma etapa confirmada e documentada para o prximo passo, auxiliando a gerncia de configurao.

Figura 2 Modelo de Ciclo de Vida em Cascata.

Quanto s desvantagens do modelo em cascata: o Os projetos reais raramente seguem o fluxo sequencial do modelo; o Os requisitos tem que estar definidos claramente logo no incio do projeto. O entendimento por parte do desenvolvedor tem que ocorrer no incio, etapa em que complicado para o usurio descrever bem os requisitos. o O usurio tem que esperar at o final do projeto para ter um produto de software operacional. Apesar das dificuldades, este modelo indicado para projetos de pequeno porte e bem definidos, onde o domnio do problema e os requisitos podem ser facilmente consolidados, sendo fcil o seu gerenciamento. Modelo de Prototipagem Este modelo utilizado quando todos os requisitos do software no esto bem definidos pelo cliente, onde apenas os objetivos gerais esto claros. A principal caracterstica desse modelo produzir prottipos a partir dos requisitos do cliente. Com um primeiro prottipo criado, o ciclo de desenvolvimento se repete, sendo necessrio realizar o levantamento de novas funcionalidades, as quais sero adicionadas ao prottipo j existente. Uma vez as funcionalidades do prottipo estejam validadas, iniciado o desenvolvimento do software definitivo, utilizando como base o prottipo. A grande vantagem deste modelo a gerao de resultados visveis ao usurio, em um curto espao de tempo e ao final de cada iterao. A prototipao ajuda a criar o entendimento do que deve ser construdo tanto para os desenvolvedores quanto os clientes, uma vez que os requisitos no estejam bem definidos. A Figura 3 exemplifica um modelo em cascata com prototipao.

Figura 3 Modelo de Ciclo de Vida em Cascata com prototipao.

Modelo de Incremental

Este modelo que se caracteriza por disponibilizar ao usurio uma verso do software contendo algumas funcionalidades enquanto outras esto sendo desenvolvidas. Em casos em que o software seja de grande porte, o usurio no precisar esperar tanto tempo para usufruir de uma verso operacional. No desenvolvimento incremental, em cada ciclo so adicionadas novas funcionalidades, e as funcionalidades j desenvolvidas podem ser melhoradas para atender s expectativas dos usurios.

Figura 4 Variaes do Modelo de Ciclo de Vida Incremental.

A Figura 4 mostra que realizado um levantamento preliminar dos requisitos na fase de planejamento. A partir desses requisitos, os incrementos so planejados a fim de desenvolver a primeira verso do software. Com o trmino da primeira iterao, todas as atividades so executadas novamente na segunda iterao, incluindo o planejamento, onde se pode revisar a implicao dos requisitos aos respectivos incrementos. A variao apresentada na Figura 4 (b) mostra que os requisitos so descritos para o sistema como um todo e os ciclos ocorrem a partir da fase de anlise. A Figura 4 (c) mostra que os requisitos j so especificados e analisados, como tambm a arquitetura do software j definida, restando as fases de detalhamento do projeto, a implementao e testes a serem desenvolvidos em vrias iteraes. Nessas duas ltimas variaes, desejvel que os requisitos estejam bem consolidados. So vantagens deste modelo: o So necessrios menos tempo e custo para a entrega da primeira verso; o Como os incrementos tem tamanho reduzido, os riscos relacionados ao desenvolvimento do incremento tornam-se reduzidos; o Devido ao curto tempo para desenvolvimento de um incremento, as solicitaes de mudanas nos requisitos podem ser minimizadas. A desvantagem desse modelo que se os requisitos no estiverem bem definidos, alguns incrementos podero ser amplamente modificados. Modelo Espiral No modelo de Ciclo de Vida Espiral, o software produzido a partir da unio do modelo Cascata e a Prototipagem. O processo dividido em quadrantes que a cada ciclo representa uma fase do processo. O primeiro quadrante representa a especificao dos objetivos para a fase; no segundo quadrante os riscos so identificados e as atividades so levantadas para trat-los; no terceiro quadrante acontece o desenvolvimento e validao do produto; e no quarto quadrante ocorre uma interao com o usurio para verificar se a verso do software atende as

necessidades, para assim iniciar um novo ciclo, ou seja, seguir para a segunda verso do software, conforme ilustrado na Figura 5.

Figura 5 Modelo de Ciclo de Vida Espiral.

3.Melhoria de Processos de Software Qualquer processo, seja ele de tecnologia ou no, criado com objetivo principal de entregar um resultado. Naturalmente a composio desse resultado pode e provavelmente ir variar com o tempo, dada ao dinamismo dos negcios. Em se tratando de processos de software, a busca por melhores prticas constante devido aos resultados insatisfatrios alcanados pela indstria de desenvolvimento de sistemas, como descreve Ambler (2002):
The current software development situation is less than ideal. Systems often dont meet the needs of our customers and we must develop them again and again and again. Our customers are angry because of these problems and are neither willing to trust us nor work with us because theyve been burned too many times in the past.

Um dos principais pontos relacionados aos problemas quanto ao processo de software recai sobre a cultura de que o desenvolvimento em si nunca o problema. comum que a dificuldade em entregar de software de qualidade seja atribuda a aspectos como gesto, demanda excessiva por documentao, o entendimento do processo de negcio pelo cliente, infraestrutura, entre outros. 3.1. Situao atual dos Processos de Software Os modelos de referncia para processos de software consistem em arqutipos os quais servem como tendncia para estruturao dos processos de software nas organizaes. Conforme descrito na seo 2, esses modelos de referncia so baseados em modelos de ciclo de vida, que so a base do pensamento de uma instncia de processo que referencie um dado modelo de ciclo de vida.

3.1.1. Modelos Iterativos e Incrementais Os modelos iterativos e incrementais se caracterizam por disponibilizar releases do software contendo algumas funcionalidades, de forma gradativa ao longo do projeto. Dessa prerrogativa, pode-se afirmar que o modelo do RUP (Rational Unified Process) emergiu como o padro mais popular pela indstria de desenvolvimento de software (Larman et al., 2001). Combinando boas prticas reconhecidas pelo mercado, utiliza o modelo de ciclo de vida iterativo e incremental como alicerce para composio do seu processo. Sua premissa que os projetos de software devem evoluir entre quatro fases bem definidas (Iniciao, Elaborao, Construo e Transio), as quais so transpassadas atravs de ciclos de iterao, os quais executam em janelas de tempo controladas, as atividades previstas no modelo (Modelagem de Negcios, Requisitos, Anlise e Design, Implementao, Testes, Implantao, Gerencia de Configurao e Mudana, Gerenciamento de Projeto e Ambiente), conforme ilustra a Figura 6.

Figura 6 Viso geral do RUP (Rational Unified Process).

Apesar de esse modelo ser amplamente aceito e utilizado pela indstria de software, so comuns os problemas daqueles que se utilizam essa abordagem. Larman et al. (2001) afirmam que existem padres para as dificuldades encontradas com a utilizao do RUP como modelo de referncia. O referido trabalho apresenta sete passos a serem seguidos para falhar na utilizao do RUP como processo de software: 1. Imposio do pensamento em Cascata fundamental que haja a compreenso de que o RUP prope um modelo iterativo e incremental e no um modelo cascata. Um processo de software que se apresente como utilizador do RUP no pode se caracterizar por: a) tentar definir e estabilizar a maior parte dos requisitos; b) detalhar o design baseado nos requisitos; c) implementar baseado no design completo; d) integrar, testar e implantar. Desse cenrio, Larman et al. (2001) apontam que o entendimento mais equivocado desse contexto caracterizado pela compreenso errada de que a maior parte dos

requisitos precisa ser definido na primeira fase do projeto. Como a Figura 6 apresenta, existe um esforo maior na fase inicial, porm esse no deve ser integral. Uma vez que as iteraes ocorrero, novos entendimentos dos requisitos bem como do negcio podero surgir.
Consequently, in the RUP, development proceeds instead via a series of iterations, each of which is timeboxed to a fixed duration (such as exactly four weeks), and which ends in a stable internal release of a subset of the final system. Timeboxing is a key concept in iterative development: it means to fix the end date of the iteration, and not normally allow date slippage. If all the objectives cant be met, requirements are removed from the iteration, rather than expanding the iteration duration. Within an iteration, there is something like a miniwaterfall. A small set of requirements is chosen and more fully analyzed (perhaps prioritized by high risk or business value). Larman et al. (2001).

2. Utilizar o RUP como um processo pesado e preditivo Como descreve Larman et al. (2001), o RUP foi pensado e encorajado para ser aplicado como leve, gil e adaptativo. Deve ser utilizado o mnimo de atividades e artefatos possvel, sendo apenas as que realmente agregam valor. Na medida em que o projeto evolua, caso algum artefato ou atividade no estiver agregando valor, deve ser descartado; bem como se houver alguma incompletude no processo, deve ser acrescentada a atividade ou artefato complementar no contexto instanciado para atender a alguma deficincia do projeto. Outro ponto abordado que no precisa haver o planejamento detalhado para todas as iteraes. Elabora-se o cenrio geral, com previses de data para incio e fim de cada iterao, contudo, seu detalhamento deve ser gradativo. Como um processo incremental, a especificao da iterao seguinte deve ser feita aps a concluso da iterao anterior. 3. Evitar o pensamento estritamente Orientado a Objetos O RUP direcionado ao desenvolvimento de sistemas orientados a objetos, ainda que suas prticas possam ser aplicadas a outras tecnologias (Larman et al., 2001). Contudo, fundamental que alm da orientao a objetos, seja prevista a adoo de design patterns, os quais ampliam a robustez e estabilidade do design da soluo. 4. Subvalorizar o desenvolvimento adaptativo e iterativo Existem diversas formas de ignorar as implicaes do desenvolvimento iterativo (Larman et al., 2001): a) adotar atitudes rgidas e preditivas, comumente remetidas a modelos em cascata; b) perverter a prtica do desenvolvimento iterativo; c) no educar os stakeholders sobre as implicaes do desenvolvimento iterativo; d) modelar demasiadamente e criar artefatos de baixo valor agregado. 5. Evitar mentores que no entendam efetivamente sobre o cerne do desenvolvimento iterativo; 6. Adotar o RUP localmente no projeto, porm, ignorar a necessidade de apresenta-lo a toda a organizao; 7. Obter conselhos de fontes mal informadas

 comum se obter informaes de ditos especialistas em RUP que profiram afirmaes como: No RUP importante obter 100% dos requisitos antes de iniciar o design., Uma boa e tpica durao de iterao deve ter por volta de seis meses. (Larman et al. 2001). 3.1.2. Modelos geis Em se tratando de modelos geis, sua motivao se deu pela situao aqum do ideal da indstria de desenvolvimento de software, conforme j relatado neste trabalho. Aspectos como burocratizao de processos, falha na entrega e baixa satisfao dos stakeholders, motivaram a reflexo sobre se os modelos previstos realmente atendiam aos melhores interesses das partes. A partir do Manifesto gil que consiste em uma declarao de princpios que fundamentam o desenvolvimento gil de software, assinada por profissionais de renome do campo da Engenharia de Software valores como a relao entre os indivduos, o funcionamento do software acima da documentao, colaborao dos clientes no projeto, capacidade de resposta s mudanas, entre outros fatores, passaram a sobrepor a engenharia prescritiva dos modelos de processos existentes at ento, conforme descreve Ambler (2002):
Prescriptive software processes such as the Unified Process, the OPEN Process, and the Object-Oriented Software Process all have their place. It is just that they may no be as appropriate as their supporters consider them to be. The problem with these approaches is that they typically focus on prescriptive procedures and the artifacts that should be created, approaches that are often implemented by organizations who consider people to be plug and play compatible. In others words, their belief is that, with the right process in place and with the necessary number of artifacts, you can swap people in and out of project with relative ease.

Nesse sentido, modelos geis de processo de software preveem que os aspectos mais importantes a serem considerados so as pessoas e como elas trabalham em conjunto, haja vista que se no h a compreenso correta dos requisitos, as melhores ferramentas e processos no iro servir para resolver os problemas (Ambler, 2002). 3.1.3.Reuso de Processos de Software Outra tendncia em processos de software consiste no Reuso de Processos. Em iniciativas de definio e gesto de processos de software, comum que sejam considerados fatores como: necessidades e caractersticas da organizao ou projeto, tcnicas e mtodos, conformidade com modelos de referncia, entre outros. (Barreto et al. 2007). A premissa para o reuso de processos de software que sua elaborao se d atravs de componentes de processos mais genricos sejam elaborados em nvel organizacional, podendo assim serem instanciados em unidades menores. Analogamente, a ideia pode ser comparada ao conceito de Herana no desenvolvimento Orientado a Objetos. Essa viso de que processos podem ser divididos em componentes

tambm referencia aos conceitos atuais de Reuso de Software, conforme descreve Barreto et al. 2007.
Espera-se aumentar a produtividade da atividade (diminuio do esforo necessrio para realiza-la); aumentar a qualidade e adequao dos processos gerados (reutilizao do conhecimento de especialistas e de dados sobre utilizao); facilitar a anlise de estabilidade e desempenho dos subprocessos; representar variabilidades e semelhanas entre processos para potencializar a reutilizao, entre outros. So utilizadas algumas tcnicas comumente aplicadas na reutilizao de produtos de software tradicional. Acredita-se que essas tcnicas possam ser adaptadas para o uso no apenas no desenvolvimento de software, mas tambm na definio de processos.

O reuso de processos de software utilizando como parmetro os aspectos relacionados ao reuso de software tambm abordado por Groenewegen et Engels (1997):
In reusing arbitrary software, not only data its data, but also its algorithms, its communication protocols and its functionality are relevant candidates for being reused. This is similar to reuse of software process fragments, and after all, this is not surprising, as software processes are software too. Here however we want to stress the similarity even further, in making it more symmetric: software is as process too. The basic argument for this is, software specialties the process consisting of the numerous steps to be taken by a suitable processor. In addition, together with system software such as a compiler or interpreter and an operating system, that process is also enactable or even enacting.

Diante dos modelos apresentados, ficam evidentes as diversas abordagens de processos de software disponveis para serem adotadas como padro. 3.2. Modelos de Melhoria de Processos de Software Ainda que os modelos de processos de software previamente abordados apresentem diversas caractersticas que motivem a sua adoo, assim como o apelo pela eficincia e possibilidade de customizao dos processos, esses arqutipos invariavelmente apresentam alguns problemas para os envolvidos com a operao de desenvolvimento: O processo de desenvolvimento em si nunca o problema; A responsabilidade pelo fracasso dos projetos exclusivamente da gesto; Demanda excessiva por documentao; Deficincia no entendimento do processo de negcio do cliente; Utilizao de tecnologia inadequada.

Entretanto, Montoni et al. (2007) aborda que a primeira ao a ser adotada por uma organizao de software que busque a melhoria dos seus processos definir um modelo de ciclo de vida adequado, com base nos objetivos do negcio e suas caractersticas. Iniciativas de definio, implantao e melhoria de processos de software devem primariamente ser vistas como um projeto estratgico para a organizao.

A implementao de forma catica uma das causas mais comuns do insucesso nas iniciativas de melhoria de processos de software. Portanto, fundamental que os projetos de melhoria sejam tratados como verdadeiros projetos nas organizaes. No entanto, projetos de melhoria possuem caractersticas e particularidades que devem ser levadas em considerao no planejamento do projeto. Atravs da caracterizao do contexto encontrado na organizao e da seleo das estratgias mais adequadas a este contexto, o planejamento do projeto pode ser realizado levando em considerao fatores humanos e demais caractersticas de importncia para a viabilidade do sucesso do projeto. (Montoni et al. 2007).

Considerando os fatores supracitados, alguns modelos e abordagens de processos de software consideram no s a estrutura de desenvolvimento, mas contemplam tambm toda a arquitetura de execuo, buscando como objetivo principal a melhoria contnua e satisfao a critrios de qualidade, maturidade e capacidade dos processos de software. 3.2.1.ISO 15054: O metamodelo para melhoria de processo de software A norma ISO 15504 consiste em um framework flexvel para construo de modelos de avaliao (e melhoria) de processos para indstria de software. Os modelos de capacidade, destacados por abordar no s os aspectos do contexto de processo, mas tambm por considerarem variveis de melhoria contnua e maturidade, foram estabelecidos originalmente a partir do CMM (Capability Maturity Model). Criado na dcada de 90 para atender a indstria de software, o CMM serviu como base para concepo de diversos outros modelos de capacidade. Essa propagao de modelos de capacidade levou a ISO (International Standardization Organization) a criar a norma ISO/IEC 15504, a qual especifica um framework de modelos para avaliao de processos para a melhoria de processos (Tsukumo et al., 2006).

Figura 7 Fluxo de definio e melhoria de processos conforme a noma ISSO 15504.

Conforme apresentado por Vasconcelos (2012), alm de prever dois contextos de abordagem (Melhoria Contnua, a qual busca a identificao de oportunidades de melhoria; Determinao de Capacidade, a qual identifica riscos com o fornecedor) a estrutura da norma ISO/IEC 15504 est dividida em cinco partes: Parte 1: Conceitos e vocabulrio; Parte 2: Executando uma Avaliao; o Requisitos para uma avaliao compatvel com a ISO/IEC 15504; Parte 3: Guia para execuo de uma avaliao; o Exemplo de um processo de avaliao; Parte 4: Guia para o uso de resultados de uma avaliao; Parte 5: Um exemplo de modelo de avaliao de processo; o Modelo de capacidade para a Engenharia de Software com base nos processos da ISO/IEC 12207. Assim a norma ISO/IEC 15504 serve como metamodelo para a concepo de modelos de avaliao e melhoria de processos de software. Atravs do instanciamento dessa norma, possvel especializar uma nova abordagem a qual seja customizada ao contexto e objetivos estabelecidos para o cenrio tratado. 3.2.2. CMMI (Capability Maturity Model Integrated) O CMMI (Capability Maturity Model Integration) um modelo de processo que contm prticas (Genricas ou Especficas) necessrias maturidade em disciplinas especficas ao processo de desenvolvimento de software. Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI uma evoluo do CMM e estabelece um modelo integrado para o processo de melhoria corporativo, associando diferentes abordagens e disciplinas. Esse modelo prope uma estrutura a qual considera duas abordagens de representaes: Contnua: Os processos so agrupados por Categoria e os avaliados sobre a perspectiva de Nveis de Capacidade, buscando avaliar o nvel de reas de processo individuais; Estagiada: Os processos so agrupados por Nvel e avaliados sobre a perspectiva de Nveis de Maturidade da organizao como um todo.

Figura 8 Comparao das representaes do CMMI (Vasconcelos, 2012).

Ainda que oferea duas propostas de representao, o modelo adotado amplamente pelo mercado o da representao Estagiada. O CMMI prev que para posicionamento dentro dos seus nveis de maturidade (1 Inicial; 2 Gerenciado; 3 Definido; 4 Qualitativamente Gerenciado e 5 Otimizao), processos genricos e especficos precisam ser executados conforme padres de produtividade e qualidade, conforme ilustrado na Figura 9.

Figura 9 Estrutura do CMMI (Capability Maturity Model Integrated).

Ainda que haja a clara tendncia pela adoo de modelos de capacidade, haja vista a demanda do mercado contratante de servios de software por certificaes como o CMMI, os dados de adoo desse modelo ainda so aqum do ideal. O Software Engineering Institute, ligado a Carnegie Mellon University mantm uma base1 de dados de avaliao do nvel de maturidade do CMMI em organizaes de tecnologia em todo o mundo. At o ano de 2002, os EUA tinham realizado 1,5 mil avaliaes de CMMI, a ndia feito 153, o Reino Unido 103 e o Brasil apenas 15. Entre abril de 2002 e junho de 2006 foram conduzidas 1581 avaliaes em 1377 organizaes. Abaixo segue o resultado obtido pelas empresas na avaliao (resultados encaminhados para o SEI at 30 de junho de 2006): 18,2%: nvel 5 (Optimizing); 4,4%: nvel 4 (Quantitatively Managed); 33,8%: nvel 3 (Defined); 33,3%: nvel 2 (Managed); 1,9%: nvel 1 (Initial); 8,4%: sem qualificao (Not Given).

CMMI Published Appraisal Results: http://sas.sei.cmu.edu/pars/pars.aspx

Especialmente no Brasil, os dados revelam que a adoo ainda muito baixa, ainda que o Governo Brasileiro tenha institudo que certificaes como o CMMI garantem pontuao extra nos processos licitatrios. Nesse sentido motivou-se o desenvolvimento de um modelo de capacidade brasileiro, o qual garantisse as premissas previstas nesse tipo de abordagem, mas que contemplasse um investimento mais acessvel s organizaes brasileiras. 3.2.3.MPS.BR (Melhoria de Processos de Software Brasileiro) O MPS.BR (Melhoria de Processos do Software Brasileiro), mantido pela Softex (Associao para Promoo da Excelncia do Software Brasileiro), em suma caracteriza-se como sendo uma verso nacional do CMMI. Conta tambm com algumas especificidades, haja vista que considerou aspectos relacionados a norma ISO 12207, a qual define um modelo de ciclo de vida para produtos de software. A particularidade mais significativa, porm, reside sobre os nveis de maturidade (que ao contrrio do CMMI so tratados por letras que vo de A a G) e os processos de capacidades previstos em cada nvel, conforme ilustra a Figura 10.

Figura 10 Estrutura do modelo do MPS.BR (Melhoria de Processos de Software Brasileiro).

3.2.4. Melhoria de Processos de Software sob o ponto de vista dos Processos de Negcios Em Arajo et al. (2004), a analisada a relao entre a definio dos processos de software baseada na perspectiva dos processos de negcio. Refora-se a demanda de entendimento do contexto organizacional como prerrogativa para uma gesto mais eficiente dos processos de software:
Assim como em qualquer rea de negcio, a rea de desenvolvimento de sistemas est interessada em conhecer melhor seu negcio para poder gerenci-lo de forma apropriada. Assim, os conceitos de modelagem de negcios aparecem invariavelmente nas iniciativas de definio de processos de software e, mais notadamente em sua posterior gesto e melhoria contnua.

A pesquisa supracitada analisou os aspectos, atividades e infraestrutura necessria para mapear uma iniciativa de melhoria de processo de software. Na viso de Arajo et al. (2002), a melhoria dos processos de software baseada na viso dos processos de negcio seguem a seguinte estrutura: Definio do escopo da iniciativa de implantao de processos de software: Essa etapa compreende no entendimento geral do Processo Padro de Desenvolvimento e Manuteno de Software, objetivando a identificao do cenrio atual de processos e priorizando-os com base na estratgia adotada para a realizao das atividades relacionadas implantao ou melhoria dos processos identificados; Compreenso do estado atual do processo/organizao/avaliao do modelo obtido: Atravs do uso de questionrios, checklists e entrevistas, realiza-se um levantamento para entendimento do modelo de negcio atual, traando um paralelo quanto condio atual do processo de software. A avaliao realizada em trs fases: o o o Infraestrutura para Definio de Processos, realizada atravs da definio do modelo de gesto para Desenvolvimento e Manuteno de Software; Ciclos de Definio de Processos, atravs dos quais seriam definidas as Polticas de cada processo estabelecido; Definio de Procedimentos para Manuteno e Melhoria Contnua dos Processos, atravs da definio e implantao do processo de manuteno do modelo utilizado e das metodologias definidas.

Discusso e gerao de idias: Compreende a estrutura de comits com as reas de processo para definio da agenda de trabalho, identificando atravs de anlise de S.W.O.T. (Foras, Fraquezas, Oportunidades e Ameaas), as caractersticas de cada unidade de processo; Definio e projeto dos processos desejados: Baseado no levantamento prvio concludo o escopo dos processos que sero tratados.
Haja vista que a iniciativa como um todo no objetivava a certificao, os processos puderam ser projetados de forma a atender o mais rapidamente possvel as principais dificuldades

e obstculos reportados pelos participantes nas sucessivas discusses do padro, bem como adapt-los ao seu nvel de conhecimento e especializao em cada uma das reas. Arajo et. al (2004).

Ferramental associado: Definio de quais ferramentas ir auxiliar na execuo da iniciativa de melhoria de processo de software Processo de Software Padro Modelo de Negcios de Software: Ao passo que as etapas prvias compreenderam a anlise da situao atual dos processos de software e seu paralelo frente a um modelo de referncia, estabelecida uma nova verso do Processo Padro de Desenvolvimento de Software, contemplando as melhorias viabilizadas pela iniciativa.

Conforme descrito por Arajo et al. (2002), o entendimento da situao atual do processo de software no suficiente para viabilizao de melhorias. fundamental que sejam adotados modelos de referncia que enderecem e norteiem o novo cenrio a ser adotado pela organizao. Nesse sentido, vrios modelos de processos de software podem ser adotados. 3.2.5. Melhoria de Processos de Software baseado em Componentes A Engenharia de Software baseada em componentes um ramo de Engenharia de Software, cujo objetivo se d na decomposio em componentes dos sistemas funcionais e lgicos, com interfaces bem definidas, usadas para comunicao entre os prprios componentes. A principal motivao para o uso de componentes a potencializao do reuso de software e o consequente ganho de produtividade proporcionado por esse modelo de desenvolvimento. Em Tsukumo et al. (2006), prope-se uma estratgia para melhoria de processos de software em organizaes que utilizem a estratgia de desenvolvimento baseado em componentes. Como essa arquitetura de desenvolvimento tem como ponto primrio a utilizao de elementos de software previamente concebidos, a particularidade desse processo precisa ser contemplada no ciclo de desenvolvimento, conforme ilustrado na Figura 11.

Figura 11 Arquitetura de processo de desenvolvimento baseado em componentes (Tsukumo et al. 2006).

Com base na arquitetura proposta, so promovidas trs avaliaes chave no processo de desenvolvimento baseado em componentes. Primeiramente promovida uma avaliao do processo de desenvolvimento de componentes, cujos objetos iro compor o repositrio de componentes da fbrica de software. Em seguida promovida uma avaliao do processo de Gerncia do Repositrio, com objetivo de avaliar os critrios de manutenabilidade dessa base. Por ltimo, realizada a avaliao do processo de desenvolvimento de software que utilizam os componentes do repositrio. A abordagem apresentada por Tsukumo et al. (2006) converge com a tendncia atual do mercado para o Reuso de Software. Esse conceito tem sido aplicado no s com o objetivo de reduzir custos com a produo de sistemas, mas principalmente, aumentar a produtividade, diminuir o retrabalho e reduzir o tempo de produo, o que consequentemente proporcionar menores custos de desenvolvimento.
A estratgia para melhoria de processo de desenvolvimento baseada em componentes orientada pela definio de especializaes dos modelos mais utilizados para engenharia de software em geral. Esta estratgia foca mais no uso destes modelos do que na definio de um novo modelo. Esta estratgia pode ser considerada tambm como uma estratgia baseada em componentes, medida que ela preconiza a definio de novos componentes (no caso novas reas de processo) e a especializao de componentes mais genricos (no caso as reas de processo dos modelos para engenharia de software). Tsukumo et al. (2006).

4. Concluso A adoo de modelos, mtodos e abordagens que possam melhorar os processos de software, quando aplicadas, apresentam resultados variados a depender do contexto em que se encontram cada organizao ou projeto. Entretanto, possvel observar algumas condies e premissas das quais comungam a maioria dos modelos apresentados, tais como a de que a melhoria do processo de software uma ao continua, ou ainda, a de que um bom processo de software contribui bastante para o desenvolvimento de um bom produto, embora no haja garantia disso. Ao mesmo tempo em que desejvel a implantao de um processo de software visando melhoria de qualidade, aumento de competitividade, reduo de custos, enfim, a satisfao do cliente final, preciso manter alinhadas as caractersticas da empresa s do modelo de processo implantado, sob o risco da perda de produtividade e resistncias na equipe tcnica, comprometendo assim os ganhos retromencionados. Por mais que se desenvolvam ferramentas para o auxlio ao desenvolvimento de software, e sejam estudadas formas de controlar os processos, sempre haver limitaes em funo dos aspectos humanos e da flexibilidade existentes nos processos de software. Nesta perspectiva, j possvel observar alguns mtodos, a exemplo dos modelos geis cujos princpios se baseiam mais nas pessoas e em como elas trabalham, privilegiando a relao entre os indivduos, a operao do software acima da documentao, a colaborao do cliente durante o projeto e a capacidade de resposta s mudanas.

Nota-se ainda que a exigncia de certificaes nos modelos de capacidade e maturidade em licitaes pblicas, a exemplo do CMMI ou MPS.BR, distorceram o principal objetivo dos mesmos que a busca constante pela melhoria do processo de software, tornando-se apenas uma luta pela obteno do certificado, no importando os aspectos tcnicos e econmicos abordados neste artigo. Por fim, a melhoria do processo de software tem proporcionado resultados positivos para muitas empresas que se comprometem estratgica e operacionalmente com sua implantao, ao tempo em que uma rea instigante, que demanda por muitas respostas, e por perguntas que ainda no foram sequer elaboradas. 5.Referncias AMBLER, S. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. Wiley Computer Publishing, 2002. ARAJO, R., CAPELLI, C., GOMES JUNIOR, A., PEREIRA, M., IENDRIKE, H. S., IELPO, D., TOVAR, J. A. A definio de processos de software sob o ponto de vista da Gesto de Processos de Negcio. VI Simpsio Internacional de Melhoria de Processos de Software. So Paulo, Brasil, 2004. BARRETO, A., MURTA, L., ROCHA, A. R. Uma abordagem de definio de processos de software baseada em Reutilizao. Programa de Engenharia de Sistemas e Computao, Universidade Federal do Rio de Janeiro. COPPE/UFRJ), 2007. BRASIL, M. M. A., CORTS, M. I. Definio de Processo de Software atravs da Composio de Atributos de Casos Similares. Departamento de Estatstica e Computao, Universidade Federal do Cear (UFCE), 2008. GROENEWEGEN, L., ENGELS, G. Reuse of software processes fragments is reuse of software too. IEEE Computer Society Press, Los Alamitos, CA, USA, 1997. IEEE, Institute of Electrical and Electronics Engineers. Software Engineering Body of Knowledge. 3rd Version, 2004. LARMAN, C., KRUCHTEN, P., BITTNER, K. How to fail with the Rational Unified Process: Seven steps to pain and suffering. Valtech Technologies and Rational Software, 2001. MOITRA, D. Indias Software Industry: The Software Superpower. IEEE Software, [S.1.], v.18, n.1, p. 77-80, Jan. 2001. MONTONI, M., CERDEIRAL, C., ZANETTI, D., ROCHA, A. R. Uma abordagem para conduo de iniciativas de melhoria de processos de software. Programa de Engenharia de Sistemas e Computao, Universidade Federal do Rio de Janeiro. COPPE/UFRJ, 2007. PFLEEGER, S. L. Software Engineering: Theory and Practice. 2nd Edition, Prentice-Hall, Inc., 2001. PRESSMAN, R. S. Engenharia de Software. 5 Edio, Makron Books, 2002.

REIS, C. A. L. Uma abordagem flexvel para evoluo de processos de software evolutivos. Tese de Doutorado, Programa de Ps-graduao em Cincia da Computao. Instituto de Informtica, Universidade Federal do Rio Grande do Sul (UFRS), 2003. ROCHA, A. R., MONTONI, M., SANTOS, G., OLIVEIRA, K., NATALI, A. C., MIAN, P., CONTE, T., MAFRA, S., BARRETO, A., ALBUQUERQUE, A., FIGUEIREDO, S., SOARES, A., BIANCHI, F., CABRAL, R., DIAS, A. Fatores de sucesso e dificuldades na implementao de processos de software utilizando o MR-MPS e o CMMI. Workshop Implementadores MPS.BR, 2005, Braslia. Anais do Workshop Implementadores MPS.BR 2005, 2005. SOMMERVILLE, I. Software Engineering. 6th Edition, Addison-Wesley, 2000. TSUKUMO, A. N., SANTOS, R. V. M., MARINHO, W., SILVA, L. P., SALVIANO, C. F. Uma estratgia para melhoria de processo de desenvolvimento de software baseado em componentes. V Simpsio Brasileiro de Qualidade de Software, SBQS, 2006. VASCONCELOS, A. M. L. Qualidade de Software. Centro de Informtica, Universidade Federal de Pernambuco, 2012. WEBER, K., DE LUCA, J. C., ROCHA, A. R. Qualidade e Produtividade em Software. 2 Ed. So Paulo, Makron Books, 1995.