MSC Metliberato

UNIVERSIDADE DE TRS-OS-MONTES E ALTO DOURO
Implementao do Modelo CMMI na Esprito Santo Informtica
DISSERTAO DE MESTRADO EM INFORMTICA
MARCO EMANUEL TEIXEIRA LIBERATO
Vila Real, 2008
Universidade de Trs-os-Montes e Alto Douro

Curso de Mestrado em Informtica
Implementao do Modelo CMMI na Esprito Santo Informtica
Dissertao do curso de Mestrado em Informtica de Marco Emanuel Teixeira Liberato
Dissertao submetida Universidade de Trs-os-Montes e Alto Douro, para cumprimento dos requisitos necessrios obteno do grau de Mestre em Informtica, elaborada sob a orientao do Prof. Doutor Joo Eduardo Quintela Alves de Sousa Varajo e co-orientao do Prof. Doutor Paulo Nogueira Martins.
Vila Real, Junho de 2008
Para a minha famlia e namorada. Pelo apoio recebido e por tudo de bom que tenho passado com eles.
Agradecimentos
Aos meus orientadores, que apesar da distncia, sempre tentaram estar perto. Sem dvida que a permanente disponibilidade e enorme capacidade de orientao tiveram um enorme peso na escrita desta dissertao.
Aos elementos da equipa de Processos e Qualidade de Sistemas de Informao da Esprito Santo Informtica, os quais sugeriram a escolha deste tema, especialmente Paula Brando e ao Pablo Mendez, por todo o apoio prestado e enorme disponibilidade demonstrada.
A todos os colaboradores que participaram na elaborao das entrevistas e preenchimento dos questionrios. O meu muito obrigado pela pronta disponibilidade e extrema simpatia demonstrada.
E por fim, a todos os que me consideram e eu os considero como amigos, por tantas aventuras e grandes momentos que j passmos!
ii
Resumo
Qualquer empresa tem a mesma finalidade: a obteno de lucro! Cada vez mais as empresas, para conseguirem sobreviver no mundo competitivo e exigente dos negcios, tero no s de se adaptar s constantes mudanas do mesmo, como tambm tentar estar um passo frente dos demais concorrentes. Uma boa estratgia para atingir o sucesso e obter vantagens competitivas atravs da qualidade. Por vezes, as organizaes sentem-se to satisfeitas, to -vontade com a sua performance diria, que ficam relutantes a mudanas, mas com isso apenas esto a adiar o inevitvel. Na competitiva indstria de desenvolvimento de software, a capacidade de questionar e melhorar procedimentos existentes, com o objectivo de cada vez serem mais perfeitos e exactos, marca a diferena entre uma empresa que apenas cumpre os requisitos de um cliente e outra que acaba por os exceder. E quando um cliente tem de optar por uma delas, certamente escolher a que a melhor o servir, lhe der maiores garantias de sucesso e lhe apresentar melhores resultados. A empresa em estudo, a Esprito Santo Informtica, aps se ter apercebido que o seu processo de desenvolvimento de software apresentava falhas, e procurando tambm optimizar os seus processos de desenvolvimento de software, partiu na difcil aventura de implementar um modelo de maturidade no seio da empresa, mudando (em alguns casos radicalmente) hbitos de trabalho cimentados nesta empresa h vrios anos. Alm de serem mostradas as estratgias de implementao, o antes e aps CMMI e todas as dificuldades inerentes execuo desta implementao, esta dissertao tem como principal objectivo procurar apurar se todas as decises tomadas pela equipa responsvel por essa implementao foram as melhores e as mais adequadas tendo em conta as necessidades e mesmo os mtodos de trabalho e caractersticas dos colaboradores que fazem parte da empresa em estudo. iii
Abstract
Any company in the world has the same purpose: to obtain profit! In order to survive in the competitive and demanding world of business, the companies will need to adapt to changes, but also try to be one step ahead of other competitors. A good strategy to achieve success and gain competitive advantage is through quality. Sometimes, organizations feel so happy with their daily performance that becomes reluctant to change, but with this they are only postpone the inevitable. In the competitive industry of software development, the ability to challenge and improve existing procedures, in order to be ever more perfect and accurate, mark the difference between a company that only meets the requirements of a client and another that ultimately exceed them. And when a customer has to choose one of them, certainly choose the one that best serve him, provide large guarantees of success and presents better results. The company under study, the Esprito Santo Informtica, which after it was realized that its software development process had flaws, and trying also to optimize their processes for software development, began the "hard adventure" to implement a maturity model within the company, changing (in some cases dramatically) habits of work cemented in this company for several years. In addition to being shown the strategies for implementation, the before and after CMMI and all the difficulties inherent in this implementation, the main goal of this thesis is aiming to seek whether all decisions taken by the team responsible for this implementation were the best and most appropriate taking into account the needs and even the working methods and characteristics of employees who are part of the company under study.
iv
"Vale mais fazer e arrepender-se, que no fazer e arrepender-se." Maquiavel
ndice Geral
Agradecimentos ................................................................................................................ ii Resumo ............................................................................................................................ iii Abstract............................................................................................................................ iv ndice Geral ..................................................................................................................... vi ndice de Figuras ........................................................................................................... viii ndice de Tabelas .............................................................................................................. x Acrnimos ....................................................................................................................... xi 1. Introduo ................................................................................................................. 1 1.1. Desenvolvimento de Software ........................................................................... 2 1.2. Objectivos .......................................................................................................... 4 1.3. Organizao da Dissertao............................................................................... 6 2. Modelo CMMI .......................................................................................................... 7 2.1. Enquadramento .................................................................................................. 7 2.1.1. Modelos de Maturidade .......................................................................... 10 2.1.2. Necessidades de Criao de Modelos de Maturidade ............................ 11 2.2. Representao do Modelo CMMI.................................................................... 13 2.3. Componentes do Modelo CMMI ..................................................................... 15 2.4. Escolher um Modelo ........................................................................................ 35 2.5. Benefcios na Implementao do CMMI......................................................... 35 2.6. Problemas e Limitaes do CMMI .................................................................. 39 2.7. Adopo do CMMI .......................................................................................... 40 2.8. Casos de Sucesso de Implementao do CMMI.............................................. 42 3. Abordagem de Investigao .................................................................................... 47 3.1. Enquadramento da Pesquisa Qualitativa.......................................................... 48 3.2. Perspectivas Filosficas................................................................................... 49 3.2.1. Pesquisa Positivista ................................................................................ 49 3.2.2. Pesquisa Interpretativa............................................................................ 50 3.2.3. Pesquisa Crtica ...................................................................................... 50 3.3. Mtodos de Pesquisa Qualitativa ..................................................................... 51 3.3.1. Estudo de Casos...................................................................................... 51 3.3.2. Etnografia ............................................................................................... 52 3.3.3. Grounded Theory.................................................................................... 52 3.3.4. Action Research...................................................................................... 53 3.4. Tcnicas Qualitativas para a Recolha de Dados .............................................. 57 4. Caso de Estudo ........................................................................................................ 59 vi
4.1. ES Informtica, ACE ....................................................................................... 59 4.2. Gap Analysis.................................................................................................... 62 4.2.1. Gap Analysis Nvel 2.............................................................................. 62 4.2.2. Gap Analysis Nvel 3.............................................................................. 69 4.2.3. Benefcios Esperados da Adopo do CMMI na Empresa..................... 72 4.3. Estratgias de Implementao.......................................................................... 74 4.3.1. Aces de Implementao ...................................................................... 76 4.3.2. Ferramentas de Suporte Implementao.............................................. 77 4.3.2.1. Sharepoint............................................................................................... 78 4.3.2.2. RoboHelp................................................................................................ 79 4.4. Lacunas Encontradas ....................................................................................... 82 4.5. Anlise e Discusso de Resultados .................................................................. 84 5. Consideraes Finais............................................................................................... 95 Bibliografia................................................................................................................... 101 Anexo I ......................................................................................................................... 107
vii
ndice de Figuras
Figura 1 - Report do Chaos ......................................................................................... 12 Figura 2 - Componentes do Modelo CMMI................................................................... 16 Figura 3 - Nveis de Maturidade do Modelo CMMI ...................................................... 21 Figura 4 - reas de Processo da Representao Faseada ............................................... 22 Figura 5 - Categorias das reas de Processo.................................................................. 23 Figura 6 - reas de Processo Bsicas da Gesto de Processos ...................................... 24 Figura 7 - reas de Processo Avanadas da Gesto de Processos ................................. 25 Figura 8 - reas de Processo Bsicas da Gesto de Projectos ....................................... 26 Figura 9 - reas de Processo Avanadas da Gesto de Projectos .................................. 28 Figura 10 - reas de Processo da Engenharia ................................................................ 30 Figura 11 - V-Model ....................................................................................................... 31 Figura 12 - reas de Processo Bsicas de Suporte......................................................... 33 Figura 13 - reas de Processo Avanadas de Suporte ................................................... 34 Figura 14 - N de Organizaes por Nvel de Certificao ............................................ 42 Figura 15 - Relao Trabalho Correco VS Actividades Qualidade de Software ........ 44 Figura 16 - Deteco de Defeitos ................................................................................... 45 Figura 17 - Pesquisa Qualitativa..................................................................................... 49 Figura 18 - Composio da Esprito Santo Informtica ................................................. 60 Figura 19 - Estrutura da Esprito Santo Informtica ...................................................... 60 Figura 20 - Implementao da Gesto de Requisitos ..................................................... 64 Figura 21 - Implementao do Planeamento do Projecto............................................... 65 Figura 22 - Implementao do Controlo e Monitorizao do Projecto .......................... 65 Figura 23 - Implementao daGesto de Acordos com Fornecedores ........................... 66 Figura 24 - Implementao das Medies e Anlises .................................................... 67 Figura 25 - Garantia de Qualidade do Produto e do Processo........................................ 67 Figura 26 - Implementao da Gesto de Configuraes............................................... 68 Figura 27 - Conformidade com as reas de Processo de Nvel 2 .................................. 68 Figura 28 - Implementao do Desenvolvimento de Requisitos.................................... 70 Figura 29 - Implementao da Verificao .................................................................... 71 Figura 30 - Implementao da Validao....................................................................... 72 Figura 31 - Conformidade com as reas de Processo de Nvel 3 .................................. 72 Figura 32 - Calendarizao da Certificao ................................................................... 75 Figura 33 - Sharepoint .................................................................................................... 79 Figura 34 - Robohelp...................................................................................................... 80 Figura 35 - Visualizao da Fase de Oramento ............................................................ 81 viii
Figura 36 - Exemplo de Pgina Descritiva da Fase de Oramento ................................ 82 Figura 37 - Opinio dos Gestores de Projecto (Pergunta 14 a. do Inqurito: A utilizao do RoboHelp facilita a implementao do processo?).................................................. 89 Figura 38 - Opinio dos Gestores de Projecto (Pergunta 14 b. do Inqurito: Os templates de documentos so teis no desenvolvimento do projecto?)........................ 90 Figura 39 - Opinio dos Gestores de Projecto (Pergunta 14 c. do Inqurito: A utilizao de um site do projecto facilita o trabalho em equipa?) ................................................. 90 Figura 40 - Opinio dos Gestores de Projecto (Pergunta 14 d. do Inqurito: A utilizao de um site do projecto facilita a organizao da documentao?) ............... 91 Figura 41 - Opinio dos Gestores de Projecto (Pergunta 14 e. do Inqurito: A utilizao de um site do projecto facilita o controle do projecto?) ............................................... 92 Figura 42 - Resumo da Opinio Gestores de Projecto relativamente Pergunta 14 do Inqurito ......................................................................................................................... 93
ix
ndice de Tabelas
Tabela 1 - Modelos de Maturidade................................................................................. 11 Tabela 2 - Vantagens das Representao do Modelo CMMI......................................... 15 Tabela 3 - Adopo do CMMI (Internacional)............................................................... 41 Tabela 4 - Adopo do CMMI (Nacional) ..................................................................... 41 Tabela 5 - N de Certificaes CMMI por Pas.............................................................. 41 Tabela 6 - Melhorias Mdias com o CMMI ................................................................... 73 Tabela 7 - Etapas da Obteno da Certificao CMMI.................................................. 74 Tabela 8 - N de Meses em Mdia para Passagem de Nvel de Maturidade .................. 75
Acrnimos
AB BES BIM CAR CM CMM CMMI CMMI-SE/SW CMMI-SE/SW/IPPD CMMI-SE/SW/IPPD/SS CO DAR DI DOD ESI E.U.A. GSI IEEE IPM IPPD ISM ISO IT MA OEI OID OPD OPF OPP OT PI PMC PMBOK Ability to Perform Banco Esprito Santo Building Information Model Causal Analysis and Resolution Configuration Management Capability Maturity Model Capability Maturity Model Integration CMMI for Systems Engineering / Software Engineering CMMI-SE/SW/Integrated Product and Process Development CMMI-SE/SW/IPPD/Supplier Sourcing Commitment to Perform Decision Analysis and Resolution Directing Implementation Departament of Defense Esprito Santo Informtica Estados Unidos da Amrica Gesto de Sistemas de Informao Institute of Electrical Electronics Engineers Integrated Project Management Integrated Product and Process Development Integrated Supplier Management International Standards Organization Integrated Teaming Measurements and Analysis Organizational Environment for Integration Organizational Innovation and Deployment Organizational Process Definition Organizational Process Focus Organizational Process Performance Organizational Training Product Integration Project Monitoring and Control Project Management Body of Knowledge xi
PMI PP PPQA PQSI QPM REQM RD RSKM SAM SCAMPI SEI SEPG SI SW-CMM TCS TIC TS USD VAL VE VER
Project Management Institute Project Planning Process and Product Quality Assurance Processos e Qualidade de Sistemas de Informao Quantitative Project Management Requirements Management Requirements Development Risk Management Supplier Agreement Management Standard CMMI Appraisal Method for Process Improvement Software Engineering Institute Software Engineering Process Group Sistema de Informao Capability Maturity Model for Software Tata Consultancy Services Tecnologias da Informao e Comunicao Technical Solution United States Dollars Validation Verifying Implementation Verification
xii
1.
Introduo
A origem da Qualidade de Software confunde-se com a origem da Engenharia de Software, j que no incio no havia a definio clara das sub-reas da Engenharia de Software. Inclusive ainda hoje, a Qualidade de Software ubqua na Engenharia de Software (SWEBOK 2004), ou seja, est ao mesmo tempo em toda a parte. Por este motivo, para se abordar a gnese da Qualidade de Software necessrio recorrer histria da Engenharia de Software. A Engenharia de Software, como aceite por muitos, iniciou-se em 1968, quando aproximadamente 50 especialistas em computao de 11 pases se reuniram em Garmisch, Alemanha, para discutir os problemas de desenvolvimento de software da poca (Naur e Randell 1968). Durante a conferncia houve um grande debate sobre o tema que os participantes escolheram chamar de Software Crisis ou Software Gap. Entre os principais problemas relacionados a este tema que foram descritos durante a conferncia estavam: Projectos realizados acima do oramento; Projectos finalizados acima do tempo esperado; Produtos de software de baixa qualidade; Produtos de software sem atender aos requisitos do cliente; Projectos impossveis de gerir e com cdigo difcil de manter.
Aps quase quatro dcadas a Engenharia de Software evoluiu bastante. Durante todo este tempo foram desenvolvidos mltiplos mtodos, tcnicas e teorias com o objectivo 1
Captulo 1 - Introduo de resolver ou amenizar os problemas reportados durante a conferncia. Grande parte destas evolues surgiu como resultado do apreendido em projectos reais e fizeram com que a Engenharia de Software amadurecesse como rea da Cincia da Computao. Ao longo desta histria uma subrea que tem ganho foras na luta contra o que foi denominado de Crise de Software a rea de conhecimento denominada Qualidade de Software, que est omnipresente na Engenharia de Software como um todo, pois ela est includa nas preocupaes das demais subreas.
1.1.
Desenvolvimento de Software
Um processo de desenvolvimento de software consiste num conjunto de actividades, parcialmente ordenadas, com a finalidade de obter um produto de software e que define quem faz o qu, como, quando e onde. estudado dentro da rea de Engenharia de Software, sendo considerado um dos principais instrumentos para se obter software de qualidade e cumprir correctamente os contratos de desenvolvimento, o que de certa forma garantir um determinado grau de confiana aos seus clientes. O processo de desenvolvimento de software tipicamente composto por diversas fases (anlise, oramento, planeamento, desenvolvimento, teste, etc.) que tem como principal objectivo dar resposta aos requisitos de um cliente, tendo em conta prazos e custos bem definidos, sempre direccionado finalidade de produzir um produto de qualidade. Quando nos referimos qualidade do produto temos de ter em conta importantes factores como a preocupao em garantir que o nvel de qualidade requerido num produto de software atingido, que a definio de normas e procedimentos de qualidade so adequados, e que existe o desenvolvimento de uma cultura de qualidade, onde a qualidade vista como uma responsabilidade de todos. Quando nos referimos a gesto de qualidade, no est apenas patente a preocupao da minimizao de defeitos do produto mas tambm todas as outras qualidades desse produto. As actividades inerentes a essa gesto da qualidade so: a Garantia de Qualidade, atravs do estabelecimento de procedimentos organizacionais e standards para a qualidade; o Planeamento da Qualidade, com a seleco de procedimentos e standards para um projecto especfico e a sua adequao conforme necessrio; e o Controlo de 2
Captulo 1 - Introduo Qualidade, com a garantia de que os procedimentos e standards so seguidos pela equipa de desenvolvimento. Os produtos/projectos so cada vez mais complexos e necessitam de ser entregues/finalizados cada vez mais depressa, com melhor qualidade e com menos custos. Cada vez mais a exigncia do mercado e dos prprios clientes e utilizadores obrigam a um esforo extraordinrio para fazer melhor gastando menos tempo e recursos. Os actores participantes nesses desenvolvimentos tm diferentes papis (gestores, programadores, designers, etc.), aumentando ainda mais a dificuldade e complexidade na troca de informao e organizao desses projectos. Ao longo do tempo verificou-se que sem uma organizao bem definida dos processos e consequente maturidade por parte da organizao, atingir tais objectivos torna-se muito difcil, ou mesmo quase impossvel. Na maior parte dos casos, essa m organizao e falta de maturidade levam a grandes perdas financeiras e estruturais. Os modelos de maturidade, quando bem implementados, e o uso de standards no seio da organizao, permitem s organizaes retirar grandes benefcios, como a satisfao do cliente, aumento da qualidade do desenvolvimento dos processos e a reduo do trabalho de correco. Estes benefcios, conjugados, permitiro empresa diminuir os custos de desenvolvimento dos processos, aumentando assim os ganhos (Miller et al. 2002). Para dar resposta a esta necessidade de garantia de qualidade do produto, atendendo aos marcos do tempo e oramento, nasceram os chamados Modelos de Maturidade. Muitas organizaes utilizam Modelos de Maturidade ou Capability Maturity Models (CMMs) com o objectivo de avaliarem os seus processos de desenvolvimento e manuteno, implementarem melhorias no seu modo de funcionamento e determinarem os progressos obtidos. Embora consistentes no propsito, estes modelos diferem na sua terminologia e arquitectura, o que gera conflito quando adoptados dentro da mesma organizao. A complexidade dos produtos de hoje implica que seja usada uma viso integrada dos sistemas e software de engenharia. Neste contexto surge, entre outros, o CMMI (Capability Maturity Model Integration), que oferece uma estrutura para estabelecer melhorias ao nvel da engenharia de software, da engenharia de sistemas e do desenvolvimento de processos e interaco com fornecedores. O CMMI, desenvolvido pela Carnegie Mellon University's Software Engineering Institute, tem como objectivo principal providenciar um conjunto de melhores prticas 3
Captulo 1 - Introduo no processo de desenvolvimento de um produto ou servio ao longo de todo o seu ciclo de vida de desenvolvimento, entrega e manuteno (SEI 2007). Apesar do CMMI no ser o nico modelo de guia para a melhoria de processos de software baseado em disciplinas de processo, a sua aceitao generalizada, f-lo uma norma de facto, levando muitas organizaes a obter sucesso ao nele basearem as suas disciplinas de processo de engenharia de software (Jones e Soule 2002). O CMMI descreve as melhores prticas das organizaes. Estas podem ser usadas por organizaes para melhorar os seus processos de desenvolvimento, aquisio e manuteno dos seus produtos e servios. Quando se comea a utilizar um modelo CMMI para melhorar processos, deve-se mapear esses processos para as reas de processo CMMI. Este mapeamento permite controlar o nvel de adaptao da empresa com o modelo CMMI e facilmente identificar oportunidades para o melhorar (Kay 2005). Muitas organizaes em todo o Mundo investiram na melhoria dos seus processos de desenvolvimento de software baseados no CMMI. A grande maioria destas organizaes conseguiu atingir e em alguns casos ultrapassar os seus objectivos de melhoria (Miller et al. 2002).
1.2.
Objectivos
Sem dvida alguma que se as empresas portuguesas quiserem fazer frente s todopoderosas multinacionais, que cada vez mais vm ganhando credibilidade e enorme espao no mercado portugus, tero de se converter qualidade, aumentando no s a qualidade dos seus produtos mas tambm dos seus processos, devendo demonstrar que podem ser uma alternativa vlida at para os clientes mais exigentes. Os objectivos desta dissertao passam por fazer o seguimento e tambm contribuir para a implementao do modelo CMMI na empresa em estudo, a ESI (Esprito Santo Informtica), com o intuito de no final dessa implementao poder ser feita uma anlise no s dos benefcios resultantes dessa implementao, mas tambm dar conta dos constrangimentos e barreiras que eventualmente surjam. Ser tambm til poder retirar elementos que digam respeito ao processo em si, ou seja, poder actuar junto dos visados (elementos constituintes das equipas dos vrios departamentos) e poder verificar quais foram as principais dificuldades e vantagens do modelo para as suas tarefas dirias na empresa. Em suma, o principal objectivo deste projecto passar pela viso do pr4
Captulo 1 - Introduo CMMI e do ps-CMMI, de modo a poder-se verificar quais as grandes mudanas que um modelo de qualidade de processos provoca numa empresa de grande dimenso com hbitos e mtodos de trabalho cimentados com vrios anos. Na empresa em estudo, o sucesso dos projectos de desenvolvimento de software tem vindo a ser muito ameaado devido a uma srie de factores como: a ausncia de standards de infra-estrutura e desenvolvimento; esforo elevado na anlise de pedidos, resultando em oramentaes muito demoradas; esforo e demora na recolha de requisitos; ausncia de controlo de qualidade e certificao durante o processo de desenvolvimento, resultando na descoberta tardia de problemas. No seu conjunto, estes factores levam aos principais e habituais problemas nas organizaes de desenvolvimento de software: os atrasos e as derrapagens financeiras. A ESI, para dar resposta e resolver os problemas identificados adoptou, o CMMI, um standard de facto da indstria, para guiar a melhoria do seu processo de desenvolvimento. Os benefcios esperados provenientes da implementao do modelo de maturidade CMMI passam pela melhoria do processo de desenvolvimento de projectos informticos, como: a adopo das melhores prticas da indstria e a normalizao de processos e das melhores prticas internas; a formalizao e normalizao dos processos; e o aumento da qualidade dos projectos para um melhor cumprimento dos prazos, menores custos e menos defeitos. De modo a implementar este modelo de maturidade na empresa, foi criado uma nova direco na estrutura da empresa, com o nome PQSI (Processos e Qualidade de Sistemas de Informao). Desde o incio do projecto de implementao do CMMI foi instituda a mxima de adaptar esta implementao s necessidades dirias dos colaboradores da organizao e tentar implementar os requisitos do modelo com o mnimo de impacto no modo e hbitos de trabalho dos colaboradores, hbitos esses consolidados ao longo de vrios anos. Apesar da execuo do projecto ter sido atribuda direco de Qualidade, toda a empresa participou na definio do mesmo, interagindo diariamente com esta, sugerindo melhorias, dando opinies, ou seja, intervindo (in)directamente na definio da implementao dos processos de qualidade do modelo de maturidade.
Captulo 1 - Introduo
1.3.
Organizao da Dissertao
Este trabalho encontra-se dividido em cinco captulos: Para alm deste captulo de Introduo, no Captulo 2 refere-se o Modelo CMMI, sendo abordada a sua origem, alguns dos seus objectivos e caractersticas. O Captulo 3 diz respeito abordagem de investigao usada no decorrer deste trabalho. No Captulo 4 apresentado o caso prtico da ESI, concretamente o processo de definio e implementao do modelo de maturidade CMMI, as estratgias e aces tomadas pela rea da empresa responsvel por essa implementao, a rea de Processos e Qualidade de Sistemas de Informao, bem como os estudos e observaes feitas com o objectivo de verificar se essas aces e estratgias foram as mais indicadas, e, por fim, apresentada a viso pr-CMMI e psCMMI da organizao. No captulo 5 so feitas diversas consideraes finais.
Captulo 2 Modelo CMMI
2. Modelo CMMI
Neste captulo primeiro efectuada uma breve introduo do modelo de maturidade CMMI, onde ir ser dado a conhecer a sua origem, alguns dos seus objectivos e caractersticas. Seguidamente so abordados de uma forma geral os modelos de maturidade, com foco no que tratam, no que disponibilizam e na necessidade da sua criao, sendo tambm disponibilizada uma tabela em que se encontram alguns dos modelos de maturidade existentes, no qual se inclui o CMMI. Iro ser apresentados os dois tipos de representao do modelo CMMI, a representao faseada e contnua, e uma breve tabela onde se comparam as vantagens de cada um deles e as diversas componentes da representao faseada, a qual foi adoptada pela empresa. Este captulo termina com uma abordagem s vantagens e problemas/limitaes do modelo CMMI e com a apresentao de casos prticos referentes ao processo de implementao do CMMI em trs organizaes. De referir que a maior parte do contedo deste captulo se baseou na verso 1.1 do manual oficial do SEI (Software Engineering Institute) CMMI Product Team (SEI 2007), referente ao modelo CMMI, tendo sido complementado com outras referncias.
2.1.
Enquadramento
Pensemos nos anos 80: a Guerra-fria ainda estava presente e o DOD (Departament of Defense) dos Estados Unidos da Amrica cada vez mais confiava nos seus computadores para todos os aspectos das suas operaes. Nessa altura, os computadores 7
Captulo 2 Modelo CMMI eram muito menos potentes do que aqueles existentes nos dias de hoje e os computadores militares teriam de dar resposta aos rigorosos requisitos de fiabilidade, o que os tornava ainda maiores, mais pesados e lentos que os computadores civis. Por esta altura comeavam a aparecer os sistemas operativos, aplicaes grficas e a maioria do software militar era desenvolvido por fornecedores externos. O DOD necessitava de determinar com um grau de certeza elevado se os fornecedores conseguiam disponibilizar software dentro do tempo til, do oramento e das especificaes. A resposta a esse pedido de qualidade veio da Carnegie Mellon University's Software Engineering Institute atravs da criao do modelo de maturidade CMM (Capability Maturity Model), verificando-se ser uma maneira eficaz de avaliar e descrever a qualidade do desenvolvimento do software por parte de uma organizao (Kay 2005). O CMM um modelo que contm os elementos essenciais dos processos efectivos para o desenvolvimento de software e a sua larga aceitao evidenciada em grandes conferncias do Software Engineering Process Group (SEPG) na Amrica do Norte, Europa e sia. Apesar do SW-CMM (Capability Maturity Model for Software) no ser o nico modelo de guia para a melhoria de processos de software baseado em disciplinas de processo, a sua aceitao generalizada f-lo uma norma de facto, levando muitas organizaes a obterem sucesso ao nele basearem as suas disciplinas de processo de engenharia de software (Jones e Soule 2002). O sucesso do SW-CMM deu origem ao desenvolvimento de vrios modelos de maturidade para outras disciplinas como, por exemplo, engenharia de sistemas, aquisio de software, prticas de trabalho e desenvolvimento de produtos e processos integrados. Apesar destes modelos se revelarem valiosos para muitas organizaes, a aplicao de mltiplos modelos tornou-se dispendiosa e complicada. Como tentativa de resoluo deste problema, o projecto Capability Maturity Model Integration (CMMI) foi iniciado, resultando num produto completo que inclui trs modelos:
CMMI for Systems Engineering/Software Engineering (CMMI-SE/SW, V1.1)
Este modelo diz respeito ao desenvolvimento de produtos e servios (em particular sistemas de software) e serve de base instituio dos outros dois modelos seguintes.
Captulo 2 Modelo CMMI CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development (CMMI-SE/SW/IPPD, V1.1)
Este modelo baseia-se no CMMI-SE/SW, introduzindo equipas de produtos integrados e o contexto que necessitam para operarem efectivamente, com o objectivo de atingirem uma colaborao sistemtica e oportuna dos stakeholders (pessoas que interagem e so afectadas pelo projecto) relevantes ao longo da vida do produto.
CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1)
Este modelo baseia-se no CMMI-SW/SE/IPPD com um foco adicional na aquisio pr-activa de produtos e servios de fontes externas (Jones e Soule 2002).
Uma abordagem na melhoria das taxas de sucesso dos projectos faz-se atravs do uso de fornecedores que possam demonstrar uma capacidade madura no desenvolvimento de software e de sistemas (Robinson et al. 2000). O CMMI tem como objectivo providenciar um guia para a melhoria dos processos das organizaes e capacidade de gerir o desenvolvimento, aquisio e manuteno de produtos e servios, apresentando um conjunto de processos integrados, que endeream com sucesso mltiplas disciplinas e tem suporte integrado de formao e avaliao para a melhoria dos procedimentos (Luqman 2005). Uma consequncia inesperada do desenvolvimento do CMMI foi o impulso significativo no que diz respeito ao desenvolvimento de software por outsourcing. As agncias de desenvolvimento econmico na ndia e na Irlanda, por exemplo, levaram a que o CMMI conseguisse competir directamente com os contratos de outsourcing nos E.U.A. (Estados Unidos da Amrica). Tal teve um efeito muito positivo no emprego dos engenheiros de software nas economias do Terceiro Mundo, mas teve tambm o efeito reverso no mercado do trabalho de altas tecnologias em pases desenvolvidos (Kay 2005). O Standard CMMI Appraisal Method for Process Improvement (SCAMPI) providencia classificaes detalhadas dos pontos fortes e dos pontos fracos da organizao relativas ao modelo CMMI. O SCAMPI foi desenvolvido para ajudar as organizaes a melhorarem os seus processos definindo prioridades e focando-se em 9
Captulo 2 Modelo CMMI melhorias que dem resposta aos objectivos de negcio. Existem organizaes de terceiros que fornecem os servios de avaliao SCAMPI (Kay 2005).
2.1.1. Modelos de Maturidade
A Gesto de Sistemas de Informao (GSI) a actividade responsvel pelas tarefas que, numa organizao, so necessrias para gerir a informao, o Sistema de Informao (SI) e a adopo de Tecnologias da Informao e Comunicao (TIC) (Amaral e Varajo 2000; Rocha e Vasconcelos 2004). A maturidade desta actividade , actualmente, um factor chave de sucesso pois o sistema de informao de grande parte das organizaes constitui uma pea fundamental do seu todo. Neste mbito, existem vrios instrumentos para ajudar a Gesto de Sistemas de Informao a caminhar em direco a uma maturidade superior, destacando-se, entre eles, os designados Modelos de Maturidade. Os Modelos de Maturidade fornecem aos gestores das organizaes um poderoso instrumento para determinarem em que estdio de maturidade se encontram e planearem as aces necessrias para progredirem em direco a uma maturidade superior e, por consequncia, alcanarem os objectivos desejados (Rocha e Vasconcelos 2004). Estes Modelos de Maturidade baseiam-se na premissa de que as pessoas, organizaes, reas funcionais, processos, etc. evoluem atravs de um processo de desenvolvimento ou crescimento em direco a uma maturidade mais avanada atravessando um determinado nmero de estdios distintos, tendo vindo a ser usados em vrias reas e tendo sido usados para descrever uma larga variedade de fenmenos (Burn 1994; King e Teo 1997; Rocha e Vasconcelos 2004). Na Tabela 1 apresentam-se vrios modelos de maturidade, incluindo o CMM:
Modelo
URL
A Guide to the Project Management www.pmi.org/standards/pmbok.htm Body of Knowledge AACE Internationals Certification Program ICB - IPMA Competency Baseline APM BoK Review Project Management Assessment and Certification Program Europe www.aacei.org/newdesign/certification/certificationprogram/welc ome.shtml www.ipma.ch/certification/standards/Pages/ICBV3.aspx www.apmgroup.co.uk www.pmforum.org/standards/index.htm
Australian Institute of Project Management (AIPM). 1996. www.dab.uts.edu.au National Competency Standards for Project Management: Various
10

