Uma boa opção para definir e customizar processo de engenharia de software

Se queremos produzir com apoio de uma ferramenta um processo de engenharia de software customizado no que a empresa necessita, pode-se atualmente encontrar com boa qualidade.

O Eclipse Process Framework (EPF) visa produzir um software com características próprias, fornecendo ferramentas e conteúdo que pode ser usado como base para uma grande variedade de processos de TI a fim de resolver necessidades. O EPF ajuda na autoria de métodos, ferramentas, processos, gestão de configuração de bibliotecas de métodos para processo e publicação de processos. O Framework conta com exemplos de processos prontos para serem adaptados, reutilizados a processos de desenvolvimento de software e ferramentas que são suportadas por vários tipos de projetos e formas de desenvolvimento. Ao usar EPF Composer pode-se criar o seu próprio processo de desenvolvimento de software e estruturá-lo em sentido específico, usando um esquema predefinido, aderente ao processo a ser registrado. Este esquema é uma evolução da Software Process Engineering Meta-Model (SPEM 1.1) de especificação referida, como o da Arquitetura do método unificado (UAM - Unified Architecture Method). Grandes partes da UAM foi recentemente adaptada para a revisão da SPEM e o EPF Composer irá apoiar plenamente o SPEM 2.0 em futuro próximo. A UAM e a SPEM são projetos de apoio à organização, com grande quantidade de descrições de métodos e processos de desenvolvimento.

Os projetos individuais de diversas organizações de desenvolvimento de software podem facilmente transferir e implantar os processos capturados no EPF. Eles podem personalizar processos existentes através da mistura de correspondência de conteúdo de vários processos, por remoção, adição ou personalização de conteúdo através da aplicação de conteúdos fornecidos por plug-ins. Os processos resultantes podem facilmente ser implantados, e continuamente evoluir, acomodando as lições aprendidas à medida que o projeto avança.



Definição do Processo com o auxilio do EPF Composer


O processo foi definido com a intenção de ser mais leve possível, mantendo entretanto a formalidade necessária para o desenvolvimento flexível, ágil e estável.

Como visto anteriormente a grande particularidade do EPF Composer é a categorização dos elementos padronizados no SPEM, em dois conceitos principais. São eles: Method Content e Process.

O Method Content descreve o que deve ser produzido (WorkProduct), as competências necessárias exigidas (roles), e as instruções passo-a-passo (steps) explicando como os objetivos serão atingidos. Process descrevem o desenvolvimento do ciclo de vida, relacionando os elementos dos Method Contents em seqüências semi-ordenadas que são personalizadas para determinados tipos de projetos.

Ao definir o processo no EPF foi criado primeiramente o plug-in, que poderia ser denominado hipoteticamente como PDS ou Processo de Aquisição de Software. Posteriormente foi criado a estrutura de pacotes dentro do Method Content que, nesse


caso, foram as etapas do processo definido levando em consideração o ciclo de vida do projeto, por exemplo: requisitos funcionais e não-funcionais, projeto, desenvolvimento, etc.. Cada pacote é expresso usando WorkProduct (artefato), role (papel), task (tarefa) e guidance (guia) relativo a sua etapa do processo assim como pode ser observado na figura abaixo. Os guias estão posicionados na interseção entre Method Content e Process, pois podem expressar informações para as duas categorias definidas no EPF.


Iniciando uma instância do projeto a partir do processo definido no EPF


Na utilização do processo publicado através da ferramenta EPF podemos constatar um ambiente rico em conhecimento, contemplando, todas relações entre papeis, tarefas, artefatos e guias, permitindo obter mais detalhe sobre cada item do processo. Ainda é possível verificar as relações das fases como, por exemplo, inspeção e as atividades envolvidas, Gerenciamento, Modelagem de Negócio e Requisitos. Podemos verificar claramente tal situação, como ilustra a figura abaixo.



Um ponto forte na utilização do processo publicado foi à possibilidade de desempenharmos papeis mesmo estando separados geograficamente, através da uma intranet. Isso facilitou o desenvolvimento do projeto, principalmente nas tarefas de curto prazo.

Os guias podem ser uma grande ajuda uma vez que, tornam-se indispensáveis na busca de informações para desempenhar de forma eficaz algumas atividades, como por exemplo, em uma fase, etapa projeto, na atividade de definição de casos de uso, onde sentimos a necessidade de obter exemplos da especificação e diagrama de caso de uso ou de um outro diagrama dinâmico ou estático.

O processo definido no EPF Composer, aponta diversas vantagens com pode ser visto, atendendo a todas as nossas expectativas e superando as nossas necessidades, proporcionando assim, uma resposta rápida e eficaz as demandas dos stakeholderes.

Era uma vez o Java...será ????

Desde meu ínicio na carreira em Tecnologia da Informação, desde 1993 quando tive meus primeiros contatos com estágios não remunerados e remunerados em linguagem de programação e o mundo profissional de tecnologia da informação, com linguagens como C Standard para Unix e MS-Windows, Clipper 5.2d, lembram ??? MUMPS para AIX...bem eu começava em 1997, já antes do Java programava algumas automações de backup e aplicações de baixa complexidade em Python e SmallTalk com a ferramenta da IBM...também lembram ??? Assim comecei a ouvir de professores, colegas sobre a linguagem OAK ...mais tarde o Java, o querido Java do nosso depois mascote Duke que reuniria funções, tecnologias de linguaguens como C, C++, SmallTalk enfim ...uma boa invenção do nosso colega James Gosling, não vou ficar aqui fazendo trilha das linguagens que implementei e conheço e propaganda de uma linguagem e plataforma de desenvolvimento como o Java, não precisa não é ????
Mas então a Oracle conseguiu ??? O que ???
Iniciar a ação predatória dos cientistas da antiga SUN, cientistas tem seus métodos, seus cronogramas que não são parecidos com os cronogramas do mundo MakeBizz, não é ? Hoje podemos dizer que se a SUN não conseguir equalizar esta falta que Gosling fará ao projeto e sua continuidade, teremos muitas baixas de empresas que irá preferir estar com tecnologia similares como o Python e estável em sua continuidade, veja não entendem que estou querendo dizer o Java terminou, não é isso...mas sem Gosling perderá força !
A Oracle tem seu jeitão e não mudará já fez isto com o Weblogic, o servidor de aplicação mais estável na minha opnião profissional e hoje o Weblogic já mostra a nova cara com o jeitão da Oracle, não sei mais esperamos que a essência do Java não seja dilacerada.

Abaixo posto o blog pessoal do sr. James Gosling :
http://nighthacks.com/roller/jag/


O mundo do desenvolvimento de software hoje tem de abstrair estes STACKs de linguagens e convergir em uma unica notação ...