Não há "bala de prata"

Autor/fonte: Tradução: Christian Reis; Adaptação: Helio Bentzen

Este texto foi baseado no artigo Brooks, 1986, “No Silver Bullet: essence and accidents of software engineering” que afirma não haver um avanço tecnológico que gere uma melhora na produtividade, simplicidade e confiabilidade da construção de software. Apontam-se, ainda, alguns caminhos promissores em desenvolvimento.

Introdução

Há, ainda, hoje, grande discussão em torno de como melhorar a produtividade na construção de sistemas complexos. Há duas partes bastante distintas que constituem as atividades relacionadas ao desenvolvimento do software: atividades essenciais, que envolvem a criação de um modelo conceitual para o sistema, e atividades acidentais, que envolvem a própria implementação do sistema em um programa. O objeto deste artigo é defender que avanços significativos conquistados até hoje foram promovidos em cima das questões acidentais do software, e que ganhos da mesma proporção no desenvolvimento das atividades essenciais são muito mais difíceis de serem alcançados.

Desenvolver softwares é uma difícil tarefa?

A própria natureza do software torna improvável que haja uma solução mágica para os problemas no desenvolvimento de sistemas, como ocorrido na integração eletrônica para a construção de hardwares complexos. Não é que o software evolui muito lentamente; na realidade, o hardware é que evolui muito rapidamente; não há paralelos tecnológicos no mundo com a velocidade da inovação em hardware.

Analisando os pontos inerentes à essência dos problemas no desenvolvimento de software, há os seguintes pontos particulares:

. Complexidade: Há poucos elementos repetitivos e idênticos, e fazer crescer o software envolve muito trabalho além de agregar ou repetir componentes menores. Não há crescimento linear para o software;

. Conformidade: Não há conforto em um princípio unificado. O software, por ser uma criação muito recente, precisa ser adaptado a todo tipo de instituição e sistema já existente;

. Adaptabilidade: Por poder ser alterado muito facilmente, o software sofre pressão por mudança e alteração constante;

. Invisibilidade: O software não é espacialmente representável: não existe um diagrama ou esquema lógico que o descreva. São necessárias muitas representações para conseguir um entendimento visual do sistema.

Conquistas passadas resolvem problemas acidentais

Passando pelas conquistas do passado que promoveram melhoras de produtividade na criação do software, temos:

. Linguagem de alto nível: Embora realmente muito importante na melhora de produtividade, este avanço só tem impacto sobre a complexidade acidental, e não no problema em si;

. Time-sharing: Sistemas modernos resolveram o problema de turnaround que realmente existia com os sistemas de processamento Batch. No entanto, este problema não faz parte do problema essencial ao desenvolvimento de software;

. Ambientes unificados: Bibliotecas integradas e formatos de arquivos unificados fazem, na prática, ser possível integrar estruturas conceituais cujo projeto já previa esta integração, de forma que não resolveram nenhum problema essencial ao trabalho de construir um sistema de software.

Proposições de soluções mágicas:

. Linguagens de alto nível: Não atacam a essência do problema, embora realmente ajudem o desenvolvedor a desenvolver técnicas novas de projetar o sistema;

. Orientação a objetos: Resolvem questões acidentais provendo tipos abstratos de dados e uma hierarquia de tipos. No entanto, não resolvem questões relacionadas à análise ou projeto de software;

. Inteligência artificial: segundo Parnas, O uso de IA não é uma bala de prata, pelo simples fato de resolver problemas muito específicos, e requerer trabalho e criatividade para permitir aplicar uma solução a novas questões;

. Programação automática: Até hoje não se viu algo que passe uma especificação diretamente para código; em geral, se existem, tem aplicação muito específica;

. Programação gráfica: Embora muito de faça analogia com procedimentos gráficos para desenvolver hardware, resta a dificuldade sempre de se visualizar a estrutura conceitual que representa o software. O uso de muitos diagramas é necessário, e isto reduz a eficiência e compreensão da visualização;

. Verificação de programas: Embora realmente tenha impacto sobre teste e validação do software criado, tem alto custo de aplicação, e não resolve o problema da especificação incorreta ou imprecisa;

. Ambientes e ferramentas: O retorno destes avanços será sempre marginal, porque apóia o acidental através de mecanismos de validação de sintaxe e semântica, e apoio a memória do desenvolvedor;

. Workstations: Edição e composição já são adequadamente suportadas pelas velocidades atuais de computadores. A compilação já não é um gargalo significativo ao processo de desenvolvimento.

Ataques promissores à essência do problema

A tarefa é objetiva, melhorar o desenvolvimento de software deve-se atacar os aspectos essenciais do software.

Utilizar componentes prontos

Uma solução boa para a construção é justamente não construí-lo; há já disponíveis grandes quantidades de componentes prontos, tornando muito mais rápido e barato desenvolver. Custos baixos de hardware e a aplicação geral da computação têm levado os usuários a requererem menos soluções customizadas para seus problemas, de forma que software padronizado passa a ser uma alternativa.

Refinar requisitos e prototipação rápida

A tarefa mais difícil é sempre decidir o que construir. Uma técnica excelente para resolver o problema é extrair e refinar iterativamente a funcionalidade do sistema; permitem que os requisitos evoluam, o que é muito mais natural do que forçar os clientes a especificarem sozinhos.

Desenvolvimento incremental

A forma mais natural de se desenvolver é justamente criar um esqueleto inicialmente desprovido de funcionalidade, e adicionar esta funcionalidade incrementalmente. Esta técnica se aplica bem tanto a projetos pequenos quanto a projetos grandes.

Ter bons projetistas

