Processos de produção de software x Incerteza associada ao produto

Antes de explorarmos as diferentes abordagens associadas aos processos de produção de softwares, é importante visitarmos a história para relembrar que muitos dos desafios atuais associados a este tema não são tão novos assim, bem como valorizar a importância da disciplina de Engenharia de Software, a qual evoluiu ao longo das décadas graças ao trabalho de profissionais de diversas áreas de atuação.

COMO NASCEU A ENGENHARIA DE SOFTWARE

Visando um melhor entendimento do conteúdo descrito a seguir, toda vez que houver uma referência ao termo “projeto”, estamos nos referindo ao esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo (PMBOK, 2018). Já o termo de “design”, refere-se aos processos de especificação, modelagem e tomadas de decisões associadas a uma ou mais soluções de software, tendo em vista o atendimento de uma determinada necessidade ou problema.

Quando os primeiros computadores eletrônicos surgiram na década de 1940, a programação computacional iniciou uma evolução contínua e exponencial que transformou o mundo e a sociedade. O Colossus, por exemplo, foi concebido pelo governo britânico para automatizar rotinas de decodificação de mensagens transmitidas por rádio pelos alemães durante a segunda guerra mundial (FILHO, 2007).

Já a década de 1950 foi marcada pela criação dos primeiros computadores modernos, baseados na Arquitetura de Von Newmann, e pelo desenvolvimento das primeiras linguagens de programação de alto nível como, por exemplo, FORTRAN, LISP e COBOL (FILHO, 2007).

LEO I foi o primeiro computador construído para fins empresariais na Inglaterra. Inicialmente suas aplicações estavam direcionadas para análises de viabilidade e, posteriormente, o seu uso foi estendido para aplicações de folha de pagamento, inventários, controle de produção, cronogramas de entregas, dentre outros cenários de uso (TATNALL, 2012).

Nos Estados Unidos, os computadores UNIVAC I, Mark I, IBM 701 e RCA 501 também foram utilizados para fins comerciais (TATNALL, 2012). Contudo, até então, não existiam práticas, métodos ou uma base de conhecimento consolidada que apoiasse as organizações na produção de software para o processamento de dados empresariais. Com isso, muitos projetos falhavam, atrasavam e custavam mais do que o planejado (NAUR e RANDELL, 1969).

Naquela época, a maior parte do orçamento estava direcionado para a aquisição de hardwares, os quais custavam muito mais do que os recursos necessários para o desenvolvimento de software. Com isso, desvios acentuados no orçamento de desenvolvimento poderiam comprometer todo o projeto e investimento até então realizado. Diante deste cenário, percebeu-se a necessidade de um estudo mais elaborado para identificar as possíveis causas e soluções para a chamada “Crise do Software” (NAUR e RANDELL, 1969).

O termo “Software” foi criado em 1958 pelo renomado estatístico John Tukey, definindo-o como um conjunto de rotinas interpretativas cuidadosamente planejadas, por compiladores e por outros aspectos da programação automática, e equalizou a sua importância perante o hardware (BOURQUE e FAIRLEY, 2014). Já o termo “Engenharia de Software” ficou mundialmente conhecido por ser utilizado como título da primeira conferência internacional sobre o tema, capitaneada pela OTAN em 1968 na Alemanha (NAUR e RANDELL, 1969).

A iniciativa para a realização desta conferência surgiu no ano anterior, em 1967, quando foi identificado pelo comitê científico da OTAN a necessidade de explorar com mais profundidade os problemas e impactos da ciência da computação em diversas áreas da sociedade. Em outubro de 1967, a OTAN criou o grupo de estudo de ciência da computação, o qual concentrou suas ações mais prioritárias nos problemas e desafios inerentes à produção de softwares (NAUR e RANDELL, 1969).

Neste contexto, o grupo de estudo de ciência da computação recomendou ao comitê científico da OTAN a realização de um evento internacional intitulado de Conferência de Engenharia de Software. O termo “Engenharia de Software” foi deliberadamente escolhido como uma provocação sobre a prerrogativa de que a construção de softwares deveria se basear em fundamentos e disciplinas práticas, os quais eram característicos em segmentos estabelecidos da engenharia (NAUR e RANDELL, 1969).

