Estilos de Arquitetura e Separação de Responsabilidades para um Design Ágil

Com a grande demanda de profissionais por parte das empresas, muitos deles acabam sendo contratados sem ter o devido conhecimento sobre boas práticas de desenvolvimento de software, infraestrutura de desenvolvimento, protocolos de comunicação, sistemas gerenciadores de banco de dados e muitas vezes até conhecimento básico sobre sistemas operacionais.

Além disso, dentro das empresas existe uma demanda cada vez maior por projetos de software de alta complexidade, com prazos de entrega na maioria das vezes fora da realidade. O que faz com que muitos projetos sejam entregues sem testes, com falhas de implementação, qualidade duvidosa e muitas vezes sem atender ao negócio do cliente.

Como consequência, após implantado, o sistema passa a apresentar sérios problemas como degradação da performance, perda de dados, cálculos incorretos, entre outros problemas, trazendo grandes prejuízos à empresa e fazendo com que os usuários percam a confiança no sistema e por fim os próprios desenvolvedores.

Direcionado para este cenário, o presente artigo visa demonstrar boas práticas de desenvolvimento de software e explicar os princípios fundamentais para se criar um bom design. Veremos também a aplicação de alguns padrões de projeto pouco difundidos, mas que são de extrema importância no dia a dia do desenvolvedor.

Estilos de Arquitetura

Quando vamos planejar o desenvolvimento de um software, geralmente um dos primeiros itens que o arquiteto de software começa a analisar é qual o melhor estilo de arquitetura que se aplica ao
contexto do projeto. Neste ponto ele leva em consideração diversos fatores, como os requisitos do software, custo, infraestrutura e conhecimento técnico da equipe.

Entender o estilo arquitetural adotado para o desenvolvimento traz diversos benefícios para os desenvolvedores e para a empresa como um todo, entre eles: fornecer uma linguagem comum entre os desenvolvedores e os demais envolvidos no projeto.

Por exemplo, quando o estilo de arquitetura é SOA, os desenvolvedores podem até conversar com pessoas de outras áreas, que não possuem conhecimento técnico (como detalhes da linguagem de programação, servidores de aplicação, etc.), sobre o método envolvido na automação dos processos de negócio, que as mesmas entenderão sobre o que é um serviço, governança e, dependendo do usuário, até termos mais específicos, como escalabilidade.

A Tabela 1 apresenta um resumo dos principais estilos de arquitetura.

Estilo de Arquitetura	Descrição
Client-Server	Também conhecida como arquitetura de duas camadas. Este tipo de arquitetura descreve a interação entre um ou mais clientes e um servidor, através de uma conexão de rede. A aplicação mais comum para esse tipo de arquitetura é um Banco de Dados no lado do servidor com a lógica da aplicação representada em Stored Procedures, e o lado do Cliente representado por aplicações conhecidas como Fat-Clients (Clientes Pesados), que muitas vezes contêm a lógica de negócio embutida no front-end. Como exemplo, podemos citar aplicações desenvolvidas com Delphi, Visual Basic, Oracle Forms, entre outros.
Arquitetura baseada em Componentes	Quando utilizamos uma arquitetura baseada em componentes, decompomos o design da aplicação em componentes lógicos com um fraco acoplamento, de forma que cada um deles seja individual e reutilizável, com uma localização transparente e interface de comunicação bem definida. Uma das grandes vantagens desse tipo de arquitetura é que ela promove a reusabilidade dos componentes e facilita a manutenção da aplicação.
Domain Driven Design	De acordo com o próprio criador, Eric Evans, DDD não é uma tecnologia e nem uma metodologia. DDD é um estilo de arquitetura orientado a objetos, focado em modelar o domínio do negócio e a lógica do domínio com o uso de técnicas, práticas e padrões de projeto.
Arquitetura em Camadas	Esse é o estilo de arquitetura mais conhecido e mais utilizado para o desenvolvimento de aplicações. Ele permite a separação dos módulos do sistema em camadas (layers) diferentes. As principais vantagens desse estilo são a facilidade de manutenção, o aumento da extensibilidade, reusabilidade e escalabilidade.
3-Tiers/N-Tiers	Esse estilo segrega as funcionalidades em segmentos separados de maneira similar ao estilo da arquitetura em camadas, mas com cada segmento alocado em camadas físicas (tiers) separadas, conforme veremos em detalhes no tópico “Arquitetura Distribuída”.  Ele é ideal quando o projeto demanda escalabilidade. Para isso, as camadas lógicas (layers) da aplicação são alocadas em máquinas diferentes.  Geralmente, ao mapear as camadas lógicas (layers) para as físicas (tiers), podemos criar um cluster ou um farm na mesma camada física para aumentar a performance e a confiabilidade da aplicação.
Arquitetura Orientada a Serviços(SOA)	SOA já deixou de ser apenas uma palavra no meio de TI para se tornar um modelo consagrado adotado em muitas empresas. Uma arquitetura orientada a serviços nada mais é do que uma aplicação que expõe e consome as funcionalidades do sistema como serviços por meio de contratos e mensagens.  Algumas das características de uma Arquitetura Orientada a Serviços são: a independência da Plataforma, comunicação baseada em serviços entre os componentes de software, integração de múltiplas funcionalidades em um único componente de interface do usuário e a exposição dos serviços por meio de repositórios ou catálogos.
Arquitetura Orientada a Objetos	Ao aplicar esse estilo, o sistema é dividido em objetos individuais, reutilizáveis e autossuficientes. Cada objeto contém os dados e o comportamento pelos quais é responsável. Uma arquitetura orientada a objetos geralmente busca espelhar objetos do mundo real de modo a tornar simples a modelagem da aplicação.

