Daniel C. de Oliveira Filho UM PASSO A PASSO PARA A ELABORAÇÃO DO DIAGRAMA DE CASO DE USO DA UML LONDRINA

Transcrição

1 Daniel C. de Oliveira Filho UM PASSO A PASSO PARA A ELABORAÇÃO DO DIAGRAMA DE CASO DE USO DA UML LONDRINA 2011

2 DANIEL C. DE OLIVEIRA FILHO UM PASSO A PASSO PARA A ELABORAÇÃO DO DIAGRAMA DE CASO DE USO DA UML Monografia entregue à Banca Examinadora do Curso de Pós-Graduação em Engenharia de Software com UML do Centro Universitário Filadélfia de Londrina - UniFil como requisito parcial para obtenção do Título de Engenheiro de Software sob a orientação do Professor Sérgio Akio Tanaka e co-orientadora Professora Simone Sawasaki Tanaka. LONDRINA 2011

3 DANIEL C. DE OLIVEIRA FILHO UM PASSO A PASSO PARA A ELABORAÇÃO DO DIAGRAMA DE CASO DE USO DA UML Monografia entregue à Banca Examinadora do Curso de Pós-Graduação em Engenharia de Software com UML do Centro Universitário Filadélfia de Londrina UniFil em cumprimento a requisito parcial para obtenção do título de Engenheiro de Software. APROVADA PELA COMISSÃO EXAMINADORA EM LONDRINA, 30 DE ABRIL DE 2011 Prof. Sérgio Akio Tanaka, (UniFil) Orientador(a) Prof.ª Simone Sawasaki Tanaka, (UniFil) Co-Orientador(a) Prof. Ruy Tsutomu Nishimura, (UniFil) Examinador(a)

4 Dedico este trabalho a minha família, em especial, aos meus avós João e Alayde Guidugli. Exemplos de caráter e honestidade.

5 AGRADECIMENTOS Aos meus familiares que sempre me apoiaram e me incentivaram de todas as formas para que me tornasse a pessoa e profissional que sou hoje. Aos meus avós João e Alayde Guidugli por me proporcionarem a chance de ter uma profissão e agora o título de Engenheiro de Software. Por me mostrar o valor e o peso da palavra família. Obrigado pela confiança e pelas oportunidades que me foram concedidas. Meu eterno carinho e gratidão. A minha esposa Karla Gonçalves de Brito por ser essa pessoa maravilhosa e compreensiva que faz tudo valer a pena. Obrigado por me deixar fazer parte da sua história de vida. Ao meu filho Caio Brito de Oliveira pela paciência e compreensão pelos finais de semana sem passear e pelas horas trabalhando e estudando em casa. Meus agradecimentos. A minha mãe Cássia Rossana Guidugli pelas palavras de incentivo e motivação. Pessoa exemplo de superação que acreditou no meu potencial e me mostrou o caminho quando a direção era incerta. Meu muito obrigado. A minha tia Silvana Guidugli pela disponibilidade do tempo cuidando do Caio. Meus agradecimentos com imenso carinho. A minha irmã Andréia Guidugli, minha prima Ana Paula Guidugli e minha cunhada Kamila Gonçalves de Brito por me ajudarem direta ou indiretamente no que fosse preciso. Muito obrigado. A Deus, por ter me iluminado em mais uma jornada e, finalmente, a todos que, de uma forma ou de outra, me ajudaram a chegar até aqui. Muito obrigado.

6 A única coisa que separa um homem do que ele quer da vida normalmente é simplesmente a vontade de tentar aquilo e a fé para acreditar que aquilo é possível. (RICHARD M. DEVOS)

