Universidade de Pernambuco Faculdade de Ciência e Tecnologia de Caruaru Bacharelado em Sistemas de Informação

Transcrição

1 1 Universidade de Pernambuco Faculdade de Ciência e Tecnologia de Caruaru Bacharelado em Sistemas de Informação UMA PROPOSTA DE BUG TRACKER ORIENTADA A PROCESSOS COM ÊNFASE EM REQUISITOS PARA APOIAR DESENVOLVIMENTO DE SOFTWARE ÁGIL Trabalho de Graduação Sistemas de Informação Tarcísio Ferreira De Souza Cavalcanti Orientador: Prof. Msc. Rômulo César Dias de Andrade

2 2 TARCÍSIO FERREIRA DE SOUZA CAVALCANTI UMA PROPOSTA DE BUG TRACKER ORIENTADA A PROCESSOS COM ÊNFASE EM REQUISITOS PARA APOIAR DESENVOLVIMENTO DE SOFTWARE ÁGIL Monografia apresentada como requisito parcial para obtenção do diploma de Bacharel em Sistemas de Informação pela Faculdade de Ciência e Tecnologia de Caruaru Universidade de Pernambuco. Caruaru, dezembro, 2014

3 3 Dedico este trabalho ao meu pai Luiz e minha mãe Tereza, e minhas a irmãs Taiza, Tassia, Tacira e Tais por todo o carinho amor e dedicação.

4 4 Agradecimentos. A Deus causa primeira e razão de todas a coisas. Razão pela qual hoje estamos, aqui e pela qual tive a oportunidade poder concluir este trabalho. A Lei de Causa e Efeito, lei natural e universal, não existe efeito sem causa, nem causa sem efeito. A meu pai Luiz minha mãe Tereza a minhas irmãs Taiza, Tassia, Tacira e Tais por todo amor incentivo, e dedicação e ensinamentos. Aos meus Avós José (in memoriam) Antônia (in memoriam), Augusto (in memoriam), Neposiana (mãe branca) (in memoriam), pelos ensinamentos passados aos meus pais, e carinho que pude desfrutar enquanto estavam no plano terrestre. Aos meus tios Avos (in memoriam) pelas palavras de sabedoria, em especial aos meus tios Jacinto e Pradin Sé. A minha família, aos meus tios e tias paternos a minha Tia materna Dona Cicera, a minha madrinha Socorro ao meu padrinho Assis, aos meus primos Antônio(Quirino), Camyla (Amarela) demais primos. A Pitadoras, Isaac newton, Abert Einstein a este e outros cientistas que não estão citados, se não ia terminar a página e ainda ia ter nomes por citar, por tudo que fizeram pela matemática e pela física, suas descobertas teoremas, conhecimento. Aos filósofos, Platão, Friedrich Nietzsche aos iluministas e aos que estiveram na revolução francesa, por toda revolução intelectual que poderão trazer a humanidade. A Napoleão Bonaparte por ter ido ir invadir Portugal e assim fazer com que a corte portuguesa mudasse para o Brasil e o resultou na independência. A democracia tão linda ao qual vivemos A Pernambuco esse estado lindo de cultura sem igual, terra dos altos coqueiros do melhor carnaval do mundo, do Recife a Petrolina meu coração se enche de alegria e amor, o paraíso na terra é Pernambuco, ser pernambucano é uma honraria. Ao todos os poetas que tive oportunidade ler por todos que ainda ei ler, por cada verso que me encantou e inspirou e inspirara os meus dias. A Eduardo Campos (in memoriam) por ter assinado a gratuidade da Upe. A Dilma, Aécio Neves, Marina silva, Lucina Genro e Eduardo Jorge pastor Everaldo por terem feitos a pior campanha que já vi em toda minha vida.

5 5 Ao politicamente correto por ter criado tantos juízes em nossa sociedade, Se dizem defensores da liberdade. E no fim das contas pregam o discurso da via única, quando podem atiram a primeira pedra, mesmo cometendo as mesmas atitudes que condenam. A Reginaldo Rossi, Luiz Gonzaga, Raul Seixas, The Beatles, Elvis, Volver, Mamonas, Azeitonas, Pedro Abrunhosa, ao Sonata Ártica Nightwish ao Epica, Pablo do arrocha e pelas músicas que fizeram parte da trilha sonora deste trabalho. Aos meus professores por todo conhecimento que poderão me passar, ao professor Rômulo por toda paciência que teve em me orientar. Aos amigos meus de faculdade, aos meus companheiros de Rotaract Cassio, Caio, Daniel, Daniel Siqueira, Karina, João, Mari, Marcinha Marcella, Thiago, Stefanie, Rebeka, Joyce, Vânia pela oportunidade de presidi-lo em momento tão especial de minha vida, às pessoas que através dele tive a oportunidade conhecer e colaboram para o meu amadurecimento, James, Wyama, Bia, Sildemberg, a paraibana Hyalle, Dalila, Diego, Demais companheiros do distrito 4500, o Rotaract para mim foi a maior oportunidade de aprendizado que puder ter nesses últimos tempos, Amo vocês. Ao Esde, que por tantas quartas feiras foi meu refúgio onde tive oportunidade de Compreender melhor a vida, e poder despertar e mim a vontade ser melhor a cada dia. Aos meus amigos de internet e leitores do recanto das letras que leem meus simples textos e desabafos e pela paciência. Samatha por ter me ajudado com os slides. A Diego, Nerd, Raul Hallyson, Laercio, Elton, Cleyllton, Rik, Leticia, Polliana Francisco, minhas vizinhas e atuais moradores do AP 102 por todos momentos e resenhas, Ozair, Saulo e Nayara pelos resumos que fizeram e que tanto me ajudaram. A Deksa por todos os aperreios e apoio, e carinho. A todos que vocês de algum modo estiveram presentes nessa minha trajetória por caruaru meu muito obrigado.

6 6 Resumo A busca pela excelência e êxito no desenvolvimento de software, fez com que ao longo do tempo surgissem métodos para não somente produzi-los mas garantir também a qualidade do software. Com métodos ágeis a engenharia passou a valorizar as interações que ocorrem no processo de desenvolvimento, Entre as interações está presente a volatilidade dos requisitos exigidos pelo cliente, os requisitos evoluem e se modificam com próprio processo de desenvolvimento, para apoiar o esse processo em metodologias como Scrum existem uma série de ferramentas para apoiar os desenvolvedores, elas têm foco em fornecer base de histórica e detalhamento dos requisitos a serem implementados. Nesse cenário surge Business Process Management (BPM) paradigma da computação empresarial para incrementar agilidade nas organizações. Nesse contexto este trabalho tem como proposta o desenvolvimento de uma ferramenta de que use Bug tracker BPM como forma de gestão alinhada com as práticas ágeis e assim facilitando a adaptação dos processos internos das organizações ao processo de desenvolvimento de software e com isso gerar indicadores de produtividade, gargalos e melhorias, possibilitando tomada de decisão da alta gestão para apoiar o desenvolvimento de software ágil com ênfase nos requisitos, através da automação de processos de numa metodologia ágil. Palavras-chave: Engenharia de software; Requisitos; Métodos ágeis; Scrum; BPM; Bug tracker;

