Resumo. Palavras-chaves: Processo de Software, Melhoria de Processos, Tomada de Decisões, Qualidade de Software. Abstract

Transcrição

1 Cosequêcias e Características de um Processo de Desevolvimeto de Software de Qualidade e Aspectos que o iflueciam: uma avaliação de especialistas Jea M. Adrade, Adriao B. Albuquerque, Fábio B. Campos, Aa Regia C. Rocha {jea, bessa, Biachi, arocha}@cos.ufrj.br Programa de Egeharia de Sistemas de Computação - COPPE/UFRJ Resumo A sistematização do desevolvimeto pelo uso de processos de egeharia de software tem o potecial de trazer vários beefícios para as orgaizações desevolvedoras de software, porém, caracterizar objetivamete o que é um processo efetivo e eficaz ão é tarefa simples. Esta caracterização se mostra importate em vários mometos: a defiição do processo adequado à orgaização e seus projetos; a implatação desse processo; o acompahameto dos seus resultados e a sua melhoria. Visado iiciar essa caracterização, foi realizada uma pesquisa (survey) ode foram apresetados aos participates, três grupos distitos de questões relativas a processos de software, que buscam respoder às seguites pergutas: Que beefícios o uso de processos de egeharia de software pode trazer? Quais são as pricipais características que um processo efetivo deve ter? e, por último, Que aspectos orgaizacioais, humaos e técicos podem iflueciar para a efetividade dos processos?. Os resultados cosolidados da pesquisa são apresetados, permitido uma aálise prelimiar de quais seriam aqueles aspectos mais relevates a se cosiderar a defiição, uso e melhoria de processos. Palavras-chaves: Processo de Software, Melhoria de Processos, Tomada de Decisões, Qualidade de Software. Abstract The systematizatio of software developmet through the use of software egieerig processes has the power to brig may beefits to software developmet orgaizatios, however, characterizig objectively, what is a effective ad efficiet process is ot a simple task. This characterizatio is importat i may times: i the defiitio of a adequate process to the orgaizatio ad its projects; i the deploymet of this process; i the moitorig of its results ad i its improvemet. To iitiate this characterizatio, a survey was coducted, presetig three distict groups of questios related to software processes, that aimed to aswer the followig questios: What beefits the use of a software egieerig process ca brig? Which are the mai characteristics that a effective process must have?, ad, fially, Which orgaizatioal, huma ad techicia aspects ca ifluece the effectiveess of the processes. The cosolidated results of the research are preseted, allowig a prelimiary aalysis of which aspects would be more relevat to be cosidered i the defiitio, utilizatio ad improvemet of processes. Key-Words: Software Process, Process Improvemet, Decisio makig, Software Quality. 1. Itrodução Produtos de software estão presetes a sociedade das mais diversas formas. Segudo REED [1] se algus sistemas de uso global deixarem de fucioar, aproximadamete 40% da população mudial sofrerá as coseqüêcias do problema. No Brasil, observa-se também o crescimeto da idústria de software e a importâcia que a mesma está represetado para a ecoomia. De acordo com a publicação Qualidade e Produtividade o Setor de Software Brasileiro [2], o valor total da comercialização bruta de software das orgaizações da amostra apurado para o ao 2000 foi de R$ milhões, ode 70% resultou de software por ecomeda (R$ milhões). Os domíios de software que mais se destacaram a pesquisa, detre vite categorias defiidas, foram: admiistração

2 privada (42%), serviços em geral (38%), setor fiaceiro e idústria (35%), comércio (34%) e admiistração pública (33%). As orgaizações de software que ão coseguirem: maior qualidade os seus produtos, torado-os cofiáveis, maior produtividade, redução de custos e melhoria a previsibilidade dos seus projetos, correm grades riscos de ão mais permaecerem o mercado. Diate deste cotexto, a idústria de software e a academia estão, cada vez mais, ivestido em processos de software, apostado este recurso como um meio para alcaçar algumas das exigêcias do mercado relacioadas acima. Além disso, há grades evidêcias de que a qualidade de um produto de software está fortemete relacioada com a qualidade dos processos que foram utilizados para desevolvê-lo. No etato, para que um processo de software seja realmete efetivo para os seus projetos, é importate cosiderar vários aspectos. O objetivo do presete trabalho é idetificar o que a comuidade de egeharia de software cosidera como coseqüêcias de um bom processo para projetos de software, as características de um bom processo de software e os aspectos que podem iflueciar positivamete e egativamete a utilização do processo. O resultado deste trabalho auxiliará as orgaizações a coseguirem obter um maior sucesso a implatação e utilização de seus processos de desevolvimeto de software, levado-as, pricipalmete, a cohecerem os riscos que devem ser prioritariamete admiistrados, bem como os potos de melhoria mais relevates. Este trabalho está orgaizado da seguite forma: a seção 2 apreseta, resumidamete, coceitos de processo de software, melhoria de processos e seus beefícios; a seção 3 mostra a metodologia utilizada a pesquisa; a seção 4 apreseta os resultados obtidos, que são aalisados a seção 5 e a seção 6 apreseta as coclusões deste trabalho e suas perspectivas de cotiuidade. 2. Processo de Software e Melhoria do Processo As orgaizações têm dado uma maior êfase a utilização de processos de software como uma das formas de buscar, pricipalmete, uma maior qualidade e cotrole sobre custos e prazos dos projetos. Processo de Software pode ser defiido como: um cojuto de atividades, métodos, práticas e trasformações que pessoas utilizam para desevolver e mater software e seus produtos associados [3]. Para ZAHRAN [4], a melhoria da qualidade, seja em processos de desevolvimeto de software, seja em qualquer outra área, está itimamete ligada à ecessidade de adaptação da empresa com êfase em produto, para a empresa focada em processos. O autor apota os seguites beefícios, quado o foco dos projetos está o processo: alihameto etre as atividades e o foco comum; cosistêcia etre as várias atividades; possibilidade de medição e maior facilidade a codução das equipes. No etato, assim como as orgaizações, os processos ão são estáticos e ecessitam acompahar a diâmica das orgaizações e seus egócios. Daí a importâcia da melhoria de processos, disciplia que evolve as seguites etapas: idetificação dos potos fortes, idetificação dos problemas que estão iterferido a capacidade do processo, implemetação das devidas alterações e avaliação dos impactos e beefícios decorretes das modificações realizadas. A orma ISO/IEC [5] defie processo de melhoria como um processo para estabelecer, avaliar, medir, cotrolar e melhorar um processo de ciclo de vida de software. E a ISO 9000 [6] apota as seguites ações como as ecessárias para uma melhoria cotíua: aálise e avaliação da situação existete para idetificar áreas para melhorias; estabelecimeto

