Ciclo de Vida de Processos de Software no ImPProS
2.1 Trabalhos Relacionados
São várias as experiências relatadas na literatura referentes à automação no contexto de Ambientes de Desenvolvimento de Software, sobretudo aqueles ditos centrados em processo. As diferentes pesquisas de construção de PSEE têm abordado desde a modelagem de processos até o controle de sua execução e alteração. A seguir, as principais características de algumas iniciativas acadêmicas e da indústria de PSEEs são discutidas no contexto das funcionalidades (arquitetura, recursos oferecidos e outros aspectos) que influenciam a concepção destes tipos de ambientes, para permitir uma análise das características oferecidas pelo ambiente ImPProS. A Seção 3.1 discutirá algumas iniciativas providas por estes PSEEs no contexto da definição de processos de software.
O ambiente EPOS [Conradi.00] é um ambiente orientado a processos que permite modelagem de processos e gerência de configuração. Esse ambiente foi desenvolvido com ênfase em gerência de processo de software para múltiplos usuários. Sua arquitetura contém uma interface comum entre o usuário e as várias ferramentas bem como um gerente de atividades. Um modelo de processos no EPOS é basicamente uma rede de atividades cujos nodos são descrições de tarefas interligadas e decompostas.
O ambiente Endeavors [Taylor.99] é um ambiente orientado a processos com enfoque em questões de distribuição, comunicação e coordenação. O projeto do ambiente foca em mecanismos para apoiar a distribuição de processos e usuários, integração de ferramentas, adoção incremental de novas tecnologias, customização e reutilização de componentes de processo e suporte à configuração dinâmica do processo. Este ambiente usa uma linguagem criada para aumentar a coordenação de equipes durante o processo de software e aumentar o controle do processo através de uma representação mais precisa.
Já o SPADE [Bandinelli.96] é um projeto que tem como objetivo prover um ADS orientado a processos que permita análise, projeto e execução de modelos de processo. O principal conceito do projeto foi a adoção de Redes de Petri estendidas para prover a execução automatizada do processo de software. Ele definiu uma linguagem específica para a modelagem de processos chamada SLANG e que possui uma arquitetura aberta que permite a introdução de novas ferramentas. O ambiente SPADE inclui um interpretador de processo capaz de executar modelos de processo escritos em SLANG. O ambiente de interação com usuário gerencia a interação entre usuários e ferramentas no ambiente.
Capítulo 2 Ciclo de Vida de Processos de Software no ImPProS
O Adele/Tempo [Estublier.00] é composto de banco de um dados contendo técnicas, métodos e padrões da engenharia de software, um gerente de atividades e um gerente de processo. Tais componentes são integrados através da linguagem Tempo que descreve o esquema de dados e o modelo comportamental do sistema. O desenvolvimento de Adele foi focalizado na integração de dados (as ferramentas compartilham informações através de um mesmo formato de dados) e de controle (as ferramentas devem ser capazes de exercer influência sobre outras), através da construção de um banco de dados ativo de engenharia de software e, mais recentemente com foco em integração de processos.
O ProcessWeaver [Christie.97] provê ferramentas para gerenciar tarefas individuais e automação do processo. Para o usuário do ambiente é provida uma janela chamada Agenda, através da qual as tarefas são alocadas para os usuários. O suporte à execução de processos compreende desde a definição das hierarquias de atividades, a especificação das entradas, saídas e cargos para as atividades, o detalhamento dos processos de cada atividade podendo ser modelados utilizando Redes de Petri e a definição das janelas onde os agentes executam suas atividades.
O PROSOFT [Reis.02] como sendo um ADS que tem como objetivo principal apoiar o desenvolvimento formal de software, fornecendo integração de dados, de controle e de apresentação entre suas ferramentas. As ferramentas do PROSOFT visam auxiliar o desenvolvedor de software desde a especificação de requisitos até a implementação do sistema. O uso de métodos formais é enfatizado na construção das ferramentas do ambiente PROSOFT com o paradigma próprio criado dentro do projeto. O projeto também envolve a construção de mecanismos para gerência e manipulação de processos de software;
A Estação TABA [Figueiredo.06], que tem como objetivo a construção de uma estação de trabalho configurável para o desenvolvimento de software. A sua principal motivação está no fato de que os domínios de aplicação e projetos específicos possuem características próprias, sendo fundamental que tais características estejam presentes de forma customizada nos ambientes de desenvolvimento utilizados pelos engenheiros de software para o desenvolvimento de tais aplicações;
O ExPSEE [Gimenes.02], um ambiente de engenharia de software orientado a processos que investiga tecnologias e mecanismos para modelagem e automação de processos de software. Faz parte do ExPSEE, um ambiente de programação de tarefas, implementado na
Capítulo 2 Ciclo de Vida de Processos de Software no ImPProS
linguagem TCL/Tk na plataforma Solaris. Este ambiente possibilita a programação dos processos por um gerente de projetos, permitindo que os envolvidos nas tarefas a serem programadas possam trabalhar de forma cooperativa durante a execução das mesmas;
O DiSEN [Takano.06], um ambiente de desenvolvimento de software distribuído, incorpora a tecnologia de agentes à arquitetura do ambiente. Foi projetado para utilizar, dentre outras, a MDSODI [Pacutti.02], uma metodologia para desenvolvimento de software que leva em consideração algumas características identificadas em sistemas distribuídos e mantém as principais características do Unified Process [Kruchten.03]. Oferece apoio à interoperabilidade entre as ferramentas usadas no desenvolvimento de software, permitindo que os artefatos construídos por elas possam ser reutilizados e mantidos em um formato comum ao longo do desenvolvimento do software;
O Odyssey Share [Maia.06], ambiente que possui como principal objetivo prover mecanismos baseados em reutilização de processos para o desenvolvimento de software, servindo como um repositório onde modelos conceituais, arquiteturas de software, e modelos implementacionais são especificados para domínios de aplicação previamente selecionados. O Odyssey possui um domínio muito particular, que é explorar os aspectos colaborativos no desenvolvimento baseado em componentes, através da construção de mecanismos para o suporte à interação em grupo;
O ODE [Falbo.05], ambiente centrado em processo que foi desenvolvido baseado em ontologias: de processo de software e da qualidade de software, usadas na fundação do ambiente. Uma das preocupações centrais do ODE é a integração de conhecimento de domínio (contexto de aplicação do processo de software), importante para prover apoio de gerência de conhecimento de domínio, fundamentando-se especialmente em sua base ontológica;
O APSEE [Reis.06], um ambiente que auxilia na modelagem e execução de processos de software e tem outras características em desenvolvimento para auxiliar simulação, reutilização e instanciação de processos. O ambiente traz como contribuições principais a flexibilidade durante a execução aliada ao aumento da automação na gerência de processos de software. A proposta é baseada em um meta-modelo unificado que atende as fases da evolução de processos de software e em uma arquitetura que provê vários serviços baseados neste meta-modelo.
Capítulo 2 Ciclo de Vida de Processos de Software no ImPProS
Durante a gerência de processos, as questões básicas do gerente são relacionadas ao presente (“Qual a situação do(s) processo(s) em execução?”), ao passado (“Que eventos levaram a esta situação?”) e ao futuro (“Quais as conseqüências de uma modificação ou instanciação de um processo em execução?”). Questões adicionais incluem “Como o desempenho dos desenvolvedores afeta o andamento dos processos?” e “Quais os recursos disponíveis e/ou mais adequados?”. Através da análise destas expectativas foi possível adotar uma coleção de requisitos para PSEEs (discutidos em [Curtis.92, Young.94, Avrilionis.96]) que são listados a seguir e serviram como comparativo, exposto na Tabela 2.1, entre os ambientes discutidos nesta seção:
• Permitir diferentes visões de processos: para prover diferentes projeções de um modelo de processo descrito em uma linguagem de modelagem de processos de software, de acordo com uma característica bem definida em diferentes níveis de detalhe;
• Mostrar o estado atual e o histórico do processo: requisito relacionado à acessibilidade do sistema em situações relacionadas com o estado atual (presente) e o histórico anterior (passado) dos processos, para possibilitar a reversibilidade, registro de decisões e estruturação das informações;
• Permitir modificação dinâmica do processo durante a execução: permitir diferentes tipos de interação para que um gerente altere um processo em execução, e fornecer feedback ao gerente acerca das conseqüências das alterações;
• Fornecer independência do formalismo de modelagem de processos: para possibilitar a visualização do processo em execução pelo gerente independente do paradigma da linguagem de modelagem de processo adotada;
• Fornecer monitoração de eventos e tratamento de exceções à execução de
processos: para enfatizar a percepção dos desvios, em relação ao planejado pelo
gerente, e estabelecer mecanismos para prever um tratamento automático de acordo com as políticas da organização, ou restrito a um projeto ou tipo de processo.
Capítulo 2 Ciclo de Vida de Processos de Software no ImPProS
Tabela 2.1 Comparativo de alguns PSEEs
Ambientes Centrados no Processo /
Requisitos para PSSEs
E P O S E nd ea vo rs SP A D E A de le /T em po P ro ce ss W ea ve r P R O SO F T E st aç ão T A B A E xP SE E D iS E N O dy ss ey S ha re O D E A P SE E Permitir Diferentes Visões de Processos √ √ √ √ √ √ √ √ √ √ √ √ Mostrar o Estado Atual
e o Histórico do Processo √ √ √ √ √ √ √ √ Permitir Modificação Dinâmica do Processo durante a Execução √ √ Fornecer Independência do Formalismo de Modelagem de Processos √ √ √ √ √ √ √ √ √ √ √ √ Fornecer Monitoração de Eventos e Tratamento de Exceções √ √ √ √ √ √ √ √ √ √
O fato da grande maioria dos ambientes tidos como parâmetro na comparação não apresentarem o requisito “Permitir Modificação Dinâmica do Processo durante a Execução” deve-se ao fato de que os mesmos não contemplam os três parâmetros, na sua totalidade, que caracterizam este requisito: reversibilidade, registro de decisões e estruturação das informações; o que representa um ponto fraco comum a alguns destes ambientes.
No entanto, o que representa uma maior deficiência nas iniciativas existentes é a falta de apoio automatizado ao usuário de todas ou algumas das fases de implementação do processo de software (definição, simulação, execução e avaliação) caracterizadas pela literatura [Osterweil.87]. Alguns ambientes até apresentam todas estas fases, como é o caso do EPOS, ProcessWeaver, PROSOFT, APSEE, DiSEN, Odyssey Share, porém a falta de um ciclo de vida automatizado para guiar os usuários na realização de cada uma destas fases dentro de um programa de melhoria de processo de software e o fato destes ambientes não disporem em seus meta-modelos do uso de modelos e padrões internacionais que orientem a garantia da qualidade do processo, faz com que estes ambientes não sejam usados por muitas organizações de desenvolvimento de software.
Capítulo 2 Ciclo de Vida de Processos de Software no ImPProS
Assim, o ambiente ImPProS, apesar de ser um framework conceitual com algumas das fases, ainda, em estado de implementação, surge como um diferencial pois agrega valor nos pontos não cobertos pelos ambientes citados na Tabela 2.1, incluindo: um ciclo automatizado que orienta o usuário ao longo de todas as fases de implementação do processos de software, o que possibilita uma adequação do ambiente às fases requeridas pela literatura especializada; a aderência dos serviços do ambiente ao programa de melhoria da qualidade organizacional com foco no uso de modelos e normas da qualidade e as recomendações dos ativos existentes nestes procedimentos para a implementação progressiva do processo de software; a definição de uma estrutura de integração flexível no contexto dos serviços disponíveis e dados gerados, permitindo a adaptação de qualquer ferramenta ao repositório do ambiente; a especificação de um conjunto de ferramentas de suporte ao gerenciamento (reuso, melhoria contínua, aquisição de conhecimento, análise de problemas, transformação/conversão) do processo de software, desenvolvidas independentemente da estrutura do ImPProS; além dos requisitos listados anteriormente na Tabela 2.1, onde alguns encontram-se atualmente em fase de desenvolvimento.