7 7 Abstract The search for excellence and success in software development, has made over time arose methods to not only produce them but also ensure the quality of software. With agile engineering came to value the interactions that occur in the development process, Among the interactions is present volatility of the requirements required by the customer, the requirements evolve and change with the development process itself, to support this process in methodologies such as Scrum there are a number of tools to support developers, they have focused on providing historical base and detailing requirements to be implemented. In this scenario arises Business Process Management (BPM) paradigm of enterprise computing to increase agility in organizations. In this context, this paper aims to develop a tool that uses Bug tracker BPM as a way to line management with agile practices and facilitating the adaptation of internal processes of organizations to the software development process and thus generate productivity indicators, bottlenecks and improvement, allowing for making senior management's decision to support the agile software development with emphasis on the requirements through the automation of processes in an agile methodology. Keywords: Software engineering; Requirements; Agile methods; Scrum; BPM; Bug tracker

8 8 LISTA DE FIGURAS Figura 1. Ciclo de vida modelo cascata. Figura 2. O ciclo de vida Scrum. Figura 3. Elementos de um processo. Figura 4. Modelo do processo do Bug tracker baseado na metodologia Scrum na notação BPMN. Figura 5. Cadastrar Backlog. Figura 6. Analisar Backlog. Figura 7. Sprint Backlog. Figura 8. Desenvolver Requisito. Figura 9. Realizar Testes. Figura 10. Revisão da Sprint. Figura 11. Realizar Implantação. Figura 12:Grafíco de analise carga. Figura 13: Gráficos dos trabalhos em andamento. Figura 14: Tempo de Ciclo. Figura 15: Histograma de duração. Figura 16: Atividade do processo. Figura 17. Classificação de Atividades.

9 9 Sumário 1 INTRODUÇÃO CARACTERIZAÇÃO DO PROBLEMA OBJETIVOS E METAS METODOLOGIA E ESTRATÉGIA DE AÇÃO RESULTADOS E IMPACTOS ESPERADOS REVISÃO DE LITERATURA ENGENHARIA DE SOFTWARE ENGENHARIA DE REQUISITOS DEFEITO DE SOFTWARE METODOS AGEÍS SCRUM BPM MODELAGEM DE PROCESSOS BPMS PROPOSTA DE BUG TRACKER ORIENTADO PROCESSOS CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS... 42

10 10 1 INTRODUÇÃO 1.1 CARACTERIZAÇÃO DO PROBLEMA Os processos de negócios têm que oferecer vantagens competitivas, logo, para serem efetivadas, as organizações devem ser capazes de definir, analisar, melhorar, medir e controlar os seus processos (ANDRADE et al, 2013). Uma das abordagens crescentes no mercado com este objetivo é o gerenciamento de processos de negócio. De acordo com Korhonen (2007), Business Process Management (BPM) é um paradigma chave da computação empresarial para incrementar agilidade nas organizações. Segundo Kaplan & Norton (1997), tradicionalmente as corporações têm tratado suas unidades de serviço de TI como centros de despesas distintos, o que pouco contribui para alinhá-las, de modo à melhor servir às unidades de negócio e à corporação. Nesse contexto surge à necessidade de desenvolver uma ferramenta orientada a processos que apoie as empresas de desenvolvimento software que utilizam metodologia ágil como forma de gestão, resultando assim em um melhor controle, aumentando a visibilidade e gerando indicadores de produtividade dentro dos processos ágeis. 1.2 OBJETIVOS E METAS Desenvolver uma ferramenta de Bug tracker que seja alinhada com as práticas ágeis e assim facilitando a adaptação dos processos internos das organizações ao processo de desenvolvimento de software e com isso gerar indicadores de produtividade, gargalos e melhorias, possibilitando tomada de decisão da alta gestão. São objetivos deste trabalho: Revisão da literatura dos assuntos abordados; Pesquisar ferramentas de Bug tracker. Desenvolver uma ferramenta que consolide a proposta do trabalho aqui pesquisado.

11 METODOLOGIA E ESTRATÉGIA DE AÇÃO Ao utilizar modelos de referências de processo juntamente com metodologias de gestão de projeto, a organização tende a enfrentar uma série de desafios, como a existência de possíveis sobreposições entre os modelos e metodologias, as quais devem ser tratadas. Neste sentido, uma forma de abordar as similaridades e diferenças entre eles é mapear os requisitos de um modelo em relação aos requisitos da gestão. Mesmo que os requisitos sejam compatíveis ou complementares, as diferenças de rigor podem significar que os resultados de um modelo podem não atender ao requisito da gestão (PAULK, 2004). Para que seja possível atender os objetivos deste trabalho, responder as questões de pesquisa e entender os assuntos que embasaram a ferramenta a ser desenvolvida, foi utilizada a metodologia de pesquisa revisão da literatura. Após a revisão da literatura será possível observar a importância de identificar as interseções do gerenciamento do processo de negócio com as metodologias ágeis, bem como a relevância de elaborar uma ferramenta de apoio para junção e a realização da implantação dos conceitos abordados na pesquisa. A visão geral da metodologia de pesquisa utilizada para realização deste trabalho, foi composta por duas etapas. A primeira etapa se refere à realização de uma Revisão da Literatura do assunto de pesquisa para identificar, analisar e selecionar os trabalhados disponíveis relacionados ao tema. Além da revisão informal, um estudo baseado em revisão sistemática será conduzido, com o objetivo de reduzir o viés de uma revisão informal e, também, permitir que a pesquisa bibliográfica possa ser atualizada com novas publicações (KITCHENHAM, 2004). A segunda etapa após a identificação dos assuntos abordados na revisão da literatura, foi desenvolvido uma ferramenta de Bug tracker para apoiar processos de fabricação do software com ênfase nos requisitos, para que cada etapa do processo possa ser monitorada e apresente ganhos reais de eficiência, e forneça a equipe dados estáticos sobre detalhados sobre o processo. As duas etapas da metodologia de pesquisa têm como objetivo: 1. Identificar os desafios na gestão ágil; 2. Identificar os procedimentos, etapas e processos contidos em uma documentação ágil;

