Melhoria de Processo de Desenvolvimento de Software: Estudo de Caso numa Instituicao Financeira

Universidade de Bras´ılia Instituto de Ciˆencias Exatas Departamento de Ciˆencia da Computa¸c˜ao

Melhoria de Processo de Desenvolvimento de Software: Estudo de Caso numa Institui¸ c˜ ao Financeira

Bruna Oliveira Sinval Bezerra de Lima

Monografia apresentada como requisito parcial para conclus˜ao do Curso de Computa¸c˜ao – Licenciatura

Orientador Prof. Dr. Jorge Henrique Cabral Fernandes

Bras´ılia 2007

Universidade de Bras´ılia – UnB Instituto de Ciˆencias Exatas Departamento de Ciˆencia da Computa¸c˜ao Curso de Computa¸c˜ao – Licenciatura

Coordenador: Prof a¯. Dr a¯. Priscila Am´erica Solis M. Barreto

Banca examinadora composta por: Prof. Dr. Jorge Henrique Cabral Fernandes (Orientador) – CIC/UnB Prof a¯. Dr a¯. Priscila Am´erica Solis M. Barreto – CIC/UnB Prof. Dr. Marco Aurelio de Carvalho – CIC/UnB

CIP – Cataloga¸c˜ ao Internacional na Publica¸ c˜ ao Bruna Oliveira. Melhoria de Processo de Desenvolvimento de Software: Estudo de Caso numa Institui¸c˜ao Financeira/ Sinval Bezerra de Lima, Bruna Oliveira. Bras´ılia : UnB, 2007. 96 p. : il. ; 29,5 cm. Monografia (Gradua¸c˜ao) – Universidade de Bras´ılia, Bras´ılia, 2007. 1. 3. 5. 9.

Melhoria de Processos, 2. Teorias de Aprendizagem, Aprendizagem Significativa, 4. Berhaviorismo, Construtivismo, 6. Cognitivismo, 7. CMMI, 8. MSP.BR, Processo de Desenvolvimento de Software

CDU 004

Endere¸co: Universidade de Bras´ılia Campus Universit´ario Darcy Ribeiro – Asa Norte CEP 70910–900 Bras´ılia – DF – Brasil

Universidade de Bras´ılia Instituto de Ciˆencias Exatas Departamento de Ciˆencia da Computa¸c˜ao

Melhoria de Processo de Desenvolvimento de Software: Estudo de Caso numa Institui¸ c˜ ao Financeira

Bruna Oliveira Sinval Bezerra de Lima

Monografia apresentada como requisito parcial para conclus˜ao do Curso de Computa¸c˜ao – Licenciatura

Prof. Dr. Jorge Henrique Cabral Fernandes (Orientador) CIC/UnB Prof a¯. Dr a¯. Priscila Am´erica Solis M. Barreto Prof. Dr. Marco Aurelio de Carvalho CIC/UnB CIC/UnB Prof a¯. Dr a¯. Priscila Am´erica Solis M. Barreto Coordenador do Curso de Computa¸c˜ao – Licenciatura

Bras´ılia, 19 de junho de 2007

Dedicat´ oria Dedico este trabalho aos meus pais por sempre terem me dado muito amor, carinho, compreens˜ao e apoio em todos os momentos de minha vida. Dedico ao meu pai pelo grande exemplo que ele ´e para mim, por sempre estar ao meu lado e me dar for¸ca para seguir. Dedico a minha m˜ae pela grande mulher que ´e e pela paciˆencia e amor que sempre me deu.

Bruna de Meneses Dedico este trabalho aos meus filhos, pelo amor, alegria e inspira¸c˜ao que sempre me deram. Dedico `a minha esposa Danielle pelo exerc´ıcio de compreens˜ao e tolerˆancia. Dedico a minha m˜ae e a minha av´o Iracy pois sem elas nada disso seria poss´ıvel, seus exemplos de for¸ca e supera¸c˜ao s˜ao o que me ajuda a seguir adiante nas horas dif´ıceis.

Sinval Bezerra de Lima

Agradecimentos Primeiramente a Deus por ter iluminado meu caminho e me dar tudo que sempre precisei. Aos meus pais, pois que s˜ao a raz˜ao do meu viver e que sem eles nada disso seria poss´ıvel. A todos os meus tios, tias e primos. Amo vocˆes! A todas as pessoas que direta ou indiretamente participaram de todos esses anos muita luta e dedica¸c˜ao. Devo agradecimentos a v´arias pessoas que me ajudaram a chegar onde estou... Meus agradecimentos especiais a: Meu primo Felipe por ter me ajudado nos trabalhos intermin´aveis. Todo o pessoal da Brasil Telecom e principalmente ao meu chefe Koreeda pelo apoio que me deu. Ao meu companheiro de trabalho Sinval pela sua paciˆencia, amizade e dedica¸c˜ao. E ao Departamento de Ciˆencia da Computa¸c˜ao, seus professores e funcion´arios respons´aveis pela minha forma¸c˜ao. Enfim agrade¸co a todos que fazem parte da minha vida e que me ajudaram a fazer esse sonho se tornar real. Bruna de Meneses Agrade¸co a Deus por permitir conhecˆe-lo e reconhecer que sem ele de forma alguma eu poderia estar aqui. Agrade¸co a minha m˜ae por todo o investimento de esperan¸cas e for¸ca, e por sempre ter acreditado em mim. Agrade¸co a minha av´o Iracy, pois o seu exemplo de vida, serenidade, for¸ca, e amor sempre me acompanhar˜ao e tanto me ajudaram a chegar at´e aqui. Agrade¸co `a minha esposa e filhos pela paciˆencia em me aturar por horas a fio em frente ao computador e dos livros sem poder lhes dar mais aten¸c˜ao. Agrade¸co a todos que direta ou indiretamente participaram da constru¸c˜ao de conhecimento que culmina com este trabalho. Em especial ao Banco do Brasil, empresa na qual trabalho, pela tolerˆancia de hor´arios, prazos, e contribui¸c˜ao de tantos colegas neste processo de aprendizagem. Agrade¸co especialmente ao colega Antˆonio Passos por sua aten¸c˜ao e ajuda, seu feedback foi muito importante para a melhoria deste trabalho.

Sinval Bezerra de Lima

Resumo Este trabalho visa analisar processos de desenvolvimento de software como uma representa¸c˜ao formal de um aprendizado corporativo, e estabelecer uma rela¸c˜ao direta entre o uso de modelos de ensino-aprendizagem apropriados e o sucesso na implanta¸c˜ao de modelos de processo unificados em grandes empresas cuja atividade fim n˜ao seja o desenvolvimento de software, mas dependa fortemente do mesmo. Ser´a utilizado um estudo de caso numa grande institui¸c˜ao financeira, que apresenta caracter´ısticas de interesse para a pesquisa em quest˜ao. Pretendemos demonstrar que para o sucesso na implanta¸c˜ao de um modelo de processo de desenvolvimento de software unificado n˜ao ´e suficiente ter um processo definido, mesmo que tenha sido modelado `a luz de modelos de maturidade de processos conhecidos como CMMI e MPS.BR. Sendo necess´ario o entendimento de que esta implanta¸c˜ao caracteriza-se por um processo de aprendizagem corporativa e depende de investimento em capacita¸c˜ao na componente pessoas da organiza¸c˜ao.

Palavras-chave: Melhoria de Processos, Teorias de Aprendizagem, Aprendizagem Significativa, Berhaviorismo, Construtivismo, Cognitivismo, CMMI, MSP.BR, Processo de Desenvolvimento de Software

Abstract This paper aims at analysing software development processes as a formal representation of a corporative learning process, and establishes a direct relation between the use of appropriate teaching-learning models and the success in the implementation of unified process models in big companies whose end activity is not software development, but is dependend of it. A case study conducted in a big financial institution will be used, with its relevant characteristics for the present paper. We intend to demonstrate that success in implementing a unified software development model is not enough to have a good modelled process, even if it has been modelled in light of maturity models of processes known as CMMI e MPS.BR. It is necessary to understand that the said implementation is characterized by a corporative learning process.

Keywords: Process Improvement, Teaching Learning Models, Subsumption Theory, Berhaviorism, Construtivism, Cognitivism, CMMI, MSP.BR, Software Development Process

Sum´ ario Lista de Figuras

10

Lista de Tabelas

12

Cap´ıtulo 1 Introdu¸c˜ ao 1.1 Contextualiza¸c˜ao . . . 1.2 Hip´oteses . . . . . . . 1.3 Objetivos . . . . . . . 1.4 Justificativa . . . . . . 1.5 Estrutura do Trabalho

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

14 14 21 21 22 23

Cap´ıtulo 2 Modelagem de Processo e Melhoria de Processo 2.1 Modelos de Ciclo de Vida de Desenvolvimento de Software . 2.1.1 Modelo de Ciclo de Vida em Cascata . . . . . . . . . 2.1.2 Modelo de Ciclo de Vida em V . . . . . . . . . . . . 2.1.3 Modelo de Ciclo de Vida Incremental . . . . . . . . . 2.1.4 Modelos de Ciclo de Vida Iterativos . . . . . . . . . . 2.1.5 Modelo de Ciclo de Vida em Espiral . . . . . . . . . ´ 2.1.6 Processos Ageis . . . . . . . . . . . . . . . . . . . . . 2.2 Modelos de Qualidade de Processo de Software . . . . . . . . 2.2.1 Modelo CMM/CMMI . . . . . . . . . . . . . . . . . . 2.2.2 Modelo MPS.BR . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

24 24 25 26 27 28 28 29 31 31 36

Cap´ıtulo 3 Teorias de Aprendizagem 3.1 Behaviorismo . . . . . . . . . . . . . 3.1.1 Behaviorismo Metodol´ogico . 3.1.2 Behaviorismo Radical . . . . . 3.2 Construtivismo . . . . . . . . . . . . 3.3 Cognitivismo . . . . . . . . . . . . . 3.3.1 Condi¸c˜oes para Aprendizagem

. . . . . .

. . . . . .

. . . . . .

38 38 38 39 41 43 44

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Significativa

. . . . . .

. . . . . .

. . . . . .

Cap´ıtulo 4 Estudo de Caso 4.1 A Empresa Pesquisada . . . . . . . . . . . . . . . . . . ´ 4.2 A Area de TI do Banco Y . . . . . . . . . . . . . . . . 4.3 A Busca pela Melhoria de Processo de Desenvolvimento 4.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Tratamento dos Dados da Pesquisa . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . . de Software . . . . . . . . . . . .

46 46 47 48 51 55

4.6

. . . . . .

55 56 74 77 77 80

Cap´ıtulo 5 Considera¸c˜ oes Finais 5.1 Conclus˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Limita¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 S´ıntese de Sugest˜oes para Pesquisas Futuras . . . . . . . . . . . .

89 89 90 90

Referˆ encias

92

Apˆ endice A Email de convoca¸ c˜ ao para participa¸ c˜ ao na pesquisa

94

4.7

Resultados Obtidos . . . . . . . . . . . . . . . . 4.6.1 Dados Agrupados Por Quest˜ao . . . . . 4.6.2 Dados da Popula¸c˜ao . . . . . . . . . . . Discuss˜ao dos Resultados . . . . . . . . . . . . . 4.7.1 Resultados por Dom´ınio Individual . . . 4.7.2 Resultado da Rela¸c˜ao entre os Dom´ınios

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Apˆ endice B Question´ ario enviado ` as Gerˆ encias de TI do Banco Y 96

9

Lista de Figuras Modelo Modelo Modelo Modelo

4.1

Ranking das Maiores Institui¸c˜oes Financeiras - Receitas/Agencias/Funcion´arios - Fonte: Banco Central do Brasil . . . . . . . . . . . . . . . . . . 46 Estrutura Organizacional de TI do Banco Y. . . . . . . . . . . . . 47 Disciplinas do Modelo de Processo PDS-BY. . . . . . . . . . . . . 49 Popula¸c˜ao e Amostra da Pesquisa. . . . . . . . . . . . . . . . . . . 52 Escala da Pesquisa. . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Quest˜oes X Dom´ınios. . . . . . . . . . . . . . . . . . . . . . . . . 53 Histograma das Respostas `a Quest˜ao 1. . . . . . . . . . . . . . . . 56 Histograma das Respostas `a Quest˜ao 2. . . . . . . . . . . . . . . . 57 Histograma das Respostas `a Quest˜ao 3. . . . . . . . . . . . . . . . 58 Histograma das Respostas `a Quest˜ao 4. . . . . . . . . . . . . . . . 59 Histograma das Respostas `a Quest˜ao 5. . . . . . . . . . . . . . . . 60 Histograma das Respostas `a Quest˜ao 6. . . . . . . . . . . . . . . . 61 Histograma das Respostas `a Quest˜ao 7. . . . . . . . . . . . . . . . 62 Histograma das Respostas `a Quest˜ao 8. . . . . . . . . . . . . . . . 63 Histograma das Respostas `a Quest˜ao 9. . . . . . . . . . . . . . . . 64 Histograma das Respostas `a Quest˜ao 10. . . . . . . . . . . . . . . 65 Histograma das Respostas `a Quest˜ao 11. . . . . . . . . . . . . . . 66 Histograma das Respostas `a Quest˜ao 12. . . . . . . . . . . . . . . 67 Histograma das Respostas `a Quest˜ao 13. . . . . . . . . . . . . . . 68 Histograma das Respostas `a Quest˜ao 14. . . . . . . . . . . . . . . 69 Histograma das Respostas `a Quest˜ao 15. . . . . . . . . . . . . . . 70 Histograma das Respostas `a Quest˜ao 16. . . . . . . . . . . . . . . 71 Histograma das Respostas `a Quest˜ao 17. . . . . . . . . . . . . . . 72 Histograma das Respostas `a Quest˜ao 18. . . . . . . . . . . . . . . 73 Histograma de Faixa Et´aria Gerˆencia A. . . . . . . . . . . . . . . 74 Histograma de Faixa Et´aria Gerˆencia B. . . . . . . . . . . . . . . 74 Histograma de Faixa Et´aria Gerˆencia C. . . . . . . . . . . . . . . 75 Histograma de Faixa Et´aria Gerˆencia D. . . . . . . . . . . . . . . 75 ´ Histograma do Tempo na Area de TI do Banco - Gerˆencia A. . . 75 ´ Histograma do Tempo na Area de TI do Banco - Gerˆencia B. . . . 76 ´ Histograma do Tempo na Area de TI do Banco - Gerˆencia C. . . . 76

4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 4.29 4.30 4.31

Cascata. [1] . V. [1] . . . . Iterativo. [1] Espiral. [1] .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

26 27 28 29

2.1 2.2 2.3 2.4

4.32 4.33 4.34 4.35 4.36 4.37 4.38 4.39 4.40 4.41 4.42 4.43 4.44

´ Histograma do Tempo na Area de TI do Banco - Gerˆencia D. Gr´afico de Dispers˜ao ET x CN para a Gerˆencia A . . . . . . . Gr´afico de Dispers˜ao ET x CN para a Gerˆencia B. . . . . . . Gr´afico de Dispers˜ao ET x CN para a Gerˆencia C . . . . . . . Gr´afico de Dispers˜ao ET x CN para a Gerˆencia D . . . . . . . Gr´afico de Dispers˜ao CP x ET para a Gerˆencia A . . . . . . . Gr´afico de Dispers˜ao CP x ET para a Gerˆencia B . . . . . . . Gr´afico de Dispers˜ao CP x ET para a Gerˆencia C . . . . . . . Gr´afico de Dispers˜ao CP x ET para a Gerˆencia D . . . . . . . Gr´afico de Dispers˜ao CP x CN para a Gerˆencia A . . . . . . . Gr´afico de Dispers˜ao CP x CN para a Gerˆencia B . . . . . . . Gr´afico de Dispers˜ao CP x CN para a Gerˆencia C . . . . . . . Gr´afico de Dispers˜ao CP x CN para a Gerˆencia D . . . . . . .

11

. . . . . . . . . . . . .

. . . . . . . . . . . . .

76 80 81 81 82 83 84 84 85 86 86 87 88

Lista de Tabelas 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19

Respostas `a Quest˜ao 1 . Respostas `a Quest˜ao 2 . Respostas `a Quest˜ao 3 . Respostas `a Quest˜ao 4 . Respostas `a Quest˜ao 5 . Respostas `a Quest˜ao 6 . Respostas `a Quest˜ao 7 . Respostas `a Quest˜ao 8 . Respostas `a Quest˜ao 9 . Respostas `a Quest˜ao 10 Respostas `a Quest˜ao 11 Respostas `a Quest˜ao 12 Respostas `a Quest˜ao 13 Respostas `a Quest˜ao 14 Respostas `a Quest˜ao 15 Respostas `a Quest˜ao 16 Respostas `a Quest˜ao 17 Respostas `a Quest˜ao 18 Coeficiente de Correla¸c˜ao CN . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . entre as Vari´aveis de Dom´ınio . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ET, CP e . . . . . .

56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 88

Lista de Siglas CM M I SOF T EX COP P E − U F RJ CESAR CEnP RA CELEP AR CISC M BA P DS − BY CP ET M P S.BR CN SW EBOK RISC CM M W esCon RU P XP SEI SCAM P I

Capability Maturity Model Integration, Associa¸c˜ao para Promo¸c˜ao da Excelˆencia do Software Brasileiro, Coordena¸c˜ao de Programas de P´os-Gradua¸c˜ao de Engenharia da Universidade Federal do Rio de Janeiro, Centro de Estudos e Sistemas Avan¸cados do Recife, Centro de Pesquisas Renato Archer, Companhia de Inform´atica do Paran´a, Complex Instruction Set Computer , Master of Business Administration, Processo de Desenvolvimento de Software do Banco Y, Cultura em Processos, Efetividade dos Treinamentos, Melhoria de Processo de Software Brasileiro, Conformidade do Processo, Software Engineering Body of Knowledge, Reduced Instruction Set Computer , Capability Maturity Model , Western Electronic Show and Convention of IEEE , Rational Unified Process, Extreme Programming, R Software Engineering Institute, The Carnegie Mellon Standard CMMI Appraisal Method for Process Improvement,

13

p. 6 p. 37 p. 37 p. p. p. p. p. p. p. p. p. p. p. p. p. p. p. p. p. p.

37 37 37 49 49 50 52 53 6 53 59 18 19 26 29 31 33 34

Cap´ıtulo 1 Introdu¸ c˜ ao 1.1

Contextualiza¸ c˜ ao

Organiza¸c˜oes, segundo Hampton [2], s˜ao uma combina¸c˜ao intencional de pessoas e de tecnologia para atingir um determinado objetivo, ou de uma outra forma, s˜ao sistemas de recursos que procuram realizar algum tipo de objetivo [3] e [4]. Podemos aplicar o conceito e verificar que uma empresa ´e uma organiza¸c˜ao, assim como o s˜ao seus departamentos, divis˜oes, se¸c˜oes e gerˆencias. Estas defini¸c˜oes poderiam nos levar a imaginar as organiza¸c˜oes como entidades bastante simples, o que na realidade n˜ao ´e verdade. Segundo Maximiano [3], toda organiza¸c˜ao existe com a finalidade de fornecer alguma combina¸c˜ao de produtos e servi¸cos, sendo portanto de uma forma geral este o seu objetivo organizacional. Apesar da defini¸c˜ao geral de organiza¸c˜ao n˜ao ter mudado em todos estes anos, as formas de atingir o seu objetivo organizacional o tem, como um reflexo das mudan¸cas ocorridas nos mercados e nas sociedades em que est˜ao inseridas que criaram novas necessidades por produtos e servi¸cos. Na dimens˜ao sociedade, v´arios autores demonstram a mudan¸ca da sociedade baseada no capital para outra baseada no conhecimento, onde o que tem valor e diferencia os indiv´ıduos n˜ao s˜ao suas caracter´ısticas f´ısicas, ou simplesmente financeiras, mas o seu conhecimento, ou seja a sua capacidade de reagir aos mesmos dados e informa¸c˜oes a que outros tˆem acesso, por´em de formas mais produtivas e lucrativas [5] e [6]. Nesta sociedade, os fatores de produ¸c˜ao cl´assicos, Terra (ou recursos naturais), M˜ao-de-Obra (ou trabalho) e Capital, n˜ao deixaram de existir mas passaram para um segundo plano, sendo obtidos com facilidade atrav´es do aplica¸c˜ao de conhecimento como recurso chave, segundo Peter Drucker [5]. Do ponto de vista das organiza¸c˜oes, n˜ao ´e diferente, e vemos o efeito desta mudan¸ca de paradigma, do capital para o conhecimento, quando constatamos, por exemplo, que diversas empresas (Microsoft, Google, Amazon.com, Nokia, etc) tˆem valor de mercado muito superior ao valor do seu patrimˆonio f´ısico, pois incorporam outros fatores como sua capacidade de inova¸c˜ao, talento e experiˆencia de seus funcion´arios, rela¸c˜oes com seus clientes, etc. [6]. A aplica¸c˜ao do co14