Volumes, Competency Standards, Level 6. Software Engineering Institute Capability Maturity Models in general SEI SW-CMM Capability Maturity Model SM for Software SEI SE-CMM Capability Maturity Model for Systems Engineering SEI P-CMM People Capability Maturity Model Microframe SPICE Trillium US Federal Aviation Administration integrated Capability Maturity Model PMA 2000 Balanced Scorecard Integrated Project Systems model ESI International's ProjectFRAMEWORK EFQM Excellence Malcom Balridge Award IBM Progress Maturity Model V-Model Innovation Maturity Model PRINCE Programme Management Maturity Model PM Solutions' Project Management Maturity Model (SM) www.sei.cmu.edu www.sei.cmu.edu/cmm/cmm.html www.sei.cmu.edu/cmm/se-cmm.html www.sei.cmu.edu/cmm-p/ www.pm2.com www.sqi.gu.edu.au/spice/ www.sqi.gu.edu.au/trillium/ www.faa.gov www.leshem.co.il/products/main1.html www.hbsp.harvard.edu www.kmsystemsgroup.com/wst_page4.html www.esi-intl.com www.efqm.org baldrige.nist.gov www.ibm.com www.scope.gmd.de/vmodel/en/ managementroundtable.com www.prince2.com www.e-programme.com/pmmm.htm www.pmsolutions.com/maturitymodel/whatismodel.htm
Tabela 1 - Modelos de Maturidade
Fonte: [PMFORUM, 2008]
2.1.2. Necessidades de Criao de Modelos de Maturidade
A indstria de software tem disponibilizado novos mtodos, ferramentas e modelos de desenvolvimento de software a um grande ritmo. Esse facto impulsionado pela prpria necessidade de se produzir software com mais velocidade, qualidade e produtividade. Apesar desses avanos tecnolgicos e metodolgicos, a indstria de software ainda continua a passar pela "crise de software" que se arrasta h mais de 30 anos. Para entender e avaliar melhor essa crise, nos meados da dcada de 90 foram realizados vrios estudos e pesquisas, entre eles o do DOD e do Standish Group. O estudo conduzido pelo DOD (DOD 1994) indicou que 75% de todos os grandes sistemas intensivos de software adaptados falhavam e que a causa principal a pobre 11
Captulo 2 Modelo CMMI gesto e no o desempenho tcnico. O primeiro estudo desenvolvido pelo Standish Group (Standish 1994) referente ao ano de 1994, chamado de relatrio do Chaos teve como foco a indstria de software comercial. Esse estudo identificou que as empresas dos Estados Unidos gastaram 81 milhes de USD (United States Dollars) em projectos de software que foram cancelados; 31% dos projectos de software estudados foram cancelados antes de estarem concludos; 53% dos projectos de software excederam mais de 50% da sua estimativa de custo; e somente 9% dos projectos, em grandes empresas, foram entregues no tempo e oramento estipulados na fase inicial do projecto, verificando tambm que para empresas de pequeno e mdio porte, os nmeros melhoraram em 28% e 16% respectivamente. Como se pode verificar na Figura 1, ao longo dos anos houve uma melhoria significativa desses valores, destacando-se sobretudo o dobro do nmero de projectos com sucesso em 2003 tendo como base de comparao o primeiro estudo realizado e publicado.
Figura 1 - Report do Chaos
Fonte: [Standish 2004]
Apesar do relatrio de 2006 ainda no estar publicado, j existem alguns dados fornecidos, nomeadamente a grande melhoria em termos da percentagem de projectos fracassados que diminuiu de 25% para 19% e um aumento de 41% para 46% no que diz respeito a projectos que deram uma resposta positiva parcial ao pedido do cliente, comparando com os valores publicados em 2003. Resumidamente, todas essas anlises levaram s mesmas concluses (Machado e Burnett 2001, Oliveira et al. 2006): 12
Captulo 2 Modelo CMMI O desenvolvimento de software ainda imprevisvel; A disciplina de gesto mais um discriminador de sucesso ou falha; O nvel de software descartado e que tem necessidade de trabalho de correco um indicativo de processo imaturo; Overkill: aquisio de dados em demasia, resultando em esforo desperdiado e reduo de moral; Descoordenao de medies: recolha de medidas erradas, ambguas ou inconsistentes, levando a uma anlise inconclusiva dos dados; Descoordenao de processos: recolha de medidas que reforam os processos errados. Com a disponibilizao desses estudos ficou evidente que as prticas de gesto de projectos deveriam ser melhoradas para que se tivesse sucesso nos projectos de tecnologia da informao. Essa melhoria poder ser obtida atravs da implementao de modelos de maturidade no seio de uma organizao (Machado e Burnett 2001).
2.2.
Representao do Modelo CMMI
Os blocos bsicos de todo modelo CMMI so as reas de processo. Uma representao reflecte, entre outros, a organizao dessas reas de processo do modelo. Existem duas representaes do modelo CMMI, ambas contendo essencialmente a mesma informao.
Representao faseada: A representao faseada oferece um mapa detalhado para o processo de melhoria passo-a-passo. Esta representao descreve a sequncia de execuo das reas de processo agrupando-as em nveis de maturidade, fornecendo uma abordagem comprovada para o processo de melhoria. Alcanando cada nvel garante-se uma base adequada de melhorias para o prximo nvel, minimizando investimentos e riscos e maximizando benefcios. Os processos so melhorados com o alcance de nveis mais altos de maturidade.
Representao contnua: A representao contnua oferece uma abordagem mais verstil para o processo de melhoria. Foi projectada para organizaes que gostariam de escolher uma rea de processo especfica ou um conjunto de processos a melhorar,
13
Captulo 2 Modelo CMMI baseada em problemas ou num conjunto de reas directamente relacionadas com os seus objectivos de negcio. Os objectivos do processo de melhoria so mapeados para reas de processo do modelo de modo a identificar as reas de processo a serem implementadas. Na Tabela 2 esto representadas as vantagens de cada uma das representaes descritas anteriormente.
Representao Contnua Permite liberdade para seleccionar a sequncia das evolues que melhor se encaixa nos objectivos da organizao e minimiza as reas de risco da mesma.
Representao Faseada Introduz uma sequncia de melhorias, comeando com prticas bsicas de gesto e progredindo por um caminho predefinido e comprovado de nveis sucessivos, cada um servindo como base para o prximo.
Permite maior visibilidade da capacidade Foca-se num conjunto de reas de alcanada dentro de cada rea de processo que fornece organizao processo. capacidade especfica caracterizada por cada nvel de maturidade. Permite que as prticas genricas de nveis Prticas genricas so agrupadas por mais altos sejam aplicadas a todas as reas caractersticas comuns que se aplicam a de processo. todas as reas de processo em todos os nveis de maturidade. Devido ao facto dos nveis de capacidade serem medidos pelas reas de processo, comparaes entre organizaes somente podem ser feitas entre reas de processo. Permite uma fcil comparao entre organizaes porque os resultados do processo de melhoria so resumidos num nico nmero, representando o nvel de maturidade.
Reflecte uma nova abordagem que ainda Construdo sobre um longo histrico de no possui dados que demonstrem o uso que inclui estudo de casos e dados, retorno dos investimentos. que demonstram retorno comprovado do investimento. Fornece uma avaliao do nvel de capacidade usada para melhoria dentro da organizao e que raramente comunicada externamente. Fornece uma avaliao do nvel de maturidade frequentemente usada na comunicao da gesto interna, indicaes externas organizao e durante aquisies.
reas de processo so organizadas por reas de processo so organizadas por categorias de reas de processo. nveis de maturidade. A melhoria medida usando nveis de A melhoria medida usando nveis de capacidade que reflectem a execuo maturidade que reflectem a execuo 14
Captulo 2 Modelo CMMI incremental de uma determinada rea de simultnea de mltiplas reas de processo. processo. Existem seis nveis de capacidade, de 0 a Existem cinco nveis de maturidade de 1 a 5. 5. Todas as prticas genricas so listadas Apenas as prticas genricas aplicveis em cada uma das reas de processo. quele nvel de maturidade so listadas nas reas de processo daquele nvel. Existem prticas genricas para os nveis Existem prticas genricas para os nveis de capacidade de 1 a 5. de maturidade de 2 a 5.
Tabela 2 - Vantagens das Representao do Modelo CMMI
Fonte: [SEI 2007]
Dadas as caractersticas de ambas representaes e tendo em conta as necessidades do caso em que foram concentrados esforos, para o caso da ESI optou-se por escolher a implementao da representao faseada, por isso, as componentes descritas de seguida sero as correspondentes a este tipo de representao.
2.3.
Componentes do Modelo CMMI
O modelo CMMI foi designado para descrever nveis de melhoria de processos. As componentes que constituem este modelo so os nveis de maturidade, que albergam as reas de processo, que por sua vez so constitudas por objectivos e por prticas genricas e especficas. Na Figura 2 1 pode-se ver a representao hierrquica dos componentes do Modelo CMMI. Esta representao foca-se nas boas prticas que uma organizao deve usar para melhorar os processos correspondentes s reas de processo que esto dentro do nvel de maturidade que se escolheu atingir.
Nesta figura e em vrias figuras seguintes, optou-se por manter a representao original, em ingls, de modo a no se perder nenhuma abrangncia semntica
15
Figura 2 - Componentes do Modelo CMMI
Fonte: [SEI 2007]
Antes de usar o modelo CMMI para a melhoria dos processos, primeiro ser necessrio mapear os processos da organizao s reas de processo do CMMI. Este mapeamento possibilita o controlo da melhoria dos processos na organizao, ajudando na rastreabilidade do nvel de conformidade da organizao com o modelo CMMI que est a usar. No obrigatrio que cada rea de processo mapeie numa ordem de um para um com os processos da organizao. Os componentes do modelo CMMI podem ser agrupados em trs categorias que reflectem o modo que iro ser interpretadas: REQUIRED: Os objectivos genricos e especficos so modelos de componentes necessrios. Estes componentes devem ser atingidos pelos processos planeados e implementados na organizao. Os componentes REQUIRED so essenciais para a classificao da obteno da rea de processo. EXPECTED: As prticas genricas e especficas so modelos de componentes esperados. Componentes EXPECTED descrevem o que uma organizao ir implementar para atingir um componente necessrio. INFORMATIVE: Sub-prticas, produtos de trabalho, elaborao de prticas genricas, ttulos e notas de objectivos e prticas, e referncias, so modelos de componentes informativos que ajudam os utilizadores a compreender os objectivos e prticas e como estes sero atingidos.
16
De seguida iro ser apresentados, de uma forma mais detalhada, as diversas componentes do modelo CMMI:
Generic Goals (Objectivos Genricos): Os objectivos genricos so assim chamados porque a descrio do objectivo aparece em mltiplas reas de processo. A obteno de um objectivo genrico numa rea de processo significa um controlo melhorado no planeamento e implementao dos processos associados a essa rea, indicando se os processos sero eficazes, reutilizveis e duradouros e, por fim, determinando se a rea de processo foi satisfeita.
Generic Practices (Prticas Genricas): As prticas genricas providenciam uma institucionalizao que garante que os processos associados com a rea de processo sero eficazes, reutilizveis e duradouros. A elaborao de prticas genricas aparece em cada rea de processo de modo a prover um guia de como as prticas genricas devem ser aplicadas de forma nica rea de processo. Por exemplo quando a prtica genrica Train the people performing or supporting the planned process as needed incorporada na rea de processo de Gesto de Configurao (Configuration Management), os tipos especficos de formao para executar a Gesto de Configurao so descritos.
Specific Goals (Objectivos Especficos): Os objectivos especficos aplicam-se a uma rea de processo e endeream as caractersticas nicas que descrevem o que deve ser implementado para satisfazer essa rea de processo. Os objectivos especficos so usados em avaliaes para ajudar a determinar se uma rea de processo foi satisfeita.
Specific Practices (Prticas Especficas): Uma prtica especfica uma actividade que considerada importante e descreve as actividades necessrias para a obteno do objectivo especfico associado rea de processo.
17
Captulo 2 Modelo CMMI Commom Features (Caractersticas Comuns): As quatro caractersticas comuns organizam as prticas genricas de cada rea de processo: Commitment to Perform (CO) Compromisso de Execuo; Ability to Perform (AB) Capacidade de Execuo; Directing Implementation (DI) Gesto de Implementao; Verifying Implementation (VE) Verificao de Implementao.
Maturity Levels (Nveis de Maturidade): O nvel de maturidade de uma organizao providencia uma maneira de prever a sua performance futura dentro de uma dada disciplina ou conjunto de disciplinas. A experincia mostra que as organizaes atingem o seu potencial quando focam o esforo da melhoria de processos num nmero conveniente de reas de processo, que requerem um esforo crescente, acompanhando o nvel de melhoria da organizao. Um nvel de maturidade um conjunto evolucionrio de melhoria de processos, que consiste num conjunto predefinido de reas de processo e so medidos aquando da obteno dos objectivos genricos e especficos aplicados a esse conjunto. Cada nvel estabiliza uma parte importante dos processos da organizao. Nos modelos CMMI de uma representao Faseada, existem cinco nveis de maturidade, onde cada um uma camada na fundao do caminho da melhoria dos processos, designados pelos nmeros de 1 a 5:
Nvel 1 Initial ou Ad-hoc No nvel 1, os processos so normalmente ad-hoc e caticos e a organizao no dispe de um ambiente estvel. O sucesso nesse tipo de organizaes depende fortemente e quase exclusivamente da competncia e capacidades das pessoas que compem essa organizao e no no uso de processos comprovados. No mbito deste ambiente ad-hoc e catico, a organizao no nvel de maturidade 1 frequentemente produz servios e produtos que funcionam, mas tambm na grande maioria excedem o oramento e prazos nos seus projectos. Numa organizao, este nvel caracterizado por uma tendncia de incumprimento de prazos, abandono de processos em tempo de crise e impossibilidade de repetio de sucessos passados (no-reutilizao de produtos e/ou servios funcionais).
18
Captulo 2 Modelo CMMI Nvel 2 Managed ou Repeatable No nvel 2, a organizao cumpriu e atingiu todos os objectivos genricos e especficos das reas de processo desse mesmo nvel. Por outras palavras, os projectos da organizao garantem que os requisitos, produtos de trabalho e servios so geridos e os processos so planeados, executados, medidos e controlados. A disciplina de processo reflectida pelo nvel de maturidade 2 ajuda garantia que as prticas existentes so retidas durante alturas de stress e crises, permitindo que os projectos sejam desenvolvidos e geridos de acordo com os planos documentados. So estabelecidos compromissos entre stakeholders (pessoas que interagem e so afectadas pelo projecto) relevantes, sendo revistos sempre que necessrios. Os produtos de trabalho e servios satisfazem os seus requisitos especficos, standards e objectivos e so revistos e controlados com os stakeholders.
Nvel 3 - Defined No nvel 3, os processos so bem caracterizados e compreendidos e so descritos em standards, procedimentos, ferramentas e mtodos. O conjunto de processos standard da organizao, que a base do nvel 3, estabelecido e melhorado ao longo do tempo sendo usado para estabelecer uma consistncia por toda a organizao. A gesto da organizao estabelece objectivos de processos baseados no conjunto standard de processos da organizao e garante que esses objectivos so considerados de forma apropriada. Os processos so tipicamente descritos em maior detalhe e rigor do que no nvel 2. Neste nvel, so geridos de uma forma mais pr-activa usando uma compreenso das inter-relaes das actividades e medidas detalhadas dos processos, produtos de trabalho e servios.
Nvel 4 - Quantitatively Managed No nvel 4, so seleccionados os sub-processos que contribuem significativamente para uma melhoria dos processos gerais. Estes sub-processos so controlados usando tcnicas quantitativas e de estatstica. So estabelecidos 19
Captulo 2 Modelo CMMI objectivos quantitativos para a qualidade e performance dos processos e so baseados nas necessidades do cliente, utilizadores finais, organizao e implementadores de processos. A qualidade e desempenho dos processos so compreendidos em termos estatsticos e so geridos ao longo da sua vida, sendo incorporados na gesto do repositrio da organizao para o suporte da tomada de decises futuras. A distino crtica entre os nveis 3 e 4 a previsibilidade da performance dos processos. No nvel de maturidade 4, a performance dos processos controlada usando tcnicas quantitativas e estatsticas, sendo quantitativamente previsvel.
Nvel 5 - Optimizing No nvel 5 focado a melhoria contnua da performance dos processos atravs de melhorias incrementais e de inovao tecnolgica. Os objectivos de melhoria de processos quantitativos so estabelecidos e continuamente revistos de modo a reflectir mudanas nos objectivos de negcio, sendo usados como critrio na gesto da melhoria dos processos. Os efeitos dessa melhoria so medidos e avaliados versus os objectivos de melhoria dos processos quantitativos. Tanto os processos definidos como o conjunto dos processos standard da organizao so alvo das actividades de melhoria. As melhorias dos processos so identificadas, avaliadas e implementadas versus o custo e impacto na organizao. A performance dos processos da organizao continuamente melhorada. A distino crtica entre os nveis 4 e 5 o tipo de variao de processos endereado. No nvel 5, os processos esto centrados no endereamento das causas comuns da variao e mudana dos processos, na melhoria da performance dos mesmos e na obteno dos objectivos de melhoria de processos quantitativos estabelecidos.
As organizaes podem atingir melhorias progressivas no que diz respeito sua maturidade, atingindo inicialmente uma estabilidade a nvel do projecto e avanando nos nveis seguintes e na melhoria contnua dos processos, usando tanto dados quantitativos como qualitativos na tomada de deciso.
20
Captulo 2 Modelo CMMI A representao Faseada identifica os nveis de maturidade atravs dos quais uma organizao deve evoluir para estabelecer uma cultura de excelncia. Como cada nvel de maturidade tem a sua base no nvel anterior, passar nveis de maturidade normalmente contra-produtivo. Um processo definido que caracterstica do nvel 3 pode ser posto em risco se as prticas de gesto do nvel 2 estiverem deficientemente definidas e implementadas. Por exemplo, uma m gesto pode criar um fraco planeamento de compromisso do calendrio ou levar falha do controlo de mudanas dos requisitos de base (Jokela e Lalli 2003). A Figura 3 resume as caractersticas dos cinco nveis de maturidade apresentados anteriormente:
Figura 3 - Nveis de Maturidade do Modelo CMMI
Fonte: [eProject 2004]
Process Areas (reas de Processo): A rea de processo um conjunto de prticas relacionadas que, quando executadas de forma colectiva, satisfazem um conjunto de objectivos considerados importantes para melhorias significativas nessa rea. As reas de processo so organizadas por nveis de maturidade, como se pode verificar na Figura 4.
21
Captulo 2 Modelo CMMI Atravs da aquisio e anlise dos dados vindos das actividades dirias, experincias e lies aprendidas, as deficincias existentes podem ser identificadas e melhoradas de forma contnua e a maturidade da capacidade do processo de software pode ser gradualmente promovida (Paulk et al. 1993, Ruzhi e Peiyao 2005, Xu et al. 2006). Uma organizao s se poder certificar num determinado nvel de maturidade CMMI quando implementar todas as reas de processo desse nvel e as do nvel abaixo, ou seja, se, por exemplo, uma organizao pretender obter uma certificao CMMI em nvel 3, ter de implementar no s todas as reas de processo do nvel 3 mas tambm todas as do nvel 2.
Figura 4 - reas de Processo da Representao Faseada
Fonte: [SEI 2007]
Categorias das reas de Processo As reas de processo podem ser agrupadas em quatro categorias (Gesto de Processos, Gesto de Projectos, Engenharia e Suporte), como se encontra representado na Figura 5:
22
Figura 5 - Categorias das reas de Processo
Fonte: [Jones e Soule 2002]
Process Management (Gesto de Processos) As reas de processo da Gesto de Processos contm as actividades transversais relacionadas com a definio, planeamento, recursos, implementao, monitorizao, controlo, apreciao e melhoria. As reas de processo do CMMI relacionadas com esta gesto so: Focus no Processo (Organizational Process Focus - OPF); Definio de Processos (Organizational Process Definition - OPD); Formao (Organizational Training OT) Desempenho dos Processos (Organizational Process Performance - OPP); Inovao e Implementao (Organizational Innovation and Deployment - OID).
As reas de processo bsicas da Gesto de Processos fornecem organizao a capacidade bsica de documentar e partilhar boas prticas, processos activos e aprendizagem ao longo da organizao.
23
Figura 6 - reas de Processo Bsicas da Gesto de Processos
Fonte: [SEI 2007]
Como se encontra ilustrado na Figura 6, o Focus no Processo (OPF) ajuda a organizao a planear e implementar as melhorias de processos baseados no conhecimento dos actuais pontos fortes e pontos fracos dos processos da organizao e dos processos activos. A Definio de Processos (OPD) estabelece e mantm o conjunto de processos standard da organizao e outros activos, baseado nas necessidades dos processos e objectivos da organizao. A rea de Formao (OT) identifica as necessidades de formao estratgicas da organizao bem como as necessidades de formao tcticas que so comuns a todos os projectos e grupos de suporte.
As reas de processo avanadas da Gesto de Processos fornecem organizao a capacidade avanada de atingir os objectivos quantitativos para a qualidade e performance de processos.
24
Figura 7 - reas de Processo Avanadas da Gesto de Processos
Fonte: [SEI 2007] Como ilustrado na Figura 7, o Desempenho dos Processos (OPP) deriva os objectivos quantitativos para a qualidade e performance dos processos dos objectivos de negcio da organizao. A organizao complementa os projectos e grupos de suporte com medidas comuns, baselines e modelos da performance dos processos. A Inovao e Implementao (OID) selecciona e implementa melhorias inovadores e incrementais que aumentam a capacidade da organizao em atingir os objectivos de qualidade e performance dos processos.
Project Management (Gesto de Projecto) As reas de processo da gesto de projecto cobrem as actividades relativas a planeamento, monitorizao e controlo do projecto. As reas de processo do CMMI relacionadas com esta Gesto so: Planeamento do Projecto (Project Planning - PP); Monitorizao e Controlo do Projecto (Project Monitoring and Control - PMC); Gesto de Acordos com Fornecedores (Supplier Agreement Management SAM);
25
Captulo 2 Modelo CMMI Gesto de Projecto Integrada para IPPD (Integrated Project Management for IPPD IPM for IPPD); Gesto de Riscos (Risk Management - RSKM); Equipas Integradas (Integrated Teaming - IT); Gesto de Fornecedores Integrada (Integrated Supplier Management - ISM); Gesto de Projecto Quantitativa (Quantitative Project Management - QPM).
As reas bsicas da Gesto de Projecto endeream as actividades relacionadas com o estabelecimento e manuteno do plano do projecto e dos compromissos, monitorizao do progresso tendo em conta o plano, tomada de aces correctivas e gesto de acordos com fornecedores. Como ilustrado na Figura 8, o Planeamento do Projecto (PP) inclui o desenvolvimento do plano do projecto, o envolvimento apropriado dos stakeholders, a obteno de compromissos com o plano e a manuteno do mesmo. Por exemplo, esses planos cobrem avaliao do processo, avaliao do produto, gesto de configurao, medidas e anlises.
Figura 8 - reas de Processo Bsicas da Gesto de Projectos
Fonte: [SEI 2007] 26
A Monitorizao e Controlo do Projecto (PMC) inclui a monitorizao das actividades e tomada de aces correctivas. O plano do projecto especifica o nvel apropriado da monitorizao do projecto, a frequncia das revises do progresso e as medidas usadas para monitorizar esse progresso. O progresso primariamente determinado atravs da comparao do progresso com o plano. Quando se verifica um desvio significativo dos valores esperados, so tomadas as aces correctivas apropriadas. Tais aces incluem o replaneamento. A Gesto de Acordos com Fornecedores (SAM) enderea a necessidade do projecto em adquirir de forma efectiva as pores de trabalho que so produzidas pelos fornecedores. Assim que a componente de um produto identificada e o fornecedor que o ir produzir seleccionado, estabelecido e mantido um acordo com esse fornecedor que ir ser usado para fazer a sua gesto, atravs da monitorizao da sua performance e do seu progresso. No componente produzido pelo fornecedor so conduzidos testes e revises.
As reas avanadas de Gesto de Projecto endeream as actividades de estabelecimento de processos definidos que so adaptados do conjunto de processos standard da organizao, coordenao e colaborao com os stakeholders relevantes (incluindo fornecedores), gesto de risco, formao e manuteno de equipas integradas para a conduo dos projectos e gesto quantitativa dos processos definidos do projecto. Como ilustrado na Figura 9, a Gesto de Projecto Integrada para IPPD (IPM for IPPD) estabelece e mantm os processos definidos que so adaptados do conjunto de processos standard da organizao, sendo o projecto gerido atravs desses processos definidos. O projecto usa e contribui para os processos activos da organizao, assegurando que os stakeholders relevantes associados ao projecto coordenam os seus esforos de forma atempada, atravs da gesto do envolvimento, identificao, negociao e rastreabilidade das dependncias crticas e resoluo da coordenao com os stakeholders das principais questes do projecto. A gesto de Projecto integrada implementa e integra a estrutura da equipa com o objectivo de direccionar o trabalho do projecto no desenvolvimento do produto. Esta estrutura da equipa tipicamente baseada na decomposio do produto. Esta actividade cumprida em conjuno com a rea de processo das Equipas Integradas (IT).
27
Figura 9 - reas de Processo Avanadas da Gesto de Projectos
Fonte: [SEI 2007]
Apesar da identificao e monitorizao de riscos ser coberta no PP e PMC, a Gesto de Riscos (RSKM) possui uma maior continuidade e uma viso de futuro aproximada de gesto de riscos com as actividades que incluem identificao dos parmetros de risco, avaliao e manipulao dos mesmos. A Gesto de Projectos Quantitativa (QPM) aplica tcnicas quantitativas e estatsticas para gerir a performance dos processos e produzir qualidade. Os objectivos de qualidade e desempenho dos processos para o projecto so baseados nos estabelecidos pela organizao. As Equipas Integradas (IT) desenvolvem a viso partilhada das equipas participantes no projecto, que tero de alinhar com as vises partilhadas do projecto e da organizao, disponibilizando o ambiente para possibilitar o trabalho de equipa integrado. A rea de processo de integrao de equipas interage com outros processos da gesto de projecto atravs do fornecimento de compromissos das equipas, planos de trabalho e outra informao que forma a base para a gesto do projecto e o suporte da gesto de riscos. Por fim, a Gesto de Fornecedores Integrada (ISM) identifica proactivamente a origem dos produtos que podero ser usados na satisfao dos requisitos do projecto e
28
Captulo 2 Modelo CMMI monitoriza os produtos seleccionados e os processos, enquanto mantm uma relao cooperativa entre o projecto e o fornecedor. Esta gesto selecciona potenciais fontes de produtos, avaliando essas fontes para seleccionar os fornecedores, monitorizar os processos e produtos de trabalho do fornecedor escolhido e rev, sempre que apropriado, a relao ou acordos com os fornecedores.
Engineering (Engenharia) As reas de processo de Engenharia cobrem o desenvolvimento e manuteno das actividades que so partilhadas ao longo das disciplinas de engenharia (engenharia de sistemas e engenharia de software). As reas de processo do CMMI relacionadas com a Engenharia so: Desenvolvimento de Requisitos (Requirements Development RD); Gesto de Requisitos (Requirements Management - REQM); Soluo Tcnica (Technical Solution - TS); Integrao do Produto (Product Integration - PI); Verificao (Verification VER); Validao (Validation VAL). As reas de processo integram processos de engenharia de software e engenharia de sistemas num cenrio orientado ao produto e melhoria de processos. Estas reas de processo aplicam-se ao desenvolvimento de qualquer produto ou servio no domnio do desenvolvimento da engenharia (produtos de software e de hardware, servios ou processos). Como ilustrado na Figura 10, o Desenvolvimento de Requisitos (RD) identifica as necessidades do cliente e trad-las em requisitos do produto. O conjunto de requisitos do produto analisado para produzir uma soluo conceptual de alto nvel. Este conjunto de requisitos ento alocado a um conjunto de requisitos de componentes do produto. Esta rea fornece requisitos rea da Soluo Tcnica (TS), onde os requisitos so ento convertidos na arquitectura do produto, no design das componentes do produto e na prpria componente do produto (cdigo, fabricao). Os requisitos so tambm fornecidos rea de Integrao do Produto (PI), onde as componentes do produto so combinadas e as interfaces so asseguradas para dar resposta aos requisitos de interface fornecidos pelo Desenvolvimento de Requisitos (RD).
29
Figura 10 - reas de Processo da Engenharia
Fonte: [SEI 2007] A Gesto de Requisitos (REQM) mantm os requisitos, descreve as actividades para obteno e controlo das mudanas de requisitos, garantindo que os outros planos e dados relevantes se mantm actuais e providencia ratreabilidade dos requisitos do cliente ao produto e s suas componentes. Esta rea garante que as mudanas nos requisitos so reflectidas nos planos do projecto, actividades e produtos de trabalho. Este ciclo de mudanas pode ter impacto nas outras reas de processo da Engenharia. Estabelecer e manter a rea de Gesto de Requisitos fundamental para um processo de design de processo de engenharia controlado e disciplinado. Em qualquer tipo de desenvolvimento, requisitos slidos so o fundamento no s dos processos de desenvolvimento mas tambm das actividades de verificao. Isto bem ilustrado atravs do V-Model (Figura 11), tipicamente associado com o desenvolvimento de software. Sem uma base slida dos requisitos de testes de sistema que so traados para as especificaes do produto, descries de design e planos de teste, todas as outras reas de processo esto potencialmente comprometidas (Stevens 2007).
30
Figura 11 - V-Model
Fonte: [WIKIPEDIA 2008] A Soluo Tcnica (TS) desenvolve pacotes de dados tcnicos para as componentes do produto que iro ser usados pela rea da Integrao do Produto (PI). O exame de solues alternativas feito com o objectivo de seleccionar o melhor desenvolvimento do produto baseado em critrios estabelecidos. Estes critrios podem ser significativamente diferentes entre produtos, dependendo do seu tipo, ambiente operacional, requisitos de desempenho e de suporte, custo e prazos de entrega. A tarefa de seleccionar uma soluo final faz uso das prticas especficas da rea de processo da Anlise e Resoluo de Deciso (CAR), que ser vista frente, como uma rea de processo de Support (Suporte). Esta rea baseia-se nas prticas especficas na rea de processo de Verificao (VER) para desempenhar a verificao do desenvolvimento e revises de pares, desde a sua concepo at construo final. A rea de Verificao (VER) assegura que os produtos seleccionados do resposta aos requisitos especificados. Selecciona tambm os produtos de trabalho e os mtodos de trabalho que iro ser usados para verificar esses produtos de trabalho contra os requisitos especificados. A Verificao (VER) tambm enderea revises de pares. As revises de pares so um mtodo provado para a remoo de defeitos de forma antecipada e concesso de valor acrescido aos produtos de trabalho e suas componentes que iro ser desenvolvidas e mantidas. 31
Captulo 2 Modelo CMMI A rea de processo de Validao (VAL) inclui a validao dos produtos, componentes do produto, produtos de trabalho intermedirios e processos. Estes produtos, componentes e processos podem por vezes requerer re-verificao e revalidao. Os problemas descobertos durante a validao so geralmente resolvidos nas reas de Desenvolvimento de Requisitos (RD) ou Soluo Tcnica (TS). A Integrao do Produto (PI) estabelece as prticas especficas esperadas, associadas com a gerao da melhor sequncia de integrao possvel, integrao de componentes do produto e entrega do produto ao cliente. Esta rea usa as prticas especficas tanto das reas de Validao (VAL) como de Verificao (VER) na implementao do processo de integrao do produto. Aquando da implementao das prticas especficas de uma rea de processo da Engenharia, estas tero de ser interpretadas relativamente ao modo como iro dar resposta s necessidades do produto. Existe um grande nmero de vantagens que advm desta abordagem, por exemplo, as reas de Engenharia podem ser aplicadas a um produto que tenha vrias camadas de componentes e garantir que as prticas especficas se iro enderear a cada camada. Alm disso diferentes segmentos de um projecto de grandes dimenses podem ser avaliadas usando o mesmo modelo.
Support (Suporte) As reas de processo de Suporte cobrem as actividades que suportam o desenvolvimento e manuteno do produto. Esta rea enderea os processos que so usados no contexto de desenvolvimento de outros processos e tambm os processos que so direccionados para o projecto, podendo tambm enderear processos que se aplicam mais globalmente organizao. As reas de processo do CMMI relacionadas com o Suporte so: Gesto de Configurao (Configuration Management CM); Garantia de Qualidade dos Processos e Produtos (Process and Product Quality Assurance - PPQA); Medida e Anlises (Measurement and Analysis MA); Anlise e Resoluo da Deciso (Decision Analysis and Resolution - DAR); Ambiente Organizacional para Integrao (Organizational Environment for Integration - OEI); Anlise e Resoluo Causal (Causal Analysis and Resolution - CAR).
32
As reas bsicas de Suporte endeream as funes de suporte que so usadas por todas as reas de processo e providenciam funes de suporte que so cobertas por prticas genricas.
Figura 12 - reas de Processo Bsicas de Suporte
Fonte: [SEI 2007]
Como ilustrado na Figura 12, a rea de Medida e Anlises (MA) suporta todas as reas de processo providenciando prticas especficas que guiam projectos e organizaes no alinhamento de necessidades de medidas e objectivos, com uma aproximao de medidas que iro disponibilizar os resultados dos objectivos. Esses resultados podem ser usados na tomada de decises e aces correctivas. A Garantia de Qualidade dos Processos e Produtos (PPQA) suporta todas as reas de processo providenciando prticas especficas para a avaliao objectiva de processos, produtos de trabalho e servios contra as descries de processos aplicveis, standards e procedimentos, garantindo que qualquer problema vindo dessas revises ser endereado. Esta rea suporta a garantia de produtos de alta qualidade e servios providenciando ao staff e a todos os nveis de gestores uma visibilidade apropriada dos processos e produtos de trabalho associados ao longo da vida do projecto. A Gesto de Configurao (CM) suporta todas as reas de processo estabelecendo e mantendo a integridade dos produtos de trabalho usando a identificao, controlo e auditorias configurao. Os produtos de trabalho colocados em CM incluem os produtos entregues ao cliente, produtos internos, produtos adquiridos, ferramentas e outros itens que so usados na criao e descrio desses produtos de trabalho. Exemplos desses produtos de trabalho so os planos, descrio de processos, requisitos, 33
Captulo 2 Modelo CMMI dados de design, desenhos, especificao de produtos, cdigo, compiladores, ficheiros e publicaes tcnicas do produto.
As reas avanadas de Suporte fornecem aos projectos e organizao uma capacidade de suporte avanada. Cada uma das reas de processo baseia-se em inputs especficos ou prticas de outras reas de processo.
Figura 13 - reas de Processo Avanadas de Suporte
Fonte: [SEI 2007]
Como ilustrado na Figura 13, usando a Anlise e Resoluo Causal (CAR), possvel obter uma compreenso das causas comuns da variao inerente aos processos e a possibilidade da sua remoo nos processos do projecto, bem como usar o seu conhecimento para melhorar de forma contnua os processos da organizao. A Anlise e Resoluo da Deciso (DAR) suporta todas as reas de processo providenciando um processo de avaliao formal que garante que as alternativas so comparadas e que a melhor ser seleccionada para atingir os objectivos das reas de processo. A rea de Ambiente Organizacional para Integrao (OEI) promove tanto a excelncia da equipa, como a individual, enquanto disponibiliza e contempla a integrao de todos os negcios e funes de negcio na execuo dos projectos. 34
2.4.
Escolher um Modelo
A seleco do modelo depende da(s) disciplina(s) relevante(s) para a organizao dentro do seu mbito de actividade. Se a organizao est preocupada exclusivamente com as actividades de Engenharia de Software ou com as actividades de Engenharia de Sistemas, ento os modelos apropriados so CMMI-SW e CMMI-SE respectivamente. No entanto, se a organizao est preocupada com ambos os sistemas, ento usar um modelo combinado CMMI-SW/SE ser mais apropriado, j que ir encorajar a melhoria de prticas integradas, reduzindo repeties e problemas administrativos que so comuns quando se usa mais de um modelo. Se a organizao emprega o desenvolvimento de produto e processo integrado nas suas actividades, ento um modelo que inclua IPPD (Integrated Product and Process Development) ser mais apropriado. E se a organizao est preocupada com os seus fornecedores, um modelo que inclua Desenvolvimento com Sub-Contratao (SS Supplier Sourcing) ser o mais apropriado. A organizao deve decidir qual dos modelos melhor se adequa s suas necessidades. Deve-se seleccionar uma representao, contnua ou faseada, e determinar as disciplinas a serem includas no modelo que a organizao ir usar.
2.5.
Benefcios na Implementao do CMMI
Nos dias de hoje o CMMI usado em todo o mundo em organizaes militares, comerciais e governamentais. J foi demonstrado que a reduo dos riscos associados ao desenvolvimento dos projectos aumenta a eficincia e melhora de modo geral a qualidade dos produtos desenvolvidos ao longo da vida do projecto e dos produtos entregues ao cliente (entregveis). Muitas indstrias civis, como a indstria de transportes e telecomunicaes, esto a fazer da reduo dos riscos um requisito na execuo de grandes projectos. Pases como a China e a ndia usam esta melhoria da qualidade para se posicionarem como fornecedores fiveis de servios de outsourcing a nvel mundial (Dion 2003). Apesar do CMMI no ter como principal objectivo cobrir todos os aspectos do software e do desenvolvimento de sistemas, e de no garantir que a sua implementao ir automaticamente levar ao sucesso de um projecto, a sua adopo ir aumentar de forma significativa a probabilidade de sucesso no processo de software (Subbiah e Sethuraman 2006)
35
Captulo 2 Modelo CMMI A seguir destacam-se os maiores benefcios que se podem atingir ao usar o CMMI numa organizao:
Conhecer o negcio
Ser que na organizao todos os que esto envolvidos nos projectos sabem exactamente qual o seu trabalho e como que ele se relaciona com todos os outros elementos envolvidos? Se se perguntar ao... Gestor do Projecto: o Qual a diferena entre plano e calendrio? o Quais so os registos que se guardam em termos de estimativas que esto a ser feitas? o Aquando do planeamento, estimado o tamanho e o esforo? Ambos os atributos so monitorizados ao longo do ciclo de vida do projecto?
Gestor de Configurao o O que uma baseline? o Qual o propsito de uma auditoria de configurao? o Quem autoriza as mudanas nas unidades de configurao?
Analista de Garantia de Qualidade o Qual o objecto da Garantia de Qualidade? o Qual a diferena entre Garantia de Qualidade e Controlo de Qualidade? E de Teste? o Quem que na organizao conhece as actividades de Garantia de Qualidade e os seus resultados?
Se as pessoas visadas no conseguirem responder de forma correcta a estas questes ou se ningum souber que papis so estes e quem os desempenha, ento necessria uma formao urgente do negcio. O CMMI pode ser a resposta para essa formao.
36
Captulo 2 Modelo CMMI Saber a posio onde se est
A organizao est a ter melhores ou piores resultados que os seus concorrentes? No que diz respeito melhoria de processos, a organizao cutting edge ou laggard?
O CMMI tanto completo como universalmente relevante, permitindo uma apreciao detalhada da performance do processo nas organizaes e segmentos da indstria (Dion 2003). Em vez de ser uma receita que deve ser seguida de forma cega e fielmente como um dogma, o CMMI uma lista de aspectos bem organizados que necessitam ser tratados com o objectivo do desenvolvimento de projecto ser sistematicamente bem sucedido. Alinhar o plano de melhoria aos nveis de CMMI assegura que nada esquecido (Dion 2003).
Posicionar-se como uma organizao de boas-prticas
Se a organizao desenvolve produtos, provavelmente querer-se- que os clientes (quer sejam internos ou externos) olhem a organizao como sendo um fornecedor disciplinado, conhecedor e fivel. Aderir aos princpios e prticas do CMMI um caminho para atingir tal percepo e realidade por parte dos clientes e ao se comprometerem publicamente como dizer Ns vamos fazer as coisas certas e iremos faz-las de forma certa! Foi verificado em diversos estudos que as organizaes que investiram entre 5% a 10% dos seus custos de operao na melhoria de processos, normalmente obtiveram um retorno do investimento a nvel dos 100% no primeiro ano e cerca de 400% nos 3 a 5 anos seguintes. Estes retornos so baseados em redues do nmero de defeitos, melhor e mais rpida resposta ao mercado, melhorias nas capacidades de estimativa e um melhor controlo do projecto, resultando em menores desvios de custo e calendrio (Dion 2003). Alguns exemplos desses benefcios, obtidos em empresas conceituadas so (Subbiah e Sethuraman 2006, SEI 2007):
37
Captulo 2 Modelo CMMI Custos 33% decrscimo de custo mdio para reparao de um defeito (Boeing); 20% reduo do custo da unidade de software (Lockheed Martin); Reduo de custo da m qualidade de 45% para 30% num perodo de 3 anos (Siemens); 10% decrscimo de custos globais por nvel de maturidade (Northrop Grumman).
Tempo 50% reduo no tempo de resposta (Boeing); 60% reduo de trabalho de correco aps testes efectuados (Boeing); Aumento de 50% a 95% do nmero de objectivos atingidos (General Motors).
Produtividade 25% a 30% aumento da produtividade num perodo de 3 anos (Lockheed Martin, Harris, Siemens).
Qualidade 50% reduo dos defeitos de software (Lockheed Martin); Reduo dos defeitos e da gravidade dos mesmos em ps-produo (JP Morgan); Melhoria na qualidade do cdigo desenvolvido (Sanchez Computer Associates, Inc.).
As organizaes no devem confundir os objectivos do CMMI com os objectivos de negcio. Atingir a maturidade do CMMI no garante organizao que ir atingir os seus objectivos de negcio. No entanto, o CMMI providencia uma ferramenta poderosa de os guiar na direco correcta (Miller et al. 2002).
38
2.6.
Problemas e Limitaes do CMMI
O CMMI apenas se concentra no processo como um factor do desenvolvimento de software, sendo por vezes criticado pelo facto que promove o processo acima de todas as outras questes, omitindo as pessoas e as tecnologias (Subbiah e Sethuraman 2006). O CMMI foca-se em algumas reas de desenvolvimento e entrega, em particular processos relacionados a projectos. Na construo, definio e documentao existe a necessidade de obter informao de outras reas de conhecimento, reas essas que no esto bem endereadas pelo CMMI como (Rochecouste 2003): Gesto de recursos humanos; Desenvolvimento de negcio; Gesto de contratos e suporte logstico.
O CMMI no a resposta para todas as organizaes. Os seus requisitos rgidos em termos de documentao e progresso passo-a-passo f-lo mais adequado para organizaes maiores do que para aquelas mais pequenas. Mas mesmo as maiores organizaes comerciais que desenvolvem software, incluindo companhias como a Apple Computer Inc. e a Microsoft Corp., raramente gerem os seus documentos de requisitos to formalmente como o CMMI requer. Como esse nvel de documentao um requisito para o nvel 2, todas essas companhias, se fosse medido o seu nvel de maturao, estariam no nvel 1, Initial ou Ad-hoc. Em particular, o CMMI no diz a uma organizao como implementar as melhorias no desenvolvimento do seu software, somente indica onde so necessrias (Kay 2005). Um dos principais problemas que o CMMI possui o facto das reas de processo se focarem principalmente em actividades e artefactos de suporte associados a um processo convencional de waterfall: especificao de requisitos, planos documentados, auditorias de garantia de qualidade e inspeces e tambm processos documentados e procedimentos. Muito poucas reas endeream os resultados envolventes (produto de software) e entregveis de engenharia associados (modelos caso-de-uso, modelos de design, cdigo fonte ou cdigo de execuo) que capturam o principal alvo real do produto. Alm disso, no feita uma nfase dos processo de arquitectura/design, avaliao ou desenvolvimento, processos esses que j provaram ser pontos-chave para o sucesso do projecto. Outro problema passa pela necessidade das organizaes produzirem mais documentao, mais checkpoints, mais artefactos, mais rastreabilidade, mais revises e
39
Captulo 2 Modelo CMMI mais planos e logo consequentemente documentos de maior dimenso, informao mais detalhada e reunies mais demoradas. Tal entra um pouco em conflito com a tcnica primria de melhoria de economia de software: reduzir complexidade e o volume de itens gerados pelo staff. Obter uma medida exacta do nvel de maturidade corrente da organizao tambm um problema. O CMMI tem uma abordagem baseada nas actividades para a medio da maturidade: se a organizao atingir um conjunto de actividades est no nvel 2; se a organizao prescrever um outro conjunto de actividades est no nvel 3; e assim sucessivamente. No existe nada que caracterize ou quantifique se a organizao faz essas actividades suficientemente bem para a entrega dos resultados esperados (Royce 2002).
2.7.
Adopo do CMMI
A certificao CMMI obtida atravs de um Lead Appraiser que, aps uma auditoria, verifica se a organizao implementou todas as reas de processo necessrias ao nvel de certificao pretendido, dando resposta aos objectivos especficos de cada uma dessas reas. Esse Lead Appraiser algum que, entre outros requisitos, aprovado via exame oral, recebendo um diploma de certificao do organismo criador do CMMI, o Software Engineering Institute, dando-o como apto a poder determinar qual o nvel de maturidade de uma determinada organizao e, por conseguinte, poder certific-la oficialmente. O CMMI foi adoptado ou est em adopo por um grande nmero de organizaes internacionais, estando algumas identificadas na Tabela 3 a ttulo de exemplo:
Accenture Boeing Dyncorp FAA General Dynamics Honeywell Intel L3 Communications NASA Nokia Polaris SAIC 40
Bank of America Bosch EDS Fannie Mae General Motors IBM Global Services J.P. Morgan Lockheed Martin NDIA Northrop Raytheon Samsung
BMW Ericsson Fujitsu Hitachi Infosys KPMG Motorola NEC NRO NTT DATA Reuters Social Security Administration
Captulo 2 Modelo CMMI Tata Consultancy Services U.S. Army Wipro TRW U.S. Navy Zuriich Financial Services U.S. Air Force U.S. Treasury Department
Tabela 3 - Adopo do CMMI (Internacional)
Fonte: [SEI 2007] E tambm por (poucas) empresas nacionais, conforme possvel constatar na Tabela 4: BCP Banco Santander Critical Software Novabase
Tabela 4 - Adopo do CMMI (Nacional)
Fonte: [SEI 2007]
Como se pode verificar na Tabela 5, em que esto indicados os pases com 10 ou mais organizaes certificadas, Portugal no se encontra indicado. Na Figura 14, est representado o nmero de empresas certificadas distribudas pelo seu nvel de certificao. Pas E.U.A. ndia China Japo Frana Coreia Reino Unido Brasil Tailndia N de Certificaes 598 177 158 155 65 56 42 39 31 Pas Alemanha Espanha Austrlia Canad Argentina Malsia Filipinas Egipto Outros 33 pases N de Certificaes 28 25 23 18 15 15 14 10
Tabela 5 - N de Certificaes CMMI por Pas
Fonte: [SEI 2007]
41
Figura 14 - N de Organizaes por Nvel de Certificao
Fonte: [SEI 2007]
Como se pode verificar, a qualidade ainda algo em que as empresas nacionais pouco apostam, ao contrrio das internacionais em que, por exemplo nos E.U.A., consideram a qualidade nas organizaes como um requisito indispensvel para um bom desenvolvimento de processos de software e crescimento organizacional.
2.8.
Casos de Sucesso de Implementao do CMMI
Por vezes, as organizaes esto to satisfeitas com a sua performance, que comeam a ficar relutantes a mudanas, mas elas no podem passar ao lado do inevitvel. Na competitiva indstria de software, a capacidade de questionar e melhorar os procedimentos existentes a diferena entre uma organizao que excede as expectativas dos clientes e dos gestores de alto-nvel e as outras que meramente as atingem. De seguida apresentam-se trs exemplos de casos de sucesso da implementao do CMMI e as vantagens que da advieram.
42
Captulo 2 Modelo CMMI a) Empresa BL Informtica
Desde 2003, a empresa BL Informtica foi motivada, estabeleceu e tem vindo a manter os seus processos de software baseados em standards internacionais (como o ISO 9001:2000) e modelos de maturidade (como o MPS.BR e o CMMI) (Ferreira et al. 2007). Apesar da falta de recursos humanos e financeiros, a organizao atingiu resultados satisfatrios. Para a empresa, os factores mais importantes na fase de desenvolvimento de software foram:
1. Suporte de gesto de alto nvel e compromisso com aces de resoluo de problemas; 2. Suporte de consultadoria externa e transferncia de conhecimento; 3. Melhoria dos mecanismos de comunicao e sistemas de suporte para uma melhor troca de informao; 4. Avaliaes das melhorias efectuados; 5. Lies aprendidas; 6. Difuso e distribuio de tarefas; 7. Investimento em formao interna e externa.
Os benefcios retirados com a aplicao do modelo foram:
1. Melhoria do conhecimento da organizao relacionada com a produtividade (por exemplo, o esforo necessrio para implementar um requisito especfico e a performance da produtividade durante os projectos); 2. Diversas lies aprendidas no que diz respeito s tecnologias usadas e desenvolvimento de requisitos; 3. Decrscimo do tempo gasto em actividades de teste e codificao; 4. Reduo do trabalho de correco.
O retorno definido como recompensa/resultado/benefcio pela execuo de melhorias, normalmente em termos quantitativos (ex: em valor monetrio). Em alguns casos os retornos no-quantificveis (ex: orgulho no trabalho, reputao da organizao,...) podem ser mais importantes.
43
Figura 15 - Relao Trabalho Correco VS Actividades Qualidade de Software
Fonte: [Ferreira et al. 2007] Como se pode constatar na Figura 15, o tempo dispendido no trabalho de correco reduzido devido a uma avaliao mais rigorosa dos entregveis. O facto de se encontrarem os erros nas fases iniciais dos projectos, leva a uma descida do nmero de avaliaes de um entregvel especfico e, em consequncia, na reduo do tempo consumido nas avaliaes. Como se pode verificar na Figura 16, os resultados mostram que, aps a implementao das reas de Verificao e Validao, os defeitos foram detectados nas fases iniciais da vida do projecto, trazendo grandes benefcios para a organizao, como a diminuio de actividades de trabalho de correco, reduo de custos e aumento da satisfao do cliente, um objectivo estratgico para todas as organizaes envolvidas na entrega de servios ao cliente.
44
Figura 16 - Deteco de Defeitos
Fonte: [Ferreira et al. 2007] Os problemas clssicos como atrasos no calendrio, derrapagens de oramentos, pobre definio de requisitos, controlo do mbito e a gesto de configurao e de riscos foram minimizados. Como efeito directo destas conquistas apontado o crescimento da organizao (Ferreira et al. 2007).
b) Empresa AAB
A empresa AAB, lder global em tecnologias de potncia e automatizao, tem desenvolvido produtos de software industrial h mais de 30 anos. Com o passar dos anos, foram tomados vrios passos para transformar a AAB numa organizao reconhecida pela sua excelncia no desenvolvimento de produtos de software. A chave desta transformao foi o uso do CMMI e do modelo de melhoria organizacional IDEALSM (Ekdahl e Larsson 2006, McFeeley 1996), ambos do Software Engineering Institute (SEI). Usar mtodos estruturados de melhoria de processos um caminho bem documentado no que diz respeito ao aumento da maturidade nas organizaes de desenvolvimento de produtos em que diferentes actividades de diagnstico tomam um papel muito importante (Ekdahl e Larsson 2006, Kasse 2002, Kitson e Humphrey 1989, Minnich 2002). 45
Captulo 2 Modelo CMMI As aprovaes internas servem mltiplos propsitos na AAB. A mais importante providenciar uma base slida para a prioritizao e planeamento de aces de melhoria, mas as aprovaes tambm permitiram definir um caminho efectivo para a identificao de boas prticas que podem ser partilhadas entre stios de desenvolvimento. Em adio, as aprovaes internas so teis na preparao de unidades visando uma apresentao formal do nvel CMMI. Finalmente os resultados das aprovaes podem tambm ser usados para se comparar os centros de desenvolvimento individuais para identificao de qual o mais maduro (Ekdahl e Larsson 2006, Kitson e Humphrey 1989, Kasse 2002, McFeeley 1996, Minnich 2002).
c) Governo da Tailndia
A Tailndia muito propensa a secas e as estatsticas dos danos nas colheitas agrcolas nos ltimos 10 anos, devido a desastres naturais, feitas pelo Conselho da Agricultura em 2005, demonstram que as perdas ascenderam a 21,000,000 USD, entre as quais 32% dizem respeito a perdas devido s secas. Assim, o Governo e as organizaes de investigao direccionaram foras para desenvolver um sistema de previso de secas. No entanto, esses sistemas de software disponveis no garantiam fiabilidade com tecnologias diferentes entre diferentes sistemas, devido a no seguirem um standard completo de desenvolvimento de software. Ento, tornou-se deveras importante desenvolver um sistema de previso das secas e a gesto do sistema de informao. Com o CMMI como guia para o desenvolvimento do sistema, seguindo os standards de procedimento de anlise de requisitos, design do sistema,
desenvolvimento, integrao e testes, estabeleceu-se um sistema de alerta e previso de secas em tempo real e fivel com a capacidade de expanso e manuteno. Baseado no modelo CMMI, o desenvolvimento desse software foi feito com o menor custo possvel e uma diminuio do tempo dispendido, tendo em vista a concluso das funes do mesmo, atingindo os objectivos de qualidade (Kung e Hua 2006).
46
3. Abordagem de Investigao
Neste terceiro captulo ir-se-o apresentar de uma maneira muito geral os tipos de investigao qualitativa e quantitativa, seguindo-se a apresentao dos vrios tipos de pesquisa e os mtodos de investigao inerentes investigao qualitativa, visto ser este o tipo de investigao escolhido para a elaborao da dissertao apresentada, j que as suas caractersticas (uso de documentos e dados de observao do participante, elaborao de entrevistas, etc.) vo de encontro ao planificado e levado a cabo para a concretizao desta dissertao. Por fim sero apresentadas, de forma resumida, algumas tcnicas qualitativas de recolha de dados. De referir que a maior parte do contedo deste captulo se baseou na informao disponibilizada pela Association For Information Systems (ISWORLD 2008), tendo sido complementado com outros elementos devidamente referenciados. No que diz respeito abordagem de investigao, uma vez aceite a complementaridade entre as abordagens qualitativa e quantitativa a partir do reconhecimento das especificidades de cada uma, possvel identificar de que maneira podem ser melhor incorporadas no delineamento da pesquisa (Serapioni 2000). Os mtodos qualitativos ajudam no trabalho de construo do objecto estudado, facilitam na descoberta de dimenses no conhecidas do problema e permitem tambm formular e comprovar hipteses. Os mtodos qualitativos devem ser utilizados pela sua capacidade de fazer emergir aspectos novos, de ir ao fundo do significado, de permitir focar a perspectiva do sujeito e tambm quando o objecto de estudo no bem conhecido. De facto, durante a pesquisa, frequentemente emergem relaes entre variveis, motivaes e comportamentos inesperados, que no surgiriam utilizando mtodos quantitativos (Myers 1997, Serapioni 2000). 47
Captulo 3 Abordagem de Investigao
3.1.
Enquadramento da Pesquisa Qualitativa
Os mtodos de pesquisa podem ser classificados de diversos modos, no entanto, uma das distines mais comuns faz-se entre mtodos de pesquisa quantitativos e qualitativos. Os mtodos de pesquisa quantitativos foram originalmente desenvolvidos nas cincias naturais para o estudo de fenmenos naturais. Temos como exemplos de mtodos quantitativos bem aceites nas cincias sociais os inquritos, experincias de laboratrio, mtodos formais (ex: econometria) e mtodos numricos como a modelao matemtica (Straub et al. 2004). A investigao qualitativa envolve o uso de dados qualitativos, tais como entrevistas, documentos e dados de observao do participante, para explicar e compreender o fenmeno social. Os investigadores qualitativos podem ser encontrados em diversas disciplinas e campos, usando uma variedade de abordagens, mtodos e tcnicas. Nos Sistemas de Informao tem havido uma mudana geral na pesquisa dos problemas tecnolgicos para os problemas de gesto e organizacionais, da ter havido um crescente interesse na aplicao de mtodos de investigao qualitativa (Myers 1997, Serapioni 2000). Exemplos de mtodos qualitativos so action research (investigao-aco), estudo de casos e a etnografia. As fontes de dados dos mtodos qualitativos incluem observao e observao participativa (trabalho de campo), entrevistas e questionrios, documentos e textos, as impresses e reaces do investigador. A motivao para fazer pesquisa qualitativa em oposio pesquisa quantitativa, vem da observao de que se existe uma coisa que distingue os humanos do mundo natural a nossa habilidade de falar, permitindo aos investigadores entender as pessoas e o contexto sociocultural em que elas vivem. O objectivo de entender um fenmeno do ponto de vista dos participantes e do seu contexto social e institucional particular amplamente perdido quando os dados textuais so quantificados (Kaplan e Maxwell 1994).
48
3.2.
Perspectivas Filosficas
Todas as pesquisas (quer sejam quantitativas ou qualitativas) so baseadas em pressupostos subjacentes do que constitui uma pesquisa vlida e que mtodos de pesquisa so apropriados. No intuito de conduzir e/ou avaliar uma pesquisa qualitativa , portanto, importante conhecer quais so esses pressupostos. necessrio clarificar que a palavra qualitativa no um sinnimo de interpretativa a pesquisa qualitativa, pode ser ou no interpretativa, dependendo dos pressupostos filosficos que o investigador segue. A pesquisa qualitativa pode ser positivista, interpretativa ou crtica (Figura 17). Resulta da que a escolha de um mtodo especfico de pesquisa qualitativa (como por exemplo o mtodo de estudo de casos) independente da posio filosfica adoptada. Por exemplo, uma pesquisa de um estudo de casos pode ser positivista (Yin 2002), interpretativa (Walsham 1993) ou crtica, tal como a pesquisa de action research pode ser positivista (Clark 1972), interpretativa (Elden e Chisholm 1993) ou crtica (Carr e Kemmis 1986). As trs perspectivas filosficas so discutidas de forma sucinta de seguida.
Figura 17 - Pesquisa Qualitativa
Fonte: (ISWORLD, 2008)

