Engenharia e Qualidade de Software

Unidade I
Engenharia de Software e Processos de Apoio

Prof. Me. Edson Quedas Moreno

1
MORENO, Edson Quedas

Engenharia e Qualidade de Software (livro-texto I) / Edson

Quedas Moreno. São Paulo: Pós-Graduação Lato Sensu UNIP,
2019.

41 p. : il.

1. Engenharia de software. 2. Processo de software. I.

MORENO, Edson Quedas. II. Pós-Graduação Lato Sensu UNIP.
III. Título.
 APRESENTAÇÃO DO PROFESSOR-AUTOR

Possui mestrado em Engenharia de Produção pela

Universidade Paulista (UNIP), ênfase em Sistemas de
Informação (2002), graduação em Engenharia Eletrônica pela
Faculdade de Engenharia Industrial (FEI, 1983), ênfase em
Computação e pós-graduação lato sensu em Novas Tecnologias
de Ensino-Aprendizagem pela UniÍtalo (2011). Atuou na
coordenação de cursos de 1989 até 2016, pelas instituições
UniÍtalo e Kroton/Anhanguera. É atualmente professor e
conteudista de cursos de graduação e pós-graduação, na área de
negócios, computação e informação pelas instituições UNIP e UniÍtalo. Exerceu
atividades de professor, tutor e conteudista, desde 1989, pelas instituições Senac,
Kroton/Anhanguera, FECAP. MBA em Engenharia de Software e da Informação pela
UNINOVE. Na parte corporativa: desde 2002, é diretor da empresa ASSERTI, de 2009
até 2012, sócio das empresas Consultoria EaD e ITGVBR, de 1994 até 2000 gerente
de sistemas na Panrotas Editora, de 1985 até 1994, analista de sistemas pela
Sistemas e Computadores (SISCO) e, de 1983 até 1985, Programador pela
Digilab/Bradesco. Áreas de conhecimento: computação e informação – ênfase em
engenharia de software, projetos de software e de sistemas e tecnologias de ensino a
distância; e em engenharia de produção – com ênfase em administração, projetos,
logística e produção. Em aspectos comunitários: de 2005 a 2006 foi gerente do
Departamento de Extensões de Assuntos Comunitários pela UniÍtalo (DEAC), em
2006 projetou e efetivou o Projeto Farol Verde (educação para crianças carentes) com
apoio do Centro Universitário Ítalo Brasileiro, Prefeitura de São Paulo, em parceria
com o 12º BPM/M SP, e, em 2015, projetou e efetivou um Hackathon (maratona de
programação de software por 30 horas contínuas com a participação de 200 alunos),
com apoio da Kroton / Anhanguera e Microsoft, promovido pela Secretaria Municipal
de Promoção da Igualdade Racial da Prefeitura de São Paulo (SMPIR), em conjunto
com o Banco Interamericano de Desenvolvimento (BID).
SUMÁRIO
INTRODUÇÃO ........................................................................................................................................ 5
1. FUNDAMENTOS DA ENGENHARIA DE SOFTWARE .................................................................. 6
1.1. O produto software ..................................................................................................................... 7
1.1.1. Características do software ........................................................................................................ 7
1.2. Aplicações do software ............................................................................................................... 9
1.3. Qualidade, processos, métodos e ferramentas........................................................................ 11
1.4. Fábrica de software .................................................................................................................. 12
1.5. Mitos e realidades no desenvolvimento do software ............................................................... 13
1.6. Exercício discursivo comentado ............................................................................................... 15
2. PROCESSO DE SOFTWARE ....................................................................................................... 16
2.1. Processo de software e o desenvolvimento do projeto ............................................................ 16
2.1.1. Planejamento do processo ....................................................................................................... 17
2.1.2. Decomposição do processo ..................................................................................................... 18
2.1.3. Análise dos recursos para o projeto do processo .................................................................... 20
2.1.4. Recursos do projeto e do produto ............................................................................................ 20
2.2. Estrutura organizacional orientada por modelos de processo de software ............................. 21
2.3. Modelos de processo de software tradicionais ........................................................................ 22
2.3.1. Modelo Cascata (waterfall ou sequencial linear)...................................................................... 22
2.3.2. Prototipagem ............................................................................................................................ 24
2.3.3. Modelo incremental .................................................................................................................. 26
2.3.4. Modelo espiral .......................................................................................................................... 28
2.4. Rational Unified Process – Processo Unificado Racional (RUP) ............................................. 29
2.4.1. Características do RUP ............................................................................................................ 30
2.4.2. Fases e workflow (ou disciplinas de trabalho) .......................................................................... 32
2.5. Modelos de processo pessoal e de equipe .............................................................................. 36
2.5.1. Personal Software Process – Processo de Software Pessoal (PSP) ...................................... 36
2.5.2. Team Software Process – Processo de Software da Equipe (TSP) ........................................ 37
2.6. Exercício discursivo e comentado ............................................................................................ 38
REFERÊNCIAS ..................................................................................................................................... 40
BIBLIOGRAFIA...................................................................................................................................... 40
 INTRODUÇÃO

Os conceitos básicos da engenharia surgiram há uns 5.000 anos com a

engenharia civil, há uns 600 anos a administração de materiais e há uns 300 anos a
engenharia industrial. A engenharia de software tem apenas 50 anos! Pode-se dizer
que estamos no início da era do software. Com o computador o ser humano
automatiza o conhecimento. A humanidade prosperou nesses últimos 50 anos o que
não conseguiu em 4.950 anos. O software foi o responsável.
Na passagem do milênio, a questão passou a ser a “velocidade”. Os
empresários precisavam ter rapidez em estratégias, processos, transações
comerciais, na logística, na vida dos consumidores e no acesso às informações.
Em meados dos anos 1990 surge a internet e em consequência, o e-mail e a
agenda de grupo online, são componentes de um grande marco e um dos avanços
mais significativos, pois através deles vários outros sistemas de comunicação foram
criados. A Tecnologia da Informação é impulsionada.
Melhorou a tecnologia e os sistemas produtivos, começaram a ser usadas
ferramentas digitais para controlar as atividades básicas de produção e na gestão dos
negócios. A tecnologia da informação proporcionou alta velocidade nos
conhecimentos para competir no mundo dos negócios. É o começo um novo ciclo na
história da humanidade, a Era da Informação e do Conhecimento.
A engenharia de software neste novo ciclo fornece às empresas, mecanismos
de acesso instantâneo às informações, velocidade para lançar produtos antes da
concorrência, estatísticas atualizadas em tempo real para cada produto em qualquer
lugar do mundo, como condições básicas para se manter na vanguarda dos negócios.
Software e sistemas poderosos auxiliam neste desempenho. A indústria se
automatiza, eletroeletrônicos tornam-se digitais, a informação liga o planeta e as
pessoas.
Podemos dar até um nome para isso!
Vivemos hoje um “Sistema de Conhecimento Distribuído”.

Prof. Me. Edson Quedas Moreno

5
 1. FUNDAMENTOS DA ENGENHARIA DE SOFTWARE

As tecnologias atuais resultam da convergência de sistemas de computadores

e de sistemas de comunicação.
O que traz questões complexas para os engenheiros de software: hardware
diferente, diversos ambientes operacionais, regras do negócio que mudam
constantemente, adaptações a novas tecnologias e interfaces, e a ligação de todos
estes elementos.
O software é uma tecnologia indispensável para os negócios, ciência e
engenharia. O desenvolvimento de um sistema computacional seja ele voltado para
negócios, web, aplicação científica, automação industrial e outras aplicações, inicia- se
pelo software. O software é quem atende à necessidade (ou resolve um problema) de
cálculo, da automação de um trabalho manufaturado ou do negócio empresarial.
 Pressman, 2011 – “Software de computadores continua a ser a tecnologia
única mais importante no cenário mundial”.
 Sommerville, 2011 – “Produzir software que apresente uma boa relação
custo/benefício é essencial para o funcionamento das economias nacionais e
internacionais”.

 Só após dimensionar o tamanho, a complexidade e as exigências de

processamento é que será possível dimensionar e especificar a infraestrutura do
sistema computacional que suportará o software.

A engenharia de software projeta e constrói o produto software de

computador. Abrange programas que executam em computadores de qualquer
tamanho e arquitetura, documentos que incluem formas impressas e virtuais e dados
que combinam números e texto, mas também incluem representações de informação
em figuras, em vídeo e em áudio.
O software é desenvolvido ou passa por um processo de engenharia, não
é manufaturado. Os problemas de qualidade do hardware podem ser corrigidos pela
manufatura, o que não ocorre com o software. O custo do software está
concentrado no trabalho de engenharia, que contempla os seguintes itens:
 Especificação, documentação e procedimentos;
 Análise, projeto, codificação, implementação, testes, diagnósticos e
implantação;
 Suporte ao cliente/usuário.

O software continua sendo construído por encomenda. À medida que uma

disciplina de engenharia evolui, novos componentes são criados. No mundo do software
esses componentes ainda estão sendo aprimorados e estão apenas começando em
ampla escala.

6
 Esses componentes devem ser implementados de modo que possam ser
