The scope of the right to education

Recentemente, diversas abordagens têm sido criadas para assegurar que os projetos alcancem a excelência no que tange ao seu gerenciamento, de forma a minimizarem as suas falhas e a garantirem a entrega dos seus produtos de acordo com os parâmetros estabelecidos no seu plano inicial.

60 _{Texto original em inglês: “The main reason we tend to focus on the technical rather than the human side of the}

work is not because it's more crucial, but because it's easier to do.” (DeMARCO; LISTER, 1999, p. 5)

61 _{Texto original em inglês: “[...] success in engineering is dependent not only on the traditional engineering}

skills in technology and analysis but also on an appreciation and application of the basics of good management. The common goal for all engineers is to succeed. In order to be successful, the engineer needs to understand how he or she is being assessed, what standards are expected and how best to 'manage' the job to achieve the desired results. As a minimum, this requires inter-personal skills, communications skills, organisational skills and an understanding of project management.” (REDFERN, 1997, p. 1)

Esta pesquisa não diferenciou as diversas categorias (modelos, metodologias, processos, padrões e normas), visto que elas aparecerem eventualmente com diferentes significados. Para tanto, consideraram-se essas categorias diferentes abordagens para o tratamento do gerenciamento de projetos de software. Entende-se como abordagem o “ato ou efeito de abordar” (FERREIRA, 1999, p.13), sendo abordar tratar de ou versar sobre um tema ou assunto (FERREIRA, 1999, p. 13). Assim, abordagem funciona como um termo genérico para as categorias acima elencadas, que permitem caracterizar as empresas de desenvolvimento de software no que é pertinente ao tipo de gerenciamento que utilizam.

Essas abordagens são importantes para esta pesquisa porque podem revelar uma preocupação com o fluxo de informação durante a gerência de projetos de software.

No Quadro 4, há uma listagem das abordagens mais comumente referenciadas na literatura.

Abordagem Responsável/mantenedor/ _criador Ementa

Capability Maturity Model Integration

(CMMI)

Software Engineering Institute (SEI), Carnegie

Mellon University

Modelo geral que integra diversos modelos de maturidade, cobrindo o desenvolvimento e a manutenção de produtos e serviços de software. Substituto e ampliador do Capability Maturity Model for Software – SW-CMM (CHRISSIS; KONRAD; SHRUM, 2005).

Crystal Clear Alistair Cockburn

