APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE DELMIR PEIXOTO DE AZEVEDO JÚNIOR

Transcrição

1 APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE DELMIR PEIXOTO DE AZEVEDO JÚNIOR UNIVERSIDADE ESTADUAL DO NORTE FLUMINENSE UENF CAMPOS DOS GOYTACAZES RJ ABRIL DE 2003

2 APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE DELMIR PEIXOTO DE AZEVEDO JÚNIOR Dissertação submetida ao corpo docente do Centro de Ciência e Tecnologia da Universidade Estadual do Norte Fluminense, como parte das exigências necessárias para obtenção do grau de mestre em Ciências de Engenharia, na área de concentração de Engenharia de Produção. Orientador: Prof. Renato de Campos, D.Sc. CAMPOS DOS GOYTACAZES RJ ABRIL DE 2003 II

3 APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE DELMIR PEIXOTO DE AZEVEDO JÚNIOR Dissertação submetida ao corpo docente do Centro de Ciência e Tecnologia da Universidade Estadual do Norte Fluminense, como parte das exigências necessárias para obtenção do grau de mestre em Ciências de Engenharia, na área de concentração de Engenharia de Produção. Aprovada em: Comissão Examinadora: Prof. Renato de Campos. D. Sc. UENF Prof. Clevi Rapkiewicz. D. Sc. UENF. Prof. Rogério Atem de Carvalho. D. Sc. UCAM. Prof. Geraldo Galdino de Paula Júnior. D. Sc. UENF. III

4 AGRADECIMENTOS Agradeço a todos que de alguma forma me ajudaram durante o período dedicado a este trabalho. Especialmente a Deus; a minha amada esposa, Marília; aos meus pais, Maria da Penha e Delmir; e ao meu orientador, Renato de Campos. IV

5 SUMÁRIO CAPÍTULO 1 - Introdução Contexto Motivação Objetivo Hipótese Estratégia Estrutura do trabalho...4 CAPÍTULO 2 - Engenharia de Software Introdução O Modelo Iterativo e Incremental Arquitetura de Software A Engenharia de Requisitos UML O Processo Unificado (UP)...28 CAPÍTULO 3 - Modelagem de Negócio Introdução Modelagem por Processos de Negócio Modelagem de Negócio com Orientação a Objeto Considerações sobre a Modelagem de Processos de negócio com UML...56 CAPÍTULO 4 Propostas de atividades para a sistematização do levantamento de requisitos no UP Introdução Atividades Propostas Aplicação das Atividades Propostas à MDS-OO Dataprev...69 V

6 CAPÍTULO 5 Conclusão Referências Bibliográficas Anexo I Artefatos da MDS Dataprev OO Anexo II Exemplos de Artefatos VI

7 LISTA DE FIGURAS Figura 1- Riscos de projeto no modelo Cascata (Adaptado de RUP 2002)...8 Figura 2 - Riscos de projeto no modelo Iterativo (Adaptado de RUP 2002)...9 Figura 3 - Vistas de uma arquitetura de software...12 Figura 4 Limites da análise de requisitos...14 Figura 5 O Gráfico das Baleias (Adaptado de RUP, 2002)...30 Figura 6 - As fases e os marcos de um projeto no UP.(Adaptado do RUP 2002)...31 Figura 7 Ícones e Estereótipos estabelecidos por Marshall...43 Figura 8 Um exemplo de Modelo Organizacional...43 Figura 9 Meta Modelo proposto por Eriksson e Penker (2000)...45 Figura 10 Um exemplo de Diagrama de Modelo Conceitual...47 Figura 11 Exemplo de Diagrama de Objetivos...48 Figura 12 Exemplo de Modelo de Informação...49 Figura 13- Ícone associado à atividade estereotipada como processo de negócio...51 Figura 14 - Representação de um processo de negócio e sua interação com recursos 52 Figura 15 Exemplo de Diagrama de Linha de Montagem...53 Figura 16 Exemplo de identificação de casos de Uso no Diagrama de Linha de Montagem...55 Figura 17 - Workflow para a Modelagem de Negócio...62 VII

8 Resumo da dissertação apresentada ao CCT/UENF como parte das exigências para a obtenção do grau de Mestre em Ciências (M. Sc.) em Engenharia de Produção. APLICAÇÃO DA TÉCNICA DE MODELAGEM DE NEGÓCIO COM UML A PROCESSOS ITERATIVOS DE DESENVOLVIMENTO DE SOFTWARE Delmir Peixoto de Azevedo Júnior Abril Orientador: Prof. Renato de Campos Curso de Mestrado em Ciências de Engenharia Área de Engenharia de Produção A atual dinâmica do mercado tem exigido das organizações uma constante reformulação de seus processos de negócio a fim de se manterem competitivas. Esta dinâmica provoca também uma necessidade de adaptações nos softwares que dão suporte a tais processos, ou seja, o surgimento de novos requisitos de software. Entretanto, a atividade de levantamento de requisitos em processos de desenvolvimento de software é realizada muitas vezes de forma pontual, sem uma visão mais abrangente e estratégica do negócio. Evidencia-se neste cenário, portanto, a necessidade de alinhamento entre o levantamento de requisitos e os processos de negócio de uma organização. E neste sentido, este trabalho busca inserir no Processo Unificado (processo de desenvolvimento de software que tem sido usado como base para a definição de várias metodologias encontradas no mercado) atividades para a sistematização do levantamento de requisitos a partir da análise de arquiteturas de negócio. Uma vez definidas de forma genérica para o Processo Unificado, estas atividades serão exemplificadas através de sua aplicação à metodologia de desenvolvimento de sistemas da Dataprev, a MDS-OO Dataprev. VIII

9 Abstract of Dissertation Submitted to the CCT/UENF as partial fulfillment of the requirements for the degree of Master of Sciences. THE BUSINESS MODELING TECHNIQUE WITH UML APPLICATION TO SOFTWARE DEVELOPMENT ITERATIVE PROCESS Delmir Peixoto de Azevedo Júnior April Advisor: Renato de Campos Course of Master's Degree in Engineering Science - Area of Production Engineering The current market dynamics has been demanding a constant rebuilding of the organizations business processes in order to maintain their competitiveness. This dynamics also provokes needs for adaptations in the software that give support to such processes, in other words, the sprouting of new software requirements. However, the activity of requirements analysis in software development processes is accomplished a lot of times without a general and strategic vision of the business. It is evidenced in this scenery, therefore, the need of alignment between the requirements analysis and the business processes of an organization. In this sense, this work looks forward to insert in the Unified Process (process of software development that has been used as base for the definition of several methodologies found in the market) activities for the requirements analysis systematization through the analysis of business architectures. Once defined in a generic way for the Unified Process, these activities will be exemplified through its application to the systems development methodology of Dataprev, the MDS-OO Dataprev. IX