nhecimento aos mais diversos ramos de neg´ocio ´e o que possibilita que pequenas empresas, com pouca disponibilidade dos trˆes fatores cl´assicos da produ¸c˜ao, j´a citados, mas com id´eias inovadoras resultantes desta aplica¸c˜ao de conhecimento, surjam praticamente do nada e abocanhem fatias consider´aveis do mercado onde se inserem em pouco tempo, muitas vezes desbancando grandes concorrentes, que por um motivo ou por outro n˜ao conseguem reagir a tempo. Segundo Maximiano, o conhecimento ´e apontado como uma das vantagens competitivas que permitem a uma organiza¸c˜ao enfrentar com ˆexito as mudan¸cas e a concorrˆencia [3]. Nesse contexto as organiza¸c˜oes perceberam a necessidade de gerir o conhecimento modelando processos que permitam governar sua cria¸c˜ao, dissemina¸c˜ao e utiliza¸c˜ao, e estabelecendo fluxos de convers˜ao de conhecimento t´acito (presente nos indiv´ıduos da organiza¸c˜ao) em expl´ıcito, dispon´ıvel a todos os indiv´ıduos que devam ter acesso a ele [6]. Na dimens˜ao Mercado, a globaliza¸c˜ao pode ser citada como um dos principais fatores que desencadearam um forte processo de acirramento da concorrˆencia em diversos n´ıveis e mercados, for¸cando as empresas a se preocuparem cada vez mais com sua produtividade e com a qualidade de seus produtos e servi¸cos para sua sobrevivˆencia. Mas a qualidade e a produtividade de uma organiza¸c˜ao dependem, segundo a literatura [7] e [8], de trˆes fatores: pessoas, processos e tecnologias. As pessoas, participantes ativas do processo produtivo, detˆem muitas vezes boa parte do conhecimento estrat´egico necess´ario para a continuidade dos neg´ocios com n´ıveis aceit´aveis de qualidade e produtividade. As tecnologias, ou ferramentas, viabilizam a aplica¸c˜ao do conhecimento e do trabalho das pessoas, e muitas vezes s˜ao o meio pelo qual as empresas disponibilizam e/ou suportam o seu produto/servi¸co no mercado. E finalmente os processos organizacionais, que numa defini¸c˜ao geral s˜ao conjuntos de passos parcialmente ordenados, constitu´ıdos por atividades, m´etodos, pr´aticas e transforma¸c˜oes, usados para atingir uma meta [8], neste caso, e em u ´ltima instˆancia, os objetivos organizacionais. V´arios s˜ao os processos organizacionais que v˜ao de processos de planejamento, controle, execu¸c˜ao, gest˜ao, produ¸c˜ao, a processos de desenvolvimento de software e processos decis´orios, n˜ao limitando-se aos aqui citados. Na manuten¸c˜ao dos n´ıveis de qualidade e produtividade, o foco de investimento nos processos ´e recomendado [7], dada a velocidade com que as tecnologias surgem e tornam-se obsoletas e do fato de ser senso comum que pessoas eventualmente saem das organiza¸c˜oes, quer por morte, aposentadoria ou mesmo a troca ´ um fato hoje que a maioria das pessoas tˆem v´arios empregos ao de emprego. E longo de suas carreiras. Os processos organizacionais s˜ao uma representa¸c˜ao do conhecimento de como realizar uma determinada tarefa que pode ser fundamental para o neg´ocio da organiza¸c˜ao, de forma que tornam-se o elo de liga¸c˜ao entre os dois outros fatores fazendo o conjunto funcionar [7]. A defini¸c˜ao de processos organizacionais, ´e portanto, uma importante estra15

t´egia de gest˜ao de conhecimento voltada para transformar o conhecimento t´acito das pessoas que passam pela organiza¸c˜ao, em conhecimento expl´ıcito dispon´ıvel e usado coletivamente por todos que precisam executar a tarefa alvo do processo. O foco no Processo de Desenvolvimento de Software neste trabalho ´e motivado pelo fato de que v´arias empresas tˆem seu neg´ocio fortemente relacionado e dependente dos seus sistemas de informa¸c˜ao. Muitas destas organiza¸c˜oes, mesmo n˜ao tendo na produ¸c˜ao de software a sua atividade fim, mant´em equipes de desenvolvimento de software internamente e portanto tˆem a qualidade de seus produtos e servi¸cos fortemente associada `a capacidade de suas equipes desenvolverem e manterem softwares com qualidade. Como exemplos de organiza¸c˜oes deste tipo podemos citar institui¸c˜oes financeiras, operadoras de cart˜ao de cr´edito, empresas de transporte a´ereo, empresas de telefonia, dentre outras, que dada a abrangˆencia e caracter´ıstica dos seus neg´ocios simplesmente n˜ao podem operar sem seus sistemas de informa¸c˜ao, tornando o conhecimento associado a ”como desenvolver software de qualidade”crucial para a manuten¸c˜ao de n´ıveis aceit´aveis de competitividade e resultado. O software desenvolvido, por ser o principal produto do processo de desenvolvimento utilizado, tem sua qualidade associada `a capacidade do processo que o gerou. ”... the quality of a system or product is highly influenced by the quality of the process used to develop and maintain it”[7]. Esse processo, portanto, precisa garantir a obten¸c˜ao de resultados previs´ıveis e principalmente aceit´aveis. Por´em, nem sempre este ´e o caso. Muitas vezes o processo usado n˜ao est´a aderente aos padr˜oes de mercado de maturidade ou mesmo resumem-se a uma sequˆencia pouco consistente de passos que n˜ao garantem os resultados esperados, quando utilizados na constru¸c˜ao de um sistema de inform´atica, sua evolu¸c˜ao ou manuten¸c˜ao. Num cen´ario pior, mas bastante comum, a organiza¸c˜ao como um todo nem possui um processo de desenvolvimento de software definido, ou seja, documentado [8]. Cada equipe (n´ ucleo, divis˜ao, gerˆencia, etc) implementa na pr´atica o seu pr´oprio processo, ou ainda, cada indiv´ıduo pode isoladamente executar um processo de desenvolvimento de software qualquer. Nesse cen´ario, h´a uma grande tendˆencia de que estes processos sejam bem diferentes entre si. Essa divergˆencia de processos est´a relacionada a aspectos inerentes a cada uma das equipes consideradas, que podem apresentar as mais diversas combina¸c˜oes de fatores como os citados a seguir: • Uso de diferentes tecnologias: Web, DataWarehouse, Java, Grid Computing; • Desenvolvimento em plataformas muito diferentes: sistemas desenvolvidos para execu¸c˜ao em mainframes (em algumas organiza¸c˜oes denominada plataforma alta), ou em servidores microprocessados dedicados baseados em 16

arquiteturas RISC. Ou ainda sistemas desenvolvidos para serem executados em microcomputadores numa configura¸c˜ao stand alone ou cliente/servidor; • Estilo de Gerˆencia: gerˆencias que valorizam a cria¸c˜ao, implanta¸c˜ao, padroniza¸c˜ao e evolu¸c˜ao de um modelo de processo, versus gerˆencias que n˜ao se preocupam com a defini¸c˜ao de um processo. Equipes matriciais que levam `a existˆencia de m´ ultiplas gerˆencias; • Forma¸c˜ao Acadˆemica da Equipe: Forma¸c˜ao mais recente onde houve foco em engenharia de software, versus, forma¸c˜ao mais antiga, cujo foco n˜ao era dado no processo e sim no produto. Ou ainda forma¸c˜ao em outras ´areas, pouco relacionadas `a inform´atica, com o aprendizado individual nesta ´area ocorrido dentro do mercado de trabalho; • Clientes e Intervenientes: Internos e Externos (´org˜aos reguladores, outras institui¸c˜oes, etc); • Idade associada aos sistemas geridos pelas equipes: N˜ao ´e incomum, em alguns segmentos, a existˆencia de sistemas com mais de 30 anos de desenvolvimento, escritos em linguagens estruturadas (COBOL, NATURAL, etc) voltadas para alta plataforma e cujos profissionais que os mant´em, por conhecerem muito bem o c´odigo j´a escrito, costumam n˜ao valorizar etapas importantes como o levantamento de requisitos, o testes de sistema, a documenta¸c˜ao, a an´alise t´ecnica e conceitual, focando muito mais no desenvolvimento direto; • Paradigmas de desenvolvimento: Orienta¸c˜ao a objetos, a servi¸cos, programa¸c˜ao estruturada. ´ necess´ario, portanto, prover a melhoria do processo de desenvolvimento de E software usado elevando-o a n´ıveis de maturidade mais altos. Mas os fatores citados acima, podem servir de grandes dificultadores ao alcance desta meta, pois, ´ segundo PADUA, ”processos imaturos s˜ao baseados na improvisa¸c˜ao individual. Eles fomentam nas pessoas mal-informadas sensa¸c˜oes de liberdade, criatividade e at´e poder que na realidade s˜ao ilus´orias, porque pagas com riscos, incerteza e desperd´ıcio”[8]. Fazendo uma compara¸c˜ao entre as teorias de aprendizagem humanas e o caso da melhoria de processo de desenvolvimento de software nas organiza¸c˜oes, podemos verificar a existˆencia de uma rela¸c˜ao que pode favorecer a conquista de melhores resultados no campo da melhoria de processos. No caso do ser humano, define-se o conhecimento como sendo uma abstra¸ca˜o interior e pessoal de alguma coisa que foi experimentada por algu´em, ou seja, algo subjetivo inerente `a vivˆencia dos indiv´ıduos e ao processo de aprendizagem a ela associado. V´arias teorias, que est˜ao detalhadas em se¸c˜oes seguintes, destinamse ao estudo de como a aprendizagem humana ocorre. A aprendizagem em si ´e definida como sendo um ”processo pelo qual uma atividade tem origem ou ´e modificada pela rea¸c˜ao a uma situa¸c˜ao encontrada”[9], ou ainda, ”´e a organiza¸c˜ao 17

e integra¸c˜ao de material `a estrutura cognitiva”[10], ou na vis˜ao de Ausubel ”´e o processo pelo qual um novo conhecimento ancora-se a outros pr´e-existentes produzindo um novo conhecimento `a partir da modifica¸c˜ao do conhecimento anterior e do novo”[11]. O termo estrutura cognitiva ´e usado para definir o ”conte´ udo total de id´eias de um certo indiv´ıduo e sua organiza¸c˜ao, ou conte´ udo e organiza¸c˜ao de suas id´eias em uma ´area particular de conhecimentos”[10]. Muito estudo ´e realizado com o objetivo de desenvolver metodologias de ensino que favore¸cam o processo de aprendizagem em diversos contextos, considerando o p´ ublico alvo e sua realidade. No campo organizacional, define-se que o conhecimento reside em documentos, nas bases de dados e sistemas de informa¸c˜ao, nas tecnologias desenvolvidas, nos processos de neg´ocio, nas pr´aticas dos grupos e na experiˆencia acumulada pelas pessoas [6] e [3]. Tomando por base a defini¸c˜ao de que a aprendizagem consiste num processo em que um novo conhecimento interage com outro preexistente modificando-o e produzindo um novo conhecimento diferente de ambos os insumos, e de que um processo (no contexto deste trabalho o processo de desenvolvimento de software) ´e um conhecimento no ˆambito organizacional, podemos concluir que neste ˆambito o processo de melhoria de processos de desenvolvimento de software ´e uma forma de aprendizagem organizacional, vez que ocorre uma altera¸c˜ao de um conhecimento existente (o processo anterior) baseado num novo conhecimento (um modelo de processo mais maduro) resultando num processo implementado novo que nem ´e o processo inicial e nem um processo igual ao modelo proposto, estando por´em mais pr´oximo deste. Os modelos de maturidade (CMM, MPS.BR, etc), por tra¸carem estrat´egias que viabilizam a modifica¸c˜ao dos processos atuais em dire¸c˜ao a modelos de processo mais capazes, e portanto catalizam o aprendizado organizacional funcionam como metodologias de ensino aprendizagem organizacionais no ˆambito dos processos de desenvolvimento de software. O processo real de desenvolvimento de software, interpretado como um conhecimento adquirido pela organiza¸c˜ao, parece numa primeira an´alise n˜ao depender da dimens˜ao Pessoas vez que, teoricamente, ´e conhecimento que n˜ao reside nos indiv´ıduos propriamente ditos. A sa´ıda de um indiv´ıduo da organiza¸c˜ao, bem como a chegada de um novo, n˜ao altera o processo de desenvolvimento de software utilizado, pois o novo indiv´ıduo incorpora o conhecimento representado no processo atrav´es de qualquer mecanismo conhecido, seja por imita¸c˜ao ou mesmo atrav´es da documenta¸c˜ao dispon´ıvel. V´arias teorias de aprendizagem, ver cap´ıtulo sobre Teorias de Aprendizagem, evidenciam que, no contexto humano, a aprendizagem depende do conhecimento anterior que o indiv´ıduo possui e salientam a importˆancia do meio e de fatores culturais, hist´oricos e sociais nesta aprendizagem. Ou seja, afirmam que o que ´e 18

aprendido por um indiv´ıduo ´e um resultado da intera¸c˜ao do novo conhecimento, com a estrutura cognitiva existente passando por processos de interioriza¸c˜ao que filtram e personalizam o entendimento do novo conhecimento de acordo com a cultura do indiv´ıduo, desenvolvida ao longo de sua vida atrav´es da troca de experiˆencia com o meio. Sendo assim, dadas as rela¸c˜oes existentes entre asp´ectos da aprendizagem humana e da aprendizagem organizacional, ser´a que a cultura organizacional, entendida como o conjunto de valores, cren¸cas e conhecimentos que os indiv´ıduos da organiza¸c˜ao possuem, tamb´em influencia a aprendizagem organizacional, da mesma forma que a cultura do aprendiz influencia sua aprendizagem individual? Quando falamos em melhoria de processos, ou seja, em aprendizagem organizacional, estamos falando de mudan¸ca, e os agentes da mudan¸ca est˜ao precisamente dentro da dimens˜ao Pessoas, vez que s˜ao elas que executar˜ao o novo processo. Antˆonio Cury afirma que ”por mais bem projetado que seja um processo, s˜ao as pessoas que o fazem funcionar”[12]. Davenport, acrescenta ainda que ”para que a mudan¸ca num processo tenha ˆexito o aspecto humano da mudan¸ca n˜ao pode ficar entregue `a autogest˜ao, e que as quest˜oes organizacionais e de recursos humanos s˜ao mais importantes que as quest˜oes de tecnologia para as mudan¸cas de comportamento que devem ocorrer dentro de um processo”[13]. A incorpora¸c˜ao do novo conhecimento, em termos organizacionais, depender´a de o novo processo, teoricamente mais maduro, ser repetidamente executado por todos os indiv´ıduos da organiza¸c˜ao, envolvidos com a tarefa afetada pelo processo, at´e que por repeti¸c˜ao, ou por entendimento de seu real valor, este conhecimento se enra´ıze de tal forma que seja executado de forma natural, passando a integrar a estrutura cognitiva da organiza¸c˜ao. P´adua, sugere que todos os que ser˜ao afetados pelas mudan¸cas de processos sejam envolvidos, e acrescenta ainda que o treinamento ´e fundamental, pois a mudan¸ca de processos envolve a absor¸c˜ao de novos conceitos muitas vezes contr´arios `a intui¸c˜ao de algumas pessoas [8]. Apesar desta referˆencia, a literatura de uma forma geral dedica pouca aten¸c˜ao `a componente Pessoas, e talvez por este motivo tantas empresas foquem seus esfor¸cos em definir modelos de processo de desenvolvimento de software mais capazes e em implant´a-los o mais rapidamente poss´ıvel, muitas vezes sem dar aten¸c˜ao suficiente ao treinamento dos envolvidos. O resultado desta estrat´egia, muitas vezes, ´e um modelo bom, com uma efetividade p´essima, em virtude das pessoas, e em u ´ltima instˆancia da organiza¸c˜ao, possuir uma cultura aderente ao modus operandi anterior muitas vezes n˜ao favor´avel ao uso de processos de desenvolvimento de software definidos. O termo cultura, aqui introduzido, deve-se `a defini¸c˜ao mais ampla a que remete. Kisil, define a cultura organizacional como um conjunto de cren¸cas e valores compartilhados que influenciam a vida organizacional, uma forma aceita de intera¸c˜ao e de relacionamento t´ıpicos de determinada organiza¸c˜ao, definindo grande parte do seu comportamento [14]. Cury, acrescenta ainda que a cultura organizacional compreende, al´em das normas formais, tamb´em o conjunto de regras n˜ao escritas, que condicionam as atitudes tomadas pelas pessoas dentro da organiza¸c˜ao [12]. 19

As pessoas, por crerem em seus processos individuais, por acharem que esses levam ao sucesso no desenvolvimento de suas atividades, e por n˜ao acreditarem, muitas vezes, que algumas etapas do novo processo agregam qualquer valor ao seu trabalho e que muitas vezes o atrapalham, acabam focando seus esfor¸cos em gerar evidˆencias de que est˜ao executando o novo processo, estando de fato ainda executando um processo muito mais pr´oximo do antigo do que do novo. As evidˆencias aqui referenciadas s˜ao os itens mais facilmente audit´aveis do processo de desenvolvimento de software: os artefatos. Ao acreditarem que uma disciplina (corpo de conhecimentos encerrados numa fase do processo – ver cap´ıtulo Modelos de Processo neste trabalho) n˜ao ´e necess´aria ou adequada, limitam-se a registrar o m´ınimo de informa¸c˜oes poss´ıvel nos artefatos previstos nesta disciplina, com o objetivo de os depositarem nos reposit´orios corporativos determinados pelo processo com a certeza absoluta de que nunca mais ser˜ao consultados, transformando-os em produtos in´ uteis do processo executado, e refor¸cando o descr´edito no pr´oprio processo. Poder´ıamos, neste ponto, afirmar que esse comportamento poderia ser corrigido com a devida auditoria do processo com foco na qualidade dos artefatos e na sua rastreabilidade dentro do pr´oprio processo. Mas, na pr´atica, verifica-se que ´e muito dif´ıcil, em grandes organiza¸c˜oes como a descrita no estudo de caso deste trabalho, identificar um desvio do processo quando h´a um esfor¸co intencional das pessoas em fazer parecer que o est˜ao executando, e principalmente quando essas pessoas acreditam que este comportamento ´e saud´avel para a pr´opria organiza¸c˜ao. Cury, afirma que ”´e for¸coso reconhecer que, em toda interven¸c˜ao, as mudanc¸as s´o ser˜ao permanentes, profundas, bem-sucedidas, se atingirem a cultura da organiza¸c˜ao”[12]. Desta forma, para que haja de fato melhoria de processo de desenvolvimento de software, ´e imprescind´ıvel o esfor¸co organizacional em mudar a cultura dos envolvidos para uma cultura que inclua o uso do processo, que o valorize, uma cultura de processos. Essa mudan¸ca pode ser favorecida pelo investimento institucional em formac¸˜ao das pessoas envolvidas com a atividade de desenvolvimento de software, com o objetivo de dot´a-las de conhecimentos na ´area de engenharia de software e de processos, permitindo que desenvolvam uma base informacional que os permita questionar seu processo de desenvolvimento e identificar o valor associado aos modelos propostos, normalmente mais aderentes `a modelos de maturidade conhecidos. Kisil, afirma que: ”... essa mudan¸ca pode se dar pela aquisi¸c˜ao de novos conhecimentos, novas habilidades para a realiza¸c˜ao de tarefas, novas atitudes, refletindo novos valores organizacionais”. [14] Muitas s˜ao as alternativas corporativas para esta forma¸c˜ao, que v˜ao de investimentos em cursos presenciais, internos e externos, cursos via WEB ou disponibilizados na Intranet corporativa, mudan¸cas no processo de contrata¸c˜ao focando a aquisi¸c˜ao de talentos fluentes em engenharia de software, especializa¸c˜ao de equipes 20

por disciplina para suporte ao desenvolvimento das atividades das demais equipes funcionando como agentes de mudan¸ca, financiamento de cursos de gradua¸c˜ao e p´os-gradua¸c˜ao aos funcion´arios na ´area de engenharia de software, cria¸c˜ao de pol´ıticas de ascens˜ao profissional que mapeiem a forma¸c˜ao e o conhecimento de engenharia de software e processos, dentre outras. Por´em, um estudo sobre metodologias de ensino-aprendizagem que sejam mais adequadas `as idiossincrasias dos paradigmas organizacionais torna-se desej´avel, como uma forma de maximizar os resultados desejados e o retorno de tal investimento.

1.2

Hip´ oteses

A - A melhoria de processos de desenvolvimento de software depende do investimento n˜ao s´o na modelagem de um processo de maior capacidade segundo modelos de maturidade, como CMMI e MPS.BR, mas tamb´em no investimento na forma¸c˜ao de uma cultura em processos na organiza¸c˜ao. B - A cria¸c˜ao de uma cultura em processos, no contexto de desenvolvimento de software em organiza¸c˜oes, mesmo naquelas onde a atividade de desenvolvimento de software n˜ao seja a sua atividade fim, pode ser potencializada pelo investimento em treinamentos e cursos acerca de engenharia de software e nas disciplinas abordadas em seu modelo de processo.

1.3

Objetivos

As empresas vˆem cada vez mais utilizando a tecnologia da informa¸c˜ao para melhoria do seu processo produtivo atrav´es do desenvolvimento de ferramentas de suporte operacional que contribuam para agilizar as suas atividades administrativas e obter dados estat´ısticos. O processo de desenvolvimento de software em grandes corpora¸c˜oes requer a utiliza¸c˜ao n˜ao s´o de ferramentas de desenvolvimento como tamb´em de ferramentas que permitam a implanta¸c˜ao de modelos de desenvolvimento de softwares que mantenham a unicidade de sua produ¸c˜ao. A implanta¸c˜ao desses modelos se torna ainda mais necess´aria nas empresas que n˜ao tem como atividade fim o desenvolvimento de software visto que eventuais deficiˆencias da solu¸c˜ao tecnol´ogica podem ser mascaradas pelo eventual sucesso do produto ou servi¸co que est´a sendo oferecido. Este trabalho tem como objetivo demonstrar que, num processo de melhoria de processos de desenvolvimento de software e considerando tal melhoria como uma forma de aprendizagem organizacional, os resultados obtidos com tal ten21

tativa de melhoria, quais sejam a execu¸c˜ao de processos de desenvolvimento de software reais mais pr´oximos de um modelo tido como mais capaz, mant´em uma rela¸c˜ao direta com a cultura em processos desenvolvida no componente Pessoas da organiza¸c˜ao em quest˜ao. Dentro do contexto de cultura em processos, pretendemos mostrar que os investimentos organizacionais na cria¸c˜ao desta cultura na forma de treinamentos e cursos podem incrementar o potencial de sucesso da melhoria de processos de desenvolvimento de software evidenciado pela execu¸c˜ao de um processo real mais pr´oximo do modelo proposto. Sugerindo a ado¸c˜ao de uma estrat´egia para o uso desta evidˆencia como catalizador da melhoria de processos desejada.

1.4

Justificativa

A utiliza¸c˜ao de modelos como o CMMI ou MPS.BR facilitam a implanta¸c˜ao de programas de melhoria de processos de desenvolvimento de software atrav´es da aplica¸c˜ao de metodologias pedag´ogicas embasadas em teorias de aprendizagem adequadas. Al´em de facilitar a implanta¸c˜ao de programas de melhoria, a utiliza¸c˜ao desses modelos tamb´em proporciona a padroniza¸c˜ao dos procedimentos de produ¸c˜ao, permitindo uma vis˜ao mais ampla dos diversos projetos em andamento, proporcionando ganhos no gerenciamento das equipes e uma maior intera¸c˜ao entre elas permitindo o deslocamento de seus membros refor¸cando as ´areas mais priorit´arias de acordo com as necessidades de neg´ocio da empresa. As vantagens obtidas com a implementa¸c˜ao desses modelos s˜ao imediatamente percebidas com a melhoria da qualidade dos trabalhos de desenvolvimento, implanta¸c˜ao e melhoria de software e na redu¸c˜ao do tempo de implanta¸c˜ao das novas solu¸c˜oes. Para empresas que atuam em um setor t˜ao competitivo como o segmento financeiro nacional todos os ganhos obtidos com a implanta¸c˜ao desses modelos se tornam de extrema importˆancia para que suas solu¸c˜oes tecnol´ogicas e seus produtos se tornem um diferencial no mercado. Os estudos sobre como as empresas aplicam a disciplina Engenharia de Software dentro de seu processo de desenvolvimento s˜ao escassos, o que nos motivou a desenvolver esse tema para obtermos uma melhor percep¸c˜ao do problema objeto de estudo neste trabalho. O estudo de caso da empresa sob an´alise proporcionar´a um enriquecimento do tema devido as suas particularidades pois a empresa est´a sujeita a r´ıgidos controles estatais inclusive quanto ao cumprimento de prazos legais que, na maioria das vezes, retardam os seus processos em rela¸c˜ao `a concorrˆencia.

