Tag: software coom qualidade

Conceitos da Construção Civil na Construção de Softwares

Introdução

Uma coisa que gosto de citar é que a construção de software não é uma “arte”; a construção de software é um produto da engenharia e funciona como na construção civil, ou seja: podemos prever e acompanhar o andamento de suas etapas.

Mas por que ‘prever e acompanhar o andamento de suas etapas’ nem sempre é possível na construção de um software ?

edificacoes

Construção Civil

A grande sacada na construção civil é que muito antes do seu início (na maioria da vezes) temos um escopo bem definido, o proprietário já definiu o quanto deseja gastar, o engenheiro ou empreiteiro lhe repassa se é possível ou não fazer aquela obra com aquele valor e no tempo desejado.

Após algumas reuniões, ambas as partes entram em acordo com as definições completas do projeto, como quantidade e tamanho dos cômodos, qual material será utilizado, tempo de entrega e todos os stakeholders sabem que qualquer alteração feita no escopo pode acarretar em alteração no valor ou no prazo de entrega e que isso refletiria no custo e prazo de entrega da obra.

A aprovação do projeto por parte dos donos ou responsáveis é fácil porque antes de iniciar já foram demonstradas as plantas baixas e já se sabe como será a área construída.

Para isso são dispostas maquetes do projeto e em alguns casos utiliza-se até de renderização 3D para montar maquetes virtuais.

Isso já deixa bem fixado na mente do cliente qual será o resultado final de seu produto.

Depois de tudo definido antes de se iniciar as obras são preparados os materiais a serem utilizados em cada etapa.

Existe a preparação do terreno, onde serão feitas as primeiras estruturas – os fundamentos – para que seja de fato realizada a construção.

Essa estrutura é sempre construída de forma cautelosa, pois é sobre ela que tudo será construída e é ela que limitará muitas coisas no projeto e fará com que essa edificação não venha a desabar.

Construção de Software

software

Se olharmos bem como uma edificação é construída, vamos ver que esses conceitos são básicos e funcionam de forma são eficiente. Para uma construtora a não entrega de um projeto no prazo acarreta perda de dinheiro e isso talvez seja  pior comparado à má reputação da empresa diante dos clientes.

Agora os softwares em sua maioria das vezes não são bem definidos ou quase nada definidos, começam como uma idéia que é iniciada pelo programador e sofre alterações ao longo do tempo até chegar no produto do cliente, que nem sempre é o que ele desejou, fora os problemas encontrados no meio do caminho devido a problemas técnicos que não foram previstos.

Imagine se uma obra inicia-se dessa forma, uma idéia de construir uma casa mais ainda não se sabe como vai ser quantos cômodos e tal ? seria um caos, existiria muito dinheiro perdido, paredes quebradas, tempo investido sem necessidade e o final disso seria uma catástrofe, uma  parede mais alta que a outra, pisos quebrados, de cores diferentes..

Bom, é assim que os softwares são construídos e assim que eles ficam.

A diferença é que toda essa bagunça é coberta pela “linda” interface gráfica que é disposta para o usuário, porem devemos ser sinceros: em muitos casos o software não faz exatamente o que o cliente pediu ou que ele realmente precisa.

Existem inúmeras funcionalidades que ele não utiliza.

Ao iniciar o projeto o cliente ainda não sabe o que ele terá de resultado fazendo que suas expectativas sejam altas com o projeto, ainda mais se ele for “salgado”($$).

Outra coisa que ocorre é que muitas vezes não só o cliente, mas também os desenvolvedores não sabem seu resultado final e muitas coisas são criadas na “tentativa e erro”;  sua estrutura é criada de forma singular e faz com que o projeto nem sempre suporte todos os itens que devem ser adicionados, causando assim problemas técnicos na implementação de novas funcionalidades no futuro, pois sua base não foi construída para suportar suas verdadeiras necessidades.
Construção Civil vs Construção de Softwares

