SISTEMA DE ENSINO PRESENCIAL CONECTADO

SUPERIOR TECNOLÓGICO EM ANÁLISE E DESENVOLVIMENTO DE

SISTEMAS
JEDIDIAH EBER SANTOS GOMES

ANÁLISE E DESENVOLVIMENTO:
Suas relações e dependências.
JEDIDIAH EBER SANTOS GOMES

Londrina
2010
ANÁLISE E DESENVOLVIMENTO:
Suas relações e dependências.

Trabalho apresentado a disciplina Análise de Sistemas I

da Universidade Norte do Paraná - UNOPAR

Prof. Simone Sawasaki Tanaka

Londrina
2010
 SUMÁRIO

1 INTRODUÇÃO...........................................................................................................3
2 Modelos ciclo de vida.................................................................................................4
3 Processos ageis.......................................................................................................10
4 RUP..........................................................................................................................15
5 Conclusão.................................................................................................................21
REFERÊNCIAS..........................................................................................................22
 3

1 INTRODUÇÃO

Perceber que atividades fazem parte do processo de engenharia de

software é o primeiro passo para o concretizar, mas é também importante perceber
como as actividades do processo se relacionam umas com as outras para que se
torne visível todo o processo de desenvolvimento. Veremos isso nas próximas
paginas.
 4

2 MODELOS CICLO DE VIDA

O termo modelo do ciclo de vida é utilizado para descrever um

modelo que visa descrever um grupo de actividades e a forma como elas se
relacionam. Os modelos mais sofisticados incluem ainda uma descrição de quando e
como se deve mover de uma actividade para a próxima e os deliverables que devem
ser produzidos em cada etapa. A razão pela qual estes modelos são tão conhecidos
é o facto ajudarem as equipas de desenvolvimento, e em particular os gestores, a
obter uma visão geral do projecto de forma a ser possível segui-lo passo a passo,
saber que deliverables foram especificados, o alocamento de recursos e os
objectivos propostos. Estes "modelos de ciclo de vida" ou "modelos de processos"
são tipicamente produzidos a partir de uma perspectiva de que poderão existir vários
modelos para o mesmo processo. Nenhum modelo é capaz de dar uma visão
completa de um determinado processo.

2.1 ATIVIDADES DO PROCESSO DE ENGENHARIA DE REQUISITOS

Diferentes tipos de organizações abordam a engenharia de

requisitos de formas radicalmente diferentes. Uma companhia aeroespacial que se
encontre a especificar sistemas de software e hardware muito complexos não utiliza
o mesmo processo de engenharia de requisitos que uma outra companhia que
desenvolve produtos de consumo para computadores pessoais. No entanto, as
diferenças entre estes processos encontram-se geralmente no nível de detalhe dos
processos. Num nível abstracto, todos os processos de engenharia de requisitos
podem ser descritos pelo modelo mostrado na figura anterior. Antes de apresentar
os modelos de ciclo de vida para o processo de engenharia de requisitos, torna-se
necessário compreender melhor as actividades nele envolvidas. As actividades do
processo de engenharia de requisitos são as seguintes:
 5

2.1.1 Levantamento de Requisitos

Os requisitos do sistema são obtidos através de consultas aos

stakeholders, documentação do sistema, conhecimento do domínio e estudos de
mercado. Este processo é também conhecido como aquisição de requisitos ou
descoberta de requisitos.

2.1.2 Análise e Negociação de Requisitos

Os requisitos são analisados em detalhe e os diferentes

stakeholders negociam para decidirem que requisitos serão aceitos. Este processo é
necessário visto que é inevitável o aparecimento de conflitos entre requisitos de
diferentes fontes, existência de informação incompleta ou então os requisitos podem
ser incompatíveis com o orçamento disponível para o desenvolvimento do sistema.
Existe, no entanto, alguma flexibilidade no negociamento de requisitos para que seja
possível concordar acerca de conjunto de requisitos para o sistema.

2.1.3 Documentação de Requisitos

Os requisitos acordados durante o processo de negociação são

documentados com um nível de detalhe apropriado. Em geral, é necessário existir
um documento de especificação de requisitos que seja compreendido por todos os
stakeholders. Isto significa que os requisitos devem ser detalhados utilizando
linguagem natural e diagramas. Podem também ser produzidos documentos de
sistema mais detalhados tais como modelos de sistema.