12 12 3. Identificar os métodos ágeis e as interações das atividades e dos procedimentos internos adotados nas organizações; 4. Identificar relacionamento dos assuntos abordados com os a ferramenta proposta. 5. Desenvolver uma ferramenta Bug tracker para apoiar o desenvolvimento de Sofware ágil 1.4 RESULTADOS E IMPACTOS ESPERADOS O mapeamento dos processos de desenvolvimento software, utilizando metodologia ágeis visa garantir maior consistência na entrega do produto dando ao cliente a possibilidade de dispor da ferramenta em um tempo menor, garantindo com que os esforços para cumprir os requisitos o sejam otimizados. Quando as etapas do trabalho forem devidamente concluídas será possível mensurar, o quanto se pode ganhar na eficiência e do cumprimento dos requisitos, e fazer com que as metodologias ágeis melhorem culturalmente a maneira com que os processos orientados a requisitos são trabalhados pelas organizações. O resultado esperando da primeira etapa do trabalho dará as bases para que o Bugtrack orientado a processos com ênfase em requisitos possa ser construído, atendendo as intersecções com metodologias ágeis. A segunda etapa é ter uma ferramenta capaz trazer uma melhor tomada de decisão e agilizando o cumprimento dos requisitos, fazendo com que cada etapa do desenvolvimento apresente ganhos reais de eficiência e uma estruturação ampla dos processos de fabricação do software

13 13 2. REVISÃO DE LITERATURA 2.1 ENGENHARIA DE SOFTWARE De acordo com MAFRA (2004), durante os últimos 20 anos, sistemas de software tem exercido um papel fundamental e crítico em nossa sociedade, estão presentes em nosso dia a dia, desde aplicações simples de smartfone, editores de texto, até aplicações mais complexas ERPs softwares para gerenciamento de redes, sistemas de banco de dados entre outras ferramentas. Segundo PINTO (2011), na década seguinte, a de 1960, constatou-se que desenvolver softwares é diferente de desenvolver hardware. O desenvolvimento de hardware exige uma exaustiva revisão de projeto antes que este possa ser posto na linha de produção, já o software permite que a medida que ele seja produzido, permite que ele seja revisado e testado. Ao longo do tempo, a demanda por softwares aumentou consideravelmente, aumentou também a complexidade dos softwares. Esses fatores no decorrer do tempo fizeram com que problemas em relação a produção fossem aparecendo, problemas esses que foram se repetindo de forma recorrente nos diversos tipos de sistemas, a esses problemas recorrente damos o nome de crise software. A crise software abrange problemas relacionados a diversas áreas do software pautados, desde a maneira ao qual softwares eram projetados pelos gerentes de projetos, que concentravam suas preocupações nos custos e no tempo de produção, a maneira como ocorre a implantação das ferramentas de software, a maneira como era feita a manutenção da mesma. Fatores esse afetam a qualidade e estabilidade, condições que se precisam garantir para que o usuário possa desfrutar dos recursos presente no software. No processo de implantação, os usuários devem ter uma fácil adaptação a utilização. A manutenção precisa ser feita de maneira dinâmica de modo que as atualizações da ferramenta de software possam atender necessidades de utilização do usuário, necessidades essas como a adição de funções e revisões do design, e corrigir problemas de funcionamento. Como reação a essa crise houve, o estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente software que seja confiável e que funcione eficientemente em máquinas reais (FRITZ BAUER-1969). A engenharia de software disciplina tem o objetivo de prover métodos organizados e boas práticas que visam atender as necessidades de projetos cada vez mais complexos (BOEHM, 2006).

14 14 Segundo SOMMERVILLE, (2011) ela engloba todas as etapas de desenvolvimento do projeto para que seja garantida a solução com qualidade. É a base para o ciclo de vida da construção do software, desde as fases iniciais, especificações de requisitos do sistema, até sua implantação e manutenção. Com estabelecimento da engenharia de software foram surgindo diversos modelos de processo de software, modelos que visam explicar como o software pode ser construído. Um modelo de processo de software é uma representação abstrata de um processo de software. Cada modelo de processo representa um processo a partir de uma perspectiva particular, de uma maneira que proporciona apenas informações parciais sobre o processo (SOMMERVILLE, 2007). Cada modelo apresenta como se dá o ciclo de vida do processo de desenvolvimento, seguem abaixo alguns modelos que são usados para gerir este processo. 1. O modelo em cascata; 2. Desenvolvimento evolucionário; 3. Desenvolvimento iterative; 4. Modelo de desenvolvimento espiral; 5. Modelo de desenvolvimento incremental; 6. Desenvolvimento baseado em components. Pressman (2006) cita outros modelos: 1. Modelo Incremental; 2. Modelo RAD; 3. Modelo de Desenvolvimento Concorrente; 4. Modelo de Métodos Formais; 5. Processo Unificado. Já FALBO (1998), cita em seu trabalho que a escolha de um modelo de ciclo de vida (ou modelo de processo) é o ponto de partida para a definição de um processo de desenvolvimento de software. Um modelo de ciclo de vida organiza as macro-atividades básicas, estabelecendo precedência e dependência entre as mesmas (FALBO, 1998). O ciclo de vida inclui desde as etapas de construção software até as etapas de manutenção, segundo PRESSMAN (2006) o modelo clássico de ciclo de vida chamado

15 15 de modelo cascata, traz uma abordagem sistemática, sequencial ao desenvolvimento do software, que se inicia no nível do sistema e seus requisitos e avança ao longo da análise do sistema, projeto, codificação teste e manutenção. A figura 1 apresenta as fases da modelo cascata: Figura 1. Ciclo de vida modelo cascata (Fonte: Adaptado Royce 1970 ) De acordo com SOMMERVILLE, (2011) cada uma das seguintes atividades pode ser resumida da seguinte maneira: 1. Analise e definição dos requisitos: os serviços, restrições do sistema, serão definidos por consulta aos usuários. Em seguida, são definidos em detalhes e funcionam como uma especificação do sistema; 2. Projeto de sistema e software. O processo de projeto aloca os requisitos tanto para hardwares quanto para o sistema, definido assim arquitetura geral do sistema, definido assim sua descrição fundamental e os relacionamentos; 3. Implementação e teste unitário. Nesse estágio o projeto do software e desenvolvido como um conjunto de programas ou unidades de programas. Essa fase visa verificar também se cada unidade implementada atendera as suas especificações.

