FACULDADE DE TECNOLOGIA DE ITAQUAQUECETUBA

RODNEY SANTOS DE MOURA

GERNCIA DE CONFIGURAO: APRESENTAO DE PRTICAS, MODELOS E NORMAS PARA A GARANTIA DE QUALIDADE NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

ITAQUAQUECETUBA 2012

FACULDADE DE TECNOLOGIA DE ITAQUAQUECETUBA

RODNEY SANTOS DE MOURA

GERNCIA DE CONFIGURAO: APRESENTAO DE PRTICAS, MODELOS E NORMAS PARA A GARANTIA DE QUALIDADE NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Trabalho de Concluso de Curso apresentado ao curso de Informtica para a Gesto de Negcios da Faculdade de Tecnologia de Itaquaquecetuba como parte de requisitos para a concluso de curso, sob a orientao do Professor Me. Csar Torres Fernandes.

ITAQUAQUECETUBA 2012

FICHA CATALOGRFICA

Moura, Rodney Santos de, 1990. Gerncia de Configurao: Apresentao de prticas, modelos e normas para a garantia de qualidade no processo de desenvolvimento de software / Rodney Santos de Moura Itaquaquecetuba, So Paulo, 2012. 94 f. : il. (algumas col.); 30 cm. Trabalho de Concluso de Curso Faculdade de Tecnologia de Itaquaquecetuba (FATEC), Curso de Informtica para a Gesto de Negcios, 2012. Orientador: Prof. Me. Csar Torres Fernandes. 1. Gerncia de Configurao de Software 2. Qualidade de Software 3. Desenvolvimento de Software 4.Gerencia de Projetos. I. Faculdade de Tecnologia de Itaquaquecetuba. Curso Informtica para a Gesto de Negcios. II. Gerncia de Configurao de Software: Apresentao de prticas, modelos e normas para a garantia de qualidade no processo de desenvolvimento de software.

RODNEY SANTOS DE MOURA GERNCIA DE CONFIGURAO: APRESENTAO DE PRTICAS, MODELOS E NORMAS PARA A GARANTIA DE QUALIDADE NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Trabalho de Concluso de Curso apresentado ao curso de Informtica para a Gesto de Negcios da Faculdade de Tecnologia de Itaquaquecetuba como parte de requisitos para a concluso de curso, sob a orientao do Professor Me. Csar Torres Fernandes.

Aprovado em ______________

BANCA EXAMINADORA

Prof. Faculdade de Tecnologia FATEC Itaquaquecetuba

Prof. Faculdade de Tecnologia FATEC Itaquaquecetuba

Prof. Faculdade de Tecnologia FATEC Itaquaquecetuba

ITAQUAQUECETUBA 2012

Dedico a minha famlia, pai Edison, me Aminadabe, e meus irmos Evelyn e Edson. Como tambm aos meus avs paternos e maternos. Pessoas que me apoiaram e ajudaram nos momentos que mais precisei de auxilio e motivao.

AGRADECIMENTOS
Agradeo primeiramente a Deus, por ter se mostrado presente na minha vida e ter tido misericrdia para comigo e ter feito conhecer seu caminho. Por ter me ajudado no desenvolvimento deste trabalho, concedendo o conhecimento e experincia necessria a respeito do tema abordado. A minha famlia, que mesmo distante por alguns quilmetros, sempre que precisei de um apoio e motivao estavam ao meu lado. Aos meus avs e tios, sempre que possvel me deram auxilio e apoio. Aos entrevistados, da empresa ALSTOM e o Mandrado do setor de Centro de Processamento de Dados da Polcia Militar do Estado de So Paulo, que responderam o questionrio, contribuindo para a realizao do estudo de caso contido neste trabalho. Aos funcionrios do setor Centro de Pesquisas da instituio de ensino FATEC (Faculdade de Tecnologia) de So Paulo, responsveis por contribuir, durante o perodo em que trabalhei l, desde 2009 a 2011, para o conhecimento e experincia adquirida em diversas reas de um ambiente de Tecnologia de Informao. Aos amigos e companheiros de trabalho na mapaBRASIL que sempre me proferiram palavras de nimo e apoio a respeito do tema escolhido e ramo de pesquisa. A todos os amigos que de forma geral sempre me animaram para a concluso deste trabalho.

Do homem so as preparaes do corao, mas do Senhor a resposta da boca. Todos os caminhos do homem so limpos aos seus olhos, mas o Senhor pesa os espritos. Confia do Senhor as tuas obras, e teus pensamentos sero estabelecidos. (Provrbios, 16:1;2;3)

RESUMO
O presente trabalho de pesquisa teve por objetivo apresentar as atividades e tarefas da Gesto de Configurao de Software, e investigar qual a importncia apresentada pelos principais modelos e normas, de desenvolvimento e qualidade de software, reconhecidos nacional e internacionalmente. O trabalho tambm se utilizou do mtodo de estudo de caso para descobrir se com a aplicabilidade da GCS possvel minimizar problemas intrnsecos ao processo de fabricao do software, fornecendo suporte aos gerentes e desenvolvedores para isso, e garantir a qualidade do produto final entregue ao cliente. Dos resultados obtidos pelas respostas do questionrio, enviado a empresa ALSTOM e ao Centro de Processamento de Dados da instituio Policia Militar do Estado de So Paulo, foi observada que a aplicabilidade da GC trouxe benefcios antes invisveis, maior eficincia ao processo de desenvolvimento e efeitos positivos s equipes. Os entrevistados ressaltaram a importncia dessa gesto por estar presente, com atividades e tarefas de acompanhamento e monitoramento, em todo o ciclo de vida de um software, garantindo que as funcionalidades estaro de acordo com os requisitos levantados baseado na auditoria da GCS, produzindo tambm efeito na reduo de retrabalhos, funcionalidades entregues no prazo por existir um controle da CCC em analisar a viabilidade de funcionalidades, e reduo de esforos desnecessrios devido ao monitoramento e controle contnuo da gesto. PALAVRAS-CHAVE: Gerncia de Configurao de Software, Qualidade de Software, Desenvolvimento de Software, Gerencia de Projetos.

ABSTRACT
The current research work had, as purpose of matter, presented tasks and activities of Software Configuration Management, and investigated the importance shown by the main models and regulations of software quality and development, with national and international acknowledgment. The work also used the case study research method do find out if the SCM applicability works for minimizing problems within the software development process, giving support for managers and developers, and to guarantee outcome quality for customer delivery. With the results achieved from the answers of a questionnaire, send to ALSTOM Company and to the Data Process Center of the Military Police of the State of So Paulo, it was observed that the use of SCM gave benefits that seemed invisible before, like higher efficiency to the development process and positive gains to the teams involved. The respondents highlighted the importance of this management for its presence in activities and tasks of attendance and monitoring in all software's life-cycle, ensuring that the functionalities will agree with the collected requirements on a SCM auditing, also producing effects on refactoring reduction, functionalities delivered on time due to CCC control on functionalities feasibility analysis, and reduction of unnecessary effort due to the continuous monitoring and control's management. KEY-WORDS: Configuration Management Software, Software Quality, Software Development, Project Management

LISTA DE ABREVIATURAS E SIGLAS

ABNT Associao Brasileira de Normas Tcnicas CCC Comisso de Controle de Configurao CCS Comisso de Configurao de Software CMM Capability Maturity Model (Modelo de Capacitao e Maturidade) CMMI Capability Maturity Model Integration (Integrao dos Modelos de Capacitao e Maturidade) CPD Centro de Processamento de Dados IEC International Eletrotechnical Commission (Comisso Internacional Eletrotcnica) IEEE - Institute of Electrical and Electronics Engineers (Instituto de Engenharia Eltrica e Eletrnica) ISO - International Organization for Standardization (Organizao Internacional de Padronizao) SPICE - Software Process Improvement and Capability dEtermination (Melhoria de Processo de Software e Determinao de Capacidade) GC Gerncia de Configurao de Software GCS Gerncia de Configurao de Software GIT Sistema de Controle de Verses GIT MCT Ministrio da Cincia e Tecnologia SEPIN - Secretaria de Poltica de Informtica MPS.BR - Melhoria do Processo de Software Brasileiro PMESP Polcia Militar do Estado de So Paulo SEI Software Engineering Institute (Instituto de Engenharia de Software) SOFTEX - Sociedade e Ncleo de Apoio a Produo e Exportao de Software SW Software

SUMRIO
INTRODUO...................................................................................................................................... 12 DELIMITAO DO TEMA.................................................................................................................... 13 PROBLEMATIZAO.......................................................................................................................... 13 JUSTIFICATIVA.................................................................................................................................... 14 OBJETIVO GERAL............................................................................................................................... 14 OBJETIVOS ESPECFICOS................................................................................................................ 14 HIPTESE........................................................................................................................................... 15 ORGANIZAO DO TRABALHO......................................................................................................... 15 Captulo 1............................................................................................................................................. 16 FUNDAMENTAO TERICA............................................................................................................ 16 1.1.Engenharia de Software................................................................................................................. 16 1.2.Processo de Desenvolvimento....................................................................................................... 18 1.3.Manuteno do Software................................................................................................................ 19 1.4.Qualidade de Software................................................................................................................... 20 Captulo 2............................................................................................................................................. 23 Gerncia de Configurao de Software................................................................................................23 2.1. A Gesto Especfica...................................................................................................................... 23 2.2. Histria e evoluo de GCS........................................................................................................... 26 2.3. Atividades da Gerncia de Configurao de Software..................................................................28 Captulo 3............................................................................................................................................. 42 Gerncia de Configurao de Software nos principais modelos e padres..........................................42 3.1. CMM verso 1.1............................................................................................................................ 44 3.2. CMMI............................................................................................................................................. 48 3.3. MPS.BR......................................................................................................................................... 54 3.4. ISO 15504 (SPICE)....................................................................................................................... 58 3.5. Padro ISO 9000........................................................................................................................... 62 Captulo 4............................................................................................................................................. 65 METODOLOGIA DE PESQUISA ESTUDO DE CASO......................................................................65 4.1. Caractersticas Gerais da Pesquisa............................................................................................... 65 4.2. Empresas Objetos da Pesquisa..................................................................................................... 67 4.3. Dificuldades Encontradas.............................................................................................................. 69 Captulo 5............................................................................................................................................. 71 ANLISE E DISCUSSO DOS RESULTADOS...................................................................................71 5.1. Questionrio.................................................................................................................................. 71 5.2. ALSTON........................................................................................................................................ 72 5.3. CPD da PMESP............................................................................................................................. 76 5.4. Comparao dos Dados................................................................................................................ 80 Captulo 6............................................................................................................................................. 83 CONSIDERAES FINAIS.................................................................................................................. 83 REFERNCIAS.................................................................................................................................... 85 APNDICE........................................................................................................................................... 90 APNCICE A........................................................................................................................................ 91

12

INTRODUO
A partir de meados dos anos 60, surgiu a expresso crise do software, que demonstrava um grande problema no processo de desenvolvimento e manuteno de softwares. Perodo em que houve uma crescente demanda por programas de computador cada vez mais complexos, devido importncia que o mundo dos negcios percebeu que o software poderia trazer. Sendo considerada a indstria de softwares um dos fatores dominantes no mundo dos negcios. Mas um dos fatores mais crticos que determinou essa expresso crise do software foi a falta de qualidade nos produtos produzidos pelas fbricas de software. Para resolver os problemas ocorrentes nessa poca em relao aos produtos de software e suas incertezas tanto s empresas desenvolvedoras como aos clientes surgiu em meados dos anos 70 a Engenharia de Software com o objetivo de estabelecer processos e mtodos para o desenvolvimento e manuteno para produo de softwares de qualidade. Qualidade objeto de desejo por todos os envolvidos na produo de um software, sejam eles desenvolvedores ou clientes, tanto no processo de fabricao como em uso depois de pronto, atendendo especificaes, sem falhas e erros. A Gerncia de Configurao um dos pilares na Engenharia de Software para adquirir um processo controlado no desenvolvimento e manuteno do software, apoiando equipes de desenvolvimento na soluo de problemas inerentes as atividades de produo e manuteno, atravs de atividades que cobrem todo o ciclo de vida do software, sendo considerado por Pressman (2006) uma das atividades guarda-chuva da Engenharia de Software, para aquisio de qualidade no produto desenvolvido, mantendo a integridade e confiabilidade do software. A GCS responsvel por controlar a evoluo do software, pois um software sempre est em constante mutao, e existem diversos fatores para que ele esteja sempre mudando, se tornando complexo manter um software, pois existe uma grande quantidade de artefatos e itens que so criados e que quando no so controlados pode tornar o processo de desenvolvimento e manuteno um verdadeiro caos. O objetivo principal controlar, acompanhar e documentar a evoluo das mudanas durante seu desenvolvimento.

13

Atualmente existem normas nacionais e internacionais e modelos em que a Gesto de Configurao est inclusa e um dos fatores principais de sucesso para obteno de qualidade tanto no processo de fabricao como no resultado final do produto ao cliente.

DELIMITAO DO TEMA
O trabalho de pesquisa proposto tem por objetivo apresentar prticas, modelos e normas de Gerncia de Configurao, gesto especfica dentro da Engenharia de Software que aplicado em organizaes de desenvolvimento, proporcionam benefcios s equipes de desenvolvimento, aos gerentes de projetos e garante a integridade e controle sob todas as alteraes do software durante todo o ciclo de vida de desenvolvimento do projeto. GCS garante a qualidade do software e que os projetos entregues estaro atendendo requisitos estabelecidos e que todos os seus itens estejam devidamente identificados e documentados.

PROBLEMATIZAO
A problemtica apresentada neste trabalho envolve a complexidade que se torna desenvolver e dar manuteno ao software durante a evoluo de suas partes integrantes. Sendo que a ocorrncia de alteraes so inevitveis e com o tempo se torna difcil manter um software em que no possvel saber qual verso est sendo usada, qual as ltimas alteraes, os motivos das mudanas, documentao das modificaes e do projeto, controle das alteraes em relao aos seus impactos e reais necessidades. Problemas que pode fazer do processo de manuteno uma etapa complexa e difcil no garantindo ao cliente e usurio a integridade e confiabilidade do produto entregue e colocado em funcionamento. A questo que levou ao estudo e desenvolvimento deste trabalho : Como a Gerncia de Configurao de Software pode colaborar com gerentes de projetos e equipes de desenvolvimento a garantir a qualidade do projeto a ser entregue ao cliente?

14

JUSTIFICATIVA
De acordo com Pressman (1995), no decorrer do desenvolvimento de um software so inevitveis a ocorrncia de diversas alteraes. Alteraes de novas condies de negcios e de mercado, novas necessidades de clientes, so mudanas que impactam nas informaes produzidas pelo software, prioridades do software, na estrutura do time de desenvolvimento e nas regras de negcio. Se essas modificaes no tiverem um controle adequado, ou seja, pela GCS, podem causar consequncias em outras partes existentes, no estando em conformidade com os requisitos, consequentemente interferindo no cronograma e elevando custos no ciclo de vida do sistema. O desenvolvimento deste trabalho pode contribuir, por meio de pesquisas bibliogrficas e utilizao do mtodo de estudo de caso em empresas que desenvolvem e manutem softwares, na soluo de problemas intrnsecos ao software, como: tempo de entrega do produto, custo, sua integridade e principalmente continuar atendendo aos requisitos esperados pelo cliente.

OBJETIVO GERAL
Demonstrar como a adoo de Mtodos e Prticas para utilizao de Gerncia de Configurao de Software, em empresas que desenvolvem sistemas, pode apoiar gerentes de projetos, analistas de sistemas, equipes no processo de fabricao de projetos de softwares na resoluo de problemas intrnsecos, ou seja, relacionados ao controle da evoluo do produto ao longo da fabricao do projeto ou manuteno do mesmo, no afetando ao cronograma e garantindo que o resultado esteja de acordo com os requisitos.

OBJETIVOS ESPECFICOS
Apresentar de forma clara o que a Gerncia de Configurao de Software, quais os objetivos de sua aplicao e quais so as atividades e tarefas contidas no processo da GC. Descrever os modelos e padres de qualidades de software em que a Gesto est presente.

15

Analisar como este controle de mudanas no ciclo de vida de softwares pode apoiar gerentes de projetos e equipes de desenvolvimento.

HIPTESE
Por meio da Gesto de mudanas possvel garantir a qualidade do produto entregue ao cliente. A mudana constante, enquanto o sistema no for descartado e estiver sendo necessrio realizar mudanas, a GC estar trabalhando para que essas alteraes no impactem o que foi desenvolvido e est funcionando, verificando se realmente essas alteraes so necessrias e se realmente atendero as necessidades esperadas. Essa gesto especfica na Engenharia de software se utiliza de modelos, mtodos e ferramentas. A adoo da GCS pode trazer alguns benefcios como: - Facilidades para acomodar mudanas; - Maior controle sobre os produtos; - Economia de tempo de desenvolvimento de software.