Tabela 1. Estilos de Arquitetura.

Cluster: É um conjunto de computadores interligados que trabalham em conjunto como se fosse um único computador. Estes computadores são utilizados para suportar aplicações que têm necessidade de alta disponibilidade e alta capacidade de processamento.
Farm: Um Servidor Farm, também conhecido como Data Center, é um conjunto de servidores mantido (geralmente) por uma empresa para atender as necessidades computacionais da corporação, como o processamento de grandes volumes de informação, atender aos sistemas corporativos e prover servidores de contingência no caso de um problema no computador principal.
Repositório: Um Repositório é um local onde todos os clientes de um domínio específico publicam seus serviços, de maneira que todos os usuários passam a conhecer os serviços disponíveis e como acessá-los.
Para tanto, um repositório deve ter uma interface bem definida para publicação dos serviços, funções para localização, controle e maneira uniforme de acesso.

Uma vez que o estilo de arquitetura é definido, o passo seguinte é definir como as funcionalidades do sistema serão divididas, de forma a manter em conjunto os componentes relacionados (alta
coesão), e fazer com que estes possuam o mínimo de conhecimento sobre os outros componentes (baixo acoplamento). Para alcançar o baixo acoplamento e uma alta coesão é importante entender o conceito de Separação de Responsabilidades.


Separação de Responsabilidades (Separation of Concerns)

O termo Separação de Responsabilidades foi criado pelo pai do algoritmo de caminho mínimo, o cientista Edsger W. Dijkstra em 1974, e tem como objetivo dividir a aplicação em funcionalidade distintas com a menor similaridade possível entre elas. Para aplicar com sucesso este princípio, o mais importante é minimizar os pontos de interação para obter alta coesão e baixo acoplamento entre os componentes do sistema. Para tanto, é recomendado, primeiro dividir suas responsabilidades e organizá-las em elementos bem definidos, sem repetição de código ou de funcionalidade.

O tipo de separação de conceito mais difundido é o da separação horizontal, onde dividimos a aplicação em camadas lógicas de funcionalidades, como por exemplo, o protocolo TCP/IP (modelo OSI), que é separado pelas camadas de aplicação, transporte, rede, enlace e física. Neste modelo, cada camada tem sua própria responsabilidade e não precisa conhecer as camadas adjacentes. Voltando ao nosso mundo, em uma aplicação Java EE, as camadas mais conhecidas são a de Apresentação, Serviço, Domínio e Infraestrutura, como ilustra a Figura 1.

Figura 1. Separação Horizontal de Conceitos (Camadas lógicas de uma aplicação).

Podemos também aplicar o tipo de separação vertical, onde dividimos a aplicação em módulos ou funcionalidades que são relacionadas a um subsistema ou grupo de operações dentro de um sistema.
Veja um exemplo na Figura 2.

Figura 2. Separação Vertical de Conceitos.

Separar as funcionalidades de uma aplicação em módulos deixa claro as responsabilidades e dependências de cada funcionalidade, o que ajuda na execução dos testes e na manutenção do
software. Na Figura 2 fazemos um agrupamento por módulos; neste caso a separação foi feita pelos módulos de RH, Contábil e Marketing.