7 OLIVEIRA FILHO, Daniel C. UM PASSO A PASSO PARA ELABORAÇÃO DO DIAGRAMA DE CASO DE USO DA UML, 50fls. Londrina, Trabalho de Conclusão do Curso de Pós-Graduação em Engenharia de Software com UML do Centro Universitário Filadélfia de Londrina - UniFil, Londrina, RESUMO O trabalho tem como objetivo demonstrar um passo a passo para elaboração do diagrama de Caso de Uso da UML. Serão demonstrados quais os artefatos de entrada necessários para modelagem do diagrama em questão, os passos a serem seguidos e quais os produtos de trabalho gerados ao final do processo. Palavras chaves: UML, Workflow, Modelagem; ABSTRACT The work aims to propose workflows that demonstrate the process to create the Use Case diagram of UML Will be showed what the artifacts are required for modeling the diagram, the steps to be followed and what work products are generated at the end of the process. Key words: UML, Workflow, Modeling.

8 LISTA DE FIGURAS Figura 2.1: Funções do Arquiteto de Negócio Figura 2.2: O Rational Unified Process (RUP) Figura 2.3: Modelo Espiral de Barry Boehm Figura 2.4: As fases e os marcos de um projeto Figura 3.1:Representação gráfica do caso de uso Efetuar Pedido Figura 4.1: Processo para criação de diagramas de caso de uso Figura 4.2: Diagrama de caso de uso do estudo de caso... 47

9 LISTA DE TABELAS Tabela 1: Objetos de Fluxo Tabela 2: Objetos de Conexão Tabela 3: Objetos Swimlanes Tabela 4: Elementos do tipo Artefatos Tabela 5: Relação entre disciplinas do RUP e artefatos... 48

10 LISTA DE ABREVIATURAS E SIGLAS BPD BPMN BPMI OMG RSA RUP UML WfMC WWF XP Business Process Diagram Business Process Modeling Notation Business Process Management Initiative Object Management Coalition Rational Software Architect Rational Unified Process Unified Modeling Language Workflow Management Coalition Windows Workflow Foundation Extreme Programming

11 SUMÁRIO INTRODUÇÃO OBJETIVOS OBJETIVO GERAL OBJETIVOS ESPECIFICOS METODOLOGIA FUNDAMENTAÇÃO TEÓRICA PROCESSO DE DESENVOLVIMENTO DE SOFTWARE RATIONAL UNIFIED PROCESS - RUP WORKFLOW BPMN LINGUAGEM DE MODELAGEM UNIFICADA UML CONSIDERAÇÕES FINAIS ESTUDO DE CASO DIAGRAMA DE CASO DE USO WORKFLOWS PARA CRIAÇÃO DE DIAGRAMAS DA UML PROCESSO PARA MODELAGEM DO DIAGRAMA DE CASO DE USO CONSIDERAÇÕES FINAIS CONCLUSÕES E TRABALHOS FUTUROS REFERENCIAS BIBLIOGRÁFICAS... 48

12 INTRODUÇÃO As linguagens de modelagem orientada a objeto apareceram em algum momento entre meados da década de 70 e começo da década de 80, tornando-se uma abordagem alternativa de análise e projeto. O número de metodologias orientado a objetos aumentou de menos de 10 para mais de 50 durante o período entre 1989 e Muitos usuários desses métodos tiveram problema para encontrar uma linguagem de modelagem que supria todas as suas necessidades. Entre essa Guerra de Metodologias começaram a se destacar como mais notáveis Booch, Object Oriented Software Engineering (OOSE) de Jacobson e o Object Modeling Technique (OMT) criado por Rumbaugh. Cada um desses como um método completo embora sendo reconhecido que todos possuíam pontos fortes e fracos. Foi quando em meados de 1990 Grady Booch, Ivar Jacobson e James Rumbaugh unindo as idéias de cada método criaram o que mais tarde seria a linguagem unificada de modelagem orientada a objetos mais utilizada no mundo a UML (BOOCH, 2005). A Unified Modeling Language (UML) é uma linguagem padrão para a elaboração da estrutura de projetos de software. Ela poderá ser empregada para a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software (BOOCH, 2005). Embora a UML ofereça uma vasta lista de artefatos, notações e padrões para a documentação de um projeto de software permitindo ao Analista, Engenheiro, Programador abstrair todo o conceito do sistema, a tarefa em si se torna um problema se a equipe de análise não tiver bem definido o roteiro, ou seja, algum tipo de processo para se criar toda a documentação. Cada empresa pode desenvolver seu próprio workflow para documentar seus projetos levando-se em consideração vários aspectos, entre eles: tecnologias de desenvolvimento; qualificação da equipe; magnitude e escopo do projeto e tipo de processo utilizado na empresa. Além dos profissionais que trazem na bagagem experiências anteriores de desenvolvimento de sistemas e processos de negócio, existem os alunos de graduação e pósgraduação que estão estudando a UML muita das vezes pela primeira vez e que precisam aprender e entender de uma forma significativa e não mecânica todos os conceitos envolvendo a linguagem de modelagem unificada.