ORGANIZAO DO TRABALHO
No primeiro captulo realizada a fundamentao terica do trabalho, mostrando as origens das necessidades de se aplicar mtodos e procedimentos a fim de buscar qualidade no processo de desenvolvimento e manuteno de softwares e citando a utilizao da Gerncia de Configurao. No segundo captulo apresentado a Gerncia de Configurao de Software, abordando alguns conceitos inerentes, sua histria, o motivo da existncia de GCS, identificar e analisar os processos e tarefas envolvidos. O captulo trs tem por objetivo identificar as principais normas nacionais e internacionais e modelos em que a Gesto de Configurao est presente, averigu-las e mostrar seu funcionamento. J no captulo quatro apresentada a metodologia de pesquisa utilizada por este trabalho para acolhimento de dados necessrios para posteriormente o desenvolvimento de anlises. No quinto captulo apresentado os resultados de anlise realizadas em empresas que desenvolvem softwares, mostrando os benefcios da aplicabilidade da GCS. E, finalmente, o captulo seis apresenta as consideraes finais do trabalho.

16

Captulo 1
FUNDAMENTAO TERICA
Neste captulo so apresentados alguns dos principais conceitos tericos necessrios para contextualizao do trabalho e maior visibilidade do que se pretende mostrar com essa pesquisa. O captulo iniciado com a apresentao da Engenharia de Software que a base para todas as disciplinas existentes que tangem o processo de fabricao do software. Apresentando ainda nos tpicos dois e trs os processos de desenvolvimento e manuteno de software, reas de grande importncia. E no ltimo tpico o principal objetivo a ser alcanada pela utilizao de uma disciplina especfica, qualidade de software.

1.1. Engenharia de Software

Engenharia de Software uma rea de conhecimento da informtica, que composto de processos, mtodos e ferramentas para o desenvolvimento de softwares de qualidade (PRESSMAN, 2006). rea responsvel por tudo que conhecido atualmente no aspecto de fabricao de software. Os princpios utilizados pela Engenharia de Software, como seu prprio nome demonstra, so os de engenharia que indica anlise, construo e manuteno. Software, programa de computador, sistema, aplicao, produto ou projeto sero com muita frequncia abordada no decorrer deste trabalho, o qual tem o mesmo significado. um conjunto de instrues que quando executadas, interagindo com os dados de entrada passados pelo usurio ou no, geram informaes, aes e efeitos desejados no meio em que est inserido. Transformando atividades manuais em instrues de computador, a fim de agilizlos e apoiar o homem em atividades complexas suscetveis a erros, sendo mais precisos. Executam vrias aes em intervalos menores, substituindo at o homem em determinadas funes, tornando-se algo primordial nas organizaes para sucesso dos negcios.

17

Outra palavra que ser muito usada processo, compreendido como o conjunto de recursos e atividades inter-relacionadas, conjunto de atividades, mtodos, prticas e tecnologias que os desenvolvedores utilizam para desenvolver ou manter o software, pelas quais um produto passa at ficar pronto, com o objetivo de que o resultado seja de qualidade. A definio de Fritz Bauer para Engenharia de Software (PRESSMAN, 2006, p. 17), O estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e que funcione eficientemente em mquinas reais. Uma definio mais abrangente por IEEE para Engenharia de Software (PRESSMAN, 2006, p. 17), aplicao de uma abordagem sistemtica, disciplinada e quantificvel para o desenvolvimento, operao e manuteno do software, isto , a aplicao da engenharia ao software. A Engenharia de Software surgiu em meados da dcada de 70, a fim de estabelecer uma estrutura formalizada a ser seguida na produo do software, para resolver problemas que ocorriam nesse perodo, e incertezas em relao ao software tanto as empresas desenvolvedoras de software como aos clientes por falta de qualidade. Na dcada de 60, surgiu uma expresso que demonstrava esses problemas ocorrentes, denominada crise do software, porque os softwares produzidos no satisfaziam os requisitos dos envolvidos (clientes, usurios e desenvolvedores), no atendiam cronogramas, grande volume de falhas e custos excedentes ao combinado.

Figura 1 Engenharia de Software em camadas (PRESSMAN, 2006, p. 24).

Pressman (2006) afirma que a base em que qualquer abordagem de engenharia de software deve se apoiar e ter compromisso com a qualidade, como apresentado na figura acima, todas as abordagens desenvolvidas devem ser

18

baseadas em um processo contnuo de aperfeioamento. O objetivo da ES a busca de um processo de desenvolvimento em que o componente mais importante a Qualidade. Pressman (2006) afirma ainda que na Engenharia de Software existem algumas atividades, denominadas por ele como atividades guarda-chuva, que so aplicveis em todos os projetos de software independentemente de seu tamanho ou complexidade, que segundo ele so pontos de garantia de qualidade. E dentre essas atividades, est a Gerncia de Configurao de Software, o qual ser tratado com mais detalhes no prximo captulo. Gesto responsvel em apoiar as esquipes de desenvolvimento e seus envolvidos na soluo de problemas que podem ocorrer durante o processo de desenvolvimento e manuteno de software, mantendo sua integridade e confiabilidade, garantindo qualidade tanto no processo de fabricao do produto como na garantia de qualidade do software a ser entregue ao cliente.

1.2. Processo de Desenvolvimento

No processo de desenvolvimento de software, existem trs fases genricas, independentemente do paradigma de ciclo de vida, da rea de aplicao, tamanho do projeto ou complexidade, devem ser realizadas: definio, desenvolvimento e manuteno (PRESMAN, 1995). Paradigma de ciclo de vida so modelos, no qual consiste de um conjunto de fases que so aplicadas durante o processo de desenvolvimento de software, que satisfazem as necessidades de um projeto. Na fase de definio, so levantados quais os objetivos esperados pelo cliente, suas funes, restries e os critrios de validao para que o produto seja considerado terminado. Segundo Pressman (1995), trs etapas ocorrem: Anlise do Sistema: Uma anlise minuciosa dos elementos que o comporo, definindo suas aes; Planejamento do projeto de software: Anlise dos riscos, recursos, custos e definio das tarefas a serem executadas; e Anlise dos Requisitos: Antes do incio das tarefas necessrio detalhar as funes esperadas do software. Na fase de desenvolvimento, so definidos pelos desenvolvedores a arquitetura do software, como sero implementadas as tarefas e como os testes

19

devem ser realizados, onde trs passos so executados: Projeto de Software: Descrio da arquitetura, os procedimentos e caractersticas de interface; Codificao e realizao dos testes. Por ltimo, a fase de manuteno reaplicada os passos das fases de definio e desenvolvimento nas manutenes que forem necessrias realizarem no software, que podem ser por: Correo de defeitos; Adaptao de ambientes internos ou externos ao sistema; e adio de novas funcionalidades ao produto.

1.3. Manuteno do Software

Manuteno uma das fases do ciclo de vida do desenvolvimento de software, geralmente so realizadas no software depois de liberado ao cliente e colocado em uso. Responsvel por realizar alteraes no produto por diversas razes determinando a categoria das mudanas a serem executadas. As categorias das mudanas so: a) Manuteno Corretiva: categoria que identifica e corrige erros de cdigofonte do projeto, ou seja, manuteno que ser executada por razo de existncia de defeitos, falhas e erros. b) Manuteno Adaptativa: mudanas ao software para que ele possa se adaptar ao ambiente operacional em que est em uso, caracterizada pela evoluo contnua existente no mundo real. c) Manuteno Perfectiva: No decorrer do tempo, os clientes e usurios tendem a querer mudar e melhorar funcionalidades existentes e incluir novas funcionalidades , a fim de aperfeioar as funes exercidas pelo software. d) Manuteno Preventiva: Melhorar o cdigo-fonte do produto para que futuramente seja fcil dar manuteno, alm de no futuro melhorar a confiabilidade do software e facilitar a incluso de novas funcionalidades. O que caracteriza esse tipo de manuteno melhorar a manutebilidade e prevenir problemas ocasionados pelo cdigo futuramente.

20

As alteraes no software so inevitveis, um dos problemas que ocorre nessa fase so custos maiores do que a etapa de desenvolvimento, como demanda tempo para a realizao das modificaes despendido maior esforo de pessoas para execuo da manuteno para que essas alteraes no impactem no cronograma estipulado, porque no processo de qualquer mudana requer entendimento do que o software faz, interpretao da estrutura de dados, ou seja, analisar, avaliar, projetar, codificar e testar as alteraes. Dentre as dificuldades do processo de manuteno est a dificuldade em analisar a evoluo do software, alteraes no documentadas, documentao do projeto inexistente e se existe difcil sua compreenso ou est desatualizada. O processo de manuteno de software considerado um dos fatores importantes para obteno de qualidade do produto de software, pela sua complexidade em relao ao processo de desenvolvimento de software.

1.4. Qualidade de Software

Qualidade de Software objeto de desejo por todos que participam do desenvolvimento de um produto, sejam eles clientes, desenvolvedores ou gerentes de projetos. No importa o que cada um entende por qualidade, pois cada um entende de uma forma diferenciada, por ngulos diferentes, mas todas as partes desejam e tm uma viso de qualidade. Por exemplo, para o desenvolvedor um software de qualidade quando o cdigo fonte est organizado e de fcil manutebilidade; para o usurio comum de um sistema, um erro no programa pode ser falta de qualidade. Essas vises diferenciadas, que de certa maneira no esto erradas, so incompletas. E por esse motivo que Molinari (2007) afirma que no existe uma nica forma de se tratar de qualidade de software, pois para alcan-la depende muito do ambiente e finalidade do software. A partir da afirmao de Koscianski (2007, p. 35): Qualidade de Software no mais um fator de diferenciao e sim condio essencial para empresas e profissionais serem bem sucedidos, percebemos que qualidade de software era

21

considerada pelas empresas de desenvolvimento de software pelo motivo de diferenciao dos seus produtos no mercado perante seus concorrentes. Diferente do passado, atualmente, tornou-se essencial nas organizaes do ramo, pois o objetivo da qualidade atender aos requisitos e necessidades do cliente, e atingindo esse objetivo, tanto a empresa como os profissionais envolvidos se tornam bem sucedidos. A partir da afirmao de Pressman (2006, p.1):
Hoje, o software de computadores a tecnologia nica mais importante no palco mundial. (...) Ningum na dcada de 1950 poderia ter previsto que o software fosse se tornar uma tecnologia indispensvel para negcios, cincia e engenharia; que o software fosse permitir a criao de novas tecnologias (...) ningum poderia ter previsto que milhes de programas de computador tivessem de ser corrigidos, adaptados e aperfeioados medida que o tempo passasse, e que o nus de realizar essas atividades de manuteno absorveria mais pessoas e mais recursos que todo o trabalho aplicado na criao de novos softwares.

Podemos identificar o cenrio atual do desenvolvimento de software. Uma busca crescente pelo desenvolvimento de novas tecnologias baseadas no desenvolvimento de softwares de computadores, a fim de melhorar os processos antes existentes e agiliz-los tornando-se indispensveis aos negcios. No decorrer dos anos, percebemos que esse grande volume de produtos desenvolvidos tiveram que ser corrigidos, adaptados e aperfeioados por motivo de novas condies de negcios e mercado, e novas necessidades de clientes. Alteraes que impactam nas informaes produzidas pelo software, prioridades do software, na estrutura do time de desenvolvimento e nas regras de negcio. Devido a essas manutenes serem grandes, o nus para realiz-las seria maior do que a criao de um novo software. Da dcada de 1950 at o presente momento ainda persistem algumas questes referentes ao processo de fabricao e manuteno do software (PRESSMAN, 2006, p. 3):
- Por que leva tanto tempo para concluir o software? - Por que os custos de desenvolvimento so to altos? - Por que no podemos achar todos os erros antes de entregar o software aos clientes? - Por que gastamos tanto tempo e esforo mantendo programas existentes?

22

- Por que continuamos a ter dificuldade em avaliar o progresso enquanto o software produzido?

Questes decorrentes de problemas ocasionados por mudanas necessrias ao software, processo que no to simples para as equipes de desenvolvimento de software. Para avaliar a qualidade de um software, existem algumas mtricas, que nada mais do que a medio de alguns atributos que de acordo com Pressman (1995) podem ser diretos (exemplo: custos, esforos e erros) ou indiretos (exemplo: usabilidade e manutebilidade). A importncia de se medir pontos de um software entender problemas e aperfeioar o processo de desenvolvimento, melhorando a gerencia de projetos, reduzindo a falta de cumprimento de prazos estipulados, indicando a qualidade de um produto de software, avaliao da produtividade, avaliar benefcios de novos mtodos e ferramentas, identificar melhores prticas de desenvolvimento, melhorar estimativas e identificar melhorias no processo de desenvolvimento de software. Para resolver esses problemas, inerentes ao processo de desenvolvimento e manutebilidade do software, existe uma disciplina especfica dentro da Engenharia de Software responsvel em resolv-los, que identificada como Gerncia de Configurao de Software. Entre os problemas relacionados esto: perda do cdigofonte, dificuldade em gerenciar o histrico das alteraes realizadas, o tempo dispendido para localizao do cdigo-fonte, falhas decorrente por falta de documentao do cdigo e regras de negcio, gerenciar alteraes que podem impactar outras partes que j estavam funcionando corretamente.

23

Captulo 2 GERNCIA DE CONFIGURAO DE SOFTWARE

Neste Captulo sero apresentadas definies da Gesto de Configurao, os objetivos e a importncia de sua aplicabilidade juntamente dos processos de desenvolvimento e manuteno do software, o histrico de evoluo e suas atividades e tarefas.

2.1. A Gesto Especfica

A Gerncia de Configurao um ramo da Engenharia de Software que, atualmente, mostra-se como uma rea a ser implantada nas organizaes desenvolvedoras de software. De acordo com Pressman (2006, p. 181):
Conjunto de atividades projetadas para controlar as mudanas pela identificao dos produtos do trabalho que sero alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes verses destes produtos, controlando as mudanas impostas, e auditando e relatando as mudanas realizadas.

A Gesto de Configurao tem-se mostrado importante em relao qualidade de projetos modernos e complexos, e at mesmo se tornando um diferencial competitivo entre empresas de desenvolvimento, sendo que, h uma corrida pela qualidade nos produtos oferecidos a seus clientes (ESTUBLIER, 2005). uma gesto que garante a qualidade de softwares por meio de mtodos e prticas. Segundo Valeriano (1998), no se insere, contudo, na rea de Qualidade de Software, uma vez que at mesmo a qualidade controlada por GCS (Gerncia de Configurao de Software), e tem um momento predefinido no cronograma do projeto. Molinari (2007) cita que essa qualidade alcanada a partir de alguns processos que envolvem o gerenciamento de configurao que, identificam, rastreiam e controlam as mudanas nos elementos do software.

24

Atualmente com o maior conhecimento e ateno que vem sendo dado a essa rea, desenvolvem-se diversas tecnologias que servem como suporte gerencial. Esse tipo de gesto no se aplica somente a um determinado ponto do ciclo de vida do projeto e, sim, em todo o decorrer do desenvolvimento do projeto, inclusive quando ele est em manuteno contnua. A GC trabalha paralelamente a qualquer outra atividade que compe o ciclo de desenvolvimento. A Gesto s encerrada a partir do momento em que o produto no sofre mais nenhuma alterao, ou seja, o projeto acompanhado at o descarte final. Um projeto est sempre em constante mutao, ou seja, as alteraes encontradas e realizadas em meio ao processo de fabricao precisam ser gerenciadas, para obter um maior controle das mudanas o que levou a mudana, seu efeito como um todo no que j estava pronto, at o momento em que se faz necessrio realizar alguma alterao no escopo planejado. Alm de controlar o que foi alterado, necessrio documentar os artefatos envolvidos para que, no futuro, possam ser facilmente identificados. A partir de um histrico de mudanas gerado por GCS, possvel responder as seguintes questes bsicas: quem, quando, o qu, onde e o porqu das alteraes. Dessa forma, segundo Oliveira (2001, p.7):
As organizaes hoje so constantemente desafiadas para se adaptar s mudanas ambientais, levando em considerao as expectativas dos clientes, estratgias competitivas, avanos tecnolgicos, leis governamentais, condies instveis na economia e na sociedade. [...] a globalizao dos mercados financeiros pressupe um novo paradigma quanto funo, importncia e impacto da informao tanto como fator de competitividade das empresas e organizaes em geral, quanto como fator determinante de sua adaptabilidade a essas mudanas ambientais.

Por meio da Gerncia de Configurao possvel fazer com que a equipe de desenvolvimento tenha maior produtividade e, assim, diminuir erros com o gerenciamento dos artefatos (SOMMERVILLE, 2008). Alm de garantir a qualidade por meio de algumas prticas que sero abordadas a seguir, importante frisar alguns benefcios que essa gesto traz como reduo de custos e melhoria da curcia dos prazos e estimativas.

25