reusados, ou seja, que possam ser adaptados a novas plataformas e ambientes
operacionais. O reuso de um componente é uma atividade natural no processo de
engenharia. A reusabilidade do software é uma métrica de qualidade usada para avaliar
o quanto um programa ou parte dele pode ser usada em outras aplicações.

1.1. O produto software

O software é o produto mais importante desta última era. Devido a sua dualidade
com o hardware que com o passar do tempo melhora o desempenho, diminui o
tamanho e reduz o custo, um software bem elaborado permite que sua evolução
produza sistemas mais sofisticados. O software possui um duplo papel na
produção, não só pode constituir um produto completo, como também pode ser o
veículo de melhora de outro produto.
Exemplos:
 Como produto de software – podemos citar toda a linha de software que
normalmente são comercializados, tais como software de sistema e de aplicação. Um
exemplo simples seria o produto Word da Microsoft.
Existem dois tipos de produtos de software (SOMMERVILLE, 2006):
1. Produtos genéricos – são sistemas do tipo stand-alone, produzidos e
comercializados no mercado a qualquer cliente.
2. Produtos sob encomenda (ou personalizados) – são sistemas
encomendados por um cliente em particular, que é desenvolvido com base em
requisitos específicos para um determinado negócio.

 Como veículo de melhora de outros produtos:

 Software como veículo de melhora de outro software – são softwares
que, adaptados a outro software, produzem novas funções, melhoram o desempenho
e que em alguns casos podem ser usados de forma independente de quaisquer outros
programas como um produto completo. Exemplo: “Globalink” – software para tradução
de textos de línguas estrangeiras, que ao ser instalado no computador, uma nova
função é inserida no conjunto de funções do ambiente operacional e aplicações,
agregando valor a este ou pode também ser executado isoladamente sem perda de
recurso;
 Software como veículo de melhora de um produto industrial – é a
associação do software a um hardware específico de uma máquina, sensores ou outros
dispositivos. Tais produtos passam a ser automatizados. Exemplo: computadores de bordo,
dispositivos de segurança predial, elevadores, robôs e vários outros que ainda estão por vir.

1.1.1. Características do software

O software é desenvolvido ou passa por um processo de engenharia, não

é manufaturado. Na manufatura as mudanças necessárias a serem feitas nos

7
produtos, sejam por necessidade, correções ou melhorias, são feitas por substituições
de peças ou concerto. Os problemas de qualidade ou manutenção do hardware
podem ser corrigidos pela manufatura, o que não ocorre com o software.

 O software não “se desgasta”, mas “se deteriora”! O software não é suscetível aos
males ambientais, que causam desgaste do hardware, mas sim devido às mudanças que
ocorrem no ciclo de vida do software (PRESSMAN, 2011).

Quando o hardware se desgasta é substituído por outro sobressalente. Durante o

ciclo de vida, o software passará por modificações (manutenção, mudanças). À medida
que as modificações são feitas, é provável que novos defeitos sejam introduzidos,
causando dente na curva de taxa de falhas. Observe a figura 1:

Figura 1 – Gráficos comparativos da curva de falhas do hardware em relação à curva de falhas do software

Fonte: Pressman, 2011 (adaptado).

 Na figura 1 o gráfico da esquerda refere-se à “curva de falhas do hardware”,

também chamado na engenharia de “curva da bacia”. Esse gráfico mostra que quando
um produto é lançado no mercado ou adaptado a outros produtos (faixa da mortalidade
infantil), o índice de falhas é alto. No decorrer do tempo por processos revisionais e de
manutenção, essas falhas vão sendo reduzidas, até chegarem ao nível de estabilidade e
com o menor índice de falhas. Nesse patamar é determinada a vida útil do produto de
acordo com o seu período de estabilidade, mais a faixa de mortalidade infantil. Como é
um hardware fica sujeito ao desgaste. O índice de falhas aumenta com o tempo e
consequentemente aumenta o custo de manutenção. As manutenções sucessivas
crescem. E consequentemente o custo para manter o produto acaba por inviabilizá-lo e
é feito o seu descarte.
 Na figura 1 o gráfico da direita refere-se a “curva de falhas do software” –
diferente do hardware, após a faixa de estabilidade começam a ocorrer mudanças no
software, sejam elas provocadas a pedido do cliente ou algum outro fator, tais como,
mudança no ambiente operacional (hardware, capacidade limitada do sistema,
8
atualização do sistema operacional ou a inclusão/exclusão de outros drivers ou software).
A cada mudança implementada no software, surge um “pico” de falhas, o que leva
novamente a processos revisionais e de manutenção, até que essas falhas reduzam ao
nível da curva real. Nessas mudanças pode se, acrescentar novos códigos, criar
redundâncias de programas e de dados.

 CENÁRIO: na deterioração do software, os usuários reclamam muito, como por exemplo:

“Isto está lento”.; “Sumiu meu registro”; “Tinha um relatório aqui”; “Este campo está vazio,
deveria ter a informação…”. Nessa situação, o volume de chamadas aos desenvolvedores e
equipes de manutenção aumenta. Para corrigir de vez esse problema e retomar um ciclo novo
de vida do software, é necessário reestruturar o software (*).

(*) Reestruturar o software significa:

 Fazer limpeza dos dados;
 Fazer limpeza dos códigos redundantes;
 Atualizar hardware;
 Atualizar com novas versões o sistema operacional e linguagens de
programação;
 Gerar novos algoritmos;
 Adaptar de forma correta as antigas e novas funcionalidades com base em uma
nova arquitetura.

Devido às mudanças causadas no software, no acompanhamento de sua evolução, são

registrados versões e releases. As versões são registros do software feitos sobre as
mudanças que ocorrem na adaptação do software à necessidades do cliente, adaptação a
novos ambientes operacionais, correções de falhas ou quando o software está em
desenvolvimento. O release (lançamento) é o registro da versão que é liberada para o usuário.

1.2. Aplicações do software

O conteúdo de informação e a determinância são fatores importantes de

decisão da natureza de um aplicativo. Por exemplo, muitas aplicações comerciais
fazem uso de dados comuns e produzem “relatórios” diferentes e formatados.
As seguintes áreas do software indicam a amplitude das aplicações:
 Software básico: é uma coleção de programas escritos para dar apoio a
outros programas, normalmente possui uma forte interação com o hardware e são
utilizados como processadores de telecomunicação, componentes do sistema
operacional, computadores com intenso uso de múltiplos usuários, operações
concorrentes que exigem escalonamento (schedule), compartilhamento de recursos,
estrutura de dados complexas e múltiplas interfaces.

9
  Software de tempo real: é um software que monitora / analisa / controla
eventos do mundo real, exige um controle / saída que responde ao ambiente externo
e um componente de monitoração que coordena todos os demais componentes de
forma a obter resposta em tempo real (que, tipicamente, varia de 1 milissegundo até
1 minuto) possa ser mantido. O termo “tempo real” difere do “interativo” ou “time-
sharing” que podem exceder o tempo de resposta sem resultados desastrosos;
 Softwares empresariais: de maior área de aplicação. Distintos “sistemas
de informação” que processam folhas de pagamentos, contas a pagar e a receber,
estoques etc. Os tipos mais comuns de sistemas de informação estão na categoria do
e-business (negócios eletrônicos). São eles: ERP (Enterprise Resource Planning) –
Planejamento dos Recursos Empresariais; CRM (Customer Relationship
Management) – Gerenciamento das Relações com o Cliente; e SCM (Supply Chain
Management) – Gerenciamento da Cadeia de Suprimentos.
 Software para web: as páginas da Web recuperadas por um browser
constituem software que incorpora instruções executáveis (p. ex., CGI, HTML, Pearl
ou Java) e dados (p. ex., hipertexto e uma variedade de formatos visuais e de áudio).
Com esses recursos tecnológicos, surgem os sistemas e aplicações baseados na
Web, as WebApps. Nessa categoria estão também o comércio eletrônico (e-
commerce), estruturado pelas tecnologias: B2B (business to business), B2C
(business to consumer) e C2C (consumer to consumer). E a tecnologia cloud
computing (computação em nuvem).
 Software científico e de engenharia: é caracterizado por algoritmos de
processamento de números. As aplicações variam da astronomia a vulcanologia, da
análise de fadiga de mecânica à dinâmica orbital de naves espaciais recuperáveis, e
da biologia molecular à manufatura automatizada.
 Software embutido: O software embutido (embedded software) reside na
memória ROM e é usado para controlar produtos e sistemas para mercados industriais
e de consumo. Pode ser usado para controlar também funções muito limitadas, tais
como o controle de um forno de micro-ondas e funções digitais de automóveis.
 Software aplicativo para microcomputadores: Processamento de
textos, planilhas eletrônicas, computação gráfica, diversões, gerenciamento de banco
de dados etc. De fato, o software de computador pessoal continua a representar os
mais inovadores projetos de interfaces com seres humanos de toda a indústria de
software.
 Software de inteligência artificial (Artificial Intelligence – AI). Faz uso