22

1.5

Estrutura do Trabalho

Este trabalho ´e composto por cinco cap´ıtulos. O primeiro cap´ıtulo, introdut´orio, ´e composto de: (1.1) Contextualiza¸c˜ao; (1.2) Hip´oteses; (1.3) Objetivos; (1.4) Justificativa; e (1.5) Estrutura do Trabalho. O segundo cap´ıtulo, destinado `a revis˜ao te´orica de Modelos de Processo e Qualidade de Processos que embasam a presente pesquisa, corresponde: (2.1) Modelos de Ciclo de Vida de Desenvolvimento de Software; e (2.2) Modelos de Qualidade de Processo de Software. O Terceiro cap´ıtulo, destinado `a revis˜ao te´orica das Teorias de Aprendizagem que tamb´em embasam a presente pesquisa, corresponde: (3.1) Behaviorismo; (3.2) Construtivismo; e (3.3) Cognitivismo. O quarto cap´ıtulo, est´a a apresenta¸c˜ao do estudo de caso com a coleta e an´alise dos dados, subdividida em: (4.1) A Empresa Pesquisada; (4.2) A ´area de TI do Banco Y; (4.3) A Busca pela Melhoria de Processo de Desenvolvimento de Software; (4.4) Metodologia;(4.5) Tratamento dos Dados da Pesquisa; (4.6) Resultados Obtidos e (4.7) Discuss˜ao dos Resultados. O quinto cap´ıtulo ´e destinado `as considera¸c˜oes finais e descreve: (5.1) Conclus˜ao; (5.2) Limita¸c˜oes; (5.3) S´ıntese de sugest˜oes para pesquisas futuras.

23

Cap´ıtulo 2 Modelagem de Processo e Melhoria de Processo 2.1

Modelos de Ciclo de Vida de Desenvolvimento de Software

”Podemos considerar um conjunto de tarefas ordenadas como sendo um processo: uma s´erie de etapas que envolvem atividades, restri¸c˜oes e recursos para alcan¸car a sa´ıda desejada. Um processo geralmente envolve um conjunto de ferramentas e t´ecnicas. Quando o processo envolve a elabora¸c˜ao de um produto, algumas vezes nos referimos a ele como ciclo de vida. Assim, o processo de desenvolvimento de software pode ser chamado de ciclo de vida do software, pois descreve a ’vida’ do produto de software desde a concep¸c˜ao at´e a implementa¸c˜ao, entrega, utiliza¸c˜ao e manuten¸c˜ao”[1]. ”Em engenharia de software, processos podem ser definidos para atividades como desenvolvimento, manuten¸c˜ao, aquisi¸c˜ao e contrata¸c˜ao de software. Podese tamb´em definir subprocessos para cada um desses por exemplo, um processo de desenvolvimento abrange subprocessos de determina¸c˜ao de requisitos, an´alise, desenho, implementa¸c˜ao e testes. Em um processo de desenvolvimento de software, o ponto de partida para a arquitetura de um processo ´e a escolha de um modelo de ciclo de vida”[1]. ”Os processos s˜ao importantes porque imprimem consistˆencia e estrutura a um conjunto de atividades. Essas caracter´ısticas s˜ao u ´teis quando sabemos como fazer algo bem e queremos garantir que outras pessoas o fa¸cam da mesma maneira”[1]. ”Um processo ´e mais do que um procedimento. Um procedimento ´e como uma receita: um meio estruturado de combinar ferramentas e t´ecnicas para produzir um produto. Um processo ´e um conjunto de procedimentos, organizados de modo que nos permita construir produtos que satisfa¸cam a uma s´erie de objetivos e padr˜oes. De fato, o processo pode sugerir que escolhamos entre diversos procedimentos poss´ıveis, desde que alcancemos nosso objetivo”[1]. 24

”A estrutura do processo orienta nossas a¸c˜oes, permitindo-nos examinar, entender, controlar e aprimorar as atividades que o comp˜oem. Os processos tamb´em s˜ao importantes, porque nos permitem capturar experiˆencias e pass´a-las adiante”[1]. Os modelos de processo de software constituem uma forte ferramenta de gest˜ao do conhecimento promovendo o aprendizado institucional no sentido em que retiram da atividade de produ¸c˜ao de software o car´ater artesanal, que valoriza caracter´ısticas individuais de alguns membros da equipe, permitindo a execu¸c˜ao desta tarefa por qualquer membro da equipe com um padr˜ao aceit´avel de qualidade de resultados. ”Um processo ajuda a manter um n´ıvel de consistˆencia e qualidade nos produtos e servi¸cos produzidos por pessoas diferentes”[8]. Vemos, portanto, uma rela¸c˜ao direta entre a qualidade do produto de software e o processo utilizado na produ¸c˜ao do mesmo, o que indica, em um mundo competitivo e globalizado como o de hoje, que a ado¸c˜ao, manuten¸c˜ao e evolu¸c˜ao de um modelo de desenvolvimento de software deve ser motivo de preocupa¸c˜ao e aten¸c˜ao por parte de qualquer empresa que mantenha uma ´area de desenvolvimento ou manuten¸c˜ao de software, quer seja essa a sua atividade fim ou meio. Modelos de processo de desenvolvimento de software vˆem sendo objeto de estudo acadˆemico h´a bastante tempo, e v´arios modelos j´a foram propostos e aplicados em diversos contextos. Alguns destes modelos s˜ao apresentados a seguir, como uma ilustra¸c˜ao da diversidade existente nesta ´area. N˜ao ´e raro, por´em, empresas criarem suas pr´oprias implementa¸c˜oes de modelos de processos, normalmente derivados dos descritos a seguir, atendendo as necessidades espec´ıficas do seu neg´ocio ou segmento em que est´a inserida.

2.1.1

Modelo de Ciclo de Vida em Cascata

Este provavelmente ´e o primeiro modelo de desenvolvimento de software de que se tem registro. Foi apresentado na WesCon de 1970 por Winston W. Royce como um exemplo de modelo de processo de desenvolvimento de software inicial que poderia evoluir num modelo iterativo. Neste modelo cada est´agio do desenvolvimento de software ´e executado em seq¨ uˆencia, um ao outro, como numa cascata. Ou seja, o desenvolvimento de um est´agio deve terminar completamente para que o pr´oximo est´agio seja iniciado o que permite demarc´a-lo com pontos de controle bem definidos. ”Esses pontos de controle facilitam muito a gest˜ao dos projetos o que faz com que esse processo seja, em principio, confi´avel e utiliz´avel em projetos de qualquer escala. Por outro lado, se interpretado literalmente, ´e um processo r´ıgido e burocr´atico em que as atividades de requisitos, an´alise e desenho tˆem de ser muito bem dominadas, pois n˜ao s˜ao permitidos erros. O modelo em cascata puro 25

Figura 2.1: Modelo Cascata. [1] ´e de baixa visibilidade para o cliente que s´o recebe o resultado final do projeto”[8]. O modelo em cascata prevˆe as seguintes atividades em seq¨ uˆencia: An´alise de Requisitos, Projeto do Sistema, Projeto do Programa, Codifica¸c˜ao, Testes de Unidade e de Integra¸c˜ao, Testes do Sistema, Testes de Aceita¸c˜ao e por fim Opera¸c˜ao e Manuten¸c˜ao do software. O foco deste modelo est´a na produ¸c˜ao de documentos e artefatos, pois os produzidos numa fase s˜ao consumidos na fase subseq¨ uente. Sua simplicidade torna-o muito u ´til para ajudar desenvolvedores iniciantes e clientes a entender os passos b´asicos num fluxo de desenvolvimento de software. O mesmo tem servido como base para a elabora¸c˜ao de outros modelos, que muitas vezes introduzem m´ ultiplas itera¸c˜oes, ou realimenta¸c˜oes no fluxo em cascata. Alguns pontos fracos s˜ao apresentados para este modelo especialmente por n˜ao repetir exatamente o que ocorre no dia a dia do desenvolvimento de software, pois na pr´atica ”os desenvolvedores podem passar de uma atividade para outra e voltar para a anterior, `a medida que se esfor¸cam para adquirir conhecimento sobre o problema e como chegar `a solu¸c˜ao proposta”[1].

2.1.2

Modelo de Ciclo de Vida em V

O modelo de processo em V ´e uma varia¸c˜ao do modelo em cascata que evidencia a rela¸c˜ao entre as fases de teste e as outras fases do projeto, aproximando-o mais do que ocorre na realidade. Neste modelo a seq¨ uˆencia b´asica de fases do desenvolvimento ´e similar ao modelo em cascata, ou seja: An´alise de Requisitos, Projeto do Sistema, Projeto do Programa, Codifica¸c˜ao, Testes de Unidade e de 26

Figura 2.2: Modelo V. [1] Integra¸c˜ao, Testes do Sistema, Testes de Aceita¸c˜ao e por fim Opera¸c˜ao e Manuten¸c˜ao do software. A disposi¸c˜ao destas fases, por´em, mostra uma rela¸c˜ao entre a fase de Projeto do Programa e a fase de Testes de Unidade e de Integra¸c˜ao, evidenciando que falhas de programa identificadas naquela fase de teste fazem com que o processo retorne `a fase de Projeto do Programa para corre¸c˜ao e seq¨ uˆencia do fluxo atrav´es da fase de codifica¸c˜ao. De forma similar as rela¸c˜oes a seguir s˜ao estabelecidas: Projeto do Sistema – Testes do Sistema, An´alise de Requisitos – Teste de Aceita¸c˜ao. ”A conex˜ao entre os lados esquerdo e direito do modelo em V implica que, caso sejam encontrados problemas durante a verifica¸c˜ao e a valida¸c˜ao, o lado esquerdo do V pode ser executado novamente para corrigir e melhorar os requisitos, o projeto e a codifica¸c˜ao, antes da execu¸c˜ao das etapas de teste do lado direito do V. Em outras palavras, o modelo em V torna mais explicitas algumas itera¸c˜oes e repeti¸c˜oes do trabalho, ocultas no modelo Cascata. Enquanto o enfoque do modelo em cascata est´a nos documentos e nos artefatos, o enfoque do modelo em V est´a na qualidade e na corre¸c˜ao”[1].

2.1.3

Modelo de Ciclo de Vida Incremental

Um processo incremental prevˆe v´arias fases de desenvolvimento de software. A solu¸c˜ao final a ser desenvolvida ´e dividida em partes relativamente independentes que ser˜ao desenvolvidas completamente uma ap´os a outra em execu¸c˜oes consecutivas (itera¸c˜oes) do modelo de processo adotado. Desta forma, cada itera¸c˜ao acrescenta alguma funcionalidade ou caracter´ıstica nova `a solu¸c˜ao como um todo, possibilitando que o cliente da solu¸c˜ao possa utilizar parte do sistema antes mesmo dele estar completamente conclu´ıdo. Por exemplo, um m´odulo de cadastro pode ser desenvolvido numa itera¸c˜ao, disponibilizado aos usu´arios para o efetivo uso, enquanto outras funcionalidades s˜ao acrescentadas em fases subseq¨ uentes, como por exemplo os relat´orios gerenciais ou funcionalidades de neg´ocio que manipular 27

Figura 2.3: Modelo Iterativo. [1] ao os dados cadastrados. Em cada fase destas pode ser utilizada uma implementa¸ca˜o de outros modelos de processo como a Cascata ou em V.

2.1.4

Modelos de Ciclo de Vida Iterativos

Os processos iterativos, de forma parecida com o modelo incremental, tamb´em estabelecem um desenvolvimento em fases mas, diferentemente daquele modelo, prevˆe a entrega de um sistema com todas as funcionalidades previstas em cada fase. As funcionalidades entregues numa fase, por´em sofrer˜ao altera¸c˜oes evolutivas nas fases subseq¨ uentes, de forma que podemos mapear vers˜oes de uma mesma funcionalidade no decorrer do ciclo de desenvolvimento do software. Por exemplo, numa itera¸c˜ao pode estar prevista a gera¸c˜ao de um relat´orio com os dados apresentados em formato tabular, e numa vers˜ao posterior este mesmo relat´orio acrescentando um gr´afico, ou incorporando novas colunas. Existem modelos de processo que apresentam caracter´ısticas do modelo Incremental e Iterativo ao mesmo tempo, como ´e o caso do RUP (Rational Unified Process). [15] ”Para entender a diferen¸ca entre o desenvolvimento incremental e iterativo, pense em um pacote de processamento de textos, suponha que o pacote deva oferecer trˆes tipos de recurso: criar textos, organizar textos (ou seja, recortar e colar) e formatar textos (como utilizar diferentes tamanhos e estilos de letras e n´ umeros). Para construir esse sistema utilizando o desenvolvimento incremental, poder´ıamos fornecer, na Vers˜ao 1, somente a fun¸c˜ao de cria¸c˜ao de textos. Na Vers˜ao 2, poder´ıamos oferecer as fun¸c˜oes de cria¸c˜ao e organiza¸c˜ao de textos. Finalmente, na Vers˜ao 3, oferecer´ıamos as trˆes fun¸c˜oes. De outra maneira utilizando o desenvolvimento Iterativo, fornecer´ıamos formas primitivas das trˆes fun¸c˜oes logo na Vers˜ao 1”[1].

2.1.5

Modelo de Ciclo de Vida em Espiral

O modelo em Espiral foi proposto por Boehm em 1988 e prevˆe um desenvolvimento iterativo onde cada itera¸c˜ao ´e representada por uma volta da espiral. O 28

Figura 2.4: Modelo Espiral. [1] foco deste modelo est´a no gerenciamento de riscos do projeto de software, onde em cada espira ´e realizada uma an´alise de riscos, com a ado¸c˜ao de estrat´egias para mitig´a-los ou contorn´a-los atrav´es de prototipa¸c˜ao das alternativas identificadas. Cada espira termina com a produ¸c˜ao de artefatos que alimentar˜ao a fase seguinte, desta forma temos os artefatos de Concep¸c˜ao da Opera¸c˜ao, Requisitos e Planejamento, Projeto e Planejamento de Testes, Planejamento de Implementa¸c˜ao, C´odigo, como exemplos de sa´ıdas de cada espira deste modelo. ”Isso permite construir produtos em prazos curtos, com novas caracter´ısticas e recursos que s˜ao agregados a medida que a experiˆencia descobre a sua necessidade. As atividades de manuten¸c˜ao s˜ao usadas para identificar problemas; seus registros fornecem dados para definir os requisitos das pr´oximas libera¸c˜oes. O principal problema do ciclo de vida em espiral ´e que ele requer gest˜ao muito sofisticada para ser previs´ıvel e confi´avel.”[8]

2.1.6

´ Processos Ageis

´ O termo Processos Ageis, ou processos leves (light-weight processes), ´e denotado a uma gama de processos de desenvolvimento de software cuja ˆenfase contrasta com os demais apresentados at´e agora, pois sugerem a gera¸c˜ao m´ınima (e `as vezes ausente) de artefatos intermedi´arios nas etapas do processo de desenvolvimento. Valorizam o foco nos integrantes da equipe de desenvolvimento, no seu expertise, e na comunica¸c˜ao entre eles, e por este motivo muitas vezes s˜ao confundidos como sinˆonimos de ’ausˆencia’ de processo de desenvolvimento de software. Este tipo de ’processo’ ´e definido no Agile Manifesto que estabelece os seguintes prin29

c´ıpios gerais para este tipo de processo [16]: • Satisfa¸c˜ao do Cliente atrav´es da entrega continua e r´apida de software utiliz´avel; • Software livre de erros ´e frequentemente disponibilizado (a cada semana muitas vezes); • Software em funcionamento ´e a principal medida de progresso do projeto; • Mudan¸cas nos requisitos s˜ao prontamente incorporadas no fluxo corrente de desenvolvimento; • Di´aria e estreita coopera¸c˜ao entre o cliente e o desenvolvedor; • Conversa¸c˜ao cara a cara ´e a melhor forma de comunica¸c˜ao; • Projetos s˜ao constru´ıdos com o uso de recursos motivados e confi´aveis; • Continua aten¸c˜ao as boas pr´aticas de programa¸c˜ao e padr˜oes de desenvolvimento; • Simplicidade; • Equipes auto-organizadas; • Adapta¸c˜ao em momentos de mudan¸cas. Vale salientar que processos ditos ´ageis, n˜ao s˜ao reconhecidos por modelos de medi¸c˜ao de capacidade de modelos de desenvolvimento de software, como os descritos na pr´oxima sess˜ao, como boas pr´aticas de desenvolvimento de software. Isto demonstra que estes modelos n˜ao tˆem sua efic´acia comprovada e n˜ao s˜ao (ou podem ser) largamente utilizados em qualquer tipo de empresa ou situa¸c˜ao. Isto, por´em, n˜ao quer dizer que n˜ao sejam usados em determinados contextos e mesmo isoladamente em equipes internas de grandes empresas, mesmo que sem adotar esta denomina¸c˜ao explicitamente.

2.1.6.1

XP – Extreme Programming

Extreme Programing ´e o mais recente e proeminente exemplo de processos ´ageis, e como tal seu foco n˜ao est´a na previsibilidade e sim na adaptabilidade. O mesmo valoriza a comunica¸c˜ao direta dos requisitos do sistema (e de suas mudan¸cas) aos programadores, o desenvolvimento de funcionalidades que sejam mais simples e necess´arias primeiro e a evolu¸c˜ao constante do sistema na dire¸c˜ao do atendimento ao escopo completo de funcionalidades requeridas, a gera¸c˜ao e refinamento de casos de testes pelos clientes e testadores para constantemente prover feedback aos desenvolvedores acerca do perfeito funcionamento e integra¸c˜ao (ou n˜ao) de qualquer c´odigo rec´em publicado, a coragem de reescrever um c´odigo que apresente 30

