Problemas essenciais no desenvolvimento de software

Algumas características diferem o processo de desenvolvimento de software de qualquer outro produto manufaturado. Essas diferenças, dadas pela própria essência do software, que é uma entidade abstrata, provocam tantos problemas durante o processo de transformar uma idéia em um produto.

Brooks, em seu artigos Essence and Accident in Software Development, trata de questões que sempre aparecem em equipes de desenvolvimento, e que são as principais inimigas dos desenvolvedores.

Assim como Aristóteles na filosofia, Brooks encontra duas classes de problemas enfrentados durante o desenvolvimento: os essenciais e os acidentais. Questões essenciais são aquelas que são inerentes ao processo de software e sempre estarão presentes durante o desenvolvimento. Já os problemas acidentais são aqueles não instrínsecos ao software e que surgem em determinados pontos do projeto. O grande erro, segundo Brooks, é quando se dá mais atenção ao que é acidental, deixando de lado aquilo que é essencial. Falaremos um pouco sobre os problemas essenciais no projeto de software.

Complexidade: Manejar uma entidade abstrata é uma tarefa por si só bastante árdua. A dificuldade de compreender um todo composto por pequenas partes interdependentes contribui para falhas de entendimento e comunicação. Muitas vezes membros de uma equipe têm visões diferentes sobre partes do software, o que gera atrasos e retrabalhos.

Conformidade: O software não depende apenas do desejo de um programador bem intencionado. O projeto deve contemplar as expectativas de clientes exigentes, fazendo jus ao tempo de desenvolvimento e ao custo. Esse é um ponto importante, que se mal observado, pode por um projeto inteiro a perder.

Mutabilidade: O software está em constante evolução. Interesses mudam, objetivos são trocados e por isso o projeto deve estar pronto para evoluir com o menor impacto possível. Projete pensando no futuro, pois logo você estará nele.

Invisibilidade: O fato de o software ser uma entidade abstrata é o responsável pela maior parte dos problemas durante o desenvolvimento. A necessidade de modelos de representação simples e eficientes é prioridade para a indústria do software. Isso nos últimos anos vem sendo bastante buscado e por vezes alcançado, com linguagens de representação como a UML, que promove as mais diversas formas de modelar o projeto.

Tentar superar esses problemas essenciais é o primeiro passo para um projeto de sucesso. De fato outros problemas aparecerão, mas serão acidentes, que podem ser tratados com outros remédios.

Desses acidentes falaremos em outra oportunidade.

Até a próxima!

Modelo de documento de especificação de requisitos

Olá pessoal,

Esse é modelo de documento de requisitos muito completo que encontrei. Segue o link. O texto está em inglês e contempla as principais seções de um documento de requisitos. Vale a pena conferir:

www.processimpact.com/process_assets/srs_template.doc


Até a próxima!

Boas práticas das metodologias ágeis

Muito se tem discutido a respeito das metodologias ágeis de desenvolvimento. A idéia é dar mais ênfase à prática que à teoria, ao sistema que à documentação. Porém em tempos onde a busca de certificações como CMM e MPSBR é grande, metodologias como XP, por exemplo, ainda têm que se adequar para poder competir com os métodos tradicionais nas grandes organizações. Porém, apesar de não integralmente, essas empresas podem adequar algumas das melhores práticas das metodologias ágeis em suas equipes.

• Programação em Pares (Pair Programming): Nesse tipo de desenvolvimento há dois programadores por micro. Alguns podem dizer que essa é uma solução custosa do ponto de vista econômico, mas o fato é o contrário. Dois desenvolvedores juntos significa um código melhor escrito, algoritmos mais eficientes, menor possibilidade de bugs, programa mais manutenível. Além disso, evita-se um problema que ainda ocorre muito: um desenvolvedor responsável por um determinado módulo do sistema sai da equipe. É o suficiente para parar o projeto, já que só ele sabia sobre aquela parte. Com pair programming isso muda, ainda mais com sistemas de revezamento entre duplas, que também ocorre em XP.