Gesto de Configurao uma rea da Engenharia de Software que tem por objetivo controlar todos os processos e itens de configurao envolvidos no processo de desenvolvimento de softwares, a fim de garantir uma maior qualidade do produto a ser entregue ao cliente. Segundo Oliveira (2001), prope-se a minimizar problemas que surgem durante o ciclo de vida do produto por meio de controles sistemticos sobre as modificaes. Permitindo assim, manter a integridade dos sistemas no decorrer do tempo atravs de algumas atividades, tais como: controle das modificaes dos itens, registro da situao dos itens e das requisies das alteraes, armazenamento das alteraes, manipulao das alteraes, liberao e entrega dos itens alterados (ISO/IEC 12207, 1995). Esse tipo de gesto, Gerncia de Configurao, um processo abrangente, tanto tcnico como gerencial. Aplica-se a todas as atividades da engenharia de sistemas, por meio de normas controlando sistematicamente a criao e alterao de itens de configurao informaes produzidas em grande quantidade durante o desenvolvimento de softwares, tais como: especificaes, planos de projeto, arquivos de cdigo fonte, casos e planos de testes, manuais, arquivos de dados, entre outros (PRESSMAN, 2005). As Informaes geradas durante o ciclo de vida so geralmente controladas por gerentes de projetos e analistas de sistemas em perodos pr-determinados no processo de desenvolvimento de software. Esses perodos que tem incio e trmino definidos so determinados baselines. Trata-se de linhas de referncia para quem tem o papel de monitoramento das criaes e alteraes de itens de configurao compreendidos nesses prazos. Consequentemente o que foi produzido e/ou alterado identificado, analisado, corrigido, passado por uma aprovao e aps isso so armazenadas as configuraes. As principais atividades envolvidas em GC, de acordo com IEEE (2005), so: Identificao da Configurao; Controle de Modificao; Auditoria e Reviso da Configurao; Contabilidade do Status da Configurao; Gerencia de Liberao. Para melhor entendimento dos termos que sero tratados no decorrer do trabalho sero apresentados alguns conceitos bsicos dentro do gerenciamento de mudanas: Configurao: um conjunto de caractersticas funcionais e/ou fsicas localizadas nas descries de documentaes tcnicas (VALERIANO, 1998);

26

Itens de Configurao (IC): qualquer informao criada ou alterada que fica sob controle, como parte do processo, da gerncia de configurao. Um item de configurao pode ser um componente fsico ou lgico, por exemplo, uma especificao de requisitos, um caso de teste, o cdigo-fonte de um programa. (PRESSMAN, 2006; VALERIANO, 1998); Artefato: so documentos, componentes de software (inclusive cdigofonte) e qualquer informao necessria para a execuo de uma atividade ou produzida por esta dentro de um processo de software. Dessa maneira, os artefatos so todos os itens de dados manipulados, criados e utilizados durante o desenvolvimento de software (LIMA REIS, 2003); Verses: quando realizado alteraes no software ou criao de novas funcionalidades, determina-se o desenvolvimento de novas variaes do produto. E caso sofram pequenas mudanas podem ser chamadas de variantes da verso original. (SOMMERVILE, 2008); Release: uma verso de um sistema distribuda para o consumidor. Porm, um release no se restringe apenas ao cdigo-fonte de um sistema, pode ser um arquivo de configurao, arquivos de dados, manual do usurio, instalador do programa dentre outros (SOMMERVILE, 2008); Repositrio: o conjunto de mecanismos e estruturas de dados que permite a uma equipe de software gerir modificaes de modo efetivo. Fornece funes inerentes a um sistema de gesto de banco de dados, porm, alm disso, executa ou prover outras funes especficas como: integridade de dados, compartilhamento de informaes, integrao de ferramentas, integrao de dados, imposio de metodologia e padronizao de documentos (PRESSMAN, 2006).

2.2. Histria e evoluo de GCS

Segundo Estublier (2002), Gerncia de Configurao de Software, surgiu nos anos 50 para atender as necessidades de se controlar alteraes em documentaes de projetos de avies de guerra e naves espaciais nas indstrias

27

aeroespaciais. Molinari (2007) destaca como marcos histricos a apresentao da tese change and configuration control pelo professor Leon Pressor da Universidade da Califrnia (Santa Brbara, EUA), que foi o marco inicial para os conceitos bsicos de mudana e do controle de mudana de componentes de um software, e o primeiro Congresso Internacional de GCS em 1988.

Figura 2 Marcos Histricos de GCS (MOLINARI, 2007).

28

Observando a figura anterior, foi a partir dos anos 60 e 70, que a Gerncia de Configurao, comeou a abordar artefatos de software, alm do hardware j estabelecido, surgindo a Gerncia de Configurao de Software. Mas somente em meados dos anos 90 com o surgimento do padro IEEE em 1987 e da norma ISO 10007 em 1995, GCS foi assimilada no processo de desenvolvimento de software em empresas que at ento era restrito s organizaes militares (Murta, 2004).

2.3. Atividades da Gerncia de Configurao de Software

O objetivo deste tpico identificar quais so as atividades/processos de GCS e apresentar o seu funcionamento e benefcios no processo de desenvolvimento de software. Sendo que cada uma dessas atividades tem sua responsabilidade e o momento correto para sua execuo no ciclo de vida do software. As principais atividades proposta pela Gesto so: identificao da configurao, controle de modificao, auditoria da configurao, contabilidade do status da configurao e gerncia de liberao, tarefas que fazem parte de um processo padro definido pelo IEEE (2005).

Figura 3 Fases da Gerncia de Configurao (PRESSMAN, 2006).

29

Falhas que antes aconteciam, sem os processos de GCS, na entrega do produto, por exemplo, um sistema que foi alterado, mas parou de funcionar uma das funcionalidades que j existia e no foram percebidos antes da entrega ao cliente, agora seriam apoiados pela gerncia de mudanas minimizando os riscos desses problemas. Depois de criado os itens de configuraes, preciso identific-los para que possam ser colocados sob controle e faam parte da configurao e baselines. Aps ser identificado s podero ser aprovadas as alteraes no item configurado somente quando estiver passado em todas as camadas e, por fim, liberado para entrega. Ou seja, o item ser identificado, passado por uma aprovao no controle de modificao, avaliado na auditoria de configurao as modificaes como um todo no item e por fim na ltima camada a gerncia de liberao tem o objetivo de distribuir as verses do software ao cliente. Para Molinari (2007) a imagem a seguir apresenta de forma geral todas as atividades bsicas e os processos de Gesto de Configurao.

Figura 4 Atividades de GC (MOLINARI, 2007)

30

Na Gerncia de Configurao de Software existe um rgo que auxilia na execuo de atividades, que sero apresentadas no decorrer desse captulo, denominado de Controle de Configurao de Software ou Comit de Configurao de Software, o qual deve ser constitudo de representantes de todas as atividades relacionadas ao sistema. O gerente de projeto o presidente de configurao podendo delegar a outra pessoa o papel de gestor da configurao. De acordo com Valeriano (1998, p.271) a CCC tem autoridade para: elaborar o plano de gesto de configurao; estabelecer os procedimento ou rotinas da GC; selecionar itens de configurao; estabelecer as configuraes bsicas; aprovar ou rejeitar as modificaes, desvios e concesses; liberar documentao (especificaes, desenhos, relatrios de GCS etc.); e verificar a implementao das alteraes.

2.3.1. Identificao da configurao

Esta a primeira fase da Gerncia de Configurao, sendo que o objetivo desta fase, como o prprio nome indica, identificar os itens de configurao, registrando as caractersticas fsicas e funcionais, estabelecendo um identificador nico para esses itens. Um item de configurao pode ser qualquer coisa criada durante o ciclo de vida do desenvolvimento do software, desde a especificao de requisitos, uma parte de um documento at uma verso executvel da aplicao. Segundo Molinari (2007) o menor item que pode ser colocado para controle em um processo de GCS. Todas as informaes produzidas sobre um item sero armazenadas e controladas. Itens sugeridos por Pressman (2005) para serem colocados no controle:

31

Quadro 1 Itens sugeridos para controle de configurao (PRESSMAN, 2005).

As informaes que sero produzidas sobre os itens de configuraes, so originados por causa das modificaes que esto sujeitas no decorrer do desenvolvimento do software. Sendo que essas mudanas podem fazer com que um item produza outros itens a serem controlados. Molinari (2007) explica que em cada ciclo de alteraes itens de configurao so identificados, produzidos, armazenados e liberados para uso.

32

Figura 5 Processo de Identificao da Configurao (MOLINARI, 2007).

O item de configurao pode ter vrias verses, e normalmente cada verso ser diferente da outra, para isso preciso nomear os itens de forma que seja fcil reconhecer a evoluo e hierarquia entre os componentes. A GCS, como visualizado na imagem anterior, realiza o registro dos eventos sob os itens, sendo assim, tornase fcil a tarefa de voltar a uma determinada verso do item ou at mesmo identific-la quando necessrio. Aps a identificao dos itens so planejadas as baselines no ciclo de desenvolvimento, no final de cada fase do desenvolvimento e depois de cada ciclo de manutenes. esse processo que define como sero criadas as baselines. No qual devem ser especificados os itens que sero revisados e armazenados. E por fim descrever a maneira como os itens sero armazenados e recuperados do repositrio. Os itens de configurao precisam ser armazenados para garantir que no desaparecero ou sero danificados, mas quando sofrer alguma alterao o item no poder apenas ser sobrescrito pela verso mais nova, pois seria o equivalente a jogar fora a anterior, e sim manter o histrico das mudanas do item. Por exemplo: Em um determinado sistema necessrio alterar a forma como realizado um

33

cadastro de funcionrios para agora alm de fazer o que fazia tambm memorizar as digitais, e depois de alguns meses da entrega ao cliente da aplicao alterada o mesmo decidisse voltar para a verso sem a memorizao das digitais. Nesse exemplo, sem o armazenamento do histrico de alteraes do software isso geraria retrabalho, gasto de tempo e consequentemente mais esforos de pessoas correndo risco de ao remover as alteraes desenvolvidas quebrar o que estava funcionando, sendo que com as mudanas armazenadas seria muito mais rpido e econmico voltar para a verso anterior, pois todas as modificaes estaro armazenadas.

2.3.2. Controle da configurao

Controle de Configurao pode ser dividido em dois tipos: controle de mudanas e controle de verso. No qual controle de mudana tem como responsabilidade controlar os pedidos de alteraes, identificando a necessidade e seus impactos podendo decidir se ser realizada ou no. Controle de verso so procedimentos juntamente de ferramentas que apoia o controle de mudanas e seus envolvidos alm de fornecer recursos para a camada de Contabilidade do Status da Configurao.

2.3.2.1. Controle de mudana

Esta fase da Gerncia de Configurao tem o objetivo de controlar todas as mudanas realizadas em todos os artefatos criados durante o ciclo de vida do software. Responsvel por monitorar toda a evoluo da fabricao do produto, pois no decorrer do desenvolvimento ocorrem diversas modificaes, segundo Pressman (2006) por quatro fontes fundamentais: alteraes nos requisitos do produto ou regras do negcio por causa de novas condies do negcio ou do mercado; novas necessidades do cliente incorporando ao sistema novas funcionalidades; restries

34

de oramento ou cronograma causam redefinio do software e reorganizao dos negcios causando modificaes nas prioridades e estrutura da equipe de desenvolvimento. Segundo Valeriano (1998), o controle de mudanas envolve as seguintes atividades: documentao e justificativas das modificaes, avaliao de suas consequncias, aprovao ou rejeio dos pedidos de alteraes, implementao e verificao dessas modificaes. Basicamente o controle da configurao tem por finalidade controlar todos os pedidos de alterao e todas as mudanas implementadas.

Figura 6 Processo Controle de Configurao (PACHECO, 1997).

35

De acordo com a figura anterior as tarefas bsicas para o processo de controle de mudanas so: 1) Criao de um registro de evento: Na requisio de mudana criado um registro com a descrio dos detalhes da alterao com dados relevantes sobre a requisio, como por exemplo, um erro na execuo de uma aplicao, como reproduzir o erro, a verso em que foi encontrado o erro, quem a localizou e a gravidade do mesmo. 2) Anlise de registro de evento: Neste ponto a CCC analisa os impactos como um todo que essa alterao pode causar nas partes relacionadas do software. Identifica o nvel de prioridade em relao s outras alteraes, a importncia e necessidade em execut-las de acordo com o requisitado pelos usurios, as repercusses sobre contrato, custos e prazos, efeitos na produo, o que em detalhes mudar no software e os riscos associados. 3) Rejeio ou aceitao de registro de evento: O evento pode ter uma dentre trs decises que podem ser decidido: aceito, rejeitado e adiado. Se aceito, uma solicitao de mudana criada. Se rejeitado, quem requisitou a modificao notificado da deciso, sendo que para tal considerado aspectos de mercado e competio. Ou se ainda adiada, o pedido de alterao entra em uma fila de espera de acordo com sua prioridade em relao s outras que esto esperando para entrar em uma baseline a ser implementada. A competncia para a deciso do registro de evento definido pelos membros da Comisso de Controle da Configurao. A CCC verifica se os dados elaborados na atividade anterior e se as alteraes na documentao esto em conformidade e, se for positivo, autorizada a implementao da mudana. 4) Implementao da mudana: definido e criado um novo item de configurao e implementada a alterao. 5) Verificao: Etapa realizada tambm pela equipe da CCC, em que so realizadas verificaes para analisar se os defeitos ou alteraes de melhorias requisitadas esto atendendo ao comportamento esperado apresentado na requisio de mudanas. 6) Fechamento de registro de evento: o fechamento da solicitao da mudana, quando se tem mais de um pedido de mudana

36

correspondentes, o registro de evento s pode ser fechado quando os outros forem fechados.

2.3.2.2. Controle de verso de software

Sistemas de Controle de Verso de Software atendem a duas camadas da Gerncia de Configurao, Controle de Mudana e Contabilidade do Status da Configurao, pois oferece suporte aps aprovao da solicitao da mudana, no armazenamento das alteraes sem sobrescrever o histrico anterior e na implementao das alteraes dando suporte aos desenvolvedores, j no processo de contabilizao do estado da configurao, no armazenamento de informaes relevantes as mudanas realizadas, tais como: o que aconteceu? Quem fez? Quando aconteceu? O que mais ser afetado? Dentro do Controle da Configurao existem ferramentas que ajuda no controle de verses do software, no qual controlada a evoluo dos artefatos, algo que no to simples de se controlar durante o ciclo de desenvolvimento e manuteno de software que tambm no curto, pelo contrrio, to longo que s ter fim a partir do momento que o software for descartado. So controladas as alteraes em um conjunto de cdigos-fontes e documentos envolvidos no processo de desenvolvimento, criando um histrico de modificaes. Como Herclito mesmo disse, 500 anos antes de Cristo, no h nada permanente, exceto a mudana. O processo de versionamento de software muito importante e serve como apoio para as equipes de desenvolvimento. Pois se em um grande esforo de pessoas na produo de um programa as mudanas que surgem desencadeadamente no forem bem controladas, o processo de desenvolvimento ou manuteno pode virar um caos (PRESSMAN, 2006). Por que um caos? Pelo grande volume de artefatos existentes, quantidades de equipes e s vezes em diferentes locais, vrias iteraes, vrios releases e diferentes produtos. Para apoio e melhor rastreamento dessas alteraes recorrentes, so combinados procedimentos humanos e ferramentas automatizadas (PRESSMAN, 2006).

37

Existem algumas ferramentas, tais como: git, subversion e bazaar, que podem resolver vrios problemas que ocorrem no processo de desenvolvimento e manuteno. Alguns problemas que podem ocorrer, e o grande apoio que solues de sistemas de controle de verses podem proporcionar as equipes de desenvolvimento. Dar manuteno na cpia real do cdigo fonte da ltima verso disponibilizada do software, sem ser necessrio mexer direto no de produo correndo o risco de alterar o software e quebrar as funcionalidades e recursos que estavam funcionando corretamente antes da alterao. Ou realizar uma cpia do servidor de produo, mas ao envi-la novamente ao servidor corre o risco de estar sobrescrevendo outra verso mais nova que havia sido enviada antes sem saber. O sistema de controle de verses proporciona o recurso de trabalhar em uma cpia atualizada do repositrio localmente, se houver uma atualizao no repositrio a cpia local ser atualizada tambm, ao enviar uma nova funcionalidade no ser perdido o cdigo ao enviar uma atualizao nova, pois estar armazenado. Se houver um problema com a alterao ser fcil identificar a verso anterior e voltar para o antigo estado. Quando ocorrer vrias alteraes simultneas, atravs de uma ferramenta de versionamento de cdigo possvel realizar a juno das alteraes. Quando surgir conflitos de alteraes em um mesmo arquivo possvel identificar os conflitos e selecionar o que se deseja manter um ou mais conflitos e mandar ao repositrio a correo do conflito, ou seja, fcil manipulao e identificao de conflito de alteraes em um mesmo arquivo. O mais importante desse processo que qualquer alterao que for feita ser registrada atravs de um sistema de controle de verses, onde nada perdido, caso seja necessrio recuperar o que aparentemente foi perdido, s poder ser recuperado porque foi salva em algum momento no ciclo de vida do software a alterao. No processo de versionamento do software preciso responder as seguintes questes: quem realizou as alteraes, quais alteraes foram realizadas, quando elas foram feitas e o porqu das modificaes. Para maior rastreabilidade das mudanas, para posteriormente possa ser facilmente identificado o motivo das alteraes, quando foi necessrio realiz-las e o que foi alterado. Dentre os motivos importncia do controle de verses est (GIT, 2012):

38

1) Armazenamento do cdigo-fonte: so armazenadas todas as verses do software, congelando-o e representando fielmente o ponto em que foi criada a verso, permitindo tambm o controle de todas as modificaes realizadas; 2) Compartilhamento do cdigo-fonte: o cdigo-fonte pode ser compartilhado entre os desenvolvedores participantes do desenvolvimento, proporcionando o desenvolvimento paralelo com quantidade ilimitada de membros que podem estar em locais diferentes e at mesmo geograficamente distantes;

Figura 7 Compartilhamento entre os envolvidos (MOLINARI, 2007).