16 16 4. Integração e teste de sistema. As partes do programa são integradas e testadas e forma conjunta, visando assim assegurar que os requisitos do sistema tenham sidos atendidos, após isso ele poderá ser entregue ao cliente. 5. Operação e manutenção: nessa fase que é a mais longa do processo, é onde o software entra em operação, e a partir daí ele será, os bugs que forem dectados começaram a serem corrigidos, poderá haver ampliação do sistema havendo assim a adição de novas funcionalidade e descobertas de novos requisitos. Este modelo como já dito antes, fala das etapas básicas da construção de software etapas essas que são semelhantes em diversos modelos, para fins de estudo e construção da ferramenta nos os tópicos seguintes apresentaremos a técnicas e metodologias que serão as bases para sua elaboração ENGENHARIA DE REQUISITOS De acordo com BECK (2000) Organizações de desenvolvimento de software geralmente enfrentam grandes desafios na produção de seus sistemas. Grande parte disso está relacionado à volatilidade de seus requisitos. O acompanhamento de como os requisitos, se comportam ao longo do desenvolvimento é importante para se garantir o produto final atenda às necessidades dos clientes. Segundo DUARTE (2012) Um requisito pode ser entendido como uma condição ou funcionalidade à qual o sistema desenvolvido deve corresponder. A análise de requisitos é o processo de descobrir, refinar, modelar, e especificar os propósitos do cliente (PRESSMAN, 1997 apud DUARTE 2012). Durante o levantamento de requisitos cliente e a empresa vão trabalhar juntos para poder encontrar a melhor maneira para que os requisitos sejam estabelecidos. Entende-se que o próprio processo de definição de requisitos gera um feedback que acabar modificando os próprios requisitos (HAZAN, 2003). A deficiência no tratamento de requisitos tem sido apontada como a principal causa de fracassos de projetos de software (HOFMANN,2001) Esse processo é sistemático e abrange diversas atividades, tais como elicitação, análise e negociação, documentação, validação e gerência de requisitos (KOTONYA,1998).

17 17 De acordo com NADDEO (2002) cada umas as etapas citadas da engenharia de requisitos podem ser resumidas do seguinte modo: Elicitação: nessa fase os requisitos serão descobertos, serão feitas reuniões com stakeholders, nas quais serão discutidas expectativas objetivos ao qual aplicação se destina, a equipe de desenvolvimento vai começar a entender o domino da aplicação para assim encontrar maneiras de entender e resolver a complexidade do problema em questão. Se identifica as partes interessadas e papel de cada stakeholders no sistema e o seu nome, além disso se define também as técnicas que vai serão usadas para realização desse processo; Análise e negociação: As atividades conduzidas no contexto de Análise e Negociação de requisitos destinam-se a resolver problemas relacionados aos requisitos que envolvam diferentes percepções do mesmo problema ou necessidade por mais de um stakeholder, bem como os problemas gerados pela representação do conhecimento obtido de mais de um stakeholder; Documentação: Após o identificados os requisitos devém ser documentos para que possam, servir como base para as etapas restantes do processo de desenvolvimento; Validação: nesta etapa a de se verificar a consistência dos requisitos levantados; Gerencia de requisitos: etapa de administração dos requisitos ao longo do projeto, pois possuem volatilidade ou seja podem ser alterados conforme as necessidades que venha a surgir no decorrer do processo de desenvolvimento mas essas alterações não deve comprometer o tempo final de entrega do projeto. Os requisitos podem ser classificados no geral em funcionais, e não funcionais: Funcionais: representam aquilo que o sistema deve fazer. Ou seja tudo aquilo que acaba sendo transformado em funções do sistema, podem ser divididos em, essenciais, desejados e supérfluos

18 18 Não funcionais: representam os atributos do sistema, definem propriedades e as restrições do sistema, estão relacionados com segurança, usabilidade, confiabilidade e manutenibilidade e tecnologia envolvida DEFEITO DE SOFTWARE Ao gerenciar um projeto, a gerente ira dispor ferramentas para tornar simplificar o acompanhamento do ciclo de vida, para que assim ele possa minimizar e até evitar que ocorram falhas durante o projeto. Com software não poderia ser diferente, evitar e gerenciar possíveis falhas no produto é essência para que a empresa de software se manter competitiva no mercado, conceito de Bug tracker sugere uma ferramenta, que apoia a gestão defeitos para que assim manter a qualidade do software. Evitar defeitos no software é garantir que o cliente possa dispor dos padrões de qualidade aos quais ele requisitou é evitar possíveis custos, portanto, descobrir os defeitos do(s) software(s) da empresa não é suficiente, é essencial adotar o gerenciamento de defeitos no processo de teste para minimizar, controlar, evidenciar os riscos para que os seus impactos não sejam grandes (ELIZA; LAGARES, 2011). O grande objetivo do Teste é garantir qualidade ao sistema, o que não quer dizer que o mesmo vai ser entregue ao cliente sem nenhum problema. (ELIZA; LAGARES, 2011). No Scrum diferentemente de outras metodologias as equipes de desenvolvimento e teste de estão integradas no mesmo time, de modo que a equipe de teste passe a ser vista como parceira e não adversaria da equipe de desenvolvimento. De acordo com ELIZA; LAGARES, (2011) muitas pessoas confundem o significado de defeito, erro e falha, cada conceito pode ser resumido em: Erro (engano): ação humana que produz resultados incorretos, como por exemplo, a implementação errada de um algoritmo; Defeito (bug): falha em um sistema que pode ocasionar uma anomalia ao tentar desempenhar a função proposta. Por exemplo, omissão de informações e cálculos incorretos; Falha: ação inesperada no software. Por exemplo, o sistema apresenta resultados diferentes do planejado.

19 19 No mercado existem diversos tipos de ferramentas que visam apoiar as equipes de teste, no controle e detecção de erros/defeitos que podem vim a resultar em falhas do sistema. Entre elas podemos citar: o Mantis; BugZilla; Testlink; Salomé TMF. 2.2 METODOS AGEÍS Os métodos de desenvolvimento ágil, surgiram em respostas aos problemas percebidos pela indústria, especialmente quanto a taxa de sucesso dos projetos (ROSE MELO, 2010). A taxa de sucesso dos projetos vinha caindo, segundo JOHNSON, (1995) em um estudo da Standish Group (1995) com mais de 30 mil projetos de desenvolvimento de produtos de software desde 1994, revelou que, embora tenha havido melhorias com o passar do tempo, ainda há um grande problema no setor. Problemas aos quais foram apontados por esse estudo, estão relacionados a atraso na entrega de aumento dos custos, e taxa de implementação (projetos que se tornaram, produtos de software que realmente forma utilizados pelo usuário final). Por décadas o desenvolvimento de software seguiu o modelo clássico de cascata para desenvolvimento de produtos (ROSE MELO, 2010). Segundo Pinto, 2011, esse modelo prega a evolução sequencial dividindo o projeto de forma semelhante ao que se faz na linha de produção. Esse enrijecimento do modelo de gestão adotado garantiu que as taxas de sucesso das entregas dos softwares desenvolvidos fossem baixas (ROSE MELO, 2010). Os métodos ágeis surgem como respostas aos métodos tradicionais, que são baseados no seguimento de um plano bem definido, excesso de documentação e rigorosa padronização (NERUR et al., 2005). As metodologias ágeis, que ganham mais destaque no início do ano de 2001 com a definição do Manifesto Ágil (BECK et al., 2001). O manifesto apresenta um conjunto de valores e princípios que provem as bases para desenvolvimento ágil. Nele os autores falam: Estamos descobrindo maneiras melhores de desenvolver software, fazendoo nós mesmos e ajudando outros a fazerem o mesmo. Segundo Manifesto ágil(2001), os valores são: Indivíduos e interações mais que processos e ferramentas

