Projeto ADD – Assembly Driven Development
1)   Introdução

O advento da popularização da Internet provocou uma mudança na forma de utilização de software. No passado não muito remoto as aplicações tinham a característica “stand alone”, mas com a disseminação da rede www, o software passou a ser instalado em servidores, o que possibilita seu uso por várias pessoas.

Esta mudança de característica do software, de “stand alone” para “web application” tem como um dos propósitos a facilidade de manutenção que é feita apenas em um único ponto, ou seja, no servidor de aplicações.

O que se percebe na evolução da maneira de desenvolvimento de software é a crescente necessidade de redução de custos, sem perda da qualidade. As denominadas “web application” contribuem para isto, mas há outra tendência na construção de aplicações que aos poucos vão se tornando realidade: a construção de elementos (ou componentes) de software que podem ser utilizados em diversas aplicações.

Componentes são porções de software que possuem funcionalidades específicas e são de uso geral. Pelo fato de serem utilizados diversas vezes, beneficiam-se do processo de melhoria contínua através do ciclo PDCA – Plan, Do, Check, Act.

O reuso dos componentes reduzem os custos de confecção dos softwares e admitindo-se que este processo prolifere, o desenvolvimento de software se torna uma montagem de software (assembly driven development), utilizando ou configurando os componentes, objeto do presente estudo.

2)   O modismo do XDD

XDD ou X Driven Development constituem metodologias de desenvolvimento de software criadas segundo o significado de X. Assim, FDD – Feature Driven Development foca no desenvolvimento orientado a funcionalidades; TDD – Test Driven Development subentende desenvolvimento orientado a testes, que evolui para BDD – Behaviour Driven Development, etc.

XDD são sugestões de técnicas para direcionar as atividades de desenvolvimento, mas tais metodologias apenas sugerem uma diretriz alternativa para a criação do software. Pouco ou nada se considera em termos de redução de custos, maximização da qualidade e redução do tempo de desenvolvimento.

Na metodologia ADD – Assembly Driven Development, a estratégia básica é utilizar o recurso de maneira otimizada, direcionando os esforços na essência do desenvolvimento que são nas regras de negócio e na proposta da solução para o software.

Portanto, não se trata meramente de mais XDD, mas sim de uma estratégia que adota como diretriz a otimização no uso dos recursos, maximizando a qualidade e reduzindo o tempo de desenvolvimento.

3)   Estratégia

São diversos aspectos considerados nesta metodologia para o desenvolvimento de software:

a)   Foco nas regras de negócio – O esforço cognitivo dos desenvolvedores é direcionado para o entendimento correto das regras de negócio e na idealização da solução do problema. A atividade de “pensar” é consumida naquilo que mais interessa em cada software que é a busca da melhor solução;

b)   Uso de componentes – Parte-se do pressuposto que muitos componentes de uso geral estão disponíveis no mercado, além de convergirem para um padrão que permite facilmente o acoplamento dos componentes como partes de um sistema. Assim, a ADD vale-se deste fato e faz uso ostensivo de componentes, entendendo que são porções de software de qualidade, pois vem sendo testado e reutilizado pela comunidade ao longo do tempo. A adoção de padrões por estes componentes facilitam o uso e consequentemente, não há necessidade de utilizar mão de obra especialidade para executar esta parte do software. Por outro lado, qualquer montagem acelera o desenvolvimento, pois se trata apenas de uma atividade de configuração, sem se preocupar inclusive em fazer testes uma vez que isto se admite como etapa executada pelos fabricantes;

c)   Redução do tempo de desenvolvimento – O maior tempo consumido é na elaboração da solução. Todas as outras atividades são de montagem e consomem apenas o tempo de configuração das interfaces (que são padrões) e testes de condições de contorno. Por isto, o tempo total de desenvolvimento se torna bastante reduzido se comparado com o tempo consumido por outras metodologias de desenvolvimento;

d)   Qualidade – A qualidade do software é maximizada por duas situações: a primeira é que todo o esforço cognitivo se concentra nas regras de negócio, não dispendendo tempo nem recurso com outras atividades consideradas rotineiras; a segunda situação se refere ao uso de componentes, onde são adotados aqueles de melhor qualidade. Não existe a preocupação de manter os componentes que são propriedade de terceiros. Além disso, ao adquirir tais elementos de software no mercado, automaticamente se obtém o upgrade, a documentação e o suporte em tempo real;

