enegep2012_tn_sto_157_919_20941

7/24/2019 enegep2012_tn_sto_157_919_20941

1/13

UMA PROPOSTA DE MODELO DEPROCESSO DE DESENVOLVIMENTO

DE SOFTWARE COM BASE EMCONCEITOS DE ENGENHARIA DEPRODUO

Gabriel Lara Baptista (UNINOVE)[email protected]

Jose Antonio Arantes Salles (UNINOVE)[email protected]

A engenharia de software uma disciplina relativamente nova se

comparada a outras engenharias existentes. Tal fato leva dificuldade

de acerto de custos, cumprimento de prazos e atendimento de

funcionalidades. Visto este cenrio, a prticca de utilizao de tcnicas

de gesto existentes em outras engenharias visualizada ao longo do

histrico da engenharia de software. O presente trabalho prope um

modelo de processo de desenvolvimento de software que busca

conceitos tericos na engenharia de produo para solucionar

questes de gesto de projeto de desenvolvimento de software, com

grande nfase no conceito de sistema de medio de desempenho. O

resultado da pesquisa sugere um modelo que ainda depende de

avaliao prtica mas que esta alinhado a bons conceitos de

desenvolvimento de software. O trabalho ainda apresenta pesquisas

que podem ser construdas com base no modelo proposto.

Palavras-chaves: modelo de processo de software, sistema de medio

de desempenho, tcnicas de gesto, CMMI-DEV, MPS.BR

XXXII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Desenvolvimento Sustentvel e Responsabilidade Social: As Contribuies da Engenharia de Produo

Bento Gonalves, RS, Brasil, 15 a 18 de outubro de 2012.

7/24/2019 enegep2012_tn_sto_157_919_20941

2/13



2

1. Introduo

O desenvolvimento de software pode ser considerado uma das mais novas engenhariasexistentes no mundo (DIJKSTRA, 1972). Tal situao leva a considerar que muitos

problemas resolvidos em outras reas ainda so dificuldades dessa indstria. Questesrelacionadas a conseguir atingir prazos, custos e funcionalidades esperados so desafiosmencionados no passado e ainda enfrentados nos dias de hoje (DIJKSTRA, 1972;HUMPHREY, 1995; KOSCIANSKI e SOARES, 2007; STANDISH GROUP, 2009;SOMMERVILLE, 2011).

Ao longo dos anos, uma srie de modelos vem sendo apresentados na Engenharia de Softwarejustamente para tentar resolver os problemas citados acima (ROYCE, 1970; BOEHM, 1988;BECK, 1999; KRUTCHEN,2003; PRESSMAN, 2011; SOMMERVILLE, 2011). Tambm sabido que alguns desses paradigmas utilizaram-se de tcnicas j concebidas na Engenhariade Produo, como o desenvolvimento Lean (PETERSEN e WOHLIN, 2010;POPPENDIECK e POPPENDIECK, 2011) e a inspeo (FAGAN, 1986) para resolverquestes da Engenharia de Software.

Partindo desse princpio, o presente artigo apresenta o modelo GMQA Gesto, Medio,Qualidade e seus Artefatos. Esse modelo surge da iniciativa de observar conceitos existentesna Engenharia de Produo e vincul-los s prticas existentes no desenvolvimento desoftware, tendo como foco a definio um modelo que abranja e integre os conceitos de um

sistema de medio de desempenho conhecidos na Engenharia de Produo. O trabalho definemodelos de processo de desenvolvimento de software como base terica possvel deadaptao para que as empresas de desenvolvimento possam criar os processos para produodo software adequados para cada realidade (PRESSMAN, 2011).

O artigo est dividido em cinco sees, sendo a primeira a introduo aqui apresentada. Asegunda seo descreve conceitos utilizados para concepo do modelo. A terceira apresenta ametodologia utilizada na construo do modelo, que est descrito na quarta seo. Finalmentena quinta seo so apresentadas as consideraes finais do trabalho, sugerindo um conjuntode trabalhos futuros.

2. Embasamento Terico

2.1. Modelos de Processo de Desenvolvimento de Software

Inmeras so as abordagens existentes para a produo de software. Desde o surgimento dotermo Engenharia de Software, foram discutidas diversas maneiras para tentar obter osoftware com um nvel de qualidade adequado (NATO, 1969).