problemas de performance, usabilidade ou manutenibilidade, ou mesmo que esteja obsoleto, e o respeito entre os desenvolvedores que devem evitar a publica¸c˜ao de vers˜oes de seus componentes que causem instabilidades ou a quebra dos casos de teste. [16] Este modelo de desenvolvimento de software, logicamente, n˜ao se aplica a qualquer escopo, sendo poss´ıvel o ganho de produtividade com sua aplica¸c˜ao em equipes pequenas desenvolvendo projetos cujos requisitos n˜ao est˜ao (ou n˜ao podem estar) bem definidos e que portanto podem mudar constantemente, e cujos prazos s˜ao muito apertados, como no atendimento de demandas legais. N˜ao ´e incomum que equipes de desenvolvimento XP implementem vers˜oes simplificadas do modelo em cascata, no que tange `a seq¨ uˆencia de a¸c˜oes a partir de uma encomenda.

2.2

Modelos de Qualidade de Processo de Software

O conceito de qualidade tem importˆancia fundamental para aumentar a competitividade das empresas. Atualmente a preocupa¸c˜ao com a qualidade deixou de ser um um fator que diferencia a empresa em um ambiente competitivo e passou a ser considerado uma necessidade b´asica para sua permanˆencia no mercado. No setor de software n˜ao ´e diferente. A demanda por qualidade tem motivado a comunidade de programadores e analistas para o desenvolvimento de modelos de qualidade de software. Um modelo de qualidade de processo procura descrever formalmente e de maneira organizada todas as atividades que devem ser seguidas para a obten¸c˜ao de um processo de software maduro, descrevendo o que ´e necess´ario implementar mas n˜ao explicitando como fazˆe-lo.

2.2.1

Modelo CMM/CMMI

Os objetivos quantitativos para a qualidade e o desempenho dos processos s˜ao estabelecidos e utilizados como crit´erios para o gerenciamento de processos. Os objetivos quantitativos s˜ao baseados nas necessidades dos clientes, usu´arios finais, da organiza¸c˜ao e dos respons´aveis pela implementa¸c˜ao dos processos. A qualidade e o desempenho do processo s˜ao entendidos em termos estat´ısticos e s˜ao gerenciados durante toda a vida dos processos. Para estes processos, s˜ao coletadas e analisadas de forma estat´ıstica, medidas detalhadas de desempenho de processos. Causas especiais de varia¸c˜oes de processos s˜ao identificadas e, quando apropriado, as fontes das causas especiais s˜ao corrigidas para evitar ocorrˆencias futuras. 31

O conhecimento quantitativo dos processos organizacionais permite que o n´ıvel de previsibilidade aumente e a varia¸c˜ao dos resultados diminua. O projeto Capability Maturity Model Integration (CMMI) envolveu um grande n´ umero de pessoas de diferentes organiza¸c˜oes de todo mundo. Essas organiza¸c˜oes utilizavam um modelo CMM ou m´ ultiplos CMMs e estavam interessadas nos benef´ıcios do desenvolvimento de um Sistema de Maturidade de Processo para auxiliar a melhoria de seus processos. Organiza¸c˜oes do Governo Norte-Americano – Departamento de Defesa dos EUA, organiza¸c˜oes industriais – Comitˆe de Engenharia de Sistema da Associa¸c˜ao Industrial da Defesa Nacional e o Instituto de Engenharia de Software (SEI) – se uniram para desenvolver esse trabalho. O CMM Integration foi desenvolvido com o objeto de solucionar os problemas gerados pelo uso de m´ ultiplos CMMs. O CMMI consiste em um m´etodo de avalia¸c˜ao e medida da capacidade dos processos de desenvolvimento de software. Esse modelo utiliza uma escala de 1 a 5 para indicar o n´ıvel de maturidade de uma organiza¸c˜ao. O CMMI n˜ao ´e um processo ou uma descri¸c˜ao de um processo. Esse modelo consiste em direcionamentos criados com o objetivo de elevar os processos de desenvolvimento de software a n´ıveis de capacidade mais elevados. Esse modelo fornece um direcionamento para o gerenciamento e manuten¸c˜ao de produtos e auxilia as organiza¸c˜oes a fixar objetivos e prioridades de melhoria dos processos. Uma das abordagens utilizadas pelo CMMI ´e a representa¸c˜ao em est´agios. Essa representa¸c˜ao organiza grupos de pr´aticas em cinco n´ıveis de maturidade sendo que cada n´ıvel define melhorias de processos. Os n´ıveis de maturidade s˜ ao: [7] 1 – Inicial No n´ıvel de maturidade 1 faltam planejamento e controle dos processos. Frequentemente prazos, cronogramas e or¸camentos s˜ao excedidos dando origem a uma grande variedade de resultados. Muitas organiza¸c˜oes que se encontram nesse n´ıvel n˜ao capazes de repetir sucessos anteriores. 2 – Gerenciado No n´ıvel de maturidade 2 existe uma gest˜ao b´asica de projetos. Constata-se que os requisitos s˜ao gerenciados e que os processos s˜ao planejados, executados medidos e controlados. A utiliza¸c˜ao de projetos estruturados permite a repeti¸c˜ao de processos anteriores. 32

3 – Definido No n´ıvel de maturidade 3 os projetos s˜ao bem caracterizados e est˜ao escritos em padr˜oes, procedimentos, ferramentas e m´etodos. Os padr˜oes, descri¸c˜oes de processos e procedimentos s˜ao utilizados para manter a consistˆencia em toda Empresa. Existem adapta¸c˜oes em projetos para que um processo se adeque a ´areas espec´ıficas. Nesse n´ıvel os projetos s˜ao descritos com mais detalhe e rigor. 4 – Gerenciado Quantitativamente No n´ıvel de maturidade 4 os objetivos quantitativos s˜ao baseados nas necessidades dos clientes, dos usu´arios finais da organiza¸c˜ao e dos respons´aveis pela implementa¸c˜ao dos processos. Esses objetivos quantitativos s˜ao utilizados como crit´erio para o gerenciamento dos processos. Medidas detalhadas de desempenho de processos s˜ao coletadas e analisadas de forma estat´ıstica. S˜ao identificadas causas de varia¸c˜oes de processos e, quando apropriado, as fontes dessas causas s˜ao corrigidas a fim de evitar ocorrˆencias futuras. O n´ıvel de previsibilidade aumenta e a varia¸c˜ao dos resultados diminui devido ao conhecimento quantitativo dos processos. 5 – Otimizado No n´ıvel de maturidade 5 ocorre um aperfei¸coamento continuo dos processos por meio de melhorias tecnol´ogicas incrementais e inovadoras. Objetivos quantitativos de melhoria de processos para a organiza¸c˜ao s˜ao estabelecidos, continuamente revisados para refletir altera¸c˜oes nos objetivos do neg´ocio e utilizados como crit´erios para gerenciamento da melhoria de processos.

2.2.1.1

Modelo SCAMPI

The Standard CMMI Appraisal Method for Process Improvement ´e um m´etodo de avalia¸c˜ao oficial do SEI para obten¸c˜ao de n´ıvel de maturidade ou capacidade de processos. O SCAMPI satisfaz todos os requisitos de avalia¸c˜ao do CMMI para o m´etodo Classe A. O SCAMPI permite: 1- obter uma vis˜ao da capacidade da organiza¸c˜ao por meio da identifica¸c˜ao os pontos fortes e fracos dos processos; 2- Relacionar esses pontos com o modelo CMMI; 3- Priorizar planos de desenvolvimento; 4- Focar o desenvolvimento nos pontos mais ben´eficos para a organiza¸c˜ao dado o seu n´ıvel de maturidade ou capacidade dos processos; 33

5- Derivar os n´ıveis de avalia¸c˜ao de capacidade como n´ıveis de avalia¸c˜ao de maturidade; 6- Identificar os riscos de desenvolvimento/aquisi¸c˜ao relativos a capacidade e maturidade. O SCAMPI A conta com um conjunto de informa¸c˜oes que s˜ao coletadas por tipos de evidˆencias definidos. Essas evidˆencias alimentam um mecanismo de processamento da informa¸c˜ao na qual partes s˜ao feitas de uma serie de dados transformados. O grupo de avaliadores observa, ouve e lˆe informa¸c˜oes que s˜ao transformadas em notas, e depois em praticas de implementa¸c˜ao de obediˆencia, e depois em veredictos iniciais. Esses veredictos s˜ao validados pela organiza¸ca˜o antes de se tornarem veredictos finais. Essa transforma¸c˜ao feita nos dados se reflete nos processos executados na organiza¸c˜ao e no modelo CMMI, e essa coleta de dados forma a base para a avalia¸c˜ao e seus resultados. O SCAMPI A consiste em trˆes fases e v´arios processos essenciais: Fase 1 – Planejamento e prepara¸c˜ao para a avalia¸c˜ao; Fase 2 – Conduzir a avalia¸c˜ao; Fase 3 – Relatar os resultados; Esse modelo fornece para a coleta e an´alise dos dados os seguintes tipos de evidˆencias: Documentos: Informa¸c˜oes escritas de uma ou mais implementa¸c˜oes de pr´aticas. Esse documento inclui regras da organiza¸c˜ao, procedimentos, n´ıvel de implementa¸c˜oes, question´arios e materiais de apresenta¸c˜ao; Entrevistas: Contato oral com os usu´arios e desenvolvedores da empresa. As entrevistas podem ser feitas com um grupo de pessoas ou individualmente. Uma apresenta¸c˜ao ou demonstra¸c˜ao serve como uma entrevista se houver intera¸c˜ao entre os avaliadores e apresentadores.

2.2.1.2

Modelo SPICE

O projeto Software Process Improvement and Capability dEtermination foi estabelecido em junho de 1993 pela ISO/IEC JTC1/SC7 (Subcomitˆe de Engenharia de Software) ´e uma iniciativa internacional para apoiar o desenvolvimento de um padr˜ao internacional de avalia¸c˜ao do processo de software. Esse projeto possui trˆes metas principais:

34

1) Auxiliar o desenvolvimento de uma Norma Internacional para avalia¸c˜ao de processos de software; 2) Construir testes para o padr˜ao emergente; 3) Disseminar a tecnologia do processo de avalia¸c˜ao de software para a ind´ ustria de software. O documento SPICE Su´ıte fornece uma estrutura para a avalia¸c˜ao do processo de desenvolvimento de software. Ele pode ser utilizado por organiza¸c˜oes para planejar, gerenciar, monitorar, controlar, melhorar a aquisi¸c˜ao, fornecimento, desenvolvimento, opera¸c˜ao, evolu¸c˜ao e suporte de software. O SPICE pode trazer benef´ıcios para a ind´ ustria de software entre eles: Produtores de software ser˜ao submetidos a um u ´nico esquema de avalia¸c˜ao. As empreses que desenvolvem software ter˜ao uma ferramenta para iniciar e manter um processo cont´ınuo de melhora. Gerentes ter˜ao meios para assegurar que o seu desenvolvimento de software est´a alinhado e suporta as necessidades do mercado. O SPICE trabalha com seis n´ıveis de capacita¸c˜ao de cada processo: N´ıvel 0 (N˜ ao Executado): N˜ao existem artefatos de trabalho e as sa´ıdas dos processos dificilmente s˜ao identificadas, o processo n˜ao est´a implementado e falha na tentativa de atingir seus objetivos, existem falhas na execu¸c˜ao das pr´aticas b´asicas no processo. N´ıvel 1 (Realizado Informalmente): O objetivo geralmente ´e atingido, mas n˜ao necessariamente de forma planejada e controlada. As pr´aticas b´asicas do processo s˜ao geralmente executadas. A execu¸c˜ao depende do conhecimento e esfor¸co individual. N´ıvel 2 (Planejado e controlado): O processo entrega produtos de trabalho com qualidade aceit´avel e no prazo, de forma planejada e controlada; A execu¸c˜ao das pr´aticas b´asicas do processo s˜ao planejadas e controladas, a execu¸c˜ao de acordo com procedimentos espec´ıficos ´e verificada; Os produtos de trabalho se adequam a padr˜oes e requisitos espec´ıficos. A principal diferen¸ca para o n´ıvel 1 ´e que a execu¸c˜ao do processo ´e planejada e gerenciada e avan¸ca junto com um processo bem definido. N´ıvel 3 (Bem Definido): O processo ´e realizado e gerenciado usando um processo bem definido, baseados em princ´ıpios de Engenharia de Software. A principal diferen¸ca do n´ıvel 2 ´e que o processo desse n´ıvel ´e planejado e gerenciado usando um processo padr˜ao. 35

N´ıvel 4 (Quantitativamente controlado): O processo ´e realizado de forma consistente, dentro dos limites de controle para atingir os objetivos; Meios detalhados da execu¸c˜ao s˜ao executados e analisados. Isso conduz a um entendimento quantitativo da capacidade do processo aperfei¸coa a execu¸c˜ao. A execu¸c˜ao ´e objetivamente gerenciada. A principal diferen¸ca entre o n´ıvel 3 ´e que os processos definidos s˜ao quantitativamente entendidos e controlados. N´ıvel 5 (Otimizado): A realiza¸c˜ao do processo ´e otimizado para atender a`s necessidades do neg´ocio atuais e futuras, e atinge repetibilidade em atender seus objetivos definidos de neg´ocios.

2.2.2

Modelo MPS.BR

O projeto MPS.BR – Melhoria de Processo de Software Brasileiro envolveu um grande n´ umero de pessoas de v´arias institui¸c˜oes e nasceu em dezembro de 2003. Organiza¸c˜oes integrantes do Sistema SOFTEX, institui¸c˜oes de ensino, pesquisa e centros tecnol´ogicos (COPPE–UFRJ, CESAR e CEnPRA) e sociedades de economia mista ( CELEPAR) se uniram para desenvolver esse trabalho. Modifica¸c˜oes vˆem ocorrendo nos ambientes de neg´ocio motivando as empresas a sa´ırem de um m´etodo de trabalho tradicionalista para redes de processos focadas nos clientes. A melhoria da qualidade dos produtos de software, processos de produ¸c˜ao e distribui¸c˜ao ´e um fator essencial para o sucesso das fabricas de software. Para que o setor de software brasileiro se torne competitivo internacional e nacionalmente ´e preciso que o foco das empresas passe a ser a efic´acia e eficiˆencia de seus processos. O foco principal, embora n˜ao exclusivo, s˜ao as micro, pequenas e m´edias empresas de software brasileiras. O MPS.BR busca atender os princ´ıpios da Engenharia de Software adequando-os ao contexto das empresas brasileiras, e estando em consonˆancia com as principais abordagens internacionais. Baseado em conceitos de maturidade e capacidade de processos para avalia¸c˜ao e melhoria da produtividade e da qualidade de produtos de software o MPS.BR divide-se em trˆes componentes:

• Modelo de Referˆ encia (MR-MPS): Esse modelo cont´em os requisitos que as organiza¸c˜oes dever˜ao atender para estar em conformidade com o MPS.BR; • M´ etodo de Avalia¸c˜ ao (MA-MPS): Esse m´etodo descreve o processo de avalia¸c˜ao, os requisitos para os avaliadores e os requisitos para averigua¸c˜ao 36

da conformidade com o modelo MPS.BR; • Modelo de Neg´ ocio (MN-MPS): Esse modelo cont´em a descri¸c˜ao das regras para a implementa¸c˜ao do MR-MPS pelas empresas de consultoria, de software e de avalia¸c˜ao.

O MPS.BR est´a descrito atrav´es de documentos em formato de guias:

• Guia Geral: cont´em a descri¸c˜ao geral do MPS.BR e detalha o Modelo de Referˆencia (MR-MPS), seus componentes e as defini¸c˜oes comuns necess´arias para seu entendimento e aplica¸c˜ao; • Guia de Aquisi¸c˜ ao: cont´em recomenda¸c˜oes para a condu¸c˜ao de compras de software e servi¸cos correlatos. Foi descrito como forma de apoiar as institui¸c˜oes que queiram adquirir produtos de software e servi¸cos correlatos apoiando-se no MR-MPS; • Guia de Avalia¸c˜ ao: cont´em a descri¸c˜ao do processo de avalia¸c˜ao, os requisitos para o avaliador, os requisitos para a avalia¸ca˜o, o m´etodo e os formul´arios para apoiar a avalia¸c˜ao.

O MPS.BR define 7 n´ıveis de maturidade: N´ıvel A – Em otimiza¸c˜ao; N´ıvel B – Gerenciado quantitativamente; N´ıvel C – Definido; N´ıvel D – Largamente definido; N´ıvel E – Parcialmente definido; N´ıvel F – Gerenciado; N´ıvel G – Parcialmente gerenciado.

37

Cap´ıtulo 3 Teorias de Aprendizagem A finalidade do ensino ´e a aprendizagem. Podemos descrever aprendizagem como sendo um processo de aquisi¸c˜ao e assimila¸c˜ao de novos padr˜oes e formas de perceber, ser, pensar e agir. Alguns autores preferem definir aprendizagem como sendo a aquisi¸c˜ao de novos comportamentos. Uma teoria ´e uma tentativa de sistematizar uma ´area de conhecimento, uma maneira particular de ver as coisas, de resolver problemas. Uma teoria de aprendizagem procura interpretar de forma sistem´atica a ´area de conhecimento ”Aprendizagem”. Os estudiosos atribuem ao conceito de aprendizagem diversos significados, incluindo em suas defini¸c˜oes o condicionamento, a aquisi¸c˜ao de informa¸c˜ao, a mudan¸ca comportamental, o uso do conhecimento na resolu¸c˜ao de problemas, a constru¸c˜ao de novos significados e estruturas cognitivas. Estes conceitos de s˜ao expressos em trˆes principais enfoques te´oricos: Comportamentalista, Cognitivista e Humanista.

3.1

Behaviorismo

O Behaviorismo ou Comportamentalismo surgiu no come¸co do s´eculo XX como uma proposta para a Psicologia tomar como seu objeto de estudo o comportamento. O termo behaviorismo se originou a partir da palavra inglesa behaviorism que significa estudo do comportamento (behavior em inglˆes). Os behavioristas entendem o comportamento como um conjunto de rea¸c˜oes ou respostas do organismo a eventos antecedentes – est´ımulos.

3.1.1

Behaviorismo Metodol´ ogico

Consiste na teoria explicativa do comportamento publicamente observ´avel da Psicologia, a qual postula que esta deve ocupar-se do comportamento animal (humano e n˜ao humano) apenas quando for poss´ıvel uma observa¸c˜ao p´ ublica para obter uma mensura¸c˜ao, ao inv´es de ocupar-se dos estados mentais que possam gerar ou influenciar tais comportamentos. Assim o behaviorismo metodol´ogico 38

acredita na existˆencia da mente, mas a ignora em suas explica¸c˜oes sobre o comportamento. John Broadus Watson fundou o Behaviorismo Metodol´ogico em 1913 com a publica¸c˜ao do artigo ”Psicologia vista por um Behaviorista”, no qual afirmava que a psicologia era um ramo puramente objetivo e experimental das ciˆencias naturais. Watson defendia importˆancia do meio na constru¸c˜ao e desenvolvimento do indiv´ıduo. Os seus estudos foram baseados no conceito de condicionamento cl´assico desenvolvido pelo fisiologista russo Ivan Pavlov, que ganhou o Prˆemio Nobel de Medicina pelo seu trabalho sobre a atividade digestiva dos c˜aes.

3.1.1.1

A origem do condicionamento cl´ assico:

O condicionamento cl´assico ´e definido como um processo que descreve o mecanismo de funcionamento e a modifica¸c˜ao de alguns comportamentos com base nos efeitos do binˆomio est´ımulo-resposta sobre o sistema nervoso central dos seres vivos. Um reflexo ´e uma sequˆencia est´ımulo-resposta e tem a fun¸c˜ao de manter o adequado funcionamento biol´ogico dos organismos vivos, garantindo sobrevivˆencia e permitindo a sua reprodu¸c˜ao. Para se conseguir um condicionamento efetivo ´e preciso que o est´ımulo condicionado preceda o est´ımulo incondicionado. Ao contr´ario da incondicionada a resposta condicionada ´e uma resposta aprendida sendo estruturalmente semelhante `a ela. Na base do reflexo condicionado est´a o est´ımulo condiconado que ´e aquele que sendo previamente neutro, passa a provocar uma resposta semelhante `a do est´ımulo incondicionado ap´os um emparelhamento repetido com este, desde que n˜ao coexistam est´ımulos externos inibidores e que haja repeti¸c˜ao peri´odica do condicionamento. Est´ımulos condicionados podem tamb´em ser associados a outros est´ımulos neutros de modo a torn´a-los igualmente condicionados sem o emparelhamento simultˆaneo com o est´ımulo incondicionado. Os primeiros seriam os condicionamentos chamados prim´arios e os seguintes, secund´arios. Esta seria ent˜ao uma associa¸c˜ao de segunda ordem. Tais associa¸c˜oes podem chegar at´e a terceira ordem e se mostrarem efetivas.

3.1.2

Behaviorismo Radical

O behaviorismo radical foi uma proposta de filosofia psicol´ogica sobre o comportamento humano referenciada em outras teorias de outros fil´osofos do s´eculo XX e que tem no psic´ologo americano Burruhs Skinner o seu representante mais importante.

39

Skinner desenvolveu os princ´ıpios do condicionamento operante e sistematizou o modelo de sele¸c˜ao por consequˆencias para explicar o comportamento. O modelo prevˆe que quando a um comportamento ou atitude ´e seguida da apresenta¸c˜ao de um refor¸co, essa resposta tem maior probabilidade de se repetir com a mesma fun¸c˜ao.

3.1.2.1

A origem do Condicionamento Operante

