Marketing para Empresas e Profissionais de Software.
Curso online de Ajax e PHP como linguagem de servidor

Repensando o desenvolvimento de software

Ramos de Souza Janones

Janones, é um empreendedor brasileiro apaixonado por empreendedorismo e tecnologia. Ao longo dos anos trabalhando com o desenvolvimento de softwares desktop desde a linguagem Clipper, passando pelo Delphi e atualmente com Java.

Optou pela formação de Publicidade e Marketing por sua segunda empresa de tecnologia ter participado do "boom" da internet nos anos 90 e na procura de melhorar seus conhecimentos em negócios.

Em razão da principal formação e profundos conhecimentos em programação e banco de dados, é capaz de realizar o desenvolvimento de aplicativos web, desktop e mobile com maior criatividade e inovação que profissionais de desenvolvimento com uma formação única e mais especifica, dedicada somente ao desenvolvimento de softwares.

Com toda sua experiência com empresas de software, sua formação e paixão por negócios escreveu o livro "Marketing para Empresas e Profissionais de Software", publicado pela editora carioca Ciência Moderna em 2012. Além de outros livros sobre programação.

Fonte: www.webinsider.com.br

Por que falham tantos projetos de criação de software? A metodologia tradicional de desenvolvimento de software, mais usada hoje, perde terreno para a utilização de metodologias ágeis inovadoras.

Por Dyego Luz

Para início de conversa, farei uma introdução de como se desenvolve software hoje e apresentarei a metodologia que solucionará grande parte dos seus problemas durante a criação de uma aplicação.

O objetivo é que você conheça os problemas da metodologia de desenvolvimento de software mais usada atualmente. É de extrema importância que você dedique um tempo para perceber o porquê da necessidade de repensar o desenvolvimento de software tradicional e utilizar metodologias ágeis inovadoras.

Aceitar uma mudança de paradigma como a que será introduzida no final deste artigo exigirá bastante coragem de sua parte.

Pois bem, vamos ao que interessa. Antes de começarmos a discutir e refletir sobre qual a melhor forma de desenvolver softwares de qualidade e de maneira produtiva é preciso buscar uma resposta para a uma pergunta que frequentemente tem voltado à tona: por que uma grande porcentagem dos projetos de criação de softwares falham?

Modelo em cascata

Para chegar a uma colusão definitiva vamos analisar como a maioria dos softwares é desenvolvida hoje em dia. O modelo de desenvolvimento mais utilizado atualmente é conhecido como “modelo em cascata”. Ele funciona de forma puramente sequencial através da distribuição de tarefas específicas para pequenas equipes envolvidas no projeto.

Essa metodologia se parece bastante com a utilizada nas grandes fábricas, principalmente após a revolução industrial.

Apesar de não parecer, isso é um grande problema. Não é porque deu certo no processo industrial que dará certo no desenvolvimento de software. Outro erro comum é pensar na criação de um software como um procedimento de fabricação, criando a idéia da “fábrica de software”.

Para comprovar a total diferença entre como deve ser o desenvolvimento de software e como é o processo de fabricação nas indústrias do mundo todo, vamos entender como funciona o processo industrial.

Assim como no modelo em cascata, as fábricas utilizam a ideia de produção sequencial e divisão de tarefas específicas para cada profissional. Ou seja, em uma fábrica de tecidos esse processo funcionaria da seguinte forma: primeiro seria selecionada a matéria prima, depois feita à pintura, o corte e assim sucessivamente.

Para cada etapa de produção, existem profissionais capacitados para fazer um trabalho manual. Esse trabalho é basicamente mecânico, ou seja, ele aprendeu a fazer e simplesmente o faz. Ele não necessita sempre de um esforço intelectual constante para isso.

É manual ou intelectual?

Dessa forma, também acaba acontecendo no modelo em cascata. Já da pra imaginar onde está o problema no fracasso da maioria dos softwares produzidos nesse modelo. Partindo do principio de que o processo de fabricação não necessita de um trabalho intelectual e sim de um trabalho mais manual, vamos refletir se o processo de desenvolvimento de software é manual ou intelectual.

Quando se desenvolve um software seguindo esse modelo tradicional em cascata, os desenvolvedores ficam limitados a fazer o que foi definido por uma analista anteriormente. Isso torna o trabalho do desenvolvedor algo mais manual do que intelectual, o pode atrapalhar bastante.

Desenvolver software está mais ligado a ideia de desenvolver um livro, uma obra de arte do que produzir tecido. Portanto, deve ser um trabalho bem mais intelectual do que manual.

Talvez isso ainda não seja suficiente para te convencer de que esse modelo pode gerar muitos problemas, então vamos aprofundar um pouco mais.

O desenvolvimento em cascata é dividido em etapas sequenciais conhecidas como análise de requisitos, projeto, implementação, integração, teste e depuração, instalação e manutenção de software.

Vamos analisar, de maneira resumida, cada etapa e os problemas que elas podem causar no produto final.

Análise de requisitos