Boehm (1988) afirma que o primeiro modelo conhecido para produo de software erachamado Codifique / Corrija. Nesse modelo, questes como detalhamento de necessidades,anlise, teste e manuteno eram levantadas aps a codificao. A abordagem resultava emcdigos mal escritos, necessidades de usurio no atingidas e alto custo de manuteno.

A abordagem que substituiu o Modelo Codifique / Corrija chamada de Modelo Cascata(ROYCE, 1970). Sommerville (2011) comenta que esse modelo considera as atividades

7/24/2019 enegep2012_tn_sto_157_919_20941

3/13



3

fundamentais do processo de especificao, desenvolvimento, validao e evoluo dosoftware.

Boehm um dos crticos do modelo Cascata e em seu trabalho que apresenta o modeloEspiral (BOEHM, 1988), processo que ficou conhecido pela sua capacidade de iterao e

preocupao com a gesto de projetos (SOMMERVILLE, 2011).

Do conceito de iterao apresentado pelo modelo espiral, surgiram outros modelos. Tcnicascomo prototipao e entrega incremental foram desenvolvidas, utilizando-se justamente daabordagem iterativa (SOMMERVILLE, 2011). Outro processo muito conhecido que surgiuno incio dos anos 2000 foi o Rational Unified ProcessRUP (KRUTCHEN, 2003). Essemodelo foi baseado nas melhores prticas para desenvolvimento de software, dentre elas o

prprio desenvolvimento iterativo.

Todos os modelos at aqui apresentados so considerados tradicionais na Engenharia de

Software, dirigidos essencialmente ao planejamento. Aps a publicao do Manifesto gil(BECK, 2001), inmeras iniciativas que se preocupavam mais com questes relacionadas aos

princpios defendidos de resposta mudana, colaborao do cliente, software emfuncionamento e indivduos e interaes surgiram para criticar a at ento nica Engenhariade Software. O Extreme Programming (BECK, 1999) e o Scrum (SCHWABER eSUTHERLAND, 2011) so exemplos de modelos geis considerados atualmente importantesno desenvolvimento de software, sendo que o primeiro foca a produo de software e osegundo se preocupa com a gesto de projetos de software.

2.2. Conceito sobre Sistema de Medio de Desempenho

Slack et. al. (2009) afirma que a medio de desempenho um processo de quantificar a ao,no qual medio relaciona-se com o processo de quantificao e o desempenho presumidocomo derivado de aes tomadas ao longo da produo.

Quanto construo de um Sistema de Medio de Desempenho, El-Baz (2010) apresentauma adaptao de Neely et. al. (1995) em relao aos nove passos tpicos e necessrios. Aatividade inicia-se com a definio da misso da empresa. Em seguida, os objetivosestratgicos da empresa devem ser mapeados, utilizando-se da misso definida anteriormentecomo guia.

Neely et. al. (1995) afirma que se deve tambm desenvolver um entendimento de cada uma

das reas funcionais em relao aos objetivos estratgicos, determinando medies dedesempenho globais para cada uma das reas. A comunicao dos objetivos estratgicos deveser executada para cada nvel da empresa e a garantia de consistncia desses objetivos com ocritrio de desempenho de cada nvel deve ser realizada.

Por fim, deve haver a garantia de compatibilidade das medidas de desempenho de cada rea eo SMD deve ser utilizado, sempre sendo reavaliado, em funo das necessidades da empresa eo ambiente competitivo atual.

Entretanto, mesmo com passos pr-definidos para construo de um SMD, o alinhamentoentre a estratgia e as operaes da empresa pode ser considerado um dos fatores crticos paraa sua implementao (ATKINSON, 2006; BHAGWAT e SHARMA, 2007; MACEDO,

2009).

7/24/2019 enegep2012_tn_sto_157_919_20941

4/13



4

No que se diz respeito produo de software, Humphrey (1989) afirma que so quatro osprincipais papis da medioControlar; Avaliar; Entender; e Prever.

Sabe-se, portanto, que um sistema de medio de desempenho adequado trar benefcios corporao que, se alinhados com sua estratgia, auxiliaro no alcance das metas estratgicas(KAPLAN e NORTON, 1997).

Quando se fala de controle de software baseado em mtricas, a utilizao de uma basehistrica se faz necessria. Humphrey (1995) apresenta em seu livro dedicado aodesenvolvimento pessoal de software a necessidade de armazenamento de um histrico, o quesugere tal prtica como caracterstica dos sistemas de medio de desempenho para projetosde software.

