A Melhoria de Processo de Software Baseada no CMM: Um Enfoque para Empresas de Pequeno Porte no BrasH Gizelle S. Lemos . Angelita M~ Segovia . Alfredo Co2enci Neto * Dr. Penido Stahlberg Filho * Phd Fredy Valente * Dr. Edson W~ Cazarini . * S&V Consultoria e Tecnologia Caixa Postal 781 CEP 13560-320 So Carlos -SP - Brasil {neto, penido, fredy}@svconsultoria.com.br . Universidade de So Paulo - So Carlos Av. Dr. Carlos Botelho So Carlos -SP - Brasil angelita@ svconsultoria.corn.br casarini @ Sc.usp.br * Universidade Federal de So Carlos Rodovia Washington Luiz, 243 So Carlos - SP- Brasil izelle@ dc.ufscar.com.br Resumo medida qua aumenta a possibil"zdade dos mesmas As mudanVas no plano politico ve^m senao participarem do mercado mundiaL, onde sao exigidaS a sistemaricamente acompanhadas pelas dz.retrizes do capacitaVa-oe maturz.dadedos processos de soare Gonerno Brasileiro. Programas de qualz.dade, incLuz.ndoa cerri!icaVa-odos processos e produros de soare, hoje 1. Introdu&o caracterz`~adoscoma compete^nciaspara competz`tz.vz.dade, Aos valores econ6rnicos classicos - capital, trabalho e rornar-se-ao z"ndz.spensdveispara a sobrevive^ncia em terra, uma nova dimens&o foi adicionada - a do tango prazo no Mercado z"nternacionaL.Pesquisas conhecimento. Na chamada "sociedade da informsAo", o constataram uma forte reLaVa-oentre quaL-zdade do quadro mundial passa por fortes e aceleradas soare e seu processo de desenvolvz.mento. transformaJes em suas estruturaspoliticas, econ6micas, sociais e culturais, e verdadeiras revoluJes nas Na quesrdo do avaliaVao e melhor"zado processo, o tecnologias de informa&o e comunicaAo~ CMM (Capabili Maturity Model) quaLz.fica a Considerando qua o setor de software serzi, Segundo capacz"taVaodos processos de soare, com o objerivo de pesquisas internacionais, responval pelos maiores avail.or o estodo atuaL e dejl~niraV6es para a melhorz.a indices de crescimento na economia global nos pr6ximos evoLutz.va desses processoS~ Ele tambe~m on-enta no anos, o Brasil es participando do movimento Que identiflcaVa-odos pro z.cas-chaverequeridas para aumento consiste em uma estrat6gia para o aumento da da maturidade dos processos. Embora 36% das empresas competitividadebaseada em qualidade,custos e efici8ncia. brasilez.ras sejam Te pequeno Forte, nenhuma recebeu a Com taxa mia annal de crescimento da receita de certzcaVa-o CMM.Sua apLica50, porranro, e~ jusrz.fzcoda`a 19% sobre os valores correntes, o setor de software QuaTIC 2001 / 27 brasileiro apresentouum melhor desempenho na decada de rumo diferente, uma vez Que as aplicaV6es de baixo 90, quando comparado ao hardware, que cresceu 6% ao custo puderamser largarnenteimplementadas. Assim, ano no mesmo perfodo. Trata-se de urn mercado de a impocia da produtividade no desenvolvimento US$2,5 bilh6es proveruentes da comercializaAo de de software aumentousignificativamente.Poi no final software das empresas desenvolvedoras nacionais, dessa dcada que se reconheceu a imponcia da acrescido de US$1 2 bilh6es estimado para a irnporta5o qualidade do software. de software, resultanteda remessa em direitos autorais. .Era da Qualidade- anos 90: Com a tecnologia do Neste contexto, o Brasil Esta procurando alcanar estado da arte, espera-Se slender demanda dos padr6es internacionais efetivos em qualidade e clientes com a exig8ncia da alta qualidade. Essa produtividade no setor de software. Grandes investimentos exig8ncia intensificada pela crescente dependncia tern ocorrido na area com fomento da Sociedade Brasileira da sociedade pelo software. para Promo5o da Export&Vo de Software - SOFTEX A -respeito da qualidade de software, ha muitos 6rgilo gonernamental que tern como um dos objetivos conceitos para deflni-la, sob diferentes pontos de vista transformar o Brasil em um centro de excel8ncia na apresentadosna literatura.O Quadro 1 a seguir, &presents produo e export&Aode software. algurnasdestas definiJes: 2. Problemas de empresas que desenvolvem software Um produto de software apresenta [16] Segundo [18], em muitas organiza6es, os projetos qualidade dependendo do grau de satisfaAo s8o entregues muito aI6m do tempo planejado e com o das necessidades dos clientes sob todos os dobro do custo estimado. Os beneficios dos metodos e ferramentas nAo podem ser gleanados por meio da E o grau em que o software possui uma [06] indisciplina ou por meio de um projeto ca6tico. Em alguns combinaAo desejada de atributos. casos, a organiza95o nAo possui infra-estrutura e suporte E O grau em que Os atributosdo software DoD- necessdrios para auxiliarem nos projetos. o capazes de desempenhar sun finalidade Std2l68 Na auncia de um processo organizado de especificada. desenvolvimento de software, os resultados dependem da A percep5o da qualidade de software 6 [19] exist8ncia de algumas avaliaJes individuais para projetos vista principalmenteem termos de tempo em pr6ximos. De acordo com [181, a melhoria contfnua,pode que um sistema de software opera ocorrer somente atrav de esforos focados e sustentados corretamente. pela construAo de uma infra-estrutura de engenharia de E a conformidade aos requisitos [14] software e prticas de gerenciamento. estabelecidos, aos padr6es de desennolvimento documentados e iis 3. QuaRdadeapRcada ao software caracteristicasimplicitas que $50 aguardadas pelos desennolvedoresde software. Quadro 1 Kan em [9], apresenta uma perspectina hist6rica a Defini(;:6essobre Qualidade de Software respeito da Engenhariade Software.a qual 6 apresentadaa seguir: *Era Funcional - anos 60: Aprendeu-Se a usar a Com o objetivo de dar continuidade ao estudo da tecnologia de inform&&opara suprir as necessidades quaZidadedo software. o assunto 6 dividido em duas ens: institucionais e comar a integrar o software nas qualidade do produto e qualidadedo processo de software. opera6es dias das organizaJes. Estas areass8o apresentadasa seguir. *Era do M6todo - anos 70: Devido aos atrasos nos pianos e ultrapassagem nos custos, a major preocupao Nessa lase foi o estabelecimento de planejamento e controle de projetos. Fol quando os modelos de ciclo-de-vida do software foram introduzidose analisados. *Era do Custo - anos 80: O custo do hardware comeou a cair e a tecnologia de informs8o tornou-Se acessivel pessoas, nAo mais somente as organizaBes. A competi80 das inddstriastomou um 28 / QuaTlC2001 3.1. QuaRdadedo produto .de software 4.1. Capability maturity model (CMM) - SEI/CMU 0 SEI (Soare Engineering Institute) sediado na De acordo com Endo [02], nos l:iZtimos60 anos, CMU (Carnegie Mellon Um`"versit)l),em Pittsburg, todo esforo esteve concentrado em se obter controle da Pennsylvania - Usa, 6 um centro de pesquisa que fol qualidade do produto final, para qua um produto criado em 1984 pelo Departamentode Defesa dos Estados defeituoso nAo chegasse ils mOs do cliente. Trabalhos Unidos (DoD - Department of Defense) e e patrocinado realizados por McCall, apresentados na norma ISO/IEC pelo OUSD CA&T) (Oce of the Under Secreta of 9126 [081, procuram definir um conjunto de caracteristicas Defense for Acquisition and Technology). As areas de que evidenciam a qualidade do produto final [01]. Essas atuao do SEI 530: capacita30 de ger6ncia de software e caracterfsticas sgo definidas para representer necessidades tecnologia para a engenharia. 0 SEI focaliza tambm a e desejos daqueles Que est5o direta ou indiretamente translAo tecnol6gica, ou seja, o desenvolvimento e ado5o envolvidos com o software, [20]. Pol6m, estudos recentes das meZhoresprticas de engenhariade software. demonstraram que a import8ncia dada ao processo de software 6 uma forrna de garantir a construo de um 4.1.1 Estmtma do CMM produto de melhor qualidade. De acordo com Humprey {052, o CMM promove 32. Qualidade do processo de software nas organizaJes desenvolvedoras de software, um guia de como alcanar o controle em sens processos de De acordo com Paulk[13], o processo de software 6 desenvolvimento e manuteno de software, e um modelo representado pol um conjunto sequencial de atividades, de como envolver uma cultura de engenharia de software e objetivos, transformaJes e eventos que encapsulam prdticas de gerenciamento. 0 CMM fol desenvolvido para estrat6Bias para o cumprimento da evoluV&odo software. oriental organizaJes na sele5o de estrat6gias de melhoria Para Fiorini [03], conhecer Os processos significa de processos pela maturidade atual e identificar areas mais conhecer como os produtos e serviOs s8o planejados, crfticas de qualidade de software- A Figura I a seguir produzidos e entregues ao cliente. ilustra Os Niveis de Maturidade do CMM: Para que um processo de software seja efetivo no cumprimento dos sens objetivos, torna-Se accesso um planejamento detalhado, que revele a realidade do ambiente de desenvolvimento do software. Dene-se considerer aspectos especificos do projeto, Como apresentadopela Figura 1, o CMM classifica como metas e polmcas, equipe de desenvolvimento, as organizaJes em cinco niveis evolutivos de maturidade, cronograma, disponibilidade de recursos humanos, cada nfvel com suas caracteristicas pr6prlas. Estas t6cnicos e financeiros. caracterfsticasestSo apresentadasno Quadro2 a seguir: Al6m desses aspectos, outros tamb6m devem ser relacionados ao processo, como: fluxo de informa5o, Quadro 2 condiJes especificas para delimitar o inicio e o Rm de Visac Geral dOs Niveis de Maturidade dO cMN [13] cada fase, sequenciamento das atividades e pap6is desempenhados pelas pessoas, [22]. A grande import8ncia dada ao processo de software Nfvel CaracteriSt:I`cas pode ser vista como forma de garantir a construAo de um CMM software de melhor qualidade. Espera-se que urn processo (1) O processo de desenvolvimento 6 contro2ado de software propicie segurana frente as Inicial desorganizado e ate ca6tico~ Poucos variaJes que o produto possa softer em relaAo Ils suas processos s2o definidos e especificaq6es iniciais, [19]. padronizadose o sucesso depende de Para isso, um mecanismo gerencial deve garantir esforOs individuals e her6icos dos o cumprimento das responsabilidades e a conduqAo do desenvolvedores. grupo para que se possa desenvolver o sistema de maneira (2) Os processos bdsicos de segura e controlada, [09]. Repetitivo gerenciamento de projeto esdio estabelecidos e permitem acompanhar custo, cronograma e funcionalidade, 6 possivel repetir o sucesso de um 4. Me&oria de processo de software (3) Tanto as atividades d QuaTIC 2001 / 29 Definido ooerenciamentoquanto de engenharia de Engenharia Organizacional do processo de desenvolvimento de e Apoio Defini5o do Processo software eso documentadas, Organizacional padronizadas, e integradas em um Programa de padr&o de desenvolvimento da Treinamento organiza5o. Todos Os projetos Gerenciamento de utilizam uma vetso aprovada e Software Integrado adaptada do processo padr5o de Engenharia de Produto desenvolvimento de software da de Software . ~ CoordenaAo (4) S-ao coletadas medidas detalhadas Intergrupos Gerenciado da qualidade do produtoe processo de desenvolvimento de software. Tanto o (4) Qualidade Gerenciamento produto quanto o processo de do Produto e do Quantitativodos Processos desenvolvimento s5o entendidos e Processo Gerenciamento da Qualidade do Software (5) 0 melhoramento contfnuo do (5) Melhorame Preveno de Defeitos Otimizado processo 6 conseguido atravds de um nto Continuo Gerenciamento de feedback quantitativodos processos e do Processo Mudanas Tecnol6gicas pelo uso pioneiro de id6las e Gerenciamento de 4.1.2 As areas chave de processos (KPA's) 4.1.3 O cIminho para o Nfvel 2 de matnridade do CMM Todos os nfveis do CMM com exce5o do nine! 1, s3o compostos de um certo n6mero de eas-chave de processo A adoi1o do CMM baseia-se em um processo gradual (Key Process Areas ou RPA's), Que descrevem Os de aumento da maturidade do desenvolvimento do objetivos a screw atingidos, assim como as quest6es a software. Essa maturidade pode ser traduzida como a screw enderadas para se alcanarem estes objedvos e probabilidadede entregar sistemas de software dentro dos atingir aquele nfvel. Todas as areas chaves sRo prazos, utilizando Os mesmos recursos planejados e apresentadasa seguir: atendendoaos requisitos e qualidade desejados {21}. O objetivo de alcanar o Nfvel 2 institucionalizarum Quadro 3 processo efetivo de gerenciamentode projetos de software, Vis o GeraJ dos Niveis de aturidade do Que permite as organizaJes repent suas praticas atraves e suas respectivas EPA's [13] de processos implementados para projetos diferentes- Um processo efetivo pode ser caracterizadocomo aquele Que praticado, documentado, treinado, medido e ser capaz de melhorias. As organizaJes com projetos em Nine! 2 tern Cl) Esforo instalado controles de gerenciamento bdsico de software. Individual Compromissos realfsticos de projetos $50 baseados nos (2) Processo de Gerenciamento de resultados observados em projetos previos e nas Gerenciamento Requisito necessidades dos atuais. Um gerente de software rasteiaos de Projetos Planejamento do custos, tempo, funcionalidade e Os problemas s5o Projeto identifxcados. Os requisitos SRO desenvolvidos e sua Supervis&o e intedade conolada. Projetos padr $50 denidos e Acompanhamento do a orgaao assegma Que Os mesmos serAo fxelmente Projeto segdos. Gerenciamento de aprendo a gulf, dehamento das As Subcontratados referentes ao NfveI 2 do C. Garantia da Qua]idade A 1 - Gerenciamento de Requisitos: a proposta do do Software Gerenciamento de Requisitos estalec um Gerenciarnento de entendimentocomum ene o clite e a pe do projeto sobre Os ruisitos alocados ao sowe. Envolve o (3) Processos Foco do Processo estalecimento e manuten30 dos ruisitos de acordo 30 / QuaTfC"2001 com as necessidades do cliente. O cliente pode ser produtos do projeto ao longo do ciclode-vida. Envolve interpretadocomo o grupo de engenharia,marketing,outro identificar os itens de configura5o, controlar intemo da organizaV&oou um cliente externo. Este acordo sistematicamente as alteraJes e mauler a integridado da forma a base para estimar,planejar, executar e localizer as configurago ao longo do ciclo-de-Vida. Utiliza linhas de atividades do projeto de software ao longo do sen ciclo-de- refer8ncia (baseLines) qua servem como um marco no Vida,[13]~ ciclode-vida do software. Os itens Que passam por ulna KPA 2 Planejamento do Projeto do Software: o baseline podem ser alter&dos somente arrays de prop6sito 6 estabelecer pianos para o desempenho e procedimentosformals de controle de mudanas. manuten50 do projeto de software. Envolve o 0 SEI estabeleceu uma proposta Que descreve desenvolvimento de estimativas para o trabalho, lases, atividades e recursos Recessos para tomar estabelecimento de compromissos e de um piano para iniciativas de melhoria de processo com sucesso, [12]. De guiar o projeto. 0 planejamento comea com a declara5o acordo com Fiorini [03], esta proposta6 similar ao ciclo de do trabaJho e outras metas Que definem o projeto meZhoriaPDCA (P/an, Do, Check ana Act - PZanejar, (estabelecidos pelas praticas do Gerenciamento de Fazer, Verificare Agir) e 6 denominadaIDEAL. Requisitos). O processo de planejamento inclui passos para estimar o tamanho do produto de trabalho e recursos 4.2. O modelo IDEAL necessdriOs, identificaVo e avaliao de riscos. A inter&50 atrav6s desses passos deve ser necessdria para 0 modelo IDEAL (/nitiating, Diagnosing, estabelecer o piano do projeto. Esta piano promove a base EsrabiLishz.ng,Acting and Leamz`ng - Inicializao, para o desenvolvimento e gerenciamentodas atividades do Diagn6stico, Estabelecimento, Ao e LiJes Aprendidas) projeto e encaminha as necessidades do cliente de acordo versiio 1.1, descreve uma abordagem de ger6ncia Que com os recursos e capacidades do projeto. ajuda as organizaJes desenvolvedoras de software a KPA 3 - Acompanhamentoe Superviso de Projeto de melhorarem sen processo de desenvolvimento. Este Software; sua fmalidade 6 promover uma vio adequada modelo estabeiece um program&de melhoria continua de do progresso real do projeto, de modo que o processo de software. A Figura 2 a seguir, apresenta sua gerenciamento possa tomar medidas efetivas quando o estrutura; desempenho desvia-se do plano proposto. Envolve acompanhar e revisar Os resultados e as realizaJes do Figure 2; software confrontandocom as estimativas documentadas, Estrutura do ModelO DEAL[13] compromissos e pianos. Envolve taml::)6mo ajuste de pianos com base nos resultados alcanVados. Os mecanismos utilizados podem ser revis6es intemas com a participa8o dos desenvolvedores e gerentes e revis6es formals com Os clientes. Quando ocorrer um desvio entre Os pianos e Os efetivos resultados, deve-Se alterar a forma como o trabalho esta sendo desempenhado ou ajustar os planos. EPA 4 - Gerenciamentode Subcontratos de Software: sua finalidade e selecionar fornecedores qualificados e gerenci Os eficazmente. Esse processo envolve estabeJecer comprornissos, acompanhar e revisar o desempenho e os resultados obtidos. Na selAo e gerenciamentodo fomecedor, s80 necessarios documentos coma cldusula do contrato, requisitos do projeto.,produtos a serem entregues, padr6es e procedimentos a serem seguidos. EPA 5 Garantia de Qualidade de Software: sua proposta6 promovero gerenciamento, com visibilidade do 42.1 Enrntura do modelo IDEAL processo Queest;isendo utilizado e dos produtos que eso sendo construidos. Envolve revis5es e auditories nos De acordo com Endo [02], cada uma das lases 6 produtos de software e Has atividades para assegurar Que realizada anands da execu2o de uma sqrte de atividades esriio em conformidade com Os padr6es e procedimentos descritasa seguir: aplicados. Fase 1-Inicializao: dove-se articulara aplicaV8odos EPA 6 - Gerenciamento da ConfiguraAo de Software: esforos para satisfazer ils necessidades` de neg6cio, sua proposta 6 estabelecer e rnanter a integridade dos asseguraro suporte ao gerenciamento e colocar em prdtica QuaTIC`2001! 31 uma infra-estrutura para gerenciar Os detalhes de * Planejamento das Ades: deve-Se desenvolver um implementsAo do processo de melhoria. piano deta]hado de implementao, o qual inclui . Esamulo para Mudanas; envolve definir as cronograrna, tarefas, prazos, recursos, necessidades de neg6cio que alavancam as responsabilidades, medidas, riscos e estrat6gias. mudanas nas praticas da organizaVAo.Quando as . Fase 4-Ao: envolve implementar o trabalho Que necessidades de mudanas o evidenciadas par foi contextualizado nas lases anteriores. raz6es de neg6cio, e mais facil convencer a . CriaVo de SoluV:Ao:desenvolver a melhor soloko organizaAo como um todo, e existem rnaiores destinada its necessidades previamente identificadas chances de sucesso. na Organizao. . Estabelecimento do Contexto: ap6s estarem . Teste da SoluV:8o:a soluV:2odeve ser testada, pois definidas as raz6es para melhoria, a organizaAo por mais Que ela seja hem elaborada, raramente estabelece o contexto para o trabalho que vai ser funciona como planejado. realizado. Isso significa definir Dude Os esforos . Refinamento da SoluV5o: a soluV:o pode ser se enquadraxBo na estrat6gia de neg6cio modificada para refletir o conhecimento e a organizacional, que metas e objetivos ser8o expert8ncia obtidos. afetados pelas mudanas como isso vat incidir . Implementao da soluV:5o:deve-Se implementer a sobre trabalhos futuros e quais as resultados soluV:Aopar coda organiza&o, utilizando algumas esperados. abordagens, como For exemplo: just-in-time. . Definio de Patrocinador: o patrocinador deve Fase 5-LiBes: nessa lase, coda experiencia adquirida e ajudara mantero comprornissonos momentos de revista para determinar o que foi cuxnprido e como a dificuldades e garantir as recursos essenciais organizaV:Ao pode implementar melhorias mais utilizados durantea melhoria. eficientemente no futuro. Fase 2-Diagn6stico: deve-se desenvolver um . Anlise e Validao: essa atividade responde a uma entendimentodo trabalhopara a melhoria. s6fie de perguntas: de Que maneira o esforo cumpriu . Fornecimento de Infra-Estrutura;envolve definir a proposta esperada?, o quo funcionou melhor?, o um mecanismo para gerenciar as esforOs para que pode ser feito para melhorar a efxci&ncia?. Os detalhes de implementa&o. e tamb6m fornecer dados s5o coletados, analisados, resumidos e um contrato que documente e esclarea as documentados. As necessidades identificadas na lase expectativas, e descreva as atividades e de inicializa98o 8o examinadas para verificar se responsabilidades. foram ou nAo satisfeitas. . CaracterizaAo dos Estados Atual e Desejado: . Proposta de Futures AJes: as recomendaV:6es urna vez identifxcadoo estado atual,pode-se usar baseadas na andlise e Valida5o s8o desenvolvidas e o CMMpara definiro desejado. documentadas. . Desenvolvimento de RecomendaJes: as atinidades da fase de diagn6stico so 5. Empresas bras8eiras desenvolvedoras de desempenhadas pelas pessoas mais experiences ou par especialistas na organiza5o Suas software recomendaJes 850 daseadas nas decis6es tomadaspelos gerenteschefe e patrocinadores. Quest5es relacionadas ao planejarnento estrategico, programas e sisternas da qualidade (de Fase 3-Estabelecimento:deve-se desenvolver um piano produtos e de processos de software), incluindo sua detalhado do trabalho, coma par exemplo: prioridades e certifio, hoje caracterizadas coma compet8ncias restriJes do ambiente operacional. A seguir, uxna qualificadoraspara competiV8ono mercado global, tornar- abordagem Que home esses fatores, aJes especfficas, seo um conjunto de compet8ncias bicas para sua prazos, produtos liberdveis e responsabilidades so sobreviv8nciaa longo prazo no mercado internacional. incorporadasao piano de a80. De acordo com QUEIROZ (2000), do Ministerio . Estabelecimento de Prioridades: envolve da Ci8ncia e Tecnologia, embora as empresas nacionais LimitsiiO de recursos, depend8ncias entre as de software estejam aumentando seas quadros com mAo- atividades recomendadas, interveno de fatores de-obra especializada e busquem corrigir falhas ouvindo extemos e prioridadesglobals da organiza5o. os clientes, a procura par prograrnas de melhoria de . Desenvolvimento de Abordagem: Envolve a qualidade ainda 6 baixa. Por6m, pode-se observer. de compreeno do escopo do trabalho com a acordo com o Gr:ifico 1, um nOmero crescente de conjunto de prioridades, levando a desenvolver empresas em processo de implants2o a cads ano, sendo uma estrat6giade acompanhamentodo trabalho e que, mars da metade desses programas forarnimplantados iderxtifica2o da disponibilidade de recursOs. a partirde 1997, 32 / QuaTlC'2001 ______________________________________ Gr fico 2 Grhf i c o 1 COnhecimentO do NOdelOs e NOrmas da Distribuio das empresas, Segundo ano de Qualidade de Processos [10] implantaAo de programa de Qualidade Total, Sistema de Qualidade ou similar [10] 0 software prodnzido no Brasil es Se Quadro 4 aproximando do padr8 intemaciona/, o que j5 permite as Conhecimerl~o dOS Model Os C~ e SPICE [1O "Careaon-a" N.' % N .o % -no-"rrnas- e projetos relac'ionaos ao tea, como: Conhece e usa sistemaneamente 8 1.8 1 0.2 - SPICE, que 6 um projeto que fol Conhece e comeca a usar 8.1 14 3.2 estabelecido em junho de 1993 pela ISO/IEC Conhece mas no usa 165 37.2 301 27.3 ffCl/SC7 (Subcomit de Xngenharia de Software) N conhece 234 528 308 69.4 com tres objetivos principais: auxiliar o ,"" - '' desenvolvimento de uma Norma Internacional para avaliaVo de processos de software; coordenar e A aplicaAo do CMM nos processos de analisar utilizaJes desta futura Norma Para subsidiar desenvolvimento de software em empresas brasileiras de revis6es antes de sua publica80; e dissemina'"la no pequeno porte e justificada medida em Que aumenta mercado; significativamente a possibilidade de participarem do . Norma ISO/IEC 12207, Information mercado mundial, junto ao qual 6 exigido a certifica8o Technology - Software Life Cycle Process, Que em sisternasde qualidade~ define os processos de software, apresentando framework para processo de ciclo-de-Vida com terminologia hem definida - CMM (Capability Maturity Model) Aldm do ClvlM ser um modelo para avaliaBo da maturidade dos processos de software de urns organiza80, 6.1. O arnbiente ele tamb6m orienta sen usuo identificao d prticasve, que so reque p aumentar a O estudo de caso foi conduzido em uma empress matdade dess processos, de acordo com o co 2 brasileirade pequeno porte desenvolvedora de solo6es de Tabela 4, tal conceito conhido por 47% empras software. A empresa em questdo, conta atualmente com brasileir sendo usado por 21% dessas. cerca de vinte desenvolvedores e tr8s gerentes de projetos~ A implementa3o do CMM Nine} 2 foi encaradapor sews diretores como um novo projeto, desta forma, equipes foram formadas e cronogramasdefinidos. O atingimento deste mvel costuma ser o mais dificil e o Que despende mais tempo e esforOs, uma vez Que a organize50 evolui do rlivel ca6tico de desenvolvimento, ou seja, sem padr6es ou metodologias, para seguir um modelo padronizado de garantia da qualidade de sens processos de software. QuaTIC'2001 / 33 A seguir s5o apresentadas as fases de implementa5o Devido ao faro do CMM n8o estabelecer como os do CMM Nivel 2 utifizando-se o Modelo IDEAL como procedimentos de melhoria devem ser implementados, fica guia para melhoria dos processos de software. a crit6rio da empress desenvolver mecanismos para a conduAo de sens processos de melhoria. A seguir ( apresentadaurns visAo geral dos padr6es para o atingimentodas Ineas-chave 1 e 2 desenvolvidos e As melhorias do processo de software devem ser estabelecidos na empresa em questo: conduzidaspor equipes Quetenham conhecimentos s6iidos em engenharia de software e sistemas de qualidade. Nas pequenas empresas, as equipes podero ser compostas por membros da pr6priaorganiza50, onde urns pessoa poderd desempenharvios papeis. Na empresa em quest8o, a primeira equipe formada foi o SEPG (Soare Engineerz`ng Process Group), constituidapor um funciondrioe dois contratados. Essa equipe foi responsavel por conduzir as atividades de manutenAo e meJhoriado processo de software. A seguir, foi definido o Cowit& Estrat6gico, responsdvel em prover os recursos necessariOs para o projeto. assim como aprovarnovos processos e polfticas. 0 terceiropasso foi a defini5o das pessoas-Chane, responsdveis por fornecer aspectos de gerenciamento e planejamento dos processos atuais. Ap6s formados Os grapes, foram ministradas palestras sobre os conceitos e praticas do CMM, com o objetivo de difundira id6ia de qualidadepor codaempresa, diminuindo assim qualquer resist8ncia por parte das pessoas envolvidas no processo. 6.3. False de diag;l:L6stico O objetivo desta lase e conhecer a situaVo real da empresa em materiade produAo de software, [04]. For se tracerde urna empresa de pequeno Forte, a estrat6gia utiJizada pelo SEPG para levantamento dos processos atuais foi entrevistas individuals. As informag6es coietadas foram inicialmente gravadas e posteriormentedocumenta. Um outro instrumentousado para o ievantamentoe avalia5o da situsAo da empresa fol a apiica8o do Questiono de Maturidade, desenvolvido peJo SEI, que ap6s estudado pelo SEPG, fol aplicado as pessoas relacionadas aoprocesso de desenvolvimento. Anaves das inforrna6es ievantadas, o SEPG p6de ter urna viso abrangenteda atual situaVo do processo de software da empresa identificando os pontos fortes e fracos relacionados a cads ea-chave, propondo ent&o,as melhorias para os pontos fracos. 6.4. Fase de estabelecimento Nesta fase deve-Se desenvolver um piano de aVo para o atingimentodas areas-chave de processo requeridas para o Nivel 2. 34 / QuaffC'2OOl 8. BibliograBa [Oil CAVANO, J. P"; MCCALL J. A. (1978). A Framework for the Measurement of So.fhvare Qualz.ty. Proceeding ACM Softwate Quality A5surence Workshop, Nonembro. [02] ENDO, Cristina (1998). Uma Estrate:gz"apara Iniciar MeLhoria de Processo de So-f1-ware. DissertaVdo de Mestrado 113 p;iginas, Escola de Engenharia de 580 Calos, Universidadede S&oPaulo. [03] FIORINI. S. T. (1998).Engenharia de Software com CMM, Brasport Rio de Janeiro. [04] GRADY~ R. B- (1997). Successful Software Process Improvement, Prentice-Hall,Nova Jersey. 6.5. Fase de implementao {05] HUMPYREY. W.S.; SWEET. W. L (I987a). Fase em Que so colocados em pratica Os pianos de Charactering the software process.. a maturity framework, ao definidos anteriormente~ Isso pode ser feito atrav6s Sofrware Engineering Institute, CMM1SEI87-TR-II, June. da` supervisdo e acompanhamento de projetos-piloto na {06) IEEE (1983)~ /EEE Standard Glossary of Sofrware organiza50. Engineering Terminology. New York: IEEE, ANSIIIEEE Para o estudo de caso, os padrs de documentos Std 729. acima forum utilizados em cinco projetos de pequeno porte. [07] IEEE (1991). IEEE Standard GLossa of Termz.noLogyin Sofhvare Engineering. In.. IEEE Software 6.6. Fase de K6es aprendidas EngineeringStandardCol\ection. p. 07-83, [08] ISO/IEC 9126 (1994). TecnoLogiade Inform@Vao- Nesta fase, todas as prticas hem sucedidas so Avalia50 do Produto de So/lware Caracterz~sticasde documentadas,servindo como base paraprojetos futuros. QuaLid7dede Diretrizes para o seu Uso - Vets8o brasileira Como, na empresa estudada, a implementa5o do em processo de votaVo peZaABNT com nume3o; NBR- CMM Nivel 2 6 recente, ainda no se fez uso dos projetos ISO/IEC9126, junho. documentados como base para estimativas em novos projetos. {09} KAN, S. H. (1995). Metrics and Models in SofLwareQuaLz`tyEngz.neering,Addison-Wesley. EUA, 7. ConclusSes [10] MCT (1999). QuaLidadee Produtividade no Setor de Software BrasiLeiro.Ministo da Ci8ncia e Tecnologia. Neste artigo, fol proposta uma estrat6gia para Ndmero3. 184 pg. Brasil, Brasilia" implementer um processo de desenvoivimento e manutenVAodo software. Esta proposta segmu algumas (11] PALADINI, E. P. (1990). Controle de Qualidade - diretrizes Que um processo deve ter, indicando como Uma Abordagem Abrangente, EditoraAtlas. avaliar se as metas desejadas estAo sendo satisfeitas ou [12] PAULK, M. C. (1994). A Comparison of ISO 9001 n8o. and the Capabilizy Maturity Model for So.frware,Sofrware No estudo de caso proposto, sugeriu-se Engineering Institute, Carnegie Mellon University, primeiramenteemendero funcionamentodos processos de CMU/SEI-94TR-12, July. desenvolvimento da empresa verificando-Se quais precisaramser modificados, adicionados e principaJmente, [13] PAULK, M- C.; GARCIA, S. M ; CHftISSIS. M documentados de acordo com as areas-chave- B., WEBER, C. V.; BUSH, M. (1993). Keypractices of the Finalmente, o processo de implementaVo relatado, Capability Maturizy Model, Version 1.1, Software Engineering Institute, Carnegie Mellon University, poderd servir como base para a cria5o de um modelo de CMUiSEI-93-TR-25.ESC-TR-93-178, February. refer8nciaimetodologia para empresas de pequeno porte que vivam a mesma dificuJdade. [14} PRESSMAN. R. S. (1994). So.lftwareEngineering - A Practtioners Approach. Ed. Europeia McGraw-HiIl" QuaTIC`2001 / 35 [15] QUEIROZ",Luiz (2000). SoL:twareNacional n Lem ISO 9000. ComputerWorld http/www.uol.corn hr/computerworld/technology/0007/00 O7issohtrn pesquisa realizada em 17/07/2000. [16] SANDERS. J-; CURRAN, E. (1994). Software QUaIity "A Framework for Success in So)\iware Development and Suport ", AdeIison-Wesley. [17] SEI (1997). Process Maturity ProfiLe of Ike Sofiware Community 1996year end Update, Software Engineering Institute. [18] SIEGEL J. A. L. (1990). National Software Capacity: Near - Term Study, So&ware Engineering Instimte, CMU/SEI-9OTR-12,ADA226694, May. [19) SMITH, D. J. WOOD, K. B. (1989). Engineering QuaLit:Y So.fhvare A Rcvz"ew of CurrenL Practi"ces SLandards and Gu!deLines incLuaz.ngnew Methods and Developement TooL,Elsevier Science Publishers Lida [20) TSUKUMO, N. A. (1995). ModeLos de Processo de Soare Visao GlobaL e Analise ComparaLiva, Fund5o CTI - Brasil, Campinas. [21] MARCINIATI, J.J. (1994). Encyclopedia of Software Engineering, Wiley Intersciense Publications, vl/, p.851-869. [221 PIRES,A-; MENDES, J.R.B. (1999). CMM: 0 Diflcil daro Primeiro Passo paraa Qualidade,Developers Magazine, Fevereiro. 36 / QuaTIC,2001