Biomarkers of exposure and effects of pollutants in blue mussels 569

Um dos primeiros processos de software existente foi o modelo cascata. Este processo proposto por Royce (1970 p.329) é dividido em fases, que não se repetiam ao longo do ciclo de vida conforme a figura 1 abaixo.

Figura 1 - Processo Cascata (Royce, 1970 p.329)

O processo cascata tornou-se conhecido na década de 70 e é referenciado na maioria dos livros de engenharia de software. As atividades são estruturadas numa cascata onde a saída de uma é a entrada para a próxima.

É criticado por ser linear, rígido e monolítico. Inspirados em modelos de outras atividades de engenharia, este processo argumenta que cada atividade apenas deve ser iniciada quando a outra estiver terminada e verificada.

Ele é considerado monolítico por não introduzir a participação de clientes e usuário durante as atividades do desenvolvimento, mas apenas o software ter sido implementado e entregue. Não existe como o cliente verificar antecipadamente qual o produto final para detectar eventuais problemas.

A versão original foi melhorada e retocada ao longo do tempo e continua sendo muito utilizada hoje em dia. Grande parte do sucesso do cascata está no fato dele ser orientado para a documentação.

No entanto, considerando o monitoramento e controle neste processo de software, não apresenta nenhuma atividade para retratar que estamos desenvolvendo de forma correta o software e se a gestão de projetos neste sentido está sendo aplicada.

Uma evolução do processo cascata foi o processo espiral, pois, repetia as fases ao longo do ciclo de vida. O grande número de fases do processo em espiral inviabilizou o seu uso na prática, pois, necessitava de um tempo para manter o processo longo sem ter a entrega do produto de software.

O processo iterativo e incremental é uma extensão do espiral que foi proposto por Boehm em 1988, como forma de integrar os diversos modelos existentes à época, eliminando suas dificuldades e explorando seus pontos fortes, sendo que foi desenvolvido para abranger as melhores características tanto do cascata como o prototipação que será visto posteriormente.

Segundo essa abordagem iterativo e incremental, o processo divide o desenvolvimento de um produto de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas às fases de análise, projeto, implementação e testes em contraste com a abordagem clássica, na qual as fases de análise, projeto, implementação e testes são realizados uma única vez.

Os requisitos são desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No próximo ciclo, 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é o sistema completo esteja construído.

Esta abordagem incremental e iterativa incentiva à participação do usuário nas atividades de desenvolvimento de software, o que diminui em muito a probabilidade de interpretações erradas em relação aos requisitos levantados com a vantagem de que os riscos do projeto podem ser bem gerenciados conforme a figura 2 abaixo.

Figura 2 - Processo Iterativo e Incremental (Bezerra, 2002 p.37)

O processo de software baseado na prototipação procura suprir as limitações do modelo cascata, ou seja, ao invés de manter inalterado o requisito durante o projeto e codificação, um protótipo é desenvolvido para ajudar no entendimento dos requisitos.

Este desenvolvimento passa por um projeto, codificação e teste, sendo que cada uma destas fases não é executada formalmente. Usando assim os protótipos, o cliente pode entender melhor os requisitos do sistema.

O protótipo é desenvolvido com uma versão inicial do documento de especificação dos requisitos. Depois de pronto, o cliente verifica e o utiliza indicando quando algo estiver faltando, e o que não é preciso.

Então o protótipo é modificado incorporando as sugestões de mudança e o cliente usa o protótipo novamente repetindo o processo até que o mesmo seja válido em termos de custo e tempo.

No final os requisitos iniciais são alterados para produzir a especificação final dos requisitos. A sequência de eventos para o processo de prototipação é ilustrada na figura 3. Como todas as abordagens ao desenvolvimento de software, o de protótipos inicia-se com a obtenção dos requisitos.

Figura 3 - Processo de Prototipação (Pressman, 1995, p.36) Para Pressman (1995 p.37), este modelo pode trazer alguns benefícios:

2. a chave é definir as regras do jogo logo no começo, ou seja, o cliente e o desenvolvedor devem concordar que o protótipo seja construído, servindo com a finalidade de definir os requisitos;

3. a prototipação é um processo que capacita o desenvolvedor a criar um software que será implementado

4. ele será depois descartado (pelo menos em parte) e o software real será projetado, levando-se em conta a qualidade e a manutenibilidade. 5. a escolha de um processo deve considerar as características do

contexto de projeto ao qual será aplicado.

Considerando as diferenças entre os processos de software, McConnel (1996, p. 154), apresenta diversas questões que devem ser respondidas ao selecionar um:

1. Qual o nível de compreensão dos usuários e desenvolvedores em relação aos requisitos no início do projeto?

