Importância de metodologia no desenvolvimento

A nossa missão como desenvolvedor é construir não somente programas ou mesmo sistemas, mas criar soluções, estas que vão de encontro com a necessidade do usuário e área requisitante em tempo previsto...

por Thiago Pastorello Gervazoni

A nossa missão como desenvolvedor é construir não somente programas ou mesmo sistemas, mas criar soluções, estas que vão de encontro com a necessidade do usuário e área requisitante em tempo previsto. Sabendo disto, Edward Yourdon e Chris Gane se aventuraram nas primeiras metodologias de desenvolvimento, desde então a metodologia desenvolveu-se muito, mas muitos desenvolvedores e empresas não a adotam, por uma série de motivos:

1. Estão acostumados com seu próprio jeito de desenvolver, e sentem-se satisfeitos.
2. "Preguiça" de aprender uma nova linguegam para descrever o comportamento dos sistemas.
3. Sentem que é "Perda de tempo", e preferem partir para a codificação.
4. Sentem que a empresa não precisa de tanto, e o usuário nem é tão exigente.
5. Acomodação.
6. Falta de informação do que a metodologia pode oferecer.

Em empresas onde não utilizam uma metodologia, o processo de desenvolvimento segue mais ou menos os seguintes passos :

1) O usuário solicita um novo sistema;

2) O analista entrevista-o informalmente para ter idéia dos requisitos do sistema;

3) O analista explica o que pensa que deve ser o sistema para sua equipe e todos se sentam imediatamente diante do computador e começam a programar. Nenhuma análise mais profunda é feita. Projeto lógico, então, nem pensar.

4) Muitos meses depois do prazo prometido ao usuário, o sistema é entregue. Não está documentado e sua estrutura deixa a desejar.

5) O usuário descobre nos três primeiros dias de uso que o sistema não é o que ele queria. Assim sendo, no quarto dia, o usuário envia ao analista uma enorme lista de modificações.

6) A equipe, então, encarrega-se de executar as modificações o mais rápido possível, comprometendo ainda mais a estrutura do sistema.

7) O resultado é um sistema que atende parcialmente ao usuário, não está documentado, terá uma taxa altíssima de manutenção e não será nada fácil de modificar.

Se na sua empresa está acontecendo mais ou menos isto que descrevi acima, das três uma, ou você não está utilizando metodologia alguma, ou não está seguindo as etapas propostas da metodologia, ou está utilizando metodologia própria que não cobre alguns "buracos" no desenvolvimento do projeto.

Toda metodologia deve conter alguns tópicos básicos, se você utiliza uma metodologia caseira, que atualmente representa 36%, esta metodologia deve abranger as seguintes etapas, senão poderá ser seu calcanhar de aquiles.

1- Solicitação do usuário
1.1 Pedido do usuário
1.2 Avaliação do problema
1.3 Formalização da solicitação

2- Viabilização da solicitação
2.1 Estudo do problema
2.2 Disponibilidade de recursos
2.3 Relações curso/benefício
2.4 Relatório formal

3- Proposta de sistema
3.1 Planejamento do projeto
3.2 Levantamento preliminar
3.3 Análise de dados
3.4 Estratégia de desenvolvimento
3.5 Definições gerais
3.6 Relatório formal
3.7 Proposta do sistema

4- Projeto de sistema
4.1 Avaliação da proposta
4.2 Planejamento do projeto
4.3 Levantamento detalhado
4.4 Análise de dados
4.5 Apresentação do projeto

5- Desenvolvimento do sistema
5.1 Revisão de procedimentos
5.2 Planejamento das atividades
5.3 Programação
5.4 Simulações
5.5 Treinamento
5.6 Implantação

6- Manutenção de sistema
6.1 Avaliaçãodo pedido
6.2 Diagnóstico da solução
6.3 Resolução

Uma boa metodologia, junto com um trabalho de análise, projeto e construção, tem tudo para gerar sistemas de informação com excelente relação custo-benefício.

Existem duas grandes metodologias: RUP ( Rational Unified Process ) e XP ( Extreme Programming) e um guideline MSF ( Microsoft Solution Framework ).

Vou detalhar uma a uma mais para frente, mas em suma:

A RUP destina-se a grandes projetos, é uma metodologia muito detalhada envolve muitas pessoas, pode chegar até 30 papéis, e seu aprendizado é longo, por ser muito detalhado possui prós e contras.

A XP destina-se a equipes menores, com mudanças a todo momento, com projetos totalmente voltados a satisfação dos usuário. Todos se destinam, mas a XP em específico preocupa-se com o usuário, para se ter uma idéia o projeto começa praticamente com um protótipo, e não existe documentação durante o desenvolvimento, que é sempre feito em dupla. Além de fábricas de Games que utilizam a XP, pode ser usada também para projetos emergênciais que não se tem tempo para análise e documentação, apenas o produto.

A guideline MSF, guideline porque a microsoft não classifica o MSF como metodologia, mas como um guia, destina-se a qualquer desenvolvimento, seria mais uma engenharia de software porque utiliza-se MSF para qualquer fim, é muito útil, fácil de implementar e necessita de pouquissímo tempo para o aprendizado, muito aconselhável nos dias atuais, é o guia para desenvolvimento do produtos Microsoft.

Alguns acabam por fazer um mix de metodologias e guidelines e criam uma para a empresa com o melhor de cada uma, para atender a todas as necessidades, projetos grandes, menores e emergênciais.

Ao longo das colunas postarei como deve ser uma equipe de projeto, papéis a serem desenvolvidos, divisão do trabalho, técnicas de análise, e as metodologias em detalhe, deve-se lembrar que recursos tecnológicos de ponta devem ser usados, mas são uma parte do projeto, não adianta você mostrar para a diretoria todos os recursos de ponta que está usando no projeto se não tiver uma metodologia para dar prazos com bom senso, documentar, saber contornar mudanças e implementar novos recursos, se comprometer o que foi avaliado.

Até a próxima.