curso de tecnologia em anÁlise e desenvolvimento de...
TRANSCRIPT
CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
DIEGO DE CARVALHO MAIA
FABRÍCIO ARAÚJO PEREIRA LIMA
PRESTADORES: O APLICATIVO QUE ENCONTRA
PROFISSIONAIS DE FORMA SIMPLES E RÁPIDA
Brasília - DF
2015
DIEGO DE CARVALHO MAIA
FABRÍCIO ARAÚJO PEREIRA LIMA
PRESTADORES: O APLICATIVO QUE ENCONTRA
PROFISSIONAIS DE FORMA SIMPLES E RÁPIDA
Trabalho de Conclusão de Curso
apresentado às Faculdades Integradas
Promove de Brasília como requisito
parcial para obtenção do título de
tecnólogo em Análise e Desenvolvimento
de Sistemas.
Orientador: Prof. Osman Lira Junior
Brasília - DF
2015
DIEGO DE CARVALHO MAIA
FABRÍCIO ARAÚJO PEREIRA LIMA
PRESTADORES: O APLICATIVO QUE ENCONTRA
PROFISSIONAIS DE FORMA SIMPLES E RÁPIDA
Trabalho de Conclusão de Curso apresentado às Faculdades Integradas Promove
de Brasília como requisito parcial para a obtenção do título de tecnólogo em Análise
e Desenvolvimento de Sistemas.
Aprovado em ___/___/______
_______________________________________
Orientador Prof. e Mestre Osman Lira Junior
Faculdades Integradas Promove
_______________________________________
Prof. e Mestre. Hamilton Iwamoto da Silva
Faculdades Integradas Promove
_______________________________________
Profª. Dra. Maria José de Oliveira
Faculdades Integradas Promove
Brasília
2015
A Deus, qυе sе mostrou Criador, qυе foi
criativo. Sеυ fôlego dе vida nos sustentou
e nos deu coragem para questionar
realidades е propor sempre υm novo
mundo dе possibilidades.
AGRADECIMENTOS
A Deus por ter nos dado saúde е força para superar as dificuldades.
Ao professor Osman Lira e doutora Maria José, pela orientação, apoio е confiança.
Aos nossos familiares, pelo amor, incentivo е apoio incondicional.
A todos qυе direta оυ indiretamente fizeram parte da nossa formação, o nosso muito
obrigado.
RESUMO
Objetivo: Desenvolver um software com o objetivo de facilitar a comunicação entre o cliente e o prestador de serviços, de maneira prática, rápida e eficiente. Métodos: Pesquisas na internet para conhecer os poucos aplicativos voltados para essa área, levantamento de requisitos com prestadores de serviços e pessoas que gostaram da ideia contratariam algum tipo de serviço através de um aplicativo. Resultados: Foi obtido um software e toda sua documentação, reunindo as informações necessárias para ser um diferencial na área de prestação de serviços. Conclusões: O objetivo foi alcançado de maneira satisfatória, com uma grande perspectiva de visão e crescimento, tendo em mente várias expansões que o aplicativo pode proporcionar.
Palavras-chave: desenvolver; software; comunicação; aplicativo; documentação; perspectiva; expansão;
ABSTRACT
Objective: To develop a software in order to facilitate communication between the client and the service provider, in a practical , fast and efficient way . Methods: Searches in the internet to know the few applications focused on this area , requirements gathering with service providers and people who liked the idea would hire some kind of service through an application. Results: A software and all its documentation was obtained by gathering the information necessary to be a differential in the area of service delivery. Conclusions: The objective was achieved satisfactorily , with a big picture vision and growth, keeping in mind several expansions that the application can provide.
Keywords: develop; software; communication; app; documentation; perspective; expansion;
LISTA DE ILUSTRAÇÕES
Figura 1: Programação Orientada a Objetos ............................................................. 17
Figura 2: Representação de um ator ......................................................................... 19
Figura 3: Diagrama de Classe ................................................................................... 20
Figura 4: Fases do RUP ........................................................................................ 23
Figura 5: Diagrama de Casos de Uso geral............................................................ 38
Figura 6: Diagrama de Casos de Uso manter Usuário ............................................ 38
Figura 7: Diagrama de Casos de Uso manter serviço ............................................. 40
LISTA DE QUADROS
Quadro 1: Descrição do Problema ............................................................................ 29
Quadro 2: Sentença de Posição do Produto ............................................................. 29
Quadro 3: Resumo dos Envolvidos ........................................................................... 31
Quadro 4: Resumo dos Clientes ............................................................................ 31
Quadro 5: Prestador de Serviços ........................................................................... 32
Quadro 6: Usuários ............................................................................................... 32
Quadro 7: Necessidades dos Envolvidos ou dos Clientes ...................................... 33
Quadro 8: Quadro de Especificação do Requisito ER aF.001 .................................. 34
Quadro 9: Quadro de Especificação do Requisito ER aD.001 .................................. 34
Quadro 10: Quadro de Especificação do Requisito ER aF. 002................................ 35
Quadro 11: Quadro de Especificação do Requisito ER aD. 002 ............................. 35
Quadro 12: Quadro de Especificação do Requisito ER aF.003 ............................... 35
Quadro 13: Quadro de Especificação do Requisito ER aD.003 .............................. 36
Quadro 14: Quadro de Especificação do Requisito ER aF.004 ............................... 36
Quadro 15: Quadro de Especificação do Requisito ER aD.004 .............................. 36
Quadro 16: Fluxo de Eventos do manter membro .................................................. 39
LISTA DE ABREVIATURAS
BD – Banco de Dados
ER- Entidade e Relacionamento
WEB – Rede de comunicação
SQL – Structured Query Language
URL – Uniform Resource Locators
RUP – Rational Unified Process
UML - Unified Modeling Language
SUMÁRIO
INTRODUÇÃO .......................................................................................................... 14
1 APRESENTAÇÃO ............................................................................................. 15
1.1 JUSTIFICATIVA ................................................................................................. 15
1.2 OBJETIVO ........................................................................................................... 15
1.2.1 Objetivo Geral .................................................................................................. 15
1.2.2 Objetivos específicos........................................................................................ 16
2 REFERENCIAL TEÓRICO ..................................................................................... 16
2.1 PROGRAMAÇÃO ORIENTADA A OBJETOS ................................................... 16
2. 2 INTRODUÇÃO ................................................................................................... 16
2. 3 DEFINIÇÕES ..................................................................................................... 17
2.3.1 Objeto ............................................................................................................... 17
2.3.2 Atributos ........................................................................................................... 17
2.3.3 Polimorfismo ..................................................................................................... 18
2.3.4 Herança ............................................................................................................ 18
2. 4 UNIFIED MODELING LANGUAGE (UML) ......................................................... 18
2.4.1 Diagrama de casos de uso ............................................................................... 18
2.4.2 Caso de uso ..................................................................................................... 19
2.4.3 Ator ................................................................................................................... 19
2.4.4 Diagrama de classe .......................................................................................... 20
2.4.5 Classe .............................................................................................................. 20
2.4.6 Atributos ........................................................................................................... 21
2.4.7 Operações ........................................................................................................ 21
2.4.8 Herança ............................................................................................................ 21
2.4.9 Associações ..................................................................................................... 21
2.4.10 Agregação ...................................................................................................... 22
2.4.11 Diagramas de Sequência ............................................................................... 22
2.5 RATIONAL UNIFIED PROCESS - RUP .............................................................. 22
2.5.1 Fase de Concepção / Iniciação ......................................................................... 23
2.5.2 Fase de Elaboração .......................................................................................... 24
2.5.3 Fase de Construção .......................................................................................... 24
2.5.4 Fase de Transição ............................................................................................ 24
2.6 FERRAMENTAS UTILIZADAS ............................................................................ 25
2.6.1 Hypertext Preprocessor (PHP) ......................................................................... 25
2.6.2 HTML ................................................................................................................ 25
2.6.3 Angular JS ........................................................................................................ 26
2.6.4 MySQL .............................................................................................................. 26
2.6.5 Apache Cordova ............................................................................................... 26
2.6.6 Java Script ........................................................................................................ 27
3 ANÁLISE E DOCUMENTAÇÃO DO SISTEMA ..................................................... 27
3.1 INTRODUÇÃO .................................................................................................... 27
3.1.1 Finalidade ......................................................................................................... 27
3.1.2 Escopo do documento ...................................................................................... 27
3.1.3 Visão Geral ....................................................................................................... 28
3.2 POSICIONAMENTO ........................................................................................... 28
3.2.1 Descrição da Empresa ...................................................................................... 28
3.2.2 Oportunidade de Negócios ............................................................................... 28
3.2.3 Descrição do Problema ..................................................................................... 29
3.2.4 Sentença de Posição do Produto ..................................................................... 29
3.2.5 Escopo do Produto ........................................................................................... 30
3.3 DESCRIÇÕES DOS ENVOLVIDOS E DOS CLIENTES ..................................... 30
3.3.1 Demografias do Mercado .................................................................................. 30
3.3.2 Resumo dos Envolvidos ................................................................................... 31
3.3.3 Resumo dos Clientes ........................................................................................ 31
3.3.4 Ambiente dos Clientes ...................................................................................... 31
3.3.5 Perfis dos Envolvidos ........................................................................................ 32
3.3.5.1 Prestador de Serviços .................................................................................... 32
3.3.5.2 Usuários ......................................................................................................... 32
3.3.5.3 Principais Necessidades dos Envolvidos ou dos Clientes ............................. 33
3.3.5.4 Alternativas e Concorrência ........................................................................... 33
3.3.6 Restrições ......................................................................................................... 33
3.4 ESPECIFICAÇÕES DE REQUISITOS ................................................................ 34
3.4.1 ERaFPR.001 ..................................................................................................... 34
3.4.2 ER aDPR.001 ................................................................................................... 34
3.4.3 ER aFPR.002 .................................................................................................... 35
3.4.4 ER aDPR.002 ................................................................................................... 35
3.4.5 R aFPR.003 ...................................................................................................... 35
3.4.6 ER aDPR.003 ................................................................................................... 36
3.4.7 ERaFPR.004 ..................................................................................................... 36
3.4.8 ERaDPR.004 .................................................................................................... 36
4 DESCRIÇÕES DOS CASOS DE USO E ATORES................................................. 37
4.1 CASOS DE USO ................................................................................................. 37
4.2 DESCRIÇÕES DOS ATORES ............................................................................. 37
4.2.1 Administrador do Sistema ................................................................................. 37
4.2.2 Prestador de Serviço ........................................................................................ 37
4.2.3 Usuário ............................................................................................................. 37
4.3 DIAGRAMA GERAL DE CASO DE USO ............................................................. 38
4.4 DETALHAMENTO DOS CASOS DE USO ........................................................... 38
4.4.1 UC 001 – Manter Usuário .................................................................................. 38
4.4.2 UC 002 – Manter Serviço .................................................................................. 40
4.5 DIAGRAMA DE CLASSE ................................................................................... 43
4.6 DIAGRAMA DE SEQUÊNCIA ............................................................................. 44
4.6.1 Diagrama de sequência autenticação ............................................................... 44
4.6.2 Diagrama de sequência manter usuário ........................................................... 44
4.6.3 Diagrama de sequência manter serviço ............................................................ 45
CONCLUSÃO ........................................................................................................... 46
REFERÊNCIAS ......................................................................................................... 47
14
INTRODUÇÃO
Para um mundo avançado em que o tempo é muito valorizado pelas pessoas,
é praticamente impossível pensar em não recorrer à tecnologia para resolver as
mais variadas questões cotidianas, seja para comunicação, trabalho, localização ou
solicitar serviços.
Segundo uma pesquisa realizada pela Nielsen Analytics, os aplicativos de
utilidade e produtividade cresceram cerca de 150% no último ano. É exatamente
isso que os adeptos de smatphones estão em busca: facilidade e praticidade.
Enquanto o consumidor tem sede pelo que é novo, o empreendedor tem a
vontade de inovar e mostrar opções que se destaquem em meio a dezenas de
outros projetos que aparecem todos os dias.
O objetivo da elaboração deste trabalho é expor o passo a passo do
desenvolvimento do software Prestadores, que será desenvolvido no primeiro
momento para usuários de Brasília e, futuramente será disponibilizado para os
demais estados do Brasil.
Os Prestadores é um software independente, não possui vínculo com
nenhuma empresa. Neste trabalho contém assuntos referentes ao aplicativo mobile
Prestadores,
Será apresentada a regra de negócio e as informações levantadas durante o
processo de análise, planejamento do sistema, diagramas, requisitos e descrições
do projeto.
15
1 APRESENTAÇÃO
1.1 JUSTIFICATIVA
Encontrar um pedreiro, encanador, faxineiro não é tarefa fácil hoje em dia. O
software Prestadores chega com a proposta de resolver esse problema, facilitando a
procura por profissionais qualificados que atendam em domicilio, inovando no
seguimento de prestação de serviços.
Atualmente as pessoas quando necessitam de um serviço procuram em
jornais, revistas ou anúncios na internet. Nestes anúncios não é possível avaliar a
qualidade do serviço oferecido, retornando resultados vazios ou até mesmo de má
qualidade quando esses serviços são realizados.
O objetivo ao desenvolver esse software é facilitar o encontro entre o usuário
e o prestador de serviço, através de cadastros realizados por ambas as partes. Ao
término de cada serviço realizado, o cliente terá a opção de avaliar o prestador de
serviço como um todo. Essa avaliação será utilizada para a criação da reputação do
prestador de serviço.
Além da resolução do problema e da facilidade em encontrar um bom serviço,
o software Prestadores terá ainda mais agilidade trabalhando com o seguimento
mobile.
1.2 OBJETIVO
1.2.1 Objetivo Geral
Desenvolver um software para gerenciamento de informações de prestação
de serviços em diversas áreas, utilizando a praticidade mobile para facilitar o
encontro entre o usuário e prestador de serviços.
16
1.2.2 Objetivos Específicos
Produzir a documentação do sistema.
Criar um processo de gerenciamento de cadastro de prestadores de serviços.
Criar um processo de gerenciamento de cadastro de usuários do sistema.
Criar um processo de qualificação do prestador de serviço, através das notas
atribuídas pelos clientes contratantes.
2 REFERENCIAL TEÓRICO
2.1 PROGRAMAÇÃO ORIENTADA A OBJETOS
2.2 INTRODUÇÃO
Em Programação orientada a objetos, um objeto é uma abstração para
algo do mundo real. Programação Orientação a Objetos, refere-se ao
paradigma de programação onde o desenvolvimento do software é regido
pelas definições e relacionamentos entre os objetos. Tem como
características uma maior facilidade, precisão, segurança e economia na
execução de ações de manutenção em relação a outros métodos de
desenvolvimento, e uma maior proximidade entre a análise do problema e a
implementação da solução.
Deboni (2003, pag. 32) salienta que:
A orientação a objetos enfoca a busca da estrutura do problema, e não apenas da informação. Identifica em objetos, os elementos importantes do domínio do problema, que guardam dados e possuem funções que podem operar seus dados. Não são apenas as funções que o sistema deve desempenhar, como na modelagem funcional, nem somente os dados que serão armazenados, como na modelagem de dados; a importância maior é encontrar os elementos do problema que possuem todas estas propriedades.
SOMMERVILLE (2007, p. 208) afirma que:
Análise orientada a objetos concentra-se no desenvolvimento de um modelo orientado a objetos do domínio da aplicação. Os objetos nesse modelo refletem as entidades e as operações associadas ao problema a ser resolvido.
17
Esse padrão se baseia em quatro pilares: abstração, encapsulamento,
herança e polimorfismo, como demonstra a figura 1 abaixo.
Figura 1- Programação Orientada a Objetos
Fonte: Google
2. 3 DEFINIÇÕES
2.3.1 Objeto
Para Ambler (1998, p. 5) “Um objeto é qualquer indivíduo, lugar, evento,
coisa, tela, relatório ou conceito que seja aplicável ao sistema”.
Segundo Pfleeger (2004, p. 213), “cada instância tem seus próprios valores
de atributos, mas compartilha o nome e os comportamentos dos atributos com a
outras instâncias da classe”.
2.3.2 Atributos
Segundo Caíque Cardoso (2003, pág. 7) “atributos possuem uma
representação determinada por um nome, um tipo e um valor padrão que é opcional.
Os atributos possuem visibilidade que são: públicos, protegidos ou privados.
18
2.3.3 Polimorfismo
Deboni (2003 p.45) afirma que “é a propriedade de que a mesma mensagem
pode ser respondida de forma diferente por duas ou mais classes, (poli = múltiplas,
morfo="forma")”.
2.3.4 Herança
Deboni (2003 p.43) afirma que:
A herança é uma das principais características da orientação a objetos, e que está intimamente associada ao conceito de agrupamento dos objetos segundo um conjunto de propriedades comuns. Uma classe de um objeto é o agrupamento de objetos que compartilham a mesma estrutura de dados e funções. É possível se encontrar grupos que possuam um conjunto de propriedades, e que a partir deste grupo seja possível criar outros grupos que possuam propriedades ainda mais específicas, formando assim um subconjunto do anterior. A orientação a objetos permite criar uma relação entre as classes de objetos de modo que classe pode ser gerada a partir de outra classe, herdando dela suas propriedades estáticas (atributos) e dinâmicas (funções).
2.4 UNIFIED MODELING LANGUAGE (UML)
Segundo Fowler (2004, pág. 25) “UML é uma família de notações gráficas,
apoiada por um modelo único, que ajuda na descrição e no sistemas de software,
particularmente daqueles construídos utilizando o estilo orientado a objetos”.
2.4.1 Diagrama de casos de uso
Deboni (2003, pag.68) afirma que “o objetivo do diagrama de casos de uso é
descrever um modelo funcional de alto nível do sistema em projeto. Este diagrama
procura identificar os usuários e representar o sistema segundo a sua visão”.
19
2.4.2 Caso de uso
Deboni (2003 p.73) afirma que:
Um caso de uso é uma sequência de transações ocorridas no sistema, que refletem em algo de importância para o ator que se comunica com este caso de uso. Os atores definem suas necessidades na forma de objetivos a serem cumpridos pelo sistema, que são capturados pelos casos de uso. Utiliza-se um caso de uso quando se deseja representar uma funcionalidade de alto nível no sistema, ou para representar um conjunto de funcionalidades esperadas por um ator. Para identificar os casos de uso devemos consultar os atores, e observar as suas necessidades, agrupando-as e associando-as aos atores.
2.4.3 Ator
Deboni (2003, pag.70) diz que:
O termo ator caracteriza bem a possibilidade do mesmo usuário, em diferentes situações, assumir personalidades diferentes para o sistema, agindo como um ator em uma peça teatral. Em cada uma destas situações, deve-se procurar identificar as necessidades dos atores, que se tornarão
requisitos para o sistema, na forma de casos de uso. A linha que separa
os atores dos casos de uso é a fronteira do sistema.
A representação do ator em um diagrama é feita de forma simples, como na
figura 2 baixo.
Figura 2 – Representação de um ator
Fonte: Autor
20
2.4.4 Diagrama de classe
Deboni (2003, pág. 88) relata que:
O diagrama de classes é a representação fundamental da modelagem orientada a objetos, e evolui de uma visão conceitual para uma visão detalhada, com o desenvolvimento do sistema. No modelo conceitual de classes é possível descrever os elementos principais de um sistema, suas características individuais e como eles se relacionam. O diagrama de classes traduz uma visão estática, sem movimento, equivalente à uma foto do sistema.
2.4.5 Classe
Deboni (2003, pág.90) afirma que:
Classes são matrizes de objetos, elas identificam grupos de elementos do sistema que compartilham as mesmas propriedades. As classes representam um conceito importante para o problema em questão. Enquanto uma classe descreve um conceito abstrato do domínio do problema, um objeto representa um elemento deste conceito, que é utilizado no sistema, de modo concreto. Ao criar um objeto, com base em uma classe, ele assume valores para os atributos, definindo um estado e herda um comportamento das classes que permite alterar este estado. Os estados e os comportamentos são compartilhados por todos os objetos da mesma classe, e são definidos na fase de análise.
Em UML, classes são representadas por retângulos, com o nome da classe, e
podem também mostrar os atributos e operações da classe em dois
outros compartimentos dentro do retângulo. Veja figura 3 abaixo.
Figura 3 – Diagrama de Classe
Fonte: autor
21
2.4.6 Atributos
Segundo Deboni (2003, pág. 153) “Os atributos são nomeados da mesma
forma que as classes. Com a diferença que os atributos são iniciados por letras
minúsculas e representam propriedades das classes”.
2.4.7 Operações
De acordo com Deboni (2003, pág. 143) “as operações indicam ações que a
classe pode executar. As operações devem ser nomeadas com nomes relativos às
responsabilidades que a classe assume para o sistema.”
2.4.8 Herança
De acordo com Cardoso (2003, pág.8) “uma classe pode possuir um
relacionamento de herança com outra classe. Nesses casos, afirma-se que a classe
“mãe” é menos especializada, ou seja, mais genérica e a classe “filha” é mais
especializada.”
2.4.9 Associações
Para Deboni (2003, pág. 96):
As associações aparecem quando há um nível maior de envolvimento, e mais bem definido do que na dependência, entre as classes. Na associação as classes estão ligadas semanticamente umas às outras. Ou seja, as classes mantêm-se independentes, mas guardam algum tipo de significado na sua relação. Esta relação já permite a troca de mensagens entre as classes na ajuda para o cumprimento de suas responsabilidades.
22
2.4.10 Agregação
Deboni (2003, pág. 97) diz que:
Alguns tipos de associação podem exigir um aumento no grau de envolvimento entre as classes o que cria a agregação. A agregação é equivalente à associação mas indica que as classes possuem uma dependência existencial, isto é, uma classe só existe em conjunto com as suas agregadas. A classe toda é composta pela(s) classe(s) à parte.
2.4.11 Diagramas de Sequência
Deboni (2003, pág. 157) afirma que:
Os diagramas de sequência descrevem o comportamento dos objetos do sistema, que se relacionam pela troca de mensagens em interações na sequência de tempo. Cada diagrama mostra um cenário, isto é, um conjunto de mensagens, ordenadas no tempo, com um determinado objetivo. Assim, para a elaborar um diagrama de sequência é importante que os objetivos do sistema já tenham sido levantados pela modelagem de contexto, e que se encontrem descritos nos cenários dos casos de uso.
Cardoso (2003, pág.35) relata que:
O diagrama de sequência apresenta uma sequência de eventos que determinam o comportamento do caso de isso apresentados no fluxo de eventos. Neste diagrama são apresentados os atores e as classes de análise na parte superior do diagrama e as linhas que se seguem abaixo de cada um deles representam a linha de vida do objeto ou da ação do ator ou objeto sobre outro objeto.
2.5 RATIONAL UNIFIED PROCESS - RUP
Dantas (2008, pág.5) diz que:
O RUP é um conjunto de práticas coletadas de engenharia de software que são continuamente aprimoradas, com regularidade, para refletirem alterações nas práticas do segmento de mercado. RUP utiliza um processo Iterativo(repetitivo) que é uma sequência de passos incrementais.
Nesse processo, as seguintes características são marcantes:
- Cada iteração inclui algumas ou todas as disciplinas;
23
- Cada iteração deve ter um conjunto bem definido de objetivos e produz
uma parte funcional do sistema;
- Cada iteração sucessiva é construída sob o trabalho da iteração
anterior;
- As primeiras iterações têm uma grande ênfase em requisitos, análise e
desenho;
- Iterações posteriores têm uma grande ênfase em implementação e
testes;
Na figura 4 abaixo, é demonstrado as fases do RUP, popularmente
conhecido como “gráfico das baleias”.
Figura 04 – Fases do RUP
Fonte:RUP
2.5.1 Fase de Concepção / Iniciação
De acordo com Dantas (2008, pág.19) “Essa fase foca na compreensão do
escopo e objetivos do projeto obtendo informações suficientes para confirmar que
você deve seguir ou até mesmo abortar o projeto”.
24
2.5.2 Fase de Elaboração
Segundo Dantas (2008, pág.21) “essa é a fase na qual a diferenças com a
abordagem cascata fica mais evidente em relação ao modelo iterativo ficando claro
as vantagens deste segundo”.
Ainda de acordo com Dantas (2008, pág.21) “O objetivo da fase de
Elaboração é definir e consolidar uma arquitetura do sistema provendo uma base
estável para as atividades de desenho e implementação”
Nessa fase você endereça riscos associados com:
- Requisitos (você está construindo a aplicação correta?);
- Arquitetura (você está construindo a solução correta?);
- Custo e Cronograma (você realmente está no caminho)?
- Processo e Ferramentas (você tem o processo e ferramenta corretos para
fazer o trabalho?).
2.5.3 Fase de Construção
De acordo com Dantas (2008, pág.24) “Durante a fase de construção é dado
total foco em detalhar o design, implementar e testar para liberá-lo por completo”.
A fase de construção é a que consome maior tempo, em geral 65% do
esforço de todo o projeto e 50% de todo o tempo previsto são dedicados a ela.
2.5.4 Fase de Transição
De acordo com Dantas (2008, pág.28) “O foco da fase de Transição é
assegurar que o software atenda integralmente às necessidades de seus usuários.
Fase de transição se estende por iterações que incluem testes do produto para
liberar e ajustes com base no feedback do usuário.”
25
2.6 FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO
2.6.1 Hypertext Preprocessor( PHP)
A linguagem PHP é uma das melhores e mais usadas linguagens de
programação voltadas para internet. Seus maiores benefícios são:
Gratuidade
Sem licenças restritas
Baixo custo de manutenção
Código maduro
Atualizações consistentes
Integração com os melhores bancos de dados
É uma linguagem de programação de ampla utilização, interpretada, que é
especialmente interessante para desenvolvimento para a Web e pode ser mesclada
dentro do código HTML. A sintaxe da linguagem lembra C, Java e Perl, e é fácil de
aprender. O objetivo principal da linguagem é permitir a desenvolvedores
escreverem páginas que serão geradas dinamicamente.
2.6.2 HTML
HTML é baseado no conceito de hipertexto, que são conjuntos de elementos
ligados por conexões, que podem ser palavras, imagens, vídeos, áudio,
documentos, que quando conectados, formam uma grande rede de informação.
O HTML5 é a mais nova versão do HTML4. Um dos seus principais objetivos
é facilitar a manipulação dos elementos, possibilitando o desenvolvedor modificar as
características dos objetos de forma não intrusiva, fazendo com que isso fique
transparente para o usuário final.
26
2.6.3 Angular JS
É um framework open source desenvolvido pela Google, que liga seu HTML
com objetos JavaScript. Ele permite que se utilize o HTML como linguagem de
modelo e permite estendê-lo para expressar os componentes da sua aplicação de
forma clara e sucinta.
Segundo a própria documentação, o Angular é o que o HTML seria se tivesse
sido projetado para aplicações dinâmicas. O HTML nasceu e sempre se manteve
com uma essência estática.
2.6.4 MySQL
O MySQL é um sistema gerenciador de banco de dados relacional de código
aberto usado na maioria das aplicações gratuitas para gerir suas bases de dados.
Utiliza-se a linguagem SQL (Structure Query Language – Linguagem de Consulta
Estruturada), que é a linguagem mais popular para inserir, acessar e gerenciar o
conteúdo armazenado num banco de dados.
2.6.5 Apache Cordova
O Apache Cordova oferece um grupo de APIs que permitem desenvolver uma
aplicação com HTML, CSS e JavaScript encapsulada como aplicação móvel nativa.
A aplicação é executada no dispositivo móvel e pode acessar as funções nativas do
dispositivo, como GPS ou câmera. Usando as APIsCordova, um desenvolvedor
consegue criar uma aplicação móvel sem escrever qualquer código nativo.
27
2.6.6 Java Script
O JavaScript é uma linguagem de programação do lado cliente, ou seja, é
processada pelo próprio navegador. Com o JavaScript pode-se criar efeitos
especiais para nossas páginas na Web, além de podermos proporcionar uma maior
interatividade com nossos usuários. O JavaScript é uma linguagem orientada a
objetos, ou seja, ela trata todos os elementos da página como objetos distintos,
facilitando a tarefa da programação.
3 ANÁLISE E DOCUMENTAÇÃO DO SISTEMA
3.1 INTRODUÇÃO
Esse documento tem o objetivo fornecer uma visão geral do software
Prestadores, detalhando como serão suas funcionalidades.
3.1.1 Finalidade
A finalidade deste documento é coletar, analisar e definir as características e
necessidades de alto nível do software Prestadores. Nele se concentra nos recursos
necessários aos envolvidos e aos usuários-alvo e nas razões que levam a essas
necessidades. O detalhe de como o Prestadores atinge essas necessidades são
descritos no caso de uso e nas especificações suplementares.
3.1.2 Escopo do documento
Esse documento de visão faz referência ao software Prestadores. A função do
Prestadores é automatizar o processo de busca de serviços de auxilio em geral.
28
3.1.3 Visão Geral
Nas próximas seções serão apresentados o escopo da empresa e produto em
desenvolvimento
3.2 POSICIONAMENTO
3.2.1 Descrição da Empresa
O Prestadores é uma empresa que busca facilitar a comunicação, realizando
ligação entre o usuário que necessita de um determinado serviço e o profissional
responsável pela prestação do mesmo. É independente de qualquer vínculo
empregatício, está sediada na Rua 37 Sul, lote 17/19 Térreo, Águas Claras,
Taguatinga Distrito Federal, desde o ano de 2015. É composta por dois sócios. Os
sócios têm a função de manter a organização e funcionalidade do sistema.
3.2.2 Oportunidade de Negócios
A empresa descrita não possui um sistema. O Prestadores será o primeiro
aplicativo desenvolvido pela empresa.
Em uma pequena pesquisa foi levantado que há poucos aplicativos voltados
para a área de prestação de serviços, tendo em vista uma boa oportunidade para se
destacar neste ramo de atividades.
29
3.2.3 Descrição do Problema
Quadro 1 – Descrição do Problema
O problema de Demora na procura de um profissional e não possuir um
histórico de atendimento.
Afeta Usuários em Geral
Cujo impacto é Dificuldade na escolha de um bom profissional para a
prestação do serviço
Uma boa solução seria Implantação de um sistema que faça a ligação do
usuário com o profissional e que possua um sistema de
pontuação, qualificação do profissional, visando facilitar
a procura do usuário.
3.2.4 Sentença de Posição do Produto
Quadro 2 – Sentença de Posição do Produto
Para Usuários
Quem Púbico em Geral
O Sistema de Ajuda É um software
Que Agiliza e automatiza a procura de serviços diversos
domésticos.
Diferente do Estado atual que a procura é feita através dos jornais
e classificados em geral.
Nosso produto Automatiza a procura e classifica o profissional.
30
3.2.5 Escopo do Produto
O software Prestadores será um aplicativo mobile híbrido, ou seja,
parcialmente nativo e parcialmente web. Assim como os nativos, ele deverá ser
baixado através de um aplicativo de loja (como Google Play do Android e AppStore
da Apple), ficando armazenado na tela principal do dispositivo e podendo aproveitar
todas as funcionalidades do dispositivo (câmera, GPS, etc). E assim como os
aplicativos web, ele será baseado em HTML5 e exibidos através de um navegador
embutido no aplicativo, tendo parte ou conteúdo total carregado da web.
Os aplicativos híbridos são populares porque permitem o desenvolvimento em
multiplataformas, utilizando o mesmo HTML para diferentes sistemas
operacionais, como através de ferramentas
como Cordova, PhoneGap e SenchaTouch permitem, inclusive compilando para o
formato nativo, reduzindo custos de produção.
3.3 DESCRIÇÕES DOS ENVOLVIDOS E DOS CLIENTES
3.3.1 Demografias do Mercado
O mercado-alvo desse sistema compreende um segmento de pessoas que
muitas vezes não sabem onde encontrar um bom profissional que tenha referência e
que seja fácil de achar. O mercado a ser atendido é composto de na sua maioria
usuários domésticos que serão os usuários do sistema.
31
3.3.2 Resumo dos Envolvidos
Quadro 03 – Resumo dos Envolvidos
Nome Descrição Responsabilidades
Sócios Fundadores Principal usuário do
sistema. Tem acesso a
todos os níveis
Controlar dados cadastrais de
usuários, controle de acesso
e manutenção do
sistema.Validaçao.
Prestadores de
Serviços
Usuário do nível cadastro Cadastrar e alterar seus
dados cadastrados
Usuários Usuário do nível cadastro Cadastrar e alterar seus
dados cadastrados
3.3.3 Resumo dos Clientes
Quadro 4 – Resumo dos Clientes
3.3.4 Ambiente dos Clientes
O software Prestadores será desenvolvido em plataforma Móbile. O controle
de acesso do software será dividido em níveis de acesso. O acesso para os clientes
será dividido em Contratar (clientes que procuram um profissional para a prestação
de algum serviço em específico) e Trabalhar (clientes que estão oferecendo seus
serviços para a contratação pelo cliente).
Nome Descrição Responsabilidades Envolvido
Prestadores de Serviços
Responsável secundário do sistema
Cadastrar e alterar seus dados, cadastrar seus serviços oferecidos
Auto-representado
Usuários Responsável secundário do sistema
Cadastrar e alterar seus dados.
Auto-representado
32
3.3.5 Perfis dos Envolvidos
3.3.5.1 Prestador de Serviços
Quadro 5 – prestador de serviços
Descrição É o responsável pelos serviços prestados.
Tipo Usuário secundário
Responsabilidades É o usuário que tem a responsabilidade de controlar todos
os seus dados cadastrados.
Critérios de Sucesso Capacidade de cadastrar, alterar e excluir seus dados
cadastrados.
Envolvimento Prestar Serviços.
Produtos Liberados Nenhum
Comentários/Problemas Nenhum
3.3.5.2 Usuários
Quadro 6 – Usuários
Descrição Assume a responsabilidade de cadastro e alteração
de seus dados.
Tipo Usuário secundário.
Responsabilidades É o usuário que tem a responsabilidade de controlar
todos os seus dados cadastrados.
Critérios de Sucesso Capacidade de cadastrar, alterar e excluir seus dados
cadastrados.
Envolvimento Usar o Sistema.
Produtos Liberados Nenhum
Comentários/Problemas Nenhum
33
3.3.5.3 Principais Necessidades dos Envolvidos ou dos Clientes
Quadro 07 – Necessidades dos Envolvidos ou dos Clientes
Necessidade Prioridade Preocupações Solução
Atual
Soluções
Propostas
Cadastrar dados Alta Níveis de volume e
tempo de resposta
Nenhuma Implantação de
um software
Alterar dados Alta Níveis de volume e
tempo de resposta
Nenhuma Implantação de um
software
Pesquisar dados Alta Níveis de volume e
tempo de resposta
Nenhuma Implantação de um
software
Excluir dados Alta Níveis de volume e
tempo de resposta
Nenhuma Implantação de um
software
3.3.5.4 Alternativas e Concorrência
No mercado existem alguns sistemas similares no seguimento de prestação
de serviços, mas o Prestadores se destacará, pois contará com o sistema de
classificação do serviço prestado, pontuando assim, o profissional cadastrado,
usando isso como referência na hora de escolher o profissional a ser contratado.
3.3.6 Restrições
O sistema deverá estar disponível até junho de 2015
34
3.4 ESPECIFICAÇÕES DE REQUISITOS
3.4.1 ERaFPR.001
Quadro 08 – Quadro de Especificação do Requisito ER aF.001
ER aF.001 Cadastrar prestador de serviço
Descrição Esse requisito tem a função de cadastrar os prestadores de serviço no sistema
Descrição do risco Risco Descrição do risco
Os dados não serem gravados no banco. Alto Os dados não serem gravados no banco.
Usuário Envolvido Prestadores de Serviços
3.4.2 ER aDPR.001
Quadro 09 – Quadro de Especificação do Requisito ER aD.001
ER aD.001 Dados cadastrar prestador de serviço
Descrição Esse requisito tem a função de cadastrar nome e sobrenome, tipo de serviço, experiência, endereço, telefone, e-mail, senha, inserir foto no sistema.
Descrição do risco Risco Descrição do risco
Os dados não serem gravados no banco. Alto Os dados não serem gravados no banco.
Usuário Envolvido Prestadores de Serviços
35
3.4.3 ER aFPR.002
Quadro 10 – Quadro de Especificação do Requisito ER aF. 002
ER aF. 002 Alterar Prestador de Serviço
Descrição Esse requisito tem a função de alterar dados de Prestadores de Serviço.
Descrição do risco Risco Descrição do risco
Os dados não serem alterados com sucesso. Alto Os dados não serem alterados com sucesso.
Usuário
Envolvido
Prestadores de Serviços
3.4.4 ER aDPR.002
Quadro 11– Quadro de Especificação do Requisito ER aD. 002
ER aD. 002 Dados prestador de serviço
Descrição Esse requisito tem a função de alterar nome e sobrenome, endereço, tipo de serviço, experiência, telefone, e-mail, senha, inserir foto.
Descrição do risco Risco Descrição do risco
Os dados não serem alterados com sucesso. Baixo Os dados não serem alterados com sucesso.
Usuário
Envolvido
Prestador de Serviço
3.4.5 ERaFPR.003
Quadro 12 – Quadro de Especificação do Requisito ER aF.003
ER aF.003 Pesquisar Serviço
Descrição Esse requisito tem a função pesquisar dados de serviços disponíveis.
Descrição do risco Risco Descrição do risco
O dado pesquisado não ser encontrado Médio O dado pesquisado não ser encontrado
Usuário
Envolvido
Usuário
36
3.4.6 ER aDPR.003
Quadro 13 – Quadro de Especificação do Requisito ER aD.003
ER aD.003 Dados pesquisar serviço
Descrição Esse requisito tem a função de pesquisar tipo de serviços.
Descrição do risco Risco Descrição do risco
O dado pesquisado não ser encontrado Médio O dado pesquisado não ser encontrado
Usuário
Envolvido
Usuário
3.4.7 ERaFPR.004
Quadro 14 – Quadro de Especificação do Requisito ER aF.004
ER aF.004 Excluir prestador de serviço
Descrição Esse requisito tem a função excluir dados de prestadores de serviço do sistema.
Descrição do risco Risco Descrição do risco
O dado não ser excluído Médio O dado não ser excluído
Usuário Envolvido Prestador de Serviço
3.4.8 ERaDPR.004
Quadro 15 – Quadro de Especificação do Requisito ER aD.004
ER aD.004 Excluir prestador de serviço
Descrição Esse requisito tem a função de excluir nome e sobrenome, endereço, tipo de serviço, experiência, telefone, e-mail, senha, inserir foto no sistema.
Descrição do risco Risco Descrição do risco
O dado não ser excluído Médio O dado não ser excluído
Usuário Envolvido Prestador de Serviço
37
4 DESCRIÇÕES DOS CASOS DE USO E ATORES
4.1 CASOS DE USO
Manter Usuário Manter Serviço Validar Dados
4.2 DESCRIÇÕES DOS ATORES
4.2.1 Administrador do Sistema
Este ator é uma pessoa que atua no sistema como ator primário, ele deverá
validar os dados que serão cadastrados pelos usuários e/ou prestadores.
4.2.2 Prestador de Serviço
Este ator é uma pessoa que atua no sistema como ator primário, ele pode
cadastrar, alterar e excluir os seus dados no sistema.
4.2.3 Usuário
Este ator é uma pessoa que atua no sistema como ator primário, ele pode
pesquisar dados no sistema.
38
4.3 DIAGRAMA GERAL DE CASO DE USO
Figura 05 – Diagrama de Casos de Uso geral
4.4 DETALHAMENTO DOS CASOS DE USO
4.4.1 UC 001 – Manter Usuário
Figura 06 – Diagrama de Casos de Uso manter Usuário
39
Quadro16- Fluxo de Eventos do manter usuário
Nome da Use Case Manter Usuário
Descrição Tem a função de cadastrar, pesquisar, alterar e excluir usuários no sistema.
Requisitos Associados
ER aF.001, ER aD.001, ER aF.002, ER aD.002, ER aF.003, ER aD.003, ER aF.004, ER aD.004.
Pré Condições Usuário autenticado no sistema.
Pós Condições A tela principal estar aberta
Atores Usuário (Cliente e Prestador) e Administrador
Fluxo Principal
Ações Recebidas(Ator) Ações Realizadas (Sistema)
1) O usuário seleciona o ícone cadastrar usuário
3) O usuário escolhe o acessar ao cadastrar; 5) O usuário insere os dados do usuário; 7) O usuário salva; 9) O usuário clica no ok.
2) O sistema abre a tela usuário para acessar Cadastrar, alterar, pesquisar, excluir; 4) O sistema abre a tela que contém os campos contendo os dados dos usuários; 6) o sistema registra o usuário no sistema; 8) Salva os dados. Apresenta a mensagem “usuário cadastrado com sucesso”; 10) o sistema retorna para a página inicial.
Fluxo Alternativo Alterar usuário
Ações Recebidas Ações Realizadas
1) O usuário seleciona o ícone usuário; 3) O usuário escolhe o alterar. 5) O usuário insere sua senha de acesso 7) O usuário Insere os dados do que ele deseja alterar. 9) O usuário salva. 11) O usuário clica no ok.
2) O sistema abre a tela usuário para acessar o Cadastrar, alterar,
pesquisar, excluir. 4) O sistema solicita a senha 6) O sistema abre a tela contém os campos a serem preenchidos com os novos dados do usuário 8) O sistema registra o usuário 10) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso” 12) O sistema volta para a página inicial
Fluxo Alternativo pesquisar usuário
Ações Recebidas Ações Realizadas
1) O ícone usuário é selecionado 3) O usuário escolhe o pesquisar.
2) O sistema abre a tela usuário para acessar o Cadastrar, alterar,
pesquisar, excluir. 4) O sistema abre a tela que contém um campo a ser preenchido com o nome do usuário
40
5) O usuário insere o nome de outro usuário. 7) O usuário clica em finalizar busca
a ser pesquisado e solicita o pesquisar. 6) O sistema abre a tela com os dados do usuário. 8) volta para a página inicial
Fluxo Alternativo excluir usuário
Ações recebidas Ações realizadas
1) O ícone usuário é selecionado
3) O usuário escolhe o excluir.
2) O sistema abre a tela usuário para acessar o Cadastrar, alterar, pesquisar, excluir.
4) O sistema abre um campo para pesquisar usuário
5) O usuário insere seu nome de login.
6) O sistema abre a tela com os dados do usuário.
7) O usuário clica em excluir
9) O usuário clica em Sim
11) o usuário clica em OK
8) o sistema apresenta a mensagem “Você realmente deseja excluir esse registro?” dois botões sim e não
10) O sistema apresenta a mensagem “Dados excluídos com sucesso!” 12) O sistema volta para a tela inicial.
4.4.2 UC 002 – Manter Serviço
Figura 07 – Diagrama de Casos de Uso manter serviço
41
Nome da Use Case Manter Serviço
Descrição Tem a função de cadastrar, pesquisar, alterar e excluir serviço no sistema.
Requisitos Associados
ER aF.001, ER aD.001, ER aF.002, ER aD.002, ER aF.003, ER aD.003, ER aF.004, ER aD.004.
Pré Condições O usuário estar autenticado no sistema
Pós Condições A tela principal estar aberta
Atores Usuário
Fluxo Principal
Ações Recebidas(Ator) Ações Realizadas(Sistema)
2) O usuário exercendo o papel de prestador de serviço seleciona o ícone cadastrar serviço.
3) O usuário escolhe o cadastrar;
5) O usuário insere os dados de seus serviços;
7) O usuário clica em Salvar;
9) O usuário clica no em OK.
3) O sistema abre a tela de serviços para acessar Cadastrar, alterar, pesquisar, excluir;
4) O sistema abre a tela com os Campos referentes aos serviços cadastrados; 6) o sistema registra os serviços no sistema; 8) Salva os dados. Apresenta a mensagem “Prestador cadastrado com sucesso”;
10) o sistema retorna para a página inicial.
Fluxo Alternativo Alterar serviço
Ações Recebidas Ações Realizadas
1) O usuário exercendo o papel de prestador, clica em Serviços;
3) O usuário escolhe em Alterar.
5) O usuário insere sua senha
7) O usuário Insere os novos dados da sede
9) O usuário Clica em Salvar
11) O usuário clica em Ok
2) O sistema abre a tela para Cadastrar, alterar, pesquisar, excluir.
4) O sistema solicita a senha.
6) O sistema abre a tela que contém os campos a serem preenchidos com os novos dados dos serviços.
8) O sistema registra o serviço
10) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso”
12) O sistema volta para a página inicial
Fluxo Alternativo pesquisar serviço
Ações Recebidas Ações Realizadas
1) O usuário exercendo o papel
2) O sistema abre a tela para
42
de cliente seleciona Serviços.
3) O usuário seleciona o pesquisar.
5) O usuário insere o nome do serviço.
7) O usuário clica em finalizar busca
acessar Cadastrar, alterar, pesquisar, excluir.
4) O sistema abre a tela que contém um campo a ser preenchido como nome do serviço a ser pesquisado e um “botão” com o nome pesquisar
6) O sistema abre a tela com os dados do serviço pesquisado.
8) volta para a página inicial
Fluxo Alternativo excluir serviço
Ações recebidas Ações realizadas
1) O usuário exercendo o papel de prestador escolhe o ícone serviços.
3) o usuário escolhe o ícone meus serviços cadastrados
2) O sistema abre a tela serviços.
4) O sistema abre uma tela com serviços cadastrados pelo usuário
5) O usuário escolhe o serviço que deseja excluir
6) O sistema abre a tela com os dados do serviço selecionado.
7) O usuário clica em excluir serviço.
9) O usuário clica no Sim
11) o usuário clica em ok
8) o sistema apresenta a mensagem “Você realmente deseja excluir esse registro?” dois botões sim e não
10) O sistema apresenta a mensagem “Dados excluídos com sucesso!”
12) O sistema volta para a tela inicial.
43
4.5 DIAGRAMA DE CLASSE
44
4.6 DIAGRAMA DE SEQUÊNCIA
4.6.1 Diagrama de sequência Autenticação
4.6.2 Diagrama de sequência manter usuário
45
4.6.3 Diagrama de sequência manter serviço
46
CONCLUSÃO
O objetivo geral desse trabalho foi desenvolver um aplicativo móbile para o
público-alvo de usuários que procuram a facilidade de encontrar prestadores de
serviços domésticos em sua região. Nesse sentido, foi realizada uma pesquisa
com profissionais da área, visando detalhar a maneira que geralmente eles
trabalham. Assim foi planejado melhor a proposta do trabalho, aproveitando os
problemas encontrados e os revertendo em soluções aplicáveis na era da
informação.
O sistema desenvolvido foi composto de diversas ferramentas de trabalho
que nos auxiliou em cada etapa, tanto na construção da documentação, como na
codificação do software. Algumas ferramentas nós já possuía-se experiência,
como o Astah, responsável pela criação dos diagramas. Outras teve-se o
primeiro contato, como o XDK, responsável pelo front-end do aplicativo.
Aprendeu-se da melhor maneira, praticando.
Ao longo do trabalho, surgiram novas possibilidades que não foram
implementadas, mas que são desejáveis e deverão compor o projeto
futuramente. As duas principais são o acesso à geolocalização pelo CEP
cadastrado e a extensão para os demais Estados brasileiros.
47
REFERÊNCIAS
AMBLER, Scott W. Análise e Projeto Orientados a Objeto: volume II. 2.ed.Rio de Janeiro: Infobook,1998.
Apresentando o AngularJS. Disponível em <http://www.dextra.com.br/apresentando-o-angular-js-4> Acessado em 22 jun. 2015.
CARDOSO, Caíque. UML na prática: do problema ao Sistema. Rio de Janeiro: Editora Ciência Moderna,2003.
Conceitos básicos sobre criação de uma aplicação Cordova. Disponível em <https://netbeans.org/kb/docs/webclient/cordova-gettingstarted_pt_BR.html> Acessado em 22 jun. 2015.
DEBONI, J.E.Z. Modelagem orientada a objetos com a UML: técnicas de análise, documentação e projeto de sistemas. Local: São Paulo. Editora Futura, 2003.
Desenvolvimento Orientado a Objetos. Disponível em <http://www.tiselvagem.com.br/desenvolvimento/desenvolvimento-orientado-a-objetos/>. Acessado em 24 jun. 2015.
FOWLER, Martin. UML Essencial. Editora: Bookman, 2004.
O que é e como usar o MySQL? Disponível em <http://www.techtudo.com.br/artigos/noticia/2012/04/o-que-e-e-como-usar-o-mysql.html> Acessado em 22 jun. 2015.
O que é HTML5. Disponível em <http://www.devmedia.com.br/o-que-e-o-html5/25820> Acessado em 22 jun. 2015.
O que é JavaScript. Disponível em <https://developer.mozilla.org/pt-PT/docs/Web/JavaScript/O_que_%C3%A9_o_JavaScript> Acessado em 22 jun. 2015
Os benefícios e vantagens do PHP. Disponível em <http://elias.praciano.com/2014/02/15-beneficios-e-vantagens-do-php> Acessado em 22 jun. 2015.
PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2. ed. Pearson Education Companion, 2004.
PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 2002.
RUP. Disponível em <http://www.infoescola.com/engenharia-de-software/rup> Acessado em 15 jun. 2015.
48
StudyGuide: IBM RationalUnifiedProcess – RUP 2003. Disponível em <http:/si.lopesgazzani.com.br/docentes/marcio/rup/ResumoLivroRUPMadeEasy.pdf> Acessado em 15 jun. 2015.
SOMMERVILLE, Ian. Engenharia de software. São Paulo. 8. ed. Pearson Education Companion, 2003.