Objetivo

A idéia deste artigo é apresentar um pouco das idéias e impressões que tenho em relação aos processos e metodologias da área de desenvolvimento de software.

O grande desafio do desenvolvimento de software está na diferença de perfis de profissionais necessários para se construir um software de qualidade. São muitas disciplinas e características diferentes para conseguir se construir uma equipe e consequentemente um software de qualidade.

Os processos na área de desenvolvimento existem principalmente para conseguir ter visibilidade sobre o tamanho do projeto (prazo e custo), minimizar os erros na passagem das tarefas entre as diferentes áreas e etapas do projeto.

Costumo dizer que a área de desenvolvimento de software precisa ser extremamente disciplinada pois cada etapa que pulamos no processo custa muito mais caro adiante. É impossível desenvolver uma funcionalidade correta quando o requisito está errado. É praticamente impossível chegar um software com um mínimo de qualidade para o cliente final quando não existe teste. Quando as etapas são puladas é que existe a certeza de ter desgaste entre o cliente, a equipe e os sponsors.

Esse artigo não tem por idéia focar alguma metodologia de desenvolvimento. Apenas discutir um pouco sobre os problemas comuns encontrados na área. Posteriormente talvez arrisque escrever um artigo discutindo um pouco sobre as metodologias de mercado (RUP, XP e outras) e suas características.

Aqui vai a idéia geral das “fases” para se concluir o desenvolvimento de um software, da sua concepção até sua implementação e os desafios encontrados em cada uma das fases.

Falaremos aqui principalmente sobre desenvolvimento de softwares empresariais, mais focados em banco de dados. Cadastros, consultas, relatórios e integrações. O universo do desenvolvimento de software é muito maior e pode compreender softwares embarcados, de missão-crítica, que controlam outros equipamentos. Descartaremos esses exemplos que existem, mas não representam a grande maioria.

Ciclo técnico de Desenvolvimento

Por mais que existam metodologias completamente diferentes, baseadas ou não em UML, com alto feedback, baixo feedback, muito prescritivas, pouco prescritivas todas elas partem de algumas premissas que chamamos de “ciclo técnico” de desenvolvimento.

As etapas-macro do desenvolvimento podem ser vistas dessa forma:

• Análise: A idéia aqui é saber “o que” fazer.
• Desenvolvimento: A idéia aqui é pegar o que foi definido na etapa de análise e fazer.
• Implantação: A idéia aqui é colocar pra rodar.

Olhando dessa forma parece muito fácil. Vamos explodir cada uma dessas etapas e verificar que não é tão simples assim. O mundo real é um pouquinho diferente.

Análise

Visão

O primeiro questionamento que temos na etapa de análise é: como saber quanto o projeto vai custar? Dependendo do custo, fica muito complicado justificar junto aos sponsors a continuidade do projeto.

Mas como vou saber o custo se a etapa de análise pode custar em torno de 40% do projeto?

Aí entram metodologias de análise de ponto de função. Existe muita coisa no mercado sobre esse assunto, porém é muito difícil achar algo que se adeque à realidade de cada uma das empresas que tem algum tipo de desenvolvimento de software. A maioria dessas metodologias é baseada no modelo matemático COCOMO.

É claro que estimar “antes” de fazer todo o levantamento é arriscado. Mas é uma forma de conseguir se ter uma “visão” do tamanho do projeto e qual etapa, funcionalidade é possível trabalhar, adiar, fasear para viabilizar o projeto.

Para chegar numa estimativa e num esforço aproximado, vários fatores são determinantes:

• Experiência da equipe: Equipes mais juniores tendem a estimar muito mal. Experiência é fundamental para conseguir ter visão.
• Padrões de Arquitetura: Os padrões ajudam a resolver uma série de problemas enfrentados em desenvolvimentos anteriores. Coisas como “como tratar um cadastro master-detail?” e um cadastro master-detail em “N” níveis? Qual ferramenta usar para gerar relatórios? Equipes sem experiência em desenvolver padrões de arquitetura tendem a fazer “cada um do seu jeito”. Isso dificulta um desenvolvedor dar manutenção no código do outro e chegar em estimativas mais precisas.
• Histórico. Começar a medir o tempo “real” que as coisas levam ajuda a chegar num tempo mais próximo da realidade em estimativas futuras. Criar a cultura de medir é muito importante.