Sabemos que os conceitos da organização da construção civil são eficientes e fáceis de se implementarem, se formos reparar veremos desde pequenos a médios projetos sendo implementados por “mestre de obras”, que na sua maioria das vezes são pessoas com pouco estudo, mas os projetos implementados por essas pessoas são eficientes e entregues com qualidade e no prazo.

Qual a dificuldade de implementar esses processos no desenvolvimento de softwares ?

Vamos pegar como exemplos obras de pequenos portes e comparar com desenvolvimento de pequenos softwares

  1. Falta da clara definição de todo o escopo do projeto
    Na construção civil sempre existe uma definição de o que se deseja no final.
    Na construção de softwares em muitos casos se desenvolve a pedido do cliente e existe a velha história do “vamos vendo no que vai dando”.
  2. A disponibilidade no tempo hábil dos recursos
    Na construção civil sabemos que antes de começar a obra existem caminhos de areia, pedra, cimentos ou qualquer outro material que são deixados no local.
    O mestre de obra faz a conferência e após a confirmação do material adequado inicia o trabalho e em alguns casos pode ocorrer de nem todo o material ser disponibilizado no inicio, mais isso é um risco que o mestre calcula e se prepara para que o restante do matéria esteja disponível logo que necessário.
    Na construção de softwares vemos muito a iniciação de um projeto sem nenhum tipo de recurso adequado, há casos que esses recursos nem foram calculados e são disponibilizados sobre demanda e na maioria das vezes em tempo tardio.
  3. A adequada utilização de ferramentas é um ponto essencial
    Na construção civil  todos esses recursos são disponibilizados antes de sua real utilização, assim não atrasando o projeto
    Na construção de softwares as ferramentas não são pensadas, nem sempre são as adequadas e nem sempre estão disponível na hora necessária.
  4. Definição de papel 
    Na construção civil  temos três papeis bem definidos: servente ou ajudante, o pedreiro e por fim o mestre de obra.
    Os serventes tem o papel fundamental de fazer os serviços mais braçais e “servir” ; o pedreiro é o responsável por executar tarefas mais especializadas e tem um maior conhecimento e mais tempo de obra, porem não executam tarefas simples pois sua mão de obra é mais cara e seria um desperdício de dinheiro colocar um pedreiro para puxar massa, e por fim temos o nosso “mestre de obra” responsável por coordenar toda a obra, não deixar ocorrer a falta de matérias, controlar o tempo e os gastos.
    Na construção de softwares  em sua maioria apenas dois papeis: os programadores e gerente do projeto, para um software pequeno raramente vamos ter o papel de analista de sistema.
    O programador podemos comparar com o pedreiro o papel dele seria fazer serviços especializados porem vemos que no desenvolvimento de softwares não temos a figura de uma auxiliar ou o servente que seria o responsável por fazer o trabalho “pesado” e fazer com que o programador não perca tempo em soluções simples e até mesmo perca tempo tendo que “carregar o tijolo”, ou seja isso pode ser considerado como uma deficiência, pois os programadores tem que se preocupar em fazer todo o trabalho e muitas das vezes de forma desordenada fazendo com que o foco seja perdido, já o gerente tem o papel semelhante ao mestre de obra, deve ser responsável por controlar coordenar a equipe, prazos e insumos do projeto.
  5. Planejamento
    Na construção civil o responsável pela obra consegue se planejar de forma eficaz dos prazos para cada etapa da obra, assim se um dos prazos não forem cumpridos ele sabe se a obra vai se atrasar num todo e antes disso ele consegue reverter essa situação. Existem um acompanhamento no mínimo semanal do andamento da obra e posso dizer que ele sabe com exatidão se esta no prazo ou não. Outra coisa impressionante é que a obra tem documentação, por menor que seja existe um mínimo de documentação, seja ela a planta baixa do projeto ou um rascunho onde sofreu a aprovação do cliente.
    Na construção de softwares nem sempre existe um planejamento, tudo é feito de forma desorganizada e nem sempre priorizam-se as reais necessidades. Outra coisa é a falta de documentação: não são gerados nem rascunhos de como o projeto deve ser.