3) Auxiliar na manuteno: Facilidade em localizar o cdigo-fonte, identificar a verso atual, quais as ltimas correes, o que foi alterado e quando foi alterado; Verso de Software o nome atribudo a um contedo em uma cadeia de alteraes. um marco indicado na evoluo de uma aplicao e indicam um ciclo de mudanas em um software, no final de cada baseline gerado uma verso do estado atual do programa. Existem alguns padres para indicar uma verso de determinado software, tipos: - Datas: 20110601; - Cdigos: XP, Karmic Koala; - Compostas: 2.4.10.

39

Dos tipos apresentados o mais usado, que se pode dizer forma padro, o composto no qual constitudo por trs nmeros separados por ponto, mais conhecidos como <major.minor.micro>. Onde o major indica compatibilidade de verses, exemplo a verso 2.0.0 incompatvel com as verses anteriores por ter diferenas na forma de funcionamento adquirindo incompatibilidades, j o minor indica acrescento de funcionalidades gerando novas verses, mas que no incompatibilizam em relao verso anterior, por exemplo, se houvesse adio de mais duas funcionalidades a verso seria 2.2.0. E por fim o ltimo indica correes de bugs encontrados no software que tambm no incompatibiliza a verso, exemplo se fosse encontrado 15 bugs e corrigidos a verso atual seria 2.2.15.

2.3.3. Contabilidade do status da configurao

Esta camada da Gerncia de Configurao encarregada por gerar relatrios dos registros de alteraes incluindo as baselines. Relatrios que podem ser utilizados para busca de informaes, para aplicao de medies de melhoria de processos, estimativa de custos futuros e suporte para gerao de relatrios gerenciais. O objetivo deste processo dar visibilidade a todos envolvidos no processo de desenvolvimento e manuteno de software, algumas informaes essenciais sobre o histrico de alteraes, tais como: Porqu da alterao? Quem alterou? O que foi alterado? Quando foi alterado? E manter atualizada a documentao de cada item e todas as vias de modificaes ou revises de: especificaes; desenhos; listas e suas modificaes e manuais. Todos os envolvidos tendo acesso a essas informaes agiliza o processo de fabricao e melhora a comunicao entre os membros, eliminando assim problemas intrnsecos a manuteno do mesmo artefato com diferentes abordagens, facilitando na juno de alteraes e rastreio das modificaes do projeto.

40

Figura 8 Informaes sobre o item de configurao (MOLINARI, 2007).

2.3.4. Auditoria da configurao

Auditoria da Configurao a camada responsvel por assegurar que as alteraes foram implantadas corretamente, as documentaes esto completas e precisas, satisfazem os requisitos estabelecidos (VALERIANO, 1998), garantindo ao cliente que o software est sem erros e que o produto tem evoludo de uma maneira rastrevel, satisfaz suas necessidades operacionais e de desempenho. Na auditagem o projeto passa por dois processos fundamentais: verificao e validao (CAPRETZ, 1988). A auditoria deve ser executada antes da definio de uma baseline, para certificao do produto em relao s especificaes e contratos, ou seja, requisitos, e auditoria tambm das alteraes realizadas para monitoramento do status durante o ciclo de vida e verificao dos requisitos estabelecidos, revelando se os requisitos esto sendo atingidos. Com isso o gerente de projeto pode avaliar melhor a

41

integridade do que esta sendo produzido, podendo resolver problemas que pode vir a ocorrer, corrigindo os defeitos no processo para garantir a integridade do software. A auditoria da Configurao pode ser dividida em dois tipos: Auditoria Funcional e Auditoria Fsica. Auditoria Funcional uma atividade de controle de qualidade que tem por objetivo identificar se as mudanas especificadas foram realizadas, se foi adicionado mais alguma modificao, se foi aplicado s normas de engenharia de software no processo de desenvolvimento e modificao e se foi aplicado os procedimentos de GC corretamente (PRESSMAN, 2006). Auditoria Fsica ocorre ao final de cada fase do ciclo de vida controlando se a configurao estabelecida em uma baseline especfica composta pelos itens corretos, nas verses corretas e que a documentao est atualizada e consistente com a verso que foi construda (PRESSMAN, 2006).

2.3.5. Gerncia de liberao

a ltima atividade de GCS, responsvel por controlar a liberao e entrega dos produtos e da documentao do software. O processo criar, empacotar e entregar os baselines. Ou seja, o responsvel por executar essa atividade, identifica os itens de configurao sobre controle da Gerncia de Configurao e suas respectivas verses criando uma baseline o qual documentada diferenciando das baselines anteriores. O baseline empacotado e entregue ao cliente, ou seja, o produto pronto com sua verso mais nova para ser colocado em uso.

42

Captulo 3 GERNCIA DE CONFIGURAO DE SOFTWARE NOS PRINCIPAIS MODELOS E PADRES

Neste captulo ser abordado a Gerncia de Configurao nos principais modelos e normas, a importncia de sua aplicabilidade juntamente dos processos de desenvolvimento e manuteno de softwares. Durante o tempo, os conceitos sobre qualidade de forma geral e qualidade de software foram sendo evoludos, com definies mais claras e especficas por meio de anlises e experincias vividas. Percebeu-se que para adquirir qualidade do produto muito importante a busca por qualidade no processo de produo, at porque uma depende diretamente da outra, se no existir qualidade no processo de fabricao no seria possvel adquirir um produto de qualidade. A partir dessa evoluo foram criados alguns modelos e padres normativos de qualidade para o processo de desenvolvimento de software (BARRETO JNIOR, 2011). Para apoiar na definio de processos existem diversas normas e modelos de qualidade de software, sendo que cada um deles apresentam uma viso um pouco diferente da outra, mas com o mesmo objetivo, dentre os principais esto: CMM, CMMI, MPS.BR, SPICE e ISO. Os rgos normalizadores reconhecidos mundialmente so: ISO (International Organization for Standardization), IEEE (Instituto de Engenharia Eltrica e Eletrnica), e ABNT (Associao Brasileira de Normas Tcnicas). Nos modelos criados por rgos normalizadores reconhecidos mundialmente ou no (caso da MPS.BR), h um conjunto de polticas, padres/normas e estruturas organizacionais que devem ser seguidos para que os processos sejam avaliados e julgados, descrevendo seus resultados obtidos diante dos esperados pela utilizao de modelos de maturidade, a fim de aprimorar sempre o processo de desenvolvimento para melhorar a qualidade dos produtos desenvolvidos (GOMES, 2011). A qualidade dos produtos de software so altamente influenciados pela qualidade dos processos utilizados nas fases de planejamento, desenvolvimento e manuteno (CAROSIA, 2003). Pdua (2003) afirma que os maiores responsveis pelos problemas que ocorrem nos processos so dos gerentes de projetos, pois segundo ele, o papel do

43

gerente propor a equipe uma cultura de excelncia, propondo metas em termos de custo, prazos e qualidade, se comprometendo a evitar repetir erros e melhorar sempre os processos. O uso de modelos e normas, na gesto de projetos e processos de desenvolvimento de software, se faz importante nas organizaes pela busca de melhoria contnua dos processos, modelos de qualidade de software que aplicam prticas efetivas, processos bem estabelecidos que incorporem mecanismos sistemticos para acompanhar o desenvolvimento e avaliar a qualidade conduzindo a produo de produtos de qualidade. A busca pelas empresas por melhoria contnua dos processos algo inevitvel nos dias de hoje, porque uma forma de evoluir constantemente os processos de trabalho adquirindo como benefcios a economia de tempo, reduo de gastos e de retrabalho, ou seja, de forma geral a eficcia das atividades (BORGES, 2001). Segundo as normas ISO/IEC 12207, ISO/IEC 15504 e CMMI definem um processo padro como um ponto base, sendo adaptveis e configurveis aos processos base, sendo possvel definir processos para projetos especficos levando em considerao as particularidades de cada projeto e aspectos importantes para atingir qualidade do processo. Os processos so organizados por etapas, resultados intermedirios, controles e medies aplicados em projetos que tem custos, prazos e responsveis bem definidos (PAULA FILHO, 2003). A imagem abaixo ilustra a adaptao dos processos de normas/padres aos projetos com suas particularidades, paradigma e tecnologia de desenvolvimento:

44

Figura 9 Modelo definido para Definio de processos em nveis (ROCHA et al, 2001)

Nos prximos subitens sero apresentados os principais modelos e normas/padres em que a Gesto de Configurao est inclusa, e considerada uma das principais reas para que haja sucesso pela busca qualidade no processo de fabricao do software e consequentemente produzindo produtos de qualidade. Este captulo tem por finalidade apresentar como a Gesto de Configurao de Software se aplica em cada modelo, e no fazer entender em detalhes os modelos de maturidade.

3.1. CMM verso 1.1

O Modelo de Maturidade da Capacidade mais conhecido pela sigla CMM (Capability Maturity Model) verso 1.1 atualmente, segundo Molinari (2007) e a PBQP (2002), o modelo mais usado no mundo. A pesquisa realizada em 2001 pelo MCT/SEPIN (Ministrio da Cincia e Tecnologia / Secretaria de Poltica de Informtica) mostra o tanto que o modelo conhecido e utilizado pelas organizaes no Brasil, sendo comparado com a ISO 12207 e SPICE, que so regulamentados por organismos regulamentadores, diferente do CMM.

45

Grfico 1 Nvel de conhecimento e utilizao de modelos no Brasil, pelo MCT/SEPIN 2002

O CMM surgiu a partir da necessidade do Departamento de Defesa dos EUA, um grande consumidor de software que precisava de um modelo formal que permitisse selecionar os seus fornecedores de software de forma adequada. Foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon em Pittsburg, EUA, por um grupo de profissionais de software, sendo a primeira verso lanada em Agosto de 1991. A verso CMM 1.1 foi liberada em 1993 e foi suportada em termos de certificao at o fim de 2005 (MOLINARI, 2007; BARRETO JNIOR, 2012). Apesar de no ser uma norma emitida pelos rgos reconhecidos internacionalmente, teve grande aceitao mundialmente. Foi baseado em algumas ideias de movimentos sobre qualidade industrial nas ltimas dcadas, dentre elas W. E. Deming que teve bastante influncia no Japo, mas voltada para a rea de software. As prticas do CMM so agrupadas em nveis de maturidade, ou seja, um modelo de capacitao em estgios. Em cada nvel, exceto o primeiro, contm um conjunto de reas chaves que representa um grupo de atividades, realizando um conjunto de metas, sendo consideradas essenciais para resolver questes identificadas que devem ser solucionadas para evoluir de nvel. A cada nvel a organizao evolui em maturidade e se capacita em atividades e processos (MOLINARI, 2007; PAULA FILHO, 2003). A figura abaixo apresenta os nveis do CMM e suas respectivas reas chaves (KPA):

46

Figura 10 CMM verso 1.1 e seus nveis de maturidade (MOLINARI, 2007)

Para que as metas sejam atendidas existem, dentro de cada rea chave, alguns processos base:

47

Figura 11 Inter - relao dos elementos do CMM (PAULA FILHO, 2003)

As prticas chave so classificados a partir de 5 tipos de caractersticas comuns (PAULK, 1993): Comprometimento em executar; Capacitao para executar; Medio e anlise; e Verificao da Implementao.

3.1.1. rea de processo gesto de configurao

O nvel em que a Gesto de Configurao est presente, uma das reaschave de processo, o Nvel 2 (Repetvel). Ao total so seis reas, conforme imagem anterior: Gerenciamento de Requisitos; Planejamento do Projeto de Software; Acompanhamento e Superviso de Projeto de Software; Gerenciamento de Subcontratados do Software; Garantia de Qualidade do Software; e Gerenciamento de Configurao de Software. Este nvel considerado a base dos processos de gerenciamento de projetos, pois todo o processo de software est sob controles bsicos, estabelecendo um ambiente estvel para se repetir prticas de sucesso vivido em experincias adquiridas em projetos anteriores. Pode-se dizer que um nvel que tem processos

48

disciplinados, desenvolvendo capacidades de gerentes de projetos para estabelecer e monitorar custos, prazos, recursos e funcionalidades no planejamento de projetos, possibilitando aes corretivas diante de problemas identificados evitando a propagao de problemas para as prximas fases do projeto (SOTILLE, 2011; PDUA, 2003; FAGUNDES 2007). A definio para a GC de CMM verso 1.1 (2006, p.114 apud Molinari, 2007, p. 59):
O propsito da Gesto de Configurao de Software (GCS) estabelecer e manter a integridade dos produtos de software de um projeto, atravs do ciclo de vida do mesmo. A GCS parte integral da engenharia de software e do processo de gerenciamento.

Segundo Molinari (2007, p. 59), as metas dessa rea chave so:

Meta 1: as atividades de gesto de configurao so planejadas. Meta 2: os produtos de trabalho de software selecionados so identificados, controlados e disponibilizados. Meta 3: as alteraes nos produtos de trabalho de software identificados so controladas. Meta 4: as equipes e indivduos afetados so informados sobre a situao e o contedo dos baselines de software.

O papel do gerenciamento da configurao do software, como citado acima, manter a integridade do projeto durante todo o ciclo de vida, controlando sua evoluo ao longo do seu desenvolvimento, sendo considerado fundamental para o desenvolvimento de um software de qualidade devido ao grande volume de itens e elementos existentes durante sua produo. parte integrante da maioria dos processos de gerencia e desenvolvimento de software. Os objetivos de GCS so: planejamento das atividades de GCS; identificao e controle dos itens de configuraes; controle dos pedidos de modificaes; propagar as informaes das modificaes aos indivduos envolvidos no desenvolvimento do projeto.

3.2. CMMI

O modelo de Integrao de Maturidade da Capacidade ( Capability Maturity Model Integration), mais conhecido pela sigla CMMI, foi criado pelo SEI - Software

49

Engineering Institute. O objetivo do Instituto de Engenharia de Software era integrar todos os CMMs, que foram criados aps o sucesso do CMM para processos de desenvolvimento de softwares, mas com intuito de atender outras reas de interesse e que tinham sua devida utilidade. Com o grande volume de modelos criados comearam a gerar alguns problemas entre eles como: incompatibilidades de terminologias ou efeitos, padronizao de nveis e avaliaes. Problemas que desencadeava altos custos de treinamentos e dificuldades para organizaes que tentassem usar mais de um modelo, pois causavam incompatibilidades (SOTILLE, 2011). Os modelos existentes criados aps o CMM para software (SW-CMM) eram (SOTILLE, 2011): SA-CMM: Avaliava a maturidade nos processos de seleo, compra e instalao de softwares desenvolvidos por terceiros; SE-CMM: Avaliava a maturidade nos processos de engenharia de sistemas, incluindo o hardware, software e todos os elementos que fazem parte de um produto final; IPD-CMM: Avaliava a maturidade, mais abrangente que o SE-CMM, nos processos referentes a outros processos necessrios para produzir e suporte ao produto, como por exemplo, suporte ao usurio. P-CMM: Avaliava a maturidade nos processos de recursos humanos no que se refere a software, como recrutamento e seleo de desenvolvedores e remunerao. O SEI sentiu a necessidade de se criar um framework nico, que abordasse todas as disciplinas especficas que eram abordadas separadamente (Engenharia de Software, Engenharia de Sistemas, Fontes da Aquisio e Desenvolvimento Integrado do Produto). O CMMI integra outras reas de uma organizao, se tornando um modelo em nvel de abrangncia organizacional no mais apenas software. A principal mudana do CMM para o CMMI, alm de adotar novas disciplinas, foi a possibilidade de a organizao utilizar o modelo de duas formas diferentes: em contnuo e em estgios. O CMM era abordado em estgios, s poderia ser classificada para o prximo nvel enquanto no possusse todo o conjunto de prticas das reas do nvel superior mesmo que possusse prticas de nveis mais superiores (SOTILLE, 2011).

50

Abaixo est a viso geral do modelo CMMI de seus nveis/estgios de maturidade:

Figura 12 Viso Geral de nveis/estgios de maturidade do modelo CMMI (MOLINARI, 2007)

A maturidade, na abordagem por nveis, medida por um conjunto de processos, assim como no CMM. As alteraes que ocorreram da transio do CMM para o CMMI foram nas nomenclaturas, siglas, adio de novas reas de processos e subdiviso em outras novas reas de reas j existentes. O foco est na melhoria dos processos por grupos de reas de processos em nveis de maturidade (VOLPE; JOMORI; ZABEU, 2003). Outra representao do modelo, na abordagem contnua, permite que as organizaes escolham as reas especficas do processo para programar melhorias. Nessa representao no existe nvel de capacidade por categoria, s avaliado o nvel de capacidade por rea de processo individualmente estabelecendo um nvel de maturidade para a organizao, podendo avaliar e planejar atividades de melhoria em processos especficos (SRIA, 2006). As reas contidas nessa abordagem do modelo esto agrupadas em quatro categorias: Gerenciamento de Processos; Gerenciamento de Projetos; Engenharia e Suporte. Apesar das reas estarem divididos por grupos nada impede delas interagirem, pois algumas delas tm efeitos independentemente da definio de grupo. De acordo com o CMMI as categorias e suas respectivas reas so (SEI, 2010):

51

