APS_Praticas de Engenaharia de Software

Prévia do material em texto

20
FMU – Faculdades Metropolitanas Unidas
Aluno RA: 
ATIVIDADE PRÁTICA SUPERVISIONADA
DISCIPLINA – PRATICA DE ENGENHARIA DE 
SOFTWARE
SÃO PAULO
2020
Aluno RA:
ATIVIDADE PRÁTICA SUPERVISIONADA
DISCIPLINA – PRATICA DE ENGENHARIA DE 
SOFTWARE
Trabalho de prática de engenharia de software apresentado ao Curso de Bacharelado de Sistemas de Informação, para composição da nota APS – Atividade Prática Supervisionada.
SÃO PAULO
2020
AUTORIZO A REPRODUÇÃO E DIVULGAÇÃO TOTAL OU PARCIAL DESTE TRABALHO, POR QUALQUER MEIO CONVENCIONAL OU ELETRÔNICO, PARA FINS DE ESTUDO E PESQUISA, DESDE QUE CITADA A FONTE
Área de Concentração: Bacharelado Sistemas de Informação
Data da Entrega: _22/11/ 2020___
Resultado:_________________________
BANCA EXAMINADORA:
__________________________________
Orientador: 
RESUMO
Estudo realizado sobre o modelo de desenvolvimento RUP (Rational Unified Process – Processo Unificado da Rational).
Através de estudos realizados sobre o modelo de desenvolvimento de software RUP (Rational Unified Process – Processo Unificado da Rational) e sua estrita relação com a linguagem de modelagem unificada (UML), adquirimos conhecimento sobre as fases de um processo de desenvolvimento de um software. Adquirimos também conhecimento de como realizar um processo eficaz e produtivo para realizar o desenvolvimento de uma aplicação, um software para uma determinada solução ou necessidade.
No estudo apresentando a seguir falaremos do modelo RUP, sobre suas fases e integração com a UML.
Palavras-chave: redes, RUP, UML, Diagramas, Desenvolvimento, Projetos.
Sumário
1.	Objetivo.................................................................................... 	6
2.	Cronograma.................................................................................... 7
3.	Fundamentação Teorica................................................................. 8
	3.1UML (Unified Modelinho Language) ........................................8
	3.2 Diagramas ..................................................................................9
	3.2.1 Diagrama de Classe ...............................................................10
	3.2.2 Diagrama de Disponibilização ...............................................10
	3.2.3 Diagrama de Caso de Uso ......................................................11
	3.2.4 Diagrama de Sequência ..........................................................12
	3.2.5 Diagrama de Comunicação .....................................................12
	3.2.6 Diagrama de Atividades ..........................................................13
	3.2.7 Diagrama de Estado ................................................................14
	3.3 Rational Unified Process (RUP) ................................................15
	3.3.1Os princípios do RUP ..............................................................15
	3.3.2 Elementos do RUP ..................................................................16
	3.3.3 Fases do RUP ..........................................................................18
	3.4 Disciplinas RUP .........................................................................19
	3.5 Testes de Software .....................................................................22
	
