OBTENÇÃO DE PROCESSOS DEFINIDOS NOS AMBIENTES DE ENGENHARIA DE SOFTWARE: UMA ABORDAGEM BASEADA EM SIMULAÇÃO

Texto

(1)

(2)

(3)

(4) !"#$" %'&)(*&)+,.- /10.2*&4365879&4/1:.+58;.2*<>=?5.@A2*3B;.- C)D 5.,.5FE)5.G.+&4- (IHJ&?,.+/?<>=)5.KA:.+5MLN&OHJ5F&4E)2*EOHJ&)(IHJ/)G.- D - ;./);.& Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. OBTENÇÃO DE PROCESSOS DEFINIDOS NOS AMBIENTES DE ENGENHARIA DE SOFTWARE: UMA ABORDAGEM BASEADA EM SIMULAÇÃO Dawilmar Guimaraes de Araujo (INPE/UNITAU) dawilmar@gmail.com Nilson SantÁnna (INPE) nilson@sesis.com.br Angela Maria Ribeiro (UNITAU) angela.ribeiro@unitau.br. Organizações desenvolvedoras de software estão dando mais atenção e obtendo mais benefícios por meio de entendimentos e aplicações de conceitos de processos definidos. Normas e padrões como o MPS-Br, CMMI e ISO15504 estabelecem um conjunto de regras para um processo no sentido de ser considerado como processo definido. Estas regras estão relacionadas a maturidade dos processos das organizações. De forma simples um processo definido é planejado, usado e bem conhecido, avaliado e pode ser reusado em outros projetos depois do feedback quantitativo. O caminho para obter um processo definido não é trivial. A falta de medidas e programas e instrumentos de análises de desempenho são causas que fazem dificultar o estabelecimento de um processo definido. Normas e padrões comumente dizem o que fazer e não como fazer. Neste cenário de dificuldades e oportunidades, este trabalho vem propor o uso de modelagem e simulação de processo no sentido de criar e planejar aplicação para definir um processo real da organização. Este trabalho também apresenta uma revisão bibliográfica relatando acerca dos temas chaves apresentados e um estudo de caso para um processo de apoio a resolução de problemas. Alguns indicadores de capacidade são apresentados demonstrando a viabilidade desta proposta. Palavras-chaves: engenharia de software, modelagem e simulação de processos de software, tecnologia de processos de software, gestão de processos, análise de desempenho de processos.

(5) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. 1. Introdução Organizações desenvolvedoras de software estão dando mais atenção aos benefícios conseguidos por meio do entendimento dos conceitos e práticas da gestão voltada aos processos. Os resultados dos esforços encontrados na literatura podem ser vistos pelo discernimento de modelos de maturidade e melhorias de processos realizados pelas organizações. Como exemplo internacional podem ser citados a norma ISO/IEC-15504 proveniente do Projeto SPICE (Software Process Improvement Capability dEtermination), o framework CMMI (Capability Maturity Model Integration) da SEI (Software Engineer Institute), e particularmente ao cenário nacional, o modelo MPS.Br (Melhoria de Processo de Software Brasileiro), que é um modelo de melhoria e avaliação de processo de software que busca atender as suas necessidades e a ser reconhecido nacional e internacionalmente como um modelo aplicável as organizações de software (SEI, SPICE, 2005; MPS.Br, 2006). A adoção de modelos e normas são bastante promissoras, no entanto dizem o que fazer e não como fazer, bem como estabelecem um conjunto de regras para um processo no sentido de ser considerado como processo definido. Regras estas, relacionadas a maturidade dos processos com as organizações. Diferentes implementações destes modelos e normas são realizadas por diferentes organizações. A fim de apoiar e justificar ações da gerência para estas implementações são realizadas diversas propostas de uso de ferramentas de gestão e análise de processos que suportam métodos quantitativos. De forma simples um processo definido é planejado, usado e bem conhecido, avaliado e pode ser reusado em outros projetos depois do feedback quantitativo. O caminho para obter um processo definido não é trivial, aliado a isto, a falta de medidas, programas e instrumentos de análises de desempenho é uma das causas que fazem dificultar o estabelecimento de um bom processo definido. Neste sentido, este trabalho apresenta alguns resultados de experimentos de uma proposta que apóia a definição, análise de desempenho e melhoria dos processos de software. Considerando este cenário de dificuldades e oportunidades, propõe-se o uso de modelagem e simulação de processo no sentido de criar e planear aplicação para definir um processo real da organização. 2. Processo de software O processo é, ou um conjunto de processos, utilizado por uma organização ou projeto para: planejar, gerenciar, executar, monitorar, controlar e melhorar as atividades relacionadas à construção de software. (MPS.Br, 2006). Um processo de software é interpretado por um conjunto de elementos, a partir de suas definições e também de suas relações, a saber: atividade, tarefa, papeis, atores, produtos e recursos. Um processo de software tipicamente é identificado por uma coleção de atividades. Uma atividade é identificada por sua posição no contexto do processo e por seu relacionamento com outras atividades que comumente são descritos por regras da organização e do próprio processo. A atividade é a parte do processo que se define por suas tarefas. Competências ou papeis são escritos e definidos para a realização das tarefas através de seus atores. Atores produzem produtos (objetivos) do processo ao exercerem seus papeis, executando suas tarefas, que para isto necessitam consumir recursos.. 2.

