Uma proposta de boas práticas do processo de comunicação para projetos de desenvolvimento distribuído de software

Texto

(1)Uma Proposta de Boas Práticas do Processo de Comunicação para Projetos de Desenvolvimento Distribuído de Software. !. Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. RECIFE, DEZEMBRO/2008.

(2) !. "#. $. "#. Ivaldir Honório de Farias Junior. “Uma Proposta de Boas Práticas do Processo de Comunicação para Projetos de Desenvolvimento Distribuído de Software". Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre Profissional em Ciência da Computação.. ORIENTADOR(A): Prof. Dr.. Edson Costa de B. Carvalho Filho. RECIFE,DEZEMBRO/2008.

(3) Farias Junior, Ivaldir Honório de Uma proposta de boas práticas do processo de comunicação para projetos de desenvolvimento distribuído de software / Ivaldir Honório de Farias Junior. – Recife: O Autor, 2008. xv, 90 folhas: il., fig., tab. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2008. Inclui bibliografia e apêndice. 1. Engenharia de software. 2. Gerenciamento de projetos. l. Título. 005.1. CDD (22. ed.). MEI2009- 107.

(4)

(5) Aos meus pais, meus irm˜ aos e minha noiva, por sempre acreditarem e me incentivarem no alcance dos meus objetivos..