Condicionamento operante ´e aquele capaz de produzir conseq¨ uˆencias, sendo regido pela Lei do Efeito que determina que todo comportamento ´e influenciado por seus resultados. O condicionamento operante ´e composto por um est´ımulo seguido de um comportamento que dar´a um resultado que definir´a a freq¨ uˆencia daquele comportamento. O comportamento pode ser refor¸cado pela apresenta¸ca˜o de um est´ımulo positivo que provocar´a o aumento de sua freq¨ uˆencia. Um refor¸co negativo tamb´em aumenta a probabilidade de repeti¸c˜ao de um comportamento por´em desta vez pela a ausˆencia (retirada) de um est´ımulo aversivo. Skinner definiu um refor¸co com qualquer coisa que fortale¸ca o aparecimento daa resposta desejada. O refor¸co pode ser um elogio, uma boa nota, um sentimento de satisfa¸c˜ao pelo sucesso na realiza¸c˜ao de uma tarefa. A teoria prevˆe ainda a existˆencia de refor¸cos negativos. A freq¨ uˆencia de um comportamento pode diminuir em fun¸c˜ao dos procedimentos de extin¸c˜ao e puni¸c˜ao. Na extin¸c˜ao, a freq¨ uˆencia do comportamento diminui em conseq¨ uˆencia da retirada de refor¸cadores contingentes a resposta. J´a na puni¸c˜ao h´a a redu¸c˜ao da probabilidade da resposta voltar a ocorrer, sendo positiva quando ocorre na presen¸ca de um est´ımulo aversivo e negativa da retirada de um est´ımulo positivo logo depois da manifesta¸c˜ao de determinado comportamento. Skinner pregou a eficiˆencia do refor¸co positivo na educa¸c˜ao, sendo contr´ario a aplic¸c˜ao de puni¸c˜oes e esquemas repressivos, sugerindo que o uso das recompensas e refor¸cos positivos de conduta correta ´e pedagogicamente mais eficaz. Skinner tentou demonstrar que o uso de amea¸cas e castigos trazem resultados positivos muito mais baixos e com efeitos secund´arios piores do que os obtidos com o sistema de refor¸cos positivos. No livro Tecnologia do Ensino ele desenvolveu o que chamou de m´aquinas de aprendizagem, que baseava-se na organiza¸c˜ao de material did´atico de maneira que o aluno pudesse utilizar sozinho, recebendo est´ımulos `a medida que avan¸cava no conhecimento. Essa id´eia nunca chegou a ser aplicada de modo sistem´atico, mas teve grande influˆencia nos procedimentos da educa¸c˜ao norte-americana e brasileira. Para Skinner o sistema escolar predominantemente baseado na presen¸ca obrigat´oria, sob pena de puni¸c˜ao era um fracasso. Ele pregava o oferecimento de raz˜oes positivas 40

aos alunos como forma de estimul´a-los a estudar. No in´ıcio, a avalia¸c˜ao tem um papel fundamental para que o professor possa determinar a melhor estrat´egia para atingir os objetivos durante o processo de aprendizagem e ao final, para verificar se os resultados desejados foram obtidos. Assim como na escola tradicional os objetivos s˜ao previamente definidos sem a participa¸c˜ao do aluno. Est´ımulos refor¸cadores, como notas, prˆemios, reconhecimento de professores e colegas s˜ao utilizados para atingir os objetivos.

3.2

Construtivismo

O construtivismo ´e uma teoria de aprendizagem que afirma ser o aprendizado o fruto do entendimento de como o mundo que nos rodeia funciona, entendimento esse obtido atrav´es da reflex˜ao acerca de nossas experiˆencias. Dessa forma, o construtivismo analisa o aprendizado como um processo que ocorre de dentro para fora (Piagetiana), ou de fora para dentro dependendo da abordagem (Vigotskyana), de um indiv´ıduo que interage com o meio social e cultural construindo e reconstruindo o seu pr´oprio conhecimento a partir desta intera¸c˜ao e de sua an´alise psicol´ogica e introspectiva dos resultados dessa intera¸c˜ao [17]. Nessa an´alise, o indiv´ıduo n˜ao ´e um simples produto do meio ou muito menos de suas predisposi¸c˜oes internas, como sugeriam algumas outras teorias de aprendizagem da ´epoca, mas sim uma constru¸c˜ao pr´opria, particular e gradativa, resultante da intera¸c˜ao destes dois fatores mutuamente. Dessa forma, pessoas diferentes apreendem um conhecimento diferente a partir de uma mesma experiˆencia com o meio, pois essa aprendizagem constitui-se numa modelagem interior que representa na estrutura cognitiva do indiv´ıduo o acontecimento externo e suas implica¸c˜oes e interrela¸c˜oes com outros. Dois te´oricos da aprendizagem s˜ao citados pela literatura como os pais do construtivismo, s˜ao eles o bi´ologo su´ı¸co Jean Piaget (1896-1980) e o pensador russo Lev Semionovitch Vigotsky (1896-1934). Vigotsky preocupou-se em salientar o papel da intera¸c˜ao social ao longo do desenvolvimento do homem. Por este motivo, o seu estudo ´e muitas vezes chamado de s´ocio-construtivismo. Para ele o homem ´e herdeiro de toda carga cultural e hist´orica desenvolvida por seus ancestrais e presentes no meio social em que vive, interage e aprende. Este processo de aprendizagem, por´em, n˜ao ocorre atrav´es da intera¸c˜ao direta entre o homem e o meio, mas atrav´es de uma intera¸c˜ao mediada pelos seus pares sociais. A realidade que percebe, ´e um reflexo do meio nos seus semelhantes, sendo a partir da´ı interpretada e codificada internamente segundo um modelo simb´olico individual. Este conceito de media¸c˜ao pressup˜oe imprescind´ıvel a vivˆencia em sociedade 41

para que o homem possa transformar-se de ser puramente biol´ogico em ser humano. Vigotsky acreditava que inicialmente a crian¸ca detinha apenas fun¸c˜oes psicol´ogicas elementares como os reflexos e a aten¸c˜ao involunt´aria, e que atrav´es de sua intera¸c˜ao com o meio desenvolvia e transformava parte dessas fun¸c˜oes elementares em fun¸c˜oes psicol´ogicas superiores, como a linguagem, a consciˆencia e a capacidade de planejar e predizer acontecimentos futuros. A linguagem, por ser o sistema simb´olico dos seres humanos, ´e o elemento mediador mais importante que permite o desenvolvimento social das fun¸c˜oes psicol´ogicas superiores, pois ´e atrav´es dela que o ser humano codifica e transmite a outros a sua cultura. Vigotsky salienta ainda o processo de internaliza¸c˜ao que consiste na transforma¸c˜ao de um acontecimento social e portanto interpessoal numa representa¸ca˜o intrapessoal que capacitar´a o indiv´ıduo a estabelecer um modelo interno da realidade externa, passando a potencializar a abstra¸c˜ao de a¸c˜oes que depois podem transformar-se em a¸c˜oes externalizadas no meio f´ısico. Este te´orico ´e principalmente reconhecido pelos seus estudos e defini¸c˜oes acerca da Zona de Desenvolvimento Proximal. A Zona de Desenvolvimento Proximal ´e definida como a distˆancia entre o n´ıvel de desenvolvimento real e o n´ıvel de desenvolvimento potencial, sendo o primeiro caracterizado por aquele conhecimento j´a dominado pelo indiv´ıduo e que o capacita a solucionar problemas neste dom´ınio de conhecimento sem a necessidade de ajuda de outros, enquanto que esta u ´ltima delimita aquilo que o indiv´ıduo conseguir´a executar se for auxiliado por outros indiv´ıduos ditos mais capazes tomando por base o seu n´ıvel de desenvolvimento real. A Zona de Desenvolvimento Proximal delimita portanto um corpo de conhecimentos que, tomando-se por base os conhecimentos j´a internalizados pelo indiv´ıduo, est˜ao ao alcance do seu aprendizado se forem dadas oportunidades de intera¸c˜ao social que manipule estes novos conhecimentos. A aquisi¸c˜ao de um novo conhecimento, por sua vez, expande a zona de desenvolvimento proximal deixando dispon´ıveis novas fronteiras de aprendizado [17]. ´ importante salientar que Vygotsky n˜ao estabelece uma rela¸c˜ao direta e deE pendente entre o desenvolvimento e a aprendizagem, vez que n˜ao se preocupa em estabelecer limites para o aprendizado baseando-se no desenvolvimento f´ısico e ps´ıquico do indiv´ıduo, esses limites s˜ao impostos, em sua teoria, pelo pr´oprio conhecimento adquirido, j´a explicado no par´agrafo anterior quando citamos as zonas de desenvolvimento proximal. Piaget, por sua vez, tamb´em versa que o comportamento do homem n˜ao ´e inato e nem resultados de simples condicionamentos, mas constru´ıdo a partir da intera¸c˜ao deste com o meio que o circunda. Para ele a inteligˆencia do indiv´ıduo est´a diretamente relacionada `a complexidade das intera¸c˜oes deste com o meio. Este autor, n˜ao salienta contextos hist´oricos e culturais como Vigotsky, e define estar a aprendizagem relacionada e limitada ao desenvolvimento f´ısico do indiv´ıduo. Sua teoria denominou-se Epistemologia Gen´etica, e descreve o apren42

dizado como uma sequˆencia bem definida condicionada ao desenvolvimento do indiv´ıduo. Esta sequˆencia independe do indiv´ıduo em si, estando mais ligada ao processo gen´etico de forma¸c˜ao de suas estruturas cognitivas. Piaget define os est´agios do desenvolvimento humano como sendo [17]: • Per´ıodo Sens´orio-Motor (de 0 a 2 anos); • Per´ıodo Pr´e-operat´orio (de 2 a 7 anos); • Per´ıodo Operat´orio-concreto (de 7 a 12 anos); e • Per´ıodo L´ogico-Formal (de 12 a 16 anos). Desta forma, Piaget afirma que s´o h´a transferˆencia de conhecimentos quando h´a estruturas cognitivas para assimil´a-los, e que estas estruturas s˜ao desenvolvidas atrav´es de um processo de matura¸c˜ao vinculado `a idade do indiv´ıduo, constituindo um fator limitante ao aprendizado. Al´em disso, Piaget definiu alguns processos cognitivos em seu modelo de aprendizagem como: Organiza¸c˜ao, processo pelo qual o conhecimento ´e estruturado e encadeado formando esquemas de representa¸c˜ao do meio; Adapta¸c˜ao, processo que visa equilibrar a estrutura cognitiva do indiv´ıduo no momento da recep¸ca˜o de um novo conhecimento do mundo exterior, ´e formado por dois outros processos distintos mas indissoci´aveis, quais s˜ao a Assimila¸c˜ao e a Acomoda¸c˜ao. A Assimila¸c˜ao ´e o processo pelo qual o indiv´ıduo integra o novo conhecimento `a estrutura cognitiva existente, deixando-a intacta ou modificando-a num processo de Adapta¸c˜ao para manter uma continuidade entre o estado mental anterior e o novo.

3.3

Cognitivismo

Alguns autores tratam a teoria cognitivista como sendo a construtivista de Piaget, por´em, podemos diferenci´a-las facilmente observando que para o construtivismo a experiˆencia ´e essencial para o desenvolvimento do conhecimento atrav´es da intera¸c˜ao entre o indiv´ıduo e o meio. Para o cognitivismo, por´em, essa experiˆencia direta n˜ao ´e exatamente necess´aria, e qualquer indiv´ıduo instru´ıdo tem capacidade para entender a ciˆencia e seus conceitos, desde que certos requisitos sejam atendidos, num processo chamado de ancoragem descrito a seguir. A Aprendizagem Significativa, foi teorizada por David Ausubel, e ´e definida como sendo ”um processo pelo qual uma nova informa¸c˜ao se relaciona, de maneira substantiva (n˜ao literal) e n˜ao arbitr´aria, a um aspecto relevante da estrutura cognitiva do indiv´ıduo”. Ou seja, aprendizagem significativa seria a forma como uma nova informa¸c˜ao ou conhecimento estabelece rela¸c˜oes com outras informa¸c˜oes j´a adquiridas pelo indiv´ıduo, absorvendo assim um significado contextual e particular, e tamb´em modificando o conhecimento preexistente. Isto indica um processo 43

de intera¸c˜ao entre o novo conhecimento e o conhecimento preexistente definido por Ausubel como conceito subsun¸c˜ ao ou simplesmente subsun¸c˜ ao. O processo como um todo ´e chamado de ”ancoragem”. ”O armazenamento de informa¸c˜oes na mente humana ´e altamente organizado, formando uma esp´ecie de hierarquia conceitual, na qual elementos mais espec´ıficos de conhecimento s˜ao ligados (e assimilados por) a conceitos, id´eias, proposi¸c˜oes mais gerais e inclusivos”. A aprendizagem mecˆanica ´e apresentada por Ausubel, em contraposi¸c˜ao `a aprendizagem significativa, e define os casos onde as novas informa¸c˜oes s˜ao aprendidas sem que ocorra ancoragem a nenhum conceito subsun¸cor preexistente, favorecendo muitas vezes seu esquecimento com o tempo. Estas duas extremidades dos processos de aprendizagem (significativa e mecˆanica) est˜ao dispostas num continuum onde, na verdade, o aprendizado ocorre ao longo destes dois processos sendo menos comum um aprendizado puramente significativo ou mecˆanico. Moreira define ainda a aprendizagem por descoberta e a aprendizagem por recep¸c˜ao, mostrando ainda que esta diferen¸ca n˜ao tem rela¸c˜ao com as diferen¸cas entre o processo de aprendizagem significativo e o mecˆanico. A classifica¸c˜ao da aprendizagem em ”por descoberta”ou ”por recep¸c˜ao”refere-se aos processo utilizado para obter as novas informa¸c˜oes, onde no primeiro o conte´ udo principal a ser aprendido deve ser descoberto pelo aprendiz de forma interativa e ativa, enquanto na outra o conte´ udo a ser aprendido ´e apresentado ao aprendiz j´a em sua forma final. A partir da´ı, a forma como este novo conte´ udo ser´a armazenado na estrutura cognitiva do aprendiz ´e que poder´a ser classificada em significativa ou mecˆanica. Desta forma, n˜ao ´e obrigat´orio que a aprendizagem significativa ocorra ap´os um processo de aprendizagem por descoberta, e da mesma forma que a aprendizagem mecˆanica decorra necessariamente de um processo receptivo. Ou seja, a primeira classifica¸c˜ao refere-se ao processo de armazenamento da informa¸c˜ao e a segunda ao processo de aquisi¸c˜ao desta informa¸c˜ao. Ausubel deixa claro ainda que o aprendizado por descoberta ´e predominante na idade pr´e-escolar, tendendo gradativamente para a significativa `a medida em que cresce o n´ıvel de maturidade cognitiva do indiv´ıduo.

3.3.1

Condi¸ c˜ oes para Aprendizagem Significativa

Para que ocorra a aprendizagem significativa, Moreira apresenta algumas condi¸c˜oes quais s˜ao: a potencialidade significativa do conte´ udo a ser aprendido e a disposi¸c˜ao do aprendiz para efetuar o processo de ancoragem. Para que o conte´ udo seja potencialmente significativo ´e necess´ario que a natureza do material estudado seja relacion´avel, ou seja, que possua significado l´ogico intr´ınseco, e tamb´em que exista conceitos subsun¸cores apropriados que favore¸cam a ancoragem. Isto tudo 44

cria a possibilidade de transformar o significado l´ogico do material estudado em significado psicol´ogico individualizado. Em sua vida, inicialmente, o indiv´ıduo n˜ao apresenta conceitos subsun¸cores, e adquire-os a partir de um processo de forma¸c˜ao de conceitos, que ´e um processo individual e particular muito baseado na aprendizagem por descoberta e muito similar `as defini¸c˜oes construcionistas. Ap´os a aquisi¸c˜ao de certa quantidade de conceitos atrav´es deste processo a diferencia¸c˜ao destes e a aquisi¸c˜ao de novos passa a ocorrer cada vez mais por outro processo chamado de assimila¸c˜ao de conceitos, que j´a ´e uma aprendizagem significativa dada a intera¸c˜ao dos novos conceitos com os j´a existentes. Como estrat´egias a serem adotadas para suprir uma eventual falta de subsun¸cores num indiv´ıduo adulto e portanto j´a apto a aprender significativamente, tipicamente quando este encontra-se em contato com um assunto totalmente novo, Ausubel prop˜oe o uso de ”Organizadores Pr´evios”, que s˜ao materiais (textos, v´ıdeos, discuss˜oes, atividades, etc) apresentados antes do material cujo aprendizado ´e desejado, de forma a constituir uma ponte cognitiva entre os conceitos j´a existentes e os novos. Os organizadores servir˜ao em alguns momentos para sustentar uma rela¸c˜ao super ordenada com o novo material, integrando ”as novas id´eias a conceitos, basicamente similares, existentes na estrutura cognitiva”, e em outros para aumentar a discriminabilidade entre estas id´eias, destacando-as ”diferentes apesar de parecerem similares a ponto de confundir”. Podemos ainda classificar a aprendizagem significativa em: representacional, de conceitos e proposicional. Sendo a primeira a forma mais b´asica de aprendizagem significativa constituindo-se na atribui¸c˜ao de significados a s´ımbolos. Na aprendizagem de conceitos, a associa¸c˜ao ´e estabelecida n˜ao s´o entre o s´ımbolo e um objeto espec´ıfico, mas entre o s´ımbolo e o conjunto de atributos que genericamente definem uma classe de objetos. Na u ´ltima, a tarefa ´e aprender n˜ao o conceito associado a um determinado s´ımbolo ou conjunto de s´ımbolos, mas conseguir abstrair a id´eia que est´a associada `aquela disposi¸c˜ao de s´ımbolos. Nos modelos de aprendizagem descritos a aprendizagem pode ser do tipo subordinada, super ordenada ou combinat´oria. Onde na subordinada o novo conceito ´e assimilado por conceitos mais abrangentes preexistentes nas estrutura cognitiva; na super ordenada quando o novo conceito passa a fundir conceitos preexistentes assimilando-os, e na u ´ltima a nova informa¸c˜ao n˜ao se relaciona com um ou mais conceitos espec´ıficos mas sim com um ou mais conte´ udos mais amplos existentes na estrutura cognitiva do indiv´ıduo. H´a ainda uma subclassifica¸ca˜o da aprendizagem subordinada em derivativa (quando a nova informa¸c˜ao simplesmente exemplifica ou ilustra o conceito subsun¸cor) e correlativa (quando amplia, modifica ou elabora o conceito subsun¸cor). Assimila¸c˜ao obliteradora ´e uma expans˜ao natural do processos de assimila¸c˜ao, onde gradativamente os novos conceitos v˜ao se dissociando dos subsun¸cores, modificando-os at´e que n˜ao seja mais poss´ıvel identific´a-los individualmente, restando um conceito subsun¸cor modificado e com mais probabilidade de uso. 45

Cap´ıtulo 4 Estudo de Caso 4.1

A Empresa Pesquisada

Para este estudo de caso foi escolhida uma institui¸c˜ao financeira brasileira. A institui¸c˜ao em quest˜ao ´e um dos 10 maiores bancos do pa´ıs, em termos de dep´ositos totais e ativo total, segundo o Banco Central do Brasil, e neste trabalho ser´a chamada de BANCO Y. Al´em do seu tamanho, esta empresa foi escolhida por mais dois motivos principais de interesse para este trabalho: o fato de manter uma ´area de TI que, dentre outras fun¸c˜oes, desenvolve software internamente; e por estar no meio de um plano de melhoria de processo de desenvolvimento de software. Caracterizando-se por ser um banco de varejo, o Banco Y est´a presente em todas as unidades federativas do pa´ıs e em alguns pa´ıses do mundo, possuindo uma base de mais de 15 milh˜oes de clientes correntistas e atendendo-os atrav´es de mais de 5000 pontos de atendimento e canais eletrˆonicos como terminais de autoatendimento, internet banking, celular, unidades de resposta aud´ıvel e call centers.

Figura 4.1: Ranking das Maiores Institui¸c˜oes Financeiras tas/Agencias/Funcion´arios - Fonte: Banco Central do Brasil

46

-

Recei-

Figura 4.2: Estrutura Organizacional de TI do Banco Y.

4.2

´ A Area de TI do Banco Y

A atividade de desenvolvimento, manuten¸c˜ao e sustenta¸c˜ao de sistemas no Banco Y s˜ao de responsabilidade das Gerˆencias de Sistemas de Neg´ocios I, II, III e pela Gerˆencia de Projetos, e s˜ao executados, em sua maioria, por equipes internas a estas gerˆencias auxiliadas eventualmente por recursos terceirizados que executam tarefas de programa¸c˜ao, num modelo de relacionamento chamado body shop. No modelo body shop o recurso terceirizado fica dispon´ıvel para o banco 8 horas por dia, havendo demanda ou n˜ao, estando localizados fisicamente hora dentro das dependˆencias da ´area de TI do Banco Y e parte nas dependˆencias da empresa contratada. S˜ao previstos tamb´em outros modelos de relacionamento para terceiriza¸c˜ao do desenvolvimento de solu¸c˜oes de TI, onde o banco paga pelo servi¸co executado e n˜ao pela hora do recurso. S˜ao modelos, por´em, utilizados ainda de forma modesta e em fase de adapta¸c˜ao:

• Uso de f´abrica de software externa, onde a defini¸c˜ao do que tem que ser 47

desenvolvido, a an´alise conceitual e o projeto f´ısico ´e realizado pelas equipes internas e o desenvolvimento e o teste de unidade ´e realizado pela empresa terceirizada, retornando o c´odigo desenvolvido `as equipes internas para os testes de integra¸c˜ao e a pr´opria implanta¸c˜ao; • Uso de f´abrica de projetos, onde o banco levanta os requisitos da solu¸ca˜o e os repassa diretamente para a empresa contratada que ficar´a respons´avel pelo desenvolvimento completo da solu¸c˜ao (todas as fases de um processo de desenvolvimento de software), retornando ao banco apenas para testes de aceita¸c˜ao e implanta¸c˜ao. O Banco Y ´e uma institui¸c˜ao bastante antiga e apresenta uma grande heterogeneidade em seu ambiente de desenvolvimento. O banco Y possui uma plataforma baseada em mainframe, cujas solu¸c˜oes nele instaladas s˜ao genericamente chamadas de solu¸c˜oes para alta plataforma; e tamb´em uma plataforma baseada em servidores microprocessados RISC e CISC, bem como microcomputadores, num geral denominados baixa plataforma. Para a alta plataforma, s˜ao desenvolvidos sistemas em linguagem COBOL e NATURAL, enquanto que para a baixa plataforma existe um incentivo para o desenvolvimento em JAVA, havendo por´em sistemas desenvolvidos em Delphi, Visual Basic, C, Clipper e dentre outras linguagens. Os paradigmas de desenvolvimento utilizados s˜ao programa¸c˜ao estruturada, funcional, orienta¸c˜ao a objetos e orienta¸c˜ao a servi¸cos. O Banco Y desenvolve solu¸c˜oes que envolvem desde Data Warehouse a portais internet, passando por solu¸c˜oes de processamento batch a aplica¸c˜oes de processamento em tempo real. Suas equipes de desenvolvimento internas tamb´em possuem grande heterogeneidade, vez que nela podem ser encontrados profissionais com os mais diversos graus de instru¸c˜ao, forma¸c˜ao em v´arias ´areas, havendo uma predominˆancia de graduados e com Especializa¸c˜oes/MBA em cursos da ´area de computa¸c˜ao. Existem funcion´arios com mais de 25 anos de atua¸c˜ao na ´area de tecnologia do Banco Y, bem como funcion´arios com apenas meses de atua¸c˜ao nesta unidade. O tempo de forma¸c˜ao tamb´em ´e um fator com alguma varia¸c˜ao vez que existem desde funcion´arios rec´em formados em cursos de computa¸c˜ao a funcion´arios formados a mais de uma d´ecada em cursos que n˜ao s˜ao da ´area de computa¸c˜ao (f´ısica, engenharia, matem´atica, dentre outros).

4.3

A Busca pela Melhoria de Processo de Desenvolvimento de Software

A alguns anos a falta de um modelo de processo de desenvolvimento de software foi identificado como um dos fatores que levavam o banco Y a uma produ¸c˜ao 48

Figura 4.3: Disciplinas do Modelo de Processo PDS-BY. de software de baixa qualidade, com muitos erros identificados e corrigidos em ambiente de produ¸c˜ao, grande retrabalho, que minavam a capacidade da empresa em reagir `as exigˆencias do mercado e das institui¸c˜oes reguladoras em tempo h´abil sem um grande desperd´ıcio de recursos. O foco da melhoria perseguida pela ´area de TI do Banco Y est´a em sair de um est´agio em que n˜ao existe processo de desenvolvimento de software definido e cada equipe implementa seu pr´oprio processo de desenvolvimento, normalmente com capacidade baixa, para um patamar onde exista um processo de desenvolvimento de software definido e aderente a n´ıveis de maturidade citados nos modelos de melhoria de processos de desenvolvimento de software conhecidos, tais como CMMI e MPS.BR. Um modelo de processo foi estudado e modelado e est´a em fase de implanta¸c˜ao. O modelo citado, neste trabalho denominado genericamente de PDS–BY (Processo de Desenvolvimento de Software do Banco Y), foi baseado num modelo iterativo incremental e prevˆe at´e o momento as seguintes disciplinas da engenharia de software: Requisitos, An´alise, Projeto, Implementa¸c˜ao, Teste, Homologa¸c˜ao, Implanta¸c˜ao, Gerˆencia de Projetos e Gerˆencia de Subcontrata¸c˜ao, cujas finalidades declaradas est˜ao descritas na tabela a seguir: As disciplinas que n˜ao est˜ao implantadas, indicam trechos da atividade de desenvolvimento de software que ainda s˜ao executadas (ou n˜ao) de acordo com os humores de cada equipe individual. A estrat´egia de implanta¸c˜ao do modelo de processo PDS–BY contempla uma implanta¸c˜ao gradual, come¸cando pela Gerˆencia de Projetos, seguida pela disciplina de Requisitos, Homologa¸c˜ao, Testes, 49

