Métodos tradicionais de desenvolvimento têm em modelos lineares de ciclo de vida, como o do tipo cascata, um de seus pilares. Um segundo e igualmente importante pilar é o planejamento antecipado. Métodos tradicionais de desenvolvimento se caracterizam pela antecipação da especificação de todos os requisitos do cliente, antes de qualquer concepção ou desenvolvimento ser iniciado (ATKINSON, 2010).
O desenvolvimento baseado em planos surgiu da necessidade de se sanar as deficiências características do desenvolvimento de software chamado de ad hoc, prática que prevalecia na década de 1960 (BOEHM, BARRY, 2006). Nessa época, programadores adotavam suas próprias técnicas e abordagens, e se sentiam confortáveis com uma abordagem do tipo codifica-e-corrige. Havia repúdio à autoridade e muito pouca preocupação com padronização. Todo produto era construído sob medida para um único propósito particular. Havia uma grande variedade de processos e formas de gestão do desenvolvimento, o que tornava um grande desafio a manutenção e a garantia de confiabilidade e produtividade (AUSTIN; DEVIN, 2009).
Foi nesse contexto que W. W. Royce propôs, na década de 1970, o primeiro modelo linear de ciclo de vida de desenvolvimento. A ênfase desse modelo era no planejamento e na antecipação das possíveis mudanças e necessidades que poderiam emergir ao longo do processo, que deveria contar com vasta documentação contendo as variadas representações das características e funcionalidades previstas e efetivamente desenvolvidas para o software. Muitos dos que aderiram ao modelo de Royce, criando posteriormente métodos e processos igualmente baseados em planejamento antecipado, descrevem sua opção como um esforço para organizar a produção de software nos mesmos moldes do que ocorreu com a produção industrial (AUSTIN; DEVIN, 2009). Esse movimento constituiu um deslocamento para um então novo paradigma de desenvolvimento centrado no produto, em padrões, e na combinação de componentes padronizados, tão organizado como uma linha de produção industrial.
Modelos orientados a planos e a processos bem definidos foram desenvolvidos originalmente para tratar projetos grandes, complexos, custosos e de alto risco
25 (MAGDALENO; WERNER; ARAUJO, 2012). Projetos cujas condições de execução não favorecem a confiança entre cliente e desenvolvedores, acentuando a dependência em contratos, a formalização de processos, e rigorosos procedimentos de controle de mudança e de documentação. Projetos grandes se caracterizam pela dificuldade de se estimar e gerir os esforços no sentido de entregar resultados de maneira confiável, esta é a razão para o emprego de modelos tradicionais calcados em planos e processos definidos (FITSILIS, 2008). As falhas em projetos tradicionais ocorrem então com muito mais frequência do que deveriam, sugerindo que planos e processos bem definidos também são falíveis (CHARETTE, 2005).
Modelos tradicionais também não são bons para aprendizagem (sobre o produto, negócio ou mercado). Como todo o conhecimento sobre objetivos e solução devem estar disponíveis logo cedo nos projetos, o foco de sua execução acaba se concentrando em garantir o cumprimento do planejado, reduzindo ou mesmo eliminando as oportunidades para concepção, adaptação e inovação (WYSOCKI, 2009). Previsibilidade, determinismo e reducionismo são características marcantes dessas abordagens tradicionais, em que a divisão do trabalho em tarefas menores e a busca por estabilidade geral – de requisitos e desenho – são objetivos continuamente perseguidos.
A seguir, são apresentados alguns métodos consagrados de desenvolvimento que se orientam segundo uma abordagem tradicional.
SDLC - Ciclo de Vida de Desenvolvimento de Sistemas
Traduzido do inglês ‘System Development Life Cycle’, mas melhor conhecido por seu acrônimo, SDLC, esse modelo de desenvolvimento deriva diretamente do modelo de ciclo de vida em cascata e, por isso, é regido pelo princípio de que o resultado desejado só pode ser alcançado por meio de uma progressão lógica e linear do que têm de ser feito (CHARVAT, 2003). Também chamado de modelo estágio-portão (do inglês ‘stage-gate’), esse modelo, além das etapas formando uma cascata, tem ao final de cada uma, e antes da seguinte, marcos que se prestam à avaliação do projeto e de sua continuidade. Os cinco estágios do modelo clássico de Cooper são: Scoping, Build business case, Development, Testing & validation, Launch. Vários outros modelos com a mesma estrutura e regidos pelo mesmo princípio derivaram dessa abordagem em cascata, diferenciando-se basicamente quanto aos rótulos, nomes e quantidade de estágios empregados.
26 Figura 6. Representação do clássico modelo SDLC de Cooper (MACCORMACK, A., 2001).
Modelos como o SDLC surgiram para viabilizar fluxos horizontais de trabalho em organizações com estruturas centralizadas e cadeias de comando hierarquizadas. Ao permitir que se atribua etapas bem delimitadas a partes diferentes da organização (equipes, departamentos e divisões), modelos lineares de etapas e atividades garantem aos projetos a capacidade de recrutarem diferentes recursos, habilidades e conhecimentos. Modelos como o SDLC buscam instituir nas organizações uma padronização do fluxo de desenvolvimento como forma de se aumentar a efetividade e a eficiência dos projetos, especialmente de novos produtos (HERSTATT; LETTL, 2004). Entender a inovação como um processo favorece a sua compreensão e comunicação. A favor de modelos lineares de desenvolvimento, como o SDLC, está a oportunidade oferecida pelos marcos, ou portões entre cada etapa do ciclo de vida do projeto, à alta gestão e ao patrocinador para decidir se o projeto deve ou não seguir sendo financiando, e assim avançar para o próximo estágio (KARLSTROM; RUNESON, 2005).
No entanto, modelos muito estruturados acabam se tornando rígidos, moldando a maneira de se gerir a inovação. E se os modelos adotados são limitados ou inapropriados para o contexto, para o tipo de inovação desejada, ou para a organização em questão, os riscos de se adotar um modelo estágio-portão podem ser ainda maiores (TIDD; BESSANT; PAVITT, 2005).
Métodos mais flexíveis de desenvolvimento de produtos de software buscam atenuar à rigidez a mudanças e ajustes dos modelos lineares, especialmente ao longo da fase em que ocorre o desenvolvimento propriamente dito, admitindo a concorrência ou o paralelismo de atividades. A Figura 7 ilustra um modelo genérico de desenvolvimento
27 mais flexível, em que fica evidente as muitas oportunidades de troca de informações e revisões ao longo do processo de desenvolvimento.
Figura 7. Modelo mais flexível de desenvolvimento, segundo (MACCORMACK, ALAN; VERGANTI; IANSITI, 2001).
Project Management Body of Knowledge - PMBOK
Há uma tendência dentre àqueles que se dedicam a projetos em um campo específico, como desenvolvimento de software (ou construção, P&D, marketing, engenharia, etc.) a considerarem que as suas práticas (orçamento, organização, controle etc.) são igualmente específicas, ou seja, guardam similaridades entre si ao mesmo tempo em que diferem das práticas empregadas em projetos de outros tipos ou em outros campos. Meredith (2009) entende que as semelhanças fundamentais entre as práticas usadas em todos os tipos de projeto superam suas diferenças. Isso pode explicar a popularidade adquirida por métodos e práticas universais de gerenciamento de projeto, inclusive no campo do desenvolvimento de software. O Project Management Body of Knowledge, ou simplesmente PMBOK pode ser considerado um importante representante desses métodos universais.
O PMBOK se apresenta como um conjunto de boas práticas em gerenciamento de projetos. Desenvolvido pelo PMI (2004), talvez seja, junto com PRINCE2, um dos mais conhecidos representantes da abordagem tradicional de desenvolvimento de projetos no ocidente. Como poderá se observar mais adiante neste estudo, a influência deste método nos guias, manuais e, inclusive, em normas da Administração Pública Federal que tratam de contratações de serviços de TI é marcante, o que também justifica sua inclusão nesse tópico do presente estudo.
28 O PMBOK define e descreve formalmente 44 processos e as atividades que devem ser executadas ao longo do ciclo de vida de um projeto. Cada processo é descrito e associado a 5 grupos de processos e 9 áreas de conhecimento. Junto à descrição de cada processo é fornecida com uma explicação sucinta de seu propósito, suas entradas (documentos, planos de projeto, outros dados, etc), saídas (documentos, produtos) e as ferramentas e técnicas (mecanismos para a produção de resultados) recomendadas. A exemplo de Fitsilis (2008), se dá maior ênfase no presente estudo nas áreas de conhecimento por estas darem uma ideia mais nítida acerca do que consiste o PMBOK e de sua abordagem tradicional.
O PMI (2004) também busca minimizar a rigidez a mudanças característica de ciclo de vida sequenciais e lineares adotando grupos de processos que avaliam recorrentemente o planejamento original, criando novas linhas de base de prazo, custo e escopo para o monitoramento e controle.
Figura 8. Exemplo da incorporação do ciclo PDCA por modelos lineares (PROJECT MANAGEMENT INSTITUTE, 2004).
Rational Unified Process (RUP)
O Rational Unified Process, também conhecido somente como RUP, foi desenvolvido por Philippe Kruchten, Ivar Jacobsen entre outros, na Rational Corporation, com o intuito de complementar a UML (do inglês Unified Modelling Language), um método de modelagem de software. RUP emprega uma abordagem iterativa no desenvolvimento de sistemas, especialmente de sistemas orientados a objeto. Entre as práticas enfatizadas pelo RUP como forma de reduzir o risco inerente ao desenvolvimento de novos softwares, estão:
29 Gerenciar os requisitos;
Usar arquiteturas baseadas em componentes; Representar visualmente;
Verificar continuamente a qualidade; e Controlar alterações.
RUP pode ser adotado como um todo ou parcialmente, mas em geral, uma avaliação cuidadosa é necessária antes de implementá-lo (ABRAHAMSSON, PEKKA et al., 2002). O processo de adoção, assim como o próprio método, é calcado em um ciclo iterativo de seis etapas, baseado no conceito planejar-fazer-checar-agir, que deve ser repetido enquanto não se chegar à configuração apropriada.
Figura 9. Representação do ciclo de vida iterativo do RUP.
Para Charvat (2003), graças a essa flexibilidade de configuração, RUP pode ser utilizada tanto em ambientes tradicionais de desenvolvimento de empresa de grande porte como para projetos ágeis. No entanto, RUP não pode ser considerada particularmente ágil (ABRAHAMSSON, PEKKA et al., 2002). Como foi originalmente concebida para cobrir processos inteiros de produção de software, ela fornece orientações extensas para fases que são irrelevantes em um ambiente de desenvolvimento tipicamente ágil. E, apesar de poder ser configurada para cada necessidade e ambiente, isso requer uma rigorosa avaliação do que é essencial dentre os 114 artefatos que propõe serem produzidos ao longo de 4 fases, ao menos 8 iterações, 9 fluxos de trabalho, 57 atividades e aproximadamente 270 passos, desempenhados por 38 papeis, no total. Como RUP não fornece orientação de como fazer essa configuração, deixando o julgamento inteiramente a critério do usuário, a questão que emerge é até
30 que ponto uma implementação que privilegie princípios ágeis, e por isso dispense grande parte desses componentes, pode ser considerada ainda RUP.
PRINCE2 Project Framework
PRINCE2, um acrônimo em inglês, para Projetos em Ambientes Controlados (segunda versão), pode ser considerada o padrão de fato para gerenciamento de projetos de TI no Reino Unido. Desenvolvida originalmente pela Agencia Central de Computação e Telecomunicações (CCTA), essa metodologia de gestão estruturada de projeto, que agora faz parte do Office of Government Commerce (OCG)2, é tão popular
nesse país que muitas empresas só contratam gerentes de projetos se forem nela certificados (CHARVAT, 2003). Segundo este autor, esta metodologia pode também ser aplicada a projetos não-TI, pois foi originalmente concebida para ser genérica e independente de tipo de projeto e nível de complexidade.
Algumas das muitas características desta metodologia são: Estrutura de gerenciamento do projeto definida. Marcos para tomada de decisão.
Um sistema de planos para recursos e questões técnicas. Conjunto pré-estabelecido de procedimentos de controle. Foco em produtos entregáveis para o cliente.
A Figura 10 mostra que PRINCE2 é uma abordagem orientada a processos e fases com as respectivas entradas, saídas e tarefas bem definidas. Mas, apesar de ser tipicamente tradicional, PRINCE2 possui uma característica rara em outras metodologias que é a possibilidade de o progresso do projeto poder ser acompanhado a partir de três perspectivas distintas mas vinculadas: a do gerente do projeto, a do cliente e a da equipe.
2 OCG é uma agência do governo do Reino Unido voltada à regulamentação da atividade de
31 Figura 10. Representação do ciclo de vida de PRINCE 2, (CHARVAT, 2003).