4.	Conclusão .........................................................................................22
5. Referencias Bibliográgic...................................................................23
1. OBJETIVO
O objetivo deste trabalho é apresentar todas as fases de um processo de desenvolvimento de um software ou aplicação para determinada necessidade. Apresentar a relação do processo de desenvolvimento RUP (Rational Unified Process – Processo Unificado da Rational), com a linguagem de modelagem unificada (UML). Iremos apresentar também os processos de testes de software apresentando no modelo RUP e os diagramas estruturais e comportamentais que compõe a UML.
2. CRONOGRAMA
O presente trabalho se deu início em Março de 2020. Desde essa data, vem sendo realizado pesquisas, levantamentos, elaboração, encontros e afins. 
O gráfico abaixo demonstra o cronograma da elaboração deste trabalho.
	Etapas do trabalho
	CRONOGRAMA - Ano 2020 a 2020
	
	Meses
	
	Set/04
	Set/11
	Out/02
	Out/16
	Out/23
	
	Out/30
	Nov/6
	Nov/20
	Nov./22
	
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	Escolha do tema 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	Revisão Bibliográfica
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	Elaboração Trabalho
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	Metodologia, pesquisa e dados.
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	Elaboração das Considerações Finais
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	Redação final do trabalho
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	Encaminhamento à correção linguística
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	Entrega do Trabalho
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	Discussão dos resultados
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	Apresentação à Banca Examinadora
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
Tabela 1- Cronograma
3. FUNDAMENTAÇÃO TEORICA
3.1 UML (Unified Modeling Language – linguagem de modelagem unificada)
UML (Unified Modeling Language – linguagem de modelagem unificada) é “uma linguagem-padrão para descrever/documentar projeto de software. A UML pode ser usada para visualizar, especificar, construir e documentar os artefatos de um sistema de software-intensivo”. Em outras palavras, assim como os arquitetos criam plantas e projetos para ser usados por uma empresa de construção, os arquitetos de software criam diagramas UML para ajudar os desenvolvedores de software a construir o software. Se você entender o vocabulário da UML (os elementos visuais do diagrama e seus significados), pode facilmente entender e especificar um sistema e explicar o projeto daquele sistema para outros interessados.
Gray Bocha, Jim Rumbaugh e Ivar Jacobson desenvolveram a UML na década de 1990 com muita realimentação da comunidade de desenvolvimento de software. A UML combinou um grupo de notações de modelagem concorrentes usadas pela indústria do software na época. Em 1997, a UML 1.0 foi apresentada ao OMG (Object Management Group), uma associação sem fins lucrativos dedicada a manter especificações para ser usadas pela indústria de computadores. A UML 1.0 foi revisada tornando-se a UML 1.1 e adotada mais tarde naquele ano. O padrão atual é a UML 2.0 e agora é um padrão ISO. Em virtude desse padrão ser tão novo, muitas referências mais antigas, como [Gam95] não usam a notação UML.
A linguagem UML proporciona essas opções (às vezes obscuras) para que você possa expressar todos os aspectos importantes de um sistema. Ao mesmo tempo, é possível suprimir partes não relevantes ao aspecto que está sendo modelado para evitar congestionar o diagrama com detalhes irrelevantes. Portanto, a omissão de uma característica particular não significa que esteja ausente, mas sim que foi suprimida.
A UML é uma tentativa de padronizar a modelagem orientada a objetos de uma forma que qualquer sistema, seja qual for o tipo, possa ser corretamente, com consistência, fácil de se comunicar com outras aplicações, simples de ser atualizado e compreensível. [Booth ET AL,1999].
A UML pode ser utilizada para desenvolver qualquer tipo de sistema, e todas as características do sistema são abrangidas em seus diagramas. A UML é aplicada em todas as fases, desde da análise de requisitos até a fase de teste. O objetivo principal da UML é descrever qualquer tipo de sistema, em forma de diagrama orientados a objeto. A UML também é usada para representar sistemas mecânicos sem nenhum software. Aqui estão alguns tipos diferentes de sistemas com suas características mais comuns: [Booth ET AL,1999].
•Sistemas de Informação: armazenar, pesquisar, editar e mostrar informações para os usuários. Manter grandes quantidades de dados com relacionamento complexos, que são guardados em bancos de dados relacionais ou orientados a objetos.•Sistemas Técnicos: Manter e controlar equipamentos técnicos como de telecomunicações, equipamentos militares ou processos industriais. Eles devem possuir interfaces especiais do equipamento e menos programação de software de que os sistemas de informação. Sistemas técnicos são geralmente sistemas real-time.
•Sistemas Real-Time Integrados: executados em simples peças de hardware integrado a telefones celulares, carros, alarmes, etc. Estes sistemas implementam programação de baixo nível e requerem suporte real-time.
•Sistemas distribuídos: distribuídos em máquinas a onde os dados são transferidos facilmente de uma máquina para outra. Eles requerem mecanismos de comunicação.
3.2 Diagramas
Todos os sistemas possuem uma estrutura estática e um componente dinâmico. A UML suporta modelos estáticos (estruturas estáticas), dinâmicos (comportamento dinâmico) e funcional. A modelagem estática é composta pelo diagrama de classes e de objetos, que possuem as classes e os relacionamentos. Os relacionamentos podem ser de associações, herança, dependências ou refinamentos. Os modelos dinâmicos são suportados pelos diagramas de estado, sequência, colaboração e atividade. E o modelamento funcional é suportada pelos diagramas de componente e execução. Em sistema utilizando UML podem ser necessários de se utilizar de todos os diagramas. Abordaremos agora cada um destes tipos de diagrama, que são divididos em nove e também logo abaixo de cada citação será mostrado um exemplo: [Booth ET AL,1999].
A UML 2.0 fornece 13 diferentes diagramas para uso na modelagem de software, porém mencionaremos apenas os diagramas de classe, distribuição, caso de uso, sequência, comunicação, atividade e estado.
3.2.1 Diagrama de Classe
O diagrama de classe fornece uma visão estática ou estrutural de um sistema, mas não mostra a natureza dinâmica das comunicações entre os objetos das classes no diagrama. Os elementos principais são caixas, ou seja, ícones usados para representar classes e interfaces. Cada caixa é dividida em partes horizontais. A parte superior contém o nome da classe. A seção do meio lista os atributos da classe. Um atributo refere-se a alguma coisa que um objeto daquela classe sabe ou pode fornecer o tempo todo. Atributos são usualmente implementados como campos da classe, mas eles não precisam ser. Poderiam ser valores que a classe calcula a partir de suas variáveis de instância ou valores que a classe pode obter de outros objetos dos quais é composta. A terceira seção do diagrama de classes contém as operações ou comportamentos da classe. Uma operação refere-se ao que os objetos da classe podem fazer. Usualmente é implementada como um método da classe. A figura 1.1 representa um modelo de diagrama de classe.
Figura 1.1 – Diagrama de Classe de uma casa.
3.2.2 Diagrama de Disponibilização
Diagramas de distribuição focalizam a estrutura de um sistema de software e são úteis para mostrar a distribuição física de um sistema de software entre plataformas de hardware e ambientes de execução. Por exemplo, suponha que você esteja desenvolvendo um pacote de renderização gráfica baseado na Web. Os usuários do seu pacote de software usarão o navegador Web para acessar o seu site e introduzir as informações de renderização. O seu site irá renderizar uma imagem gráfica de acordo com as especificações do usuário e a enviará de volta ao usuário. Como a renderização gráfica pode ser cara em termos de computação, você decide mudar a renderização para fora do servidor Web, colocando-a em uma plataforma separada. A figura 1.2 representa um diagrama de disponibilização.
Figura 1.2 – Diagrama de Disponibilização para um pacote de software.
3.2.3 Diagrama de Caso de Uso
Diagrama Caso de uso é uma técnica usada para descrever e definir os requisitos funcionais de um sistema. Eles são escritos em termos de atores externos, use-cases e o sistema modelo. Os atores representam o papel de uma entidade externa ao sistema como um usuário, um hardware, ou outro sistema que interage com o sistema modelado. Os atores iniciam a comunicação com o sistema através dos uses-cases, onde o use-as representa uma sequência de ações executadas pelo sistema e recebe do ator que lhe utiliza dados tangíveis de um tipo ou formato já conhecido, e o valor de resposta da execução de um use-as (conteúdo) também já é de um tipo conhecido, tudo isso é definido juntamente com o use-as através de texto de documentação. A figura 1.3 representa um diagrama de caso de uso.
Figura 1.3 – Exemplo de um diagrama de classe de uso.
3.2.4 Diagrama de Sequencia
Em contraste com os diagramas de classe e os de distribuição, que mostram a estrutura estática de um componente de software, o diagrama de sequência é utilizado para indicar as comunicações dinâmicas entre objetos durante a execução de uma tarefa. Ele mostra a ordem temporal na qual as mensagens são enviadas entre os objetos para executar aquela tarefa. Podemos usar um diagrama de sequência para mostrar as interações em um caso de uso ou em um cenário de um sistema de software.
O diagrama de sequência mostra a colaboração dinâmica entre os vários objetos de um sistema. O mais importante aspecto deste diagrama é que a partir dele percebe-se a sequência de mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos, alguma coisa que acontecerá em um ponto especifico da execução do sistema. O diagrama de sequência consiste em um número de objetos mostrado em linhas verticais. O decorrer do tempo é visualizado observando-se o diagrama no sentido vertical de cima para baixo. As mensagens enviadas por cada objeto são simbolizadas por setas entre os objetos que se relacionam. A figura 1.4 mostra um exemplo de um diagrama de sequência.
Figura 1.4 – Exemplo de um diagrama de sequência.
3.2.5 Diagrama de Comunicação
O diagrama de comunicação UML (chamado de “diagrama de colaboração” em UML 1.X) fornece outra indicação da ordem temporal das comunicações, mas dá ênfase às relações entre os objetos e classes em vez da ordem temporal. Em um diagrama de comunicação, os objetos que interagem são representados por retângulos. Associações entre objetos são representadas por linhas ligando os retângulos. Há tipicamente uma seta apontando para um objeto no diagrama, que inicia a sequência de passagem de mensagens. A seta é identificada com um número e um nome de mensagem. Se a mensagem, que chega, for identificada com o número 1 e se ela faz o objeto receptor invocar outras mensagens em outros objetos, aquelas mensagens são representadas por setas do emissor para o receptor com uma linha de associação e recebem números 1.1, 1.2 e assim por diante, na ordem em que são chamadas. Se aquelas mensagens por sua vez invocam outras, é acrescentado outro ponto e outro número ao número que as identifica, para indicar novo alinhamento da mensagem passada. Na figura 1.5 temos um exemplo de um diagrama de comunicação.
Figura 1.5 – Exemplo de um diagrama de comunicação.	
3.2.6 Diagrama de Atividades
O diagrama de atividade mostra o comportamento dinâmico de um sistema ou parte de um sistema através do fluxo de controle entre ações que o sistema executa. Ele é similar a um fluxograma exceto que pode mostrar fluxos concorrentes. Capturam ações e seus resultados. Eles focam o trabalho executando na implementação de uma operação (método), e suas atividades numa instancia de um objeto. O diagrama de atividade é uma variação do diagrama de estado e possui um propósito um pouco diferente do diagrama de estado, que é o de capturar ações (trabalho e atividades que serão executados) e seus resultados em termos das mudanças de estado dos objetos. A figura 1.6 representa um diagrama de atividades.
Figura 1.6 – Exemplo de um diagrama de atividade.
3.2.7 Diagrama de Estado
Um diagrama de estado modela os estados de um objeto, as ações executadas dependendodaqueles estados e as transições entre os estados do objeto. Um diagrama de estado mostra os estados através de retângulos arredondados, cada um dos quais tem um nome em sua metade superior. Há também um círculo preto chamado de “pseudoestado inicial”, que não é realmente um estado, mas apenas pontos para o estado inicial. Um diagrama de estado o ajudará a descobrir situações perdidas ou inesperadas. Com um diagrama de estado, é relativamente fácil garantir que todos os eventos possíveis para todos os estados possíveis foram levados em conta. A figura 1.7 representa um exemplo de um diagrama de estado.
Figura 1.7 – Exemplo de diagrama de estado.
3.3 Rational Unified Process (RUP)
Conforme [Kroll e Kruchten 2003], pode ter três definições para o RUP:
•O RUP é uma maneira de desenvolvimento de software que é iterativa, centrada à arquitetura e guiada por casos de uso. É descrita em vários livros e artigos. Uma das maiores fontes de informações é o próprio produto IBM RUP, que contém guias detalhados, exemplos e modelos cobrindo todo o ciclo de vida do software;
•O RUP é um processo de engenharia de software bem definido e bem estruturado. O RUP define claramente quem é responsável pelo que, como as coisas devem ser feitas e quando fazê-las. O RUP também provê uma estrutura bem definida para o ciclo de vida de um projeto RUP, articulando claramente os marcos essenciais e pontos de decisão;
•O RUP é também um produto de processo que oferece uma estrutura de processo customizável para a engenharia de software. 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. Essas configurações do RUP podem ser criadas para suportar equipes grandes e pequenas, e técnicas de desenvolvimento disciplinadas ou menos formais. O produto IBM RUP contém várias configurações e visões de processos prontas que guiam analistas, desenvolvedores, testadores, gerentes de projeto, gerentes de configuração, analistas de dados, e outros membros da equipe de desenvolvimento em como desenvolver o software. Ele tem sido utilizado por muitas companhias em diferentes setores da indústria. O RUP utiliza a UML, para modelar, especificar e documentar artefatos. A UML tornou-se um padrão empresarial para a modelagem orientada a objeto. Por ser flexível e configurável, o RUP pode ser utilizado em projetos de pequeno, médio e grande porte. [Kroll e Kruchten 2003] mostra como o RUP pode ser utilizado em um projeto de uma semana com uma equipe de uma pessoa.
3.3.1. Os princípios do RUP
Não existe um modo exato para se usar o RUP, pois ele pode ser utilizado de várias formas e será diferente em cada projeto e organização. Mas existe alguns princípios que podem caracterizar e diferenciar o RUP de outros métodos iterativos: [Kruchten 2003]
•. Atacar os riscos cedo e continuamente;
•. Certificar-se de entregar algo de valor ao cliente;
•. Focar no software executável;
•. Acomodar mudanças cedo;
•. Liberar um executável da arquitetura cedo;
•. Construir o sistema com componentes;
•. Trabalhar junto como um time;
•. Fazer da qualidade um estilo de vida, não algo para depois.
3.3.2. Elementos do RUP
O RUP possui cinco elementos principais que são: papéis, atividades, artefatos, fluxos de trabalho e disciplinas. Um papel ou perfil tem como característica o comportamento e a responsabilidade de um determinado individuo ou grupo unidos num trabalho de equipe. Um indivíduo pode assumir um determinado papel, como: [Kruchten 2003]
•. Analista de sistema – O indivíduo que assume este papel coordena a obtenção dos requisitos e a modelagem dos casos de uso identificando funcionalidades do sistema e estabelecendo limites do sistema;
•. Projetista – Esse indivíduo define responsabilidades, operações, atributos, relacionamentos de uma ou mais classes e determina como elas devem ser ajustadas para serem implementadas no ambiente;
•. Projetista de testes – Responsável pelo planejamento, projeto, implantação e avaliação de testes, incluindo a geração de plano e modelo de teste, implementando procedimentos de testes e avaliando a abrangência dos testes, resultados e a efetividade.
A atividade executa um determinado trabalho e se obtém um resultado muito importante para o contexto do projeto, e ela e dívida em passos, são elas:
•. Planejar uma iteração: realizada pelo papel gerente de projeto;
•. Encontrar casos de uso e atores: realizada pelo papel analista de sistemas;
•. Rever o projeto: realizada pelo papel revisor de projeto;
•. Executar um teste de performance: realizado pelo papel testador de performance.
Um artefato é uma pequena informação que é produzida, modificada ou utilizada em um processo. O artefato é tudo aquilo que é produzido durante o desenvolvimento do projeto. O artefato pode ter várias formas, como:
•. Um modelo, como de caso de uso, de projeto;
•. Um elemento de um modelo, como uma classe, um caso de uso, um subsistema;
•. Um documento, como um caso de negócio, glossário, visão;
•. Código fonte;
•. Executáveis.
A enumeração de atividades, papéis e artefatos não constituem um processo, pois é preciso saber a sequência do desenvolvimento das atividades para que se possa produzir o artefato de valor para o projeto. O fluxo de trabalho é uma sequência de atividades que são executadas para obter resultados valiosos na produção do projeto. O RUP possui três tipos de fluxos de trabalho, são eles: [Kruchten 2003]
•. Fluxos de trabalho principais, associados com cada disciplina; 
•. Fluxos de trabalho de detalhe, para detalhar cada fluxo de trabalho principal;
•. Planos de iteração, que mostram como a iteração deverá ser executada. 
Uma atividade possui diversas atividades relacionadas que fazem parte de um determinado projeto. A separação das atividades em disciplinas torna a compreensão das atividades mais fácil, porém dificulta mais o planejamento das atividades. O RUP é dividido em nove disciplinas, são elas, contida na figura abaixo: [Kruchten 2003].
Figura 1.8 – Representa a arquitetura geral do RUP.
A dimensão horizontal representa o tempo e os aspectos do ciclo de vida à medida que o software é desenvolvido. O processo é descrito em termos de fases (iniciação ou concepção, elaboração, construção e transição), iterações e marcos de referência [DANTAS, 2008] & [RATIONAL SOFTWARE CORPORATION, 2001]. Estes termos estão conceituados logo abaixo:
Na dimensão horizontal da arquitetura, o ciclo do projeto é representado por uma sequência de fases que vão do início ao fim de um projeto. Já as iterações do processo representam sequências de atividades a serem realizadas em um período de tempo definido dentro de um projeto; onde em cada iteração é desenvolvida uma versão estável de um produto e os marcos de referência estão associados a objetivos definidos e alcançáveis, que podem ser analisados pelos clientes e desenvolvedores. 
A dimensão vertical representa a estrutura estática do processo. Descreve como elementos do processo (atividades, disciplinas, artefatos e papéis) são agrupados em disciplinas de processo ou fluxos de trabalho [DANTAS, 2008]. Na estrutura estática um processo descreve “quem” está fazendo “o quê”, “como” e “quando”.
3.3.3. Fases do RUP
O ciclo de desenvolvimento do RUP é dividido em 4 fases que são: Iniciação ou Concepção, Elaboração, Construção e Transição. O ciclo de vida termina com a entrega do produto final. Vale salientar que apesar das fases serem sequenciais, o RUP não é um processo que segue a o modelo cascata, pois dentro de cada fase as disciplinas são executadas de maneira iterativa e incremental [DANTAS, 2008] & [MORAES, 2006]. 
Cada uma de suas quatro fases compreende um momento distinto dentro do ciclo de vida de um projeto de engenharia de software e, portanto, dão maior ou menor foco em algumas disciplinas, de acordo com a necessidade do projeto no decorrer de sua execução. São elas:
· Iniciação – foca nadefinição do escopo e análise da viabilidade econômica do projeto. Essa fase endereça riscos de requisitos e negócio antes de continuar com o projeto.
· Elaboração – foca nos riscos técnicos e arquiteturais. O escopo deve ser revisado e definido em detalhes. A maior parte dos requisitos funcionais e não-funcionais deve ser definida neste ponto. Os requisitos não funcionais podem ser encarados como fatores críticos para o sucesso, que descrevem o grau de risco envolvido no desenvolvimento do sistema.
· Construção – foca no tratamento dos riscos lógicos envolvidos na construção do produto. A fase de construção é de certa forma um processo de manufatura, em que a ênfase está no gerenciamento de recursos, pessoas e controle de operações para otimizar custos, codificações e qualidade.
· Transição – está associada com a entrega do produto ao usuário final, o qual pode requisitar treinamento, bem como encontrar bugs que precisem ser consertados. Muitas iterações podem ser necessárias antes que o usuário assine o aceite formal do sistema.
3.4 Disciplinas RUP
Uma disciplina no RUP expressa todas as atividades que devem ser realizadas para produzir um conjunto de artefatos. O RUP organiza suas disciplinas da seguinte forma [PERRELLI, 2009]:
· Fluxos de processo correspondem às atividades de desenvolvimento: modelagem de negócios, requisitos, análise e projeto, implementação, testes e implantação.
· Fluxos de suporte correspondem às atividades de gerenciamento e infraestrutura: gerenciamento de configuração e mudanças, gerenciamento de projeto e ambiente.
As disciplinas dos fluxos de processo são descritas a seguir:
· Modelagem do negócio: Os objetivos desta disciplina são compreender a estrutura e a dinâmica da organização-alvo; entender os problemas da organização; fazer com que os clientes e desenvolvedores tenham um entendimento comum em relação à organização e obter os requisitos necessários do sistema para sustentar a organização.
A disciplina de Modelagem e Negócios é baseada em modelos de casos de uso de negócio e modelo de objeto de negócio. O modelo de caso de uso de negócio descreve uma sequência de atividades necessárias para fornecer um resultado para o ator de negócio e o modelo de objetos de negócio descreve a realização dos casos de uso de negócio.
· Requisitos: Na disciplina de requisitos o foco é manter concordância entre os clientes e as partes interessadas no que diz respeito àquilo que o sistema deve fazer; fornecer aos desenvolvedores uma melhor compreensão dos requisitos do sistema; ter uma base para estimar custos e prazos de desenvolvimento do sistema e definir uma interface para o usuário ter um entendimento de como o sistema funcionará de acordo com as suas necessidades. 
Os modelos de caso de uso de negócio e objetos de negócio produzidos na disciplina de Modelagem e Negócio servirão como informação importante para esse fluxo. Além desses documentos, serão criados um documento de visão, um modelo de casos de uso, e a especificação suplementar. O documento de visão descreve qual o entendimento que as partes envolvidas do sistema têm dele. O Modelo de casos de uso descreve as funções fornecidas pelo sistema, onde cada caso de uso representa uma sequência de ações que resultam em valor para um ator especifico. A Especificação suplementar captura os requisitos que não são capturados pelos casos de uso no modelo de casos de uso. Exemplos de especificação suplementar são: definição de atributos de qualidade, confiabilidade e usabilidade do sistema, bem como a definição da tecnologia necessária para colocar o sistema em uso.
· Análise e Projeto: Os objetivos desse fluxo são: derivar o projeto do sistema a partir dos requisitos; obter uma arquitetura robusta do sistema e adaptar o projeto de acordo com o ambiente de implementação. O modelo de análise e projeto é o principal produto dessa disciplina. O modelo de análise e projeto possui a realização dos casos de uso. A realização de casos de uso expressa o modelo de projeto associado a cada caso de uso, um exemplo seria os diagramas de classes associados às classes e subsistemas participantes da implementação de cada caso de uso.
· Implementação: O objetivo é construir um sistema, produzindo o código em termos de subsistemas de implementação organizados em camadas; implementar classes e objetos em termos de componentes (arquivo fonte, executável, binários, etc.). A disciplina de implementação limita o seu escopo de maneira que as classes individuais possam ser testadas em unidades.
· Teste: A disciplina de teste atua em vários aspectos como uma provedora de serviços a outras disciplinas. O teste foca principalmente na avaliação da qualidade do produto, realizada através de algumas práticas, tais como: encontrar e documentar erros no software, avisar sobre a qualidade geral observada no software, validar as funções da maneira que foram projetadas, verificar se os requisitos foram implementados de forma correta, entre outras. 
· Implantação: Descreve as atividades que possibilitam que o software seja disponibilizado para o usuário final. A ênfase da disciplina de implantação é testar o produto no ambiente de implantação, onde são realizados testes beta antes do produto ser entregue ao usuário final.
As disciplinas dos fluxos de suporte são descritas a seguir:
· Ambiente: Esta disciplina centraliza-se nas atividades necessárias à configuração do processo para um projeto. Ao fazer isso, ela também serve de suporte a todas as outras disciplinas. A meta das atividades dessa disciplina é organizar o ambiente de desenvolvimento de software (processos e ferramentas) que dará suporte à equipe de desenvolvimento.
· Gerência de configuração e mudanças: O gerenciamento de configuração e mudanças envolve a identificação de itens de configuração, restrições a mudanças nestes itens, verificação de mudanças feitas nos itens e definição e gerenciamento das configurações dos mesmos durante o processo de desenvolvimento. Os métodos, processos e ferramentas que são usados para fazer esse controle em uma organização podem ser considerados como o sistema de gerência de configuração (SGC). O SGC manuseia informações importantes sobre o processo de desenvolvimento, sobre a implantação e manutenção do software, além de conservar o acervo de artefatos potencialmente reusáveis que resultam da execução destes processos.
O SGC é essencial para o controle dos artefatos produzidos por várias pessoas que trabalham em um projeto. O controle ajuda a evitar desordens custosas e garante que os artefatos resultantes não sejam conflitantes em relação a questões como: atualização simultânea, notificação de mudanças nos artefatos compartilhados pelos desenvolvedores, e múltiplas versões.
· Gerência de projetos: O gerenciamento de projetos de software é a arte de balancear os objetivos, o gerenciamento de riscos e as restrições para entregar, com sucesso, um produto que esteja de acordo com as necessidades dos clientes e usuários. O propósito do fluxo de gerenciamento de projetos é fornecer um processo para o gerenciamento de projetos de software; bem como providenciar guias para o planejamento, recrutamento de pessoal, execução e monitoração dos projetos.
3.5 Testes de Software
Teste: A disciplina de teste atua em vários aspectos como uma provedora de serviços a outras disciplinas. O teste foca principalmente na avaliação da qualidade do produto, realizada através de algumas práticas, tais como: encontrar e documentar erros no software, avisar sobre a qualidade geral observada no software, validar as funções da maneira que foram projetadas, verificar se os requisitos foram implementados de forma correta, entre outras. 
Existem diferentes tipos de testes que podem ser aplicados num software para identificar suas falhas, sendo as principais:
– Teste da caixa branca – utiliza o aspecto interno do programa/sistema, o código fonte, para avaliar seus componentes. Ele também é conhecido como teste orientado à lógica ou estrutural. Podem ser analisados itens como: fluxo dos dados,condição, ciclos etc. Na hora de implementá-lo é preciso verificar a criticidade, a complexidade, a estrutura e o nível de qualidade que se pretende obter do programa, envolvendo confiança e segurança;
– Teste da caixa preta – diferente do teste anterior, que prioriza os aspectos internos, o teste da caixa preta verifica aspectos externos. Os requisitos funcionais do sistema são avaliados. Não se observa o modo de funcionamento, sua operação, tendo como foco as funções que deverão ser desempenhadas pelo programa. Desse modo, avalia-se se um grupo de entrada de dados resultou nas saídas pretendidas, levando-se em consideração a especificação do programa. Ou seja, o que se esperava que o software deveria fazer. É conhecido também como técnica funcional;
– Teste da caixa cinza – esse tipo de teste une os dois anteriores, por isso o termo “cinza”. Avalia tanto os aspectos internos quanto os externos, de entrada e saída. Pode utilizar-se de engenharia reversa;
– Teste de regressão – esse consiste em realizar testes a cada versão de um software, onde se modificam-se funcionalidades. Desse modo, evita-se que erros que foram corrigidos antes no software antes voltem a aparecer na hora de se incrementar algo novo a ele.
– Teste de unidade – testa-se unidades menores de um software, de modo isolado, para ver se todas funcionam adequadamente;
– Teste de integração – depois das unidades testadas, realiza-se uma verificação se elas funcionam juntas, integradas. Pode ocorrer delas apresentarem incompatibilidades ao funcionarem em conjunto, mesmo após terem sido aprovadas no teste de unidade;
– Teste de carga – esse teste é feito para avaliar os limites de uso do software, o quanto ele suporta em volume de informações, tráfego etc. sem que apresente erros;
– Teste de usabilidade – esse teste é feito por um pequeno grupo de usuários para ver se o software satisfaz as suas necessidades. Nesse teste analisa-se como o usuário usa o sistema, verificando onde ele tem mais dificuldade. Ouve-se também suas impressões, porém é preciso confrontá-las com as observações do avaliador;
– Teste de stress – aqui leva-se o software ao seu limite de potência e funcionamento, para mais ou para menos, de modo a avaliar em qual ponto ele deixa de funcionar adequadamente. Isso é feito para verificar se suas especificações máximas ou mínimas de uso estão corretas.
4. CONCLUSÃO
Neste trabalho abordamos o estudo do modelo de desenvolvimento RUP (Rational Unified Process – Processo Unificado da Rational) e sua relação com a UML (Unified Modelling Language – Linguagem de Modelagem Unificada).
Abordamos os mais usados diagramas utilizados na UML, e suas principais características e funcionalidades. Ressaltamos também as disciplinas que compõe o RUP e como emprega-las em cada etapa nos processos de desenvolvimento dos softwares.
Além disso falamos de como implementar os testes ao longo do desenvolvimento e entrega de um software. Através da realização deste trabalho adquirimos conhecimento das fases de um projeto, como implementar os diagramas da UML e introduzir as disciplinas do modelo de desenvolvimento RUP no projeto afim de ter processos precisos e com um resultado esperado e as diferentes formas de testes nos sistemas ao decorrer dos processos.
5. REFERENCIAS 
[Boehm 1988] Boehm, B. (1988) A Spiral Model of Software Development and Enhancement Computer, Vol. 21, 5 (5), May 1988, pp. 61-72. 
Dantas, Fernando (2008) “Study Guide IBM Rational Unified Process – RUP 2003”. Disponível em http://si.uniminas.br/~marcio/rup/Resumo_Livro_RUP_Made_Easy.pdf. Último acesso em 20/11/2020.
Kruchten, Philippe. Introdução ao RUP Rational Unified Process, 2003. Addison Wesley Logan.
Pressman, Roger S. Engenharia de Software – Uma abordagem Profissional; ed. 7°. 2011, The McGraw-Hill Companies, Inc., New York, NY, EUA.