especficos do processo.De forma contraditria ao apresentado at agora pela bibliografia levantada, que destaca o usodas mtricas para gerenciamento de projetos de software, est uma pesquisa levantada peloMinistrio da Cincia e Tecnologia, que afirma que somente 39,6% das empresas pesquisadasmedem o desempenho do processo de software de forma sistemtica (MCT, 2009)

2.3. Normas e modelos de processos que apoiam a medio de desempenho

A Engenharia de Software possui um conjunto de normas e processo que apoiam a mediode desempenho. Dentre elas, pode-se destacar a norma ISO 12207 (ABNT, 1998), a norma

ISO 15504 (ABNT, 2008), o modelo internacional CMMI-DEV Capability Maturity ModelIntegration for Development (SEI, 2010) e o modelo nacional MPS.BR Melhoria deProcesso do Software Brasileiro (SOFTEX, 2011).

A NBR ISO/IEC 12207:1998 (ABNT, 1998) a verso brasileira da norma que trata daquesto de processos de ciclo de vida de software. Koscianski (2007) afirma que essa normaoferece uma estrutura para que uma organizao defina os seus processos de produo desoftware, cobrindo todo seu ciclo de vida, de requisitos at a manuteno e retirada do

produto. A norma requer em suas atividades que a empresa se preocupe em medir osprocessos de desenvolvimento de software, armazenando dados histricos dos projetos, demodo a entender os processos que est executando.

A norma ISO/IEC 15504:2008 (ABNT, 2008) trata da questo de avaliao do processo dedesenvolvimento de software. Atualmente a norma possui sete partes, j traduzidas para o

portugus. Salviano (2009) afirma que as partes oito e nove esto em desenvolvimento, sendoque existe um projeto atual para realizar a evoluo da atual norma para uma srie ISO/IEC33000.

Anacleto (2005) afirma que a norma ISO 15504 presta-se a realizao de avaliaes dosprocessos com dois objetivos, melhorar e determinar a capacidade dos processos. Para tanto,ela define o conceito de nvel de capacidade, que aponta o quo capaz a empresa em relao execuo do processo avaliado. A norma apresenta seis nveis de capacidade, que vo deincompleto a otimizado, sendo que o seu quarto nvel refere-se diretamente a empresas que

tem a capacidade de prever resultados a partir de medies detalhadas e analisadas. A norma

7/24/2019 enegep2012_tn_sto_157_919_20941

5/13



5

ainda conta com uma rea de processo dedicada medio, considerada base para os modelosCMMI-DEV e MPS.BR (SEI, 2010; SOFTEX, 2011).

O CMMI-DEV atualmente o framework para melhoria de processo de desenvolvimento desoftware mais conhecido e aceito mundialmente. O modelo atualmente encontra-se em suaverso 1.3 e composto por 22 reas de processo, que esto posicionadas em cinco nveis dematuridade ou seis nveis de capacidade, dependendo do tipo de representao utilizado. Eleest embasado nas propostas das normas ISO 9000, ISO/IEC 12207, ISO/IEC 15504, entreoutras (SEI, 2010).

J se faz obrigatrio a partir do Nvel 2 de maturidade do CMMI-DEV a aplicao demedio e anlise nos projetos de software. Segundo o seu documento guia, a escolha dasmtricas de um projeto devem estar alinhadas com as necessidades da organizao e do

projeto. O modo de coleta das medies tambm deve ser definido, bem como a maneira

como as mtricas sero armazenadas.O MPS.BR foi fruto de uma iniciativa brasileira ocorrida no final do ano de 2003, coordenada

pela Associao para Produo da Excelncia do Software Brasileiro (SOFTEX) e apoiadapelo Ministrio de Cincia e Tecnologia (MCT), alm de outras entidades governamentais eprivadas (SOFTEX, 2011) com objetivo principal a melhoria de processo do softwarebrasileiro, compatibilizando custos de implantao com o cenrio brasileiro (SBC, 2010).

Nesse modelo, a rea de processo de medio tem como propsito a coleta, o armazenamento,a anlise e o relato dos dados relativos a produtos e processos da organizao, tambmapoiando os objetivos da empresa (SOFTEX, 2011). O modelo deixa claro ainda que o foco

principal da medio seja o de apoiar a tomada de deciso em relao aos projetos e