(6) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. Processo definido é um processo que é gerenciado (planejado, monitorado e ajustado) e adaptado de um conjunto de processos-padrão de acordo com os guias de adaptação da organização (MPS.Br, 2006). A capacitação em desenvolvimento de software pressupõe a existência de um processo de software definido e a aplicação de um modelo de melhoria de processos. Neste sentido, a capacitação em desenvolvimento de software reflete o grau de institucionalização de uma infra-estrutura e da cultura relacionada aos métodos, práticas e procedimentos de desenvolvimento de software de uma organização, ou seja, dos processos de software e a sua maturidade (CEREJA, 2004). Assim, a maturidade do processo indica até que ponto um processo é modelado, bem como seus demais aspectos ligados a sua gestão, métricas, controle e eficácia são realizados (CEREJA, 2004). A qualidade de um produto de software é determinada pela qualidade do processo utilizado para o seu desenvolvimento e manutenção (KELLNER, RAFFO, 1999). As citações apresentadas procuram apontar sobre a importância de formalizar e melhorar os processos de software organizacionais, com o intuito de ganhar qualidade e produtividade. Um processo é o principal elemento de um ambiente de desenvolvimento de software já que a qualidade de um produto de software está diretamente ligada a qualidade do processo utilizado para seu desenvolvimento. Neste sentido, a modelagem de processos constitui-se em um recurso importante para alcançar os processos organizacionais pelos quais são desenvolvidos os produtos de software. 3. Simulação de processos A Modelagem e simulação quantitativa como ferramentas da melhoria do processo, inicialmente foram utilizadas na área de manufatura convencional. Entretanto, estas ferramentas só foram aplicadas aos processos do desenvolvimento do software recentemente (RAFFO, 1999). Simulações de processos de software são encontradas de forma geral em três clássicos modelos: evento-discreto, contínuo e híbrido. Para o primeiro modelo, simulação evento-discreto, entende-se que os eventos de interesse acontecem pontualmente no tempo e não importa o que aconteça entre eles. Assim por exemplo, iniciar uma codificação, terminar o código, iniciar uma interpretação ou análise de requisitos e muitos outros podem ser caracterizados facilmente no tempo. O segundo modelo, da simulação contínua, busca capturar aspectos dinâmicos que o modelo anterior não o faz. Modelos de simulação contínua visam a captura e entendimento de fenômenos como, por exemplo, as atividades dos processos de software são desenvolvidas por agentes humanos e consomem um certo tempo que por ventura ocasionam modificação em suas respostas quanto à produtividade, qualidade dos produtos que geram etc. Fatores como stress ou motivação podem diminuir ou aumentar estas respostas. Já o terceiro modelo, chamado modelo híbrido que aparece quando existem manipulação das variáveis (contínua e discreta) dos dois tipos de modelos envolvidos no estudo e que são considerados conjuntamente. Também quando a partir de qualquer modificação que se faz em um ou outro modelo e que alterem a estrutura conceitual do modelo original. Há ainda propostas que buscam realizar simulações de maneiras diferentes das abordagens anteriormente citadas. Trata-se do uso de técnicas da inteligência artificial, baseada em. 3.

