Modelagem de Processos de Software. Pato Branco, , Paraná, Brasil

Transcrição

1 Modelagem de Processos de Software André L. STOROLLI 1, Gislaine I. ZANOLLA 2, José E. GUIDINI 3, Beatriz T. BORSOI 4 1,2,3,4 Coordenação de Informática, grupo de pesquisa GETIC, Universidade Tecnológica Federal do Paraná Pato Branco, , Paraná, Brasil RESUMO Processos de software adequadamente definidos auxiliam a prever os resultados no desenvolvimento de software, verificar se esses resultados estão sendo obtidos e estimar prazos e recursos necessários para os projetos de software. Normas e modelos de qualidade determinam o que s que atendam a esses requisitos devem atender. Contudo, normalmente, esses modelos e normas não definem como os s devem ser definidos. Esse artigo tem o objetivo de apresentar uma forma de definir de s de software independentemente de padrão ou modelo de qualidade adotado. Palavras-Chave: s de software, fábrica de software. 1. INTRODUÇÃO Usar s adequadamente definidos para desenvolver sistemas de software tem sido colocado como uma forma de alcançar os requisitos do usuário e que os sistemas sejam desenvolvidos de acordo com o planejamento e o orçamento [1]. Um adequadamente definido permite acompanhar os resultados obtidos ao longo do ciclo de vida do software, prever resultados, estimar projetos e prover melhoria e qualidade. Conhecer os s significa conhecer como os produtos são planejados e produzidos [2]. Um de software bem definido precisa considerar diversas particularidades relacionadas à organização que desenvolve software e ao próprio sistema desenvolvido. Dentre essas particularidades destacam-se a adequação às tecnologias envolvidas, ao de software, ao domínio da aplicação, ao grau de maturidade (ou capacitação) e as características da equipe, da organização e do projeto [3]. Essa quantidade e diversidade de variáveis leva ao entendimento que para cada projeto de desenvolvimento de software é necessário que s com características específicas sejam definidos. Embora cada projeto de software tenha características específicas é possível estabelecer um conjunto de s básicos que sejam utilizados na definição de s de software de uma organização ou de uma área de interesse. Esses s constituem os chamados s padrão de desenvolvimento de software. Processos para projetos específicos são definidos a partir da instanciação do de software padrão da organização [4]. Na instanciação, os s são adaptados de acordo com as características particulares da organização, da equipe e do projeto de software. Esses s instanciados são denominados s de projeto [2] ou projetos de software baseados em s. Como forma de auxiliar na definição de s padrão e de especializá-los, este trabalho tem o objetivo de propor um método para definir representações, modelos, de s. Esses modelos são definidos tendo como base a orientação a objetos. O uso de objeto traz a facilidade de encapsular os dados e operações realizadas com esses dados, fazendo do e dos seus componentes unidades encapsuladas. A herança e o polimorfismo, por exemplo, facilitam a especialização de um padrão. A comunicação por meio de mensagens possibilita a interação entre os objetos que representam o e os seus componentes, mesmo que eles tenham operações polimórficas e pertençam a organizações distintas. Assim, o uso da orientação a objetos para o tratamento de s contribui para definir s padrão e para especializá-los. Este texto está organizado em seções. A seção 2 apresenta o referencial teórico sobre de software que fundamenta a proposta deste trabalho. Na seção 3 está o método proposto. A seção 4 contém uma mostra do uso do método proposto na Seção 3. Por fim, está a conclusão. 2. PROCESSO DE SOFTWARE No desenvolvimento de software estão envolvidos aspectos técnicos e de negócio. Por exemplo, a manutenção de software envolve as atividades de manutenção que são técnicas e o contrato com o cliente que abrange aspectos de negócio. Para atender tanto a aspectos técnicos como de negócio, o conceito de definido e utilizado neste trabalho é baseado nas referências: [5] e [6] para s de maneira geral; [7], [8], [9], [10] e [11] para s de software; e [12] para s de negócio. Os conceitos de que constam nessas referências podem ser sumarizados em como um conjunto de atividades ordenadas, que transformam entradas em saídas. Tendo como base essas referências, esse conceito de e que o desenvolvimento de software é baseado na realização de s, neste trabalho, de software é conceituado como um conjunto de atividades organizadas de maneira a alcançar objetivos relacionados ao ciclo de vida de software. As atividades são realizadas por atores que com o auxílio de recursos produzem e transformam artefatos de software. Os s de software são representados por meio de modelos. Esses modelos representam abstrações definidas de acordo com objetivos e interesses dos envolvidos nos s. Os seguintes autores propõem modelos de s, por vezes denominados visões: [13], [14], [15], [16] e [17]. Curtis, Kellner e Over [13] referem-se às visões como perspectivas e as categorizam em: funcional, organizacional, comportamental e informacional. A funcional contém os componentes do que estão sendo realizados e os fluxos de produtos que são relevantes para esses componentes. A