3 dos objetivos para melhoria; pesquisa de possíveis soluções para atigir os objetivos; avaliação e seleção destas soluções; implemetação da solução escolhida; medição, verificação, aálise e avaliação dos resultados da implemetação para determiar se os objetivos foram atedidos; e formalização das alterações. 3. Metodologia de pesquisa O objetivo desta pesquisa é idetificar as coseqüêcias do uso de um bom processo de desevolvimeto; as características que devem estar presetes em um bom processo de desevolvimeto; e os aspectos que podem iflueciar positiva ou egativamete a utilização do processo. Como istrumetação para a pesquisa, foi elaborado um questioário que aborda questões a respeito das características e coseqüêcias de um bom processo de desevolvimeto de software e aspectos que iflueciam positiva e egativamete este processo. Tais questões foram implemetadas, baseadas a literatura de Egeharia de Software, e ão tem a pretesão de ser uma lista completa, podedo o participate da pesquisa iserir ovos ites ao questioário. O questioário foi dividido em cico partes, sedo que a primeira parte tem como objetivo caracterizar e qualificar o participate em relação à atividade que desempeha, sua formação, sua experiêcia profissioal em projetos de software e seu cohecimeto e experiêcia em Processo de Software. O restate do questioário é formado de questões fechadas com opções múltiplas e exclusivas abragedo, respectivamete, as coseqüêcias de um bom processo de desevolvimeto, as características de um bom processo de desevolvimeto e os aspectos que podem iflueciar positiva e egativamete a utilização do processo de desevolvimeto de software. Os questioários foram etregues aos participates sem que o preechimeto sofresse ehum tipo de acompahameto em cotrole de tempo de preechimeto. Para tato, foram utilizados questioários em meio físico, que foram etregues pessoalmete e em meio eletrôico, distribuídos através de . O preechimeto foi volutário e realizado o tempo e o ambiete escolhidos pelo participate. Os idivíduos foram selecioados por coveiêcia e dispoibilidade. No esforço de abrager uma parcela represetativa do uiverso de especialistas em Qualidade e Egeharia de Software o Brasil, o questioário foi distribuído a diversos participates do II Simpósio Brasileiro de Qualidade de Software (II SBQS); aos participates do Ecotro da Qualidade e Produtividade em Software EQPS, ambos em Fortaleza, CE; a aluos de pós-graduação e professores da COPPE/UFRJ e a diversas outras pessoas com cohecimeto recohecido a área de Qualidade e Egeharia de Software. Assim sedo, procurou-se obter a colaboração de idivíduos da idústria e da academia, de diversas regiões do país e com experiêcias diversas com o objetivo de dimiuir um possível viés a amostra, decorrete de potos de vista particulares de cada um desses segmetos. 4. Cosolidação da pesquisa A Metodologia e critérios adotados para a cosolidação desta pesquisa basearam-se em FARIAS [7] e NOGUEIRA e ROCHA [8] e será vista a seguir Perfil da amostra iicial A primeira parte do questioário tem como objetivo caracterizar e qualificar o participate da pesquisa. De acordo com esta caracterização, será atribuído um peso às suas respostas, uma vez que a amostra utilizada é composta de pessoas de diferetes seguimetos idústria,

4 academia, estudates com diferetes graus de cohecimeto e experiêcia. A reuião de todas estas iformações permite caracterizar o perfil da amostra iicial. As tabelas de 1 a 6 mostram, para a amostra iicial, respectivamete: Área de Atuação, Atuação em Idústria, Atuação em Uiversidade, Formação Acadêmica, Cohecimeto em Processo de Software e Experiêcia em Processo de Software. Na tabela 4 foi cosiderado o ível de formação mais alto, uma vez que o questioário permitia mais de uma escolha. Tabela 1 - Participates por Área de Atuação Total de Participates 91 Participates com atuação a idústria 58 Participates com atuação a uiversidade 67 Participates com atuação exclusiva a idústria 24 Participates com atuação exclusiva a uiversidade 33 Participates com atuação cocomitate em ambas 34 Tabela 2 - Participação por Atuação em Idústria Atuação Empresário 5 Gerete de Iformática 2 Gerete da Qualidade 4 Gerete de Projeto 11 Aalista de Sistemas 23 Chefe de Desevolvimeto 2 Cosultor TI 2 Programador 2 Outros 12 Tabela 3 - Participação por Atuação em Uiversidade Atuação Professor 23 Pesquisador 14 Cosultor 8 Aluo de Doutorado 11 Aluo de Mestrado 23 Aluo de Graduação 7 Tabela 4 - Participates por Formação Acadêmica Nível e Área Eg. de Software Computação/Iformática Outro Total Doutorado Mestrado Especialização Graduação Total Tabela 5 - Participates por Cohecimeto em PS Cohecimeto Excelete 9 Alto 33 Médio 44 Baixo 5 Nehum 0 Tabela 6 - Participates por experiêcia em PS Experiêcia Excelete 4 Alta 19 Média 40 Baixa 27 Nehuma 1 No que se refere ao tempo de atuação a área, o tempo médio foi de 9 aos e a mediaa do úmero de projetos em que participou foi de 7 projetos. Apesar da distribuição dos questioários ter sido feita em evetos que, por atureza, apresetavam um elevado úmero de especialistas, ão se pode geeralizar e acreditar que a