(7) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. conhecimento e outras propostas de implementação por agentes de software. Independentemente da escolha do modelo de simulação, deve os desenvolvedores possuir as duas principais habilidades: - conhecer bem os processos de software com seus elementos, regras etc, entendendo bem suas particularidades; e - conhecer o processo de simulação, a ferramenta utilizada e tudo que os cerca, para escrever modelos de processos de software nestes ambientes de simulação adequados, isto é que possam efetivamente representar suas particularidades. 4. Desempenho e capacidade do processo de software Capacidade do processo: Uma caracterização da habilidade do processo atingir os objetivos de negócio atuais ou futuros (MPR.Br, 2006). Para Gonçalves (2001), o desempenho do processo de software representa os resultados reais alcançados em sua execução. Assim, o desempenho do processo de software traduz a capacidade do processo durante sua execução. Traduz resultados obtidos. Obter a capacidade de um processo é algo critico. Com base nos atributos de um projeto específico, nas características ambientais e no contexto no qual o processo é definido e conduzido, seu desempenho real pode não refletir a capacidade do processo esperado. Por exemplo, alterações radicais na aplicação ou na tecnologia empregada podem colocar o pessoal do projeto na situação de aprendizes, o que faz com que a capacidade e o desempenho do seu projeto diminuam com relação à capacidade de processo total da organização (GONÇALVES, 2001). Segundo Gonçalves (2001), a maturidade do processo de software é a extensão para a qual um processo específico é explicitamente definido, gerenciado, medido, controlado e efetivado. A maturidade representa o potencial de crescimento de capacidade e indica a riqueza do processo de software da organização e a consistência com que o mesmo é aplicado em todos os seus projetos. 5. Obtenção dos indicadores A escolha e adoção dos indicadores devem partir de uma sistemática, de um método apoiado pela organização e amplamente difundido no grupo envolvido. Deve ser usado para visibilidade, motivação e melhoria. Esta é uma tarefa árdua que demanda suficiente conhecimento, habilidade e vontade para evitar que a escolha incorreta possa levar ao aumento desnecessário de esforço do responsável, a uma visão distorcida do processo, o que dificulta a sua análise e, muitas vezes, termina por orientar decisões equivocadas. A falta de cuidados faz com que a maioria das propostas de implantação de métricas para avaliação e melhoria de processos não tenham tido muito sucesso até os dias de hoje. Poucos foram os casos onde o seu uso não foi considerado ineficiente ou, até mesmo, desaconselhável. Lemes (1997) constata numa pesquisa realizada que a razão para esta falta de sucesso pode ser atribuída ao fato de que as atividades de medição não tiveram como objetivo o principal requisito, que é prover as informações necessárias para apoiar as decisões gerenciais. Além disso, Gomes Junior (2001) também argumenta que as metodologias tradicionais geralmente são orientadas por modelos de regressão para estimativa, o que provê pouca informação de caráter decisório para os gerentes.. 4.