Conclusão

Existem outras inúmeras razões para os processos da construção civil serem mais eficientes do que os processos da construção de software e que não serão abordadas nesse artigo.

Porém,  é interessante saber que são processos simples: à ponto de serem feitos de forma transparente sem a necessidade de tanta “burocracia”, ou que essa burocracia não seja sentida pelos seus participantes. São processos de certa forma organizados “naturalmente”, tão “simplórios” que os participantes desse processo em muitos casos não tem a necessidade de sequer ter uma quarta série do ensino fundamental, e a inclusão de um novo participante no processo é simples e natural.

Torço para ver o dia em que o processo para a construção de um software seja tão ou mais organizado que o processo para a construção de um edífício

 

Gutierry Antonio Neto Pereira

No Code Squad ministra os seguintes treinamentos:  http://code-squad.com/perfil/gutierryantonio.netopereira#cursos-ministrados

Gutierry Antonio Neto Pereira – Engenheiro de Software Experiência em desenvolvimento com visual Fox Pro, Delphi, Ruby on Rails, Action Script 3.0 , nos bancos de dados Firebird, MySQL, gerencia de projetos de software e aplicação de métricas de software. Conhecimentos nas linguagens de programação Java, C# e C++, no banco de dados SQL Server.Participação de desenvolvimento de Framework em Delphi para desenvolvimento de softwares, desenvolvimento de framework para importação e exportação de dados entre banco de dados e Framework para BI.

Twitter

Desafios do Projeto de Software

Este artigo é baseado em uma parte do quinto capítulo do livro Code Complete, por McConnell, 2ª edição

Esse foi um dos melhores livros que eu li sobre criação de software, cujos princípios não entram em obsolescência com o passar do tempo, ao contrário das implementações das linguagens de programação.

McConnel sabe o valor da metáfora no mundo abstrato da programação de computadores.

Ele inclusive trata disso em seu livro.

Eu também sou um grande adepto da metáfora como ferramenta de comunicação.

Sem metáforas, fica muito difícil discutir arquitetura de software.

Falar sobre milhares de linhas de código para uma equipe com a limitada capacidade de retenção de informação que temos não é prático.

Uma das primeiras metáforas que McConnel propõe é a de comparar a criação de sistemas de informação com a construção de edificações.

É melhor do que a métafora da escrita de documentos, pois leva o ouvinte ou leitor a imaginar (um real) esforço na criação de software.

Construir software não é uma tarefa fácil, pois há muitos desafios que tem de ser superados a cada projeto.

Mais do que otimizar algoritmos, é preciso organizar o software, para mantê-­lo funcionando depois que ele for colocado em produção.

128345994_e037b5a511_z

Segundo McConnel, o problema de software é um problema perverso!

Isso não quer dizer que os problemas que envolvem a construção de software são criados por supervilões.

Isso significa que você precisa resolver o problema uma vez para defini­-lo claramente, depois resolvê­-lo mais uma vez para criar uma solução que funcione.

O que implica dizer que você só irá compreender realmente o negócio que o software implementa depois que implementá-­lo pela primeira vez.

Não que a primeira versão só software seja errada, que não faça o que o cliente pediu.

Ela pode atingir os objetivos mas de uma forma inadequada.

E essa inadequação só será percebida quando uma modificação for solicitada e você perceber que é extremamente difícil modificar seu software.

E essa dificuldade só aumenta a cada novo lançamento.

Por mais planejamento que haja em um projeto de software, ele só controla o atendimento ao requisito e não o código que o implementa.

O código que implementa um requisito pode se dividir em várias funções ou classes, o que não permitirá ter conhecimento completo, com um simples olhar, de como o requisito é implementado em detalhes.

imagem-artigo-flavio-livro

