II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

Metodologias geis: Um Novo Paradigma de Desenvolvimento de Software

Renata Bastos Ferreira
1

, Francisco de Paula Antunes Lima2

Departamento de RH ATAN Cincia da Informao Tel.: (31) 3289.7769 Belo Horizonte MG Brasil Departamento de Engenharia de Produo UFMG Tel.: (31) 3499.4895 Belo Horizonte MG Brasil
2

renata.bastos@atan.com.br, fpalima@dep.ufmg.br

Abstract: The Software Engineering for a long time has been facing problems related to the delay in the delivery of projects, the extrapolated budget, the costumers and users discontentment, besides the conflicts and detritions among annalists and costumers. Aiming at better results, the IT companies are adopting software development methodologies more flexible and propitious to the frequent changes, beyond more interaction during the whole project between the users and the system itself. These methodologies are considered agile in contraposition to the heavy methodologies that, traditionally, prevailed in the area but have shown themselves ineffective and unproductive. Resumo: A Engenharia de Software h muito vem enfrentando problemas relativos a atraso na entrega de projetos, oramento extrapolado, insatisfao de clientes e usurios, alm de conflitos e desgastes entre analistas e clientes. Visando a melhores resultados, as empresas de TI esto adotando metodologias de desenvolvimento de software mais flexveis e propcias s freqentes mudanas, alm de mais interao durante todo o projeto entre os usurios e o prprio sistema. Estas metodologias so chamadas de geis em contraposio s metodologias pesadas que, tradicionalmente, predominaram na rea, mas que se mostraram ineficientes e improdutivas.

1. Introduo: definio do escopo de projeto

Um problema freqente da concepo de sistemas informatizados a dificuldade de se definir, de incio, o escopo do projeto (funcionalidades, requisitos etc.). No momento da definio do escopo, o cliente e os diversos usurios do sistema geralmente no sabem o que querem, isto , parecem ser incapazes de definir detalhadamente as funes e procedimentos operacionais do sistema, o que comumente atribudo ao desconhecimento, por parte do cliente, (1) da tecnologia de informtica (linguagem tcnica e possibilidades das aplicaes), (2) de caractersticas do prprio processo a ser informatizado ou (3) de suas prprias necessidades, sempre cambiantes ao longo do desenvolvimento do sistema. Em conseqncia, os programas desenvolvidos no atendem ou atendem mal s necessidades dos clientes, gerando frustrao, perda de tempo em retrabalho e, inevitavelmente, conflitos e desgaste das relaes entre os contratantes. Os estudos de avaliao das promessas da informtica colocam em dvida se os ganhos de produtividade so efetivos ou to significativos como se pretende (sobre

107

II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

isso, ver LOJKINE, 1996; DERTOUZOS, 1997 e vrios estudos em KLING, 1996). De modo geral, a tendncia atual de diversificao de produtos para atender mercados fragmentados, mediante uma maior customizao, depende do reconhecimento preciso das necessidades reais dos usurios. Essa adequao pode no ocorrer devido a problemas de comunicao, quando se adota um processo de desenvolvimento seqencial, separando a fase de concepo da operao em escala real. As conseqncias so bem conhecidas: canibalismo entre produtos semelhantes, no atendimento das necessidades dos clientes, retrabalho, atrasos e perda de produtividade em geral. Em seus estudos de caso, Wheelwright e Clark (1992) revelaram o modo reativo de resoluo de problemas adotado pelos gerentes de projeto (after-the-fact problem solving), ao invs de preveno de problemas por meio de pr-projetos e planejamento mais efetivos. Esse comportamento reativo diminui o poder dos gerentes para influenciar as solues de projeto. O problema do escopo mal definido acontece em todos os tipos de projeto, de bens de consumo s instalaes e equipamentos industriais, de natureza mais tcnica. Por exemplo, a anlise dos conflitos entre clientes e fornecedores de equipamentos automticos na Frana revelou o papel crucial das especificaes (cahier des charges), que estavam sujeitas a mltiplas interpretaes. De um lado, os clientes estavam insatisfeitos com equipamentos que no atendiam suas necessidades, de outros os construtores reclamavam da impreciso dos requisitos das encomendas. Aps estudos conduzidos por um consrcio entre clientes, fornecedores, entidades de classe e pesquisadores, chegou-se concluso que a especificao no uma questo puramente tcnica (a ser resolvida, por exemplo, com um check list aperfeioado), uma vez que os problemas decorriam, sobretudo, das relaes sociais entre cliente e fornecedor (TIGER, 1990). Essa tendncia de associao dos clientes e dos usurios finais ao processo de desenvolvimento de produtos em geral, e de softwares em particular, surge como uma alternativa para se melhoras as especificaes, na forma de uma coresponsabilizao. No caso dos projetos de automao estudados por ns, um dos tcnicos associa os prejuzos sofridos pela empresa precariedade da especificao dos requisitos de projeto: "O foco principal do prejuzo no est no desenvolvimento tcnico do projeto, pois este muito bom, mas no pouco contato com o cliente e na especificao rpida (programador). O foco de anlise deve, portanto, ser redirecionado para as relaes entre fornecedores e clientes. Apesar dos mtodos de desenvolvimento de softwares preverem a avaliao permanente dos clientes, os procedimentos e as tcnicas de participao ainda esto distantes de se conseguir uma associao efetiva. As recomendaes, por vezes, se limitam a aspectos comportamentais, notadamente na capacidade comunicativa: uma publicao j antiga, nos ensina que o analista tem que ter "talentos combinados de lder, professor e psiclogo (...), saber entender as queixas dos clientes, reclamaes e opinies do usurio" (CARVALHO, 1988, p. 175) e,na fase de implementao, detectar "desvios, erros, atitudes perigosas"(ibid. p. 201). Mais recentemente, o surgimento das metodologias geis se apresenta como uma possvel soluo para integrar o usurio ao processo de desenvolvimento de softwares (OLIVEIRA, 2003), s vezes combinadas com metodologias top-down (BOEHM e TURNER, 2004).