5 amostra, a sua totalidade, seja realmete represetativa o cotexto da pesquisa. Pelo fato dos questioários terem sido distribuídos publicamete em tais evetos, estudates de graduação e outros profissioais cosiderados como ão-especialistas participaram da pesquisa. Neste setido, a heterogeeidade da amostra o que tage aos critérios citados acima fica evideciada os dados apresetados Cálculo da Potuação Idividual Com o objetivo de difereciar as respostas dos participates de acordo com a sua caracterização, a cada idivíduo foi atribuída uma potuação idividual, calculada em fução dos diversos fatores que o caracteriza. A formula utilizada para atribuir esta potuação é: P ( i) = Max{ Max[ I( i)]; Max[ U ( i)]} + F1( i) + F 2( i) + T ( i) + N( i) + C( i) + E( i), ode: P(i) é a potuação total atribuída ao participate i; I(i) é a potuação atribuída ao participate i em fução de sua atuação a idústria de desevolvimeto de software segudo a tabela 7; U(i) é a potuação atribuída ao participate i em fução de seu ível de formação acadêmica segudo a tabela 8; F 1 (i) é a potuação atribuída ao participate i em fução de seu ível de formação acadêmico segudo a tabela 9; F 2 (i) é a potuação atribuída ao participate i em fução da área de formação acadêmica segudo a tabela 10; T(i) é a potuação atribuída ao participate i em fução de seu tempo de atuação a área seguda a tabela 11; N(i) é a potuação atribuída ao participate i em fução do úmero de projetos os quais participou segudo a tabela 12; C(i) é a potuação atribuída ao participate i em fução de seu cohecimeto em Processo de Software segudo a tabela 13; E(i) é a potuação atribuída ao participate i em fução da sua experiêcia em Processo de Software seguda a tabela 14. Tabela 7 - Potuação por atuação a idústria Atuação a idústria I(i) Empresário 2 Gerete de Iformática 2 Gerete da Qualidade 4 Gerete de Projeto 3 Aalista de Sistemas 1 Cosultor 3 Tabela 8 - Potuação por atuação a uiversidade Atuação a Uiversidade U(i) Professor 4 Pesquisador 3 Cosultor 3 Aluo de Doutorado 2 Aluo de Mestrado 1 Aluo de Graduação 0 Tabela 9 - Potuação por ível de formação Nível de Formação F 1 (i) Doutorado 4 Mestrado 3 Especialização 2 Graduação 1 Tabela 10 - Potuação por área de formação Área de Formação F 2 (i) Egeharia de Software 4 Iformática/Computação 2 Outras áreas 0 Tabela 11 - Potuação por úmero de projetos Número de Projetos N(i) A partir de 10 4 De 4 a 9 2 Até 3 0 Tabela 12 - Potuação por tempo de atuação Tempo de Atuação T(i) Mais de 15 aos 6 Acima de 5, até 15 aos 3 Até 5 aos 0

6 Tabela 13 - Potuação Cohecimeto em Processo de Software Cohecimeto em Processo de Software C(i) Excelete 4 Alto 3 Médio 2 Baixo 1 Nehum 0 Tabela 14 - Potuação Cohecimeto em Processo de Software Experiêcia em Processo de Software E(i) Excelete 4 Alta 3 Média 2 Baixa 1 Nehuma 0 Para que os dados qualitativos forecidos pelos participates pudessem ser tratados de forma quatitativa, optou-se pela adoção de tabelas de classes. Para os dados já quatitativos por atureza, a opção de mater as tabelas de classes decorreu do fato de tais ites ão serem precisos como, por exemplo: o úmero de projetos que já participou. A adoção do agrupameto por tabelas de classes permitiu cotorar ambos os problemas Distribuição dos Pesos da Amostra Iicial Depois de calculados os pesos dos participates da amostra iicial, a Distribuição de Freqüêcia pôde ser determiada, coforme mostrado o gráfico da Figura 1. Dividido a amostra em quartis, obtêm-se os limites mostrados a Tabela 15. Figura 1 - Distribuição de Freqüêcia de Potuação Tabela 15 - Quartis Quartis Potuação Valor míimo 5,0 Limite do 1º Quartil 10,0 Limite do 2º Quartil 16,0 Limite do 3º Quartil 22,0 Limite do 4º Quartil 30, Ajuste da Amostra Iicial Devido ao método de coleta de questioários utilizado, vários dos participates da amostra iicial ão se caracterizam como especialistas. Os critérios de potuação adotados permitiram que estes participates fossem idetificados e isolados, sedo represetados pelos participates que compõem o 1º Quartil da amostra, que foram descosiderados da amostra o mometo da aálise de forma a se ter uma melhor represetatividade desta Perfil da Amostra Ajustada Uma vez excluídos os participates que compõem o 1º Quartil (p(i) 10,0), chega-se a um ovo perfil para a amostra utilizada a aálise. Com o corte, o úmero de participates caiu de 91 para 83, porém, a represetatividade da amostra foi aumetada. No que se refere à experiêcia profissioal, o tempo médio de atuação a área aumetou para 9,6 aos e a mediaa do úmero de projetos que o profissioal participou aumetou para 8 projetos.