10 CAPÍTULO 1 Introdução 1.1. Contexto O avanço tecnológico tem permitido o surgimento de novas formas de negócios. As organizações empresariais modernas precisam estar em constante evolução para se manterem competitivas. São necessárias freqüentes reformulações e inovações nos processos de negócio e conseqüentemente nos sistemas de informação que os dão suporte. Muitas vezes a complexidade atinge proporções que dificultam o gerenciamento e mesmo o conhecimento do negócio pelos que o gerenciam. Muitos gerentes não conhecem os recursos que possuem e entre estes os sistemas de informações que existem por toda a organização. É muito comum observar gerentes de departamentos vizinhos replicando dados em sistemas de informações. A integração entre os objetivos do negócio, os processos de negócio, e sistemas de informação é um fator determinante da dinâmica necessária à organização e também um desafio aos gerentes. Nesse cenário dinâmico, os sistemas de informações são os habilitadores do negócio e portanto precisam estar alinhados com os reais objetivos do negócio (AZEVEDO; CAMPOS, 2002). Existem vários métodos, técnicas e ferramentas de modelagem para facilitar o entendimento e análise da complexidade das organizações modernas. Essas facilidades são utilizadas na tentativa de tornar a realidade organizacional mais tangível. Também existem várias metodologias para o desenvolvimento de sistemas de informação. Entretanto, Santander e Castro (2002) observam que há uma falta de integração entre as análises no domínio do negócio e no domínio dos sistemas de informação. Dentre as metodologias de desenvolvimento de sistemas de software o Processo Unificado (UP) é uma das que vêm obtendo destaque entre as demais. Várias

11 2 metodologias, como a apresentada em Paula (2001), têm sido concebidas utilizando-se os princípios estabelecidos no UP. Entretanto mesmo no UP a atividade de levantamento de requisitos ainda é um processo empírico, não considerando de forma sistemática a importância do foco nos objetivos do negócio. Neste contexto, evidencia-se a necessidade de maior aproximação entre o levantamento de requisitos de sistemas de softwares, nos processos ou metodologias de desenvolvimento de software, às reais necessidades do negócio. Esta dissertação propõe contribuições para uma melhor aproximação entre estes dois domínios, mostrando como um processo de desenvolvimento de software pode utilizar modelos de negócio para sistematizar a identificação de requisitos em função dos reais objetivos do negócio Motivação Segundo Santander e Castro (2002) a identificação dos requisitos funcionais dos sistemas de informação tem sido feita de forma bastante empírica, sem o apoio de métodos mais sistemáticos, o que resulta freqüentemente no desenvolvimento de sistemas não alinhados aos objetivos do negócio. Embora existam algumas heurísticas propostas para identificação de requisitos funcionais, como as apresentadas por Schneider e Winters (1998), Jacobson et al (1999), e em Lilly (1999), não existem métodos estabelecidos que tornem esta atividade mais sistemática. A principal motivação para este trabalho é, portanto, a carência de métodos que alinhem, de forma sistemática, o levantamento de requisitos de software às reais necessidades de um negócio.

12 Objetivo Este trabalho busca definir atividades a serem inseridas no UP, ou em qualquer outro processo de desenvolvimento baseado neste, de forma a sistematizar o levantamento de requisitos com base em análise de modelos de negócio. Um segundo objetivo deste trabalho é a aplicação das atividades propostas à MDS-OO Dataprev, a metodologia de desenvolvimento de sistemas da Dataprev, fundamentada nos mesmos princípios estabelecidos no UP Hipótese O presente trabalho utiliza a hipótese de que o alinhamento entre requisitos de software e as reais necessidades de informatização da empresa pode ser melhorado através de técnicas de modelagem de empresa, e que a tecnologia da orientação a objeto, através da Unified Modeling Language (UML) permite a integração da representação de modelos nos dois domínios, negócio e software. Uma empresa pode ser modelada como um conjunto de objetos e seus relacionamentos. A análise do relacionamento entre objetos da empresa e objetos de sistemas de software permitirá o alinhamento entre os domínios da modelagem de empresa e de modelagem de requisitos de software e a conseqüente identificação de requisitos de software alinhados ao negócio. A atividade de identificação dos requisitos deve ser ajustada à estrutura do processo de desenvolvimento de software utilizado Estratégia De maneira a testar a hipótese citada esta dissertação inicialmente avalia através de uma pesquisa bibliográfica técnicas de modelagem de negócio e de identificação de requisitos de software.

13 4 Em seguida são definidas atividades para identificação sistemática de requisitos, a partir de modelos de negócio, e aplicadas ao Processo Unificado de desenvolvimento de software. As atividades propostas são então aplicadas à MDS-OO Dataprev Estrutura do trabalho A dissertação está organizada de acordo com a estrutura de capítulos a seguir: Capítulo 2: Apresenta os conceitos da engenharia de software e de requisitos. Apresenta a Linguagem UML e o Processo Unificado de Desenvolvimento de Software. Capítulo 3 : Apresenta os conceitos e métodos da modelagem de negócio e as propostas de extensão da linguagem UML para a modelagem de negócio. Capítulo 4. Apresenta as atividades propostas nesta dissertação, a serem inseridas no UP ou qualquer outra metodologia de desenvolvimento de sistemas baseada na estrutura deste. Apresenta também a aplicação destas atividades na metodologia de desenvolvimento de sistemas da Dataprev. Capítulo 5: Apresenta as conclusões do trabalho.