de algoritmos não numéricos para resolver problemas complexos que não sejam
favoráveis à computação ou à análise direta. Atualmente, a área de AI mais ativa é a
dos sistemas especialistas, também chamados sistemas baseados em conhecimento.
Outras áreas de aplicação: são o reconhecimento de padrões (voz e imagem), jogos
e demonstração de teoremas. Atualmente a chamada rede neural artificial simula a
estrutura dos processos cerebrais e pode levar a uma nova classe de software que
consegue reconhecer padrões complexos e aprender com a “experiência” passada.

10
 1.3. Qualidade, processos, métodos e ferramentas
(PRESSMAN, 2011; 2002)

De acordo com Pressman (2011), a engenharia de software é uma tecnologia em

camadas (figura 2) e que deve estar fundamentada em um comprometimento
organizacional com a qualidade. A qualidade leva à cultura de melhoria contínua dos
processos e abordagens cada vez mais efetivas para a engenharia de software.
Exemplos de Normas e Modelos de Qualidade: NBR ISO/IEC 9126, ISO 9001,
ISO 9003, ISO 12207, CMMI e SPICE (ISSO 15504) e MPS.BR.

Figura 2 – Engenharia de software: uma tecnologia em camadas

FERRAMENTAS

MÉTODOS

PROCESSOS

FOCO NA QUALIDADE

Fonte: Pressman, 2002.

A estrutura para a engenharia de software é formada na camada de processos.

O processo é responsável por manter integradas as camadas da tecnologia,
permitindo o desenvolvimento racional e oportuno do software. O processo define uma
metodologia que deve ser estabelecida para a entrega efetiva de tecnologia,
constituindo a base para o controle do gerenciamento do projeto.
Exemplos de modelos de processos: cascata, incremental, prototipagem,
espiral, RUP, PSP e TSP.
Uma estrutura genérica de um processo para a engenharia de software
compreende cinco atividades:
 Elicitação – compreende o gerenciamento das relações com o cliente, a
comunicação e a interpretação do negócio. A intenção é compreender os objetivos
dos stackholders (conjunto dos interessados).
 Análise – partindo da interpretação do negócio constrói-se um arquétipo
do Plano de Projeto de Software que contemple a descrição do produto de software a
ser produzido, as atividades e tarefas técnicas, cronograma, gestão do risco, recursos
e custos empregados.
 Modelagem – é a tarefa de criar modelos que representem ideias
apresentadas em uma linguagem simbólica, ou gráfica. Uma vez apresentada a ideia,
é possível compreender, detalhar e refinar o modelo.

11
  Construção – constitui a tarefa de codificação (geração do código),
depuração (exame e limpeza dos dados, do código e da interface) e geração de
diagnósticos.
 Implementação / Implantação – é a entrega do software ao cliente, que
por sua vez fornece feedbacks de avaliação, validação e aceite do produto de
software.

Os métodos fornecem a técnica de como fazer para construir software. Incluem

um amplo conjunto de tarefas que abrangem análises de requisitos, projeto,
construção de programas, teste, entrega, suporte e manutenção. Os métodos formam
um princípio básico que regem cada área da tecnologia e incluem atividades de
modelagem e outras técnicas descritivas.
Exemplos de métodos: Metodologias Ágeis aplicadas ao desenvolvimento de
software.
As ferramentas da engenharia de software fornecem apoio automatizado ou
semiautomatizado para o processo e para os métodos. Quando as ferramentas são
integradas, e que podem ser reusadas, um sistema de apoio ao desenvolvimento de
software pode ser estabelecido.

A ferramenta CASE – Computer Aided Software Enginnering (Engenharia de

Software Auxiliada por Computador) é um software de apoio que cria um ambiente de
desenvolvimento para construir outro software. Essa ferramenta combina em um repositório
de dados vários artefatos do software, hardware, estrutura dos dados e do sistema. Contém
informações sobre análise, projeto, construção de programas e teste.

1.4. Fábrica de software

Nos primórdios da era do computador, os sistemas baseados em computador

eram desenvolvidos pela administração orientada ao hardware. Hoje, a distribuição
dos custos para o desenvolvimento baseados em computador mudou drasticamente
para o software.
Em uma perspectiva industrial os gerentes e muitos profissionais técnicos
formulam há décadas, as seguintes questões:
 Por que demora tanto tempo para que os programas sejam concluídos?
 Por que os custos são tão elevados?
 Por que não descobrimos todos os erros antes de entregarmos o software
aos nossos clientes?
 Por que temos dificuldade em medir o progresso enquanto o software está
sendo desenvolvido?

12
 Essas e muitas outras perguntas manifestam a preocupação relativa ao
software e à maneira pela qual ele é desenvolvido, o que leva à prática da engenharia
de software. Com base nessas questões, Sommervillle (2003) descreve: “atualmente
a engenharia de software enfrenta três principais desafios”:

1 – O desafio do legado
Atualmente uma grande parte dos sistemas de software em utilização foi
desenvolvida no passado, em uma época em que as linguagens não eram nem
orientada a objetos, mas esses sistemas ainda operam importantes funções
corporativas e controlam grandes quantidades de eventos em uma grande massa de
dados. O desafio do legado é fazer a manutenção e atualização desses sistemas
a custos baixos, com qualidade e prosseguir com a prestação de serviços
corporativos essenciais.

2 – O desafio da heterogeneidade
Exige-se cada vez mais que os sistemas operem como sistemas distribuídos
atuando por meio de redes que possuem diferentes tipos de arquiteturas de
computadores e diferentes tipos de sistemas operacionais. O desafio da
heterogeneidade é desenvolver técnicas para construir sistemas confiáveis e
flexíveis o bastante para lidar com essa heterogeneidade.

3 – O desafio do fornecimento
Muitas técnicas de engenharia de software tradicionais são muito demoradas,
nos dias atuais existe uma demanda enorme de sistemas que sejam desenvolvidos
no menor tempo possível e com facilidade de adaptação as mudanças. O desafio do
fornecimento é entregar sistemas grandes e complexos, com a qualidade
desejada e em curto espaço de tempo.

1.5. Mitos e realidades no desenvolvimento do software

(PRESSMAN, 2011; 2002)

Os mitos relacionados ao software / sistemas surgiram nos primórdios de seu

desenvolvimento e propagaram desinformação e confusão. Alguns dos mitos
remanescentes de software ainda merecem créditos:

Mitos de gerenciamento

 Mito: já temos um manual repleto de padrões e procedimentos para trabalhar

com o sistema. Isso não oferecerá ao meu pessoal tudo o que eles precisam saber?
o Realidade: o manual de padrões pode muito bem existir, mas será que ele
é usado? Os profissionais têm conhecimento de sua existência? É completo? Em
muitos casos, a resposta a todas estas perguntas é “não”.

13
  Mito: se estamos atrasados com prazo, podemos adicionar mais usuários
ou programadores?
o Realidade: o desenvolvimento de software não é um processo
manufaturado.
 Mito: temos software de última geração e compramos os mais novos
computadores. Por que ainda estamos atrasados?
o Realidade: é preciso muito mais do que o último modelo de computador
para se trabalhar com um software de alta qualidade. As operações com os novos
softwares / sistemas são mais importantes do que o hardware para se conseguir boa
qualidade e produtividade, tais operações dependem do treinamento do pessoal.

Mitos dos clientes

 Mito: uma declaração geral dos objetivos é suficiente para começar a

escrever programas.
o Realidade: uma definição inicial ruim é a principal causa de fracasso dos
esforços de desenvolvimentos de software. Dominar a informação, função,
desempenho, interfaces, restrições de projeto e critérios de validação é fundamental.
 Mito: os requisitos do software mudam continuamente, mas as mudanças
podem ser facilmente acomodadas, porque o software / sistema é flexível.
o Realidade: é verdade que os requisitos de software / sistema se modificam,
mas o impacto da mudança varia de acordo com o tempo em que ela é introduzida.

Mitos dos desenvolvedores

 Mito: assim que escrevermos o programa e o colocarmos em uso, nosso

trabalho estará completo.
o Realidade: os dados de indústrias indicam que entre 50% e 70% de todo
o esforço gasto num programa será despendido depois que ele for entregue pela
primeira vez ao cliente.
 Mito: enquanto o software não estiver “funcionando” não tenho condições
de avaliar sua qualidade.
o Realidade: um dos mecanismos mais efetivos de avaliação de software /
sistema é a revisão formal, que pode ser aplicada desde o início do projeto, o que
considerado um “filtro de qualidade”.
 Mito: um projeto bem-sucedido é o programa funcionando.
o Realidade: um programa funcionando é somente uma parte de uma
configuração de software. A documentação forma os alicerces para um
desenvolvimento bem-sucedido e, o que é mais importante, fornece um guia rápido
para a tarefa de suporte e manutenção do software.

14
 1.6. Exercício discursivo comentado

De acordo com Pressman (2011), “o software possui um duplo papel na