3.2.1. Pesquisa Positivista
Os positivistas geralmente assumem que a realidade objectivamente dada e pode ser descrita por propriedades mensurveis que so independentes do observador (investigador) e do seu instrumento. Os estudos positivistas geralmente tentam testar a teoria, com o objectivo de aumentar o entendimento preditivo do fenmeno. Nesta linha
49
Captulo 3 Abordagem de Investigao de pensamento, a pesquisa dos Sistemas de Informao ser positivista caso haja a evidncia de proposies formais, medidas quantificveis de variveis, teste de hipteses e o desenho de inferncias de um fenmeno de uma amostra para uma populao alvo (Orlikowski e Baroudi 1991). Caractersticas do positivismo (Orlikowski e Baroudi 1991, Gonzlez 1997): Separao entre sujeito (investigador) e o objecto de estudo; Super-valorizao do mtodo (viso instrumentalista) e desconsiderao pela teoria e pela interpretao; Crena no empreendimento cientfico como algo neutro e objectivo; O mtodo cientfico considerado de forma monoltica. O que varia so os objectos de estudo, o mtodo de investigao o mesmo para todas as cincias; Os objectivos da cincia so a descrio imparcial, a predio e o controlo sobre a realidade; Viso determinista acerca da realidade.
3.2.2. Pesquisa Interpretativa
Os investigadores interpretativos assumem que o acesso realidade (dada ou socialmente construda) possvel apenas atravs de construes socais como a linguagem, conscincia e significados partilhados. Os estudos interpretativos geralmente tentam compreender os fenmenos atravs dos significados que as pessoas lhes atribuem, sendo que os mtodos interpretativos de pesquisa nos Sistemas de Informao so destinadas produo e percepo do contexto dos Sistemas de Informao e o processo no qual o Sistema de Informao influencia e influenciado pelo contexto (Walsham 1993).
3.2.3. Pesquisa Crtica
Os investigadores crticos assumem que a realidade social historicamente constituda e produzida e reproduzida pelas pessoas. Apesar das pessoas poderem de forma consciente mudar as suas circunstncias sociais e econmicas, os investigadores crticos reconhecem que a capacidade de o fazerem constrangida por vrios factores sociais, culturais e polticos. A pesquisa crtica foca-se nas oposies, conflitos e
50
Captulo 3 Abordagem de Investigao contradies na sociedade contempornea e procura ser emancipadora, isto , tenta ajudar a eliminar as causas de alienao e dominao (Hirschheim e Klein 1994, Ngwenyama e Lee 1997).
3.3.
Mtodos de Pesquisa Qualitativa
Nesta seco iro ser abordados os diferentes mtodos de pesquisa qualitativa, nomeadamente o estudo de casos, a etnografia, a grounded theory e por fim a action research. Os trs primeiros iro ser apresentados de uma forma geral, j o ltimo mtodo ir ser apresentado em maior detalhe, tendo em conta que as suas caractersticas se aproximam mais do estudo levado a cabo nesta dissertao, tendo por isso sido eleito entre os quatro apresentados. Tal como existem vrias perspectivas filosficas que podem informar sobre pesquisas qualitativas, existem tambm vrios mtodos de pesquisa qualitativa. Um mtodo de pesquisa qualitativa uma estratgia que parte de pressupostos filosficos para a concepo de investigao e recolha de dados. A escolha do mtodo de pesquisa influencia a maneira na qual o investigador recolhe os dados. Mtodos de pesquisa especficos implicam tambm diferentes skills, pressupostos e prticas de pesquisa.
3.3.1. Estudo de Casos
A expresso estudo de casos tem mltiplos significados. Pode ser usado para descrever uma unidade de anlise (por exemplo, o estudo de casos de uma organizao em particular) ou para descrever um mtodo de pesquisa. Apesar de haver inmeras definies, Yin (Yin 2002) define o mbito de um estudo de casos como: investigao de um fenmeno contemporneo dentro do contexto da vida real, especialmente adequado quando as fronteiras entre o fenmeno e o contexto no so claramente evidentes. Este mtodo de investigao adequado para a investigao dos Sistemas de Informao, visto que o objecto da disciplina o estudo dos sistemas de informao nas organizaes e tambm os problemas organizacionais (Bensabat et al. 1987).
51
Captulo 3 Abordagem de Investigao Uma investigao de um estudo de casos pode ser positivista, interpretativa ou crtica, dependente dos pressupostos filosficos subjacentes do investigador. Yin e Bensabat (Yin 2002, Bensabat et al. 1987) so adeptos de uma investigao positivista enquanto que Walsham (Walsham 1993) adopta uma investigao interpretativa no que diz respeito investigao de estudo de casos (Orlikowski e Baroudi 1991).
3.3.2. Etnografia
A investigao etnogrfica vem da antropologia social e cultural onde um etngrafo necessita de passar grande parte do tempo em trabalho de campo. Os etngrafos integram-se na vida das pessoas que estudam, procurando colocar o fenmeno estudado no seu contexto sociocultural (Lewis 1985). A etnografia comeou mais recentemente a ser mais usada no estudo de sistemas de informao nas organizaes, desde o estudo do desenvolvimento dos sistemas de informao ao estudo dos aspectos da gesto da tecnologia de informao (Wynn 1979, Suchman 1987, Zuboff 1988, Preston 1991, Davies e Nielsen 1992, Hughes et al. 1992). A etnografia foi tambm discutida como um mtodo onde mltiplas perspectivas podem ser incorporadas na concepo de sistemas e tambm como uma abordagem geral ao vasto leque de possveis estudos relativos investigao de sistemas de informao. Na rea da concepo e avaliao dos sistemas de informao, algum trabalho interessante est a ser levado a cabo por etngrafos de um lado e designers, profissionais de Sistemas de Informao e engenheiros do outro (Pettigrew 1985, Holzblatt e Beyer 1993).
3.3.3. Grounded Theory
A grounded theory um mtodo de investigao que procura desenvolver uma teoria que se baseia nos dados sistematicamente recolhidos e analisados. A principal diferena entre a grounded theory e os outros mtodos a abordagem especfica do desenvolvimento terico, em que esta teoria defende que deve ser uma interaco contnua entre a recolha e anlise dos dados (Martin e Turner 1986). Esta teoria extremamente til no desenvolvimento de descries baseadas no contexto e orientado aos processos e na explicao de fenmenos (Orlikowski e Baroudi 1991).
52