2. É provável que a compreensão mude significativamente durante o desenvolvimento do projeto?

3. Qual o nível de compreensão dos desenvolvedores em relação à arquitetura do sistema?

4. É provável que mudanças na arquitetura do sistema ocorram no meio do caminho?

5. Qual nível de confiança é necessário?

6. O quanto é necessário planejar e projetar durante o projeto prevendo mudanças em versões futuras?

7. Qual o nível de riscos implícitos no projeto? 8. Pode ser limitado em um cronograma?

10. É necessário mostrar ao cliente o progresso durante o projeto?

11. É necessário demonstrar ao usuário aspetos gerenciais durante o projeto? Para auxiliar nas respostas a essas questões, McConnel (1996) apresenta uma tabela na qual são apresentadas as vantagens e desvantagens, utilizando uma escala para classificá-los que varia entre “deficiente”, “bom” e “excelente”, em relação às questões apresentadas acima.

Capacidade do Processo Cascata Iterativo Prototipação

Trabalha com a compreensão deficiente

dos requisitos Deficiente Excelente Excelente Trabalha com a compreensão deficiente

da arquitetura Deficiente Excelente

Deficiente para bom Produz sistemas de alta confiança Excelente Excelente Bom É fácil modificar o sistema em versões

futuras Excelente Excelente Excelente Gerencia riscos Deficiente Excelente Bom Pode ser limitado em um cronograma

predefinido Bom Deficiente Deficiente Permite correções no meio do projeto Deficiente Bom Excelente Possibilita ao cliente visibilidade do

progresso Deficiente Excelente Excelente Possibilita ao cliente visibilidade do

progresso do gerenciamento Bom Excelente Bom Requer pouca gerência ou experiência

para usá-lo Bom Bom Deficiente

Tabela 1 - Comparação dos Processos de Software (McCONNEL, 1996)

Identificamos nestas respostas se o monitoramento e controle está atribuído aos processos de software, e constatamos que de certa forma ele é aplicado, porém, em algumas respostas existem situações em que os processos possuem algum item deficiente.

O processo de software unificado é um conjunto de atividades executadas para transformar um conjunto de requisitos do cliente em um sistema de software. Entretanto, o processo unificado também é uma estrutura genérica de processo que pode ser customizado adicionando ou removendo atividades com base nas necessidades específicas e nos recursos disponíveis para o projeto (SCOTT, 2003, p.19).

O processo unificado da Rational (RUP) é um exemplo da versão especializada do processo unificado que adiciona elementos à estrutura genérica. O RUP foi desenvolvido por Ivar Jacobson, Grady Booch e James Rumbaugh, com a intenção de ser um “conjunto de filosofias e práticas para o desenvolvimento de software bem sucedido”.

Na prática, o RUP é um processo proprietário da empresa IBM2 bastante conhecido e normalmente aplicado em médias e grandes organizações. (Jacobson et al, 2007)

O RUP utiliza a abordagem iterativo e incremental sendo personalizável de acordo com as necessidades específicas do desenvolvimento de software. Baseado no paradigma de desenvolvimento orientado a objetos, com especificação utilizando a notação UML - Unified Modeling Language (Linguagem Unificada de Modelagem). O RUP implementa as práticas de engenharia de software através de uma abordagem em duas dimensões conforme a figura 4.

A dimensão horizontal representa o tempo e divide o ciclo de vida de desenvolvimento em quatro fases: Concepção, Elaboração, Construção e Transição.

2 _{International Business Machines (IBM) é uma empresa dos Estados Unidos voltada para a área de}

informática. Um das poucas da área de Tecnologia da Informação (TI) com uma história contínua que remonta ao século XIX. A IBM fabrica e vende Hardware e Software, oferece serviços de infra-estrutura, serviços de hospedagem e serviços de consultoria nas áreas que vão desde computadores de grande porte até a nanotecnologia.

Figura 4 - Processo Unificado RUP (2007)

A dimensão vertical representa as disciplinas: Modelagem de Negócio, Requisitos, Análise e Design, Implementação, Testes, Implantação, Gerenciamento de Configuração e Mudança, Gerenciamento de Projeto e Ambiente.

As disciplinas definem o que deve ser feito pelos responsáveis em termos de atividades e artefatos3_{. Uma facilidade que o RUP apresenta é o fornecimento}

de modelos (templates) para cada artefato e roteiros (guidelines) para o cumprimento das atividades.

3 _{Artefatos são códigos executáveis, códigos fonte, especificação de interfaces, documentações, diagramas}

e planos que são produzidos ao longo das diferentes fases do processo de desenvolvimento de software (Oliveira e Elias, 2008).