diana ferreira barboza melhoria de … › pergamum › vinculos › 000003 › 00000322.pdfdalai...
TRANSCRIPT
DIANA FERREIRA BARBOZA
MELHORIA DE PROCESSO NA FASE ELABORAÇÃO UTILIZANDO O RUP
LONDRINA
2011
DIANA FERREIRA BARBOZA
MELHORIA DE PROCESSO NA FASE ELABORAÇÃO UTILIZANDO O RUP
Trabalho de Conclusão de Curso apresentado
à 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 grau de Especialista em
Engenharia de Software sob a orientação do
professor MSc. Sérgio Akio Tanaka.
LONDRINA
2011
DIANA FERREIRA BARBOZA
MELHORIA DE PROCESSO NA FASE ELABORAÇÃO UTILIZANDO O RUP
Monografia apresentada à Banca Examinadora do Curso de Pós-Graduação em
Engenharia de Software com UML Centro Universitário Filadélfia de Londrina -
UniFil em cumprimento ao requisito parcial para obtenção do título de Especialista
em Engenharia de Software.
APROVADA PELA COMISSÃO EXAMINADORA
EM LONDRINA, 30 de Julho de 2011.
Prof. MSc. Sergio Akio Tanaka
(UniFil) - Orientador
Prof. Dr. Rodrigo Duarte Seabra
(UniFil) - Avaliador
Dedico este trabalho à minha filha, família e amigos que me apoiaram e
incentivaram na conclusão desta.
AGRADECIMENTOS
Aos meus pais, especialmente a minha mãe pela compreensão, apoio e
confiança, sem a qual não poderia de jeito nenhum começar mais esta etapa de
vida.
A minha pequena grande filha Nádia Maria que pela sua pouca idade
pôde compreender minha ausência mesmo estando em casa, e mesmo assim me
deu seu carinho e amor.
A toda minha família pela torcida, em especial a minha irmã Karina.
Aos meus amigos, especialmente a Luciane Pedroso, pelo incentivo,
apoio e conselhos.
Ao orientador pela paciência, pela disposição em ajudar e compreensão
pelas dificuldades surgidas.
À Universidade Filadélfia (UniFil) e professores, pela oportunidade em
aprofundar os conhecimentos, pelos incentivos e exemplos.
Á Deus, por ter me proporcionado tantos motivos e pessoas para
agradecer.
“Só existem dois dias no ano que nada pode
ser feito. Um se chama ontem e o outro se chama
amanhã, portanto hoje é o dia certo para amar,
acreditar, fazer e principalmente viver”.
Dalai Lama
"Grandes realizações não são feitas por
impulso, mas por uma soma de pequenas
realizações”.
Vincent Van Gogh
BARBOZA, D. F. MELHORIA DE PROCESSO NA FASE ELABORAÇÃO
UTILIZANDO O RUP. Londrina, 2011. 51f. Monografia - Curso de Pós-Graduação
em Engenharia de Software com UML. Centro Universitário Filadélfia de Londrina -
UniFil, Londrina, 2011.
RESUMO
Este trabalho apresenta um estudo sobre a fase Elaboração do Rational Unified
Process (RUP) junto com uma iniciativa rumo ao levantamento de algumas
dificuldades em se projetar uma arquitetura base durante esta fase, e a aplicação
dos conceitos e artefatos da Elaboração em um estudo de caso para um website
usando a tecnologia Language INtegration Query (LINQ), além de empregar a UML
para modelagem.
Palavras-chave : Arquitetura, Elaboração, RUP.
ABSTRACT
This paper presents a study on the preparation phase of the Rational Unified Process
(RUP) with an initiative towards the lifting of some difficulties in designing a base
architecture during this phase, and applies the concepts and artifacts in preparation
for a case study a website using technology Language Integration Query (LINQ), and
employs the UML for modeling.
Keywords : Architecture, Elaboration, RUP.
LISTA DE FIGURAS
Figura 1: Estrutura do processo RUP. Fonte: (IBM, 2006) ........................................ 15
Figura 2: Custo de mudanças no software. Fonte: (QUADROS, 2002). ................... 18
Figura 3: Fluxo de Análise e Design. Fonte: (IBM, 2006) .......................................... 22
Figura 4: Detalhamento do Fluxo de Trabalho: Definir uma Sugestão de Arquitetura.
Fonte: (IBM, 2006) .................................................................................................... 23
Figura 5: Projetar Arquitetura. Fonte: (IBM, 2006) .................................................... 29
Figura 6: Modelo 4 + 1. Fonte: (KRUCHTEN, 1995) ................................................. 31
Figura 7: Diagrama de Caso de Uso ......................................................................... 35
Figura 8 Diagrama de Classes .................................................................................. 36
Figura 9: Ícones dos elementos da WAE .................................................................. 36
Figura 10: Diagrama Navegacional - Gerenciar Usuários ......................................... 38
Figura 11: Modelo físico do banco de dados ............................................................. 39
Figura 12: Design do DataContext ............................................................................ 40
LISTA DE ABREVIATURAS E SIGLAS
GUI Graphical User Interface
IBM International Business Machines
IOC Initial Operational Capability
LCA LifeCycle Architecture
LCO LifeCycle Objetive
LINQ Language INtegration Query
RUP Rational Unified Process
TI Tecnologia da Informação
UML Unified Modeling Language
UniFil Centro Universitário Filadélfia
WAE Web Application Extension
SUMÁRIO
1 INTRODUÇÃO ............................................................................................... 12
1.1 OBJETIVOS ................................................................................................... 13
2 REVISÃO DA LITERATURA ............................. ............................................ 14
2.1 RUP ................................................................................................................ 14
2.2 FASE ELABORAÇÃO ..................................................................................... 16
2.3 RISCOS .......................................................................................................... 19
2.4 DISCIPLINAS DE ELABORAÇÃO .................................................................. 20
2.4.1 Modelagem de Negócio .............................................................................. 20
2.4.2 Requisitos ................................................................................................... 20
2.4.3 Análise e Design ......................................................................................... 21
2.4.4 Implementação ........................................................................................... 24
2.4.5 Teste ........................................................................................................... 25
2.4.6 Implantação ................................................................................................ 25
2.4.7 Gerenciamento de Configuração e Mudança .............................................. 25
2.4.8 Gerenciamento do Projeto .......................................................................... 26
2.4.9 Ambiente ..................................................................................................... 27
2.5 MARCO DE CONCLUSÃO ............................................................................. 27
2.6 ARQUITETURA .............................................................................................. 29
3 DESENVOLVIMENTO DO TRABALHO ....................... ................................. 33
3.1 ESTUDO DE CASO........................................................................................ 33
3.1.1 Fase Iniciação ............................................................................................. 33
3.1.2 Fase Elaboração: ........................................................................................ 34
4 CONCLUSÕES .............................................................................................. 43
REFERÊNCIAS ......................................................................................................... 45
APÊNDICE A – REQUISITOS DE SOFTWARE ............... ........................................ 47
APÊNDICE B – DOCUMENTO DE ARQUITETURA DE SOFTWARE . ................... 48
APÊNDICE C – PLANO DE PROJETO ..................... ............................................... 49
APÊNDICE D – PLANO DE ITERAÇÃO .................... .............................................. 50
APÊNDICE E – ESPECIFICAÇÃO DE CASO DE USO GERENCIAR USUÁRIOS . 51
12
1 INTRODUÇÃO
Este trabalho apresenta um planejamento voltado para o desenvolvimento
de software e o estudo de algumas dificuldades em se projetar uma arquitetura base
na fase de Elaboração da metodologia Rational Unified Process (RUP). O resultado
deste estudo foi aplicado em um estudo de caso para o desenvolvimento do Módulo
Administrativo de um website, utilizando a tecnologia Language INtegration Query
(LINQ) para acesso a dados.
As organizações que possuem sistemas de informação buscam obter
vantagens em ganho de produtividade, melhoria de qualidade, redução de custos e
diminuição de riscos. Esses sistemas se tornam de suma importância ao negócio, já
que podem acarretar prejuízos caso haja quaisquer problemas. De forma paralela,
ao longo dos anos está cada vez mais complexo o desenvolvimento do software,
coincidentemente na exata medida em que as demandas de software das empresas
aumentam em importância estratégica para suas operações.
O desenvolvimento de software possui um alto grau de risco, e se não for
gerenciado de forma eficaz, fracassará. Isso se deve muitas vezes por um
planejamento inadequado e, até mesmo, uma metodologia fraca ou a ausência de
uma, pode ser a causa de uma arquitetura frágil e consequentemente um produto
instável que ocasionará conflitos que impeçam o funcionamento correto de um
sistema (KRUCHTEN, 2003).
Assim, Conallen (2003) menciona: "as equipes de desenvolvimento estão
tornando-se cada vez maiores e as habilidades dos membros da equipe agora são
especializadas. O desenvolvimento desses tipos de aplicações sem um processo
muito robusto e bem compreendido pode ser imprudente".
O planejamento de um projeto fazendo uso do RUP proporciona uma
metodologia confiável que guia a equipe do início até a finalização do projeto
inclusive em uma das fases mais desafiadoras, a Elaboração, na qual o propósito é
estabelecer os fundamentos arquiteturais para o projeto do software.
Este documento está organizado da seguinte forma: o capítulo 1 aborda a
introdução com objetivos do trabalho; o capítulo 2 relata sobre a revisão da literatura,
13
com a metodologia escolhida, a pesquisa sobre a fase de Elaboração, suas
disciplinas, e descreve as considerações sobre a arquitetura de sistemas; no
capítulo 3 apresenta o estudo de caso realizado aplicando os conceitos estudados
no capítulo 2; o capítulo 4 mostra as considerações, conclusões e trabalhos futuros.
Nos apêndices podem ser encontrados os documentos de maior importância
gerados durante o desenvolvimento do estudo de caso, sendo estes: no apêndice A
estão os Requisitos de Software; o apêndice B mostra o Documento de Arquitetura
de Software, o apêndice C exibe o Plano de Projeto; o apêndice D apresenta o Plano
de Iteração e, por fim, no Apêndice E está a Especificação do Caso de Uso
Gerenciar Usuários.
1.1 OBJETIVOS
Este trabalho visa estudar e aplicar a fase Elaboração do RUP e seu
marco de progresso, a arquitetura base em um estudo de caso. Segundo Kruchten
(2003), o propósito da fase é “analisar o domínio do problema, estabelecer uma
fundação arquitetônica sadia, desenvolver o plano de projeto e eliminar os
elementos de alto risco do projeto”.
Pelo exposto, este trabalho contém os seguintes objetivos específicos:
• estudar os artefatos de entrada e saída da fase de Elaboração;
• analisar como a fase passa pelas disciplinas do RUP;
• entender como as disciplinas do RUP colaboram para a
estruturação efetiva e eficaz de tarefas e fluxos de trabalho;
• identificar alguns riscos da fase;
• elaborar um estudo de caso para validar os conceitos da fase.
14
2 REVISÃO DA LITERATURA
Neste capítulo foram abordados os assuntos necessários para embasar a
fundamentação teórica, sustentar a proposição metodológica e relacionar os
resultados obtidos com o estudo de caso com elementos da literatura.
2.1 RUP
Para Jacobson et al.(1999), a indústria de software necessita de um
processo para orientar a equipe de desenvolvimento. Um processo "define quem
está fazendo o que, onde e quando para alcançar um objetivo”.
Ao empregar a metodologia, os gerentes de projeto conseguem um
planejamento mais eficaz, pois o RUP permite minimizar os riscos, mapear a
arquitetura, e integrar os testes realizados do início do projeto à implantação
(KRUCHTEN, 2003).
Conforme Kroll e Kruchten (2003), o RUP pode ser definido como: “o
produto IBM RUP suporta a customização e autoria de processos, e uma vasta
variedade de processos, ou configuração de processos, podem ser montadas nele”.
Para organizações que fazem uso desta metodologia, a característica de
ser um processo configurável, significa que a empresa pode ter diferentes
processos, de acordo com o projeto em que se está trabalhando. O RUP assim
atende desde projetos pequenos até projetos em que se exigem maiores esforços e
uma quantidade grande de profissionais atuando ao mesmo tempo, ou seja, permite
que o método seja configurado para adequar-se às necessidades exclusivas de cada
projeto.
O RUP divide em duas dimensões seu processo unificado, como
apresenta o gráfico da Figura 1.
15
A primeira dimensão indica as fases que representam o ciclo de vida de
construção de software e, a segunda, os fluxos de processos que contemplam as
atividades a serem realizadas no projeto (IBM, 2009).
A construção do software com o RUP é iterativa e incremental, onde o
projeto é dividido em pequenas fases ou “iterações” (KENDALL,2004).
Figura 1: Estrutura do processo RUP. Fonte: (IBM, 2006)
As fases são compreendidas em:
• iniciação : refere-se à especificação da visão do produto, o domínio de
negócio e a definição do escopo do projeto. O marco de conclusão dessa
fase é o Lifecycle Objetive (LCO), objetivo do ciclo de vida;
• elaboração : retrata como planejar as atividades e os recursos
necessários, além de projetar a arquitetura a ser utilizada. Define também
o ambiente onde a aplicação será executada e os testes que serão
16
efetuados. O marco de conclusão é LifeCycle Architecture (LCA),
arquitetura do ciclo de vida;
• construção : destina-se ao desenvolvimento do produto em si, até a
visão estar completa para a entrega aos usuários. Implica-se nesta fase
também, o desenvolvimento de versões demonstrativas, denominados
protótipos. O marco de conclusão é Initial Operational Capability (IOC),
capacidade operacional inicial;
• transição : o objetivo é a implantação final do software. Isso inclui
treinamentos e a manutenção do software após a entrega. O marco de
conclusão é product release, lançamento do produto (KENDALL, 2004).
2.2 FASE ELABORAÇÃO
Humphrey afirma que: “se você não planeja você não pode executar uma
operação de produção” (SEI, 2011).
Com base nessa afirmação, a fase Elaboração é responsável por evoluir
a idéia conceitual para modelos e planos tangíveis, assim que o escopo do software
é fechado e estabelecido pela fase de Iniciação. É a fase cuja preocupação central é
a estruturação e a viabilidade operacional do projeto por meio do desenvolvimento
da arquitetura candidata e, se possível, um primeiro protótipo.
A fase envolve descobrir as informações sobre o projeto o mais cedo
possível. Para isso, acontece o detalhamento das atividades contidas no projeto, por
meio de definição das tarefas (MARTINS, 2007).
No início desta fase, o profissional tem uma vaga idéia das
funcionalidades do software, tendo que investigar a fundo os obstáculos e os
prováveis riscos que o projeto poderá encontrar no decorrer do desenvolvimento,
pelo detalhamento e refinamento dos requisitos (QUADROS, 2002).
O planejamento de um projeto de desenvolvimento de software e
consequentemente os objetivos da fase incluem:
17
• organizar e estruturar o projeto, incluindo atividades, equipes e
responsabilidades;
• refinar a visão, fundamentado nas informações obtidas, estabelecendo
uma compreensão sólida dos casos de uso mais críticos que interferem e
conduzem as decisões de arquitetura e planejamento;
• analisar e gerenciar os riscos relacionados à arquitetura do projeto;
• produzir um protótipo evolutivo para diminuir riscos específicos como:
� selecionar componentes potenciais;
� mudanças de design/requisitos;
� reutilização de componentes;
� demonstração do sistema para investidores, clientes e usuários
finais;
� evidenciar que a arquitetura de baseline suportará os requisitos
do sistema a um custo aceitável e em tempo planejado.
• refinar o caso de desenvolvimento e posicionar o ambiente de
desenvolvimento, incluindo o processo, as ferramentas e o suporte de
automatização necessária para dar assistência à equipe do projeto
(KRUCHTEN, 2003).
Uma das finalidades em se projetar a arquitetura candidata, marco dessa
fase, é para prevenir os impactos de uma provável mudança. Mesmo explicando ao
usuário o custo da mudança nas fases posteriores, poderão aparecer mudanças no
decorrer do projeto, pois como cita Humphrey “o usuário não saberá o que ele quer
até utilizar o sistema real (talvez nem assim)” (LIMA, 2011).
As solicitações de mudança podem surgir por várias razões: “corrigir um
defeito, melhorar a qualidade do produto (como a utilidade ou desempenho),
adicionar um requisito ou, simplesmente, documentar o delta entre uma iteração e a
próxima” (KRUCHTEN, 2003).
Para Quadros (2002), a mudança dos requisitos na fase de elaboração
18
envolve menos custos que nas fases posteriores.
Como Krutchen (2003) cita, os problemas encontrados no software
custam 100 a 1.000 vezes mais após a entrega do que nas fases iniciais. Os custos
gerados com erros e impactos negativos de mudança na fase Construção e
Transição são maiores que os custos gerados com erros de projeto e mudanças
suportadas durante o planejamento.
Isso justifica os investimentos feitos em projetos com planejamento,
protótipo inicial, levantamento de requisitos, e o desenvolvimento e teste da
arquitetura base.
A Figura 2 ilustra os custos de mudanças no software à medida que se
avançam as fases do processo de desenvolvimento (QUADROS, 2002).
Figura 2: Custo de mudanças no software. Fonte: (QUADROS, 2002).
O controle e gerenciamento de mudanças solucionam a maioria dos
problemas relacionados aos fracassos em projetos de software (MARTINS, 2007).
Independente das medidas adotadas é importante que as partes
envolvidas avaliem os riscos que as mudanças trarão, os documentem, avaliem a
abrangência e as consequências. Se as mudanças comprometerem o escopo
definido do projeto será preciso ajustar os artefatos concluídos e os recursos para
realizá-las (MARTINS, 2007).
19
2.3 RISCOS
O intuito em gerenciamento de risco é não consentir que ele se torne um
problema antes de ter uma rota para controlá-lo ou desviá-lo, definindo um plano de
contingência que considere os passos:
• fuga : reorganizar o projeto de forma que não seja afetado pelo risco;
• transferência : reorganizar de forma que alguém ou algo suporte o
risco;
• aceitação : aceitar e monitorar com o risco havendo possibilidade de
que aconteça ou não.
Um plano de contingência determina a ação necessária para
compreender se o risco tornou-se um problema atual e os caminhos possíveis para
controlá-lo (KRUCHTEN, 2003).
Os riscos de projeto podem ser definidos nas categorias:
• requisitos : analisa o retorno do investimento dos usuários e o retorno
financeiro a empresa de desenvolvimento;
• tecnológicos : verifica se as ferramentas utilizadas fornecerão o
suporte adequado ao desenvolvimento;
• habilidades : confere o potencial da equipe, constatando habilidades
suficientes para conduzir o projeto;
• políticos : considera probabilidade de interferência de forças alheias
que poderiam influenciar negativamente na viabilização do projeto
(QUADROS, 2002).
A necessidade de gerenciar riscos é expressa no princípio de Gilb (1998)
“Se você não atacar ativamente os riscos eles atacarão você ativamente”, portanto,
é preciso identificar, analisar e controlar os riscos de forma que eles não
surpreendam os envolvidos no projeto em nenhuma das fases.
20
2.4 DISCIPLINAS DE ELABORAÇÃO
Como a fase passa pelas disciplinas do RUP, ocorre o detalhamento dos
requisitos e artefatos levantados na fase de Iniciação. A seguir é analisada a fase
Elaboração em cada disciplina.
2.4.1 Modelagem de Negócio
Este fluxo define a compreensão da organização na qual o sistema será
implantado, certificando que os stakeholders tenham um entendimento comum e
único da estrutura da organização.
Na primeira iteração da fase de Iniciação, é analisada a situação atual da
organização na qual o sistema resultante será implantado, gerando os artefatos de
Caso de Uso de Negócio e um Modelo de Objeto de Negócios. Apoiando-se nesses
resultados será decidido sobre como prosseguir nas fases e iterações seguintes
(KRUCHTEN, 2003).
2.4.2 Requisitos
O intento dessa disciplina é estabelecer e manter acordo com todos
envolvidos no que o sistema deveria fazer e porque, delimitando e focalizando o
projeto, além de fornecer alicerce para o planejamento dos conteúdos técnicos para
construir as iterações seguintes (KRUCHTEN, 2003).
A ênfase durante a fase de Elaboração recai em compreender
precisamente o que o projeto fará nas atividades Definir e Refinar o escopo do
sistema.
De acordo com a metodologia RUP, em um projeto são considerados dois
tipos de requisitos, os funcionais e os não funcionais.
Os requisitos funcionais são usados para expressar o comportamento do
sistema especificando as condições esperadas de saída.
21
Visando satisfazer as necessidades de qualidade ao cliente, um sistema
deve exibir uma variedade de atributos que não são descritos pelos requisitos
funcionais, estes dizem respeito aos requisitos não funcionais, que podem ser:
• utilidade : condizem aos fatores humanos como estética, layout,
facilidade de aprendizado, documentações de manual e para treinamento;
• confiança : compõem frequência e severidade de fracasso,
recuperação e precisão dos dados;
• desempenho : impõem condições em requisitos funcionais, tais como:
velocidade, tempo de resposta, tempo de recuperação e, uso de memória;
• suporte : dizem respeito à preservação, a outras qualidades exigidas
para manter o software depois de sua implantação.
Com o conjunto de requisitos, é desenvolvido o Documento de Visão
contendo o conjunto fundamental de necessidades, focalizando nas características
essenciais e na solução encontrada para solucionar os problemas do cliente.
Manter o rastreamento dos requisitos é a chave para administrar
efetivamente a extensão do projeto e controlar futuras mudanças de requisitos
(KRUCHTEN, 2003).
2.4.3 Análise e Design
Este fluxo foca em transformar os requisitos em uma especificação que
descreva como implementar o sistema, elegendo a melhor estratégia para o
desenvolvimento, estabelecendo uma arquitetura robusta que seja de fácil
entendimento, manutenibilidade, evolução, e projetando-a para satisfazer questões
de desempenho, escalabilidade, testes esperados, desejados e propostos.
O projeto seria um esboço elaborado o suficiente para garantir aos
desenvolvedores produzir um conjunto de componentes que satisfaça os requisitos
para um protótipo inicial, validando a arquitetura (KRUCHTEN, 2003).
Na Figura 3, é apresentado o fluxo de Análise e Design na fase
Elaboração, no qual é realizada a atividade de Sugestão de Arquitetura, assim como
22
as atividades de Projetar Componentes e Projetar o Banco de Dados, cruciais
elementos de finalização de marco desta fase.
Figura 3: Fluxo de Análise e Design. Fonte: (IBM, 2006)
A atividade Projetar Componentes disponibiliza um conjunto de
componentes que fornecem o comportamento desejado para validar os requisitos. A
23
persistência é documentada e revisada em Projetar o Banco de Dados. A saída é um
conjunto de componentes para a disciplina de Implementação.
Na Figura 4 é apresentado o fluxo de Definir uma Sugestão de Arquitetura
com as atividades que a equipe terá que resolver, mostrando também os artefatos
de entrada com as informações necessárias para que o fluxo aconteça. Ao final, é
gerado o Documento de Arquitetura de Software, o Modelo de Design, as
Realizações dos Casos de Uso, o Modelo de Implantação, e as Classes de Análise
(IBM, 2006).
Figura 4: Detalhamento do Fluxo de Trabalho: Definir uma Sugestão de Arquitetura. Fonte: (IBM, 2006)
24
Este fluxo de trabalho é composto das atividades Análise Arquitetural e
Análise de Caso de Uso. Seu propósito é:
• criar um esboço inicial da arquitetura;
• identificar as classes de análise dos casos de uso arquiteturalmente
significantes;
• atualizar as realizações de caso de uso com as interações das classes
de análise.
O fluxo de análise e o projeto preenchem a lacuna entre os requisitos e a
codificação, utilizando casos de uso para identificar um conjunto de objetos que
posteriormente é refinado em classes, subsistemas e pacotes (KRUCHTEN, 2003).
2.4.4 Implementação
Responsável pela padronização do código fonte, implementar, testar e
integrar componentes.
O desenvolvimento de um protótipo na fase de Elaboração mostra um
pequeno executável ao cliente, aumentando a credibilidade e confiança do produto,
além de reduzir incertezas sobre:
• a viabilidade do negócio;
• a estabilidade ou desempenho da tecnologia;
• a compreensão dos requisitos; e
• o aspecto, layout e utilidade do produto.
O trabalho de estruturar o Modelo de Implementação é concluído na fase
de Elaboração, para isso realiza-se as seguintes atividades: Planejar a Integração,
Implementar os Componentes, Integrar cada Subsistema e Integrar o Sistema. O
propósito é assegurar que o modelo de Implementação seja organizado de tal modo
que produza componentes livres de conflitos e riscos (KRUCHTEN, 2003).
25
2.4.5 Teste
O fluxo de teste avalia a qualidade do produto como um todo. Na fase de
Elaboração, a qualidade é centrada na arquitetura do projeto.
De acordo com Kruchten (2003):
O termo qualidade significa a ausência de defeitos, ou mais importante que
é a aptidão para um propósito desejado, algo imbuído com qualidade faz o
que queremos que faça, e um processo pobre ou que não seja seguido
pode ser uma causa significante de qualidade pobre.
Esta disciplina não é só uma atividade de conclusão de ciclo de vida
esperada para aprovar ou rejeitar o componente ou o sistema desenvolvido, é uma
parte vital do mecanismo de avaliação ininterrupta do projeto (KRUCHTEN, 2003).
2.4.6 Implantação
Como cita IBM (2006), “implantar o software desenvolvido é pôr o produto
disponível ao usuário final. É o ápice do esforço do desenvolvimento de software”.
O planejamento da implantação envolve a preparação da documentação
ao cliente, a atividade Desenvolver Material de Suporte contém informações
suficientes para que o usuário final utilize e mantenha o sistema operando sem
problemas, além de liberar material de treinamento para o uso correto do sistema
implantado (IBM, 2006).
2.4.7 Gerenciamento de Configuração e Mudança
À medida que o produto é construído, os usuários idealizam novas
características que antes não eram percebidas. Com a utilização do produto
requisitos que antes eram desejáveis passam a ser necessários.
Como menciona Kruchten (2003), “a proposta da configuração e do fluxo
de gerenciamento de mudança é localizar e manter a integridade dos recursos de
evolução do projeto”.
26
O Plano de Gerenciamento de Configuração descreve os procedimentos
e políticas aplicadas para identificar, proteger e reportar todos os artefatos de projeto
gerados durante o ciclo de vida do projeto (KRUCHTEN, 2003).
2.4.8 Gerenciamento do Projeto
Fornece uma estrutura para gerenciar projetos e equilibrar os objetivos
concorrentes como: gerenciar riscos, gerenciar recursos, controlar gastos,
acompanhar cronograma, planejar e monitorar progresso das iterações.
Para a elaboração deve-se fazer um planejamento para cada iteração,
determinando quantas iterações, quanto tempo cada iteração uma terá e como serão
distribuídas as atividades/tarefas.
O planejamento de cada fase acontece uma vez por projeto, contendo o
objetivo, as pessoas capacitadas para exercer cada responsabilidade e as datas de
início e fim esperados e planejados.
O plano de iterações é um plano mais detalhado, sendo usado para
delimitar as tarefas e sua distribuição aos indivíduos e equipe. Contém os critérios
de sucesso da iteração e as datas de duração prevista de cada atividade.
Durante esse fluxo acontece a avaliação dos riscos e o conceito de
medida do projeto, mensurando o tamanho para controlá-lo.
No início da Elaboração é criado um Plano de Projeto, com o intuito de
obter compreensão sobre os riscos e o refinamento dos requisitos. O Gerente de
Projeto e o Arquiteto de Software decidem quais requisitos devem ser atendidos,
permitindo que o trabalho possa continuar com uma Lista de Riscos e assim prover
uma base consistente para aperfeiçoar o Plano de Projeto.
É inicializado um Plano de Iteração dentro do Plano de Projeto que
determinará se os objetivos da iteração foram alcançados. A Revisão da Aceitação
da Iteração decide se o projeto deve ser cancelado, ou se pode dar continuidade.
Permitindo ao gerenciamento de projeto e a outros envolvidos a oportunidade de
corrigir problemas durante o curso.
27
Em paralelo com o gerenciamento da Iteração, as tarefas cotidianas do
gerenciamento de projeto são realizadas, acompanhando o status do projeto e
resolvendo problemas conforme aparecem (IBM, 2006).
2.4.9 Ambiente
O propósito é suportar a organização de desenvolvimento atual com
processos e ferramentas que acompanhem o desenvolvimento até sua conclusão.
Para isso se faz necessário:
• selecionar a ferramenta de desenvolvimento e/ou aquisição;
• ter ferramentas de configuração;
• configurar o processo e/ou melhorar o processo existente;
• conferir serviços técnicos para suportar o processo, como infraestrutura
e backup.
O principal artefato desse fluxo é o Caso de Desenvolvimento, no qual é
especificado e configurado o processo apropriado ao projeto, ou seja, o responsável
pela configuração do RUP (KRUCHTEN, 2003).
2.5 MARCO DE CONCLUSÃO
O marco da fase é o ponto onde se define sua finalização. O marco da
fase Elaboração é o artefato Definição da Arquitetura Candidata, que elimina os
elementos de maior risco do projeto pela criação de uma arquitetura coerente e
consistente da solução, visto que a partir deste ponto a equipe está madura em
relação à base do projeto (MARTINS, 2007).
Para a conclusão da fase Elaboração têm-se as seguintes questões:
• a visão do produto e os requisitos estão estáveis e documentados?
• a arquitetura está estável?
28
• os riscos foram abordados e estão sendo mitigados?
• a demonstração executável mostrou que os elementos de maior risco
foram abordados satisfatoriamente?
• todos os stakeholders concordam quanto à coerência entre os
documentos?
• os custos planejados e executados estão aceitáveis?
Se esses critérios forem considerados satisfatórios é encerrada a fase de
Elaboração e o segundo marco, o LCA é alcançado e os seguintes resultados
devem ser apresentados:
• um modelo de caso de uso, e um caso de uso praticamente pronto com
uma descrição completa dos atores e cenários de uso;
• descrição da arquitetura do software;
• um protótipo executável do software, se este foi desenvolvido;
• cronograma detalhado de evolução do projeto, incluindo as iterações
necessárias e os critérios de avaliação para cada iteração;
• revisão da visão de negócios e lista de riscos (KRUCHTEN, 2003).
Na Figura 5 é possível analisar as tarefas que são necessárias para a
finalização do marco da fase Elaboração do RUP, como também verificar os
artefatos de saída gerados após a conclusão da definição do projeto de arquitetura.
29
Figura 5: Projetar Arquitetura. Fonte: (IBM, 2006)
2.6 ARQUITETURA
No RUP, a arquitetura de um sistema de software é a organização ou a
seleção de elementos estruturais significativos e as interfaces das quais o sistema é
composto, junto com seu comportamento.
A arquitetura não está relacionada somente com estrutura e
comportamento, como também avalia aspectos fundamentais como: funcionalidade,
desempenho, elasticidade, reutilização, manutenibilidade, compreensão, restrições e
intercâmbios tecnológicos e econômicos, e estéticos (KRUCHTEN, 2003).
O RUP usa a Unified Modeling Language (UML) para descrever e
exemplificar como a arquitetura foi produzida, defendendo o uso de uma de suas
melhores práticas, denominada “modelar visualmente o software”. Como Kruchten
(2003) relata, “modelos nos ajudam a entender e moldar o problema e sua solução”.
A modelagem da arquitetura é expressa por meio de diagramas que são
agrupados em visões que permitem aos stakeholders comunicar, discutir e
argumentar sobre os fatores que interessam a cada um (KRUCHTEN, 2003).
30
Cada visão aborda um determinado conjunto de aspectos específicos dos
envolvidos no processo de desenvolvimento. O RUP sugere um modelo para essas
visões, chamado Modelo de Visão 4 + 1. Esse modelo descreve cinco visões
concorrentes que são apresentadas de modo que cada uma endereça um conjunto
diferente de preocupações, e de interesse a diferentes stakeholders.
O modelo 4 + 1 é composto pelas seguintes visões:
•••• Caso de Uso (Scenarios): representam as exigências mais
significantes do projeto. É expressa por meio de casos de uso, que
mapeiam o relacionamento de todas as visões.
•••• Lógica ( Logical View): voltada em suprir as exigências funcionais que
o sistema deve atender. Essa visão intermédia a comunicação entre o
arquiteto e o cliente, por esse motivo ,é destinada aos usuários finais.
•••• Implementação ( Development View): estrutura o desenvolvimento
do sistema em termos de organização em módulos estáticos de pacotes e
camadas no ambiente de desenvolvimento. É utilizada para distribuir o
trabalho de implementação e manutenção do sistema entre as pessoas
que constituem a equipe de desenvolvimento.
•••• Processo ( Process View): engloba os aspectos de concorrência e
sincronização do sistema, como também suas interações como a
inicialização e finalização. Está centrada nos requisitos não-funcionais do
sistema.
•••• Implantação ( Physical View): Descreve a organização estática do
software no ambiente de desenvolvimento. Direciona os assuntos de
desenvolvimento, instalação e desempenho. Essa visão é utilizada
quando o sistema for distribuído. Ela é um subconjunto do modelo de
implantação.
A Figura 6 ilustra o modelo da arquitetura 4+1.
31
Figura 6: Modelo 4 + 1. Fonte: (KRUCHTEN, 1995)
Embora as visões descritas no modelo 4 + 1 representam todo o design e
estrutura de um sistema, a arquitetura se preocupa com aspectos específicos, tais
como:
•••• a estrutura do modelo, os padrões organizacionais, por exemplo, a
divisão em camadas;
•••• os elementos essenciais, os casos de uso de maiores riscos, as
classes principais, os principais fluxos de controle do sistema;
•••• os serviços para definir a modularidade, os recursos considerados
opcionais, os aspectos do produto.
Segundo a IBM (2006), as visões de arquitetura se referem à abstrações,
em que as características fundamentais são destacadas, ignorando os detalhes.
Essas características são importantes quando forem avaliados os aspectos:
•••• evolução do sistema, a fim de melhorá-lo, geralmente essas melhorias
são realizadas gradualmente;.
32
•••• reutilização da arquitetura em produtos similares;
•••• avaliação das qualidades não funcionais, como desempenho,
portabilidade e segurança;
•••• inclusão de componentes desenvolvidos internamente e/ou adquiridos
de terceiros;
•••• desenvolvimento de um sistema de maior complexidade.
No RUP, a arquitetura é basicamente o resultado do fluxo Análise e
Design. Como cada iteração inclui a integração e o teste, a arquitetura é refinada e
aprimorada ao longo do tempo e à medida que o produto é liberado (IBM, 2006).
33
3 DESENVOLVIMENTO DO TRABALHO
Este capítulo descreve os passos aplicados no estudo de caso direcionado a
obter os resultados para definir a arquitetura base e os artefatos principais da fase
de Elaboração de um projeto de desenvolvimento de um website seguindo a
metodologia RUP.
3.1 ESTUDO DE CASO
Este estudo de caso apresenta uma solução de uma base arquitetural
fruto da fase da Elaboração do RUP sobre o desenvolvimento de um módulo
administrativo de um website usando a tecnologia LINQ, ainda não utilizada pela
equipe do projeto, empregando a UML para modelagem, linguagem de programação
C# e banco de dados SQL Server 2005.
A solução para esse website consiste em dois projetos:
•••• módulo administrativo: responsável por gerenciar o conteúdo do
website, cujo desenvolvimento arquitetural será descrito neste trabalho;
•••• páginas de acesso público : responsável por apresentar o conteúdo
de forma interativa e dinâmica, alimentado pelo módulo administrativo.
Esse projeto não está incluso no escopo da base arquitetural deste
trabalho.
3.1.1 Fase Iniciação
O levantamento de requisitos foi obtido no fluxo de trabalho Requisitos. A
partir de então foi elaborado o caso de uso de negócio e o documento Requisitos de
Software, encontrado no apêndice A, que consiste em uma descrição do software,
identificando requisitos funcionais e não funcionais, além dos atores e uma
descrição para cada um.
34
3.1.2 Fase Elaboração:
Após finalizado o levantamento de requisitos pôde-se iniciar a fase de
elaboração. Nessa fase foi analisada a tecnologia LINQ com a construção dos
primeiros casos de uso, apesar de a implementação não ser do escopo da Iteração,
mas foi necessária para a prova de conceito e minimização de riscos.
• Requisitos
No documento Plano de Iteração, elaborado na disciplina Gerenciamento
de Projeto foi decidido que os casos de uso implementados para esta fase seriam:
Efetuar Login e Logout; Inserir Log; Consultar log e Gerenciar Usuários. Foram feitas
Especificações de Casos de Uso, identificando cenários, na finalidade de entender o
que cada caso de uso iria proporcionar. O Apêndice E, apresenta a Especificação do
Caso de Uso Gerenciar Usuários.
• Análise e Design
Com os requisitos coletados foi possível esboçar o Diagrama de Caso de
Uso para representar as funcionalidades obtidas em conjunto com os atores que irão
interagir com elas. A Figura 7 mostra este diagrama revisado e finalizado.
35
Aplicação
(from Actors)
Inserir Log
(from Inserir Log)
A aplicação Insere Log para toda ação ocorrida .
Gerenciar Cases
(from Gerenciar Ca...
Gerenciar dados sobre a Equipe
(from Gerenciar dados sobre a Equ...
Gerenciar Depoimento de Clientes
(from Gerenciar Depoimento de Clien...
Gerenciar Notícias
(from Gerenciar Notic...
Ef etuar Login e Logout
(from Efetuar Login e Log...
Desenv olv edor de Conteúdo Web
(from Actors)
Gerenciar Upload de Arquiv os
(from Gerenciar Upload de Arqui...
Consultar logs
(from Consultar l...
Administrador
(from Actors)
Gerenciar Usuários
(from Gerenciar Usuár...
<<extend>> <<extend>>
<<extend>> <<extend>>
Figura 7: Diagrama de Caso de Uso
Em seguida, foi projetado o diagrama de classe, conforme a Figura 8, e
diagramas navegacionais para uma melhor compreensão das funcionalidades.
Nesta atividade seguindo a metodologia, elaborou-se o Documento de Arquitetura
de Software apresentando uma visão geral da arquitetura a ser empregada na
aplicação e que utiliza visões arquiteturais diferentes para ilustrar os diversos
aspectos do sistema e os padrões a serem seguidos na implementação. Esse
documento encontra-se no Apêndice B.
36
Noticia
idtitulopeqDescricaolongaDescricaoarquiv os : Arquiv odataPublicacaourlLink
(from RGerenciar Notícias)
DepoCliente
idnomeClientenomeFuncdescClientedepoimentoarquiv os : Arquiv ocargoFuncpathLogo
(from RGerenciar Depoimento de Clientes)
Funcionario
idnomecargodescricaoareasInteressearquiv os : Arquiv of uncoespathFotourlLinktituloLinkativ o
(from RGerenciar dados sobre a Equipe)
Arquiv o
idtipopathPadraotituloobserv acaopathMiniaturaposicaoListagem
(from RGerenciar Upload de Arquivo)
1
0..n
1
0..n 1
0..n
1
0..n
Case
idnomeclientepeqDescClienteproblemasolucaoresultadodepoimentoClientetecnologiasf uncionarios : Funcionarioarquiv os : Arquiv opathImagempathMiniaturapeqDescCaselinkCasedataCase
(from RGerenciar Cases)
1
1..n
1
1..n
1
0..n
1
0..n
Log
IdLogCodEv entoCategoriaDataHoraMensagemIp
(from RLog)
Usuario
idnomesobrenomedataNascemailtipoUsuloginsenhapathFoto
(from RGerenciar Usuários)
0..*
1
0..*
1
Figura 8 Diagrama de Classes
Para a representação dos diagramas navegacionais, usou-se Web
Application Extension (WAE), uma extensão para a UML permitindo representar
páginas web e outros elementos significativos do ponto de vista arquitetônico. A
Figura 9 ilustra elementos da WAE, o <Server Page>, <Client Page> e <HTML
Form> respectivamente.
Figura 9: Ícones dos elementos da WAE
O <Server Page> representa a abstração lógica de uma página web visto
37
pelo servidor. O <Client Page> representa uma página no cliente, com os elementos
<html> </html> e o <HTML Form> representa um formulário em uma <Client Page>.
A Figura 10 ilustra o Diagrama Navegacional de Gerenciar Usuários que
faz uso destes estereótipos.
• Implementação
Nesta disciplina iniciou-se a construção do projeto da Graphical User
Interface (GUI), as funcionalidades da Master Page e a construção dos casos de
usos escolhidos.
Primeiramente foi configurada a base de dados com as tabelas e campos
necessários para execução dos casos de uso desta iteração. Depois de identificados
os dados com seus tipos pelo diagrama de classes, foi possível definir o modelo
físico do banco de dados implementado com o SQL Server 2005 onde foram
acrescentados as tabelas e os campos necessários para o projeto, para então serem
mapeados para o DataContext. O DataContext é o objeto responsável pelo acesso
ao banco de dados em LINQ. O modelo físico é apresentado na Figura 11, e o
design do DataContext com o banco mapeado para o LINQ é apresentado na Figura
12.
38
Regra{C#}<<layer>>
(from Business Services)
UsuarioPessoal.aspx_Client(from UsuarioPessoal.aspx)
Form
<<HTML Input>> btnSalvar : button(from UsuarioPessoal.aspx_Client)...)
UsuarioPessoal.aspx
<<Build>>
<<Submit>>
UsuarioGer.aspx_Client(from UsuarioGer.aspx)
Form
<<HTML Input>> btnAlterar : button<<HTML Input>> btnExcluir : button
(from UsuarioGer.aspx_Client)
Default.aspx(from WUI {ASP.NET})
<<link>>
UsuarioDados.aspx_Client(from UsuarioDados.aspx)
Form
<<HTML Input>> btnSalvar : button(from UsuarioDados.aspx_Client)
UsuarioGer.aspx
<<link>>
<<Build>><<Submit>>
UsuarioDados.aspx
<<link>>
<<Build>>
<<Submit>>
{parametro= idUsuario}<<Link>>
<<Redirect>>
Figura 10: Diagrama Navegacional - Gerenciar Usuários
39
Figura 11: Modelo físico do banco de dados
40
Figura 12: Design do DataContext
Em seguida foi projetada a Master Page, uma página default
contendo menus, cabeçalhos e rodapés servindo como base para o design e
permitindo compartilhar métodos que todas as outras páginas utilizarão.
Depois de concluída a configuração da Master Page foi possível
começar a implementar o primeiro caso de uso, Login e Logout. Em seguida
foram implementados os casos de uso Inserir Log e Consultar Log, e para
encerrar a fase foi desenvolvido o caso de uso Gerenciar Usuário.
41
• Teste
Para avaliar os métodos desenvolvidos com LINQ foram realizados
testes unitários e Web Test. Nos testes unitários foram avaliados os métodos
individuais da tecnologia para observar se eles se comportavam da maneira
esperada. Nos Web Test foi avaliado o desempenho da aplicação no ambiente
web.
• Gerenciamento de Configuração e Mudança
O Plano de Gerenciamento de Configuração desenvolvido determina
e assegura a integridade de códigos-fonte e demais artefatos produzidos,
preservando o histórico de evolução e mudança, caso necessário.
• Gerenciamento de Projeto
O primeiro artefato desta fase foi o Plano de Projeto definindo o
cronograma de execução das fases (Apêndice C), os recursos necessários, a
Análise de Riscos e o Plano de Teste e Qualidade. Em seguida foi elaborado o
Plano de Iteração, que conduz a iteração e contém os casos de uso a serem
implementados (Apêndice D). Depois de concluídos os testes realizou-se um
Plano de Avaliação da Iteração, com intuito de capturar o resultado da iteração,
o grau de cumprimento dos critérios de avaliação, as lições aprendidas, as
possíveis mudanças, e medir o sucesso da iteração.
A fase de Elaboração é encerrada com sua meta atingida, pois com
os testes aplicados, uma arquitetura definida e executável e com os primeiros
casos de uso implementados com sucesso na tecnologia LINQ foi possível
finalizar a iteração.
• Ambiente
Os recursos de hardware utilizados são definidos nos itens a seguir:
•••• Processador Intel Pentium IV 2.8 Ghz;
42
•••• Memória RAM 2 GB;
•••• Disco rígido 80 GB.
Além dos recursos de hardware, foram utilizados recursos de software
para a execução das atividades, sendo relacionados abaixo:
•••• Microsoft Team Foundation Server: ferramenta integrada ao
Visual Studio que colabora nas atividades da equipe, centralizando
os dados envolvidos no projeto, tais como: códigos, figuras,
processo e artefatos;
•••• IBM Rational Rose Enterprise Edition: ferramenta utilizada para
modelagem de diagramas da WAE;
•••• Microsoft Internet Explorer 8.0, Mozilla Firefox 3. 0 e Google
Chrome: navegadores utilizados para realização de testes;
•••• Sql Server 2005 Management Studio: utilizado para configurar e
gerenciar a implantação do banco de dados do sistema na web.
43
4 CONCLUSÕES
Gerenciar a manutenibilidade e complexidade de sistemas se tornou
preocupante nas organizações que desenvolvem software.
Contudo, é cada vez mais freqüente a concentração do foco das
organizações nas suas atividades principais. Para garantir o sucesso do
software e fazer com que este atenda as expectativas dos usuários é
fundamental a existência de uma gerência eficiente que seja capaz de controlar
e manter o projeto.
O modelo 4+1 simplifica a complexidade de grandes sistemas, uma
vez que a divide em partes, ou módulos, separando em visões específicas.
O processo de desenvolvimento em conjunto com a modelagem, o
acompanhamento dos riscos, o plano de projeto, e o plano de iteração são
extremamente úteis para medir a evolução do projeto e a realizar eventuais
adaptações ou mudanças dentro do desenvolvimento para o cumprimento dos
objetivos do sistema.
Desenvolvimento rápido e eficiente de software é fundamental, pois
se tem clientes cada vez mais exigentes com relação a prazos e à qualidade.
Se houver um modo de reduzir o tempo de desenvolvimento pela metade, isso
se caracterizará em um benefício tanto para a empresa de desenvolvimento
quanto para seus clientes, gerando lucro e satisfação.
Esta monografia e o estudo de caso alcançaram resultados
positivos. Foram gerados documentos necessários à especificação do módulo
proposto, e alguns foram disponibilizados nos apêndices para
acompanhamento.
A utilização do RUP foi completada com êxito, pois não foram
encontradas dificuldades no manuseio e na compreensão da metodologia. O
estudo sobre os conceitos da fase de Elaboração foi realizado conforme
descrito no capítulo 2, permanecendo a continuação dos estudos para
consolidar o ensino obtido e possibilitar a melhora contínua na aplicação nos
44
próximos projetos, a fim de aproveitar melhor os recursos oferecidos.
Como trabalho futuro pode-se aplicar o conhecimento adquirido em
projetos do dia a dia, ensinando sobre a eficácia de projetos planejados
antecipadamente, principalmente na análise dos riscos e na elaboração da
arquitetura base que suportará o projeto em toda sua extensão, evitando
retrabalho, fracassos e frustrações tanto para a organização como para seus
clientes.
45
REFERÊNCIAS
CONALLEN, Jim. Desenvolvendo aplicações Web com UML . 2. ed. Rio de
Janeiro: Campus, 2003.
GILB, Ton. Principles of Software Engineering Management , Wokingham,
England, Addison Wesley, 1988.
IBM. RUP – Rational Unified Process (Software) Versão 7.0. USA: IBM
Rational, 2006.
JACOBSON, Ivan.; BOOCH, Grady.; RUMBAUGH, James. The Unified
Software Development Process . 1.ed. United States of America: Addison-
Wesley, 1999.
KENDALL, Scott. O Processo Unificado (RUP) Explicado . Porto Alegre:
Bookman, 2004.
KROLL, Per. KRUCHTEN Phillippe. “The Rational Unified Process Made
Easy: A Practitioner ' s Guide to the RUP ” , Addison Wesley, 2003.
KRUCHTEN, Philippe. Introdução ao RUP - Rational Unified Process. 2ª ed.,
Rio de Janeiro: Ciência Moderna Ltda. 2003.
KRUCHTEN, Philippe. Architectural Blueprints. The “4+1” View Model of
Software Architecture , IEEE Software 12 (6), pp.42-50, 1995.
LIMA, Rafael. Desenvolvimento de Software. Disponível em
<http://www.slideshare.net/rafael_lima/desenvolvimento-de-software> Acesso
em 20/02/2011.
LUZ, Luiz. From Business Architecture to Software Architecture . Disponível
em: <http://homepages.dcc.ufmg.br/~clarindo/arquivos/disciplinas/uml-
mpn/material/transparencias/12-arquitetura-negocio-software.pdf> Acesso em:
10/09/2010.
MARTINS, José Carlos Cordeiro. Gerenciando Projetos de Desenvolvimento
de Software, com PMI, RUP e UML , Quarta Edição, Rio de Janeiro, Brasport,
2007.
46
QUADROS, Moacir. Gerência de Projetos de Software Técnicas e
Ferramentas . Florianópolis: Visual Books, 2002.
SEI. Celebrating Watts Humphrey 1927 - 2010 2011. Disponível em
<http://www.sei.cmu.edu/watts/index.cfm> Acesso em 15/04/2011.
SILVA FILHO, Antônio M. Análise da Arquitetura de Software , Engenharia de
Software Magazine p 50 a 56, Ano 2 - 14ª ed, 2009.
VILELA LUIZ, Ronaldo R. Obtendo Qualidade de Software com o RUP.
Disponível em: <http://javafree.uol.com.br/artigo/871455/Obtendo-Qualidade-
de-Software-com-o-RUP.html> Acesso em: 23/07/2010.}
47
APÊNDICE A – REQUISITOS DE SOFTWARE
48
APÊNDICE B – DOCUMENTO DE ARQUITETURA DE SOFTWARE
49
APÊNDICE C – PLANO DE PROJETO
50
APÊNDICE D – PLANO DE ITERAÇÃO
51
APÊNDICE E – ESPECIFICAÇÃO DE CASO DE USO GERENCIAR
USUÁRIOS