3.3.4. Action Research
Como a action research foi o mtodo de investigao escolhido para desenvolvimento do presente estudo ser abordada em maior detalhe, sendo apresentados, alm das suas caractersticas e definio, tambm os diferentes modos, domnios e abordagens. A action research um mtodo de investigao que comeou por ser usado nas cincias sociais e mdicas desde meados do sculo 20. Perto do fim dos anos 90 comeou a crescer em popularidade no uso de investigaes acadmicas de Sistemas de Informao. O mtodo produz resultados de investigao bastante relevantes porque se baseia na aco prtica que tem como alvo a resoluo imediata de um problema, com o cuidado de fornecer informao terica (Keen 1991, Baskerville 1999).
Contexto para a action research Os investigadores que utilizam action research acreditam que as organizaes humanas, como um contexto que interage com tecnologias de informao, apenas podem ser entendidas como entidades globais. A implicao chave deste pressuposto que a elaborao da configurao social, como uma organizao e as suas tecnologias de informao em variveis ou componentes, no ir conduzir a um conhecimento til sobre toda a organizao. Como poderemos ento desenvolver um entendimento da interaco de organizaes sociais complexas e dos seus Sistemas de Informao? A discrdia fundamental da action research que os processos sociais complexos podem ser estudados atravs da introduo de mudanas nesses processos e observando os efeitos dessas mudanas (Baskerville 1999). Quando os investigadores intervm, passam a fazer parte do estudo, isto , so um dos aspectos do estudo. Por outras palavras, o investigador percebe o significado da observao. Aquando da tentativa do investigador em entender o que est a ser observado, esse conhecimento pessoal ir invadir o registo da observao e as dedues que se seguem (Baskerville 1999). A action research operacionaliza um mtodo ideogrfico de inquirir parcialmente atravs da incorporao dos temas nas suas investigaes como se se tratassem de colaboradores importantes, envolvendo sempre uma equipa que inclui investigadores e temas como co-participantes na pesquisa e na troca de experincias (Kant 1908, Baskerville 1999).
53
Definio de action research Existem inmeras definies de action research, no entanto a mais citada a de Rapoport (Rapoport 1970), que define que o principal objectivo da action research :
contribuir tanto para os constrangimentos prticos das pessoas numa situao problemtica imediata, como para os objectivos da cincia social atravs da juno da colaborao com uma framework tica mutuamente aceitvel.
Esta definio centra a ateno para o aspecto colaborativo da action research e para possveis dilemas ticos que podem surgir com o seu uso. claro tambm que este tipo de investigao se preocupa em alargar o conjunto do conhecimento das cincias sociais da comunidade. neste aspecto que a action research se distingue da cincia social aplicada, onde o seu objectivo simplesmente a aplicao do conhecimento social cientfico e no a contribuio para o alargar desse conhecimento (Clark 1972).
Modos de action research A action research refere-se a um conjunto de abordagens de investigao em vez de um mtodo de investigao nico e monoltico. Como um conjunto, os vrios modos partilham algumas caractersticas e essas caractersticas distinguem-na de outras abordagens pesquisa social. A action research composta por quatro caractersticas comuns (Peters e Robinson 1984): 1. Orientao e aco de mudana; 2. Focus do problema; 3. Processo orgnico que envolve etapas sistemticas e por vezes iterativas; 4. Colaborao entre participantes. Este modo de investigao descrito como uma tcnica caracterizada pela interveno experimental que opera sobre questes ou problemas percebidos pelos praticantes dentro de um contexto em particular. A action research participativa distinguida pela caracterstica adicional do envolvimento dos participantes como sujeitos e co-investigadores.
54
Captulo 3 Abordagem de Investigao Action research participativa
Na action research participativa assumido que o investigador no pode adquirir o mesmo detalhe de conhecimento que os profissionais j possuem, fruto dos longos anos de vivncia dentro do contexto social em estudo. Um efeito indirecto da colaborao de todos os participantes que a action research participativa estende o mbito social da action research (Elden e Chisholm 1993, Baskerville 1999).
Domnios da action research
O domnio ideal do mtodo de action research caracterizado pelo aspecto social onde: 1. O investigador est activamente envolvido, com benefcios esperados tanto para ele como para a organizao; 2. O conhecimento obtido pode ser imediatamente aplicado, com uma participao activa com a vontade de utilizar qualquer novo conhecimento baseado no enquadramento explcito e conceptual; 3. A pesquisa um processo (tipicamente cclico) que liga a teoria prtica.
Uma rea de importncia clara no domnio da action research so as novas (ou modificadas) metodologias de desenvolvimento de sistemas. O estudo dessas metodologias envolve implicitamente a introduo dessas mudanas, sendo
necessariamente intervencionista. Este modo de investigao um das poucas abordagens vlidas que podemos legitimamente aplicar ao estudo de efeitos de alteraes especficas nos sistemas de desenvolvimento de metodologias em organizaes humanas (Baskerville e Wood-Harper 1996, Baskerville 1999).
Abordagem da action research
A descrio mais prevalente de action research detalha um processo cclico, com 5 fases. A abordagem requer o estabelecimento de uma base cliente-sistema ou ambiente de investigao. Essas 5 fases so (Susman e Evered 1978, Baskerville 1999):
55
Captulo 3 Abordagem de Investigao 1. Diagnstico; 2. Planeamento da aco; 3. Tomada da aco; 4. Avaliao; 5. Especificao da aprendizagem. Diagnstico Diagnosticar corresponde identificao dos problemas primrios que so as causas subjacentes ao desejo da organizao para mudar. Diagnosticar envolve autointerpretao do problema organizacional complexo, sendo que esse diagnstico ir desenvolver certos pressupostos tericos (isto , hipteses funcionais) acerca da natureza da organizao e o seu domnio dos problemas.
Planeamento da aco Os investigadores e praticantes colaboram na prxima actividade, o planeamento da aco. Esta actividade especifica aces organizacionais que devem atenuar ou melhorar esses problemas primrios. A descoberta das aces planeadas guiada pelo enquadramento terico que indica tanto o estatuto futuro desejado para a organizao como as mudanas que iro levar a conseguir atingir tal estado. O plano estabelece a meta para a mudana e a abordagem para essa mudana.
Tomada da aco Os investigadores e os praticantes colaboram na interveno da aco na organizao, levando a que certas mudanas sejam feitas. Vrias formas de estratgias de interveno podem ser adoptadas. Por exemplo, a interveno pode ser directiva, no qual a investigao direcciona a mudana, ou no-directiva, em que a mudana feita de forma indirecta.
Avaliao Aps as aces estarem completas, os investigadores colaborativos e os praticantes avaliam os resultados. A avaliao inclui determinar se os efeitos tericos da aco foram realizados e se esses efeitos resultaram em problemas. Onde a mudana se verificou ser um sucesso, a avaliao deve questionar de forma crtica se a aco tomada, de entre todas as rotinas j presentes na organizao, foi a nica causa do
56
Captulo 3 Abordagem de Investigao sucesso. Onde a mudana se verificou ser um insucesso, deve ser estabelecida um enquadramento para a prxima iterao do ciclo de action research (incluindo ajustamento das hipteses) (Baskerville 1999).
Especificao da aprendizagem Embora a especificao da aprendizagem seja a ltima fase a ser tomada, geralmente um processo contnuo. O conhecimento ganho atravs da action research (quer a aco tenha sido um sucesso ou um insucesso) pode ser direccionado para trs audincias:
1. A reestruturao das normas organizacionais de modo a reflectir o novo conhecimento ganho pela organizao durante a investigao; 2. Onde as mudanas foram um insucesso, o conhecimento adicional pode providenciar bases para o diagnstico da preparao de futuras intervenes; 3. Finalmente, o sucesso ou falha do enquadramento terico dispe conhecimento importante para a comunidade cientfica poder lidar com investigaes futuras.
O ciclo da action research pode continuar, quer a aco tenha sido um sucesso ou um insucesso, para desenvolver o conhecimento sobre a organizao e a validade dos enquadramentos tericos relevantes. Com o resultado dos estudos, a organizao aprende mais sobre a sua natureza e ambiente e a constelao dos elementos tericos da comunidade cientfica continua a melhorar e a evoluir (Argyris e Schn 1978, Baskerville 1999).
3.4.
Tcnicas Qualitativas para a Recolha de Dados
Cada um dos mtodos de investigao discutidos usa uma ou mais tcnicas para a recolha de dados. Essas tcnicas variam desde entrevistas, tcnicas de observao como observao participante e trabalho de campo at pesquisa de arquivos. As fontes desses dados podem incluir documentos publicados ou por publicar, relatrios das organizaes, memorandos, cartas, relatrios, mensagens via e-mail, faxes, artigos de jornais e por a em diante.
57
Captulo 3 Abordagem de Investigao Na antropologia e na sociologia uma prtica comum distinguir-se entre fontes de dados primrias e secundrias. Os dados de fontes primrias so aqueles no-publicados e os quais o investigador os recolhe das pessoas ou directamente da organizao. Fontes secundrias dizem respeito a todo o material (livros, artigos, etc.) que foi previamente publicado. Tipicamente, um investigador de um estudo de casos usa entrevistas e materiais documentais, sem usar a observao participante. O aspecto que distingue o estudo de casos da etnografia o facto do investigador despender uma grande parte do tempo em trabalho de campo. As notas provenientes desse trabalho de campo e as prprias experincias adquiridas so uma adio muito importante para qualquer outro tipo de tcnicas de recolha de dados que podero ser usadas (Silverman 1993, Miles e Huberman 1994, Rubin e Rubin 1995, Denzin e Lincoln 2005, Myers e Newman 2007).
58
4. Caso de Estudo
Neste captulo primeiro efectuada uma breve introduo onde ser dada a conhecer a empresa em estudo e as motivaes da mesma para a implementao do modelo de maturidade CMMI no seu seio. Seguidamente iro ser apresentadas os pontos fortes e pontos a melhorar (denominados de Gap Analysis) nos processos respeitantes ao modelo CMMI e a identificao das recomendaes e aces a serem tomadas para a melhoria dos processos. Sero tambm apresentadas as estratgias, aces de implementao e ferramentas, levadas a cabo pela empresa, com o objectivo de implementar o modelo de maturidade. Este captulo termina com uma anlise e discusso dos resultados obtidos de entrevistas realizadas junto de vrios Gestores de Projecto, nas quais foram abordados os assuntos respeitantes ao modo de trabalho das suas equipas antes e aps a implementao do CMMI e recolhidas as opinies sobre se as decises tomadas pela equipa designada para a definio e implementao do modelo CMMI foram as mais indicadas.
4.1.
ES Informtica, ACE
A Esprito Santo Informtica (ESI), ACE um agrupamento complementar de duas empresas de informtica do Grupo Esprito Santo, que iniciou a sua actividade em 2006 com o objectivo de gerir os Sistemas de Informao e o desenvolvimento de aplicaes de software que dem resposta aos pedidos dos membros agrupados identificados na Figura 18. A ESI est estruturada por vrias reas, como apresentado na Figura 19, sendo uma empresa constituda por cerca de 600 colaboradores, dos quais 55% so 59
Captulo 4 Caso de Estudo internos empresa e os restantes 45% so provenientes de empresas de prestao de servio de outsourcing.
Figura 18 - Composio da Esprito Santo Informtica
Figura 19 - Estrutura da Esprito Santo Informtica
No mbito do Programa de Transformao da ESI foram identificadas lacunas significativas num conjunto de processos fundamentais relacionados com a execuo de projectos. Nesse sentido, numa primeira fase foram feitos dois diagnsticos sobre o estado de maturidade desses processos na ESI, denominados por Gap Analysis.
O primeiro diagnstico abordou as seguintes reas CMMI Nvel 2: Gesto de Requisitos (Requirements Management REQM); Planeamento do Projecto (Project Planning PP); Monitorizao e Controlo do Projecto (Project Monitoring and Control PMC); Gesto de Acordo com Fornecedores (Supplier Agreement Management SAM); Medida e Anlises (Measurement and Analysis MA);
60
Captulo 4 Caso de Estudo

Garantia de Qualidade dos Processos e Produtos (Process and Product Quality Assurance PPQA); Gesto de Configurao (Configuration Management CM);
O segundo diagnstico abordou as seguintes rea CMMI Nvel 3: Desenvolvimento de Requisitos (Requirements Development RD); Verificao (Verification VER); Validao (Validation VAL ).
Estes diagnsticos confirmaram, como esperado, a existncia de lacunas significativas nos processos englobados nestas reas. Adicionalmente foi tambm produzido um conjunto de recomendaes sobre as principais actividades a desenvolver para melhorar estes processos de forma a torn-los compatveis com o nvel 2 e parte do nvel 3 do modelo CMMI.
Ambos os diagnsticos foram efectuados com o apoio de consultadoria da empresa Tata Consulting Services.
Algumas das principais lacunas e problemas foram bem identificadas: Ausncia de standards de infra-estrutura e desenvolvimento; Responsabilidades indefinidas ou incorrectamente distribudas entre Informtica e Negcio no processo de definio das solues para as medidas informticas; Esforo elevado na anlise de pedidos resultando em oramentaes muito demoradas; Sponsors frequentemente especificam pedidos com base na indicao de sistemas; Elevado esforo e demora na recolha de requisitos com consequente atraso na entrega dos projectos; Ausncia de controlo de qualidade e certificao durante o processo de desenvolvimento, resultando na descoberta tardia de problemas.
A soluo passa pela melhoria do processo de desenvolvimento: Definio de regras e normas globais, baseada em melhores prticas de mercado; Formalizao e documentao de todas as actividades do processo de desenvolvimento; Normalizao dos documentos a produzir em cada uma das fases; 61
Captulo 4 Caso de Estudo Adopo de melhores prticas de mercado para especificao de requisitos, baseadas em casos de uso; Centralizao do gestor de projecto da gesto de requisitos; Especificao e validao da soluo antes da sua codificao.
Para tal foi usado o modelo CMMI, por ser o modelo de referncia para os processos relacionados com a execuo de projectos informticos na maioria das empresas internacionais.
4.2.
Gap Analysis
A Gap Analysis um estudo formal do que o negcio faz e onde se quer posicionar no futuro. Poder ser conduzido na perspectiva da Organizao (ex: Recursos Humanos), da direco ou processos do negcio e/ou das tecnologias da Informao. O objectivo de uma Gap Analysis encontrar as diferenas entre as prticas em uso numa dada organizao e o guia dado por um modelo de referncia, neste caso o CMMI, ou seja, uma ferramenta que permite organizao determinar, documentar e aprovar a varincia entre a sua performance actual e os requisitos do negcio. Tal anlise poder ser feita a um nvel operacional ou estratgico (WIKIPEDIA, 2008).
4.2.1. Gap Analysis Nvel 2
Foi efectuada uma Gap Analysis na ESI, respeitante s reas de processo do nvel 2 do modelo CMMI, cujo seu propsito passou: pelo conhecimento das prticas da engenharia e gesto usado no desenvolvimento do software e actividades de manuteno na ESI; pela identificao dos pontos fortes e pontos a melhorar, nos processos respeitantes ao Nvel 2 do modelo CMMI; pela identificao do grau de satisfao para as reas de processo examinados e pela identificao das recomendaes e aces a serem tomadas para a melhoria dos processos. O mbito da Aprovao da Gap Analysis a organizao ESI, onde foram includos projectos de Desenvolvimento e Manuteno. Nesta anlise participaram: 62 15 Gestores de Projecto; 10 Directores; 8 Elementos das Equipas de Desenvolvimento (Vrios Perfis);
Captulo 4 Caso de Estudo 5 Representantes da Gesto de Configurao; 2 Representantes da Qualidade; 2 Representantes da Arquitectura; 1 Representante dos Recursos Humanos; 1 Representante das rea das Finanas.
Os pontos fortes globais encontrados atravs desta anlise foram: o ambiente aberto, amigvel e profissional e a experincia e longevidade de tempo na organizao das pessoas que l trabalham, com capacidade para o suporte de melhorias. As oportunidades de melhoria passariam por: um aumento do grau de institucionalizao; melhoria, definio e integrao de polticas, processos, guias de ajuda e ferramentas e estabelecimento de mtricas e funes de garantia de qualidade, bem como um aumento da disciplina no que diz respeito ao desenvolvimento de requisitos e actividades de teste. De seguida iro ser apresentadas as anlises das reas de processo do nvel 2 efectuadas na empresa, com a indicao dos objectivos de cada rea de processo e do que j se encontra implementado bem como das melhorias a efectuar na empresa de modo a poder atingir esses mesmos objectivos. Gesto de Requisitos (REQM)
Nesta rea de processo focada a necessidade de gerir os requisitos e identificar as inconsistncias com os planos de projecto e produtos de trabalho. Os pontos fortes aquando da anlise desta rea de processo na empresa passaram pelo acordo dos requisitos entre o provedor dos mesmos, a equipa de projecto e outros membros da organizao sempre que necessrio, aps as revises e anlises. Os aspectos a melhorar passariam por um melhor registo das mudanas nos requisitos acordados no template especfico para a mudana de requisitos e tambm proceder-se a uma melhor manuteno de requisitos, planos de projecto e do produto final atravs da sua documentao. Abaixo (Figura 20) encontra-se um grfico exemplificativo da implementao desta rea de processo na empresa.
63
40. 00% 20. 00%
40. 00%
Totalmente Implementado
Parcialmente Implementado
No Implementado
Figura 20 - Implementao da Gesto de Requisitos
Planeamento do Projecto (PP)
No Planeamento do Projecto necessrio estabelecer-se e manter-se no s estimativas dos parmetros do planeamento do projecto mas tambm um plano do projecto. No final ter de se obter um compromisso desse plano entre o cliente e o gestor do projecto. Na empresa, aps a anlise da implementao desta rea de processo, foi possvel verificar-se que: o mbito do Projecto estabelecido pela identificao de actividades e tarefas a serem executadas pela equipa do Projecto; so feitas estimativas de esforo determinadas pelo uso de folhas de estimativas ao nvel do projecto; existe a definio do ciclo de vida do software; e a oramentao do projecto, calendrio e recursos humanos so planeados e mantidos. So feitas reunies de revises dos compromissos, onde so envolvidos os stakeholders relevantes ao longo do ciclo de vida. Ter de haver uma melhor identificao, anlise ou documentao da calendarizao dos impactos dos riscos, entregveis, requisitos especiais, cumprimento dos compromissos, etc.; melhorar a garantia da privacidade e segurana dos dados; haver uma melhor identificao e planeamento dos mecanismos de aquisio de conhecimento (ex: formao) e tambm uma maior planificao do envolvimento dos stakeholders relevantes. Abaixo (Figura 21) encontra-se um grfico exemplificativo da implementao desta rea de processo na empresa.
64
21.43% 57.14% 21.43%
No Implementado
Figura 21 - Implementao do Planeamento do Projecto
Controlo e Monitorizao do Projecto (PMC)
Quando se fala em Controlo e Monitorizao do Projecto, trata-se da monitorizao do progresso e da performance actual do projecto e comparao destes versus o planeado inicialmente. Quando existem desvios significativos desta performance, as aces correctivas so identificadas e geridas at ao seu fecho. Na empresa, a monitorizao dos valores actuais versus os planeados feita usando mecanismos tais como comits de steering, reunies internas, relatrios de progresso e ferramentas de registo dirios, havendo tambm a identificao, anlise e registo dos problemas que afectam o projecto. De modo a melhorar o controlo e monitorizao do projecto, ser necessrio aumentar a consistncia da monitorizao de factores como, por exemplo, riscos e gesto dos dados do projecto, e efectuar anlises para determinar a eficcia das aces correctivas identificadas. Abaixo (Figura 22) encontra-se um grfico exemplificativo da implementao desta rea de processo na empresa.
20. 00%
30. 00%
50. 00%
Tot alment e Implement ado
Parcialmente Implement ado
No Implementado
Figura 22 - Implementao do Controlo e Monitorizao do Projecto
65
Gesto de Acordos com Fornecedores (SAM)
Na gesto de acordos com fornecedores necessrio estabelecer e satisfazer acordos com os fornecedores. Nesta rea de processo, por parte da empresa j h uma seleco dos fornecedores (em concordncia com o sponsor), sendo estabelecidos sistematicamente acordos formais com os mesmos. A necessidade da garantia da resposta aos requisitos por parte dos produtos adquiridos atingida atravs da execuo de testes de aceitao com o sponsor. H a necessidade de aumentar a obteno do progresso real dos fornecedores e tambm evidenciar de forma mais clara o planeamento da transio sistemtica do produto do fornecedor para o Projecto. Abaixo (Figura 23) encontra-se um grfico exemplificativo da implementao desta rea de processo na empresa.
28. 57% 42. 86%
28. 57%
Tot almente Implementado
Parcialment e Implement ado
No Implementado
Figura 23 - Implementao daGesto de Acordos com Fornecedores
Medies e Anlises (MA)
Atravs das medies e anlises pretende-se alinhar os objectivos e actividades de medio com a identificao das necessidades de informao e objectivos e providenciar os resultados dessa medio. Esses resultados j so providenciados aos stakeholders relevantes, no entanto, no existem procedimentos de medio que definem os objectivos de medio, indicadores, frmulas, fontes ou anlises de actividades na organizao e tambm no feito de modo consistente a anlise dos dados provenientes dessas medies.
66
Captulo 4 Caso de Estudo Abaixo (Figura 24) encontra-se um grfico exemplificativo da implementao desta rea de processo na empresa.
12. 50% 50. 00% 37. 50%
No Implementado
Figura 24 - Implementao das Medies e Anlises
Garantia de Qualidade do Produto e do Processo (PPQA)
Quando se pretende atingir a garantia de qualidade do produto e do processo necessria uma avaliao da adeso dos processos desempenhados, produtos de trabalho e servios associados s descries dos processos aplicveis, standards e procedimentos. Todos os problemas de no-conformidades so monitorizados e comunicados de forma objectiva, sendo garantida uma resoluo. Por parte da empresa as actividades de garantia de qualidade de produto e processo no so planeadas nem executadas de forma consistente e necessrio uma maior disponibilizao dos relatrios de no-conformidades e das aces correctivas. Abaixo (Figura 25) encontra-se um grfico exemplificativo da implementao desta rea de processo na empresa.
25. 00% 75. 00%
Tot almente Implementado
Parcialmente Implement ado
No Implement ado
Figura 25 - Garantia de Qualidade do Produto e do Processo
67
Captulo 4 Caso de Estudo Gesto de Configuraes (CM)
Na gesto de configuraes necessrio estabelecer baselines de produtos de trabalho identificados, sendo necessrio tambm monitorizar e controlar quaisquer mudanas aos produtos de trabalho em gesto de configuraes. Apesar de existirem ferramentas de gesto de configurao, estas no esto completamente implementadas em todos os ambientes e projectos. Alm disso, necessitar de haver uma melhor identificao dos tipos de produtos de trabalho e um aumento da evidncia da identificao e criao de baselines internas (que no feita na maioria dos casos). Ser necessrio haver um aumento de auditorias s baselines para garantir a integridade e controlo nos itens de configurao. Abaixo (Figura 26) encontra-se um grfico exemplificativo da implementao desta rea de processo na empresa.
14. 29%
85. 71%
No Implement ado
Figura 26 - Implementao da Gesto de Configuraes
Na Figura 27 encontra-se um grfico resumo da conformidade, com as reas de processo nvel 2 existentes na ESI.
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
REQM
PP
PMC
SAM
MA
PPQA
CM
No Implementado
Figura 27 - Conformidade com as reas de Processo de Nvel 2
68
O diagnstico efectuado revela que: Actividades de Gesto de Requisitos e Gesto de Projecto so feitas, embora parcialmente e sem uniformidade; Outras actividades no so feitas ou so feitas mas com muito pouca formalizao.
Concluso: existe uma boa base para normalizar e uniformizar os principais processos, pois parte significativa da empresa j os executa.
4.2.2. Gap Analysis Nvel 3
Aps ter sido efectuada uma Gap Analysis na ESI, respeitante s reas de processo do nvel 2 do modelo CMMI, foi posteriormente efectuada uma Gap Analysis correspondentes a trs reas de processo de Nvel 3 (VER, VAL e RD) consideradas estratgicas para a organizao, cujo seu propsito passou: pelo conhecimento das prticas da engenharia e gesto usado no desenvolvimento do software e actividades de manuteno na ESI; pela identificao dos pontos fortes e pontos a melhorar, nos processos respeitantes ao Nvel 3 do modelo CMMI (VER, VAL e RD); pela identificao do grau de satisfao para as reas de processo examinados; e pela identificao das recomendaes e aces a serem tomadas para a melhoria dos processos.
O mbito da Aprovao da Gap Analysis a organizao ESI, onde foram includos projectos de Desenvolvimento e Manuteno. Nesta anlise participaram: Staff da Engenharia; Directores; Gestores de Projecto.
Tal como fizemos na Gap Analysis de nvel 2, apresentamos de seguida as anlises das reas de processo do nvel 3 efectuadas na empresa, com a indicao dos objectivos de cada rea de processo, bem como com a indicao do que j se encontra implementado e as melhorias a efectuar na empresa de modo a poder atingir esses mesmos objectivos.
69
Desenvolvimento de Requisitos (RD)
Para o desenvolvimento de requisitos necessrio assegurar-se que: as necessidades dos stakeholders, expectativas, insatisfaes e as interfaces so recolhidas e traduzidas em requisitos do cliente; os requisitos do cliente so refinados e elaborados para o desenvolvimento dos requisitos do produto e das suas componentes; e por fim os requisitos so analisados e validados, sendo desenvolvida uma definio da funcionalidade requerida. Na empresa j feita uma recolha e anlise das necessidades do cliente, sendo traduzidas em Requisitos do Cliente e as interfaces so identificadas e os requisitos associados so desenvolvidos e documentados em documentos de especificao de requisitos. O problema reside na pouca ou inexistente documentao desses requisitos, onde nem sempre feita a validao dos mesmos para garantir se o funcionamento do produto resultante no ambiente do utilizador o adequado. Apesar de existir a anlise dos requisitos na maior parte dos casos, no so identificados os diferentes nveis dos requisitos. Abaixo (Figura 28) encontra-se um grfico exemplificativo da implementao desta rea de processo na empresa.
74%
13% 13%
No Implementado
Figura 28 - Implementao do Desenvolvimento de Requisitos
70
Captulo 4 Caso de Estudo Verificao (VER)
O ponto principal da rea de processo de verificao, como o seu nome indica a verificao dos produtos seleccionados contra os requisitos, aps ter sido feita uma apropriada preparao dessa verificao e de terem sido executadas revises de pares nos produtos de trabalho seleccionados. Apesar de se estabelecerem ambientes para diferentes tipos de verificao, incluindo revises e testes de cdigo, os produtos de trabalho a serem verificados no so seleccionados ou estabelecidos na maior parte dos casos e as revises de pares no so propriamente preparadas, conduzidas ou analisadas. Os defeitos nos produtos de trabalho so registados, no entanto, no h a garantia que os casos de teste so executados. Na maior parte dos casos, os casos de teste e os resultados no so guardados. Abaixo (Figura 29) encontra-se um grfico exemplificativo da implementao desta rea de processo na empresa.
62%
38% 0%
No Implementado
Figura 29 - Implementao da Verificao
Validao (VAL)
Aps a preparao para a validao ser conduzida, o produto ou as componentes so validadas para garantir que so adequadas para o uso no ambiente de operao destinado. No que diz respeito implementao desta rea de processo na empresa verifica-se que, na maioria dos casos, os produtos ou as componentes a serem validadas e os mtodos de avaliao associados para demonstrao da satisfao das necessidades do utilizador no so seleccionados e no est disponvel tambm uma metodologia de 71
Captulo 4 Caso de Estudo validao. A validao executada nos produtos para garantir que so adequados para o uso no seu ambiente operacional pretendido, mas os resultados dos testes globais incluindo casos satisfeitos no so analisados. Abaixo (Figura 30) encontra-se um grfico exemplificativo da implementao desta rea de processo na empresa.
0%
60%
40%
TotaImente plementado
No Implementado
Figura 30 - Implementao da Validao
Na Figura 31 encontra-se um grfico resumo da conformidade, com as reas de processo nvel 3 (VER, VAL e RD) existentes na ESI.
100% 80% 60% 40% 20% 0% RD Totalmente Implementado VER VAL No Implementado
Figura 31 - Conformidade com as reas de Processo de Nvel 3
4.2.3. Benefcios Esperados da Adopo do CMMI na Empresa
Para alm de suprir as lacunas identificadas, a empresa atravs do CMMI tem como principais objectivos: melhorar o processo de desenvolvimento de projectos informticos atravs da adopo de melhores prticas da indstria, a normalizao de processos e das melhores prticas internas, levando a um aumento da repetio dos 72
Captulo 4 Caso de Estudo casos de sucesso de desenvolvimento de software e uma maior facilidade de integrao de pessoas e equipas em processos bem definidos; a exigncia de melhores prticas aos fornecedores; e tambm a melhoria da previsibilidade dos projectos, aumentando a eficcia da oramentao e o planeamento dos mesmos. Visto que um dos principais causadores dos fracassos do desenvolvimento de projectos de software a elevada derrapagem em termos de oramento e cumprimento de prazos, a ESI tem como ponto a melhorar, o aumento da qualidade dos projectos, nomeadamente atravs da melhoria em termos de cumprimento de prazos e na diminuio de custos e defeitos. Na Tabela 6 encontram-se as indicaes, de acordo com o SEI (Software
Enginnering Institute), da melhoria mdia nas diversas categorias, aps adopo e implementao do CMMI.
Categoria de Desempenho Custo Calendrio Produtividade Qualidade Satisfao do Cliente Retorno do Investimento
Melhoria Mdia 34% 50% 61% 48% 14% 4:1
Tabela 6 - Melhorias Mdias com o CMMI
Fonte: (SEI 2007) Em termos de indicaes, de modo a poder medir o nvel de melhoria resultante da adopo deste modelo de maturidade, tal s poder ser feito a partir de 2009, j que a empresa no possui qualquer tipo de histrico de registos de qualidade a nvel dos processos de desenvolvimento de software ou mesmo a nvel de projectos ou reas da empresa em geral, definindo ento que o ano de 2008 seria um ano apenas de recolha de dados para assim poderem formar um histrico e terem um ponto inicial para a definio de metas e objectivos para os diferentes tipos de projectos a desenvolver na empresa da em diante.
73
4.3.
Estratgias de Implementao
No que diz respeito implementao propriamente dita, foi escolhida a empresa de consultoria Tata Consulting Services (TCS), pelas seguintes razes: nos trabalhos anteriores esta empresa revelou ter consultores (internacionais) com boa experincia, conhecimento e capacidade para este tipo de trabalhos, estando envolvidos em projectos de ndole semelhante noutras instituies bancrias na Pennsula Ibrica; a experincia que a TCS adquiriu nos trabalhos anteriores permitiria ser mais eficiente e melhor dirigida neste projecto. O objectivo definido para o Projecto foi obter a certificao da ESI em CMMI nvel 2 em Julho de 2008. Dado o elevado grau de dificuldade e complexidade inerente implementao deste modelo de maturidade e do risco de tanto a equipa consultora como a prpria organizao ESI no conseguirem efectuar as transformaes pressupostas neste projecto, ele foi dividido em 3 etapas: Etapa 1: Planeamento e definio de processos; Etapa 2: Ciclo 1 de projectos-piloto e roll-out (implementao das mudanas em todas as reas da empresa); Etapa 3: Ciclo 2 de projectos-piloto, roll-out, mini-apraisal (avaliao obrigatria antes da certificao) e gaps closure (reparao de lacunas ainda remanescentes).
Na Tabela 7 e na Figura 32 encontram-se detalhados os processos tratados em cada uma das etapas e a sua distribuio ao longo da vida deste projecto de implementao do modelo de maturidade CMMI.
Fase
Processos
Roll-out
Visibilidade para sponsors BES (Banco Esprito Santo)
Etapa 1 Etapa 2
Planeamento e definio Gesto de Requisitos Gesto de Projectos Subcontratao de Fornecedores Mtricas Gesto de Configuraes Controlo de Qualidade
1 Quinzena de Abril Set Out 2007
Nenhuma Mdia
Etapa 3
Jan Fev 2008
Baixa
Tabela 7 - Etapas da Obteno da Certificao CMMI
74
April
May
Jun
Jul
Ago
Sept
Oct
Nov
Dec
Jan
Feb
Mar 08
Cycle 1 Rollout
Cycle
Pilots & Training
Cycle
Pilots & Training
Mini Appraisal
Rollout
REQM, RD PP & PMC