13 Um workflow consiste em uma seqüência de passos conectados entre si que demonstram a execução de um trabalho ou processo real desenvolvido por pessoas, máquinas ou qualquer tipo de entidade envolvida no processo. O termo workflow foi usado primeiramente de uma forma mais moderna na indústria de software, sintetizando o que seria uma automação do processo de negócio. Vislumbrando o grande potencial da tecnologia grandes empresas como Microsoft estão investindo em desenvolver ferramentas e máquinas de workflow que possam ser utilizadas na criação e gerenciamento de qualquer tipo de processo de negócio. Até mesmo um padrão de notação de processos de negócio foi criado na intenção de se tornar o processo visível independente de plataforma ou recurso utilizado. Ele foi chamado de Business Process Modeling Notation (BPMN). Uma empresa de software bem-sucedida é aquela que fornece um produto de qualidade capaz de atender as necessidades dos respectivos usuários. Uma empresa que consiga desenvolver esse software de maneira previsível e em determinado período, com utilização eficiente e eficaz de recursos, será uma empresa com um negócio viável (BOOCH, 2005). A modelagem é uma parte central de todas as atividades que leva à implantação de um bom software. Construímos modelos para comunicar a estrutura e o comportamento desejados do sistema. Construímos modelos para visualizar e controlar a arquitetura do sistema. Construímos modelos para compreender melhor o sistema que estamos elaborando, muitas vezes expondo oportunidades de simplificação e reaproveitamento. Construímos modelos para gerenciar os riscos (BOOCH, 2005). Dentre as dificuldades enfrentadas pelas empresas que desenvolvem software podemos destacar algumas: finalizar o produto no prazo estipulado durante o planejamento; não ultrapassar o orçamento previsto para o projeto; entregar ao Stakholder o produto ou serviço desejado, fruto do investimento. Possíveis motivos seriam: o mau planejamento; requisitos fracos; falta de um processo de desenvolvimento de software que possa direcionar tanto a equipe quanto os gerentes de projeto a estabelecer metas e diretrizes para o desenvolvimento; falta de um meio de comunicação comum entre os envolvidos, uma zona neutra entre a equipe de negócios e a equipe técnica para que ambas conversem entre si utilizando uma só forma de representar cada ponto de vista relevante ao projeto.