processos, sendo as mtricas criadas a partir de necessidades estratgicas de informao daorganizao. Ele sugere ainda a utilizao de um mtodo de medio como, por exemplo, oGQM (Goal-Question-Metric), idealizado por Solingen e Berghout (1999).

3. Metodologia

A construo do modelo foi realizada com base em um levantamento bibliogrficoestruturado e sistemtico sobre modelos de processo de desenvolvimento de software esistemas de medio de desempenho.

Desse levantamento, uma anlise crtica das metodologias de desenvolvimento de software esistemas de medio de desempenho foi realizada, criando um mapeamento entre tcnicas,normas e modelos que poderiam ser utilizados. Essa etapa serviu de base para a escolha dos

princpios do modelo conceitual, associando os conceitos de Processo de Desenvolvimento deSoftware e Sistemas de Medio de Desempenho.

Em seguida, o modelo conceitual foi formulado. Tal modelo busca alinhar os conceitosnecessrios para a construo de um software ao sistema de medio de desempenhoescolhido. O modelo proposto j fruto de duas rodadas de apresentao em empresas quedesenvolvem software, com o objetivo de detectar a percepo e avaliao de profissionais darea em relao aplicabilidade do modelo proposto (SEVERINO, 2007).

4. Apresentao do Modelo

4.1. Ciclo de Vida do Projeto de Software

7/24/2019 enegep2012_tn_sto_157_919_20941

6/13



6

A Figura 1 apresenta o ciclo de vida do projeto de software considerado pelo modelo. Esseciclo possui dois conceitos j conhecidos na Engenharia de Produo. O primeiro est

relacionado com a contabilizao de medies relativas aos estoques (M1, M2, M3 e M4),originrio do Lean (POPPENDIECK e POPPENDIECK, 2007; PETERSEN e WOHLIN,2010; SCHWABER e SUTHERLAND, 2011).

Outro fator ligado Engenharia de Produo tem relao com a tomada de deciso em algunspontos estratgicos do processo. Essa avaliao foi definida com base nos conceitos de stage-gates, oriundos do desenvolvimento de produtos (COOPER, 1993; KARLSTRM eRUNESON, 2006; COOPER, 2007).

Figura 1Ciclo de vida do projeto de software para o modelo GMQA

Apesar de o modelo apresentar um conjunto de tarefas em sequncia, no correto imagin-locomo um desenvolvimento em cascata. Na verdade, ele apenas a representao de atividades

que podem at estar acontecendo paralelamente em um ambiente de desenvolvimento, aolongo da vida de um software, garantindo a sua fluidez, decises difusas, foco e flexibilidade,conforme mencionado pelo modelo defendido de Cooper (1993) para desenvolvimento de

produto.

O que ele na verdade representa so macro etapas elementares existentes em um processo dedesenvolvimento de software, com os pontos mnimos de medio exigidos (M1, M2, M3 eM4) e os portes de deciso (G1, G2 e G3).

O modelo acredita que no possvel realizar a construo de um software profissional nosdias de hoje sem se preocupar com sua Arquitetura. Tambm no possvel imaginar umsoftware sem o seu Desenvolvimento. E o software desenvolvido que no est em produo

com certeza no valeu nem um centavo do investimento. Portanto, as trs macro etapas

7/24/2019 enegep2012_tn_sto_157_919_20941

7/13



7

apresentadas deveriam ser consideradas em qualquer projeto de software Arquitetura,Desenvolvimento e Implantao.

4.2. Princpios do Modelo

O modelo acredita que a gesto do projeto deve ser contnua, tendo os outros trs princpiosaplicados ao longo de um ciclo de gesto, conforme apresentado na Figura 2. Dentro desseciclo, trs fases podem ser definidas: Planejamento, Execuo e Entrega. Estas etapas vo deencontro com conceitos bsicos do gerenciamento de projetos (PMI, 2004).

Figura 2Ciclo de Gesto de Projetos de Software GMQA

O modelo considera que o projeto de software poder ter um ou mais ciclos de gesto,organizados atravs da priorizao de necessidades a serem implementadas, de acordo com o

porto G1. Com base em conceitos geis, espera-se que cada ciclo seja planejado de talmaneira que sejam entregues partes do software ao final de um curto espao de tempo, de nomximo um ms (SCHWABER e SUTHERLAND, 2011).