CATEGORIAS DE PROCESSOS DO CMMI CATEGORIAS REAS DE PROCESSOS GERENCIAMENTO DE PROCESSOS Definio do Processo Organizacional (OPD) Foco no Processo Organizacional (OPF) Treinamento Organizacional (OT) Desenho do Processo Organizacional (OPP) GERENCIAMENTO DE PROJETOS Inovao e Desenvolvimento Organizacional (OID) Gerenciamento Quantitativo de Projeto (QPM) Gerenciamento de Riscos (RSKM) Gerenciamento Integrado de Projeto (IPM) Gerenciamento de Acordo com Fornecedores (SAM) Monitoramento e Controle de Projetos (PMC) Planejamento de Projetos (PP) Gerenciamento Integrado de Fornecedores (ISM) ENGENHARIA Integrao de Equipes (IT) Validao (VAL) Verificao (VER) Integrao de Produtos (PI) Soluo Tcnica (TS) Desenvolvimento dos Requisitos (RD) SUPORTE Gerenciamento de Requisitos (REQM) Gerenciamento de Configurao (CM) Garantia da Qualidade de Processo e Produto (PPQA) Medio e Anlise (MA) Anlise e Tomada de Deciso (DAR) Anlise de Causas e Resoluo (CAR) Ambiente Organizacional para Integrao (OEI)
Tabela 1 Demonstrao das categorias na abordagem contnua do CMMI (SEI, 2010)

3.2.1. rea de Processo Gesto de Configurao

52

Definio para Gesto de Configurao de Software de CMMI (BOAS, GONALVES, 2006, p. 127):
O propsito da Gesto de Configurao de Software (GCS) estabelecer e manter a integridade dos produtos de trabalho, usando identificao da configurao, controle de configurao, status da configurao contbil e auditoria da configurao.

Segundo SEI (2010) a Gerncia de Configurao envolve as seguintes atividades: Identificar a configurao de itens de trabalho que compem as baselines durante o ciclo de vida do projeto; Controlar as alteraes de itens de configurao; Manter a integridade dos baselines; e Fornecer informaes precisas a todos os envolvidos (desenvolvedores, usurios finais e clientes) do estado dos itens controlados. As metas e prticas especficas so: - Estabelecer Baselines Esta meta especfica responsvel por estabelecer as baselines. Identificao de itens de configurao: Identificao de itens de configurao compem informaes referentes ao produto e partes integrantes do produto e sua respectiva identificao, como por exemplo, documentaes (SEI, 2010). Estabelecer um Sistema de Gesto de Configuraes: Estabelecer um sistema para controle de configuraes, pelo qual possvel gerenciar alteraes por meio de ferramentas que armazenem informaes de itens de configuraes e sigam procedimentos para registro e acesso s solicitaes de alteraes (SEI, 2010). Criar ou Liberar Baselines: Criar ou liberar um produto (conjunto de especificaes) ou uma etapa do desenvolvimento, ou seja, baseline, que so criados ao evoluir no decorrer do tempo. S pode ser criado ou liberado assim que autorizado pela Comisso de Configurao e documentado o que foi realizado (criado ou alterado) nos itens de configurao contidos no baseline (SEI, 2010). - Rastrear e Controlar Alteraes

53

Depois de especificada as baselines preciso rastrear e controlar as alteraes nos itens de configuraes para manter as baselines. Rastrear solicitaes de alteraes: Todas as solicitaes de mudanas so analisadas para determinar seu nvel de prioridade, impacto das alteraes, custos e cronograma. Solicitaes so registradas, analisadas em relao a contratos, requisitos e impactos, dependendo do caso juntamente com os stackeholders decidindo se ser recusado ou executado. No caso de executar as alteraes, devem ser rastreadas at sua concluso (SEI, 2010). Controlar itens de configurao: Manter o controle da configurao de cada item de configurao sobre as baselines e novos itens que podem vir a surgir, alterando a baseline. Registrando os motivos de alteraes e acompanhar as alteraes para verificar e assegurar o no acontecimento de efeitos indesejveis (SEI, 2010). - Estabelecer Integridade Estabelecer integridade das baselines. Estabelecer registros de Gesto de Configurao: Deve criar histrico de revises de itens de configurao, registro de alteraes, armazenar cpia das solicitaes de alteraes e diferena entre os baselines (SEI, 2010). Executar Auditorias de Configurao: Auditorias de Configurao devem ser realizadas para verificar se as baselines e documentaes esto atendendo aos padres e requisitos especificados, itens de configurao completos, consistentes e precisos (SEI, 2010).

54

3.3. MPS.BR

Melhoria do Processo de Software Brasileiro, mais conhecido pela sigla MPS.BR, um modelo brasileiro lanado em dezembro de 2003 com a participao de sete instituies brasileiras renomadas com competncias complementares na melhoria de processos de software em empresas: SOFTEX, coordenadora do projeto; Universidade do Rio de Janeiro (COPPE/UFRJ), Centro de Estudos e Sistemas Avanados de Recife (CESAR) e Centro de Pesquisas Renato Archer (CenPRA) - trs instituies de ensino, pesquisa e centros tecnolgicos; Companhia de Informtica do Paran (CELEPAR), hospedeira do subcomit de Software da Associao Brasileira de Normas (ABNT); e duas organizaes no governamentais integrantes do Programa SOFTEX (Sociedade e Ncleo de Apoio a Produo e Exportao de Software do Rio de Janeiro RIOSOFT e Sociedade Ncleo SOFTEX 2000). A Universidade Catlica de Braslia (UCB) parceira da COPPE/UFRJ no projeto. A entidade responsvel pelo programa da SOFTEX (Sociedade para Programao da Excelncia do Software Brasileiro), empresa privada e sem fins lucrativos, promovendo aes de empreendedorismo, capacitao, apoio a capitalizao e ao financeiro, e apoio gerao de negcios no Brasil e no exterior, visando aumentar a competitividade da indstria brasileira de software (WEBER et al, 2011). O modelo MPS.BR, criado pelo programa da SOFTEX, conta com o apoio do Ministrio da Cincia e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). O objetivo da criao do modelo foi pelos seguintes fatos (WEBER et al, 2004; MOLINARI, 2007): Existir poucas empresas com avaliao formal CMM/CMMI nos nveis 4 e 5, com foco em empresas grandes e exportadoras de software; Melhorar processos de software em micro, pequenas e mdias empresas, um nmero considerado significativo de empresas para que atinjam os nveis de maturidade 2 e 3 a custo acessvel; E que seja um modelo personalizado para as caractersticas do software brasileiro e sul-americano.

55

Esse modelo foi baseado nos modelos CMM/CMMI e nas normas ISO/IEC 12207 e 15504 e prope-se a ser compatvel com esses modelos e normas. A MPS.BR define sete nveis para definir o nvel de maturidade de uma organizao, caracterizando estgios de melhoria da implementao de processos na organizao. Cada nvel de maturidade atribudo um perfil de processos indicando organizao onde deve estar os esforos de melhoria de processos. O nvel definido atravs de uma combinao entre processos e capacidades. A escala de maturidade se inicia no nvel G progredindo at o nvel mais alto A, conforme a imagem abaixo (SOFTEX, 2011):

Figura 13 Representao da escala de nveis do modelo MPS.BR (SOFTEX, 2011)

Cada nvel tem um conjunto de processos que devem ser habilitados para que possa escalar para o prximo nvel, a seguir a apresentao dos nveis e seus respectivos processos: NVEL A B C PROCESSOS Gerncia de Projetos (GPR) Gerncia de Riscos (GRI) Desenvolvimento para Reutilizao (DRU) Gerncia de Decises (GDE)

56

Verificao (VER) Validao (VAL) Projeto e Construo do Produto (PCP) Integrao do Produto (ITP) Desenvolvimento de Requisitos (DRE) Gerncia de Projetos (GPR) Gerncia de Reutilizao (GRU) Gerncia de Recursos Humanos (GRH) Definio do Processo Organizacional (DFP) Avaliao e Melhoria do Processo Organizacional (AMP) Medio (MED) Garantia da Qualidade (GQA) Gerncia de Portflio de Projetos (GPP) Gerncia de Configurao (GCO) Aquisio (AQU) Gerncia de Requisitos (GRE) Gerncia de Projetos (GPR)

Tabela 2 reas de Processos por nveis de maturidade (SOFTEX, 2011)

3.3.1. rea de Processo de Gesto de Configurao de Software

Conforme visualizado a rea de processo da Gerncia de Configurao est localizado no nvel F. A definio pelo MPS.BR para o propsito da GCS em execuo (SOFTEX, 2011, p. 30):
O propsito do processo de Gerncia de Configurao estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibiliz-los a todos os envolvidos.

Todas as reas de processos no modelo MPS.BR descreve os propsitos e os resultados esperados de cada rea de processo em execuo, permitindo a organizao avaliar e atribuir graus de efetividade, sendo assim os resultados esperados da aplicao de GCS na viso da MPS.BR so (SOFTEX, 2011): Identificao dos itens de configurao;

57

Os itens de configurao gerados pelo projeto so colocados sob uma baseline; estabelecido e mantido um sistema de Gesto de Configurao para controle das modificaes, aes dentro das baselines e controle de liberaes;

O estado e informaes dos itens de configuraes e das baselines so registrados e disponibilizados aos envolvidos durante o ciclo de vida do projeto;

Controle das alteraes e liberaes dos itens de configuraes. Todas as verses devem ser de fcil localizao, assim como as alteraes, para avaliar os motivos de sua criao, diferenas e possvel reutilizao;

Controle do armazenamento, manuseio e liberao dos itens de configurao e baselines. Os itens do software devem ser de fcil rastreabilidade dentro do sistema de Gerncia de Configurao;

E por fim assegurar a integridade das baselines e dos itens de configurao, como sua completude e consistncia de acordo com os requisitos e especificaes de modificaes.

GCS junto de outras reas de processo como: Garantia da Qualidade, Verificao, Validao, Medio, Anlise de Deciso e Resoluo, so considerados processos de apoio contribuindo para o sucesso e qualidade do projeto de software. Responsveis por auxiliar outros processos como (WEBER et al 2004): Gerenciamento de Projetos: pode apoiar no planejamento do processo de Gerncia de Configurao; Anlise de Deciso e Resoluo: pode apoiar na atividade de avaliao de solicitaes de modificao; Anlise de Causas de Problemas e Resoluo: pode apoiar na atividade de solicitaes de modificao, analisando impactos e prioridades das mudanas; E Gerenciamento de Requisitos: pode apoiar a Gerncia de Requisitos no momento de controle de modificaes durante a evoluo do projeto sobre os requisitos levantados.

58

3.4. ISO 15504 (SPICE)

A norma internacional ISO/IEC 15504 estabelece os princpios, requisitos e metodologias a aplicar na avaliao do estado de capacidade e maturidade dos processos das empresas, juntamente com o modelo de processos definidos pela norma ISO/IEC 12207. A norma apresenta uma metodologia genrica para realizao de processos em organizaes. um modelo bidimensional, dimenso dos processos e a dimenso da capacidade, onde a capacidade medida pelo estado dos processos, de acordo com os seus objetivos e resultados esperados, fornecido pelo modelo de normas ISO/IEC 12207 (ANACLETO et al 2005).

Figura 14 Modelo Bidimensional da ISO 15504 (Fonte: HAUCK, 2007).

Essa norma foi desenvolvida pela ISO ( International Organization for Standardization) e pelo IEC (International Electrotechnical Commission) com apoio do projeto SPICE (Software Process Improvement and Capability dEtermination ). Modelo que orienta as empresas para uma melhoria contnua de seus processos tendo como norma de referncia ISO/IEC 12207. A ISO/IEC 15504 a evoluo do SPICE, houve a transio em maro de 2003 com diversas alteraes se tornando uma norma internacional. As reas de processos na norma ISO 15504 so divididas em trs categorias, assim como na norma ISO 12207: Processos Fundamentais; Processos Organizacionais e Processos de Apoio. Ao total so 48 reas de processos

59

adotadas pelo modelo, sendo que dentro de cada categoria os processos so divididos em mais um conjunto, esses conjuntos so denominados de reas de capacidade ou grupos de reas. Todas as reas de processos na organizao so avaliadas, sendo atribudo nesta norma ISO um nvel de capacidade adquirida pela organizao, assim como no CMMI j comentado anteriormente. A capacidade medida por processo, fornecendo uma referncia para melhoria do processo. Os nveis de capacidade e maturidade so constitudos de atributos que devem ser atendidos para aumentar sua capacidade, so ao total seis nveis que variam de 1 a 5: 0 (Incompleto): Processo no existe ou falha; 1 (Executado): Processo executado mas sem padro de qualidade e controle de prazos e custos; 2 (Gerenciado): Planejado e acompanhado, ou seja gerenciado, satisfazendo requisitos de custo, prazo e qualidade; 3 (Estabelecido): Processo executado e gerenciado adaptado definido, eficaz e eficiente; 4 (Previsvel): Processo executado dentro de limites de controle e medies detalhadas e analisadas; 5 (Otimizando): Processo sempre em melhoria contnua de forma disciplinada (HAUCK, 2007). A tabela abaixo representa a estrutura de categorias e seus processos divididos em grupos dentro de cada categoria (HAUCK, 2007): CATEGORIAS FUNDAMENTAIS GRUPOS E SEUS RESPECTIVOS PROCESSOS AQUISIO (ACQ) ACQ.1 Preparao da Aquisio ACQ.2 Seleo do Fornecedor ACQ.3 Acordo Contratual ACQ.4 Monitoramento de Fornecedor ACQ.5 Aceitao pelo Cliente FORNECIMENTO (SPL) SPL.1 Prospeco de Fornecedor SPL.2 Liberao de Produto SPL.3 Apoio para Aceitao do Produto ENGENHARIA (ENG) ENG.1 Elicitao de Requisitos ENG.2 Anlise de Requisitos de Sistema ENG.3 Projeto da Arquitetura de Sistema ENG.4 Anlise de Requisitos de SW ENG.5 Projeto de SW ENG.6 Construo de SW ENG.7 Integrao de SW ENG.8 Teste de SW ENG.9 Integrao de Sistema

60

ENG.10 Teste de Sistema ENG.11 Instalao de SW ENG.12 Manuteno de SW e Sistema

OPERAO (OPE) OPE.1 Operao OPE.2 Suporte ao Cliente ORGANIZACIONAIS GERNCIA (MAN) MAN.1 Alinhamento Organizacional MAN.2 Gerncia Organizacional MAN.3 Gerncia de Projeto MAN.4 Gerncia da Qualidade MAN.5 Gerncia de Riscos MAN.6 Medio MELHORIA DE PROCESSO (PIM) PIM.1 Estabelecimento de Processo PIM.2 Avaliao de Processo PIM.3 Melhoria de Processo RECURSOS E INFRA-ESTRUTURA (RIN) RIN.1 Gerncia de Recursos Humanos RIN.2 Treinamento RIN.3 Gerncia de Conhecimento RIN.4 Infra-estrutura REUSO (REU) REU.1 Gerncia de Ativos REU.2 Gerncia de Programa de Reuso REU.3 Engenharia de Domnio APOIO CONTROLE DE CONFIGURAO (CFG) CFG.1 Documentao CFG.2 Gerncia de Configurao CFG.3 Gerncia de Resoluo de Problemas CFG.4 Gerncia de Requisio de Mudana GARANTIA DE QUALIDADE (QUA) QUA.1 Garantia de Qualidade QUA.2 Verificao QUA.3 Validao QUA.4 Reviso Conjunta QUA.5 Auditoria QUA.6 Avaliao do Produto
Tabela 3 Representao dos processos na norma ISO/IEC 15504 (HAUCK, 2007)

61

3.4.1. rea de Processo Gerncia de Configurao de Software

A rea de processo Gesto de Configurao, como visualizado na tabela acima de processos por grupo e categoria de processos, est classificada como uma rea de apoio s outras reas de processos. Considerada ainda uma das reas para garantia de qualidade do produto. Com a GCS na categoria de apoio, ela d suporte aos processos contidos em outras categorias, tendo relao indireta com as reas de gerenciamento de processo para estabelecer baselines, liberao do produto e principalmente no grupo de processos de Engenharia, processo responsvel pelo desenvolvimento do projeto, a GC controla e monitora todo o decorrer da produo do produto, garantindo que todos os requisitos estaro sendo atendidos. A GCS a base para produzir produtos de qualidade. O objetivo da Gesto de Configurao no SPICE desenvolver e manter a integridade de todos os produtos de um processo ou projeto (MOLINARI, 2007). A GC responsvel por (BARBARESCO, 2000): Identificao e definio dos itens de configurao e estabelecer suas baselines; Definio de uma estratgia da Gesto de Configurao para controle dos elementos de software e suas liberaes (verses). Contendo um plano de configurao descrevendo as atividades da gerncia de configurao, procedimentos e cronograma para execuo das tarefas estabelecidas; Controle de acesso e de mudanas nos itens de configurao. Para o controle das mudanas devem ser realizadas anlises e avaliaes das alteraes a serem realizadas, podendo ser aprovadas ou rejeitadas, se implementadas devem ser tambm verificadas e liberadas; Registrar e notificar os status das modificaes e dos baselines aos interessados em forma de relatrios incluindo o nmero de alteraes realizadas no projeto, as ltimas verses liberadas e suas diferenas; Garantir a integridade e a confiabilidade dos pedidos de mudanas.

62

3.5. Padro ISO 9000