14 CAPÍTULO 2 Engenharia de Software 2.1. Introdução Uma primeira definição de engenharia de software foi proposta por Fritz Bauer na primeira grande conferência (NAUR; RANDELL; BUXTON, 1969) dedicada ao assunto: O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais. Segundo Pressman (1995) a engenharia de software abrange um conjunto de três elementos fundamentais: métodos, ferramentas e procedimentos, que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a construção de software de alta qualidade com produtividade. A seguir o autor analisa cada um desses elementos: Os métodos - proporcionam os detalhes de como fazer para construir o software. Os métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto, análise de requisitos de software e de sistemas, projeto da estrutura de dados, arquitetura de programa e algoritmo de processamento, codificação, teste e manutenção. Os métodos da engenharia de software muitas vezes introduzem uma notação gráfica ou orientada a uma linguagem específica, e introduzem um conjunto de critérios para a qualidade do software. As ferramentas proporcionam apoio automatizado ou semi-automatizado aos métodos. Atualmente existem ferramentas para dar suporte a vários métodos. Quando as ferramentas são integradas de forma que a informação criada por uma ferramenta possa ser usada por outra, é estabelecido um sistema de

15 6 suporte ao desenvolvimento de software chamado engenharia de software auxiliada por computador (CASE Computer-Aided Software Engineering). Os procedimentos (também citados como metodologia ou processos) constituem o elo de ligação que mantém juntos os métodos e as ferramentas e possibilitam o desenvolvimento racional e oportuno do software de computador. Os procedimentos definem a seqüência em que os métodos serão aplicados, os produtos que se exige que sejam entregues (documentos, relatórios, formulários, etc.), os controles que ajudam a assegurar a qualidade e a coordenar as mudanças, e os marcos de referência que possibilitam aos gerentes de software avaliar o progresso. A engenharia de software se dá através de um conjunto de fases. Cada uma das fases pode envolver métodos, ferramentas e procedimentos. A forma de estruturação destas são citadas como modelo de engenharia de software (PRESSMAN, 1995). Um modelo de engenharia de software é escolhido tendo-se como base a natureza do projeto e da aplicação, os métodos e as ferramentas a serem usados, os controles e os produtos que precisam ser entregues. Pressman também analisa que independentemente do modelo de desenvolvimento de software, o processo de desenvolvimento contém três fases genéricas: definição, desenvolvimento e manutenção. Na fase de definição, o desenvolvedor de software tenta identificar que informações necessitam ser processadas, quais funções e desempenho são desejados, quais interfaces devem ser estabelecidas, quais restrições de projeto existem e quais critérios de validação são exigidos para se definir um sistema bem sucedido. Pressman(1995) também observa que embora os métodos aplicados durante a fase de definição variem em função do modelo, três etapas específicas ocorrerão de alguma forma: Análise do sistema que define o papel de cada elemento num sistema baseado em computador determinando o papel que o sistema desempenhará;

16 7 Planejamento do projeto de software que aborda a análise de riscos, alocação de recursos, estimativas de custos e a definição de tarefas e programação de trabalho. Análise de requisitos que detalha o escopo através de uma análise do domínio da informação e das funções do software. A fase de desenvolvimento tenta definir como a estrutura de dados e a arquitetura de software têm de ser projetadas, como os detalhes procedimentais têm de ser implementados, como o projeto será traduzido numa linguagem de programação e como os testes têm de ser realizados. Assim como na fase de definição, os métodos da fase de desenvolvimento também variam em função do modelo de engenharia de software a ser usado no projeto. Mas três etapas genéricas ocorrerão de alguma forma: projeto de software, codificação e realização de testes do software. A fase de manutenção concentra-se nas mudanças que estão associadas a correção de erros, adaptações e melhoramento funcional do software. Quatro modelos de engenharia de software têm sido amplamente discutidos: o ciclo de vida clássico (ou cascata), a prototipação, o modelo espiral, e as técnicas de Quarta geração (PRESSMAN, 1995). Atualmente um novo modelo tem sido amplamente usado, o modelo iterativo e incremental. Este modelo é apresentado em (JACOBSON; BOOCH; RUMBAUGH, 1999) e em (PAULA, 2001). Este modelo será apresentado a seguir e utilizado como base para o método proposto neste trabalho O Modelo Iterativo e Incremental Um projeto de desenvolvimento de software transforma uma quantidade de requisitos e usuários em uma quantidade de produto de software. Num processo iterativo e

17 8 incremental a quantidade de mudança é feita por partes. Em outras palavras, divide-se o projeto em um número de mini-projetos, cada um correspondendo a uma iteração. Cada iteração abrange todas as etapas do desenvolvimento: planejamento, levantamento de requisitos, análise, projeto, implementação, teste, e preparação para a implantação. Cada uma destas iterações assemelha-se ao tradicional modelo Cascata da engenharia de software porque se procedem através de atividades seqüenciais e subsequentes. Pode-se considerar cada iteração como um processo minicascata. Geralmente, uma abordagem iterativa é superior a uma abordagem linear ou em cascata. O RUP (2002) apresentada vários motivos para isto, entre eles: Os riscos são reduzidos mais cedo, pois os elementos são integrados progressivamente: Todos os projetos têm um conjunto de riscos envolvidos. Quanto mais cedo puder ser verificado que se evitou um risco no ciclo de vida, mais precisos serão os planos. Muitos riscos nem são descobertos até que se tente integrar o sistema. É impossível prever todos eles, por mais experiente que seja a equipe de desenvolvimento. Em um ciclo de vida em cascata, não se pode verificar se o projeto está livre de um risco até o final do ciclo.(figura 1) Figura 1- Riscos de projeto no modelo Cascata (Adaptado de RUP 2002)

18 9 Em um ciclo de vida iterativo, a seleção do incremento a ser desenvolvido em uma iteração é feita com base em uma lista dos principais riscos. Como a iteração produz um conjunto de artefatos testados, pode-se verificar a diminuição dos riscos em cada iteração. (Figura 2) Figura 2 - Riscos de projeto no modelo Iterativo (Adaptado de RUP 2002) As táticas e os requisitos variáveis são acomodados: A abordagem iterativa permite que sejam considerados os requisitos variáveis, já que eles normalmente serão alterados durante o processo. As mudanças efetuadas nos requisitos e a forma lenta como eles são levantados têm sido sempre as principais fontes de problemas para um projeto, levando a liberação depois do prazo, programações atrasadas, clientes insatisfeitos e desenvolvedores frustrados. Os usuários mudarão de idéia durante o processo. Essa é a natureza humana. Forçar os usuários a aceitarem o sistema como o imaginaram originalmente está errado. Eles mudam de idéia porque o contexto está sendo alterado; eles aprendem mais sobre o ambiente e a tecnologia e enxergam uma demonstração intermediária do produto durante o seu desenvolvimento. Um ciclo de vida iterativo fornece o gerenciamento com um modo de fazer mudanças táticas no produto. Por exemplo, para competir com os