produção: não só pode constituir um produto, como também pode ser o veículo de
melhora de um produto”. Justifique e exemplifique cada caso.
Resposta:
O software é um programa ou conjunto de programas, organizados para atingir
um ou mais objetivos (ou necessidades), que normalmente trabalham de forma
independente e que podem ser disponibilizados para o mercado consumidor.
Como veículo de melhora de um produto, podem constituir um ou mais
programas embutidos em outro software, que assumem o papel de funções internas
e que também podem ser disponibilizados para o mercado consumidor.
Exemplo:
O sistema operacional Windows é um produto de software disponível no
mercado. Ao instalar o sistema operacional no computador, periodicamente ele vai
sofrer atualizações para melhoria do sistema. Essas atualizações são software
implementados no Windows para melhora deste outro software.
A indústria de produtos de eletrodomésticos, produz vários aparelhos: micro-
ondas, fogão, geladeira etc. São hoje em dia automatizados pela indústria de software.

15
 2. PROCESSO DE SOFTWARE

2.1. Processo de software e o desenvolvimento do projeto

De acordo com Sommerville (2011; 2003):

[…] a engenharia de software é uma disciplina da engenharia que se ocupa

de todos os aspectos da produção de software. Isso vai desde os estágios
iniciais de especificação de um sistema, até propriamente a manutenção,
para que esse mesmo sistema sobreviva ao longo do tempo.

A estrutura apresentada na figura 3 mostra os estágios de evolução da análise

de um sistema em uma organização até o uso da engenharia de software.

Figura 3 – Estágio de análise do sistema até o emprego da engenharia de software

Estruturar a organização com base

nas entidades e representantes de
áreas gerenciais.

Estruturar as funcionalidades
com base nos requisitos, dados
e atividades da organização.

Criar diagramas e protótipos de

relacionamento entre as entidades,
lógica, objetos e dados.

Construir o código, criar,

implementar e testar o sistema.

Usar a engenharia de software e a tecnologia para escolher processos,

métodos e ferramentas apropriadas para o projeto, controle,
operacionalização e manutenção do sistema.

Fonte: elaborado pelo autor, 2019.

Stair (2006) sugere também que “quando se elabora um sistema é importante

percorrer uma série de passos previsíveis, o Ciclo de Vida do Desenvolvimento do

16
Sistema (System Development Life Cycle – SDLC)”. Que é um roteiro que ajuda a
criar a tempo um resultado de alta qualidade. Os Modelos de Processos de Software
englobam um conjunto de atividades, métodos, práticas e transformações, a serem
empregadas no desenvolvimento e manutenção do software. Fornecem estabilidade,
controle e organização para as atividades.

Se um processo estiver sem controle, às atividades tornam-se bastante caóticas,

comprometendo a eficiência do projeto. Em um processo sem controle, o que significa:
sem acompanhamento, sem medições, sem comparações com marcas de referência
(milestones), ocorrem atividades e tarefas redundantes, conflitos na comunicação, na
análise e consequentemente os aumentos de erros.
Construir e operacionalizar um software / sistema sem planejamento com base
em processos é um projeto com grande risco de ser efetivado e operacionalizado.

2.1.1. Planejamento do processo

“Um processo é uma sequência de fatos, atividades ou operações que

apresentam certa unidade e/ou que se reproduzem com certa regularidade”
(PRESSMAN, 2002).
Em cada processo deve se definir pontos de início (input) e fim (output).
Esses pontos são marcas de referências (ou milestones), úteis para o
acompanhamento do processo. Essas marcas servirão para controlar o processo,
medir, avaliar, projetar melhorias e tendências.
A figura 4 mostra o modelo básico de um processo, com suas respectivas
marcas de referência (input e output), dos quais:
 Input: o ponto inicial, normalmente marca os itens necessários para dar
entrada no processo. Esses itens em uma forma ampla referem-se: aos Requisitos de
entrada do processo, tais como: Recursos necessários, Tecnologia a ser empregada,
Fornecedores, Metodologias, Componentes, Custo, Cronograma, Procedimentos de
trabalho e Documentos.
 Processo: é combinação organizada e dos itens de entrada para criar um
produto de software ou de sistema, um componente de outro produto ou executar um
determinado trabalho.
 Output: é a finalização do processo com a entrega do produto ou serviço.
Novos registros são feitos, novas medições e verificações são realizadas, para
confrontar o resultado obtido com o objetivo planejado para o processo.

17
 Figura 4 – Modelo básico do processo

PROCESSO

Input (Entradas) Output (saídas)

* Fornecedores * Produto
* Mão de obra * Subprodutos
* Materiais * Serviços
* Tecnologia

Fonte: elaborado pelo autor, 2019.

2.1.2. Decomposição do processo

O processo de engenharia de software pode representar uma determinada

funcionalidade(*). É uma sequência coerente de práticas, que objetiva o
desenvolvimento ou evolução de sistemas de software. Essas práticas englobam as
atividades de análise, especificação, modelagem, implementação, testes,
implantação, suporte e manutenção. São caracterizadas pela interação de
ferramentas, pessoas e métodos aplicáveis. A estrutura comum de um processo de
software pode ser caracterizada como mostrada na figura 5.

(*) Funcionalidade: uma ou várias funções que empregam recursos e lógicas similares,
tecnologias comuns e que capacitam o produto software a prover funções que atendam
as necessidades externas e internas do software / sistema.

Figura 5 – Elementos que compõem uma estrutura comum do processo

Estrutura comum para o acompanhamento do processo

Atividades de estrutura

Conjunto de tarefas

Tarefa

Marca de referência (Milestone)

SQA – Software Quality Assurance

(Garantia da Qualidade de Software)

Fonte: Pressman, 2002 (adaptado).

18
 O grupo SQA mostrado na figura 5 acompanha os resultados de cada tarefa,
cada atividade e consequentemente de cada processo do desenvolvimento do
software. O grupo SQA cuida para que os resultados qualitativos e quantitativos não
desviem de seus objetivos e metas, garantindo a eficácia de cada item.
De acordo com o escopo do projeto, o processo é estruturado em vários módulos
(ou componentes), com base: no tamanho do processo, sua complexidade, qualidade
exigida e tecnologia a ser implementada. A figura 6 mostra como é a estrutura genérica
de um processo e os elementos que a compõem.

Figura 6 – Estrutura do processo

PROCESSO

META 1 META 2 META 3

ATIVIDADE 1 ATIVIDADE 2 ATIVIDADE 3

PROCEDIMENTO 1 PROCEDIMENTO 2

TAREFA 1 TAREFA 2 TAREFA 3 TAREFA 4

Fonte: elaborado pelo autor, 2019.

A meta (etapa do processo ou subprocesso) é uma marca de referência que

traça o objetivo de uma parte do processo. Normalmente associada ao custo e prazo
de cumprimento da meta. Tem como objetivo manter os planos, artefatos e atividades
de software consistentes com os requisitos alocados.
A atividade é a realização de uma função específica do processo, normalmente
compreendida na meta.
O procedimento é a forma de como se deve agir, fazer ou cumprir uma
atividade. Os procedimentos normalmente são caracterizados por meio de uma lista
que apresenta passo a passo e de forma sequencial as tarefas que deverão ser
executadas.
As tarefas são os trabalhos que devem ser realizados. Representam uma
empreitada de serviços, ou seja, uma quantidade de trabalhos realizados ou a realizar
dentro de um prazo determinado.

19
 2.1.3. Análise dos recursos para o projeto do processo

Na projeção dos recursos para o ambiente computadorizado, três perfis de analistas

são essenciais na elaboração e efetivação do processo por meio computacional:
1. Analista de negócio (ou autor do processo): esse profissional é aquele
que precisa do negócio. Entende-se pelo negócio como algo que tenha que ser
gerado, corrigido ou melhorado, para atender um objetivo ou necessidade. O Analista
de Negócio utiliza uma linguagem natural e diagramas simples para apresentar o que
quer, o que precisa que seja feito.
2. Analista de processo: é aquele que interpreta a ideia do negócio e que
tem por objetivo determinar as atividades e respectivas tarefas necessárias para
processar o negócio. O Analista de Processo busca uma padronização da
nomenclatura, específica por meio de textos breves e diagramas específicos a
ordenação das atividades, e das tarefas que compõe a atividade.
3. Analista de sistema: converte as atividades em componentes (peças
que compõe o processo). Cada componente representa uma parte do sistema
apoiada pelo processamento dos dados. A interpretação das tarefas e do workflow
(fluxo de trabalho) levam a criação das funções de acesso do software / sistema, a
lógica de processamento (programa de computador) e os recursos computacionais
necessários para executar as funções. O Analista de Sistema especifica cada função
por meio de descrições singulares e modelos gráficos (modelagem) e determinam as
funcionalidades que serão interpretadas pelos especialistas da tecnologia da
informação.

2.1.4. Recursos do projeto e do produto

Os recursos necessários para o projeto e para o produto garantem a efetivação

do processo. Com base nos requisitos determinados pelos analistas, esta abordagem
recai em duas categorias gerenciais: Gerência do Projeto e Gerência do Produto.
 Gerência do projeto: dimensiona o escopo do projeto, se comunica,
