PETERS e PEDRYCZ (2001), PAULA FILHO (2003) e SOMMERVILLE (2003) ressaltam que a relação dinâmica entre as atividades do processo define o seu
modelo. Em suas obras, os autores enumeram vários modelos, entre eles é possível destacar:
• Caótico, também chamado por PAULA FILHO (2003) de "codifica-remenda": Neste tipo de modelo, o desenvolvedor do software parte apenas de uma especificação (ou nem isso) e codifica o software, e à medida que erros são descobertos as correções são realizadas. O autor deixa claro que tal modelo é o mais utilizado pelos desenvolvedores, considerado atraente devido a não exigência de conceitos relacionados à visão gerencial e organizacional presente nos processos de produção (vide modelo na Figura 4.3);
Figura 4.3 – Modelo caótico (adaptado de PAULA FILHO (2003))
• Modelo cascata: Neste modelo as atividades são executadas em seqüência, o que possibilita a demarcação de pontos de controle bem definidos quando o processo é gerenciado. Considerado um modelo rígido e burocrático, em que as atividades de requisitos, análise e projeto devem ser, extremamente, consistentes, pois erros no final do projeto não são permitidos, PETERS e PEDRYCZ (2001) relatam que o modelo possui uma baixa visibilidade para o cliente, que só recebe o produto no final do projeto (vide modelo na Figura 4.4);
Figura 4.4 – Modelo cascata. Adaptado de PAULA FILHO (2003).
• Modelo incremental (apresentado por SOMMERVILLE (2003) e PEDRYCZ (2001)): Modelo definido para minimizar as deficiências advindas do modelo cascata. Neste tipo de modelo, os requisitos do produto são identificados em um instante inicial e, em seguida, as demais atividades do processo são repetidas cada vez que há uma nova versão do produto ou quando um novo módulo do software é identificado. Na relação dinâmica incremental, a confecção do produto é particionada, cada parte percorre as atividades e são apresentadas ao usuário no momento da implantação (vide o modelo na Figura 4.5);
Figura 4.5 – Modelo incremental inferido a partir dos relatos feitos por SOMMERVILLE (2003) e PETERS e PEDRYCZ (2001).
• Modelo Espiral: Neste modelo o produto é desenvolvido em uma série de iterações. BOEHM (1988) relata que cada iteração define uma volta no modelo espiral. SOMMERVILLE (2003) salienta que tal modelo combina as características positivas da gerência de documentos associados às fases do ciclo presente no modelo cascata com a sobreposição pertinente no âmbito espiral. O modelo em questão parte do princípio de que a forma do desenvolvimento de software não pode ser, completamente, determinada de antemão. Uma visão ilustrativa do modelo espiral pode ser verificada na Figura 4.6;
Figura 4.6 – Modelo espiral (retirado de PAULA FILHO (2003) p.19).
• Modelo de prototipagem: Segundo PRESSMAN (2002), este modelo se inicia com a definição dos requisitos, contemplando os objetivos gerais do software por parte do cliente e do desenvolvedor e estabelecendo as áreas mais complexas para o desenvolvimento de novas definições. Um “projeto rápido” é então realizado. O projeto concentra-se na representação daqueles aspectos do software que vão ficar visíveis ao cliente (exemplo: padrões de entradas e saídas de dados). O projeto rápido é estabelecido via protótipo, o protótipo é avaliado pelo cliente e utilizado no refinamento das áreas complexas do produto estabelecidas no início do levantamento de requisitos. Interações ocorrem à medida que o protótipo é ajustado para satisfazer os requisitos do cliente, e estas permitem ao desenvolvedor entender melhor o que precisa ser construído. Pode ser que em um determinado momento o protótipo passa a ser visto como produto1. Uma visão gráfica do modelo prototipagem é espelhada na Figura 4.7.
SOMMERVILLE (2003) apresenta o modelo de prototipagem relatado por PRESSMAN (2002) com a denominação evolucionária. O primeiro autor ressalta que:
1
Salienta-se que o protótipo tem como finalidade demonstrar os aspectos importantes do produto final. Em alguns casos ele, também, é descartado não se transformando em produto.
“o modelo evolucionário tem como base a idéia de desenvolver um implementação inicial, expor o resultado ao comentário do cliente e fazer seu aprimoramento por meio de muitas versões, até que um sistema adequado tenha sido desenvolvido. Em vez de se ter as atividades de especificação, desenvolvimento e validação em separado, todo esse trabalho é realizado, concorrentemente, com um rápido feedback por meio dessas atividades” (SOMMERVILLE
(2003) p. 39).
Figura 4.7 – Modelo prototipagem (extraído de PRESSMAN (2002) p. 29).
SOMMERVILLE (2003) relata, ainda, que o modelo evolucionário possui duas visões:
1. Desenvolvimento exploratório: Trabalhar com cliente e explorar os requisitos do produto e entregar o software pronto como produto final.
2. Fazer protótipos descartáveis: Compreender os requisitos do produto, a partir disto, desenvolver uma melhor definição de requisitos complexos desenvolvendo um protótipo, descartar o protótipo utilizado na compreensão destes requisitos. • Desenvolvimento orientado a reuso: Aborda a ampla base de componentes de
software reutilizável. Partindo dos requisitos do software, o projetista verifica quais os componentes que aderem a tais requisitos, se tais componentes não existem, eles são desenvolvidos. Tais componentes são encapsulados e reutilizáveis em um outro projeto (SOMMERVILLE (2003)). O modelo orientado a
reuso pode ser utilizado em conjunto com outros modelos, tais como incremental e o espiral.
Além dos modelos de processo apresentados por PAULA FILHO (2003), SOMMERVILLE (2003), PRESSMAN (2002), PETERS e PEDRYCZ (2001), é possível encontrar, na literatura, uma estrutura base para a definição de processo. Segundo PAULA FILHO (2003 páginas 29, 30, 31 e 32) nesta estrutura é possível verificar que o processo é composto por:
• Passo: “Divisão formal de um processo, com pré-requisitos, entradas, critérios de aprovação e resultados definidos”;
• Fase: “Divisão maior de um processo, para fins gerenciais, que corresponde aos pontos principais de aceitação por parte do cliente”;
• Iteração: “Passo constituinte de uma fase, no qual se atinge um conjunto bem definido de metas parciais de um projeto”;
• Fluxo: “Subprocesso caracterizado por um tema técnico”; • Etapa: “Passo constituinte de um fluxo”;
• Atividade: “Termo genérico para unidades de trabalho executadas em um passo”. A nomenclatura apresentada por PAULA FILHO (2003) é utilizada para a definição das unidades de trabalho que compõem o processo de produção de software por ele apresentado. Tal nomenclatura assemelha-se a do Processo Unificado da Rational (RUP) (KRUCHTEN (2003)), tanto no âmbito das fases (subprocessos gerenciais) quanto nos fluxos (suprocesso técnicos). O autor relata que uma fase é composta por uma ou mais iterações. Um fluxo é particionado em uma ou mais etapas.
Por fim, o autor apresenta um diagrama relatando a composição estrutural de um processo (vide Figura 4.8).
Figura 4.8 – Composição de um processo de produção de software (retirado de PAULA FILHO (2003) p. 28). O diagrama deve ser lido da seguinte forma: Um processo agrega uma ou mais fases e um ou mais fluxo, a(s) fase(s) agrega(m) uma ou mais iterações, o(s) fluxo(s) agrega(m) uma ou mais etapas. As etapas e as iterações são classificadas como passos.
Já DERNIAME et. al. (1999) apresentam, em seu trabalho, uma estrutura básica para a modelagem do processo, estrutura esta composta dos seguintes elementos:
• Atividade: definida como um passo de um processo. As atividades, geralmente, modificam os artefatos; elas incorporam e melhoram procedimentos, regras e políticas;
• Conjunto de artefatos a serem desenvolvidos, entregues e mantidos pelos projetos. Os artefatos também podem ser chamados de produtos;
• Recursos: Elementos necessários para que uma atividade seja realizada. No processo de produção de software, os recursos são classificados como agentes (recursos humanos) e ferramentas, estruturas computadorizadas que, tradicionalmente, devem ser utilizadas no desenvolvimento de software.
A relação entre os elementos propostos por DERNIAME et. al. (1999) pode ser verificada por meio da Figura 4.9. A leitura da figura deve ser feita da seguinte
forma: Uma atividade possui regras, ferramentas e produtos (artefatos do processo). A execução da menor unidade de uma atividade, a regra, é de responsabilidade de um agente, denominado na figura por executor.
Figura 4.9 - Composição de um processo de produção de software (adaptado de DERNIAME et. al. (1999)).
De posse das idéias apresentadas por PAULA FILHO (2003) e DERNIAME et. al. (1999) e com o objetivo de adequar a composição arquitetônica de um processo estabelecida por eles, este trabalho verifica que um processo de produção de software possui:
• Atividades: Aglomera um conjunto de tarefas que são executadas para a produção de artefatos de trabalho;
• Fluxo: Relaciona as atividade e as tarefas;
• Tarefas: Menor unidade de uma atividade, possui entradas, processo transformador e saída;
• Artefatos: Produtos de trabalho gerados pelas tarefas e, conseqüentemente, pelas atividades;
• Iteração: Atividade que tem como objetivo verificar se as definições organizacionais relacionadas à gerência do processo estão sendo atingidas;
• Ferramentas: Infra-estrutura, geralmente, computadorizada para automatizar as atividades na confecção dos produtos (artefatos).
Finalizando esta seção, um diagrama, representando a composição arquitetônica de um processo, proposta neste trabalho, é apresentado na Figura 4.10.
Figura 4.10 - Composição de um processo de produção de software (visão deste trabalho) O
diagrama deve ser lido da seguinte forma: Um processo agrega uma ou mais atividades e uma ou mais pessoas; a(s) atividade(s) agrega(m) uma ou mais tarefa(s), zero ou mais ferramentas e um ou mais fluxo(s); a(s) tarefas(s) agrega(m) um ou mais artefatos. As iterações são classificadas como atividades. O processo também está relacionado com o modelo de processo e com os padrões, normas e modelos da qualidade.
Apresentado o levantamento bibliográfico sobre processo de software, a próxima seção irá apresentar os conceitos sobre meta-processo e reuso de processo de software.