Metodologia para o desenvolvimento da ferramenta proposta

Descreveremos a seguir uma definição geral do método a ser utilizado no desenvolvimento da ferramenta proposta. Mais do que a definição de uma linguagem de programação em si que pode tanto ser “dotNet” da Microsoft ou PHP como uma

linguagem interpretada livre, entendemos que o importante nesse contexto metodológico é a definição de um processo de desenvolvimento que atenda às necessidades do projeto.

Existem vários processos para o desenvolvimento de software. No entanto algumas atividades fundamentais são comuns a todos eles de acordo com Sommervile e serão utilizadas para a definição metodológica deste trabalho:

1 - Especificação de Software: os participantes do projeto (clientes, arquitetos e engenheiros) definem os requisitos e as funcionalidades do software a ser produzido. Uma fase em que o produto final é composto por uma densa e detalhada documentação com o esboço de telas e definição passo a passo da estrutura sistêmica, similar ao que faremos na definição da ferramenta BigChain Escola proposta nesta dissertação a seguir no item 3.4 deste capítulo.

2 - Projeto e Implementação de Software: o software é projetado e programado de acordo com as especificações da fase 1. As telas esboçadas anterior são traduzidas em modelos através de diagramas e estes modelos são implementados em uma linguagem de programação.

3 - Validação de Software: o software é validado para garantir que todas as funcionalidades especificadas foram implementadas.

4 - Evolução de Software: o software é modificado para continuar atendendo às necessidades dos clientes e do mercado e dessa forma percorre-se novamente as fases 1, 2, 3 e 4 em um ciclo contínuo, surgindo então as versões 1.0, 1.1, 1.2, 2.0 e assim por diante.

Diferentes tipos de sistemas necessitam de diferentes processos de desenvolvimento. Por exemplo, um software de tempo real de uma aeronave deve ser completamente especificado antes do inicio do desenvolvimento, enquanto nos sistemas de comércio eletrônico a especificação e o programa são, geralmente, desenvolvidos em conjunto. Consequentemente, essas atividades genéricas podem ser organizadas de diferentes maneiras e descritas em níveis diferentes de detalhes, para diferentes tipos de software. (SOMMERVILLE, 2008, p. 6)

De forma geral, definimos como premissas para a definição do processo metodológico de desenvolvimento do software deste trabalho: agilidade, flexibilidade e adaptabilidade.

O processo que se adapta melhor a esses princípios é o que conhecemos como

Extreme Programming, ou XP, que detalharemos melhor a seguir.

3.3.1 Extreme Programming e seus benefícios

A ferramenta proposta neste trabalho adapta-se perfeitamente à metodologia XP de desenvolvimento que visa imprimir maior agilidade, flexibilidade e adaptabilidade ao processo, pois o conceito principal que está por traz dessa metodologia é que o usuário aprende sobre as necessidades do sistema na medida em que é capaz de manipular o

software que esta sendo desenvolvido.

Na medida em que o usuário vai tomando contato com as funcionalidades do sistema em desenvolvimento, ele vai podendo validar e compor melhor suas necessidades e prioridades.

“A Extreme Programming (XP) é possivelmente o mais conhecido e mais amplamente usado dos métodos ágeis” (SOMMERVILLE, 2008, p. 263).

O ponto principal para a compreensão desse método é que quando o usuário- cliente aprende dinamicamente com o sistema em desenvolvimento, ele gera feedback para a equipe de desenvolvimento e dessa forma alimenta e re-alinha os processos garantindo maior agilidade, flexibilidade e adaptabilidade.

O método de Extreme Programming não deixa de seguir as atividades metodológicas fundamentais de um processo de desenvolvimento de software descrito anteriormente como: especificação de software, projeto e implementação de Software, validação de software e evolução de software. No entanto, envolve algumas práticas que segundo Sommerville, se enquadram nos princípios dos métodos ágeis como:

1 - Planejamento Incremental no qual os requisitos são registrados em cartões e as histórias a serem incluídas em um release são determinadas pelo tempo disponível e sua prioridade relativa. Os desenvolvedores dividem essas histórias em tarefas.

2 – Pequenos releases nos quais um conjunto mínimo de funcionalidades que agrega valor ao produto são desenvolvidos primeiro. Releases do sistema são freqüentes e adicionam funcionalidade incrementais ao primeiro release.

