O “Manifesto para o Desenvolvimento Ágil de Software” foi assinado em 2001 por Kent Beck e outros dezesseis renomados desenvolvedores, que em sua essência, se tratava de um esforço para sanar fraquezas da engenharia de software convencional. Apesar disso, o Desenvolvimento Ágil não se aplica a todos os projetos.

Um outro ponto importante dos projetos ágeis é a fluidez, ou seja, facilidade de adaptação de um projeto. Mas essas mudanças precisam ser gerenciadas, do contrário o projeto se torna um caos. Além disso, a comunicação é um elemento essencial nesse tipo de projeto, e o cliente não é mais uma pessoa tão distante. Agora ele faz parte da equipe.

Existem três preceitos que precisam ser considerados:

1. É difícil prever quais requisitos de software vão persistir, e quais sofrerão mudanças;

2. É difícil prever quanto tempo será gasto no projeto antes que a construção comece;

3. Análise, projeto, desenvolvimento e testes não são tão previsíveis quanto gostaríamos.

Como resolver os três problemas acima? Com a adaptabilidade. É importante que o software seja entregue em incrementos, ou seja, versões funcionais em intervalos de tempo curto, para que seja possível o feedback do cliente.

A equipe ágil deve possuir alguns traços chave:

• Competência

• Foco comum

• Colaboração

• Habilidade na tomada de decisão

• Habilidade na solução de problemas confusos

• Confiança mútua e respeito

• Auto-organização

Extreme Programming (XP) – ou programação extrema – é a abordagem mais comum entre os métodos ágeis. Alguns valores estabelecem suas bases: comunicação, simplicidade, feedback, coragem e respeito.

São enfatizadas a colaboração informal (verbal) entre clientes e desenvolvedores, o estabelecimento de metáforas eficazes – ou seja, uma história que todos (clientes, desenvolvedores e gerentes) podem contar sobre o sistema – e feedback contínuo, para evitar uma documentação muito extensa. Além disso, projeta-se apenas para necessidades imediatas. A equipe está disposta a correr o risco de ter que “refabricar” o sistema ao considerar apenas as necessidades do presente.

Refabricar significa aprimorar o código e forma que ele funcione melhor, sem alterar o comportamento externo. O princípio do KIS (Keep it simple, ou seja, preserve a simplicidade) é seguido rigorosamente e protótipos operacionais são uma ferramenta utilizada para problemas mais difíceis.

Também existem outros modelos ágeis, como por exemplo:

• Desenvolvimento de Software Adaptativo (ASD) – centra-se na colaboração e auto-organização das equipes.

• Scrum – Além de outras características, possui reunião diárias de cerca de 15 minutos que são utilizadas para prever problemas potenciais. As reuniões são conduzidas por um Scrum Master.

• Método de Desenvolvimento de Sistemas Dinâmicos (DSDM) – Se baseia no princípio de que 80% do sistema pode ser entregue em 20% do tempo. O restante é entregue em outra iteração.

Um processo é – a grosso modo – uma metodologia que define ações, atividades e tarefas necessárias para desenvolver um software de alta qualidade. Uma metodologia genérica possui cinco atividades: comunicação, planejamento, modelagem, construção e entrega.

Junto com essas atividades, é necessário definir um fluxo de processo, que descreve como elas serão organizadas. O fluxo de processo pode ser:

• Linear – executa as atividades em sequência

• Iterativo – repete uma ou mais atividades antes de ir para a seguinte

• Evolucionário – Executa as atividades de forma circular

Cada volta nas atividades produz uma versão mais completa do software.

Dentre os modelos de processo existentes, estão os modelos prescritivos. O mais conhecido deles é o modelo cascata – ou ciclo de vida clássico – que seja um fluxo linear e sequencial das cinco atividades citadas acima. O modelo cascata raramente é aplicado na vida real, pois precisa de requisitos muito bem definidos.