2 organizacional representa onde e por quem na organização os componentes do são realizados. A comportamental representa o tempo em que os componentes do são realizados. A informacional contém informações para a representação dos produtos produzidos ou manipulados pelos componentes do. Tendo em vista a inserção da tecnologia nos negócios, as perspectivas indicadas por [13] podem ser complementadas ou agregadas, abrangendo aspectos como: recursos, tecnologias e negócio. List e Korherr [14] indicam que as perspectivas de Curtis, Kellner e Over [13] não capturam informações importantes do contexto do de negócio, como os objetivos e os s de s. Assim, eles criaram uma perspectiva de contexto que serve de base para as outras perspectivas. Holt [15] tendo como base as perspectivas de [13] propõe um meta-modelo de composto por sete visões interrelacionadas: a) requisitos, com os objetivos gerais do ; b) estrutura, com a estrutura dos conceitos e a terminologia utilizada; c) conteúdo, contendo as atividades e os artefatos; d) interessados, identificando-os dentro da organização e apresentando-os em hierarquia; e) comportamento, com a ordem das atividades, o fluxo da informação e as responsabilidades; f) informação que inclui os artefatos e os seus relacionamentos; g) de instância do. Chen et al. [16] estabelecem as visões de um em função dos seus componentes. Essas visões são: atividades que representam o progresso do, produtos com estados e recursos humanos que apresenta as atividades atribuídas aos atores do projeto. As visões de atividades e de produtos representam aspectos dinâmicos do e a visão de recursos humanos com aspectos estáticos desses recursos. Os s são constituídos por componentes. Para auxiliar na definição desses componentes, neste trabalho foram utilizadas as referências: [10], [11], [12], [17], [18], [19], [20] e [21]. Considerando os componentes do como conceitos, [10] estabelecem a atividade, o artefato e o recurso como os conceitos básicos dos modelos de s. A atividade e o artefato possuem um auto-relacionamento denominado contém, indicando que podem ser compostos. O artefato é uma especialização do recurso. Há um relacionamento usa entre a atividade e o recurso e um relacionamento produz entre a atividade e o artefato. Os autores [12], [17], [18], [19], [20] e [21] definem os componentes de um tendo de negócio como referência. Dentre os componentes indicados por esses autores são comuns: atividade, recurso e produto. Aversano e Cânfora [19] fazem um complemento incluindo os serviços e a lógica de negócio como componentes do. A lógica de negócio se refere às regras que coordenam as atividades, ordenam os serviços e definem o fluxo de controle durante a execução do. De maneira mais abstrata, Bhuta, Boehm e Meyers [20] se referem a um componente de como um grupo de atividades e/ou outros componentes relacionados por dependências lógicas, que quando executados provêm valor ao projeto. Referindo-se especificamente a s de software, Bertollo e Falbo [11] citam atividades, artefatos, procedimentos e recursos como partes do. As atividades possuem estrutura e organização, ou seja, relacionamentos. Os artefatos representam insumos e produtos. Os procedimentos representam os métodos, as técnicas, as normas, os roteiros e os padrões. Os recursos são do humano, hardware ou software. 3. DEFINIÇÃO, REPRESENTAÇÃO E EXECUÇÃO DE PROCESSOS DE SOFTWARE Um, assim como um sistema de software, possui um ciclo de vida. Ele precisa ser definido gerando modelos e esses modelos são executados obtendo-se os resultados definidos para o. Neste trabalho, as atividades abrangidas pelo ciclo de vida de software incluem a definição de objetivos, requisitos, estrutura e comportamento do e dos seus componentes, a definição e a representação de modelos de s e a execução, manual e/ou automatizada, desses modelos. Os modelos de precisam ser representados e é necessário definir os elementos para representá-los. Para atender a esses requisitos definiu-se um método para modelar s. A Figura 1 apresenta o modelo conceitual desse método. Essa figura expressa que o método é utilizado para definir modelos de s e ele é composto por etapas e os seus resultados são estruturados por meio de conceitos. Esses conceitos são representados por meio de linguagens de modelagem e são definidos a partir do objeto. Modelo de Método para modelar s define Etapas Conceitos notacionais Linguagens de modelagem modelos modelos estruturados por representados por definidos a partir do Figura 1 - Modelo conceitual do método Objeto O Objeto é definido em [22]. Em resumo ele se refere à representação do e dos seus componentes como objetos. A Figura 3, utilizando notação de diagrama de classes da UML, contém a representação estrutural do objeto. artefato papel recurso política Processo.. ação da atividade(papel, recurso, política) : artefato Figura 2 - Representação conceitual do objeto Fonte: Borsoi e Becerra [22] Com auxílio da representação da Figura 2, conceitua-se, neste trabalho, o objeto como o definido por identidade, atributos e comportamento. Identidade individualiza cada objeto. Atributos definem as suas características e representam os seus dados relacionados. Comportamento representa as operações do objeto com os seus dados e as ações resultantes dos relacionamentos entre objetos. A designação objeto representa a identificação essencial para representar s como objetos. Essa identificação se refere tanto ao como aos componentes que estão vinculados a um. Esses componentes são as

