Archive for January 24, 2013

Rapid Application Development (RAD)

Posted in processo de produção de software on January 24, 2013 by José Augusto Fabri

radApós publicar o post sobre aplicabilidade do modelo cascata, recebi várias mensagens sugerindo a publicação de textos sobre os demais modelos de processo.

Sugestão aceita, neste post apresento o modelo RAD.

O RAD é caracterizado como um modelo de processo seqüencial e linear que enfatiza um ciclo de desenvolvimento do projeto extremamente curto. Neste modelo os requisitos devem ser estabilizados e o projeto é fracionado (em subprojetos) e direcionado a equipes de desenvolvimento. Estas equipes utilizam uma base de componentes com o objetivo agilizar a construção do produto.

A aplicabilidade do modelo em uma empresa exige recursos humanos suficiente para todas as equipes. Clientes e desenvolvedores também devem estar comprometidos com as atividades do processo a fim de finalizar a construção do produto num prazo curto.

Importante: Aplicações que não são passíveis de modularização não acondicionam processos instanciados a partir do modelo RAD. Lembre-se também que, durante o desenvolvimento, os módulos devem ser integrados, esta integração exige que as regras de interfaces sejam bem definidas e respeitadas.

J. A. Fabri – fabri@utfpr.edu.br

A aplicabilidade do modelo cascata na engenharia de software

Posted in processo de produção de software on January 24, 2013 by José Augusto Fabri

cascataPessoal!

Vários alunos de graduação, pós-graduação e profissionais imersos no mercado de trabalho me questionam sobre a aplicabilidade do modelo cascata na engenharia de software.

Antes de discorrer sobre o tema vale à pena definir, formalmente, processo de software.

Um processo (de software) é caracterizado por meio de um conjunto de atividades bem definidas e documentadas que quando aplicadas, sistematicamente, garantem certo grau de qualidade na confecção do produto. Além do conjunto de atividades, o processo possui outros atributos como: matéria prima, mão de obra e recursos. Tais atributos são considerados os insumos do processo de produção. Salienta-se também que o processo deve possuir o conceito de retro-alimentação com o objetivo de garantir o caráter evolutivo do mesmo.

Já um modelo de processo pode ser definido como uma representação ou abstração das atividades caracterizadas em um processo de software. Geralmente, o modelo norteia a instanciação e o sequenciamento das atividades de um processo de software.

O modelo cascata é o mais antigo utilizado pela engenharia de software. Sua composição é totalmente baseada nos ciclos que compõem um processo de produção da engenharia convencional. Este modelo propõe que as atividades que compõem o processo sejam sequencializadas e os artefatos gerados em uma atividade se caracterizam como a entrada da outra (click na figura no início do post).

Muitos engenheiros acreditam que este modelo caiu no desuso. Este texto contraria esta ideia, ou seja, o modelo cascata ainda é utilizado em vários projetos de software. Estes projetos, geralmente, são simples e pequenos, por exemplo – projeto de software para entrada e saída de produtos em uma pequena loja de roupas. Com certeza neste tipo de projeto você, em apenas uma interação, irá mapear cerca de 90% dos requisitos. E os outros 10? Eu classifico-os como melhoria daquilo que foi implementado.

Perceba que processos que seguem este modelo não são aplicáveis facilmente em projetos de médio ou grande porte, pois estes não seguem um fluxo sequencial de produção, os requisitos não são mapeados em sua totalidade no início do projeto e os stakeholders têm dificuldade em esperar por uma versão executável do software, fato este que ocorre somente na atividade de entrega do produto.

Enfim, se o projeto é simples e possui poucas funcionalidades, utilize o modelo cascata.

J. A. Fabri – fabri@utfpr.edu.br

Follow

Get every new post delivered to your Inbox.

Join 38 other followers