A ISO (International Organization for Standardization ), fundada em 1947, uma organizao sediada em Genebra e que no governamental. um organismo normalizador reconhecido internacionalmente como referncia em Sistemas de Qualidade (MOLINARI, 2011). Sua funo promover a normatizao de produtos e servios, para que a qualidade dos mesmos seja sempre melhorada. A ISO estabelece requisitos que auxiliam na melhoria de processos, resultando na maior capacitao dos envolvidos ao executar processos com qualidade (TAIT, 1998). O foco deste trabalho voltado para as normas que tem correlao com processos de produo de software de qualidade. A ISO 9000 abrange um conjunto de padres com mbitos diferentes. No mbito de fabricao de software existe a norma ISO 9000-3 que faz referncia, especificamente para a rea de desenvolvimento de software, para garantia de qualidade em projeto, desenvolvimento, fornecimento e manuteno de software a norma ISO 9001 (GUSMO; MOURA, 2004). Segundo ROCHA (2001, apud ISO 9000, 2000) Abordagem de Sistemas de Gesto ISO 9000:
Uma organizao que adota esta abordagem gera confiana na capacidade de seus processos e na qualidade de seus produtos, e fornece uma base para melhoria contnua. Isto pode conduzir ao aumento da satisfao dos clientes e das outras partes interessadas e, tambm, ao sucesso da organizao.

Na ISO 9000-3 os processos so divididos em trs partes, e em cada grupo so definidos os seguintes processos: a estrutura de um sistema de qualidade que envolve aspectos organizacionais na produo de software; as atividades do ciclo de vida definem as aes necessrias para as fases ao longo do processo de desenvolvimento; atividades de apoio estabelecem atividades de suporte produo, operao e manuteno de software. Estrutura dos grupos de processos (GUSMO, MOURA, 2004):

63

GRUPOS ESTRUTURA DE UM SISTEMA DE QUALIDADE ATIVIDADES DO CICLO DE VIDA

ATIVIDADES DE APOIO

PROCESSOS Reponsabilidade do Fornecedor Responsabilidade do Comprador Anlise Crtica Conjunta Anlise Crtica do Contrato Especificao dos Requisitos do Comprador Planejamento do desenvolvimento Planejamento da Qualidade Projeto e Implementao Testes e validao Aceitao Cpia, Entrega e Instalao Manuteno. Gerenciamento de configurao Controle de documentos Registros da Qualidade Medio Regras, Prticas e Convenes. Ferramentas e Tcnicas Aquisio Produto de Software Includo Treinamento.

Tabela 4 Representao dos grupos de processos na ISO 9000-3 (GUMO, MOURA, 2004)

A norma ISO 9000-3 abrange todo o ambiente de desenvolvimento, especificando requisitos mnimos para que as organizaes definam seus prprios modelos de gesto de qualidade de acordo com suas caractersticas e negcio. O foco deste padro de qualidade garantir conformidade do produto ou servio ao expectado pelo cliente.

3.5.1. rea de Processo Gesto de Configurao de Software

A Gerncia de Configurao esta classificada no grupo de atividades de apoio da organizao, conforme tabela apresentada acima, no qual participa com atividades de apoio a outros processos do grupo de atividades do ciclo de vida, estando presente no processo de desenvolvimento e manuteno. Sendo assim, um

64

processo base para as outras, garantindo a qualidade e que o produto estar atendendo as expectativas do cliente, criando um produto de qualidade. Segundo MOLINARI (2007, p.65 apud ISO 9000-3, 2006) a ISO 9000-3 descreve GCS da seguinte maneira:
A Gesto de Configurao prov um mecanismo de identificao, controle e rastreamento de verses de cada item de software. Mesmo verses recentes de softwares usados devem ser controladas e mantidas.

Um sistema de GCS tem os seguintes requisitos na ISO 9001 (MOLINARI, 2007): As alteraes no projeto e desenvolvimento devem ser identificadas, registradas, revisada, aprovadas e mantidas; Identificar alteraes nos itens do software que identificam uma verso especfica lanada do produto; Documentos e dados que fazem parte do desenvolvimento e compreenso de requisitos para a fabricao do projeto devem estar sobre controle da GCS tambm; Os resultados, partes do produto, devem ser identificados para rastreamento das mudanas realizadas. Possibilitando assim, um controle simultneo de atualizao de um software; As revises e seus status de construo (em desenvolvimento, entrega, instalao) devem ser armazenados e informados aos envolvidos e interessados nas modificaes; O que no estiver em conformidade deve ser controlado na GCS; Identificar e rastrear todas as aes e mudanas resultantes aps uma requisio de mudana at o fim da concluso da alterao.

65

Captulo 4 METODOLOGIA DE PESQUISA ESTUDO DE CASO

Neste captulo ser demonstrada a metodologia de pesquisa utilizada para verificar na realidade os assuntos mencionados nos captulos anteriores em empresas que desenvolvem softwares.

4.1. Caractersticas Gerais da Pesquisa

Para saber o resultado do problema proposto por este trabalho, foi necessrio utilizar-se do mtodo de investigao, mais conhecido como estudo de caso. Este mtodo de investigao, que caracteriza a pesquisa, possibilita segundo Cervo et al. (2007), estudar um determinado grupo para examinar aspectos variados de sua vida. O grupo mencionado por Cervo, neste trabalho, representado pelas empresas pesquisadas, especificamente na rea de TI. Este mtodo tem como caracterstica o aprofundamento de questes sobre algo de interesse, propiciando o conhecimento e a anlise intensiva do tema abordado em fatos pesquisados e questionados, porm impede que as concluses obtidas sejam generalizadas para outros objetos de estudo, ou seja, proporciona uma viso geral do problema estudado (GIL, 2002; YIN, 2005). O estudo de caso o meio pelo qual se pode obter o objetivo deste trabalho, sendo ele saber como a Gerncia de Configurao de Software pode contribuir s equipes de desenvolvimento, analistas e gerentes de projetos a garantir maior qualidade no desenvolvimento de seus projetos e satisfao de seus clientes e usurios. De acordo com Cervo et al. (2007) e Martins Jnior (2008), a utilizao de estudo de casos justifica-se pelo interesse em analisar a influncia das variveis ambientais externas e internas sobre o desempenho organizacional das instituies, tornando possvel descobrir, atravs dessas anlises e tcnicas, a eficcia de suas estratgias adotadas em relao Gerncia de Configurao de Software.

66

Este trabalho, alm da pesquisa bibliogrfica, aborda um tema pouco explorado no mbito da Tecnologia da Informao, mais especificamente nos processos que dizem respeito ao desenvolvimento de softwares, gerenciamento de projetos e qualidade de software. A pesquisa proposta por este trabalho tenta deixar mais claro a importncia do problema exposto, realizando descries mais precisas da situao, descobrir as relaes existentes entre seus elementos e suas caractersticas. O tipo de pesquisa adotado por este trabalho caracteriza-se por exploratriadescritiva. Gil (2008) destaca que a pesquisa exploratria deve proporcionar uma viso geral acerca de determinado fato, mas realizado somente quando o tema pouco explorado, tornando-se difcil formular hipteses precisas e operacionalizveis. Contribui para o esclarecimento de questes superficialmente abordadas sobre o assunto, reunindo mais conhecimento e caractersticas inditas a respeito do assunto. A pesquisa exploratria um dos primeiros passos para o desenvolvimento de um trabalho cientfico, sendo possvel realizar outro tipo de pesquisa acerca do mesmo tema, e o outro tipo escolhido foi a descritiva, como j mencionado acima, o trabalho caracteriza-se como exploratrio-descritiva. Para Cervo et al. (2007, p. 61), a pesquisa descritiva:
Procura descobrir com a maior preciso possvel, a frequncia com que um fenmeno ocorre, sua relao e conexo com outros, sua natureza e suas caractersticas.

Esta tcnica envolve a utilizao de coleta de dados, sendo que as mais utilizadas so: questionrios e observao sistemtica. Depois de realizado o levantamento dos dados, faz-se necessrio, segundo Andrade (2006), observar, registrar, analisar, classificar e interpretar, sem interferncia do pesquisador. No incio do desenvolvimento deste trabalho a inteno era que no estudo de caso, a partir dos dados colhidos, houvesse uma descrio dos mesmos em carter quantitativo e qualitativo. Mas por algumas dificuldades encontradas ao realizar o estudo de caso, mais detalhado no tpico 4.3 deste captulo que diz respeito s dificuldades encontradas, o trabalho contemplar somente dados qualitativos. Anlise qualitativa, segundo Martins Junior (2008, p.132):
a descrio dos dados obtidos atravs de instrumentos de coleta de dados, tais como: entrevistas, observaes, descrio e relatos.

67

Consiste em buscar a compreenso particular daquilo que se est investigando, no se preocupando com generalizaes, princpio e leis.

A tcnica usada para coleta de dados foi o questionrio (Apndice A), constitudo de 20 questes, sendo uma parte composta por perguntas abertas e outra parte fechadas, direcionada a funcionrios que trabalham diretamente na rea de Gesto de Configurao de Software de vrias empresas, ou seja, um funcionrio representando a aplicabilidade da GCS em cada organizao. Pessoas que conhecem o funcionamento dos processos, que apoiam a aplicabilidade e esta em constante contato com as diversas pessoas envolvidas. Em primeiro instante, a inteno era realizar uma entrevista com essas pessoas, mas essa tambm foi uma das dificuldades encontradas ao realizar o estudo de caso. Isso ser abordado no item que faz referencia as dificuldades encontradas. As respostas e informaes de maior relevncia foram selecionadas e expostas na pesquisa, estando entre essas as respostas diretas, indiretas e observaes que tenham contribudo ao cumprimento dos objetivos propostos pelo trabalho.

4.2. Empresas Objetos da Pesquisa

O questionrio desenvolvido foi entregue a 12 pessoas, cada um representando a rea de TI, em que ele aplica e/ou responsvel por ser gerente/coordenador em Gerncia de Configurao de Software na organizao, ou seja, cada um representante da rea por empresa. Mas uma das dificuldades encontradas no desenvolvimento desta pesquisa tambm, como ser mencionada no prximo tpico, foi a falta de resposta em tempo hbil para anlise e exposio dos dados colhidos. Apenas duas empresas responderam ao questionrio dentro do tempo estipulado, sendo as nicas empresas participantes da pesquisa: a ALSTON do Brasil e o Centro de Processamento de Dados da Polcia Militar do Estado de So

68

Paulo. O prazo passado para que as empresas pudessem colaborar com essa pesquisa, foi de quatro semanas. Ambas as empresas so de grande porte, devido a grande importncia proporcionada por seus ramos de atuao e atividades para o mercado direcionado. Sendo considerada ainda, a rea de TI (Tecnologia da Informao) nessas empresas, um dos setores em que h um grande volume de colaboradores e tambm a importncia dada a este setor. A rea de TI nessas empresas, objetos da pesquisa, colabora no aperfeioamento de processos internos, j existentes, e tambm no desenvolvimento de ferramentas que facilitem a criao e utilizao de recursos, que antes eram difceis ou at impossveis de utilizar, ou ainda inexistentes. Independentemente do tipo de administrao que as empresas se encontram, sejam eles pblicos ou privados. Os setores de TI nessas organizaes exercem um papel muito importante, apoiando-as a continuar sempre atingindo suas metas, misses e objetivos, ou seja, contribuindo nos planejamentos organizacionais e estratgicos. Os setores de tecnologia das organizaes participantes da pesquisa realizada, que desenvolvem projetos de software, se utilizam de prticas e atividades da Gerncia de Configurao de Software como apoio a todo o processo de desenvolvimento.

4.2.1. Empresa ALSTOM

O entrevistado na empresa ALSTOM, atua na rea de qualidade, segurana e confiabilidade na unidade Bandeirantes, sede da empresa no Brasil. um grupo industrial francs que tem atuao nas reas de infraestrutura de energia e transporte ferrovirio, como tambm nos segmentos pertinentes as reas de atuao. uma empresa de capital aberto, administrao privada. J vm alguns anos participando do desenvolvimento da infraestrutura no Brasil, participando dos grandes projetos hidreltricos e termeltricos. No setor ferrovirio est presente com seus produtos e servios (solues tecnolgicas) nas grandes operadoras de passageiros (Ex.: Metr de So Paulo).

69

Os projetos desenvolvidos ou em desenvolvimento abordam o crescimento de infraestrutura vital no pas nas reas de transporte ferrovirio e gerao e transmisso de energia.

4.2.2. Centro de Processamento de Dados da PMESP

O entrevistado coordenador de Gerncia de Configurao de Software no setor Centro de Processamento de Dados (CPD) da instituio Polcia Militar do Estado de So Paulo (PMESP) localizada no municpio de So Paulo. uma empresa de administrao pblica, governamental, cujo foco a prestao de servios ao cidado pela preservao da ordem pblica estadual. Neste setor de CPD so desenvolvidos ferramentas para a automatizao de processos manuais, colaborando para a instituio melhorar processos internos e facilitando o trabalho dos colaboradores para serem melhores executados e mais rpidos. So desenvolvidas novas ferramentas, a partir de recursos externos ao setor, para apoiar a instituio a estar sempre melhorando a execuo de suas metas e objetivos, que manter a ordem pblica.

4.3. Dificuldades Encontradas

Antes de comear o desenvolvimento deste trabalho de pesquisa foi realizado um levantamento da delimitao do tema a ser abordado, do problema a ser explorado, da justificativa para a problemtica apresentada, do objetivo geral do trabalho a ser desenvolvido, dos objetivos especficos e apresentao de uma proposta para estudo de caso. O objetivo proposto nesta etapa em relao ao estudo de caso era alm de conhecer os mtodos e a atual aplicabilidade da Gerncia de Configurao e juntamente da equipe de desenvolvimento, observar e

70

analisar durante determinado tempo as vantagens e desvantagens percebidas pela sua aplicabilidade. O local escolhido para realizar o estudo de caso seria o setor Centro de Pesquisas (CEPE) da instituio de ensino Faculdade de Tecnologia de So Paulo (FATEC-SP), previamente concordado pela responsvel do setor e a direo da faculdade. Mas por motivos no muito claros o autor deste trabalho foi impedido de realizar a coleta de dados e observar o trabalho cotidiano, realizado pelos responsveis por gerenciar a rea de TI e da equipe de desenvolvimento. A soluo encontrada para continuar a pesquisa foi entrevistar funcionrios em empresas de TI, e colher dados qualitativos e quantitativos, para conseguir informaes mais completas a respeito do assunto e continuar mantendo a caracterstica do estudo de caso apresentado no incio deste trabalho. A partir deste grande grupo de pessoas entrevistadas, conseguir extrair anlises e comparaes mais maduras e de grande representatividade a respeito do problema apresentado, em empresas de Tecnologia de Informao que utilizam a GC direta ou indiretamente. O ideal seria entrevistar as pessoas envolvidas diretamente com a rea de Gesto da organizao, mas houve alguns empecilhos por parte das empresas, sendo sugerido o envio de questionrio ao responsvel pelo responsvel da rea, tornando esta a nica forma de colher os dados. Foi desenvolvido um questionrio, com questes de mltipla escolha e dissertativas, e enviado via e-mail para as pessoas consideradas chave para a pesquisa em cada organizao. O tempo estipulado para retorno das respostas foi de 3 a 4 semanas, consideravelmente largo, para conseguir o mximo de questionrios respondidos e maior tranquilidade nas respostas. Das dificuldades encontradas, a maior foi que do total de empresas que receberam o questionrio, apenas duas responderam. As anlises e concluses, resultantes do estudo podem ser utilizadas somente em empresas que tenham as mesmas caractersticas organizacionais e gerenciais no setor de TI.

71

Captulo 5 ANLISE E DISCUSSO DOS RESULTADOS

Conforme dito, nos captulos e tpicos anteriores, o objetivo deste trabalho pesquisar a Gerncia de Configurao de Software sob suas prticas, principais modelos e normas, para qualidade de software juntamente do gerenciamento de projetos em que faz parte. Neste captulo ser realizada uma anlise e discusso dos dados obtidos o pelas empresas que responderam ao questionrio enviado via e-mail.

5.1. Questionrio

O questionrio foi montado, afim de que, posteriormente para anlise dos dados colhidos, os mesmos pudessem ser avaliados e classificados. As questes dissertativas foram desenvolvidas, com o objetivo de: - Colher maiores informaes e detalhes a respeito dos benefcios identificados pela equipe e responsvel por acompanhar a aplicabilidade da GC no processo de desenvolvimento e manuteno de softwares; - E da mesma forma, conhecer as dificuldades encontradas ao implantar a Gesto de Configurao; - Saber se a maneira adotada pela organizao para gerenciar a qualidade de software e o desenvolvimento de projetos adotam a gesto especfica. J nas questes de mltipla escolha, o enfoque foi descobrir: - O grau de satisfao de toda a organizao com os resultados obtidos na qualidade do software e na rpida soluo de problemas correntes na fabricao de software; - O grau de eficincia e benefcios adquiridos; - E o grau de dificuldade em sua adoo. A anlise desenvolvida teve como principal foco a avaliao dos seguintes itens:

72