Vamos iniciar pela primeira etapa, a análise de requisitos. Nessa etapa o cliente apresenta suas necessidades para a equipe de análise que decidirá as funcionalidades do sistema. É quando o primeiro problema já aparece. Normalmente o cliente apresenta algo completamente abstrato como: “Eu quero uma loja online”. A partir disso os analistas é que decidirão quais funcionalidades essa tal loja terá.

Todos sabem que os clientes nunca pensam em necessidades da forma como analistas pensam. Ou seja, o sistema terá funcionalidades que para o cliente não são tão necessárias, assim como não terá as funcionalidades que são realmente necessárias ao cliente.

O projeto

Segunda etapa, o projeto. É exatamente nessa etapa que começa um dos maiores problemas desse modelo – a falta de comunicação. O processo de desenvolvimento vira um verdadeiro telefone sem fio.

Durante essa etapa, os projetistas irão documentar o sistema pelo que receberam dos analistas. Surge outro problema. Quase sempre a análise feita pelos analistas não é suficientemente concreta para fazer com que os projetistas criem uma documentação realmente significativa de como o sistema deverá funcionar.

Implementação

Chegamos à terceira etapa, implementação. Aqui começa o estresse. Os programadores recebem a documentação dos projetistas e começam a criar as funcionalidades. Mais um problema. Os programadores desenvolvem todo o software com base em um documento (já bem diferente do que o cliente gostaria). Mas não para por ai. Pela falta de comunicação que existe entre o cliente e o desenvolvedor, o software termina se tornando algo totalmente diferente do que o cliente imagina que receberá no final do projeto. Ele não ficará nem um pouco feliz em saber que todo o dinheiro que investiu está indo pra lata do lixo.

Integração

Quarta etapa. Como os programadores se dividem para desenvolver partes diferentes do software, é necessário que exista uma etapa só para integrar essas partes. Encontramos outro problema. Programadores pensam diferentes e geralmente tem dificuldade em se comunicar bem com outros programadores por medo de ter um código ruim ou se mostrar inexperiente em determinadas áreas. Isso, além de ser uma bobagem, é preocupante na hora de integrar o sistema e pode gerar códigos difíceis de reutilizar. Além disso, pode criar as chamadas ilhas de conhecimento na equipe, onde alguns programadores conhecem bem uma parte do código, mas não conhecem nada sobre a outra parte. Imagine se um sair da equipe de repente.

Teste e depuração

Em fim chegamos à quinta etapa. Tirem as crianças da sala. Esta é a etapa mais complicada, chata e preocupante nesse modelo de desenvolvimento. Testes e depuração. É nessa parte que as maiores dores de cabeça começam a surgir em toda a equipe. A partir de agora é só problema, problema e problema. Nesse modelo de desenvolvimento o custo de alteração aumenta exponencialmente a cada minuto que passa e para chegar a esta etapa já se passaram muitas e muitas horas, dias ou meses.

Como o sistema foi todo desenvolvido sem testes, só agora aparecem os erros. Acreditem, eles muitas vezes não são corrigidos. Isso quando os projetos já não fracassaram antes dessa parte. O porquê disso é fácil de explicar.

Quando se tem milhares de linhas de código, corrigir um erro pode levar meses ou até anos. E como tempo é dinheiro, no desenvolvimento de software isso se torna muito custoso. Para que você possa entender melhor, seria como se você criasse um ônibus espacial e quando fosse testar ele explodisse por culpa de um simples parafuso.

Não é necessário comentar as outras etapas, já que na maioria dos casos os projetos nem chegam nelas. Acabam fracassando na etapa de testes.

A solução?

Qual a solução para que isso não aconteça?

Você não deve se limitar a esse modelo de desenvolvimento só porque ele é o mais usado. Ao contrário, você deve abrir a sua mente para conhecer e estudar novas metodologias de desenvolvimento de software com qualidade e de forma produtiva. Ainda discutiremos muitos sobre essas metodologias ágeis.

Para quem se interessou em se livrar desses problemas e desenvolver softwares de qualidade, acompanhem os próximos textos. Em breve estarei postando sobre eXtreme Programming ou simplesmente XP, uma metodologia de desenvolvimento ágil com valores na comunicação, simplicidade, feedback e coragem.

XP parte do princípio de que desenvolver software de qualidade está totalmente relacionado com a comunicação entre o cliente e o desenvolvedor, além de buscar encurtar o espaço de tempo entre a codificação e a entrega das funcionalidades, tentar fazer todos trabalharem em todo o código, entre outras características.

Uma característica do XP que pode deixar você um pouco confuso no início é conhecida como TDD – desenvolvimento guiado por testes.

TDD consiste em criar testes antes de desenvolver. Como assim? Vou testar algo que ainda não existe? Exatamente.

Primeiro são criados os testes de cada funcionalidade ainda não existente. Logicamente elas vão falhar. Aí entra o desenvolvedor para criar um código suficiente para que o teste valide e passe. Com isso você consegue códigos melhores, mais simples, com menos linhas e que fazem apenas o necessário, diminuindo em 90% a probabilidade de erros futuros.