O modelo incremental funciona um pouco diferente: o software não é entregue de uma só vez. O processo segue uma sequência linear, mas ao final das atividades, é entregue uma versão liberada do software, ou seja, uma versão que o cliente poderá utilizar efetivamente.

Também existem os modelos de processo evolucionários, que são mais interessantes quando não existe um produto final, ou seja, quando os sistemas são complexos e evoluem o tempo todo. Dentre os modelos evolucionários, podemos citar a prototipação.

Prototipar é como criar um esboço (não necessariamente funcional) de um sistema. Dessa forma são tiradas as dúvidas em relação ao projeto e menos erros são cometidos.

Outro modelo evolucionário é o espiral. Na primeira iteração deve se resultar uma especificação do produto. Algumas passagens subsequentes podem ser necessárias para o desenvolvimento de um protótipo, e então, progressivamente, versões cada vez mais completas do software.

Modelos concorrentes possibilitam à equipe de software representar elementos concorrentes e iterativos de qualquer um dos modelos de descritos acima.

O processo unificado possui as mesmas ações dos outros modelos, com a seguinte diferença: utiliza casos de uso para a descrição do sistema. O processo unificado utiliza a UML – linguagem de modelagem unificada – e é indicada para sistemas orientados a objetos.

O software – da forma como conhecemos – está morto. Para mim (e para o autor do livro) isso é fato. Com a Web 2.0 as coisas vêm mudando muito rapidamente, e o quanto antes percebermos isso será melhor.

Não é mais necessário haver 5 versões diferentes de um mesmo software rodando em milhares de máquinas isoladas. Na Web 2.0 deverá existir apenas uma versão, e tudo que for alterado ou implementado nessa versão, estará disponível instantaneamente para todos os usuários.

É claro que sempre existirão casos específicos onde as coisas serão feitas à moda antiga, mas de maneira geral, essa será a regra.

Ninguém poderia prever a importância que o software ganharia nos últimos 50 anos – e é bastante difícil de prever o que acontecerá nos próximos 50 – mas como se isso não fosse suficiente, está ganhando cada vez mais importância. E agora está presente em tudo. Desde sua TV, até o sinal de trânsito.

É aí que entra a Engenharia de software: precisamos de soluções rápidas, corretas e baratas.

 A Natureza do software

O software distribui o produto mais caro da nossa sociedade: a informação. Informação essa que pode vir de várias formas, desde operações bancárias, até vídeos em streaming. Ele está presente em dispositivos de todos os tamanhos: de celulares a mainframes.

Hoje a indústria de software tornou-se fator importantíssimo no mundo industrializado, com equipes altamente especializadas, e ainda temos alguns problemas relacionados a isso:

1. O tempo para se desenvolver;

2. O custo muito alto;

3. Falhas de projeto e execução;

4. Sistemas legados (sistema antigos);

5. Dificuldade em medir o progresso do desenvolvimento.

Definindo software

Software é muito mais um elemento lógico que físico, e por isso sua construção difere bastante da fabricação de hardware, por exemplo. Além disso, é desenvolvido por um processo de engenharia, e não fabricado – no sentido clássico.

Apesar disso, a produção de hardware e software possui coisas em comum. Ambos atingem a qualidade por meio de um bom projeto, mas um erro nesse projeto muitas vezes pode ser facilmente corrigido quando se trata de software, mas é bem mais complicado em relação ao hardware.

O software não se desgasta: um aplicativo lançado hoje precisa de algum tempo para ter correções aplicadas – o mesmo acontece com o hardware – mas depois disso se estabiliza. A diferença é que o hardware começa a apresentar problemas com o passar do tempo, relacionado a poeira, calor e outros aspectos físicos. Isso não acontece com o software.

Apesar disso, a cada nova alteração em um software, aparecem novos problemas e ele leva mais outro período para se estabilizar. Outro ponto em comum são os componentes reutilizáveis.