e)   Redução de custos – Toda parte da montagem via componentes são de baixo custo. Os componentes sendo comercializados em larga escala também são de baixo custo e alta qualidade. Em termos globais há um ganho significativo em termos de economia;

f)    Ganho de competitividade – Neste aspecto, obtém-se a vantagem competitiva através da minimização de custos, alta qualidade e menor tempo de desenvolvimento;

g)   Manutenabilidade – Em relação a este item, a ADD garante a fácil manutenção das aplicações uma vez que os componentes secundários praticamente não necessitarão de manutenção e a parte central ocupando-se da implementação das regras de negócio será desenvolvida através do uso de metodologias ágeis que absorvem bem as mudanças de requisitos, aderindo fortemente aos anseios do Usuário, o que garante a baixa manutenção pós-facto.

4)   Papéis previstos

São diversos perfis projetados para esta metodologia, cada um com seus procedimentos e responsabilidades.

a)   Enabler – É o facilitador que coordena as atividades entre os membros de toda a equipe;

b)   Avaliador de Componentes – É o profissional especializado em avaliar diversos componentes e indicar aqueles que se adaptam ao padrão de desenvolvimento da Organização, em termos de nível de qualidade, suporte e interfaces;

c)   Comprador – É o profissional que tem expertise em compras. Deve possuir amplo conhecimento de componentes de TI e Negociações. Além de efetuar a aquisição dos componentes, deverá também celebrar contratos e acordos de manutenção;

d)   Arquiteto – É o profissional encarregado de conversar com o Cliente e desenhar a solução do problema. Reponde também por desenhar a arquitetura da solução e interagir com a equipe de desenvolvimento, esclarecendo as dúvidas;

e)   Desenvolvedor Master – É o profissional experiente em desenvolvimento que coordena os trabalhos de codificação das regras de negócio. É o líder da equipe de desenvolvimento;

f)    Testador – Profissional com expertise em testes, responsável pela elaboração da documentação de testes e avaliação da aplicação.

g)   Instalador – Profissional experiente na instalação da aplicação, configurando servidores e parâmetros da aplicação, entregando o software para o Cliente;

5)   Atividades previstas para o projeto ADD – Neste momento do projeto, há a necessidade de detalhar e aprofundar com mais ou menos detalhes dependendo de cada assunto.

a)   Pesquisa bibliográfica – Existe ainda a necessidade de aprofundar mais sobre o assunto, de modo a acrescentar maior nível de detalhes para a metodologia;

b)   Análise de riscos – Ainda não elaborada, a análise de risco é de grande importância para minimizar os efeitos negativos de algo não previsto neste método;

c)   Estudo dos papéis requeridos no método, aprofundando suas atividades e responsabilidades de modo a explicitar claramente o domínio e as interfaces de cada papel;

d)   Benefícios – Necessidade de aprofundar os estudos sobre os benefícios citados, validando cada item elencado;

e)   Definir os processos e detalhar o conjunto estruturado de atividades, normas, recursos e outros itens necessários para execução de cada um dos processos;

f)    Redução de Custos - Estudos para avaliação da redução de custos possível, analisando a economia obtida ao adotar o uso de componentes ao invés do desenvolvimento dos mesmos;

g)   Qualidade – Estudos para avaliar o ganho de qualidade, estabelecendo algumas métricas para o método.

6)   Conclusão

O fundamento básico da metodologia ADD consiste na otimização de recursos, redução de custos e aumento de qualidade, conforme descrito anteriormente. Estes três itens são suficientes para mostrar a viabilidade de prosseguir com esta pesquisa.

As metodologias XDD – X Driven Development  existentes apresentam maneiras diferentes de desenvolver software. FDD – Feature Driven Development e SCRUM, por exemplo, são similares. O primeiro foca nas funcionalidades e o segundo em uma lista denominada de Product Backlog.

A metodologia ADD – Assembly Driven, por sua vez, sugere a obtenção de vantagens competitivas, direcionado esforços para aquilo que realmente importa na aplicação, que são as regras de negócio. As outras atividades do software são consideradas de importância secundária e faz uso de partes de software de baixo custo e alta qualidade, que são os componentes comerciais.

ADD é uma inovação que tem grande probabilidade de sucesso em virtude de abordar redução de custos com ganho de qualidade, o que no mundo atual é de importância estratégica.

Obviamente, há ainda a necessidade de analisar com mais detalhes alguns pontos colocados anteriormente, mas isto não invalida avançar com este projeto.