14 Pensando-se em aumentar a produtividade, organização, melhorar o planejamento e qualidade, foram criados os processos de desenvolvimento de software. Existem no mercado vários processos voltados ao desenvolvimento de sistemas onde os mesmos são adotados por diferentes empresas de todos os tamanhos. Destacam-se entre eles: o Scrum e o Extreme Programming (XP) como formas de processos ágeis e o Rational Unified Process (RUP), um processo robusto, iterativo e incremental, que poder ser utilizado em projetos de pequenos e também em projetos de grande porte. Como forma de documentar o produto desenvolvido no processo a UML vem sendo amplamente utilizada como padrão de modelagem de sistemas e adotada em vários processos de desenvolvimento. Ela utiliza uma notação para que se possa demonstrar graficamente toda a arquitetura do sistema proposto. Tanto de uma visão estrutural quanto comportamental. Um método que demonstre um passo-a-passo de como modelar os diagramas do sistema utilizando a notação da UML poderá auxiliar não só profissionais que atuam no mercado de trabalho em projetos dentro das empresas, mas também alunos em projetos acadêmicos desenvolvidos em sala de aula ou como trabalhos de conclusão de curso. Como forma de demonstrar os passo do processo será utilizado um workflow que fará uso de padrões de notação para representar graficamente o processo proposto de modelagem dos diagramas. Sistemas de workflow são amplamente utilizados por empresas para criar uma linha lógica de um processo de negócio a ser seguido por pessoas, máquinas ou sistemas computacionais. Podendo o mesmo gerar um produto final palpável ou somente gerenciar documentos e rotinas de trabalho OBJETIVOS Os objetivos da pesquisa são elencados a seguir OBJETIVO GERAL Demonstrar em forma de passo-a-passo como pode ser modeladoo diagrama de Caso de Uso da UML, quais artefatos de entrada são necessários e quais produtos de trabalho são

15 gerados ao final do processo, auxiliando profissionais e estudantes a abstrair um sistema computacional e representá-lo graficamente utilizando padrões universalmente adotados OBJETIVOS ESPECIFICOS a) identificar os artefatos de entrada e saída do diagrama proposto pelo trabalho; b) propor um processo e modelagem do diagrama utilizando a notação da UML; c) agregar valor ao processo de desenvolvimento mantendo o projeto do sistema documentado METODOLOGIA a) estudo da UML e dos diagramas propostos; b) estudo do BPMN e Workflow; c) aplicação do processo a um estudo de caso. Os capítulos seguintes farão uma breve introdução aos assuntos abordados na pesquisa passando pela fundamentação teórica, seguindo pela proposta de um estudo de caso e encerrando com a aplicação pratica do processo resultante do trabalho. O capítulo dois representa os principais conceitos utilizados na pesquisa em questão. Será feita uma explanação sobre processos de desenvolvimento de software tendo como foco o Rational Unified Process (RUP), seguindo pela explicação em síntese do que são workflows e padrões de notação BPMN, encerrando com a uma explanação resumida do que seria a UML. No capitulo três será abordado um estudo de caso. Este mesmo estudo de caso será utilizado pelo processo proposto. O objetivo de se trabalhar um estudo de caso é facilitar a compreensão e ver na prática toda teoria proposta até então. A demonstração do processo utilizando o estudo de caso citado acima estará a cargo do capítulo quatro que unindo um exemplo da vida real com o processo fruto da pesquisa demonstrará como poderá ser modelado o mesmo diagrama do capítulo três, mas agora seguindo uma linha lógica de execução.

16 2. FUNDAMENTAÇÃO TEÓRICA O software é o combustível dos negócios modernos, com o qual se conectam melhor controles governamentais e sociedades. O software nos ajudou a criar, acessar e visualizar a informação de formas anteriormente inconcebíveis. Globalmente, o passo surpreendente do progresso em software ajudou a direcionar o crescimento da economia mundial. Numa escala mais humana, os produtos de software intensivos ajudaram a curar o doente e deram voz ao mudo, mobilidade ao debilitado e oportunidade ao incapacitado. De todas essas perspectivas, o software é uma parte indispensável de todo mundo moderno (BOOCH, 2005). Diferentes projetos de desenvolvimento de software falham de formas diferentes e, infelizmente, muitos deles falham mas é possível identificar vários sintomas comuns que caracterizam esses tipos de projetos: incompreensão das necessidades do usuário final; inabilidade para lidar com requisitos variáveis; módulos que não se ajustam; software difícil de manter ou estender; descoberta tardia de sérias imperfeições do projeto; baixa qualidade de software; os membros da equipe um no caminho do outro, tornando impossível reconstruir quem mudou o quê, quando, onde e por quê; um processo de construção e lançamento indigno de confiança. objetivos: Algumas causas de origem são comuns entre projetos que não atingem seus gerenciamento inadequado de requisitos; comunicação ambígua e imprecisa; arquiteturas frágeis; complexidade subjugada; inconsistências não detectadas em requisitos, construções e implementações;