Na fabricação de hardware, tempos parafusos e outras peças que podem ser usadas em diversos projetos. E no software também é assim: não é preciso construir tudo a partir do zero. A diferença é que estamos apenas começando a evoluir nesse aspecto.

Campos de aplicação do software

Hoje em dia, o software é dividido em sete categorias:

1. Software de sistema: programas que interagem diretamente com o hardware, como compiladores, drivers e componentes do sistema operacional;

2. Software de aplicação: atendem diretamente à necessidade específica de um negócio, e processam dados comerciais ou técnicos;

3. Software científico/de engenharia: utilizados para processar dados científicos pesados, que vão desde a física à biologia molecular;

4. Software embarcado: projetado especificamente para implementar funções para um usuário final e para o próprio sistema. É utilizados em aparelhos eletrônicos como micro-ondas;

5. Software para linha de produtos: focado em uma atividade específica e para muitos clientes diferentes, desempenham atividades como: processamento de texto, planilhas eletrônicas e edição de imagens;

6. Aplicações para a Web (ou WebApps): inicialmente apenas uma série de arquivos de texto interligados, as aplicações web atualmente desempenham funções complexas, como grandes sistemas comerciais e corporativos;

7. Software de inteligência artificial: programas ligados a áreas como robótica, reconhecimento de padrões de imagem e voz etc.

Software legado

Sistemas de software legado são programas antigos – que muitas vezes foram construídos décadas atrás – mas que algumas vezes possuem funções de negócio vitais. Algumas vezes são considerados muito caros para manter, e também para evoluir.

Como se não bastasse, não raras são as vezes onde a documentação é inexistente, e uma construção deficiente. Mas então o que fazer?

A resposta é simples: nada. Se ele atende às necessidades da empresa, não há motivo para fazer qualquer alteração. Mas muitas vezes a evolução é necessária por motivos como:

• Atender a novas tecnologias;

• Novos requisitos ou regras de negócio;

• Interação com sistemas mais modernos.

A engenharia de software entra quando essa evolução se faz necessária.

 A natureza única das WebApps

Sites que, no início da Web – por volta de 1990 a 1995 – eram constituídos basicamente por páginas HTML, ganharam novas ferramentas, como o Java e o XML. O que antes era apenas HTML estático, agora pode ser uma grande aplicação web (WebApp), que podem ser integradas, por exemplo, a grandes bancos de dados corporativos.

Apesar de ser apenas uma categoria de software, as WebApps possuem vários atributos distintos. Entre eles:

• Uso intensivo de redes – Gigabytes ou até terabytes podem ser trafegados diariamente em uma única aplicação

• Simultaneidade – Vários clientes podem utilizar a aplicação ao mesmo tempo

• Carga não previsível – A quantidade de usuários simultâneos pode ser de 1 ou 1000

• Desempenho – A WebApp tem que ser rápida, ou então o usuário irá atrás de outra solução

• Disponibilidade – Muitas aplicações exigem uma disponibilidade de (quase) 100%, ou seja, 24 horas por dia, 7 dias por semana, 365 dias por ano. Geralmente é considerado algo em torno de 99,9% de disponibilidade. Isso quer dizer que a WebApp só poderia – com esse índice – ficar parada 8 horas por ano.

• Orientadas a dados – A função mais importante dos aplicativos web é, geralmente, fornecer dados (vídeos, textos, áudio etc.)

• Natureza do conteúdo – A qualidade e a estética do conteúdo são fatores bastante importantes

• Evolução contínua – Diferente dos softwares convencionais, as WebApps são atualizadas continuamente. Muitas vezes minuto a minuto.

• Imediatismo – O tempo de publicação pode ser muitas vezes, medido em minutos

• Segurança – Por não estar na segurança de uma rede local, e sim na internet, a segurança é um fator que não pode ser deixado de lado

• Estética – Numa aplicação web feita para vender, a estética é muitas vezes tão importante quanto quanto a funcionalidade

 Engenharia de software