interpreta o processo, distribui atividades e tarefas, organiza, elabora cronogramas,
tabela de custos e diagramas de implementação e implantação do processo. No
gerenciamento do projeto os principais recursos a serem tratados são:
o Recursos humanos;
o Recursos materiais;
o Recursos tecnológicos;
o Recursos financeiros.
 Gerência do produto: especifica e cria projeto do produto. O produto como
vimos anteriormente, pode ser um componente ou um subproduto, serviços a serem
executados, resultados da produção ou do comércio, ou produto produzido em fábrica.
Processos de gerenciamento de produto são tipicamente definidos em uma
determinada etapa do ciclo de vida do projeto e variáveis específicas da área de
aplicação. No ambiente computacional informatizado é considerado como
gerenciamento do produto o gerenciamento praticado para fornecer a infraestrutura
20
de Tecnologia da Informação (TI), que apoia o desenvolvimento do Sistema de
Informação (SI). Em uma sequência ordenada os principais recursos para desenvolver
um Sistema de Informação são:
o Recursos humanos (peopleware);
o Recursos do software;
o Recursos de hardware;
o Recursos de dados;
o Recursos da rede de computadores.

2.2. Estrutura organizacional orientada por modelos de processo de

software

“O processo é um diálogo no qual o conhecimento, que deve se transformar em

software, é reunido e embutido no software” (PRESSMAN, 2002).
“Um modelo de software é uma representação simplificada de um processo
de software. Cada modelo representa uma perspectiva particular de um processo e,
portanto, fornece informações parciais” (SOMMERVILLE, 2011).
Logo, um modelo de software deve ser aplicado em partes específicas do
processo que atenda toda a organização. Em uma visão global tanto um sistema como
um processo, são orientados por uma estrutura organizacional. A figura 7 mostra um
modelo genérico de estrutura organizacional para o desenvolvimento do software, que
atende desde as áreas gerenciais da alta administração, bem como a área ligada a
produção do software.

21
 Figura 7 – Modelo de estrutura organizacional para o desenvolvimento do software

PLANEJAMENTO
Nesta fase são levantados os requisitos do software com
base nas arguições sobre os negócios, necessidades dos
clientes/usuários e restrições do sistema.

Partindo do levantamento dos requisitos do software, à

análise consiste em coletar dados, especificar os
ANÁLISE requisitos, determinar as atividades do desenvolvimento
do software, medir o escopo do sistema e avaliar a relação
custo / benefício.

No projeto usa-se a engenharia de software para escolher

metodologias, procedimentos e técnicas apropriadas para
o controle e operacionalização do sistema, e que atendam
aos requisitos do software. Criam-se diagramas de
PROJETO entidades e relacionamento dos dados e da lógica de
processamento, com base em protótipos e arquiteturas
desenvolvidas em UML. O desenvolvimento do software
ocorre na sequência, onde são definidos: stakeholders,
técnicas de programação, linguagens associadas e formas
de testar e diagnosticar os programas.

A construção aborda: a escolha dos profissionais,

CONSTRUÇÃO construir e testar o código, implementar e implantar,
entregar, manter, treinar e dar suporte ao usuário.

Fonte: elaborado pelo autor, 2019.

Exemplos de modelos de processo de software que serão discutidos neste

capítulo:
 Modelos de processos tradicionais: cascata, incremental, prototipagem
e espiral;
 Processo Unificado: RUP; e
 Modelos de processo pessoal e de equipe: PSP e TSP.

2.3. Modelos de processo de software tradicionais

Basicamente são quatro os principais modelos de processo de software

tradicionais e aplicados na atualidade: modelo cascata (waterfall ou sequencial linear);
modelo incremental; prototipagem e modelo espiral.

2.3.1. Modelo Cascata (waterfall ou sequencial linear)

O modelo cascata foi o primeiro modelo publicado do processo de

desenvolvimento do software, originário de outros processos da engenharia
de sistemas, é considerado o modelo clássico do ciclo de vida de

22
 desenvolvimento do software, se dá de forma sequencial encadeada e
refletem as atividades fundamentais do desenvolvimento (PRESSMAN,
2011).

O modelo cascata com suas principais atividades é mostrado na figura 8 e

abaixo a descrição de suas respectivas tarefas:
1. Definição dos requisitos – São determinadas as funcionalidades,
restrições e objetivos do sistema. Estabelecidas com base na comunicação com o
cliente e usuários do sistema. E em seguida são definidos em detalhes e servem como
especificação do sistema.
2. Projeto de sistemas e de software – Este processo agrupa os requisitos
em sistemas de software e/ou hardware. Define a arquitetura do sistema.
3. Implementação e teste de unidades – Verifica se cada unidade atende
as especificações.
4. Integração e testes de sistemas – As unidades são integradas e
testadas como um sistema completo. Depois dos testes, o software é entregue ao
cliente.
5. Operação e manutenção – Esta é a fase mais longa do ciclo de vida do
software. O sistema é instalado e colocado em operação e novos problemas surgem.
A manutenção procura corrigir erros que não foram identificados anteriormente,
melhora a interface, aumenta as funções do sistema e novos requisitos são
descobertos.

Figura 8 – Modelo Cascata para o desenvolvimento do software com suas principais atividades

DEFINIÇÃO DE
REQUISITOS

PROJETO DE SISTEMAS
E DE SOFTWARE

IMPLEMENTAÇÃO E
TESTES DE UNIDADES

INTEGRAÇÃO E
TESTES DE SISTEMAS

OPERAÇÃO E
MANUTENÇÃO

Fonte: Sommerville, 2003; Pressman, 2011.

Apesar de o Modelo Cascata servir de base para outros modelos, a vantagem

do modelo cascata está nas aplicações com sistemas estruturados, que são
sistemas únicos e que operam em um ambiente operacional restrito, porém de alta
capacidade. Outra vantagem é ser aplicado em problemas complexos, ou ainda
difíceis por resolver por incluir vários componentes.
23
 A desvantagem do modelo cascata é ser inflexível na divisão do projeto em
estágios distintos. Na prática, é impossível se conseguir a totalidade dos requisitos
em um momento inicial do projeto, e qualquer problema que ocorra em uma das fases
só poderá ser detectado após a entrega do software para o cliente, gerando
retrabalhos ou até mesmo a extinção do projeto. A visão do Modelo Cascata é de alto
nível e não reflete o modo de como o software é desenvolvido. Mudanças no software
durante o desenvolvimento não são apreciáveis e consequentemente não são
sugeridos para projetos orientados a objeto.

2.3.2. Prototipagem

A figura 9 mostra uma maquete (escala reduzida de uma obra de arquitetura).

A prototipagem tem o mesmo objetivo de uma maquete. Antes da entrega final do
sistema são desenvolvidos protótipos apresentados em um esboço, para melhorar o
entendimento de desenvolvedores e clientes, sobre as possíveis problemáticas que
possam surgir.

Figura 9 – Maquete produzida para uma obra, desenhada pela arquitetura com uso de computação gráfica

Fonte: IMOVELWEB, 2019.

A prototipagem pode ser classificada de acordo com uma variedade de

dimensões. A abordagem de prototipação tem um número de vantagens importante a
oferecer, as quais são:
 Primeira abordagem – todos os requisitos do sistema não têm que ser
completamente determinados antecipadamente e podem mesmo ser trocados durante
o curso do projeto.

24
  Segunda abordagem – a entrega da prototipação concisa deve conter
definições do sistema e especificações para o usuário final. Como consequência, o
envolvimento e satisfação do usuário final são fortemente aumentados.
 Última abordagem – a prototipação possibilita testar rapidamente o
ambiente de desenvolvimento voltado para a funcionalidade, desempenho e interface
de dados.
Dentro dessa visão, o projeto passa por várias investigações para garantir que
o desenvolvedor, usuário e cliente cheguem a um consenso sobre o que é necessário
e o que deve ser proposto. Como muitos usuários não possuem uma visão ampla
sobre a tecnologia, esse método de desenvolvimento é bastante interessante,
permitindo que o usuário interaja significativamente no sistema.
As atividades da prototipagem podem ser determinadas a partir do
paradigma de prototipagem, apresentado por Pressman (2002), como é mostrado na
figura 10. Um procedimento do analista a ser seguido, é mostrado no diagrama abaixo:

Figura 10 – O paradigma de prototipagem

Ouvir o Cliente Construir / revisar

o protótipo

O cliente testa
o protótipo

Fonte: Pressman, 2002.

Ciclo de atividades da prototipagem:

1. Começar com um conjunto bem simples de requisitos fornecidos pelos clientes e
usuários;
2. Clientes e usuários fazem testes e experimentações, e assim que eles decidem o que
querem, os requisitos são revisados, alterados, detalhados, documentados e o
sistema passa a ser codificado ou protótipos simples desenhados para análise de
funções e interface do usuário;
3. Novamente as alternativas são apresentadas e discutidas com os usuários, continua
o processo de prototipagem, passa para uma nova etapa do ciclo de desenvolvimento
do software ou implementa uma nova funcionalidade, até a entrega definitiva do
Sistema.

25
 Vantagens da prototipagem

 A prototipagem é um ciclo de vida eficiente, que possibilita ao