• Cliente faz parte da equipe: Geralmente o desenvolvedor tende a ver o cliente como inimigo. Para ele o usuário é aquele que nunca sabe o que quer, que sempre pede coisas diferentes e que provoca mudanças em algo que já estava pronto e funcional. Por isso há a tendência de a equipe de desenvolvimento acabar se isolando do seu cliente, que por sinal é o maior interessado no projeto. Para os métodos ágeis, o cliente é um membro da equipe. Ele participa das reuniões, escreve estórias (requisitos) e faz os testes de validação. Quanto mais próximo o cliente estiver, maiores são as chances de se entregar um produto de qualidade e útil para as necessidades do usuário final.

• O desenvolvedor estima seus próprios prazos: Na divisão de tarefas é o desenvolvedor quem estima os prazos para a conclusão de determinada tarefa. O gerente apenas administra o processo de delegaçaõ das atividades. Caso o prazo estimado seja muito folgado, ou seja, o desenvolvedor terminou antes do prazo, então na próxima divisão de atividades são distribuídas um número maior de tarefas. Caso o tempo estimado seja muito curto, então o número de tarefas será diminuído. É o conceito de Yesterday's weather (tempo de ontem). O tempo hoje provavelmente será parecido com o de ontem. Se ontem choveu, hoje também choverá. Se sobrou tempo antes, então agora também sobrará, e por isso o número de tarefas aumentará para compensar isso.
  

As metodologias ágeis têm propostas bastante interessantes, apesar de necessitarem ainda de ajustes para serem totalmente aceitas pelo mercado. Como tudo na vida, cabe-nos avaliar prós e contras de cada lado e tentarmos criar uma proposta ótima.

Fico por aqui. Até a próxima!

Análise de Requisitos: Funcionais x Não Funcionais

A especificação de requisitos é a tarefa mais importante na fase de análise de um sistema. Requisitos mal especificados produzem dor de cabeça, retrabalho e atrasos no projeto. Aqui vamos ver os principais conceitos relativos aos tipos de requisitos de um sistema.

Os requisitos, de modo geral, pordem ser classificados em dois grandes grupos: os requisitos funcionais e os não funcionais.

O requisitos funcionais são aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema. São o cérebro do projeto, já que descrevem as funcionalidades que o sistema deve dispor.

Os requisitos não funcionais são aqueles que expressam como deve ser feito (não confundir requisitos não funcionais com design). Em geral se relacionam com padrões de qualidade como confiabilidade, performance, robustez, etc. São muito importantes, pois definem se o sistema será eficiente para a tarefa que se propõe a fazer ou não. Um sistema ineficiente certamente não será usado. Neles também são apresentados restrições e especificações de uso para os requisitos funcionais.

Além desses dois, existem ainda os requisitos de interface, que como o nome já diz especifica as funcionalidades inerentes a interface do sistema com usuário.

Muitas vezes é difícil discernir entre quais requisitos são funcionais e quais não são. Essa pática vem com o tempo e com a experiência e, por isso, para quem não trabalha diretamente com análise, é sempre bom exercitar. Vejamos o exemplo:

Requisito:
O sistema deve prover um grid na tela, que permitirá a visualização de imagens. Esse grid poderá ser ativado ou desativado através do clique em um botão. O grid terá uma régua, cuja escala poderá estar tanto em centímetros como em polegadas, que ajudará no redimensionamento das imagens.

Os requisitos não foram especificados da maneira correta no exemplo acima. É o que chamamos de aglutinação de requisitos. Temos então que seprarar requisitos funcionais, não funcionais e de interface. No nosso caso, o maneira correta seria:

• Funcional: O sistema deve prover um grid para a visualização de imagens. Este grid poderia ser ativado ou desativado.
• Não funcional: A escala do grid poderá estar tanto em centímetros com em polegadas.
• Interface: Deve haver um botão responsável por habilitar e desabilitar o grid.
  

O processo de análise é uma das fases mais complexas do projeto de software. Vamos ainda continuar falando sobre o processo de elicitação de requisitos e de análise em geral em próximas ocasiões.

Até a próxima!

Estimativa de prazos e custos com pontos por função

A difícil tarefa de se estimar prazos e custos no desenvolvimento de software pode ser facilitado com o uso de ferramentas matemáticas como a análise de pontos por função. A partir de dados como número de interfaces, entradas e saídas de usuários, linguagens utilizadas, grau de generalidade do projeto, pode-se chegar a valores aproximados de custos e tempo para um projeto de software.