7 Tabela 16 - Participates por Área de Atuação Total de Participates 83 Participates com atuação a idústria 54 Participates com atuação a uiversidade 60 Participates com atuação exclusiva a idustria 23 Participates com atuação exclusiva a uiversidade 29 Participates com atuação cocomitate em ambas 31 Tabela 18 - Participação por Atuação em Uiversidade Atuação Professor 23 Pesquisador 14 Cosultor 8 Aluo de Doutorado 11 Aluo de Mestrado 22 Aluo de Graduação 1 Tabela 17 - Participação por Atuação em Empresas Atuação Empresário 5 Gerete de Iformática 2 Gerete da Qualidade 4 Gerete de Projeto 11 Aalista de Sistemas 21 Chefe de Desevolvimeto 2 Cosultor TI 2 Outros 11 Tabela 19 - Participates por Formação Acadêmica Atuação/área Eg. de Software Computação Outro Total /Iformática Doutorado Mestrado Especialização Graduação Total Tabela 20 - Participates por Cohecimeto em PS Cohecimeto Excelete 9 Alto 32 Médio 41 Baixo 1 Nehum 0 Tabela 21 - Participates por experiêcia em PS Experiêcia Excelete 4 Alta 19 Média 38 Baixa 22 Nehuma 0 As potuações calculadas para os participates da amostra ajustada apresetam, agora, a Distribuição de Freqüêcia apresetada o gráfico da Figura 2. Tabela 22 - Quartis Quartis Potuação Valor míimo 11,0 Limite do 1º Quartil 15,0 Limite do 2º Quartil 19,0 Limite do 3º Quartil 24,0 Limite do 4º Quartil 30,0 Figura 2 -Distribuição de Freqüêcia de Potuações Novamete o agrupameto dos especialistas em classes, adotado-se uma potuação úica para todos aqueles que pertecem à mesma classe foi realizado. Os Quartis para a amostra ajustada são mostrados a Tabela 22. Na Tabela 23 são apresetadas as classes defiidas e seus respectivos valores limite, freqüêcia (Qtd.), valor médio e desvio padrão.

8 Tabela 23 - Classes de especialistas Classe Potuação Limite Qtd. Valor Desvio Médio Padrão A Até 15, ,28 1,55 B De 16,0 a 19, ,86 1,09 C De 20,0 a 24, ,46 D Maior que 24, ,16 1,69 Cosiderado-se a Média e o Desvio Padrão de cada classe, pode-se observar que cada uma apreseta um grau razoável de homogeeidade, o que permite cosiderar como ão sigificativa as difereças de pesos existetes etre cada um dos compoetes. Para o cálculo dos pesos a serem atribuídos a cada uma das classes, utilizou-se a primeira classe como referêcia, atribuido-se a ela um peso igual a 1,0. Para as demais classes, seu peso foi calculado em relação ao peso da primeira classe, de acordo com a formula: P ( j) = X ( j) X ( A),ode: P(j) é o peso atribuído à classe j; X(j) é o peso Médio da classe j; X(A) é o peso Médio da classe A. Assim, obtêm-se os pesos de cada classe coforme a tabela Cosolidação dos resultados Tabela 24 - Peso por classe Classe Cálculo do Peso Peso A 1,0 1,00 B 17,86/13,28 1,34 C 22/13,28 1,65 D 27,16/13,28 2,04 Na cosolidação dos resultados, cada voto foi computado de acordo com a classe a que pertece. Para efeito de apresetação dos dados, uma ormalização foi aplicada ao total dos votos de cada questão. As Tabelas 25 a 28 apresetam o resultado da cosolidação. Na Tabela 25 é apresetada a cosolidação da pesquisa para as coseqüêcias de um bom processo de desevolvimeto. As coluas 0, 1 e 2 idicam, respectivamete, que o item sedo avaliado uca está relacioado, às vezes está relacioado ou está muito relacioado. Tabela 25 - Cosolidação dos resultados: Coseqüêcias de um bom processo de desevolvimeto Item Qualidade atigida o produto fial 0,00 0,10 0,90 Croograma previsto atigido 0,00 0,42 0,58 Custos previstos ão ultrapassados 0,01 0,42 0,57 Baixo ídice de retrabalho 0,01 0,23 0,75 Satisfação da equipe 0,06 0,46 0,48 Satisfação do cliete 0,01 0,50 0,49 Alta produtividade da equipe 0,02 0,42 0,56 Produto mauteível 0,02 0,20 0,78 Time-to-market 0,05 0,53 0,42 Cotrole gerecial do projeto 0,00 0,15 0,85 Relação custo/beefício do uso do processo adequada 0,01 0,28 0,71 Riscos gereciados ao logo do processo de desevolvimeto 0,01 0,25 0,74 Qualidade do processo gereciada (desvios e ão coformidades documetados e tratados) 0,01 0,13 0,86 Produtividade da equipe passível de ser medida 0,00 0,33 0,67 Satisfação do usuário 0,05 0,55 0,40 Melhoria da imagem corporativa da orgaização 0,04 0,57 0,39 Aumeto da competitividade da orgaização 0,02 0,48 0,50 Facilidade de adequar-se às mudaças durate o projeto 0,02 0,32 0,66 Facilidade de atualização da documetação 0,03 0,30 0,67