An´alise, nesta ordem at´e o momento. ` medida em que cada disciplina esteja completamente definida ´e publicada A na intranet corporativa detalhes sobre a disciplina (finalidade, objetivos, pap´eis, artefatos, etc), s˜ao disponibilizados modelos de artefatos e a equipe que est´a mo´ dado delando o processo fica dispon´ıvel para a retirada de qualquer d´ uvida. E um prazo para em que todos os desenvolvimentos de software realizados naquele ´ınterim devem produzir os artefatos previstos e deposit´a-los em reposit´orios espec´ıficos. S˜ao compostas equipes de auto-verifica¸c˜ao que num primeiro momento avaliam se os artefatos est˜ao sendo depositados nos reposit´orios. A partir de um segundo prazo estas equipes de auto-verifica¸c˜ao passam a analisar a qualidade dos artefatos depositados nos reposit´orios. Todas as gerˆencias possuem um acordo de n´ıvel de servi¸co, cujo atendimento `as exigˆencias do PDS–BY comp˜oem um dos quesitos. O n˜ao atendimento aos itens deste acordo de trabalho pode levar os funcion´arios da gerˆencia envolvida a perdas pecuni´arias na forma de n˜ao recebimento de parcela da participa¸c˜ao nos lucros e resultados da empresa. Eventualmente, s˜ao disponibilizados aos funcion´arios treinamentos acerca das disciplinas que est˜ao sendo implantadas ou que j´a foram. Estes treinamentos n˜ao tˆem uma regularidade definida e nem um padr˜ao,vez que algumas disciplinas s˜ao contempladas com mais recursos que outras. Os investimentos do Banco Y em treinamento e forma¸c˜ao dos funcion´arios envolvidos com o processo de desenvolvimento de software traduzem-se nas seguintes modalidades: • Curso auto-instrucional da intranet corporativa; • P´agina oficial do PDS–BY na intranet com informa¸c˜oes diversas sobre as fases e disciplinas do processo, disponibilizando modelos de artefatos para download – Algumas disciplinas possuem p´agina espec´ıfica e separada da p´agina do PDS–BY, por terem sido constru´ıdas antes de se falar no pr´oprio processo em si; • Treinamentos externos (realizados em outras empresas); • Treinamentos internos (realizados pelo pr´oprio Banco Y num processo de multiplica¸c˜ao); • Valoriza¸c˜ao de forma¸c˜ao na ´area de inform´atica nos processos de sele¸c˜ao e promo¸c˜ao internas na ´area de TI; • Financiamento de bolsas de gradua¸c˜ao e p´os-gradua¸c˜ao em ´areas de interesse do banco Y (que incluem a ´area de inform´atica). Nem todas essas modalidades de treinamento, por´em, s˜ao disponibilizadas continuamente, tendo algumas sido oferecidas j´a h´a alguns anos, existindo portanto v´arios novos funcion´arios que n˜ao tiveram acesso `as mesmas. 50

4.4

Metodologia

Segundo Pereira [18], a natureza de uma pesquisa pode ser classificada como B´asica e Aplicada, tendo a primeira o prop´osito de ”gerar conhecimentos novos e u ´teis para o avan¸co da ciˆencia sem aplica¸c˜ao pr´atica prevista. Envolve verdades e interesses universais.”, e segunda o objetivo de ”gerar conhecimentos para aplica¸ca˜o pr´atica e dirigidos `a solu¸c˜ao de problemas espec´ıficos. Envolve verdades e interesses locais.” Ainda segundo aquele autor, a forma de abordagem do problema divide-se em Pesquisa Quantitativa quando ”tudo pode ser mensurado numericamente, ou seja, pode ser traduzido em n´ umeros, opini˜oes e informa¸c˜oes para classific´a-las e analis´a-las. Requer o uso de recursos e de t´ecnicas estat´ısticas (percentagem, m´edia, moda, mediana, desvio padr˜ao, coeficiente de correla¸c˜ao, an´alise de regress˜ao, etc)”[18]. E em Pesquisa Qualitativa ”quando parte do entendimento que existe uma rela¸c˜ao dinˆamica entre o mundo real e o sujeito, isto ´e, um v´ınculo indissoci´avel entre o mundo objetivo e a subjetividade do sujeito que n˜ao pode ser traduzida em n´ umeros. A interpreta¸c˜ao dos fenˆomenos, e atribui¸c˜ao de significados, s˜ao b´asicas no processo de pesquisa qualitativa. N˜ao requer o uso de m´etodos e t´ecnicas estat´ısticas. O ambiente natural ´e fonte direta para a coleta ´ descritiva. Os pesquisadores de dados e pesquisador ´e o instrumento chave. E tendem a analisar os seus dados indutivamente. O processo e seu significado s˜ao os focos principais de abordagem”[18]. Desta forma realizamos uma pesquisa aplicada e quantitativa, na ´area de tecnologia da institui¸c˜ao financeira descrita no item 4.1 deste cap´ıtulo. Da ´area de ˆ TI foram selecionadas 4 gerˆencias denominadas neste trabalho de GERENCIA ˆ ˆ ˆ A, GERENCIA B, GERENCIA C, e GERENCIA D. Estas gerˆencias foram selecionadas em virtude do seu perfil, vez que trabalham exclusivamente com o desenvolvimento de sistemas, sendo o principal alvo do modelo de processo de desenvolvimento de software em implanta¸c˜ao naquela institui¸c˜ao. Essas gerˆencias s˜ao divididas em divis˜oes, e estas em n´ ucleos de desenvolvimento, apresentando portanto cargos de n´ıvel gerencial e operacional. A popula¸c˜ao (universo da pesquisa) foi composta por membros dos dois cargos citados (gerentes e analistas), segundo os dados da tabela abaixo:

51

Figura 4.4: Popula¸c˜ao e Amostra da Pesquisa. O instrumento de coleta de dados utilizado foi um question´ario composto por 18 quest˜oes objetivas cujas respostas estavam limitadas aos valores da escala descrita na tabela abaixo: O objetivo da pesquisa era identificar o relacionamento entre trˆes dom´ınios de interesse: Dom´ınio CP: Mede a Cultura de Processos de desenvolvimento de software que o entrevistado possui; Dom´ınio ET: Mede a efetividade dos treinamentos recebidos pelo entrevistado, nas disciplinas de engenharia de software abordadas na pesquisa; Dom´ınio CN: Mede a conformidade do processo real executado pelo entrevistado em rela¸c˜ao ao modelo proposto por sua organiza¸c˜ao. As disciplinas de engenharia de software abordadas nesta pesquisa foram: Requisitos, Gerˆencia de Projetos e Testes, em virtude de serem as disciplinas implantadas a mais tempo na institui¸c˜ao estudada. As quest˜oes foram distribu´ıdas da seguinte forma, em rela¸c˜ao `as disciplinas e aos dom´ınios citados:

Figura 4.5: Escala da Pesquisa. 52

Figura 4.6: Quest˜oes X Dom´ınios. Quest˜ oes: Q1 – Existe treinamento suficiente que capacite todos os envolvidos com a execu¸c˜ao da disciplina de requisitos a desempenhar seu papel como prevˆe o processo de desenvolvimento de software da minha organiza¸c˜ao. Q2 – A gerˆencia de requisitos (processo de elicita¸c˜ao, documenta¸c˜ao, validac¸˜ao, controle de mudan¸ca de requisitos) ´e extremamente necess´aria no desenvolvimento de software. Q3 – Na minha equipe todos os requisitos identificados e implementados numa manuten¸c˜ao, projeto ou versionamento, s˜ao de fato REGISTRADOS nos documentos de requisitos e passam pelo processo previsto no PDS–BY para a disciplina de Requisitos. Q4 – Todos os requisitos funcionais e n˜ao–funcionais precisam estar registrados num documento de requisitos ou num equivalente eletrˆonico (sistema de gerˆencia de requisitos). Q5 – Os procedimentos utilizados na minha organiza¸c˜ao para identificar, coletar e documentar, os requisitos dos sistemas desenvolvidos est˜ao de acordo com o processo definido. Q6 – Quando executo tarefas inerentes `a disciplina de requisitos no desenvolvimento de solu¸c˜oes de software utilizo conhecimentos adquiridos atrav´es dos treinamentos disponibilizados pela organiza¸c˜ao onde trabalho. Q7 – Existe treinamento suficiente que capacite todos os envolvidos com a execu¸c˜ao da disciplina de gerˆencia de projetos a desempenhar seu papel como prevˆe o processo de desenvolvimento de software da minha organiza¸c˜ao. Q8 – No desenvolvimento de solu¸c˜oes de software de tamanho m´edio a grande ´e indicado fazˆe–lo na forma de um projeto (escopo, prazo e custo definidos e gerenciados). Q9 – No desenvolvimento de projetos ´e comum iniciar a an´alise e desenvolvimento da solu¸c˜ao com o projeto ainda na fase de Planejamento (defini¸c˜ao de 53

escopo, elabora¸c˜ao do plano do projeto, cronograma, aprova¸c˜oes, etc). Q10 – Todas as altera¸c˜oes de escopo dos projetos s˜ao registradas nas ferramentas e documentos de gerˆencia de projetos. Q11 – Caso seja poss´ıvel, ´e prefer´ıvel que uma demanda de desenvolvimento de software de tamanho grande, seja dividida em v´arias menores objetivando evitar o seu desenvolvimento como um projeto, enquadrando–as em outros paradigmas de desenvolvimento menos r´ıgidos como o versionamento ou a manuten¸c˜ao de software. Q12 – Quando executo tarefas inerentes `a disciplina de Gerˆencia de Projetos no desenvolvimento de solu¸c˜oes de software utilizo conhecimentos adquiridos atrav´es dos treinamentos disponibilizados pela organiza¸c˜ao onde trabalho. Q13 – Existe treinamento suficiente que capacite todos os envolvidos com a execu¸c˜ao da disciplina de testes a desempenhar seu papel como prevˆe o processo de desenvolvimento de software da minha organiza¸c˜ao. Q14 – Todos os planos de testes (unidade, integra¸c˜ao, sistema, aceita¸c˜ao, homologa¸c˜ao) previstos no PDS–BY s˜ao ELABORADOS antes da execu¸c˜ao destes testes na pr´atica. Q15 – Todos os testes realizados (unidade, integra¸c˜ao, sistema, aceita¸c˜ao, homologa¸c˜ao) na pr´atica s˜ao DOCUMENTADOS nos planos de testes. Q16 – O planejamento dos testes a serem executados ao longo do ciclo de desenvolvimento de software (testes de unidade, integra¸c˜ao, sistema, aceita¸c˜ao, homologa¸c˜ao) deve ser realizado e registrado ANTES da codifica¸c˜ao propriamente dita. Q17 – Os testes executados de fato ao longo do ciclo de desenvolvimento de software n˜ao precisam estar registrados em documentos (planos, registro de resultados, etc) desde que a solu¸c˜ao seja entregue sem erros. Q18 – Quando executo tarefas inerentes `a disciplina de Testes no desenvolvimento de solu¸c˜oes de software utilizo conhecimentos adquiridos atrav´es dos treinamentos disponibilizados pela organiza¸c˜ao onde trabalho. Nas quest˜oes Q9, Q11 e Q17, em virtude da forma como a pergunta foi formulada, os valores das respostas quando utilizadas nos c´alculos e gr´aficos, foram invertidos: 0 tornou–se 3, 1 tornou–se 2, 2 tornou–se 1 e 3 tornou–se 0.

54

4.5

Tratamento dos Dados da Pesquisa

Inicialmente analisamos cada quest˜ao separadamente, por gerˆencia, verificando a frequˆencia de respostas correspondente a cada valor da escala. Plotando um gr´afico de barras para cada Quest˜ao/Gerˆencia. Em segundo lugar montamos 3 cen´arios que relacionavam os dom´ınios CP, ET e CN, dois a dois, em cada gerˆencia com o objetivo de verificar a rela¸c˜ao de dependˆencia entre cada par de dom´ınios. Utilizamos gr´aficos de dispers˜ao para essa an´alise.

4.6

Resultados Obtidos

Esta se¸c˜ao apresenta os dados obtidos com a aplica¸c˜ao dos question´arios na ´area de TI da empresa pesquisada. Os dados est˜ao agrupados inicialmente por quest˜oes e exibidos na forma de histogramas, mostrando a rela¸c˜ao entre as respostas das diversas gerˆencias pesquisadas. Em seguida ´e mostrada a rela¸c˜ao entre os dom´ınios considerados neste trabalho (ET – Efetividade dos Treinamentos, CP – Cultura em Processos e CN – Conformidade com o Processo), tamb´em para cada gerˆencia.

55

4.6.1

Dados Agrupados Por Quest˜ ao

Quest˜ ao 1 – Existe treinamento suficiente que capacite todos os envolvidos com a execu¸c˜ao da disciplina de requisitos a desempenhar seu papel como prevˆe o processo de desenvolvimento de software da minha organiza¸c˜ ao. Visa avaliar a percep¸c˜ao dos funcion´arios em rela¸c˜ao aos treinamentos recebidos na disciplina de Requisitos, evidenciando poss´ıveis carˆencias de treinamentos em termos quantitativos ou qualitativos. Sendo assim, respostas 0 (discordo totalmente) significam que n˜ao existe treinamento para capacitar os envolvidos a praticar a disciplina em quest˜ao. Respostas 1 (discordo parcialmente) significam que o treinamento oferecido ´e insuficiente para capacitar os envolvidos. Respostas 2 (concordo parcialmente) significam que existe treinamento, por´em com algumas deficiˆencias. E respostas 3 (concordo totalmente) significam que os treinamentos oferecidos pela empresa s˜ao suficientes e eficazes para capacitar os envolvidos a desempenhar as fun¸c˜oes previstas no processo de desenvolvimento de software da organiza¸c˜ao na disciplina de requisitos. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,38 0,80 1,22 0,79 1,09 0,91 1,29 0,67

Tabela 4.1: Respostas `a Quest˜ao 1

Figura 4.7: Histograma das Respostas `a Quest˜ao 1.

56

Quest˜ ao 2 – A gerˆencia de requisitos (processo de elicita¸c˜ ao, documenta¸c˜ ao, valida¸c˜ao, controle de mudan¸ca de requisitos) ´e extremamente necess´ aria no desenvolvimento de software. Esta quest˜ao apresenta uma defini¸c˜ao exposta no SWEBOK 2004 [SWEBOK], corpo de conhecimentos da ind´ ustria de software na ´area de Engenharia de Software que afirma ser a gerˆencia de requisitos uma das pr´aticas chave para o sucesso de projetos de engenharia de software, medindo assim a distˆancia entre a cultura de requisitos do funcion´ario e o que considerado senso comum na comunidade de engenharia de software. Sendo assim, respostas 0 (discordo totalmente) significam que o entrevistado acha que o levantamento de requisitos n˜ao ´e importante para o desenvolvimento de um software. Respostas 1 (discordo parcialmente) significam que o entrevistado acha que ´e pouco importante o levantamento de requisitos. Respostas 2 (concordo parcialmente) significa que o entrevistado acha importante mas n˜ao imprescind´ıvel para o processo de desenvolvimento. E respostas 3 (concordo totalmente) significam que o levantamento de requisitos ´e importante e traz beneficios ao processo de desenvolvimento. Gerˆencia A B C D

M´edia Desvio Padr˜ao 2,58 0,76 2,46 0,80 2,35 0,77 2,40 0,91

Tabela 4.2: Respostas `a Quest˜ao 2

Figura 4.8: Histograma das Respostas `a Quest˜ao 2.

57

Quest˜ ao 3 – Na minha equipe todos os requisitos identificados e implementados numa manuten¸c˜ao, projeto ou versionamento, s˜ ao de fato REGISTRADOS nos documentos de requisitos e passam pelo processo previsto no PDS–BY para a disciplina de Requisitos. Avalia se, na opini˜ao do funcion´ario, a disciplina de requisitos do processo real de desenvolvimento de software executado ´e aderente ao modelo de processos definido. Neste contexto, respostas 0 (discordo totalmente) significam que o processo executado n˜ao mapeia o modelo de processos previsto. Respostas 1 (discordo parcialmente) significam que o processo real mapeia pouco o modelo proposto, neste contexto. Respostas 2 (concordo parcialmente) significam que o processo executado implementa muito do que o modelo prevˆe, mas n˜ao tudo. E respostas 3 (concordo totalmente) demonstra que o processo executado ´e fiel ao modelo de processo proposto. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,46 0,95 1,27 0,87 1,20 0,81 1,66 1,03

Tabela 4.3: Respostas `a Quest˜ao 3

Figura 4.9: Histograma das Respostas `a Quest˜ao 3.

58

Quest˜ ao 4 – Todos os requisitos funcionais e n˜ ao–funcionais precisam estar registrados num documento de requisitos ou num equivalente eletrˆ onico (sistema de gerˆencia de requisitos). Esta quest˜ao apresenta uma defini¸c˜ao exposta no SWEBOK 2004 [SWEBOK], corpo de conhecimentos da ind´ ustria de software na ´area de Engenharia de Software que afirma ser o registro dos requisitos em documento ou meio eletrˆonico equivalente parte essencial de um processo de levantamento de requisitos quer seja de um sistema pequeno ou grande. Assim, respostas 0 (discordo totalmente) significam que o funcion´ario acha que n˜ao precisa documentar os requisitos. Respostas 1 (discordo parcialmente) significam que ele acha ser necess´ario registrar apenas os requisitos classificados como mais importantes. Respostas 2 (concordo parcialmente) significam que o entrevistado acha importante documentar os requisitos mas n˜ao imprescind´ıvel que sejam todos. E respostas 3 (concordo totalmente) significam todos os requisitos devem estar documentados. Gerˆencia A B C D

M´edia Desvio Padr˜ao 2,31 0,84 2,35 0,72 2,30 0,76 2,49 0,70

Tabela 4.4: Respostas `a Quest˜ao 4

Figura 4.10: Histograma das Respostas `a Quest˜ao 4.

59

Quest˜ ao 5 – Os procedimentos utilizados na minha organiza¸c˜ ao para identificar, coletar e documentar, os requisitos dos sistemas desenvolvidos est˜ ao de acordo com o processo definido. Avalia se, na opini˜ao do funcion´ario, o processo real de desenvolvimento de software executado ´e aderente ao modelo de processos definido. Neste contexto, respostas 0 (discordo totalmente) significam que o processo executado n˜ao mapeia o modelo de procesos previsto. Respostas 1 (discordo parcialmente) significam que o processo real mapeia pouco o modelo proposto. Respostas 2 (concordo parcialmente) significam que o processo executado implementa muito do que o modelo prevˆe, mas n˜ao tudo. E respostas 3 (concordo totalmente) demonstra que o processo executado ´e fiel ao modelo de processo proposto. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,69 0,74 1,51 0,65 1,39 0,80 1,94 0,76

Tabela 4.5: Respostas `a Quest˜ao 5

Figura 4.11: Histograma das Respostas `a Quest˜ao 5.

60

Quest˜ ao 6 – Quando executo tarefas inerentes ` a disciplina de requisitos no desenvolvimento de solu¸c˜oes de software utilizo conhecimentos adquiridos atrav´es dos treinamentos disponibilizados pela organiza¸c˜ ao onde trabalho. Avalia se os treinamentos oferecidos pela empresa, na ´area de requisitos, est˜ao aderentes `as necessidades pr´aticas enfrentadas pelos funcion´arios na execu¸c˜ao daquela disciplina. Desta forma, respostas 0 (discordo totalmente) significam que o formato (conte´ udo, carga hor´aria, metodologia, etc) n˜ao est˜ao adequados a`s necessidades pr´aticas da execu¸c˜ao desta disciplina. Respostas 1 (discordo parcialmente) significam que o formato dos treinamentos est´a pouco adequado `as necessidades reais do trabalho. Respostas 2 (concordo parcialmente) significam que o formato dos treinamentos, mapeiam mas n˜ao totalmente as necessidades do trabalho em requisitos. E respostas 3 (concordo totalmente) significam que os treinamentos oferecidos pela empresa est˜ao de acordo com as caracter´ısticas exigidas pela disciplina de requisitos no processo de desenvolvimento de software da organiza¸c˜ao. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,81 0,85 1,46 0,87 1,24 0,92 1,46 0,85

