Este modelo é baseado na teoria da especificação formal, onde software é um sequência de passos especificados que gradativamente se transformam em implementação.

Consistindo em 2 estágios principais este modelo prega:

Analise e especificação de requisitos: como nos outros modelos, através da aplicação de várias técnicas onde se extrai a necessidade do negócio do cliente.

Otimização: onde as especificações são trabalhadas e transformadas em artefatos de software, porém a cada novo ajuste nos requisitos deve-se atualizar as especificações antes das implementações de maneira religiosa, pois alterações na implementação pode gerar impactos custosos de serem resolvidos, uma vez estes impactos sendo descobertos na especificação a correção torna-se indolor.

O processo  de transformação é controlado por 1 ou mais engenheiros (de software) para garantir a aplicação das técnicas empregadas.

Além, este modelo prega o básico de reaproveitamento de código na forma de componentes, toda vez que um novo componente é desenvolvido pode/deve ser incorporado ao projeto (ou outros projetos) e pode ser armazenado em bibliotecas de componentes.

Como não é novidade que requisitos inevitavelmente são alterados esta metodologia se mostra um tanto flexível nestes cenários.

Neste modelo os estágios consistem em expandir ou incrementar o produto (software) gradativamente.

Não se tem muito a falar sobre o mesmo, pois utiliza-se do modelo em cascata (Watrfall) para gerenciar seus processos porém com algumas resalvas. Antes de iniciar-se o desenvolvimento do produto propriamente dito este modelo prega que devemos esboçar nossa visão de solução em forma de um protótipo funcional para validação de requisitos junto ao cliente (após a análise e especificação).

Protótipos basicamente são experimentos, modelos (rascunhos) de uma solução final que serve unicamente para se ter uma idéia de como prosseguir e logo em seguida ser descartado. Protótipos são feitos para não serem usados no produto final.

De posse da validação dos requisitos e de um aceite do cliente (que provavelmente vai dizer que já quer usar o protótipo) pode-se iniciar o desenvolvimento seguindo as etapas após a análise e especificação. Prototipação traz alguns ganhos reais de visão de projeto, mas protótipos são um outro assunto que será abordado mais a frente.

Intende-se por modelo de desenvolvimento uma série de padrões e técnicas agrupadas que são aplicadas a um projeto, desde a idealização até a concepção do produto propriamente dito. É esse modelo que dita as regras de como o produto deve ser desenvolvido, passando por todas as etapas propostas e cumprindo-se as metas que o modelo determina.

Modelos são importantes para organizar o processo de desenvolvimento de acordo com o proposto. Cada projeto pode necessitar de uma abordagem (e modelo) diferente, o que nos leva também a analisar qual a melhor tecnologia a se aplicar para cada situação específica.

Existem diversas tecnologias no mercado, porém por mais que se esforçem pra isso não é possivel que uma tecnologia seja a melhor alternativa para todas as necessidades assim como os modelos não podem ser aplicados com eficácia em todo tipo de projeto.

No decorrer desta série estaremos tratando das principais metodologias empregadas no modelo de desenvolvimento estruturado e quais os casos que as mesmas se aplicam melhor. aguardem.

A Engenharia segundo a Wikipedia "(<latim ingeniu = "faculdade inventiva, talento") é a arte, a ciência e a técnica de bem conjugar os conhecimentos especializados (científicos) de uma dada área do saber com a sua viabilidade técnico-econômica, para produzir novas utilidades e/ou transformar a natureza, em conformidade com idéias bem planejadas". Sendo assim Engenharia de Software é a aplicação dos conceitos de engenharia direcionados a desenvolvimento de software de qualidade, confiável e principalmente viável.

Fritz Bauer disse em 1969: “O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais”, como podemos ver este não é um conceito novo, assim como a busca de qualidade e melhores maneiras de se obter artefatos de softwares.

Programadores apenas codificam, analiastas analisam e assim subsequentemente, porém o papel do engenheiro de software é um tanto mais amplo. Um engenheiro de software deve ser capaz de identificar um problema, levantar requisitos, especificar processos, propor soluções e implementa-las, ou seja, a especialização de cada individuo em uma determinada área não é mais vista com bons olhos pois limita a visão do todo somente a sua área de conhecimento específica, é importante que  alem da especialidade se tenha uma visão ampla do todo.