19 10 produtos existentes, pode-se decidir lançar um produto com funcionalidade reduzida mais cedo como reação a uma movimentação de um concorrente ou poderá adotar um outro fornecedor de uma determinada tecnologia. A iteração também permite mudanças tecnológicas durante o processo. Se alguma tecnologia é alterada ou se torna um padrão conforme aparece uma nova, o projeto poderá aproveitá-la. Particularmente, esse é o caso de mudanças de plataforma e de infra-estrutura de nível inferior. A melhoria e o refinamento do produto são facilitados, resultando em um produto mais robusto. Uma abordagem iterativa resulta em uma arquitetura mais robusta, pois os erros são corrigidos após várias iterações. As falhas iniciais são detectadas conforme o produto amadurece, durante as iterações iniciais. Os gargalos de desempenho são descobertos e podem ser reduzidos, em vez de aparecerem na véspera da liberação. Desenvolver iterativamente, ao contrário de executar testes uma vez ao final do projeto, resulta em um produto totalmente testado. Houve muitas oportunidades para testar as funções críticas após várias iterações, e os próprios testes, além dos softwares de teste, tiveram tempo para amadurecer. Aumento de Reutilização Um ciclo de vida iterativo facilita a reutilização. Identificar as partes comuns quando estão parcialmente projetadas ou implementadas é mais fácil que identificar todas as semelhanças no início.

20 11 É difícil identificar e desenvolver partes reutilizáveis. As revisões de design nas iterações iniciais possibilitam que os arquitetos de software identifiquem reutilizações inesperadas e potenciais, e as iterações subseqüentes permitem que eles desenvolvam e amadureçam posteriormente esse código comum. O uso de uma abordagem iterativa facilita o aproveitamento dos produtos desenvolvidos internamente e adquiridos prontos para serem usados. Haverá várias iterações para selecioná-los, integrá-los e confirmar que eles são adequados à arquitetura Arquitetura de Software O tamanho e a complexidade dos softwares têm aumentado tanto que as técnicas de abstração utilizadas até o final da década de 1980 (como, por exemplo, tipos de dados abstratos, linguagens de programação de alto nível e técnicas de decomposição modular) já não são mais suficientes para lidar com esses novos problemas envolvendo o projeto de software no nível de sistema. (MENDES, 2002) O desenvolvimento de software baseado em arquitetura de software vem atender a esta maior necessidade de abstração, permitindo que o sistema possa ser analisado através de várias vistas integradas. Cada vista evidenciando informações de determinado aspecto e suprimindo de outros a fim de facilitar a análise de cada um dos aspectos. A arquitetura de software é a estrutura do sistema, que compreende os componentes do software, as propriedades externamente visíveis desses componentes, e os relacionamentos entre eles. (BASS; CLEMENTS; KAZMAN, 1998). O conceito de arquitetura engloba os aspectos mais relevantes, tanto estáticos como dinâmicos, do sistema a fim de garantir um todo consistente que represente bem as

21 12 necessidades dos interessados. Uma arquitetura é composta por vistas que evidenciam as informações de determinados aspectos do sistema. A arquitetura de software não se preocupa apenas com a estrutura e o comportamento mas também com restrições e concessões quanto ao uso, funcionalidade, performance, elasticidade, reuso, compreensibilidade, economia e tecnologia. (KRUCHTEN, 1998). Uma arquitetura de software deve abordar características funcionais, não funcionais e de desenvolvimento. As características funcionais Refere-se à capacidade do sistema em realizar as funções requeridas pelos usuários. As características não funcionais correspondem às demais características que afetam o sistema como um todo, tais como: performance, segurança, e viabilidade. As características não funcionais também podem ser em parte derivadas do modelo do negócio. Elas se apresentam em forma de Restrições (ex: restrições de hardware) e Qualitativos (ex: segurança). As características de desenvolvimento referem-se ao processo de desenvolvimento e à qualidade do software. Um software é um sistema complexo que pode ser abordado sob mais de um aspecto. Cada aspecto pode ser observado a partir de uma vista. Cada vista pode ser modelada por um ou mais tipos de diagramas. A Figura 3 apresenta as cinco vistas estabelecidas por Kruchten (1995). Segundo Kruchten o uso de múltiplas vistas permite endereçar os requisitos de vários interessados no sistema: usuários finais, desenvolvedores, engenheiros de sistemas, e gerentes de projetos entre outros. Figura 3 - Vistas de uma arquitetura de software

22 A Engenharia de Requisitos Como foi apresentada na seção anterior, a análise de requisitos é uma etapa sempre presente na fase de definição do software, independentemente do modelo de engenharia de software adotado. Paula (2001) diz que a engenharia de requisitos é formada por um conjunto de técnicas empregadas para levantar, detalhar, documentar, e validar os requisitos de um produto de software. Sommerville (2000) apresenta as seguintes definições para requisito: (1) Uma condição ou capacidade necessitada por um usuário para resolver um problema ou atingir um objetivo. (2) Uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente de sistema para satisfazer um contato, padrão, especificação, ou outro documento de formalidade. (3) Uma representação documentada de uma condição ou capacidade como em (1) ou (2). Segundo Pressman (1995) a tarefa de análise de requisitos é um processo de descoberta, refinamento, modelagem e especificação, e embora possa parecer uma tarefa relativamente simples, o conteúdo de comunicação é muito elevado, o que abundam as chances de interpretações errôneas e informações falsas. Portanto, pode-se definir a engenharia de requisitos como um campo da engenharia de software que visa a aplicação de técnicas de engenharia em métodos de análise de requisitos. A análise de requisitos efetua a ligação entre a necessidade de informatização de processos ao projeto do software que atenderá tais necessidades (ver Figura 4).