desenvolvedor criar o modelo do software que será construído.
 Apropriado para quando o cliente definiu os objetivos do software, mas não
identificou detalhes dos requisitos de entrada, processamento e saídas.
 A prototipagem serve como para identificar os requisitos do software. É um
processo que possibilita ao desenvolvedor, cliente e usuário a examinarem
antecipadamente os requisitos, reduzindo os riscos e incertezas do desenvolvimento.
A chave é definir as regras do jogo logo no começo.
 Velocidade de desenvolvimento no sentido de propiciar ao usuário uma
visão mais real do software que se está projetando (o usuário pode “enxergar” telas e
relatórios resultantes do software).
 Envolvimento direto do usuário à medida que o desenvolvimento do
software evolui, o usuário passa a ser um coautor do desenvolvimento.

Desvantagens da prototipação
 O cliente não sabe que o software que está testando ainda não foi concluído
e não o considera no desenvolvimento, a qualidade global e a manutenibilidade a
longo prazo.
 A prototipação pode dar ao usuário a impressão que praticamente qualquer
sugestão pode ser implementada, não importa qual estágio do processo de
desenvolvimento está. Além disso, para os usuários não está claro o porquê da
demora em entregar a aplicação final, depois que uma versão demo do sistema foi
exibida. A cliente não aceita bem a ideia de que a versão final do software ainda vai
ser construída e “força” a utilização do protótipo como produto final.

2.3.3. Modelo incremental

O modelo de processo incremental (figura 11) aplica sequências lineares dos

elementos do Modelo Cascata e aplica de forma evolucionária incrementos com base
no prazo de entrega, aprovação e validação. O modelo de processo Incremental é
iterativo (*) e tem como objetivo apresentar um produto operacional a cada
incremento realizado, ou seja, é desenvolvido com o conceito de versões.

26
 Figura 11 – Modelo de processo incremental

Funcionalidade

n Incrementos
Incremento 2 Comunicação
Incremento 1 Comunicação Planejamento
Comunicação Planejamento Modelagem

Planejamento Modelagem Construção

Implantação
Modelagem Construção

Construção Implantação

Implantação Entrega do
Incremento 2
Entrega do
Incremento 1
Fonte: adaptado de Pressman (2007). Tempo

Na prática o usuário quer sempre o sistema para ontem, e com qualidade. O

Modelo Incremental parte do princípio que é preferível o usuário receber o sistema em
partes, permitindo assim que esses recursos já possam ser utilizados, enquanto que
os demais estariam em desenvolvimento.
Nesse modelo o sistema será especificado na documentação dos requisitos, e
“quebrado” em subsistemas por funcionalidades. As versões são definidas,
começando com um pequeno subsistema funcional e então adicionadas mais
funcionalidades a cada versão. Pode-se então dizer que o modelo incremental chega
lentamente à funcionalidade total, por meio dessas novas versões.

(*) Iteração é uma estratégia de planejamento para retrabalhar o processo, revisar

tempos, comentar falhas, erros e tecnologia, melhorar o sistema e distribuir tarefas. A
cada iteração são geradas novas versões, que são os registros de acomponhamento
das mudanças no software até o release que é o registro da versão que é liberada para
o usuário. As iterações do processo são necessárias para melhoria contínua do
processo e do software.

O modelo incremental é o mais indicado na atualidade para o desenvolvimento

de software, principalmente nos projetos orientados a objetos e é adaptado a vários
tamanhos de sistemas / software. Possui várias vantagens em relação aos demais
modelos de processos.
Abaixo são comentadas as diversas vantagens do modelo de processo
incremental:
 Aprendizagem, melhora contínua do processo, maturidade e composição
progressiva do produto de software.
 Cada iteração / incremento produz um conjunto de produtos utilizáveis.

27
  Redistribuição contínua de tarefas para os envolvidos ao longo do projeto.
 Encoraja a participação ativa dos usuários.
 Identifica falhas, riscos e dúvidas no projeto.
 Identifica inconsistência entre a análise, projeto e implementação.

2.3.4. Modelo espiral

O modelo espiral é um modelo evolucionário que combina a natureza iterativa

da prototipagem com o estilo clássico do modelo cascata.
Observe a figura 12. No modelo espiral, o software é desenvolvido em uma
série de versões evolucionárias e em cada ciclo da espiral é definido um conjunto de
atividades de arcabouço que depois de completada a espiral, um release é definido.
Após várias iterações o software atinge sua totalidade.

Figura 12 – Modelo de processo de desenvolvimento de software espiral

Fonte: Pfleeger, 2004.

O modelo espiral é mais adequado para sistemas complexos, software de

grande porte e que exigem um alto nível de iterações com os usuários, o que
possibilita uma melhor abordagem de todos os problemas do sistema.

28
 O modelo espiral basicamente é dividido em quatro setores
ATIVAÇÃO  Define-se os objetivos específicos, identificam-se as restrições para o
processo e é preparado um plano de gerenciamento detalhado. Identificam-se também
os riscos sem os analisar profundamente (foco da próxima fase).
ANÁLISE de RISCOS  Com base nos riscos identificados na fase anterior são
realizadas análises detalhadas, e tomadas providências para amenizar esses riscos.
Criam-se várias versões de protótipos para apoiar essa fase.
DESENVOLVIMENTO  Fundamentado pelas fases anteriores escolhe-se o modelo
mais adequado para o desenvolvimento do Sistema. A bagagem profissional e a vivência
do desenvolvedor em outros sistemas, são estratégicas para essa fase. Dependendo da
complexidade do Sistema, às vezes, é necessária a presença de um consultor
especialista.
PLANEJAMENTO  O projeto é revisto nessa fase, e é tomada uma decisão de realizar
um novo ciclo na espiral ou não. Se continuar com o aperfeiçoamento do Sistema, é traçado
um plano para a próxima fase do projeto. Um diferencial nesse modelo comparado com
outros, é a explícita consideração de riscos dentro do projeto como um todo. Para tanto, criou-
se uma fase específica de Análise de Riscos nesse modelo.

2.4. Rational Unified Process – Processo Unificado Racional (RUP)

O RUP é um processo proprietário de engenharia de software criado pela

Rational Software Corporation e atualmente representado pela IBM, ganhando um
novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process.
O RUP é um processo da engenharia de software, considerado também como
uma metodologia de desenvolvimento de software. Fornece às organizações um
processo de software maduro, rigoroso e flexível. É distribuído on-line sob o formato
eletrônico utilizando tecnologia Web, disponibilizando upgrades regulares de software
pela Rational Software. Veja na figura 13 o ambiente operacional do RUP.

29
 Figura 13 – Plataforma de trabalho RUP pela Web

Fonte: Kruchten, 20001.

Pode ser configurado de acordo com as necessidades de cada organização. É

documentado, desenhado, desenvolvido, distribuído e mantido como uma ferramenta
de software, usando a UML.

2.4.1. Características do RUP

O RUP oferece uma abordagem baseada em disciplinas para atribuir tarefas e

responsabilidades dentro de uma organização de desenvolvimento. Sua meta é
garantir a produção de software de alta qualidade que atenda às necessidades dos
usuários dentro de um cronograma e de orçamentos previsíveis.
O RUP captura as principais boas práticas modernas da engenharia de
software:
 Desenvolvimento iterativo
Diferentemente do método clássico de desenvolvimento, um grande sistema
de software não permite que se defina o problema e se construa uma solução eficiente
em um único passo. Dependendo da complexidade, os requisitos mudam com
frequência, devido a vários fatores, tais como: restrições da arquitetura empregada,
mudanças nas necessidades primárias do cliente e mudanças refletidas devido a um
refinamento do problema inicialmente levantado.

1Disponível em: https://pdfs.semanticscholar.org/b844/988bad3b33adc326f08cbe2a569e

191e8460.pdf. Acesso em: mar. 2011.

30
 Tendo como base o desenvolvimento iterativo é possível acomodar novos
requisitos ou mudanças, aperfeiçoar o entendimento do projeto a cada refinamento
sucessivo, endereçando os itens de risco e permitindo identificar e atenuar os riscos
que circundam o projeto.
Cada iteração pode corresponder a um novo release do sistema, e isso diminuir o
risco do projeto, permitindo ao cliente uma avaliação do progresso do projeto e de sua
gerência (KRUCHTEN, 2001).

 Gestão de requisitos
Documentar apropriadamente é crucial para o sucesso de um grande projeto.
O RUP é conduzido por Casos de Uso e sustentado em outros diagramas da UML.
O RUP descreve como documentar as funcionalidades, restrições do sistema,
restrições do projeto e requisitos através de Casos de Uso (Use Cases), desde a
análise de requisitos até o teste do sistema finalizado. “Os casos de uso e cenários
são exemplos de artefatos do processo, que se mostram altamente eficazes para
documentar os requisitos funcionais” (KRUCHTEN, 2000).

 Arquitetura baseada em componentes