17 teste insuficiente; avaliação subjetiva de status do projeto; deficiência para risco de ataque; propagação de mudança incontrolada; automação insuficiente. Com a proposta de serem aplicadas melhores práticas ao desenvolvimento de software foram criados os Processos de Desenvolvimento de Software. Empresas bem sucedidas chegaram a um consenso após inúmeros projetos no que diz respeito a melhores práticas, são eles: desenvolvimento iterativo; gerenciamento de requisitos; arquitetura e uso de componentes; modelagem visual; qualidade de processo e produto; gerenciamento de configuração e mudança. Processos de desenvolvimento como o RUP abordam essas e outras boas práticas em seu modelo. Criando um ambiente onde se possa documentar, organizar e compartilhar documentos e produtos de trabalho e também definir papéis e tarefas de cada envolvido. A sessão irá abordar os conceitos propostos pelo RUP. Seguindo a linha de raciocínio envolvendo as melhores práticas citadas anteriormente encontra-se à modelagem visual do sistema que seria a representação gráfica, baseada em uma notação, da abstração do projeto. Tanto do ponto de vista estrutural quanto do comportamental. Reconhecida mundialmente a Unified Modeling Language (UML) é adotada como padrão para modelar sistemas. A UML não está vinculada a nenhum processo de desenvolvimento. Ela tem como função e objetivo fornecer uma notação que represente objetos e seus relacionamentos, comportamentos, ligações como sistemas externos, etc. Ficando a cargo do profissional ou da empresa definir quais diagramas serão criados dependendo do processo utilizado ou metodologia de trabalho. Uma introdução e alguns exemplos de diagramas da UML serão demonstrados na seção

18 A terceira tecnologia abordada na pesquisa será o workflow. Apesar de o termo estar sendo amplamente utilizado em áreas de reengenharia de processos, onde empresas estão buscando através da implantação de rotinas padronizadas, melhorar seus processos de negócio, pode-se também utilizar essa tecnologia para criar novos processos. A idéia por trás do workflow é se definir passos que seguem uma linha lógica de tarefas a serem executadas que tem como objetivo executar um trabalho, resultando ou não em um produto acabado. Sistemas de workflow são amplamente utilizados por empresas que tentam implantar padrões em suas rotinas de trabalho. Como exemplo de workflow poderia citar uma linha de montagem automotiva. O objetivo é entregar no final da linha de montagem um carro montado e pronto para exercer sua função oferecendo segurança e conforto aos seus condutores e passageiros. Cada passo do processo envolve um grupo de pessoas treinadas para executar tal tarefa destinada aquele passo. Começando pela montagem da carroceria e partes mecânicas, seguindo para estofamentos e acabamentos internos até a montagem do motor e encerrando com a fiscalização e aprovação. Todo esse processo pode ser definido com um sistema de workflow. Tarefas são atribuídas, monitoradas e avaliadas constantemente podendo a qualquer momento ser alterado o curso do fluxo baseado em tomadas de decisões. Desde a movimentação de um documento até a logística de fabricação de entrega de um produto. As seções seguintes abordarão assuntos que fizeram a base deste trabalho. Iniciando por processos de desenvolvimento de software, passando por workflows e sua notação BPMN e encerrando com UML PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Durante o ciclo de vida de desenvolvimento de um software inúmeras são as influencias de cada participante. Gerentes de projetos, arquitetos, investidores, desenvolvedores são apenas alguns dos papéis existentes em um projeto. Para que se tornar possível administrar todos esses recursos empresas adotam diferentes tipos de processos de desenvolvimento. Esses processos são estudados e desenvolvidos por engenheiros de software que compilam informações de empresas bem sucedidas do ramo e propõe a comunidade uma metodologia que possa de alguma forma organizar e orientar a equipe durante o ciclo de vida de um projeto. Algumas dessas propostas já estão consolidadas no mercado, é o caso do