Metodologia que enfatiza entregas freqüentes, comunicação de perto e melhoramento reflexivo, para grupos de até 8 pessoas. É uma de uma série de metodologias caracterizadas por cores (Clear, Yellow, Orange, Red, Maroon, Blue, Violet62₎

(COCKBURN, 2004). Extreme Programming

(XP) Kent Beck

Disciplina pouco demandante para grupos pequenos e médios (de dois a dez programadores) de desenvolvimento de software, com ciclos curtos e feedback contínuo (BECK, 2000; KOCH, 2005). HERMES Informatique de la Unité de Stratégie

Confédération (USIC), Suíça

Método de gerenciamento e desenvolvimento de projetos no domínio das tecnologias da informação e comunicação, do governo suíço (UNITÉ DE STRATÉGIE INFORMATIQUE DE LA CONFÉDÉRATION, 2005).

IEEE 1058/1998 _{Electronics Engineers (IEEE)} Institute of Electrical and Especifica o formato e o conteúdo dos planos de gerenciamento _{de projetos de software (IEEE, 1998a).} IEEE 1074/1997 _{Electronics Engineers (IEEE)} Institute of Electrical and Padrão para o desenvolvimento de processos de ciclo de vida _{de software (IEEE, 1997).} IEEE 828/1990 _{Electronics Engineers (IEEE)} Institute of Electrical and Padrão para planos de gerenciamento de configuração _{utilizados na produção de software (IEEE, 1990).} ISO/IEC 12207/1995 (IEEE/EIA 12207.0) International Standard Organization (ISO) e International Electrotechnical Commission (IEC)

Padrão que estabelece uma estrutura de base comum para os processos do ciclo de vida do software (IEEE, 1998b).

ISO/IEC 9126-1/2001

International Standard Organization (ISO) e International Electrotechnical

Commission (IEC)

Padrão para a avaliação da qualidade de produtos de software (ISO, 2001; KOSCIANSKI et al., 1999; TIAN, 2005). Information Technology

Infrastructure Library (ITIL)

Office of Government Commerce (OGC), Reino

Unido

Conjunto de melhores práticas para o gerenciamento de serviços, promovendo eficácia e eficiência do uso dos sistemas de informação (OGC, 2002).

MPS.BR

Associação para Promoção da Excelência do Software

Brasileiro - SOFTEX

Programa de melhoria do processo do software brasileiro, cujo foco principal são as micro, pequenas e médias empresas de

software, que têm poucos recursos e que necessitam melhorias nos

processo de software em 1 ou 2 anos (SOFTEX, 2006, p. 4 e 6).

continua...

continuação...

Abordagem Responsável/mantenedor/ _criador Ementa

Project Management Body of Knowledge

(PMBOK)

Project Management Institute (PMI)

É o conjunto de todo o conhecimento adquirido com a execução do gerenciamento de projetos. (PROJECT MANAGEMENT INSTITUTE, 2004, p. 3)

PRINCE2 _{Commerce (OGC), Reino Unido} Office of Government Método estruturado para planejamento de projetos. (OGC, _2005). Personal Software

Process (PSP)

Software Engineering Institute (SEI), Carnegie

Mellon University

Processo que propicia aos desenvolvedores de software uma abordagem personalizada e disciplinada no seu trabalho (HUMPHREY, 2000a).

Rational Unified Process

(RUP) IBM Corporation

Processo de engenharia de software que descreve quem faz o quê, quando e como em um projeto de desenvolvimento e entrega de software (CHARBONNEAU, 2004).

Scrum Ken Schwaber e Jeff _Sutherland Método para gerenciar qualquer tipo de desenvolvimento de _{produtos, inclusive software (SCHWABER, 2004).} Structured Systems

Analysis and Design Methodology

(SSADM)

Office of Goverment Commerce, Reino Unido

Método de desenvolvimento de aplicações para computadores (HUIJBERS et al., 2004).

Capability Maturity Model for Software

(SW-CMM)

Software Engineering Institute (SEI), Carnegie

Mellon University

Modelo de maturidade para a melhoria do software (CHRISSIS; KONRAD; SHRUM, 2005).

Team Software Process (TSP)

Software Engineering Institute (SEI), Carnegie

Mellon University

Processo para melhorar a performance de grupos de desenvolvedores de software (HUMPHREY, 2000b).

V-Modell XT Koordinierungs - und Beratungsstelle der Bundesregierung für Informationstechnik in der Bunderverwaltung (KBSt), Alemanha

Modelo para o planejamento e a execução de projetos (BUNDESREPUBLIK DEUSTCHLAND, 2004). Sucessor do V-Modell 97.

Quadro 4 – Listagem de abordagens mais comuns para o gerenciamento de projetos de software Fonte: O Autor.

No entanto, a introdução e a implantação dessas abordagens devem ser sopesadas, pois, de uma forma ou de outra, interferem no processo de gerenciamento de projetos de

software. Assim previne Jalote (2002, p. 3, tradução nossa):

Ao ponderar sobre processos de gerenciamento de projetos, você se deve perguntar se os gerentes de projeto irão usá-los. Ouço freqüentemente elaboradores de processos reclamar que os gerentes de projeto não seguem o processo e que eles resistem às mudanças. Minha experiência com gerenciamento de projetos na Infosys e em outras organizações diz que, na verdade, eles querem utilizar processos, mas somente se eles os ajudarem a executar melhor os seus projetos. Os gerentes de projeto, todavia, se ressentem de processos que parecem ser desnecessariamente burocráticos e acrescentam pouco valor a seu trabalho. A dica é, então, criar processos leves – aqueles que ajudam os gerentes de projeto a planejar e controlar seus projetos melhor e que lhes dão flexibilidade para tratar diversas situações.63

63 _{Texto original em inglês: “When you consider project management processes, you must ask the question}

whether project managers will use them. I have often heard process designers complain that project managers don't follow the process and that they resist changes. My experience with project managers at Infosys and other organizations is that they actually want to use processes but only if they're reasonable and will help the project managers execute their projects better. Project managers do, however, resent processes that seem to be unnecessarily bureaucratic and add little value to their work. The trick, then, is to have lightweight processes— those that help project managers plan and control their projects better and that give them the flexibility to handle various situations.” (JALOTE, 2002, p. 3)

Por isso, é importante que as abordagens estejam adequadas à realidade das organizações em que serão introduzidas, bem como aos anseios de quem as utilizará.