Além disso, podemos utilizar o conceito de separação vertical em conjunto com o conceito de separação horizontal. Veja um exemplo na Figura 3.

Figura 3. Aplicação da Separação de Conceitos Vertical e Horizontal.

Um papel importante da separação de conceitos é o da separação de comportamento, que envolve a divisão dos processos do sistema em unidades lógicas de código reutilizáveis e gerenciáveis. Ao organizar o comportamento, alcançamos os seguintes benefícios:

• Eliminamos a duplicação de funcionalidades;
• Minimizamos as dependências externas;
• Maximizamos o potencial para reuso;
• Restringimos o escopo do trabalho para os limites de cada módulo.

Como vimos, é importante entender a separação de conceitos pois ao modelarmos uma aplicação devemos ter conhecimento das responsabilidades de cada um de seus componentes. Além disso, devemos ter uma ideia de como será feita esta separação e como será feita a distribuição destes componentes na arquitetura disponível pelo cliente.

Para tanto, é preciso levar em consideração outros fatores, como infraestrutura e recursos disponíveis, conforme veremos a seguir, no próximo artigo da série.

Referências

Excelente artigo sobre separação de responsabilidades
http://www.aspiringcraftsman.com/2008/01/art-of-separation-of-concerns/

Biografia de Edsger Dijkstra.
http://pt.wikipedia.org/wiki/Edsger_Dijkstra

Guia de Arquitetura de Aplicações da Microsoft.
http://www.codeplex.com/AppArchGuide

[Getting Real] Caindo na Real no Desenvolvimento de Software

Este ultimo mês, finalmente li o livro da 37signals.com, chamado Getting Real, dos mesmos criadores do framework Ruby on Rails, onde eles criticam de maneira agressiva o desenvolvimento de software tradicional, e expõe os seus pontos de vista, e não dão a mínima importância de ir contra a maioria dos conceitos que aplicamos diariamente em nossos projetos.

É uma leitura no mínimo interessante, e com certeza recomendada, tem vários conceitos que ficam inviáveis de se aplicar na maioria das empresas, mas com certeza ajuda a abrir os olhos para muitas coisas, se você não quiser ler o livro, recomendo pelo menos a leitura do resumo que fiz abaixo, boa leitura !!!!

******************************************************

Caindo na Real.

Quer construir uma aplicação web de sucesso? Então é hora de Cair na Real. Caindo na Real é o menor, mais rápido e melhor caminho para construir software. Veja como:

Construir menos

Desenvolver apenas o arroz com feijão.

• Menos funcionalidades
• Menos opções/preferências
• Menos pessoas e estrutura empresarial
• Menos reuniões e abstrações

Construir software para você mesmo.

Com paixão, realmente goste do que faz, acredite no seu software, seguindo a filosofia da comunidade open source.

Viva o software que você produz, fale dele, realmente se importe com isso.

Financie você mesmo

Não conte com o dinheiro de fora. Isso pode trazer dor de cabeça, pois um projeto financiado traz consigo prazos, cobranças, expectativa, metas, inchação de saco, e por fim acaba sendo produzido um produto medíocre.

Em projeto sem dinheiro de fora você tem tempo para desenvolver e com isso mais qualidade,

O que você pode fazer em 3 meses ao invés de 6 ?

Prazo fixo, orçamento, flexibilidade no escopo.

Faça o arroz e o feijão, aquilo que será o core do sistema, o que puder ser feito dentro do prazo e do orçamento, ótimo, fora disso a qualidade do produto irá sofrer, sempre diminua o escopo, sempre haverá novas features para serem incluídas no futuro.

Tenha um inimigo

Arrume um inimigo, veja um produto no mercado que seja um concorrente e faça algo inovador no seu produto, sem querer imitir, tome um caminho oposto, e faça uma proposta diferente para abordar o seu produto.

Tendo em mente o seguinte pensamento “Não siga o líder”, conte uma história diferente para os seus clientes. Não tente convencer o seu cliente de que ele fez uma escolha errada, ao invés disso mostre as qualidades do seu software.

Menos massa

Quanto mais robusto você for, mais fácil será se adaptar as mudanças.

Menos massa diminuir o custo de mudança.

Mais massa é:

Contratos de longos termos, excesso de burocracia, decisões permanentes, reuniões sobre outras reuniões, processo moroso, inventário (físico e mental), ficar preso a fornecedores, formatos de dados proprietários, o passado mandando no futuro, roadmaps, políticas de escritórios.

Menos massa é:

Pensamento just-in-time, time com membros multi-tarefa, abraçar as regras ao invés de tentar burlá-las, menos software, menos código, times pequenos, simplicidade, formatos de dados abertos, produtos open source, uma cultura aberta que é fácil de admitir erros.

Abrace as Regras

Permita que as restrições guiem você para soluções criativas. Não reclame sobre a falta de recursos (tempo/dinheiro/equipe). Trabalhe com o que tem e veja o lado bom disto. Em um bom time, limitação traz boas idéias (inovação) e força o foco.

Tenha times pequenos

Times pequenos melhoram o entendimento do grupo, potencializa o fluxo de informação e evita guerra de egos. O ideal em um projeto é ter times de até 3 pessoas.

Seja você mesmo e sinta a dor

Seja diferente dos grandes players, trabalhando o lado pessoal sendo amigável com os clientes, dê um atendimento pessoal sempre que possível, atenda seu cliente, conheça seu cliente, por default, empresas pequenas são mais próximas do cliente, utilize isto como uma vantagem, e conheça seu cliente, que desta maneira você irá ver seu produto por um outro foco.

Sinta a dor que o seu cliente passa, quando ele reclama de alguma coisa, NÃO FAÇA OUTSOURCING DO SAC PARA UM CALL CENTER OU UM OUTRO TERCEIRO, FAÇA ISTO VOCÊ MESMO.

Passe confiança para o cliente, a nível de passar o seu número celular se possível, traga o cliente para perto de você, pois isto inspira confiança.

Mantenha o Foco.

O seu aplicativo deve ter uma identidade, um objetivo, e nunca deve perder o seu propósito, tenha sempre em mente o que ele deve fazer e nunca fuja do foco.

Eleja o cliente/mercado correto e foque somente neste nicho, se você tentar agradar a todos, nunca irá dar certo.

Ignore os detalhes no primeiro momento

Faça o seu produto o mais simples possível, pense no “floreamento” em um segundo momento, ou até mesmo deixe para lá, deixe que o usuário trabalhe como o que tem.

É um problema somente quando é um problema

Não perca seu tempo tentando arrumar bugs que não existem, não faça algo pensando em resolver um problema que não existem.

Por exemplo, porque montar uma aplicação altamente escalável em um primeiro momento, se você não sabe ainda se vai precisar, ou não sabe a quantidade de acessos sua aplicação irá ter... crie sua aplicação e depois se preocupe para resolver isto, quando sua aplicação for um sucesso. Pois se formos pensar, sempre teremos que rever a nossa aplicação, em termos de tunning, dimensionamento, etc...

Meio Produto, não Meia Boca.

Atenha-se ao que é verdadeiramente essencial. Boas idéias podem ser tiradas da gaveta. Pegue tudo que você acha que seu produto deve ser e corte pela metade. Remova funcionalidades até que você obtenha apenas o essencial. E então, repita o processo.

FAÇA ALGO QUE VOCÊ POSSA GERENCIAR.

FAÇA UM SOFTWARE PARA UM PÚBLICO GERAL E FAÇA COM QUE O USUÁRIO ACHE SUAS PRÓPRIAS SOLUÇÕES.

O Não é a resposta,

Uma vez com o produto lançado, prepare-se para uma enxurrada de requisições de usuários, do tipo, porque não colocar isso? Porque não coloca aquilo? etc...

A primeira resposta é sempre NÃO. Nós não precisamos de um milhão de funcionalidades, eu mesmo não utilizo metade das funcionalidades do NetBeans, só altere seu produto, quando começar a pipocar várias vezes a mesma requisição.

Outra coisa, você não precisa de uma lista de backlog, o fórum /lista de discussão é o melhor local, pois aquilo que realmente precisa ser feito, irá sempre aparecer.

O que você não quer?

Busque feedback dos usuários, e pergunte por funcionalidades que eles não utilizam ou coisas que eles não querem, então, tire do seu software, mantenha seu software o mais simples possível.

Coloque seu código para rodar,

Não espere muito tempo para colocar seu software no ar, coloque no ar, e vá incluindo novas funcionalidades aos poucos.