O software no século XXI se tornou cada vez mais importante na vida das pessoas. Quando um projeto está sendo desenvolvido, muitas vozes devem ser ouvidas e um esforço deve ser feito para que se entenda qual o problema antes de produzir uma solução.

As aplicações estão ficando cada vez mais complexas, e projetos que antes eram desenvolvidos por uma única pessoa, agora precisam de, muitas vezes, dezenas. O software está em todo lugar: de sinais de trânsito a equipamentos de controle de tráfego aéreo.

De indivíduos a governos, passando por grandes empresas, inúmeras pessoas dependem de softwares. Se eles falharem, podem ocorrer de pequenos inconvenientes e a verdadeiras catástrofes. A qualidade é um ponto chave.

O software deve ser passível de manutenção, pois à medida que sua longevidade aumente, a quantidade de usuários e sua base de dados também irá aumentar, e adaptações serão, na maioria das vezes, necessárias.

Em resumo: software deve passar por engenharia. Mas o que é necessário para desenvolver um software que realmente funcione e que seja economicamente viável?

É necessário disciplina, mas também adaptabilidade e agilidade. São consideradas quatro camadas:

1. Foco na qualidade,

2. Processos,

3. Métodos

4. Ferramentas.

A base para a engenharia de software é a camada de processos, que mantém as camadas coesas e permitem que o desenvolvimento seja feito de forma racional e dentro do prazo.

Os métodos fornecem as técnicas para o desenvolvimento, que incluem: análise de requisitos, modelagem de projeto, testes, entre outras.

As Ferramentas oferecem um suporte automatizado para as ferramentas e métodos, e quando são integradas de modo que as informações de uma possam ser utilizadas por outra, é estabelecido o que se chama de “Engenharia de Software com o Auxílio do Computador”.

 O processo de software

Um processo não é uma metodologia rígida de como desenvolver um software, mas sim uma abordagem flexível que permite aos interessados realizar o trabalho selecionado de suas ações e tarefas. A intenção é sempre entregar um produto de qualidade e no prazo definido.

Uma metodologia é um alicerce de uma série de atividades estruturais aplicáveis a um projeto – independente do tamanho. Uma metodologia de processos genérica engloba cinco atividades:

• Comunicação – é importantíssimo se comunicar com o cliente e definir as necessidades antes de começar o desenvolvimento

• Planejamento – define as tarefas técnicas a serem desenvolvidas, os riscos, recursos e produtos resultantes. Além de um cronograma.

• Modelagem – é necessária a criação e um esboço, para se ter uma ideia geral da coisa, da mesma forma como fazem os engenheiros e arquitetos.

• Construção – geração de código e testes

• Emprego – o produto é entregue ao cliente, que fornece um feedback.

Uma série de atividades de apoio são utilizadas ao longo da evolução do projeto, entre elas:

• Controle e acompanhamento do projeto

• Administração de riscos

• Garantia da qualidade do software

• Revisões técnicas

• Medição

• Gerenciamento da configuração do software

• Gerenciamento da reusabilidade

• Preparo e produção de artefatos de software

 A prática da engenharia de software

Existem princípios básicos para uma metodologia de software:

• Compreenda o problema antes de querer construir uma solução

• Planeje a solução. Faça um projeto, pesquise produtos similares

• Execute. Siga o projeto que você definiu – mas se necessário faça correções no projeto.

• Examine o resultado. Teste sua aplicação.

Antes de sair adicionando funcionalidades a torto e a direito, veja se o que você pretende incluir irá realmente agregar valor. Se não for, não inclua. As coisas precisam ser simples. Não pense apenas no que você pode adicionar e pense no mais importante: o que você pode retirar.

Tenha cuidado para não transformar o projeto em uma colcha de retalhos, sem foco e sem função específica e quando for fazer qualquer coisa, deixe tudo especificado, pois outras pessoas provavelmente irão trabalhar no que você construiu.

Pense no futuro!