20 20 Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano à esquerda. Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens No manifesto é apresentado os seguintes princípios: 1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. 2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. 3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. 4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. 5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. 6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. 7. Software funcionando é a medida primária de progresso. 8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. 9. Contínua atenção à excelência técnica e bom design aumenta a agilidade. 10. Simplicidade--a arte de maximizar a quantidade de trabalho não realizado é essencial. 11. As melhores arquiteturas, requisitos e designs emergem de equipes auto organizáveis.

21 Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo. De acordo com Cohen et al, (2004) a partir da divulgação do Manifesto Ágil, metodologias como Adaptive Software Development (ASD) (Highsmith e Cockburn, 2001), SCRUM (Schwaber e Beedle, 2002) e extreme Programming (XP) (Beck e Andres, 2004) ganharam um grande número de adeptos e se tornaram objeto de pesquisas acadêmicas. Enquanto as metodologias tradicionais de desenvolvimento mantêm o foco na geração de documentação sobre o projeto e no cumprimento rígido de processos, a proposta ágil é concentrar as atenções no desenvolvimento em si e nas relações entre os participantes (MUNDIN et al., 2002). Projetos que seguem métodos ágeis, permitem flexibilidade, visando enxugar a produção e evitar o desperdício, o cliente participa ativamente do processo de desenvolvimento, de modo que assim o produto final consegue se aproximar daquilo que o cliente espera SCRUM De acordo com PRESSMAN, (2006) o framework Scrum é uma metodologia ágil de desenvolvimento para gestão e planejamento de projetos de software. Foi elaborada por Jeff Sutherland e por sua equipe, no início da década de 90, e tinha como base o processo de produção de automóveis de indústrias japonesas. Segundo CARVALHO E MELO (2009) o nome Scrum surgiu da comparação entre desenvolvedores e jogadores de Rugby. Scrum é a denominação da rápida reunião que ocorre quando os jogadores de Rugby irão iniciar um lance. No Rugby, cada time age em conjunto, como uma unidade integrada, em que cada membro desempenha um papel específico e todos se ajudam em busca de um objetivo comum (CARVALHO E MELO 2009). Assim como no Rugby, no Scrum a cada nova Sprint os desenvolvedores se reúnem para assim debater e chegar num consenso sobre a fase do projeto que será iniciada, dessa maneira pode se garantir que haja flexibilidade para observar e discutir tanto o que foi planejado antes do início do projeto quanto para lidar com os desafios que surgiram ao longo da execução do projeto.

22 22 Esta metodologia fornece técnicas específicas para a fase de desenvolvimento, constitui práticas gerenciais que devem ser adotadas para o sucesso de um projeto. Segundo SCHWABER, (1995) Scrum baseia-se em seis características flexibilidade dos resultados; flexibilidade dos prazos; times pequenos; revisões frequentes; colaboração; orientação a objetos. PEREIRA et al, (2007) ressalta que as práticas do Scrum podem ser aplicadas em qualquer conjuntura onde pessoas precisem trabalhar juntas para atingir um objetivo comum. Logo podemos aplicar Scrum a projetos que não seja essencialmente de desenvolvimento de software. Segundo CARVALHO E MELO, (2009) temos como praticas gerenciais do Scrum as seguintes atividades: Product Backlog, Daily Scrum, Sprint, Sprint Planning Meeting, Sprint Backlog e Sprint Review Meeting. Product Backlog é a etapa inicial do processo onde é feito uma série de reuniões com objetivo, de definir os requisitos que serão implementados, reuniões essas que contam com todos os envolvidos, investidores e parceiros no projeto, são apontados os itens com todas as necessidades do negócio e os requisitos técnicos a serem desenvolvidos (CARVALHO E MELO 2009). A lista de funcionalidade fica em constante adaptação ao longo de todo o projeto com o objetivo de atender as mudanças que podem surgir no decorrer deste (SCHWABER, 2009). Sprint Planning Meeting é a reunião em que o time faz o planejamento do Sprint (CARVALHO E MELO 2009). Sprint Backlog ANDRADE (2012) fala que esta etapa consiste na análise do Product Backlog, com a elaboração de um conjunto dos requisitos aceitos, que serão implementados na Sprint. Daily Scrum consiste em reunião diária, rápida que possibilita o controle das atividades que serão feitas durante o dia. Três perguntas devem ser respondidas por cada membro sobre suas responsabilidades (RISING & JANOFF, 2000): O que foi feito ontem? O que será feito hoje? Há algum obstáculo à realização de suas atividades? Sprint Review Meeting Após cada Sprint a equipe se reúne avalia os resultados erros, acertos, a Sprint dura de duas a quatro semanas com a sua revisão é possível apontar quais caminhos o desenvolvimento do software seguira até ele esteja pronto para implantação. Caso nessa revisão surjam novos requisitos eles serão inseridos no Product Backlog, para serem adicionadas nas Sprints posteriores, dependendo assim do seu grau de importância pra o projeto.