9 Motivação da equipe de desevolvimeto em utilizar o processo 0,00 0,47 0,53 Crescimeto o ível de qualificação dos desevolvedores 0,03 0,37 0,60 Promoção de uma cultura comum a orgaização 0,00 0,20 0,80 Meor impacto por rotatividade de pessoal 0,03 0,40 0,57 A Tabela 26 apreseta a cosolidação da pesquisa para as características de um bom processo de desevolvimeto. As coluas 0, 1 e 2 idicam, respectivamete, que o item sedo avaliado ão tem importâcia, tem alguma importâcia e é muito importate. Tabela 26 - Cosolidação dos resultados: Características de um bom processo de desevolvimeto Item Métodos e técicas adequadas ao projeto 0,00 0,08 0,92 Possuir apoio automatizado 0,04 0,51 0,45 Fácil de ser utilizado 0,00 0,14 0,86 Produzir um volume de documetação adequado ao projeto 0,00 0,36 0,64 Processo bem defiido 0,00 0,04 0,96 Existêcia de diretrizes para execução das atividades do processo 0,00 0,11 0,89 Resposabilidades defiidas 0,00 0,07 0,93 Etrada/saída de atividades defiidas 0,00 0,09 0,91 Template de documetos defiidos 0,04 0,33 0,64 Modelo de ciclo de vida adequado ao projeto 0,00 0,09 0,91 Cotrole da qualidade dos artefatos defiido 0,01 0,16 0,83 Tipos de testes bem defiidos 0,01 0,24 0,75 Forecer cohecimeto de experiêcias em projetos ateriores 0,00 0,43 0,57 Adequação ao tamaho e complexidade do projeto 0,00 0,12 0,88 Adequação ao tipo de projeto (web, software crítico, etc.) 0,01 0,14 0,85 Possuir represetação gráfica (visual) do processo 0,03 0,62 0,35 Apoio à gerêcia do projeto 0,00 0,14 0,86 Estar baseado as melhores práticas da Egeharia de Software 0,01 0,23 0,76 Aderêcia à cultura orgaizacioal 0,01 0,25 0,73 Permitir avaliação e melhoria de processo 0,00 0,18 0,82 Fácil de eteder 0,01 0,11 0,88 Coformidade com ISO ,10 0,63 0,26 Coformidade com CMM 0,05 0,61 0,34 Graularidade adequada ao desevolvimeto de software 0,00 0,31 0,67 Possuir mecaismos para o desevolvedor forecer feedback sobre o processo 0,00 0,26 0,74 Estar alihado aos objetivos de egócio da orgaização 0,00 0,16 0,84 Ter sido defiido cosiderado a realidade atual da orgaização 0,01 0,18 0,81 Estar baseado em expectativas realistas 0,00 0,14 0,86 Fácil de apreder 0,02 0,26 0,73 As Tabelas 27 e 28 apresetam a cosolidação da pesquisa para os aspectos que podem iflueciar positiva e egativamete a utilização do processo de desevolvimeto. As coluas 0, 1 e 2 idicam, respectivamete, que o item sedo avaliado ão tem ifluêcia, tem alguma ifluêcia e tem muita ifluêcia. Tabela 27 - Cosolidação dos resultados: Aspectos que podem iflueciar positivamete a utilização do processo de desevolvimeto Item Equipe experiete 0,02 0,36 0,62 Gerêcia experiete 0,00 0,21 0,79 Bom relacioameto com o cliete 0,09 0,51 0,40 Existêcia de apoio automatizado 0,03 0,48 0,49 Alto comprometimeto da equipe com o projeto 0,00 0,17 0,83 Alto comprometimeto da gerêcia com o projeto 0,00 0,12 0,88 Treiameto formal da equipe o processo 0,01 0,18 0,80

10 Apoio da direção da empresa 0,00 0,09 0,91 Motivação da equipe 0,00 0,18 0,82 Papéis claramete defiidos 0,00 0,12 0,88 Estabilidade da equipe 0,05 0,44 0,51 Existêcia de políticas de icetivo ao uso do processo (ex.: premiações para projetos com meor úmero de desvios / ão-coformidades) 0,07 0,56 0,37 Existêcia de orietações para uso do processo 0,01 0,14 0,84 Apoio à utilização do cohecimeto de experiêcias em projetos ateriores 0,00 0,38 0,62 Ambiete físico de trabalho adequado 0,01 0,47 0,52 Boa ifra-estrutura de apoio (equipametos, software, rede, biblioteca, etc.) 0,00 0,31 0,69 Existêcia de um Grupo de Processo de Egeharia de Software a empresa (SEPG) 0,04 0,45 0,51 Sesibilização a empresa da importâcia do uso do processo 0,00 0,12 0,88 Aderêcia do processo à cultura orgaizacioal 0,00 0,19 0,81 Existêcia de auditorias da aderêcia ao processo 0,02 0,43 0,55 Estimativas realistas para o projeto 0,01 0,16 0,83 Clareza do que pode ser melhorado a orgaização 0,04 0,35 0,62 Seguir rigorosamete uma abordagem de processo (ISO, CMM, etc.) 0,12 0,56 0,32 Ter claro que se quer atigir um ível mais alto de maturidade ou certificação ISO 0,07 0,60 0,33 Iiciar a implatação do processo pelas atividades mais fáceis 0,14 0,62 0,24 Iiciar a implatação do processo pelas atividades mais relevates 0,06 0,34 0,61 Disciplia a implatação das atividades 0,02 0,13 0,85 O processo estar alihado aos objetivos de egócio da orgaização 0,00 0,13 0,87 O processo estar baseado em expectativas realistas 0,00 0,10 0,90 O processo cosiderar a complexidade e o tempo ecessário para mudaças culturais efetivas 0,00 0,25 0,75 Tabela 28 - Cosolidação dos resultados: Aspectos que podem iflueciar egativamete a utilização do processo de desevolvimeto Item Mudaças os objetivos da orgaização 0,00 0,44 0,56 Falta de apoio da direção da orgaização 0,00 0,12 0,88 Perda de atualidade do processo 0,03 0,39 0,57 Iexistêcia de políticas de icetivo ao uso do processo 0,04 0,50 0,46 Equipe do projeto mal dimesioada 0,04 0,33 0,63 Equipe com perfil iadequado ao projeto 0,02 0,18 0,80 Iadequação às características dos desevolvedores 0,01 0,30 0,69 Falta de comuicação etre os membros da equipe 0,02 0,19 0,80 Falta de um bom relacioameto etre os desevolvedores e o gerete 0,02 0,24 0,74 Falta de um evolvimeto cotiuado dos iteressados 0,00 0,22 0,78 Grade úmero de mudaças de requisitos o projeto 0,07 0,36 0,56 Resistêcias à implatação do processo 0,00 0,17 0,83 Não istitucioalização do processo 0,00 0,27 0,73 Alta rotatividade da direção da orgaização 0,09 0,39 0,52 Estimativa de custo/prazo ão realistas 0,01 0,24 0,75 Pouca experiêcia da equipe 0,04 0,57 0,39 Pouca experiêcia da gerêcia 0,02 0,40 0,58 Problemas o relacioameto da equipe 0,02 0,37 0,61 Falta de apoio automatizado 0,07 0,62 0,31 Falta de comprometimeto da equipe 0,00 0,11 0,89 Falta de comprometimeto da gerêcia 0,00 0,02 0,98 Falta de treiameto o processo 0,00 0,19 0,81 Falta de coordeação e lideraça as atividades de implatação 0,00 0,12 0,88 Iadequação às características dos projetos 0,00 0,26 0,74 Descosiderar a complexidade e o tempo ecessário para mudaças culturais efetivas 0,00 0,23 0,77 Não ter claro que se quer atigir um ível mais alto de maturidade ou certificação ISO 0,20 0,61 0,20 Alta rotatividade de desevolvedores 0,08 0,42 0,51