108

II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

2. Quadro de referncia: associando abordagens descendentes e ascendentes

Os mtodos tradicionais de engenharia possuem em comum o fato de serem um processo descendente (top-down), que parte de uma lista de requisitos ou do conceito de um produto, progressivamente concretizado ao longo do processo de desenvolvimento do produto (PDP). Isso torna o PDP, predominantemente, seqencial e linear. Mesmo os reajustes, nos momentos de iterao e de avaliao, so correes de percurso em funo de um objetivo pr-determinado, no influenciando de modo significativo o escopo inicial. A distncia entre o produto oferecido e as necessidades reais dos clientes e usurios, verificada na prtica, coloca em questo a eficcia desse processo seqencial. Ainda que esta seqncia seja quebrada em vrios ciclos iterativos, o procedimento permanece top-down, partindo do modelo conceitual para os detalhes das situaes de uso. "Uma outra abordagem, que pode ser qualificada de ascendente ou bottom-up, parte do princpio de que a considerao das condies de realizao da atividade de trabalho, desde as etapas iniciais de um projeto, pode ajudar a esclarecer as escolhas a serem feitas em relao concepo dos sistemas tcnicos e dos postos de trabalho. Trata-se de uma abordagem complementar abordagem descendente ou top-down" (DUARTE, 2000). O princpio desta abordagem o inverso da anterior: as fases subseqentes influenciam nas decises tomadas em fases iniciais, o que instaura uma temporalidade especfica ao PDP, dando mais fora s linhas de retroao. Assim, a possibilidade de (re)definir o escopo durante o PDP depende das diversas combinaes entre estratgias de projeto descendentes e ascendentes, onde se criam condies de antecipao e de correo, sem necessidade de um grande retrabalho. Os esquemas abaixo permitem compreender melhor as possibilidades de combinao entre mtodos descendentes e ascendentes, configurando-se espaos de manobra diferentes. A Figura 1 representa as duas abordagens e o espao possvel para a considerao de determinantes das situaes futuras de utilizao do produto (operao, manuteno...). A rea sob a curvas indica o espao de manobra para a equipe de projeto efetivar alteraes e encontrar solues alternativas, o que depende da capacidade de antecipao dos compromissos a serem estabelecidos no decorrer do PDP. Na Figura 2 esto representadas diferentes possibilidades de articulao entre as abordagens ascendentes e descendentes. A linha A tpica do PDP tradicional, quando as informaes sobre as situaes reais de utilizao aparecem apenas no final do projeto ou aps a partida (start-up). O espao de manobra para se estabelecerem compromissos favorveis reduzido, com efeitos negativos sobre as condies de trabalho e sobre a produtividade. A linha B representa um PDP em que as abordagens ascendentes e descendentes, apesar de iniciarem simultaneamente, s se encontram ao final do projeto, sem interaes durante o desenvolvimento. Seus inconvenientes so os mesmos da situao A: "as margens de manobra para mudanas nos projetos so muito reduzidas, pois as principais decises j foram tomadas" (DUARTE, 2000).