Além disso, ocorrem bugs no software. E eles são corrigidos. E as correções geralmente aumentam a quantidade de código.

Como as correções geralmente são feitas de forma emergencial, elas não são implementadas da melhor forma possível e isso causa degradação do código.

Um código degradado é um código difícil de manter e que contém operações inúteis ou desnecessárias.

Após perceber que o código está degradado, geralmente quando você já não consegue mais entender o que o código faz, é necessário reorganizá-­lo, para torná-­lo compreensível e remover o que não é mais necessário.

E eventualmente corrigir um bug que paradoxalmente foi introduzido pela correção de outro bug.

Por isso o processo de software é um processo desordenado (mesmo que conduza a um resultado ordenado).

Você comete vários erros até distinguir a diferença entre uma solução boa e outra ruim.

Isso é natural quando precisamos entregar uma funcionalidade no prazo ou corrigir um bug de um dia para outro.

Você naturalmente age nessas condições como alguém que tem de fugir de alienígenas zumbis e precisa ligar o motor do primeiro carro que encontrar.

Você nem procura a chave, já faz uma ligação direta, porque sua vida depende disso.

Mesmo quando criamos software com tempo para planejamento, podemos não compreender realmente o contexto dos problemas a serem resolvidos, pois nossa visão é limitada.

E isso não é nenhum sintoma de burrice, é tão somente uma consequência da falta de experiência.

A compreensão de um problema às vezes exige a experiência de ter resolvido outro.

Isso é algo natural na ciência. A compreensão do átomo, por exemplo, foi sendo ampliada conforme os instrumentos de observação foram aperfeiçoados e os pesquisadores tinham conhecimento anterior para estender.

A solução de um problema em software só irá se revelar ruim se você tiver implementado essa solução.

Não é possível corrigir ou aperfeiçoar o que não existe.

Ao resolver o problema pela primeira vez, você não o compreende direito. Mas após estudar sua solução em funcionamento, o problema fica mais claro, e você percebe o que pode ser melhorado.

Ou seja, não espere que qualquer implementação em software seja definitiva, por mais planejamento que você faça. Ela sempre poderá e precisará ser aperfeiçoada.

Se os programadores de sua equipe não puderem assimilar isso, então Ultron terá razão ao dizer para eles: “Vocês querem salvar o mundo, mas não querem que ele mude”.

A mudança é a única certeza constante.

flisboa

Flávio Gomes da Silva Lisboa
No Code Squad, ministra os seguintes treinamentos: http://code-squad.com/perfil/flaviogomeslisboa#cursos-ministrados

Flávio é Bacharel em Ciência da Computação com pós-graduação em Aplicações Corporativas usando Orientação a Objetos e Tecnologia Java pela Universidade Tecnológica Federal do Paraná. Programador formado pelo Centro Estadual de Educação Tecnológica Paula Souza, já atuou em empresas privadas de TI e foi funcionário de carreira do Banco do Brasil, onde chegou a analista na diretoria internacional.

É funcionário do Serviço Federal de Processamento de Dados (Serpro), onde já trabalhou na Superintendência de Soluções de Desenvolvimento e na Coordenação Estratégica de Tecnologia. Atualmente é chefe do setor de adequação da solução e mobilidade do projeto Expresso 3 na Coordenação Estratégica de Ações Governamentais.

Foi membro do time oficial de tradução do Zend Framework e é autor dos livros: Zend Framework Desenvolvendo em PHP 5 Orientado a Objetos com MVC, Zend Framework Componentes Poderosos para PHP (2ª ed.) e Criando Aplicações PHP com Zend e Dojo (2ª ed.). É associado da ABRAPHP, Zend PHP Certified Engineer, Zend Framework Certified Engineer, Zend Framework 2 Certified Architectcontribuidor oficial do projeto Tine 2.0, suíte livre de comunicação em PHP.

 

 

Twitter

© 2017 Bussola Code Squad

Theme by Anders NorenUp ↑