A grande questão de melhorar o processo de desenvolvimento envolve melhorar a qualidade do pessoal atribuído as atividades de desenvolvimento. Bons desenvolvedores e gerentes são raros, mas são o ponto único de maior impacto na produtividade de uma equipe de desenvolvimento.

Bibliografia

Brooks, F. P. (1986), No silver bullet: essence and accidents of software engineering, in H. Kugler, ed., “`Information Processing 86”', Elsevier Science (North Holland), pp. 1069-1076.

Parnas, D. (1985), “Software aspects of strategic defense systems”, Communications of the ACM 28(12), 1326-1335.

LEAN e Desenvolvimento de Software em 2 minutos

Porque não pensar em somar-se qualidade de software aliada às necessidades reais do cliente?

Pode-se dizer que as metodologias tradicionais herdam características das engenharias tradicionais em que se projeta tudo antes para só se construir depois através da mão de obra não intelectual.

Ao se tratar do contexto de desenvolvimento de software, os modelos tradicionais em torno 40% do que é desenvolvido não será utilizado. Já com as metodologias ágeis o foco no desenvolvimento e teste acaba por agregar valor ao cliente, usuário e a organização. Em Metodologias ágeis mudanças são sempre bem vindas.

As metodologias ágeis se caracterizam por serem iterativas, incrementais, auto-gerenciáveis (o programador pode optar por suas preferências), auto-organizável, equipe multifuncional, foco nas pessoas, valor agregado ao cliente, produtos de qualidade. E quando se fala em metodologia ágil é necessário se conhecer em que base circunda sua fundamentação e aí é que falamos como boa parte dessa base de Lean Software Development, que é uma adaptação do Toyotismo.

Em Lean, o modelo é comportamental, ou seja, não exato. Pode-se resumir Lean em uma filosofia de gestão focada na redução de desperdícios (super-produção, tempo de espera, excesso de processamento e defeitos). Só se faz o necessário, o trabalho é reduzido ao essencial e os gastos em desenvolvimento são elaborados de maneira mais prática possível. Se houver erros, elimina-se tudo que não agrega valor. Sua filosofia de trabalho é baseada no empower, ou seja, dá maior poder aos trabalhadores, aproveita-se o limite dos profissionais, dando-se poder à ponta.

Além disso, há as seguintes características: o respeito aos trabalhadores, aumento do total da capacidade da carga produtiva, incentivo aos trabalhadores passando responsabilidade e autoridade.

Simplificando, Lean resume-se a alguns princípios básicos:

1. Eliminar o desperdício
2. Aumentar feedback
3. Comprometimento do tempo
4. Entregas rápidas
5. Construir a integridade do sistema
6. Poder ao time (empower)
7. Enxergar o todo
   

PONG no quadro

Eis o PONG no quadro, um projeto de software 3D da empresa ENESS, da Austrália. O dispositivo pode perceber e reconhecer formas negras interagindo com uma bola virtual.

Leituras Recomendadas em Metodologia Ágeis

As metodologias ágeis baseiam-se em práticas semelhantes às utilizadas no processo just-in-time oriundos do Toyota Way (Liker) da década de 50, cuja característica principal é o feedback. Através delas é possível se gerenciar com eficácia mudanças no escopo do projeto.

Aos interessados em Metodologias Ágeis, eis algumas bibliografias extremamente recomendadas:

The Mythical Man-month de Frederick P. Brooks Jr.
Agile Project Management with Scrum de Ken Schwaber
Extreme Programming Explained de Kent Beck e Cynthia Andres
Peopleware - Productive Project and Teams de Tom DeMarco e Timothy Lister
Managing the Design Factory de Donald G. Reinertsen
Implementing the Lean Software Development de Mary e Tom Poppendieck
Joel on Software de Joel Spolsky
Agile Estimating and Planning de Mike Cohn
Lean Software Development an Agile Toolki de Mary e Tom Poppendieck
Balancing Agility and Discipline - A guide for the Perplexed de Barry Boehm e Richard Turner
Agile Software Development with Scrum de Ken Schwaber e Mike Beed

Outra recomendações em português aqui.

Filosofias da Engenharia

Quatro engenheiros viajavam em um carro, quando de repente o carro parou de funcionar.

O engenheiro mecânico disse:
- O mancal da biela deu jogo, e o pistão atropelou as válvulas.

O engenheiro eletricista disse:
- Nada disso. F uma pane na centralína de injeção eletronica, e não está chegando os 12 volts nos bicos.

O engenheiro químico disse:
- Vocês não sabem nada. I é o combustivél que esta adulterado e baixou o nível de octanagem da gasolina.

Então o engenheiro da computação disse:
- E se agente sair do carro e entrar de novo?

By Cirili

Fragmentos da Revolução Robótica - Parte 2

Em 1921 a palavra "Robô" (que significa "trabalho") foi introduzida pelo escritor tcheco Karel Čapek. Em seu jogo “R.U.R.” (Rossum’s Universal Robots), robô felizes trabalham para os humanos. Essa mudança acarreta no fim da espécie humana devido a uma rebelião hostil dos robôs.

Em agosto de 2008 a Sega Toys lançará o robô “Dream Hamster”, um robô com formato de hamster que se mexe ao tocá-lo. A companhia pretende atingir (japoneses) mulheres de 20 a 40 anos de idade e esperá vender 100.000 unidades por ano.

Notebook de 10 reais

O prenúncio do mal maior

Um Mac instalando Windows.

Service Pack 3

Teclado Ideal para Windows

Atenção: Meu novo blog

Olá pessoal, venho informar que estarei postando agora no www.arrobazona.com

O meu novo blog.

Esse aqui não acabará, mas se restringirá a assuntos mais pessoais.

Abraços a todos.