19 Rational Unified Process (RUP), Scrum, Extreme Programming (XP). As duas últimas como metodologias ágeis. Cada processo pode gerar um conjunto específico de produtos de trabalho dependendo do escopo do projeto, pois é possível se personalizar o framework do processo conforme a necessidade da equipe e a dimensão do projeto. A seção seguinte tratará do processo unificado criado pela Rational. Um processo iterativo e incremental desenvolvido visando as melhores práticas utilizadas na engenharia de software RATIONAL UNIFIED PROCESS - RUP O Rational Unified Process é um processo de engenharia de software. Ele fornece uma abordagem disciplinada para assumir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Seu objetivo é assegurar a produção de software de alta qualidade que satisfaça as necessidades de seus usuários finais dentro de um prazo e orçamento previsíveis (KRUCHTEN, 2003). Desenvolvido e mantido pela Rational o RUP é um processo iterativo e incremental de desenvolvimento de software, podendo cada empresa se adequar ao modelo conforme a dimensão e escopo do projeto. Profissionais de desenvolvimento de software que trabalham como parte de uma equipe de projeto, incluindo os investidores desses projetos e profissionais de engenharia de processo são os principais interessados em utilizar o processo unificado. Baseado nas funções propostas pelo RUP de cada envolvido no projeto é possível se definir quais produtos de trabalho e tarefas cada papel terá que desenvolver ou realizar. A estrutura proposta pelo RUP permite que as equipes possam colaborar e manter organizado toda a documentação do projeto, sendo definidas estruturas lógicas baseadas em cada disciplina. Um exemplo seria criar uma estrutura para fase de Iniciação, responsável por manter documentos de levantamento de requisitos, documento visão, solicitações do Stakholder entre outros. A Figura 2.1 demonstra o papel do Arquiteto de Negócio proposto pelo RUP. Como em outras atribuições ficam definidas quais as responsabilidades, que entre outras no caso do arquiteto de negócio são: Análise de Arquitetura de Negócio e Análise da Área Funcional e como produto de trabalho seus respectivos documentos.

20 Figura 2.1. Funções do Arquiteto de Negócio (IBM, 2007). O ambiente de processo oferecido pelo RUP é em sua essência um conjunto de práticas coletadas da engenharia de software que são continuamente aprimoradas. Alguma dessas inclusive compartilhadas por outros processos de desenvolvimento de software. No RUP o processo possui duas dimensões. O eixo horizontal representa o ciclo de vida do processo e o eixo vertical que demonstra as disciplinas essenciais para o desenvolvimento do software. O modelo do processo é demonstrado na Figura 2.2. No eixo horizontal ficam visíveis as fases que vão de iniciação, passando pela elaboração, construção e transição. Em cada fase é possível se determinar os marcos entre as iterações. Na dimensão vertical ficam as disciplinas que demonstrando as atividades pertinentes ao desenvolvimento do sistema. Figura 2.2. Rational Unified Process (RUP) (IBM, 2007).

21 O objetivo do processo é fazer com que cada iteração resulte, ao passar por todas as disciplinas, um lançamento executável. Dessa forma pode-se identificar, por exemplo, possíveis defeitos de construção, requisitos fracos e possíveis riscos para o projeto durante uma fase inicial, permitindo ao gerente do projeto tomar decisões e direcionar a equipe durante a próxima iteração. A Figura 2.3 representa este ciclo de iterações conhecido como Modelo Espiral de Barry Boehm baseado em um modelo iterativo e incremental. Figura 2.3. Modelo Espiral de Barry Boehm (IBM, 2007). Ao final de cada fase são definidos os marcos com objetivos específicos. A avaliação destes marcos define se os objetivos propostos para a fase foram alcançados permitindo que o projeto avance. As fases poderiam ser definidas como o intervalo de tempo entre os marcos. A Figura 2.4 demonstra os marcos durante o ciclo de vida do projeto. Figura 2.4. As fases e os marcos de um projeto (IBM, 2007).