3 atividades, os atores, os recursos, os artefatos e as políticas a que o e os seus componentes estão sujeitos. Os Conceitos notacionais são os elementos conceituais utilizados por uma linguagem de modelagem para representar modelos de s. Esses conceitos definem quais são os elementos a serem representados e a linguagem de modelagem define como eles são sintática e semanticamente representados. Foram definidas três categorias de conceitos notacionais. Elas estão representadas nas Figuras 3 a 5, utilizando notação de diagrama de classes da UML [23]. As classes dessas figuras representam os elementos notacionais e os relacionamentos representam as associações entre esses elementos. Na Figura 3 estão os conceitos notacionais para a representação da estrutura do objeto, que são objeto com atributos e operações e relacionamentos entre objetos. Objeto atributo operação() relacionados por relacionamentos Figura 3 Conceitos para representar o objeto Os atributos definem as propriedades do objeto e representam abstrações dos s de dados possíveis às suas instâncias. As operações são abstrações das ações do objeto. O elemento notacional para representar a estrutura do objeto é uma classe com atributos e operações. As classes estão relacionadas entre si. Diagramas de classes e de objetos da UML [23] podem ser utilizados para representar modelos compostos por esses conceitos A Figura 4 contém os conceitos notacionais utilizados para representar os modelos que definem o comportamento do objeto em termos de estados. Esses conceitos são: estado, transição entre estados, ação e evento. Estado resulta na alteração de Ação relaciona Transição entre estados ativa Evento Figura 4 - Conceitos para representar estados do objeto Modelos de estados contêm o ciclo de vida do objeto como estados e transições entre estados. Os estados estão relacionados entre si por meio de transições que ocorrem a partir de eventos. A mudança de estados resulta em ações realizadas pelos objetos. Diagramas de estados da UML [23] podem ser utilizados para representar os modelos de estados dos objetos. A Figura 5 contém os conceitos notacionais para representar o comportamento do objeto em termos de relacionamento entre atividades por meio de fluxo de seqüência e a comunicação entre atividades, entre s e entre atividade e por meio de fluxo de mensagem. Os modelos de fluxo de seqüência e de mensagem podem ser representados por diagramas BPMN [24] ou diagramas de atividades e de seqüência da UML [23]. Papel Atividade Evento definido por inicia/finaliza por Fluxo entre atividades Fluxo seqüência definem regras Política para entre atividades Relacionamento Fluxo mensagem Figura 5 - Conceitos para representar fluxos de seqüência e de mensagem Os conceitos para representar o fluxo entre atividades são: fluxo de seqüência e de mensagem, relacionamento, atividade, papel, política e evento. Um fluxo entre atividades é composto por atividades relacionadas. Política representa condições que controlam as conexões dos fluxos entre atividades que são realizados por papéis (que são instanciados por atores humanos, máquinas e software) e iniciados e finalizados por eventos. Os relacionamentos conectam as atividades definindo os fluxos. As linguagens de modelagem são utilizadas para representar os resultados das etapas do método. As representações obtidas com essas linguagens obedecem aos critérios sintáticos e semânticos dos conceitos notacionais. Esses conceitos compõem o vocabulário básico para representar a arquitetura de. A UML [23] e a BPMN [24] são exemplos de linguagens que podem ser utilizadas para modelar s. A UML possui os seus próprios conceitos, um vocabulário, os elementos para composição de modelos, diagramas para representar os modelos, relacionamentos para compor os modelos e regras para uso dos conceitos e representação dos modelos. BPMN é uma notação utilizada para representar s, centrada no seqüenciamento de execução das suas atividades. As etapas representam as seqüências de atividades para obter os modelos de. Essas atividades são agrupadas em modelagem conceitual e execução de s. Na fase de modelagem de s, os s são definidos e representados. Na fase de execução de s, as atividades que compõem os s são utilizadas para realizar um projeto de software. A modelagem de s de software é freqüentemente associada à sua execução. Na fase de execução, devem ser consideradas as questões de coordenação de múltiplos usuários e a interação dos mesmos com as ferramentas utilizadas para realizar as atividades. Para isso, é necessário que se obtenha um modelo de executável (ou instanciado), ou seja, um modelo que descreva o em um nível de detalhe que permita a execução manual ou automatizada das suas atividades de forma inequívoca. A modelagem de s abrange a abstração do que será representado em termos de e a representação dessa abstração em modelos. Esses modelos são representações utilizadas para criar e gerenciar as instâncias de, que representam um em uso. A Figura 6, em notação BPMN [24], apresenta as atividades propostas para a fase de modelagem de s. Neste trabalho, a qualidade é considerada sistêmica ao desenvolvimento de software e está vinculada aos s de software e a orientação a objetos é utilizada para definir os modelos desses s. Assim, normas e modelos de qualidade e conceitos da orientação a objetos são utilizados na realização de todas as atividades da fase de modelagem de s.