Alguns links com planilhas e mais informações sobre análise de pontos por função:

• Planilha com análise AFP de projetos (em inglês)
• Grupo Brasileiro de Usuários de Pontos por Função
  

Até a próxima!

Reusabilidade com Orientação a Objetos

Um conceito muito importante no processo de desenvolvimento de software é a reusabilidade. Precisamente a reusabilidade de código.

Antes da disseminação da OO, pouco se falava nessa questão. Os softwares costumavam ser muito acoplados e pouco coesos, tornando a manutenção uma tarefa penosa. As funções estavam espalhadas por todo o código de maneira desordenada e, muitas vezes, repetida.

O paradigma da orientação a objetos vem justamente solucionar os principais problemas da programação estruturada.

• Objetos: São a base da programação OO e já têm algum nível de reusabilidade. Têm uma interface com o meio externo e através dela acessamos seus atributos.
• Herança: Quando utilizamos herança, temos um alto grau de reusabilidade do código. As classes filhas não precisam reimplementar os métodos e atributos já presentes na classe pai. Isso de certa forma é muito bom, já que escrevemos o código apenas uma vez e o utilizamos em contextos diferentes.
• Interfaces: A herança apresenta algumas limitações de uso, e além disso, aumenta o acoplamento do sistema. Como alternativa, temos as interfaces, que propõem um contrato entre as classes que as implementam. Interfaces aumentam a coesão do sistema, além de simularem perfeitamente o uso da herança.
  

O uso da herança e de interfaces deve ser encorajado a fim de se obter o máximo de reuso do código. Além disso elas fornecem as ferramentas necessárias ao polimorfismo, que consiste em referenciar-nos de uma única maneira a objetos de classes diferentes, desde que eles implementem a mesma interface ou herdem uma classe comum. Além desses tópicos, a reusabilidade atinge seu grau mais alto em sistemas OO com o uso de frameworks e padrões de projeto, mas esses são temas para outra oportunidade.

Por enquanto, ficamos por aqui! Até a próxima!

Produtividade no desenvolvimento de software

A questão da produtividade de uma equipe de desenvolvimento é de extrema relevância para a análise de um projeto, já que ela define entre outros fatores, o seu prazo e o seu custo. Por que é tão difícil estimar com precisão o tempo de um conjunto de atividades?

Geralmente a experiência conta muito para a definição de prazos e metas reais e concretas. Porém deve haver variáveis menos subjetivas que essa para se alcançar o sucesso em um projeto.

O maior erro ao se estipular prazos é o caráter teórico da avaliação.

Sabe-se que um programador tem uma produtividade média X. Multiplica-se isso pelo número de programadores e, pronto, tem-se a produtividade do conjunto e, portanto, o tempo de projeto.

Essa abordagem apesar de simples e aparentemente lógica, não conta com a interferência de fatores cotidianos que terminam provocando atrasos, como reuniões da equipe, doenças e possíveis afastamentos de funcionários, membros que entram e que saem, além das mais diversas interações dentro do grupo. Tudo isso deve ser levado em consideração durante o processo de análise.

Outro fator que limita a fixação de prazos mais apertados é a questão do nível de complexidade do projeto. Estatísticas mostram que a produtividade para o desevolvimento de um SO, por exemplo, é cerca de duas vezes menor quando comparada com sistemas tradutores. Prestando atenção, percebe-se que projetos de grande porte têm dois fatores negativos quanto à produtividade: a própria complexidade do sistema, e o grande número de membros do grupo, que gera mais interações entre a equipe, que por sua vez diminui a produtividade geral.

A maioria dos dados relativos à produtividade existentes referem-se a projetos desenvolvidos em linguagem Assembly, nos quais ela é medida em instruções por indivíduo em um ano. Mas algumas pesquisas realizadas com linguagens de alto nível já mostram que a produtividade aumenta cerca de cinco vezes em relação à linguagens de baixo nível, já que cada linha de código em linguagem alto nível correponde, em média, a cinco instruções assembly.

Portanto, apesar de complexa, a análise de produtividade pode ser aproximada dos níveis reais a partir de estimativas mais práticas e mais concretas, levando em consideração os mais diversos fatores que limitam a produtividade da equipe. Além disso, a avaliação do uso de uma linguangem de alto nível adequada pode proporcionar níveis ainda maiores de produtividade.