Definition + Pilots
PPQA MA CM SAM VER VAL

Definition + Pilots
All Process Areas
Figura 32 - Calendarizao da Certificao
Este tipo de diviso de etapas deveu-se ao facto da equipa de qualidade ter como principal objectivo a definio e implementao das reas de maior impacto para a empresa, como so as correspondentes ao planeamento e definio dos processos de desenvolvimento de software e consequente gesto de projecto e de requisitos do mesmo. Os processos definidos tiveram tambm em conta o ciclo de vida pelo qual um projecto passa e o impacto para o sponsor, tendo em conta que a 1 e 2 fases tm um maior impacto, visto existirem processos intimamente ligados com ele, como so a definio de requisitos de negcio e a recepo da documentao inicial, imperativa para o incio do projecto. Tendo como ponto de comparao os dados fornecidos pela SEI (representados na Tabela 8) no que diz respeito ao nmero mdio de meses de passagem de um nvel adhoc (nvel 1) para o nvel 2 de maturidade, pode-se verificar que os 11 meses de implementao do modelo superam em muito os 19 meses mdios indicados pela SEI, sendo portanto um objectivo muito ambicioso por parte da organizao.
Nvel de Maturidade Nvel 1 para Nvel 2 Nvel 2 para Nvel 3 Nvel 3 para Nvel 4 Nvel 4 para Nvel 5
N de Meses (Mdia) 19 20 25 13
Tabela 8 - N de Meses em Mdia para Passagem de Nvel de Maturidade
Fonte: [SEI 2007] 75

4.3.1. Aces de Implementao
Desde o incio do Projecto que foi tido em conta que esta implementao do modelo de maturidade de processos de desenvolvimento de software iria ser uma mudana muito grande no dia-a-dia e no modo de trabalho dos colaboradores da empresa e, tambm, que iria ser encontrada muita resistncia por parte dos mesmos. De modo a tentar combater estes problemas foi determinado que a definio dos processos e tambm a criao e consequente aumento de documentao nesta altura, indispensvel para dar resposta aos requisitos do modelo CMMI, iriam ter em conta as necessidades dos colaboradores, ou seja, ir-se-ia definir um processo de mudana mas com o mnimo de impacto na sua forma de trabalho diria na organizao. Toda esta definio foi sempre feita com o feedback das vrias reas da organizao, de modo a que os processos fossem o mais de acordo possvel s pretenses e necessidades de trabalho dirias de todos e que dessem resposta s exigncias dos projectos a desenvolver. A estratgia definida pela equipa de Processos e Qualidade do Sistema de Informao (PQSI) foi a de tentar definir e criar apenas a documentao necessria e mnima que permitisse dar resposta aos processos de nvel 2 do CMMI. De modo a poder definir os processos de desenvolvimento de software e criar a documentao mnima, mas orientada s necessidades, houve um acompanhamento forte e dirio de alguns projectos (estratgicos) em desenvolvimento e em que eram sempre tidas em conta todas as opinies dos colaboradores e sugestes de melhoria de um ou outro ponto de tudo o que era definido. Alm desse acompanhamento dirio dos projectos, foram tidas reunies ao longo dos vrios meses de definio e implementao do modelo de maturidade com as diversas reas constituintes da empresa. Nestas reunies, foram no s apresentados os novos processos definidos aos colaboradores, mas tambm obtido o feedback dos mesmos e o aproveitamento das melhores prticas j utilizadas pelas equipas dessas reas, como, por exemplo, ferramentas e documentao j utilizadas que aps alguns reajustamentos seriam muito teis para dar resposta s necessidades de uma ou outra rea de processo em definio ou j definida. No final da 1 e 2 fases de definio dos processos e dos documentos subjacentes, foram seleccionados alguns projectos das vrias reas da empresa, designados de projectos-piloto. Estes projectos-piloto foram seleccionados de entre os demais visto
76
Captulo 4 Caso de Estudo que a fase de desenvolvimento em que se encontravam era a ideal para validar esses processos definidos e documentos produzidos, como por exemplo, em que no fim da 2 fase, para validar as reas de processo de VER e VAL, foram escolhidos dois projectos que se encontravam na fase de Testes de Aceitao. Aps o fim desses projectos-piloto, foi iniciado o chamado roll-out, constitudo por aces de formao dos processos definidos e validados, para toda a organizao. Tendo em conta a grande dimenso da empresa e a inteno de formar o maior nmero possvel de colaboradores, foram agendadas vrias aces de formao em que, apesar do principal ponto ser a apresentao dos processos a implementar nos projectos, tambm foi uma oportunidade de mais uma vez receber o feedback/opinies/sugestes dos presentes de modo a poderem ser melhorados os processos definidos. Este acompanhamento dirio, enorme flexibilidade da equipa de Qualidade e validao final teve como principais resultados a melhoria de tudo que era definido, tendo dado resposta ao maior nmero possvel das diferentes necessidades das reas da organizao e de certa forma ir diminuindo, de uma forma gradual, a resistncia dos colaboradores mudana.
4.3.2. Ferramentas de Suporte Implementao
Alm do acompanhamento dirio com os colaboradores, de modo a suavizar ainda mais o impacto da mudana, decidiu-se que os processos definidos e a gesto da informao dos projectos seria suportada em duas ferramentas, nomeadamente a Microsoft Sharepoint (SHAREPOINT 2008) e o RoboHelp (ROBOHELP 2008). Como ferramentas de Gesto de Projectos sero utilizadas as j existentes, uma vez que estas j do resposta aos processos definidos, nomeadamente o Artemis com ligao ao MSProject. Aps o perodo de institucionalizao dos processos definidos, sero analisadas e avaliadas ferramentas que permitam optimizar os processos, sendo prioritrias ferramentas para gesto de requisitos e de mtricas, entre outras. Com isto, pretende-se minimizar a carga administrativa nos projectos e gerir melhor as mudanas que ocorram durante o ciclo de vida dos mesmos.
77