Existem 3 aspectos bastantes importantes sendo: métodos (como fazer), ferramentas (apoio) e procedimentos (união de métodos e ferramentas) que proporcionam aos gerentes de um projeto de software controle dos processos e aos engenheiros uma imensa base para desenvolvimento de softwares de alta qualidade com produtividade.

Projetos de softwares podem ser coisas simples e bastante especificas até sistemas complexos e bastante grandes, o que envolve metodolias diferentes aplicadas a grandes ou varias equipes, logo o conhecimento e aplicação de metodologias, processos e técnicas tornam-se indispensaveis para se manter um ambiente saudável. Enfim engenharia de software é uma maneira concentrada e objetiva de se desenvolver software usando de alguns artifícios para se chegar a um produto (software) de boa qualidade em tempo e custos viáveis.

Errar é humano, disso não há dúvidas, no entanto não são só as pessoas que erram, máquinas também (se você nunca viu antes de morrer verá, não se preocupe) mas até onde o famoso “vai tentando que uma hora dá” é aceitável no processo de desenvolvimento de software e que impacto isso pode acarretar?

Problemas são normais e ocorrem mesmo a todo instante, às vezes nos deparamos com situações nunca vivídas e não sabemos muito bem como lidar com elas, pois é ai que vem a dúvida, procurar ajuda técnica (colegas, livros, manuais, tutoriais, wikis) ou vamos tentando resolver até que uma hora conseguimos?

Pois bem, a uma série de coisas a considerar, algumas delas seriam: se alguém depende da sua parte do projeto para continuar, se a documentação está acessível, se seu tempo lhe permite parar para estudar um pouco, qual o impacto que uma solução mal feita e inconcistente (gambiarra) pode causar ao projeto.

Tentar uma forma simples de solucionar o problema pode ser uma saída fácil, porém muitas vezes empregamos tempo e esforço demais sem sucesso o que causa atraso no projeto sendo que este tempo empregado pode ser mais que o suficiente para estudar e chegar a uma solução descente e satisfatória do problema garantindo qualidade ao projeto.

No entanto muitas vezes o problema é tão simples que nada impede de tentarmos resolvê-lo com o que “achamos” ser uma solução pláusivel desde que não prejudique ninguém. Nesta área é interessante aplicar tentativa e erro pois geralmente o projeto que esta sendo trabalhado não influi no ambiente da empresa ou do cliente como nos setores de TI.  Tentar e errar é normal desde que seja feito com bom senso e não se passe o dia em cima de um problema e deixe todo o resto de lado.

Para quem ainda não sabe o Carlos Eduardo da e-Genial teve a brilhante idéia e iniciativa de promover uma maratona de palestras online através do TreinaTOM, sistema de treinamento online desenvolvido por ele e sua empresa. As palestras vinham acontecendo toda sexta-feira a noite e agora graças a Deus foram transferidas para o sábado. Dia 18/08 é um dia especial com palestras o dia todo. Confira a grade abaixo:

Manhã

09:00 às 10:00

Título : Web Semântica com Ruby on Rails
SubTítulo : Aplicações e Sites mais Inteligentes, aprenda como ela está
mudando os processos de indexação, editoração e recuperação da informação.
Palestrante: Charleno Pires
Tempo para perguntas e respostas: 10 minutos

10:10 às 11:10

Titulo: XP + Rails = produtividade ao extremo na web
SubTítulo: Projeto Lucidus: Desenvolvendo aplicacoes web com maxima
produtividade usando Extreme Programming e Ruby on Rails
Palestrante: Vinícius Manhães Teles
Tempo para perguntas e respostas: 10 minutos
11:20 às 12:20