O RUP é baseado na arquitetura de componentes do sistema. Promove a
definição inicial de uma arquitetura de software robusta, que facilita a parametrização
do desenvolvimento, a reutilização e a manutenção. Uma arquitetura baseada em
componentes viabiliza um sistema extensível promovendo a reutilização de software.
Kruchten (2000) afirma que “O RUP suporta essa sistemática de construção de
sistema, focando-se numa arquitetura executável nas primeiras fases do projeto.”

 Uso de software de modelos visuais

Ao representar o projeto utilizando construções gráficas, o RUP apresenta
de forma eficiente uma visão geral da solução, o que permite também que clientes,
sem nenhuma afinidade com a área de desenvolvimento de sistemas, possam
facilmente compreender o projeto e, dessa forma, desenvolverem-se mais com o
projeto. A linguagem UML se transformou em um padrão para as indústrias ao
representar projetos, e é utilizada amplamente pelo RUP (KRUCHTEN, 2000).

 Verificação contínua da qualidade

Assegurar a qualidade do software durante do desenvolvimento do projeto é
algo intensivo feito pelo RUP, que assiste todo o processo envolvendo todos os
membros no controle e planejamento da qualidade (KRUCHTEN, 2000).

 Gestão e controle de mudanças do software

O RUP define métodos para controlar e monitorar as mudanças a fim de
garantir que mudanças não venham a comprometer inteiramente o sucesso do projeto
(KRUCHTEN, 2000).

31
 2.4.2. Fases e workflow (ou disciplinas de trabalho)

Cada ciclo do RUP se divide em fases e o ciclo resulta numa nova geração do
produto ou parte dele. Cada fase se divide em iterações a definir em cada projeto
concreto. O RUP possui quatro fases, seis disciplinas de trabalho e três
disciplinas gerenciais.
Na figura 14 as fases são apresentadas na dimensão horizontal e o workflow
na dimensão vertical, como disciplinas.

Figura 14 – Arquitetura do RUP com suas fases e workflow

As atividades são
agrupadas em O desenvolvimento é
workflows expresso em ciclos, fases e
iterações.

Fonte: Kruchten, 2000.

O RUP define um processo bidimensional. Observe a figura 14. Na

dimensão horizontal estão as fases do processo de desenvolvimento (estrutura
dinâmica), representando mudanças no tempo de desenvolvimento, e na dimensão
vertical estão os workflows (estrutura estática), representando mudanças no
esforço despendido no desenvolvimento.

 Estrutura dinâmica

A estrutura dinâmica corresponde às quatro fases do RUP que equivalem

ao ciclo de vida do desenvolvimento de um produto de software. Ao final de cada uma

32
destas fases se verifica se os objetivos da fase foram concluídos. Após completar as
quatro fases, uma versão release do software está completa, e para cada nova versão
o software passará por todas as fases novamente (desenvolvimento evolucionário).

Iniciação/concepção (inception/conception)
o Definir o escopo e as fronteiras do sistema (contrato com o cliente).
o Elaborar casos de uso críticos ao sistema (atores e requisitos).
o Elaborar o business case do sistema, que deve incluir os critérios de
sucesso, avaliação de riscos, uma estimativa de recursos e um cronograma dos
pontos mais importantes.
o No final: obter concordância dos stakeholders, compreensão dos
requisitos e credibilidade nas estimativas. O projeto pode ser cancelado ou
fortemente reformulado se falhar este marco.

Elaboração (elaboration) Garantir que o projeto, a arquitetura e o conjunto de

requisitos estejam estáveis para garantir o cumprimento de prazos e custos.
o Produzir protótipos evolucionários e exploratórios.
o Eliminar os elementos de maior risco.
o Descrever requisitos adicionais (não-funcionais e com menor grau de
importância).
o Revisar o business case.
o No final: obter estabilidade da arquitetura, demonstrar que o projeto é
viável (tempo, custo). O projeto pode ser cancelado ou reformulado se falhar
neste marco.

Construção (construction)
o Minimizar custos através da utilização ótima de recursos.
o Desenvolver versões utilizáveis.
o Completar os processos de análise, projeto, implementação e testes das
f uncionalidades do sistema.
o Desenvolver de maneira iterativa e incremental um produto que esteja
pronto para ser entregue aos usuários, um manual e uma descrição da versão
corrente.
o Decidir se o software, o site e os usuários estão prontos para a implantação do
sistema.
o No final: a disponibilização pode ser adiada se os critérios não forem
cumpridos.
Transição / implantação (transition) – Atividades de entrega do software
o Testar para validar o novo sistema.
o Treinar usuários e pessoas responsáveis pela manutenção.

33
 o Iniciar as tarefas de marketing e distribuição.
o No final: obter satisfação dos clientes, gastos e custos dentro do aceitável.

 Estrutura estática
Na estrutura estática, o RUP é representado por suas 9 disciplinas (seis
disciplinas de trabalho e três disciplinas gerenciais). Cada uma delas utiliza quatro
elementos primários de modelagem: papéis, atividades, artefatos e workflows.

Papéis
o Descreve o comportamento e responsabilidades de um indivíduo ou grupo
de indivíduos de uma equipe.
o O comportamento de cada papel é dado pelo conjunto de atividades
desempenhadas por ele.
o As responsabilidades de cada papel estão associadas a artefatos que
devem ser desenvolvidos ao longo do processo.
o Exemplo de papéis: especificador de casos de uso, arquiteto de softwares,
projetista de interface, gerente de projetos.

Atividades
o Realizadas pelos papéis, consistem em ações que atualizam ou geram
artefatos.
o A granularidade de uma atividade é expressa em horas ou dias.
o As atividades são divididas em etapas de tarefas: entendimento, realização,
revisão.

Exemplos de atribuições de papéis e responsabilidades

Atividade Papel

Planejar uma iteração Gerente de projetos

Determinar casos de uso e atores Analista de sistemas

Executar teste de desempenho Tester of performance

Artefatos
o Informações produzidas, modificadas ou utilizadas ao longo do
desenvolvimento de software.
o São utilizados como entrada para atividades e são produzidos como saída.
Exemplos: modelos (de caso de uso, projetos), documentos (plano de
negócios, conjunto de artefatos, plano de projeto), código-fonte.
34
 Workflow
o Define uma sequência de atividades que produzem resultados
observáveis na forma de artefatos.
o Podem ser expressos em forma de diagramas de sequência, colaboração,
atividades.
o O workflow é apresentado em seis disciplinas de trabalho e três disciplinas
gerenciais, descritas a seguir.

Disciplinas de trabalho

 Modelagem de Negócio (business modeling) – A intenção é melhorar o

entendimento do negócio através do desenvolvimento de um modelo de negócios. Os
documentos gerados são casos de uso de negócio e modelo de objetos de negócio.
 Requisitos (requirements) – Possibilita um melhor entendimento dos
requisitos do sistema partindo de um acordo com o cliente e com objetivo de oferecer
uma orientação aos desenvolvedores. É produzido um modelo de caso de uso
detalhado e um protótipo do sistema.
 Análise e Projeto (analysis and design) – Os requisitos capturados na
disciplina anterior são transformados em projeto. Modelos de análise e projeto são
gerados.
 Implementação (implementation) – Nesta fase, o projeto é transformado
em código. A estratégia é desenvolver o sistema em camadas, particionando em
subsistemas. O resultado final é componente testado que faz parte do produto final.
 Teste (test) – Elaboração de testes e verificação se todos os requisitos
foram cumpridos. Os documentos gerados são os modelos e casos de testes.
 Utilização (deployment) – Torna o produto disponível para o usuário final.
Responsável pelo empacotamento do produto, instalação, treinamento ao usuário e
distribuição do produto.

 Disciplinas gerenciais

 Gerenciamento de configuração – Controla as modificações e mantém

a integridade dos artefatos do projeto.
 Gerenciamento de projeto – Descreve várias estratégias para o trabalho
com um processo iterativo.
 Ambiente – Abrange infraestrutura necessária para o desenvolvimento do
sistema.

35
 2.5. Modelos de processo pessoal e de equipe

2.5.1. Personal Software Process – Processo de Software Pessoal (PSP)

O PSP é um processo de desenvolvimento criado pelo Software Engineering

Institute (SEI) (WATTS HUMPHREY, 1995), específico para engenheiros de software.
O PSP orienta o planejamento, o desenvolvimento dos componentes do software e
tem como principais objetivos:
 Melhorar a estimativa de prazo e esforço para o desenvolvimento do
software;
 Melhorar o planejamento e o acompanhamento de cronogramas;
 Evitar sobrecarga de serviços;
 Criar um comprometimento pessoal com a qualidade e com a melhoria
contínua do processo.

 O PSP é um modelo de processo que ajuda os profissionais a serem melhores

engenheiros de software. A ideia é: “A melhoria da capacidade da organização,
depende da melhoria de cada indivíduo”.

A estrutura do PSP é formada por 4 níveis, como mostra a figura 15:

Figura 15 – Estrutura do Personal Software Process (PSP)

Fonte: PIEAS, 2017 (traduzido e adaptado).

36
 A proposta do PSP como mostra a figura 15 é interagir com as práticas organizacionais