2.1.4 Validação de Requisitos

Todos os requisitos obtidos nas actividades anteriores devem ser

cuidadosamente verificados para apurar se estão completos e são consistentes.
Este processo tem como finalidade detectar potenciais problemas no documento de
 6

especificação de requisitos antes que este seja utilizado como base para o
desenvolvimento do sistema.

2.2 MODELOS DE CICLO DE VIDA

Os modelos existentes possuem diferentes graus de sofisticação e

complexidade. Para projetos que envolvem uma equipe de desenvolvimento pouco
numerosa e experiente, o mais adequado será provavelmente um processo simples.
No entanto, para sistemas maiores que envolvem equipes de dezenas ou centenas
de elementos e milhares de utilizadores, um processo simples não é suficiente para
oferecer a estrutura de gestão e disciplina necessárias à engenharia de um bom
produto de software. Desta forma, é necessário algo mais formal e disciplinado. É
importante fazer notar que isto não significa que se perca em inovação ou que se
põe entraves à criatividade. Significa apenas que é utilizado um processo bem
estruturado para permitir a criação de uma base estável para a criatividade.

Por mais simples ou complexo que possa parecer, um modelo de

ciclo de vida de um projeto é, de facto, uma versão simplificada da realidade. É
suposto ser uma abstracção e, tal como todas as boas abstracções, apenas a
quantidade de detalhe necessária ao trabalho em mãos deve ser incluída. Qualquer
organização que deseje por um modelo de ciclo de vida em prática irá necessitar de
adicionar detalhes específicos para dadas circunstâncias e diferentes culturas. Por
exemplo, a Microsoft quis manter uma cultura de pequena equipa e ao mesmo
tempo tornar possível o desenvolvimento de grandes e complexos produtos de
software.

Na próxima seção, é introduzida uma interpretação do aspecto que

um modelo de ciclo de vida deve ter em termos de engenharia de requisitos para
projectos de software. Dependendo do tipo de sistema em desenvolvimento pode
não ser completamente possível ou até apropriado seguir os modelos
rigorosamente. É de notar também que para por em prática um destes modelos e
aplica-lo a um projecto real seria necessário adicionar mais detalhe.
 7

2.2.1 Modelos em Engenharia de Software e Requisitos

A engenharia de software tem produzido inúmeros modelos de ciclo

de vida, incluindo os modelos de cascata, espiral e desenvolvimento rápido de
aplicações (RAD). Antes do modelo de cascata ser proposto em 1970, não havia
concordância em termos dos métodos a levar a cabo no desenvolvimento de
software. Desde então ao longo dos anos muitos modelos têm sido propostos
refletindo assim a grande variedade de interpretações e caminhos que podem ser
tomadas no desenvolvimento de software. Neste artigo, foi decidida a inclusão
destes modelos por duas razões: primeiro porque são representativos dos modelos
utilizados na indústria e foi já provado o seu sucesso, e segundo porque mostram
como a ênfase no desenvolvimento de software mudou gradualmente de forma a
incluir uma visão mais interativa e centrada no utilizador.

2.2.1.1 Modelo em Cascata

O modelo de ciclo de vida em cascata foi o primeiro modelo a ser

conhecido em engenharia de software e está na base de muitos ciclos de vida
utilizados hoje em dia. Este consiste basicamente num modelo linear em que cada
passo deve ser completado antes que o próximo passo possa ser iniciado. Por
exemplo, a análise de requisitos deve ser completada antes que o desenho do
sistema possa ser iniciado. Os nomes dados a cada passo variam, assim como varia
a definição exata de cada um deles, mas basicamente o ciclo de vida começa com a
análise de requisitos movendo-se de seguida para a fase de desenho, codificação,
implementação, teste e finalmente manutenção do sistema. Uma das grandes falhas
deste modelo é o fato de os requisitos estarem constantemente a mudar já que os
negócios e ambiente em que se inserem mudam rapidamente. Isto significa que não
faz sentido parar os requisitos durante muito tempo, enquanto o desenho e
implementação do sistema são completados. Foi então reconhecido que seria
necessário dar feedback às atividades iniciais a partir do momento em que este
modelo começou a ser usado em grande escala. A ideia de interacção não foi
incorporada na filosofia do modelo de cascata. Neste momento, é incluído algum
 8

