Resumo
As mudanVas no plano politico ve^m senao sistemaricamente acompanhadas pelas dz.retrizes do Gonerno Brasileiro. Programas de qualz.dade,incLuz.ndoa cerri!icaVa-odos processos e produros de soare, hoje caracterz`~adoscoma compete^nciaspara competz`tz.vz.dade, rornar-se-ao z"ndz.spensdveipsara a sobrevive^ncia em tango prazo no Mercado z"nternacionaL.Pesquisas constataram uma forte reLaVa-oentre quaL-zdadedo soare e seu processo de desenvolvz.mento.
Na quesrdo do avaliaVao e melhor"zado processo, o CMM (Capabili Maturity Model) quaLz.fica a capacz"taVaodos processos de soare, com o objerivo de avail.or o estodo atuaL e dejl~niraV6es para a melhorz.a evoLutz.va desses processoS~ Ele tambe~m on-enta no identiflcaVa-odos pro z.cas-chaverequeridas para aumento da maturidade dos processos. Embora 36% das empresas brasilez.ras sejam Te pequeno Forte, nenhuma recebeu a certzcaVa-o CMM.Sua apLica50, porranro, e~jusrz.fzcoda`a medida qua aumenta a possibil"zdade dos mesmas participarem do mercado mundiaL, onde sao exigidaS a capacitaVa-oe maturz.dadedos processos de soare 1. Introdu&o
Aos valores econ6rnicos classicos - capital, trabalhoe terra, uma nova dimens&o foi adicionada - a do conhecimento.Na chamada "sociedade da informsAo", o quadro mundial passa por fortes e aceleradas transformaJes em suas estruturaspoliticas, econ6micas, sociais e culturais, e verdadeiras revoluJes nas tecnologias de informa&o e comunicaAo~
Considerando qua o setor de software serzi,Segundo pesquisas internacionais, responval pelos maiores indices de crescimento na economia global nos pr6ximos anos, o Brasil es participando do movimento Que consiste em uma estrat6gia para o aumento da competitividadebaseadaem qualidade,custos e efici8ncia.
Com taxa mia annal de crescimento da receita de 19% sobre os valores correntes, o setor de software 2. software brasileiro apresentouum melhor desempenho na decada de 90, quando comparado ao hardware,que cresceu 6% ao ano no mesmo perfodo. Trata-se de urn mercado de US$2,5 bilh6es proveruentes da comercializaAo de software das empresas desenvolvedoras nacionais, acrescido de US$1 2 bilh6es estimado para a irnporta5o de software, resultanteda remessaem direitosautorais.
Neste contexto, o Brasil Esta procurando alcanar padr6es internacionais efetivos em qualidade e produtividadeno setor de software.Grandesinvestimentos tern ocorrido na area com fomento da Sociedade Brasileira para Promo5o da Export&Vo de Software - SOFTEX 6rgilo gonernamental que tern como um dos objetivos transformar o Brasil em um centro de excel8ncia na produo e export&Aode software.
Problemas de empresas que desenvolvem
Segundo [
Na auncia de um processo organizado de desenvolvimento de software, os resultados dependem da exist8ncia de algumas avaliaJes individuais para projetos pr6ximos. De acordo com [181, a melhoria contfnua,pode ocorrer somente atrav de esforos focados e sustentados pela construAo de uma infra-estrutura de engenharia de software e prticas de gerenciamento.
QuaRdadeapRcada ao software
Kan em [9], apresentauma perspectina hist6rica a respeito da Engenhariade Software.a qual 6 apresentadaa seguir:
*Era Funcional - anos 60: Aprendeu-Se a usar a tecnologia de inform&&opara suprir as necessidades institucionais e comar a integrar o software nas opera6es dias das organizaJes.
*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 rumo diferente, uma vez Que as aplicaV6es de baixo custo puderamser largarnenteimplementadas. Assim, a impocia da produtividade no desenvolvimento de softwareaumentousignificativamente.Poi no final dessa dcada que se reconheceu a imponcia da qualidadedo software.
.Era da Qualidade- anos 90: Com a tecnologia do estado da arte, espera-Se slender demanda dos clientes com a exig8ncia da alta qualidade. Essa exig8ncia intensificada pela crescente dependncia da sociedade pelo software.
A -respeito da qualidade de software, ha muitos conceitos para deflni-la, sob diferentes pontos de vista apresentadosna literatura.O Quadro 1 a seguir, &presents algurnasdestas definiJes:
Um produto de software apresenta qualidadedependendo do grau de satisfaAo das necessidades dos clientes sob todos os [16]
E o grau em que o software possui uma [06] combinaAo desejada de atributos.
E O grau em que Osatributosdo software DoDo capazes de desempenharsun finalidade Std2l68 especificada.
A percep5o da qualidade de software 6 [19] vista principalmenteem termos de tempo em que um sistema de software opera corretamente.
E a conformidade aos requisitos [14] estabelecidos, aos padr6es de desennolvimento documentados e iis caracteristicasimplicitas que $50 aguardadas pelos desennolvedoresde software.
Quadro 1
Defini(;:6essobre Qualidade de Software
Com o objetivo de dar continuidade ao estudo da
quaZidadedo software.o assunto6 dividido em duas ens:
qualidadedo produtoe qualidadedo processo de software.
Estas areass8o apresentadasa seguir.
3.1. QuaRdadedo produto .de software
4.1. Capability maturity model (CMM) - SEI/CMU
De acordo com Endo [02], nos l:iZtimos60 anos,
todo esforo esteve concentrado em se obter controle da
qualidade do produto final, para qua um produto
defeituoso nAo chegasse ils mOs do cliente. Trabalhos
realizados por McCall, apresentados na norma ISO/IEC
9126 [081, procuram definir um conjunto de caracteristicas
que evidenciam a qualidade do produto final [01]. Essas
caracterfsticas sgo definidas para representer necessidades
e desejos daqueles Que est5o direta ou indiretamente
envolvidos com o software, [
32. Qualidade do processo de software
De acordo com Paulk[13], o processo de software 6 representado pol um conjunto sequencial de atividades, objetivos, transformaJes e eventos que encapsulam estrat6Biaspara o cumprimento da evoluV&odo software.
Para Fiorini [03], conhecer Os processos significa conhecer como os produtos e serviOs s8o planejados, produzidos e entregues ao cliente.
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 metas e polmcas, equipe de desenvolvimento, cronograma, disponibilidade de recursos humanos, t6cnicos e financeiros.
Al6m desses aspectos, outros tamb6m devem ser relacionados ao processo, como: fluxo de informa5o, condiJes especificas para delimitar o inicio e o Rm de cada fase, sequenciamento das atividades e pap6is desempenhados pelas pessoas, [22].
A grande import8ncia dada ao processo de software pode ser vista como forma de garantir a construAo de um software de melhor qualidade. Espera-se que urn processo contro2ado de software propicie segurana frente as variaJes que o produto possa softer em relaAo Ils suas especificaq6es iniciais, [19].
Para isso, um mecanismo gerencial deve garantir o cumprimento das responsabilidades e a conduqAo do grupo para que se possa desenvolver o sistema de maneira segura e controlada, [09].
4. Me&oria de processo de software 0 SEI (Soare Engineering Institute) sediado na CMU (Carnegie Mellon Um`"versit)l),em Pittsburg, Pennsylvania - Usa, 6 um centro de pesquisa que fol criado em 1984 pelo Departamentode Defesa dos Estados Unidos (DoD - Department of Defense) e e patrocinado pelo OUSD CA&T) (Oce of the Under Secreta of Defense for Acquisition and Technology). As areas de atuao do SEI 530:capacita30 de ger6ncia de software e tecnologia para a engenharia.0 SEI focaliza tambm a translAo tecnol6gica, ou seja, o desenvolvimento e ado5o das meZhoresprticas de engenhariade software.
4.1.1
Estmtma do CMM
De acordo com Humprey {052, o CMM promove nas organizaJes desenvolvedoras de software, um guia de como alcanar o controle em sens processos de desenvolvimento e manuteno de software, e um modelo de como envolver uma cultura de engenharia de software e prdticas de gerenciamento. 0 CMM fol desenvolvido para oriental organizaJes na sele5o de estrat6gias de melhoria de processos pela maturidade atual e identificar areas mais crfticas de qualidade de software- A Figura I a seguir ilustra Os Niveis de Maturidade do CMM:
Como apresentadopela Figura 1, o CMM classifica as organizaJes em cinco niveis evolutivos de maturidade, cada nfvel com suas caracteristicas pr6prlas. Estas caracterfsticasestSo apresentadasno Quadro2 a seguir: Visac
Geral de Maturidade
dO
Quadro dOs Niveis cMN [13]
2
CaracteriSt:I`cas
Nfvel CMM (1) Inicial
O processo de desenvolvimento 6 desorganizado e ate ca6tico~ Poucos processos s2o definidos e padronizadose o sucesso depende de esforOs individuals e her6icos dos desenvolvedores. (2) Os processos bdsicos de Repetitivo gerenciamento de projeto esdio estabelecidos e permitem acompanhar custo, cronograma e funcionalidade, 6 possivel repetir o sucesso de um (3)
Tanto as atividades
d (4) Gerenciado ooerenciamentoquanto de engenharia do processo de desenvolvimento de software eso documentadas, padronizadas, e integradas em um padr&o de desenvolvimento da organiza5o. Todos Os projetos utilizam uma vetso aprovada e adaptada do processo padr5o de desenv.olv~imento de software da
S-ao coletadas medidas detalhadas da qualidadedo produtoe processo de desenvolvimento de software.Tanto o produto quanto o processo de desenvolvimento s5o entendidos e (5) 0 melhoramento contfnuo do Otimizado processo 6 conseguido atravdsde um feedback quantitativodos processos e pelo uso pioneiro de id6las e 4.1.2 As areas chave de processos (KPA's)
Todos os nfveis do CMM com exce5o do nine! 1, s3o compostos de um certo n6mero de eas-chavede processo (Key Process Areas ou RPA's), Que descrevem Os objetivos a screw atingidos, assim como as quest6es a screw enderadas para se alcanarem estes objedvos e atingir aquele nfvel. Todas as areas chaves sRo apresentadasa seguir:
Quadro 3 Vis o GeraJ dos Niveis de aturidade do e suas respectivas EPA's [13] Cl) (2) (4) (5) de Engenharia Organizacional e Apoio Defini5o do Processo
Organizacional
Programa de Treinamento
Gerenciamento de Software Integrado
Engenharia de Produto de Software
CoordenaAo
Intergrupos
Qualidade Gerenciamento do Produto e do Quantitativodos Processos Processo Gerenciamento da
Qualidadedo Software
Melhorame Preveno de Defeitos nto Continuo Gerenciamento de do Processo Mudanas Tecnol6gicas
Gerenciamento de 4.1.3 O cIminho para o Nfvel 2 de matnridade do CMM
A adoi1o do CMM baseia-se em um processo gradual de aumento da maturidade do desenvolvimento do software. Essa maturidade pode ser traduzida como a probabilidadede entregarsistemas de software dentrodos prazos, utilizando Os mesmos recursos planejados e atendendoaos requisitose qualidadedesejados{21}.
O objetivo de alcanar o Nfvel 2 institucionalizarum processo efetivo de gerenciamentode projetos de software, Que permite as organizaJes repent suas praticas atraves 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 instalado controles de gerenciamento bdsico de software. Compromissos realfsticos de projetos $50 baseados nos resultados observados em projetos previos e nas necessidades dos atuais.Um gerente de software rasteiaos custos, tempo, funcionalidade e Os problemas s5o identifxcados. Os requisitos SRO desenvolvidos e sua intedade conolada. Projetos padr $50 denidos e a orgaao assegma Que Os mesmos serAo fxelmente segdos.
aprendo a gulf, dehamento das As referentes ao NfveI 2 do C.
A 1 - Gerenciamento de Requisitos: a proposta do Gerenciamento de Requisitos estalec um entendimentocomum ene o clite e a pe do projeto sobre Os ruisitos alocados ao sowe. Envolve o estalecimento e manuten30 dos ruisitos de acordo com as necessidades do cliente. O cliente pode ser interpretadocomo o grupo de engenharia,marketing,outro intemo da organizaV&ou um cliente externo. Este acordo forma a base para estimar,planejar,executare localizer as atividadesdo projeto de software ao longo do sen ciclo-deVida,[13]~
KPA 2 Planejamento do Projeto do Software: o prop6sito 6 estabelecer pianos para o desempenho e manuten50 do projeto de software. Envolve o desenvolvimento de estimativas para o trabalho, estabelecimento de compromissos e de um piano para guiar o projeto. 0 planejamentocomea com a declara5o do trabaJho e outras metas Que definem o projeto (estabelecidos pelas praticas do Gerenciamento de Requisitos). O processo de planejamento inclui passos para estimar o tamanho do produto de trabalhoe recursos necessdriOs, identificaVo e avaliao de riscos. A inter&50 atrav6s desses passos deve ser necessdria para estabelecero piano do projeto.Esta piano promove a base para o desenvolvimento e gerenciamentodas atividadesdo projeto e encaminhaas necessidades do cliente de acordo com os recursos e capacidadesdo projeto.
KPA 3 - Acompanhamentoe Superviso de Projeto de Software; sua fmalidade 6 promoveruma vio adequada do progresso real do projeto, de modo que o gerenciamento possa tomar medidas efetivas quando o desempenho desvia-se do plano proposto. Envolve acompanhar e revisar Os resultados e as realizaJes do software confrontandocom as estimativas documentadas, 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 Osclientes. Quando ocorrerum desvio entre Ospianos e Osefetivos resultados,deve-Se alterara forma como o trabalhoesta sendo desempenhadoou ajustar os planos.
EPA 4 - Gerenciamentode Subcontratosde 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 cldusulado 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 processo Queest;isendo utilizadoe dos produtos que eso sendo construidos. Envolve revis5es e auditories nos produtos de software e Has atividades para assegurarQue esriio em conformidadecom Os padr6es e procedimentos aplicados.
EPA 6 - Gerenciamentoda ConfiguraAo de Software: sua proposta 6 estabelecer e rnanter a integridade dos produtos do projeto ao longo do ciclode-vida. Envolve identificar os itens de configura5o, controlar sistematicamenteas alteraJes e mauler a integridado da configurago ao longo do ciclo-de-Vida.Utiliza linhas de refer8ncia (baseLines) qua servem como um marco no ciclode-vida do software. Os itens Que passam por ulna baseline podem ser alter&dos somente arrays de procedimentosformals de controle de mudanas.
0 SEI estabeleceu uma proposta Que descreve lases, atividades e recursos Recessos para tomar iniciativas de melhoria de processo com sucesso, [12]. De acordocom Fiorini [03], esta proposta6 similar ao ciclo de meZhoriaPDCA (P/an, Do, Check ana Act - PZanejar, Fazer, Verificare Agir) e 6 denominadaIDEAL.
4.2.
O modelo IDEAL 0 modelo IDEAL (/nitiating, Diagnosing, EsrabiLishz.ng,Acting and Leamz`ng - Inicializao, Diagn6stico, Estabelecimento,Ao e LiJes Aprendidas) versiio 1.1, descreve uma abordagem de ger6ncia Que ajuda as organizaJes desenvolvedoras de software a melhorarem sen processo de desenvolvimento. Este modelo estabeiece um program&de melhoria continua de processo de software. A Figura 2 a seguir, apresenta sua estrutura;
Estrutura
De acordo com Endo [02], cada uma das lases 6 realizada anands da execu2o de uma sqrte de atividades descritasa seguir:
Fase 1-Inicializao: dove-se articulara aplicaV8odos esforos para satisfazer ils necessidades` de neg6cio, asseguraro suporte ao gerenciamento e colocar em prdtica uma infra-estrutura para gerenciar Os detalhes de implementsAo do processo de melhoria.
. Esamulo para Mudanas; envolve definir as necessidades de neg6cio que alavancam as mudanas nas praticasda organizaVAoQ.uandoas necessidades de mudanas o evidenciadas par raz6es de neg6cio, e mais facil convencer a organizaAo como um todo, e existem rnaiores chances de sucesso. . Estabelecimento do Contexto: ap6s estarem definidas as raz6es para melhoria, a organizaAo estabelece o contexto para o trabalhoque vai ser realizado. Isso significa definir Dude Os esforos se enquadraxBo na estrat6gia de neg6cio organizacional, que metas e objetivos ser8o afetados pelas mudanas como isso vat incidir sobre trabalhos futuros e quais as resultados esperados. . Definio de Patrocinador: o patrocinador deve ajudara mantero comprornissonos momentos de dificuldades e garantir as recursos essenciais utilizados durantea melhoria.
Fase 2-Diagn6stico: deve-se desenvolver um entendimentodo trabalhopara a melhoria.
. Fornecimento de Infra-Estrutura;envolve definir um mecanismo para gerenciar as esforOs para detalhes de implementa&o. e tamb6m fornecer um contrato que documente e esclarea as expectativas, e descreva as atividades e responsabilidades. . CaracterizaAo dos Estados Atual e Desejado: urnavez identifxcadoo estado atual,pode-se usar o CMMpara definiro desejado. . Desenvolvimento de RecomendaJes: as atinidades da fase de diagn6stico so desempenhadas pelas pessoas mais experiences ou par especialistas na organiza5o Suas recomendaJes 850 daseadas nas decis6es tomadaspelos gerenteschefe e patrocinadores.
Fase 3-Estabelecimento:deve-se desenvolverum piano detalhado do trabalho,coma par exemplo: prioridadese restriJes do ambiente operacional. A seguir, uxna abordagem Que home esses fatores, aJes especfficas, prazos, produtos liberdveis e responsabilidades so incorporadasao piano de a80.
. Estabelecimento de Prioridades: envolve LimitsiiO de recursos, depend8ncias entre as atividades recomendadas,interveno de fatores extemos e prioridadesglobals da organiza5o. .
Desenvolvimento de Abordagem: Envolve a compreeno do escopo do trabalho com a conjunto de prioridades, levando a desenvolver uma estrat6giade acompanhamentodo trabalhoe iderxtifica2o da disponibilidadede recursOs. * Planejamento das Ades: deve-Se desenvolver um piano deta]hado de implementao, o qual inclui cronograrna, tarefas, prazos, recursos, responsabilidades, medidas, riscos e estrat6gias. . Fase 4-Ao: envolve implementar o trabalho Que foi contextualizado nas lases anteriores. . CriaVo de SoluV:Aod:esenvolver a melhor soloko destinada its necessidades previamente identificadas na Organizao. . Teste da SoluV:8o:a soluV:2odeve ser testada, pois por mais Que ela seja hem elaborada, raramente funciona como planejado. . Refinamento da SoluV5o: a soluV:o pode ser modificada para refletir o conhecimento e a expert8ncia obtidos. . Implementao da soluV:5o:deve-Se implementer a soluV:Aopar coda organiza&o, utilizando algumas abordagens, como For exemplo: just-in-time.
Fase 5-LiBes: nessa lase, coda experiencia adquirida e revista para determinar o que foi cuxnprido e como a organizaV:Ao pode implementar melhorias mais eficientemente no futuro. . Anlise e Validao: essa atividade responde a uma s6fie de perguntas: de Quemaneira o esforo cumpriu a proposta esperada?, o quo funcionou melhor?, o que pode ser feito para melhorar a efxci&ncia?.Os dados s5o coletados, analisados, resumidos e documentados. As necessidades identificadas na lase de inicializa98o 8o examinadas para verificar se foram ou nAosatisfeitas. . Proposta de Futures AJes: as recomendaV:6es baseadas na andlise e Valida5o s8o desenvolvidas e documentadas. 5. Empresas software bras8eiras desenvolvedoras de
Quest5es relacionadas ao planejarnento estrategico, programas e sisternas da qualidade (de produtos e de processos de software), incluindo sua certifio, hoje caracterizadas coma compet8ncias qualificadoraspara competiV8ono mercado global, tornarseo um conjunto de compet8ncias bicas para sua sobreviv8nciaa longo prazono mercadointernacional.
De acordo com QUEIROZ(2000), do Ministerio da Ci8ncia e Tecnologia, embora as empresas nacionais de software estejam aumentandoseas quadros com mAode-obra especializada e busquem corrigir falhas ouvindo os clientes, a procura par prograrnas de melhoria de qualidade ainda 6 baixa. Por6m, pode-se observer. de acordo com o Gr:ifico 1, um nOmero crescente de empresas em processo de implants2o a cads ano, sendo que, mars da metade desses programasforarnimplantados a partirde 1997, ______________________________________
Grhf i c o 1
Distribuio das empresas, Segundo ano de implantaAo de programa de Qualidade Total, Sistema de Qualidade ou similar [10] -no-"rrnaesp-rojetos relac'ionaos ao tea, como:
- SPICE, que 6 um projeto que fol estabelecido em junho de 1993 pela ISO/IEC ffCl/SC7 (Subcomit de Xngenharia de Software) com tres objetivos principais: auxiliar o desenvolvimento de uma Norma Internacional para avaliaVo de processos de software; coordenar e analisar utilizaJes desta futura Norma Para subsidiar revis6es antes de sua publica80; e dissemina'"la no mercado;
. Norma ISO/IEC 12207, Information Technology - Software Life Cycle Process, Que 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, ele tamb6m orienta sen usuo identificao d prticasve, que so reque p aumentar a matdade dess processos, de acordo com o co 2 Tabela 4, tal conceito conhido por 47% empras brasileir sendo usado por 21% dessas.
0 aproximando software do padr8 prodnzido no Brasil es Se intemaciona/, o que j5 permite as Conhecimerl~o
Quadro 4 dOS Model Os C~
e SPICE [1O
Gr fico 2 COnhecimentO do NOdelOs e NOrmas da
Qualidade de Processos [10] "Careaon-a" Conhece e usa sistemaneamente Conhece e comeca a usar Conhece mas no usa N conhece N.' 8 165 234
A aplicaAo do CMM nos processos de desenvolvimento de software em empresas brasileiras de pequeno porte e justificada medida em Que aumenta significativamente a possibilidade de participarem do mercado mundial, junto ao qual 6 exigido a certifica8o em sisternasde qualidade~ 6.1. O arnbiente
O estudo de caso foi conduzido em uma empress brasileirade pequeno porte desenvolvedora de solo6es de software. A empresa em questdo, conta atualmente com 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 formadase 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.
A seguir s5o apresentadas as fases de implementa5o do CMM Nivel 2 utifizando-se o Modelo IDEAL como guiapara melhoriados processos de software.
As melhorias do processo de software devem ser conduzidaspor equipesQuetenhamconhecimentos s6iidos em engenharia de software e sistemas de qualidade. Nas pequenas empresas,as equipes podero ser compostaspor membros da pr6priaorganiza50, onde urnspessoa 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 atividadesde 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 planejamentodosprocessos 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. Falsede 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 outroinstrumentousado 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 urnaviso abrangenteda atual situaVo do processo de software da empresa identificando os pontos fortes e fracos relacionados a cads ea-chave, propondo ent&o,as melhoriaspara 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.
Devido ao faro do CMM n8o estabelecer como os procedimentos de melhoria devem ser implementados,fica a crit6rio da empress desenvolver mecanismos para a conduAo de sens processos de melhoria.
A seguir ( apresentadaurnsvisAo geral dos padr6es para o atingimentodas Ineas-chave 1 e 2 desenvolvidos e estabelecidos na empresa em questo: 6.5. Fase de implementao
Fase em Que so colocados em pratica Os pianos de ao definidos anteriormente~ Isso pode ser feito atrav6s da` supervisdo e acompanhamento de projetos-piloto na organiza50.
Para o estudo de caso, os padrs de documentos acima forum utilizados em cinco projetos de pequeno porte.
6.6. Fase de K6es aprendidas
Nesta fase, todas as prticas hem sucedidas so documentadas,servindocomo base paraprojetos futuros.
Como, na empresa estudada, a implementa5o do CMM Nivel 2 6 recente, ainda no se fez uso dos projetos documentados como base para estimativas em novos projetos.
7. ConclusSes
Neste artigo, fol proposta uma estrat6gia para implementer um processo de desenvoivimento e manutenVAodo software. Esta proposta segmu algumas diretrizes Que um processo deve ter, indicando como avaliar se as metas desejadas estAo sendo satisfeitas ou n8o.
No estudo de caso proposto, sugeriu-se primeiramenteemendero funcionamentodos processos de desenvolvimento da empresa verificando-Se quais precisaramser modificados, adicionados e principaJmente, documentadosde acordocom as areas-chave
Finalmente, o processo de implementaVo relatado, poderd servir como base para a cria5o de um modelo de refer8nciaimetodologia para empresas de pequeno porte que vivam a mesma dificuJdade. 8. BibliograBa
[Oil CAVANO, J. P"; MCCALL J. A. (1978). A Framework for the Measurement of So.fhvare Qualz.ty. Proceeding ACM Softwate Quality A5surenceWorkshop, Nonembro.
[02] ENDO, Cristina (1998). Uma Estrate:gz"apara Iniciar MeLhoria de Processo de So-f1-wareD.issertaVdo 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.
{05] HUMPYREY. W.S.; SWEET. W. L (I987a). Charactering the software process.. a maturity framework, Sofrware Engineering Institute, CMM1SEI87-TR-II, June.
{06) IEEE (1983)~/EEE Standard Glossary ofSofrware Engineering Terminology. New York: IEEE, ANSIIIEEE Std 729.
[07] IEEE (1991). IEEE Standard GLossa of Termz.noLogyin Sofhvare Engineering. In.. IEEE Software EngineeringStandardCol\ection. p. 07-83,
[08] ISO/IEC 9126 (1994). TecnoLogiade Inform@VaoAvalia50 do Produto de So/lware Caracterz~sticasde QuaLid7dede Diretrizes para o seu Uso - Vets8o brasileira em processo de votaVo peZaABNT com nume3o; NBRISO/IEC9126, junho.
{09} KAN, S. H. (1995). Metrics and Models in SofLwareQuaLz`tEyngz.neering,Addison-Wesley. EUA, [10] MCT (1999). QuaLidadee Produtividade no Setor de Software BrasiLeiro.Ministo da Ci8nciae Tecnologia. Ndmero3. 184pg. Brasil,Brasilia"
(11] PALADINI, E. P. (1990). Controle de Qualidade Uma Abordagem Abrangente, EditoraAtlas.
[12] PAULK, M. C. (1994). A Comparison of ISO 9001 and the Capabilizy Maturity Model for So.frware,Sofrware Engineering Institute, Carnegie Mellon University, CMU/SEI-94TR-12, July.
[13] PAULK, M- C.; GARCIA, S. M ; CHftISSIS. M B., WEBER, C. V.; BUSH, M. (1993). Keypractices of the Capability Maturizy Model, Version 1.1, Software Engineering Institute, Carnegie Mellon University, CMUiSEI-93-TR-25.ESC-TR-93-178, February.
[14} PRESSMAN. R. S. (1994). So.lftwareEngineering - A Practtioners Approach. Ed. Europeia McGraw-HiIl"
[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 PublishersLida