A importância de um estudo de viabilidade

Todo projeto de software, em sua fase inicial, deve ser submetido a uma rápida análise panorâmica sobre o problema. Esta etapa de desenvolvimento é chamada de estudo de viabilidade.

É o estudo de viabilidade que determinará pontos críticos do seu projeto, diferentes alternativas de soluções para o problema e, até mesmo, se o projeto será levado adiante ou não.

O estudo de viabilidade consiste, na prática, de um documento com formato mais ou menos definido que descreve de maneira geral o problema a ser tratado, a organização para a qual se destina o software, e as mais variadas soluções acompanhadas de análises comparativas entre elas.

A estrura básica de um documento como este é composta por uma breve descrição sobre a organização que o contratou para desenvolver a solução, o problema em questão, fontes e referências que lhe proporcionaram conhecimento do problema (questionários, bibliografia, etc), além, é claro de mais de uma solução para o problema. Cada uma, acompanhada de uma breve análise com prós e contras. Ao final do documento, o desenvolvedor, a partir da análise de cada uma das soluções por ele propostas, indica qual a mais adequada, levando em cosideração fatores como custo, tempo de desenvolvimento, satisfação dos anseios do cliente, etc.

Para empresas de desenvolvimento de software, o estudo de viabilidade já é um procedimento padrão no processo de design, do qual depende todo o restante do projeto. Porém, o pequeno desenvolvedor, ou o famoso "freela" deve estar se perguntando como isso afetaria seu trabalho de maneira positiva. Para ele, isso não seria apenas um desperdício de tempo e dinheiro?

A resposta é não. Com certeza, por mais breve que seja um estudo de viabilidade ele leva um certo tempo para ser feito e consome algumas horas preciosas de trabalho. Porém os benefícios trazidos são maiores. Com uma análise prévia, o desenvolvedor terá uma visão mais abrangente sobre o problema e poderá congitar diversas soluções. A partir do estudo destas soluções, ele terá a melhor proposta tanto para ele quanto para o cliente. Imagine você chegar no meio de um projeto, e decobrir que havia uma maneira mais fácil e mais eficiente para chegar ao mesmo resultado? Com certeza seria frustrante. Além disso, com um documento como este sendo entregue ao cliente, você com certeza terá seu trabalho mais valorizado e se destacará num mercado que anda a cada dia mais concorrido.

Desenvolvimento ágil com XP

Extreme programming (XP) é uma metodologia de desenvolvimento de software que difere principalmente dos métodos tradicionais por visar a adaptabilidade do sistema, em vez de previsibilidade normalmente utilizada. Defensores de XP afirmam que a capacidade de um software se adaptar a novos requisitos durante o desenvolvimento promove uma melhoria no processo, ao contrário das metodologias não ágeis, que defendem a inserção de todos os requisitos na fase de concepção do projeto. De acordo com XP, prever requisitos antes mesmo de existirem é , na verdade, um fator gerador de perda de recursos, uma vez que estes próprios requisitos previstos podem ser alterados no decorrer do desenvolvimento.

A metodologia está baseada em alguns valores que definem métodos de interação e trabalho entre os membros da equipe e o cliente. São eles: a comunicação, a simplicidade (marca das metodologias ágeis), o feedback, a coragem (muitas vezes é necessário jogar fora muito trabalho para dar lugar a novos requisitos) e o respeito (último valor incorporado à essa lista, que visa gerenciar as relações humanas dentro do grupo).

As atividades básicas dentro da extreme programming são a de codificação, testes, o projeto - apesar de contrariar um pouco as premissas de desenvolvimento ágil, às vezes é necessário de acordo com a magnitude do projeto - e, por último, o ouvir, que é um fator imprescindível para o sucesso de um projeto de software.

Gradativamente, com um pouco de resistência até, a XP vem sendo incorporada à projetos de vários segmentos. Como qualquer outra metodologia, tem seus prós e contras que devem ser pesados durante a análise. Além disso, também vem sendo amadurecida e aperfeiçoada a fim de que seja uma opção para pequenos e grandes projetos.