Celebre as pequenas vitórias, uma coisa importante é a motivação, diminua suas iterações, no meio de uma semana atribulada busque algo que foi feito durante a semana, uma funcionalidade, uma melhoria, retirar uma funcionalidade não utilizada e comemore... pois isto irá trazer desejo de mais pequenas vitórias.

ABOMINE REUNIÕES.

Você já parou para pensar, em quanto tempo você já perdeu da sua vida em reuniões inúteis ? Muitas né .. pois é, eu também :(,, no livro o cara detona as reuniões. Nunca faça reuniões, somente em último caso, se não tiver como evitar, faça uma reunião de no máximo 30 minutos, convide o menor número de pessoas possíveis, e procure não perder o foco. Sempre tem aquele que acaba desvirtuando para um assunto totalmente fora do foco.

Não contrate,

Mantenha um número pequeno de pessoas, somente contrate em último caso, se sair alguém, espere por um tempo, e veja se aquela pessoa esta fazendo falta, se estiver fazendo muita falta, contrate, senão, não.

Ações, Não Palavras.

Se for contratar, procure caras que fazem open-source, pois de quebra, você pode analisar a qualidade do código, cultura, nível de paixão, se a pessoa é social. Open source rules !!! Contrate caras que sabem escrever bem, tenham boa comunicação, e que sejam entusiasmadas.

Primeiro a interface,

Faça primeiro a interface, depois codifique, fica muito mais fácil quando você vê o produto.

Depois de iniciar o desenvolvimento, desenvolva de dentro para fora, começando pelo núcleo do seu código.

Trabalhe pensando nos 3 estados, no estado regular, que é quando o usuário vê a tela funcionando normalmente, estado da tela em branco, quando o usuário vê a tela ao utilizar a tela primeira vez, este estado é importante pois marca a primeira impressão. E o estado de erro, que é quando acontece algo de errado na aplicação.

Felicidade Otimizada

Utilize ferramentas que deixe seu time feliz e excitado, pois um desenvolvedor feliz é um desenvolvedor produtivo.

Se desenvolvedores fossem pagos para remover código de seus programas,.

Ao invés de escrever novo código, seu software seria muito melhor, pense nisso.

Abra as portas

Disponibilize para o mundo seu software através de RSS, APIs, Widgets etc..

Isso faz toda a diferença, se possível torne seu software extensível.

Amostra Grátis

Quando lançar seu produto, disponibilizar amostras grátis, deixe o seu cliente em potencial testar seu produto, mas deixe sempre funcionalidades na manga para o produto licenciado, deixe a funcionalidade a mostra, quando o usuário clicar na opções, avise-o esta funcionalidade é para clientes que tem uma assinatura, bla bla bla..

Não tem nada de funcional e uma especificação funcional,

Não escreva especificações funcionais, pois elas não refletem a realidade, isso é feito para fazer as pessoas felizes, ela leva para acordo ilusório, pois cada um pode interpretar de uma maneira um texto.

Especificações funcionais levam você a tomar decisões importantes quando você tem menos informação. Essas especificações não fazem você evoluir, mudar, ou revisar pois você fica preso naquele escopo.

E bata de frente com os bloqueadores, pois vai aparecer várias pessoas querendo todo tipo de documentação, o que com certeza vai atrasar todo o processo. O melhor a fazer é ter os conceitos bem formados na cabeça, iniciar um protótipo estático, isto dará uma idéia muito madura do que deve ser feito.

Mais uma vez, NÃO FAÇA DOCUMENTAÇÃO QUE NINGUÉM IRÁ LER.

Escreva estórias, não detalhes.

Lembra do user stories, então, é isso aí.

Fácil para entrar, fácil para sair,

No site, torne fácil o processo de adesão do produto e o de cancelamento, pois é mais difícil um cliente que não teve problemas ao cancelar a assinatura de voltar a assinar do que o cliente que ficou nervoso ao tentar cancelar e não conseguiu.

Evite contratos de longo termo, taxas de assinatura, etc... não tente enganar seu cliente para ganhar mais dinheiro, seja HONESTO sempre.

Luva de Pelica

Precisa dar uma má notícia como aumento de preço, faça de uma maneira que não vá agredir, ou seja, vá avisando aos poucos, enviando emails comentando de melhorias, de novas aquisições (de hardware), etc... e por isso nós próximos meses teremos um pequeno reajuste, bla bla bla.. isso dói muito menos, do que chegar na hora H e pegar o cliente desavisado, é pedir para apanhar.

Lançamento estilo Hollywood

Vá do teaser para o trailer para o lançamento.

O esquema é marketing, para o seu produto faça um lançamento no estilo Hollywood.

Teaser

Alguns meses antes, já inicie o projeto, divulgando o produto em sites relacionados, crie um logo, crie um site promocional, com algumas novidades semana a semana, para ir alimentando a curiosidade de seus futuros clientes. Crie uma lista para as pessoas receberem avisos do que está rolando, novidades.

Trailer

Nesta fase, lance um produto beta com preview de algumas funcionalidades, deixe um grupo de pessoas testarem, e colha opiniões, bugs, etc...

Lançamento

Divulgue, faça com que todos voltem a atenção para o seu software, reformule o hot site, coloque blog, tour, um overview, relate cases, Valores, formulários para inscrição, testemunhos,

Blog é o melhor marketing que existe, você não gasta nada (apenas tempo) e as vezes o efeito é melhor do que uma propaganda na mídia.

Promova seu software através da educação, ensine as pessoas a utilizarem seu software, com tutoriais, vídeo aulas, seminários, etc..

E deixe o software o mais fácil possível, utilize FAQs, e help na aplicação, tente deixar um nível próximo de zero a necessidade de um treinamento.

De um nome

Dê um nome fácil das pessoas guardarem, não precisar ser nada muito óbvio com que a sua aplicação faz.

Resposta Rápida

Responda o mais rápido possível ás dúvidas do seu cliente, o suporte rápido e eficiente deve ser a prioridade no seu negócio, e seja sempre sincero, quando acontecer algum muito errado, por exemplo, deu crash no servidor, seja sincero, e explique o que aconteceu, com certeza ele irá entender.

Mantenha o seu blog atualizado

Um blog parado, passa a impressão que o produto está descontinuado, tirando assim a confiabilidade, atualize sempre, dê uma dica, ensine uma feature, mas mantenha seu blog sempre atualizado

Saiba o que os seus concorrentes estão fazendo.

Se inscreva nos feeds dos seus concorrentes, mas não se aprofunde demais, para o seu produto não perder a personalidade

Siga a maré

Seja sempre aberto para novas possibilidades, e mudanças de direção. Seja um surfista, e não o oceano, tente adivinhar aonde a maré rebenta e se ajuste de acordo ;-).