Conferência Internacional de Engenharia de Software — Garmisch, Alemanha — Outubro de 1968

Os desafios associados à condução e desenvolvimento de projetos de software são temas de debates na área acadêmica, militar e na iniciativa privada a algumas décadas. As questões abordadas na conferência, capitaneada pelo comitê científico da OTAN em 1968, que popularizou mundialmente o termo “Engenharia de Software”, ainda são alvos frequentes de estudos que objetivam guiar as organizações e os engenheiros de software na construção de produtos através de princípios, práticas, técnicas e ferramentas que maximizam a probabilidade de alcance dos resultados almejados.

Dentre os temas abordados na Conferência de Engenharia de Software de 1968, destaco abaixo alguns trechos parafraseados do relatório produzido por Naur e Randell (1969):

• Segundo McIlroy, as técnicas para a produção de software utilizadas eram retrógadas; foi consenso geral de que a engenharia de software estava em um estágio muito rudimentar de maturidade, se comparado com outros ramos da engenharia;
• Para Kolence, a indústria de software continuaria a merecer a má fama de não atingimento das expectativas de custo, prazo e qualidade enquanto não houvesse um estudo mais completo sobre os processos associados a produção de software;
• Fraser dissertou sobre o desafio da medição do progresso de execução de um projeto de software, afirmando que nem sempre um incremento pode ser interpretado como um avanço no desenvolvimento e que o produto final pode ser descrito simplesmente como a soma de muitos incrementos.
• Graham criticou o processo de produção onde, na maioria das vezes, a necessidade não estava compreendida o suficiente para que a construção fosse iniciada e, com isso, os softwares não funcionavam como esperado. Ele chegou a comparar o processo de produção de software com o utilizado pelos irmãos Wright na construção de aviões: construíam tudo, empurrava pelo penhasco, deixava cair e recomeçava tudo de novo;
• Opler demonstrou preocupação com o tamanho dos projetos de software, tendo em vista que o aumento da complexidade está associado de modo exponencial ao número de erros que poderiam ser produzidos.
• Dijkstra comentou sobre a assustadora quantidade de software distribuído com erros, enfatizando que a disseminação do conhecimento era um caminho óbvio para mitigar a sua ocorrência;

Como podemos observar através da figura abaixo, apresentadas por Nash e Selig na conferência de 1968, os ciclos de vida dos projetos de software utilizavam em geral uma abordagem preditiva, onde a produção era executada através de um conjunto de etapas sequenciais contemplando a identificação de necessidades, design, desenvolvimento, testes, validação e, finalmente, a disponibilização do produto aos usuários.

Na última fase do projeto, muitas vezes eram identificadas necessidades de manutenções corretivas ou novas demandas evolutivas que, quando não eram bem gerenciadas, acabavam impactando não só o prazo e o custo do projeto, mas também a qualidade do produto, haja visto que a ênfase com testes e validações estavam concentradas nas etapas anteriores.

É possível identificar também que a prática de produção de software através do ciclo de vida incremental já era uma abordagem utilizada naquela época, conforme o comentário de Fraser sobre o seu trabalho “The nature of progress in software production”, o qual propunha que a produção fosse realizada através de um conjunto de etapas de design e implementação, no qual cada uma delas tinha a premissa de produzir um produto útil para o negócio, fornecendo a experiência e conhecimento operacional para a execução da próxima etapa.

Fraser ressaltou ainda que, em geral, os produtos entregues através deste processo se aproximavam mais da exigência final do projeto. As mudanças necessárias foram identificadas mais precocemente, entre cada uma das entregas, o que proporcionou um resultado melhor do produto final.

A distinção entre o trabalho de design e de implementação também foi foco de discussão na conferência. Para Nauer, essencialmente não existe diferença entre eles, uma vez que decisões de design também são tomadas durante a fase de implementação. Esta distinção só se torna útil quando existe uma necessidade prática de separação dos trabalhos de design e implementação.

Conforme exemplificado por Nauer, é útil separar o trabalho de design e implementação quando o trabalho de design precisa ser realizado previamente no projeto até um nível de detalhe suficiente para que a implementação o siga e reste apenas a tomada de decisões de baixo impacto.