11 Alta rotatividade de geretes 0,02 0,31 0,67 5. Aálise dos resultados Os resultados apresetados a seção aterior foram muito iteressates, por torar claras as cocepções que a idústria e academia têm em relação a processos de desevolvimeto de software. Como veremos a seguir, algumas estão de acordo com o que foi evideciado em estudos ecotrados a literatura. Em outras, percebem-se cotradições. No primeiro subgrupo de ites: Coseqüêcias de um bom processo de desevolvimeto, pôde-se idetificar o que a comuidade acredita serem os pricipais resultados que um bom processo de desevolvimeto é capaz de atigir. O resultado mostra que se acredita que a maior coseqüêcia é a Qualidade atigida o produto fial, estado de acordo com a evidêcia da forte relação etre a qualidade do produto fial e a qualidade do processo utilizado. Segudo FLORAC e CARLETON [9], para melhorar a qualidade deve-se focar os processos que geram os produtos e serviços. A próxima coseqüêcia mais bem avaliada foi a Qualidade do processo gereciada (desvios e ão coformidades documetados e tratados). Esta avaliação mostra a compreesão de que quato melhor um processo, melhor a sua gerêcia de qualidade. Em terceiro lugar apresetou-se a cosequêcia: Cotrole gerecial do projeto. Isto deota a cocepção de que um bom processo de desevolvimeto de software auxilia sobremaeira a gerêcia dos vários fatores evolvidos em um projeto de software. PFLEEGER [10] apóia as avaliações ateriores ao defiir que quato maior a maturidade do processo, maior a sua visibilidade, forecedo um cojuto mais rico de iformações e um melhor etedimeto do mesmo. De acordo com os participates da pesquisa, o meor resultado obtido com a implatação de um bom processo de desevolvimeto de software é a Melhoria da imagem corporativa da orgaização. E a seguda coseqüêcia foi a Satisfação do usuário. Estes dois resultados demostram uma ão compreesão da iterdepedêcia dos vários efeitos que um bom processo de desevolvimeto de software pode gerar, pois os mesmos participates elegeram a Qualidade atigida o produto fial como sedo a maior cosequêcia de um bom processo. Porém se uma orgaização melhora o seu produto fial, melhorará também a satisfação dos seus usuários, melhorado a imagem corporativa da orgaização o mercado. Time-to-market, ou seja, a rapidez em colocar um ovo produto ou versões o mercado foi a terceira coseqüêcia meos cosiderada. A avaliação deste item está em desacordo com algus trabalhos da literatura que mostram a importâcia de um bom processo para o aumeto da produtividade e dimiuição do retrabalho, que estão itimamete relacioados à velocidade de etrega de produtos ao mercado. Algo que pode ter acotecido é o item ter sido mal compreedido pelos participates da pesquisa. Além disto, podem ter raciociado que uma empresa, apesar de ão ter um bom processo, pode coseguir colocar seus produtos em tempo hábil o mercado, mesmo em detrimeto da qualidade do produto. Outro subgrupo apreseta o que a comuidade cosidera serem características de um bom processo de desevolvimeto, ou seja, os critérios e seus valores que podem classificá-lo como um bom processo. A pricipal característica cosiderada foi Processo bem defiido, evideciado que os participates da pesquisa acreditam que para um processo de desevolvimeto ser bom de se utilizar, deve ser defiido criteriosamete. Segudo GRUHN [11], uma boa modelagem de um processo de software é fudametal para facilitar a sua implatação e utilização.