(8) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. Pode-se dizer que é de consenso, o futuro das métricas de software está no uso de métricas relativamente simples combinando diferentes aspectos do desenvolvimento de forma a permitir vários tipos de estimativas e avaliações (LEMES, 1997). Novas abordagens precisam ser definidas a fim de facilitar o trabalho de engenheiros de software na implantação de programas de medição de forma a tornar menos árduas as tarefas necessárias à definição, coleta e avaliação de métricas em processos de software. E é neste contexto que este trabalho se insere, para um posicionamento estratégico das organizações desenvolvedoras em um cenário onde possa ser realizadas conjuntamente as tarefas de definições de processos, predição de desempenho e analise de capacidade uma subsidiando a outra. Isto direcionado para melhoria e qualidade dos processos da organização. 5.1. Indicadores de desempenho adotados Verifica-se que os parâmetros de custo, prazo, esforço são os mais trabalhados, evidenciando o quanto se qualifica o processo de software a partir deles. também pela estreita dependência do recurso humano dos ambientes ADS. Por exemplo, estimativa de custo de software é feito medindo o tempo de esforço requerido para completar um produto de software. Esforço é usualmente representado pelo número de homens-mês (HM). Três aspectos foram contemplados para o processo usado neste estudo de caso, corroborando com a idéia da simplicidade dos indicadores e que esteja diretamente ligado a questão do recurso humano no processo. Pode-se obter diretamente dos indicadores proposta a melhora do índice de produtividade planejada. Conforme é apresentado no Quadro 1, a saber: i) capacidade produtiva do processo refletida diretamente na disponibilidade estimada total de esforço de homem-hora para um dado projeto; ii) aproveitamento do tempo efetivo do grupo em função da medida de utilização estimada; e iii) a relação entre o que foi previsto e realizado, medida em função da eficiência. Com alguns destes indicadores pode-se obter a produtividade do processo. Indicador. Interpretação (métrica). Objetivo da organização. Capacidade do processo ou Recurso total disponibilizado (CP). Número total de horas disponíveis no projeto. Esforço que é usualmente representado pelo numero de homens-horas para um determinado projeto.. Rendimento (%). Tempo efetivamente gasto/numero total de horas disponíveis. ou Utilização de uma operação, traduz a relação percentual entre as horas trabalhadas e as horas efetivamente destinadas no período do projeto. Eficiência (%). Tempo estimado/tempo gasto no trabalho. relacionada aos recursos previsto e realizados para a execução de uma quantidade de produção em um período de tempo determinado. Produtividade (Pp). processo. Rendimento*Eficiência. efetivo. Reflete a relação de ganho efetivo para toda capacidade planejada do projeto.. Quadro 1 – Indicadores de desempenho, métricas e objetivos globais para avaliação de processos.. 6. O processo de resolução de problemas – estudo de caso Durante a execução de um processo de construção de software, muitos fatos prejudiciais ao projeto podem ocorrer, sejam eles previstos pela gerência ou não, tratá-los adequadamente supõe maturidade e disciplina. De qualquer maneira atitudes e ações devem ser tomadas para que estes fatos não venham a prejudicar o andamento normal do projeto, principalmente. 5.

(9) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. aqueles que podem causar o comprometimento da qualidade, do custo e do cronograma. Alguns trabalhos apresentam a relevância do tratamento de problemas em projetos para o bom gerenciamento do mesmo (CEREJA, 2004) Defini-se como Ocorrência a qualquer evento ou fato que deva ser considerado como um potencial elemento de risco para o projeto e que necessite de avaliação pelo grupo responsável por tal tarefa. Uma ocorrência pode ser, por exemplo, uma inconsistência identificada durante uma revisão de análise entre o modelo de classe/objeto desenvolvido e o documento de requisitos de software. Em função desta inconsistência e do fato detectado, alguma ação de modificação deve ser tomada para corrigir esta inconsistência (CEREJA, 2004). O processo de solução de problemas, modelado no ambiente do simulador Simprocess (CACI, 2005) (Figura 1), como modelo lógico deve ser iniciado a partir do momento em que qualquer pessoa envolvida no projeto encontre um problema, para tanto alguns procedimentos devem ser seguidos: - Abrir Ocorrência - O “Notificador”, qualquer pessoa envolvida no projeto e que encontra um problema, deve preencher um relatório de ocorrência, fornecendo informações referentes ao problema; - Analisar Ocorrência - O “Analista”, após ser notificado deve verificar o correto preenchimento das informações fornecidas pelo relator e assim analisar a ocorrência. Uma vez analisada, o analista deve fornecer/confirmar informações sobre o problema verificar o possível impacto, o produto a ser corrigido e se a ocorrência procede, se sim o analista deve encaminhar a solução e um solucionador deve ser notificado sobre o problema, se a ocorrência for de alto risco ao projeto, a gerência de projeto deve ser notificada, se a ocorrência não proceder, deve então, ser descartada; - Solucionar a Ocorrência - O “Solucionador”, após ser notificado deve solucionar o problema descrito no relatório de ocorrência e assim fornecer as informações da solução, solução deve ser encaminhada para revisão e validação da solução; e - Rever a Ocorrência - O “Revisor” deve revisar as informações fornecidas e compará-las com o critério de fechamento, fechando-a se os critérios forem atendidos, senão, a ocorrência deve permanecer em aberto indicando a necessidade de re-trabalho, o solucionador deve então ser notificado do re-trabalho.. 6.