22 Existem princípios essenciais de um processo de desenvolvimento de software eficiente são eles: desenvolver uma visão: o artefato visão captura requisitos de nível muito alto e restrições de design, para fornecer ao leitor um entendimento do sistema a ser desenvolvido. gerenciar para o plano: um plano de desenvolvimento de software reúne as informações necessárias para gerenciar o projeto. Ele é utilizado para fazer o planejamento do projeto e planejar as necessidades de recursos e para acompanhar o progresso do planejamento. mitigar riscos e rastrear problemas relacionados: é essencial identificar e combater os itens de risco mais alto no inicio do projeto e acompanhá-los, juntamente com outros problemas relacionados. A lista de riscos foi projetada para capturar os riscos percebidos para o sucesso do projeto. examine o caso de negócio: o caso de negócio fornece as informações necessárias, de um ponto de vista de negócios, para identificar se compensa ou não investir no projeto. projete uma arquitetura de componente: no RUP, a arquitetura de um sistema de software é a organização ou estrutura dos componentes significativos do sistema que interagem por meio de interfaces com componentes constituídos de componentes e interfaces sucessivamente menores. Quais são as partes principais? E como elas se ajustam juntas? Temos uma estrutura na qual o restante do software pode ser incluído? progressivamente construir e testar o produto: o RUP é uma abordagem iterativa de criação, de teste e de avaliação de versões executáveis do produto, a fim de afastar os problemas e resolver os riscos e as questões o mais cedo possível. acessar resultados regularmente: a comunicação aberta contínua com dados e objetivos originados diretamente de atividades em andamento e as configurações do produto em desenvolvimento são importantes em qualquer projeto. Avaliações regulares de status fornecem um mecanismo para endereçar, comunicar e resolver problemas de gerenciamento, problemas técnicos e riscos do projeto. Além de

23 identificar os problemas, é necessário designar a cada um deles uma data de expiração e uma pessoa responsável pela resolução. gerenciar e controlar alterações: assim que o primeiro protótipo for colocado diante dos usuários, as alterações serão solicitadas. Para controlar essas mudanças e gerenciar eficazmente o escopo do projeto e as expectativas dos investidores, é importante que todas as mudanças em quaisquer artefatos de desenvolvimento sejam propostas por meio de controles de mudanças e gerenciadas com um processo consistente. implementar um Produto Utilizável: a finalidade de um processo é produzir um produto utilizável. Todos os aspectos do processo dever ser adaptados considerando essa meta. O produto é normalmente mais do que apenas o software. No mínimo, deve haver um guia do usuário. dependendo da complexidade do produto, os materiais de treinamento também poderem ser necessários. adotar um processo que se ajuste ao projeto: é essencial que seja escolhido um processo que se ajuste ao tipo de produto que está sendo desenvolvido. Mesmo depois que um processo é escolhido, ele não deve ser seguido às escuras o bom senso e a experiência devem ser aplicados para configurar o processo e as ferramentas para atender as necessidades da organização e do projeto. Quando se utiliza um processo de desenvolvimento que possa aplicar na prática os princípios acima citados as chances de sucesso com o projeto sofrem um aumento considerado. Esses princípios foram estabelecidos por grandes empresas do ramo e adotados como boas práticas do desenvolvimento de sistemas. Conforme explicado anteriormente o RUP prevê um desenvolvimento iterativo que utiliza uma linha de vida para o projeto dividida em fases e outra onde se ocorrem às iterações passando por nove disciplinas. Essas disciplinas iniciam na modelagem de negócios e vão até o ambiente. As fases definidas no ciclo de vida de um projeto são: iniciação: a meta dominante da fase de iniciação é atingir o consenso entre todos os investidores sobre os objetivos do ciclo de vida do projeto.

