O primeiro passo para a definição de um processo de software é a especificação de suas informações. Isto envolve escolher um conjunto de elementos tais como
atividades, tarefas, produtos de trabalho e papéis, combinando e organizando estes elementos em fluxos de trabalho para a construção ou manutenção de um produto de software [Jac01]. Nesse estágio, deve-se considerar as tecnologias utilizadas pela organização onde o processo será utilizado, os tipos de software desenvolvidos, o domínio de aplicação, o grau de maturidade (ou capacitação) da equipe em engenharia de software, as características próprias da organização e as características dos projetos e das equipes [Hum89], [Mac00] e [Roc01].
Tipicamente, para definir um processo de software as organizações de TI podem se utilizar de processos off-the-shelf, tais como RUP e OPEN, os quais estão disponíveis na literatura e especificam as melhores práticas de engenharia de software. Os referidos processos podem ser adotados por completo, ou podem ainda, ser adaptados de acordo com as características da organização. Faz-se possível, também, que uma organização baseie-se em mais de um desses processos mencionados para especificação de seu ou, ainda, que especifique seu processo próprio, através de consultorias ou de um grupo de processos de software interno.
Independente da estratégia escolhida para a definição do processo, além da especificação de suas informações, torna-se necessário também a sua modelagem. Modelar um processo de software consiste em representar as informações deste, utilizando alguma linguagem de modelagem de processos [Rib02]. Uma linguagem de modelagem de processos (em inglês Process Modeling Language – PML) tem como objetivo apoiar a representação de diversos conceitos que caracterizam um processo de software [Cug98].
Atualmente, uma grande quantidade de linguagens de modelagem de processos está disponível na literatura, mas, nos últimos anos, em uma tentativa de padronização destas linguagens muitos pesquisadores e profissionais da área têm adotado o uso da UML como PML [Hsu08]. Já em 1999, Franch e Ribó [Fra99] definiram a UML como uma linguagem emergente que havia despertado um grande interesse por parte da indústria e academia e estava se tornando, de fato, um padrão na área da modelagem de processos. Nesse sentido, a popularização da UML, como linguagem para modelagem de processos, deve-se principalmente ao fato de importantes processos terem sido modelados, utilizando essa linguagem. Esse é o caso, por exemplo, dos processos RUP e OPEN, os quais possuem metamodelos de processos representados com diagramas de classe da UML [Kru00] e [Fir02]. Outro fato que contribuiu para o aumento do uso da UML
como PML foi a definição do metamodelo de processos SPEM [Omg02] e [Omg07a]. Este metamodelo, que teve sua primeira versão publicada em 2002, encontra-se hoje na versão 2.0 e, como já dito anteriormente, é tido como referência para a definição de processos de software.
Uma vez que o metamodelo SPEM 2.0 será utilizado nesta pesquisa para a modelagem de processos de software, a Seção 2.6 abordará alguns conceitos sobre metamodelagem e detalhará o metamodelo SPEM 2.0.
2.3.1 Estruturação dos Processos de Software nas Organizações
Seguindo com o entendimento acerca da atividade de definição dos processos de software, é importante considerar que, torna-se também necessário determinar a forma como isso será feito em uma organização de TI. Tipicamente, organizações podem optar por definir apenas um processo de software (conhecido como processo padrão de desenvolvimento de software) que servirá como base para todos os projetos ou podem ainda seguir a abordagem proposta pela área de pesquisa denominada Engenharia de Método (em inglês Method Engineering). Nesta área, os autores estabelecem a criação dos processos de software a partir de um repositório de fragmentos de processo e fragmentos de produto (conforme Seção 2.3.1.2). Cada um destes fragmentos é responsável por descrever somente uma parte do processo de software.
2.3.1.1 Processo Padrão de Desenvolvimento de Software
Um processo padrão de desenvolvimento de software é o processo que deve servir como referência para guiar a execução de todos os projetos de software dentro de uma organização. De acordo com Ginsberg e Quinn [Gin95], este é o meio pelo qual a organização expressa os requisitos que todos os processos de software dos projetos devem atender. Assim sendo, a implantação de um processo padrão apresenta vantagens, como:
Redução dos problemas relacionados a treinamento, revisões e suporte de ferramentas [Hum89];
Maior facilidade em medições de processo e qualidade [Hum89]; Maior facilidade de comunicação entre os membros da equipe [Xu05];
Melhor desempenho, previsibilidade e confiabilidade dos processos de trabalho [Xu05].
Além das vantagens acima, outro incentivo para definição de um processo padrão é que este é um dos requisitos essenciais para obtenção de alguns níveis de maturidade de importantes modelos de qualidade tais como ISO/IEC 15504 e CMMI. Segundo Borges e Falbo [Bor01], esses modelos definem um processo padrão como um ponto base a partir do qual um processo especializado poderá ser obtido de acordo com as características de um projeto de software específico.
Nesse sentido, um cenário bastante comum nas organizações de TI que utilizam um processo padrão é a utilização de processos já estabelecidos e difundidos na literatura (processos off-the-shelf). Como já mencionado anteriormente, essas organizações, muitas vezes adotam tais processos por completo ou fazem adaptações de acordo com suas características de desenvolvimento.
2.3.1.2 Engenharia de Método
A principal abordagem da área de engenharia de método é a decomposição de um processo de software em partes modulares conhecidas na bibliografia especializada, como fragmentos ou chunks de método (em alguns artigos chamados de fragmentos ou
chunks de processo). De acordo com Sellers [Sel03], esses fragmentos ou chunks ficam
armazenados em um repositório e são disponibilizados para serem selecionados durante a criação de qualquer processo de software.
O termo fragmento de método (ou fragmento de processo) foi introduzido nos estudos da área por Harmsen et al. em [Har94]. Os autores definiram um fragmento de método como uma descrição de um método de engenharia ou qualquer parte coerente
deste método. Um fragmento de método é classificado em dois tipos [Har94] e [Bri96]: os
fragmentos de processo e os fragmentos de produto. Os fragmentos de processo descrevem as ações do processo de software e podem ser representados pelas atividades e tarefas. Já os fragmentos de produto representam as estruturas dos produtos de trabalho de um processo de software. Deliverables, diagramas e modelos constituem exemplos de fragmentos de produto.
Analogamente aos fragmentos de método, alguns autores, em seus respectivos estudos [Rol96], [Rol98], [Pli98], [Ral99], [Ral01a], [Ral01b], [Ral04] e [Sel08], definiram o termo chunk de método (ou chunk de processo). Um chunk de método é uma combinação
de uma parte processo (também chamada de guideline) com uma parte produto [Sel08]. A
um forte acoplamento entre produto e processo. De acordo com Sellers et al. [Sel08], a ligação entre produto e processo do chunk de método é uma abstração de todos os tipos de ligação (produção, modificação, etc.) que a parte processo realiza sobre a parte produto de um processo de software.
Usualmente, ambos (fragmentos e chunks de métodos) são modelados utilizando um metamodelo. Muitos trabalhos, como [Ral01b], [Per05a], [Hug09] e [Kor10], propõem soluções para esta modelagem, e há também alguns autores que utilizam o metamodelo SPEM 2.0 para modelagem de fragmentos e chunks de métodos [Puv09].
Os tópicos de pesquisa em engenharia de método são muitos, entre eles, existem estudos que referenciam como os processos devem ser estruturados em uma organização de TI. Alguns trabalhos [Ral01a], [Ral03], [Mir06] e [Sel08] propõem a definição de um processo de software para cada projeto da organização. A ideia é a de que, através das técnicas para recuperação de fragmentos e chunks a partir do repositório, apenas sejam selecionados os fragmentos e chunks de método necessários a um projeto.
Nessa abordagem, todo projeto inicia com uma etapa de definição de processo em que os fragmentos ou chunks de método são selecionados e organizados para atender às necessidades específicas do projeto em questão [Sel08]. Outros autores propõem uma abordagem similar à já apresentada sobre processo padrão. Para isso, esses pesquisadores definem que um processo base deve ser estabelecido, através dos fragmentos e chunks, e tem de estar disponível para ser utilizado em todos os projetos de software.