109

II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

Decises globais

B A
Decises especfica ESTUDOS capacidade de antecipa e margem de manobra PARTIDA ESTUDOS PARTIDA

FIGURA 1: Articulao entre as abordagens descendentes e ascendentes. Adaptado de Duarte, 2000.

FIGURA 2: Diferentes articulaes entre abordagens descendentes e ascendentes. Adaptado

Finalmente, na abordagem ascendente representada pela linha C, torna-se possvel a reflexo entre os agentes envolvidos no projeto (gerentes, tcnicos, clientes e usurios) a respeito de suas opes principais. "Essa combinao das abordagens descendentes e ascendentes permite a descrio e compreenso das inter-relaes entre os diferentes componentes do projeto, ampliando a capacidade de antecipao e reduzindo, ao longo do processo de concepo, as incertezas relativas eficcia do funcionamento futuro." (DUARTE, 2000) Assim, gere-se melhor os efeitos de irreversibilidade implicados em qualquer deciso. Evidentemente, a simples enunciao desse princpio no cria as condies necessrias para a antecipao, apenas assinala a necessidade de que isso ocorra. Se viabilizado, problemas clssicos em desenvolvimento de softwares, como a prototipagem, em especial a tendncia a transformar um prottipo que consome grande parte dos recursos em produto (PREECE, ROGERS e SHARP, 2005), poderiam ser resolvidos ou amenizados. A questo se resolve na medida em que as avaliaes se tornam mais realistas e que a experincia dos usurios diretos incorporada na especificao dos softwares. Vinck et al. (1999) mostram, em uma anlise comparativa, como a incorporao da experincia dos tcnicos de cho-de-fbrica permite desenvolver um sistema CAD-CAM (aplicado em projetos de matrizes de extruso de perfis de alumnio) bem mais eficiente do que o sistema desenvolvido apenas com os conhecimentos de engenharia. O primeiro software no definia por si s as sadas, mas deixava espao para ajustes feitos pelos tcnicos e supervisores de produo que amenizavam, por exemplo, um ngulo da matriz "demasiadamente agudo".

110

OTNEMAHLATED E OTNEMIVLOVNESED

OTNEMAHLATED E OTNEMIVLOVNESED

II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

3. Como a metodologia influncia no sucesso ou no fracasso do projeto