12 A seguda característica melhor avaliada foi Resposabilidades defiidas. Há um etedimeto da importâcia das resposabilidades estarem claramete defiidas. EMAM [12] destacou que um dos elemetos mais importates para a ifra-estrutura de um processo é ter as resposabilidades bem defiidas, cofirmado a avaliação realizada. A característica Métodos e técicas adequadas ao projeto foi a terceira melhor avaliada. Esta característica diz respeito à existêcia de difereças etre projetos e da ecessidade de tratá-los de forma diferete. OLIVEIRA [13] defie como um dos passos para a defiição de um processo de software, idetificar os métodos e ferrametas utilizadas a orgaização para o tipo de software a ser desevolvido. LEUNG e YUEN [14] realçaram esta importâcia ao apresetarem um relato de experiêcia de uma empresa em Hog Kog que começou por defiir um processo padrão para todos os projetos da orgaização, apesar de 80% dos seus projetos serem pequeos. Observou-se depois a ecessidade de adaptar o processo padrão para pequeos projetos, pois estava havedo um aumeto das atividades admiistrativas e de documetação. As próximas duas características melhor avaliadas foram: Modelo de ciclo de vida adequado ao projeto e Etrada/saída de atividades defiidas. Estas dizem respeito à importâcia da escolha de um modelo de ciclo de vida adequado ao projeto, que é uma das decisões mais difíceis de serem tomadas, e à relevâcia do processo de desevolvimeto defiir claramete os artefatos de etrada e saída para cada atividade. As características com avaliação mais baixa, em ordem decrescete, foram: Coformidade com ISO 9000, Coformidade com CMM e Possuir represetação gráfica (visual) do processo. Este resultado mostra que a comuidade ão cosidera ser relevate para a qualidade de um processo de desevolvimeto estar em coformidade com as ormas ISO 9000 e CMM, ormas estas desevolvidas por orgaizações de reome e cuja certificação ou atestado está sedo buscado, cada vez mais, pelas empresas em âmbito iteracioal. Para HEFNER e TAUSER [15] é estrategicamete importate defiir claramete os objetivos da orgaização, ão tedo como pricipal objetivo apeas coseguir mais um ível de maturidade. MESSNARZ [16] destacou que as orietações dadas pelas metodologias para avaliações, tipo CMM, em sempre estão de acordo com os objetivos da empresa. Cosiderou-se, também, que ter uma represetação gráfica de um processo ão sigifica ecessariamete que este é bom. O terceiro subgrupo a ser aalisado cotém os aspectos que podem iflueciar positivamete a utilização de um processo de desevolvimeto. Com isto buscou-se cohecer os aspectos que estão muito relacioados ao sucesso da utilização de um processo. O aspecto cosiderado como mais importate foi o Apoio da direção da empresa. Acredita-se, portato, que o evolvimeto da alta direção é extremamete relevate para a utilização do processo de software em uma orgaização, o que cofirma a literatura. O segudo aspecto idetificado como de muita relevâcia foi O processo estar baseado em expectativas realistas. Costatou-se que a comuidade acredita que um processo deve ser defiido especificamete para uma orgaização, baseado-se em expectativas que estejam detro do real e do possível. FLORAC e CARLETON [9] compactuaram deste argumeto ao dizerem que quado da defiição, implemetação e mauteção de um processo de software, deve-se garatir que a empresa tem habilidade para executar e mater os processos. Os aspectos: Alto comprometimeto da gerêcia com o projeto, Papéis claramete defiidos e Sesibilização a empresa da importâcia do uso do processo, ficaram empatados como terceiro aspecto mais importate. Evidecia-se a importâcia que é dada ao comprometimeto do gerete de um projeto com o processo de desevolvimeto de software, bem como a compreesão, por parte da equipe do projeto, da relevâcia para um projeto de

13 software em seguir um processo de desevolvimeto. O outro aspecto mostrou ser cosiderado importate para a utilização do processo: ter cada um dos participates cohecimeto claro de seus papéis. KALTIO e KINNULA [17] destacaram a relevâcia de sesibilizar a empresa a respeito da importâcia de se utilizar processos de software, ao apresetarem um estudo de caso ocorrido a empresa Nokia Mobile Phoes Ltd. ode o último elemeto do framework de implatação do processo de desevolvimeto foi a atividade de promoção do processo, que foi fudametal para o sucesso do projeto de implatação. Os três aspectos cosiderados como os que têm meos ifluêcia positiva a utilização do processo foram: Iiciar a implatação do processo pelas atividades mais fáceis, Seguir rigorosamete uma abordagem de processo (ISO, CMM, etc.) e Ter claro que se quer atigir um ível mais alto de maturidade ou certificação ISO. A comuidade cosiderou como ão sedo relevate iiciar pelas atividades mais fáceis e em seguir rigorosamete uma abordagem de avaliação de processo. Além disto, ão se viu muita relação etre a facilidade de utilizar um processo de desevolvimeto com a clareza em atigir um ível mais alto de maturidade ou certificação ISO. CATTANEO et al. [18] cofirmaram a pequea ifluêcia do item Seguir rigorosamete uma abordagem de processo (ISO, CMM, etc.) a utilização de um processo, ao descreverem a experiêcia de uma empresa em que ão foi suficiete usar apeas o CMM, sedo importate aalisar, detalhadamete, os problemas orgaizacioais e estratégicos da empresa. O último subgrupo diz respeito aos aspectos que podem afetar egativamete a utilização do processo de desevolvimeto, ou seja, aqueles fatores que devem ser bem gereciados para que a equipe utilize bem e de forma adequada o processo implatado. O aspecto cosiderado mais crítico foi o Falta de comprometimeto da gerêcia, mostrado que os participates da pesquisa cosideram que o fato da gerêcia ão estar comprometida com o processo como sedo o maior risco para o sucesso da sua utilização. O segudo aspecto cosiderado crítico foi Falta de comprometimeto da equipe. Este resultado mostra a importâcia do comprometimeto com o processo, daqueles que fazem parte do projeto. HEFNER e TAUSER [15] cofirmaram a relevâcia do comprometimeto da equipe ao destacarem o cuidado que a gerêcia deve ter a fase de execução do processo, para ão dificultar o evolvimeto dos participates e para ão egligeciar a ecessidade de treiametos. Os aspectos Falta de apoio da direção da orgaização e Falta de coordeação e lideraça as atividades de implatação também foram tidos como iflueciado bastate egativamete a utilização do processo. Estes dizem respeito à importâcia da direção da orgaização apoiar a utilização de processos e de a atividade de implatação do processo em um projeto, ser bem coordeada e liderada. Os três aspectos cosiderados como de meor risco para o sucesso a utilização de um processo de software foram: Não ter claro que se quer atigir um ível mais alto de maturidade ou certificação, Falta de apoio automatizado e Pouca experiêcia da equipe. Estes resultados sigificam que os participates cosideram que, ão ter claro que se quer atigir um ível maior de maturidade ou certificação ISO e cotar com uma equipe pouco experiete tem pouco efeito egativo a utilização do processo. Além disto, a falta de apoio automatizado ao processo também ão é um fator de muita ifluêcia egativa para a sua utilização. A visão de EMAM [12] em relação ao item Pouca experiêcia da equipe é cotrária ao resultado da pesquisa, já que o autor ressalta a ecessidade de se dispor de pessoal competete para a ifra-estrutura de um processo. FLORAC e CARLETON [9] também têm a mesma