Para conseguir chegar num número (geralmente hora/homem, ou quanto tempo um desenvolvedor em média levaria para implementar tal requisito, tendo como padrão um desenvolvedor num nível pleno geralmente) deve-se fazer levantamentos preliminares, obtendo as seguintes informações:

• Quantos cadastros/consultas existem? Entende-se por cadastro/consulta interfaces para dar manutenção em dados simples ou compostos (desde uma tabela de “tipo de pedido”, “parâmetros”, até entidades mais complexas como pedidos (compostos por itens e programações de entrega, por exemplo).
  • Desses cadastros, quantos armazenam dados em uma única tabela? Quantos armazenam em duas, três, quatro tabelas? Esse é um bom fator para determinar complexidade.
  • Quantos campos tem em média em cada uma das tabelas? (Até 5 – simples, até 10 médio, mais de 10, complexo)
  • Quantas tabelas auxiliares precisarão ser consultadas para conseguir realizar esse cadastro?
  • A consulta tende a envolver muitos filtros (até 5, até 10, mais de 10).
• Existem integrações?
  • Os sistemas integrados são padrão de mercado?
  • Existe viabilidade tecnologica de integração entre o software desenvolvido e o sistema destino?
  • Quantas interfaces existem?
  • Quantos campos em média?
• Quantos relatórios existem?
  • Quantas tabelas envolvidas para gerar o relatório?
  • Dependem de informações obtidas de algum outro sistema/site/web service? É viável extrair essas informações?
  • Quantos campos em média no relatório?

Através desses fatores, dá para obter através de histórico uma média do esforço para projetos futuros. Em cima disso é possível também declarar escopo para o projeto (é interessante declarar o “número” de cadastros, consultas, interfaces) para evitar desvios futuros. É interessante até que essa declaração de escopo conste na proposta. Fica mais transparente tanto para quem está vendendo, quanto para quem está comprando.

Muitas vezes os projetos são manutenções evolutivas em sistemas já existentes. Nesses casos, deve-se preocupar com alguns fatores adicionais:

• Caprichar na análise de impacto quando as mudanças envolvem módulos “Core” do sistema a ser modificado. Vale a pena investir tempo aqui, porque geralmente sistemas legados não possuem documentação de projeto, manual e pouquíssima gente sabe como funciona (geralmente o lugar mais confiável para saber o que o sistema faz é o próprio código-fonte).
• Na ausência de padrões de arquitetura ou manutenções em módulos com código mal escrito (cenário mais comum) considerar na estimativa o tempo perdido com lutas para entender a arquitetura ou desenvolver de um jeito mais custoso. As vezes esse tipo de análise fomenta a migração de um sistema todo para outra tecnologia ou arquitetura.
• É importantíssimo ter um processo de gestão de configuração e versões para garantir a mudança de uma forma saudável. Manutenções evolutivas em softwares legados sem esse tipo de processo tendem a ser desastrosas, pois não consegue-se rastrear o que mudou e voltar as alterações como contingência de algum problema mais sério, principalmente em sistemas que envolvam casos de multa, penalização ou processos críticos (billing, por exemplo).

Levantamento de Requisitos

Aqui faremos uma abordagem bem superficial. A idéia é detalhar algumas técnicas de levantamento num artigo separado.

O grande desafio da etapa de levantamento de requisitos está em extrair as informações dos usuários. É um desafio por uma série de razões.

A principal delas na minha opinião é que raramente os usuários sabem o que querem. Eles querem um sistema que resolva o problema deles, mas geralmente nunca pararam pra pensar no que a ferramenta deve fazer para ajudá-lo. Por isso as solicitações podem ter desvios absurdos em relação ao escopo declarado na etapa anterior. As vezes começa-se um sistema de faturamento por exemplo e percebe-se que no meio do caminho a dificuldade de se emitir as notas fiscais e faturas a tempo está nas informações de um sistema de estoque por exemplo, mas o escopo do projeto é desenvolver um sistema de faturamento.

Outro fator que geralmente prejudica o levantamento são usuários que “seguram” informações. Tem medo de serem obsoletados pelo novo sistema e acabam boicotando o projeto. Para esse tipo de usuário é interessante ter uma conversa mais próxima e mostrar futuras oportunidades que ele pode ter caso o projeto tenha sucesso. É muito importante estar atento a esses detalhes. Ambiente de guerra e conflito não é um bom ambiente para executar trabalhos criativos.

O perfil da pessoa responsável pela análise e documentação dos requisitos é um perfil bem “raro” no mercado. Na minha opinião o ideal são pessoas que evoluiram da programação e passaram a compreender um pouco mais de negócio e tem boas características de relacionamento pessoal. São comunicativos, bons argumentadores e extremamente pacientes com os usuários. Há quem acredite que uma pessoa que realiza análise de sistemas não precisa saber desenvolver. Há controvérsias. Eu acredito que ele não precise ser um exímio desenvolvedor ou mesmo gostar de código-fonte, mas precisa ter visão de processo e principalmente do modelo entidade-relacionamento (ou o diagrama de classes para quem usa).

Para “documentar” os requisitos existem várias formas. Pretendo detalhar algumas delas quando me aprofundar no assunto “Levantamento de Requisitos”.

O importante é concluir essa fase com um documento descrevendo a funcionalidade do ponto de vista do usuário. O que tem, como se comporta, de onde vem a informação (outro cadastro, outro sistema). É importante ter uma aprovação “formal” do usuário final. Para que no caso de mudanças futuras, tenha-se um ponto “base” para discutir.

No caso de manutenções de sistemas, nada impede que o comportamento do sistema atual seja descrito e o que será modificado no mesmo documento. O importante é que com este documento seja possível ter um ponto base para discutir com o usuário no caso de futuras modificações.

Desenvolvimento

A etapa de desenvolvimento consiste em “fazer” o software. Como pré-requisito, as especificações funcionais da etapa de análise devem estar prontas e consistentes.

Geralmente, dependendo dos profissionais que realizam a análise, existe grande chance delas não estarem 100% consistentes e num nível de detalhamento bom (com todas as informações referentes aos comportamentos do software esperado informadas). É interessante colocar um processo “formal” de aceite, onde os desenvolvedores validem essas especificações e “aceitem” as mesmas da equipe de análise antes de começar a contar o tempo de desenvolvimento.

Algumas equipes de desenvolvimento desprezam especificações técnicas. As especificações técnicas basicamente são descrições de “como implementar” o software, em termos bem técnicos. O que usar, detalhamento de lógicas de programação e outros. Isso está muito relacionado com o perfil das pessoas que estão desenvolvendo. Quando existem muitos programadores inexperientes, é interessante que estes recebam as coisas muito bem especificadas. Quando se trabalha com perfis de analista/programador é possível não usar especificações técnicas e ter sucesso.

Existem algumas metodologias que utilizam ferramentas da UML como diagrama de classes, seqüência, componentes para descrever a implementação. Particularmente acho que estes diagramas podem ser “opcionais” na maioria dos casos (os mais simples). Vai muito do critério de quem é o líder técnico da equipe e a maturidade desta equipe. Vale lembrar que os diagramas de classes ou descrições da especificação técnica são um processo bastante custoso e raramente evoluem junto com o software. Eu acredito que vale mais não ter um documento no projeto do que ter um documento desatualizado. Documentos desatualizados atrapalham invés de ajudar.

Padrões de arquitetura são fundamentais. Geralmente os times tem os padrões deles já descritos **antes** de começar o projeto. A idéia aqui está em já ter formatadas e prontas soluções para os problemas mais comuns: Como paginar grids na Web, padrão de navegação, como tratar cadastros master-detail (em vários níveis), padrão para desenvolvimento de relatórios, processamentos batch e outros. Ter esses padrões desenvolvidos e maduros agiliza muito o desenvolvimento e melhora muito a qualidade do produto final.

Os testes “unitários” são de responsabilidade do desenvolvedor. Faz parte da etapa de desenvolvimento. É muito interessante que o líder técnico monitore por “amostragem” o código escrito pelos demais desenvolvedores, para saber se os padrões estão sendo seguidos e se os mesmos estão testando o código antes de liberar para testes. Ferramentas de controle de versão que “notificam” alterações ajudam muito na gestão desse tipo de alteração.

Homologação Interna

Testes

Teste é um assunto sempre complicado. Geralmente as pessoas que testam são usuários de sistema experientes e não conhecem a fundo o sistema. Não é raro pegar pessoas que sequer conhecem o ciclo de desenvolvimento de software e mesmo não tem muita experiência com informática. Ex.: Um testador de um sistema Web que não entende como funciona o “cache” de um browser.

O mais importante aqui é garantir que as funcionalidades estejam desenvolvidas de acordo com a especificação funcional. Todas as funcionalidades previstas na especificação devem estar de acordo com o especificado. Especificações que contém “casos de teste” ajudam bastante. Casos de teste são exemplos de como operar o sistema, e como o sistema deve se comportar nessas situações.

Testes de operação simples também devem ser contemplados. Estouro de tamanho de campos, informar letras em campos numéricos e coisas não-óbvias que geralmente os usuários fazem e os desenvolvedores acabam não prevendo.

Para a área de testes é importante criar “scripts” documentados sobre quais processos devem ser feitos no sistema para dar “aceite” na funcionalidade. À medida que surgem novas situações, alimentar esses scripts. Eles ajudaram em futuras manutenções para evitar que situações já previstas ocorram após uma manutenção.

Aqui devem ser previstos os testes “integrados”, ou seja, o impacto de uma funcionalidade nas demais (ligou um parâmetro aqui, o que muda ali?) e testes de integração entre sistemas.

Homologação Interna

Uma vez testado, o sistema encontra-se num estágio em que está funcionando e é muito importante que os analistas que participaram do levantamento façam a “passagem” para a equipe de implantação. Esse processo costumo chamar de “homologação”, ou seja, verificar se o que foi desenvolvido está de acordo com a especificação funcional, pelas pessoas que conceberam a espeficação funcional e conhecem a real necessidade do cliente.

Se isso for realizado antes dos testes, é possível que a quantidade de bugs existentes ainda no sistema e erros básicos acabem transformando a equipe de análise em testadores, o que é um custo completamente desnecessário.

Uma vez os analistas considerando que o sistema está 100% de acordo com o desenvolvido, passa-se para a etapa de homologação junto aos usuários.

Não é raro nessa etapa surgirem discussões sobre coisas o sistema “deveria” contemplar. O juiz para esse tipo de situação é sempre a especificação funcional. Veremos mais adiante o tópico “Aumentos de Escopo” que fala um pouco sobre esses “desvios”.

Homologação junto aos usuários

Nesse processo a equipe de implantadores já deve ter conhecimento do funcionamento do sistema e junto aos analistas (fica a critério da empresa, qual ou quais equipes mandar. Mandar as duas é uma opção interessante para disseminar o conhecimento e evitar que o cliente ou usuário final aproveite-se da insegurança de quem está conduzindo a homologação para ganhar funcionalidades novas) devem se reunir com o usuário final e validar as solicitações junto a ele.

Nesse processo é muito comum senão inevitável surgirem questionamentos relacionados ao sistema. Falta isso, falta aquilo, isso é bug, isso não deveria funcionar dessa maneira. Aqui é que a especificação funcional paga todo o seu investimento.

É muito simples, mas exige bastante firmeza e disciplina:

• Se o erro for grosseiro do tipo, mensagem de erro em inglês não tratada, campo numérico aceitando valor string ou coisas parecidas, não tem nem o que questionar. É bug, gera um issue (importante ter um sistema de issue tracking).
• Se a solicitação do usuário estiver contemplada na especificação funcional e não estiver contemplada no software, é bug. Gera um issue.
• Se a solicitação do usuário não estiver contemplada na especificação (que o próprio usuário aprovou), é uma situação de aumento de escopo do projeto. Deve-se negociar o custo para fazer a alteração.

Aumentos de Escopo

No caso de aumento de escopo é muito comum a equipe de gestão de projeto ou mesmo a equipe comercial, não ir atrás de justificar essas horas com o cliente. É sempre 1h aqui, 2 ali, um dia aqui. E ninguém faz a soma de quanto perdeu no final. Não é raro jogar uma quantidade de mais de 50% de aumento de escopo num projeto, pois os usuários raramente sabem o que querem e não entendem o custo envolvido no desenvolvimento de um software. Como quem geralmente paga a conta é o fornecedor ou a área que desenvolve o software, os usuários acabam não se incomodando em pedirem coisas novas indiscriminadamente.

Sugiro que a equipe de desenvolvimento “feche as portas” para solicitações desse tipo não-especificadas. Quem tem que entender a solicitação do cliente, analisar o impacto e especificar a alteração é a equipe de análise. Quando vierem as especificações revisadas, devidamente aprovadas pelo cliente, deve-se estimar as horas e contabilizar no projeto o quanto houve de desvio em relação às horas estimadas no inicio. É a única forma de criar uma cultura na equipe de sempre estimar horas, dar visibilidade de onde ocorrem os problemas e ainda e melhorar a receita dos projetos. Os problemas geralmente se classificam em algum destes:

* Usuário chave que não sabe exatamente o que quer
* Equipe de análise com dificuldade para entender o que o usuário precisa
* Equipe de desenvolvimento sendo displicente e propositalmente “esquecendo” de implementar requisitos para não perder seus prazos.

Implantação

Plano de Implantação

Deve ser traçado junto aos usuários um plano, com datas e responsabilidades para realizar a implantação do projeto. Algumas etapas críticas:

• Treinamento dos usuários
• Levantamento de cargas/dados iniciais para o sistema começar a funcionar
• Coordenação de subida da aplicação para o ambiente de produção
• Alterações/processos necessários em sistemas integrados

Uma vez traçado esse plano, é segui-lo e acompanhar o ambiente de produção. É interessante deixar alguns desenvolvedores, analistas em stand-by para atender os clientes em possíveis problemas (já que é um processo novo e geralmente gera-se uma série de dúvidas).

Solicitações Extra-Escopo

Agora não partindo do usuário chave e sim do usuário final, é comum surgirem mais questionamentos sobre como o sistema deve funcionar.

Por isso é importante conseguir manter um ótimo relacionamento com o usuario-chave e fazer ele se que sua colaboração é imprescindível para o sistema (já que o usuário chave é mesmo uma das figuras mais importantes do sistema!). Ele é o primeiro defensor do sistema.

No caso da impossibilidade de evitar que novas solicitações sejam colocadas para que o projeto entre em produção, deve-se seguir o mesmo processo do item “Aumentos de Escopo”.

Conclusão

Como vimos na maioria dos tópicos, disciplina é imprescindível. Se as etapas são puladas, os problemas não aparecem. Cria-se um ambiente de projeto em que as pessoas ficam mais preocupadas em se defender do que em colaborar.

O sucesso do sistema está no trabalho cooperativo entre equipes multi-disciplinares. É praticamente impossível conseguir sucesso quando se estabelece um clima de guerra na equipe.

Os processos parecem tornar o desenvolvimento mais “chato”. Eu discordo totalmente disso. Quando as pessoas começam a adquirir facilidade e disciplina para realizar todas essas etapas, cada um começa a ter clara a sua importância e responsabilidade no processo, diminuem-se as falhas e dessa forma o trabalho fica mais produtivo e agradável.