3.1 Metodologias tradicionais ou pesadas Dentre as abordagens descendentes, encontram-se as chamadas metodologias tradicionais ou pesadas, devido ao seu tamanho e dificuldade de serem implementadas na ntegra (OLIVEIRA, 2004). Historicamente, elas predominaram e ainda so muito utilizadas nos projetos de desenvolvimento de software (OLIVEIRA, 2004). O que melhor caracteriza estas metodologias a separao bem rgida das fases de projeto, que consistem em: Levantamento de Requisitos, Anlise, Desenho, Implementao, Testes e Implantao. Cada fase tem suas especificidades e possuem entre si interdependncia, isto , a prxima fase s comea quando a anterior estiver pronta. Isto significa que o processo seqencial e linear, no qual cada fase deve ser concluda antes de passar para a prxima etapa. Estas metodologias seguem o modelo tradicional da engenharia como a Engenharia Civil ou Eltrica, onde o desenvolvimento do sistema dividido em duas fases distintas: o sistema primeiramente planejado e, depois do planejamento pronto, o sistema construdo. A fase de concepo do projeto ou planejamento realizada por uma equipe de analistas que, mediante reunies e discusses com os clientes ou usurios, estrutura como o sistema vai ser, quais sero suas funcionalidades e caractersticas. Nesta fase necessrio grande trabalho de documentao, pois este ser o alicerce do projeto; com isso muito tempo gasto para que haja um levantamento de requisitos completo e claro, a fim de evitar o aparecimento de novos requisitos ou funcionalidades durante a fase de desenvolvimento do projeto. Por este motivo recomendvel que os analistas de sistema tenham como caracterstica de personalidade a facilidade de comunicao. indispensvel ao trabalho dos analistas de sistemas uma boa aptido para o dilogo, para a expresso, comunicao verbal, escuta e para a interao, respeitosa e profunda, com pessoas que vivem e trabalham no meio ambiente onde a fbrica de informao vai ser instalada (CARVALHO, 1988, p. 143). Como seu trabalho uma espcie de ponte entre as necessidades e problemas humanos e a computao, "o analista tem de saber entender as queixas, reclamaes e opinies do usurio, filtrando-as e sintetizando-as em termos de necessidades efetivas e economicamente justificveis" (ibid., p. 175). Os analistas de sistemas consideram esta fase de definio do escopo a mais importante do projeto, pois dependendo da sua qualidade, o projeto ter sucesso ou no. Quanto mais imprevistos surgirem durante o desenvolvimento, maior ser o retrabalho e conseqentemente o tempo de realizao do projeto, uma vez que uma modificao na base do sistema, isto , no escopo do projeto, acarreta mudanas estruturais muitas vezes complexas e impactantes para o desenvolvimento do sistema, comprometendo assim os prazos, o preo e qualidade do servio. como se um prdio j tivesse todo pronto e, de repente, descobre-se um problema na sua sustentao, obrigando os engenheiros a desconstruir boa parte do trabalho e refaz-lo novamente. Alm dos prejuzos com o grande retrabalho e os atrasos, outra caracterstica marcante destas metodologias preditivas a punio com faturamentos de extra-escopo quando o conjunto inicial de requisitos modificado, o que leva a conflitos entre clientes e analistas. Mas pior que o aumento do oramento originado pelo retrabalho ou pelo

111

II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

aumento do escopo devido a requisitos no especificados inicialmente, a ineficincia do sistema que no atende s necessidades dos clientes, situao esta comum de acontecer devido estrutura seqencial e linear do projeto. Os clientes ou usurios s participam da fase inicial do projeto (concepo) e da final, que a implantao do sistema. Durante o desenvolvimento propriamente dito no h interao alguma entre os usurios e o sistema, impedindo assim as correes graduais e as implementaes de novas funcionalidades correspondentes s necessidades dos usurios. Quando o projeto est todo pronto que os usurios tero a oportunidade de experiment-lo, e, caso percebam problemas, h muita resistncia dos analistas em corrigi-los, deixando de fora muitas necessidades dos usurios. O relato de um operador, usurio final de um sistema de automao, retrata muito bem este problema: quando eles vo embora fica um monte de problema pra trs, a gente tem que ficar arrumando e burlando o sistema, seno a gente no trabalha e a produo no sai como deveria (operador de fbrica). Devido a esses problemas, a Engenharia de Software tem se empenhado na construo de novas metodologias de desenvolvimento, dentre elas as metodologias geis, que parte de premissas contrrias quelas das metodologias pesadas.

3.2. Metodologias geis

Uma premissa fundamental das metodologias geis o reconhecimento da dificuldade do usurio saber de antemo as funcionalidades que gostaria que o sistema tivesse. Por isso, essas metodologias adotam a abordagem ascendente, isto , criam condies favorveis para as interaes e as retro-alimentaes entre usurios e o sistema durante todo o projeto, uma vez que so as necessidades reais dos usurios, e no o conceito do sistema ideal, o ponto chave do sucesso do projeto. As necessidades dos usurios so, por outro lado, sempre mutveis, isto , no so definidas (nem definveis) a priori, mas vo-se desenhando ao longo do projeto. Donde a necessidade de uma abordagem que rompa com a temporalidade linear do projeto organizado em fases seqenciais (ver, por exemplo, a metodologia do objetos intermedirios (CAMPOS, 2002; VINCK, 1999), que aperfeioa as simulaes e modelos convencionais de prototipagem). A percepo que os usurios tm de suas necessidades tambm evolui medida que eles conhecem o sistema. difcil compreender o valor de uma determinada funcionalidade at que ela seja efetivamente usada, principalmente porque no se pode requerer de um usurio comum a mesma capacidade de abstrao que um desenvolvedor possui ao olhar um conjunto de requisitos (OLIVEIRA, 2003, p. 16). Com isso, as metodologias geis so estruturadas de modo a atender a natureza mutvel e dinmica do processo de concepo do sistema. Diferentemente das metodologias pesadas que possuem fases bem separadas e delimitadas, nas metodologias geis, as fases de concepo e desenvolvimento interagem durante todo o projeto, possibilitando desse modo uma interao constante entre os usurios e os analistas, ou seja, entre os profissionais da concepo e da operao, como ocorre nos projetos na "produo enxuta": as equipes de projeto japonesas permanecem no local at bem depois da implantao e operam contnuas mudanas, acumulando, assim, novos conhecimentos, que sero transferidos aos sistemas atravs das modificaes que fazem (LOJKINE, 1995, p. 248). Tem-se, assim, um modelo no-linear, que enfatiza a retroao de fases posteriores sobre as