(6) AGRADECIMENTOS A Deus que sempre esteve ao meu lado e que apesar de tudo nunca me deixou desistir e sempre me proporcionou as melhores alternativas para a conclusão deste trabalho. ` minha fam´ılia, por tudo o que eles me proporcionaram até aqui e por tudo o que A representam na minha vida. A todos os colaboradores do Softex Recife e em especial a Eduardo Paiva e Ermeson Carneiro. Ao meu Orientado Edson Carvalho e a minha Co-orientadora Carina Frota Alves, que aceitou o desafio de me ajudar nesta caminhada, agrade¸co também pela sua forma u ńica de conduzir seus orientandos, de conduzir o trabalho e pela paciência de manter sempre o objetivo de forma a buscá-lo da melhor maneira poss´ıvel. Aos avaliadores Alex Sandro Gomes e Cristine Gusm˜ ao que se dispuseram a avaliar esta disserta¸caõ. Aos professores Katyusco de Farias do CEFET-PE e Tiago Alessandro da UFRPE pela confian¸ca e apoio durante esses 2 anos. A todos os entrevistados, pelo tempo dispensado e pela rica contribui¸caõ. Aos meus colegas de mestrado, pelas discussões, trabalhos e, pela grande amizade. A todos os professores e funcionários do Centro de Informática pelo apoio durante o mestrado e que contribu´ıram para que eu adquirisse o conhecimento necessário e, acima de tudo, para me qualificar na busca de novos conhecimentos como um profissional competente e ciente do meu compromisso.. vii.

(7) Aprender ´ e a ´ unica coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende. —LEONARDO DA VINCE.

(8) RESUMO Atualmente, podemos perceber que o n´ umero de empresas que estão aderindo ao Desenvolvimento Distribu´ıdo de Software(DDS) é bem mais significativo quando comparado há alguns anos atrás. As empresas visam ganhos de qualidade, produtividade e diminui¸caõ de custos. Por tais motivos, o DDS vem despertando um grande interesse de pesquisadores nos u ´ltimos anos. A distribui¸caõ das equipes de desenvolvimento de software tem criado diversos desafios ao processo de desenvolvimento de software e a gestão dos seus projetos. Dentre os desafios, o processo de comunica¸caõ destaca-se, como sendo uma das atividades de grande importância entre os membros da equipe. Essa atividade vem sofrendo impactos adversos, dentre eles: distância f´ısica, diferen¸cas culturais, fuso-horário, limita¸cões dos meios de comunica¸caõ dispon´ıveis e outros. Diversos trabalhos tem enfatizado que a falta de comunica¸caõ compromete diretamente o sucesso de projetos, sejam centralizados ou distribu´ıdos. Diante deste contexto, o presente estudo apresenta resultados obtidos a partir de uma pesquisa emp´ırica. O método de pesquisa utilizado foi o paradigma qualitativo que envolveu entrevistas com analistas de projetos distintos e sua grande maioria com equipes distribu´ıdas de forma global. Inserido nesse contexto, esta disserta¸cão propõe boas práticas para o processo de comunica¸caõ no desenvolvimento distribu´ıdo de software. Essa proposta visa contribuir, no sentido de preencher essa lacuna existente na área de DDS, especificamente no que se refere ao processo de comunica¸caõ. Palavras-chave: Desenvolvimento Distribu´ıdo de Software, Processo de comunica¸cão, Boas práticas. xi.

(9) ABSTRACT Nowadays a growing number of companies are following a distributed software development process. Companies that are adopting this methology envisage gains of productivities, quality and cost reduction. For this reason, the distributed software developmentis gaining attention of many companies. However, this approach is giving rise to several challenges and problems. Among these problems, the communication among development team is considered one of the most difficult to deal with. The communication is considered difficult because of work time in different places around the world, cultural differences, limitations of the ways of communication among others reasons. Several research are emphasizing that weak communication among team members can result in poor results even if a development is centralized. This work presents an empirical study of the communication process of distributed software teams. The study was carried out using a qualitative research approach with different team members working in distributed projects. As a result of this dissertation, we propose several good practices to better support the communication process of distributed software projects. Keywords: Software Distributed Developing, Communication Process, Best Practices. xiii.

(10) ´ SUMARIO. Cap´ıtulo 1—Introdu¸c˜ ao 1.1 1.2 1.3 1.4 1.5. Motiva¸cão . . . . . . . . . . Objetivos . . . . . . . . . . Descri¸caõ do Problema . . . Contribui¸cão . . . . . . . . . Organiza¸caõ da Disserta¸caõ. 1 . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. Cap´ıtulo 2—Modelos de Qualidade 2.1. 2.2 2.3. 2.4. 2.5. 5. ISO/IEC 12207 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Processos Fundamentais . . . . . . . . . . . . . . . . . . . . . 2.1.2 Processos de Apoio . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Processos Organizacionais . . . . . . . . . . . . . . . . . . . . 2.1.4 Visão Geral do Gerenciamento de Comunica¸caõ na ISO 12207 SPICE - ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Visão Geral do Gerenciamento de Comunica¸caõ na ISO 15504 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 N´ıveis de Maturidade . . . . . . . . . . . . . . . . . . . . . . . ´ 2.3.2 Areas de Conhecimento do CMMI . . . . . . . . . . . . . . . . 2.3.3 Visão Geral do Gerenciamento de Comunica¸caõ no CMMI . . MPS.BR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 N´ıveis de maturidade . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Visão Geral do Gerenciamento de Comunica¸caõ no MPS.BR . Considera¸co˜es Finais . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. Cap´ıtulo 3—Desenvolvimento Distribu´ıdo de Software (DDS) 3.1 3.2 3.3 3.4 3.5 3.6 3.7. 1 2 2 3 3. Motiva¸cões para o DDS . . . . . . . . . . . . . . . . . . . . . . . . . . Caracteriza¸caõ do DDS . . . . . . . . . . . . . . . . . . . . . . . . . . Desafios do DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processo de Comunica¸cão . . . . . . . . . . . . . . . . . . . . . . . . Problemas Relacionados a Comunica¸caõ em DDS . . . . . . . . . . . Comparando Processo de Comunica¸caõ Distribu´ıdo com Centralizado Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 Abordagem de Carmel . . . . . . . . . . . . . . . . . . . . . . 3.7.2 MuNDDoS - Prikladnicki e Audy . . . . . . . . . . . . . . . . 3.7.3 Abordagem de Medeiros . . . . . . . . . . . . . . . . . . . . . xv. 5 6 6 8 8 10 14 16 17 18 19 21 23 23 25 27. . . . . . . . . . .. . . . . . . . . . .. 28 31 32 32 35 39 40 41 45 46.

(11) ´ SUMARIO. xvi 3.8 3.9. Comparativo entre os Trabalhos Relacionados . . . . . . . . . . . . . . . Considera¸co˜es Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 4—Metodologia de Pesquisa 4.1 4.2 4.3 4.4 4.5 4.6 4.7. Paradigma Qualitativo . . . . . . . . . . . . . 4.1.1 Compara¸caõ entre Pesquisa Qualitativa Plano de Pesquisa . . . . . . . . . . . . . . . . Instrumento de Coleta de Dados . . . . . . . . Sele¸caõ dos Participantes . . . . . . . . . . . . Coleta de Dados . . . . . . . . . . . . . . . . . Análise de Dados . . . . . . . . . . . . . . . . Considera¸co˜es Finais . . . . . . . . . . . . . .. 49 . e . . . . . .. . . . . . . . . Quantitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. Cap´ıtulo 5—Resultados do Estudo Emp´ırico 5.1 5.2 5.3 5.4. 47 48. Caracter´ısticas dos Participantes . . . . . . . . . . . . . . Análise e Interpreta¸caõ dos Dados das Entrevistas . . . Categorias e fatores associados à comunica¸caõ . . . . . . Considera¸co˜es Finais . . . . . . . . . . . . . . . . . . . .. 49 51 52 54 55 56 57 57 59. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 59 61 63 68. Cap´ıtulo 6—Proposta de Boas Pr´ aticas para Processo de Comunica¸c˜ ao em DDS 69 6.1. 6.2. Descri¸caõ da Práticas . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Abertura do Projeto Distribu´ıdo com Reunião Presencial 6.1.2 Criar Pontos Focais . . . . . . . . . . . . . . . . . . . . . 6.1.3 Manter a Cordealidade . . . . . . . . . . . . . . . . . . . 6.1.4 Documenta¸caõ . . . . . . . . . . . . . . . . . . . . . . . 6.1.5 Defini¸caõ de Vocabulário . . . . . . . . . . . . . . . . . . 6.1.6 Criar Portal Institucional . . . . . . . . . . . . . . . . . . 6.1.7 Defini¸caõ de um Plano de Comunica¸caõ . . . . . . . . . . 6.1.8 Curso de Inglês para Negócios . . . . . . . . . . . . . . . 6.1.9 Ado¸caõ Video-Conferência . . . . . . . . . . . . . . . . . 6.1.10 Reuniões Periódicas . . . . . . . . . . . . . . . . . . . . . 6.1.11 Criar e Alimentar a Base de Informa¸cões Culturais . . . Considera¸co˜es Finais . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. Cap´ıtulo 7—Conclus˜ ao e Trabalhos Futuros 7.1 7.2 7.3. Contribui¸cões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limita¸co˜es do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 8—Apˆ endice A. 69 70 70 72 72 73 74 75 75 76 77 78 79 81 82 83 83 85.

(12) LISTA DE FIGURAS. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8. Processo da ISO 12207 [13] . . . . . . . . . . . . . . . . . . . . . . . N´ıveis de Capacidade da ISO 15504 . . . . . . . . . . . . . . . . . . Melhoria do Processo Organizacional [13] . . . . . . . . . . . . . . . Melhoria da Capacidade Organizacional [13] . . . . . . . . . . . . . Estrutura da Organiza¸cão dos Documentos do Modelo ISO 15504 [1] N´ıveis de Maturidade do CMMI . . . . . . . . . . . . . . . . . . . . Componentes do MPS.BR . . . . . . . . . . . . . . . . . . . . . . . N´ıveis de Maturidade do MPS.BR . . . . . . . . . . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 7 12 12 13 13 17 22 22. Equipe centralizada e distribu´ıda . . . . . . . . . . . . . . . . . . . . . . Principais razões envolvidas no DDS (adaptado [40]) . . . . . . . . . . . Demanda por software em rela¸cão ao n´ umero de microcomputadores e profissionais dispon´ıveis (adaptado de [28]) . . . . . . . . . . . . . . . . . 3.4 Componentes da Comunica¸cão . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Componentes da Comunica¸cão Representado pelo Contexto . . . . . . . . 3.6 For¸cas centr´ıfugas e centr´ıpetas de equipes distribu´ıdas ou globais . . . . 3.7 N´ umero de canais de comunica¸cão em uma equipe [31] . . . . . . . . . . 3.8 Modelo de impacto dos desafios apresentados devido dispersão dos stakeholders (adaptado de [16]) . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Diagrama de influência das categorias em DDS (adaptado de [40]) . . . . 3.10 Compara¸caõ entre os trabalhos relacionados . . . . . . . . . . . . . . . .. 28 29. 4.1 4.2 4.3 4.4. Uma Perspectiva do Processo de Pesquisa Qualitativa . . Plano da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . Etapas da Pesquisa . . . . . . . . . . . . . . . . . . . . . . ´ Arvore de Análise no Software NVivo . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 52 53 55 58. 5.1 5.2 5.3 5.4 5.5 5.6. Visão geral da Certifica¸cão de Modelos de Qualidade ´ Area de Atua¸caõ dos Entrevistados . . . . . . . . . . N´ıvel de Dispersão das Equipes . . . . . . . . . . . . Entrevistados com Certifica¸cão PMP . . . . . . . . . Categorias com impacto na Comunica¸caõ . . . . . . . ´ Estrutura da Arvore no NVivo . . . . . . . . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 60 61 61 62 63 64. 3.1 3.2 3.3. xvii. . . . . . .. . . . . . .. . . . . . .. 30 33 34 41 43 45 46 48.

(13)

(14) LISTA DE TABELAS. 2.1 2.2. Principais Modelos de Qualidade . . . . . . . . . . . . . . . . . . . . . . Dimensões de Processo do ISO 15504 . . . . . . . . . . . . . . . . . . . .. 6 11. 3.1. Principais Desafios do DDS [40] . . . . . . . . . . . . . . . . . . . . . . .. 32. 4.1. Compara¸caõ entre pesquisa qualitativa e quantitativa. . . . . . . . . . . .. 51. 5.1. Caracteriza¸caõ Geral dos Entrevistados . . . . . . . . . . . . . . . . . . .. 59. xix.

(15)

(16) LISTA DE ABREVIATURAS DDS - Desenvolvimento Distribu´ıdo de Software DCS - Desenvolvimento Centralizado de Software DGS - Desenvolvimento Global de software CMM - Capability Maturity Model CMMI - Capability Maturity Model Integration MPS.BR - Melhoria de processo de Software Brasileiro PMI - Project Management Institute RUP - Rational Unified Process SEI - Software Engineering Institute Carnegie Mellon University SECM - Systems Engineering Capability Model SPICE - Software Process Improvement Capability dEtermination. xxi.

(17)

(18) CAPÍTULO 1. ˜ INTRODUC ¸ AO Neste cap´ıtulo serão apresentadas as principais motiva¸co˜es deste trabalho, buscando contextualizar o objetivo principal do estudo e as suas contribui¸co˜es. 1.1. ˜ MOTIVAC ¸ AO. Nas u ´ltimas décadas, a globaliza¸cão trouxe e ainda trás algumas conseq¨ uências, dentre elas podemos destacar a acirrada competitividade nos mercados nacionais e internacionais, os clientes cada vez mais exigentes, com demandas mais sofisticadas e complexas, e meios de comunica¸caõ e recursos tecnológicos em crescente evolu¸cão. Este cenário apresenta maiores exigências em padrões de qualidade, necessidade de inova¸caõ e excelência em gestão de projetos, seja centralizados ou distribu´ıdos. Para Kerzner [29] a globaliza¸caõ e a tecnologia farão com que a boa prática de gestão de projetos se torne ainda mais importante do que já é nos dias atuais. ´ poss´ıvel perceber que as empresas estão buscando implantar ou se certificar em E algum dos modelos de qualidade existente, como CMMI e MPS.BR para conseguir obter ou aumentar a qualidade de seus processos. Portanto, o processo ao qual este trabalho estará dando prioridade, será o processo de comunica¸caõ onde o mesmo permeia todo o projeto e é foco desta disserta¸cão. Os modelos de qualidade como CMMI [11], MPS.BR [45], ISO 12207 [13], ISO 15504 [1] dentre outros, tratam o processo de comunica¸cão de forma abrangente, dando uma aten¸cão não satisfatória para o Desenvolvimento Distribu´ıdo de Software (DDS). Atualmente, podemos perceber que é cada vez mais significativo o n´ umero de empresas que estão aderindo ao DDS; distribuindo seus processos de desenvolvimento de software globalmente. Entretanto, mesmo que a empresa seja certificada em algum modelo de qualidade, onde determinado n´ıvel de maturidade estabelece um processo de comunica¸cão promovendo dados e informa¸co˜es para apresentar o andamento ou status do projeto, ainda não consegue apresentar um processo de comunica¸cão direcionado, ou seja, suficientemente adequado para o Desenvolvimento Distribu´ıdo de Software onde fatores externos como dispersão geográfica, a dispersão temporal e as diferen¸cas culturais entre outros tem grande impacto. Por tal motivo, o Desenvolvimento Distribu´ıdo tem despertado interesse em um maior volume de pesquisas na área de Engenharia de Software[31]. Os engenheiros de software, pesquisadores da área, tem reconhecido a grande influência desta nova forma de trabalho e estão em busca de modelos que venham a facilitar o desenvolvimento de software com equipes geograficamente separadas ou dispersas. Segundo Carmel [6], as principais caracter´ısticas que diferenciam o Desenvolvimento Distribu´ıdo de Software do desenvolvimento co-localizado ou centralizado são: dispersão geográfica, dispersão temporal e as diferen¸cas culturais. 1.

(19) ˜ INTRODUC ¸ AO. 2. O DDS, por ser altamente dependente da comunica¸cão, sofre com o impacto da dispersão das equipes. Com as equipes distribu´ıdas geograficamente, a comunica¸cão acaba tornando-se menos frequente e mais importante. A dispersão temporal, principalmente devido a diferen¸ca de fuso-horário, afeta atividades como, por exemplo, a elicita¸cão, negocia¸caõ de requisitos e mudan¸cas de escopo, introduzindo dificuldades como o contato s´ıncrono entre as equipes. O DDS, por necessitar e depender de um bom relacionamento entre os envolvidos, também é influenciado pelas diferen¸cas culturais entre os membros das equipes. Portanto, a falta de um processo de comunica¸caõ bem definido ou minimamente padronizado para o DDS, torna-se um aspecto cr´ıtico para o sucesso de projetos. Neste contexto, esta disserta¸cão enfoca o processo de comunica¸caõ de projetos distribu´ıdos de software. 1.2. OBJETIVOS. A comunica¸cão é um fator extremamente determinante para o sucesso dos projetos, sejam eles centralizados ou distribu´ıdo. A distribui¸cão das equipes envolvidas no processo de desenvolvimento de software apresenta diversos desafios, tanto para a Engenharia de Software quanto para as empresas que adotam esta nova forma de estratégia de negócio, ou seja, o desenvolvimento distribu´ıdo de software onde as empresas podem distribuir seus processos de forma global, tendo como um dos principais benef´ıcios, estar mais próximo do cliente, incentivos fiscais e equipes interdisciplinares. As equipes distribu´ıdas acabam sendo diretamente afetadas pela distância f´ısica e temporal. Desta forma, fica evidente que equipes necessitam de uma maior comunica¸caõ via tecnologias, sejam elas via email, videoconferência, chat ou teleconferência dentre outras, para suprir a falta de reuniões face a face. Portanto, ambiguidades e problemas de entendimento são muito freq¨ uentes com as diferen¸cas de idioma e cultura. Diante deste cenário, questões como gestão do conhecimento e fuso horário exercem impacto nas atividades das equipes em ambientes de Desenvolvimento Distribu´ıdo de Software (DDS) [31]. Essa pesquisa tem como principal objetivo o suporte necessário para a sele¸caõ de um conjunto de boas práticas a serem incorporadas na execu¸cão do processo de comunica¸caõ para o desenvolvimento distribu´ıdo de software 1.3. ˜ DO PROBLEMA DESCRIC ¸ AO. No cenário atual, com a possibilidade de pessoas separadas geograficamente poderem cooperar no desenvolvimento de um determinado software, tornou-se necessário um controle, mais rigoroso das atividades relacionadas à gestão do projeto e mais especificamente no processo de comunica¸cão dos projetos. Várias pesquisas foram realizadas em busca de modelo de referência para Desenvolvimento Distribu´ıdo de Software (DDS), tendo como um dos objetivos principais, determinar como as dificuldades relacionadas à comunica¸caõ em DDS podem ser controladas permitindo que as empresas garantam o sucesso em seus projetos. Diante deste contexto, é percebido que a comunica¸caõ torna-se uma área negligenciada pelos gerentes de pro-.

(20) ˜ 1.4 CONTRIBUIC ¸ AO. 3. jetos no DDS, pois os mesmos tratam o Desenvolvimento Distribu´ıdo de Software como desenvolvimento centralizado de software (DCS). Dentre as dificuldades encontradas em comunica¸caõ no DDS, podemos citar: diferen¸cas culturais, idioma, mudan¸ca de escopo, informalidade, ausência de infra-estrutura de comunica¸caõ entre outros. O objetivo principal desta pesquisa é a elabora¸caõ de uma proposta de boas práticas no processo de comunica¸caõ para ambientes de Desenvolvimento Distribu´ıdo de Software. Deseja-se que essas práticas de comunica¸caõ, sejam as mais adequadas poss´ıveis para os membros de projetos DDS. 1.4. ˜ CONTRIBUIC ¸ AO. Esta disserta¸cão contribui para melhorar o processo de comunica¸caõ no Desenvolvimento Distribu´ıdo de Software (DDS). Seu objetivo principal é propor boas práticas para facilitar o gerenciamento da comunica¸caõ nesse tipo de projeto. As contribui¸co˜es que se destacam são: Descrever as principais caracter´ısticas de DDS; Identificar as práticas utilizadas e relatadas em ambientes de Desenvolvimento Distribu´ıdo de Software, sendo, o foco principal, na atividade de comunica¸caõ; Identificar as principais categorias relacionadas à comunica¸cão em ambientes de desenvolvimento distribu´ıdo de software; Propor boas práticas no processo de comunica¸cão para projetos de desenvolvimento distribu´ıdos de software.. 1.5. ˜ DA DISSERTAC ˜ ORGANIZAC ¸ AO ¸ AO. Esta disserta¸caõ está organizada em 7 cap´ıtulos. O presente cap´ıtulo exibe uma introdu¸caõ sobre o contexto de Comunica¸caõ dentro do Desenvolvimento Distribu´ıdo de Software. Apresenta, ainda, o objetivo central deste trabalho, a motiva¸caõ e a descri¸cão do nosso problema de pesquisa visando propor boas práticas para o processo de comunica¸cão no desenvolvimento distribu´ıdo de software. No Cap´ıtulo 2 introduzimos conceitos sobre modelo de qualidade de software, bem como a necessidade existente para a condu¸cão dos mesmos em ambientes de desenvolvimento distribu´ıdos de software. No Cap´ıtulo 3 é apresentada uma contextualiza¸cão do Desenvolvimento Distribu´ıdo de Software (DDS), bem como suas caracter´ısticas, desafios do DDS e problemas relacionados ao processo de comunica¸cão. No Cap´ıtulo 4, é definida a metodologia de pesquisa utilizada para a conclusão desse trabalho. Nessa metodologia estão previstas a realiza¸cão de uma entrevista semiestruturada [20] com gerentes de projeto que participem ou tenha experiência em projetos com caracter´ıstica de Desenvolvimento Distribu´ıdo de acordo com Prikladnicki [41]..

(21) 4. ˜ INTRODUC ¸ AO. No Cap´ıtulo 5, são apresentados os resultados do estudo e a análise das entrevistas realizadas. Como resultado dessas pesquisa foram geradas informa¸co˜es e categorias que darão suporte a proposi¸caõ das boas práticas no Cap´ıtulo 6. Estas informa¸co˜es estão listadas no Cap´ıtulo 6. já as conclusões e limita¸cões do presente trabalho, bem como e as sugestões para trabalhos futuros, ficaram no Cap´ıtulo 7..

(22) CAPÍTULO 2. MODELOS DE QUALIDADE. O desenvolvimento de software com qualidade e com uma alta produtividade, no prazo estabelecido, sem precisar de mais recursos do que aqueles planejados e alocados, tem se tornado um desafio para Engenharia de Software [46]. Qualidade não é mais um diferencial de mercado para a empresa conseguir vender e lucrar mais é um pré-requisito que a mesma deve obter ou conquistar para tentar colocar o seu produto no Mercado Global. O conceito de qualidade e sua aplicabilidade vem sendo fortemente disseminado em diversos setores empresariais e industriais. ´ importante a utiliza¸caõ de modelos de qualidade, como ISO 12207, ISO 15504, E CMMI, MPS.BR entre outros, que permitam estabelecer e avaliar os requisitos de qualidade através de um processo de avalia¸cão bem definido e estruturado. Um aspecto interessante da qualidade, é que não basta sua existência dentro do processo de desenvolvimento, é essencial, ainda, o seu reconhecimento pelo cliente. Por tal motivo, é necessário que exista algum tipo de certifica¸caõ oficial, emitida com base em um padrão, como por exemplo, os certificados de qualidade CMMI, MPS.BR, e os da série ISO 9001 [13]. Manter a qualidade de software vem sendo uma preocupa¸cão crescente e com grande evidência nas empresas de fábricas de software, tal fator deve-se inclusive devido ao aumento da concorrência, mas também pelas exigências dos clientes e pela necessidade de controle interno. Atualmente existe uma grande preocupa¸cão para criar modelos que venham a melhorar a avalia¸cão de qualidade tanto de produto de software quanto de processo de desenvolvimento de software. Algumas iniciativas estão sendo fomentadas por governos e institui¸co˜es de pesquisas. A Tabela 2.1 apresenta os principais modelos de qualidade. A seguir cada um desses modelos serão apresentados em detalhes. 2.1. ISO/IEC 12207. A Norma NBR ISO/IEC 12207 foi criada em 1995 e tem como meta fornecer um template ou estrutura comum para fornecedores, clientes, desenvolvedores, mantenedores, operadores, gerentes e técnicos envolvidos com o desenvolvimento de software. Desta forma, a ISO 12207 tem como objetivo utilizar uma linguagem comum a todos, estabelecida por processos bem definidos, proporcionando uma melhor defini¸cão dos papéis envolvidos e um entendimento das atividades a serem executadas. Esses processos são classificados de três formas: Fundamentais, de Apoio e Organizacional. Esses processos conduzem uma melhor qualidade do produto quanto do Software [12]. A Figura 2.1 apresenta os processos. 5.

(23) 6. MODELOS DE QUALIDADE. Tabela 2.1 Principais Modelos de Qualidade. Modelos ISO 12207. Descri¸ c˜ ao Processo de Ciclo de Vida do Software. Norma para a qualidade do processo de desenvolvimento de software. SPICE - ISO 15504 Projeto da ISO/IEC para avalia¸cão de processo de desenvolvimento de software. CMMI Capability Maturity Model Integration. Modelo do SEI (Instituto de Engenharia de Software do Departamento de Defesa dos EUA) para avalia¸caõ da qualidade do processo de desenvolvimento de software. MPS.BR Projeto coordenado pelo Softex, com o apoio do Ministério de Ciência e Tecnologia - MCT, além da Financiadora de Estudos e Projetos - FINEP e do Banco Interamericano de Desenvolvimento - BID para Melhoria do Processo de Software no Brasil.. 2.1.1. Processos Fundamentais. Estes processos definem: aquisi¸cões, fornecimento, opera¸caõ e manuten¸caõ do ciclo de vida do software encontram-se divididos nas seguintes atividades: Aquisi¸ c˜ ao - Atividade do cliente. Inicia-se com a necessidade de adquirir um software. Fornecimento - Atividade do fornecedor do software. Inicia-se com a prepara¸cão de propostas, contratos, planos de projeto e etc. Opera¸ c˜ ao - Atividade de quem opera o software. Inicia-se com a operacionaliza¸caõ do software e suporte aos usuários em sua opera¸caõ.. c˜ ao - Atividade do profissional ou equipe responsável em fazer a manu Manuten¸ ten¸caõ do software. 2.1.2. Processos de Apoio. Define a documenta¸caõ, gestão de configura¸caõ, gestão da qualidade, verifica¸caõ, valida¸cão, revisão conjunta, auditoria e resolu¸caõ de problemas. c˜ ao - Atividade que registra as informa¸cões que são produzidas por Documenta¸ um processo ou atividade. Essa atividade inclui planejar, projetar, desenvolver, produzir, editar e manter todos os documentos que são de interesse dos gerentes, engenheiros e usuários do sistema..

(24) 7. 2.1 ISO/IEC 12207. Figura 2.1 Processo da ISO 12207 [13]. Gerˆ encia de Configura¸c˜ ao - Atividade que faz o controle dos artefatos de software. Esta atividade tem como objetivo o controle de software, bem como, identificar e definir itens de software em um sistema, estabelecer linhas bases também chamadas de baseline, liberar, manipular, distribuir e modificar cada item e artefato que compõe o software. Garantia da Qualidade - Atividade que fornece garantia que o processo e produto de software estão em conformidade com os requisitos especificados e são aderentes ao plano estabelecido.. c˜ ao - Atividade que determina se os produtos de software atendem em sua Verifica¸ completude aos requisitos. Valida¸ c˜ ao - Atividade que valida os produtos de software que foram produzidos. Determina se os requisitos e o produto atendem ao seu uso espec´ıfico proposto. Revis˜ ao Conjunta - Atividade que avalia a adequa¸caõ dos produtos de uma fase de um projeto, se apropriado. Elas são feitas nos n´ıveis de gerenciamento do projeto, bem como, nos n´ıveis técnicos. Sua execu¸caõ é feito durante a vigência do contrato. Auditoria - Atividade que determina a adequa¸caõ do produto aos requisitos, planos e contratos, quando for apropriado.. c˜ ao de Problemas - Atividade responsável por analisar e resolver os pro Resolu¸ blemas de qualquer tipo de natureza, descobertos durante a execu¸cão do desenvolvimento, opera¸cão e manuten¸cão ou outros processos..

(25) 8. MODELOS DE QUALIDADE. 2.1.3. Processos Organizacionais. Tem como objetivo melhorar os processos dentro da organiza¸caõ. Esse processos contém atividades organizacionais que são as seguintes: Gerˆ encia- Atividade responsável pelo gerenciamento dos processos. O gerente é responsável pelo gerenciamento do produto e projeto. Infra-Estrutura - Atividade que estabelece e mantém a infra-estrutura adequada para qualquer outro processo. A Infra-estrutura inclui hardware, software, ferramentas, técnicas, padrões de desenvolvimento, opera¸cão e manuten¸caõ. Melhoria - Atividade básica e necessária que as organiza¸cões devem executar para avaliar, medir, controlar e melhorar um processo de ciclo de vida de software. Treinamento - Atividade para prover uma melhor qualifica¸caõ dos profissionais ´ necessário que esses treinamentos sejam planejados e e mantê-los atualizados. E implantados com antecedência para que o pessoal a ser treinado esteja dispon´ıvel quando necessário.. 2.1.4. Vis˜ ao Geral do Gerenciamento de Comunica¸c˜ ao na ISO 12207. O gerenciamento de comunica¸cão é fundamental para o sucesso dos projetos, sejam eles centralizados ou distribu´ıdos. Portanto, a Norma NBR ISO/IEC 12207 - Processos do Ciclo de Vida do Software foi criada com o objetivo de fornecer uma estrutura comum para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e técnicos envolvidos com o desenvolvimento de software utilizem uma linguagem comum. O processo de comunica¸caõ permeia todos os processos da norma ISO 12027 que vai do processo Fundamental, Apoio até o Organizacional. A ausência de um processo de comunica¸cão formal nas normas e nos modelos de qualidade insere mais um desafio para o desenvolvimento de software, pois cada pessoa pode interpretá-la de uma forma, seja correta ou incorreta. A norma ISSO 12207 não apresenta nenhuma prática para o gerenciamento da comunica¸cão, mas apresenta alguns sub-processos que mostram a claramente a necessidade da comunica¸cão para que venham a ter o sucesso esperado. Em seguida apresentamos alguns dos sub-processos referentes aos processos Fundamentais, Apoio e Organizacionais que deixam claro a necessidade de obter uma comunica¸caõ leg´ıvel e objetiva. O gerenciamento de comunica¸caõ é fundamental para o sucesso dos projetos, sejam eles centralizados ou distribu´ıdos. Portanto, a Norma NBR ISO/IEC 12207 - Processos do Ciclo de Vida do Software foi criada com o objetivo de fornecer uma estrutura comum para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e técnicos envolvidos com o desenvolvimento de software utilizem uma linguagem comum. O processo de comunica¸cão permeia todos os processos da norma ISO 12027 que vai do processo Fundamental, Apoio até o Organizacional. A ausência de um processo de comunica¸cão formal nas normas e nos modelos de qualidade insere mais um desafio para o desenvolvimento de software, pois cada pessoa pode interpretá-la de uma forma, seja.

(26) 2.1 ISO/IEC 12207. 9. correta ou incorreta. A norma ISSO 12207 não apresenta nenhuma prática para o gerenciamento da comunica¸caõ, mas apresenta alguns sub-processos que mostram a claramente a necessidade da comunica¸cão para que venham a ter o sucesso esperado. Em seguida apresentamos alguns dos sub-processos referentes aos processos Fundamentais, Apoio e Organizacionais que deixam claro a necessidade de obter uma comunica¸caõ leg´ıvel e objetiva. A seguir serão apresentados os processos, no qual necessitam largamente da comunica¸cão: Elicita¸ c˜ ao de Requisitos - O propósito da Elicita¸caõ de Requisitos é obter, processar e acompanhar as necessidades e os requisitos do cliente ao longo da vida do produto e/ou servi¸co, de forma a estabelecer a linha básica (baseline) de requisitos que serve de base para a defini¸caõ dos produtos de trabalho necessários. A Elicita¸caõ de Requisitos pode ser executada pelo adquirente ou pelo desenvolvedor do sistema. A seguir são apresentados alguns dos resultados referente ao processo comunica¸cão na elicita¸cão de requisitos: uma comunica¸cão cont´ınua com o cliente é estabelecida; requisitos acordados com o cliente são definidos e colocados sob uma linha básica (baseline); um mecanismo é estabelecido para o monitoramento cont´ınuo das necessidades do cliente.. An´ alise dos Requisitos do Software - O propósito da Análise dos Requisitos do Software é estabelecer os requisitos dos elementos de software do sistema. A seguir são apresentados alguns dos resultados referente ao processo comunica¸caõ na análise de elicita¸cão do software: a prioriza¸cão para implementa¸cão dos requisitos do software é definida; os requisitos do software são aprovados e atualizados, sempre que necessário; as mudan¸cas nos requisitos do software são avaliadas quanto aos impactos nos aspectos técnicos, de custo e de cronograma;. Os requisitos do software s˜ ao colocados sob uma linha b´ asica (baseline) e comunicados a todas as partes envolvidas. - O Processo de Fornecimento contém as atividades e as tarefas do fornecedor. Esse processo inicia-se tanto por uma decisão de preparar uma proposta para responder a um pedido de proposta de um adquirente quanto pela assinatura e celebra¸caõ de um contrato com o adquirente para fornecer o sistema, produto de software ou servi¸co de software, e encerra-se com a entrega do sistema, produto de software ou servi¸co de software para o adquirente. O propósito da Proposta do Fornecedor é estabelecer uma interface para responder a requisi¸cões e solicita¸cões de propostas, preparar e submeter propostas e confirmar atribui¸cões através do estabelecimento de um acordo/contrato pertinente. A seguir são apresentados alguns dos resultados referente ao processo comunica¸caõ na gerência de configura¸cão: Uma interface de comunica¸caõ é estabelecida e mantida de forma a responder as requisi¸co˜es e solicita¸co˜es de propostas do cliente;.

(27) 10 2.2. MODELOS DE QUALIDADE. SPICE - ISO/IEC 15504. Tendo em vista que o modelo ISO 9000 encontrava-se em desvantagem, quando comparado a outros modelos que teriam sido concebidos especialmente para software; o ISO resolveu iniciar uma nova investiga¸caõ sobre a necessidade de se criar um padrão internacional [13]. A ISO, ao visualizar essa falha decidiu em 1991, fazer uma investiga¸caõ sobre a real necessidade de se criar esse modelo internacional. Em 1992, os resultados da investiga¸caõ indicaram a necessidade da cria¸caõ de um padrão internacional e a publica¸cão de um primeiro relatório técnico. Para dar in´ıcio a este trabalho foi criado em 1993 o projeto Spice - Software Process Improvement Capability dEtermination que tem como objetivo definir o processo de desenvolvimento de software[1]. esse projeto é uma evolu¸cão da ISO 12207. Em 1998, o ISO/IEC TR 15504 (relatório técnico) foi publicado pela primeira vez [1]. Uma das novidades do projeto Spice foi a inova¸caõ da organiza¸caõ em duas dimensões, a de processos, e a de capacidade de processos. A dimens˜ ao de processos. ´ formada por processos do ciclo de vida do software definido no modelo de referência E de processos o qual é derivado diretamente da norma ISO 15504. Os processos são agrupados em nove categorias conforme Tabela 2.2. . A dimens˜ ao de capacidade. A capacidade de um processo é definida numa escala de seis pontos: O n´ıvel 0 (incompleto) até o topo da escala que é o n´ıvel 5 (otimizado). A escala representa a maximiza¸caõ da capacidade de desempenho do processo, desde um desempenho não satisfatório para atingir os objetivos, até um desempenho satisfatório que é capaz de alcan¸car os objetivos e de realizar melhorias relevantes, sendo que esses objetivos são derivados dos objetivos de negócio da empresa. A escala dos n´ıveis define um percurso claro para melhorar individualmente cada processo conforme Figura 2.2. Objetivos e Documenta¸ c˜ ao. Tem como objetivo principal a melhoria do processo e a determina¸cão da capacidade dos processos em uma organiza¸caõ. De acordo com Côrtes [13], se o objetivo da organiza¸cão for a melhoria de processos, a mesma terá que realizar a avalia¸caõ gerando um perfil dos processos que serão usados para elaborar um plano de a¸cão de melhorias conforme a Figura 2.3 apresenta. A organiza¸caõ deve definir: Todos os objetivos e contextos para a avalia¸caõ; Escolher modelos e métodos para avalia¸cão; Definir os objetivos de melhoria..

(28) 2.2 SPICE - ISO/IEC 15504. 11. Tabela 2.2 Dimens˜ oes de Processo do ISO 15504. Modelos Aquisi¸caõ. Descri¸c˜ ao Processos executados pelo cliente, com o intuito de adquirir um produto e/ou servi¸co. Suprimento Processos executados pelo fornecedor, com o intuito de propor ou fornecer um produto e/ou servi¸co. Engenharia Processos que identificam e gerem os requisitos do cliente, especificam, implementam e/ou mantêm o produto de software e a sua rela¸cão com o sistema. Opera¸caõ Processos executados com o intuito de assegurar o correto funcionamento e utiliza¸caõ do produto e/ou servi¸co. Fornecer Suporte Processos que podem ser utilizados no âmbito de qualquer outro processo em diversos pontos do ciclo de vida de desenvolvimento de software. Melhoria de Processo Processos que contêm práticas que podem ser utilizadas por quem gere qualquer tipo de projeto ou processo dentro do ciclo de vida de desenvolvimento de software. Gerenciamento Processos executados com o intuito de definir, implementar, avaliar e melhorar os processos executados na unidade organizacional. Recurso e Infra-Estrutura Processos executados com o intuito de disponibilizar os recursos (humanos e de infra-estrutura) necessários para a execu¸caõ de qualquer outro processo executado dentro da unidade organizacional. Reuso Processos executados para aproveitar de forma sistemática as oportunidades de reutiliza¸cão dentro da organiza¸cão.. Caso o objetivo seja avaliar um fornecedor em potencial, é necessário obter o seu perfil de capacidade. A organiza¸cão deve definir de acordo com a Figura 2.4. Todos os objetivos e contextos para a avalia¸caõ; Os modelos e métodos para avalia¸cão e os requisitos esperados.. A obten¸caõ do perfil de capacidade do fornecedor permite ao contratante estimar o risco da contrata¸caõ. Essa informa¸caõ auxilia na tomada de decisão para contratar ou não o fornecedor..

(29) 12. MODELOS DE QUALIDADE. Figura 2.2 N´ıveis de Capacidade da ISO 15504. Figura 2.3 Melhoria do Processo Organizacional [13].

(30) 2.2 SPICE - ISO/IEC 15504. Figura 2.4 Melhoria da Capacidade Organizacional [13]. Figura 2.5 Estrutura da Organiza¸c˜ ao dos Documentos do Modelo ISO 15504 [1]. 13.

(31) 14. MODELOS DE QUALIDADE. Os documentos do projeto Spice foram organizados em nove partes. Dentre estas, duas são normativas e as demais são informativas. Logo em seguida, cada uma das partes são detalhadas conforme a Figura 2.5 e a norma [1]. A Parte 1 (informativa) é uma introdu¸caõ ao ISO/IEC TR 15504; descreve os requisitos contidos dentro do ISO 15504 e a sua aplicabilidade na execu¸cão de uma avalia¸cão. Já a Parte 2 (normativa) define um modelo de referência que descreve os processos e os seus n´ıveis de capacidade usado nas avalia¸cões. Nesta parte também são definidos requisitos para o estabelecimento de compatibilidade entre diferentes modelos de avalia¸cão e o modelo de referência. Quanto a Parte 3 (normativa) esta define os requisitos para a execu¸caõ da avalia¸caõ com o objetivo de que os resultados sejam pass´ıveis de repeti¸caõ, confiáveis e consistentes. A Parte 4 (informativa) fornece orienta¸co˜es para a execu¸cão de avalia¸cões de processos de software e interpreta¸cão de requisitos em contextos diferentes. Estas orienta¸cões são caracteristicamente genéricas demais para serem aplicadas a todas as organiza¸cões. Na Parte 5 (informativa) forcene um exemplo de um modelo para avalia¸cões de processos que é baseado e compat´ıvel com o modelo de referência. Esta Parte 6 (informativa) descreve os requisitos para a qualifica¸cão dos avaliadores que possa ser relevante para a execu¸caõ da avalia¸cão de processos. Esta parte apresenta os meios que podem ser usados para demonstrar a competência, para validar a forma¸caõ, treino e experiência dos avaliadores. Acerca da Parte 7 (informativa), esta descreve orienta¸co˜es para fins de melhoria de processos. Descreve, também, como se definem as entradas para a execu¸caõ da avalia¸cão e como se utilizam os resultados da mesma em busca da melhoria do processo. Na Parte 8 (informativa), tem-se a defini¸cão de orienta¸co˜es para fins de avalia¸caõ da capacidade, ou seja, descreve a forma como se definem as entradas para a execu¸cão da avalia¸caõ e como se utilizam os resultados da mesma quando utilizados com o objetivo de determina¸caõ da capacidade dos processos. Por fim, a Parte 9 (informativa) que é um vocabulário consolidado com os termos espec´ıficos definidos no âmbito do ISO/IEC TR 15504. 2.2.1. Vis˜ ao Geral do Gerenciamento de Comunica¸c˜ ao na ISO 15504. A melhoria do processo de comunica¸caõ tem demonstrado na prática ser altamente relevante e viável, além de eficaz e eficiente para a necessária melhoria das organiza¸co˜es intensivas em software. Melhoria de processo é na verdade uma abordagem para a me-.

(32) 2.2 SPICE - ISO/IEC 15504. 15. lhoria das organiza¸co˜es, em dire¸caõ a objetivos de negócio, por meio da melhoria da capacidade de seus processos mais importantes. Dentro deste contexto, o processo de comunica¸cão vem sendo evidenciado nos u ´ltimos anos. O gerenciamento do processo de comunica¸caõ na norma ISO 15504 em comum com outros modelos, não é um processo expl´ıcito, pois se faz necessário que venhamos a interpretá-lo para instanciá-lo dentro de um contexto, seja ele, em um desenvolvimento tradicional ou distribu´ıdo. Um aspecto importante da melhoria de processo é a identifica¸caõ do equil´ıbrio do grau de formaliza¸cão do processo como a complexidade da comunica¸caõ em um projeto. Um excesso de formaliza¸cão do processo pode causar ”burocracia”enquanto que uma insuficiência de formaliza¸caõ pode causar ”anarquia”. Uma forte tendência atual é a amplia¸caõ da abrangência da melhoria de processo de software para a melhoria de processo de software e sistemas. O principal framework de capacidade de processo (ISO/IEC TR 15504) foi evolu´ıdo e sua respectiva nova versão (ISO/IEC 15504) define framework genérico para modelos de qualquer disciplina. A norma ISO 15504 apresenta práticas de comunica¸caõ em seus respectivos n´ıveis de capacidade (de 0 a 5) que não são expl´ıcitas na norma, mas que podemos interpretá-las e utilizá-las para estabelecer este processo. Vejamos, logo em seguida, os principais subprocessos referente a comunica¸cão em alguns n´ıveis de capacidade, e como os mesmos podem nos auxiliar na obten¸cão de uma comunica¸cão efetiva. N´ıvel 2 (Processo Gerenciado) - neste n´ıvel podemos perceber alguns subprocessos de comunica¸caõ: Os recursos e a informa¸caõ necessária para a execu¸cão do processo são identificadas, disponibilizadas, alocadas e utilizadas; As interfaces entre as partes envolvidas são gerenciadas para garantir comunica¸caõ efetiva e atribui¸cão clara de responsabilidades; Atribui¸caõ e comunica¸caõ de responsabilidades e autoridades para executar o processo; Os recursos e informa¸co˜es necessários para implementar o processo de acordo com os objetivos identificados de execu¸cão do processo são identificados, disponibilizados; Gerenciamento as partes envolvidas para assegurar uma comunica¸cão efetiva e a clara atribui¸cão das responsabilidades; Registros de qualidade tais como registros pessoais, atas de reunião.. N´ıvel 3 (Processo Estabelecido) - podemos visualizar alguns subprocessos de comunica¸cão: Defini¸caõ de uma infra-estrutura para a comunica¸caõ (ferramentas, métodos e etc);.

(33) 16. MODELOS DE QUALIDADE. Prover repositório de conhecimento para a compreensão e melhoria do processo padrão; Os papéis necessários, responsabilidades e autoriza¸cões para execu¸caõ do processo definido são designados e comunicados; Os recursos e informa¸cão necessários para a execu¸caõ do processo definido são disponibilizados.. N´ıvel 4 (Processo Previs´ıvel) - logo em seguida, podemos perceber alguns dos principais subprocessos de comunica¸cão: Coletar as medidas e em seguida analisadas e comunicadas as partes interessadas para permitir a monitora¸cão; Institucionalizar informa¸cões para medi¸cão.. Percebe-se que o PMBOK através do seu processo de gerenciamento da comunica¸cão pode ser muito u ´til para auxiliar a norma na defini¸cão clara do processo de comunica¸cão através do seu planejamento e suas técnicas. Logo, o PMBOK pode ser utilizado para atender algumas práticas dentro de determinados n´ıveis de capacidade para deixar o processo de comunica¸cão mais explicito e efetivo. O sucesso do processo de comunica¸cão, ou do planejamento da comunica¸caõ melhora o uso de modelos/normas e documentos auxiliares para seu entendimento e sua correta aplica¸cão dentro das organiza¸co˜es. 2.3. CMMI. O CMMI, modelo criado pelo SEI (Software Engineering Institute Carnegie Mellon University) e com o objetivo de integrar os modelos já existentes, como o CMM (Capability Maturity Model ) e SECM (Systems Engineering Capability Model ), solucionando, assim, o uso dos m´ ultiplos CMMs. Além disso, o CMMI também incorporou li¸co˜es aprendidas durante vários anos de utiliza¸caõ dos modelos do SEI, eliminando desta forma, inconsistências, reduzindo inclusive redundâncias e aumentando assim a clareza no uso dos termos comuns. Segundo Becker [3], dois conceitos que permeiam a concep¸cão dos modelos do SEI são: as idéias de capacidade e as de maturidade de processo. A capacidade apresenta o intervalo de resultados que podem ser atingidos e, ainda os resultados esperados através da utiliza¸caõ de um processo, e desta forma provê um meio de prognosticar os resultados caracter´ısticos dos projetos a serem desenvolvidos pela organiza¸cão. A maturidade simboliza as condi¸cões para o crescimento da capacidade de uma organiza¸caõ e informa a consistência e riqueza do processo com o qual ele é aplicado no contexto da organiza¸caõ [3]. A principal mudan¸ca do CMMI em compara¸caõ com o SW-CMM, é a op¸cão de utiliza¸caõ de duas abordagens diferentes para a melhoria do processo. As abordagens são:.

(34) 17. 2.3 CMMI. Cont´ınuo - Tem como objetivo a maturidade da organiza¸cão através de um processo evolutivo para sua melhoria. Essa representa¸caõ ajuda as organiza¸co˜es que desejam a melhoria de seus processos de desenvolvimento de software. Est´ agios - Tem como objetivo a melhoria de processo de forma sistêmica e estruturada, além de apresentar um meio mais fácil ou flex´ıvel para a implanta¸cão das melhorias. Essa abordagem permite que as organiza¸cões possam escolher as áreas para a implanta¸caõ das melhorias, bem como implantar n´ıveis distintos para diferentes processos.. .. 2.3.1. N´ıveis de Maturidade. O modelo CMMI está dividido em cinco n´ıveis de maturidade conforme a Figura 2.6 e suas áreas de processo.. Figura 2.6 N´ıveis de Maturidade do CMMI. . Detalhes sobre os N´ıveis de Maturidade. Os N´ıveis de maturidade baseiam-se em um conjunto pré-definido de áreas de processo, são eles: N´ıvel de maturidade 1: (Inicial) - Neste n´ıvel, os processos são muito informais e a organiza¸caõ, geralmente, não dispõe de um ambiente estável. Sucesso nestas organiza¸co˜es depende do talento e competência das pessoas na organiza¸cão e.

(35) 18. MODELOS DE QUALIDADE. não na utiliza¸cão dos processos. Organiza¸co˜es com esta maturidade, normalmente produzem produtos e servi¸cos que funcionam, entretanto, eles freq¨ uentemente ultrapassam o prazo e or¸camento de seus projetos. N´ıvel de maturidade 2: (Gerenciado) - Uma organiza¸caõ obteve as metas espec´ıficas e genéricas de áreas de processo, ou seja, os projetos das organiza¸co˜es asseguram quais requisitos são gerenciados e quais processos são planejados, executados, medidos, e controlados. N´ıvel de maturidade 3: (Definido) - A organiza¸caõ obteve metas espec´ıficas e genéricas das áreas de processo concedidas aos n´ıveis 2 e 3. Cabe saber acerca da maturidade, que os processos são bem entendidos. N´ıvel de maturidade 4: (Quantitativamente Gerenciado) - Aqui, uma organiza¸caõ obteve todas as metas espec´ıficas das áreas de processo determinadas para os n´ıveis de maturidade 2, 3 e 4, bem como, metas genéricas dos n´ıveis de maturidade 2 e 3. Subprocessos são selecionados que significativamente contribuam a toda parte de desempenho de processo. Estes subprocessos selecionados são controlados usando técnicas estat´ısticas e outras técnicas quantitativas. N´ıvel de maturidade 5: (Otimizado) - Neste, uma organiza¸caõ obtem todas as metas espec´ıficas das áreas de processo determinadas para os n´ıveis 2, 3, 4 e 5 com metas genéricas determinadas para os n´ıveis 2 e 3. Os Processos são continuamente melhorados e baseiam-se em entendimentos quantitativos de causas comuns de varia¸caõ inerente aos processos.. 2.3.2. ´ Areas de Conhecimento do CMMI. O objetivo do CMMI é fornecer um CMM que aborde o desenvolvimento do produto ou servi¸co além da manuten¸cão, permitindo a inclusão de novas disciplinas ou áreas de conhecimento do CMMI. Atualmente o CMMI descreve quatro áreas de conhecimento que ajudam na melhoria do processo: i)engenharia de sistemas, ii)engenharia de software, iii)produtos integrados, iv)desenvolvimento de processos e fornecimento de recursos [35], [10]. Essas disciplinas são descritas logo em seguida. Engenharia de Software: onde o objetivo principal é o desenvolvimento de software aplicando uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, opera¸caõ e manuten¸caõ do software [10], [35]; Engenharia de Sistemas: está coberto o desenvolvimento de sistemas completo. O foco principal é transformar as necessidades, expectativas e restri¸co˜es do cliente em produtos e assistência dos mesmos durante seu ciclo de vida [10]; Desenvolvimento integrado de processo e produto: aborda de uma forma sistemática o relacionamento e intera¸caõ dos stakeholders mais representativos durante o tempo de vida do produto. Os processos utilizados nesta disciplina estão integrados a.

(36) 2.3 CMMI. 19. outros processos da organiza¸cão, portanto os projetos são caracterizados por uma grande quantidade de equipes de diferentes áreas de conhecimento e processo [10]. Fornecimento de Recursos: essa disciplina tem como foco aquisi¸cão ou subcontrata¸cão de servi¸cos ou produtos para agilizar e facilitar o desenvolvimento do projeto, principalmente quando o esfor¸co de trabalho é muito grande ou complexo.[10]). As disciplinas de Engenharia de Software e Engenharia de Sistemas, segundo o CMMI, podem ser aplicadas individualmente ou em conjunto. Já as disciplinas de Desenvolvimento integrado de processo e produto e Fornecimento de Recursos devem ser aplicadas mediante a aplica¸caõ das anteriores. 2.3.3. Vis˜ ao Geral do Gerenciamento de Comunica¸c˜ ao no CMMI. O gerenciamento de comunica¸co˜es é uma área de conhecimento que através dos seus processos asseguram uma correta comunica¸caõ entre as partes interessadas, ou seja, os stakeholders [24]. O modelo CMMI avalia a maturidade organizacional, além das capacidades dos processos utilizados em cada organiza¸caõ [11]. O CMMI apresenta algumas práticas de comunica¸caõ que não são expl´ıcitas no modelo, mas que podemos interpretá-las e utilizá-las para estabelecer este processo. Sabemos que e-mails, relatórios não garantem a efetiva comunica¸cão, por isso é importante que exista um processo formal e bem definido através das partes interessadas. Ademais, é necessário saber como e quando essa comunica¸cão pode ser estabelecida. Vejamos, logo em seguida, como o CMMI pode nos auxiliar a obter uma comunica¸caõ efetiva. Planejar o processo. Aqui abordamos a abrangência no planejamento das práticas espec´ıficas desta área de processo. Em outras palavras, esta prática genérica do CMMI solicita fazer o ”planejamento do plano”. no planejamento inclui-se atribui¸caõ de tempo, recursos e habilidades para realiza¸caõ dos processos, junto a descri¸caõ de quais serão ou não realizados em determinado projeto. As comunica¸co˜es em diversos momentos, tem a atribui¸caõ de multitarefas, e as vezes uma u ńica mensagem pode desencadear diversas respostas e troca de mensagens. Caso esse fluxo de mensagens não seja esperado pelo emissor ou gestor, esse ocorrido pode gerar um grande transtorno para o projeto. Identificar e envolver os stakeholders importantes. Esta prática é necessária à sele¸caõ do stakeholders relevantes para o projeto a partir dos gerentes de projetos, gerentes funcionais do projeto, fornecedores, clientes dentre outros que podem ser afetados (ou afetar) o projeto. Desta forma o CMMI consegue estabelecer atividades que necessitam de uma comunica¸caõ correta como: estabelecer estimativas, resolver questões sobre riscos no projeto, estabelecer planos de projeto entre.

(37) 20. MODELOS DE QUALIDADE. outras. Além disso, uma vez selecionado os stakeholders mais relevantes, podemos delimitar quem é responsável por tal atividade e quem irá receber as devidas informa¸co˜es sem gerar um broadcast de mensagens dentro do projeto. Para obter uma boa sele¸cão dos stakeholders do projeto é necessário saber quais dos selecionados tem especializa¸co˜es para executar tal atividade. ´ importante salientar que um plano de envolvimento com stakeholders deve conter: E justificativas para o envolvimentodo dos mesmos; papéis e responsabilidades em rela¸caõ ao projeto; relacionamento entre os stakeholders; importância e otimismo em rela¸caõ ao sucesso do projeto; recursos necessários para assegurar a intera¸cão dos stakeholders (treinamento,tempo, finan¸cas, materias). Distribui¸c˜ ao das informa¸c˜ oes. Este processo de distribui¸cão das informa¸co˜es engloba informa¸cões importantes ligadas ao projeto; informa¸co˜es estas totalmente dispon´ıveis para as partes interessadas no momento apropriado, ou seja, disponibilizadas de forma adequada a informa¸cão correta, às pessoas certas. Esse processo esta localizado na fase de execu¸cão do projeto, onde a distribui¸caõ dessas informa¸cões come¸ca a efetivar o que fora previsto no gerenciamento de comunica¸cão. Entretanto, dado que o CMMI promove uma estrutura para gerenciamento de processos e melhores práticas para Engenharia de Software, o termo comunica¸cão aparece através do texto do modelo, mas não há nada expl´ıcita à execu¸cão do processo de distribui¸cão de informa¸caõ. Os elementos do modelo que se relacionam mais claramente com componente de comunica¸caõ são as práticas genéricas, as quais não iremos nos aprofundar nesta pesquisa. Diante deste contexto, no modelo CMMI podemos encontrar alguns elementos do processo de distribui¸cão das informa¸cões ao longo de diversas práticas de variadas áreas de processo, dentre as quais destacamos: Institucionalizar um processo gerenciado - envolve revisar as atividades, status e resultados do processo com os n´ıveis gerenciais mais elevados, buscando por fim, resolver dificuldades. Monitorar o plano frente ao projeto - esta prática busca revisar o processo periodicamente, sua performance e problemas do projeto para manter os stakeholders sempre informados, ou seja, comunicar frequentemente o status de atividades atribu´ıdas e produtos de trabalho. Esta prática do CMMI estabelece que tais revisões podem ser informais e não devem ser explicitamente especificadas nos planos de projeto.. c˜ oes - esta prática estabelece que os resultados das Fornecer Resultados de Medi¸ atividades de medi¸co˜es e análises são comunicados para os stakeholders importantes de forma adequada e no momento apropriado. . O PMBOK através do seu processo de gerenciamento da comunica¸caõ pode auxiliar na.

(38) 2.4 MPS.BR. 21. defini¸cão do processo de comunica¸caõ através do planejamento da comunica¸caõ e suas técnicas apresentadas, as quais os modelos de qualidade não apresentam especificamente. Logo, o PMBOK pode ser utilizado para atender algumas práticas de comunica¸cão solicitadas pelo CMMI e outros modelos de qualidade. O êxito do processo de comunica¸cão, ou do planejamento da comunica¸cão melhora o uso de modelos e documentos auxiliares ao processo como ferramenta de suporte para uma boa comunica¸caõ. 2.4. MPS.BR. A Associa¸cão para Promo¸caõ e Excelência do Software Brasileiro, criou em dezembro de 2003 o Modelo de Melhoria de Processo de Software Brasileiro (MPS.BR) com o objetivo de aumentar a qualidade do processo de desenvolvimento de Software em organiza¸co˜es micro, pequenas e médias empresas que não possuem recursos financeiros suficiente para a implanta¸caõ de modelos como CMMI [48]. O MPS.BR é um programa coordenado pelo Softex, com o apoio do Ministério de Ciência e Tecnologia - MCT, além da Financiadora de Estudos e Projetos - FINEP e do Banco Interamericano de Desenvolvimento - BID [45]. Este modelo tem como base técnica para sua composi¸caõ as normas NBR ISO/IEC 12207 - Processo de Ciclo de Vida do Software, ISO/IEC 15504 - Avalia¸caõ de Processo, e de forma complementar o modelo abrange conte´ udo de outros modelos de referência de processo como o CMMI [10] com o qual está em conformidade. O modelo também tem definidas algumas regras para a implementa¸cão e avalia¸caõ com intuito de dar sustenta¸cão e uma maior garantia de que esta sendo executado conforme suas defini¸co˜es. A Figura 2.7 apresenta os três componentes do modelo MPS. MR-MPS (Modelo de Referência para Melhoria de Processo de Software) - tem como objetivo orientar a realiza¸cão de avalia¸cões, em conformidade com a norma ISO/IEC 15504, em empresas e organiza¸co˜es que implementaram o MR-MPS. MA-MPS (Método de Avalia¸cão para Melhoria de Processo de Software) o Softex através de seus agentes e algumas institui¸cões no Brasil têm larga experiência na gestão e forma¸cão de grupos de empresas para melhoria de processo de software, seja voltado à implementa¸cão e certifica¸caõ ISO 9000, seja grupos de empresas voltados à implementa¸caõ e avalia¸caõ CMM e CMMI. Baseado nestas experiências concebeu-se para o Projeto MPS.BR um Modelo de Negócio (MN-MPS) que prevê duas situa¸cões:. 1. A implementa¸caõ do MR-MPS de forma personalizada para uma empresa (MNE - Modelo de Negócio Espec´ıfico); 2. A implementa¸cão do MR-MPS de forma cooperada em grupos de empresas (MNC - Modelo de Negócio Cooperado), com custo mais baixo, ficando acess´ıvel às micro, pequenas e médias empresas, além de dividir todo o custo proporcionalmente entre as empresas e por buscar outros meios de financiamento..

(39) 22. MODELOS DE QUALIDADE. MN-MPS (Modelo de Negócio para Melhoria de Processo de Software) descreve regras para o negócio com o intuito de: implementa¸caõ do Modelo de Referência MR-MPS pelas Institui¸cões Implementadoras (II); avalia¸cão seguindo o Método de Avalia¸caõ MA-MPS pelas Institui¸co˜es Avaliadoras (IA); organiza¸caõ de grupos de empresas para implementa¸caõ do MR-MPS e avalia¸cão MA-MPS pelas Institui¸co˜es Organizadoras de Grupos de Empresas (IOGE); Certifica¸cão de Consultores de Aquisi¸caõ (CA) de software e servi¸cos correlatos, de acordo com o Guia de Aquisi¸caõ do MPS.BR; realiza¸caõ de treinamentos e provas no Modelo MPS.. Figura 2.7 Componentes do MPS.BR. O Modelo de Referência MR-MPS define n´ıveis de maturidade (Ver Figura 2.8) que são uma combina¸cão entre processos e sua capacidade.. Figura 2.8 N´ıveis de Maturidade do MPS.BR.

(40) 2.4 MPS.BR. 2.4.1. 23. N´ıveis de maturidade. . O modelo MPS.BR está dividido em SETE n´ıveis de maturidade conforme a Figura 2.8 e suas áreas de processo. Detalhes sobre os N´ıveis de Maturidade.. N´ıvel de maturidade A: (Em Otimiza¸ c˜ ao) - é formado pelos processos dos n´ıveis de maturidade anteriores (G ao B), acrescido do processo Análise de Causas de Problemas e Resolu¸cão. N´ıvel de maturidade B: (Gerenciado Quantitativamente) - é formado pelos processos dos n´ıveis anteriores (G ao C), sendo que acrescidos dos processos de Desempenho do Processo Organizacional e Gerência Quantitativa do Projeto. N´ıvel de maturidade C: (Definido) - é formado pelos processos dos n´ıveis de anteriores (G ao D), acrescidos dos processos Análise de Decisão e Resolu¸caõ, Desenvolvimento para Reutiliza¸cão e Gerência de Riscos. N´ıvel de maturidade D: (Largamente Definido) - é formado pelos processos dos n´ıveis anteriores (G ao E), acrescidos dos processos Desenvolvimento de Requisitos, Integra¸cão do Produto, Projeto e Constru¸caõ do Produto, Valida¸caõ e Verifica¸cão. N´ıvel de maturidade E: (Parcialmente Definido) - é formado pelos processos dos n´ıveis anteriores (G e F), acrescidos dos processos Avalia¸cão e Melhoria do Processo Organizacional, Defini¸caõ do Processo Organizacional, Gerência de Recursos Humanos e Gerência de Reutiliza¸cão. O processo de Gerência de Projetos sofre sua primeira evolu¸cão retratando seu novo propósito que é o gerenciamento com base no processo definido para o projeto e planos integrados. N´ıvel de maturidade F: (Gerenciado) - é formado pelos processos do n´ıvel anterior (G) acrescidos dos processos de Aquisi¸caõ, Gerência de Configura¸caõ, Garantia da Qualidade e Medi¸cão. N´ıvel de maturidade G: (Parcialmente Gerenciado) - é formado pelos processos Gerência de Projetos e de Gerência de Requisitos.. 2.4.2. Vis˜ ao Geral do Gerenciamento de Comunica¸c˜ ao no MPS.BR. O gerenciamento de comunica¸cões no MPS.BR não é muito diferente do modelo CMMI. Para estes dois modelos o PMBOK é um parceiro muito importante, pois estimula o melhoramento efetivo do processo de comunica¸caõ. No MPS.BR o processo Gerência de.