24 elaboração: a finalidade principal é criar uma baseline para a arquitetura do sistema e fornecer um base estável para o esforço em massa do design e implementação na próxima fase. construção: terceira fase do RUP cuja finalidade principal é concluir o desenvolvimento do sistema baseado na arquitetura. transição: quarta e última fase com finalidade de assegurar que o software esteja pronto para ser fornecido a seus usuários. Deve ser estabelecido para cada fase um número de iterações que ao passarem por todas as disciplinas vão gerar artefatos. Estes artefatos irão incrementar ou até mesmo atualizar o repositório de artefatos do projeto. São nove as disciplinas previstas pelo RUP(IBM, 2007): modelagem de Negócio: fornece orientação sobre diferentes técnicas de modelagem que podem ser utilizadas durante um esforço de engenharia de negócio. requisitos: explica como eliciar os requisitos dos investidores e transformá-los em um conjunto de requisitos de produtos de trabalho, no escopo do sistema a ser construído e fornece requisitos detalhados sobre o que faz o sistema. análise e design: explica como transformar os requisitos dos produtos de trabalho em produtos de trabalho especificando o design do software que o projeto desenvolverá. implementação: explica como desenvolver, organizar, testar a unidade e integrar os componentes implementados de acordo com as especificações do design. teste: fornece orientação sobre como avaliar a qualidade do produto. implantação: descreve as atividades associadas a garantir que o produto de software esteja disponível a seus usuários. gerenciamento de configuração e mudança: explica como controlar e sincronizar a evolução do conjunto de produtos de trabalho que compõem o sistema de software. gerenciamento de projetos: enfoca o planejamento do projeto, gerenciamento de riscos, monitoramento do progresso e métricas.

25 ambiente: a finalidade da disciplina ambiente é fornecer a organização de desenvolvimento de software com o ambiente de desenvolvimento de software para processos e ferramentas que oferecerão suporte à equipe de desenvolvimento. O nível de esforço varia ao longo do tempo. Em iterações iniciais o tempo gasto é maior com requisitos e em iterações posteriores a implementação exige maior atenção. O objetivo do desenvolvimento iterativo é que ao final de cada iteração se tenha um executável para validação dos investidores. O resultado dessa iteração pode alterar ou não o planejamento de iterações previstas no inicio do projeto. Ficando a cargo do gerente de projetos planejar as alterações. O mercado de desenvolvimento de software exige cada vez mais processos que aumentem a produtividade, melhorem organização e controle de documentação além de ser capaz de se adaptar a qualquer tipo de projeto. O RUP pode ser configurado para atender diferentes tipos de projetos, como: soluções de componentes soluções de e-business, soluções orientadas a serviços, projetos pequenos e outros. O escopo do RUP no presente projeto é servir como base para acomodar os artefatos gerados por cada processo proposto. Demonstrando em que fase do processo esse artefato é gerado e em qual disciplina. Na seção seguinte será apresentado o assunto chave da pesquisa. Quando se fala em criar um processo é impossível não falar de workflow WORKFLOW Workflow é a automação total ou parcial de um processo de negócio, durante a qual documentos, informações e tarefas são passadas entre os participantes do processo (WfMC, 1996). A busca por aumento de produtividade e melhoria na qualidade da execução de um processo está fazendo com que empresas de todos os ramos de atividade busquem implementar processos padronizados em seu ambiente de trabalho. Estes processos não dizem respeito somente ao gerenciamento de documentos ou rotinas de trabalho do ambiente formal, mas também podem ser aplicados na melhoria de processos de chão de fábrica por exemplo.