23 23 A figura 2, mostra como estão interligadas cada etapa do clico de vida do Scrum, e também o tempo médio que cada uma delas leva para sua conclusão: Figura 2. O ciclo de vida Scrum - (THAMIEL, 2009) No Scrum os diversos stakeholders do projeto são divididos em dois grupos principais: os envolvidos e os comprometidos. Os envolvidos são os diversos espectadores do projeto que não têm autoridade direta sobre o processo (SCHWABER, 2004). Pinto 2001 cita que os comprometidos são aqueles que estão diretamente ligados ao projeto e tem papéis bem definidos, sendo eles: Scrum Master, Product Owner e Time (equipe Scrum). O Scrum Master deve trabalhar para que o processo Scrum aconteça e para que não existam impedimentos para que os membros da equipe realizem seu trabalho (CARVALHO E MELO 2009). O Scrum Master é comparado com gerente projetos contudo SCHWABER, 2004, ressalta que enquanto o gerente de projetos gerencia ditando o ritmo do trabalho, o ele gerencia o funcionamento do Scrum. Logo ele é o responsável por garantir seu funcionamento, fazer com que as práticas do Scrum sejam efetivamente realizadas. A reponsabilidade de definir requisitos cabe ao Product Owner, Segundo CARVALHO E MELO (2009) sendo ele membro do time tem ao qual tem o papel de representar o cliente interno ou externo. Para PEREIRA et al, (2007) que além disso decide a data do release e o que deve conter nele, é responsável pelo retorno financeiro (ROI) do produto, e deve priorizar os requisitos de acordo com o seu valor, ajustá-los conforme a prioridades para cada Sprint, aceita ou rejeita o resultado de cada Sprint.

24 24 O time é justamente a equipe de desenvolvimento, cada time é responsável pelo seu próprio gerenciamento e organização, PINTO, (2011) ressalta que dessa forma, o Scrum Master trabalha apenas como facilitador no dia-a-dia da equipe. São os membros classificados nesse papel que decidem como os requisitos vão ser transformados em funcionalidades (SCHWABER, 2004). PRESSMAN (2011), cita Beedle e seus Colegas [bee99] expondo que O Scrum pressupõe a existência do caos dessa desse modo o framework Scrum procura trabalhar num mundo onde a eliminação de incertezas é impossível. 2.3 BPM Gerenciamento de Processos de Negócio (do original em inglês: Business Process Management BPM) é uma abordagem de gestão que vem recebendo interesse crescente da academia e da indústria na última década (SANTANA et al, 2010). Segundo mini dicionário AURELIO, processo é uma sucessão de estados ou de mudanças, de modo que se possa realizar ou executar uma coisa. Em linhas gerais processo é o conjunto de passos/atividades necessárias para que uma ação seja executada. BPM refere-se à gestão do ciclo completo de gerenciamento de processos de negócio, o qual inclui: desenho, análise, implementação, execução e melhoria contínua dos processos de uma organização (SANTANA et al, 2010). Assim como os requisitos de uma ferramenta de uma ferramenta de software os processos evoluem com passar do tempo e precisam ser e ter uma gerencia que permita o ganho de eficiência e ao mesmo tempo flexibilidade para lidar com mudanças que podem vim a ocorrer ao longo do tempo. Os princípios de BPM enfatizam a visibilidade, a reponsabilidade, e a capacidade de adaptação dos processos e constantemente aperfeiçoar resultados e melhor enfrentar os desafios de um ambiente de negócio globalmente diversificado(cbok,2013). Dentro do contexto da adoção do BPM é de suma importância a análise minuciosa de como está todo o andamento organizacional com a implantação da metodologia, pois é preciso mapear o potencial de cada processo, visando o que cada um pode gerar ou não no ponto de vista da otimização constante (JOSE et al,2014).

25 25 A questão é que em muitas organizações seus diversos departamentos trabalham de maneiras separadas o que dificulta a adoção de BPM, sua adoção sugere que a empresa passe a ser enxergada como um todo, sendo ela é composta por diversos sub processos que se integram. O BPM possibilita, por exemplo, que um analista de negócios integre os sistemas de tecnologia da informação (TI) com as metas estratégicas de uma organização da forma mais viável (JOSE et al,2014). Os Processos de negócio definem como as organizações executam o trabalho para entregar valor a seus clientes e aplicar BPM é se concentrar nos processos interfuncionais que agregam valor para esses clientes(cbok,2013). Segundo AMARAL et al (2008) o BPM possibilita as seguintes vantagens: Melhoria da velocidade do negócio: os tempos de ciclo dos processos podem ser reduzidos significativamente por meio da sua automação, realização de atividades paralelas, controle e monitoramento; Aumento da satisfação dos clientes: os clientes internos e externos podem obter informações mais rapidamente e facilmente devido à melhoria no tempo do ciclo e do monitoramento, já que as ocorrências não se perdem ao longo do caminho, assim, ações preventivas e corretivas são gerenciadas com maior agilidade; Integridade: o BPM, por ser também estratégico para suportar certificações de qualidade (ex.: ISO) e exigências regulatórias (ex.: Lei Sarbanes-Oxley), garante a integridade por seguir todos os passos especificados no processo; Flexibilidade: a intervenção da área de informática é minimizada, existindo uma grande flexibilidade para alteração de fluxos e regras de negócio; Maximização da melhoria e evolução dos processos: a disponibilidade de indicadores e métricas sobre custos, tempos de execução, carga de trabalho e outros aspectos, geram insumos fundamentais para um trabalho de melhoria.

26 26 O CBOK, (2013), reforça que Adoção de BPM é uma jornada, não um destino desse modo podemos entender que ao longo de sua adoção ele reforçara desde as estratégias da empresa até a operação, dando maior resiliência a organizacional e operacional, menos intrusiva fazendo com assim se tenha o aumento de produtividade MODELAGEM DE PROCESSOS Ao adotar BPM, precisamos ter noção de como os processos estão organizados, e como se dão as interações nele, quais são suas etapas? Nesse processo temos subprocessos? Quais são suas atividades e tarefas? Faz-se necessário que ele seja mapeado e modelado para que assim possa iniciar de fato a sua gerencia. De acordo com LOJA (2011), Com a modelagem dos processos é possível visualizar o funcionamento da organização através dos modelos obtidos. A modelagem servira para aumentar o nível de compreensão dos processos, nela deverão estar contidos não só as tarefas e subprocessos, como também os papeis dos atores envolvidos, além os recursos que estão sendo utilizados. Desse modo a organização passa a desenvolver sua capacidade de BPM, Segundo o CBOK, (2013) para ter a capacidade de gerenciar processos de negócio, a organização deve possuir métodos otimizados, pessoas preparadas e tecnologias apropriada para tal. A figura 3 ilustra os elementos básicos de presentes num processo: Figura 3. Elementos de um processo (Araujo e Borges, 2001) A modelagem de processos de negócio deve incluir, a informações atuais do processo (As Is), o modelo futuro do processo (To Be), Segundo FRANCO, (2014) ela é