4 Figura 6 - Atividades da fase de modelagem de s A seguir a das atividades da Figura 6: - Elicitar os requisitos do - inicialmente, o domínio e o contexto para o são definidos. Por meio de abstrações, de acordo com objetivos e interesses, a partir do domínio e contexto são identificados os atributos, o comportamento e os relacionamentos do, os seus componentes, as ações das atividades, os papéis e os recursos necessários para realizálas, as políticas aplicadas ao, aos seus componentes e relacionamentos. Os requisitos incluem a qualidade requerida e esperada para os s e os produtos, as restrições tecnológicas, financeiras e de pessoal e a cultura organizacional. - Realizar análise dos requisitos do - a partir dos requisitos, os objetos que representam o e os seus componentes, os estados do e dos seus componentes são definidos e organizados de acordo com classificação, generalização, agregação e associação da orientação a objetos. Utilizando a orientação a objetos, os requisitos do definem atributos; comportamento e operações são deduzidos a partir das ações realizadas pelas atividades, do seqüenciamento dessas atividades em s e pelos estados a que o e os seus componentes podem assumir. - Definir e representar os modelos de - modelos de são definidos e modelados de acordo com o método na Figura 1. Para utilizar esse método é necessário: a) definir as características básicas que os modelos de s devem ter para atender seus objetivos; b) definir a estrutura básica que caracteriza cada modelo, considerando os requisitos e as operações dos s e dos seus componentes e as políticas que eles estão sujeitos; c) estabelecer o nível de abstração e o grau de detalhamento de cada modelo; d) determinar os componentes de cada e os relacionamentos necessários para compor cada modelo; e) definir as atividades contidas em cada, as suas ações e os seus resultados; f) determinar a seqüência para realização das atividades de cada e as principais informações trocadas entre os s; g) definir os atores que realizam as atividades, a sua hierarquia, as habilidades, as responsabilidades e as restrições dos seus papéis; i) definir os recursos e os procedimentos necessários para realizar cada atividade; g) estabelecer os requisitos e as políticas para os s e os seus componentes. - Especializar modelo de - um modelo de é especializado de acordo com requisitos específicos para um projeto de software, com as características da equipe de desenvolvimento, políticas da organização e outros. A seta circular representada nessa atividade na Figura 6 indica que um modelo de pode passar por diversas especializações. Na execução de um de software, os modelos de s são utilizados para realizar projetos de software. Neste trabalho, executar um consiste em instanciar esse por meio de um projeto de software e realizar esse projeto. Projeto de software pode abranger desde todo o ciclo de vida de software até atividades específicas como implementação de componentes de software e realização de testes. A Figura 7, em BPMN [24], contém as atividades dessa fase. Preparar a atividades manuais instância do para execução atividades automatizadas Preparar ferramentas computacionais Executar o procedimentos políticas Figura 7 - Atividades da fase de execução de s A seguir a das atividades da Figura 7: Gerenciar, monitorar, coletar dados e avaliar o dados de controle e métricas - Preparar a instância do para execução nessa atividade o é instanciado por meio de um projeto de software. Para isso são determinados os requisitos necessários para executar o, incluindo definir os recursos, o orçamento, os prazos, os papéis, os procedimentos, os padrões de documentos e a especificação das ferramentas computacionais a serem utilizadas. Esta atividade inclui alocar recursos e pessoas, definir o planejamento e o cronograma do projeto e atribuir as atividades aos atores. - Preparar as ferramentas computacionais as ferramentas para automatizar e gerenciar a execução das atividades são instaladas e configuradas, incluindo mediadores para prover compatibilidade entre as ferramentas. - Executar o - o projeto de software que instanciou os s é realizado. Um modelo de instanciado ou executável possui características específicas de um projeto de software. Esse modelo orienta a realização das atividades do projeto. A instanciação de um projeto deve considerar: a criticidade em termos de segurança e de desempenho, o grau de distribuição dos s, os modelos e as normas de qualidade utilizadas, o orçamento, as limitações de recursos, as habilidades dos participantes e o nível de automação dos s. Na execução do, as atividades são realizadas por atores humanos ou sistemas automatizados. - Gerenciar, monitorar e coletar dados e avaliar o nessa atividade é realizado o acompanhamento do. Durante a execução do atuam os controles definidos de acordo com as políticas e avaliados de acordo com as métricas estabelecidas. Essa atividade está relacionada com a execução do, isto é representado, na Figura 7, pelas setas que as interligam e significa que elas são realizadas simultaneamente, gerando resultados para realimentar uma a outra. 4. DEFININDO MODELOS DE PROCESSOS Para utilizar o método proposto na Seção 3 é necessário definir o contexto e o domínio dos s. Isso auxilia a determinar quais os s, o que esses s contêm e os modelos necessários para representá-los. Para o exposto nesta seção, o contexto e domínio são os s de desenvolvimento de software de uma fábrica de software de pequeno porte e o uso da ABNT ISO/IEC [7] como modelo de qualidade. Assim, os modelos de estão relacionados à estrutura, ao comportamento e a organização dos objetos e aos relacionamentos entre objetos. Os componentes de um são os seus elementos, ou itens, fundamentais que o compõem. Neste trabalho, os componentes do são denominados essenciais e complementares. Os componentes essenciais de um são os que respondem às questões definidas como fundamentais para um e que compõem a sua conceitualização. Essas questões fundamentais e seus respectivos componentes essenciais são:

5 a) Como e quando é feito são as atividades que compõem o e o seu seqüenciamento que indica a ordem que as atividades devem ser realizadas. b) O que é feito são os artefatos produzidos, modificados e utilizados pelas atividades. c) Quem faz são os atores que representam pessoas, sistemas de software e equipamentos que realizam as atividades. d) Com o que é feito são os recursos utilizados pelos atores para produzir e alterar artefatos. Os componentes complementares possuem atuação vinculada ao e aos seus componentes, aos seus relacionamentos e comportamento. Para este trabalho foram definidos os seguintes componentes complementares: a) Políticas - abrangem aspectos de qualidade, regras e outros critérios que restringem a realização das atividades, a atuação dos atores, o uso dos recursos e a produção dos artefatos. b) Métricas - visam determinar referências para padrões de qualidade e a aplicação de políticas. c) Controles possibilitam a coleta de dados e a verificação da aplicação das políticas e das métricas. Foram definidas três categorias de modelos de tendo como critério as características dos modelos que as compõem: a) Estrutural - representam a estrutura do e dos seus componentes. Os objetos são classes com atributos e podem ter operações. b) Comportamental - representam o comportamento dos objetos por meio de estados e da interação entre atividades. O comportamento são os estados e a comunicação por meio de troca de mensagens entre os objetos. Projeto responsável paradigma observações possui Calendário horas dia data Recurso proprietário Processo objetivo requisitos data inicio prevista data inicio realizada data fim prevista data fim realizada utiliza realizada por Ator habilidades Atividade meta pré-condição pós-condição habilidades artefato (entrada) artefato (saída) pré-atividade pós-atividade produz Artefato versão proprietário Figura 9 Modelo estrutural do de software Tarefa Descrição De acordo com a Figura 9, um projeto de software, independentemente de abranger todo o ciclo de vida de software ou apenas fases ou atividades específicas, agrega um conjunto de s. Um é composto por atividades e estas por tarefas que são as unidades atômicas de trabalho. Um projeto possui um calendário de execução. Às atividades estão vinculados atores que utilizam de recursos para realizá-las e produzir artefatos. A Figura 10 em notação BPMN [24] é um exemplo de modelo da categoria comportamental. Essa figura apresenta a seqüência de atividades do de desenvolvimento de software. Essas atividades estão em um nível bastante elevado de abstração. Os artefatos produzidos são indicados pelo ícone que representa uma folha com o canto superior direito dobrado. c) Organizacional - representam os s e os atores no contexto e no domínio de uma organização que desenvolve software. É a organização em termos de distribuição e categorização dos s de acordo com a estrutura organizacional e a hierarquização dos papéis. As Figuras 8 e 9 representam modelos da categoria estrutural. A Figura 8 utilizando UML [23] apresenta o modelo estrutural dos componentes complementares. Eles se aplicam ao objeto (o e os seus componentes) e aos relacionamentos (incluindo comportamento e estado) entre eles. Metrica Descrição Tipo Período de medição Forma obtenção Valor medido Objeto medido definida de acordo com Política Descricao Tipo Objeto Processo aplicado definido de acordo com Controle Política Métrica Figura 10 Seqüência de atividades desenvolvimento As setas cheias que interligam as atividades na Figura 10 indicam a seqüência que elas devem ser realizadas. O circulo com borda delgada indica o inicio do e o círculo com borda espessa indica o fim do. A ocorrência de eventos pode determinar o início e o fim de um. A Figura 11 utilizando UML [23] representa um exemplo de modelo da categoria organizacional. Esse modelo representa a organização hierárquica dos papéis. Nessa figura os papéis estão organizados por funcionalidades. Um papel é instanciado por atores. Equipe Gerência Geral Equipe Gerência de Projeto Nível estratégico Nível gerencial Figura 8 Modelo estrutural dos componentes complementares A Figura 8 utilizando UML [23] apresenta o modelo estrutural do projeto, do e dos componentes do. Equipe Lógica de Negócios Equipe Banco de Dados Figura 11 Hierarquia dos papéis Equipe Interface Humano- Computador Nível operacional