- Benefcios percebidos aps a aplicao da GCS na organizao; - A importncia, ou no, da adoo de um modelo, de qualidade de software e conjunto de prticas para gerenciamento de projetos, em que a GCS utilizada; - Dificuldades na implantao e utilizao da GC, se integrante nos processos existentes. Os dois tipos de questes, dissertativas e de mltipla escolha, se complementam. Pois os resultados obtidos atravs da anlise foram fundamentados nos pontos mencionados acima, pois ajudam a responder a problemtica apresentada e atende aos objetivos levantados no incio deste trabalho. As anlises sero dividas para cada empresa. Aps as anlises ser realizado uma comparao entre os resultados, para verificar resultados comuns e diferentes em relao a utilizao, de ambas empresas, da Gerncia de Configurao.

5.2. ALSTON

A empresa utiliza um modelo de maturidade como referncia para prticas genricas e especficas. O modelo utilizado pela organizao CMMI verso 1.2. Este modelo contribui para a maturidade e capacidade em diversas disciplinas, conforme abordado na sesso 3.2 do captulo trs, nesta sesso contm informaes detalhadas em relao aos seus conceitos e como o funcionamento de ascenso aos nveis de maturidade e capacidade superiores. Neste modelo a Gesto de Configurao citada como uma das reas de processos de maior importncia. Antes do CMMI v1.2 os processos originais utilizados pela empresa eram baseados no SW-CMM da SEI. O nico item que era adotado pelo pessoal de desenvolvimento, que faz parte de um processo de gerencia de configurao, era a utilizao de uma ferramenta de controle de verso de cdigo nomeada como Rational Clearcase Telelogic CM Synergy. A nica diferena do CMMI apresentado neste trabalho para o aplicado pela ALSTON um dos processos que controla o ciclo de desenvolvimento de software,

73

pois foi adaptada com referncia a uma norma que era utilizada antes do CMMI, segundo o entrevistado, a CENELEC EN 50128 chamada de Modal Safety.

5.2.1. Benefcios

Um dos itens que foi analisado na pesquisa foram os benefcios trazidos pela utilizao da Gerncia de Configurao, incluso no modelo de maturidade CMMI. O grau de benefcios percebido pelo entrevistado, representado todas as pessoas da rea de TI que tem contato direta ou indiretamente com esta gerencia especfica, foi classificado, em uma escala de 0 a 10, onde zero indica o menor grau de importncia e dez o maior grau. Para a ALSTON, o grau de benefcios segundo o entrevistado, classificado de seis a oito. Comentando ainda que aps a adoo da GCS, ao longo do tempo em que o processo estava sendo implementada, ela auxiliou na compreenso e resgate de toda a equipe de valores, sem muita importncia no passado e hoje o oposto. Valores que ajudam na soluo de problemas relacionados ao desenvolvimento e manuteno de software, que antes de se tornarem algo complexo e consequentemente demande maiores esforos e tempo, hoje pode ser resolvido com algumas atividades do processo que limita a quantidade de problemas e at mesmo quando inevitvel sua ocorrncia, acaba sendo de menor complexidade no ocasionando maiores transtornos a equipe de desenvolvimento e aos gerentes e analistas de projetos. O efeito positivo proporcionado pela GC, avaliado pelo entrevistado, foi considerado forte. Dentre os benefcios apontados esteve o fato de obter um controle maior dos entregveis, no sendo restrito ao ambiente de desenvolvimento de software. Esse controle diz respeito ao total suporte gerencial e operacional que a GC fornece durante todo o processo de fabricao e manuteno, apoiando a equipe de desenvolvimento no resgate de documentos, controle das alteraes realizadas, rastreabilidade do cdigo, controlando as mudanas impostas, alm de contribuir com o ambiente, como o prprio entrevistado cita, de desenvolvimento de software a

74

atingir o que foi planejado e a validar requisies de alteraes ou novas implementaes. Outra varivel percebida pelo entrevistado foi a certeza de reduo de custos por conta do exerccio de algumas atividades mencionadas no pargrafo anterior. Houve reduo do Backlog durante o perodo em que a GCS esteve presente, em outrora, em sua ausncia era o contrrio. Isso devido padronizao do controle dos artefatos do software, consequncia da adoo da Gesto de Configurao. A eficincia da adoo foi classificada de seis a oito, um grau de satisfao considerado muito bom, pois comparado com outro perodo, os benefcios proporcionados foram bem melhores do que em outra poca que a GC no era considerada no mbito de desenvolvimento e manuteno de softwares.

5.2.2. Dificuldades na implantao

Outro ponto considerado muito importante para anlise deste trabalho foi as dificuldades encontradas na implantao da Gerncia de Configurao seja ela por um modelo reconhecido comercialmente de desenvolvimento de software e qualidade ou uma metodologia prpria criada para o formato da empresa. O grau de dificuldade da implantao da GC apontado pelo entrevistado foi classificado de 9 a 10, ou seja, foi a representao do grau mximo da dificuldade encontrada no incio da implantao. Mas por outro lado, depois de concludo, a fase de implantao o grau de eficincia da aplicabilidade teve uma avaliao muito boa. No incio do processo de implantao da GCS, foi orientado ao controle da documentao do projeto de software at abranger o software em si. A cada fase da implantao que ia passando foram aumentando o controle e o suporte da GC nos projetos. Segundo o entrevistado, questes referentes ao controle dos requisitos alcanados sobre o desenvolvimento de funcionalidades e manuteno de cdigo, mais especificamente sobre o corpo do cdigo fonte, foram compreendidas no processo recentemente.

75

De acordo com o entrevistado, com a utilizao da GCS houve diminuio de custos significativos em relao ao perodo em que a GC no estava presente na empresa, mas por outro lado, com sua adoo o processo obrigou a alocar custos em recursos extras que outrora no eram alocados.

5.2.3. Importncia

Uma das vertentes analisadas por esta pesquisa foi a importncia da Gerncia de Configurao expressada pela empresa, rea de desenvolvimento e manuteno de software, processo que esta incluso no modelo de maturidade e capacidade adotado pela organizao. O grau de importncia avaliado foi classificado pelo entrevistado de nove a dez, ou seja, o grau mximo de importncia percebida pela empresa a respeito da GC. Um dos fatores levados em considerao, e que contribuiu para a importncia da Gesto de Configurao, so os benefcios trazidos pelas atividades de suporte gerencial e operacional que acompanham todo o processo de fabricao e manuteno do produto. A importncia da GCS foi avaliada baseando-se nos benefcios, eficincia e efeitos positivos que segundo o entrevistado influencia diretamente na importncia que tem na rea de desenvolvimento e manuteno do software. Dos benefcios, positividade e eficincia proporcionada esto alguns pontos bsicos, mas considerados importantes no mbito da fabricao do produto, tais como: produtividade, maior controle dos entregveis, reduo de custos e maior controle sobre o backlog. Das avaliaes propostas pelos questionrios para analisar as vantagens da adoo do processo da Gerncia de Configurao acompanhando as equipes de desenvolvimento e manuteno de software, segundo as respostas do entrevistado, so de grande importncia para contribuir no desenvolvimento de softwares de qualidade.

76

Generalizando o resultado dos dados colhidos da empresa ALSTOM, a GC pontuaes muito boas, demonstrando a satisfao e a contribuio desta gerencia especfica na soluo de problemas intrnsecos e benefcios extras a rea e aos integrantes.

5.3. CPD da PMESP

Atualmente o setor de CPD (Centro de Processamento de Dados) da PMESP (Policia Militar do Estado de So Paulo), segundo o entrevistado, utiliza uma metodologia de desenvolvimento de sistemas interna, no seguindo especificamente nenhuma metodologia conhecida. Este modelo adotado foi desenvolvido internamente pelo setor baseado em vrios modelos conhecidos, utilizando uma parte de cada uma delas, adaptando-as de maneira que seja possvel conseguir um processo gerencial e operacional no setor para que o que for desenvolvido baseado nessa metodologia adquira maior eficincia, qualidade e melhoria contnua dos processos internos do setor. Para o entrevistado, o processo da Gesto de Configurao uma das disciplinas que fornecem suporte a todos os outros processos envolvidos direto ou indiretamente ao mbito de fabricao de um produto de software. Alm de apoiar na garantia de melhoria contnua desses processos integrantes. Antes da escolha do setor pela criao de um modelo complementar baseado em outro modelo e normas como: o CMMI para o desenvolvimento, a NBR ISO 10007 de 2005 com diretrizes para a gesto de configurao e NBR ISO/IEC 12207 de 1998 para os processos de ciclo de vida de software e processos de Gerncia de Configurao, era utilizado outro modelo interno, mas baseado especificamente no processo proprietrio RUP (Rational Unified Process) ou Processo Unificado Racional que fornece tcnicas apoiada por ferramentas vendidas pela IBM para a equipe de desenvolvimento de software a fim de aumentar a produtividade das equipes. A GCS exercia tambm neste modelo, adotado anteriormente, tarefas e ferramentas voltadas para o controle das mudanas e desenvolvimento de cdigosfonte.

77

5.3.1. Benefcios

Uma das anlises considerada principais por este trabalho foi a anlise dos benefcios proporcionados pela implantao dos processos da Gesto de Configurao no setor de Processamento de Dados da instituio governamental. O grau dos benefcios percebidos pelo entrevistado no mbito do desenvolvimento e manuteno de software foi classificado dentre seis e oito, considerado por ele bom, comparado no perodo anterior em que era utilizado outro modelo, levando em considerao os quesitos de organizao de diretrizes e processos de apoio da Gerncia de Configurao de Software juntamente dos processos de ciclo de vida dos sistemas. Dentre os benefcios percebidos esto: - Maior controle sobre os cdigos-fonte; - Melhoria do processo de desenvolvimento desde o levantamento de requisitos, manuteno e atualizao de cdigo fonte e documentao; - Rastreabilidade e versionamento de cdigo liberado para a produo; - Rastreabilidade de toda a alterao efetuada em um cdigo fonte. Outros benefcios, comentado pelo entrevistado, a confiabilidade no cdigo fonte que ser colocada em produo e a rastreabilidade das ltimas alteraes que foram realizadas na ltima verso lanada, e principalmente reduo de retrabalhos corrigindo erros que voltam a aparecer, mas que j foram corrigidos em verses anteriores. Benefcios esses que antes eram problemas que frequentemente ocorriam e tornavam-se problemas complexos demandando maiores esforos para que o tempo de entrega das funcionalidades dos projetos no ficasse comprometido por problemas correntes. Muito dos motivos apresentados para se realizar manutenes em cdigo por motivo de no atendimento por parte do processo de desenvolvimento do software de no compreenderem os requisitos levantados e, por conseguinte no os atenderem. Com a adoo da GC isso minimizado por uma com a documentao das solicitaes de mudanas, avaliao de necessidade e prioridade das mesmas, sendo posteriormente passado por uma validao das alteraes e validando se estiver atendendo ao solicitado. Mesmo quando inevitvel o surgimento de problemas, se torna fcil e rpido o seu rastreamento, fornecendo tempo hbil para gerentes, analistas e

78

desenvolvedores suport-los e entrarem com recursos necessrios para resolv-los sem grandes impactos nos entregveis. A ferramenta utilizada pelo setor para versionamento do cdigo fonte o Subversion (Apache Subversion software Project). Os efeitos positivos percebidos pelo entrevistado foram classificados como forte principalmente pelos benefcios proporcionados pela aplicao do processo da GC. A eficincia foi classificada no grau mximo, de nove a dez, ou seja, foram timos os resultados obtidos pelas atividades da Gerncia de Configurao.

5.3.2. Dificuldades na implementao

Outro fator de anlise para este trabalho a anlise das dificuldades da implantao de GCS. O grau de dificuldade de adoo do processo da GC, segundo o entrevistado, classificado entre seis e oito, sendo razoavelmente grande. As dificuldades encontradas foram em especial ao comportamento dos envolvidos, tanto desenvolvedores quanto dos lideres de projeto, pois para que fossem alcanados os objetivos propostos pela Gerencia de Configurao seria necessrio executarmos novas atividades e tarefas, no podendo simplesmente deixar de serem executadas ou ainda que sim executa-las de qualquer maneira. De acordo com o entrevistado, a dificuldade por parte do lder de projeto foi o aumento de suas atividades como, por exemplo, abertura de solicitaes de mudanas, por mais simples que seja essa atividade e ainda com a utilizao de uma ferramenta de apoio para lanamento dessas solicitaes de mudanas via sistema web. Por parte dos desenvolvedores, mesmo havendo treinamentos e disponibilidade de um mentor da aplicabilidade da Gerencia de Configurao, por muitas vezes, segundo o entrevistado, no planejavam corretamente o tempo de desenvolvimento e ao final do projeto queriam colocar uma verso no ar sem passar pelo controle de verso e outras atividades passveis de serem executadas pela

79

gerencia especfica para que finalmente uma verso possa ser criada e consequentemente colocada em funcionamento. Aps a implantao passar pela fase inicial, as dificuldades encontradas no inicio foram resolvidas com a compreenso dos envolvidos a cada resultado positivo percebido. Mas das dificuldades encontradas a maior estava na organizao das novas atividades e tarefas que deveriam ser exercidas pelo novo modelo de metodologia de desenvolvimento de sistemas criado pelo setor.

5.3.3. Importncia

Outra anlise importante, considerada por este trabalho, foi a importncia da aplicabilidade da Gerncia de Configurao no setor de TI da instituio. A importncia avaliada pelo entrevistado foi classificada no grau mximo, de nove a dez, o setor, de acordo com o entrevistado, reconhece a total importncia da utilizao das atividades e tarefas da Gesto de Configurao do Software. Os benefcios proporcionados, a eficincia e os efeitos positivos percebidos so os motivos da causa do grande reconhecimento da importncia compreendida do setor por esta gerencia especfica. Com a experincia obtida pelo setor da utilizao deste processo, analisou-se que os efeitos proporcionados pela GC foram devido a sua total cobertura de suporte gerencial e operacional para as equipes de desenvolvimento e manuteno dos projetos. No s contribuindo com tarefas externas de acompanhamento do que desenvolvido, manutenido e criao de builds, mas tambm tarefas e atividades que influenciam o ciclo normal de vida do desenvolvimento de um software. Dos efeitos produzidos, o mais evidente a cada verso lanada e/ou funcionalidades criadas a qualidade percebida pelo atendimento aos requisitos das solicitaes das funcionalidades e os entregveis estarem sempre, de acordo com o entrevistado, dentro do prazo estipulado. Evidenciando a importncia das atividades contidas em GC com relao a validao do que foi produzido e seus requisitos, e tambm as anlises de importncia e necessidade das solicitaes enviadas s equipes de desenvolvimento. Ou seja, conseguindo controlar o que ser realmente

80

necessrio produzir, os critrios que identifiquem a solicitao e principalmente a validao das implementaes em relao aos requisitos para ela antes levantados, para que no seja entregue ao cliente ou at mesmo colocado em produo algo que no esta de acordo com o esperado e/ou com falhas, erros ou bugs.

5.4. Comparao dos Dados

Partindo dos dados colhidos, da empresa ALSTOM e do setor Centro de Processamento de Dados da instituio da Polcia Militar do Estado de So Paulo, possvel abstrair algumas concluses a respeito das dificuldades, benefcios, e importncia da aplicabilidade da Gerncia de Configurao de Software no processo de desenvolvimento e manuteno de softwares. Independente do tipo de administrao que as empresas esto inseridas, pblicas ou privadas, e o ramo de atividade em que elas esto localizadas, havendo um setor da rea de TI com equipes de desenvolvimento e manuteno grandes ou pequenas, adotando uma metodologia, com processos e atividades especficas para o desenvolvimento e qualidade de softwares, reconhecida ou no se percebe que a Gerncia de Configurao exerce atividades e tarefas de suma importncia, fornecendo suporte gerencial e operacional para o alcance dos objetivos propostos no mbito de desenvolvimento de software e apoio para gerentes e desenvolvedores na resoluo de problemas intrnsecos ao processo de fabricao e de manutebilidade de softwares. Essa importncia pode ser verificada nos relatos dos entrevistados, indicando os motivos para a adoo desse processo aos j existentes. Modelos, normas e padres ressaltam tambm a importncia da aplicabilidade desta gerncia no ciclo de vida de um software, ajudando as empresas e setores de Tecnologia de Informao a conseguirem algo de desejo nesta rea, que a qualidade, confiabilidade e integridade do produto a ser colocado em funcionamento, atendendo os requisitos propostos pelo cliente e o comum desejo entre ele e os envolvidos no desenvolvimento de um software que a qualidade.

81