Aplicando Caindo na Real

Execução.

Todo mundo pode ler um livro, criar um blog, ter uma idéia, todo mundo tem um primo que é web designer.

A diferença entre você e o resto é de como isso será executado. Sucesso se resume a uma grande execução.

Pessoas

Não adianta você aplicar estes conceitos, se você não tem um bom time, com pessoas que realmente gostam do que faz, que se importam com a qualidade do software, pessoas que não guardam informação. Tenha o time certo! Procure os apaixonados.

Engenharia de Software: 40 Anos de sofrimento e aprendizado

Um pouco de história:
Modelo Cascata ou Waterfall:
Nas empresas que passei, pelo menos a maioria, posso dizer que trabalharam (ou trabalham) com o método cascata para o desenvolvimento de software, que tem seus prós e contras, o problema é que este modelo foi concebido nos anos 70 por W. W. Royce, e consiste na evolução de cada fase do projeto de forma sequencial (Figura 1), vemos na imagem que o primeiro quadrado inicia-se pelo "Requerimento", ou seja, é aquela fase do projeto que demora até meses para ser feita, onde o analista tem que coletar todas as informações pertinentes do projeto e definir os seus requisitos.

Pois bem, uma vez definido os requisitos e fechado o contrato ou a SLA, é montado o cronograma e iniciando a segunda fase deste modelo, a fase do "Projeto", e aí é que geralmente os problemas começam, pois muitas vezes, o cliente ao especificar um projeto não tem nem certeza do que quer, apenas uma idéia, ficando para o analista decifrar tudo o que cliente quer, e quando os requisitos chegam para os desenvolvedores, muitas vezes estes não tem nem contato com o usuário, e tem que se virar com o entendimento baseado nos documentos de especificação, o máximo é uma conversa rápida com o analista, e quando possível.
Outro problema é que estes projetos, são estimados em torno de 3 - 6 meses, e conforme o tempo vai passando, acontece coisas com o cliente e ele começa a esquecer o que foi acordado, sobrando para o pobre desenvolvedor que acaba tendo que refatorar o código para atender a necessidade do usuário, e no modelo cascata não podemos voltar uma fase, conclusão, projetos mal sucedidos, ou atrasados, ou o produto acaba não atendendo o cliente.