nível de interação na maior parte das versões deste modelo e são comuns sessões
de revisão entre os elementos responsáveis pelo desenvolvimento do sistema. No
entanto, a possibilidade de revisão e avaliação com os utilizadores do sistema não
está contemplada neste modelo.

2.2.1.2 Modelo em Espiral

Durante muitos anos, o modelo cascata foi a base da maior parte do

desenvolvimento de projetos de software, mas em 1988 Barry Boehm sugeriu o
modelo em espiral. Do modelo em espiral para desenvolvimento de software saltam
a vista dois aspectos: a análise de risco e prototipagem. O modelo espiral incorpora-
os de uma forma interativa permitindo que as ideias e o progresso sejam verificados
e avaliados constantemente. Cada interação à volta da espiral pode ser baseada
num modelo diferente e pode ter diferentes atividades. No caso da espiral, não foi a
necessidade do envolvimento dos utilizadores que inspirou a introdução de interação
mas sim a necessidade de identificar e controlar riscos. No modelo espiral para
engenharia de requisitos mostra-se que as diferentes atividades são repetidas até
uma decisão ser tomada e o documento de especificação de requisitos ser aceito.
Se forem encontrados problemas numa versão inicial do documento, reentra-se nas
fases de levantamento, análise, documentação e validação. Isto repete-se até que
seja produzido um documento aceitável ou até que fatores externos, tais como
prazos e falta de recursos ditem o final do processo de engenharia de requisitos.

2.2.1.3 Modelo Iterativo e Incremental

O modelo de ciclo de vida incremental e iterativo foi proposto como

uma resposta aos problemas encontrados no modelo em cascata. Um processo de
desenvolvimento segundo essa abordagem divide o desenvolvimento de um produto
de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas
as fases de análise, projeto, implementação e testes. Essa característica contrasta
com a abordagem clássica, na qual as fases de análise, projeto, implementação e
testes são realizadas uma única vez.
 9

Cada um dos ciclos considera um subconjunto de requisitos. Os

requisitos são desenvolvidos uma vez que sejam alocados a um ciclo de
desenvolvimento. No próximo ciclo, outro subconjunto dos requisitos é considerado
para ser desenvolvido, o que produz um novo incremento do sistema que contém
extensões e refinamentos sobre o incremento anterior.

Assim, o desenvolvimento evolui em versões, através da construção

incremental e iterativa de novas funcionalidades até que o sistema completo esteja
construído. Note que apenas uma parte dos requisitos é considerada em cada ciclo
de desenvolvimento. Na verdade, um modelo de ciclo de vida iterativo e incremental
pode ser visto como uma generalização da abordagem em cascata: o software é
desenvolvimento em incrementos e cada incremento é desenvolvido em cascata
(figura).

A abordagem incremental e iterativa somente é possível se existir

um mecanismo para dividir os requisitos do sistema em partes, para que cada parte
seja alocada a um ciclo de desenvolvimento. Essa alocação é realizada em função
do grau de importância atribuído a cada requisito.

2.2.1.3.1 O PROCESSO ITERATIVO

A noção de Processo Iterativo corresponde à ideia de “melhorar (ou

refinar) pouco - a - pouco” o sistema (iterações). Em cada iteração a equipe de
desenvolvimento identifica e especifica os requisitos relevantes, cria um projeto
utilizando a arquitetura escolhida como guia, implementa o projeto em componentes
e verifica se esses componentes satisfazem os requisitos. Se uma iteração atinge os
seus objetivos, o desenvolvimento prossegue com a próxima iteração, caso contrário
a equipa deve rever as suas decisões e tentar uma nova abordagem.

Portanto, o âmbito do sistema não é alterado, mas o seu detalhe vai

aumentando em iterações sucessivas. Um excelente exemplo de aplicação do
processo iterativo encontra-se no trabalho artístico, em que o resultado final de uma
obra sofre inúmeras iterações.
 10

3 PROCESSOS AGEIS

3.1 EXTREME PROGRAMMING

Programação extrema (do inglês eXtreme Programming), ou

simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que
irão desenvolver software com requisitos vagos e em constante mudança. Para isso,
adota a estratégia de constante acompanhamento e realização de vários pequenos
ajustes durante o desenvolvimento de software.

Os quatro valores fundamentais da metodologia XP são:

comunicação, simplicidade, feedback e coragem. A partir desses valores, possui
como princípios básicos: feedback rápido, presumir simplicidade, mudanças
incrementais, abraçar mudanças e trabalho de qualidade.

Dentre as variáveis de controle em projetos (custo, tempo, qualidade

e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização
de funcionalidades que representem maior valor possível para o negócio. Desta
forma, caso seja necessário a diminuição de escopo, as funcionalidades menos
valiosas serão adiadas ou canceladas.

A XP incentiva o controle da qualidade como variável do projeto,

pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é
compensado por perdas (ou até impedimentos) a médio e longo prazo.

3.1.1 Valores

• Comunicação

• Simplicidade

• Feedback

• Coragem
 11

• Respeito

3.1.2 Principios Basicos

• Feedback rápido

• Presumir simplicidade

• Mudanças incrementais

• Abraçar mudanças

• Trabalho de alta qualidade.

3.2 EXTREME PROGRAMMING

Para aplicar os valores e princípios durante o desenvolvimento de

software, XP propõe uma série de práticas. Há uma confiança muito grande na
sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes
de outras.

3.2.1 Jogo de Planejamento

O desenvolvimento é feito em iterações semanais. No início da

semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades.
Essa reunião recebe o nome de Jogo do Planejamento. Nela, o cliente identifica
prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo
e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto.
Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de
escopo negociável, que difere significativamente das formas tradicionais de
contratação de projetos de software. Ao final de cada semana, o cliente recebe
novas funcionalidades, completamente testadas e prontas para serem postas em
produção.
 12

3.2.2 Pequenas Versões

A liberação de pequenas versões funcionais do projeto auxilia muito

no processo de aceitação por parte do cliente, que já pode testar uma parte do
sistema que está comprando. As versões chegam a ser ainda menores que as
produzidas por outras metodologias incrementais, como o RUP.

3.2.3 Metafora

Procura facilitar a comunicação com o cliente, entendendo a

realidade dele. O conceito de rápido para um cliente de um sistema jurídico é
diferente para um programador experiente em controlar comunicação em sistemas
em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do
cliente para o significado que ele espera dentro do projeto.

3.2.4 Projeto Simples

Simplicidade é um princípio da XP. Projeto simples significa dizer

que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste"
possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema,
você vai fazer o código exato para que esta funcionalidade seja implementada, sem
se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum
ao adotar essa prática é a confusão por parte dos programadores de código simples
e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução
mais simples por parte de projeto. Esse entendimento é fundamental para o bom
andamento do XP. Código fácil deve ser identificado e substituído por código
simples.

3.2.5 Time Coeso

A equipe de desenvolvimento é formada pelo cliente e pela equipe

de desenvolvimento.
 13

3.2.6 Teste de Aceitação

São testes construídos pelo cliente e conjunto de analistas e

testadores, para aceitar um determinado requisito do sistema.

3.2.7 Ritmo Sustentavel

Trabalhar com qualidade, buscando ter ritmo de trabalho saudável

(40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas
quando trouxerem produtividade para a execução do projeto. Outra prática que se
verifica neste processo é a prática de trabalho energizado, onde se busca trabalho
motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem
estar sempre em harmonia.

3.2.8 Reuniões em Pé

Reuniões em pé para não se perder o foco nos assuntos, produzindo

reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela
equipe.

3.2.9 Posse Coletiva

O código fonte não tem dono e ninguém precisa solicitar permissão

para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas
as partes do sistema.

3.2.10 Programação em Pares

É a programação em par/dupla num único computador. Geralmente

a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como
um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a
codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades.
 14

Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo
assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe,
melhorando a qualidade do código fonte gerado.

3.2.11 Padrões de Codificações

A equipe de desenvolvimento precisa estabelecer regras para

programar e todos devem seguir estas regras. Desta forma parecerá que todo o
código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou
100 membros.

3.2.12 Desenvolvimento Orientado a Testes

Primeiro crie os testes unitários (unit tests) e depois crie o código

para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra
o processo de desenvolvimento de muitos anos. Só que os testes unitários são
essenciais para que a qualidade do projeto seja mantida.

3.2.13 Relatoração

É um processo que permite a melhoria continua da programação,

com o mínimo de introdução de erros e mantendo a compatibilidade com o código já
existente. Refabricar melhora a clareza (leitura) do código, divide-o em módulos
mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte.

3.2.14 Integração Continua

Sempre que produzir uma nova funcionalidade, nunca esperar uma

semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de
conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua
permite saber o status real da programação.
 15

4 RUP

O RUP, abreviação de Rational Unified Process (ou Processo

Unificado Racional), é um processo proprietário de Engenharia de software criado
pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome
IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se
uma brand na área de Software, fornecendo técnicas a serem seguidas pelos
membros da equipe de desenvolvimento de software com o objetivo de aumentar a
sua produtividade no processo de desenvolvimento.

O RUP usa a abordagem da orientação a objetos em sua concepção

e é projetado e documentado utilizando a notação UML (Unified Modeling Language)
para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas
comercialmente.

É um processo considerado pesado e preferencialmente aplicável a

grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser
amplamente customizável torna possível que seja adaptado para projetos de
qualquer escala. Para a gerência do projeto, o RUP provê uma solução disciplinada
de como assinalar tarefas e responsabilidades dentro de uma organização de
desenvolvimento de software.

O RUP é, por si só, um produto de software. É modular e

automatizado, e toda a sua metodologia é apoiada por diversas ferramentas de
desenvolvimento integradas e vendidas pela IBM através de seus "Rational Suites".

Métodos concorrentes no campo da engenharia de software incluem

o "Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) como a
Programação Extrema (XP-Extreme Programming), Scrum, FDD e outros.

4.1 PRINCIPIOS E MELHORES PRATICAS

RUP é baseado em um conjunto de princípios de desenvolvimento

de software e melhores práticas, por exemplo:

1. Desenvolvimento de software iterativo

 16

2. Gerenciamento de requisitos

3. Uso de arquitetura baseada em componente

4. Modelagem visual de software

5. Verificação da qualidade do software

6. Controle de alteração no software

4.1.1 Desenvolvimento iterativo

Dado o tempo gasto para desenvolver um software grande e

sofisticado, não é possível definir o problema e construir o software em um único
passo. Os requerimentos irão freqüentemente mudar no decorrer do
desenvolvimento do projeto, devido a restrições de arquitetura, necessidades do
usuário ou a uma maior compreensão do problema original. Alterações permitem ao
projeto ser constantemente refinado, além de assinalarem itens de alto risco do
projeto como as tarefas de maior prioridade. De forma ideal, ao término de cada
iteração haverá uma versão executável, o que ajuda a reduzir o risco de
configuração do projeto, permitindo maior retorno do usuário e ajudando ao
desenvolvedor manter-se focado.

O RUP usa desenvolvimento iterativo e incremental pelas seguintes

razões:

• A integração é feita passo a passo durante o processo de

desenvolvimento, limitando-se cada passo a poucos elementos

• A integração é menos complexa, reduzindo seu custo e

aumentado sua eficiência

• Partes separadas de projeto e/ou implementação podem

ser facilmente identificadas para posterior reuso

• Mudanças de requisitos são registradas e podem ser

acomodadas
 17

• Os riscos são abordados no inicio do desenvolvimento e

cada iteração permite a verificação de riscos já percebidos bem como a identificação
de novos

• Arquitetura de software é melhorada através de um

escrutino repetitivo

Usando iterações, um projeto terá um plano geral, como também

múltiplos planos de iteração. O envolvimento dos stakeholders é freqüentemente
encorajado a cada entrega. Desta maneira, as entregas servem como uma forma de
se obter o comprometimento dos envolvidos, promovendo também uma constante
comparação entre os requisitos e o desenvolvimento da organização para as
pendências que surgem.

4.1.2 Gerenciamento de requisitos

O Gerenciamento de requisitos no RUP está concentrado em

encontrar as necessidades do usuário final pela identificação e especificação do que
ele necessita e identificando aquilo que deve ser mudado. Isto traz como benefícios:

• A correção dos requisitos gera a correção do produto,

desta forma as necessidadades dos usuários são encontradas.

• As características necessárias serão incluídas, reduzindo

o custo de desenvolvimentos posteriores.

RUP sugere que o gerenciamento de requisitos tem que seguir as

atividades:

• Análise do problema é concordar com o problema e criar

medições que irão provar seu valor para a organização

• Entender as necessidades de seus stakeholders é

compartilhar o problema e valores com os stakeholders-chave e levantar quais as
necessidades que estão envolvidas na elaboração da ideia
 18

• Definir o problema é a definição das características das

necessidades e esquematização dos casos de uso, atividades que irão facilmente
mostrar os requerimentos de alto-nível e esboçar o modelo de uso do sistema

• Gerenciar o escopo do sistema trata das modificações de

escopo que serão comunicadas baseadas nos resultados do andamento e
selecionadas na ordem na qual os fluxogramas de casos de uso são atacados

• Refinar as definições do sistema trata do detalhamento

dos fluxogramas de caso de uso com os stakeholders de forma a criar uma
especificação de requerimentos de software que pode servir como um contrato entre
o seu grupo e o do cliente e poderá guiar as atividades de teste e projeto

• Gerenciamento das mudanças de requisitos trata de

como identificar as chegadas das mudanças de requerimento num projeto que já
começou

4.1.3 Uso de arquitetura baseada em componentes

Arquitetura baseada em componentes cria um sistema que é

facilmente extensível, intuitivo e de fácil compreensão e promove a reusabilidade de
software. Um componente freqüentemente se relaciona com um conjunto de objetos
na programação orientada ao objeto.

Arquitetura de software aumenta de importância quando um sistema

se torna maior e mais complexo. RUP foca na produção da arquitetura básica nas
primeiras iterações. Esta arquitetura então se torna um protótipo nos ciclos iniciais
de desenvolvimento. A arquitetura desenvolve-se em cada iteração para se tornar a
arquitetura final do sistema. RUP também propõe regras de projeto e restrições para
capturar regras de arquitetura. Pelo desenvolvimento iterativo é possível identificar
gradualmente componentes os quais podem então ser desenvolvidos, comprados ou
reusados. Estes componentes são freqüentemente construídos em infra-estruturas
existentes tais como CORBA e COM, ou JavaEE, ou PHP.
 19

4.1.4 Modelagem visual de software

Abstraindo sua programação do seu código e representando-a

usando blocos de construção gráfica constitui-se de uma forma efetiva de obter uma
visão geral de uma solução. Usando esta representação, recursos técnicos podem
determinar a melhor forma para implementar a dado conjunto de interdependências
lógicas. Isto também constrói uma camada intermediária entre o processo de
negócio e o código necessário através da tecnologia da informação. Um modelo
neste contexto é uma visualização e ao mesmo tempo uma simplificação de um
projeto complexo. RUP especifica quais modelos são necessários e porque.

A Linguagem modelagem unificada (UML) pode ser usada para

modelagem de Casos de Uso, diagrama de classes e outros objetos. RUP também
discute outras formas para construir estes modelos.

4.1.5 Verificar qualidade de software

Garantia da qualidade de software é o ponto mais comum de falha

nos projetos de software, desde que isto é freqüentemente algo que não se pensa
previamente e é algumas vezes tratado por equipes diferentes. O RUP ajuda no
planejamento do controle da qualidade e cuida da sua construção em todo processo,
envolvendo todos os membros da equipe. Nenhuma tarefa é especificamente
direcionada para a qualidade; o RUP assume que cada membro da equipe é
responsável pela qualidade durante todo o processo. O processo foca na descoberta
do nível de qualidade esperado e provê testes nos processos para medir este nível.

4.1.6 Controle de alterações no software

Em todos os projetos de software, mudanças são inevitáveis. RUP

define métodos para controlar, rastrear e monitorar estas mudanças. RUP também
define espaços de trabalho seguros (do inglês secure workspaces), garantindo que
um sistema de engenharia de software não será afetado por mudanças em outros
 20

sistemas. Este conceito é bem aderente com arquiteturas de software baseados em

componentização.
 21

5 CONCLUSÃO

Através das paginas anteriores vimos à relação que existe entre a

analise e a programação de um software, percebemos que é através da analise que
decidimos tudo o que, e como irá ser feito ou alterado em um software.
 22

REFERÊNCIAS

Wikipédia, a enciclopédia livre. http://pt.wikipedia.org/wiki/Programação_extrema .

Acessado em 09/09/2010.

Wikipédia, a enciclopédia livre. http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida .

Acessado em 09/09/2010.

Wikipédia, a enciclopédia livre.

http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process . Acessado em 09/09/2010

Wikipédia, a enciclopédia livre.

http://pt.wikipedia.org/wiki/Desenvolvimento_iterativo_e_incremental . Acessado em
09/09/2010