da qualidade (por exemplo: ISO 9001 e ISO 9126) e de modelos de qualidade (por exemplo:
CMMI e SPICE), de forma que os processos pessoais sejam conhecidos, controlados e
melhorados.
 PSP0 – Processo referencial: estabelecer práticas de medidas e alguns
formatos de relatórios que constituem o referencial para a implantação da melhoria
contínua pessoal. Não afeta as práticas de projeto, codificação e teste; apenas mede.
 PSP1 – Processo de planejamento pessoal: acrescenta um relatório
sobre testes e práticas de estimativa de tamanho e recurso. Depois introduz o
planejamento de tarefas e a elaboração de cronogramas.
 PSP2 – Processo de gestão pessoal da qualidade: introduz as técnicas
de inspeção e revisão para detecção de erros mais cedo.
 PSP3 – Processo pessoal cíclico: os níveis 0 a 2 são aplicáveis a
pequenos programas. Para grandes projetos, é preciso usar os princípios contidos no
nível PSP3.

Estratégia de aplicação do PSP

 Dividir o projeto em módulos.
 Desenvolvimento iterativo e incremental em cada módulo.
 Para cada iteração, usar um ciclo completo de: projeto, codificação e teste
(como em PSP2).
 Controlar a qualidade de cada iteração, assumindo que a garantia das
iterações anteriores foi conseguida ou, pelo menos verificada.

2.5.2. Team Software Process – Processo de Software da Equipe (TSP)

O TSP foi desenvolvido por Watts Humphrey em 1995 (criador do CMMI e

PSP), com enfoque na equipe de trabalho, já que o indivíduo não trabalha sozinho no
desenvolvimento de software.
O TSP foi “criado” para ser seguido por desenvolvedores previamente treinados
no PSP, para que pudessem trabalhar em equipes auto organizadas para desenvolver
softwares de qualidade, podendo vir a ser a solução para pequenas organizações de
software que se consideram muito pequenas para enfrentar as complexidades do
CMMI.

 Conceito e estrutura

As equipes são auto gerenciadas:

 A gerência provê orientação e suporte.

37
  A equipe planeja o próprio trabalho, acompanha o progresso e gerencia as
tarefas do dia a dia.
 Cada membro da equipe tem papéis e responsabilidades definidos.
 Todos os membros participam do planejamento do projeto e da tomada de
decisões chave.
 A equipe é proprietária dos seus processos e pode mudá-los sempre que
necessário.
 Os processos da equipe são baseados em sua experiência, conhecimento
e maturidade.
 As equipes aplicam práticas do Nível 5 do CMMI.

O TSP provê um conjunto de elementos:

 Scripts de processos – são guias específicos de trabalho.
 Formulários, relatórios e gráficos – reporte sobre os métodos e métricas
aplicáveis, em que são gerados dados estatísticos a partir do histórico do projeto ou
algum script de processo.
 Papéis – os papéis são definidos para cada membro da equipe, podendo
adquirir as seguintes funções como papéis: responsável pela interação com o cliente,
responsável pelo design, responsável pela implementação, gestor de testes, gestor
de planeamento, gestor de processos, gestor de qualidade, responsável pelo suporte
e líder de equipe.

 Estes elementos guiam os desenvolvedores em: criar equipes eficazes; estabelecer

metas e planos para a equipe; acompanhar e reportar o trabalho.

 Nota: O TSPi – Introductory Team Software Process é uma versão

simplificada do TSP para equipes e projetos menores, que apresenta a seguinte
arquitetura:
 Estrutura simples construída sobre o PSP.
 Desenvolvimento incremental.
 Métricas padronizadas de qualidade e performance.
 Métricas precisas para equipes e indivíduos.
 Uso de avaliações de papéis e de time.
 Exigência de disciplina de processo.
 Sugestões nos problemas do trabalho em equipe.

2.6. Exercício discursivo e comentado

38
 De acordo com Pressman, a engenharia de software é uma tecnologia em
camadas e que deve se apoiar num compromisso organizacional com o foco na
qualidade. Explique as camadas da engenharia de software e de pelo menos um
exemplo de tecnologia da engenharia de software para cada camada.
Resposta:
 Processo – mantém integradas as camadas de tecnologia, permitindo o
desenvolvimento racional e oportuno do software. Os processos formam a base para
o controle gerencial de projetos de software e estabelecem os métodos técnicos, os
produtos de trabalho (modelos, documentos, dados, relatórios, formulários), marcos
de referência, asseguram a qualidade e modificações geradas adequadamente.
Exemplo: Processo de Configuração do Software.
 Métodos – fornecem a técnicas de como fazer para construir software.
Incluem um amplo conjunto de tarefas que abrangem análises de requisitos, projeto,
modelagem, construção de programas, testes e manutenção.
Exemplo: Métodos Ágeis de Software.
 Ferramentas – fornecem apoio automatizado ou semiautomatizado para o
processo e para os métodos.
Exemplo: ferramenta CASE – Computer-aided Software Enginnering.

39
REFERÊNCIAS

BOOCH, Grady. UML – Guia do Usuário. São Paulo: Campus, 2002.

HUMPHREY, A. S. A discipline for software engineering. Reading, Mass.: Addison-
Wesley, 1995.
IBM. Processo iterativo controlado para desenvolvimento de software. IBM
Software Group: Disponível em: http://www.br.ibm.com. Acesso em: 2003.
KRUCHTEN, Philippe. The rational unified process: an introduction. 2. ed. USA:
Addison-Wesley, 2000.
LAUDON, Kenneth C.; LAUDON, Jane P. Sistemas de informação gerencial:
administrando a empresa digital. 5. ed. São Paulo: Prentice Hall, 2004.
PAULA FILHO, W. de P. Engenharia de software: fundamentos, métodos e padrões.
3. ed. Rio de Janeiro: L TC, 2012.
PFLEEGER, Shari Lawrence. Engenharia de software. 2. ed. São Paulo: Prentice
Hall, 2004.
PRESSMAN, Ph.D. Roger S. Engenharia de software: uma abordagem profissional.
7. ed. Rio de Janeiro: McGraw-Hill, 2011.
PRESSMAN, Ph.D. Roger S. Engenharia de software. 5. ed. Rio de Janeiro:
McGraw-Hill, 2002.
SERRA, Ana Paula. Modelos de processo pessoal e de equipe. São Paulo:
Conferência da qualidade de software, 4., Universidade São Judas. Disponível em:
http://asrconsultoria.com.br/. Acesso em: set. 2017.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson Prentice
Hall, 2011.
STAIR, Ralph M.; REYNOLDS, George W. Princípios de sistemas de informação:
uma abordagem gerencial. 6. ed. São Paulo: Pioneira – Thomson Learning, 2006.
BIBLIOGRAFIA
FIORINI, Soeli; STAA, Arndtvon; BAPTISTA, Renam Martins. Engenharia de
software com CMM. Rio de Janeiro Brasport, 1998.
IMOVELWEB. Entenda como a computação gráfica vem sendo utilizada no
mercado imobiliário. Disponível em:
https://www.imovelweb.com.br/noticias/socorretor/tecnologia-e-inovacao/entenda-
como-computacao-grafica-vem-sendo-utilizada-no-mercado-imobiliario/. Acesso em:
jul. 2019.
KOSCIANSKI, André. Qualidade de software: aprenda as metodologias e técnicas
mais modernas para o desenvolvimento de software. 2. ed. São Paulo: Novatec
Editora, 2007.
KRUCHTEN, Phillippe. Introdução ao RUP – Rational Unified Process. 2. ed. Rio de
Janeiro: Editora Ciência Moderna, 2001.
PAKISTAN INSTITUTE OF ENGINEERING AND APPLIED SCIENCES (PIEAS).
Software Development Methodologies, Computer Science. Paquistão, Islamabad:
Pakistan Institute of Engineering and Applied Sciences (PIEAS), 2017. Disponível em:

40
https://www.docsity.com/en/cyclic-personal-process-software-quality-lecture-
slides/80929/. Acesso em: nov. 2017.
Project Management Body of Knowledge (PMBOK). Um guia do conhecimento em
gerenciamento de projetos (Guia PMBOK). 4. ed. Atlanta, USA: Project
Management Institute, Inc. 2010.
PRESSMAN, Ph.D. Roger S. Engenharia de software. 6. ed. Rio de Janeiro:
McGraw-Hill, 2007.
REZENDE, Denis Alcides. Engenharia de software e sistemas de informação. 3. ed.
Rio de Janeiro: Brasport, 2005.
O’BRIEN, JAMES A. Sistemas de informação e as decisões gerenciais na era da
internet. São Paulo: Saraiva, 2002.
ROCHA, Roberto dos Santos. Modelagem do processo de desenvolvimento e
manutenção de software para a UINFOR/UESB. Bahia: UINFOR/UESB, 2006.
Artigo.
SERRA, Ana Paula. Modelos de processo pessoal e de equipe. São Paulo:
Conferência da Qualidade de Software, 4., Universidade São Judas.
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Addison-Wesley, 2003.
STAIR, Ralph M.; REYNOLDS, George W. Princípios de sistemas de informação:
uma abordagem gerencial. 6. ed. São Paulo: Pioneira – Thomson Learning, 2006.

41