(10) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. Figura 1 – Tela do Modelo Lógico do processo Resolução de problemas no ambiente do simulador.. 7. Executando o modelo de processo de resolução de problemas Os dados usados a partir de três projetos, procurou-se representar a informação a partir de estimativas da gerência com base em dados reais. O processo modelado reproduz tipicamente a rotina de uma empresa utilizada para o estudo. A empresa produz, ao longo de três fases do ciclo de vida do projeto de software em torno de 500 problemas. O esforço considerado foi de 6,5 [h/h/d] (horas-homem-dia), o restante 1,5 horas foi destinada a paralisações necessárias (reunião de rotina da equipe no dia, configuração de equipamentos etc). O processo de Resolução de Problemas adotado tem uma atividade de análise, com um ator para esta atividade; três atividades de solucionadores do problema, sendo um ator para cada uma das três fases diferentes do projeto; e uma atividade de revisor, com um ator para esta atividade. Na fase 1 inclui-se levantamento de requisito, análise e projeto estrutural, na fase 2 tem-se a codificação que realiza construção em código fonte, implementação de todos os produtos e testes específicos, por fim na fase 3 tem-se os testes finais e a implantação do produto. Adotou-se respectivamente para cada fase um faixa típica de problema levantados na ordem de 10%, 60%, 30%. Aponta-se que as duas primeiras fases possuem interatividade constante, sendo que considerou-se para a fase 1, 10% de problemas de ordem primária (inicial), concentrando-se o restante na fase 2. Para este exemplo, cada revisão detectada entre as interações das fases 1 e 2 aproximadamente 30% dos defeitos que estão nesse ponto são remediadas para a fase 2 o que aumentou significativamente sua taxa para 60%. As atividades dos solucionadores são suficientemente eficazes, fechando na média de 85% dos problemas na primeira interação. Sendo assim, 15% ficam após passar por revisores, condicionadas ainda aos solucinadores. Para este exemplo, a questão feita foi, "considerando agrupamento de papeis dos atores (desenvolvedores/solucionadores), qual seria o impacto no desempenho processo?" Os dados usados na simulação quanto ao esforço na realização, habilidade em resolver o problema, tipo do problema (classificação quanto a fase e índice de criticidade) e outros mais ficaram subscritos nos códigos do ambiente, conforme apresenta a Figura 2. Para estes parâmetros foram considerados como balizadores os dados de Boehm (BOEHM, 2000) originados do. 7.

