modelagem e simulação de processos de software mariane m. souza ([email protected])[email protected]...
TRANSCRIPT
Modelagem e Simulação de Processos de Software
Mariane M. Souza([email protected])Centro de InformáticaUniversidade Federal de Pernambuco
Roteiro da Apresentação
Contextualização Modelagem de Processos de Software SPEM - Software Process Engineering Meta
Model Simulação de Processos de Software SPEM x Simulação Conclusões Referências e Bibliografia
Contextualização (1/3)
Cerca de 70% de investimentos na área de Engenharia de Software são realizados para manter softwares existentes [Pressman 2002]
Qualidade do Produto X Qualidade do Processo
Surgimento de normas para qualidade do processo: ISO/IEC 12207, CMM, ISO 9001...
Surgimento de abordagens com o objetivo de disciplinar o processo de desenvolvimento de software (mecanismo de controle) visando sua qualidade e melhoria contínua.
Contextualização (2/3) Ferramentas CASE (Computer Aided Software Engineering)...
Ambientes ADS: Ambientes Integrados de Desenvolvimento de Software
Ambientes PSEE (Process-centred Software Engineering Environment): ADS orientados ao processo que permitem:
Controle do projeto durante sua execução Gerência da comunicação entre desenvolvedores Controle de atividades realizadas Controle de recursos e prazos Automação de atividades Coleta de dados de métricas automaticamente Guiar os usuários do processo ...
Contextualização (3/3) Ambientes para Implementação de Processos de
Software: PSEEs que fornecem ferramentas que
automatizam as fases do ciclo de vida do processo de software: Definição (Modelagem) Simulação Execução Avaliação
Modelagem de Processos de Software (1/9)
A modelagem auxilia principalmente na fase de definição (análise de requisitos, projeto e instanciação) do ciclo de vida do processo de software
A modelagem de processos de software não é uma tarefa simples, mas pode ser simplificada pela utilização de ontologias (ambientes ODE – Ontology-based software Development Environment)
Ontologias são representações do vocabulário de algum domínio ou problema [Bertollo,2002].
Vantagens: conceitos bem definidos que auxiliam na integração de ferramentas em ADS.
Modelagem de Processos de Software (2/9)
Processo de Software: Conjunto de todas as atividades necessárias para transformar os requisitos do usuário em software.
Elementos básicos para modelagem de processos de software: Ator: entidade que executa o processo Papel: conjunto de responsabilidades necessárias para a
execução de atividades Atividade: estágio do processo que produz mudanças
visíveis no estado do produto sendo desenvolvido Artefato: matéria-prima e/ou (sub)produto de uma
atividade relacionada ao processo
Modelagem de Processos de Software (3/9)
Modelo básico do domínio de processos de software
Modelagem de Processos de Software (4/9) Um modelo de processo de software é uma
representação abstrata da arquitetura, projeto ou definição do processo de software [Acuña,2001]
Define os elementos que compõem o processo e o inter-relacionamento entre os mesmos.
Pode ser: Gráfico ou Textual Executável (definido formalmente e passível de
ser simulado e validado) ou Não-Executável (guias)
Modelagem de Processos de Software (5/9) Um modelo de processo deve possuir um
formalismo de representação Pode ser orientado a linguagens (PMLs) ou
diagramático Exemplos:
Máquinas de Estado ou Redes de Petri (SPADE, Memphis e ProSoft): enfatizam modelagem gráfica, mas... acoplamento entre dados do processo e de sua execução
Baseado em Agentes, Regras ou Scripts (HyperCode e CAGIS): flexibilidade de construção, mas... Dificuldade de entendimento
Modelagem de Processos de Software (6/9)
Não existe um formalismo ideal Alguns ambientes combinam múltiplos formalismos
EPOS, Merlin, ProNet/ProSim, Dynamite, APEL e Mokassin:
Ambientes propícios para modelagem além de permitir o mapeamento de workflows modelados, em regras para execução do processo
Tentativa de Padronização: SPEM
Modelagem de Processos de Software (7/9)
Uma visão é uma projeção de um modelo de processo descrito em um dado formalismo com certo nível de detalhes.
Um modelo de processo pode ser projetado em diferentes visões (perspectivas): Funcional: representa os elementos de
processo em execução no momento Comportamental: representa quando e sob que
condições os elementos do processo estão sendo executados
Modelagem de Processos de Software (8/9)
Perspectivas para Modelagem (Cont.): Organizacional: representa onde e por quem
na organização os elementos do processo são executados
Informativa: representa as informações relacionadas aos elementos de processo executados no momento.
Modelagem de Processos de Software (9/9)
Vantagens da utilização de Modelagem: Possibilita maior entendimento e seguimento do
processo Facilita a gerência do processo Facilita a adaptação do processo já definido
(redefinição) Permite a definição de pontos de medição Permite o compartilhamento de experiências e
aprendizados na organização
Meta-modelo criado para suprir a necessidade de um padrão para as técnicas de modelagem de processo
Em Novembro de 2002 foi oficializado como um padrão da OMG (Object Management Group) e encontra-se atualmente na sua versão 1.1
Abordagem orientada a objetos e define estereótipos UML para modelagem de processos de software
A execução do processo não está no escopo da linguagem
SPEM – Software Process Engineering MetaModel (1/23)
O SPEM foi criado a partir do esforço conjunto de vários pesquisadores e empresas tais como: IBM Rational Toshiba Siemens ...
Pesquisadores: Philippe Kruntchen, Craig Lairman, etc.
SPEM – Software Process Engineering MetaModel (2/23)
SPEM – Software Process Engineering MetaModel (3/23)
Arquitetura de modelagem OMG:
A especificação do SPEM é baseada em um UML Profile que é baseado no meta-modelo MOF.
Um UML Profile é um conjunto de extensões UML criados com o objetivo de customizá-la para determinado domínio (processos de software)
SPEM – Software Process Engineering MetaModel (4/23)
SPEM – Software Process Engineering MetaModel (5/23) O SPEM é formado por dois pacotes principais:
SPEM_Foundation: definido por um subconjunto da UML 1.4
SPEM_Extensions: adiciona a forma de construir e a semântica necessária em um processo de engenharia de software.
SPEM – Software Process Engineering MetaModel (6/23) Estrutura de Pacotes:
A modelagem é feita através do uso de estereótipos Os principais estereótipos definidos pelo SPEM são:
WorkProduct WorkDefinition ProcessPerformer ProcessRole ProcessPackage Phase Process Document UMLModel Activity Guidance
SPEM – Software Process Engineering MetaModel (7/23)
SPEM – Software Process Engineering MetaModel (8/23)
WorkProduct: classe de produto de trabalho produzido em um processo e está associado a um tipo de produto. Ex: documento, código fonte, etc. Artefato
Notação:
WorkDefinition: é um tipo de operação que descreve o trabalho realizado no processo. É a representação para atividades compostas por outras sub-atividades.
Notação:
SPEM – Software Process Engineering MetaModel (9/23)
ProcessPerformer: define o “realizador” de um conjunto de WorkDefinitions do processo.
Notação:
ProcessRole: define responsabilidades em relação a WorkProducts específicos e define papéis que realizam e auxiliam atividades específicas.
Notação:
SPEM – Software Process Engineering MetaModel (10/23)
ProcessPackage: notação especial para pacotes no contexto SPEM
Notação:
Phase: é uma especialização de um WorkDefinition em que sua pré-condição define a fase de critérios de entrada e seus objetivos definem a fase de critérios de saída
Notação:
SPEM – Software Process Engineering MetaModel (11/23)
Process: representa um processo completo, em toda sua
extensão. Notação:
Document: notação específica para diferentes tipos de WorkProducts
Notação:
SPEM – Software Process Engineering MetaModel (12/23)
UMLModel: notação específica para diferentes tipos de WorkProducts
Notação:
Activity: descreve uma parte do trabalho realizado por um ProcessRole: suas tarefas, operações e ações executadas por um papel ou de que forma o papel deve auxiliar
Notação:
SPEM – Software Process Engineering MetaModel (13/23)
Guidance: Informação mais detalhada sobre o elemento associado fornecida aos praticantes Ex:Guidelines, Metrics, Tools, Checklists e Templates.
Notação:
SPEM – Software Process Engineering MetaModel (14/23)
Um Exemplo Simples:
SPEM – Software Process Engineering MetaModel (15/23)
Estudo de Caso: Ambiente e-WebProject:
Ambiente integrado para o desenvolvimento e gerência de projetos de software
Pertence ao SESIS: Sistemas de Engenharia de Software
SPEM: estudo de modelagem para definição de processos de Gerência de Configuração e Gerência da Qualidade para posterior implantação
SPEM – Software Process Engineering MetaModel (16/23)
Características do e-WebProject: Trabalho cooperativo centrado no processo Ambiente ativo com o objetivo de forçar o fluxo
de trabalho Agentes Autônomos Conjunto de serviços oferecidos via WEB para
os participantes do processo Categorias de Gerenciamento: Configuração e
Qualidade
SPEM – Software Process Engineering MetaModel (17/23)
Pontos de Partida: Adoção de padrões de qualidade:
ISO/IEC 12207: estrutura para processo de desenvolvimento e manutenção de software
ISO/IEC 15504: estrutura para avaliação e melhoria de processo de software
Mais especificamente... Padrões na categoria de processos de
suporte (SUP): “atividades guarda-chuva”
SPEM – Software Process Engineering MetaModel (18/23) Exemplo de Modelagem: (Gerência das Modificações e
Configurações)
SPEM – Software Process Engineering MetaModel (19/23)
Sub-Atividades (WorkDefinition Controlar Modificação (SUP 2.BP5)): Sub-Atividade 1: Criar Registro de Evento de ModificaçãoSub-Atividade 2: Analisar Impacto da ModificaçãoSub-Atividade 3: Avaliar ModificaçãoSub-Atividade 4: Implantar ModificaçãoSub-Atividade 5: Verificar o Produto de TrabalhoSub-Atividade 6: Concluir Modificação
SPEM – Software Process Engineering MetaModel (20/23) Modelagem (Diagrama de Atividades): Controlar
Modificação
SPEM – Software Process Engineering MetaModel (21/23)
Exemplo de Modelagem (Gerência da Qualidade):
SPEM – Software Process Engineering MetaModel (22/23)
Sub-Atividades (WorkDefinition Realizar Verificações (SUP 4.BP1)):
Sub-Atividade 1: Abertura da Verificação Sub-Atividade 2: Definição de Critérios de
Verificação Sub-Atividade 3: Conduzir a Verificação Sub-Atividade 4: Fechamento da Verificação
SPEM – Software Process Engineering MetaModel (23/23) Modelagem (Diagrama de Atividades): Realizar Verificações
Simulação de Processos de Software (1/10) Um modelo de processo pode conter falhas e
inconsistências
Após a definição do modelo de processo, o próximo passo seria “simular” o seu comportamento
Simulação: “processo de desenvolver um modelo matemático ou lógico de um sistema real e então conduzir experimentos baseados em computador, usando o modelo para descrever, explicar e predizer o comportamento de um sistema real.” [Hoover,1989]
Envolve geralmente sistemas de comportamento dinâmico, incertos ou estocásticos. Exige modelos executáveis
Simulação de Processos de Software (2/10)
Para que simular? Prever comportamento futuro dos sistemas usando
modelos Economia de tempo e recursos financeiros Ganhos de produtividade e qualidade Percepção do sistema real
Tipos de Modelos de Simulação: Voltados à Previsão Voltados à Investigação: informações e hipóteses Voltados à Comparação: mudanças em variáveis de
controle
Simulação de Processos de Software (3/10) Simulação de Processos de Software:
Validação do processo antevendo resultados que só seriam vistos durante a execução do mesmo
Detecção de possíveis deficiências no modelo definido
Auxílio no refinamento de processos de software
Principais motivações para pesquisa na área: Dificuldade de pesquisa de campo na área de
processos de software Menor tempo para validação do processo
Simulação de Processos de Software (4/10)
Algumas aplicações... Gerência de estratégias: “Seria melhor realizar
este serviço ou terceirizá-lo?” Planejamento: “O processo A ou o processo B
deve ser utilizado em nosso novo projeto?” Entendimento (simulações gráficas e
animadas) Treinamento e aprendizagem
Alguns benefícios... Melhoria na tomada de decisões
organizacionais Justificativa para iniciativas de melhoria no
processo Predição dos impactos causados por
mudanças no processo antes da execução Predição do nível de performance do processo Suporte à análises “What if...” acessando
múltiplas alternativas de processos sob diferentes condições e cenários
Simulação de Processos de Software (5/10)
O que se pode simular com relação à: Modelo de escopo: porção do ciclo de vida ou
todo o ciclo de um produto Parâmetros de entrada: número de linhas de
código, esforço de projeto (tamanho), taxa de contratação e demissão, capacidade e motivação pessoal ao longo do tempo, afinidades entre desenvolvedores, freqüência da produção de releases, etc.
Variáveis de resultado: esforço/custo, tempo de duração, nível de defeito, custo/benefício, produtividade, etc.
Simulação de Processos de Software (6/10)
Simulação de Processos de Software (7/10)
Principais tipos de simulação: Discreta:
Variáveis inalteradas ao longo de intervalos de tempo e mudam seus valores somente em momentos bem definidos
Mais utilizada para verificação de escalonamento de processos
Simulação de Processos de Software (8/10)
Principais tipos de simulação (Cont.): Contínua:
Valores das variáveis podem mudar continuamente ao longo do tempo
Simulação de Processos de Software (9/10)
Principais tipos de simulação (Cont.): Baseada em conhecimento:
Raciocínio de acordo com padrões armazenados
Suprir com a maior quantidade possível de informação sobre o domínio
Agentes Inteligentes simulam comportamento dos desenvolvedores
Simulação baseada em experiências, lições aprendidas, habilidades, etc.
Simulação de Processos de Software (10/10)
Requisitos importantes para ferramentas de simulação de processos de software: Suporte à prévia avaliação do processo instanciado Configurável para diferentes processos e escopos Simulação visual, animada e interativa Informações textuais complementares Reportagem simultânea de resultados Suporte à simulação realizada de forma progressiva
e dinâmica Simulação baseada em conhecimento (experiências,
lições aprendidas, habilidades, etc)
Simulação X SPEM (1/3)
SPEM é uma linguagem com bastante recursos, padrão, porém, trata-se de uma notação gráfica não-executável
SPEM representa graficamente os componentes do processo, mas não existe lógica definindo o relacionamento entre os mesmos.
A Simulação de processos pode ser realizada somente em modelos executáveis
Solução: criação de mecanismos de mapeamento...
Simulação X SPEM (2/3)
APES2: Ferramenta free e open-source criada
por estudantes na IUP ISI –Universidade de Toulouse, França, 2003
Validação e Automação do modelo definido na linguagem SPEM
Geração de XML correspondente ao modelo gráfico definido
Vasta documentação
Simulação X SPEM (3/3)
APES2 define todos os relacionamentos entre os componentes do processo. Ex: composição de atividades, ordem de execução de atividades, etc.
Cada componente possui um estado (esperando, pronto, ativo, parado, completo) utilizado pelo simulador para controle do processo
SPEM + APES2: modelo de processo facilmente entendível e executável
Conclusões (1/2)
Qualidade do produto de software está ligada ao processo de geração do mesmo.
Ambientes PSEE são de fundamental importância para o cenário de definição, acompanhamento e aperfeiçoamento de processos
A Modelagem de processos é um recurso valioso, que deve ser utilizado pois: “Força” a documentação do processo Facilita a visualização do processo e sua
“divulgação” e entendimento pelos membros da organização
Conclusões (2/2)
A linguagem SPEM define um padrão de fácil utilização e visualização (familiarizados com UML)
A simulação de processos de software é um grande recurso para análise e validação do modelo proposto antes de sua institucionalização na organização, permitindo:
Entendimento, aprendizado e treinamento do processo Aperfeiçoamento dos modelos construídos
O modelo deve refletir a realidade... Muitos ambientes não se preocupam com a
definição de características específicas da organização
Referências (1/1)
[Acuña, 2001]: ACUÑA, S. T.; FERRÉ, X. Software Process Modelling. In: WORLD MULTICONFERENCE ON SYSTEMICS, CIBERNETICS AND INFORMATICS, 5., 2001, Orlando, EUA. Proceedings... Orlando, EUA: 2001. p. 1-6. Disponível em: <http://is.ls.fi.upm.es/udis/miembros/xavier/papers/processmodelling.pdf>. Acesso em: 11 Out. 2005.
[Bertollo, 2002]: ODE – Um Ambiente de Desenvolvimento de Software Baseado em Ontologias. In: SIMPOSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 4., 2002, Gramado, Brasil. Anais... Gramado, Brasil: 2002.
[Hoover, 1989]: Hoover, S., Perry, R. Simulation a problem-solving approach, Reading, Massachusetts: Addison-Wesley, 1989.
[Pressman,2002]: Pressman, R., Engenharia de Software, São Paulo: Makron Books, 2002.
Bibliografia (1/3) A FRAMEWORK FOR EVALUATING PROCESS MODELLING LANGUAGES FOR
DISTRIBUTED ENVIRONMENTS. Disponível em:< www.idi.ntnu.no/grupper/su/ publ/alfw/sea2005-distributed-pml.pdf >. Acesso em: 11 Out. 2005.
ABDALA, M. A. D. et al. Utilizando SPEM para a Modelagem dos Processos da Qualidade e do Gerenciamento da Configuração em um Ambiente Integrado. In: SIMPOSIO INTERNACIONAL DE MELHORIA DE PROCESSO DE SOFTWARE, 5., 2003, Recife, Brasil. Anais… Recife, Brasil.
ARAUJO, R.M. Construção Gráfica de Processos de Desenvolvimento e Geração de uma Ontologia de Processos de Software. 2005. 73 p. Monografia (Graduação em Ciências da Computação) - Universidade Federal de Pernambuco, Recife.
BERTOLLO, G.; FALBO, R. A. Apoio Automatizado à Definição de Processos de Software em Níveis. In SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, 2., 2003, Fortaleza, Brasil. Anais... Fortaleza, Brasil: 2003.
CHRISTIE, A. M. Simulation: An Enabling Technology in Software Engineering. Crosstalk: The Journal of Defense Software Engineering, p. 25-30, April 1999
Bibliografia (2/3) KELLNER, M. I.; MADACHY, R. J.; RAFFO, D. M. Software Process Simulation
Modeling: Why? What? How?. The Journal of Systems and Software, v. 46, n. 02/03, p. 1-18, April 1999.
MARTINS, P. V.; SILVA, A. R. da. Comparação de Metamodelos de Processos de Desenvolvimento de Software. In: CONFERENCE FOR QUALITY IN INFORMATION AND COMMUNICATIONS TECHNOLOGY, 5., 2004, Porto, Portugal. Proceedings... Porto, Portugal. Disponível em:<berlin.inesc-id.pt/alb/static/papers/2004/pv-quatic2004.pdf>. Acesso em: 11 Out. 2005.
MENDES, R.C. Modelagem e Avaliação do CMMI no SPEM para Definição de um Meta-Processo de Software. 2005. 83 p. Monografia (Graduação em Ciências da Computação) - Universidade Federal de Pernambuco, Recife.
MURTA, L.G. P.; BARROS, M. de O.; WERNER C. M. L. Charon: Uma máquina de Processos Extensível Baseada em Agentes Inteligentes. In: WORKSHOP IBERO-AMERICANO DE ENGENHARIA DE REQUISITOS E AMBIENTES DE SOFTWARE, 5., 2002, Havana, Cuba. Proceedings... Havana, Cuba: 2002. Disponivel em: < https://sety.cos.ufrj.br/prometeus/ publicacoes/ideas2002-paper80.pdf>. Acesso em: 11 Out. 2005.
OLIVEIRA, S. R. B; VASCONCELOS, A. M. L.; ROUILLER, A. C. Uma Proposta de um Ambiente de Implementação de Processo de Software. INFOCOMP Journal of Computer Science, v. 4, n. 01, p. 70-77, Março 2005. Disponível em: <http://www.dcc.ufla.br/infocomp/artigos/v4.1/art09.pdf> Acesso em: 11 Out. 2005.
Bibliografia (3/3) OMG. Software Process Engineering Metamodel Specification, v.1.1, January 2005.
SCACCHI, W. Understanding Software Process Redesign using Modeling, Analysis and Simulation. Software Process Improvement and Practice, v. 5, n. 01, p. 183-195, March 2000.
SILVA, F.A. das D. et al. Um Modelo de Simulação de Processos de Software Baseado em Agentes Cooperativos. In: SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 13., 1999, Florianópolis, Brasil. Anais... Florianópolis, Brasil: 1999.
SILVA, F.A. das D. Um Modelo de Simulação de Processos de Software Baseado em Conhecimento para o Ambiente PROSOFT. 2001. 124 p. Dissertação (Mestrado em Informática) - Universidade Federal do Rio Grande do Sul, Porto Alegre.
WICKENGERG, T.; DAVIDSSON, P. On Multi Agent Based Simulation of Software Development Processes. In: INTERNATIONAL WORKSHOP ON MULTI-AGENT SYSTEMS AND AGENT-BASED SIMULATION, 3., 2002, Bologna, Italy. Proceedings... Bologna, Italy. p. 171-180. Disponível em: < www.ide.bth.se/~pdv/Papers/MABS2002.pdf>. Acesso em: 11 Out. 2005.