Modelo Espiral:

Para tentar acabar com estes problemas conhecidos do Modelo Cascata, em 1988 Barry Boehm escreveu um artigo “A Spiral Model of Software Develpement and Enhancement” , que propõe um desenvolvimento iterativo e incremental que podem chegar de 6 meses a 2 anos,


Vantagens deste modelo:
• O Modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos.
• Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento.


Desvantagens:
• Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que a abordagem evolutiva é controlável.
• A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas.
• Este tipo de modelo é relativamente novo e não tem sido amplamente usado.
• É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido.
• O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

RUP:

Nestes 3 últimos anos especificamente, tenho trabalhado com um híbrido de RUP, e nas minhas experiências não tenho tido o sucesso desejado, vendo a causa pude chegar a conclusão que para uma metodologia desta dar certo não dependendo só dos templates do método e das fases estabelecidas mas da cultura da empresa e das pessoas envolvidas, pelo menos nos locais onde trabalhei com esta metodologia as pessoas trabalham com RUP em uma forma cascata, e RUP pode será ágil, que é o que mostra o artigo RUP Ágil de José Papo em seu blog. Mas mesmo assim, as pessoas tendem a trabalhar com um RUP mais “pesado”, com um excesso de documentação a ser preenchida, onde para cada passo que é dado, é preciso de assinaturas dos envolvidos.
Ou seja, essa situação faz com que as pessoas envolvidas no processo (leia-se cliente, fornecedor, terceiro) acabam entrando em conflito, pois imagine a seguinte situação, eu tenho um determinado cliente que pede uma determinada funcionalidade no sistema DELE, após eu(analista) colher o requisito, eu tenho o trabalho de documentar isso em um documento definindo as fronteiras do sistema, identificando principais envolvidos/interessados e priorizando suas necessidades, e os requisitos funcionais e não funcionais, pois bem, depois de todo este trabalho, antes de fazer qualquer coisa eu tenho que pegar um documento assinado ou email, provando que foi uma solicitação real e será implementada de acordo com a especificação.
É normal que o cliente terá receio de assinar qualquer documento, pois na cabeça dele, ele pensa que se acontecer alguma coisa errada no processo, a culpa irá recair sobre ele por causa deste documento assinado. Isso vai gerando um desconforto muito grande entre os envolvidos, e o atraso é evidente pois para cada passo é preciso da aprovação do cliente, cada fase do projeto é auditada. Então me diga, Cadê a agilidade?
Lembro que estas foram as minhas experiências com RUP.
Será que não tem algo errado nisto ? Por quê muitas empresas utilizam processos de desenvolvimento de 40 anos atrás, sendo que todo ano é publicado o relatório do Caos pela Standish Group International, onde até o ano passado, 1 entre 3 projetos estouram o orçamento,

Foram por causa dessas perguntas que comecei a me interessar por meios alternativos de gerenciamento de projeto, foi quando conheci as metodologias ágeis. E descobri algo que o que realmente faltava nestes processos / modelos / metodologias, e é algo que é o ponto chave em metodologias como SCRUM, é que esta metodologia é centrada em PESSOAS, GENTE, SER HUMANO, agora que as outras não priorizam. Desenvolvimento LEAN. Veja alguns dos principios:

“Indivíduos e interações são mais importantes que processos e ferramentas.”

“Software funcional é mais importantes que excesso de documentação.”

Para uma idéia melhor sobre o que que é manifesto ágil, veja meu outro post Agile Manifesto – Metodologias Ágeis.

E essa descoberta mudou radicalmente o meu processo de pensar, é a solução para todos o problemas? NÃO.

Mas com certeza é um passo muito importante para quebrar o paradigma de desenvolvimento de software tradicional.

Aos poucos vou falar sobre estes processos ágeis, recomendo que você leia as seguintes matéria.


Blog:

Agile Manifesto – Metodologias Ágeis
TDD – Test Driven Development
SCRUM – Uma abordagem prática

Livros:
Agile Software Development with SCRUM
Extreme-Programming-Explained
User Stories Applied
Lean-Software-Development