Depois de muitos anos “batendo a cabeça” e correndo que nem barata tonta atrás de diversas metodologias, ou muito burocráticas, ou demasiadamente leviadas, cheguei a uma fórmula de “sucesso” para o desenvolvimento de sistemas. Agora, sempre que vou iniciar a criação de qualquer sistema sigo um pequeno roteiro que posteriormente auxilia qualquer pessoa a rapidamente entender o sistema pelo menos de forma básica. Infelizmente, muitas vezes, mesmo com o roteiro reduzido e quantidade de artefatos sendo poucos, ainda assim uma etapa ou outra acaba sendo queimada pela famosa pressa gerencial guiada por uma área comercial que na ânsia de conseguir o contrato promete prazos irreais ao cliente.
Com este roteiro, uma série de artefatos são desenvolvidos no processo da análise, todos eles visando documentar o mínimo necessário a fim de termos uma documentação fácil de manter e atualizar.
Os elementos que considero essenciais e o mínimo para garantir o desenvolvimento de um sistema com foco nas necessidades do cliente são, em ordem de criação:
| Elemento | Objetivo |
| Mapa Mental | Em um primeiro momento, realiza-se um brainstorm com o stakeholder principal do projeto, normalmente denominado também como “Gestor do Sistema”. O resultado deste primeiro brainstorm é o Mapa Mental. Nele, vão todas as ideias sobre o que se espera do sistema, mesmo aquelas que não tem como serem implementadas. Tem por objetivo criar uma visualização geral da aplicação a ser desenvolvida. No centro, temos a aplicação em si. Normalmente, as ramificações de 1ª nível são elementos modulares funcionais, e suas subramificações, funcionalidades de cada módulo. Um item não-funcional pode ser criado vinculado ao sistema. |
| Definição de arquitetura e Visão do Sistema | Com base nas informações mapeadas, inicia-se a etapa de definição da arquitetura. É neste ponto que as funcionalidades são analisadas para verificar sua aplicabilidade real. Um desejo muito comum dos usuários é poder digitar apenas o CPF ou CNPJ e então trazer os dados diretamente da Receita, mas a maioria não sabe que há um custo na contratação do serviço ou que um convênio a nível político precisa ser estabelecido para utilização dos webservices que provêm estes dados. A integração com outros sistemas também precisa ser analisada e o desenvolvimento dos componentes de integração também influem nos custos, prazos, recursos necessários, e muitas vezes em autorização dos gestores dos outros sistemas. Enfim, este é o ponto no qual dá-se resposta ao cliente sobre o que pode ou não ser desenvolvido. Resulta daqui normalmente a escolha tecnológica e o documento de visão do sistema, bem como as definições de custo inicial e cronograma. A partir deste ponto, torna-se comum a definição de pequenos pacotes para entrega. Veja que para iniciar a codificação não é necessário estar com todo o sistema mapeado. E é, a partir daqui que pode-se definir o uso ou não de uma metodologia ágil. Dependendo do tamanho do projeto, quantidade de recursos necessários, prazo, etc, pode ser que o desenvolvimento tenha que seguir uma linha mais tradicional. |
| Modelagem conceitual | Após a visão definindo o escopo e a arquitetura detalhando as tecnologias a serem utilizadas, vem a modelagem conceitual, que visa mapear os casos de uso, os diagramas de atividades com o mapeamento dos fluxos de processos envolvidos (e pontos de decisão), o mapa navegacional da aplicação (storyboard), e a prototipação não funcional das telas. Com estes elementos prontos, pode-se agora iniciar a execução do desenvolvimento do código da aplicação. Caso se deseje aplicar TDD (Test Driven Development), é a partir deste ponto que os testes macro devem ser definidos, e os casos de uso podem ser quebrados em pequenas stories para aplicação do Scrum. |
| Modelagem Sistêmica | Com o entendimento da aplicação feita pelo mapa mental, tecnologia necessária mapeada pela arquitetura, casos de uso detalhando regras, processos mapeados nos diagramas de atividade, navegação do sistema, e os protótipos aprovados pelo cliente, inicia-se a codificação do sistema. Para isso, faz-se necessário pelo menos mais dois diagramas: Classes (modelo), e, se o banco de dados utilizado for relacional, o MER que atenderá às classes. Uma falha muito comum das pessoas é querer definir o MER antes das classes, e então criar uma “engenharia reversa” do banco de dados que gerará as classes. Isso acaba gerando uma classe para cada tabela, e tabelas de junção levam desenvolvedores a trabalharem de uma forma “orientada a estruturas” ao invés de “orientada a objetos”. Outros diagramas podem ser dispensados pois apenas detalham mais elementos que não precisam ser detalhados pois a arquitetura já define essas comunicações entre eles, e como a sequencia das mensagens se dão. O diagrama de pacotes pode ser feito em conjunto com o de classes. Se possível, o ideal é fazer dois diagramas de classe: um de alto nível, com a notação de entidades (círculos) mostrando suas associações, e depois o de baixo nível, detalhando seus atributos e métodos. A partir deste ponto, a TDD já começa a elaborar os testes unitários. |
| Modelagem de implantação | Esta modelagem na verdade já ocorre quando da definição da arquitetura. Diz respeito a como os elementos se encontram fisicamente dentro da infraestrutura de rede e da aplicação, e como eles devem comunicar-se. Porém, ao final da codificação, é necessário uma revisão e atualização do que foi feito, pois como os requisitos sofrem mudanças constantes, manter tais diagramas durante o desenvolvimento com uma equipe reduzida só se faz necessário quando o impacto é muito grande. |
| Manual do Sistema | O manual do sistema pode ser escrito a partir do momento em que se inicia a modelagem conceitual, porém, como a definição das funcionalidades e informações muda muito nessa etapa, é recomendável que seja criado mais ao final de cada ciclo, após a homologação de cada micro-entrega pelo cliente, e apenas cobrindo o que foi finalizado. Dessa forma, o retrabalho é bem menor, e acompanha apenas as solicitações de mudança ocorridas no andar do projeto. |
Como pode-se notar, por este pequeno roteiro, o mínimo é coberto, e diversas metodologias na parte do desenvolvimento podem ser aplicadas. A partir do terceiro item, o sequenciamento das atividades seccionado em pequenos pacotes de entrega permitem um desenvolvimento suave, e com todas as áreas da equipe trabalhando paralelamente. Isso garante um andamento rápido ao projeto já que ninguém está parado, além de ser mais fácil de controlar o que está acontecendo.
A idéia é aplicar o conceito da Navalha de Occam juntamente com a afirmação de Einstein sobre o conceito onde ele afirma “tudo deve ser feito da forma mais simples possível, mas não mais simples que isso”, também expressa por Antoine de Saint-Exupéry como: “a perfeição não é alcançada quando já não há mais nada para adicionar, mas quando já não há mais nada que se possa retirar”. Esses conceitos e a prática sobre diversas metodologias nos levam à necessidade de encontrar um ponto de equilíbrio, pois nem sempre é possível adotar todos os elementos do RUP, como também nem sempre é possível ser simplista demais apenas com “estórias”. Ambas as metodologias são opostos que podem andar juntos sem causar danos ou prejuízos aos clientes, analistas, desenvolvedores e todos os demais envolvidos no projeto.
Espero ter conseguido ajudar alguns a organizar seu trabalho de forma a incluírem nele o planejamento e percepção necessárias dos requisitos dos clientes que vemos tantos terem problemas com isso.