-
Notifications
You must be signed in to change notification settings - Fork 0
7 Gestão de Processos
SOMMERVILLE (2011) saliente que um modelo de processo de software é uma representação simplificada de um processo de software onde cada modelo representa uma perspectiva particular de um processo e, portanto, fornece informações parciais sobre ele.
SOMMERVILLE (2011) também apresente três modelos, e os define da seguinte forma:
-
O modelo em cascata: esse modelo considera as atividades fundamentais do processo de especificação, desenvolvimento, validação e evolução, e representa cada uma delas como fases distintas, como: especificação de requisitos, projeto de software, implementação, teste e assim por diante SOMMERVILLE (2011).
-
Desenvolvimento incremental: essa abordagem intercala as atividades de especificação, desenvolvimento e validação. O sistema é desenvolvido como uma série de versões (incrementos), de maneira que cada versão adiciona funcionalidade à anterior SOMMERVILLE (2011).
-
Engenharia de software orientada a reúso: essa abordagem é baseada na existência de um número significativo de componentes reusáveis. O processo de desenvolvimento do sistema concentra-se na integração desses componentes em um sistema já existente em vez de desenvolver um sistema a partir do zero SOMMERVILLE (2011).
Muitas vezes são usados em conjunto, especialmente para o desenvolvimento de sistemas de grande porte SOMMERVILLE (2011).
O modelo em cascata é um exemplo de um processo dirigido a planos — em princípio, você deve planejar e programar todas as atividades do processo antes de começar a trabalhar nelas SOMMERVILLE (2011).
SOMMERVILLE (2011) dividiu esse modelo em cinco parte, sendo eles:
-
1 - Análise e definição de requisitos. Os serviços, restrições e metas do sistema são estabelecidos por meio de consulta aos usuários. Em seguida, são definidos em detalhes e funcionam como uma especificação do sistema SOMMERVILLE (2011).
-
2 - Projeto de sistema e software. O processo de projeto de sistemas aloca os requisitos tanto para sistemas de hardware como para sistemas de software, por meio da definição de uma arquitetura geral do sistema. O projeto de software envolve identificação e descrição das abstrações fundamentais do sistema de software e seus relacionamentos SOMMERVILLE (2011).
-
3 - Implementação e teste unitário. Durante esse estágio, o projeto do software é desenvolvido como um conjunto de programas ou unidades de programa. O teste unitário envolve a verificação de que cada unidade atenda a sua especificação SOMMERVILLE (2011).
-
4 - Integração e teste de sistema. As unidades individuais do programa ou programas são integradas e testadas como um sistema completo para assegurar que os requisitos do software tenham sido atendidos. Após o teste, o sistema de software é entregue ao cliente SOMMERVILLE (2011).
-
5 - Operação e manutenção. Normalmente (embora não necessariamente), essa é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em uso. A manutenção envolve a correção de erros que não foram descobertos em estágios iniciais do ciclo de vida, com melhora da implementação das unidades do sistema e ampliação de seus serviços em resposta às descobertas de novos requisitos SOMMERVILLE (2011).
De modo geral, a finalização de cada estágio deve ser aprova, e somente será possível avançar nos estágios após a finalização do estágio anterior.
O desenvolvimento incrementai é baseado na ideia de desenvolver uma implementação inicial, expô-la aos comentários dos usuários e continuar por meio da criação de várias versões até que um sistema adequado seja desenvolvido SOMMERVILLE (2011).
Cada incremento ou versão do sistema incorpora alguma funcionalidade necessária para o cliente. Frequentemente, os incrementos iniciais incluem a funcionalidade mais importante ou mais urgente. Isso significa que o cliente pode avaliar o sistema em um estágio relativamente inicial do desenvolvimento para ver se ele oferece o que foi requisitado SOMMERVILLE (2011).
Segundo SOMMERVILLE (2011) o desenvolvimento incrementai tem três vantagens importantes quando comparado ao modelo em cascata:
-
1 - O custo de acomodar as mudanças nos requisitos do cliente é reduzido. A quantidade de análise e documentação a ser refeita é muito menor do que o necessário no modelo em cascata SOMMERVILLE (2011).
-
2 - É mais fáci I obter feedback dos clientes sobre o desenvolvimento que foi feito. Os clientes podem fazer comentários sobre as demonstrações do software e ver o quanto foi implementado. Os clientes têm dificuldade em avaliar a evolução por meio de documentos de projeto de software SOMMERVILLE (2011).
-
3 - É possível obter entrega e implementação rápida de um software útil ao cliente, mesmo se toda a funcionalidade não for incluída. Os clientes podem usar e obter ganhos a partir do software inicial antes do que é possível com um processo em cascata SOMMERVILLE (2011).
Porem na parte de gerenciamento essa abordagem sofre dos seguintes problemas:
-
1 - O processo não é visível. Os gerentes precisam de entregas regulares para mensurar o progresso. Se os sistemas são desenvolvidos com rapidez, não é economicamente viável produzir documentos que reflitam cada uma das versões do sistema.
-
2 - A estrutura do sistema tende a se degradar com a adição dos novos incrementos. A menos que tempo e dinheiro sejam dispendidos em refatoração para melhoria do software, as constantes mudanças tendem a corromper sua estrutura. Incorporar futuras mudanças do software torna-se cada vez mais difícil e oneroso.
Na maioria dos projetos de software, há algum reúso de software. Isso acontece muitas vezes informalmente, quando as pessoas envolvidas no projeto sabem de projetos ou códigos semelhantes ao que é exigido. Elas os buscam, fazem as modificações necessárias e incorporam-nos a seus sistemas.
Esse reúso informal ocorre independentemente do processo de desenvolvimento que se use. No entanto, no século XXI, processos de desenvolvimento de software com foco no reúso de software existente tornaram-se amplamente usados. Abordagens orientadas a reúso dependem de uma ampla base de componentes reusáveis de software e de um framework de integração para a composição desses componentes.
Existem uma divisão em estágios nesse modelo, sendo esses estágios:
-
1 - Análise de componentes. Dada a especificação de requisitos, é feita uma busca por componentes para implementar essa especificação. Em geral, não há correspondência exata, e os componentes que podem ser usados apenas fornecem alguma funcionalidade necessária.
-
2 - Modificação de requisitos. Durante esse estágio, os requisitos são analisados usando-se informações sobre os componentes que foram descobertos. Em seguida, estes serão modificados para refletir os componentes disponíveis. No caso de modificações impossíveis, a atividade de análise dos componentes pode ser reinserida na busca por soluções alternativas.
-
3 - Projeto do sistema com reúso. Durante esse estágio, o framework do sistema é projetado ou algo existente é reusado. Os projetistas têm em mente os componentes que serão reusados e organizam o framework para reúso. Alguns softwares novos podem ser necessários, se componentes reusáveis não estiverem disponíveis.
-
4 - Desenvolvimento e integraçao. Softwares que não podem ser adquiridos externamente são desenvolvidos, e os componentes e sistemas COTS são integrados para criar o novo sistema. A integração de sistemas, nesse modelo, pode ser parte do processo de desenvolvimento, em vez de uma atividade separada.
Existem três tipos de componentes de software que podem ser usados em um processo orientado a reúso:
-
1 - Web services desenvolvidos de acordo com os padrões de serviço e que estão disponíveis para invocação remota.
-
2 - Coleções de objetos que são desenvolvidas como um pacote a ser integrado com um framework de componentes, como .NET ou J2EE.
-
3 - Sistemas de software stand-alone configurados para uso em um ambiente particular.
No desenvolvimento de nosso projeto estamos utilizando um pouco de cada modelo.
No inicio do projeto planejamos e definimos tudo que deveria ser feito, como isso utilizando o Modelo em Cascata, porem ao logo do desenvolvimento fomos nos deparando com a necessidade de funcionalidades que não tínhamos previsto, sendo assim nessas partes especificas utilizamos o modelo Desenvolvimento Incremental. E por ultimo, como utilizamos alguns frameworks acabamos reutilizando códigos já prontos.
Dados a nossa forma de trabalho e a alguns imprevisto utilizamos os três modelos.