Para ambas empresas a Gerncia de Configurao de Software um processo de muita importncia, sendo avaliado no grau mximo, de nove a dez. Isso porque os benefcios, a eficincia e os efeitos positivos identificados por cada um deles foram fortemente evidenciados. De zero a dez foram avaliados os benefcios adquiridos pela Gerncia de Configurao nos setores das empresas, sendo que uma demonstrou mais satisfeita, demonstrado pelo grau mximo na avaliao, do que a outra. A PMESP avaliou o grau dos benefcios trazidos de nove a dez, quanto que na ALSTOM foi avaliado dentre seis e oito. Mas os benefcios apontados por cada um deles tiveram avaliaes bem parecidas, melhores do que em outro perodo que no existia um processo de GCS ou ainda mesmo existindo no era completamente aplicado. Por exemplo, na ALSTOM, no havia uma padronizao e controle sobre os artefatos, no provendo o controle ideal dos entregveis ficando restrito somente ao mbito do processo de desenvolvimento de software, podendo frequentemente ocorrer problemas no ciclo de vida do software impactando nos prazos e custos com esforos que hoje se tornaram desnecessrios, alm de reduzir manutenes corretivas, necessrias para corrigir falhas de requisitos e de necessidades implementadas que no seguiram os critrios esperados. O resultado da anlise de eficincia da GC em ambas foi avaliado de bom para timo, para a ALSTOM foi levemente menos eficiente comparado ao resultado do CPD da PMESP, que avaliou com o grau mximo de nove a dez, quanto que a ALSTOM avaliou de seis a oito. Essa avaliao da ALSTOM foi indicativa de bom para timo a eficincia da GCS, pois comparado a outro perodo, o entrevistado afirmou que hoje se obtm maior controle das alteraes e benefcios identificados por essa aplicabilidade que fez com que toda a equipe de desenvolvimento compreendesse valores da aplicao do processo que antes eram invisveis, segundo o entrevistado, no passado. O grau de dificuldade da adoo do processo de GCS foi considerado alto pelas empresas, objeto da pesquisa, sendo que para o CPD da PMESP foi levemente, comparado a ALSTOM, menos difcil, pois foi classificado no grau de dificuldade entre seis e oito, j ALSTOM entre nove e dez. Apesar da diferena entre as duas a implantao da Gerncia de Configurao para ambas, de acordo com os entrevistados, no foi fcil. Principais motivos das dificuldades levantados pelas empresas foram:

82

- A compreenso, no incio da aplicabilidade das atividades e tarefas da GCS, da sua importncia; - A seguir todos os processos da GC, por mais simples que seja, corretamente por todos os envolvidos no processo; - E dependendo da forma como as atividades e tarefas, desta gesto especfica, so introduzidas pelo modelo de desenvolvimento de sistemas da organizao, pois dependendo da maneira como so distribudas podem influenciar na compreenso e execuo por parte dos envolvidos no processo.

83

Captulo 6 CONSIDERAES FINAIS

Os motivos levados em considerao para a realizao deste trabalho foi a descrio de uma disciplina que desse suporte rea de sistemas, que atualmente pouco estudada, que apoiasse o processo de desenvolvimento e manuteno de softwares, o entendimento de uma gesto especfica para a resoluo de problemas tradicionalmente conhecidos no mbito de equipes de desenvolvimento e principalmente um processo que contribusse na busca pela qualidade do software entregue ao cliente e no processo de desenvolvimento. O problema abordado por este trabalho foi como a Gerncia de Configurao, uma gesto especfica, pode apoiar gerentes e desenvolvedores na garantia de qualidade no processo de desenvolvimento de softwares e consequentemente dos projetos produzidos. Dentre os modelos e normas mais conhecidos, nacional e internacionalmente, no quesito processos de fabricao e qualidade de software foi averiguado em pesquisa bibliogrfica que a Gesto de Configurao considerada uma das disciplinas mais importantes para o alcance de qualidade, atravs do controle sistemtico e execuo de atividades e tarefas especficas dando suporte gerencial e operacional durante todo o ciclo de vida. Foi utilizado o mtodo de estudo de caso, por este trabalho de pesquisa, para avaliar quais os benefcios, a importncia, os efeitos positivos e o grau de eficincia proporcionado em equipes de desenvolvimento que utilizam um modelo/norma em que a Gerncia de Configurao est presente. Dos resultados obtidos pelas empresas que responderam o questionrio no foi encontrado inconformidades da teoria descrita por este trabalho. Importante salientar que os resultados obtidos pelas empresas objetos da pesquisa, s podero ser considerados em setores e equipes que tenham a mesma caracterstica gerencial e operacional. Os resultados obtidos, segundo os entrevistados, foram de grande importncia devido aos valores e efeitos positivos adquiridos pelas equipes de desenvolvimento, pela garantia de qualidade dos produtos de softwares produzidos

84

e maior eficincia proporcionada pela GCS nos processos de fabricao e manuteno de software de qualidade. A contribuio proporcionada por este trabalho est relacionada ao pouco contedo informativo e estudos desenvolvidos e divulgados a respeito da Gerncia de Configurao de Software. No Brasil muito reduzido o nmero de livros em lngua portuguesa que tenham uma abordagem mais completa a respeito desta rea. um assunto amplo que pode ser distribudo em outros ramos de pesquisa, pois o objetivo proposto por este trabalho foi apenas demonstrar que a GC pode apoiar os envolvidos a resolverem problemas relacionados ao desenvolvimento do software, evidenciando a importncia da adoo desta disciplina especfica juntamente do software.

85

REFERNCIAS

ANACLETO, Alessandra; GRESSE VON WANGENHEIM, Christiane; SALVIANO, Clnio F. Um Mtodo de Avaliao de Processos de Software em Micro e Pequenas Empresas. In: SBQS Simpsio Brasileiro de Qualidade de Software , Porto Alegre, 2005. BARBARESCO, Eduardo Alexandre. Software de apoio ao processo de gerncia da configurao segundo normas e modelos da qualidade . Trabalho de Concluso de Curso (Bacharelado em Cincias da Computao) - Centro de Cincias Exatas e Naturais, Universidade Regional de Blumenau, Blumenau, 2000. BARRETO JUNIOR, Jos. Qualidade de Software. Disponvel em: <http://www2.unemat.br/rhycardo/download/qualidade_em_software.pdf> Acesso em 25/11/2011 BOAS, Andr Villas; GONALVES, Jos Marcos. CMMI para Desenvolvimento, verso 1.2 CMMI-DEV, 1.2: Verso Traduzida . Disponvel em: <http://pt.scribd.com/ms9840/d/65995312/7-GARANTIA-DA-QUALIDADE-DEPROCESSO-E-PRODUTO#page=9>. Acesso em 25/11/2011 BORGES, L. S., FALBO, R. A. Gerncia de Conhecimento sobre Processos de Software In: VIII Workshop de Qualidade de Software - XV SBES . Rio de Janeiro: Anais do VIII Workshop de Qualidade de Software, 2001. CAROSIA, Jaciara Silva. Levantamento da Qualidade do processo de software com foco em pequenas organizaes. So Jos dos Campos: INPE, 2003. CERVO, Amado L.; BERVIAN, Pedro A.; SILVA, Roberto da. Metodologia Cientfica. 6. ed. So Paulo SP: Prentice Hall, 2007. 176 p. DIAS, ANDR FELIPE. Conceitos Bsicos de Controle de Verso de Software Centralizado e Distribudo. Disponvel em: <http://www.pronus.eng.br/ artigos_tutoriais/gerencia_configuracao/conceitos_basicos_controle_versao_centrali zado_e_distribuido.php> Acesso em 14/08/2011

86

Estublier, J.; Leblang, D.; Geoff Clemm et al. Impact of the Research Community on the Field of Software Configuration Management , ACM SIGSOFT Software Engineering Notes, vol. 27, no. 5, 2002 Estublier, J.; Leblang, D.; van der Hoek et al. Impact of Software Engineering Research on the Practice of Software Configuration Management . ACM Transactions on Software Engineering and Methodology, 2005. Fagundes, Eduardo Mayer. Capability Maturity Model for Software .Disponvel em <http://www.efagundes.com/artigos/CMM.htm>, acessado em novembro de 2007. GIL, Antonio Carlos. Como elaborar projetos de pesquisa. 4. ed. So Paulo: Atlas, 2002. GIT. Software Configuration Management. Disponvel em: <http://git-scm.com/> Acesso em: 18/04/2012 GOMES, Nelma da Silva. Qualidade de Software - Uma necessidade . Disponvel em: <http://www.fazenda.gov.br/ucp/pnafe/cst/arquivos/Qualidade_de_Soft.pdf> Acesso em 25/11/2011. GUSMO, C. M. G. ; MOURA, H. P. . Gerncia de Risco em Processos de Qualidade de Software: uma Anlise Comparativa. SBQS 2004 - III Simpsio de Brasileiro de Qualidade de Software, Braslia. Anais de 2004. HAUCK, Jean Carlo Rossa ; GRESSE VON WANGENHEIM, C. ; THIRY, Marcello . Suportando a Modelagem de Processo de Monitorao e Controle em Micro e Pequenas Empresas, alinhado ao CMMI, MPS.BR e ISO/IEC15504. In: SBQS Simpsio Brasileiro de Qualidade de Software , 2007, Porto de Galinhas. Anais de 2007. IEEE. Institute of Electrical and Electronics Engineers. Disponvel em: <http://www.ieee.org/index.html> Acesso em 12/12/2011 ISO/IEC 12207. Information technology - Software life cycle processes . 1995. Disponvel em: <http://www.math.unipd.it/~tullio/IS-1/2009/Approfondimenti/ISO _12207-1995.pdf> Acesso em 10/01/2012

87

KOSCIANSKI, A. Soares, M. S. Qualidade de Software. 2 ed. So Paulo: Novatec. 2007 LIMA REIS, C. A. Uma Abordagem Flexvel para Execuo de Processos de Softwares Evolutivos (Tese de Doutorado) . Porto Alegre: PPGC-UFRGS. 2003. MARTINS JUNIOR, Joaquim. Como escrever trabalhos de concluso de curso: Instrues para planejar e montar, desenvolver, concluir, redigir e apresentar trabalhos monogrficos e artigos. 2. ed. Petrpolis - RJ: Vozes, 2008. 169 p. MCT/SEPIN, Ministrio da Cincia e Tecnologia / Secretaria de Poltica de Informtica. Programa Brasileiro de Qualidade em Software 2001 . 4 ed. Braslia: Editora Brazilian Software, 2002. MOLINARI, Leonardo. Gerncia de Configurao - Tcnicas e Prticas no Desenvolvimento do Software. Florianpolis: Visual Books, 2007. MURTA, L.G.P., WERNER, C.M.L. Proposta de Arquitetura de Gerencia de Configurao para Ambientes de Reutilizao . Rio de Janeiro: COPPE/UFRJ, 2003 OLIVEIRA, ANGELINA, A. A. C. P., et al. Gerncia de Configurao de Software, Evoluo do Software sob controle. ITI Instituto Nacional de Tecnologia da Informao, Laboratrio de Avaliao e Melhoria de Processos de Software, Campinas SP. 2001 PACHECO, R. F. Uma Forma de Avaliao de Implantao de Gerenciamento de Configurao de Software em Empresas de Pequeno Porte (Dissertao de Mestrado). Instituto de Cincias Matemticas e de Computao de So Carlos ICMC - Universidade de So Paulo, So Carlos, Outubro de 1997. PAULA FILHO, Wilson de Pdua. Engenharia de software: fundamentos, mtodos e padres. 2 ed. Rio de Janeiro: Editora LTD, 2003. PAULK, M. C.; CURTIS, B.; CHRISSIS, M. B. et al. Capability Maturity Model for Software. Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-24.1993. PBQP - Programa Brasileiro da Qualidade e Produtividade - Subcomit Setorial da Qualidade e Produtividade em Software (2002). Qualidade e Produtividade no Setor de Software Brasileiro Pesquisa 2001. Disponvel em <http://www.mct.gov.br/index.php/content/view/2867.html>. Acesso em: 18/01/2012.

88

PRESSMAN, Roger S.. Engenharia de Software. Books, 1995. 85-346-0237-9

So Paulo: Pearson Makron

___________________. Engenharia de Software. 6 ed. So Paulo (SP): MacGraw-Hill, 2006. 720p. ___________________. Software Engineering: A Practitioners Approach . 2005. McGraw - Hill, 6th ed, New York. Rocha, A. R. C.; Maldonado, J. C.; Weber, K. C. Qualidade de Software: Teoria e Prtica. So Paulo: Prentice Hall, 2001. SEI - Software Engineering Institute. CMMI fir Development version 1.3 . Pittsburg, PA: Carnegie Mello University, CMU/SEI, 2010. SOFTEX Associao para Promoo da Excelncia do Software Brasileiro. MPS.BR Melhoria de Processo do Software Brasileiro . Campinas: Sociedade SOFTEX, 2011. SOMMERVILLE, Ian. Engenharia de Software: So Paulo (SP): Addison-Wesley. 2006. ________________. Engenharia de Software. 8 ed. So Paulo (SP): Pearson Prentice Hall, 2008. 552p. SRIA, Felipe Grando. Implantao do CMMI: Metodologia baseada na abordagem por processos. Curitiba: Pontifcia Universidade Catlica do Paran, 2006. SOTILLE, Mauro. PMBok & CMM + CMMi Resumo. <http://www.pmtech.com.br/artigos/PMBOK&CMM+CMMI.pdf> 25/11/2011 Disponvel Acesso em: em

TAIT, T.F.C.; BARCIA. R.M.& PACHECO.R. Uma arquitetura de sistemas de informao para integrar aspectos tcnicos e organizacionais nos sistemas de infomlao. Anais do XVIII Encontro Nacional de Engenharia de Produo e IV Congresso Intemacional de Engenharia Industrial . Niteri/RJ.1998.

89

VALERIANO, Dalton L. Gerncia em Projetos: Pesquisa, Desenvolvimento e Engenharia. So Paulo: Makron Books, 1998. VOLPE, Renato Luiz Della; JOMORI, Sergio Massao; ZABEU, Ana Ceclia Peixoto. SPIN BH: CMM - CMMI. Principais conceitos, diferenas e correlaes. Disponvel em: <http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf>. Belo Horizonte, 2003. Acesso em 25/11/2011 YIN, R. K. Estudo de Caso: planejamento e mtodos . Trad. de Daniel Grassi. 3 a ed. Porto Alegre: Bookman, 2005. WEBER, Kival Chaves. et al. Modelo de Referncia para Melhoria de Processo de Software: uma abordagem brasileira. In XXX Conferncia Latino-Americana de Informtica (CLEI 2004). Arequipa, Peru. Anais... Disponvel em: <http://www.softex.br/media/artigoCLEI_versao_final.pdf> Acesso em 21/11/2011 WEBER, Kival Chaves; ROCHA, Ana Regina; ALVES, ngela, et al. Modelo de refernciapara melhoria de processo de software: uma abordagem brasileira. XXX Conferncia Latinoamericana de Informatica (CLEI2004) . Arequipa, Peru. 2004.

90

APNDICE

APNDICE A: Questionrio entregue ao representante da rea de TI em cada empresa

91

APNCICE A
QUESTIONRIO 1) Quantos funcionrios a empresa tm na rea de TI e seus respectivos cargos

e funes? 2) Existe algum tipo de modelo, norma ou padro nacional ou internacional para

o desenvolvimento de software adotado pela empresa como: CMM, CMMI, MPS.BR, SPICE, ISO? Qual? 3) Qual a motivao para a adoo de um modelo de melhoria de processos?

4) Existe algum funcionrio com certificao em modelos de melhoria de processo? (Quantidade com cargos e respectivas funes) 5) Antes era utilizado algum modelo, norma ou padro em que existiam processos definidos para a rea de Gerenciamento de Configurao de Software? 6) Com a adoo de um modelo especfico em relao a rea de processo GCS, trouxe benefcios para a empresa? Quais? 7) Houve dificuldades da implantao do modelo de melhoria de processos adotado em relao ao GCS? Se sim quais? 8) Houve reduo de esforos, em relao a manuteno, em projetos que foram desenvolvidos aplicando um modelo de melhoria de processos com foco em GCS comparado anteriormente sem a aplicao de um modelo com GCS, e assim ganhando mais produtividade? 9) Em projetos que foram desenvolvidos aplicando um modelo de melhoria de processos com foco em GCS comparado com o perodo que no havia um modelo em que a GCS estava presente, as funcionalidades do projeto eram entregues dentro do prazo estipulado? 10) Houve reduo de falhas, defeitos e bugs encontrados aplicando um modelo de melhoria de processos em relao a Gerncia de Configurao de Software? 11) Houve alguma melhora na reduo de custos em relao ao perodo em que no era adotado um modelo, norma ou padro com foco em GCS? 12) Houve excesso de esforo de horas gastas em relao ao planejado?

92

13) Houve aumento ou reduo do Backlog em relao ao perodo em que no existia um modelo de melhoria de processo em que a Gesto de Configurao no estava presente? 14) 15) Existe uma ferramenta para versionamento de cdigo-fonte? Se sim qual? Determine o grau de importncia da utilizao de um modelo em que a A. ( ) 0-2 B. ( ) 3-5 C. ( ) 6-8 D. ( ) 9-10 16) Determine o efeito positivo que o modelo com a Gerencia de Configurao de A. ( ) - Fraco B. ( ) - Razovel C. ( ) - Forte D. ( ) - Muito Forte 17) Qual o grau de eficincia proporcionado pela adoo da Gerncia de A. ( ) 0-2 B. ( ) 3-5 C. ( ) 6-8 D. ( ) 9-10 18) Qual o nvel de dificuldade para adoo do modelo com GCS? A. ( ) 0-2 B. ( ) 3-5 C. ( ) 6-8 D. ( ) 9-10

Gerncia de Configurao est presente para o desenvolvimento de projetos.

Software proporcionou aos projetos desenvolvidos.

Configurao nos projetos desenvolvidos?

93

19)

Determine o grau de benefcios trazidos pelo modelo em relao a GCS nos A. ( ) 0-2 B. ( ) 3-5 C. ( ) 6-8 D. ( ) 9-10

projetos desenvolvidos.

20)

As funcionalidades eram entregues dentro do prazo estipulado? A. ( ) - Nunca B. ( ) - Raramente C. ( ) Frequentemente D. ( ) - Sempre