14 opiião ao defiirem como sedo, pessoal mal treiado, uma das causas que podem iterferir a variação de um processo. 6. Coclusões e trabalhos futuros Este trabalho apresetou o resultado de uma pesquisa, caracterizado cocepções que a idústria e a academia, o cotexto brasileiro, têm em relação a processos de desevolvimeto de software. Com isto, torou-se possível compreeder as possíveis motivações que estão por trás de um projeto de implatação e melhoria de processos de software, bem como as características de qualidade de um processo e os aspectos que podem iflueciar positiva ou egativamete a utilização deste processo. Observou-se que, para implatar e utilizar um processo de software é ecessário cosiderar vários fatores, cohecer o peso de cada um deles e o tipo de relações existetes etre eles. Com isto, pode-se obter um direcioameto melhor que ajude a ter mais sucesso a sua utilização, auxiliar a admiistração dos pricipais riscos evolvidos a utilização do processo, bem como cohecer os possíveis resultados de uma melhoria. Além disto, pode ajudar a priorizar as melhorias a serem implatadas, baseado-se os pesos de cada fator. Como trabalhos futuros, espera-se realizar outra pesquisa que possibilite idetificar as relações etre os diversos ites que foram idetificados, quatificado a força da relação, bem como o grau de icerteza, de modo a gerar um diagrama de ifluêcias que auxilie a costrução de modelos de simulação a serem implemetados em uma ferrameta. Com isto, buscar-se-á apoiar, de forma mais simples, os geretes de projetos a ateciparem possíveis tedêcias durate o processo e a priorizar as melhorias a serem implatadas o processo de desevolvimeto. Agradecimetos Os autores agradecem ao CNPq e a CAPES pelo apoio fiaceiro ao projeto. Agradecem também a todos os participates da pesquisa e a Mauro Oddo Nogueira. Referêcias 1. REED, K., 2000, Software egieerig a ew milleium?, IEEE Software, July- August. 2. MCT/SEPIN Secretaria de Política de Iformática e Automação / Miistério da Ciêcia e Tecologia, 2002, Qualidade e Produtividade o Setor de Software Brasileiro 2001 /.4., Brasília. 3. PAULK, M. C., CURTISS, B., CHRISSIS, M. B., WEBER, C. V., 1993, Capability Maturity Model for Software, Versio 1.1, Pittsburgh, Software Egieerig Istitute. 4. ZAHRAN, S., 1997, Software Process Improvemet Practical Guidelies for Busiess Success; Addiso-Wesley. 5. ISO/IEC 12207, 1995, ISO/IEC Iformatio techology software life cycle, Iteratioal Stadard Orgaizatio. 6. ISO 9000, 2000, Quality Maagemet Systems Fudametal ad Vocabulary. 7. FARIAS, L. L., 2002, Plaejameto de Riscos em Ambietes de Desevolvimeto de Software Orietados à Orgaização, Tese de M.SC., COPPE/UFRJ, Rio de Jaeiro, Brasil.

15 8. NOGUEIRA, M. O., ROCHA, A. R., 2003, Práticas Relevates em Egeharia de Software: uma avaliação de especialistas, II Simpósio Brasileiro de Qualidade de Software, Fortaleza, CE, Brasil. 9. FLORAC, W., CARLETON, A. E., 2000, Measurig the Software Process: Statistical Process Cotrol for Software Process Improvemet, Addiso-Wesley. 10. PFLEEGER, S. L., 2000, Improvig Predictios, Products, Processes ad Resources, I: Software Egieerig, cap.13, pp GRUHN, V., 2000, Software Process Ladscapig, Software Process: Improvemet a Practice, 5: EMAM, K. E., 2001, Software Egieerig Process, i IEEE - Trial Versio. 13. OLIVEIRA, K. M., 1999, Modelo para Costrução de Ambietes de Desevolvimeto de Software Orietados a Domíio, Tese de D.SC., COPPE/UFRJ, Rio de Jaeiro, RJ, Brasil. 14. LEUNG, H. K. N., YUEN, T. C. F., 2001, A Process Framework for Small Projects, Software Process: Improvemet a Practice, 6: HEFNER, R., TAUSER, J., 2001, Thigs They Never Taught You i CMM School, 26th Aual NASA Goddard Software Egieerig Workshop, November, pp MESSNARZ, R., 1999, Road map for Readers ad How to Use the Book, I: Richard Messarz ad Coli Tully (eds.), Better Software Practice for Busiess Beefit: Priciples ad Experiece, IEEE Computer Society, cap1, pp KALTIO, T., KINNULA, A., 2000, Deployg the Defied SW Process, Software Process: Improvemet ad Practice, 5: CATTANEO, F., FUGGETA, A., SCIUTO, D., 2001, Pursuig Coherece i Software Process Assessmet ad Improvemet, Software Process: Improvemet ad Practice, 6:3-22.