Tabela 4.6: Respostas `a Quest˜ao 6

Figura 4.12: Histograma das Respostas `a Quest˜ao 6.

61

Quest˜ ao 7 – Existe treinamento suficiente que capacite todos os envolvidos com a execu¸c˜ao da disciplina de gerˆencia de projetos a desempenhar seu papel como prevˆe o processo de desenvolvimento de software da minha organiza¸c˜ ao. Visa avaliar a percep¸c˜ao dos funcion´arios em rela¸c˜ao aos treinamentos recebidos na disciplina de Gerˆencia de Projetos, evidenciando poss´ıveis carˆencias de treinamentos em termos quantitativos ou qualitativos. Sendo assim, respostas 0 (discordo totalmente) significam que n˜ao existe treinamento para capacitar os envolvidos a praticar a disciplina em quest˜ao. Respostas 1 (discordo parcialmente) significam que o treinamento oferecido ´e insuficiente para capacitar os envolvidos. Respostas 2 (concordo parcialmente) significam que existe treinamento, por´em com algumas deficiˆencias. E respostas 3 (concordo totalmente) significam que os treinamentos oferecidos pela empresa s˜ao suficientes e eficazes para capacitar os envolvidos a desempenhar as fun¸c˜oes previstas no processo de desenvolvimento de software da organiza¸c˜ao na disciplina de Gerˆencia de Projetos. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,42 0,81 1,08 0,80 0,89 0,82 1,17 0,82

Tabela 4.7: Respostas `a Quest˜ao 7

Figura 4.13: Histograma das Respostas `a Quest˜ao 7.

62

Quest˜ ao 8 – No desenvolvimento de solu¸c˜ oes de software de tamanho m´edio a grande ´e indicado fazˆe–lo na forma de um projeto (escopo, prazo e custo definidos e gerenciados). Parte da premissa de que a constru¸c˜ao de grandes solu¸c˜oes de sistemas, envolvem grande complexidade, e possuem alto risco de desvios em rela¸c˜ao ao seu escopo, prazos e custos, ensejando o controle destes trˆes parˆametros b´asicos, sendo o modelo de gerˆencia de projetos o mais adequado para a minimiza¸c˜ao deste risco. Assim, respostas 0 (discordo totalmente) significam que funcion´ario n˜ao considera essencial o atendimento a grandes demandas de constru¸c˜ao de solu¸c˜oes de software usando o paradigma de gerˆencia de projetos. Respostas 1 (discordo parcialmente) significam que o usu´ario considera este tratamento pouco importante. Respostas 2 (concordo parcialmente) funcion´ario acha importante mas n˜ao imprescind´ıvel que seja tratado neste paradigma. E respostas 3 (concordo totalmente) demonstra o funcion´ario acha que ´e importante o uso do paradigma de gerˆencia de projetos em desenvolvimentos deste tipo. Gerˆencia A B C D

M´edia Desvio Padr˜ao 2,46 0,58 2,57 0,69 2,24 0,79 2,63 0,69

Tabela 4.8: Respostas `a Quest˜ao 8

Figura 4.14: Histograma das Respostas `a Quest˜ao 8.

63

Quest˜ ao 9 – No desenvolvimento de projetos ´e comum iniciar a an´ alise e desenvolvimento da solu¸c˜ao com o projeto ainda na fase de Planejamento (defini¸c˜ ao de escopo, elabora¸c˜ao do plano do projeto, cronograma, aprova¸c˜ oes, etc). Quest˜ao embasada no fato de o processo de desenvolvimento de software da empresa pesquisada prever a fase de an´alise e desenvolvimento de software est˜ao encerradas em uma fase chamada de Execu¸c˜ao que ´e iniciada somente ap´os a conclus˜ao da fase de Planejamento do Projeto (fase que encerra a abertura do projeto, a elabora¸c˜ao do plano do projeto com a defini¸c˜ao de escopo, riscos, cronogramas, or¸camentos). Logo, respostas 0 (discordo totalmente) significam que o processo nunca ´e executado conforme descrito no modelo, em rela¸c˜ao `a ordem das disciplinas e seus pr´e-requisitos (entradas previstas para cada fase). Respostas 1 (discordo parcialmente) significam que na maioria das vezes a ordem das tarefas no processo de desenvolvimento real executado, difere do planejado no modelo. Respostas 2 (concordo parcialmente) significam que na maioria das vezes o modelo de processo ´e seguido quando da execu¸c˜ao de uma itera¸c˜ao de processo, mas nem sempre. E respostas 3 (concordo totalmente) que o processo executado ´e fiel ao modelo de processo proposto. Gerˆencia A B C D

M´edia Desvio Padr˜ao 0,81 0,80 0,92 0,80 0,83 0,68 0,94 0,91

Tabela 4.9: Respostas `a Quest˜ao 9

Figura 4.15: Histograma das Respostas `a Quest˜ao 9.

64

Quest˜ ao 10 – Todas as altera¸c˜ oes de escopo dos projetos s˜ ao registradas nas ferramentas e documentos de gerˆencia de projetos. Quest˜ao embasada no fato de o processo de desenvolvimento de software da empresa pesquisada prever que as altera¸c˜oes de escopo devam ser sempre registradas e controladas pela gerˆencia de projetos. Assim, respostas 0 (discordo totalmente) significam que a parte do processo que trata de registro e controle das altera¸c˜oes de escopo nunca ´e executada conforme descrito no modelo. Respostas 1 (discordo parcialmente) significam que na maioria das vezes esta patre do processo real n˜ao adere ao modelo proposto. Respostas 2 (concordo parcialmente) significam que na maioria das vezes o modelo de processo ´e seguido quando da execu¸c˜ao de altera¸c˜oes de escopo, mas n˜ao sempre. E respostas 3 (concordo totalmente) que o processo executado ´e fiel ao modelo de processo proposto. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,50 0,86 1,68 0,97 1,65 0,77 1,60 0,88

Tabela 4.10: Respostas `a Quest˜ao 10

Figura 4.16: Histograma das Respostas `a Quest˜ao 10.

65

Quest˜ ao 11 – Caso seja poss´ıvel, ´e prefer´ıvel que uma demanda de desenvolvimento de software de tamanho grande, seja dividida em v´ arias menores objetivando evitar o seu desenvolvimento como um projeto, enquadrando–as em outros paradigmas de desenvolvimento menos r´ıgidos como o versionamento ou a manuten¸c˜ao de software. Parte da premissa de que a constru¸c˜ao de grandes solu¸c˜oes de sistemas, envolvem grande complexidade, e possuem alto risco de desvios em rela¸c˜ao ao seu escopo, prazos e custos, ensejando o controle destes trˆes parˆametros b´asicos, sendo o modelo de gerˆencia de projetos o mais adequado para a minimiza¸c˜ao deste risco. Assim, respostas 0 (discordo totalmente) significam que funcion´ario n˜ao considera essencial o atendimento a grandes demandas de constru¸c˜ao de solu¸c˜oes de software usando o paradigma de gerˆencia de projetos. Respostas 1 (discordo parcialmente) significam que o usu´ario considera este tratamento pouco importante. Respostas 2 (concordo parcialmente) funcion´ario acha importante mas n˜ao imprescind´ıvel que seja tratado neste paradigma. E respostas 3 (concordo totalmente) demonstra o funcion´ario acha que ´e importante o uso do paradigma de gerˆencia de projetos em desenvolvimentos deste tipo. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,08 0,98 1,43 1,17 1,07 1,10 1,34 1,16

Tabela 4.11: Respostas `a Quest˜ao 11

Figura 4.17: Histograma das Respostas `a Quest˜ao 11.

66

Quest˜ ao 12 – Quando executo tarefas inerentes ` a disciplina de Gerˆencia de Projetos no desenvolvimento de solu¸c˜ oes de software utilizo conhecimentos adquiridos atrav´es dos treinamentos disponibilizados pela organiza¸c˜ ao onde trabalho. Avalia se os treinamentos oferecidos pela empresa, na ´area de Gerˆencia de Projetos, est˜ao aderentes `as necessidades pr´aticas enfrentadas pelos funcion´arios na execu¸c˜ao daquela disciplina. Desta forma, respostas 0 (discordo totalmente) significam que o formato (conte´ udo, carga hor´aria, metodologia, etc) n˜ao est˜ao adequados `as necessidades pr´aticas da execu¸c˜ao desta disciplina. Respostas 1 (discordo parcialmente) significam que o formato dos treinamentos est´a pouco adequado `as necessidades reais do trabalho. Respostas 2 (concordo parcialmente) significam que o formato dos treinamentos, mapeiam mas n˜ao totalmente as necessidades do trabalho em requisitos. E respostas 3 (concordo totalmente) significam que os treinamentos oferecidos pela empresa est˜ao de acordo com as caracter´ısticas exigidas pela disciplina de Gerˆencia de Projetos no processo de desenvolvimento de software da organiza¸c˜ao. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,85 0,88 1,54 0,90 1,30 0,81 1,71 0,79

Tabela 4.12: Respostas `a Quest˜ao 12

Figura 4.18: Histograma das Respostas `a Quest˜ao 12.

67

Quest˜ ao 13 – Existe treinamento suficiente que capacite todos os envolvidos com a execu¸c˜ao da disciplina de testes a desempenhar seu papel como prevˆe o processo de desenvolvimento de software da minha organiza¸c˜ ao. Visa avaliar a percep¸c˜ao dos funcion´arios em rela¸c˜ao aos treinamentos recebidos na disciplina de Testes, evidenciando poss´ıveis carˆencias de treinamentos em termos quantitativos ou qualitativos. Sendo assim, respostas 0 (discordo totalmente) significam que n˜ao existe treinamento para capacitar os envolvidos a praticar a disciplina em quest˜ao. Respostas 1 (discordo parcialmente) significam que o treinamento oferecido ´e insuficiente para capacitar os envolvidos. Respostas 2 (concordo parcialmente) significam que existe treinamento, por´em com algumas deficiˆencias. E respostas 3 (concordo totalmente) significam que os treinamentos oferecidos pela empresa s˜ao suficientes e eficazes para capacitar os envolvidos a desempenhar as fun¸c˜oes previstas no processo de desenvolvimento de software da organiza¸c˜ao na disciplina de Testes. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,23 0,82 0,86 0,82 0,67 0,70 0,83 0,79

Tabela 4.13: Respostas `a Quest˜ao 13

Figura 4.19: Histograma das Respostas `a Quest˜ao 13.

68

Quest˜ ao 14 – Todos os planos de testes (unidade, integra¸c˜ ao, sistema, aceita¸c˜ ao, homologa¸c˜ao) previstos no PDS–BY s˜ ao ELABORADOS antes da execu¸c˜ ao destes testes na pr´atica. Quest˜ao embasada no fato de o processo de desenvolvimento de software da empresa pesquisada prever que os planos de testes sejam elaborados antes da execu¸c˜ao dos mesmo. Assim, respostas 0 (discordo totalmente) significam que o funcion´ario n˜ao planeja os testes que realiza antes da fase de codifica¸c˜ao. Respostas 1 (discordo parcialmente) significam que planeja um m´ınimo necess´ario dos testes realizados. Respostas 2 (concordo parcialmente) significam que o entrevistado planeja a maioria dos testes que executa, mas n˜ao todos. E respostas 3 (concordo totalmente) significam o funcion´ario de fato registra os planos de testes antes de execut´a-los de fato. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,00 0,80 1,14 0,89 0,91 0,78 0,91 0,56

Tabela 4.14: Respostas `a Quest˜ao 14

Figura 4.20: Histograma das Respostas `a Quest˜ao 14.

69

Quest˜ ao 15 – Todos os testes realizados (unidade, integra¸c˜ ao, sistema, aceita¸c˜ ao, homologa¸c˜ao) na pr´atica s˜ ao DOCUMENTADOS nos planos de testes. Quest˜ao embasada no fato de o processo de desenvolvimento de software da empresa pesquisada prever que os planos de testes registrem todos os testes a serem executados, ou seja, prevˆe que os testes executados sejam registrados em algum lugar. Assim, respostas 0 (discordo totalmente) significam que os testes realizados pelo funcion´ario n˜ao mapeia aqueles que s˜ao planejados e registrados nos planos de testes ou similar. Respostas 1 (discordo parcialmente) significam que a maioria dos testes realizados n˜ao s˜ao documentados. Respostas 2 (concordo parcialmente) significam que o entrevistado executa e registra a maioria dos testes realizados, mas n˜ao todos. E respostas 3 (concordo totalmente) significam o funcion´ario documenta todos os testes que realiza. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,50 0,95 1,30 0,88 1,28 0,83 1,31 0,80

Tabela 4.15: Respostas `a Quest˜ao 15

Figura 4.21: Histograma das Respostas `a Quest˜ao 15.

70

Quest˜ ao 16 – O planejamento dos testes a serem executados ao longo do ciclo de desenvolvimento de software (testes de unidade, integra¸c˜ ao, sistema, aceita¸c˜ ao, homologa¸c˜ao) deve ser realizado e registrado ANTES da codifica¸c˜ ao propriamente dita. Esta quest˜ao apresenta uma defini¸c˜ao exposta no SWEBOK 2004 [SWEBOK], corpo de conhecimentos da ind´ ustria de software na ´area de Engenharia de Software que afirma: ”Indeed, planning for testing should start with the early stages of the requirement process, and test plans and procedures must be systematically and continuously developed, and possibly refined, as development proceeds” [SWEBOK]. Desta forma, infere-se que o planejamento dos testes deve ser realizado antes da execu¸c˜ao das tarefas de desenvolvimento do sistema, pois iniciam j´a nas fase de requisitos. Assim respostas 0 (discordo totalmente) significam que o funcion´ario n˜ao acha que o planejamento de testes deve ser executado antes desenvolvimento. Respostas 1 (discordo parcialmente) significam que ele acha ser necess´ario registrar antes do desenvolvimento em alguns casos apenas. Respostas 2 (concordo parcialmente) significam que o entrevistado acha importante planejar o testes antes da codifica¸c˜ao mas n˜ao sempre. E respostas 3 (concordo totalmente) significam o funcion´ario acha que o planejamento de testes deve sempre ser realizado antes da fase de codifica¸c˜ao. Gerˆencia A B C D

M´edia Desvio Padr˜ao 2,42 0,86 2,11 0,88 1,76 0,82 1,91 0,92

Tabela 4.16: Respostas `a Quest˜ao 16

Figura 4.22: Histograma das Respostas `a Quest˜ao 16. 71

Quest˜ ao 17 – Os testes executados de fato ao longo do ciclo de desenvolvimento de software n˜ao precisam estar registrados em documentos (planos, registro de resultados, etc) desde que a solu¸c˜ ao seja entregue sem erros. Esta quest˜ao apresenta uma defini¸c˜ao exposta no SWEBOK 2004 [SWEBOK], corpo de conhecimentos da ind´ ustria de software na ´area de Engenharia de Software que afirma: ”... testing should be performed in accordance with documented procedures using a clearly defined version of the software under test.”[SWEBOK]. Assim, respostas 0 (discordo totalmente) significam que o funcion´ario acha que n˜ao precisa documentar os testes realizados. Respostas 1 (discordo parcialmente) significam que ele acha ser necess´ario registrar apenas alguns testes mais relevantes. Respostas 2 (concordo parcialmente) significam que o entrevistado acha importante documentar os testes mas n˜ao imprescind´ıvel que sejam todos. E respostas 3 (concordo totalmente) significam todos os testes devem estar documentados. Gerˆencia A B C D

M´edia Desvio Padr˜ao 2,27 0,96 2,11 0,97 1,96 0,94 2,17 0,82

Tabela 4.17: Respostas `a Quest˜ao 17

Figura 4.23: Histograma das Respostas `a Quest˜ao 17.

72

Quest˜ ao 18 – Quando executo tarefas inerentes ` a disciplina de Testes no desenvolvimento de solu¸c˜oes de software utilizo conhecimentos adquiridos atrav´es dos treinamentos disponibilizados pela organiza¸c˜ ao onde trabalho. Avalia se os treinamentos oferecidos pela empresa, na ´area de Testes de Software, est˜ao aderentes `as necessidades pr´aticas enfrentadas pelos funcion´arios na execu¸c˜ao daquela disciplina. Desta forma, respostas 0 (discordo totalmente) significam que o formato (conte´ udo, carga hor´aria, metodologia, etc) n˜ao est˜ao adequados `as necessidades pr´aticas da execu¸c˜ao desta disciplina. Respostas 1 (discordo parcialmente) significam que o formato dos treinamentos est´a pouco adequado a`s necessidades reais do trabalho. Respostas 2 (concordo parcialmente) significam que o formato dos treinamentos, mapeiam mas n˜ao totalmente as necessidades do trabalho em requisitos. E respostas 3 (concordo totalmente) significam que os treinamentos oferecidos pela empresa est˜ao de acordo com as caracter´ısticas exigidas pela disciplina de Testes no processo de desenvolvimento de software da organiza¸c˜ao. Gerˆencia A B C D

M´edia Desvio Padr˜ao 1,38 0,85 1,08 0,95 0,91 0,89 1,06 0,84

Tabela 4.18: Respostas `a Quest˜ao 18

Figura 4.24: Histograma das Respostas `a Quest˜ao 18.

73

4.6.2

Dados da Popula¸ c˜ ao

Figura 4.25: Histograma de Faixa Et´aria Gerˆencia A.

Figura 4.26: Histograma de Faixa Et´aria Gerˆencia B.

74

Figura 4.27: Histograma de Faixa Et´aria Gerˆencia C.

Figura 4.28: Histograma de Faixa Et´aria Gerˆencia D.

´ Figura 4.29: Histograma do Tempo na Area de TI do Banco - Gerˆencia A. 75

´ Figura 4.30: Histograma do Tempo na Area de TI do Banco - Gerˆencia B.

´ Figura 4.31: Histograma do Tempo na Area de TI do Banco - Gerˆencia C.

´ Figura 4.32: Histograma do Tempo na Area de TI do Banco - Gerˆencia D. 76

4.7

Discuss˜ ao dos Resultados

4.7.1

Resultados por Dom´ınio Individual

4.7.1.1

Dom´ınio ET - Efetividade dos Treinamentos

As quest˜oes utilizadas para mapear o dom´ınio Treinamento foram as Quest˜oes 01, 06, 07, 12, 13 e 18. As quest˜oes 1 e 6 pertencem a disciplina Requisitos. Pelas respostas da quest˜ao 1 infere-se que a maioria dos entrevistados considera os treinamentos sobre requisitos insuficiente para capacit´a-los a executar suas tarefas de acordo com o modelo de desenvolvimento da empresa. Na quest˜ao 6 as respostas mostram que os treinamentos na disciplina de requisitos n˜ao est˜ao sendo suficientes para mapear todas as necessidades dos envolvidos no processo. As quest˜oes 7 e 12 pertencem `a disciplina Gerˆencia de Projetos. As respostas dadas a quest˜ao 7 mostram que os entrevistados consideram que os treinamento sobre Gerˆencia de Projetos oferecidos pela institui¸c˜ao s˜ao insuficientes para que eles atuem de acordo com o processo de desenvolvimento de software. Na quest˜ao 12 as respostas mostram que os treinamentos de gerˆencia de projetos n˜ao s˜ao suficientes para que o funcion´ario execute suas tarefas de acordo com o modelo PDS–BY. As quest˜oes 13 e 18 pertencem `a disciplina Testes. Na quest˜ao 13 as respostas mostraram que n˜ao existe treinamento para capacitar os funcion´arios na disciplina de testes. Na quest˜ao 18 as respostas mostram que os conhecimentos utilizados nas tarefas de teste n˜ao foram adquiridos nos treinamentos oferecidos pela institui¸c˜ao. As quest˜oes pertencentes ao dom´ınio treinamento foram avaliadas na m´edia com conceito discordo parcialmente. A an´alise dos dados obtidos a partir dos question´arios permite verificar que o treinamento oferecido n˜ao tem sido suficiente para elevar a cultura de processo e fazer com que os funcion´arios adquiram conhecimento necess´ario para a pratica das disciplinas de Requisitos, Gerencia de Projetos e Teste, apontando a necessidade de aperfei¸coamento dos cursos oferecidos para que o processo de desenvolvimento esteja em conformidade com o modelo adotado pela organiza¸c˜ao.

77

4.7.1.2

Dom´ınio CP - Cultura de Processos

As quest˜oes utilizadas para mapear o dom´ınio Cultura de Processo foram as Quest˜oes 02, 04, 08, 11, 16 e 17. As quest˜oes 02 e 04 pertencem `a disciplina Requisitos. As respostas a quest˜ao 02 permite verificar que os funcion´arios acham que a gerˆencia de requisitos ´e uma etapa importante no processo de desenvolvimento de software. As respostas a quest˜ao 4 mostra que os funcion´arios acham importante o registro de requisitos em documentos ou sistemas eletrˆonicos. As quest˜oes 08 e 11 pertencem `a disciplina Gerˆencia de Projetos. As respostas a quest˜ao 08 mostram que o funcion´ario acha importante o uso do paradigma de gerencia de projetos em desenvolvimentos de solu¸c˜ao de software de tamanho m´edio a grande. As respostas a quest˜ao 11 mostram que os funcion´arios acham importante que projetos grande sejam tratados como projetos e n˜ao sejam enquadrados em paradigmas menos r´ıgidos. As quest˜oes 16 e 17 pertencem `a disciplina Testes. As respostas a quest˜ao 16 mostram que os funcion´arios acham importante planejar o testes antes da codifica¸c˜ao mas n˜ao em todos os ciclos de desenvolvimento de software. As respostas a quest˜ao 17 mostram que o entrevistado acha importante documentar os testes mas que esse procedimento n˜ao ´e imprescind´ıvel para o sucesso do seu trabalho. As quest˜oes pertencentes ao dom´ınio Cultura de Processo foram avaliadas na m´edia com o conceito concordo parcialmente. A an´alise dos dados obtidos a partir dos question´arios permite verificar que apesar dos treinamentos n˜ao estarem sendo muito eficiente percebe-se que funcion´arios j´a possuem uma cultura de processo adquirida por outros meios que n˜ao os oferecidos pela Organiza¸c˜ao.