3 – Um Projeto Simples é realizado de forma a atender os requisitos atuais e nada mais.

4 – Desenvolvimento test-first como um framework automatizado de teste unitário para escrever os testes para uma nova parte da funcionalidade antes que esta seja implementada.

5 – Em um processo de Refactoring, espera-se que todos os desenvolvedores recriem o código continuamente tão logo os aprimoramentos do código forem encontrados. Isso visa tornar o código simples e fácil de manter.

6 – Programação em pares é praticada de forma que os desenvolvedores possam verificar o trabalho um do outro fornecendo apoio de forma integrada.

7 – Propriedade coletiva: os pares de desenvolvedores trabalham em todas as áreas do sistema de tal maneira que não se formem ilhas de conhecimento. Com todos os desenvolvedores de posse de todo o código, qualquer um pode mudar qualquer coisa.

8 – Em um processo de integração contínua, tão logo o trabalho em uma tarefa seja concluído, este é integrado ao sistema como um todo e depois de qualquer integração, todos os testes unitários do sistema devem ser realizados.

9 – Cliente on-site: Um representante do usuário final do sistema deve estar disponível em tempo integral para apoiar a equipe de XP. Nesse método de desenvolvimento, o cliente é um membro da equipe de desenvolvimento e é responsável por trazer os requisitos do sistema à equipe para implementação.

A comunicação constante e interativa entre o usuário e a equipe de desenvolvimento é algo fundamental no processo XP de desenvolvimento e deverá ser praticada com destreza para o desenvolvimento da ferramenta proposta neste trabalho.

Quando tratamos da Web 2.0 em que o processo de interação e colaboração são intrínsecos ao conceito, o método XP torna-se algo ainda mais aplicável uma vez que usuários e desenvolvedores fazem parte de um universo comum em que a forma de comunicação encontra-se pré-definida dentro de um contexto ainda mais amplo.

Um ponto importante que utilizaremos com atenção para o desenvolvimento dessa ferramenta baseada no conceito web 2.0 para o ensino e aprendizado da generosidade em escolas no ensino fundamental é o desenvolvimento test-first, uma das mais importantes práticas da metodologia XP.

A escrita de testes primeiro define implicitamente tanto uma interface como uma especificação do comportamento para a funcionalidade que esta sendo desenvolvida. Os problemas de mau entendimento de requisitos e interface são reduzidos. Essa abordagem pode ser adotada em qualquer processo em que houver uma clara relação entre um requisito de sistema e a implementação de código necessária (SOMMERVILLE, 2008, p. 266)

Ou seja, nessa metodologia de desenvolvimento, ao invés de escrever primeiramente o código do programa e depois realizar os testes de aceitação, o test-first na metodologia XP propõe que os testes sejam escritos antes do código final do sistema. O teste é escrito como um componente executável e visa simular os componentes de entrada de dados no sistema e avaliar se saída corresponde ao resultado esperado.

Conhecer detalhadamente a especificação inicial do software é um pré-requisito para que os programadores possam escrever testes adequadas para a avaliação do sistema.

Vale observar também que em casos de maior complexidade acaba sendo difícil e pouco eficiente escrever testes antes da codificação do sistema em si e isso acaba sendo uma avaliação dinâmica ao longo do desenvolvimento do software que trataremos caso a caso ao longo do processo.

Enfim, optamos por uma metodologia que possa empregar maior agilidade, flexibilidade e adaptabilidade possível ao longo do processo de desenvolvimento da aplicação proposta neste trabalho.

Entendemos que as metodologias tradicionais, com planejamentos muito densos e alto custo de especificação, não se adaptariam às premissas desse trabalho, pois esse projeto requer mudanças rápidas e pretende ser composto por uma equipe pequena e dinâmica capaz de integrar-se e receber feedbacks constantes dos usuários finais ao longo do processo de desenvolvimento.

O sucesso desse trabalho certamente passa pelo adequado direcionamento da metodologia Extreme Programming, pois pretende que os escassos recursos financeiros a serem empregados sejam otimizados de forma prática e dinâmica com menos tempo gasto na documentação e mais direcionada à interação com os usuários finais do sistema que entendemos como os personagens principais para o êxito desse projeto.