Kinslow, que entendia que o processo de design e implementação deveria ser iterativo, expressou a sua opinião sobre a distinção entre design e a implementação através de uma prática bem interessante: a) realize o design até acreditar que entendeu o problema; b) implemente até você perceber que não entendeu o problema; c) volte a executar o design; d) implemente novamente para o que acredita ser a solução correta.

Ou seja, a percepção de Kinslow é pessimista sobre o design inicial do projeto, uma vez que enfatiza a premissa de que ele não produzirá a direção correta da solução final. Para Ross, o problema mais crítico na produção de software é a crença de que um software deve ser simplesmente especificado (design) e construído (implementação), corroborando com a visão de Kinslow.

Com base na leitura dos últimos parágrafos, podemos ser levados a pensar que o ciclo de vida preditivo é ruim e não deve ser utilizado, certo? A resposta é que não existe um ciclo de vida ou abordagem única e ideal na engenharia de software, conforme mencionado pelo famoso autor de engenharia de software Ian Sommerville (2007).

Desde a conferência realizada em 1968, houve diversos avanços nas práticas, técnicas e ferramentas que apoiam as atividades de concepção do projeto, especificação de requisitos, design, desenvolvimento, testes e de gestão de projetos. Do mesmo modo, foram definidos ao longo do tempo diferentes modelos de ciclos de vida de projetos de software. Conforme Sommerville (2007), um processo de engenharia de software pode ser descrito como um conjunto de atividades que levam a produção de um produto de software.

Já um modelo de processo de engenharia de software é uma representação abstrata do processo. Ou seja, se for possível identificar e definir previamente qual a necessidade ou o problema que precisa ser resolvido e como ele será resolvido tecnicamente, o modelo preditivo poderia ser um possível candidato como o modelo de processo (ciclo de vida), tendo em vista que atualmente a maturidade sobre o processo de engenharia de software é muito superior à maturidade existente em 1968.

Algumas palavras estão em negrito nos últimos parágrafos, pois abordaremos a seguir o racional por trás dos diferentes tipos de ciclos de vida de produção de software, os quais também podem ser entendidos como modelos de processo de engenharia de software, com o intuito de esclarecer a diferença entre eles e em quais cenários eles são mais aderentes.

ABORDAGENS E PRÁTICAS ÁGEIS DE ENGENHARIA DE SOFTWARE

Publicado em 2017, o Agile Practice Guide foi desenvolvido por voluntários do Project Management Institute (PMI) em parceria com a Agile Alliance. O conteúdo descrito a seguir tem como referência esta publicação, disponível em https://www.pmi.org/pmbok-guide-standards/practice-guides/agile.

No início do artigo descrevemos o conceito do que é um projeto e, a seguir, vamos explorar como eles surgem. De acordo com o PMI (2008), projetos podem ser oriundos, por exemplo, do planejamento estratégico organizacional, seja para explorar uma necessidade de negócio ou para mitigar potenciais ameaças e fraquezas. Neste contexto podemos citar a criação de um novo produto, a resolução de um determinado problema, o atendimento de demandas regulatórias, iniciativas de resposta à riscos, adaptação diante de avanços tecnológicos e até mesmo aquelas iniciativas que surgem do além, mas que são patrocinados por um executivo influente.

De acordo com o guia, os projetos podem ser classificados de acordo com a incerteza associada à iniciativa, seja sobre o que deve ser feito, mas também sobre como deve ser feito. O Agile Practice Guide explora ferramentas, técnicas e práticas destinados a iniciativas que possuem alto grau de incerteza, comuns em projetos de caráter exploratório, com baixa maturidade sobre os requisitos, sobre os processos de desenvolvimento ou das competências que serão necessárias para atender os resultados esperados.

O Modelo de Complexidade de Stacey, ilustrado abaixo, nos auxilia na compreensão de que quanto maior a incerteza sobre uma iniciativa, maior será a taxa de mudanças, retrabalho e a complexidade do projeto.

Fonte: AGILE PRACTICE GUIDE (2017)

Para responder a este risco, o uso de práticas ágeis incentiva, por exemplo:

• ciclos de entregas curtos e incrementais, com o objetivo de proporcionar valor agregado ao negócio de maneira frequente e antecipada, bem como para obter feedback sobre o valor proporcionado pelas entregas e ajustar o percurso quando necessário;
• que as mudanças são sempre bem-vindas, mesmo em um estágio mais avançado da execução, enfatizando a capacidade adaptativa do processo em prol da entrega de valor e atendimento das necessidades do negócio;
• que as pessoas de negócio e da área técnica trabalhem juntos diariamente; estejam motivadas; recebam autonomia e empowerment para realizar o trabalho;
• a contínua atenção à excelência técnica e ao bom design;

O Manifesto para Desenvolvimento Ágil de Software (2001), descreve 4 valores e 12 princípios que fundamentam grande parte dos frameworks de agilidade existentes. Mesmo que sua origem tenha sido fundamentada na indústria de software, seus valores e princípios se disseminaram para muitos outros setores. Ele está disponível em https://agilemanifesto.org.

Conforme descrito no Agile Practice Guide, é a incorporação desta mentalidade, valores e princípios que se constitui uma abordagem ágil. Cabe às organizações, unidades de negócios e times de desenvolvimento selecionarem àquelas que melhor atenderão às suas necessidades. A seguir exploraremos quatro tipos de ciclos de vida sobre os quais os projetos podem ser realizados, conforme as suas características e incertezas associadas.

• Preditivo: trata-se de uma abordagem mais tradicional, onde existem etapas pré-definidas associadas à definição, design, planejamento, execução, validação e entrega de produtos e resultados. Normalmente aplicado quando a iniciativa possui um baixo grau de incerteza.
• Iterativo: contempla ciclos repetidos de prototipações e provas de conceito com o objetivo de obter feedbacks, melhorias e mudanças sobre o trabalho em andamento até que ele satisfaça os resultados esperados pela iniciativa e os produtos e serviços finais sejam entregues ao cliente. O foco desta abordagem está na aprendizagem e não sobre a velocidade de entrega.
• Incremental: se caracteriza pela repetida entrega de produtos/serviços que provejam valor agregado ao negócio e possam ser utilizados pelo cliente. Nesta abordagem o foco é a velocidade de entrega.
• Ágil: abordagem que mescla práticas iterativas e incrementais, nos quais os produtos e serviços são refinados, desenvolvidos, entregues e avaliados em ciclos, com a premissa de que as entregas intermediárias ao final de cada ciclo proporcionem valor e possam ser utilizados pelo cliente.

A seguir são ilustradas as principais características e diferenças entre os tipos de ciclos de vida definidos acima.

Fonte: AGILE PRACTICE GUIDE (2017)

Ao considerar uma abordagem ágil, temos que lembrar a definição de Projeto citado no início do artigo, onde cada iniciativa é única. Mesmo que se pretenda desenvolver um produto ou resultado já desenvolvido anteriormente, ao desenvolvê-lo novamente para outro cliente, o time pode ser diferente, as partes interessadas podem ser diferentes, bem como riscos e contextos externos a iniciativa.

Neste contexto, as abordagens e práticas ágeis podem ser adaptadas de acordo com as especificidades e contexto de cada iniciativa ou projeto, tendo em vista o atingimento de um fluxo contínuo de valor para os clientes e a maximização dos resultados para os negócios.

REFERÊNCIAS BIBLIOGRÁFICAS

AGILE PRACTICE GUIDE. Newtown Square, PA: Project Management Institute, 2017.

BOURQUE, P.; FAIRLEY, R. E. SWEBOK: Guide to the Software Engineering Body of Knowledge. 3 ed. Piscataway: IEEE Computer Society, 2014.

FILHO, C. F. História da Computação: o caminho do pensamento e da tecnologia. Porto Alegre: EDIPUCRS, 2007.

NAUR, P; RANDELL, B. SOFTWARE ENGINEERING: Report on a conference sponsored by the NATO Science Committee. Brussels: NATO, 1969.

PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. 4 ed. Newtown Square, PA: Project Management Institute, 2008.

SOMMERVILLE, I.; ENGENHARIA DE SOFTWARE. 8 ed. São Paulo: Pearson Addison-Wesley, 2007.

TATNALL, A. Reflections on the History of Computing: preserving memories and sharing stories. New York: Springer, 2012.