78

4.7.1.3

Dom´ınio CN - Conformidade com os Modelos

As quest˜oes utilizadas para mapear o dom´ınio Conformidade com os modelos foram as Quest˜oes 03, 05, 09, 10, 14 e 15. As quest˜oes 03 e 05 pertencem `a disciplina Requisitos. As respostas a quest˜ao 03 mostram que o processo real mapeia pouco o modelo proposto uma vez que a documenta¸c˜ao de requisitos n˜ao ocorre conforme prop˜oe o modelo PDS–BY para todos os casos. As respostas a quest˜ao 05 mostram que os procedimentos utilizados para identificar, coletar e documentar os requisitos dos sistemas n˜ao est˜ao sendo feito de acordo com o processo definido. As quest˜oes 09 e 10 pertencem `a disciplina Gerˆencia de Projetos. As respostas a quest˜ao 09 mostram que os funcion´arios seguem as fases definidas nos modelos de desenvolvimento. As respostas a quest˜ao 10 na maior parte dos casos as altera¸c˜oes de escopo de projetos n˜ao s˜ao registrados nas ferramentas e documentos de gerˆencia de projetos. As quest˜oes 14 e 15 pertencem `a disciplina Testes. As respostas a quest˜ao 14 mostram que o planejamento de testes de unidade, de integra¸c˜ao, de sistema, de aceita¸c˜ao e de homologa¸c˜ao ´e deficiente limitando-se ao m´ınimo necess´ario. As quest˜oes pertencentes ao dom´ınio Conformidade com o modelo foram avaliadas na m´edia com o conceito discordo parcialmente. A an´alise dos dados obtidos a partir dos question´arios permite verificar que as fases propostas nos modelos s˜ao seguidas por´em os procedimentos de documenta¸c˜ao e planejamento de testes n˜ao seguem esse modelo.

79

4.7.2

Resultado da Rela¸ c˜ ao entre os Dom´ınios

4.7.2.1

Rela¸c˜ ao entre os Dom´ınios ET e CN

Os gr´aficos de dispers˜ao que relacionam as duas vari´aveis de dom´ınio ET (Efetividade dos Treinamentos) e CN (Conformidade com o Modelo) para as quatro gerˆencias pesquisadas, mostrados a seguir, evidenciaram uma rela¸c˜ao aproximadamente linear entre as duas vari´aveis de dom´ınio. Isto significa que ficou evidenciada a rela¸c˜ao direta entre as duas vari´aveis, onde o incremento de uma corresponde ao incremento da outra e vice-versa.

Figura 4.33: Gr´afico de Dispers˜ao ET x CN para a Gerˆencia A

80

Figura 4.34: Gr´afico de Dispers˜ao ET x CN para a Gerˆencia B. As gerˆencias A, B e C possuem caracter´ısticas diferentes da Gerˆencia D que ´e uma gerˆencia especializada na condu¸c˜ao de projetos corporativos e cuja estrutura interna favorece as pr´aticas da engenharia de software. As gerˆencias A, B e C, apresentam a grande diversidade de fatores e paradigmas de desenvolvimento de software apresentados na Contextualiza¸c˜ao deste trabalho e que favorecem a existˆencia de v´arios processos reais diferentes entre estas gerˆencias.

Figura 4.35: Gr´afico de Dispers˜ao ET x CN para a Gerˆencia C

81

Neste contexto, percebe-se que nas Gerˆencias A, B e C, apresentaram n´ıveis de conformidade com o processo mais baixos em m´edia que os n´ıveis de conformidade da Gerˆencia D, para os mesmos ´ındices de Efetividade de Treinamentos. Al´em disso, em rela¸c˜ao aos treinamentos em si, percebe-se que nas Gerˆencias A, B e C, o resultado dos treinamentos na conformidade dos processos com o modelo ´e maior que na Gerˆencia D, indicando que esta u ´ltima j´a apresenta n´ıveis de desenvolvimento cultural em processos mais elevado, apensar disto n˜ao estar t˜ao evidente nos outros gr´aficos de dispers˜ao mostrados a seguir.

Figura 4.36: Gr´afico de Dispers˜ao ET x CN para a Gerˆencia D Percebe-se, portanto, que o potencial de melhoria de processos nas Gerˆencias A, B e C atrav´es do investimento em treinamento especializado ´e maior que na Gerˆencia D. H´a uma maior dispers˜ao dos valores da rela¸c˜ao ET x CN na Gerˆencia D do que nas demais, evidenciando provavelmente uma gerˆencia cujo treinamento n˜ao est´a sendo direcionado de forma equitativa entre todos os seus membros, apesar dos picos de investimento em alguns. As gerˆencias A, B e C mostram n´ıveis mais baixos de efetividade de treinamento que a gerˆencia D, apesar de ser este investimento aparentemente melhor distribu´ıdo entre seus funcion´arios (dada a menor dispers˜ao dos valores).

82

4.7.2.2

Rela¸c˜ ao entre os Dom´ınios ET e CP

Os dados e gr´aficos levantados atrav´es desta pesquisa n˜ao evidenciaram uma rela¸c˜ao direta entre as duas vari´aveis de dom´ınio ET (Efetividade dos Treinamentos) e CP (Cultura em Processos), como demonstram os gr´aficos de dispers˜ao mostrados a seguir, vez que a vari´avel ET percorreu toda a sua faixa de valores poss´ıveis mas a vari´avel CP manteve-se entre os valores medianos de 2 a 2,5 com muito pouca dispers˜ao.

Figura 4.37: Gr´afico de Dispers˜ao CP x ET para a Gerˆencia A

83

Figura 4.38: Gr´afico de Dispers˜ao CP x ET para a Gerˆencia B Em geral, todas as quatro gerˆencias pesquisadas apresentaram valores m´edios relativamente altos, para a vari´avel de dom´ınio CP, apresentando por´em uma maior dispers˜ao dos valores de ET. Estes valores elevados para CP (situados entre 2 e 2,5) sugerem que as quatro gerˆencias j´a possuem uma cultura em processos relativamente formada, apesar da mesma ainda n˜ao incluir todo o corpo de conhecimentos inerentes `as disciplinas de engenharia de software abordadas na pesquisa.

Figura 4.39: Gr´afico de Dispers˜ao CP x ET para a Gerˆencia C 84

Figura 4.40: Gr´afico de Dispers˜ao CP x ET para a Gerˆencia D A gerˆencia A apresentou os maiores valores m´edios para o dom´ınio CP, por´em, aparenta que esta cultura n˜ao foi desenvolvida de forma significativa atrav´es de treinamentos fornecidos pela empresa, devendo existir outros fatores que potencializaram a cria¸c˜ao desta cultura, seja a forte renova¸c˜ao do quadro de funcion´arios da empresa abordada, ocorrida nos u ´ltimos anos que injetou um contingente de profissionais rec´em-formados ou em forma¸c˜ao na ´area de inform´atica, evidenciado pelos gr´aficos da faixa et´aria da popula¸c˜ao pesquisada e do tempo na ´area de TI do banco, ou mesmo o contexto de melhoria de processos na qual est´a inserida. Enquanto a Gerˆencia B foi a que apresentou ´ındices mais baixos de cultura de processos.

85

4.7.2.3

Rela¸c˜ ao entre os Dom´ınios CN e CP

A rela¸c˜ao entre as vari´aveis de dom´ınio CN (Conformidade com o modelo) e CP (Cultura em Processos) apresentou uma caracter´ıstica parecida com a rela¸c˜ao ET x CP, mostrada anteriormente, onde o v´ınculo entre as duas vari´aveis mostrou-se fraco, n˜ao evidenciando uma rela¸c˜ao direta entre elas, como pode ser constatado nos gr´aficos a seguir.

Figura 4.41: Gr´afico de Dispers˜ao CP x CN para a Gerˆencia A

Figura 4.42: Gr´afico de Dispers˜ao CP x CN para a Gerˆencia B 86

Tal rela¸c˜ao, por´em, pode estar mascarada pelos valores elevados de CP, j´a explanados na se¸c˜ao ET x CP que diminuem a taxa de varia¸c˜ao de CP em rela¸c˜ao `a taxa de varia¸c˜ao de CN, dificultando a an´alise de um poss´ıvel v´ınculo entre estes dom´ınios. Dentre as gerˆencias pesquisadas a gerˆencia D foi a que apresentou maiores ´ındices de conformidade com o processo, enquanto que as gerˆencias A e C apresentaram os menores.

Figura 4.43: Gr´afico de Dispers˜ao CP x CN para a Gerˆencia C Al´em disso, deve ser considerada a hip´otese de que as quest˜oes indicadas para mapear o dom´ınio CP podem n˜ao ter conseguido explorar adequadamente o dom´ınio cultura, restringindo-se, por exemplo, ao dom´ınio conhecimento, excluindo assim as cren¸cas e valores dos indiv´ıduos pesquisados.

87

Figura 4.44: Gr´afico de Dispers˜ao CP x CN para a Gerˆencia D 4.7.2.4

Coeficiente de Correla¸ c˜ ao entre os Dom´ınios

Calculando o coeficiente de correla¸c˜ao estat´ıstica entre os trˆes dom´ınios, dois a dois, obtemos os valores mostrados na tabela a seguir. Valores de correla¸ca˜o abaixo de 0.39 s˜ao indicativos de uma correla¸c˜ao fraca a bem fraca entre as duas vari´aveis comparadas, sendo o valor ZERO um indicativo de completa falta de correla¸c˜ao estat´ıstica entre as entidades comparadas. Valores acima de 0.69 indicam uma correla¸c˜ao forte, e entre 0.40 e 0.69 uma correla¸c˜ao moderada. Valores positivos de correla¸c˜ao indicam uma rela¸c˜ao onde o incremento de uma vari´avel implica no incremento da outra, enquanto que valores negativos representam uma rela¸c˜ao inversa. Os valores apresentados, portanto, s´o ratificam o que j´a foi exposto nas se¸c˜oes anteriores, evidenciando uma rela¸c˜ao direta de moderada a forte entre as vari´aveis ET e CN. Tal correla¸c˜ao, por´em, n˜ao pode ser afirmada entre a vari´avel CP e as demais. Gerˆencia A B C D

ET x CP 0,06 0,00 0,26 0,35

CN x CP 0,26 0,32 0,26 0,07

CN x ET 0,71 0,41 0,40 0,39

Tabela 4.19: Coeficiente de Correla¸c˜ao entre as Vari´aveis de Dom´ınio ET, CP e CN

88

Cap´ıtulo 5 Considera¸ c˜ oes Finais 5.1

Conclus˜ oes

Considerando a melhoria de processos de desenvolvimento de software como uma forma de aprendizagem organizacional, uma vez que modifica o modo como as pessoas da organiza¸c˜ao executam suas tarefas para alcan¸car o objetivo de produzir software com qualidade, vimos que tal aprendizagem fica prejudicada quando o componente Pessoas (triˆangulo da qualidade – processos, ferramentas e pessoas) n˜ao recebe investimento suficiente em treinamentos e forma¸c˜ao sobre engenharia de software e nas disciplinas abordadas no modelo de processo de desenvolvimento de software adotado pela organiza¸c˜ao. Percebemos assim que h´a uma rela¸c˜ao direta entre a capacidade do processo de desenvolvimento de software executado pelas pessoas da organiza¸c˜ao na pr´atica (ou seja, o processo de desenvolvimento real) e os treinamentos e cursos realizados por estas pessoas nas ´areas de conhecimento afins com as disciplinas abordadas nos modelos de processo de desenvolvimento de software. Ao contr´ario do que supomos no in´ıcio do trabalho, constatamos que desenvolver uma cultura em processos, sendo um conceito mais amplo, entendido aqui como o conjunto de cren¸cas, valores e conhecimentos nas ´areas de engenharia de software e engenharia de processos, n˜ao depende somente do investimento em treinamentos e cursos nestas ´areas, visto que no estudo de caso, as gerˆencias estudadas, apresentavam uma cultura em processos de desenvolvimento de software aparentemente desenvolvida mesmo n˜ao tendo recebido correspondente investimento em treinamentos e cursos. Por´em acreditamos que um estudo mais aprofundado com foco na rela¸ca˜o existente entre a Cultura em Processos, denominada neste trabalho de Conformidade do processo se faz necess´aria, e a pr´atica do Processo de desenvolvimento de software, pois para avaliar a Cultura em Processos, dada a sua amplitude que envolve os valores e cren¸cas do indiv´ıduo, ´e necess´ario um maior grau de detalhamento e talvez outros m´etodos cient´ıficos, de forma a conseguir medir todos os seus componentes separadamente. Acreditamos que, com a nossa pesquisa, 89

talvez s´o tenhamos conseguido mapear o componente Conhecimentos mas n˜ao as Cren¸cas e Valores do Indiv´ıduo, sendo portanto precipitado concluir que a pr´atica do processo de desenvolvimento de software segundo um modelo de processo n˜ao guarda rela¸c˜ao com o desenvolvimento de uma Cultura em Processos na organiza¸ca˜o. Dada a forte rela¸c˜ao entre a capacidade do processo executado na pr´atica e os treinamentos, seria interessante um estudo futuro baseado nas metodologias de aprendizagem com o objetivo de modelar solu¸c˜oes de ensino/aprendizagem adequadas `a realidade e necessidade de cada empresa e de seus funcion´arios.

5.2

Limita¸c˜ oes

As limita¸c˜oes deste estudo podem ser resumidas no que se segue. A pesquisa foi feita na ´area de Tecnologia de um grande Banco Brasileiro que por se tratar de uma empresa p´ ublica submetida a r´ıgidos controles estatais trouxe dificuldade na obten¸c˜ao de autoriza¸c˜ao para a realiza¸c˜ao deste estudo de caso. A gera¸c˜ao de um grande volume de dados durante a pesquisa ampliou consideravelmente o tamanho da tarefa de interpret´a-los. Apesar do esfor¸co despendido na etapa das discuss˜oes sobre os resultados, talvez n˜ao tenha sido poss´ıvel analisar, confrontar e comparar todas as informa¸c˜oes obtidas a partir dos dados coletados. A greve dos servidores da Universidade de Bras´ılia tamb´em foi um fator que dificultou a realiza¸c˜ao do trabalho, pois o acesso a textos e algumas referˆencias bibliogr´aficas ficou comprometido.

5.3

S´ıntese de Sugest˜ oes para Pesquisas Futuras

Dadas as evidˆencias de que a melhoria de processo de desenvolvimento de software constitui-se num processo de aprendizagem corporativa, e que esta guarda uma rela¸c˜ao de dependˆencia com a aprendizagem das pessoas da organiza¸c˜ao que est˜ao envolvidas com o processo, e ainda dada a demonstra¸c˜ao de que o investimento realizado na componente Pessoas (triangulo da qualidade – processos, ferramentas e pessoas) em forma¸c˜ao e informa¸c˜ao acerca de engenharia de software e dos processos em si geraram melhores resultados no aprendizado organizacional, um estudo sobre quais metodologias de ensino-aprendizagem seriam mais adequadas a contextos organizacionais de forma a maximizar o resultado dos programas de melhoria de processos faz-se necess´ario. Em pesquisas futuras seria recomend´avel verificar a importˆancia dos conhecimentos adquiridos por iniciativa do pr´oprio funcion´ario na consolida¸c˜ao e utiliza90

¸c˜ao das boas pr´aticas de desenvolvimento de software.

91

Referˆ encias [1] PFEEGLER Shari Lawrence. Engenharia de Software: Teoria e Pr´ atica. Prentice Hall, S˜ao Paulo-SP, 2nd utgave, 2004. [2] HAMPTON David R. Administra¸c˜ ao Contemporˆ anea. Makron Books, S˜ao Paulo-SP, 3rd utgave, 1992. [3] MAXIMIANO Antˆonio Cesar Amaru. Introdu¸c˜ ao ` a Administra¸c˜ ao. Editora Atlas, S˜ao Paulo-SP, 6th utgave, 2004. [4] CHAMPION Dean J. Sociologia das Organiza¸c˜ oes. Editora Saraiva, S˜ao Paulo-SP, 1st utgave, 1979. [5] DRUKER Peter Ferdinand. Sociedade P´ os-Capitalista. Editora Pioneira, S˜ao Paulo-SP, 6th utgave, 1990. [6] FILHO Jayme Teixeira. Gerenciando Conhecimento. Editora SENAC, Rio de Janeiro-RJ, 1st utgave, 2000. [7] TEAM CMMI Product. CMMI-DEV: CMMI for Development. Carnegie Mellon Software Engineering Institute, Pittsburgh-PA (USA), 1.2 utgave, Agosto 2006. [8] FILHO Wilson de P´adua Paula. Engenharia de Software - Fundamentos, M´etodos e Padr˜oes. LTC Editora, Rio de Janeiro-RJ, 2nd utgave, 2001. [9] HILGARD Ernest R. Teorias da Aprendizagem. Editora Pedag´ogica e Universit´aria LTDA, S˜ao Paulo-SP, 1st utgave, 1973. [10] MOREIRA Marco Antˆonio og MASINI Elcie F. Salzano. Aprendizagem Significativa, A Teoria de David Ausubel. Editora Moraes, S˜ao Paulo, 1st utgave, 1982. [11] AUSUBEL D., NOVAK J. og HANESIAN H. Educational Psychology: A Cognitive View. Holt, Rinehart and Winston, New York-USA, 2nd utgave, January 1978. [12] CURY Antˆonio. Organiza¸c˜ ao e M´etodos - Uma Vis˜ ao Hol´ıstica. Editora Atlas, S˜ao Paulo-SP, 8th utgave, 2006. [13] DAVENPORT Thomas H. Reengenharia de Processos. Editora Campus, Rio de Janeiro-RJ, 5th utgave, 1994. 92

[14] KISIL Marcos. Gest˜ao da Mudan¸ca Organizacional - Volume 4. Editora Funda¸c˜ao Peir´opolis LTDA, S˜ao Paulo-SP, 1st utgave, 1998. [15] BOOCH Grady, RUMBAUGH James og JACOBSON Ivar. UML - Guia do Usu´ario. Editora Campus, Rio de Janeiro-RJ, 1th utgave, 2000. [16] MARTIN Robert C. Agile Software Development - Principles, Patterns, and Practices. Prentice Hall, Upper Saddle River-NJ, 1st utgave, 2003. [17] STERNBERG Robert J. Psicologia Cognitiva. Artmed Editora, Porto Alegre, 1st utgave, 2000. [18] PEREIRA Jos´e Matias. Metodologia Cient´ıfica - Manual de Pesquisa Cient´ıfica. Editora Universidade de Bras´ılia, Bras´ılia-DF, 1th utgave, 2006. [19] CERUTTI Aldo et al. Adequa¸c˜ ao do Modelo CMM (Capability Maturity Model for Software) ao Ambiente de Desenvolvimento do Banco do Brasil S.A. Monografia de Conclus˜ao de Curso de P´os-Gradua¸c˜ao, Bras´ılia-DF, 1st utgave, Outubro 2001. [20] WATANABE M´ario. Capacidade Organizacional nos Processos de Inova¸ca˜o e Mudan¸ca em Tecnologia da Informa¸c˜ ao: O Caso de uma Institui¸c˜ ao Financeira. Disserta¸c˜ao de Conclus˜ao de Curso de P´os-Gradua¸c˜ao, Bras´ılia-DF, 1st utgave, Maio 2004. [21] LAUDON Kenneth C. og LAUDON Jane Price. Sistemas de Informa¸c˜ao. LTC - Livros T´ecnicos e Cient´ıficos Editora, Rio de Janeiro-RJ, 4th utgave, 1999. R Guide, A Guide to the Pro[22] PMI Project Management Institute. PMBOK ject Management Body of Knowledge. PMI, Newtown Square-PA (USA), 3rd utgave, November 2004.

[23] SOFTEX Sociedade. MPS.BR-Melhoria de Processo do Software Brasileiro, Guia Geral. SOFTEX, Bras´ılia-DF, 1.1 utgave, Maio 2006. [24] MOREIRA Marco Antˆonio. A Teoria da Aprendizagem Significativa e Sua Implementa¸c˜ao em Sala de Aula. Editora Universidade de Bras´ılia, Bras´ıliaDF, 1st utgave, 2006. [25] WHALEY Donald L. og MALOTT Richard W. Princ´ıpios Elementares do Comportamento. Editora Pedag´ogica e Universit´aria LTDA, S˜ao Paulo, 1st utgave, 1980. [26] KRECH David og Richard S. CRUTCHFIELD. Elementos de Psicologia Segundo Volume. Pioneira Editora, S˜ao Paulo-SP, 4th utgave, 1973. [27] LIMONGI-FRANCA ¸ Ana Cristina. As Pessoas na Organiza¸c˜ ao. Editora Gente, S˜ao Paulo-SP, 2nd utgave, 2002. [28] LAPPONI Juan Carlos. Estat´ıstica Usando Excel. Lapponi Treinameto e Editora, S˜ao Paulo-SP, 1th utgave, 2000. 93

Apˆ endice A Email de convoca¸ c˜ ao para participa¸ c˜ ao na pesquisa

94

95

Apˆ endice B Question´ ario enviado ` as Gerˆ encias de TI do Banco Y

96

97

98