27 27 formada por um conjunto de técnicas que buscam descrever as atividades dentro da empresa e como elas se relacionam e interagem com os recursos do negócio buscando alcançar o objetivo do processo. A partir do momento em que se tem o modelo do processo com todas as suas atividades e executores definidos, é possível simular a sua execução a partir de dados coletados no dia-a-dia e, dessa forma, verificar o fluxo de informações, testar as regras definidas e principalmente medir a eficiência do processo (PUNTAR et al, 2009). Modelagens no geral são representadas por diagramas de fluxo de trabalho, para entender a situação atual (As-Is) e a situação futura desejada (To -Be). Segundo OLIVEIRA S (2012), o autor fala que diagramas de fluxo servem como uma análise de eventuais lacunas entre como a organização trabalha e como deve trabalhar no futuro, sinalizando os pontos que precisam ser melhorados para que possa alcançar efetividade na melhoria de processos de negócio BPMS De acordo com PUNTAR et al, (2009) [TIC/IDTA/AT, 2008] um BPMS (Business Process Management System) é um ambiente integrado de componentes de software que automatizam o ciclo de vida de processos de negócios, desde a sua concepção e modelagem inicial, passando pela execução e monitoramento, até a incorporação de melhorias, inclusive com a possibilidade de simulação. Quando falamos em BPMS estamos falando em automação de processos, em geral as ferramentas presentes no mercado apresentam um conjunto de instrumentos que a partir do modelo já otimizado (To-Be), fazem a automação. Segundo PUNTAR et al, (2009) a automação ocorre através do acompanhamento de atividades por um motor de execução de processos, que funciona recebendo e enviando as atividades aos agentes responsáveis pela sua execução. A automação do processo ocorre com a criação de uma ferramenta a partir do modelo de processo de negócio na notação BPMN, ela irá gerenciar o fluxo de trabalho do processo. Um webservice, no qual os subprocessos, as etapas tarefas e atividades envolvidas, estão devidamente interligados por meio das regras de negócio para a execução do processo, estará também definido o papel dos atores envolvidos.

28 28 Um webservice é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis (SHODJAI, 2006 apud TESSARI, 2008). De acordo com SORDI e SPELTA (2006) o modelo conceitual do BPMS valoriza os investimentos já realizados em softwares pelas organizações envolvidas com o processo de negócio, diferentemente da estratégia da reengenharia de uma década atrás, que apregoava o descarte e a substituição dos sistemas de informação. Os autores ainda ressaltam que, no modelo, sistemas de informação legados, hospedados em diferentes ambientes computacionais, com adoção do BPM pela organização continuam a executar as operações necessárias aos processos de negócio ao quais estão envolvidas. De acordo com DUBOULOZ (2004) as ferramentas BPMS deveram ser compostas por cinco blocos são eles: definição de processos; mecanismo de execução e controle de processos; modelagem gráfica do processo; Controle de atividades; e interface do usuário. Para SANTOS et al (2009) os sistemas BPMS são compostos de um conjunto de soluções as quais ele cita as seguintes, workflow (automação de processos), EAI Enterprise Application Interchange (troca de informações entre sistemas empresariais) e TICs (Tecnologias de Informação e Comunicação), ferramentas de modelagem dos processos de negócios (e.g.: UML e BPMN), componentes de integração dos processos (e.g.: ERP, SCM, GED, CRM, data centers e etc.) e ferramentas de simulação e análise (e.g.: Business Inteligence - BI). Funcionalidades essas que estão relacionadas tanto com o conjunto de ferramenta apresentado por DUBOULOZ conjunto esse que é explicitado por SANTOS et al, mostrando a maneira a maneira como as ferramentas se integram para dar vida ao BPMS. ARAUJO e BORGES, (2001) Explicam que um BPMS apresenta as seguintes funcionalidades: definição dos processos, controle de execução dos processos, controle de interações e gerenciamento e acompanhamento de execuções.

29 29 Em um estudo conceitual realizado por PUNTAR et al, (2009), o autor explica cada umas dessas funcionalidades mostrando a maneira como elas se relacionam para geração de melhorias nos processos: A definição de processos está relacionada com a modelagem, ela deve apresentar todas informações necessárias para que processo possa funcionar, é nessa fase em que o processo e suas etapas e ferramentas tornam-se evidentes, suas condições de início e fim. Nessa etapa ocorrem também as simulações, que vão permitir observar como o processo se comporta, e onde o processo pode ser alterado ou não. O controle de execução dos processos, através da interpretação do processo implementado no BPMS, ele irá acompanhar e coordenar a sua execução, ela corresponde à ativação de instâncias, várias instâncias de um mesmo processo ou de processos distintos podem estar em execução simultaneamente em um BPMS. No controle de interações está relacionado a maneira como o BPMS adiciona itens às listas de trabalho atores do processo, tais listas contêm atividades de diversas instâncias dos diversos processos em execução. Os atores, por sua vez, acessam as suas listas de trabalho e selecionam a tarefa que desejam executar. A execução da tarefa envolve a manipulação de documentos, tomadas de decisão ou preenchimento de dados Gerenciamento e acompanhamento de execuções, modelo do processo apresentara o status das atividades realizadas, em execução ou a serem executadas, BPMS pode ter recursos de medida de desempenho e estatística que auxiliam na projeção de melhorias. Das várias ferramentas BPMS disponíveis no mercado Bizagi [Bizagi 2010] e Bonita [Bonita 2010] podem ser citadas como exemplos do estado da prática nesse tipo de software(oliveira et al,2011).

30 30 3. PROPOSTA DE BUG TRACKER ORIENTADO PROCESSOS Os conceitos apresentados no capítulo anteriores serviram como base para que a ferramenta proposta pudesse ser elaborada. A proposta de Bug tracker tem como base e fim mapear e monitorar o processo de desenvolvimento de um requisito até sua implantação, com base na metodologia Scrum de gerenciamento de projetos de software. Para que isso fosse possível de ser realizado, foi feita a modelagem das etapas necessárias para implementação do requisito, modelagem essa que utiliza a notação BPMN. A modelagem e automação do processo fosse realizada foi utilizado o Software Bizagi Studio, posteriormente o modelo gerado serviu como base para automação do processo, etapa que resultou na criação da ferramenta. As figuras 4 a 11 apresentam a modelagem do processo e sua automação, explicando cada tarefa contida no processo e suas respectivas etapas, desde seu início até o seu fim: Figura 4. Modelo do processo do Bug tracker baseado na metodologia Scrum na notação BPMN. (Fonte o autor)