112

II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

fases anteriores e interao concepo/produo. As metodologias geis propem que os projetos devam ser conduzidos de forma adaptativa, isto , feito atravs de desenvolvimento iterativo e interativo. A idia central trabalhar com iteraes curtas. Cada iterao entrega ao seu final um produto completo e pronto para ser usado, que contm a implementao de um novo subconjunto de caractersticas. O uso de iteraes curtas permite aos usurios e clientes fazerem uma avaliao do sistema logo que uma verso inicial colocada em produo. Neste momento, usurios, clientes e desenvolvedores decidem sobre quais caractersticas devem ser adicionadas, quais devem ser modificadas, e at, quais devem ser retiradas do sistema. O sistema desenvolvido da forma mais iterativa possvel. O escopo de cada iterao pequeno e contempla somente as funcionalidades que aquela iterao dever possuir, deixando para iteraes futuras o restante dos requisitos. O oramento segue a lgica das iteraes, isto , cada iterao ter um custo definido e pago aps a sua concluso. Obtm-se com isso facilidade na negociao, tendo em vista que o aparecimento de novas funcionalidades ser negociado na prxima iterao. Para o cliente esses procedimentos so tambm vantajosos, pois ele ter maior transparncia e visibilidade do processo, poder acompanhar seu desenvolvimento e seus investimentos. Mas nem sempre foi fcil convencer o cliente deste mtodo, que comea a ser posto em prtica em projetos de automao industrial em uma empresa brasileira, antes acostumados aos projetos baseados na metodologia pesada. A dificuldade era convencer o cliente a pagar parcelado, ao invs de comprar o sistema no valor global de 1000,00 reais (valor fictcio), ele pagaria 10 iteraes de 100,00 reais. Por mais interessante que possa parecer, causou muita estranheza no incio. Atualmente os clientes que participaram de projetos baseados nas metodologias geis esto satisfeitos e demandando sempre por novas iteraes, o que tem gerado contratos permanentes. O sucesso desta metodologia est relacionado aos sistemas mais adaptados s necessidades dos usurios, ao cumprimento dos prazos e do oramento, uma vez que as correes esperadas de cada iterao no impactam mais em grandes retrabalhos. Pelo contrrio, as modificaes aqui so desejadas, tanto que as iteraes servem para estimular o contato do usurio com o sistema justamente para possibilitar o mximo de correes, evitando-se assim que, ao final, ele venha a apresentar ineficincias. Quanto mais cedo os problemas aparecerem, melhores so as chances de se obter um sistema eficiente, no tempo estimado e no preo acordado. Problemas clssicos na informtica (apesar de ser uma prtica relativamente nova), como no cumprimento de prazos, m qualidade dos softwares e oramentos estourados (CARVALHO, 1988), so contornados com esta nova metodologia.

4. Concluso
A soluo dos problemas relatados aqui fundamental para evitar o retrabalho decorrente de informaes lacunares ou inadequadas, obtidas durante o projeto de controle automtico. Podemos resumir o princpio geral de uma abordagem alternativa na gesto da irreversibilidade das decises tomadas ao longo do PDP. A possibilidade de (re)definir o escopo depende das diversas combinaes entre estratgias de projeto descendentes e ascendentes, onde se criam condies de antecipao e de correo, minimizando o retrabalho. Isto implica uma nova temporalidade do PDP, gastando-se mais tempo na especificao, para se economizar no retrabalho e no start-up, e a realimentao mais eficaz dos momentos de deciso com informaes de campo

