Conceito, definição e importância de modelo de processo de software
Um modelo de processo de desenvolvimento de software, ou simplesmente modelo de processo, pode ser visto como uma representação, ou abstração dos objetos e atividades envolvidas no processo de software. Além disso, oferece uma forma mais abrangente e fácil de representar o gerenciamento de processo de software e consequentemente o progresso do projeto.
Exemplos de alguns modelos de processo de software;
Modelos ciclo de vida
Sequencial ou Cascata (do inglês waterfall) - com fases distintas de especificação, projeto e desenvolvimento.
Desenvolvimento iterativo e incremental - desenvolvimento é iniciado com um subconjunto simples de Requisitos de Software e iterativamente alcança evoluções subsequentes das versões até o sistema todo estar implementado
Evolucional ou Prototipação - especificação, projeto e desenvolvimento de protótipos.
V-Model - Parecido com o modelo cascata, mas com uma organização melhor, que permite que se compare com outros modelos mais modernos.
Espiral - evolução através de vários ciclos completos de especificação, projeto e desenvolvimento.
Componentizado - reuso através de montagem de componentes já existentes.
Formal - implementação a partir de modelo matemático formal.
Ágil
RAD
Quarta geração.
A utilização de um processo de software têm sido apontada como um fator primordial para o sucesso de empresas de desenvolvimento de software.
Para poder melhor compreender o assunto é necessário definir o que é um processo de software.
Um processo de software pode ser entendido como um conjunto estruturado de atividades exigidas para desenvolver um sistema de software. Assim Sommerville trás a seguinte definição:
"[O processo é] um conjunto de atividades e resultados associados que produzem um produto de software".
Jalote conclui que um processo de software é :
"é um conjunto de atividades, ligadas por padrões de relacionamento entre ela, pelas quais se as atividades operarem corretamente e de acordo com os padrões requeridos, o resultado desejado é produzido. O resultado desejado é um software de alta qualidade e baixo custo. Obviamente , um processo que não aumenta a produção (não suporta projetos de software grandes) ou não pode produzir software com boa qualidade não é um processo adequado."
A partir destas definições podemos considerar que de forma geral um processo de software padrão pode ser visto como um conjunto de atividades, métodos, ferramentas e práticas que são utilizadas para construir um produto de software. Na definição de um processo de software devem ser consideradas as seguintes informações: atividades a serem realizadas, recursos necessários, artefatos requeridos e produzidos, procedimentos adotados e o modelo de ciclo de vida utilizado.
Sucintamente podemos definir o processo de software (defini-lo(o processo) como um conjunto de atividades uniformizadas a serem aplicadas sistematicamente que se encontram agrupadas em fases, cada uma das quais com os seus intervenientes com responsabilidades, que possui diversas entradas e produz diversas saídas. Isto é, define quem faz o quê, quando e como para atingir um certo objetivo.
Humphrey define as seguintes razões para a definição de um processo padrão:
• Redução dos problemas relacionados a treinamento, revisões e suporte à ferramentas;
• As experiências adquiridas nos projetos são incorporadas ao processo padrão e contribuem para melhorias em todos os processos definidos;
• Economia de tempo e esforço na definição de novos processos adequados a projetos.
Fatores que influenciam a definição de um modelo de processo de software
Definição de Processos
• Há vários aspectos a serem considerados na definição de um processo de software. Nocentro da arquitetura de um processo de desenvolvimento estão as atividades-chave desseprocesso: análise e especificação de requisitos, projeto, implementação e testes, que são abase sobre a qual o processo de desenvolvimento deve ser construído. Entretanto, a definiçãode um processo envolve a escolha de um modelo de ciclo de vida, o detalhamento(decomposição) de suas macro-atividades, a escolha de métodos, técnicas e roteiros(procedimentos) para a sua realização e a definição de recursos e artefatos necessários e produzidos. Um processo de software não pode ser definido de forma universal. Para ser eficaz econduzir à construção de produtos de boa qualidade, um processo deve ser adequado aodomínio da aplicação e ao projeto específico. Deste modo, processos devem ser definidoscaso a caso, considerando-se as especificidades da aplicação, a tecnologia a ser adotada na suaconstrução, a organização onde o produto será desenvolvido e o grupo de desenvolvimento
Modelos em Engenharia de Software e Requisitos
A engenharia de software tem produzido inúmeros modelos de ciclo de vida, incluindo os modelos de cascata, espiral e desenvolvimento rápido de aplicações (RAD). Antes do modelo de cascata ser proposto em 1970, não havia concordância em termos dos métodos a levar a cabo no desenvolvimento de software. Desde então ao longo dos anos muitos modelos têm sido propostos refletindo assim a grande variedade de interpretações e caminhos que podem ser tomados no desenvolvimento de software. Neste artigo, foi decidida a inclusão destes modelos por duas razões: primeiro porque são representativos dos modelos utilizados na indústria e foi já provado o seu sucesso, e segundo porque mostram como a ênfase no desenvolvimento de software mudou gradualmente de forma a incluir uma visão mais interativa e centrada no utilizador.
O modelo de ciclo de vida em cascata foi o primeiro modelo a ser conhecido em engenharia de software e está na base de muitos ciclos de vida utilizados hoje em dia. Este consiste basicamente num modelo linear em que cada passo deve ser completado antes que o próximo passo possa ser iniciado. Por exemplo, a análise de requisitos deve ser completada antes que o desenho do sistema possa ser iniciado. Os nomes dados a cada passo variam, assim como varia a definição exata de cada um deles, mas basicamente o ciclo de vida começa com a análise de requisitos movendo-se de seguida para a fase de desenho, codificação, implementação, teste e finalmente manutenção do sistema. Uma das grandes falhas deste modelo é o fato de os requisitos estarem constantemente a mudar já que os negócios e ambiente em que se inserem mudam rapidamente. Isto significa que não faz sentido parar os requisitos durante muito tempo, enquanto o desenho e implementação do sistema são completados. Foi então reconhecido que seria necessário dar feedback às atividades iniciais a partir do momento em que este modelo começou a ser usado em grande escala. A ideia de interacção não foi incorporada na filosofia do modelo de cascata. Neste momento, é incluído algum nível de interação na maior parte das versões deste modelo e são comuns sessões de revisão entre os elementos responsáveis pelo desenvolvimento do sistema. No entanto, a possibilidade de revisão e avaliação com os utilizadores do sistema não está contemplada neste modelo.
Modelo em Espiral
Durante muitos anos, o modelo cascata foi a base da maior parte do desenvolvimento de projetos de software, mas em 1988 Barry Boehm sugeriu o modelo em espiral. Do modelo em espiral para desenvolvimento de software saltam a vista dois aspectos: a análise de risco e prototipagem. O modelo espiral incorpora-os de uma forma interativa permitindo que as ideias e o progresso sejam verificados e avaliados constantemente. Cada interação à volta da espiral pode ser baseada num modelo diferente e pode ter diferentes atividades. No caso da espiral, não foi a necessidade do envolvimento dos utilizadores que inspirou a introdução de interação mas sim a necessidade de identificar e controlar riscos. No modelo espiral para engenharia de requisitos mostra-se que as diferentes atividades são repetidas até uma decisão ser tomada e o documento de especificação de requisitos ser aceito. Se forem encontrados problemas numa versão inicial do documento, reentra-se nas fases de levantamento, análise, documentação e validação. Isto repete-se até que seja produzido um documento aceitável ou até que fatores externos, tais como prazos e falta de recursos ditem o final do processo de engenharia de requisitos.
Características de Vários Modelos
Na tabela seguinte estão sumariadas algumas vantagens e desvantagens de vários modelos de ciclo de vida utilizados em engenharia de requisitos para projectos de software:
Como acomodar o modelo em cascata e o modelo de prototipacao no modelo de processo espiral ?
Modelo Espiral e Modelo Incremental
Se a necessidade do programa for a integração de subsistemas o modelo em cascata é o mais
apropriado, juntando com a prototipação que cria protótipos facilitando o feedback com o
cliente.Correto, a prototipação é ideal em modelos que apresentem uma arquitetura bem
descentralizada e de facil integração.
Modelo Espiral e Modelo Incremental
O modelo Espiral proposto por Barry Boehm, reúne características dos modelos Cascata e Prototipação acrescentando ainda em sua base a análise de riscos. Cada giro na espiral(iniciando a partir do centro e avançando para fora) representa uma nova fase do processo. Esse processoevolutivo permite que novas versões possam ser construídas progressivamente. Tipicamente, o modelopode ser dividido em 3 ou 6 regiões. PRESSMAN (vide referências) apresenta o modelo divido em 6 regiões: comunicação com o cliente, planejamento, análise de riscos, engenharia, construção e evolução e, avaliação do cliente. O número de tarefas por regiões pode variar conforme o tamanho e complexidade doprojeto. Desta forma, o modelo pode ser adaptado conforme as características do projeto.
A adoção do modelo Espiral proporciona algumas vantagens. Teoricamente, quanto maistempo e recursos forem destinados, ou seja, quanto mais iterações na espiral, menor serão os riscos sobre o projeto. Outra vantagem em relação a modelos seqüenciais como o modelo Cascata, é a execução deatividades de verificação presentes ao final de cada iteração que permitem um melhor controle gerencial sobre o projeto. Uma desvantagem do modelo refere-se a situações em que o projeto é considerado simples e os riscos são modestos. Nesse contexto, muitos projetos não precisam da flexibilidade e gerenciamento de riscos proporcionados pelo modelo.
O modelo de ciclo de vida incremental e iterativo foi proposto como uma resposta aos problemas encontrados no modelo em cascata. Um processo de desenvolvimento segundo essa abordagem divide o desenvolvimento de um produto de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas as fases de análise, projeto, implementação e testes. Essa característica contrasta com a abordagem clássica, na qual as fases de análise, projeto, implementação e testes são realizadas uma única vez.
Cada um dos ciclos considera um subconjunto de requisitos. Os requisitos são desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No próximo ciclo, um outro subconjunto dos requisitos é considerado para ser desenvolvido, o que produz um novo incremento do sistema que contém extensões e refinamentos sobre o incremento anterior.
Assim, o desenvolvimento evolui em versões, através da construção incremental e iterativa de novas funcionalidades até que o sistema completo esteja construído. Note que apenas uma parte dos requisitos é considerada em cada ciclo de desenvolvimento. Na verdade, um modelo de ciclo de vida iterativo e incremental pode ser visto como uma generalização da abordagem em cascata: o software é desenvolvimento em incrementos e cada incremento é desenvolvido em cascata (figura).
A abordagem incremental e iterativa somente é possível se existir um mecanismo para dividir os requisitos do sistema em partes, para que cada parte seja alocada a um ciclo de desenvolvimento. Essa alocação é realizada em função do grau de importância atribuído a cada requisito.
O Processo Incremental
A noção de processo incremental corresponde à ideia de “ aumentar (alargar) pouco-a-pouco ” o âmbito do sistema. Uma boa imagem para este atributo é a de uma mansão que foi construída por sucessivos incrementos a partir de uma primeira casa com apenas duas divisões.
Um incremento não é necessariamente a adição do código executável correspondente aos casos de uso que pertencem à iteração em andamento. Especialmente nas primeiras fases do ciclo de desenvolvimento, os desenvolvedores podem substituir um projeto superficial por um mais detalhado ou sofisticado. Em fases avançadas os incrementos são tipicamente aditivos.
Ciclo de vida incremental
Ainda que muitos modelos sejam semelhantes entre os modelos de ciclo de vida, existemalguns aspectos que os diferenciam:
• Enfoque dado pelo modelo. Por exemplo, no Modelo Cascata o enfoque é dado nadocumentação e no Modelo Espiral o enfoque é dado nos riscos;
• Estratégia de desenvolvimento. Define a disposição das atividades que deverão serexecutadas para atingir um objetivo em um contexto de projeto de desenvolvimento desoftware. A disposição das atividades pode ser, por exemplo, linear (uma atividade após aoutra) como no ciclo de vida Cascata puro ou iterativa (um conjunto de atividades é repetida várias vezes até atingir o seu objetivo) como nos modelos incrementais. Outrasestratégias podem envolver a disposição das atividades em paralelo, a prototipação ou reunir as características de modelos de ciclo de vida lineares e iterativos.
Vantagens e Desvantagens dos Protótipos
Vantagens:
• Testar o layout antes de começar a programar;
• Fazer alterações rapidamente;
• Eliminar variáveis tecnológicas nos testes de usabilidade.
• Baixo custo de implementação;
• Documentação rápida.
DESVANTAGENS:
• Difícil “copiar” o comportamento de alguns elementos do interface: scrollbars, transmissão de informação através do uso de cores, animações, Rich Applications, etc...
• Durante a concepção e testes aos protótipos, não é escrita nenhuma linha de código, o que pode atrasar o tempo total disponível para o projecto;
• O aspecto dos ecrãs pode fazer com que os utilizadores (e o cliente) sinta que é um método pouco profissional;
• Não permite encontrar todo o tipo de problemas de usabilidade.
Prototipagem de Software é um processo interativo de geração de modelos de software que faz parte da análise do ciclo de vida do desenvolvimento de sistemas. É a atividade de desenvolvimento de uma versão inicial do sistema baseada no atendimento dos requisitos ainda pouco definidos, permitindo a descoberta de falhas difíceis de serem encontradas na comunicação verbal. Um processo que propõe a criação de um protótipo de software objetiva apoiar a fase levantamento de requisitos a fim de prevenir as possíveis falhas no sistema. Um protótipo simula a aparência e funcionalidade do software permitindo que os clientes, analistas, desenvolvedores e gerentes percebam os requisitos do sistema podendo interagir, avaliar, alterar e aprovar as características mais marcantes na interface e funções. Os protótipospodem ser evolutivos ou descartáveis. Na prototipagem evolutiva o sistema surge de evoluções refinadas dos protótipos enquanto um protótipo descartável é usado para descobrir problemas nos requisitos e depois é abandonado. Dentre algumas vantagens da Prototipação está a redução de custos no desenvolvimento; participação do usuário no processo de desenvolvimento; facilidade de operação do sistema, uma vez que, os usuários sabem o que esperar através do protótipo; resultados na satisfação mais elevada do usuário; diminuição de equívocos entre usuários e desenvolvedores; esclarecimento de alguns requisitos confusos. Algumas desvantagens no uso de protótipos são: a condução a uma análise insuficiente do software; os usuários esperam um desempenho do software final igual ao do protótipo; os clientes podem tornar-se unidos demais a seus protótipos.
Exemplos de modelos genéricos aplicados para gerenciar sistemas diversos
1- Sistema para controlar anti-bloqueador de sistemas de freios de um automóvel, usa-se o modelo evolucionário de prototipaçao
2- sistema de realidade virtual para apoiar a manutenção de software, usa-se o modelo por componentes, basicamente um componente de realidade virtual para construir outro
3- Sistema de contabilidade de universidade que substitui um sistema existente, usa-se o modelo de desenvolvimento evolucionário exploratório
4 - sistema interativo que permite aos passageiros encontrar o horário dos trens por meio de terminais instalados nas estacoes, neste caso a solução mais viável e a junção do modelo cascata com o modelo por componentes.
.jpg)