23 14 Figura 4 Limites da análise de requisitos A análise de requisitos possibilita que o analista de sistemas especifique a função e o desempenho do software, indique a interface do software com outros elementos do sistema e estabeleça quais são as restrições de projeto que o software deve enfrentar Atividades da Análise de Requisitos Segundo Pressman (1995) a análise de requisitos de software pode ser dividida em cinco áreas de esforço: reconhecimento do problema, avaliação e síntese, modelagem, especificação e revisão. Reconhecimento do problema : No reconhecimento do problema é importante entender o software num contexto de sistema e revisar o escopo do software que foi usado para gerar as estimativas de planejamento. Avaliação e síntese: Durante a avaliação a meta do analista é o reconhecimento dos elementos problemáticos básicos e as informações desejadas de entrada e saída no sistema. No decorrer da síntese de avaliação e solução, o principal foco do analista recai sobre o que, não sobre como. Quais dados o sistema produz e consome, quais funções o sistema deve executar, quais interfaces são definidas e quais restrições se aplicam.

24 15 Modelagem: Durante a atividade de síntese e avaliação, o analista cria modelos do sistema num esforço para compreender melhor o fluxo de dados e de controle, o processamento funcional e a operação comportamental. Especificação: A atividade de especificação esforça-se para oferecer uma representação de software que possa ser revisada e aprovada pelo cliente. Revisão: Após especificados os requisitos devem ser revisados pelo cliente e pelo desenvolvedor. De forma similar, Sommerville (2000) afirma que o processo de engenharia de requisitos pode ser descrito como um processo sistemático de cinco passos distintos: elicitação, análise e negociação, especificação e modelagem, validação, e gerenciamento de requisitos: Elicitação: A elicitação de requisitos corresponde a identificar junto aos clientes, usuários e outros envolvidos, quais são os objetivos do sistema ou produto, o que deve ser acompanhado, como o sistema ou produto se encaixa no contexto das necessidades do negócio e, finalmente, como será a utilização do sistema ou produto no dia-a-dia. Análise e Negociação: A análise categoriza e organiza os requisitos em subconjuntos relacionados, explora o relacionamento de cada requisito com todos os demais, examina consistência, omissão e ambigüidade dos requisitos e prioriza requisitos com base nas necessidades dos clientes/usuários. Especificação e Modelagem: A especificação do sistema é o produto final produzido pelos engenheiros de requisitos. Ela é usada como base para as engenharias de hardware, software e banco de dados, pois descreve funções e performance requeridas de um sistema baseado em computação e as regras que irão guiar seu desenvolvimento. A especificação limita cada elemento alocado ao sistema. A especificação do sistema também descreve a informação (dados e

25 16 controle) que é entrada e saída do sistema. A modelagem dos requisitos especificados pode facilitar o entendimento das relações existentes entre os mesmos. Validação: A validação examina a especificação para garantir que todos os requisitos do sistema foram estruturados de maneira não ambígua, que as inconsistências, omissões e erros foram apagados e corrigidos, e que os produtos de trabalho estão em conformidade com os padrões estabelecidos para o processo, para o projeto e para o produto. Gerenciamento de Requisitos: É necessário persistir as alterações de requisitos através de toda a vida do software; neste sentido, o gerenciamento de requisitos corresponde ao conjunto de atividades que auxilia a equipe do projeto a identificar, controlar e rastrear os requisitos, bem como as alterações nos requisitos em muitos momentos do projeto Métodos de análise de requisitos No decorrer das duas últimas décadas, uma série de métodos de análise e especificação de requisitos foi desenvolvida, entretanto, poucas são as propostas que visam uma sistematização da elicitação de requisitos de forma a tornar esta atividade menos subjetiva (SANTANDER; CASTRO, 2002). No paradigma da orientação a objeto a análise de requisitos tem sido feita com base num elemento de modelagem da UML chamado de Caso de Uso. Embora existam algumas heurísticas propostas para identificação de casos de uso, como as apresentadas em Schneider e Winters (1998), Jacobson et al (1999), e em Lilly (1999), não existem métodos estabelecidos que tornem esta atividade mais sistemática. Os casos de uso são geralmente identificados em entrevistas com futuros usuários do sistema e responsáveis pelo negócio, realizadas por analistas de sistemas.

26 17 Segundo PRESSMAN (1995) cada método de análise tem uma notação e um ponto de vista únicos porém todos eles relacionam-se com um conjunto de princípios fundamentais: 1. O domínio de informação de um problema deve ser representado e compreendido para que a função possa ser entendida mais completamente. 2. Modelos que descrevam a informação, função e comportamento do sistema devem ser desenvolvidos para que a informação possa ser comunicada completamente. 3. Os modelos (e o problema) devem ser divididos em partições, de maneira que revele os detalhes em forma de camadas (ou hierarquicamente), e assim reduzir a complexidade. 4. O processo de análise deve mover-se da informação essencial para os detalhes de implementação para acomodar as restrições lógicas impostas por requisitos de processamento e as restrições físicas impostas por outros elementos do sistema UML A UML foi adotada pela OMG (Object Management Group) em 1997 como linguagem padrão para a modelagem de sistemas orientados a objeto. Ela é uma linguagem para especificação, visualização, construção, e documentação de artefatos de sistemas de software, tão bem como para a modelagem de negócios e outros sistemas que não de software. Ela representa uma coleção das melhores práticas de engenharia que provaram sucesso na modelagem de sistemas grandes e complexos. (OMG, 2002) Os principais objetivos na definição da UML (OMG, 2002) são: 1. Prover aos usuários uma linguagem de modelagem visual de forma que eles pudessam desenvolver e trocar modelos; 2. Prover mecanismos de extensão e especialização para estender o centro dos conceitos;

27 18 3. Ser independente de uma linguagem de programação específica e de processos de desenvolvimento; 4. Prover uma base formal para o entendimento da linguagem de modelagem; 5. Incentivar o crescimento de ferramentas de orientação a objeto no mercado; 6. Suportar desenvolvimento de conceitos de alto nível como colaboração, arquiteturas de referência, padrões, e componentes; 7. Integrar as melhores práticas. Muitos usuários de outros métodos (BOOCH, OMT, FUSION, entre outros) adotaram a UML. A maioria das ferramentas de modelagem de sistemas têm implementado o suporte à linguagem, entre elas o Rose da Rational e o Together da Together Soft. A UML padroniza notação para descrever modelos, mas não padroniza um processo para produzir aquelas descrições (uma ordem de atividades bem definidas, um conjunto de artefatos produzidos, e meios de controlar e monitorar o trabalho). A UML pode ser usada por diversos processos de desenvolvimento distintos, mais ou menos formalmente especificados. Com relação a estrutura da UML, conforme apresentado em (BOOCH; JACOBSON; RUMBAUGH, 2000), o vocabulário da UML abrange três tipos básicos de blocos de construção: 1- Itens 2- Relacionamentos 3- Diagramas Os itens são as abstrações identificadas em um modelo; os relacionamentos reúnem esses itens; os diagramas agrupam coleções interessantes de itens Itens da UML Existem quatro tipos de itens na UML:

28 19 1- Itens estruturais 2- Itens comportamentais 3- Itens de agrupamentos 4- Itens de anotação Estes itens constituem os blocos de construção básicos orientados a objetos da UML e são utilizados para escrever modelos bem-formados Itens estruturais São os substantivos utilizados em modelos da UML. São as partes mais estáticas do modelo, representando elementos conceituais ou físicos. Ao todo existem sete tipos de itens estruturais: Classes - são descrições de conjuntos de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica. Interface - é uma coleção de operações que especificam serviços de uma classe ou componente. Portanto, uma interface descreve o comportamento externamente visível desse elemento. Uma interface poderá representar todo o comportamento de uma classe ou componente, como também apenas parte desse comportamento. A interface define um conjunto de especificações de operações (suas assinaturas), mas nunca um conjunto de implementações de operações. Colaborações - definem interações e são sociedades de papéis e outros elementos que funcionam em conjunto para proporcionar um comportamento cooperativo superior à soma de todos os elementos. Portanto, as colaborações contêm dimensões estruturais, assim como comportamentais. Uma determinada classe poderá participar em várias colaborações. Assim, essas colaborações representam a implementação de padrões que formam um sistema.

29 20 Caso de Uso - é a descrição de um conjunto de seqüência de ações realizadas pelo sistema que proporciona resultados observáveis de valor para um determinado ator. Um caso de uso é utilizado para estruturar o comportamento de itens em um modelo. Um caso de uso é realizado por uma colaboração. Os outros três itens restantes classes ativas, componentes e nós são semelhante a classes, ou seja, descrevem conjuntos de objetos que compartilham os mesmos atributos, operações, relacionamentos e semânticas. Porém, esses três são suficientemente diferentes e necessários para a modelagem de certos aspectos de sistemas orientados a objetos e, portanto merecem um tratamento especial: Classes ativas - são classes cujos objetos têm um ou mais processos ou threads e, portanto, podem iniciar a atividade de controle. Uma classe ativa é semelhante a uma classe, exceto pelo fato de que seus objetos representam elementos cujo comportamento é concorrente com o de outros elementos. Componentes - são partes físicas e substituíveis de um sistema, que proporcionam a realização de um conjunto de interfaces. Em um sistema, encontram-se diferentes tipos de componentes próprios da implantação, como os componente COM+ ou Java Beans, assim como componentes que são artefatos do processo de desenvolvimento, como os arquivos de código-fonte. Tipicamente os componentes representam o pacote físico de elementos lógicos diferentes, como classes, interfaces e colaborações. Nó - é um elemento físico existente em tempo de execução que representa um recurso computacional, geralmente com pelo menos alguma memória e, freqüentemente, capacidade de processamento. Um conjunto de componentes poderá estar contido em um nó e também poderá migrar de um nó para outro. Esses sete elementos classes, interfaces, colaborações, casos de uso, classes ativas, componentes e nós são os itens estruturais básicos que se pode incluir em um modelo da UML. Também existem variações desses sete elementos, como atores,

30 21 sinais e utilitários (tipos de classes), processos e threads (tipos de classes ativas), e aplicações, documentos, arquivos, bibliotecas, páginas e tabelas (tipos de componentes) Itens comportamentais Os itens comportamentais são as partes dinâmicas dos modelos de UML. São os verbos de um modelo, representando comportamentos no tempo e no espaço. Ao todo, existem dois tipos principais de itens comportamentais: Interação - é um comportamento que abrange um conjunto de mensagens trocadas entre um conjunto de objetos em determinado contexto para a realização de propósitos específicos. O comportamento de uma sociedade de objetos ou de uma operação individual poderá ser especificado por meio de uma interação. As interações envolvem outros elementos, inclusive mensagens, sequências de ações (os comportamentos chamados pelas mensagens) e ligações (as conexões entre objetos). Máquina de estado - é um comportamento que especifica as sequências de estados pelos quais objetos ou interações passam durante sua existência em reposta a eventos, bem como suas respostas a esses eventos. O comportamento de uma classe individual ou de uma colaboração de classes pode ser especificado por meio de uma máquina de estados. Um máquina de estado abrange outros elementos, incluindo estados, transições (o fluxo de um estado a outro), eventos (itens que disparam uma transição) e atividades (as respostas às transições). Semanticamente, esses itens comportamentais costumam estar conectados a vários elementos estruturais, classes principais, colaborações e objetos.

31 Itens de agrupamento Os itens de agrupamento são as partes organizacionais dos modelos de UML. São os blocos em que os modelos podem ser decompostos. Ao todo, existe apenas um tipo principal de itens de agrupamento, chamado pacote: Pacote - é um mecanismo de propósito geral para a organização de elementos em grupos. Os itens estruturais, os itens comportamentais e até outros itens de grupos podem ser colocados em pacotes. Ao contrário dos componentes (que existem em tempo de execução), um pacote é puramente conceitual (o que significa que existe apenas em tempo de desenvolvimento). Os pacotes são itens de agrupamento básico, servem para organizar modelos de UML. Também existem variações, como frameworks, modelos e subsistemas (tipos de pacotes) Itens de anotação Os itens de anotação são as partes explicativas dos modelos de UML. São comentários, incluídos para descrever, esclarecer e fazer alguma observação sobre qualquer elemento de modelo. Existe um único tipo de item de anotação, chamado nota: Nota - é apenas um símbolo para representar restrições e comentários anexados a um elemento ou a uma coleção de elementos. Esse elemento é o único item de anotação básico que se pode incluir em um modelo de UML. Geralmente são utilizadas para aprimorar os diagramas com restrições ou comentários que possam ser mais bem expressos por um texto formal ou informal. Também existem variações desse elemento, como os requisitos (que especificam determinado comportamento desejado sob uma perspectiva externa ao sistema).