As macro etapas podero ser executadas em um nico ciclo, em caso de projetos maissimples, ou em ciclos separados, conforme ambiente em que o modelo esteja sendo aplicado.De qualquer maneira, no recomendvel a interrupo de um ciclo de gesto no meio paraatender a demandas oriundas de novas necessidades. Da o motivo de se ter um ciclo curto(SCHWABER e SUTHERLAND, 2011).

4.3. Pontos mnimos de medio exigidos

O modelo apresenta quatro pontos de medio exigidos, chamados de M1, M2, M3 e M4. Oconceito por trs destes pontos tem relao com a avaliao de estoques, base dos princpiosLean (PETERSEN e WOHLIN, 2010). Deve-se, portanto, considerar cada um desses marcosum estoque do ciclo de vida de desenvolvimento do software. So eles:

7/24/2019 enegep2012_tn_sto_157_919_20941

8/13



8

M1 Estoque de necessidades a serem avaliadas. Pode ser medido por quantidade derequisitos de usurio pendentes.

M2 Estoque de software arquitetado: Esse estoque possui documentao essencial paraconstruo do software, tais como requisitos de sistema definidos, custo paradesenvolvimento, e at modificaes na arquitetura planejada. Entretanto, o desenvolvimentodessa arquitetura ainda no foi executado por conta de falta de recursos ou por falta deaprovao de custo. Pode ser medido pela somatria da quantidade de requisitos sistmicosaprovados com os requisitos pendentes de aprovao.

M3 Estoque de software construdo: Nesse terceiro estoque encontra-se softwareconsiderado pronto para instalao, mas que no foi ainda entregue ao seu usurio final, seja

por falta de treinamento ou falta de recursos para instalao. Pode ser medido pela soma daquantidade de requisitos pendentes de implantao, classificados como exemplificado.

M4 Estoque de software descartado: No quarto estoque encontra-se software que foiinicialmente considerado vlido, mas que por mudanas internas ou externas ao projeto, no

pde ser implementado por conta de no mais fazer parte da realidade do sistema.

Poppendieck e Poppendieck (2007) afirmam que o estoque em desenvolvimento de softwareequivale a trabalhos parcialmente acabados. Um software parcialmente acabado tem todos osmales de um estoque na produo: se perde, fica obsoleto, esconde problemas de qualidade eestagna dinheiro. Sendo assim, a correta e contnua priorizao de quais itens do estoque M1sero produzidos ir interferir diretamente na eficincia do processo. Essa deciso estrelacionada ao porto G1.

Os conceitos Lean deixam claro que o aumento dos volumes em estoque simbolizadesperdcio e, por consequncia, prejuzo (POPPENDIECK e POPPENDIECK, 2007;PETERSEN e WOHLIN, 2010; SCHWABER e SUTHERLAND, 2011). interessante,

portanto, o monitoramento de cada um desses estoques de modo a garantir uma estratgiacorreta de execuo de tarefas. Espera-se que, com a medio desses pontos, os envolvidos no

processo de desenvolvimento tenham conhecimento de quais sero os pontos que devem sermedidos para evoluir o processo.

4.4. Portes de deciso

Aps a execuo de um ciclo de gesto, chega o momento de tomar decises no projeto. Por

tal razo, os portes de deciso iro usufruir de todo o material at o momento gerado. Omodelo prev inicialmente trs portes.

Cada um desses pontos poder iniciar uma nova macro etapa do projeto ou realimentar oestoque de necessidades por conta de modificaes no trabalho que foi gerado ao final dociclo de gesto. Abaixo, um conjunto de preocupaes existentes em cada um dos portes dedeciso:

G1O porto 1 aquele responsvel pela priorizao das atividades que iro comear a serarquitetadas. Ele deve estar aderente s necessidades dos clientes e da organizao, de talmaneira que no se desperdice tempo com o incio de atividades de arquitetura que no so

primordiais para o andamento do projeto. A priorizao das atividades pode ser considerada

pea chave para o sucesso na execuo de qualquer projeto. A mo de obra atualmente emqualquer ambiente corporativo escassa, o que sugere que a priorizao do que realmente

7/24/2019 enegep2012_tn_sto_157_919_20941

9/13



9

precisa ser desenvolvido gerar menor nvel de estoques intermedirios (SCHWABER eSUTHERLAND, 2011).

G2Ao chegar ao porto 2 devero ser observados os estoques M1, M2 e M3 de tal maneiraa tomar a deciso por Desenvolver o que est em M2, mover necessidades de M2 para M1 ousimplesmente deixar de executar a macro atividade de Desenvolvimento para atender a outrosestoques, com maior demanda.