31 31 O processo inicia com o cadastro do Backlog. Nesta etapa que é cadastrado na ferramenta o requisito ao qual será desenvolvido no processo, cada requisito cadastrado é trabalhado em um fluxo de processos na ferramenta fica em um processo. Figura 5. Cadastrar Backlog. (Fonte o autor) A etapa de cadastro do Backlog, contém o formulário apresentado na figura 5, dele fazem parte os seguintes campos: Id do Requisito: código pelo qual o requisito é identificado; Nome Do Requisito; Story: descrição do requisito e sua funcionalidade; Data do Requisito: é data ao o requisito foi cadastrado na ferramenta; Categoria do requisito: Relatório, código fonte e banco de dados; Sistema: nesse campo é relatado software ao qual o requisito pertence; Plataforma: Campo utilizado para que seja informado a plataforma ao qual o requisito pertence; Passo para reproduzir: Caminho para que a funcionalidade seja executada;

32 32 Anexo: espaço utilizado pra que possa ser carregado e enviado o documento (ou imagem), para auxiliar o entendimento do requisito; Ao terminar o preenchimento dos campos, o formulário apresenta os seguintes botões, Guardar e Próximo: ao Guardar tudo que foi preenchido será salvo no banco de dados do Bizagi, ao Clicar em Próximo, além de guardar as informações do processo, ele caminhara para a etapa seguinte. A análise do Backlog, consiste na análise e votação da prioridade implementação do Requisito. Figura 6. Analisar Backlog. (Fonte o autor) A etapa de Analise Backlog contém as informações inseridas no formulário anterior ao qual sofre o acréscimo dos seguintes campos: Pontuação do Cliente: Campo ao qual é informado qual a prioridade que o cliente aufere para o requisito que foi cadastrado. Estado do Requisito: Apresenta a situação ao qual o requisito se encontra, ele pode receber os seguintes atributos: Aberto quando o requisito ainda não foi iniciado; Em desenvolvimento; Fechado quando o requisito foi finalizado; e Ignorado.

33 33 Pontuação da Equipe Técnica: Apresenta a pontuação da prioridade e do grau de dificuldade avaliado pela equipe técnica para que o requisito seja implementado. Ao marcar implementado o usuário tem opção de escolher se o processo continuará ou não, para que ele continue deve se marcar a opção sim e clicar no botão próximo, para que ele seja finalizado clique na opção não e em seguida no botão próximo, desse modo o requisito que ao qual foi decidido que será implementado é inserido no Sprint Backlog, passo ao contém os requisitos que serão desenvolvidos pelo time. A figura 7 mostra o Sprint Backlog, esta etapa possui um formulário com as informações sobre o requisito - sendo possível a edição do atributo estado -, o passo tem a duração de 15 dias, é nesse período ao qual ele deve ser iniciado. Uma vez feito, devese alterar o estado do requisito para Em desenvolvimento e clicar em próximo para que o processo vá à etapa de desenvolvimento. Figura 7. Sprint Backlog. (Fonte o autor) A figura 8 mostra a etapa de Desenvolvimento do requisito, onde o estado do requisito será alterado para Fechado para que assim possa ser encaminhado para a fase de teste. Os campos Relatar Comportamento e Aprovar requisito poderão ser editados na fase seguinte.

34 34 Figura 8. Desenvolver Requisito. (Fonte o autor) O formulário da figura 9 está relacionado com a etapa Realizar Testes, traz neles além das informações das fases anteriores os seguintes campos: Relatar comportamento: para que o teste faça breve relato de como o requisito se comportou durante a fase, e que possam ser relatados os critérios que levaram a sua aprovação ou reprovação. Aprovar Requisito: ao clicar em sim e no botão próximo o requisito será enviado para a etapa de Revisão da Sprint, se não ele será encaminhado novamente a etapa de Desenvolver requisito. Caso seja aprovado o estado será alterado para fechado, se não for permanece ele Em desenvolvimento.

35 35 Figura 9. Realizar Testes. (Fonte o autor) A figura 10 mostra a etapa de Revisão da Sprint, o requisito aprovado poderá ser revisto, e consequentemente, ser feito o no campo Relatar Comportamento um relato de como ele se comportou na revisão, ou seja se surgiram ou não novas informações sobre ele. Figura 10. Revisão da Sprint. (Fonte o autor) A figura 11, mostra Formulário da etapa Realizar Implantação onde são apresentados os campos:

36 36 Relato de implantação: destinado ao responsável pela implantação do requisito aprovado, possibilitando-o fazer um relatório do que ocorreu durante a implantação. Requisito implementado: campo para a checagem se o requisito foi implantado. Ao final do processo caso seja clicado no botão guardar as informações serão salvas no banco de dados e processo ainda continuará ativo, ao pressionar próximo ele será encerrado. Figura 11. Realizar Implantação. (Fonte o autor) Além do acompanhamento do fluxo do processo, com a ferramenta resultante da automação, é possível obter uma serie de relatórios de desempenhos relacionados ao processo. Gráficos e planilhas que tem como objetivo fornecer a informações detalhadas sobre o andamento dos processos. O Gráfico da figura 12, mostra para todos os processos ativos a quantidade de casos que estão em dia, em risco ou atrasados. Em risco significa que expiram hoje.

37 37 Figura 12:Grafíco de analise carga. (Fonte o autor) A figura 13, os gráficos do Trabalho em andamento: Estado de caso: Este gráfico mostra a porcentagem de casos que estão em dia ou em rico ou atrasados; Casos próximos do vencimento: mostra quando os casos em aberto atingirão suas datas de expiração. Figura 13: Gráficos dos trabalhos em andamento. (Fonte o autor) A Figura 14, os graficos relacionados com o tempo de ciclo.

38 38 Duração do caso: duração média x duração esperada;estado de caso: Este gráfico mostra a porcentagem de casos que estão em dia ou em rico ou atrasados; Tabela de Resumo do tempo de clico. Figura 14: Tempo de Ciclo. (Fonte o autor) A figura 15 apresenta Histograma de duração, o gráfico mostra quantos dias forma necessários para concluir os casos encerrados. A linha tracejada vertical separa os casos em dia dos atrasados. Figura 15: Histograma de duração. (Fonte o autor) A figura 16 apresenta os seguintes gráficos: Tendência; Atividade do processo e a tabela de resumo, os gráficos estão contidos na tela de nome Atividade do

39 39 processo, onde possível selecionar m intervalo de tempo para que os gráficos sejam gerados. Tendência: Tendência ou número de ativações do processo no intervalo de tempo selecionado; Atividade do processo: Casos iniciados, casos encerrados casos abortados no intervalo de tempo selecionado; Tabela de resumo das atividades do processo. Figura 16: Atividade do processo. (Fonte o autor) A Figura 17, mostra denominada Classificação de Atividades o número ativações do processo, num intervalo de tempo selecionado. Figura 17. Classificação de Atividades. (Fonte o autor)