Título: Ruby off Rails - O outro lado da moeda
SubTítulo: Um overview da aplicabilidade da linguagem em ambiente de
telefonia IP(VoIP), desempenho, restrições, padrões, deploy, etc.
Finalizando com estudo de casos dos projetos abertos RubyGhostEngine(rghost)
- Document Builder, RailsTree, JsDOMenu e outros projetos futuros.
Palestrante: Shairon Toledo
Tempo para perguntas e respostas: 10 minutos

Tarde

13:30 às 14:30

Título: O que há de novo no Flex 3?
SubTítulo: Veja todas as novas funções que o Flex 3 pode oferecer e tire
proveito disso.
Palestrante: Igor Costa
Tempo para perguntas e respostas: 10 minutos
14:40 às 15:40

Título: Desenvolvimento orientado a componentes
SubTítulo: Entenda o modelo de desenvolvimento de componentes do Adobe Flex
Palestrante: Beck Novaes
Tempo para perguntas e respostas: 10 minutos

15:50 às 16:50

Título: Flex nas empresas
SubTítulo: Uma nova roupagem para o velho
Palestrante: Rogério Oliveira (Sócio Diretor da Zellen)
Tempo para perguntas e respostas: 10 minutos

17:00 às 18:00

Titulo: Rails Stand-Alone
SubTítulo: Introdução a Slingshot e acts_as_replica
Palestrante: AkitaOnRails
Tempo para perguntas e respostas: 10 minutos

18:10 às 19:10

Título: Linguagens de programação: passado, presente e futuro
Subtítulo: O que você deve saber sobre linguagens de programação e como
elas impactam o seu desenvolvimento e carreira; quais são as prováveis
linguagens do futuro e como fazer as melhores escolhas; ambientes
multi-linguagem e produtividade; o passado no futuro: ressurgência de
temas; paradigmas e produtividade; a próxima grande revolução.
Palestrante: Ronaldo Ferraz
Tempo para perguntas e respostas: 10 minutos

Como podem ver a grade é bem preenchida por assuntos muito bem escolhidos e apenas feras no elenco de palestrantes, já sou presença confirmada e não perco por nada, se você se interessa por algum dos assuntos citados acima não pode perder.

Você conhece Caindo na Real(Getting Real)?

Se não conhece na integra pode ter certeza que já viu alguns dos conceitos (se não todos) aplicados na WEB.

Caindo na Real é um livro escrito pelo pessoal da 37signals, desenvolvedores do Basecamp, RubyOnRails e diversos outros serviços. O livro trata de metodologais, boas práticas, truqes de marketing e dicas para se criar serviços WEB de qualidade.

Cansamos de ver na WEB serviços com visual poluído, confuso, com uma penca de funcionalidades que nunca usamos ou nem sabemos para que serve , documentação é tão escondida e inácessivel que ninguém tem coragem de se aventurar nos FAQ’s com 500 tópicos.

Pois é disso que o livro trata, como criar serviços simples, usáveis, intuitivos e diretos, sem “gordura”, sem entulho visual e funcional.

Como citei no início, você já deve ter visto serviços do Google, Wikipedia e o próprio Wordpress, pois o livro é um manual descritivo da metodologia usada em serviços como estes, o lema é: mantenha as coisas simples e somente o necessário.

Propaganda é cara e nem sempre traz o resultado esperado, então utilize um blog, antes mesmo de ter o produto, divulge a idéia, criar espectativa como as grandes empresas fazem, a alma é uma propaganda barata e que efetivamente dá resultado. Estas empresas já cairam na real e isto está ao alcance de todos.

Equipes são difíceis de gerenciar e manter, então mantenha-se simples, gente demais atrapalha, caso o prazo seja curto, revise escopo e retire “gordura”, não precisa eliminar funcionalidades, apenas adiá-las um pouco. Assim que tiver algo funcionando já disponibilize, bugs vão ocorrer, na medida do possível concerte-os.

Seja honesto com seus clientes, qualquer problema que ocorra na aplicação ou servidor, não tente esconder, conte a seus clientes, mantenha transparente perante eles e ganhe sua confiança.

O livro trata de tópicos como este e muitos mais, a leitura é altamente recomendada, quem se interessar pode conferir o livro aqui.

Eu já cai na real e meus próximos projetos ja demonstraram isso, e você?