(11) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. COCOMO II. Desta forma, permitiu-se uma maior liberdade para modificar parâmetros na experimentação e analisar seus resultados.. Figura 2 – Script de funções randômicas internas ao modelo. Sintaxe do Simprocess (CACI, 2005).. 7.1 – Experimentos e resultados Para este trabalho foram consideradas duas modalidades de simulação. Na primeira equipe (recursos humano) manteve constante em relação ao formato da organização quanto a suas atividades ou seja, manteve o processo “como é”; e na segunda modalidade, os papeis que contemplam a atividade foram agregados, buscando uma equipe multifuncional, ou seja modificou-se o processo para “como seria se”. Em ambos os casos observou-se os índices de utilização, eficiência e tempo médio de resolução de problemas. Deficiências do modelo no simulador e do processo puderam claramente ser percebidos, como: - não se tem tempo padrão de serviços para as atividades (em função do três aspectos: do individuo, do tipo da atividade, da complexidade das atividades e do tipo especifico do problema a ser resolvido) e diversos outros registros. - sem nenhuma informação estatística de qualquer tipo é oferecido como por exemplo distribuição de probabilidade de acordo (concordância, entendimento das estimativas dos gerentes da empresa em estudo) que precisam ser corrigidos. Está entre os objetivos da pesquisa deste autor para futuros trabalhos a definição de um modelo de aferição de parâmetros para estes e outros aspectos, o que inclui estas deficiências por meio de resultados experimentais (ARAÚJO, 2006). Resultados neste estudo de caso ressaltam as evidências para: - processos devem necessariamente serem tratados continuamente, e aspectos como eficiência e rendimento devem ser analisados conjuntamente (conforme mostrado na Tabela 1, alguns resultados parciais); - a falta, ou indisponibilidade de um recurso num dado momento poderá acarretar na diminuição do desempenho. O que reflete diretamente nos resultados do processo. Incluímos aqui recurso como desenvolvedor, documento para analise, documento preenchido incorretamente ou parcialmente ocasionando a falta ou indisponibilidade de. 8.

(12) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. informação necessária à resolução do problema.. Indicador. Processo original. Eficiência [%] Utilização [%] Produtividade [%] Tempo de resolução [h - média]. ~81 ~74 ~60 4,4. Processo modificado (agregando funcionalidade) ~90 ~85 ~76 2,5. Tabela 1 – Comparação das alternativas experimentadas. 8. Conclusão Há diversas opções para aumentar a eficácia das análises, solução e revisão de processos. Pode-se determinar novos resultados potenciais baseados na predição dos resultados da simulação. Contudo quando for para avaliar a mudança potencial em mais profundidade e para avaliar também algumas estratégias alternativas da execução é interessante levar em consideração recursos adicionais dos modelos inseridos nos processos de engenharia. Parte considerável dos problemas e principalmente das alternativas de soluções esta nas tarefas diretamente relacionadas aos processos de negocio da organização. É fundamental salientar que os tipos de mudanças a ser considerado vão depender da cultura organizacional. O que se pode trabalhar para uma organização, muitas das vezes não pode trabalhar para outra. A simulação é uma ferramenta muito eficaz para explorar alternativas. Corroborado por diversos autores, no entanto apenas auxiliam nos aspectos que foram considerados no modelo. O feeling e as decisões ainda estão na realidade da organização e no atores – gerentes que tomam decisões. O processo que foi modelado para a abordagem usada neste trabalho é particularmente útil para explorar estas questões consideradas qualificadoras no processo de obtenção do processo definido. Para cada opção potencial, um resultado em produtividade, rendimento, eficiência etc pode ser estimado. Alguns destes podem não ser imediatos como o treinamento de pessoal, e outros podem retornar de forma imediata como a adição de desenvolvedores com mais conhecimentos e habilidades. Esta abordagem contribui a evolução de níveis de maturidade processo, pois desta forma pode-se definir processos e explorar melhorias a partir da métricas adotadas. O aspecto combinado trabalha o apoio as práticas do CMMI em diferentes níveis, sendo globalmente aplicável a qualquer instituição, independemente do nível de maturidade que se encontra bem como das características arquiteturais e tecnológicas de seus ambientes de desenvolvimentos com forte relações as à gerência processo quantitativo e à gerência da qualidade do software. Bem como também o uso da simulação do processo do software é uma parte chave da estratégia para conseguir uma potencialidade processo. A abordagem apresentada neste trabalho ressalta como contribuição nas áreas citadas deste trabalho (modelagem, simulação e análise de desempenho) sendo bastante interessante, pois apóia a metrologia da engenharia de software para análise de desempenho de processos de software, e para a gestão de processos de desenvolvimento de software. A combinação interativa desta proposta é apontada como inédita ao ambientes de processo de software. Isto porque implementa a modelagem e simulação de processos de software que permite que os envolvidos (engenheiros, desenvolvedores etc) procurarem automaticamente. 9.