G3Ao chegar ao porto 3 devero ser observados os estoques M1, M2 e M3 de tal maneiraa decidir por Implantar o que est em M3, mover necessidades de M3 para M1 ousimplesmente deixar de executar a macro atividade de Implantao para atender a outrosestoques, com maior demanda.

4.5. Anlise de Aderncia do Modelo e outras Abordagens

O modelo apresentado fruto do estudo de uma srie de diferentes abordagens, oriundas dolevantamento bibliogrfico realizado. A Tabela 1 mostra cada uma dessas abordagens, bemcomo a sua referncia base.

Abordagem Referncia

Melhores prticas no desenvolvimento de software (BOOCH, 1998)

Princpios Lean para desenvolvimento de software (POPPENDIECK e POPPENDIECK, 2011)

Passos para desenvolver um SMD (NEELY et. al, 1995)

Papis da Medio (HUMPHREY, 1989)

CMMI-DEV (SEI, 2010)

MPS.BR (SOFTEX, 2011)

SCRUM (SHWABER e SUTHERLAND, 2011)

ISO 15939 (ISO, 2007)

Stage-Gates (COOPER, 2007)

Tabela 1Abordagens base para concepo do modelo

Com base no levantamento das principais atividades solicitadas por esse conjunto deabordagens existentes para produo do software, a Figura 3 apresenta uma viso do quo

prximo o modelo se encontra das diversas abordagens utilizadas para sua concepo.

7/24/2019 enegep2012_tn_sto_157_919_20941

10/13



10

Figura 3Aderncia do modelo a outras abordagens

5. Consideraes finais

Considerando como objetivo principal do trabalho a proposta de um modelo de processo dedesenvolvimento de software com base em conceitos de Engenharia de Produo, pode-seafirmar que o modelo apresentado consegue atingir essa meta.

Tambm possvel afirmar que a verificao de conceitos j existentes na Engenharia deProduo pode ser feita com o intuito de adaptar tais tcnicas na Engenharia de Software,desde que observadas as variaes existentes em um projeto nessa indstria.

Ressalta-se que o modelo ainda no foi adaptado para processos em empresas, sendo apenastestado conceitualmente. Essa deve ser considerada a principal limitao do trabalho. Aaplicao em alguns ambientes poderia ser tema para estudos futuros, mas mesmo assim noseria possvel afirmar que tal modelo resolveria os problemas mencionados na introduo do

trabalho em sua completude.Outro ponto que pode ser discutido em um trabalho futuro est relacionado a quais mtricas eartefatos devem ou poderiam ser gerados ao longo do processo de desenvolvimento desoftware.

Referncias

ABNT (ASSOCIAO BRASILEIRA DE NORMAS TCNICAS). Tecnologia dainformaoProcessos de ciclo de vida de software. NBR ISO/IEC 12207, 1998.

7/24/2019 enegep2012_tn_sto_157_919_20941

11/13



11

ABNT (ASSOCIAO BRASILEIRA DE NORMAS TCNICAS). Tecnologia dainformaoAvaliao de processo. NBR ISO/IEC 15504, 2008.

ANACLETO, A.; WANGENHEIM, C.; SALVIANO, C. Um mtodo de avaliao deprocessos de software em micro e pequenas empresas. SBQS - Simpsio Brasileiro deQualidade de Software. Porto Alegre, 2005.

ATKINSON, H., Strategy implementation: a role for the balanced scorecard?ManagementDecision v.44 n. 10, 2006.

BECK, K.Embracing Change with Extreme Programming.IEEE Computer, 1999.

BECK, K. et. al. Manifesto for Agile Software Development. Utah, 2001. Acessadoeletronicamente emhttp://www.agilemanifesto.org/.

BHAGWAT, R. e SHARMA, M. K., Performance measurement of supply chainmanagement: A balanced scorecard approach. Computer & Industrial Engineering. Elsevier,2007.

BOEHM, B.A Spiral Model of Software Development and Enhancement.IEEE Computer,1988.

BOOCH, G.Leaving Kansas.IEEE Software 15(1), 1998.

COOPER, R. G. Winning at new products, accelerating the process from idea to launch.Reading, M. A., Perseus Books, 1993.

COOPER, R. G.Doing it Right: Winning with new products. Innovation FrameworkTechnologies, 2007.DIJKSTRA, E. W. The Humble Programmer.EWD 340. ACM 15(10): 859-866, 1972.