Ufa… Se você foi guerreiro e chegou ao final deste texto enorme, parabéns. Provavelmente você deve ter ficado bastante curioso para conhecer mais sobre as metodologias ágeis. Mas seria querer demais que você aprendesse tudo isso de primeira.

Por isso nos próximos textos vamos apresentar uma metodologia de desenvolvimento ágil capaz de desenvolver, em apenas três meses, softwares que costumam ser desenvolvidos em três anos. Pois é, o tal do Extreme Programming é capaz de ajudar a realizar façanhas como essa. Aos poucos vamos ver outros detalhes do XP, para não tornar o assunto muito confuso.

Acompanhe, vamos tentar explicar como o XP funciona e, dessa forma, ajudar você a eliminar de vez a probabilidade de fracasso no seu projeto. XP vai mudar sua vida profissional para melhor. Acredite! [Webinsider]

Compartilhe.

PinIt
Profile photo of Ramos de Souza Janones

About Ramos de Souza Janones

Janones, é um empreendedor brasileiro apaixonado por empreendedorismo e tecnologia. Ao longo dos anos trabalhando com o desenvolvimento de softwares desktop desde a linguagem Clipper, passando pelo Delphi e atualmente com Java.Optou pela formação de Publicidade e Marketing por sua segunda empresa de tecnologia ter participado do "boom" da internet nos anos 90 e na procura de melhorar seus conhecimentos em negócios.Em razão da principal formação e profundos conhecimentos em programação e banco de dados, é capaz de realizar o desenvolvimento de aplicativos web, desktop e mobile com maior criatividade e inovação que profissionais de desenvolvimento com uma formação única e mais especifica, dedicada somente ao desenvolvimento de softwares.Com toda sua experiência com empresas de software, sua formação e paixão por negócios escreveu o livro "Marketing para Empresas e Profissionais de Software", publicado pela editora carioca Ciência Moderna em 2012. Além de outros livros sobre programação.

Curso online de Aprendendo Linux: Fundamentos

Comentários

3 thoughts on “Repensando o desenvolvimento de software

  1. Agenor Luiz Gonzaga

    Concordo com o Dyego quanto ao Dephi XE que evoluiu muito, mas está faltando muito de suporte (artigos, livros, etc) principalmente para quem não sabe ingles (o que até no delphi 7 esta documentação era muito farta).
    Estou tentando migrar os meus sistemas do delphi 7 para o xe e encontrando muitas dificuldades por falta de material explicativos.
    Digite delphi xe no google e veja o que voce encontra! quase nada!!!
    A Embarcaderro, se quer vingar o delphi XE, vai ter que pensar nisto.

  2. clayton fernandes

    dyego, gostei de seu artigo. Pouquíssimos desenvolvedores têm alguma ideia de como chegar ao fim em um projeto. Muitos consideram que conhecer Oracle é o suficiente.

    Contudo gostaria de sua opinião sobre o compilador Delphi. Sempre programei neste ambiente, mas me parece que estou ficando sozinho.

    Você começaria um novo projeto em Delphi?

    Abraços

    • Profile photo of Ramos de Souza JanonesRamos de Souza Janones Post author

      Olá Clayton,

      O Delphi realmente ficou um período digamos “nebuloso”. Com a aquisição da Embarcadero as novas versões desde então e o que prometem vir por ai deu uma “ressucitada” no Delphi. Hoje, por exemplo, não iniciaria um projeto em Delphi 7 de jeito nenhum – que é a versão que a grande maioria ainda usa. Mas isso dependende da estratégia e objetivos de cada empresa ou profissional. Como nosso objetivo hoje é a Web e Smartphones, o Delphi XE 2 já atende boa parte do que necessitamos muito bem e a promessa das futuras versões iriam 100% de acordo com nossas estratégias. Há muitas empresas que estão presas em versões anteriores – seja pelo software ser muito grande para uma migração; seja por estratégias da própria empresa.

      Hoje os melhores salários são pra Java e Oracle e quem procura emprego vai focar nestas duas tecnologias, sem dúvidas e não censuro. A definição das tecnologias baseam nas estratégias de cada empresa e/ou individuos. Aqui utilizamos diversas linguagens de programação, para os mais variados tipos de aplicativos. Acreditamos que hoje isso é fundamental, mas tendo uma linguagem que seja padrão – no nosso caso o Delphi, principalmente depois do lançamento do XE2.

      O interessante de utilizar diversas linguagens é poder ter um conhecimento maior sobre qual tecnologia fica mais fácil em um determinado projeto. Um exemplo: O desenvolvimento de aplicativos para celulares. Existem diversos sistemas operacionais e pra cada uma linguagem específica: O Android com o Java, o iPhone com o Objective-C, etc. Mas há frameworks que permitem com uma única linguagem desenvolver para todos: O Delphi XE começou a adotar o Mono Project que permite compilar pra vários sistemas operacionais, existem excelente outros frameworks em C# ou C++ que também permitem isso. E é a grande tendência do momento e a Embarcadero está mirando.

      Concluindo: Sim, o Delphi é uma excelente linguagem de programação, principalmente na sua última versão.

Comments are closed.