4.3.2.1. Sharepoint
Nesta implementao ficou definido que iriam existir quatro tipos diferentes de projectos de desenvolvimento de software na empresa: desenvolvimento, definio de requisitos, manuteno evolutiva e manuteno correctiva. O projecto de desenvolvimento o mais completo de todos, associado normalmente a projectos variando de mdia a grande dimenso, custos e esforos mais elevados, etc. Este tipo de projecto poder dizer respeito ao desenvolvimento de uma aplicao nova ou melhoria/alterao de grande impacto numa ou vrias aplicaes. O projecto de definio de requisitos um input para a fase de oramento de um projecto de desenvolvimento. Num projecto de desenvolvimento, quando o pedido do cliente complexo ou os requisitos especificados pelo utilizador so muito complexos ou crticos, criado priori um projecto de definio de requisitos. Ou seja, este tipo de projecto criado para analisar com mais detalhe os requisitos e elaborar um oramento mais fivel e perto da realidade. O projecto de manuteno evolutiva um projecto de pequena/mdia dimenso e tem como principal caracterstica ser uma evoluo/melhoria ou alguma alterao a uma funcionalidade j existente. Como o prprio nome indica, um projecto de manuteno correctiva tem como objectivo corrigir um erro detectado em produo. Para cada tipo de projecto foi definido um processo diferente adequado s suas caractersticas e com exigncias diferentes no que diz respeito produo de documentao. No Sharepoint para cada tipo de projecto est definido um site com uma estrutura prpria e com acesso a toda a documentao a produzir. Todos os templates definidos para cada um dos processos esto disponveis no respectivo site do projecto. Esta a forma de gesto e publicao de toda a informao produzida no mbito de cada projecto, com atribuio dos devidos perfis de acesso (consulta, leitura/escrita, etc.). Alm dos colaboradores afectos ao projecto, a equipa de PQSI ter acesso aos demais sites de modo a a poder registar as suas actividades de garantia de qualidade dos projectos, como: auditorias feitas aos projectos, no-conformidades encontradas, inspeces finais aos documentos antes de serem entregues ao sponsor e recolha de mtricas para uso no prximo ano. Resumindo, o site do projecto pretende ser um ponto central das actividades do projecto e das actividades da rea de qualidade sobre esse mesmo projecto. 78
Captulo 4 Caso de Estudo Na Figura 33, encontra-se um exemplo de um site criado para um projecto de desenvolvimento, utilizando a ferramenta Microsoft Sharepoint.
Figura 33 - Sharepoint
4.3.2.2.
RoboHelp
Desde o incio deste projecto de implementao de maturidade e qualidade nos processos de desenvolvimento foi decidido e estipulado que o ciclo de vida e todos os passos necessrios execuo de um projecto de desenvolvimento de software no iriam ser fornecidos aos colaboradores atravs de um manual de mil e uma pginas, mas sim atravs de uma ferramenta de suporte a essa execuo. A ferramenta escolhida foi o RoboHelp, cuja pgina inicial tem o aspecto apresentado na Figura 34. Com esta ferramenta pretendeu-se que os colaboradores tivessem sempre sua disposio um suporte grfico e de certa forma interactivo, no qual se poderia consultar todos os passos a seguir na execuo de um projecto, servindo como um guia de ajuda para qualquer dvida que aparea em qualquer momento do ciclo de vida do projecto. Esta ferramenta est disponvel na Intranet da ESI e acessvel a todos os colaboradores autorizados da Esprito Santo Informtica. A pgina inicial do mesmo, como se pode ver na Figura 34, disponibiliza o ciclo de vida e consequentes fases 79
Captulo 4 Caso de Estudo (Oramento, Planeamento, Anlise, Desenho, Desenvolvimento, Testes e
Implementao) pelas quais um projecto ter de passar.
Figura 34 - Robohelp
Como se pode ainda verificar atravs da visualizao da Figura 34, na ferramenta RoboHelp, para cada um dos diferentes tipos de projecto, possvel aceder com mais detalhe ao que ser necessrio desenvolver e que passos sero necessrios seguir para dar resposta aos requisitos dessa fase em questo. Esse detalhe inclui a descrio do processo, com a descrio e objectivos de cada fase e actividades a executar ao longo do ciclo de vida do projecto, os responsveis por essa execuo e os diversos documentos que sero necessrios produzir. As baselines a criar em cada fim de fase e consequente passagem para a fase posterior esto indicadas na figura atravs dos losangos, os quais se podero aceder sendo mostrados os documentos que necessitam de estar presentes na baseline de cada fase. Alm disso, existem tambm as actividades transversais, que podero ocorrer em qualquer fase do ciclo de vida do projecto. Estas actividades so: as de Gesto de Projecto, como, por exemplo, actividades de Monitorizao e Controlo da Equipa, Gesto de Alteraes de Requisitos, Controlo de Configuraes, entre outras; as de Processos de Seleco de Software, ou seja, todas as correspondentes aquisio de produtos/componentes de software a fornecedores externos e as da responsabilidade da rea de Qualidade, como so as Auditorias, Revises e Inspeces Finais de Documentao-Chave criada no decorrer do projecto.
80
Captulo 4 Caso de Estudo A ttulo de exemplo, seleccionando a visualizao da fase de oramento para um projecto de desenvolvimento (clicando na rea representada no rectngulo exemplificado na Figura 35), ser possvel visualizar com mais detalhe todos os passos, actividades, documentao a gerar/modificar, e os responsveis e participantes dessa fase de Oramentao de um projecto de Desenvolvimento.
Figura 35 - Visualizao da Fase de Oramento
O caso representado na Figura 36, pretende ser um exemplo da pgina que seria apresentada aps essa seleco, na qual se pode constatar que a fase de Oramento de um Projecto constituda pelas actividades de Anlise de Requisitos do Utilizador, Elaborao de Oramento e Entrega de Oramento para Aprovao. A diferena entre as caixas de tom escuro e de tom claro que as primeiras funcionam como agregadoras de outras actividades, ou seja, ao seleccion-las ir ser apresentado um novo ecr, com o mesmo formato deste, com a descrio de todas as actividades correspondentes anteriormente seleccionada. Por exemplo, ao seleccionar a actividade Estimar Oramento, esta seria subdividida noutras actividades como Identificao de Actividades, Estimar Tamanho e Esforo e Estimar Custo Total. Quando as caixas correspondentes a um passo/actividade se encontram a tom claro, no haver mais detalhe dessa actividade/passo do que aquela que est a ser apresentada. Com isto, pretendido que o RoboHelp seja utilizado para facilitar a leitura das especificidades de cada actividade e, como j dito anteriormente, ser utilizado como um guia nas actividades dirias.
81
Figura 36 - Exemplo de Pgina Descritiva da Fase de Oramento
4.4.
Lacunas Encontradas
Ao longo da execuo do projecto foi possvel identificar algumas lacunas encontradas na organizao, quer pelo dia-a-dia, quer pelo contacto directo com os colaboradores. A lacuna mais frequente a falta de documentao dos projectos. Na maioria dos projectos anteriores ao CMMI, ou no se documentavam os progressos e evidncias do mesmo, ou quando se documentava, cada rea ou cada gestor de projecto tinha o seu prprio modelo de documentao definido, verificando-se assim uma inconformidade de documentao entre as equipas, evidentes quando para a realizao de um projecto eram necessrias a interveno de vrias equipas correspondentes a diferentes reas da organizao. Um exemplo dessa evidncia ficou bem patente quando
82
Captulo 4 Caso de Estudo numa reunio de acompanhamento de uma determinada rea, um colaborador afirmou que a criao de documentao standard para toda a organizao absolutamente necessrio, porque, como ns interagimos com praticamente todas as reas da empresa, por vezes demoramos mais tempo a perceber o que as pessoas querem, ou a corrigir algo que pensvamos que estaria de acordo com as pretenses do projecto, do que realmente a desenvolver o que nos pedem. A criao de documentao standard ir trazer uma melhor comunicao entre as diversas reas constituintes da organizao e definio dos deveres de cada um e, assim, diminuir o tempo de desenvolvimento e de correco de erros. Tambm de certa forma ligada documentao, existe um enorme gap no que diz respeito aos testes. Os testes necessrios verificao e validao daquilo que foi desenvolvido pelo projecto em contraposio aos requisitos do utilizador, nunca eram documentados, ou seja, apesar de obviamente serem executados, no havia qualquer registo de que eram planeados, havendo em poucas reas o registo dos defeitos encontrados aquando da execuo dos mesmos. Os testes eram planeados e executados pela pessoa que os definia, ficando na sua memria, havendo por isso o risco de que se ela faltasse, um qualquer erro que obrigasse a recuar no ciclo de vida do projecto e a desenvolver novamente algumas funcionalidades do software, poderia levar a uma redefinio, re-planeamento e re-execuo de casos de teste j bem definidos e aprovados. Neste caso, a re-utilizao de testes era algo praticamente inexistente, algo que o planeamento e registo da especificao e execuo dos mesmos ir trazer. Muitos dos projectos desenvolvidos tiveram derrapagens no que diz respeito a custos e calendarizao. Estas derrapagens aconteceram porque na grande maioria das vezes no havia um entendimento certo e acordado dos requisitos do utilizador, facto esse que levava a que j no decorrer do projecto, se o utilizador notasse que algo desenvolvido no ia de encontro s suas pretenses ou mesmo se mudasse ou adicionasse um novo requisito ao projecto, este teria inevitavelmente de se atrasar em relao ao previsto e tambm ter custos acrescidos inerentes a essas mudanas no previstas. Tais derrapagens poderiam ser evitadas ou minimizadas se houvesse uma definio clara e um acordo dos requisitos, no incio do projecto, e uma qualquer mudana ao longo da vida do projecto j poderia ser negociada, o seu impacto calculado e o atraso no projecto justificado.
83
4.5.
Anlise e Discusso de Resultados
Aps se ter terminado a definio e implementao do modelo de qualidade CMMI na organizao, foi elaborado um inqurito com a finalidade de verificar a eficcia das aces tomadas e da estratgia seguida pela equipa de Qualidade junto dos Gestores de Projecto. No questionrio utilizado, que se encontra em anexo, foram focados os pontos principais referentes ao modo de trabalho das equipas antes do CMMI, as maiores mudanas notadas pelos mesmos aps a implementao dos standards e documentao do modelo de qualidade, as principais vantagens e desvantagens do Modelo e, por fim, avaliar todas as decises tomadas pela rea de Qualidade, nomeadamente se os templates, sites do projecto, RoboHelp, etc. facilitaram ou no a absoro das mudanas e do prprio modo de trabalho. Com a realizao do inqurito procurava-se constatar o pr e o ps-CMMI. No s para verificar quais foram os pontes fortes e pontos fracos do trabalho referente rea de Qualidade, mas tambm para servir como referncia a essa rea para colmatar as falhas encontradas pelos Gestores e procurar melhorar alguns aspectos que os mesmos considerassem que poderiam ser melhorados. Para tal, foi includa uma ltima questo nesse inqurito, em que se pede que os Gestores de Projecto dem sugestes de melhoria e que apontem os aspectos que gostariam de ver modificados, com o intuito de melhorar o trabalho dirio na organizao e melhor responder aos requisitos do modelo de Qualidade. Este inqurito foi realizado durante o ms de Abril, um ms e meio depois de concluda a implementao e definio de todas as reas de processo definidas, tendo sido escolhidos 22 Gestores de Projecto das diversas reas constituintes da empresa (de um total de 48) com intervalo de anos de experincia em gesto de projectos que vai dos 2 aos 18 anos de experincia e na rea de informtica do Grupo Esprito Santo que vai dos 6 meses aos 24 anos, representando 46% do total de Gestores de Projecto na entidade em estudo e representando toda a amplitude do universo em termos de experincia em gesto de projectos e na ESI. Tendo em conta o pouco tempo de implementao e visto ser uma grande mudana a implementar no seio da empresa e nos mtodos de trabalho dos colaboradores, tais resultados tiveram tambm grande utilidade em perceber como era efectuado o desenvolvimento dos processos de software e o impacto mais imediato que esta mudana teve em cada um deles e na sua equipa de
84
Captulo 4 Caso de Estudo trabalho. No futuro poder ser feito o estudo mais focado nas mudanas a mdio/longo prazo que este modelo de maturidade ir trazer. Foram efectuadas as seguintes questes no estudo elaborado (ver Anexo I): 1. Quais os standards usados, em termos de documentao, no desenvolvimento dos projectos, antes do CMMI? 2. Qual o modelo ou modelos de acompanhamento do projecto usados antes do CMMI? 3. Qual o processo geral de gesto de projectos seguido antes do CMMI (ex. primeiro era feito uma reunio de definio do mbito, depois era preparado um plano do projecto, depois)? 4. Quais os principais problemas identificados no desenvolvimento de software antes do CMMI? 5. Quais os principais aspectos positivos identificados no desenvolvimento de software antes da implementao do CMMI? 6. Como caracteriza a comunicao e controlo de dependncia com equipas de outras reas antes do CMMI? 7. Principais benefcios ou melhorias identificadas originadas pela implementao dos processos referentes ao CMMI? 8. Principais dificuldades identificadas na implementao dos processos referentes ao CMMI? 9. Qual a utilidade das ferramentas utilizadas no decorrer da implementao? 10. Quais as mudanas no mtodo de trabalho aps a implementao do CMMI? 11. O que melhorou na gesto de projectos? 12. O que piorou na gesto de projectos? 13. Como caracteriza a comunicao e controlo de dependncia com equipas de outras reas aps a implementao e definio dos standards documentais para toda a organizao? 14. Qual a sua opinio no que diz respeito a... a. A utilizao do Robohelp facilita a implementao do processo? (discordo totalmente, discordo, concordo, concordo totalmente) b. Os templates de documentos so teis no desenvolvimento do projecto? (discordo totalmente, discordo, concordo, concordo totalmente) c. A utilizao de um site do projecto facilita o trabalho em equipa? (discordo totalmente, discordo, concordo, concordo totalmente)
85
Captulo 4 Caso de Estudo d. A utilizao de um site do projecto facilita a organizao da documentao? (discordo totalmente, discordo, concordo, concordo totalmente) e. A utilizao de um site do projecto facilita o controle do projecto? (discordo totalmente, discordo, concordo, concordo totalmente) f. Suporte aos projectos pela rea de PQSI? g. Que mudanas/sugestes gostaria de ver includas com o intuito de melhoramento da implementao dos processos de CMMI?
Atravs da anlise das respostas dos Gestores de Projecto primeira pergunta do inqurito, Quais os standards usados, em termos de documentao, no
desenvolvimento, antes do CMMI?, foi possvel perceber que na organizao j se utilizavam alguns standards documentais, mas esses standards foram desenvolvidos e implementados ao nvel de cada equipa, ou seja, j havia algum tipo de normalizao na empresa, mas era uma normalizao local, pertencente a uma rea e no uma normalizao global, tal como foi implementado com o CMMI. No que diz respeito utilizao de modelos de acompanhamento Qual o modelo ou modelos de acompanhamento do projecto usados antes do CMMI?, apenas 4 dos 22 inquiridos j tinha utilizado, por iniciativa prpria, nos seus projectos e nas equipas com que trabalhou o modelo de maturidade PMI-BOOK (Project Management InstituteBOOK) (3 inquiridos) e 1 dos inquiridos tinha j utilizado tanto o modelo BIM (Building Information Model) como o mtodo ONE. Nenhum dos restantes inquiridos utilizou qualquer modelo de acompanhamento de projectos. As respostas pergunta Qual o processo geral de gesto de projectos seguido antes do CMMI? demonstraram que apesar da grande maioria dos gestores no utilizar um processo geral de gesto de projectos associados a um modelo de acompanhamento, todas as equipas j tinham um ciclo de vida bem definido, que de certa forma segue o ciclo que foi implementado com o CMMI, tendo as fases de Oramentao, Planeamento, Anlise, etc., sendo que o principal aspecto que os inquiridos viram como uma grande diferena foi o facto de haver muito mais controlo, documentao e actividades bem definidas em cada uma das fases. Tendo em conta as respostas dos Gestores pergunta Quais os principais problemas identificados no desenvolvimento de software antes do CMMI?, ressaltamse problemas como o facto de por vezes ser muito difcil fechar o mbito e compreender os requisitos do utilizador e ter a certeza do que se definia era o que o Sponsor
86
Captulo 4 Caso de Estudo realmente queria. Havia muitas mudanas de requisitos por parte do Sponsor ao longo do ciclo de vida dos projectos e, por vezes, mesmo em fases bem adiantadas (ex: Testes de Aceitao), o que fazia com que houvesse muitos atrasos e desvios oramentais. Outro ponto era o facto de na altura de testes de Aceitao por parte do Sponsor, ele no saber ao certo que testes teria de fazer e por isso necessitar de um enorme apoio por parte da equipa de desenvolvimento. Os aspectos positivos pr-CMMI, no ponto de vista da resposta dos inquiridos pergunta Quais os principais aspectos positivos identificados no desenvolvimento de software antes da implementao do CMMI?, era o facto de que os projectos mais pequenos eram desenvolvidos muito mais rapidamente, considerando mesmo que a documentao (excessiva na sua opinio) definida para estes projectos mais pequenos se revelava mais um entrave do que propriamente um benefcio. A anlise das respostas pergunta Como caracteriza a comunicao e controlo de dependncia com equipas de outras reas antes do CMMI? d a perceber que a comunicao entre as diversas equipas continua igual, tendo havido sempre uma boa comunicao entre elas. No que diz respeito implementao propriamente dita, os Gestores de Projecto que responderam questo Principais benefcios ou melhorias identificadas originadas pela implementao dos processos referentes ao CMMI?, consideram que as principais melhorias advindas do CMMI passam pela normalizao, no s da documentao mas tambm de todos os processos, permitindo que a empresa se torne uma s e no seja composta por ncleos separados como vinha acontecendo at aqui. O facto de haver um exaustivo estudo e definio dos requisitos e posterior aprovao por parte do Sponsor na fase inicial dos projectos, permite haver um maior controlo dos mesmos, diminuindo assim o nmero de mudanas em fases posteriores e tambm permite salvaguardar as equipas, havendo a possibilidade de justificao dos desvios oramentais e dos atrasos resultantes dessas mudanas. As principais dificuldades encontradas em implementar os novos processos referentes ao CMMI, com a anlise das respostas dos Gestores pergunta Principais dificuldades identificadas na implementao dos processos referentes ao CMMI?, prendem-se principalmente com o facto de ter havido um grande aumento de documentao a produzir, uma vez que o tempo disponvel no suficiente e as equipas no esto organizadas para tal, j que so compostas na sua grande maioria por tcnicos e no por analistas funcionais, levando a que essas tarefas documentais se fixem, por
87
Captulo 4 Caso de Estudo vezes, numa s pessoa ou at mesmo levando a que os Gestores sintam a necessidade de delegarem funes suas para poderem executar tais funes, levando a uma perda significativa do controlo do projecto. O facto de no existir ainda uma ferramenta de gesto documental tambm um dos aspectos mencionados, o que ajudaria, e muito, na gesto de mudanas e de actualizao dos documentos, poupando assim muito tempo. Outro aspecto, que se poder considerar normal nesta fase inicial, alguma dificuldade no preenchimento da nova documentao. As ferramentas definidas para o suporte a esta mudana, nomeadamente o RoboHelp e o Microsoft Sharepoint, de acordo com as respostas pergunta Qual a utilidade das ferramentas utilizadas no decorrer da implementao?, foram vistas com bons olhos pelos inquiridos, sendo teis sobretudo como suporte ao esclarecimento de dvidas e como meio de lhes permitir saber ao certo quais actividades/processos/documentos tm de produzir em cada uma das fases. Alm disso, ao existir um site de projecto, acessvel a todos os elementos da equipa, permite estruturar toda a documentao produzida no projecto e ser um ponto nico de partilha, onde todos podem aceder aos documentos que necessitarem. No perodo ps-implementao, ou seja, um ms e meio depois de todos os processos do CMMI terem sido definidos e implementados, atravs da anlise s respostas dadas pergunta Quais as mudanas no mtodo de trabalho aps a implementao do CMMI?, verifica-se que os Gestores de Projecto no vm grandes mudanas em termos de mtodos de trabalho porque os projectos que geriam j tinham um ciclo de vida bem definido e similar ao que foi implementado via CMMI, com a nica diferena em termos de formalismo e necessidade de elaborao de documentao. As melhorias, tendo em conta as respostas pergunta O que melhorou na gesto de projectos? passam por um maior controlo, maior organizao e definio do projecto, com fases e actividades bem definidas, permitindo produzir um produto com maior qualidade, mas por outro lado, verifica-se, atravs das respostas pergunta O que piorou na gesto de projectos, alguma falta de sensibilizao do Sponsor no que diz respeito ao aumento de tempo e consequente aumento de custos dos projectos, ao aumento de documentao a produzir e necessidade de adaptao nova metodologia veio dificultar muito a gesto porque as tarefas aumentaram muito mas o nmero de colaboradores nas equipas manteve-se.
88
Captulo 4 Caso de Estudo As respostas pergunta Como caracteriza a comunicao e controlo de dependncia com equipas de outras reas aps a implementao e definio dos standards documentais para toda a organizao?, do a entender que, em termos de controlo, com a vinda do CMMI e as necessidades de haver acordos dos compromissos das diversas equipas e de elaborar status reports, veio de certa forma aumentar e especificar esse controlo de dependncias e atribuio de deveres, algo que era dificil de fazer sobretudo em projectos de grande dimenso em que eram envolvidas vrias equipas de diversas reas. Como se pode ver atravs da anlise dos resultados presentes no grfico 2 da Figura 37, apenas 5% dos inquiridos (1 dos Gestores) considerou que o Robohelp no o ajudava, enquanto que os restantes inquiridos concorda que a ideia da disponibilizao de uma ferramenta de apoio implementao e consequente utilizao da mesma facilita muito a implementao do processo, servindo como suporte no que diz respeito necessidade de saber o que fazer em determinada fase do ciclo de vida de um projecto e consequente esclarecimento de dvidas que eventualmente surjam.
Figura 37 - Opinio dos Gestores de Projecto (Pergunta 14 a. do Inqurito: A utilizao do RoboHelp facilita a implementao do processo?)
No que diz respeito aos templates que foram disponibilizados aos colaboradores, todos os inquiridos concordaram (Figura 38) que os templates dos documentos que foram disponibilizados ajudaram muito no processo de mudana, permitindo sobretudo, que toda a organizao utilize os mesmos formatos documentais e que todos falem a
Os resultados apresentados nos diversos grficos seguintes encontram-se arredondados s unidades
89
Captulo 4 Caso de Estudo mesma linguagem dentro da empresa, aumentando, sem dvida, o nvel de entendimento de todo o processo de desenvolvimento do projecto.
Figura 38 - Opinio dos Gestores de Projecto (Pergunta 14 b. do Inqurito: Os templates de documentos so teis no desenvolvimento do projecto?)
As respostas pergunta presente na Figura 39, revelam que 95% dos inquiridos entende que o facto de haver um site do projecto facilita bastante o trabalho em equipa, j que o site serve como ponto nico de acesso a todos os elementos da equipa, facilitando assim principalmente o acesso documentao e a todos os itens de trabalho que necessitam para poder desempenhar a sua funo dentro do projecto.
Figura 39 - Opinio dos Gestores de Projecto (Pergunta 14 c. do Inqurito: A utilizao de um site do projecto facilita o trabalho em equipa?)
90
Captulo 4 Caso de Estudo Alm do trabalho em equipa, os Gestores inquiridos concordam em absoluta maioria (Figura 40), que a existncia do site do projecto e da estrutura de pastas predefinida ajuda imenso na organizao de toda a documentao produzida ao longo do ciclo de vida do projecto, organizao e estruturao, permitindo a qualquer um dos elementos da equipa do projecto poder aceder a qualquer documento que necessite com grande facilidade e rapidez.
Figura 40 - Opinio dos Gestores de Projecto (Pergunta 14 d. do Inqurito: A utilizao de um site do projecto facilita a organizao da documentao?)
Quando se perguntou aos inquiridos se a utilizao do site do projecto facilitava o controle do projecto, como se pode verificar na Figura 41, apesar da maioria concordar que atravs do site conseguiriam ter maior controle do projecto por conseguirem um ponto central de trabalho, 19% (5% + 14%) dos Gestores discordaram desta ideia, justificando que no utilizavam o site para fazer o controle mas sim outras ferramentas e mtodos prprios ou anteriormente institucionalizados na empresa.
91
Figura 41 - Opinio dos Gestores de Projecto (Pergunta 14 e. do Inqurito: A utilizao de um site do projecto facilita o controle do projecto?)
Como se pde ver atravs da anlise dos anteriores grficos e do grfico abaixo (Figura 42), que corresponde ao resumo das respostas dadas s alneas da pergunta 14 do inqurito em anexo, os Gestores de Projecto consideram que as ferramentas que foram postas disposio (Robohelp e Microsoft Sharepoint), bem como a criao de templates documentais, vieram amenizar o impacto da mudana e, como j foi dito anteriormente, servir de ajuda para o esclarecimento de dvidas e para disponibilizar um suporte no que diz respeito necessidade de saber o que fazer em determinada fase do ciclo de vida de um projecto. Poder-se- dizer ento que a estratgia e aces de implementao levados a cabo pela organizao, e em particular pela equipa de Processos e Qualidade dos Sistemas de Informao, foram os adequados tendo em conta as expectativas e necessidades dirias dos gestores de projecto e suas equipas.
92
Figura 42 - Resumo da Opinio Gestores de Projecto relativamente Pergunta 14 do Inqurito
Nas respostas de opinio dadas alnea f, a larga maioria dos Gestores de Projecto consideraram que o suporte dado pela equipa de Qualidade tem sido muito bom, que todas as dvidas que tiveram ao longo deste processo de implementao foram esclarecidas e que a rea de Qualidade tem tido bom senso no rigor da validao e demonstrado flexibilidade e capacidade de ouvir opinies, tendo todos esses factores ajudado muito na interiorizao da mudana, dos novos processos e das actividades inerentes. As sugestes de melhoria apontadas pelos Gestores de Projecto inquiridos (na alnea g) incidiram, sobretudo: na indicao da necessidade de ser implementada uma ferramenta de gesto de requisitos, o que iria ajudar de sobremaneira em tudo o que diz respeito gesto de mudanas documentais; na diminuio do volume de documentao a produzir nos projectos mais simples, para acelerar o processo de concluso dos mesmos; e tambm na necessidade de maior envolvimento do Sponsor neste processo de mudana. Concluindo, pode-se afirmar, atravs da anlise dos inquritos feitos aos Gestores de Projecto e atravs da vivncia diria com as diversas equipas de desenvolvimento que 93
Captulo 4 Caso de Estudo esta implementao e a mudana que da adveio, apesar de ter alguns pontos negativos no ponto de vista dos mesmos, ir trazer muitas coisas positivas e ir, sem dvida, a mdio/longo prazo melhorar todo o processo de desenvolvimento de software na Esprito Santo Informtica.
94
5. Consideraes Finais
Ao longo desta dissertao pretendeu-se, sobretudo, focar o processo de desenvolvimento de software, dando destaque necessidade da sua qualidade como factor determinante para a obteno de melhores resultados, do prprio sucesso das organizaes e da optimizao das actividades inerentes a todo o processo de desenvolvimento. Aps essa abordagem geral, a questo da mudana surge em particular ligada deciso de melhoria dos processos de desenvolvimento de software por parte da empresa em estudo, nomeadamente a Esprito Santo Informtica, que se aventurou nesse desafio de se propor a uma grande mudana organizacional, para poder eliminar lacunas existentes e poder dar resposta aos pedidos de desenvolvimento de software com mais qualidade, aumentando assim os nveis de satisfao do cliente. A questo da qualidade est j bastante presente e interiorizada quando falamos em organizaes que provm de pases mais desenvolvidos e que de certa forma dominam no s o mercado nacional mas tambm mundial como, por exemplo, os EUA, a ndia, a China, o Japo, entre outros. So vrias as organizaes que apostam fortemente na qualidade, no s para optimizao de todos os seus processos de desenvolvimento, mas tambm para marcarem uma posio fivel e concisa aos olhos dos clientes e do prprio segmento de mercado onde actuam. Uma organizao que garanta um bom servio, com qualidade superior e que chegue a exceder as expectativas, mais facilmente seleccionada quando comparada com uma empresa que somente tenha como meta atingir os mnimos indispensveis para dar resposta ao pedido do cliente. O Mundo est em constante mudana e o mercado de trabalho no foge regra. Para dar conta de tantas mudanas e tantos avanos tecnolgicos e at mentais, as 95
Captulo 5 Consideraes Finais organizaes tero de se precaver e seguir neste comboio da mudana, sob o grande risco de ficarem para trs e de se perderem na luta diria por um espao no competitivo mercado em que operam. Esta precauo ter de ser feita com a optimizao e melhoria contnua de todos os pontos correspondentes sua rea de negcio. Seno vejamos, qual a grande organizao, de renome, com sucesso que, por exemplo, no possui um site de Internet nos dias de hoje? Ou qual o grande fornecedor que no oferece hoje encomendas via Internet ou at mesmo no possibilita a opo de entrega ao domiclio? Todas as organizaes tero de mudar com o objectivo de dar resposta s (mais diversas) necessidades dos clientes e ganhar o seu espao. A organizao que se mostrar relutante mudana e se mantiver fiel e resignada apenas na sua boa performance diria actual, mais tarde ou mais cedo ir sentir as consequncias de no se ter preparado para o futuro. O grande esforo (na maioria das vezes) de mudar para melhor trar, sem dvida, os seus dividendos num mdio/longo prazo, de forma mais visvel na reduo de custos e aumento dos proveitos. No caso especfico de processos de desenvolvimento de software, a melhoria da qualidade pode ser obtida atravs da implementao de Modelos de Maturidade, modelos esses que permitem organizao avaliar os seus processos de desenvolvimento e manuteno, implementar melhorias no seu modo de funcionamento e determinar os progressos obtidos. No caso da Esprito Santo Informtica, aps a constatao de que existiam alguns problemas que vinham ameaando a qualidade do software desenvolvido e que levavam a derrapagens financeiras e de calendrio, como a ausncia de standards de infraestrutura e desenvolvimento, o esforo elevado na anlise de pedidos, resultando em oramentaes muito demoradas, o esforo e demora na recolha de requisitos e a ausncia de controlo de qualidade, entre outros, resolveu avanar para a resoluo destes mesmos problemas e tambm para a melhoria global dos processos e actividades da empresa atravs da adopo do modelo de maturidade CMMI, um standard de facto da indstria, para guiar a melhoria do seu processo de desenvolvimento. O objectivo passou ento pela certificao em nvel 2 de CMMI, sendo necessrio para isso a definio e implementao das reas de processo correspondentes a esse nvel. A deciso de adoptar o CMMI numa organizao multi-facetada. A framework do CMMI ter de ser comparada a outras opes de melhoria, como a ISO 9001-2000, o PMBOK (Project Management Body of Knowledge), entre outras. Se a deciso de adoptar o CMMI for feita, muitas opes se iro apresentar. Qual a melhor
96
Captulo 5 Consideraes Finais representao? STAGED ou CONTINUOUS? Qual dos modelos deve ser adoptado? Software ou Engenharia de Sistemas? Que nvel de maturidade se pretende atingir...? Qualquer que seja a motivao de adopo do CMMI, imperativo que a organizao se foque primeiramente e de forma consistente em definir o que a implementao do CMMI suposto que atinja. O esforo CMMI deve ser capaz de fazer parte de forma significativa da soluo dos objectivos como, por exemplo, aumentar a base do negcio de engenharia de sistemas em 15% em dois anos ou dispor uma abordagem e mecanismos fiveis para permitir responder a novas necessidades de engenharia em questo de dias. Objectivos mais tpicos tais como aumentar a qualidade do produto e diminuir o tempo de resposta ao mercado tambm so apropriados. Esta dissertao pretendeu dar a conhecer de uma forma detalhada e especfica as caractersticas, as componentes e todos os aspectos abordados no modelo CMMI, e tambm os principais benefcios e limitaes que este modelo oferece. Das muitas organizaes que j adoptaram o CMMI em todo o Mundo ( volta de 1500), foram apresentados 3 casos prticos que relatam a implementao do CMMI e os principais benefcios que da advieram. No que diz respeito ESI, esta dissertao permitiu demonstrar todo o caminho que a empresa passou para definir e implementar todas as mudanas no seu seio, mudanas essas indispensveis para estar em conformidade com o que especificado no modelo CMMI. Foi dado a conhecer todo o processo concreto de averiguao dos problemas existentes na empresa (tendo como base de comparao a metodologia CMMI) e tambm todas as estratgias e aces levadas a cabo pela empresa para implementar o modelo e conseguir, desta feita, suprir todos esses problemas/lacunas que existiam, com vista a discutir a sua eficincia na prtica. Alm de todos os aspectos inerentes mudana, o principal benefcio diz respeito verificao do impacto que uma mudana do calibre da que aqui se encontra documentada teve no dia-a-dia das diversas equipas que compem esta grande organizao e das grandes dificuldades que a relutncia mudana das mesmas veio trazer a este processo de melhoria. O facto da escrita desta dissertao ter coincidido justamente com todo o processo de definio e implementao do modelo de maturidade na empresa e o facto de ter havido um contacto dirio com as pessoas que compem a mesma, permitiu ter a grande vantagem de poder constatar directamente todo o impacto que esta mudana teve nas
97
Captulo 5 Consideraes Finais vrias equipas, no modo de trabalho que j se vinha definindo e cimentado h vrios anos e tambm actuar junto dos visados, em vez da base do estudo ser um conjunto de documentao ou estatsticas globais da empresa, possibilitando assim compreender quais foram os benefcios e problemas que encontraram ao longo do tempo, respeitantes introduo das novas actividades e processos decorrentes do CMMI e, por fim, verificar se todas as aces/estratgias/ferramentas definidas e utilizadas para esta mudana foram as mais indicadas e se serviram os propsitos e necessidades dirias das diferentes equipas. Esta dissertao permitiu ento classificar os grandes impactos que uma mudana deste calibre gera, com todos os seus prs e contras, todas as dificuldades inerentes e alteraes do ambiente e trabalho dirio de uma empresa de grandes dimenses, com vrios anos de actividade. Um trabalho futuro, dando continuidade ao aqui apresentado, poder ser abordar as mudanas na empresa a mdio/longo prazo. A elaborao de um estudo em que este processo de mudana inerente implementao do modelo de maturidade esteja j mais interiorizado pelas pessoas, j bastante assente no seio da organizao e com um certo nvel de maturidade dos seus processos/actividades, permitir obter resultados concretos a nvel de ganhos e perdas, podendo ser possvel verificar se os principais problemas que os projectos de desenvolvimento tipicamente tm, como a derrapagem de oramentos e de calendrio, a falta de normalizao nos processos, o pouco controlo das actividades, etc., sero minimizados ou at mesmo extinguidos. Tal como foi feito j em outros estudos em empresas de grande dimenso como o caso da Boeing, Siemens, etc., poder-se- calcular qual foi o ganho em termos de reduo de defeitos na produo, se os custos diminuram, se os prazos e oramentos passaram a ser cumpridos ou se a sua margem de erro diminuiu. Ou seja, ser bastante interessante identificar qualitativa e quantitativamente as mudanas que a implementao de um modelo de maturidade de processos trouxe organizao e at mesmo poder fazer comparaes com outras organizaes certificadas em CMMI e com valores mdios fornecidos pela entidade responsvel pela criao do CMMI, a SEI, permitindo assim averiguar qual a taxa de sucesso presente na empresa. Em jeito de concluso poder-se- dizer que os principais contributos decorrentes desta dissertao, passam pela constatao que a deciso de se efectuar uma mudana de to grande relevo requer muito esforo e objectivos bem definidos e uma capacidade muito grande de lutar contra a resistncia (natural) das vrias equipas que compem a
98
Captulo 5 Consideraes Finais organizao e de seguir sempre o caminho de tentar adaptar ao mximo todos os processos e actividades definidas, para irem de encontro s necessidades das equipas, com o intuito delas conseguirem responder aos mais variados pedidos que lhes so feitos e aos modos de trabalho/caractersticas dos colaboradores de cada uma dessas equipas. Alm de toda experincia in loco que permitiu ter a percepo da realidade de uma grande empresa e dos seus processos antes CMMI e aps CMMI, o facto de ter sido possvel interagir, no s atravs da elaborao dos inquritos e entrevistas, mas tambm diariamente com os colaboradores das vrias equipas constituintes da empresa, permitiu verificar quais foram os principais documentos/processos/actividades que tiveram melhor aceitao e se revelaram como uma mais-valia para as necessidades de cada um e os que, no ponto de vista dos colaboradores, no trazem grande valor acrescentado e at por vezes so considerados como factores responsveis por alguns atrasos em algumas fases e causadores do aumento de tempo necessrio para desenvolver os projectos e at mesmo do aumento excessivo da burocracia. Portanto, o aumento de documentao (alguma desnecessria aos olhos dos colaboradores) o principal factor negativo decorrente da implementao do modelo CMMI. Apesar destes aspectos negativos, de forma geral pode-se dizer que as pessoas aceitaram a mudana e deram conta, nesta fase inicial, que a implementao deste modelo de maturidade ir trazer grandes benefcios para a organizao, comeando pela normalizao dos processos, documentos, etc., permitindo que toda a organizao fale a mesma linguagem, passando por um maior controlo de definio e da prpria mudana de requisitos ao longo do ciclo de vida dos projectos e das restantes actividades que so necessrias executar nas diferentes fases de um projecto, acabando com a entrega de um produto de software ao cliente com mais qualidade e menos probabilidade de conter erros no detectados durante o desenvolvimento e erros psimplementao. Pesando os prs e contras de toda esta definio e implementao do modelo CMMI, e tendo em conta que, por larga maioria, os gestores de projecto entrevistados consideraram que o que a equipa de Qualidade definiu e implementou, desde a ferramenta de apoio implementao, o Robohelp, o site de projecto que permite um acesso geral a todas as pessoas da equipa documentao e todos os templates de documentos criados, foi de encontro s suas necessidades e provaram ser uma grande ajuda neste processo de interiorizao de toda esta mudana. Pode-se dizer, com grande
99
Captulo 5 Consideraes Finais certeza, que esta implementao do CMMI nos processos de desenvolvimento de software na Esprito Santo Informtica se revelou um sucesso, cuja constatao dos benefcios decorrentes poder servir como incentivo para outras organizaes procurarem tambm uma melhoria a este ou a outro nvel, tendo em conta as suas capacidades e sobretudo necessidades.
100
Bibliografia
Amaral, L. e J. Varajo, Eds. (2000). Planeamento de Sistemas de Informao, Portugal, FCA. Argyris, C. e D. Schn (1978). Organizational Learning: A Theory of Action Perspective, Reading, MA: Addison-Wesley. Baskerville, R. e A. T. Wood-Harper (1996). A Critical Perspective on Action Research as a Method for Information Systems Research, Journal of Information Technology, pp. 235-246. Baskerville, R. L. (1999). Investigating Information Systems With Action Research, Computer Information Systems Department, Georgia State University. Bensabat, I., D. K. Goldstein, et al. (1987). The Case Research Strategy in Studies of Information Systems, MIS Quarterly, pp. 369-386. Burn, J. (1994). A revolutionary staged growth model of information systems planning, Proceedings of the Fifteenth International Conference on Information Systems: 395406. Carr, W. e S. Kemmis (1986). Becoming Critical: Education, Knowledge and Action Research, Flamer Press, London. Clark, P. A. (1972). Action Research and Organizational Change, Harper & Row, London. Davies, L. J. e S. Nielsen (1992). An Ethnographic Study of Configuration Management and Documentation Practices in an Information Technology Centre, The Impact of Computer Supported Technology on Information Systems Development. Denzin, N. K. e Y. S. Lincoln (2005). The Sage Handbook of Qualitative Research, 3rd Edition, Sage Publications, London. Dion, F. (2003), What is CMMI, v1.0, July 30, Process Academy's White Paper, from http://www.ProcessAcademy.ca, consultado a 15/10/07. 101
Bibliografia
DOD (1994), Defense Science Board. Report of the Defense Science Board Task force on Acquiring Defense Software Commercially, Washington, D.C. Ekdahl, D. F. e S. Larsson (2006). Experience Report: Using Internal CMMI Appraisals to Institutionalize Software Development Performance Improvement, IEEE, 32nd EUROMICRO Conference, Digital Object Identifier 10.1109/EUROMICRO.2006.37, pp. 216-223. Elden, M. e R. F. Chisholm (1993). Emerging Varieties of Action Research: Introduction to the Special Issue, Human Relations (46:2), pp. 121-142. eProject, I. (Dezembro, 2004). Capability Maturity Model (CMM) White Paper, from http://www.eproject.com, consultado a 15/10/07. Ferreira, A. I. F., G. Santos, R. Cerqueira, M. Montoni, A. Barreto, A. O. S. Barreto, A. R. Rocha (2007). Applying ISO 9001:2000, MPS.BR and CMMI to Achieve Software Process Maturity: BL Informaticas Pathway, IEEE, Digital Object Identifier 10.1109/ICSE.2007.15, pp. 642-651. Gonzlez, F. (1997). Epistemologa cualitativa y subjetividad, Psicologia e Sociedade, So Paulo, v.9, n. 1/2, pp. 65-90. Hirschheim, R. e H. Klein (Maro 1994). Realizing Emancipatory Principles in Information Systems Development: The Case for ETHICS, pp. 83-109. Holzblatt, K. e H. Beyer (1993). Making Customer-Centered Design Work for Teams, Communications of the ACM, pp. 93-103. Hughes, J. A., D. Randall e D. Shapiro (1992). Faltering from Ethnography to Design, Conference on Computer-Supported Cooperative Work: Sharing Perspectives, pp. 115123. ISWORLD (2008), Association For Information Systems from http://www.isworld.org, acedido a 27/11/07. Jokela, T. e T. Lalli (Abril 2003). Usability and CMMI: Does A Higher Maturity Level in Product Development Mean Better Usability?, Computer-Human Intercation, Fort Lauderdale. Jones, L. G. e A. L. Soule (Julho, 2002). Software Process Improvement and Product Line Practice: CMMI and the Framework for Software Product Line Practice, Software Engineering Institute, Technical Note, CMU/SEI-2002-TN-012. Kant, I. (1908). The Critique of Pure Reason (1781), Modern Classical Philosophers: in B. Rand, (ed.) Modern Classical Philosophers, Cambridge, MA: Houghton Mifflin, pp. 370-456. Kaplan, B. e Maxwell (1994). Qualitative Research Methods for Evaluating Computer Information Systems, Evaluating Health Care Information Systems: Methods and Applications, Sage Publications, Thousand Oaks, pp. 45-68. 102
Bibliografia
Kasse, T. (2002). Action Focused Assessments for Software Process Improvement, Artech House Inc., Norwood, MA. Kay, R. (2005). CMMI, COMPUTERWORLD, http://www.computerworld.com , consultado a 15/10/07. January 24, from
Keen, P. (1991). Relevance and Rigor in Information Systems Research: Improving Quality, Confidence Cohesion and Impact, Information Systems Research: Contemporary Approaches & Emergent Traditions, pp. 27-49. King, W. e T. Teo (1997). Integration between Business Planning and Information Systems Planning: Validating a Stage Hypothesis, Decision Sciences: 279-307. Kitson, D. H. e W. S. Humphrey (1989). The Role of Assessment in Software Process Improvement, (CMU/SE1-89-TR-3, ADA227426), Pittsburgh PA Software Engineering Institute, Carnegie Mellon University. Kung, H.-Y. e J.-S. Hua (2006). Sensor Surveillance System for Drought Disaster Based on CMMI Model, IEEE, Innovative Computing, Information and Control, First International Conference, Digital Object Identifier 10.1109/ICICIC.2006.347, pp.722725. Lewis, I. M. (1985). Social Anthropology in Perspective: The Relevance of Social Antropology, 2nd Edition, Cambridge, UK, Cambridge University Press. Luqman, A. (2005). Implementation and Analysis of CMMIs Configuration Management Process Area, 0-7803-9421-6/05 IEEE., pp. 296-301. Machado, C. e Burnett, R. C. (2001), Gerncia de Projetos na Engenharia de Software em Relao as Prticas, In: XII CITS:QS Mtricas para Qualidade e Produtividade de Software, Curitiba : Editora Universitria Champagnat, pp. 172-181. Martin, P. Y. e B. A. Turner (1986). Grounded Theory and Organizational Research, The Journal of Applied Behavioral Science, pp. 141-157. McFeeley, R. (1996). IDEALSM: A Users Guide for Software Process Improvement, Software Engineering Institute Handbook, Carnegie Mellon University, CMU/SEI-96HB-001. Miles, M. B. e A. M. Huberman (1994). Qualitative Data Analysis: An Expanded Sourcebook, 2nd ed. Thousand Oaks, CA: Sage. Chapter 11: Ethical Issues in Analysis Summarized. Miller, M., D. M. Ferrin, F. Pulgar-Vidal (2002) ACHIEVING HIGHER LEVELS OF CMMI MATURITY USING SIMULATION, IEEE, Proceedings of the 2002 Winter Simulation Conference, pp 1473-1478. Minnich, I. (Fevereiro 2002). CMMI Appraisal Methodologies: Choosing What Is Right for You, CrossTalk: The Journal of Defence Software Engineering, Vol. 15, No. 2, pp. 7-8. 103
Bibliografia
Myers, M. D. (Junho 1997). Qualitative Research in Information Systems, MISQ Discovery, MIS Quarterly (21:2), pp. 241-242. Myers, M. D. e M. Newman (2007). The qualitative interview in IS research: Examining the craft, Information and Organization (17:1), pp.2-26. Naur, P. e B. Randell (1968). Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO (1969), 231p. Ngwenyama, O. K. e A. S. Lee (1997). Communication Richness in Electronic Mail: Critical Social Theory and the Contextuality of Meaning, MIS Quarterly (21:2), pp. 145-167. Oliveira J., K. Oliveira K. e A. Dias Belchior. (2006), Measurement Process: A Mapping Among CMMI-SW, ISO / IEC 15939, IEEE Std 1061, SIX SIGMA And PSM, Departamento das Cincias Computacionais, Universidade de Fortaleza, IEEE, ISBN: 1-4244-0450-9, pp 810-815. Orlikowski, W. J. e J. J. Baroudi (1991). Studying Information Technology in Organizations: Research Approaches and Assumptions, Information Systems Research pp. 1-28. Paulk, M. C., C. V. Weber S.M. Garcia, M.B. Chrissis e M. Bush (1993). Key Practices of the Capability Maturity Model, Software Engineering Institute, CMU/SEI-93-TR-25 Peters, M. e V. Robinson (1984). The Origins and Status of Action Research, Journal of Applied Behavioral Science, pp. 113-124. Pettigrew, A. M. (1985). Contextualist Research and the Study of Organizational Change Processes, Research Methods in Informations, pp. 53-78. PMFORUM (2008), from http://www.pmforum.org/, consultado a 11/03/08. Preston, A. M. (1991). The 'Problem' in and of Management Information Systems, Accounting, Management and Information Technologies, pp. 43-69. Rapoport, R. N. (1970). Three Dilemmas in Action Research, Human Relations (23:6), pp. 499-513. Robinson, N., P. Lindsay, A. Pitman (2000). Extending the Integrated Capability Maturity Model (CMMI) for Safety-related Applications, Queensland, Australia, University of Queensland. ROBOHELP (2008), from www.adobe.com/products/robohelp/, consultado a 25/06/08. Rocha, . e J. Vasconcelos (2004). Os Modelos de Maturidade na Gesto de Sistemas de Informao, Revista da Faculdade de Cincia e Tecnologia da Universidade Fernando Pessoa: 93-107.
104
Bibliografia Rochecouste, H. (2003), CMMI Use the Body of Knowledge to Create and Improve your System Integration Capability, EC&S Systems Pty. Ltd, Melbourne, Australia. Royce, W. (2002). CMM vs. CMMI: From Conventional to Modern Software Management, Rational Edge. Rubin, I. e H. Rubin (1995). Qualitative interviewing : the art of hearing data, Thousand Oaks, CA: Sage Publications, 2nd Edition, 306 p. Ruzhi, X. e N. Peiyao (Setembro, 2005). Optimizing Software Process based on Risk Assessment and Control, IEEE, Fifth International Conference of Computer and Information Technology, Digital Object Identifier 10.1109/CIT.2005.151, pp.896-900. Serapioni, M. (2000). Mtodos qualitativos e quantitativos na pesquisa social em sade: algumas estratgias para a integrao, Cincia & Sade Coletiva, ABRASCO, vol. 5, n1, pp. 187-92. SEI (2007), from http://www.sei.cmu.edu/cmmi/, consultado a 21/10/07. SHAREPOINT (2008), from www.microsoft.com/Sharepoint/default.mspx, consultado a 25/06/08. Silverman, D. (1993). Interpreting Qualitative Data: Methods for analysing talk, text and interaction, London: Sage. Standish (1994). Chaos Report 1994. Software Development Report, The Standish Group, West Yarmouth, MA, disponvel em http://www.standishgroup.com. Standish (2004). Chaos Report 2004. Software Development Report, The Standish Group, West Yarmouth, MA, disponvel em http://www.standishgroup.com. Straub, D., D. Gefen, M. Boudreau (2004). The ISWorld Quantitative, Positivist Research Methods Website, from http://dstraub.cis.gsu.edu:88/quant/. Stevens, S. T. (Agosto 2007). Applying CMMI and Strategy to ATE Development, IEEE, Instrumentation & Measurement Magazine, Digital Object Identifier 10.1109/MIM.2007.4291221, pp.38-43. Subbiah, B. e M. Sethuraman (2006) Multiple views of CMMI approach: A Case Experience, India, Cybernet Software System, White Paper. Suchman, L. (1987). Plans and Situated Actions: The Problem of Human-Machine Communication, Cambridge University Press. Susman, G. e R. Evered (1978). An Assessment of The Scientific Merits of Action Research, Administrative Science Quarterly, pp. 582-603. SWEBOK (2004), Guide to the Software Engineering - Body of Knowledge, IEEE Computer Society Order Number C2330, ISBN 0-7695-2330-7, Library of Congress Number 2005921729, 204p.
105
Bibliografia Walsham, G. (1993). Interpreting Information Systems in Organizations, 1st Edition, Chichester: John Wiley & Sons, Inc, ISBN:0471938149. Wikipedia (2008), from www.wikipedia.org, acedido a 27/03/08. Wynn, E. (1979). Office conversation as an Information Medium, Department of Anthropology, University of California, Berkeley, unpublished PhD dissertation. Xu, R., Y. Xue, P. Nie, Y. Zhang; D. Li (2006). Research on CMMI-based Software Process Metrics, IEEE, Digital Object Identifier 10.1109/IMSCCS.2006.260, pp. 391 397. Yin, R. K. (2002). Case Study Research, Design and Methods, 3rd ed. Newbury Park, Sage Publications. Zuboff, S. (1988). In the Age of the Smart Machine: The future of work and power, New York, NY: Basic Books, 400 pp.
106
Anexo I
INQURITO AOS GESTORES DE PROJECTO Data: Nome: / / E-mail:
Anos de Experincia em Gesto de Projectos: Anos de Experincia na ESI:

ANTES DO CMMI 1- Quais os standards usados, em termos desenvolvimento dos projectos, antes do CMMI? de documentao, no
2- Qual o modelo ou modelos de acompanhamento do projecto usados antes do CMMI?
3- Qual o processo geral de gesto de projectos seguido antes do CMMI (ex. primeiro era feito uma reunio de definio do mbito, depois era preparado um plano do projecto, depois)?
107
Anexo I
4- Quais os principais problemas identificados no desenvolvimento de software antes do CMMI?
5- Quais os principais aspectos positivos identificados no desenvolvimento de software antes da implementao do CMMI?
6- Como caracteriza a comunicao e controlo de dependncia com equipas de outras reas antes do CMMI?
IMPLEMENTAO DO CMMI 7- Principais benefcios ou melhorias registadas originadas pela implementao dos processos referentes ao CMMI?
8- Principais dificuldades referentes ao CMMI?
identificadas
na
implementao
dos
processos
9- Qual a utilidade das ferramentas utilizadas no decorrer da implementao?
DEPOIS DO CMMI 10- Quais as mudanas no mtodo de trabalho aps a implementao do CMMI?
11- O que melhorou na gesto de projectos?
108
Anexo I
12- O que piorou na gesto de projectos?
13- Como caracteriza a comunicao e controlo de dependncia com equipas de outras reas aps a implementao e definio dos standards documentais para toda a organizao?
14- Qual a sua opinio no que diz respeito a... a. A utilizao do Robohelp facilita a implementao do processo? (discordo totalmente, discordo, concordo, concordo totalmente)
b. Os templates de documentos so teis no desenvolvimento do projecto? (discordo totalmente, discordo, concordo, concordo totalmente)
c. A utilizao de um site do projecto facilita o trabalho em equipa? (discordo totalmente, discordo, concordo, concordo totalmente)
d. A utilizao de um site do projecto facilita a organizao da documentao? (discordo totalmente, discordo, concordo, concordo totalmente)
e. A utilizao de um site do projecto facilita o controle do projecto? (discordo totalmente, discordo, concordo, concordo totalmente)
f.
Suporte aos projectos pela rea de PQSI?
g. Que mudanas/sugestes gostaria de ver includas com o intuito de melhoramento da implementao dos processos de CMMI?
109
Anexo I
INQURITO AOS GESTORES DE PROJECTO
Data: Nome:
07 / 04 /08 Gestor de Projecto 01 E-mail:

R1: Alguns processos formais mas sem qualquer standard. R2: No utilizo nenhum modelo de acompanhamento. R3: Vinha da organizao. Fases +/- definidas, kick-off, definio de mbito, constituio equipa de projecto, desenvolvimento (trabalho de diagnstico e fase de definio de requisitos) e fase de concluso. Praticamente no havia nada escrito. De vez em quando fazamos as actas das reunies. R4: Dificuldade em fechar o mbito e fechar os requisitos. Existiam vrias etapas na definio dos requisitos (macro requisitos, depois mais detalhe, ...) e quando se chegava fase de testes, havia por vezes grandes falhas. No havia especificao de testes. R5: Informalismo traz mais rapidez. Para coisas simples o CMMI poder ser mais entrave do que benfico. R6: Existia gesto de relao das equipas. A comunicao nem sempre era a melhor porque umas equipas tinham um modo de trabalho, outras equipas tinham outro. R7: Uniformizao. Criar fases estanques e no avanar para fases sem as anteriores estarem fechadas. Haver regras. R8: Os projectos j em desenvolvimento difcil conseguir ir de encontro ao que o CMMI pede. R9: So teis, o Robohelp como guia e para tirar dvidas e o Sharepoint como ponto de partilha. R10: Uniformizao e uso de regras entre fases de projectos. R11: Conseguir gerir um projecto um passo a seguir ao outro R12: Para projectos mais pequenos a carga muito grande. R13: Mesma linguagem dentro da organizao permite-nos ter uma melhor comunicao.
110
Anexo I
R14a: Concordo Totalmente. R14b: Concordo. R14c: Concordo. R14d: Concordo. R14e: Concordo. R14f: Sempre que necessrio fui esclarecido. implementao e esclarecimento de dvidas. um bom suporte para
R14g: Menos documentao para projectos mais pequenos. Ferramenta de gesto de requisitos e documentao. Ter vrias ferramentas por vezes no ajuda (planeamento num stio, gesto noutro, ...). Deveriam ser integradas para melhor controlo.
111
Anexo I
INQURITO AOS GESTORES DE PROJECTO Data: Nome: 07 / 04 /08 Gestor Projecto 02 E-mail:

R1: Usava prticas PMI, mas sempre por iniciativa prpria. R2: Baseava-me no PMI, escolhendo algumas etapas relevantes do modelo e criando algumas etapas eu prpria, ou seja, era uma prtica pessoal. Tentava que as pessoas com que trabalhava adoptassem os meus planeamentos, controlo oramental, templates, etc. R3: Fazia Kick-off, elaborava um plano conjunto com as vertentes do ciclo de vida de um projecto informtico. Identificava milestones e entregveis, tinha reunies de acompanhamento, status report. Baseava os testes numa ferramenta de controlo e gesto de alterao dos testes. As aceitaes eram via mail. No existia registo da documentao. No havia definio exacta de como eram feitas as coisas. Havia equipas que documentavam muito bem outras que nem por isso. R4: Requisitos incompletos, umas equipas implementavam-nos mesmo incompletos, outras tentavam compreend-los melhor. Postura das equipas era muito diferente. Uma melhor especificao dos testes permitiria planear e fazer as melhorias antecipadamente. R5: Informalismo traz mais rapidez. Para coisas simples o CMMI poder ser mais prejudicial do que benfico. R6: J existia boa comunicao e bom envolvimento das equipas, com as ferramentas que actualmente existem. O CMMI melhorou alguns aspectos. Os standards melhoram a documentao a produzir. R7: Relacionamento fornecedor-cliente. Forma de trabalhar da ESI para o cliente. Formalizao de como as equipas devem proceder. Assim torna-se uma empresa em vez de ncleos separados. Retira do cliente a gesto das diversas equipas. Centra-se no negcio e no nas reas IT. R8: No entendimento total dos standards. Redesenhar certas coisas para obter sign-off. Dificuldades em institucionalizar templates. R9: Muito teis. Devia existir ferramenta da gesto de requisitos e para automatizar as mudanas. O Robohelp ajudou a explicar o CMMI. J utilizava o Sharepoint h algum tempo, sendo muito til para conseguir centrar toda a documentao do projecto. R10: Uniformizao e uso de regras entre fases de projectos.
112
Anexo I
R11: Conseguir gerir um projecto um passo a seguir ao outro R12: Projectos mais pequenos a carga de trabalho mais baixa e o CMMI faz com que se demore muito. Por vezes fazem-se as coisas e escreve-se a documentao CMMI depois. R13: Mesma linguagem permite uma melhor comunicao. R14a: Concordo Totalmente. R14b: Concordo. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Discordo. R14f: Sempre que houve dvidas foram sempre respondidas. R14g: Diminuir carga para projectos mais pequenos. A documentao no ajuda em projecto reactivos. Falta ferramentas de gesto de requisitos. fcil esquecer a manuteno da documentao por ser manual. No h nada definido para prototipagem, que deveria ser includo em projectos maiores, porque uma imagem vale mais que mil palavras. Esse prottipo poderia ser includo no documento de especificao de requisitos de software, caso o projecto desse para faz-lo e posteriormente haveria aceitao desse prottipo. Alinhar a rea de negcio rea de implementao. Por ter documentao muito vasta, o Sponsor no vai ler a documentao, logo a introduo de prottipos seria muito til para auxlio.
113
Anexo I
Data: Nome:
08 / 04 /08 Gestor Projecto 03 E-mail:

R1: Algumas indicaes provenientes do PMI. Variava de equipa para equipa. Cada equipa onde trabalhei tinha os seus standards. R2: PMI mas no baseado numa documentao especfica. R3: No com a obrigatoriedade de formalizao que existe hoje. Com a Microsoft fazia reunies de kick-off, steerings,... O processo dependia do tamanho dos projectos. As entidades externas (IBM, Microsoft) traziam a normalizao para dentro da empresa. R4: Falta de clareza dos requisitos identificados, dificuldade em fechar o mbito. Em questes de timing, avanava para outras fases antes das anteriores estarem fechadas. Muitas mudanas durante o desenvolvimento do projecto levava a derrapagens oramentais e de calendrio. R5: Celeridade no desenvolvimento do processo. Quando o Sponsor sabia exactamente o que queria, o processo de desenvolvimento era rpido. R6: O CMMI ajuda a formalizar o que se quer, ajuda a identificar os pedidos s outras reas. J antes havia boa comunicao, mas o CMMI veio ajudar. J detalhvamos bastante o pedido s outras equipas. O Gestor de Projecto deve garantir que aquilo que pedido deve ser perceptvel por todos. R7: A direco j pede que se faam as coisas que o CMMI pede. Ajuda a ganhar um tempo para produo dos entregveis que antes havia dificuldade em entregar ao Sponsor nos prazos acordados. Justificao de necessidade de mais tempo para desenvolveremos algo com qualidade atravs da metodologia. Permite que a resposta v de encontro ao que se quer porque temos a justificao de terem de seguir os passos definidos pela metodologia. R8: Falta de uma ferramenta que integre a documentao produzida. Implementar ferramentas para o processo de gesto. R9: So teis mas o Sharepoint no chega para ter uma viso integrada de todo o processo.
114
Anexo I
R10: O projecto condicionado aos entregveis definidos no CMMI. Temos de garantir que o projecto produz toda a documentao. O ritmo do projecto est alinhado para o ritmo da elaborao da documentao, por isso ter de se garantir o preenchimento de todos os documentos sem prejudicar o projecto. Ter de saber e planear a altura ideal para preencher determinado documento. Ter de arranjar um equilbrio nas funes a desempenhar. R11: Permite ter mais tempo para entregar um projecto com qualidade porque o Sponsor est sensibilizado que dever dar tempo para a concretizao desse projecto com qualidade. R12: Documentao excessiva. R13: Melhorou porque a metodologia obriga que haja pontos de sincronismo obrigatrios. Documentao em si obriga a que fique bem claro o que se pretende. R14a: Concordo Totalmente. R14b: Concordo. R14c: Concordo Totalmente. R14d: Concordo. R14e: Concordo. R14f: Suporte muito bom. A tarefa da rea muito difcil. Tem havido flexibilidade para ouvir as pessoas e tm sido receptivos s crticas. R14g: Ferramenta de gesto de documentos.
115
Anexo I
Data: Nome:
08 / 04 /08 Gestor Projecto 04 E-mail:

R1: No usava standards, havia apenas documentao que cada um produzia face s suas necessidades. R2: No usava modelos de acompanhamento. Cheguei a utilizar o PMI Book mas sempre numa ptica de curiosidade e no como regra de implementao. R3: No incio dos anos 90 no havia oramentao nem planeamento, o foco estava na necessidade. Geria-se o projecto em funo do custo. Componente tcnica ligeiramente mais avanada. Geria-se reas de desenvolvimento sendo o foco a gesto de equipas. A organizao estava virada para as equipas, ou seja, cada equipa ia fazendo aquilo que lhes era pedido de um ou vrios projectos simultaneamente. No se sabia ao certo o que as equipas produziam ao longo do ano. No meio dos anos 90 j comeou a ver a noo de planeamento, houve a compra dos primeiros pacotes de software e as equipas eram influenciadas e envolvidas com o que as empresas fornecedoras j faziam. R4: Atropelo de prioridades. Projectos decorriam de acordo com as necessidades do Sponsor. Trabalhava-se quase sempre com o mesmo Sponsor. Paravam-se projectos j em desenvolvimento para desenvolver projectos de desenvolvimento prioritrios. R5: Do ponto de vista do utilizador tinha a hiptese de manipular os focos da equipa e o tempo. Do lado do Sponsor podia parar e mandar avanar outros projectos mais importantes e crticos para ele. No havia aspectos positivos da parte das equipas. R6: Antes da integrao da IBM no existia, era uma imposio por um sistema hierrquico. No se falava com as equipas directamente. As decises eram tomadas pelos directores. Apesar de no se demorar mais tempo, a probabilidade de falhas de quem se envolvia era maior. As equipas comunicavam no atravs do pedido mas sim atravs da ordem. Depois da IBM, o dilogo e relacionamento da equipas foi obtido mas no de uma forma estruturada. Existia um conjunto de regras tcnicas e no o controlo de dependncias.
116
Anexo I
R7: Toda a empresa tomou a conscincia da necessidade de trabalho com o mesmo foco. Aplicar as melhores prticas que existiam em algumas reas. Como se comeou a falar em CMMI, isso abriu a mente s pessoas para a mudana. Facilidade de dilogo entre as pessoas quando se fala de algo. Ciclos perfeitamente definidos. Existe mais informao distribuda por todos os intervenientes do projecto. As grandes melhorias esto para vir, para projectos de grande dimenso. A qualidade dos entregveis. Os desenvolvimentos de baixa qualidade j melhoraram um pouco e os bons mantiveram-se. Os grandes problemas existentes no passado deixaro de existir como as grandes diferenas nas estimativas, os extras desenvolvidos (novos requisitos, novas funcionalidades, etc.) no terem tanta qualidade como o que foi pedido inicialmente. R8: Numa estrutura que contm muitas pessoas a mudana mais difcil de passar. Grande nmero de passos e hierarquias. A dificuldade no est tanto em implementar mas sim em alinhar as pessoas para a mudana. Faltam ferramentas de gesto de documentos, principalmente para projectos de maiores dimenses (Grande probabilidade de falha, repetio, etc.) R9: Unificar a forma de implementao dos processos e facilita a produo dos itens necessrios. Mais fcil passar a mensagem. Nivelar a qualidade dos itens a produzir. R10: Passar de mtodos individuais para mtodos uniformes entre as equipas. Documentao e orientao do trabalho para o plano, oramento, qualidade. A principal mudana est em ter uma organizao documentada e estruturada. R11: Fazer gesto de projectos! Ter a viso do projecto do principio ao fim, antes a gesto era descentralizada e s era entregue a um gestor quando havia problemas no projecto. Noo da posio e estado do projecto a cada momento. Capacidade de fornecer reports para a hierarquia e a possibilidade de se poder fazer a gesto da empresa atravs da gesto dos projectos. R12: Nada. R13: A 30%. Faltam ferramentas, ou seja, existem mas no esto optimizadas para isso, so muito complexas. A implementao no foi comprada da mesma maneira por todos. Nas ferramentas existentes h pouca caracterizao das equipas, no se incluem recursos externos (pacote que se compra), logo no possvel fazer o controlo de dependncias com esses recursos. necessrio definir princpios na comunicao e a gesto de tempo de cada uma das pessoas constituintes das equipas. R14a: Concordo Totalmente. R14b: Concordo. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Concordo Totalmente.
117
Anexo I
R14f: Se a empresa quer ter qualidade no pode estar limitada aos meios humanos. A equipa de qualidade ter de ser pr-activa. Necessidade de integrao de mais pessoas. Dividir em 2 fases, em que a 1 seria garantir que se cumpre o processo e numa 2 fase garantir qualidade do processo. R14g: Estabelecer grau de qualidade execuo dos processos. As coisas devem ser feitas de forma gradual. No existir grau de exigncia igual para todos os blocos do ciclo de vida do projecto.
118
Anexo I

R1: J utilizava standards mas em termos de metodologia. Sempre que iniciava um projecto, criava toda a estrutura de organizao documental atravs de uma organizao template, ou seja, todos se baseavam nessa estrutura esqueleto. Tinha hbito de fazer actas de reunio com os Sponsors. Tinha documentao tcnica standard. Nas equipas com que trabalhei no existiam standards, eu introduzia sempre os standards criados por mim. R2: No usava modelos de acompanhamento. R3: No era habitual haver documento de especificao de requisitos nem kickoffs. Existiam mesma fases de oramento, planeamento, anlise e fecho de requisitos. Por vezes especificvamos as necessidades dos clientes a pedido do prprio cliente. Fazamos baterias de testes, actas por decises de fecho de requisitos ou pontos de situao de grandes mudanas. As aprovaes eram via mail. Utilizvamos checklists na entrada dos projectos em produo. R4: Requisitos incompletos, o cliente no sabe muito bem o que quer ao certo, sabe que deveria funcionar de certa maneira mas nunca detalham o pedido. Chega fase de testes de aceitao e h alteraes de requisitos e desvios. Quando havia muito tempo dedicado a oramentao de pedidos de grande dimenso, esse tempo no era registado na ferramenta de imputao de horas. R5: No havia tanto peso de documentao. Nos projectos mais pequenos demorase mais tempo a gerir e planear do que a implementar a mudana. Projectos antes no precisavam de seguir o workflow que seguem agora (Artemis, CMMI,...). R6: A disponibilizao de informao e o tempo de resposta era mais rpido. R7: Introduo da noo de anlise funcional e da elaborao do documento de especificao de requisitos de software que obriga a ir mais fundo na gesto antes de se fazer anlise tcnica. Ganha abrangncia no alto nvel, algo que no acontecia antes. Com o documento de especificao de requisitos de utilizador possvel especificar e desenvolver requisitos mais prximos da realidade e com mais qualidade, j que antigamente o Sponsor criava um PowerPoint com a anlise dos requisitos, os pressupostos, a implementao, dvidas, etc. R8: Todos os projectos em curso actualmente j se tinham iniciado, por isso implementamos o CMMI a meio do seu ciclo de vida. Muita coisa ao mesmo tempo. Temos de fazer coisas adicionais quelas que costumvamos fazer. Existe alguma dificuldade em concluir o documento de planeamento do projecto antes de entrar
119
Anexo I
na fase de Anlise Funcional. Necessidade de arranque de projectos prioritrios. Alguma dificuldade em balancear a conformidade CMMI e a realidade. R9: So teis, o Sharepoint permite ter todas as coisas organizadas e centradas e possvel de consultar por todos. Por vezes perco-me no Robohelp. Ou se tem uma ideia fixa para onde se quer realmente ir seno perde-se a noo de ponto onde se est. R10: No iniciar o desenho antes de ser feita a anlise funcional. No houve grandes mudanas mas sim mais coisas para me dedicar. R11: Metodologia de Status Report, de haver compromissos do prprio utilizador em termos de aceitao. O projecto mais controlado. R12: O detalhe do Status Report para o Utilizador exagerado. A ferramenta Project no fivel para consulta de trmino das tarefas. Tem de se detalhar muito o planeamento para um bom controlo do projecto. Muita mais carga (perodo de adaptao). R13: No tenho sentido grande aderncia das equipas. Demoram a responder a oramento, os planeamentos no so os ideais. Um pedido que no do mbito de um determinado gestor, as outras equipas no lhe do tanta ateno como seria necessrio. R14a: Concordo. R14b: Concordo Totalmente. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Concordo. R14f: Tem sido bom. Foi feito um bom trabalho na fase inicial. Deveriam ter sido criados mais exemplos e guias. Tal facilitaria a interiorizao dos conceitos a implementar. R14g: O documento de planeamento do projecto deveria ser suavizado. Para o efectuar necessrio muita coisa. Alm disso, tambm o Status Report para o Sponsor deveria ser suavizado, j que muita informao para ele, informao que ele no ir ler. No querer ter 100% de aderncia ao modelo por parte dos projectos. Algumas outras coisas poderiam ser melhoradas e suavizadas.
120
Anexo I

R1: J utilizava standards em todas as empresas que trabalhei, ex: Accentures (consultora). R2: Usei o BIM (Business Integration Methodology) e o Mtodo One (Accentures). Utilizvamos nos princpios das metodologias e adaptava-se medida, s necessidades das equipas. R3: Sempre tive um processo definido, com fases tradicionais como as do CMMI, que alternavam mediante o mbito dos projectos. R4: Mais dificuldades de gesto de verses, do projecto com o cliente. No se sabia muito bem como as coisas estavam num determinado momento e o que se ia fazer no passo seguinte. R5: Maior agilidade no desenvolvimento e capacidade de resposta s solicitaes no planeadas. R6: CMMI formaliza um processo. H equipas que j fazem isso de alguma forma estruturada. Antes no havia o formalismo de registar evidncias como agora existe, cada equipa possua os seus registos. R7: Processos definidos de acordo com a gesto que a organizao pretende. Existem evidncias do que feito e que as coisas so feitas com a qualidade adequada. Gesto efectiva e atempada de todas as vertentes e realidades do projecto. No ficam esquecidos factores importantes do projecto (riscos, contingncias, etc.). R8: Tempo de realizao do que pedido face ao esperado. Nesta fase inicial consome-se mais tempo sem que haja uma percepo imediata das vantagens. R9: Ferramentas so adequadas e esto a responder ao pretendido. O RoboHelp importante para a formao e o Sharepoint para repositrio. R10: Mais estruturado, com passos definidos. Alguns passos que foram definidos e que para certos projectos no trazem valor imediato. Houve grandes mudanas na gesto de pequenos projectos.
121
Anexo I
R11: Informao centralizada e estruturada, acessvel por todos. Evidncias dos projectos e dos relacionamentos. Evoluo das pessoas para a prtica de gesto de projectos. R12: Tempo! Tarefas administrativas aumentaram muito. Documentao e formalismos (reunies). Algumas actividades no so directamente produtivas e no so percebidas no imediato. Cliente ainda no est sintonizado com a nova realidade. O cliente ainda usa a realidade antiga. R13: A informao centralizada e normalizada, alguns processos formais de comunicao e controlo de equipa e cliente veio melhorar a comunicao e o controlo. R14a: Concordo Totalmente. R14b: Concordo Totalmente. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Concordo Totalmente. R14f: Tem sido bom. Tem estado sempre disponvel e a dar um grande apoio em termos de ajuda e de validao, o que muito importante para os projectos. Bom senso no rigor da validao. R14g: Continuar as aces de acompanhamento/formao. Existirem eventos regulares para avaliar/corrigir/superar as faltas das equipas ou pessoas. Funciona muito bem para projectos novos mas no to bem para projectos em desenvolvimento ou antigos.
122
Anexo I

R1: Standards eram transversais por rea. Houve um tempo em que respeitvamos e utilizvamos a documentao mas devido presso para desenvolvermos rapidamente deixmos de a utilizar. R2: No utilizava qualquer tipo de modelo. R3: Dependendo do tamanho do projecto tnhamos uma reunio de kick-off, depois oramentao, planeamento, anlise, etc. tal como o CMMI. No eram documentados e formalizados como o CMMI pede, excepo de projectos grandes que j documentvamos mas sem standards. R4: Desenvolvimento face s alteraes de requisitos e desvios. No havia standards na empresa. Com o CMMI est mais claro o que o Sponsor ter de fazer em termos de alterao de requisitos, existindo portanto uma gesto de alterao de requisitos, algo que antes no existia. R5: Menos burocratizao, menos tempo necessrio para desenvolver. Os projectos mais pequenos demoravam menos tempo. R6: Funcionava bem, dialogavam entre elas. A comunicao era feito via troca de mails. R7: Documentao de todo o ciclo de vida do projecto. Partilha de conhecimentos atravs da documentao. R8: Educao, apreenso dos novos conceitos, mais trabalhoso e o facto de no estarem habituados a certos parmetros levou a uma educao das pessoas para atingirem os objectivos propostos. As equipas no esto dimensionadas para o CMMI. R9: So teis. O Sharepoint til para ter um repositrio nico de documentao e para poder centralizar os acessos. O Robohelp, apesar de no ter muita experincia com a ferramenta, acho que til para aprender o que tem de se fazer. R10: Esforo de adaptao e de implementao. Utilizao da documentao e implementao de algumas fases que no tnhamos nos processos que utilizvamos antes. Faltam analistas, a maioria das anlises feita por pessoas com apetncias tcnicas.
123
Anexo I
R11: Obrigatoriedade de documentar. R12: Tempo necessrio para desenvolver aumentou mas o nmero de recursos o mesmo. R13: Manteve-se como j era antes mas com outra formalizao de modos de comunicao. R14a: Concordo. R14b: Concordo Totalmente. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Concordo. R14f: At agora no pedi muita ajuda mas tudo o que solicitei foi respondido. R14g: Definir algo para a Anlise Tcnica. A forma como foi definido o documento de especificao de requisitos de utilizador no intuitivo. Os Casos-de-Uso so contra-natura ao que estamos habituados, penso que no acrescenta valor.
124
Anexo I

R1: J utilizava standards mas mais no desenvolvimento que propriamente em termos de gesto. Os standards eram utilizados ao nvel da equipa e tambm utilizvamos o que os fornecedores tinham j implementado no seu seio. J tenho experincia de 7 anos em CMMI. R2: Alm do CMMI, usava os modelos internos que as multinacionais tinham implementados no seu seio. R3: Utilizava o PMI Book, parecido com o CMMI, com fases j bem definidas e com processos implementados. R4: Na parte dos testes, como no havia controlo suficiente nem informao era muito difcil garantir a satisfao do cliente. R5: Processos mais rpidos. Oramentao era mais rpida porque no havia tanta carga administrativa R6: O PMI era um modelo que se preocupava muito com a comunicao entre as equipas, por isso sempre houve boa comunicao. R7: Os standards, uniformizao transversal a todas as equipas. No tem um efeito imediato, esses efeitos iro ser mais visveis com o tempo e em projectos de grande dimenso. R8: Complexidade de projectos de mdia dimenso. Deveria ser adoptada uma viso mais simples para projectos mais pequenos. Falta de ferramentas de modelos de dados. Informao est um pouco dispersa com o uso de documentos templates. R9: So teis, principalmente o Robohelp est muito claro e intuitivo. R10: Ainda no so visveis, ainda se est numa fase de mudana. As pessoas ainda consideram o CMMI como uma carga de trabalho extra. R11: Controlo e o registo das reunies em actas tem sido importante para uma melhor gesto do projecto. R12: No identifico piorias no que diz respeito gesto dos projectos.
125
Anexo I
R13: A rea que est responsvel pelo processo responsvel pela documentao. As outras equipas apenas a actualizam por isso ainda utilizam documentao que j vinham utilizando antes do CMMI. Aceitam mas ainda no interiorizaram muito a mudana. Mas no geral houve melhorias. R14a: Concordo Totalmente. R14b: Concordo. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Concordo Totalmente. R14f: ptimo Suporte. R14g: Principalmente a incluso de uma ferramenta de gesto de requisitos.
126
Anexo I

R1: Usvamos documentao que era transversal a toda a rea. Fazamos documentao para levantamento de requisitos, envivamos para os programadores e na maioria das vezes no envivamos para o Sponsor. Os programadores faziam bateria de testes na maioria das vezes. Utilizavam tambm uma folha Excel que davam ao Sponsor para ele reportar os erros que encontrava. R2: No utilizvamos qualquer tipo de modelo. R3: Dependia dos projectos. Fazamos reunies com o Sponsor dependendo da complexidade do projecto. Fazamos sempre o planeamento. O processo geral que utilizavam era de certa forma parecido ao definido atravs do CMMI. R4: Problema que o CMMI poder no conseguir resolver que o facto de existir muita presso por parte do Sponsor para cumprir prazos muito apertados. Vista a urgncia no conseguamos seguir um ciclo de vida bem definido. No tnhamos as coisas organizadas e no sabamos que testes tnhamos ao certo. R5: No vejo grandes diferenas, talvez a menor documentao que era obrigatrio e necessrio produzir. R6: J havia uma boa comunicao e controlo devido sobretudo ao bom relacionamento que tnhamos com as diversas equipas. Essa comunicao era feita atravs de mails e telefonemas, muito dificilmente nos reuniamos. R7: Outro tipo de preocupaes, as coisas ficam mais organizadas e as pessoas j se focalizam mais naquilo que tm de fazer. H mais dilogo com os restantes elementos constituintes da equipa, o que muito benfico. Necessidade de seguir um mtodo de trabalho bem estruturado. Todos falam a mesma lngua. R8: A metodologia fcil de aprender e incorporar, a principal dificuldade a educao e a aprendizagem de algumas pessoas. uma questo de hbito e vontade. R9: So teis. O Sharepoint j era antes utilizado para organizao da documentao e como ponto nico de acesso. O Robohelp, apesar de no o utilizar muito muito til para aprender a metodologia. R10: A obrigatoriedade de termos de cumprir o que foi definido. Interagimos mais com os elementos da equipa e com o Sponsor. Muito importante a interaco e organizao dos tempos.
127
Anexo I
R11: Uma melhor organizao. R12: Muitas mais coisas para fazer e muito mais tempo necessrio para as fazer. R13: A comunicao e controlo manteve-se boa como j era antes. R14a: Concordo. R14b: Concordo Totalmente. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Concordo. R14f: Muito bom. Sempre responderam a todas as questes colocadas. R14g: Automatizar mais o processo, implementar ferramentas para essa automatizao. A proposta de soluo de arquitectura podia ser gerada atravs do documento de especificao de requisitos do utilizador.
128
Anexo I

R1: Dependia da ampliao do projecto. Nos mais antigos no se utilizavam standards. Procurvamos fazer um documento genrico que servisse como documento de especificao de requisitos do utilizador e documento de especificao de software (equipa tcnica). Utilizvamos tambm documentos para balizar o compromisso com o Sponsor. Os standards eram utilizados a nvel da equipa. R2: No utilizavam qualquer tipo de modelo. R3: Dependendo da complexidade dos projectos fazamos reunies ou comunicvamos atravs de mails para fazer o oramento, depois gastvamos algum tempo a fazer o documento de requisitos mas sem formalismos. Nos projectos maiores tnhamos reunio de kick-off, reunies de acompanhamento. A finalizao era feita com a aceitao. Tnhamos um ciclo de vida parecido com o do CMMI. R4: A nvel da definio clara do mbito e dos requisitos. No havia prova que os requisitos tinham mudado, coisa que agora j h. R5: Parte da gesto e controlo do projecto. O Sponsor no v utilidade no documento de planeamento do projecto, muito detalhado. Antes era apresentado em PowerPoint. O documento devia ser mais directo e apelativo. R6: No tenho frequentemente projectos que envolvam outras equipas e a interaco que ia tendo era muito por mail e ferramenta Remedy. Os Status Report so importantes para melhorar. Os projectos onde estive implicavam pouca carga e pouca influncia nas outras equipas, mas sempre foi boa. R7: O documento de especificao de requisitos do utilizador e documento de especificao de requisitos de software, toda a empresa faz as coisas de maneira igual. Pode haver substituio de pessoas que quem vier substituir compreende o que foi feito. H evidncias do que foi aprovado e registo de desvios. Tudo no Sharepoint, melhora organizao da documentao e acesso. Compromisso entre Sponsor e ESI. R8: Excesso de documentao. O documento de planeamento do projecto muito extenso. Gesto de alteraes na documentao. Mtricas, as quais no vejo beneficio. O detalhe desgasta muito as pessoas. Relatrios muito grandes.
129
Anexo I
R9: O Sharepoint muito til na partilha e registo de documentao e na garantia de backups. Robohelp uma forma mais fcil de encontrar e consultar informao em caso de dvidas.
R10: Agora fazemos sempre o documento de especificao de requisitos do utilizador antes do oramento (se calhar muito detalhado). H muitas mudanas, apesar de j fazermos as coisas mais ou menos da forma como o CMMI pede. R11: Compromisso com o Sponsor. H uma melhor evidncia do compromisso e menos conflitos aquando de uma alterao. R12: Burocracia excessiva e a questo das mtricas. R13: Apesar de no ter grande experincia prtica, melhorou. R14a: Concordo. R14b: Concordo. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Concordo. R14f: Nada de negativo a apontar. Sempre que precisei obtive uma resposta. R14g: Simplificar a burocracia. Ver o que realmente til e o que no . O documento de planeamento do projecto um bocado excessivo, d mais trabalho que a utilidade que tem.
130
Anexo I

R1: No havia standards, o que havia era de documentao batch. Usava standards IBM que existiam na empresa. Documentos Word para aceitao do Sponsor, criados por mim. R2: No utilizvamos qualquer tipo de modelo. R3: Tinha as fases normais, reunies executivas com os Sponsors. J desde o ano 2000 analisava os requisitos e fazia depois a oramentao. Algo parecido com o CMMI, a diferena est na maior rigidez nos passos e templates. R4: Problemas que ainda hoje existem. Na fase de aceitao do Sponsor, ele precisa de muito apoio nos testes de aceitao. Solicitavam as coisas, mas como falam uma linguagem diferente, chegavam fase dos testes e no os conseguiam fazer. Actualmente esse problema no to grande visto termos mudado de Sponsor. R5: O CMMI d muito trabalho mas permite que haja maior organizao e faz com que o Sponsor perceba tambm. Sempre tive preocupaes que todas as equipas envolvidas tivessem conhecimento das coisas que se passavam no projecto. Os aspectos positivos mantm-se no CMMI. Sempre escrevemos muita documentao porque a informao dentro da cabea das pessoas somente no serve de grande coisa. R6: Nunca tivemos problemas nem dificuldades porque sempre tivemos regras de comunicao com as diversas equipas e essas equipas j tinham essas regras incorporadas. R7: Toda a estrutura percebe que preciso mais tempo para fazer todo o processo CMMI e garantir um produto com qualidade. As coisas esto mais standards e melhora a compreenso de todos e do que a documentao pretende transmitir. Passagem de conhecimento. O facto de haver aceitaes formais, melhorou todo o processo de aceitao do Sponsor. R8: No tive dificuldades, s falta de tempo para conseguir fazer tudo certo. R9: Ainda no utilizei muito as ferramentas que foram definidas. R10: No h muitas mudanas. R11: H mais controlo porque os passos esto pr-definidos. Quando falam, falam todos a mesma linguagem.
131
Anexo I
R12: No piorou nada. R13: Manteve-se igual. R14a: Concordo Totalmente. R14b: Concordo Totalmente. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Concordo Totalmente. R14f: ptimo suporte. R14g: Comecei h pouco e o que fiz at agora correu tudo bem, no tenho por isso indicaes de melhorias ou mudanas.
132
Anexo I

R1: Tnhamos standards para a anlise funcional e tcnica. O Project para acompanhar o desenvolvimento e cadernos de testes. Standards criados e adaptados s necessidades. R2: No utilizvamos qualquer tipo de modelo. R3: Num projecto tivemos de fazer o acompanhamento das equipas porque trabalhvamos com uma equipa dos E.U.A.. Reunies dirias para acompanhar o trabalho e definio de fases e tarefas. Definamos quais as tarefas, actividades e tnhamos actividades definidas e reunies semanais via teleconferncia. Nos restantes projectos trabalhvamos lado a lado com o Sponsor por isso no havia o formalismo. R4: No identifico muitas falhas. Mais a nvel de gesto de riscos e de gesto de projecto. A parte de desenvolvimento estava bem assegurada. R5: difcil ter um modelo de comparao. Antes trabalhava mais organizado, apesar de considerar que a culpa no vem do CMMI. Hoje em dia estamos mais preocupados com a qualidade de que com a anlise propriamente dita. R6: A comunicao era boa. Tnhamos documentos de protocolo entre as vrias reas. Definamos os layouts dos ficheiros e comunicvamos via telefone e mail. R7: Uniformizao. Todos trabalham da mesma maneira. R8: Apenas o tempo que tem de se despender. No tive dificuldades, j fazamos documentao, uma questo de alterao de layouts. R9: Robohelp fantstico para saber em que fase se deve fazer determinado documento e manter uma rastreabilidade do ciclo de vida. Ter os templates disponveis no Sharepoint muito vantajoso. R10: Ainda no notei muitas diferenas. Talvez seja pelos projectos em que estou envolvida. R11: Formalismo e maior compromisso. Necessidade de actas aumenta o formalismo e a gesto das vrias equipas envolvidas no projecto.
133
Anexo I
R12: No piorou nada excepo do nmero de documentos a produzir. preciso tempo ao nvel da educao das pessoas e da interiorizao e aceitao do processo. R13: Manteve-se igual. A diferena passa por darmos nomes diferentes aos documentos do que j dvamos. Vantagem estar no SharePoint e toda a gente acede. R14a: Concordo Totalmente. R14b: Concordo Totalmente. R14c: Concordo. R14d: Concordo Totalmente. R14e: Concordo Totalmente. R14f: ptimo suporte. Nada a apontar, esto sempre disponveis quando coloco dvidas. R14g: Incluso do director da rea nos sites criados. Os diagramas de contexto na proposta de soluo de arquitectura no tem nada a ver com o do documento de especificao de requisitos do utilizador. O Sponsor no entende e faz-se trabalho a dobrar. Viso de ambas as reas deveria ser aproximada. O Comit de Arquitectura no deveria trabalhar separadamente da ESI. Objectivo bom mas deveria ser mais uniforme e coerente.
134
Anexo I