32 Relacionamentos na UML Existem quatro tipos de relacionamentos na UML: 1- Dependência 2- Associação 3- Generalização 4- Realização Esses relacionamentos são os blocos relacionais básicos de construção da UML: Dependência - é um relacionamento semântico entre dois itens, nos quais a alteração de um (o item independente) pode afetar a semântica do outro (o outro dependente). Associação - é um relacionamento estrutural que descreve um conjunto de ligações, em que as ligações são conexões entre objetos. A agregação é um tipo especial de associação, representando um relacionamento estrutural entre o todo e suas partes. Generalização - é um relacionamento de especialização/generalização, nos quais os objetos dos elementos especializados (os filhos) são substituíveis por objetos do elemento generalizado (os pais). Dessa maneira, os filhos compartilham a estrutura e o comportamento dos pais. Realização - é um relacionamento semântico entre classificadores, em que um classificador especifica um contrato que outro classificador garante executar. Os relacionamentos de realizações serão encontrados em dois locais: entre interfaces e as classes ou componentes que as realizam; e entre casos de uso e as colaborações que os realizam.

33 24 Também existem variações desses quatro elementos, como refinamentos, rastros, inclusões e extensões (para dependências) Diagramas da UML Um diagrama é a apresentação gráfica de um conjunto de elementos, geralmente representadas como gráficos de vértices (itens) e arcos (relacionamentos). São desenhados para permitir a visualização de um sistema sob diferentes perspectivas; nesse sentido, um diagrama constitui uma projeção de um determinado sistema. Em todos os sistemas, com exceção dos mais triviais, um diagrama representa uma visão parcial dos elementos que compõem o sistema. O mesmo elemento pode aparecer em todos os diagramas, em apenas alguns (o caso mais comum) ou em nenhum diagrama (um caso muito raro). Na teoria, um diagrama pode conter qualquer combinação de itens e de relacionamentos. Na prática, porém, aparecerá um pequeno número de combinações comuns, que são consistentes com as cinco visões mais úteis da arquitetura de um sistema complexo de software apresentadas no item 2.3. A UML inclui nove diagramas: 1- Diagrama de classes 2- Diagrama de objetos 3- Diagrama de casos de uso 4- Diagrama de seqüência 5- Diagrama de colaborações 6- Diagrama de gráficos de estados 7- Diagrama de atividades 8- Diagrama de componentes 9- Diagrama de implantação Diagrama de classe - exibe um conjunto de classes, interfaces e colaborações, bem como seus relacionamentos. Esses diagramas são encontrados com maior frequência em sistemas de modelagem orientados a objeto e abrangem uma visão estática da estrutura do sistema.

34 25 Diagrama de objetos - exibe um conjunto de objetos e seus relacionamentos. Representa retratos estáticos de instâncias de itens encontrados em diagrama de classes. São diagramas que abrangem a visão estática da estrutura ou do processo de um sistema, como ocorre nos diagramas de classes, mas sob perspectiva de casos reais ou de protótipos. Diagrama de caso de uso - exibe um conjunto de caso de uso e atores (um tipo especial de classe) e seus relacionamentos. Diagramas de caso de uso abrangem a visão estática de casos de uso do sistema. Esses diagramas são importantes principalmente para a organização e a modelagem de comportamentos do sistema. Tanto os diagramas de seqüências como os de colaborações são tipos de diagramas de interações. Um diagrama de interação exibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. Diagramas de interações abrangem a visão dinâmica de um sistema. Diagrama de seqüências - é um diagrama de interações cuja ênfase está na ordenação temporal das mensagens. Diagrama de colaborações - é um diagrama de interação cuja ênfase está na organização estrutural dos objetos que enviam e recebem mensagens. Os diagramas de seqüências e de colaborações são isomórficos, o que significa que você poderá transformar o diagrama de um tipo em um diagrama de outro tipo. Diagramas de gráfico de estados - exibem uma máquina de estados, formada por estados, transições, eventos e atividades. Os diagramas de gráfico de estados abrangem a visão dinâmica de um sistema. São importantes principalmente para a modelagem de comportamentos de uma interface, classe ou colaboração e para dar ênfase a comportamentos de um objeto ordenados por eventos, o que é de grande ajuda para a modelagem de sistemas reativos.

35 26 Diagrama de atividade - é um tipo especial de diagrama de gráfico de estado, exibindo o fluxo de uma atividade para outra no sistema. Abrange a visão dinâmica do sistema e é importante principalmente para a modelagem da função de um sistema. Dá ênfase ao fluxo de controle entre objetos. Diagrama de componente - exibe as organizações e as dependências existentes em um conjunto de componentes. Abrange a visão estática da implementação de um sistema. Está relacionado aos diagramas de classes, pois tipicamente os componentes são mapeados para uma ou mais classes, interface ou colaborações. Diagrama de implantação - mostra a configuração dos nós de processamento em tempo de execução e os componentes neles existentes. Abrange a visão estática do funcionamento de uma arquitetura. Está relacionado aos diagramas de componentes, pois tipicamente um nó inclui um ou mais componentes Adornos Em sua maioria, os elementos da UML têm uma notação gráfica única e direta, que proporciona uma apresentação visual dos aspectos mais importantes do elemento. Por exemplo, a notação para uma classe é intencionalmente projetada para ser desenhada facilmente, pois as classes são os elementos mais comumente encontrados em sistemas de modelagem orientados a objetos. A notação de classe também expõe os aspectos mais importantes da classe, ou seja, seu nome, atributos e operações. A especificação da classe pode incluir outros detalhes, como se a classe é abstrata ou como é a visibilidade de seus atributos e operações. Muitos desses detalhes podem ser representados como adornos gráficos ou textuais para a notação retangular básica da classe. Todos os elementos da notação da UML são iniciados com um símbolo básico, ao qual pode ser acrescentada uma variedade de adornos específicos desse símbolo.

