Da Análise e Codificação até o Deploy

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.

Posted in Uncategorized | Leave a comment

No ar

Bem vindos ao site da SanSIS – Sánchez Sistemas. Escolhemos o formato de blog para a página inicial de nosso espaço virtual pois é um dos formatos mais populares e simples de publicarmos notícias acerca de nossos produtos, nossas atividades, e outros assuntos de interesse de nossos clientes.

Esperamos através deste canal atingir um público fiel de usuários de nossos sistemas há mais de 15 anos no mercado.

Embora nossa especialidade tenha sempre sido o desenvolvimento de soluções específicas para clientes de características únicas através da prestação de serviços in loco, abriremos agora também uma nova frente, de produtos com foco na Gestão de Processos que incluirão ferramentas para mapeamento e modelagem de processos, e a automação dos mesmos em sistemas controlados através de certificados e assinaturas digitais sob a ICP-Brasil, trazendo transparência e legalidade à todas as ações e tramitações registradas no mesmo.

Aguarde e confira em breve. Teremos grandes e agradáveis surpresas para todos.

Posted in Uncategorized | Leave a comment