R1: Usvamos standards que j estavam definidos na equipa. Definio de requisitos usvamos template que j havia definido pelo Departamento da Organizao. No usvamos standards para os testes. R2: No utilizvamos qualquer tipo de modelo. R3: Fazamos a anlise de requisitos e devolvamos ao Sponsor se estivessem incompletos. Depois passvamos para o oramento, anlise,... Seguamos um processo parecido com o do CMMI. R4: Definio do mbito. Gesto de verses de software. Acompanhamento/execuo dos testes de aceitao, porque o Sponsor diz que faz e no chega a fazer, no conhece detalhadamente o que quer nem o mbito, etc. R5: Menos tempo para documentao e um desenvolvimento mais rpido. J fazamos muitos testes integrados. R6: Nunca tive problemas. Fazamos reunio para saberemos o que estava dentro do mbito. O controlo era feito via telefone. Nunca tive projectos com muitas equipas ao mesmo tempo. R7: Definio do mbito e dos requisitos. Definio de uma metodologia geral para todos seguirem. R8: Elaborao dos vrios documentos e o esforo adicional que isso teve. Os projectos mais longos e mais caros tero de ser justificados ao Sponsor e eles nem sempre sentem a necessidade desses aumentos. R9: So muito teis. Permitem ter um repositrio de documentao geral atravs do Sharepoint e o Robohelp tem as regras, etc. e acessvel a quem tem dvidas e precisa de consultar. R10: Fazer mais documentao. Estruturar mais a equipa, uma parte a fazer gesto de requisitos e outra a fazer as restantes fases. R11: Grande problema de gesto de requisitos e com o fecho do mbito fica mais fcil fechar a anlise dos requisitos. Conjunto de ferramentas que ajudam a gerir. R12: A pior coisa o facto de termos de fazer muita documentao e muito difcil justificar esse esforo adicional ao Sponsor.
135
Anexo I
R13: Manteve-se como era dantes. R14a: Concordo Totalmente. R14b: Concordo. R14c: Concordo. R14d: Concordo Totalmente. R14e: Concordo Totalmente. R14f: Excelente. No tem nada a apontar. R14g: Apresentao/Workshop da ESI para os Sponsors. Os Sponsors deviam j conhecer a metodologia e conhecer as diversas fases. So as equipas no momento de desenvolvimento dos projectos que tm de apresentar e explicar-lhes a metodologia. A maior parte das vezes no necessrio o documento de especificao de requisitos de softwaree sendo obrigatrio deveria surgir antes do oramento.
136
Anexo I

R1: No usava. O que se fazia na rea era algo ad-hoc. R2: No utilizvamos qualquer tipo de modelo. R3: Processo era o normal. Fazamos uma reunio com o Sponsor para perceber os requisitos. Dependendo da complexidade fazia-se um projecto de estudo tcnico de viabilidade, o qual era pedido a aprovao por parte do Sponsor. Depois fazia-se oramento e implementao. No final do projecto produzia-se a documentao de anlise tcnica (o que tinha sido feito, o que tinha sido alterado, etc.). Se o projecto fosse grande havia reunies mas no havia o registo das mesmas. R4: Garantia do que se fazia era exactamente o que o Sponsor pretendia. independente do CMMI. R5: O CMMI vai trazer mais carga administrativa. Para aplicar em projectos grandes e quando a pessoa apenas est dedicada somente gesto do projecto e no a muitos ao mesmo tempo. R6: Sempre tive uma boa comunicao. Sincronizar os milestones e planeamentos das outras equipas era em reunies de kick-off ou de gesto do projecto. As pessoas acabam por no ler os documentos dada a sua extenso e o seu nmero elevado. R7: O CMMI tem a vantagem de todos os projectos terem o mesmo tipo de documentao, seja qual for o projecto. As pessoas podero assim ler a documentao e verificar o que se mudou na aplicao. Em termos tericos interessante mas no vejo as pessoas a implementar novas funcionalidades e irem ler toda a documentao referente aplicao em que esto a trabalhar. Analisam o impacto e passam directamente para a implementao. R8: Ter noo clara da sequncia de passos a seguir em cada fase. Carga adicional que traz para a implementao dos projectos, que so muitos simultaneamente e no conseguimos realizar assim todos os projectos nem aumentar o nmero de recursos. R9: Sharepoint serve para ter carregado toda a documentao dos projectos e de consulta para quem necessitar. Robohelp um guia para se perceber e orientar os passos da metodologia.
137
Anexo I
R10: A metodologia implica gastar mais tempo na fase de anlise. Nos projectos antigos fazamos uma pequena anlise e partamos logo para o desenvolvimento. Dedicamos mais tempo no a programar mas sim a produzir toda a documentao. R11: A lgica seria melhorar o entendimento das equipas com o Sponsor. Neste momento no consigo comprovar isso. Ao obrigar o Sponsor a aceitar diminui o nmero de mudanas na fase de testes. R12: O CMMI uma coisa boa se se gerir apenas 2 ou 3 projectos. Muitos projectos s veio trazer mais dificuldades e mais carga. No se consegue monitorizar as actividades. A ESI quer ter a certificao mas ao mais alto nvel no tem fora para definir e institucionalizar isso com o Banco. Deveria haver um ajuste da fasquia que foi definida para atribuio de projectos de desenvolvimento. Antes o dilogo com o Sponsor no era atravs de reunies e actas mas sim atravs de mails e telefone e sempre correu tudo bem. H trabalho e deslocaes por parte do Sponsor que so desnecessrias. R13: No noto diferenas porque o processo que se utilizava continua-se a utilizar. Fazemos uma reunio onde se discute a soluo e cada equipa passa a sua parte da soluo para o documento de especificao de requisitos do utilizador. R14a: Concordo. R14b: Concordo. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Concordo. R14f: Tem dado todo o apoio necessrio. Nunca ficmos com tarefas pendentes por atraso de algo da rea PQSI. R14g: Aumentar fasquia das horas para determinar se um projecto de desenvolvimento ou de manuteno evolutiva. Implementar esta metodologia apenas para projectos de maior dimenso ou que tenham muitas equipas envolvidas.
138
Anexo I

R1: Utilizava standards definidos para a equipa. Continuo a utilizar os mesmos. Apenas fiz 2 fichas de anlise de requisitos. Somos uma equipa de actividades transversais. O trabalho da rea est focado para transaces. Estamos tentar implementar casos-de-uso na documentao. R2: No utilizvamos qualquer tipo de modelo. R3: Os pedidos chegam equipa via ferramenta Remedy. As outras equipas tm de anexar um template definido para a equipa. Enviam tickets via Remedy. Fazem o oramento, planeamento e quando chega o ticket, mediante as pessoas livres, lhes atribuda a tarefa. R4: Se cabea conseguisse especificar as necessidades, a probabilidade de ao fazer os testes de aceitao encontrar erros ser muito menor. R5: No tenho grande experincia de trabalho com o CMMI. Antes j exigiam a especificao detalhada do que as equipas precisavam e pedamos aprovao a essas equipas. J tnhamos algo parecido com o CMMI mas sem templates. R6: No vejo muita diferena. S houve uma vez que todas as semanas tinhamos de fazer um status report. Antigamente trocava-se mails e existia boa comunicao com as diferentes equipas R7: No registei ainda nenhuma melhoria mas penso que vamos ganhar nos testes porque vo haver muito menos alteraes. R8: Como s fiz 2 fichas de anlise de requisitos ainda no tive dificuldades de implementao do que foi definido. Tive alguma dificuldade de preencher os Casosde-Uso ao adapt-los para a sua folha template. R9: Apenas tenho 2 projectos no Sharepoint e por vezes tenho de seleccionar vrias opes para chegar ao stio que pretende mas entendo que o site um bom stio para todas a gente consultar os documentos. Robohelp muito importante para ajuda. R10: Manteve-se igual. A nica diferena foi tentar aplicar as coisas que so pedidas nos templates que j usava como os testes e a especificao de pedidos. R11: No tenho experincia prtica.
139
Anexo I
R12: No tenho experincia prtica. R13: Manteve-se igual. R14a: Concordo. R14b: Concordo Totalmente. R14c: Concordo. R14d: Concordo. R14e: Discordo. R14f: Excelente. Sempre que precisei foi dado apoio e aceitaram j algumas opinies. R14g: Exemplos mais virados para a realidade, para as pessoas se poderem basear neles e no terem tantas dvidas e fazer tantas perguntas.
140
Anexo I

R1: Enquanto trabalhei em reas do gnero ferramenta COBOL no utilizava. S mesmo no projecto Euclide que utilizava os da ferramenta. R2: No utilizvamos qualquer tipo de modelo. R3: Era o mesmo, o ciclo normal de um projecto, mas no apoiado em nenhuma metodologia. Fazamos reunies em projectos de maior dimenso. R4: Ps-produo. Manuteno das aplicaes. Toda a documentao de anlise, requisitos ficavam em mails e era muito difcil porque determinada funcionalidade estava presente num dos mails e no aparecia em produo, ou seja, no havia registo e controlo das funcionalidades e das especificidades a implementar. R5: Rapidez de incio dos projectos e era um processo muito mais light porque havia muito menos burocracia e documentao. R6: O Microsoft Project servia para o controlo. A comunicao era via mail, no estava to estruturada e standard como agora. Quando surgiam problemas de resoluo urgente havia o hbito de telefonar directamente pessoa responsvel pela resoluo para implementar essa mudana de uma maneira mais rpida. No geral a comunicao era boa. R7: Standard de processos, que era algo que sentia falta e que at cheguei a falar com a direco por causa da desestruturao de tempo e de documentao. Uma pessoa pode no conhecer o processo de negcio de outra equipa mas rapidamente poder aceder documentao e tomar conhecimento desses aspectos de negcio. R8: Processo demasiado abrangente para um espao de tempo to curto. Gerir um projecto de mdia ou grande dimenso necessrio ter um Gestor de Projecto dedicado exclusivamente s tarefas de gesto. Difcil conciliar grandes projectos com outros mais pequenos. O tempo muito pouco. R9: Ainda no as utilizei. Forma standard como a informao guardada e possibilitar saber concretamente onde procurar e o que procurar. R10: Deleguei tarefas que tinha antes porque o CMMI muito extenso e em projectos pequenos consome muito tempo. Os processos tpicos de desenvolvimento comeam muito precocemente no ciclo de vida do projecto. Seria preciso sistematizar muito mais as actividades.
141
Anexo I
R11: A documentao dos projectos. O custo de manuteno dos projectos ser reduzido. Algum grau de independncia dos projectos, j que se consegue substituir algum de forma mais rpida, no sendo por isso a ausncia to notada. R12: Tempo que os projectos levam a ser concludos. R13: Comunicao tornou as coisas mais preto no branco. As pessoas sabem exactamente o que fazer. Deixamos de fazer as coisas porque o amigo a pedir, etc., ou seja, as tarefas a partir de agora so as que foram definidas, so as que foram concordadas pelas equipas. R14a: Concordo. R14b: Concordo. R14c: Concordo Totalmente. R14d: Concordo Totalmente. R14e: Concordo. R14f: Opinio muito boa. Vieram colmatar a necessidade da rea de metodologia de gesto de projectos e com uma muito boa prestao. R14g: H projectos e projectos, alguns no se adequam com o CMMI. Os clientes do Banco querem algo numa data especfica e muitas vezes muito apertadas e o Banco para no perder esses clientes concorda com essas datas e esquece todo protocolo que os projectos devem seguir, havendo um atropelo de fases. O CMMI deveria ser adaptado s caractersticas de determinados projectos, alm dos mais pequenos. O CMMI poderia permitir uma gesto de projectos em cascata, ou seja, medida que as coisas iam acontecendo partia-se para as diversas fases. Adaptar o CMMI realidade da empresa, j que ele est muito terico e metodolgico.
142
Anexo I

R1: Havia standards que fiz e standards existentes j nas equipas. No tinha para especificao de requisitos e de anlise funcional. R2: No utilizvamos qualquer tipo de modelo. Apenas utilizei uma metodologia de gesto de projectos. R3: Havia reunio se fosse preciso discutir os requisitos com o Sponsor nos projectos mais complexos. Havia sempre uma reunio de kick-off, nem que fosse via telefone. Fazamos oramento, planeamento, etc. como o CMMI. R4: Alterao dos requisitos pelo Sponsor. Como se faziam oramentos sem se ter qualquer anlise do assunto, tal levava a grandes desvios. R5: Os projectos grandes passaram a custar o dobro. Menos flexibilidade e menos rapidez. R6: Relao igual actual. Boa comunicao com as diferentes equipas, via telefone e via mail. Algumas reunies com as equipas nos projectos mais importantes. R7: Maior controle do utilizador tanto na definio como alterao de requisitos. Mais cuidado na anlise e processo dos testes. R8: No h tempo til para implementar o CMMI. Mantendo as mesmas exigncias e mais estas novas tive de comear a delegar tarefas. O incio do projecto atrasa-se devido s actividades de oramentao. R9: Sharepoint til em termos de organizao. Robohelp no est muito actualizado, no tem um guia. Utilizo um PowerPoint para me orientar. Os grandes entregveis no esto evidenciados na ferramenta. R10: Registos documentais. No havia uma organizao da documentao. Reunies cclicas. R11: No meu trabalho no melhorou. No ponto de vista da gesto h mais organizao e controle. R12: Como tive de delegar tarefas perdi um pouco a viso total do projecto. No consigo acompanhar tudo e ter o controle de tudo. H mais sobrecarga de trabalho.
143
Anexo I
R13: Igual, excepo da necessidade de criao de mais actas. R14a: Discordo. R14b: Concordo Totalmente. R14c: Concordo. R14d: Discordo. R14e: Discordo Totalmente. R14f: Bom suporte, sempre que necessito recebo resposta s dvidas mais cedo ou mais tarde. R14g: O problema a falta de tempo. Ter um guia mais simples do que necessrio fazer. O Robohelp est demasiado detalhado para esta fase inicial.
144
Anexo I

R1: Usava uma folha de estimativas e documentao tcnica. No tnhamos standards de requisitos, era o que o utilizador utilizava. Utilizvamos standards do ncleo. Matriz de testes de aceitao. R2: S utilizvamos o MS Project e o Artemis. Tivemos uma rea de planeamento que utilizvamos o PMI Book. R3: Havia 1 oramento, planeamento e normalmente havia 1 reunio de kick-off do projecto com o Sponsor no inicio dos testes de aceitao. Consoante a dimenso do projecto tnhamos reunies peridicas. Na rede j tinhamos uma pasta por cada projecto. R4: Falta normalizao de documentao entre equipas. Normalmente no conseguia rever o que tinha sido especificado pelas outras equipas porque no havia uma linguagem idntica para todos e por vezes uma equipa pensava numa coisa e a outra equipa implementava outra. Divergncia nos objectivos. R5: No tnhamos tanta documentao, o que atrasa a rapidez de desenvolvimento dos projectos. R6: Com as reas transversais as coisas j esto normalizadas e tm normas e templates j definidos o que facilita a comunicao com elas. Entre equipas de desenvolvimento havia por vezes atrasos o que penalizavam o rendimento dos outros. No havia um processo de comunicao institudo. R7: Normalizao da documentao. R8: Falta de sensibilizao do Sponsor para o CMMI e falta de conhecimento dos mesmos sobre os processos implementados. Em termos internos h falta de analistas funcionais para fazer o documento de especificao dos requisitos do utilizador, etc. R9: Muito teis. Os Guias de Preenchimento so bastante teis. A formao bastante til. Sharepoint tambm muito til. R10: Bastantes. Sobretudo a fase de oramentao ser no final do documento de especificao dos requisitos do utilizador e nele j est presente um pouco de anlise o que positivo porque possvel oramentar um valor mais prximo do real. Antes j me defendia de surpresas com a criao de projectos de estudo tcnico de viabilidade. R11: Forma de trabalhar estruturada e nica para todas as equipas.
145
Anexo I
R12: Quantidade de entregveis e documentao a produzir. R13: Melhorou a comunicao. J h um processo definido de comunicao. R14a: Concordo Totalmente. R14b: Concordo Totalmente. R14c: Concordo Totalmente. R14d: Concordo. R14e: Concordo. R14f: Bom suporte. R14g: Normalizao de documento de especificao dos requisitos de negcio e a sensibilizao do Sponsor para esse documento e para todo o processo.
146
Anexo I

R1: Usava standards elaborados por ns na rea. Fazamos sempre documentao de anlise funcional e tcnica. Oramento era com base na experincia que tinha e nas notas que tirava aquando da leitura dos requisitos vindos do Sponsor. Os casos de teste eram especificados numa folha excel em projectos maiores. Documento de passagem a produo com todos os passos que tinham de seguir. R2: No utilizava qualquer tipo de modelo. R3: Fazia os planeamentos dos projectos. Reunio de acompanhamento com o Sponsor de 15 em 15 dias. H cerca de 1 ano temos tido reunio de situao de portflio. Comevamos sempre com um projecto aps o fecho de mbito e enviavamos por mail ao Sponsor para aprovao. Se houvesse no-conformidades eram nas reunies quinzenais que se discutiam. R4: Muitas vezes no se testavam com exausto as funcionalidades que passavam para produo e no acho que o CMMI vai resolver (mas vai ajudar). R5: No demorvamos tanto tempo a fazer a documentao. Fazia j a documentao mas agora preciso tempo de integrao das pessoas. Antes j escrevamos tudo mas num formato mais simples. R6: Era difcil a articulao com outras equipas, agora melhorou. Temos de estar dependentes do calendrio das outras equipas. Boa comunicao com as equipas e os projectos corriam normalmente bem. R7: Utilizao do Sharepoint que veio permitir que todos possam consultar toda a documentao referente ao projecto. documento de especificao dos requisitos do utilizador e documento de especificao dos requisitos de software comum para os projectos muito importante porque at o Sponsor v o projecto como um todo. Projectos de maior dimenso, a atribuio de responsabilidades muito importante. R8: Relutncia das pessoas para adoptar o processo de documentao. exaustivo, obriga a escrever muito. Na rea as pessoas no gostam de escrever, so mais tcnicos. R9: Muito teis. Ajudam bastante. Faz falta um quadro por tipo de projecto que diga o que necessrio. Criar uma tabela por fases e tipo de projecto menos exaustiva que a existente R10: Passei a documentar mais, em termos de oramento j feito baseado atravs de estimativas.
147
Anexo I
R11: At este momento no notei grandes melhorias. R12: No acho que tenha piorado nada. R13: Comunicao melhorou bastante. No controle manteve-se como era dantes. R14a: Concordo. R14b: Concordo. R14c: Concordo. R14d: Concordo Totalmente. R14e: Concordo. R14f: Excelente. Fazem um trabalho muito bom. R14g: Integrar melhor o CMMI com o tipo de projecto que tm de fazer e nos chegam pelo ARTEMIS. Fazer a ligao dessa informao com o CMMI. O que se tem de fazer num formato geral para cada tipo de projecto. Formato da documentao (formato dos casos-de-uso, etc.) menos pesado que o actualmente. Aces de formao em Portugus. Assuntos novos ouvidos por uma lngua estrangeira mais difcil de incorporar.
148
Anexo I
INQURITO AOS GESTORES DE PROJECTO Data: Nome: 22 / 04 / 08 Gestor Projecto 20 E-mail:

R1: Standards para a definio de requisitos e para a anlise funcional. A nvel da oramentao tinha uma folha excel. A nvel dos testes tambm j havia alguma documentao (bateria de testes). Os standards eram definidos para a equipa. R2: No utilizava qualquer tipo de modelo de acompanhamento. R3: No como nvel de detalhe do CMMI mas j seguia um ciclo de vida parecido. Recebamos o documento de requisitos do Sponsor e se fosse necessrio retiravamse algumas dvidas que surgissem. Quando os requisitos eram escassos, recorriase criao de um projecto de estudo tcnico de viabilidade para a anlise mais detalhada dos requisitos para se ter uma noo mais prxima e fiel do oramento. Se fosse um projecto maior havia reunio de kick-off. Se fosse necessrio fazer 1 caderno de requisitos, tal documentao era feita com o acompanhamento do cliente. Havia reunies de ponto de situao com o Sponsor mas no se produziam as actas. R4: Problemas com os requisitos, que ainda hoje temos, h um grande esforo inicial para percebermos os mesmos porque os pedidos do Sponsor so normalmente muito escassos. Relao com o prprio Sponsor, requisitam muitas alteraes a meio do ciclo de vida do projecto. Em termos internos, quando os projectos eram grandes havia problemas de coordenao e processo de desenvolvimento com as outras equipas. Quanto maior o nmero de equipas envolvidas mais difcil era de gerir. R5: A pedidos pequenos conseguia-se dar uma maior resposta e ter uma capacidade de desenvolvimento muito mais rpida. O CMMI obriga a um formalismo demasiado grande para projectos de pequenas dimenses. Apesar de gastar mais tempo, agora temos tudo bem estruturado e formalizado, o que poder ser uma grande ajuda para o futuro porque se tem uma base de como as coisas se devem fazer e de relao com determinado Sponsor. R6: Havia alguma dificuldade em controlar as diversas equipas envolvidas. Quantas mais equipas tinha de acompanhar pior. A prpria gesto dos requisitos e alterao dos mesmos era difcil de acompanhar e de controlar. Gastava-se muito mais tempo para verificaes, etc. Com o CMMI todos so obrigados a recorrer a um conjunto de standards o que torna mais fcil de gerir todo o projecto. R7: Normalizao da documentao. Todos tm as mesmas regras e todos seguem a mesma base. Permite a mdio prazo ter ganhos (qualitativos, produtivos e menos tempo de desenvolvimento) nos projectos. Qualidade dos entregveis atravs da organizao e estruturao desde que toda a gente siga as regras e standards.
149
Anexo I
R8: Mudana muito grande apesar de j antes utilizar documentao. um passo muito grande e isso demora algum tempo a incorporar. O documento de especificao dos requisitos do utilizador est muito detalhado para um documento que pretende ser funcional. Adaptao a uma nova metodologia leva tempo a incorporar. R9: Muito importante ter um histrico dos projectos e centralizao de toda a documentao. Como so ferramentas genricas d para ter uma viso da empresa, o que as outras reas tm pendentes, etc. R10: Como j fazamos documentao passmos a ajustar-nos a uma nova metodologia. Forma de abordagem aos pedidos de forma diferente. O modo de trabalho praticamente o mesmo. R11: Permite ter a informao disponvel. Ter um mtodo de trabalho bem definido. D maior visibilidade dos projectos. Atravs da metodologia obriga a ter um conjunto de processos a definir. Os utilizadores e outras fontes externas conseguem ter uma maior visibilidade do projecto. R12: H uma certa desresponsabilizao da parte do Sponsor. Como as equipas fazem tudo, os Sponsors desleixam-se nas suas actividades. As tarefas administrativas e documentais so muito pesadas. Menos tempo para fazer gesto propriamente dita. Tendo pessoas mais funcionais na equipa permite ter uma ajuda na gesto. R13: At agora no tive muitos projectos com equipas envolvidas. Atravs de um mtodo vai facilitar o controlo e comunicao. Vai obrigar que todas as equipas se responsabilizem e saber sobre o que se responsabilizam. H registo das responsabilidades e isso ajuda na gesto. Vai levar algum tempo at que todas as pessoas faam as coisas de acordo com a metodologia. R14a: Concordo. R14b: Concordo. R14c: Concordo. R14d: Concordo. R14e: Concordo. R14f: Ainda no requisitei muito suporte mas o que requisitei no tenho razes algumas de queixa. R14g: Acompanhamento junto das equipas que tivessem mais projectos para verificar se a realizao de certos documentos realmente indispensvel ou se se poderia minimizar a sua extenso ou mesmo encontrar uma maneira de se automatizar esse processo de criao documental.
150
Anexo I

R1: No utilizava standards. Apenas havia um documento de anlise tcnica e de oramento. R2: No utilizava qualquer tipo de modelo de acompanhamento. R3: Oramento e Planeamento das aplicaes no Artemis. Quando as propostas de soluo de arquitectura eram aprovadas iniciavam-se os projectos. Reunies de Kick-off e reunies com o Sponsor s em projectos de grande dimenso. R4: Falta de esquematizao dos requisitos e no fazamos baterias de testes. R5: Burocracia e termos de cumprir com as diversas normas e metas do CMMI levando a que os projectos sejam muito mais custosos e demorados. R6: Boa comunicao, nunca tive problemas com isso. Atravs de mails, telefone e reunies de acompanhamento. R7: Normalizao dos processos e dos documentos. Obrigatoriedade de seguirem um processo, algo que no era feito porque no havia regras, impossibilitando o registo de alteraes, etc. R8: Ainda no tenho grande experincia de actividades CMMI. Apenas fiz um documento de especificao dos requisitos do utilizador. A folha de estimativas muito complicada e dificulta a gesto. R9: Ainda no utilizei. R10: As coisas esto mais organizadas e estruturadas, os passos bem definidos e especificados na vida do projecto. R11: Melhorou mais nos projectos que na prpria gesto. Melhora a relao com o utilizador, com a definio certa do que se deve fazer. R12: Mais demorados e muito mais caros. Folha de estimativas complica a gesto. R13: Ainda no fiz um projecto com outras equipas. R14a: Concordo.
151
Anexo I
R14b: Concordo. R14c: Concordo. R14d: Concordo. R14e: Concordo. R14f: Ainda no precisei muito de suporte. O que precisei at agora sempre tiveram disponibilidade. R14g: Deveriam ser definidos os documentos de anlise tcnica para toda a organizao. Era interessante haver mtricas que pudessem dar a indicao de quanto tempo se demora a fazer determinada coisa.
152
Anexo I

R1: Utilizava principalmente standards na parte dos testes onde tinhamos um template criado por mim equivalente aos testes de sistema. No havia nada definido para anlise funcional nem para requisitos. O caderno de requisitos era o que o Sponsor fizesse. Quanto maior era o pedido mais prximo tinham de um caderno de requisitos como hoje temos. O que existia normalmente era algo parecido com o documento de especificao dos requisitos de negcio que actualmente existe. Quando o projecto era crtico fazamos uma anlise mais detalhada. R2: No utilizava qualquer tipo de modelo de acompanhamento. R3: Parecido com o CMMI. Recebamos o documento de especificao dos requisitos de negcio, analisvamos e complementvamos, no se fazia grande anlise funcional, mas fazia-se uma extensa anlise tcnica. Fazamos depois a implementao e os testes. As reunies de arranque acabavam por coincidir com as reunies de ponto de situao. Actas de reunio apenas eram feitas com os fornecedores, porque com eles existia um outro tipo de formalismo e outro nvel de preocupao. R4: Falta de testes. O tempo reservado para os testes era consumido com o desenvolvimento e por isso no se faziam todos os testes necessrios. R5: Passagem a produo e controlo funcionavam bem. No se fazia documentao por isso era mais rpido. Na rea sempre houve testes unitrios, integrados e de sistema. Agora perde-se mais tempo na execuo e validao de documentao. Gastamos mais horas e tempo para desenvolver. R6: No tenho essa experincia de trabalho com outras equipas. R7: Ter um caderno de requisitos bem definido e estruturado. Ter o compromisso das partes envolvidas, no ficar as coisas dbias do tipo no sabia que era isso que iam fazer. Parte dos testes e validao, havia uma tendncia muito grande para no se fazerem. R8: Relao custo/benefcio do documento de planeamento do projecto muito baixa. Apenas 25% do documento til. Grande demais e tem demasiada informao. positivo ter l descrito as responsabilidades. Por vezes no sei se os documentos necessitam de ser revistos/inspeccionados/aprovados. Envolvimento dos Sponsors foi quase nulo. Eles no perceberam o que as equipas tero agora de fazer e o que eles prprios tm de fazer. No percebem tambm o porqu do aumento em termos oramentais e de tempo.
153
Anexo I
R9: ptimas. Como ainda no interiorizei tudo acedo a essas ferramentas diariamente. muito importante para uma mudana deste calibre ter esse apoio. At agora tenho encontrado sempre o que procurava. R10: No penso que tenha havido muitas mudanas. Temos um caderno de requisitos aprovado e fases encadeadas. ramos um pouco mais permissivos e agora a metodologia no nos deixa ser. Temos de fazer actas das reunies. R11: Tenho pouca experincia na execuo de processos/actividades CMMI e o tempo que tive a trabalhar na empresa antes do CMMI foi muito pouco para poder ter uma opinio fundamentada. R12: Tenho pouca experincia na execuo de processos/actividades CMMI e o tempo que tive a trabalhar na empresa antes do CMMI foi muito pouco para poder ter uma opinio fundamentada. R13: Tenho pouca experincia na execuo de processos/actividades CMMI e o tempo que tive a trabalhar na empresa antes do CMMI foi muito pouco para poder ter uma opinio fundamentada. R14a: Concordo Totalmente. R14b: Concordo Totalmente. R14c: Discordo. R14d: Concordo. R14e: Discordo. R14f: Bom suporte. A parte da formao dos testes no foi muito boa, foi dada a correr e em espanhol. O suporte s dvidas tem sido muito bom. R14g: Os Sponsors deveriam estar mais envolvidos, deveria-lhes ter sido dada mais informao. Costumam dizer que isso um problema vosso, quando se referem a tarefas de CMMI. Alguma informao presente no documento de planeamento do projecto poderia estar presente nos sites em vez de estar constantemente presente nos documentos.
154

MSC Metliberato

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MSC Metliberato

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE DE TRS-OS-MONTES E ALTO DOURO

Implementao do Modelo CMMI na Esprito Santo Informtica

DISSERTAO DE MESTRADO EM INFORMTICA

MARCO EMANUEL TEIXEIRA LIBERATO

Vila Real, 2008

Universidade de Trs-os-Montes e Alto Douro

Implementao do Modelo CMMI na Esprito Santo Informtica

Dissertao do curso de Mestrado em Informtica de Marco Emanuel Teixeira Liberato

Vila Real, Junho de 2008

"Vale mais fazer e arrepender-se, que no fazer e arrepender-se." Maquiavel

Captulo 2 Modelo CMMI

CMMI for Systems Engineering/Software Engineering (CMMI-SE/SW, V1.1)

2.1.1. Modelos de Maturidade

Captulo 2 Modelo CMMI

Tabela 1 - Modelos de Maturidade

Fonte: [PMFORUM, 2008]

2.1.2. Necessidades de Criao de Modelos de Maturidade

Figura 1 - Report do Chaos

Fonte: [Standish 2004]

Representao do Modelo CMMI

Fonte: [SEI 2007]

Componentes do Modelo CMMI

Captulo 2 Modelo CMMI

Figura 2 - Componentes do Modelo CMMI

Fonte: [SEI 2007]

Captulo 2 Modelo CMMI

Figura 3 - Nveis de Maturidade do Modelo CMMI

Fonte: [eProject 2004]

Figura 4 - reas de Processo da Representao Faseada

Fonte: [SEI 2007]

Captulo 2 Modelo CMMI

Figura 5 - Categorias das reas de Processo

Fonte: [Jones e Soule 2002]

Captulo 2 Modelo CMMI

Figura 6 - reas de Processo Bsicas da Gesto de Processos

Fonte: [SEI 2007]

Captulo 2 Modelo CMMI

Figura 7 - reas de Processo Avanadas da Gesto de Processos

Figura 8 - reas de Processo Bsicas da Gesto de Projectos

Fonte: [SEI 2007] 26

Captulo 2 Modelo CMMI

Captulo 2 Modelo CMMI

Figura 9 - reas de Processo Avanadas da Gesto de Projectos

Fonte: [SEI 2007]

Captulo 2 Modelo CMMI

Figura 10 - reas de Processo da Engenharia

Captulo 2 Modelo CMMI

Captulo 2 Modelo CMMI

Figura 12 - reas de Processo Bsicas de Suporte

Fonte: [SEI 2007]

Figura 13 - reas de Processo Avanadas de Suporte

Fonte: [SEI 2007]

Captulo 2 Modelo CMMI

Benefcios na Implementao do CMMI

Captulo 2 Modelo CMMI Saber a posio onde se est

Posicionar-se como uma organizao de boas-prticas

Captulo 2 Modelo CMMI

Problemas e Limitaes do CMMI

Tabela 3 - Adopo do CMMI (Internacional)

Tabela 4 - Adopo do CMMI (Nacional)

Fonte: [SEI 2007]

Tabela 5 - N de Certificaes CMMI por Pas

Fonte: [SEI 2007]