Softwares com muito tempo de uso possuem mais valor agregado, então não pense no projeto de forma limitada e pense na reutilização.

O componente que você construiu pode ser utilizado no mesmo projeto várias vezes, ou até em outros projetos e, acima de tudo: pense antes de fazer! Mesmo que você erre, irá aprender com a experiência.

Roger Pressman, autor do livro Engenharia de Software: Uma Abordagem Profissional

No primeiro post do blog sobre engenharia de software . com resolvi falar um pouco sobre o autor do livro que usaremos como base para os estudos em Engenharia de Software: Roger Pressman. Ele é referência internacional no assunto. Autor e co-autor de vários livros, já trabalhou como engenheiro de software, gerente, professor, consultor e também como desenvolvedor.

Possui Ph. D em engenharia pela Universidade de Connecticut, e é atualmente presidente da R. S. Pressman & Associates Inc., que tem como foco o desenvolvimento de treinamentos e métodos em engenharia de software. Entre os livros que foi autor ou co-autor estão:

• Numerical control and computer-aided manufacturing (1977)
• Making software engineering happen: a guide for instituting the technology (1988)
• Software engineering: a beginner’s guide (1988)
• Software shock: the danger & the opportunity (1991)
• Software engineering: a practitioner’s approach (2005)
• Web engineering: a practitioner’s approach (2009)

A obra que iremos nos aprofundar foi organizada em 32 capítulos, dividos em 5 partes, além de dois apêndices (Introdução à UML e Orientação a Objetos). Essas partes são:

1. O Processo – apresenta as diversas visões e filosofias de processo de software, entre modelos ágeis e preceptivos;
2. Modelagem – métodos de processo e análise com base na UML e Orientação a Objetos;
3. Gestão da Qualidade – conceitos, técnicas, procedimentos e métodos que visam avaliar a qualidade do software;
4. Gerência de Software – tópicos relevantes ao planejamento e gerência de sofware;
5. Tópicos Avançados – aperfeiçoamento e tendências da engenharia de software.

O livro foi organizado de forma a atender a diferentes públicos ligados à área de Tecnologia da Informação, como estudantes no final da graduação e profissionais a área.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7ª Edição. Porto Alegre: AMGH, 2011. 780 p.

Veja abaixo a lista dos capítulos do livro:

1. Engenharia de software

PARTE UM – PROCESSOS DE SOFTWARE
2. Modelos de processo
3. Desenvolvimento ágil

PARTE DOIS – MODELAGEM
4. Princípios que orientam a prática
5. Engenharia de requisitos
6. Modelagem de requisitos: cenários, informações e classes de análise
7. Modelagem de requisitos: fluxo, comportamento, padrões e aplicações baseadas na web (WebApp)
8. Conceitos de projeto
9. Projeto de arquitetura
10. Projeto de componentes
11. Projeto de interfaces de usuário
12. Projeto baseado em padrões
13. Projeto de WebApps

PARTE TRÊS – GESTÃO DA QUALIDADE
14. Conceitos da qualidade
15. Técnicas de revisão
16. Garantia da qualidade de softwae
17. Estratégias de teste de software
18. Testando aplicativos convencionais
19. Testando aplicações orientadas a objeto
20. Testando aplicações para a web
21. Modelagem formal e verificação
22. Gestão de configuração de software
23. Métricas de produto

PARTE QUATRO – GERENCIAMENTO DE PROJETOS DE SOFTWARE
24. Conceitos de gerenciamento de projeto
25. Métricas de processo e projeto
26. Estimativas de projeto de software
27. Cronograma de projeto
28. Gestão de risco
29. Manutenção e reengenharia

PARTE CINCO – TÓPICOS AVANÇADOS
30. Melhoria do processo de software
31. Tendências emergentes na Engenharia de Software
32. Comentários finais

São 780 páginas de muito conteúdo. É bastante material para que a gente possa se debruçar nos próximos meses.