EL-BAZ, M. A. Fuzzy performance measurement of a supply chain in manufacturingcompanies. Expert Systems with Applications, 2010.

FAGAN, M.Advances in Software Inspections.IEEE Transactions on Software Engineering,1986.

HUMPHREY, W. S.Managing the software process.Addison-Wesley, 1989.

HUMPHREY, W.A discipline for software engineering.SEI series in software engineering.Addison-Wesley, 1995.

ISO/IEC 15939-2:2007Systems and software engineeringMeasurement process.

KAPLAN, R. S., NORTON, D. P.A Estratgia em Ao: Balanced Scorecard. Rio de

Janeiro: Campus, 1997.
http://www.agilemanifesto.org/http://www.agilemanifesto.org/

7/24/2019 enegep2012_tn_sto_157_919_20941

12/13



12

KARLSTRM, D., RUNESON, P.Integrating agile software development into stage-gatemanaged product Development. Empirical Software Engineering, 2006.

KOSCIANSKI, A; SOARES, M. S. Qualidade de software: Aprenda as metodologias etcnicas mais modernas para desenvolvimento de software.So Paulo: Novatec, 1995.

KRUTCHEN, P. The Rational Unified ProcessAn Introduction. Addison-Wesley, 2003.

MACEDO, M. A. S. et al.,Desempenho de agncias bancrias no Brasil: aplicando anliseenvoltria de dados (DEA) a indicadores relacionados s perspectivas do BSC. RevistaEconomia e Gesto v.19 n. 19, 2009.

MCT (MINISTRIO DA CINCIA E TECNOLOGIA) Pesquisa de Qualidade no Setor

de Software Brasileiro 2009. Braslia, 2009.

NATO Science Committee Software EngineeringReport on a Conference sponsored by theNATO Science Committee, Garmisch, Germany, 1969.

NEELY, A.; GREGORY, M. J.; PLATTS, K.Performance measurement system design: Aliterature review and research agenda. International Journal of Operations & ProductionManagement, 1995.

NEELY, A; ADAMS, C; KENNERLEY, M.The Performance Prism - The Scorecard forMeasuring and ManagingBusiness Success.Financial Times Prentice Hall, 2002.

PETERSEN, K., WOHLIN, C. Software process improvement throught the LeanMeasurement (SPI-LEAM) method. The Journal of Systems and Software, 2010.

PMI (PROJECT MANAGEMENT INSTITUE) Um Guia do Conjunto de Conhecimentosem Gerenciamento de Projetos (PMBOK), 3 Edio, 2004.

POPPENDIECK, M., POPPENDIECK, T.Implementando o desenvolvimento Lean deSoftware: do conceito ao dinheiro. Porto Alegre: Bookman, 2011.

PRESSMAN, R. S.Engenharia de Software: Uma abordagem profissional. Porto Alegre:

AMGH, 2011.

ROYCE, W. W.Managing the Development of Large Software Systems. WESCON, 1970.

SALVIANO, C.Projetos da CE-21-007-10 e Novidades da ISO/IEC 15504 (SPICE). SoPaulo, 2009.

SCHWABER, K., SUTHERLAND, J. The Definitive Guide to Scrum: The rules of thegame. Scrum.org, 2011.

SEVERINO, A. J.Metodologia do trabalho cientfico.23. ed. So Paulo: Cortez, 2007.

7/24/2019 enegep2012_tn_sto_157_919_20941

13/13



13

SEI (SOFTWARE ENGINEERING INSTITUTE)CMMI for Development, Version 1.3.Pittsburgh, 2010.

SLACK, N. et. al.Administrao da Produo. 3 ed. So Paulo: Atlas, 2009.

SOMMERVILLE, I.Engenharia de Software.9 ed. So Paulo: Pearson Prentice Hall, 2011.

SOLINGEN, R., BERGHOUT, E. The Goal/Question/Metric Method: A Practical Guidefor Quality Improvement of Software Development.McGraw-Hill, 1999.

SOFTEXMPS.BRMelhoria de Processo do Software Brasileiro: Guia Geral, 2011.

STANDISH GROUP INTERNATIONAL. CHAOS Summary 2009 Report. Boston, 2009.

enegep2012_tn_sto_157_919_20941

Documents

Transcript of enegep2012_tn_sto_157_919_20941