36 Mecanismos de extensibilidade A UML fornece uma linguagem-padrão para a elaboração de estrutura de projetos de software, mas não é possível que uma única linguagem fechada seja suficiente para expressar todas as nuances possíveis de todos os modelos em qualquer domínio o tempo todo. Por isso, a UML permite que a linguagem seja ampliada de uma maneira controlada através de mecanismos de extensão. Estes mecanismos têm a intenção de servirem aos seguintes propósitos: Podem ser usados para adicionar elementos de modelagem na criação de modelos; São usados nas especificações da UML para definir itens padrões não considerados ou complexos demais para serem modelados diretamente pelos elementos do metamodelo UML; São usados para definir processos específicos ou implementação de extensões de linguagens específicas; São usados para unir arbitrariamente informações semânticas e não semânticas a elementos do modelo. Os mecanismos de extensibilidade da UML incluem: Estereótipos - definem novos blocos construtores na UML baseados em blocos existentes. Embora não seja possível adicionar novos tipos de elementos, todos os elementos da UML podem ser customizados, estendidos, ou adaptados através da definição e nomeação de estereótipos. Valores atribuídos - estendem um elemento da UML através de uma etiqueta (tag) e um valor (value). Por exemplo pode ser definida um valor atribuído para expressar a versão de uma determinada classe. Restrições - são regras aplicadas aos modelos UML. Podem ser aplicadas para apenas um ou para vários elementos do modelo. Por exemplo pode-se

37 28 definir através de uma restrição um condicionamento numa associação entre duas classes. A UML possui um grande potencial de expressão e modelagem podendo ser amplamente aplicada sem extensões, portanto empresas e projetos devem definir extensões apenas quando for realmente necessário introduzir novas notações e terminologias. Os conceitos fundamentais não devem ser mudados mais que o estritamente necessário (OMG, 2001). No capítulo 3 será apresentada a disciplina de modelagem de negócio e como a UML tem sido proposta como linguagem para a construção dos modelos neste domínio. A seção a seguir irá apresentar o Processo Unificado, uma metodologia baseada no modelo iterativo e incremental e que será usada como base para o desenvolvimento deste trabalho O Processo Unificado O Processo Unificado (UP) é um processo estabelecido para o desenvolvimento de software que resultou de três décadas de desenvolvimento e uso prático. Jacobson et al(1999) apresenta as origens do UP desde o processo Objectory (com primeira versão em 1987) passando pelas contribuições do Processo Rational Objectory (em 1997) até o Processo Unificado da Rational (RUP) (em 1998). O propósito do UP, como qualquer outro processo de desenvolvimento, é determinar um conjunto de atividades necessárias para transformar requisitos em sistemas de software. Ele utiliza a UML como linguagem para a modelagem dos artefatos de software produzidos ao longo do processo de desenvolvimento. O processo Unificado representa a disponibilização do RUP (que é proprietário da Rational) ao público geral. (JACOBSON; BOOCH; RUMBAUGH, 1999)

38 Caractéristicas do UP O UP é fundamentado em três boas práticas: dirigido por caso de uso, centrado em arquitetura, e iterativo e incremental. Estas práticas são descritas a seguir, conforme apresentadas em RUP(2001): Dirigido por caso de uso: Os casos de uso definidos para um sistema são a base de todo o processo de desenvolvimento. Baseados no modelo de caso de uso, os desenvolvedores criam uma série de modelos de projeto e implementações que realizam no sistema as funcionalidades dos casos de uso. Os testes também são realizados de forma a verificar se os componentes implementados implementam corretamente as funcionalidades dos casos de uso. Centrado em arquitetura: Os casos de uso orientam o UP durante todo o ciclo de vida, mas as atividades de projeto são centralizadas na noção da arquitetura de software. O foco principal das iterações iniciais do processo, principalmente na fase de Elaboração, é produzir e validar uma arquitetura de software, que no ciclo de desenvolvimento inicial toma a forma de um protótipo arquitetural executável que gradualmente evolui até se tornar o sistema final em iterações posteriores. Iterativo e Incremental: O UP utiliza pequenos ciclos de projeto (mini-projetos) que correspondem a uma iteração e que resultam em um incremento no software. Iterações referem-se a passos no processo, e incrementos a evoluções do produto. Esta característica foi apresentada anteriormente no item 2.2. Sua estrutura portanto é composta por Fases (relacionadas às metas ao longo do tempo) e Workflows (relacionadas à natureza das atividades). Cada Workflow é responsável por gerar seus respectivos artefatos através de um

39 30 conjunto de atividades. Cada Artefato corresponde a uma documentação (como um modelo) ou outro objeto de valor a ser criado no desenvolvimento (como um componente de software). Por ser iterativo, cada fase percorre todo o conjunto de fluxos de trabalho (workflows). Por ser incremental, cada iteração atualiza os artefatos gerados nas iterações anteriores. Cada fase possui uma maior ênfase em determinados fluxos de trabalho. A Figura 5, conhecida como Gráfico das Baleias apresenta a ênfase que é cada em cada fase. Figura 5 O Gráfico das Baleias (Adaptado de RUP, 2002) Na figura podem ser observadas duas dimensões: o eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve o eixo vertical representa os workflows, que agrupam as atividades de maneira lógica, por natureza. A primeira dimensão representa o aspecto dinâmico do processo quando ele é aprovado e é expressa em termos de fases, iterações e marcos. A segunda dimensão representa o aspecto estático do processo, como ele é descrito em termos de componentes, atividades, fluxos de trabalho, artefatos e papéis do processo.

40 31 O gráfico mostra como a ênfase varia através do tempo. Por exemplo, nas iterações iniciais, dedica-se mais tempo aos requisitos. Já nas iterações posteriores, gasta-se mais tempo com implementação Fases A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do UP é dividido em quatro fases seqüenciais. Cada fase refere-se a uma determinada meta a ser atingida ao longo do desenvolvimento. As fases correspondem a períodos determinados por pontos de controle ao longo do tempo. Em cada ponto de controle, ou seja, ao final de cada fase, é esperado um determinado estado de alguns artefatos do desenvolvimento. Em cada final de fase é executada uma avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase. As fases e seus marcos são apresentados na Figura 6. Figura 6 - As fases e os marcos de um projeto no UP.(Adaptado do RUP 2002) Concepção: O objetivo da fase de Concepção é conseguir a simultaneidade entre o cliente e o desenvolvedor nos objetivos do ciclo de vida do projeto. A Fase de Concepção é de importância primária para novos esforços de desenvolvimento quando há um negócio significativo e riscos requeridos que precisam ser esclarecidos antes do procedimento do projeto. Para projetos focados ou aprimoramento de um sistema já existente, a fase de Concepção é mais breve, mas ainda deve estar focalizado para assegurar que o projeto ainda é válido e possível de ser feito.