6 Foram utilizados os níveis estratégico, gerencial e operacional para hierarquizar os papéis. Esses níveis são definidos de acordo com a necessidade e o de informação acessado e manipulado pelos atores que realizam esses papéis. 5. CONCLUSÃO Esse trabalho apresenta um método que auxilia a definir modelos de s. Esse método também facilita o uso de modelos de qualidade visto que eles são baseados na existência de s. É importante ressaltar que somente ter s de software, mesmo que sejam definidos de acordo com os mais rigorosos e consistentes modelos de qualidade, não garante a definição de sistemas de software que atendam os requisitos do usuário, incluindo prazos e custos. Contudo, um adequadamente definido permite prever o resultado final a ser obtido, estabelecer pontos de verificação durante o desenvolvimento, repetir um, melhorar sucessivamente um e adaptá-lo às especificidades de cada projeto de software a ser desenvolvido, incrementado ou melhorado. Os modelos de também podem ser utilizados como padrão pela organização que os especializa de acordo com suas necessidades. Esses modelos podem ser automatizados por sistemas de workflow, por exemplo. 6. REFERÊNCIAS [1] A. Fuggetta, Software process: a roadmap, The Future of Software Engineering (ICSE 2000), ACM Press, 2000, pp [2] S.T. Fiorini, Arquitetura para reutilização de s de software, tese (doutorado em Informática) - Pontifícia Universidade Católica do Rio de Janeiro, orientador Julio Cesar Sampaio do Prado Leite, [3] A.R.C. Rocha, J.C., Maldonado, K.C. Weber, Qualidade de Software, São Paulo: Prentice Hall, [4] A.R.C. Rocha, et al., Definição de s em ambientes de desenvolvimento de software orientados a organização, Simpósio Brasileiro de Qualidade de Software (SBQS 2004), Vol. 1, 2004, pp [5] A. Lazovik, M. Aiello, M. Papazoglou, Associating assertions with business processes and monitoring their execution, II International Conference on Service Oriented Computing, 2004, pp [6] A. Lindsay, D. Downs, K. Lunn, Business processes - attempts to find a definition, Information and Software Technology, Vol. 45, pp , Management Conference (IEMC '02), IEEE International, Vol. 1, 2002, pp [11] G. Bertollo, R.A. Falbo, Apoio automatizado à definição de s em níveis, II Simpósio Brasileiro de Qualidade de Software, 2003, pp [12] D.A. Taylor, Engenharia de negócios com tecnologia de objetos, Rio de Janeiro: Axcel Books, [13] B. Curtis, et al., Process Modelling. Communications of the ACM, New York, Vol. 35, Num. 9, 1992, pp [14] B. List, B. Korherr, An evaluation of conceptual business process modeling languages, 2006 ACM symposium on Applied computing, 2006, pp [15] J. Holt, No views in bad news - process modelling within a framework, IEE Seminar on Process Modelling Using UML, 2006, pp [16] M. Chen, et al., Enacting a software development process, Third IEEE International Conference on Engineering of Complex Computer Systems (ICECCS '97), 1997, pp [17] W.A. Barnett, et al., An architecture for the virtual enterprise, 1994 IEEE International Conference on Systems, Man, and Cybernetics, 1994, Vol. 1, pp [18] A. Caetano, et al., A role-based framework for business process modeling, 38 th Hawaii International Conference on System Sciences, 2005, pp [19] L. Aversano, G. Canfora, Introducing e-services in business process models, 14 th international conference on Software engineering and knowledge engineering, Vol. 27, ACM Press, 2002, pp [20] J. Bhuta, B. Boehm, S. Meyers, Process elements: components of software process architectures, Software Process Workshop (SPW 2005), LNCS 3840, 2005, pp [21] S. De Cesare, A. Serrano, Collaborative modeling using UML and business process simulation, 39 th IEEE Hawaii International Conference on System Sciences, 2006, pp [22] B.T. Borsoi, J.L.R. Becerra, Definition and modeling of process using object orientation, ACM SIGSOFT Software Engineering Notes, Vol. 33, Num. 3, 2008, pp 1-5. [23] G. Booch, J. Rumbaugh, I. Jacobson, UML Guia do usuário, 13ª reimpressão, Rio de Janeiro: Elsevier, [24] S.A. White, Business process management notation, version 1.0, OMG, [7] ABNT, Associação Brasileira de Normas Técnicas. NBR ISO/IEC 12207: tecnologia de informação - s de ciclo de vida de software, Rio de Janeiro: ABNT, [8] C.G.V. Wangenheim, et al., Experiences on establishing software processes in small companies, Information and Software Technology, Vol. 48, Num. 9, 2006, pp [9] R.S. Pressman, Engenharia de software, 5ª ed. Rio Janeiro: McGraw-Hill, [10] M. Lepasaar, T. Makinen, Integrating software process assessment models using a process meta model, Engineering