113

II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

(mtodos ascendentes). Isto possvel, em parte, com o aperfeioamento dos mtodos de obteno e validao das informaes de campo e dos testes intermedirios (testes de plataforma, objetos intermedirios...). O PDP uma criao coletiva. No entanto, a mistura de papis pode ser prejudicial, transformando o fornecedor de softwares em um mero executante. A gesto dessa relao complexa precisamente porque exige uma definio precisa dos papis de cada agente, assim como do conhecimento especializado que cada um possui enquanto especialista em um certo campo, ao mesmo tempo em que esses diversos especialistas devem cooperar entre si, levando em conta o ponto de vista do outro e traduzindo suas necessidades em exigncias de projeto. Propostas especficas sobre uma nova abordagem foram detalhadas em Ferreira (2004). Ressaltamos, aqui, apenas o princpio geral: as especificaes tcnicas devem se inserir em um contrato social mais amplo, cujo objetivo definir as condies de relacionamento dos agentes, em especial entre cliente e fornecedor. Nesse sentido, as metodologias geis vm favorecer a confrontao de lgicas diferentes entre usurios e analistas durante toda a fase de desenvolvimento do projeto, de modo a manter o mais aberta possvel, o mximo de tempo possvel, a definio dos objetivos e dos requisitos do projeto (TIGER, 1991). Seja pela antecipao, seja pela retroalimentao, o que vai acontecer interfere sobre o j acontecido, tornando o PDP menos determinado por decises irreversveis e criando condies mais favorveis para se projetar certo da primeira vez.

Referncias
BAINBRIDGE, L. (1999). Verbal reports as evidence of the process operator's knowledge, In: Int. Human-Computer Studies, n.51, p.213-238. BECK, K. (2000). Extreme programming explained: embrace change, Boston: Addison-Wesley. BOEHM, B. E TURNER, R. (2004). Balacing agility and discipline: evaluating and integrating agile and plan-driven methods, Proceedings of the 26th Int. Conf. On Soft. Eng. (ICSE'04). CAMPOS, N. (2002). Equipes multifuncionais de projeto, Dissertao Mestrado. UFMG, Belo Horizonte. CARVALHO, L.C. (1988). Anlise de sistemas, Rio de Janeiro: Livros Tcnicos e Cientficos. COLLINS, H.M. (1992). Artificials experts, Seuil: MIT Press. DERTOUZOS, M. (1997). O que ser? Como o novo mundo da informao transformar nossas vidas, So Paulo, Cia das Letras. DREYFUS, H.; DREYFUS, S (1986). Mind over machine, New York: Free Press. DUARTE, F. (2000). Complementaridade entre ergonomia e engenharia em projetos industriais, In: DUARTE, F. (org.) Ergonomia e projeto na indstria de processo contnuo. Rio de Janeiro, Lucerna, pp. 11-21. FERREIRA, R. B. (2004). Dilogo de surdos: a difcil explicitao do saber entre programadores de software e operadores de fbrica, Dissertao de mestrado pela

114

II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

Engenharia de Produo: UFMG. KLING, R. (1996). Computerization and Controversy, Academic Press LOJKINE, J. (1996). A revoluo informacional, So Paulo: Cortez. MCGRAW, K.L.; HARBISON-BRIGGS, K. (1989). Knowledge acquisition, Englewood Cliffs: Prentice Hall. PREECE, J.; RIGERS, Y.; SHARP. H. (2005). Design de interao, Porto Alegre, Bookman. OLIVEIRA, E. S. (2003). Uso de Metodologias geis no Desenvolvimento de Software, Monografia apresentada no Programa de Ps-Graduao em Engenharia de Software da UFMG. SILVA, C. & LIMA, F. (2000). A objetivao do saber prtico em sistemas especialistas, In: DUARTE, op. cit. TIGER, H. (1991). L'tablissement du Cahier des Charges des quipements automatiques, Colloque A.R.R.P., MRT, Janvier 1991. VINCK, D. (1999). Ingnieurs au quotidien. Grenoble, PUG. WHEELWRIGHT, S. C. & CLARK, K. B. (1992). Revolutioning product development, New York, Free Press.

115

II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

116