(13) P PQ RSRUT8VW XYVAZ\[XVA]W RSXYVA]^F_Y`6`.aYbY`8aYcY% dYe %f_Y`6gUdhY_Yijk% h l'mMn?mIo p?q rsut9mv wJx*myrz9o w9{?t9|~}~w??t?v{9q ~ w?p9w~w9?o myq nO mMp9o r~|u}~w9>z?o wOm NwmyIt?N mMnJ rM?q q {?r~{9m Foz do Iguaçu, PR, Brasil, 09 a 11 de outubro de 2007. por soluções ótimas aos sistemas de processos cada vez mais complexos. Pode-se definir as variáveis para controlar, os parâmetros de objetivo que se deseja (quando maximizar ou minimizar), e todas as restrições que se requere e encontrar. Bem como estabelecer metas para variáveis-candidatas (dos parâmetros de controle) de alguns aspectos. Referências ARAÚJO, D G; KIENBAUM, G S; SANTÁNNA, N. Apoio a estimativas em projetos de software através simulação: Estudo de caso do processo transição do RUP. II UNEM-WorkShop Colaboração UniversidadeEmpresa. Taubaté-SP.2006. BOEHM, B W. et al. Software Cost Estimation with COCOMO II. Upper Saddle River: Prentice-Hall, 2000. CACI Products Company. Simprocess. Versão 4.12. 2005 CEREJA JUNIOR, M. Uma arquitetura flexível para máquina de processos dos ambientes de engenharia de software. Dissertação de Mestrado. Orientador (SantÁnna, N). Instituto Nacional de Pesquisas Espaciais. São José dos Campos-SP.2004. GONÇALVES, J M; BOAS, A V. Modelo de Maturidade de Capabilidade de Software. (Tradução). CMU/SEI-93-TR-24-CMM. V1.1.Telecom & IT Soluction. Campinas-SP. 2001. IOANA, R A; COLLOFELLO, J A; LAKEY, P B. Software process simulation for reliability management. The Journal of Systems and Software, 46, 173-182, Nov.2001. ISO/IEC 15504-1, 2004] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-1: Information Technology - Process Assessment – Part 1 Concepts and Vocabulary, Geneve: ISO, 2004. KELLNER, M I; RAFFO, D M and MADACHY, R J. Software process simulation modeling: Why? What? How? The Journal of systems and software, 46, (2-3), 91-105, apr, 15. 1999. LEMES, M J R, FERNANDES, C T.Uma taxonomia para métricas de software. XI Simpósio Brasileiro de Engenharia de Software. Workshop Qualidade de Software – CITS, Fortaleza, 1997. RAFFO, D M; VANDEVILLE, J V; MARTIN, R H. Software Process Simulation to Achieve Higher CMM Levels. Journal of systems and software, 46, (2-3), 91-105, apr, 15.1999. SPICE - Software Process Assessment– Part 1 : Concepts and introductory guide.V. 1.0. Rout T. 2005. SALVIANO, C F. Tutorial: Introdução aos modelos CMM, ISO/IEC 15504 (SPICE) e CMMI. V Simpósio Internacional de Melhoria de Processo de Software, Recife-PE, Nov.2003. Software Engineering Institute (SEI). Capability maturity model for software version 1.1. (Technical Report CMU/SEI-93-TR-24). 1993. MPS.Br–Melhoria de Processo do Software Brasileiro. Guia Geral, V. 1.1. Em: www.softex.br. Mai/2006.. 10.

(14)