363

Aula 1º

Introdução à Engenharia
de Software

Olá, pessoal, tudo bem?

Iniciamos a disciplina de Engenharia de software I. Espero que
a disciplina contribua com o entendimento e aprendizado de vocês
a respeito. Para tanto, vamos abordar alguns conceitos introdutórios.
Qualquer dúvida, entrem em contato via quadro de avisos, certo?
Vamos lá?
Bons estudos!

Figura 1: <http://www.cbsi.net.br/2014/10/curso-de-engenharia-de-software-gratuito.html>. Acesso em: 05 abr. 2017.

Objetivos de aprendizagem

Esperamos que, ao término desta aula, vocês sejam capazes de:

‡HQWHQGHURVFRQFHLWRVGHVRIWZDUHHHQJHQKDULDGHVRIWZDUH
‡FRQKHFHURVXUJLPHQWRGRFDPSRGHVRIWZDUH
364 Engenharia de Software I 8
especial, um sistema de computador é capaz
Seções de estudo de executar. Podemos considerar que um
software é uma solução para um determinado
problema. Essa solução pode ser composta por
1 - Engenharia de software: conceitos iniciais
vários programas de computador formando
2 - O que é a engenharia de software? um sistema de software. Assim, um sistema
de software é um conjunto de programas de
computador que operam de forma conjunta
1 - Engenharia de software: conceitos para solucionar problemas de uma determinada
iniciais área. Em um sentido mais amplo, Sommerville
A engenharia de software engloba as técnicas e lógicas
que dizem respeito a dados, atividades, tecnologia e pessoas.
Ela permite que se desenvolva o planejamento, a análise, a
projeção e a construção e a manutenção dos sistemas de
processamento de dados, por meio de uma ação integrada e
inteligente. Além da definição dada, é importante sabermos:
quando surge e por que surge a discussão a respeito da
temática?
Os conhecimentos a respeito de software ganharam
força há pouco tempo. Há algumas décadas:
[…] menos de 1% do público poderia
GHVFUHYHUGHIRUPDLQWHOLJtYHORTXHVLJQLÀFD
“software de computador”. Hoje, a maioria
GRV SURÀVVLRQDLV EHP FRPR D PDLRU SDUWH
do público, acham que entendem o que é
software. Será que entendem? Uma descrição
de software num livro didático poderia
assumir a seguinte forma: “Software é: (1)
instruções (programas de computador) que,
quando executadas, produzem a função e
 S  DÀUPD TXH XP VLVWHPD TXH
descreve a estrutura desse sistema, e a
documentação do usuário, que explica como
utilizar o sistema e, no caso dos produtos
de software, sites da Web para os usuários
fazerem download das informações recentes
do produto” (PARREIRA JÚNIOR, 2013).
Como pudemos notar na citação, o software diz respeito aos
programas disponíveis em um equipamento, principalmente,
quando associados ao sistema de um computador. Os sistemas,
associados, formam o que chamamos de software. Para tanto, é
importante entender que, no software, há diversos programas
que são particulares, mas que atuam em conjunto.
Nessa perspectiva, de que modo atua o profissional
responsável por gerir a engenharia de software?
Um produto de software é um sistema que
pode ser disponibilizado para uma clientela.
Esses produtos podem ser genéricos
personalizados. Produtos genéricos são
R GHVHPSHQKR GHVHMDGRV  HVWUXWXUDV GH
dados que possibilitam que os programas
PDQLSXOHP DGHTXDGDPHQWH D LQIRUPDomR H
(3) documentos que descrevem a operação e
o uso dos programas”. Não há duvida de que
RXWUDV GHÀQLo}HV PDLV FRPSOHWDV SRGHULDP
ser oferecidas. Mas precisamos de algo mais
TXH XPD GHÀQLomR IRUPDO 3$55(,5$
JÚNIOR, 2013).
Como pode ser notado na citação, o software diz respeito
ao modo de organizar informações e manipulá-las por meio
de programas. De modo geral, o software se relaciona à
informação e à sua manipulação. Porém, como a própria
citação defende, não adianta somente entender a definição
elementar, certo? Vamos avançar, então?
Vocês já devem ter percebido que, quando se fala em
software, as pessoas associam, imediatamente, aos programas
de computador. Como interessados no assunto, contudo,
vocês talvez já saibam que essa é uma visão possível somente
no senso comum: enquanto profissionais da área entendam:
essa é uma visão restrita e insuficiente.
Na verdade, o software engloba todos os dados e
informações documentados. Eles provêm de diversas
naturezas. perpassam pelas bases de dados e envolvem
os procedimentos manuais que estão integrados aos
sistemas de software produzidos por uma
organização e comercializados para qualquer
cliente que seja capaz de utilizá-los. Produtos
personalizados são sistemas de software
desenvolvidos para atender às necessidades
de um cliente em especial. Em ambos os
casos, a empresa produtora disporá de
um processo de software. O processo
de software é o conjunto de atividades
gerenciais e tecnológicas, bem como os
resultados gerados por tais atividades, que um
determinado produtor de software emprega
no desenvolvimento e na manutenção de
seus produtos de software (AUDI et al.,
2007, p. 171).
Bom, já entendemos, até aqui, a relação entre tecnologia
e software, certo? É papel do produtor de software, então,
desenvolver e promover a manutenção dele. Aos poucos,
tenho certeza de que vocês se apropriarão da teoria relacionada
e conseguirão ampliar o conhecimento de vocês no que
tange à nossa temática. Lembrem-se de que há os produtos
genéricos e os produtos sob encomenda, também chamados
de personalizados. Os primeiros dizem respeito aos produtos
disponibilizados, por meio de venda. Entre eles, podem-se
automatizados. Então, quando tratamos de todo o sistema de
software, falamos de:
A palavra software designa o conjunto
de programas que um equipamento e, em
FLWDU0LFURVRIW:RUG%52IÀFH$GREH3KRWRVKRSHWF-i
os segundos são os sistemas feitos de modo particular a uma
empresa, por exemplo.
O que diferencia um e o outro é o fato de que os produtos
personalizados podem ser organizados de modo a atender
 9 365
às necessidades de um cliente, que, por sua vez, geralmente,
representa uma empresa. Há também casos em que as empresas,
de posse de um produto genérico, alteram-no de acordo com
as necessidades específicas.
)LJXUD6RIWZDUH)RQWHKWWSȴHOGJXLGHJL]PRGRFRPDOOWKHFRROEHWDVRI
tware-you-can-use-for-free-1765553479>. Acesso em: 16 mar. 2017.
Entendidas questões inicias acerca do software, vamos
discutir a engenharia de software, em específico?
2 - O que é a engenharia de software?
A engenharia de software é uma disciplina que se associa
a todas as etapas da produção do software. Nessa perspectiva,
não está relacionada somente às técnicas e processos de
desenvolvimento do software, mas, também, às atividades
a respeito do gerenciamento do projeto de software e ao
desenvolvimento das ferramentas, dos métodos e das teorias
que dão suporte à produção do software.
Segundo Júlio Cesar Leite (1991, p. 2),
na maioria das organizações que se utilizam
de sistemas computacionais para apoio às
suas atividades, os conceitos de Sistemas de
Informação e de Engenharia de Software se
misturam no que comumente se chama de
Desenvolvimento de Sistemas. Esta mistura
GH iUHDV DÀQV PDV GLIHUHQFLDGDV p QR QRVVR
entender, um dos principais problemas
encontrados pelos gerentes de informática.
Como se nota, para Leite (1991), é comum, em empresas, os
conceitos a respeito de Sistemas de Informação se misturarem
ao de Desenvolvimento de Sistemas. Essa “confusão” é
responsável por originar diversos problemas, entre eles:
‡FULDomRGHURWLQDVDGPLQLVWUDWLYDV
‡SULRULGDGHVGHGHVHQYROYLPHQWR
‡SURFHGLPHQWRVRSHUDFLRQDLV
‡PRWLYDomR
‡LPSDFWRVQDVURWLQDVGHWUDEDOKR
‡DORFDomRGHPmRGHREUD
‡WUHLQDPHQWRGHXVXiULRV
se misturam com problemas de:
‡ HVFROKD GH IHUUDPHQWDV GH DSRLR DR
desenvolvimento de software,
‡SUREOHPDVGHWUHLQDPHQWRGHSHVVRDOWpFQLFR
‡ DFRPSDQKDPHQWR GH SURMHWRV GH VRIWZDUH
(LEITE, 1991, p. 2).
Assim, prcebe-se que, não aplicar a teoria à prática pode
gerar alguns problemas bastante relevantes na atuação do
profissional. É importante, nessa perspectiva, entender os
objetivos da engenharia de software.
Em sua origem, a engenharia de software foi concebida
com o propósito de lidar com os sistemas básicos, compiladores
e sistemas operacionais.
Para entender mais, é preciso conhecer alguns conceitos:
8UQD SULPHLUD GHÀQLomR GH HQJHQKDULD GH
software foi proposta por Fritz Bauer na
primeira grande conferencia dedicada ao
assunto: ‘O estabelecimento e uso de sólidos
princípios de engenharia para que se possa
obter economicamente um software que
IXQFLRQH HÀFLHQWHPHQWH FRP PiTXLQDV UHDLV·
(PARREIRA JUNIOR, 2013).
Basicamente, propunha-se a existência de uma engenharia
que proporcionasse um uso economicamente viável no que
diz respeito à tecnologia de software, envolvendo, sempre,
o uso das máquinas. Nessa direção, pode-se afirmar que
a engenharia de software foi concebida com o intuito de
integrar a engenharia de sistemas, bem como a engenharia de
hardware.
Ela abrange um conjunto de três elementos
fundamentais - métodos, ferramentas e
procedimentos - que possibilita ao gerente
o controle do processo de desenvolvimento
GR VRIWZDUH H RIHUHFH DR SURÀVVLRQDO XPD
base para a construção de software de alta
qualidade produtivamente. Os métodos de
engenharia de software proporcionam os
detalhes de “como fazer” para construir o
software. Os métodos envolvem um amplo
conjunto de tarefas que incluem: planejamento
c estimativa de projeto, análise de requisitos
de software e de sistemas, projeto da estrutura
de dados, arquitetura de programa e algoritmo
GH SURFHVVDPHQWR FRGLÀFDomR WHVWH H
manutenção. Os métodos da engenharia
de software muitas vezes introduzem uma
QRWDomR JUiÀFD RX RULHQWDGD D OLQJXDJHP
especial e introduzem um conjunto de critérios
para a qualidade do software. As ferramentas
de engenharia de software proporcionam
apoio automatizado ou semiautomatizado aos
métodos (PRESSMAN, 19995, p. 31).
Hoje, contudo, há ferramentas que permitem o sustento
de cada um dos métodos discutidos. Assim, quando as
ferramentas se integram e a informação criada pode ser
utilizada por outra ferramenta, notamos que se estabelece
um sistema que integra as ferramentas. Esse suporte é o que
chamamos de engenharia de software. Ela tem o suporte
de um computador (CASE - Computer-Aided Software
Engineering), que, por sua vez,
[…] combina software, hardware e um banco
de dados de engenharia de software (uma
estrutura de dados contendo importantes
informações sobre analise, projeto,
366 Engenharia de Software I 10
FRGLÀFDomRHWHVWHSDUDFULDUXPDPELHQWHGH
engenharia de software que seja análogo ao
projeto auxiliado por computador/engenharia
auxiliada por computador para o hardware.
Os procedimentos da engenharia de software
constituem o elo de ligação que mantém juntos
os métodos e as ferramentas e possibilita
o desenvolvimento racional e oportuno do
software de computador. Os procedimentos
GHÀQHPDVHTrQFLDHPTXHRVPpWRGRVVHUmR
aplicados, os produtos (deliverables) que se
exige que sejam entregues (documentos,
relatórios, formulários etc.), os controles
que ajudam a assegurar a qualidade e a
coordenar as mudanças, e os marcos de
referência que possibilitam aos gerentes de
software avaliar o progresso (PARREIRA
JUNIOR, 2013, p. 8).
É visível, então, que a engenharia de software envolve
etapas que, por sua vez, envolvem métodos, ferramentas e
procedimentos. Tais etapas são, comumente, classificadas
como paradigmas. Cada paradigma é selecionado de acordo
com as especificidades do projeto. Considera-se sua natureza,
as aplicações necessárias, os métodos e as ferramentas que
serão utilizados. Também se levam em conta os produtos que
serão entregues.
É necessário refletir a respeito do fato de que os
profissionais com formação em Análise de Sistemas
devem atuar em seu próprio campo. Nele, os contatos
com a organização e com seu complexo social são bastante
APLICAÇÕES E DESAFIOS DA ENGENHARIA
DE SOFTWARE
Agora que vocês já conhecem alguns conceitos básicos
a respeito da teoria da engenharia de software, é necessário
entendermos, primeiro, qual a aplicação do software e quais
os desafios relacionados à área de atuação da engenharia de
software. Se já sabemos que o software diz respeito ao complexo
de programas dos Sistemas de Informática, e que cada
componente existente em um meio computacional se constitui
em um software, concluímos, então, que há especificidades no
que tange às classificações. O software, dessa forma, pode ser:
‡ %iVLFR – Programas escritos para apoiarem outros
programas. São eles: compiladores, editores de textos, sistemas
RSHUDFLRQDLV
‡7HPSRUHDO - Responde dentro de restrições de tempo
estritas. Monitora, analisa e controla eventos do mundo real.
Está presente em sistemas de controle de voo, sinalização de
WUkQVLWR
‡&RPHUFLDO – Responsáveis por reestruturar os dados de
uma forma que facilita as operações comerciais e a tomada de
decisões administrativas: folha de pagamento, contas a pagar
HUHFHEHUHVWRTXHRSHUDo}HVFRPHUFLDLVHGHDSRLRjGHFLVmR
‡&LHQWtÀFRHGH(QJHQKDULD – Englobam os sistemas de
astronomia, o controle da dinâmica orbital de naves espaciais,
os sistemas de manufatura automatizada (CAD-Computer Aided
Design ou Desenho auxiliado por computador, CAE-Computer
Aided Engineering ou Engenharia auxiliada por computador,
CAM-Computer Aided Manufacturing ou Manufatura auxiliada
SRUFRPSXWDGRU
frequentes. Assim, não se deve supor que os profissionais
de Sistemas de Informação substituem os usuários no
contato com os Engenheiros de Software. Os usuários e
os engenheiros de software entram em contato quando é
necessário, do mesmo modo, ocorre com os profissionais de
sistemas de informação. Quando a divisão de tarefas é feita de
modo eficaz, é possível que os engenheiros atentem a aspectos
da engenharia de modo detalhado. Do mesmo modo, ocorre
com os especializados em sistemas de informação.
Quando atentamos a essa explicação, contudo, não
dizemos que um profissional não tem capacidade para
mesclar os campos. É possível, sim, que o especialista em
Sistemas de Informação atue desenvolvendo um sistema de
informação completo e sendo responsável, inclusive, pelo
sistema computacional. Em contrapartida, é possível que os
engenheiros de software atuem desenvolvendo um protótipo
de software e realizar a interação direta com os usuários,
como, por exemplo, ao se implantar um sistema. Quem
decide o modo como a divisão será realizada é o gerente que
é responsável pela função informática.
Tratando em aspectos conceituais, ciência da computação
e análise de sistemas englobam teorias e métodos que
sustentam a base de computadores e sistemas de software.
Estão relacionadas ao desenvolvimento de hardware, projeto
de políticas e de processos e implantação do sistema, ou seja,
com a especiação do sistema. Já a engenharia de software
se dedica aos problemas práticos de produção de software,
adotando técnicas como modelagem de casos de uso e
JHUHQFLDPHQWRGHFRQÀJXUDomR
‡ (PEXWLGR HPEHGGHG VRIWZDUH – Ele controla
produtos e sistemas para os mercados industriais e de consumo.
Responsável pelas funções digitais em automóveis (controle
de combustível, sistema de freios), controle de teclado para
IRUQRVPLFURRQGDV
‡ 'H FRPSXWDGRU SHVVRDO – Faz o processamento de
WH[WRVSODQLOKDVHOHWU{QLFDVHJHUHQFLDGRUGHEDQFRVGHGDGRV
‡ 'H LQWHOLJrQFLD DUWLÀFLDO ,$) – Softwares baseados
em conhecimento.
Como se vê, a engenharia do software possui a capacidade
de ser multifacetada quanto a seu campo de atuação. O
profissional define, junto às necessidades da empresa que o
contrata, como o software será desenvolvido.
Nessa perspectiva, é válido questionar: quais são, então, os
desafios da profissão na contemporaneidade? É esse o nosso
próximo assunto.
Pode-se afirmar que há três dificuldades básicas na atuação
no campo da engenharia de software. Vejamos abaixo:
‡ KHWHURJrQHD WHFQRORJLD OHYDQGR HP FRQWD D GHPDQGD
do momento.
‡ 1D PHVPD GLUHomR p LPSRUWDQWH FRQVLGHUDU R WHPSR
de entrega. É importante que o profissional trabalhe o mais
rápido possível, sem deixar cair, contudo, a qualidade de seu
serviço. Dinamicidade é a palavra de ordem para o profissional.
‡ *DUDQWLU D FRQILDELOLGDGH GR FOLHQWH QmR p WDUHID IiFLO
Pode levar um tempo, então, para que o profissional forme
uma visão positiva a respeito de seu trabalho. ética e qualidade,
então, são palavras-chave para garantir um bom retorno.
 11 367
Sommerville (2011) elaborou uma tabela na qual discute
algumas questões básicas acerca do assunto. Vejam abaixo se Vale a pena
têm algumas de suas dúvidas esclarecidas:

Vale a pena acessar

O guia do estudante discute alguns aspectos

relacionados à profissão: <http://guiadoestudante.abril.
com.br/profissoes/engenharia-de-software/>. Acesso em:
05 abr. 2017.

Vale a pena assistir

O vídeo Engenharia de software retoma alguns dos

conceitos aqui discutidos. Disponível em: <https://www.
youtube.com/watch?v=WQr1GXar9N8>. Acesso em: 5
abr. 2017.

Minhas anotações

Sommerville (2011, p. 4).

Retomando a aula

Parece que estamos indo bem. Então, para encerrar esta

aula, vamos recordar:

²(QJHQKDULDGHVRIWZDUHFRQFHLWRVLQLFLDLV
Vimos, na seção I, que a engenharia de software engloba
as técnicas e lógicas que dizem respeito a dados, atividades,
tecnologia e pessoas. Ela permite que se desenvolva o
planejamento, a análise, a projeção e a construção e a
manutenção dos sistemas de processamento de dados, por
meio de uma ação integrada e inteligente.

2TXHpDHQJHQKDULDGHVRIWZDUH"
A engenharia de software é uma disciplina que se associa
a todas as etapas da produção do software. Nessa perspectiva,
não está relacionada somente às técnicas e processos que dizem
respeito ao desenvolvimento do software, mas, também, às
atividades a respeito do gerenciamento do projeto de software
e ao desenvolvimento das ferramentas, dos métodos e das
teorias que dão suporte à produção do software.
368 Engenharia de Software I

2º Aula

Processos de software

Olá, pessoal!
Chegamos à aula 2 e, nela, vamos discutir os
processos de software. Um processo de software pode
ser definido como um conjunto de passos que são
parcialmente ordenados, e tem por base atividades,
métodos, práticas e transformações com o propósito de
atingir uma meta.
Vamos lá?
Boa aula!

Objetivos de aprendizagem

Esperamos que, ao término desta aula, vocês sejam capazes de:

‡FRPSUHHQGHURVFRQFHLWRVHPRGHORVGHSURFHVVRVGHVRIWZDUH
‡HQWHQGHURPRGHORVGRVSURFHVVRVGHVRIWZDUH
 13
Seções de estudo
1 - Processos de software
2 - Modelos de processos de software
1 - Processos de software
Para Somerville (2011), um processo de software diz
respeito ao conjunto de atividades que são relacionadas e
que levam à produção de um produto de software. Portanto,
o processo de software culmina no produto final, entendido
como produto de software. As atividades podem estar
relacionadas ao desenvolvimento de software a partir do zero,
seguindo uma linguagem padrão, como Java ou C. Contudo, em
aplicações de negócios não há necessidade de seguir essa regra.
No mundo nos negócios, cada vez mais, há o desenvolvimento
de novos softwares por meio da modificação e alteração de
sistemas já existentes e que podem ser reconfigurados. Apesar
de já existirem diversas variações em um processo de software,
basicamente, devem-se seguir quatro atividades fundamentais:
(VSHFLÀFDomRGHVRIWZDUH$IXQFLRQDOLGDGH
do software e as restrições a seu funcionamento
GHYHPVHUGHÀQLGDV
2. Projeto e implementação de software. O
software deve ser produzido para atender às
HVSHFLÀFDo}HV
3. Validação de software. O software deve ser
validado para garantir que atenda às demandas
do cliente.
4. Evolução de software. O software deve
evoluir para atender às necessidades de
mudança dos clientes.
De alguma forma, essas atividades fazem parte
de todos os processos de software. Na prática,
são atividades complexas em si mesmas,
que incluem subatividades como validação
de requisitos, projeto de arquitetura, testes
unitários etc. Existem também as atividades que
dão apoio ao processo, como documentação e
JHUHQFLDPHQWR GH FRQÀJXUDomR GH VRIWZDUH
(SOMERVILLE, 2011, p. 18).
A título de ilustração, vejam um exemplo: um processo é
XPDUHFHLWDTXHpVHJXLGDSRUXPSURMHWRRSURMHWRFRQFUHWL]D
uma abstração, que é o processo. Não se deve confundir um
processo (digamos, uma receita de bolo de laranja) com o
respectivo produto (bolo de laranja) ou com a execução do
processo através de um projeto (a confecção do bolo de laranja
por determinado cozinheiro, em determinado dia).
3UHVVPDQDVVLPGHÀQLXSURFHVVRGHVRIWZDUH´4XDQGR
você elabora um produto ou sistema é importante percorrer
uma série de passos previsíveis – um roteiro que o ajuda a criar
a tempo um resultado de alta qualidade. O roteiro que você
segue é o processo de software” (PRESSMAN, 2006).
Continuando, em engenharia de software, os processos
podem ser definidos como as atividades realizadas para a
manutenção, para a aquisição, para a contratação de um
369
software. Nessa perspectiva, engloba todos os subprocessos
necessários. Um processo de software envolve diversos
subprocessos que determinam os requisitos, a análise, o
desenho, a implementação e os testes.
Figura 1: <http://www.macoratti.net/proc_sw1.htm>. Acesso em: 05 abr. 2017.
Quando se é necessário descrever ou discutir os
processos, geralmente tratamos das suas atividades e as
relacionamos a um modelo específico de dados e ao modo
como tais atividades estão descritas. Contudo, as descrições
do processo podem envolver, também:
Produtos: diz respeito aos resultados de uma das
atividades do processo. Para exemplificar, uma atividade de
projeto de arquitetura resulta em um modelo de arquitetura
de software.
Papéis: eles refletem as responsabilidades, as funções das
pessoas envolvidas no processo. Ex.: gerente de configuração,
programador, entre outros.
Pré e pós-condições: são as declarações feitas antes
e depois de uma atividade do processo e que validam a sua
veracidade. Ex.: é necessário que seja obtido uma confirmação
do cliente em relação à aprovação de todos os requisitos.
Já percebemos que todas as atividades relacionadas aos
processos de software são complexas e dependem de pessoas,
ou seja, os envolvidos devem exercer sua intelectualidade,
criatividade e ética. Para tanto, tudo precisa ser bem definido
e claro para que os sujeitos envolvidos atuem de modo a
favorecer a empresa. Assim, as pessoas dão o seu melhor
e o processo de software é aproveitado da melhor maneira
possível:
Para alguns sistemas, como sistemas críticos,
é necessário um processo de desenvolvimento
PXLWR EHP HVWUXWXUDGR SDUD VLVWHPDV GH
negócios, com requisitos que se alteram
UDSLGDPHQWH SURYDYHOPHQWH VHUi PDLV HÀFD]
XPSURFHVVRPHQRVIRUPDOHPDLVÁH[tYHO
Os processos de software, às vezes, são
categorizados como dirigidos a planos ou
processos ágeis. Processos dirigidos a planos
são aqueles em que todas as atividades são
planejadas com antecedência, e o progresso é
avaliado por comparação com o planejamento
inicial. Em processos ágeis, que discuto no
Capítulo 3, o planejamento é gradativo, e
é mais fácil alterar o processo de maneira
D UHÁHWLU DV QHFHVVLGDGHV GH PXGDQoD GRV
370 Engenharia de Software I
clientes. Conforme Boehm e Turner (2003),
cada abordagem é apropriada para diferentes
tipos de software. Geralmente, é necessário
encontrar um equilíbrio entre os processos
dirigidos a planos e os processos ágeis.
(PERUD QmR H[LVWD XP SURFHVVR ¶LGHDO· GH
software, há espaço, em muitas organizações,
para melhorias no processo de software. Os
processos podem incluir técnicas ultrapassadas
ou não aproveitar as melhores práticas de
engenharia de software da indústria. De fato,
muitas empresas ainda não se aproveitam dos
métodos da engenharia de software em seu
desenvolvimento de software.
Em organizações nas quais a diversidade de
processos de software é reduzida, os processos
de software podem ser melhorados pela
padronização. Isso possibilita uma melhor
comunicação, além de redução no período de
treinamento, e torna mais econômico o apoio
ao processo automatizado. A padronização
também é um importante primeiro passo
na introdução de novos métodos e técnicas
de engenharia de software, assim como as
boas práticas de engenharia de software
(SOMMERVILLE, p. 2013, p. 19).
Agora que vocês já têm um conhecimento importante
sobre o assunto, é hora de aprofundarmos e verificarmos
alguns dos modelos de processos de software. Ao conhecer
cada um deles, atentem às especificações e particularidades
envolvidas. Em caso de dúvidas, não hesitem em me contatar
pelo quadro de avisos, ok?
2 - Modelos de processos de software
Um modelo de desenvolvimento diz respeito a uma
apresentação do processo de desenvolvimento que irá definir
as etapas relacionadas ao desenvolvimento de software.
Eles definem, também, de que modo as etapas serão
conduzidas e relacionadas de forma a alcançar o objetivo,
que é o desenvolvimento de um produto de software de alta
qualidade, e com o menor custo possível. Vamos conhecer
cada um deles?
2.1 - O Modelo em cascata
O primeiro que verificaremos é o modelo em cascata.
Aliás, ele é o primeiro modelo desenvolvido. Sua origem está
relacionada aos processos mais abrangentes da engenharia de
sistema. Devido ao encadeamento de uma fase na outra, vem
seu nome: modelo em cascata:
O resultado de cada fase envolve um ou mais
documentos que são aprovados e assinados.
A fase seguinte só é iniciada após a conclusão
da fase precedente, mas na prática eles se
sobrepõem e trocam informações. Durante
R SURMHWR VmR LGHQWLÀFDGRV SUREOHPDV FRP
RV UHTXLVLWRV GXUDQWH D FRGLÀFDomR VmR
YHULÀFDGRV SUREOHPDV GR SURMHWR H DVVLP
14
por diante. O processo não é um modelo
linear simples, mas envolve uma sequência de
interações das atividades de desenvolvimento
(PARREIRA JUNIOR, 2011, p. 29).
Figura 2. Modelo em cascata. Sommerville, 2013.
O modelo em cascata envolve, basicamente, as seguintes
etapas:
1. Análise e definição de requisitos: são definidas todas as
atividades e exigências, a partir do contato com o usuário.
2. Projeto de sistema e software: faz-se a identificação
e descrição das abstrações do sistema de software e de seus
relacionamentos. Diz respeito a uma arquitetura geral do
sistema.
3. Implementação e teste unitário: observa-se, nessa
atividade, se cada uma das unidades do software está atendendo
a sua especificação e função.
4. Integração e teste de sistema: as unidades, primeiramente,
individuais, nessa fase, não integradas e testadas no conjunto.
1RWHTXHQDIDVHDQWHULRUHODVIRUDPWHVWDGDVLQGLYLGXDOPHQWH
aqui, são testadas no conjunto.
5. Operação e manutenção: é a fase mais longa, geralmente,
pois o sistema é utilizado. Durante esse processo, a partir do
momento que o sistema está em uso, podem ser corrigidas
possíveis falhas.
2.2 - Prototipação
Esse modelo é indicado quando o cliente define uma série
de objetivos gerais para o software, mas não identificou os
requisitos de entrada, de processamento e de saída de modo
detalhado. Inicialmente, a finalidade de um protótipo era a de
avaliar os requisitos e, então, o desenvolvimento tradicional
não era necessário. Agora, praticamente não há definição entre
prototipação e o desenvolvimento de sistemas. Um protótipo
pode ser entendido com a primeira versão do software. O
objetivo é o de abordar a questão de interface com o usuário,
definir requisitos e discutir, com o cliente, a possibilidade de
desenvolvimento do sistema.
A prototipação permite que clientes e desenvolvedores
fiquem em interação constante e, juntos, elaborem os
requisitos e funcionalidades do sistema. Deve-se atentar que
muitas vezes a prototipação encarece o sistema, pois, alguns
desenvolvedores costumam elaborar um projeto de protótipo
e um projeto do sistema final, o que vem provocando a redução
de sua utilização.

Figura 3: <https://centraldaengenharia.wordpress.com/2011/02/09/paradigmas
-prototipacao/>. Acesso em: 05 abr. 2017.
A principal aplicação da prototipação é no auxílio a
clientes e desenvolvedores no entendimento dos requisitos
para o sistema. Os usuários podem experimentar o protótipo
para ver como o sistema pode apoiar seu trabalho, o que é
uma vantagem. Esse modelo pode também revelar erros e
omissões nos requisitos, ou seja, pode promover a validação
dos requisitos.
O desenvolvimento da prototipação pode, assim, reduzir
diversos riscos nos requisitos dos sistemas.
Vamos ver um pequeno excerto de Sommerville (2013, p.
31) acerca da prototipação:
2HVW£JLRȴQDOGRSURFHVVR«DDYDOLD©¥RGRSURWµWLSR'XUDQWHHVVH
estágio, provisões devem ser feitas para o treinamento do usuário, e
RV REMHWLYRV GR SURWµWLSR GHYHP VHU XVDGRV SDUD GHULYDU XP SODQR
de avaliação. Os usuários necessitam de um tempo para se sentir
confortáveis com um sistema novo e para se situarem em um padrão
normal de uso. Uma vez que estejam usando o sistema normalmente,
eles descobrem erros e omissões de requisitos.
8PSUREOHPDJHUDOFRPDSURWRWLSD©¥R«TXHRSURWµWLSRSRGHQ¥R
VHUQHFHVVDULDPHQWHXVDGRGDPHVPDIRUPDFRPRRVLVWHPDȴQDO2
WHVWDGRUGRSURWµWLSRSRGHQ¥RVHUXPXVX£ULRW¯SLFRGRVLVWHPDRXR
WHPSRGHWUHLQDPHQWRGXUDQWHDDYDOLD©¥RGRSURWµWLSRSRGHWHUVLGR
LQVXȴFLHQWHSRUH[HPSOR6HRSURWµWLSR«OHQWRRVDYDOLDGRUHVSRGHP
ajustar seu modo de trabalho e evitar os recursos do sistema que têm
tempos de resposta lentos.
4XDQGR HTXLSDGRV FRP PHOKRUHV UHVSRVWDV QR VLVWHPD ȴQDO HOHV
podem usá-lo de forma diferente.
Às vezes, os desenvolvedores são pressionados pelos gerentes para
HQWUHJDU SURWµWLSRV GHVFDUW£YHLV HVSHFLDOPHQWH TXDQGR K£ DWUDVRV
QDHQWUHJDGDYHUV¥RȴQDOGRVRIWZDUH1RHQWDQWRLVVRFRVWXPDVHU
desaconselhável:
1.3RGHVHULPSRVV¯YHODMXVWDURSURWµWLSRSDUDDWHQGHUDRVUHTXLVLWRV
não funcionais, como requisitos de desempenho, proteção, robustez
HFRQȴDELOLGDGHTXHIRUDPLJQRUDGRVGXUDQWHRGHVHQYROYLPHQWRGR
SURWµWLSR
2. Mudanças rápidas durante o desenvolvimento inevitavelmente
VLJQLȴFDPTXHRSURWµWLSRQ¥RHVW£GRFXPHQWDGR
$ ¼QLFD HVSHFLȴFD©¥R GH SURMHWR « R FµGLJR GR SURWµWLSR 3DUD D
PDQXWHQ©¥RDORQJRSUD]RLVVRQ¥R«ERPRVXȴFLHQWH
3.$VPXGDQ©DVGXUDQWHRGHVHQYROYLPHQWRGRSURWµWLSRSURYDYHOPHQWH
WHU¥RGHJUDGDGRDHVWUXWXUDGRVLVWHPD2VLVWHPDVHU£GLI¯FLOHFXVWRVR
de ser mantido.
15 371
4.3DGU·HVGHTXDOLGDGHRUJDQL]DFLRQDOJHUDOPHQWHV¥RUHOD[DGRVSDUD
RGHVHQYROYLPHQWRGRSURWµWLSR
3URWµWLSRVQ¥RSUHFLVDPVHUH[HFXW£YHLVSDUDVHUHP¼WHLV0DTXHWHV
em papel da interface de usuário do sistema (RETTIG, 1994) podem
VHUHȴFD]HVHPDMXGDURVXVX£ULRVDUHȴQDURSURMHWRGHLQWHUIDFHH
trabalhar por meio de cenários de uso. Estes são muito baratos de se
GHVHQYROYHUHSRGHPVHUFRQVWUX¯GRVHPSRXFRVGLDV8PDH[WHQV¥R
GHVVDW«FQLFD«RSURWµWLSR0£JLFRGH2]QRTXDODSHQDVDLQWHUIDFH
de usuário é desenvolvida. Os usuários interagem com essa interface,
mas suas solicitações são passadas para uma pessoa que os interpreta
e produz a resposta adequada.
Já percebemos que ele tem vantagens e desvantagens, não
é? Qual seu ponto de vista? Compartilhem no quadro de avisos!
2.3 - O modelo espiral
O modelo espiral foi preparado para abranger, de modo
geral, as melhores características do ciclo de vida clássico e
as da prototipação. Além disso, o propósito é o de adicionar
um novo elemento: análise de riscos. Notamos que ele parte
de outros tipos de modelo, e busca lidar com os benefícios
ofertados por um e outro. Para tanto, suas etapas envolvem,
necessariamente,
‡3ODQHMDPHQWR
‡$QiOLVHHSURMHWR
‡3URWRWLSDomR
‡$YDOLDomR
Os passos vão sendo retomados e somente são
finalizados quando o projeto é obtido. Há, portanto, para seu
desenvolvimento, quatro atividades fundamentais:
Planejamento: determinam-se os objetivos, as alternativas
e as limitações. Tais determinações devem ser feitas em cada
FLFORHMiVHUHPSHQVDGDVGHDFRUGRFRPRFLFORSRVWHULRU
‡$QiOLVHGRVULVFRVID]VHDLQYHVWLJDomRGDVDOWHUQDWLYDV
das possibilidades e caminha-se para resolução de problemas,
ou seja, resolução dos riscos.
‡ (QJHQKDULD p R PRPHQWR QR TXDO p IHLWR R
desenvolvimento e a verificação da solução possível.
‡$YDOLDomRGRFOLHQWHHPFRQWDWRFRPRFOLHQWHYHULILFD
se o andamento de cada ciclo.
Nota-se que esse modelo se preocupa com uma coisa
fundamental: a redução dos riscos. Cada etapa é feita de modo
a possibilitar que se compreendam quais são as problemáticas
e as soluções possíveis antes que se dê encaminhamento. A
análise criteriosa por parte do engenheiro de software e o
contato permanente com o cliente são elementos básicos.
Figura 4: <http://www.devmedia.com.br/introducao-aos-processos-de-software-e
-o-modelo-incremental-e-evolucionario/29839>. Acesso em: 05 abr. 2017.
372 Engenharia de Software I
2.4 - Desenvolvimento baseado
em componente (desenvolvimento
orientado a reuso)
Nosso próximo modelo é o desenvolvimento baseado
em componente. Para tanto, vamos pensar: a maioria dos
projetos de software possibilita que haja reaproveitamento
de algum software. Desse modo, é importante que a pessoa
responsável já tenha certo conhecimento dos projetos,
bem como dos códigos a serem elaborados. A partir desse
conhecimento, é possível que se aproveite o software e que
este seja incorporado ao sistema. Há uma possibilidade
significativa de softwares que podem ser utilizados por vários
sistemas. Isso facilita e agiliza o trabalho, além de reduzir
custos e riscos. Certamente, garante-se entrega mais rápida e
maior satisfação do cliente.
Figura 5: Parreira Junior, 2011.
2.5 - Entrega incremental
Há, também, a entrega incremental. Ela diz respeito
a uma abordagem por meio da qual é possível desenvolver
alguns softwares, bem como elaborar alguns incrementos
que possibilitem a entrega ao cliente e sua implantação para
uso em um ambiente operacional. Nesse tipo de processo,
o cliente identifica o serviço a ser fornecido pelo sistema,
avaliando qual é mais e qual é menos importante para ele.
A partir daí, uma série de incrementos são definidos e cada
um proporciona, com isso, um determinado subconjunto da
funcionalidade do sistema.
Figura 6: Entrega incremental. Sommerville, 2013.
Sommerville (2013, p. 32) identifica uma série de
vantagens em relação à entrega incremental. Vamos conferir?
16
4. Quanto maior a prioridade dos serviços entregues e, em seguida,
incrementos integrados, os serviços mais importantes recebem a
PDLRULD GRV WHVWHV ΖVVR VLJQLȴFD TXH D SUREDELOLGDGH GH RV FOLHQWHV
encontrarem falhas de software nas partes mais importantes do
sistema é menor.
1RHQWDQWRH[LVWHPSUREOHPDVFRPDHQWUHJDLQFUHPHQWDO
1.$PDLRULDGRVVLVWHPDVH[LJHXPFRQMXQWRGHUHFXUVRVE£VLFRVXVDGRV
SRUGLIHUHQWHVSDUWHVGRVLVWHPD&RPRRVUHTXLVLWRVQ¥RV¥RGHȴQLGRV
em detalhes até que um incremento possa ser implementado, pode ser
GLI¯FLOLGHQWLȴFDUUHFXUVRVFRPXQVQHFHVV£ULRVDWRGRVRVLQFUHPHQWRV
2. 2 GHVHQYROYLPHQWR LWHUDWLYR WDPE«P SRGH VHU GLI¯FLO TXDQGR XP
sistema substituto está sendo desenvolvido.
Usuários querem toda a funcionalidade do sistema antigo e, muitas
YH]HVȴFDPUHOXWDQWHVHPH[SHULPHQWDUXPQRYRVLVWHPDLQFRPSOHWR
3RUWDQWR«GLI¯FLOREWHUIHHGEDFNV¼WHLVGRVFOLHQWHV
3.$HVV¬QFLDGRSURFHVVRLWHUDWLYR«DHVSHFLȴFD©¥RVHUGHVHQYROYLGD
HP FRQMXQWR FRP R VRIWZDUH ΖVVR FRQWXGR FDXVD FRQȵLWRV FRP R
PRGHORGHFRPSUDVGHPXLWDVRUJDQL]D©·HVHPTXHDHVSHFLȴFD©¥R
completa do sistema é parte do contrato de desenvolvimento do
VLVWHPD1DDERUGDJHPLQFUHPHQWDOQ¥RK£HVSHFLȴFD©¥RFRPSOHWDGR
VLVWHPDDW«TXHR¼OWLPRLQFUHPHQWRVHMDHVSHFLȴFDGRRTXHUHTXHU
uma nova forma de contrato, à qual os grandes clientes, como agências
JRYHUQDPHQWDLVSRGHPDFKDUGLI¯FLOGHVHDGDSWDU
2.6 - Metodologia ágil
Passemos, agora, à metodologia ágil. Elas foram criadas
por volta da década de 1980. Contudo, algumas informações
passaram por distorções, o que acarretou na dificuldade da
utilização das metodologias ágeis. Hoje, pode-se dizer que há
o senso comum de que a metodologia ágil diz respeito ao que
é desenvolvido sem planejamento, sem documentação, o que,
obviamente, não é verdade. As metodologias ágeis são bastante
úteis e podem trazer muito sucesso ao projeto: é amplamente
utilizada no setor industrial. Pressman (2011) define que:
A engenharia de software ágil combina
ÀORVRÀD FRP XP FRQMXQWR GH SULQFtSLRV
GH GHVHQYROYLPHQWR $ ÀORVRÀD GHIHQGH D
satisfação do cliente e a entrega de incremental
SUpYLRHTXLSHVGHSURMHWRVSHTXHQDVHDOWDPHQWH
PRWLYDGDV PpWRGRV LQIRUPDLV DUWHIDWRV GH
engenharia de software mínimos e, acima de
tudo, simplicidade no desenvolvimento geral.
Os princípios de desenvolvimento priorizam a
entrega mais que a análise e projeto (embora
A entrega incremental tem uma série de vantagens:
1. 2VFOLHQWHVSRGHPXVDURVLQFUHPHQWRVLQLFLDLVFRPRSURWµWLSRVH
JDQKDUH[SHUL¬QFLDDTXDOLQIRUPDVHXVUHTXLVLWRVSDUDLQFUHPHQWRV
SRVWHULRUHV GR VLVWHPD $R FRQWU£ULR GH SURWµWLSRV WUDWDVH DTXL
GH SDUWHV GR VLVWHPD UHDO RX VHMD Q¥R H[LVWH D QHFHVVLGDGH GH
UHDSUHQGL]DJHPTXDQGRRVLVWHPDFRPSOHWRHVW£GLVSRQ¯YHO
2. Os clientes não necessitam esperar até que todo o sistema seja
entregue para obter ganhos a partir dele. O primeiro incremento
VDWLVID]RVUHTXLVLWRVPDLVFU¯WLFRVGHPDQHLUDTXHHOHVSRVVDPXVDUR
software imediatamente.
3.2SURFHVVRPDQW«PRVEHQHI¯FLRVGRGHVHQYROYLPHQWRLQFUHPHQWDO
o que deve facilitar a incorporação das mudanças no sistema.
HVVDV DWLYLGDGHV QmR VHMDP GHVHQFRUDMDGDV
também priorizam a comunicação ativa e
contínua entre desenvolvedores e clientes
(PRESSMAN, 2011).
Vemos, então, que os métodos ágeis para desenvolvimento
de software são as abordagens interativas nas quais o software é
desenvolvido e entregue aos clientes em incrementos. Eles não
são planejados previamente, mas, sim, calculados e planejados
durante o desenvolvimento. As variantes dependerão do
progresso obtido, bem como das prioridades do cliente. Ao
considerar que tais necessidades dos clientes podem mudar, é
possível, assim, que o planejamento do software também vá
sofrendo alterações.
 17
2.7 - Processo Unificado da Rational
(RUP)
Esse processo foi criado para dar suporte ao
desenvolvimento voltado aos objetos. Ele pode fornecer uma
forma sistematizada para que se obtenha vantagens no uso da
UML. Ele foi desenvolvido pela Rational Software Corporation
e foi adquirido em 2003 pela IBM.
Sua proposta é, principalmente, atender às prioridades
dos usuários. Com isso, garante-se uma produção de qualidade
dentro de um orçamento e cronograma viável à equipe e ao
cliente. O RUP estipula, de início, os papéis de cada um dentro
do planejamento. Ele conta com quatro fases:
)DVH GH &RQFHSomR  ,QLFLDomR: diz respeito às
tarefas de comunicação com o cliente e ao planejamento. São
estabelecidas as prioridades, as etapas, entre outros.
)DVH GH (ODERUDomR: é o momento em que se faz o
modelo genérico do processo. O propósito é o de analisar o
problema, repassar os riscos e arquitetar o projeto, ainda em
sua forma básica.
)DVHGH&RQVWUXomR: É o momento em que se faz, de
fato, o desenvolvimento do projeto. Faz-se, aqui, a construção
do sistema de software, e o enfoque é no desenvolvimento de
componentes.
)DVH GH 7UDQVLomR: diz respeito à entrega do software
ao usuário. É, também, a fase de testes. Com isso, é possível
disponibilizar o sistema ao usuário, que pode avaliá-lo.
inclusive, em equipes grandes, como deixam evidentes os
casos de sucesso. Lendo a aula, restam dúvidas? Em caso
afirmativo, não hesitem em nos procurar, ok?
Figura 7: <http://www.infoescola.com/wp-content/uploads/2010/03/FasesRUP.
jpg>. Acesso em: 05 abr. 2017.
373
Seu planejamento inicial era de quatro anos (1995-1999) e isso não
RFRUUHX(P.HQW%HFNH-H΍ULHVIRUDPFRQWUDWDGRVHFRPH©DUDP
DDSOLFDUSU£WLFDVTXHDX[LOLDUDPDFRQVROLGDURTXHKRMH«R;3(VVH
SURMHWRWHPFODVVHVHP«WRGRVIRLSDUDSURGX©¥RDSµV
XPDQRGHSRLVGDFRQWUDWD©¥RGH%HFNH-H΍ULHV
2XWUR H[HPSOR IRL R VLVWHPD )RUG 0RWRUV &RPSDQ\ 9&$36 6\VWHP
que utilizava métodos tradicionais e enfrentava diversos problemas.
2V GHVHQYROYHGRUHV ȴFDYDP PDLV WHPSR FRQVHUWDQGR SUREOHPDV
HQFRQWUDGRV GR TXH GHVHQYROYHQGR RX HYROXLQGR R VLVWHPD $SµV
isso o projeto começou a adotar testes automatizados, integração
FRQW¯QXDHRXWURVYDORUHVGR;3(PPHQRVGHXPDQRDOJRTXHQ¥R
VHFRQVHJXLDK£TXDWURDQRVRVLVWHPDIRLGHVHQYROYLGRHHYROX¯GR
constantemente sem maiores problemas.
2;3PXGDRSDUDGLJPDRQGHQ¥RWHPRVRPHGRGDPXGDQ©DSRLV
RHUUDU«IHLWRFRPXPEDL[RFXVWR'LIHUHQWHGRWUDGLFLRQDOHPTXHVH
diz que quanto mais tarde a mudança, maiores são os custos, e assim
VHQGR QXQFD GHYHPRV ID]HU PXGDQ©DV R ;3 GL] TXH GHYHPRV VLP
estar constantemente fazendo mudanças e não devemos teme-las,
principalmente quando seguimos os seus valores e as suas práticas.
2XWUD VLWXD©¥R GHVDȴDGD SHOR ;3 « D HQJHQKDULD GH VRIWZDUH TXH
DȴUPD VHPSUH SURMHWDUPRV SDUD PXGDQ©D RX VHMD YDOH GHVSHQGHU
tempo e esforço antecipando mudanças quando isso reduz custos
SRVWHULRUHVQRFLFORGHYLGD1RHQWDQWRQRYDPHQWHR;3DVVXPHTXH
este esforço não vale a pena quando as mudanças não podem ser
FRQȴDYHOPHQWHSUHYLVWDVRXVHMDQ¥RYDOHDSHQDHPSUHJDUPRVXP
grande esforço que pode nem mesmo ser utilizada no agora, no futuro
ou nunca. Fonte: <http://www.devmedia.com.br/conceitos-basicos-
sobre-metodologias-ageis-para-desenvolvimento-de-software-
PHWRGRORJLDVFODVVLFDV[H[WUHPHSURJUDPPLQJ! $FHVVR HP
05 abr. 2017.
Já vimos que a metodologia XP pode ser utilizada,
Retomando a aula

2.8([WUHPH3URJUDPPLQJ;3
Dentro das metodologias ágeis, há o XP, adequado para
equipes reduzidas ou médias que, geralmente, desenvolvem
software baseado em requisitos vagos, com rápida modificação.
Tem por vantagem a possibilidade de se ter um feedback rápido
e constante, incrementos e comunicação fácil entre as pessoas.
Com isso, garante-se rapidez por ter um enfoque no cliente
e na comunicação com ele, pois torna-se fácil a compreensão
acerca do produto final e de sua elaboração.
O excerto abaixo discute alguns dos casos de sucesso
acerca da metodologia XP, vamos ver?
2VRSRVLWRUHVGR;3GL]HPTXH;3«SDUDWLPHVRXSURMHWRVSHTXHQRV
1RHQWDQWRKLVWµULDVGHVXFHVVRFRPRDGDJUDQGHHPSUHVDFKDPDGD
&KU\VOHU$&KU\VOHUSRVVX¯DXPVLVWHPDGHIROKDGHSDJDPHQWRJOREDO
que envolvia seus 90 mil empregados ao redor de todo o mundo.
([LVWLD XP VLVWHPD &2%2/ H FRQYHUWHXVH HP 6PDOOWDON QD «SRFD
Parece que estamos indo bem. Então, para encerrar esta
aula, vamos recordar:
3URFHVVRVGHVRIWZDUH
A seção I abordou alguns conceitos acerca dos processos
de software. Com ela, foi possível entender de que um
processo de software diz respeito ao conjunto de atividades
que são relacionadas e que levam à produção de um produto
de software. Portanto, o processo de software culmina no
produto final, entendido como produto de software.
0RGHORVGHSURFHVVRVGHVRIWZDUH
Esta seção, mais específica, trouxe à tona diversas
metodologias de processos de software. Conhecemos cada
uma delas, mas, certamente, é possível ampliar os estudos. Que
tal verificarmos alguns links que serão úteis nesse sentido?
374 Engenharia de Software I 18

Vale a pena

Vale a pena acessar

Disponível em: <http://araguaia2.ufmt.br/professor/

disciplina_arquivo/100/20140922403.pdf>.
Disponível em: <http://homepages.dcc.ufmg.
br/~figueiredo/disciplinas/aulas/processos-software_v01.
pdf>.

Minhas anotações
 375

Aula 3º

Análise de requisitos

Olá, pessoal, tudo bem?

Chegamos à nossa aula de verificarmos conteúdos
relacionados à análise de requisitos. É o momento de
entendermos as especificações relacionadas ao conceito e de
que modo a análise de requisitos contribui para que o cliente
tenha seus desejos atendidos quando solicita um produto na
área da engenharia de software.
Vamos lá?
Boa aula!

)LJXUDKWWSVZZZSURȴVVLRQDLVWLFRPEUDQDOLVHGHVLVWHPDVOHYDQWD
mento-de-requisitos/>. Acesso em: 05 abr. 2017.

Objetivos de aprendizagem

Esperamos que, ao término desta aula, vocês sejam capazes de:

‡GHILQLUUHTXLVLWRV
‡HQWHQGHUOLPLWDo}HVHGHVGREUDPHQWRVUHODFLRQDGRVjDQiOLVHGHUHTXLVLWRV
376 Engenharia de Software I 20
importância da discussão sobre requisitos, mas, também, sua
Seções de estudo aplicação.
Quando falamos especificamente acerca dos requisitos de
software, chegamos a um ponto fulcral do sucesso do projeto.
Independentemente de qual software vai ser projetado, caso a
1 - Definição de requisitos análise de requisitos não seja feita adequadamente, não teremos
2 - Especificação de software ou engenharia de requisitos um bom resultado.
3 - Processos de comunicação e documentação No contato com o cliente, precisamos tentar chegar a
algo concreto, a desejos e necessidades bem definidos para
1'HȴQL©¥RGHUHTXLVLWRV termos uma função e um desempenho adequado em relação
ao produto a ser desenvolvido:

Até agora, já pudemos perceber que o Desenvolvimento Alguns dos problemas que surgem durante o
lida com o processo de se transformar um desejo em um processo de engenharia de requisitos são as
produto que satisfaça tais desejos. Parece complexo? Vejam falhas em não fazer uma clara separação entre
a imagem: esses diferentes níveis de descrição. Faço uma
distinção entre eles usando o termo ‘requisitos
GH XVXiULR· SDUD H[SUHVVDU RV UHTXLVLWRV
DEVWUDWRVGHDOWRQtYHOH¶UHTXLVLWRVGHVLVWHPD·
para expressar a descrição detalhada do que
o sistema deve fazer. Requisitos de usuário
H UHTXLVLWRV GH VLVWHPD SRGHP VHU GHÀQLGRV
como segue:
1. Requisitos de usuário são declarações, em
uma linguagem natural com diagramas, de
quais serviços o sistema deverá fornecer a seus
usuários e as restrições com as quais este deve
operar.
2. Requisitos de sistema são descrições mais
detalhadas das funções, serviços e restrições
operacionais do sistema de software. O
documento de requisitos do sistema (às vezes,
Figura 2: <http://www.devmedia.com.br/engenharia-de-requisitos-introducao-e-
FHUWLȴFDFDR!$FHVVRHPDEU
A imagem traz à tona diferentes modos de se compreender
um produto a ser desenvolvido. O que muda, certamente, é de
quem é o olhar diante do produto. Porém, uma coisa é certa:
faltou a definição de requisitos para que não houvesse tantos
problemas, concordam? Vejam alguns dados:
Muito se discute sobre projeto de software,
mas ainda temos muitos problemas,
principalmente quando tratamos sobre os
requisitos. O Relatório do Standish Group
denominado Chaos, indica que 42% dos
projetos foram entregues fora do prazo
previsto, ainda indica que 21% dos projetos
foram um fracasso total, e somente 37%
dos projetos foram bem sucedidos. Segundo
o relatório, parte das falhas é devida a
problemas de requisitos, desta forma, é de
suma importância para a equipe saber levantar
e gerenciar requisitos (Fonte: <http://www.
devmedia.com.br/engenharia-de-requisitos-
LQWURGXFDRHFHUWLÀFDFDR ! $FHVVR
em: 05 abr. 2017.
. É importante ter claro, ainda, a diferença entre 5HTXLVLWR
Notamos, na citação, que quando o planejamento não é
feito de modo adequado, os requisitos não são estabelecidos
em parceria com o cliente. Então, isso gera problemas de
satisfação com o resultado final, exatamente como descreve
a imagem acima. Para tanto, é preciso entender não só a
FKDPDGRHVSHFLÀFDomRIXQFLRQDOGHYHGHÀQLU
exatamente o que deve ser implementado.
Pode ser parte do contrato entre o comprador
do sistema e os desenvolvedores de software
(SOMMERVILLE, 2013. p. 58).
Perceberam a diferença entre requisitos de usuário e
de sistemas? O primeiro diz respeito às declarações menos
sistematizadas e o segundo está relacionado a declarações
detalhadas. Vejam uma definição sobre requisitos de
Sommerville (2013):
Os requisitos de um sistema são as descrições
do que o sistema deve fazer, os serviços que
oferece e as restrições a seu funcionamento.
(VVHV UHTXLVLWRV UHÁHWHP DV QHFHVVLGDGHV GRV
clientes para um sistema que serve a uma
ÀQDOLGDGH GHWHUPLQDGD FRPR FRQWURODU XP
dispositivo, colocar um pedido ou encontrar
informações. O processo de descobrir,
DQDOLVDU GRFXPHQWDU H YHULÀFDU HVVHV VHUYLoRV
e restrições é chamado engenharia de requisitos
(RE, do inglês requirements engineering).
IXQFLRQDO e 5HTXLVLWR QmR IXQFLRQDO. O primeiro diz
UHVSHLWRDGHFODUDo}HVGHVHUYLoRVTXHRVLVWHPDGHYHIRUQHFHU
de que modo o sistema deve reagir a entradas específicas
e como o sistema deve se comportar diante de situações
específicas. O segundo diz respeito às restrições a serviços ou
funções ofertados pelo sistema, como restrições de timing,
 21
no processo de desenvolvimento e as impostas pelas normas.
Exemplificando: Pensando em um sistema comercial qualquer,
que possua o seguinte requisito funcional: Ao final de uma
venda o sistema deve gerar nota fiscal. Analisando o requisito
percebe-se que para gerar a nota fiscal que deve respeitar as
normas impostas pela Receita Federal. Portanto, o requisito
não funcional seria “a necessidade do conhecimento relativo às
normas”. Caso as normas não fossem seguidas, poderia gerar
uma inconsistência dos dados ou até a não geração da nota
fiscal.
É fundamental, para tanto, entender quais são as etapas da
análise de requisitos. Esse será o assunto de nossa próxima seção.
2  (VSHFLȴFD©¥R GH VRIWZDUH RX
engenharia de requisitos
A especificação de requisitos diz respeito ao processo
de escrita dos requisitos de usuários e de sistemas em um
documento, chamado de documento de requisitos. Ele deve
ser claro, com uma linguagem simples, sem contradições, mas
consistente e completa. Esse paralelo é difícil de ser alcançado,
tendo em vista que os stakeholders entendem os requisitos
de maneiras diversas, o que gera conflitos no que tange aos
requisitos.
No que diz respeito aos requisitos de usuário, eles devem
descrever os requisitos funcionais e não funcionais de modo
que sejam acessíveis aos usuários do sistema mesmo que estes
não tenham um conhecimento teórico e técnico a respeito do
assunto:
Os requisitos de sistema são versões expandidas
dos requisitos de usuário, usados por
engenheiros de software como ponto de partida
para o projeto do sistema. Eles acrescentam
detalhes e explicam como os requisitos de
usuário devem ser atendidos pelo sistema. Eles
podem ser usados como parte do contrato para
a implementação do sistema e devem consistir
HPXPDHVSHFLÀFDomRFRPSOHWDHGHWDOKDGDGH
todo o sistema.
Os requisitos do sistema devem descrever
apenas o comportamento externo do sistema e
suas restrições operacionais. Eles não devem se
preocupar com a forma como o sistema deve
ser projetado ou implementado. No entanto,
para atingir o nível de detalhamento necessário
SDUDHVSHFLÀFDUFRPSOHWDPHQWHXPVLVWHPDGH
software complexo, é praticamente impossível
eliminar todas as informações de projeto
(SOMMERVILLE, 2013).
Notaram a necessidade de sempre se voltar a atenção ao
usuário? Tenho certeza que sim! Os requisitos são uma etapa
fundamental para o desenvolvimento do software, e fazê-los
corretamente só amplia a credibilidade do profissional.
A especificação de software, ou engenharia de requisitos,
diz respeito ao processo de compreensão e de definição dos
serviços que são requisitados do sistema. Na sequência, esses
serviços são identificados no que tange às restrições relativas à
operação, bem como ao desenvolvimento do sistema. Quando
377
abordamos a especificação de software dizemos respeito a um
estágio bastante crítico e importante do processo de software:
caso sejam cometidos erros nessa fase, ocorrerão problemas
no sistema no que tange ao projeto e à implementação. O
propósito, então, é o de elaborar um documento por meio
que especifique um sistema que satisfaça aos requisitos de
stakeholder. Há dois níveis por meio dos quais devem ser
apresentados: os usuários finais e clientes recebem uma
GHFODUDomRGHUHTXLVLWRVGHDOWRQtYHOMiRVGHVHQYROYHGRUHV
de sistemas recebem uma especificação mais detalhada do
sistema. Para Sommerville, há quatro atividades principais do
processo de engenharia de requisitos:
1. Estudo de viabilidade. É feita uma estimativa
acerca da possibilidade de se satisfazerem as
QHFHVVLGDGHV GR XVXiULR LGHQWLÀFDGR XVDQGR
se tecnologias atuais de software e hardware.
O estudo considera se o sistema proposto
será rentável a partir de um ponto de vista
de negócio e se ele pode ser desenvolvido no
âmbito das atuais restrições orçamentais. Um
estudo de viabilidade deve ser relativamente
barato e rápido. O resultado deve informar a
decisão de avançar ou não, com uma análise
mais detalhada.
2. Elicitação e análise de requisitos. Esse é o
processo de derivação dos requisitos do
sistema por meio da observação dos sistemas
existentes, além de discussões com os
potenciais usuários e compradores, análise
de tarefas, entre outras etapas. Essa parte do
processo pode envolver o desenvolvimento de
um ou mais modelos de sistemas e protótipos,
os quais nos ajudam a entender o sistema a ser
HVSHFLÀFDGR
3. (VSHFLÀFDomR GH UHTXLVLWRV. É a atividade de
traduzir as informações obtidas durante
a atividade de análise em um documento
TXH GHÀQD XP FRQMXQWR GH UHTXLVLWRV 'RLV
tipos de requisitos podem ser incluídos
nesse documento. Requisitos do usuário são
declarações abstratas dos requisitos do sistema
SDUD R FOLHQWH H XVXiULR ÀQDO GR VLVWHPD
requisitos de sistema são uma descrição mais
detalhada da funcionalidade a ser provida.
4. A validação de requisitos(VVDDWLYLGDGHYHULÀFD
os requisitos quanto a realismo, consistência e
completude (SOMMERVILLE, 2013, p. 24-
25).
Ao serem seguidas cada uma dessas etapas, todos os
erros verificados no documento de requisitos são descobertos.
Aí, então, é possível modificá-lo para eventuais correções.
Certamente, não há uma sequência definida para realizar
as atividades no processo de requisitos, até mesmo porque
durante a análise de requisitos, novos requisitos irão surgir:
“Portanto, as atividades de análise, definição e especificação são
intercaladas. Nos métodos ágeis, como extreme programming, os
requisitos são desenvolvidos de forma incremental, de acordo
com as prioridades do usuário, e a elicitação de requisitos é
feita pelos usuários que integram equipe de desenvolvimento”
(SOMMERVILLE, 2013, p. 25).
378 Engenharia de Software I
2.1 - Análise de Requisitos
A etapa de Análise de Requisitos é caracterizada
basicamente pela realização de um conjunto de tarefas, as
quais serão discutidas individualmente a seguir:
‡$QiOLVHGRSUREOHPD
A primeira etapa diz respeito ao estudo dos documentos
de Especificação do Sistema e o Plano de software. O
objetivo é entender o posicionamento do software no
sistema, bem como revisar o escopo do software utilizado.
Assim, é possível definir a estrutura do projeto. Para tanto, é
importante que se desenvolva uma comunicação eficaz entre
a equipe de engenharia de software e o cliente. O gerente dos
projetos pode atuar nesse processo.
Nessa primeira etapa, o cliente deve ser priorizado.
Muitas vezes, esquece-se da necessidade de sua participação,
apesar de parecer óbvio. Podem-se elencar algumas questões
iniciais:
Quem é o cliente?
Quem deve estar na equipe?
Quais são as necessidades da empresa?
A quais problemas ele está destinado?
Quem deve estar em contato com o cliente, ou, de quem
é a responsabilidade para sanar dúvidas específicas?
22
3 - Processos de comunicação e
documentação
A reflexão acerca dos processos de comunicação permite
entender de que forma se dá a criação de um software.
Nesse caminho, é importante entender que, por mais que
um software seja desenvolvido para atender às necessidades
expressas por um determinado cliente, nem sempre, esse
cliente irá utilizar tal software, que será destinado, na verdade,
a usuários finais:
Os avanços na área da tecnologia têm
permitido ao longo dos últimos anos grande
informatização nos processos das organizações.
No entanto, dispor de um sistema de software
que atenda as diversas necessidades da gestão
organizacional pode se tornar um processo
complexo. Isso implica, muitas vezes, em
desenvolver ou customizar um sistema. Mas
não é só isso: os sistemas de software precisam
evoluir para acompanhar os modelos de gestão
e, neste contexto passam obrigatoriamente
por manutenções que podem ser melhorias,
otimizações e até mesmo reparos. Segundo
‡$YDOLDomRHVtQWHVH
A segunda etapa diz respeito à análise do fluxo de
informação e à elaboração das funções e dos aspectos de
comportamento do software. Nesse momento, todas as
questões relacionadas à interface do sistema devem ser
respondidas. Além disso, é importante que haja o esclarecimento
das limitações dos projetos. Ao serem analisadas todas as
possíveis problemáticas, é importante que se leve em conta
também as possíveis soluções para os problemas. Ao final,
faz-se uma sequência de contatos com o cliente, com o intuito
de se verificar, em um contato dialógico, as soluções viáveis no
que diz respeito a tempo e recursos financeiros.
‡0RGHODJHP
Realizadas a avaliação e a síntese, pode-se definir um
modelo do sistema. Isso irá possibilitar que se compreendam
melhor os fluxos de informação e de controle, e, do mesmo
modo, aspectos funcionais e de comportamento. A modelagem
é uma base, uma referência para as atividades do projeto e, do
mesmo modo, para que se possam criar as especificações de
requisitos. Além disso, pode ser desenvolvido, inclusive, um
protótipo do software. Por meio de tal protótipo, é possível
saber se o software a ser desenvolvido é viável.
‡(VSHFLILFDomRGRVUHTXLVLWRVHUHYLVmR
Trata-se de um documento criado com o propósito de
registrar resultados das tarefas realizadas. Paralelo à criação
da Especificação de Requisitos de Software, pode-se criar um
Manual Preliminar do Usuário. Este último permite que o
Engenheiro de Software observe o software sob a perspectiva
do cliente, o que certamente dá mais qualidade ao produto
final. Ele permite ainda que a revisão dos requisitos seja feita
em um momento inicial, evitando diversos problemas futuros
no que tange aos aspectos do software.
3ÁHHJHUHVWDVPDQXWHQo}HVDEUDQJHP
qualquer alteração ou correção efetuada num
sistema que já está sendo utilizado, uma vez
que sua vida útil não acaba com a entrega. A
grande maioria dos sistemas de software deve
ser construída para incorporar mudanças:
seja porque o usuário decidiu realizar seu
processo de maneira diferente, seja porque
houve alguma alteração de leis ou normativas
municipais, estaduais ou mesmo federais que
regulamentam os requisitos do sistema (Fonte:
<http://www.devmedia.com.br/artigo-
engenharia-de-software-24-a-comunicacao-
no-processo-de-software/16807>. Acesso
em: 5 abr. 2017).
Nessa perspectiva, pensando na questão da comunicação
nos processos de desenvolvimento de software, temos três
partes principais envolvidas: o cliente, o desenvolvedor
e finalmente os usuários. Para que a relação dê certo, é
importante que o profissional tenha em mente que os desejos
expressos pelo cliente sejam compatíveis com as possíveis
necessidades dos usuários do sistema. Certamente, é preciso
muita atenção por parte do desenvolvedor, tendo em vista
algumas dificuldades, tais como:
‡'LILFXOGDGHGRVFOLHQWHVHPHQWHQGHUDVSHFWRVUHODWLYRV
aos softwares, ou ao processo de desenvolvimento de um
SURJUDPD
‡2GHVHQYROYHGRUFHUWDVYH]HVQmRFRQKHFHRVLVWHPDHP
que o software irá executar. Para tanto, destaca-se a importância
dos documentos no que diz respeito à comunicação com o
cliente acerca das possíveis problemáticas.

Figura 4: Sommerville, 2013
O documento de requisitos terá suas especificações
definidas pelo tipo de sistema e pelo processo usado. Em casos
de sistemas críticos, é necessário haver requisitos detalhados.
Em caso de sistemas desenvolvidos por uma companhia
separada, tais especificações devem ser bastante detalhadas e
precisas. Já quando o processo interno tem desenvolvimento
interativo, não são necessários tantos detalhes.
Vejamos um documento apresentado por Sommervile
(2013).
$ WDEHOD >@ PRVWUD XPD SRVV¯YHO RUJDQL]D©¥R GH XP GRFXPHQWR GH
requisitos baseada em uma norma IEEE para documentos de requisitos
(IEEE, 1998). Essa é uma norma genérica que pode ser adaptada
SDUD XVRV HVSHF¯ȴFRV 1HVVH FDVR HX HVWHQGL D QRUPD SDUD LQFOXLU
informações sobre a evolução prevista do sistema. Essa informação
ajuda os engenheiros de manutenção de sistema e permite que os
projetistas incluam suporte para futuros recursos do sistema.
Figura 5: Sommerville, 2013.
23 379
Sommerville (2013) deixa claro que a informação
incluída em um documento de requisitos dependerá de qual
tipo de software será desenvolvido. Também dependerá
da abordagem de desenvolvimento em uso. Em caso de
abordagens evolutivas, o documento de requisitos excluirá
muitos capítulos detalhados, e o enfoque se dará sobre
a definição de requisitos de usuários e sobre requisitos
não funcionais de alto nível de sistema. Nesse caso, são os
projetistas e programadores que decidirão como atender aos
requisitos gerais de usuário para o sistema.
Retomando a aula
&KHJDPRV DR ȴQDO GD WHUFHLUD DXOD 7UD©DPRV XP
bom caminho até aqui, não é mesmo? Vamos, então,
recordar?
'HILQLomRGHUHTXLVLWRV
Entendemos, na primeira seção, o conceito de requisitos
de um sistema, que são as descrições do que o sistema deve
fazer, quais os serviços a serem oferecidos e as restrições para
seus funcionamentos.
  (VSHFLILFDomR GH VRIWZDUH RX HQJHQKDULD GH
UHTXLVLWRV
Nesta seção abordou-se a especificação de software.
Entendemos, então, que ela diz respeito ao processo de
compreensão e de definição dos serviços que são requisitados
do sistema. Na sequência, esses serviços são identificados no
que tange às restrições relativas à operação, bem como ao
desenvolvimento do sistema.
3URFHVVRVGHFRPXQLFDomRHGRFXPHQWDomR
Vimos que a reflexão acerca dos processos de
comunicação permite entender de que forma se dá a criação
de um software. Nesse caminho, é importante entender que,
por mais que um software seja desenvolvido para atender
às necessidades expressas por um determinado cliente, nem
sempre esse cliente irá utilizar tal software, que será destinado,
na verdade, a usuários finais.
Vale a pena
Vale a pena assistir
Segue um vídeo no qual se aborda a engenharia de
requisitos. Disponível em: <https://www.youtube.com/
watch?v=0qclkZSFKmw>. Acesso em: 05 abr. 2017.
380 Engenharia de Software I

4º Aula

Qualidade de software

Olá, pessoal!
Nesta aula, abordaremos a qualidade de software.
Vocês já devem ter percebido até aqui que desenvolver
um software de qualidade é um dos principais objetivos
de nosso campo de estudo, não é mesmo?
Esta aula, portanto, se dedicará à discussão de tal
tema.
Dispostos?
Boa aula!

Objetivos de aprendizagem

Esperamos que, ao término desta aula, vocês sejam capazes de:

‡HQWHQGHUGHPRGRDSURIXQGDGRDTXDOLGDGHGHVRIWZDUH
‡VDEHURVIDWRUHVTXHGHWHUPLQDPDTXDOLGDGHGHVRIWZDUH
‡FRQKHFHURVGLOHPDVUHODFLRQDGRVjTXDOLGDGHGHVRIWZDUH
 25
Seções de estudo
1 - Qualidade de Softwares
2 - O dilema da qualidade de software
1 - Qualidade de Softwares
Caríssimos(as),
Vamos refletir acerca do conceito de qualidade. Quando
estamos discutindo por um aspecto profissional, é importante
termos em conta que a qualidade não parte de uma definição
popular. Em nível de dicionário, qualidade é entendida como
característica inerente a algo. Contudo, a ISO9126 (1994) define
qualidade como sendo: “[...] a totalidade de características e
critérios de um produto ou serviço que exercem suas habilidades
para satisfazer às necessidades declaradas ou envolvidas”.
Já para a NBR ISO 9000 (2005), “qualidade é o grau
no qual um conjunto de características inerentes satisfaz aos
requisitos”.
A qualidade de software, como já vimos, tem por
propósito garantir que se elabore um bom software. Para
Pressman “Qualidade de software é a satisfação de requisitos
funcionais e de desempenho explicitamente declarados,
normas de desenvolvimento explicitamente documentadas e
características implícitas que são esperadas em todo o software
381
produtos exatamente iguais, o que não ocorre no campo do
desenvolvimento de software.
Em vista disso, a grande utilização de software em
diferentes áreas faz com que a procura por produtos de
qualidade também seja ampliada:
A complexidade dos sistemas desenvolvidos
também tem aumentado, bem como a
concorrência entre as empresas fornecedoras.
Assim, é muito comum haver reclamações
em relação aos produtos de software gerados,
apesar de estes serem imprescindíveis na
execução de diversas tarefas. Ou seja, apesar
de todas as reclamações existentes em
relação aos softwares adquiridos, eles são
bastante utilizados, possivelmente por falta
de alternativa (http://www2.dbd.puc-rio.
br/pergamum/tesesabertas/0812576_10_
cap_03.pdf).
Nessa perspectiva, é fundamental ao profissional
entender o que é qualidade em software e suas especificidades.
O assunto começou a gerar debate ainda em 1960, quando
se notou, no desenvolvimento do primeiro grande sistema
de software, que houve problemas relacionados em relação
a sua qualidade, como mostra Sommerville (2011). Já na
década de 1990, começou a ser percebido que empresas de
grande porte estavam perdendo bilhões de dólares por ano
devido aos softwares não apresentarem as características e
GHVHQYROYLGRSURÀVVLRQDOPHQWHµ35(660$11HVVD
perspectiva, a discussão envolve uma busca pela satisfação tanto
com os requisitos funcionais e de desempenho explicitamente
declarados, quanto em relação às normas de desenvolvimento
explicitamente documentadas. De modo geral, almeja-se que
todo o software corresponda a determinada perspectiva, e que
cada etapa desempenhe função à qual foi planejada.
Além disso, é importante que se considere a questão
custo/benefício: o software deve ser planejado de modo que
gere o menor custo possível, desde que, certamente, não altere
a sua qualidade:
A área de Qualidade na Engenharia de
Software é similar a esta mesma área em outras
engenharias. Porém, há algumas características
que distinguem os produtos de software dos
demais produtos industriais. Os processos
de desenvolvimento de um produto da
engenharia e de um software podem apresentar
muitas semelhanças em relação ao seu ciclo:
GHÀQLomRGRSURGXWRTXHVHGHVHMDFRQVWUXLURX
GHVHQYROYHU DQiOLVH GRV UHTXLVLWRV GHÀQLomR
da arquitetura macro e construção do projeto
detalhado, fabricação ou desenvolvimento
e entrega. Entretanto, a maneira como um
software é produzido se difere, pois este é
intangível e está mais sujeito ao erro humano
(http://www2.dbd.puc-rio.br/pergamum/
tesesabertas/0812576_10_cap_03.pdf).
Desse modo, caso se desenvolva dois softwares por
meio do mesmo processo de desenvolvimento, eles terão,
certamente, algumas particularidades. No entanto, quando
tratamos de produtos industriais, é comum haver diversos
funcionalidades prometidas.
Para que seja obtido um software com qualidade, é
importante ter a resposta de algumas questões:
Adequação do software à finalidade
Durante o processo de desenvolvimento os padrões de
programação e documentação foram seguidos?
‡2VRIWZDUHIRLGHYLGDPHQWHWHVWDGR"
‡2VRIWZDUHpFRQILiYHORVXILFLHQWHSDUDVHUFRORFDGR
em uso?
‡2GHVHPSHQKRGRVRIWZDUHpDFHLWiYHOSDUDXVRQRUPDO"
‡2VRIWZDUHpXViYHO"
‡2VRIWZDUHpFRPSUHHQVtYHOHHVWUXWXUDGR"
Para Pressman (2011), há três pontos a serem analisados
no que diz respeito à qualidade de software:
ʃ 8PD JHVWmR GH TXDOLGDGH HIHWLYD HVWDEHOHFH
infraestrutura que dá suporte a qualquer
tentativa de construir um produto de software
de qualidade.
ʃ 8P SURGXWR ~WLO IRUQHFH R FRQWH~GR DV
IXQo}HVHRVUHFXUVRVTXHRXVXiULRÀQDOGHVHMD
DOpP GLVVR GHYH IRUQHFHU FRQÀDELOLGDGH H
isenção de erros.
ʃ $R DJUHJDU YDORU WDQWR SDUD R IDEULFDQWH
quanto para o usuário de um produto de
software, um software de alta qualidade gera
benefícios para a empresa bem como para os
XVXiULRVÀQDLV
Na próxima seção, discutiremos cada uma das
especificidades relacionadas à qualidade de software. Vamos
lá?
382 Engenharia de Software I
1.1 - Dimensão de qualidade de
Garvin
David A. Garvin, em 1984, publicou um importante
estudo no MIT Sloan Management Review, sob o título “O
que significa realmente Qualidade do Produto?”, no qual
estabelece oito dimensões para qualidade. É importante
saber que as oito dimensões de Garvin não são específicas
a software, porém, podem ser aplicados a esse campo sem
nenhum problema. Vamos conhecê-las?
4XDOLGDGH GR GHVHPSHQKR. O software
fornece todo o conteúdo, funções e recursos
TXHVmRHVSHFLÀFDGRVFRPRSDUWHGRPRGHOR
de requisitos de forma a gerar valor ao usuário
ÀQDO"
4XDOLGDGHGRVUHFXUVRV. O software fornece
recursos que surpreendem e encantam
XVXiULRV ÀQDLV TXH RV XWLOL]DP SHOD SULPHLUD
vez?
&RQIRUPLGDGH. O software está de acordo
com os padrões de software locais e externos
relacionados com a aplicação? Segue as
FRQYHQo}HVGHSURMHWRHFRGLÀFDomRGHIDWR"
Por exemplo, a interface com o usuário está
de acordo com as regras de projeto aceitas
para seleção de menus ou entrada de dados?
'XUDELOLGDGH. O software pode ser mantido
26
de software. Quem faz essa aproximação é Pressman (2006). É
ele quem dimensiona a questão das oito dimensões de modo
articulado às discussões acerca do software.
1.2 - Fatores de Qualidade de McCall
O segundo fator que verificaremos são os fatores de
qualidade de McCall. Novamente, Pressman (2006) pautará
nossas reflexões. McCall, Richards e Walters elaboraram
uma proposta com o intuito de impactar as discussões sobre
a qualidade de software. A teoria tem por base focar em três
aspectos considerados mais importantes no que diz respeito
a um produto de software: as características operacionais, a
habilidade de suportar mudanças e a adaptabilidade a novos
ambientes.
McCall e seu grupo fazem as seguintes descrições no que
diz respeito à qualidade:
Correção. O quanto um programa satisfaz a sua
HVSHFLÀFDomRHDWHQGHDRVREMHWLYRVGDPLVVmR
do cliente.
&RQÀDELOLGDGH2TXDQGRVHSRGHHVSHUDUTXH
um programa realize as função pretendida com
a precisão exigida.
(ÀFLrQFLD $ TXDQWLGDGH GH UHFXUVRV
computacionais e código corrigidos por um
programa para desempenhar sua função.
Integridade. O quanto o acesso ao software ou
PRGLÀFDGR RX FRUULJLGR GHSXUDGR VHP
a geração involuntária de efeitos colaterais
indesejados? as mudanças farão com que a
WD[D GH HUURV RX D FRQÀDELOLGDGH GLPLQXDP
com o passar do tempo?
)DFLOLGDGH GH 0DQXWHQomR. O software
dados por pessoas não autorizadas pode ser
controlado.
Usabilidade. Esforço necessário para aprender,
operar, preparar a entrada de dados e interpretar
a saída de um programa.
Facilidade de manutenção. Esforço necessário
SRGH VHU PDQWLGR PRGLÀFDGR RX FRUULJLGR
(depurado) em um período de tempo aceitável
e curto? O pessoal de suporte pode obter
todas as informações necessárias para realizar
alterações ou corrigir defeitos? [...]
(VWpWLFD. Não há duvida nenhuma de que
cada um de nós tem uma visão diferente muito
subjetiva do que é estética. Mesmo assim, a
maioria de nós concordaria que uma entidade
HVWpWLFDWHPFHUWDHOHJkQFLDXPÁXLU~QLFRp
XPD´SUHVHQoDµTXHVmRGLItFHLVGHTXDQWLÀFDU
mas que, não obstante, são evidentes. Um
software estético possui essas características.
3HUFHSomR. Em algumas situações, temos
DOJXQV SUHFRQFHLWRV TXH LQÁXHQFLDUmR QRVVD
percepção de qualidade. Por exemplo, se
for apresentado um produto de software
construído por um fornecedor que, no
passado, havia produzido software de
Pi TXDOLGDGH ÀFDUHPRV FRP D QRVVD
percepção de qualidade do produto software
LQÁXHQFLDGD QHJDWLYDPHQWH 6LPLODUPHQWH VH
um fornecedor tem uma excedente reputação,
talvez percebamos qualidade, mesmo quando
ela realmente não existe (PRESSMAN, 2006,
p. 361).
Como discutido anteriormente, David A. Garvin não
estipulou dimensões de qualidade especificamente para a área
para localizar e corrigir um erro em um
programa.
Flexibilidade. Esforço necessário para testar
um programa de modo a garantir que ele
desempenhe a função destinada.
Portabilidade. Esforço necessário para
transferir o programa de um ambiente de
hardware ou software para outro.
Recusabilidade. O quanto um programa
pode ser reutilizado em outras aplicações
(PRESSMAN, 2011, p. 362).
Certamente, nem sempre é possível saber diretamente o
quanto cada um dos fatores provoca impacto. Tais medidas são
utilizadas, majoritariamente, em um aspecto indireto. Abaixo,
segue uma figura com um exemplo da aplicação dos fatores
de McCall:
Figura 1. Pressmann, 2011, p. 362.
 27
1.3 - Fatores de Qualidade ISO 9126
Os fatores de qualidade ISO 9126 estabelecem seis fatores
para aferição da qualidade do software. Pressman (2011)
também discute os fatores de qualidade ISSO 9126.
Segundo Pressman (2011, p. 363) são expressos da
seguinte maneira:
Funcionalidade. O grau com que o software
satisfaz às necessidades declaradas conforme
indicado pelos seguintes subatributos:
adequabilidade, exatidão, interoperabilidade,
conformidade e segurança.
&RQÀDELOLGDGH $ TXDQWLGDGH GH WHPSR TXH
R VRIWZDUH ÀFD GLVSRQtYHO SDUD XVR FRQIRUPH
indicado pelos seguintes subatributos:
maturidade, tolerância a falhas, facilidade de
recuperação.
Usabilidade. O grau de facilidade de utilização
do software conforme indicado pelos seguintes
subatributos: facilidade de compreensão,
facilidade de aprendizagem, operabilidade.
(ÀFLrQFLD2JUDXGHRWLPL]DomRGRXVRSHOR
software, dos recursos do sistema conforme
indicado pelos seguintes subatributos:
comportamento em relação ao tempo,
comportamento em relação aos recursos.
Facilidade de manutenção. A facilidade com
a qual uma correção pode ser realizada no
software conforme indicado pelos seguintes
subatributos: facilidade de análise, facilidade
de realização de mudanças, estabilidade,
testabilidade.
Portabilidade. A facilidade com a qual um
software pode ser transposto de um ambiente
a outro conforme indicado pelos seguintes
subatributos: adaptabilidade, facilidade de
instalação, conformidade, facilidade de
substituição.
Os fatores ISSO 9126, do mesmo modo que os outros, não
conduzem a uma medida exata e direta. Contudo, são bastante
importantes para que se desenvolvam medidas indiretas, e uma
lista de verificação para avaliar a qualidade do sistema.
Após ver maneiras de se medir e investigar a qualidade do
software, nossa próxima seção abordará questões relacionadas a
possíveis problemáticas e dificuldades da qualidade de software.
2 - O dilema da qualidade de software
2.1 - Software “bom o suficiente”
No mundo contemporâneo, todos trabalham com prazos
apertados, dias corridos de trabalho. No campo da engenharia
de software não é diferente. Contudo, para mantermos um
público, devemos ofertar produtos de qualidade. Do contrário,
ficaremos obsoletos. É importante, para tanto, pensarmos na
seguinte questão: devemos ofertar sempre o melhor produto
possível.
Mas, em relação aos prazos, custos? Como conciliar?
383
A maneira de resolver essa equação é entendendo que
a oferta de produtos de qualidade precisa “caber” dentro do
tempo e dentro do financeiro do qual se dispõe. A prática
aliada a análises críticas permitirá que vocês consigam conciliar
os três aspectos: qualidade, prazo e custo. Diálogos com a
equipe, o contato com o cliente, a verificação de satisfação
dos usuários são elementos que possibilitam que nossos três
fatores básicos entrem em convergência, possibilitamos que
nosso público cresça.
Assim, um software “bom o suficiente” oferta aos usuários
funções e características de alta qualidade, mas, do mesmo
modo, outras funções que possam conter erros conhecidos. O
fornecedor do software, contudo, tem em mente que a grande
maioria dos usuários não irá se apegar em pequenos problemas
devido à satisfação com as outras funcionalidades.
2.2 - Custo da Qualidade
Outra questão a ser levada em conta são os custos da
qualidade do software. Esse aspecto inclui todos os custos
necessários para que se busque qualidade, considerando-se os
custos causados devido à falta de qualidade. Pode-se dizer que
os custos relativos à qualidade envolvem: prevenção, avaliação
e falhas. Cada uma dessas etapas envolvem custos.
Custos de prevenção: envolvem os custos relacionados às
atividades para gerenciamento, planejamento e coordenação
GDV DWLYLGDGHV FXVWRV GH DWLYLGDGHV WpFQLFDV DGLFLRQDLV
SODQHMDPHQWR GH WHVWHV WUHLQDPHQWR DVVRFLDGR jV HWDSDV
anteriores.
Custos de avaliação: envolvem atividades que permitam
que se compreenda a condição do produto. Estão relacionados
jUHDOL]DomRGHUHYLV}HVWpFQLFDVFROHWDGHGDGRVHDYDOLomRGH
PpWULFDVWHVWHVHGHSXUDo}HV
Custos de falhas: são organizados em: custo de falhas
internas: são gerados quando se percebe um erro antes da
HQWUHJD DR FOLHQWH FXVWR GH IDOKDV H[WHUQDV VmR SHUFHELGRV
quando há erros depois da entrega ao cliente.
2.3 - Riscos
Outro dilema importante da qualidade de software diz
respeito aos riscos. Certamente, caso o software tenha baixa
qualidade, os riscos estarão presentes. Tanto o desenvolvedor
quando o usuário podem percebê-los. A título de exemplo, em
2000, devido a uma alteração de software pela equipe de um
hospital, vinte e oito pacientes receberam uma dose maciça
de raio gama. Isso ocasionou na morte de cinco pacientes e
quinze tiveram complicações. A segurança, portanto, deve ser
um elemento fundamental quando se desenvolve um produto
de software.
Um software com baixa qualidade também ocasiona maior
possibilidades de pirataria, o que aumenta, em consequência,
os riscos que podem advir dela. Nessa perspectiva, entra em
cena o impacto das ações administrativas.
2.4 - O Impacto das ações
administrativas
As discussões acerca da qualidade de software envolvem
também a questão das decisões administrativas. Nessa
384 Engenharia de Software I
perspectiva, para Presmann (2011, p. 462) “Até mesmo
as melhores práticas de engenharia de software podem ser
subvertidas por decisões de negócios inadequadas e ações
questionáveis de gerenciamento do projeto”. Há, então,
decisões que podem ser decisivas na qualidade do produto, a
serem consideradas pelo líder do projeto. As primeiras são as
GHFLV}HVGHHVWLPDWLYDV, relacionadas ao que a equipe pode
fornecer no que tange a previsões e estimativas. A equipe, para
tanto, realiza algumas decisões para estabelecer qual será o
prazo de entrega, o custo, entre outros. Também é importante
pensar sobre as GHFLV}HV GH FURQRJUDPD. Depois que se
elaborou um cronograma, é importante que as tarefas sejam
elaboradas tomando como base as dependências de um
componente em relação a outro cada componente deve ser
testado e avaliado para que não acarrete em problemas no
próximo componente.
28
qualidade de software. Discutimos cada uma deles de modo a
entender como é possível aferir a qualidade de um software.
2GLOHPDGDTXDOLGDGHGHVRIWZDUH
Aqui, vimos questões relacionadas à gerência, custos
e implicações relacionados a um software de qualidade.
É importante ter em mente que caso o software não
tenha qualidade, poderá acarretar em riscos, tanto para o
desenvolvedor quanto par os usuários.
Vale a pena
Vale a pena acessar

2.5 - Alcançando a Qualidade de BALTHAZAR, Glauber da Rocha. Visão Geral da

Software Qualidade de Software. Disponível em: <http://re.granbery.
Finalmente, vamos refletir acerca da qualidade de edu.br/artigos/MjUw.pdf>. Acesso em: 05 abr. 2017.
software e como alcançá-la. Certamente, todos os fatores
discutidos anteriormente são extremamente importantes,
mas, vamos verificar outras questões.
Minhas anotações
Para se alcançar um software de qualidade, é preciso
que haja um bom gerenciamento de projeto, bem como uma
prática consistente de engenharia de software. Há, assim,
quatro padrões de qualidades de software a serem alcançados:
Métodos de engenharia de software: envolvem a
capacidade da equipe de entender o problema a ser resolvido.
Do mesmo modo, o projeto deve ter adequação à solução de
problemas. Ele deve, ainda, considerar as dimensões e fatores
de qualidade.
Técnicas de gerenciamento de software: diz respeito às
técnicas explícitas para que se gerenciem as mudanças que
conduzirão à qualidade. As especificações técnicas contribuem
para o mínimo de erros.
Controle de qualidade: diz respeito às revisões e
verificações no que diz respeito à busca pelas metas de
qualidade. Aqui, é feita uma etapa de testes para investigar e
solucionar possíveis erros. Assim, os testes feitos e os feedbacks
recebidos conduzem ao máximo de qualidade.
Garantia da qualidade: engloba tanto a infraestrutura
para suportar os métodos sólidos de engenharia de software,
o gerenciamento dos projetos e as ações de controle de
qualidade. Nessa fase, também se faz um conjunto de
funções de auditoria e elaboram-se relatórios para se avaliar
efetivamente as ações de controle de qualidade.

Retomando a aula

&KHJDPRVDRȴQDOGDTXDUWDDXOD
Vamos recordar?

4XDOLGDGHGH6RIWZDUH
Nesta seção, verificamos diversos fatores relacionados à
 385

Aula 5º

Projeto e implementação
de software

Olá, alunos(as)!
Esta é nossa quinta aula!
É o momento de verificarmos e entendermos a
implementação do desenvolvimento de software. O estágio
de projeto e de implementação do software diz respeito
à conversão de uma especificação do sistema em um
sistema passível de execução. Analisaremos tal ideia e seus
desdobramentos.
Prontos para mais uma aula?
Boa aula!

Objetivos de aprendizagem

Esperamos que, ao término desta aula, vocês sejam capazes de:

‡HQWHQGHURSURMHWRHLPSOHPHQWDomRGRGHVHQYROYLPHQWRGHVRIWZDUH
‡FRQKHFHURVSURMHWRVRULHQWDGRVDREMHWRVHSDGU}HVGHSURMHWRV
‡YHULILFDUDVSHFWRVUHODFLRQDGRVjLPSOHPHQWDomR
386 Engenharia de Software I
Seções de estudo
1 - Projeto e implementação
2 - Projetos orientados a objetos com UML
3 - Tradução
4 - Características das linguagens de programação
1 - Projeto e implementação
Quando falamos sobre o estágio de projeto e
implementação do desenvolvimento de software, referimo-
nos ao processo em que se converte uma especificação de
sistema em um sistema que possa ser executado. Para tanto, as
etapas de projeto e implementação envolvem a formalização
das ideias verificadas na etapa da engenharia do sistema, dos
requisites estabelecidos e dos modelos gerados na etapa de
projeto para que o sistema computacional alvo possa realizar
as tarefas definidas anteriormente:
As atividades de projeto e implementação de
software são invariavelmente intercaladas. O
projeto de software é uma atividade criativa
HP TXH YRFr LGHQWLÀFD RV FRPSRQHQWHV GH
software e seus relacionamentos com base
nos requisitos do cliente. A implementação é
o processo de concretização do projeto como
um programa. Às vezes, existe um estágio de
projeto separado e esse projeto é modelado
e documentado. Em outras ocasiões, um
SURMHWR HVWi ¶QD FDEHoD· GR SURJUDPDGRU RX
esboçado em um quadro ou em papel. Um
projeto trata de como resolver um problema,
por isso, sempre existe um processo de
projeto. No entanto, nem sempre é necessário
ou apropriado descrever o projeto em
detalhes usando a UML ou outra linguagem
de descrição (SOMMERVILLE, 2011, p. 25).
No início do projeto de software, uma das primeiras
decisões que são tomadas é se o software será comprador
ou construído. Aliás, comprar sistemas de prateleira é uma
possibilidade atual. Assim, tais sistemas podem ser adaptados
e adequados aos requisitos dos usuários. Nessa perspectiva,
quando se está, por exemplo, implementando um sistema de
prontuário médio, é possível adquirir um pacote já elaborado
e utilizado em hospitais. Com isso, o desenvolvimento de
sistema pode ser barateado e entregue ao cliente mais rápido:
Quando você desenvolve uma aplicação dessa
forma, o processo de projeto preocupa-se em
¶FRPR·XVDURVUHFXUVRVGHFRQÀJXUDomRGHVVH
sistema para cumprir os requisitos do sistema.
Usualmente, você não desenvolve modelos
de projeto do sistema, como modelos
de objetos do sistema e suas interações
(SOMMERVILLE, 2013, p. 25).
30
2 - Projetos orientados a objetos com
80/
Para avançarmos, vamos entender, agora, como são
implementados os sistemas orientados a objetos. Eles são
compostos interativos, tendo em vista que podem manter
o seu próprio estado local, e, também, oferecer operações
nesse mesmo estado. A representação de seu estado, contudo,
é privada: não pode ser acessada diretamente. Os projetos
orientados a objetos permitem que se projetem as classes de
objetos e sejam feitos relacionamentos entre elas. Tais classes,
por sua vez, são responsáveis pela definição dos objetos no
sistema, bem como suas interações. Já quando o projeto é
elaborado como um programa em execução, os objetos ganham
dinamicidade, tendo como base as definições de classe. Além
disso, os sistemas orientados a objetos ganham em facilidade
no que diz respeito a alterações do que os sistemas que são
desenvolvidos com abordagens funcionais. Tendo em vista que
os projetos orientados a objetos incluem dados e operações
para manipulá-los:
>«@HOHVSRGHPVHUHQWHQGLGRVHPRGLÀFDGRV
como entidades autônomas. Alterar a
implementação de um objeto ou adicionar
serviços não deve afetar outros objetos do
sistema. Como os objetos são associados com
coisas, muitas vezes existe um mapeamento
claro entre entidades do mundo real (como
componentes de hardware) e seus objetos
de controle no sistema, o que melhora a
inteligibilidade e, portanto, a manuteniblidade
do projeto (2013, p. 26).
Para que possamos elaborar o desenvolvimento de um
projeto de sistema desde o princípio até um projeto detalhado
orientado a objeto, devemos seguir algumas etapas, conforme
estabelece Sommerville (2013, p. 26):
 &RPSUHHQGHU H GHÀQLU R FRQWH[WR H DV
interações externas com o sistema. 2. Projetar
D DUTXLWHWXUD GR VLVWHPD  ,GHQWLÀFDU RV
principais objetos do sistema. 4. Desenvolver
PRGHORV GH SURMHWR  (VSHFLÀFDU LQWHUIDFHV
Como todas as atividades criativas, o projeto
não é um processo sequencial claro. Você
desenvolve um projeto tendo ideias, propondo
VROXo}HVHUHÀQDQGRHVVDVVROXo}HVDVVLPTXH
DV LQIRUPDo}HV ÀFDP GLVSRQtYHLV 4XDQGR RV
problemas surgem, inevitavelmente você tem
de voltar atrás e tentar novamente. Às vezes,
você explora as opções detalhadamente para
YHU VH HODV IXQFLRQDP HP RXWURV PRPHQWRV
YRFrLJQRUDRVGHWDOKHVDWpRÀPGRSURFHVVR
porque isso implicaria a possibilidade de o
projeto ser pensado como uma sequência de
atividades. Na verdade, todas essas atividades
VmR LQWHUFDODGDV H DVVLP LQÁXHQFLDPVH
mutuamente (SOMMERVILLE, 2013, p. 26).
Já a UML é uma Linguagem de Modelagem Unificada.
Diz respeito a uma linguagem gráfica que permite visualizar,

especificar, construir e documentar artefatos de um sistema
orientado a objetos. Assim, os projetos orientados a objetos
com UML podem ser desenvolvidos de forma rápida e eficiente.
Também permite que a estrutura e comportamento do sistema
sejam visualizados de forma mais fácil. É possível, ainda, que
se visualize e se controle a arquitetura do sistema. Há, também,
um entendimento mais rápido do sistema em processo, o que,
certamente, torna mais fácil o gerenciamento de riscos.
Figura 1. Fonte: <https://webserver2.tecgraf.puc-rio.br/ftp_pub/lfm/CIV2802-131-Au-
la04-ModelagemOrientadaObjetos.pdf>. Acesso em 8 abr. 2017.
Deve-se ter uma visão de casos de usos, de modo que
se exponham as exigências do sistema. Assim, é possível ter
uma visão do projeto de modo que se capture o vocabulário
do espaço do problema e do espaço da solução. Pode-se
ainda ter uma visão do processo de modo que seja possível
modelá-lo à distribuição dos processos e das linhas do sistema.
Também é possível uma visão da implementação, de modo
dirigido à realização física do sistema. Por fim, tem-se uma
visão da distribuição, com foco na edição da engenharia do
sistema. Juntas, tais visões representam as plantas de sistemas
computacionais.
3 - Tradução
A tradução do desenho detalhado no código de uma
ou mais linguagens de programação é feita na atividade de
´FRGLÀFDomRµ(VVHPDSHDPHQWRUHVXOWDQRFyGLJRIRQWH$V
unidades de código fonte produzidas são submetidas a uma
revisão de código. Nesse processo, são corrigidos os defeitos
gerados a partir de erros de digitação, ou, ainda, do uso da
linguagem. Quando se faz uma revisão, deve-se considerar que
são introduzidos por erros de digitação ou de uso da linguagem.
Essa revisão também deve ser feita pelos autores. Outros
programadores podem contribuir nesse processo. As unidades
de código fonte são transformadas em código objeto por
meio de um compilador. Nesse sentido, o código objeto será
mapeado nas instruções executáveis pelo microprocessador
que compõe o sistema computacional, resultando no código
de máquina ou código executável.
Em grande parte dos casos, o primeiro nível de
mapeamento é obtido de forma manual ou semiautomatizada,
estando sujeito a “ruídos” inerentes do processo. Temos
alguns exemplos de ruídos: interpretação errônea de aspectos
GH HVSHFLILFDomR GR SURMHWR UHVWULo}HV RX FRPSOH[LGDGHV
características da linguagem de programação adequada. As
restrições advindas de uma linguagem de programação, ou
mesmo o desconhecimento de suas potencialidades, podem
ocasionar alguns raciocínios limitados.
31 387
Para tanto, veremos, agora, algumas das características da
linguagem de programação.
4&DUDFWHU¯VWLFDVGDVOLQJXDJHQVGH
programação
As linguagens de programação são responsáveis
por desempenhar o papel de agente de formalização das
representações de projeto no sistema computacional. Entre
suas características, estão a possibilidade de desempenhar um
impacto no processo de decodificação. Entre as características,
estão:
‡ &DUDFWHUtVWLFDV SVLFROyJLFDV 'H DFRUGR FRP D yWLFD
psicológica, a facilidade de uso, a simplicidade de aprendizagem,
a confiabilidade e a baixa frequência dos erros, são algumas
das características a serem consideradas pelas linguagens de
programação. Tais fatores podem afetar o desenvolvimento
de um software, pois a codificação é uma atividade humana.
‡&DUDFWHUtVWLFDVGHHQJHQKDULDSRGHVHGL]HUTXHSDUD
a engenharia de software, a linguagem de programação
está relacionada com as necessidades do processo de
desenvolvimento do software. Nesse aspecto, podem-se
elencar algumas características decorrentes dessa necessidade:
Ⱥ )DFLOLGDGH GH GHULYDomR GR FyGLJRIRQWH HVWi
relacionada à aproximação da linguagem de programação
com a linguagem de representação do projeto. Geralmente,
as linguagens que dão suporte às construções estruturadas
possibilitam a manipulação de bits, a construção orientada a
objetos e construções de entrada e saída.
Ⱥ (ILFLrQFLD GR FRPSLODGRU HVWi UHODFLRQDGD FRP
os requisitos de tempo de resposta e concisão acerca dos
projetos. A maior parte dos compiladores de linguagem de
alto nível tem geração de código ineficiente.
Ⱥ3RUWDELOLGDGHGL]UHVSHLWRjSRVVLELOLGDGHGRFyGLJR
fonte migrar de um ambiente para outro com o mínimo de
alterações.
Ⱥ $PELHQWH GH GHVHQYROYLPHQWR GL] UHVSHLWR j
disponibilidade de ferramentas de desenvolvimento para uma
ampla gama de aplicações.
Ⱥ0DQXWHQLELOLGDGHGL]UHVSHLWRjVIDFLOLGDGHVQRTXH
tange às alterações do código-fonte para a manutenção. A
clareza do código-fonte é um item essencial para o sucesso
das tarefas de manutenção.
‡ &DUDFWHUtVWLFDV WpFQLFDV Ki GLYHUVDV FDUDFWHUtVWLFDV
técnicas relacionadas à linguagem de programação. Elas
exercem forte impacto na qualidade do software, bem como
nas condições por meio das quais ele é desenvolvido.
Ⱥ6XSRUWHDWLSRVGHGDGRVDWXDOPHQWHQDVOLQJXDJHQV
de programação, o suporte à representação de dados tem
como características a existência de diversas categorias de
dados, tanto em estruturas extremamente simples até em
estruturas extremamente complexas.
Ⱥ 6XESURJUDPDV VmR FRPSRQHQWHV GR SURJUDPD
que contém estruturas de controle e de dados passíveis de
serem compilados individualmente. No que diz respeito aos
elementos de um software, pode-se dizer que subprogramas
são o mapeamento natural dos módulos de um software.
388 Engenharia de Software I
Há diferentes denominações para os subprogramas, entre
eles: sub-rotinas, procedimentos, funções, entre outros.
Subprogramas possuem os seguintes elementos: seção de
HVSHFLILFDomR FRP LGHQWLILFDGRU H GHVFULomR GD LQWHUIDFH
seção de implementação, na qual é descrito o comportamento
SRUPHLRGDVHVWUXWXUDVGHFRQWUROHGHGDGRVPHFDQLVPRVGH
ativação, que, por sua vez, permitem invocar o subprograma
tendo como base um ponto do programa.
Ⱥ (VWUXWXUDV GH FRQWUROH GL]HP UHVSHLWR DR VXSRUWH
ofertado pela representação das estruturas clássicas, como,
por exemplo, sequências, condições e repetições.
Ⱥ 6XSRUWH D DERUGDJHQV RULHQWDGDV D REMHWRV GL]
respeito ao suporte ofertado pela linguagem de programação
ao mapeamento dos elementos especificados.
‡&ULWpULRVGHHVFROKDGHXPDOLQJXDJHPGHSURJUDPDomR
todas as discussões anteriores devem ser levadas em conta.
Contudo, há outros critérios a serem considerados, como:
a área de aplicação para a qual o software
HVWi VHQGR FRQVWUXtGR ‡ D FRPSOH[LGDGH
FRPSXWDFLRQDOHDOJRUtWPLFDGRVRIWZDUH‡R
DPELHQWHQRTXDORVRIWZDUHYDLH[HFXWDU‡RV
UHTXLVLWRV GH GHVHPSHQKR ‡ D FRPSOH[LGDGH
GD HVWUXWXUD GH GDGRV ‡ R FRQKHFLPHQWR GD
HTXLSHGHGHVHQYROYLPHQWR‡DGLVSRQLELOLGDGH
de boas ferramentas de desenvolvimento
(MAZZOLA, p. 74).
Leiam, abaixo, um texto acerca das classes de linguagens.
Leiam-no atentamente e, em caso de dúvidas, compartilhem
via quadro de avisos.
&/$66(6 '( /Ζ1*8$*(16 'HYLGR ¢ JUDQGH GLYHUVLGDGH GDV
OLQJXDJHQVGHSURJUDPD©¥RH[LVWHQWHVQRVGLDVDWXDLV«LQWHUHVVDQWH
HVWDEHOHFHU XPD FODVVLȴFD©¥R TXH SHUPLWD VLWX£ODV QR FRQWH[WR GR
GHVHQYROYLPHQWRGHSURJUDPDV(PERUDRVFULW«ULRVGHFODVVLȴFD©¥R
SRVVDPVHURVPDLVGLYHUVRVDGRWRXVHDTXLXPDµWLFDFURQROµJLFD
onde as linguagens posicionam-se, de certo modo, em função de suas
FDUDFWHU¯VWLFDV W«FQLFDV  /LQJXDJHQV GH 3ULPHLUD *HUD©¥R 1HVWD
FODVVHGHOLQJXDJHQVGHVHQYROYLGDVQRVSULPµUGLRVGDFRPSXWD©¥R
HQTXDGUDPVHDVOLQJXDJHQVHPQ¯YHOGHP£TXLQD2FµGLJRGHP£TXLQD
32
para muitas aplicações de engenharia. Cobol, por outro lado, ainda é
uma linguagem bastante utilizada no desenvolvimento de aplicações
FRPHUFLDLV  /LQJXDJHQV GH 7HUFHLUD *HUD©¥R 1HVWD FODVVH
HQFDL[DPVH DV FKDPDGDV OLQJXDJHQV GH SURJUDPD©¥R HVWUXWXUDGD
VXUJLGDV HP PHDGRV GRV DQRV  2 SHU¯RGR FRPSUHHQGLGR HQWUH
a década de 60 e a de 80 foi bastante produtivo no que diz respeito
ao surgimento de linguagens de programação, o que permitiu o
aparecimento de uma grande quantidade de linguagens as quais
SRGHPVHURUJDQL]DGDVGDVHJXLQWHIRUPDȏDVOLQJXDJHQVGHXVRJHUDO
as quais podem ser utilizadas para implementação de programas com
DVPDLVGLYHUVDVFDUDFWHU¯VWLFDVHLQGHSHQGHQWHGD£UHDGHDSOLFD©¥R
FRQVLGHUDGD HQFDL[DPVH QHVWD FDWHJRULD OLQJXDJHQV FRPR 3DVFDO
0RGXODH&ȏDVOLQJXDJHQVHVSHFLDOL]DGDVDVTXDLVV¥RRULHQWDGDV
DRGHVHQYROYLPHQWRGHDSOLFD©·HVHVSHF¯ȴFDVDOJXPDVGDVOLQJXDJHQV
TXH LOXVWUDP HVWD FDWHJRULD V¥R 3URORJ /LVS H )RUWK ȏ DV OLQJXDJHQV
orientadas a objeto, que oferecem mecanismos sintáticos e semânticos
de suporte aos conceitos da programação orientada a objetos; alguns
H[HPSORVGHVWDVOLQJXDJHQVV¥R6PDOOWDON(L΍HOH&/LQJXDJHQV
de Quarta Geração As linguagens de quarta geração surgiram como
forma de aumentar o grau de abstração na construção de programas.
8PD FDUDFWHU¯VWLFD FRPXP QHVWDV OLQJXDJHQV « D HVSHFLȴFD©¥R GR
SURJUDPDVHPDQHFHVVLGDGHGHH[SUHVV¥RGHGHWDOKHVDOJRU¯WPLFRV
GH SURFHVVDPHQWR ‹ HYLGHQWH TXH GHYLGR D HVWD FDUDFWHU¯VWLFD «
LPSRVV¯YHOTXHXPDOLQJXDJHPSRVVDVHUXWLOL]DGDSDUDDSURJUDPD©¥R
GHXVRJHUDOVHQGRQRUPDOPHQWHGHVWLQDGDVDDSOLFD©·HVHPGRP¯QLRV
HVSHF¯ȴFRV 'HQWUR GHVWD FODVVH « SRVV¯YHO HQFRQWUDU GLIHUHQWHV
FDWHJRULDVGHOLQJXDJHQV/LQJXDJHQVGHFRQVXOWD1HVWDFDWHJRULD
HQFDL[DPVHDVOLQJXDJHQVRULHQWDGDVDDSOLFD©·HVFRQMXQWDVGHEDQFRV
GHGDGRVSHUPLWLQGRTXHRXVX£ULRHVSHFLȴTXHRSHUD©·HVVREUHRV
UHJLVWURV QXP DOWR Q¯YHO GH VRȴVWLFD©¥R $OJXPDV OLQJXDJHQV QHVWD
categoria incorporam recursos de interpretação de linguagem natural,
GH PRGR TXH R XVX£ULR SRGH PDQLSXODU D LQIRUPD©¥R QR Q¯YHO PDLV
DOWRGHDEVWUD©¥RSRVV¯YHO/LQJXDJHQVJHUDGRUDVGHSURJUDPDV
1HVWDFDWHJRULDHVW¥RDVOLQJXDJHQVTXHSHUPLWHPTXHRSURJUDPDGRU
HVSHFLȴTXHRSURJUDPDFRQVLGHUDQGRFRQVWUX©·HVHLQVWUX©·HVQXP
HOHYDGR Q¯YHO GH DEVWUD©¥R VHQGR TXH RV SURJUDPDV VHU¥R REWLGRV
HP FµGLJRIRQWH GH XPD OLQJXDJHP GH SURJUDPD©¥R GH WHUFHLUD
JHUD©¥R2XWUDVOLQJXDJHQV1HVWDFDWHJRULDSRGHVHFRQVLGHUDU
DVOLQJXDJHQVGHVHQYROYLGDVQRV¼OWLPRVDQRVFRPRSRUH[HPSORDV
representa a linguagem interpretada pelos microprocessadores, OLQJXDJHQV GH HVSHFLȴFD©¥R IRUPDO UHIHUHQFLDGDV QR FDS¯WXOR  DV
sendo que cada microprocessador é caracterizado por uma linguagem linguagens de prototipação, e os ambientes de programação presentes
GH P£TXLQD SUµSULD SRGHQGR HYHQWXDOPHQWH HVWDEHOHFHUVH FHUWD HP FRPSXWDGRUHV SHVVRDLV SODQLOKDV EDQFRV GH GDGRV K\SHUWH[WR
compatibilidade em software entre microprocessadores de uma etc...).
PHVPDIDP¯OLDIDEULFDQWH(PERUDWHQGRVHXXVREDVWDQWHOLPLWDGR
DOJXQV SURJUDPDV DLQGD V¥R UHDOL]DGRV XWLOL]DQGR R FµGLJR GH
P£TXLQDRXPDLVSUHFLVDPHQWHVHXHTXLYDOHQWHȊOHJ¯YHOȋDOLQJXDJHP
$VVHPEO\ 1XPD µWLFD GH (QJHQKDULD GH 6RIWZDUH D SURJUDPD©¥R
através de linguagens desta classe limitam-se a situações onde a
OLQJXDJHP GH DOWR Q¯YHO DGRWDGD SDUD D SURJUDPD©¥R Q¥R VXSRUWH
DOJXQVUHTXLVLWRVHVSHFLȴFDGRV/LQJXDJHQVGH6HJXQGD*HUD©¥R
As linguagens de segunda geração constituem as primeiras linguagens
GHȊDOWRQ¯YHOȋTXHVXUJLUDPHQWUHRȴQDOGDG«FDGDGHHLQ¯FLRGRV
DQRV/LQJXDJHQVFRPR)RUWUDQ&RERO$OJROH%DVLFFRPWRGDVDV
GHȴFL¬QFLDVTXHVHSRGHDSRQWDUDWXDOPHQWHIRUDPOLQJXDJHQVTXH
marcaram presença no desenvolvimento de programas, sendo que
DOJXPDVGHODVW¬PUHVLVWLGRDRWHPSRH¢VFU¯WLFDVFRPRSRUH[HPSOR
Fortran que ainda é visto como uma linguagem de implementação
 (67Ζ/2 '( &2'Ζ)Ζ&$‰…2 $ HVFROKD GH XPD OLQJXDJHP GH
programação adequada, que suporte os requisitos de projeto
HVWDEHOHFLGRV H TXH DSUHVHQWH ERDV FDUDFWHU¯VWLFDV HQWUH R FRQMXQWR
apresentado anteriormente é, sem dúvida, um grande passo na direção
da obtenção de um software de qualidade. Entretanto, um fator que é
HVVHQFLDOSDUDDREWHQ©¥RGHXPFµGLJRFODURHTXHRIHUH©DIDFLOLGDGH
de manutenção é a boa utilização dos mecanismos presentes na
OLQJXDJHPDGRWDGDRTXHYDPRVURWXODUDTXLSRUȊHVWLORGHFRGLȴFD©¥Rȋ
$EDL[RVHU¥RGLVFXWLGRVRVSULQFLSDLVIDWRUHVGHWHUPLQDQWHV¢REWHQ©¥R
GHFµGLJRIRQWHEHPHVFULWR$'RFXPHQWD©¥RGH&µGLJR2FµGLJR
IRQWH Q¥R GHYH VHU FRQVLGHUDGR HP QHQKXPD KLSµWHVH FRPR XP
resultado intermediário irrelevante no processo de desenvolvimento
de um software. Ele se constitui num elemento essencial tanto para
atividades de validação do software como (e principalmente) para as

tarefas de manutenção. Desta forma, o aspecto de documentação
é um aspecto que deve ser bastante considerado na etapa de
FRGLȴFD©¥R 8P SULPHLUR SDVVR QD GRFXPHQWD©¥R GR FµGLJR IRQWH «
DHVFROKDGRVLGHQWLȴFDGRUHVGHYDUL£YHLVHSURFHGLPHQWRV2XVRGH
ȊVLJODVȋ RX FDUDFWHUHV SDUD LGHQWLȴFDU RV HOHPHQWRV GH XP SURJUDPD
é uma tendência herdada das linguagens de segunda geração que
não encontra mais lugar nos dias atuais. Assim, é importante que os
LGHQWLȴFDGRUHVHVFROKLGRVWHQKDPVLJQLȴFDGRH[SO¯FLWRSDUDDDSOLFD©¥R
considerada. Outro aspecto bastante considerado é a introdução de
FRPHQW£ULRVDRORQJRGRFµGLJRIRQWH1DUHDOLGDGHHVWH«XPDVSHFWR
bastante polêmico, mas este mecanismo pode ser bastante útil se
XWLOL]DGR HȴFLHQWHPHQWH SRGHQGR WUDQVIRUPDUVH QR SULQFLSDO DOLDGR
às tarefas de manutenção. Uma sistemática interessante de uso dos
comentários é a compatibilização destes com a documentação de
projeto do software. Um último aspecto importante na documentação
« D IRUPDWD©¥R GR FµGLJRIRQWH 8P PHFDQLVPR LPSRUWDQWH QHVWH
FRQWH[WR«RXVRGDHQGHQWD©¥RFRPRPHLRGHPHOKRUSRVLFLRQDUDV
LQVWUX©·HVQRFRQWH[WRGHWUHFKRVVLJQLȴFDWLYRVGRFµGLJR$HQGHQWD©¥R
SHUPLWH H[SOLFLWDU PHOKRU D FRPELQD©¥R GRV EORFRV E£VLFRV GH XPD
linguagem de programação (as estruturas clássicas de controle) para
DFRPSRVL©¥RGHFRPSRQHQWHVPDLVFRPSOH[RV1RTXHGL]UHVSHLWR
a este aspecto muitas ferramentas CASE oferecem os chamados
IRUPDWDGRUHVDXWRP£WLFRVGHFµGLJRRVTXDLVOLEHUDPRSURJUDPDGRU
desta preocupação.
5.2. A Declaração de Dados Este aspecto nem sempre é objeto de
preocupação por parte dos programadores, mas, à medida que o
SURJUDPD YDL VH WRUQDQGR FRPSOH[R QR TXH GL] UHVSHLWR ¢ GHȴQL©¥R
de estruturas de dados, o estabelecimento de uma sistemática
padronizada de declaração de tipos de dados e variáveis vai assumindo
XPQ¯YHOFDGDYH]PDLRUGHLPSRUW¤QFLD$OLQJXDJHP3DVFDOGHXXP
impulso importante neste aspecto, com a possibilidade do usuário
FRQVWUXLUWLSRVGHGDGRVPDLVFRPSOH[RVDSDUWLUGRVWLSRVE£VLFRVH
de seus construtores. Este mecanismo está presente em praticamente
todas as linguagens em uso nos dias de hoje. 5.3. A Construção de
ΖQVWUX©·HV2ȵX[ROµJLFRGHLQVWUX©·HV«GHȴQLGRQRUPDOPHQWHGXUDQWH
a etapa de projeto (projeto detalhado). Entretanto, o mapeamento
GHVWH ȵX[R OµJLFR HP LQVWUX©·HV LQGLYLGXDLV ID] SDUWH GR WUDEDOKR GH
FRGLȴFD©¥R8PDVSHFWRTXHGHYHVHUH[SORUDGRGXUDQWHDFRQVWUX©¥R
das instruções é a simplicidade. Utilizar as possibilidades que algumas
linguagens oferecem de escrever mais de uma instrução por linha, por
H[HPSOR«VHPG¼YLGDXPDGHFLV¥RTXHYDLFRQWUDDFODUH]DGRFµGLJR
independente da economia de espaço (e de papel) que isto pode
UHSUHVHQWDU$EDL[RV¥RDSUHVHQWDGDVDOJXPDVUHJUDVLPSRUWDQWHVQR
TXHGL]UHVSHLWRDHVWHDVSHFWRȏHYLWDURXVRGHWHVWHVFRQGLFLRQDLV
FRPSOLFDGRVRXTXHYHULȴTXHPFRQGL©·HVQHJDWLYDVȏHYLWDURLQWHQVR
DQLQKDPHQWRGHOD©RVRXFRQGL©·HVȏXWLOL]DUSDU¬QWHVHVSDUDHYLWDUD
DPELJ¾LGDGHQDUHSUHVHQWD©¥RGHH[SUHVV·HVOµJLFDVRXDULWP«WLFDVȏ
XWLOL]DUV¯PERORVGHHVSD©DPHQWRSDUDHVFODUHFHURFRQWH¼GRGHXPD
LQVWUX©¥R  (QWUDGDV6D¯GDV $V HQWUDGDV GH GDGRV QXP VRIWZDUH
podem ser realizadas de forma interativa ou em batch. Independente
da forma como as entradas serão efetuadas, é importante considerar
DOJXPDV UHJUDV ȏ YDOLGD©¥R GH WRGDV DV HQWUDGDV GH GDGRV ȏ
VLPSOLFLGDGH H SDGURQL]D©¥R QR IRUPDWR GD HQWUDGD ȏ QR FDVR GH
HQWUDGDVHQYROYHQGRP¼OWLSORVGDGRVHVWDEHOHFHUXPLQGLFDGRUGHȴQDO
33 389
Pessoal, no texto, refletimos acerca das classes de
linguagens, considerando sua diversidade e sua classificação.
Em caso de dúvida, partilhem no quadro de avisos, tudo bem?
Retomando a aula
3HVVRDOFKHJDPRVDRȴQDOGDTXLQWDDXOD
Vamos, então, recordar.
3URMHWRHLPSOHPHQWDomR
Conversamos, na primeira seção, sobre projeto e
implementação. Quando falamos sobre o estágio de projeto
e implementação do desenvolvimento de software, referimo-
nos ao processo em que se converte uma especificação de
sistema em um sistema que possa ser executado. Para tanto, as
etapas de projeto e implementação envolvem a formalização
das ideias verificadas na etapa da engenharia do sistema, dos
requisites estabelecidos e dos modelos gerados na etapa de
projeto para que o sistema computacional-alvo possa realizar
as tarefas definidas anteriormente
3URMHWRRULHQWDGRDREMHWRVFRP80/
Os sistemas orientados a objetos são compostos
interativos, tendo em vista que podem manter o seu próprio
estado local, e, também, oferecer operações nesse mesmo
estado. A representação de seu estado, contudo, é privada:
não pode ser acessada diretamente. Os projetos orientados a
objetos permitem que se projetem as classes de objetos e sejam
feitos relacionamentos entre elas. Tais classes, por sua vez,
são responsáveis pela definição dos objetos no sistema, bem
como suas interações. Já quando o projeto é elaborado como
um programa em execução, os objetos ganham dinamicidade,
tendo como base as definições de classe.
7UDGXomR
Na terceira seção, abordamos a tradução. Ela é feita
QDDWLYLGDGHGH´FRGLÀFDomRµ(VVHPDSHDPHQWRUHVXOWDQR
código fonte. As unidades de código fonte produzidas são
submetidas a uma revisão de código. Nesse processo, são
corrigidos os defeitos gerados a partir de erros de digitação,
ou, ainda, do uso da linguagem. Quando se faz uma revisão,
deve-se considerar que são introduzidos por erros de digitação
ou de uso da linguagem.
&DUDFWHUtVWLFDVGDOLQJXDJHPGHSURJUDPDomR
As linguagens de programação são responsáveis
por desempenhar o papel de agente de formalização das
GHHQWUDGD(17(5SRQWRȴQDOHWFȏHQWUDGDVGHGDGRVLQWHUDWLYDV
representações de projeto no sistema computacional. Entre
devem ser rotuladas, indicando-se eventuais parâmetros, opções e
suas características, estão a possibilidade de desempenhar
YDORUHVGHIDXOWȏURWXOD©¥RGHUHODWµULRGHVD¯GDHSURMHWR0$==2/$
um impacto no processo de decodificação. Discutimos suas
p. 76-78).
características de modo detalhado.
390 Engenharia de Software I 34

Vale a pena

Vale a pena acessar

O texto Engenharia de software discute as questões

aqui abordadas. Disponível em: <https://jalvesnicacio.files.
wordpress.com/2010/03/engenharia-de-software.pdf>.
Acesso em: 05 abr. 2017.

Vale a pena assistir

Vejam também o vídeo: Disponível em: <https://

www.youtube.com/watch?v=PmefpISZ7Ew>. Acesso em:
05 abr. 2017.

Minhas anotações
 391

Aula 6º

Teste de software

Olá, alunos(as),
Nesta aula, conheceremos os testes de software.
Entenderemos desde seus conceitos, até o entendimento
de alguns testes de software. Perceberão a importância
dessa etapa para validar a qualidade do projeto.
Leiam com atenção, tudo bem?
Boa aula!

Objetivos de aprendizagem

Ao término desta aula, vocês serão capazes de:

‡HQWHQGHURFRQFHLWRGHWHVWHGHVRIWZDUH
‡VDEHUDUHVSHLWRGRVSULQFLSDLVWHVWHVGHVRIWZDUHXWLOL]DGRV
392 Engenharia de Software I
Seções de estudo
1 - O que é o teste de software?
2 - Objetivos dos testes
3 - Projeto de casos de teste
1 - O que é o teste de software?
Em nossa primeira seção vamos discutir o conceito de
teste de software. Peço que compartilhem dúvidas no quadro
de avisos, ok? Atentem à aula a vamos lá!
Figura 1. Sommerville, 2011, p. 147.
O teste de software tem por princípio desenvolver ações
que possibilitem que sejam detectados defeitos do software.
Contudo, a fase de testes não tem a capacidade de eliminar
todas as falhas, mas somente os defeitos de software que se
fizerem presentes.
Ela é desenvolvida durante e depois do processo de
implementação. Todos os programas que compõem os
sistemas são devidamente testados, e, assim, certifica-se que
ele atente às especificações e que suas funcionalidades estão
correspondendo com as esperadas, ou seja, com o cliente.
Ao contrário das revisões e inspeções, os testes não são
tão eficazes para a remoção de defeitos. No entanto, na fase
de testes é possível perceber alguns possíveis defeitos que não
foram detectados pelas revisões. Nesse sentido, ainda é possível
verificar a qualidade de um produto e de seus componentes.
Mesmo que o software tenha sido construído com base
nas técnicas e nos métodos da engenharia de software, não
é possível evitar o surgimento de falhas, por isso, a etapa
de testes é tão necessária. Deve se considerar, ainda, não é
possível testar o software exaustivamente. Mesmo que sejam
produtos simples, um teste que envolva um programa com
entrada de um texto de dez caracteres envolveria uma análise
de 2610 combinações. Levando em conta que muitos testes
são redundantes, a utilização de força bruta pode fazer com
que muitos casos com alta probabilidade de defeitos não
sejam testados.
Para se ter uma ideia da importância dessa fase e de seu
impacto nos resultados, muitas vezes, a etapa de teste chega
a 40% do esforço empreendido para o desenvolvimento de
software. Já em casos de programas em sistemas críticos,
dos quais dependem vidas humanas, como controle de voo,
a atividade de teste pode chegar a um custo de três a cinco
vezes do orçamento das demais atividades.
Os pesquisadores da área de teste de software apresentam
divergências no que diz respeito à terminologia. Nesse sentido,
O Institute of Electrical and Electronics
Engineers (IEEE) 610.12-1990 (IEEE, 1990)
tem realizado vários esforços com o intuito
de padronizar a terminologia utilizada em
36
vários campos do conhecimento, dentre eles o
da Engenharia de Software. Nesta dissertação,
p XWLOL]DGD D GHÀQLomR HVWDEHOHFLGD SHOR
IEEE. A norma IEEE distingue os termos
da seguinte forma: GHIHLWR (fault) – é um ato
inconsistente cometido por um indivíduo ao
tentar entender uma determinada informação,
resolver um problema ou utilizar um método
ou uma ferramenta. Por exemplo, uma
LQVWUXomRRXFRPDQGRLQFRUUHWRHUUR (error)
- manifestação concreta de um defeito num
artefato do software, ou seja, é a diferença
HQWUHYDORUREWLGRHRYDORUHVSHUDGRHIDOKD
(failure) - o comportamento operacional do
software diferente do esperado pelo usuário.
Uma falha pode ter sido causada por diversos
erros e alguns erros podem nunca causar uma
falha (SOUZA, 2010, p. 5).
Por mais que haja divergências conceituais, a norma IEEE
fica indicada para definição dos termos.
2 - Objetivos dos testes
Para que sejam feitos os testes, é importante que se tenham
objetivos muito bem definidos. Por se tratar de uma etapa
que pode gerar custos dispendiosos, devem ser planejados e
desenhados. Assim, consegue-se extrair o melhor dos recursos
destinados para testes.
De modo amplo, o objetivo das técnicas de testes é
promover ações que verifiquem diferentes classes de erros,
e, do mesmo modo, de modo rápido e com o mínimo de
dificuldades.
É importante, para aferir a qualidade do software,
entender que:
Caso os erros graves sejam recorrentes, a qualidade do
VRIWZDUHSUHFLVDVHUSRVWDHPTXHVWmR
Caso os erros facilmente corrigidos sejam encontrados, a
qualidade e a confiabilidade do software estão aceitáveis. Ou,
GLVS}HVHGHWHVWHVTXHVWLRQiYHLV
Se não houver erros, o teste precisa ser verificado, pois sua
configuração não foi elaborada de modo suficiente e há erros
ocultos no software.
Uma coisa certa é: não há software livre de falhas. A
função do teste é identificá-las, portanto, eles precisam ser
programados corretamente.
Figura 2: O teste no processo de software.
 37
3 - Projeto de casos de teste
Os métodos de projetos de casos de teste disponibilizam
uma abordagem sistemática ao teste, e um mecanismo que
contribua para garantir que se detectem erros com alta
probabilidade. Por isso, os testes devem sempre ser desenhados
e planejados da melhor forma possível.
Figura 6.1 – Estrutura de testes
Os testes são os melhores indicadores da qualidade do
produto. Nesse sentido,
Os desenvolvedores não são as pessoas mais
adequadas para testar seus próprios produtos.
Assim como nas revisões, os autores têm
PDLRU GLÀFXOGDGH HP HQ[HUJDU SUREOHPDV
comparados com pessoas que não participam
do desenho e da implementação. O trabalho
de testadores independentes é particularmente
importante no caso dos testes de aceitação e de
integração, que exercitam o produto como um
todo. O planejamento e o desenho dos testes
devem ser feitos por pessoas experientes, que
conheçam adequadamente a metodologia de
testes usada. Por outro lado, a realização dos
WHVWHV EDVHDGRV HP SODQRV H HVSHFLÀFDo}HV GH
WHVWHVEHPGHÀQLGRVSRGHVHUIHLWDSRUSHVVRDV
menos experientes, ou pode até ser parcialmente
automatizada (http://www.theclub.com.br/
restrito/revistas/PDFS/2005/0506.pdf).
3.1 - Abordagens de teste
As duas abordagens de testes são o Teste da Caixa Preta e
o Teste da Caixa Branca. Vamos conhecê-los individualmente.
3.1.17HVWHGH&DL[D3UHWD
Está relacionado aos requisitos funcionais (voltem à aula
sobre requisitos, caso tenham dúvidas). Diz respeito aos testes
que são realizados nas interfaces do software e são úteis para
demonstrar que:
‡$VIXQo}HVGRVRIWZDUHVmRRSHUDFLRQDLV em suas variáveis. Os diversos caminhos possíveis são os
‡$HQWUDGDpDGHTXDGDPHQWHDFHLWD$VDtGDpSURGX]LGD
FRUUHWDPHQWH Complexidade Lógica.
‡$LQWHJULGDGHGDVLQIRUPDo}HVH[WHUQDVpPDQWLGD
393
Esse teste examina os aspectos do sistema e não considera
a estrutura lógica do software. O foco, nesse teste, é investigar
elementos como:
‡PRGRGHFRPSRUWDPHQWRGRVRIWZDUHQDVH[WUHPLGDGHV
‡GHVHPSHQKRGDVIXQo}HV
‡SRVVtYHLVIXQo}HVLQFRUUHWDV
‡UHWRUQRGRVUHVXOWDGRV
‡HUURVGHLQWHUIDFH
‡HQWUDGDVHVDtGDV
‡SRVVtYHLVHUURVQDVHVWUXWXUDVGHGDGRVRXQRDFHVVRD
EDQFRVGHGDGRVH[WHUQRV
‡SRVVtYHLVHUURVGHGHVHPSHQKR
‡SRVVtYHLVHUURVGHLQLFLDOL]DomRHWpUPLQR
‡LQWHJUDomRHQWUHVRIWZDUHV
Como o software se comporta nas extremidades, perceber
se as funções estão desempenhando seus papéis, entender se
há funções incorretas, obter o retorno dos resultados, ver se
há erros de interface.
Para tanto, o desenvolvedor pode se concentrar em
algumas perguntas:
ȏ&RPRDYDOLGDGHIXQFLRQDO«WHVWDGD"
ȏ4XDLVFODVVHVGHGDGRVGHHQWUDGDFRQVWLWXLU¥RERQVFDVRVGHWHVWH"
ȏ2VLVWHPD«SDUWLFXODUPHQWHVHQV¯YHODFHUWRVYDORUHVGHHQWUDGD"
ȏ&RPRDVIURQWHLUDVGHXPDFODVVHGHGDGRVV¥RLVRODGDV"
ȏ4XDLV¯QGLFHVGHGDGRVHYROXPHVGHGDGRVRVLVWHPDSRGHWROHUDU"
ȏ 4XH HIHLWRV WHU¥R FRPELQD©·HV HVSHF¯ȴFDV GH GDGRV VREUH D
operação do sistema?
Fonte: <https://polisoftware.wordpress.com/2012/11/05/teste-processos/>.
Acesso em: 8 abr.
3.1.27HVWHGDFDL[DEUDQFD
O Teste da Caixa Branca, por sua vez, se encarrega de
um exame minucioso dos procedimentos e das estruturas
internas. O estado do programa, assim, pode passar por
diversos exames para obter resultados no que diz respeito
ao fato de determinar se o estado esperado corresponde ao
estado real. Assim, os caminhos lógicos são testados por
meio do software, e, assim, são fornecidos casos de teste que
investigam conjuntos específicos de condições ou lações.
Mesmo em programas pequenos, é importante notar que a
quantidade de caminhos lógicos pode ser bem ampla, o que
representaria um grande obstáculo para o sucesso de tal
atividade.
O Teste da Caixa Branca pode dar origem a outros casos
de testes. Vamos verificá-los?
Caminho independente: um caminho independente diz
respeito a um caminho que introduza pelo menos um novo
conjunto de instruções de processamento, ou, ainda, uma
nova condição.
Teste do Caminho Básico: cada programa tem em seus
DOJRULWPRVYDULDGRVFDPLQKRVTXHSRGHPVHUVHJXLGRVHOHV
dependerão dos valores de entrada e dos resultados obtidos
FDPLQKRV OyJLFRV VXD PHGLomR GHSHQGH GD 0HGLGD GH
Grafo de Fluxo ou Grafo de Programa: é usado para
394 Engenharia de Software I 38
representar o fluxo de controle e permite representar os
caminhos independentes existentes no algoritmo. Vejam seus ȏ2Q¼PHURGHUHJL·HVGRJU£ȴFRGHȵX[R
possíveis símbolos: ȏ9* (1RQGH(«RQ¼PHURGHUDPRVGRJUDIRH1RQ¼PHURGH
QµVGRJUDIRGHȵX[R*
ȏ9* 3RQGH3«RQ¼PHURGHQµVSUHGLFDWLYRVQµVTXHFRQW«P
XPDFRQGL©¥RFRQWLGRVQRJUDIRGHȵX[R*
Fonte: <https://memorexti.wordpress.com/2016/02/25/testes-de-software-33/>.
Acesso em: 8 abr. 2017.

No exemplo a seguir observamos o cálculo da

Figura 3. Fonte: <https://images.google.com/>. Acesso em: 05 abr. 2017. complexidade ciclomática usando as três formas:
A estrutura Caso deve ser decomposta em estruturas
6H 1RWHP QD ÀJXUD DEDL[R TXH RV QyV SRVVXHP XPD
decisão e delas partem dois caminhos: são chamados de nós
predicativos.

Figura 6. Fonte: <https://images.google.com/>. Acesso em: 05 abr. 2017.

Figura 4. Fonte: <https://images.google.com/>. Acesso em: 05 abr. 2017.

As regiões do grafo podem ser observadas pelas cores

1R JUDIR GH ÁX[R HQFRQWUDPRV TXDWUR HOHPHQWRV
HVVHQFLDLV 1yV $UHVWDV UDPRV ² 5HSUHVHQWDP R ÁX[R GH verde, vermelha, branca e a região externa ao grafo que é a
FRQWUROHHQWUHRVQyV5HJL}HV1yVSUHGLFDWLYRV²FRQWpP amarela.
uma instrução condicional.
Derivando casos de testes - Passos do Método
Exemplo:

1) Usando um procedimento de um algoritmo, mostrado

DVHJXLUWUDFHXPJUDIRGHÁX[RFRUUHVSRQGHQWH

3URFHGLPHQWR 0$,25 $9HWRU 7LQWHLURYDU 0$;

LQWHLURYDULiYHLV,0LQWHLUR
Início
 0$>@
 ,
3. Enquanto I < T faça
4. Se A[I] > M
 (QWmR 0$>,@
Figura 5. Fonte: <https://images.google.com/>. Acesso em: 05 abr. 2017.
 ,,
Complexidade Ciclomática: essa métrica de software  6HQmR,,
oferta uma medida quantitativa de complexidade lógica em  )LP6H
um programa. Se usada no contexto do método de teste  )LP(QTXDQWR
de caminho básico, o valor resultado irá definir o número
 0D[0
de caminhos independentes do conjunto básico de um
programa e oferecerá um limite máximo ao número de testes )LPGR3URFHGLPHQWR
a serem feitos, garantindo que as instruções sejam executadas
ao menos uma vez. Ela pode ser obtida de três modos: Para este exemplo, o grafo gerado será o seguinte:
 39 395
Vamos discutir um exercício resolvido? Fiquem atentos e,
em caso de dúvidas, procurem saná-las pelo quadro de avisos:

(63(&Ζ)Ζ&$‰…2DIXQ©¥RGHYHGHWHUPLQDUVHXPLGHQWLȴFDGRU«RX
Q¥R Y£OLGR HP XPD OLQJXDJHP LPDJLQ£ULD 8P LGHQWLȴFDGRU Y£OLGR
GHYHFRPH©DUFRPXPDOHWUDHFRQWHUDSHQDVOHWUDVRXG¯JLWRV$O«P
GLVVRGHYHWHUQRP¯QLPRFDUDFWHUHHQRP£[LPRFDUDFWHUHVGH
comprimento.

Condição de Entrada Classe(s) válida Classe(s) inválida

Tamanho t do (1) (2) (3) (4)
LGHQWLȴFDGRU ! W  t<1 W!
Primeiro caractere é Sim (5) 1¥R(6)
letra?
Demais caracteres Sim (7) 1¥R(8)
são letras ou digitos

Caso de teste:
Figura 7. Fonte: <https://images.google.com/>. Acesso em: 05 abr. 2017.
‡[YHUGDGHLUR!(1)
2) Determine a Complexidade Ciclométrica do grafo de ‡QRPH$OYHUGDGHLUR!(1, 2, 5, 7)
ÁX[RUHVXOWDQWH&RPSOH[LGDGH&LFORPiWLFD ‡QRPH$OXQRIDOVR!(4)
Primeira forma: 2JUDIRGHÁX[RWHPWUrVUHJL}HV ‡ DEFIDOVR!(6)
Segunda forma: V(G) = 10 ramos - 9 nós + 2 = 3 ‡DEF IDOVR!(8)
Terceira forma: V(G) = 2 nós predicativos + 1 = 3
&RPSOH[LGDGH&LFORPiWLFDGRJUDIRGHÁX[RpLJXDOD
Retomando a aula

&KHJDPRVDRȴQDOGDVH[WDDXOD-£WUD©DPRVXPEHOR
percurso por aqui, não é mesmo?
Vamos, então, recordar.

2TXHpRWHVWHGHVRIWZDUH"
Nesta seção, conhecemos o conceito de teste de software,
bem como sua importância na execução de projetos de
software. O teste de software tem por princípio desenvolver
ações que possibilitem que sejam detectados defeitos do
software. Contudo, a fase de testes não tem a capacidade de
eliminar todas as falhas, mas somente os defeitos de software
que se fizerem presentes.
2EMHWLYRVGRVWHVWHV
Figura 8. Fonte: <https://images.google.com/>. Acesso em: 05 abr. 2017.
Nesta seção, entendemos quais são os objetivos e
finalidades dos testes. Também percebemos em que medida
3) Determine um conjunto básico de caminhos os testes se diferenciam de outros modos de verificação
linearmente independentes: da qualidade do software. Para que sejam feitos os testes, é
Caminho 1: 1-2-3-10 importante que se tenham objetivos muito bem definidos. Por
Caminho 2: 1-2-3-4-5-6-8-9-3-10 se tratar de uma etapa que pode gerar custos dispendiosos,
Caminho 3: 1-2-3-4-7-8-9-3-10 devem ser planejados e desenhados. Assim, consegue-se
extrair o melhor dos recursos destinados para testes.
Vamos praticar?
3URMHWRGHFDVRVGHWHVWH
Os métodos de projetos de casos de teste disponibilizam
Utilizando seu conhecimento de Delphi ou alguma outra linguagem de
uma abordagem sistemática ao teste, e um mecanismo
SURJUDPD©¥R HODERUH XPD FKHFNOLVW GH HUURV FRPXQV Q¥R HUURV GH
que contribua para garantir que se detectem erros com
VLQWD[HTXHQ¥RSRGHPVHUGHWHFWDGRVSRUXPFRPSLODGRUPDVTXH
alta probabilidade. Por isso, os testes devem sempre ser
podem ser detectados em uma inspeção de programa.
desenhados e planejados da melhor forma possível.
396 Engenharia de Software I 40

Vale a pena

Vale a pena acessar

Buscando qualidade de software com a aplicação de

técnicas de teste. O artigo discute modos de se alcançar
a qualidade em projetos a partir da aplicação de técnicas
de teste. Disponível em: <http://www.theclub.com.br/
restrito/revistas/PDFS/2005/0506.pdf>.

Minhas anotações
 397

Aula 7º

Gerência de projetos

Caros(as) alunos(as),
Nesta aula, abordaremos a questão da gerência de projetos.
Enquanto etapa essencial da engenharia de software, é importante
saber que o bom gerenciamento garante melhores resultados no
projeto, e previne falhas, entregas atrasadas, aumento do custo,
entre outras questões.
Já perceberam que é uma discussão fulcral para nós, não é?
Então, vamos à sétima aula!
Boa aula!

Objetivos de aprendizagem

Ao término desta aula, vocês serão capazes de:

‡FRQKHFHUDVSHFWRVUHODWLYRVjJHVWmRGHSURMHWRV
‡VDEHUDUHVSHLWRGR30%2.
398 Engenharia de Software I 42
esforço altamente intensivo de pessoas que
Seções de estudo co-participam em um período de tempo, com
implicações fundamenteis no projeto e no
desempenho das diferentes classes de pessoas
1 - Gerência de projetos (BOEHM E ROSS, 1989), em busca de um
2 - PMBOK
1 - Gerência de projetos
O gerenciamento de projetos vem, há tempos, sendo
desenvolvido: desde a antiguidade, é possível encontrar
evidências de seu surgimiento e evolução, como, por exemplo,
na construção das Grandes Pirâmides. Como começaram
a ser projetadas as primeiras grandes construções, ficou
evidente a necessidade da utilização de métodos, técnicas
e ferramentas para gerenciar projetos. Em dissertação de
mestrado, discuto essa e outras questões. Caso queiram ler
mais sobre a temática, segue o link: <http://www.din.uem.
br/~mestrado/diss/2012/almeidajunior.pdf>.
Apesar de não ser prática recente, o gerenciamento de
projetos torna-se formal há pouco mais de cinquenta anos:
Atualmente, o conceito por trás do
gerenciamento de projetos está sendo aplicado
em diversas indústrias e organizações de defesa,
construção civil, produtos farmacêuticos,
químicos, bancário, hospitais, contabilidade,
publicidade, direito, governos estaduais e
UHVXOWDGR SRVLWLYR 6RPPHUYLOH  DÀUPD
que “O fracasso de muitos grandes projetos
de software, na década de 60 e no início da
década de 70, foi a primeira indicação das
GLÀFXOGDGHV GH *HUHQFLDPHQWR GH 6RIWZDUHµ
Ele analisa que esses projetos não fracassaram
por incompetência da equipe, mais sim pela
abordagem de gerenciamento utilizada, como
também pode ser observado nos relatórios
elaborados nos anos 90 pelo Departamento
de Defesa Americano (DOD) (DOD, 1994)
e o “The Chaos Report” (THE STANDISH
GROUP, 1994) (ALMEIDA JUNIOR, 2012,
p. 22).
Como a engenharia de software está sempre dependendo de
orçamentos e cronogramas apertados, um bom gerenciamento
de projetos é decisivo, e garantirá que o produto seja entregue
ao cliente cumprindo os requisitos, dentro do prazo e dentro
do custo.
Normalmente, os gerentes assumem as seguintes
responsabilidades, discutidas por Sommerville (2011, p. 415):
1. planejamento do projeto. Os gerentes devem planejar
ORFDLV .(5=1(5  H SRU ÀP QR GH
desenvolvimento de sistemas de software.
De acordo com Kerzner (2009), a Gerência
de Projetos consiste no planejamento,
organização, direção e controle dos recursos
de uma empresa para objetivos relativamente
de curto prazo que foram estabelecidos para
DFRQFUHWL]DomRGHREMHWLYRVHVSHFtÀFRV3DUD
a quarta edição do Guia PMBOK (2008),
Gerenciamento de Projetos é a aplicação de
conhecimentos, habilidades, ferramentas
H WpFQLFDV QDV DWLYLGDGHV GR SURMHWR D ÀP
de atender aos requisitos do projeto. Para a
norma ISO / IEC 15504 (ISO / IEC 15504,
1999), o propósito da gerência de projetos é
LGHQWLÀFDUHVWDEHOHFHUFRRUGHQDUHPRQLWRUDU
as atividades, tarefas e recursos de que um
projeto necessita para produzir um produto
ou serviço, no contexto dos requisitos e
restrições do projeto (ALMEIDA JUNIOR,
2012, p. 22).
Entendemos, por meio da citação, que o gerenciamento
de projetos lida com a capacidade de se elaborar uma
sequência de ações do início ao fim do projeto com o objetivo
de garantir seu melhor aproveitamento. Já no que tange ao
gerenciamento de software,
[…] Gerenciamento de Projeto pode
ser considerado uma arte. A estratégia
de integração da tecnologia de software,
economia e relações humanas no contexto
HVSHFtÀFRGHSURMHWRGHVRIWZDUHQmRpXPD
tarefa fácil. O projeto de software é um
e elaborar a estimativa e cronograma do desenvolvimento do
projeto. Além disso, deve organizar a equipe e atribuir tarefas.
Também deve fazer a supervisão do trabalho.
2. geração de relatórios. Os gerentes elaboram os relatórios
com os dados sobre o andamento do projeto tanto para os
clientes quanto para os gerentes da empresa em que trabalha.
Precisam ter a capacidade de articular a linguagem de modo a
alcançar diferentes públicos, e “traduzir” a linguagem técnica a
uma linguagem mais acessível, quando estiver produzindo um
relatório ao cliente.
3. gerenciamento de riscos. Os gerentes do projeto
avaliam os riscos que poderão afetá-lo. Assim, devem conseguir
identificar e controlar os possíveis riscos.
4. gerenciamento de pessoas. Também é ele quem organiza
D HTXLSH VHOHFLRQD SHVVRDV H JDUDQWH R ERP DQGDPHQWR GH
quem está envolvido no projeto.
5. elaboração de proposta. O gerente de projetos também
elaboram propostas de modo a fechar contratos. É uma tarefa
bastante importante e crítica, pois depende da capacidade de
conseguir contratos suficientes para sustentar a empresa.
1.1 - Gerenciamento de riscos
O gerenciamento de riscos diz respeito à capacidade
do gerente em antecipar riscos e resolvê-los. É uma etapa
bastante séria, para a qual o profissional deve ter experiência e
capacidade de análise crítica das diferentes problemáticas que
vão surgindo. Há três tipos de riscos que podem surgir.
Riscos de projeto: podem afetar o cronograma ou
os recursos, como, por exemplo, a perda de um projetista
experiente.
Riscos de produto: podem afetar a qualidade ou o
desempenho do software, como, por exemplo, a aquisição de
 43
um componente falho.
Riscos de negócio: podem afetar a organização que
está desenvolvendo ou que adquiriu um software, como o
surgimento de um concorrente com um produto inovador e
competitivo. Sommerville (2013) elenca o modo como deve ser
organizado um processo de gerenciamento de riscos:
Figura 1. Sommerville, 2013.
1.2 - Gerenciamento de pessoas
Q²
Outra etapa do gerenciamento de projetos é o
gerenciamento de pessoas. Uma equipe é responsável, em
seu conjunto, pelo bom andamento do projeto. Para ter uma
boa equipe, o gerente deve ter em mente que esse não é um
processo barato ou simples. Para tanto, respeito pela equipe é
uma maneira de motivá-la. O contrário faz com que haja muita
rotatividade, insatisfação e desconfiança em relação ao gerente
e à empresa.
Para Sommerville (2011, p.421), há quatro questões
básicas relacionadas à gestão de pessoas:
1. Consistência. Pessoas em uma equipe de
projeto devem ser tratadas da mesma forma.
Ninguém espera que o reconhecimento seja
igual para todos, mas as pessoas não devem
sentir que sua contribuição para a organização
é subvalorizada.
2. Respeito. Pessoas diferentes têm habilidades
diferentes e os gerentes devem respeitar essas
diferenças. A todos os membros da equipe
devem ser dadas oportunidades de contribuir.
Claro que, em alguns casos, você vai encontrar
pessoas que simplesmente não se encaixam
em uma equipe e não podem continuar, mas
é importante não tirar conclusões no estágio
inicial do projeto.
3. Inclusão. Pessoas contribuem efetivamente
quando sentem que são ouvidas por outras
pessoas e que suas propostas são levadas
em consideração. É importante desenvolver
um ambiente de trabalho em que todas as
visões são consideradas, mesmo aquelas dos
membros mais novos da equipe.
4. Honestidade. Como gerente, você
deve sempre ser honesto sobre o que está
indo bem e o que vai mal na equipe. Você
também deve ser honesto sobre seu nível
de conhecimento técnico e estar disposto a
submeter-se a algum membro da equipe com
mais conhecimento, quando necessário. Se
tentar encobrir sua ignorância ou problemas,
você será eventualmente descoberto e perderá
o respeito do grupo.
399
Sommerville (2011) ainda destaca que a experiência é um
LWHPIXOFUDOGDJHVWmRGHSHVVRDVQmRpDOJRTXHVHDSUHQGD
em um livro.
Acerca do gerenciamento de projetos, Somerville (2011)
defende que é necessário que os membros de uma equipe se
comuniquem de uma maneira eficaz. Devem compartilhar
informações acerca do andamento do trabalho, acerca das
decisões e sobre as alterações realizadas. Assim, é possível
que um contribua com o outro, possibilitando o bom
andamento do projeto. Há alguns aspectos específicos a serem
consideradas para uma boa comunicação da equipe:
1. Tamanho de grupo. Conforme um grupo
VHWRUQDPDLRUDFRPXQLFDomRHÀFD]HQWUH
RVPHPEURVÀFDPDLVGLItFLO2Q~PHURGH
OLQNVGHFRPXQLFDomRXQLGLUHFLRQDOpQ
1), em que n é o tamanho do grupo, então,
com um grupo de oito membros, existem
56 possíveis caminhos de comunicação. Isso
VLJQLÀFDTXHpSRVVtYHOTXHDOJXPDVSHVVRDV
raramente se comuniquem com outras. As
diferenças de status entre os membros de
JUXSR VLJQLÀFDP TXH DV FRPXQLFDo}HV
frequentemente, são unidirecionais. Os
gerentes e os engenheiros experientes
tendem a dominar as comunicações com o
pessoal menos experiente, que pode estar
relutante em iniciar uma conversa ou fazer
observações críticas.
2. Estrutura de grupo. Pessoas em grupos
estruturados informalmente comunicam
PDLV HÀFD]PHQWH GR TXH DV SHVVRDV
em grupos com uma estrutura formal,
hierárquica. Em grupos hierárquicos, as
comunicações tendem a subir e descer o
ÁX[RGDKLHUDUTXLD$VSHVVRDVGRPHVPR
nível não podem conversar entre si. Esse
é um problema ainda maior em projetos
de grande porte com vários grupos de
desenvolvimento. Se as pessoas que
trabalham em diferentes subsistemas se
comunicarem apenas por meio de seus
gerentes, existe maior probabilidade de
atrasos e mal-entendidos.
3. Composição de grupo. Pessoas com
os mesmos tipos de personalidade
(discutidos na Seção 22.2) podem colidir e,
consequentemente, inibir as comunicações.
Geralmente, a comunicação também é
melhor em grupos mistos (MARSHALL
e HESLIN, 1975) do que em grupos do
mesmo sexo. Frequentemente, as mulheres
são mais orientadas a interações do que os
homens e podem atuar como controladoras
e facilitadoras das interações para o grupo.
4. Ambiente físico de trabalho. A organização do
local de trabalho é um fator importante para
facilitar ou inibir as comunicações.
5. Canais de comunicação disponíveis. Existem
400 Engenharia de Software I
muitas formas diferentes de comunicação:
face a face, mensagens de correio
electrônico, documentos formais, telefone e
tecnologias da Web 2.0 como redes sociais e
wikis. Como as equipes de projeto se tornam
cada vez mais distribuídas, com membros
de equipe trabalhando remotamente, você
precisará fazer uso de várias tecnologias para
facilitar a comunicação (SOMMERVILLE,
2011, p. 442).
Chegamos ao final da primeira seção. Na próxima,
iremos discutir o PMBOK. Vamos lá?
230%2.
O guia PMBOK foi elaborado em 1987. É intitulado The
Project Manegement Body of Knowlede. O propósito do
documento é sugerir quais processos devem ser executados
no gerenciamento de projetos, em áreas de Escopo, Tempo,
Custo, Recursos Humanos, Comunicações, Risco, Aquisições
e Qualidade. Ele propõe o desenvolvimento de um conjunto
de processos que integrem tais áreas. Segue o esquema
utilizado para implementar os processos:
44
HVSHFLÀFDo}HVGRSURMHWR
4. 0RQLWRUDPHQWR H &RQWUROH: os processos
exigidos para acompanhar, analisar e controlar
o progresso e desempenho do projeto,
LGHQWLÀFDU TXDLVTXHU iUHDV QDV TXDLV VHUmR
necessárias mudanças no plano, e iniciar as
mudanças correspondentes.
5. (QFHUUDPHQWR: os processos executados para
ÀQDOL]DUWRGDVDVDWLYLGDGHVGHWRGRVRVJUXSRV
de processos, visando encerrar formalmente o
projeto ou fase (http://www.adminconcursos.
com.br/2014/08/gerenciamento-de-projetos-
guia-pmbok.html).
Já as áreas do conhecimento são: Gerenciamento do
,QWHJUDomRGR3URMHWR*HUHQFLDPHQWRGR(VFRSRGR3URMHWR
*HUHQFLDPHQWR GR 7HPSR GR 3URMHWR *HUHQFLDPHQWR
GRV &XVWRV GR 3URMHWR *HUHQFLDPHQWR GD 4XDOLGDGH GR
3URMHWR*HUHQFLDPHQWRGRV5HFXUVRV+XPDQRVGR3URMHWR
*HUHQFLDPHQWRGDV&RPXQLFDo}HVGR3URMHWR*HUHQFLDPHQWR
GRV 5LVFRV GR 3URMHWR *HUHQFLDPHQWR GDV $TXLVLo}HV GR
3URMHWR*HUHQFLDPHQWRGDV3DUWHV,QWHUHVVDGDVGR3URMHWR
A seguir, verifiquem um mapa mental acerca de como
organizar os grupos de processos e as áreas do conhecimento.
Minhas anotações

Figura 2. Xavier, s.d.

O guia MPBOK fornece, ainda, um vocabulário básico a

ser utilizado pelos profissionais da área. Em 2016, foi lançada
a edição mais recente: a sexta. O guia PMBOK é o único
entre os padrões globais que contém um guia e um padrão. O
padrão é ligado a ISO 21500 e apresenta conceitos-chave. Já
o guia apresenta informações adicionais a respeito de como
utilizar as práticas já comprovadas.
Os grupos de processos são organizados em cinco
QR 30%2. 6mR HODV ,QLFLDomR 3ODQHMDPHQWR ([HFXomR
Monitoramento e Controle Encerramento:
1. ,QLFLDomR: os processos executados para
GHÀQLUXPQRYRSURMHWRRXXPDQRYDIDVHGH
um projeto existente através da obtenção de
autorização para iniciar o projeto ou fase.
2. 3ODQHMDPHQWR: os processos necessários
SDUD GHÀQLU R HVFRSR GR SURMHWR UHÀQDU RV
REMHWLYRVHGHÀQLUDOLQKDGHDomRQHFHVViULD
para alcançar os objetivos para os quais o
projeto foi criado.
3. ([HFXomR: os processos realizados para
H[HFXWDU R WUDEDOKR GHÀQLGR QR SODQR GH
gerenciamento do projeto para satisfazer as
 45
Figura 3. Fonte: <http://www.diegomacedo.com.br/grupos-de-processos-de-gerenciamento-de-projetos-e-suas-areas-de-conhecimento-pmbok-5a-ed/?print=pdf>. Acesso
em 8 abr. 2017.
As explanações acerca do PMBOK certamente não se
encerram aqui. No link http://www.diegomacedo.com.br/
grupos-de-processos-de-gerenciamento-de-projetos-e-suas-
areas-de-conhecimento-pmbok-5a-ed/?print=pdf há um
resumo acerca do documento que, alias, é bastante extenso.
Procurem acessá-lo!
Retomando a aula
&KHJDPRVDRȴQDOGDV«WLPDDXOD
Certamente os conhecimentos acerca da gestão de
projetos precisam ser ampliados. Procurem artigos
e livros a respeito da temática, pois disso depende a boa atuação na
gerência de projetos. Vamos recordar o que vimos até agora?
*HUrQFLDGHSURMHWRV
Aqui, discutimos a gestão de projetos e de que modo ela
está articulada entre gerenciamento de risco, gerenciamento de
pessoas e trabalho em equipe. O gerente de projetos precisa
articular a experiência com a capacidade de analisar criticamente
as situações.
401
30%2.
Aqui, discutimos o PMBOK, principal documento no
que tange ao gerenciamento de projetos, pois é responsável
por estabelecer normativas globais para a gerência, além de
conceitos-chave. Certamente o documento facilita muito o
crescimento e a inovação na área.
Vale a pena
Vale a pena acessar
Procurem conhecer mais a respeito do PMBOK,
seguem dois links para leitura:
Disponível em: <http://www.adminconcursos.com.
br/2014/08/gerenciamento-de-projetos-guia-pmbok.html
>. Acesso em 8 abr. 2017.
Disponível em: <https://lmdourado.files.wordpress.
com/2013/10/resumo-pmbok-5.pdf>. Acesso em 8 abr.
2017.
402 Engenharia de Software I

8º Aula

Gerenciamento de
FRQȴJXUD©¥RGHVRIWZDUH

Olá, pessoal!
Chegamos à nossa última aula!
Para finalizar, abordaremos o gerenciamento de
configuração de software, que diz respeito à tarefa
de identificar, organizar e controlar modificações no
software em desenvolvimento. Por meio da gerência
de configuração de software é possível maximizar a
produção e reduzir erros, sendo uma das bases para a
Engenharia de Software.
Vamos aos seus desdobramentos?
Boa aula!

Objetivos de aprendizagem

Ao término desta aula, vocês serão capazes de:

‡HQWHQGHUFRPRVHRUJDQL]DDJHUrQFLDGHFRQILJXUDomRGHVRIWZDUH
‡HQWHQGHUSURFHGLPHQWRVHDWLYLGDGHVUHODFLRQDGDVj6&0
 47
Seções de estudo
1 - Gerenciamento de configuração de software
2 - Importância do gerenciamento de configuração
3 - Atividades associadas à SCM
4 - Versão CMM
5 - Impedimentos à adoçao de GCS
6 - Gerenciamento de configuração e a abordagem de
Sommerville
1*HUHQFLDPHQWRGHFRQȴJXUD©¥RGH
software
Já vimos em nossa introdução da aula que a gerência
de software volta-se à identificação, organização e controle
de mudanças no software em construção. Ela permite que
erros sejam minimizados, e que o software produzido ofereça
sua melhor qualidade. Enquanto produto que passa por
manutenções, o software precisa de um acompanhamento pela
equipe, e a gerência de sua configuração permite que todas
as pessoas envolvidas saibam do projeto. Mesmo que haja
mudanças na equipe, a gerência de configuração de software,
doravante GCS, possibilita que elas saibam as necessidades do
projeto. Basicamente, a GCS controla as alterações e mantém
a integridade do sistema. Além disso, identifica e controla as
configurações do software, do hardware e das ferramentas
utilizadas durante o ciclo de desenvolvimento.
Com isso, uma ferramenta de GCS deve possibilitar
funcionalidades de diferentes aspectos, com controle da área
de trabalho de diversos desenvolvedores, além de integração
adequada com ferramentas de desenvolvimento e controle de
processo.
Muitas vezes, o estudo acerca da GCS é negligenciado,
contudo, isso é um erro, tendo em vista que pode acarretar em
diversos prejuízos.
2 - Importância do gerenciamento de
FRQȴJXUD©¥R
As organizações, de modo geral, possuem algum tipo de
GCS, mesmo que não reconheçam sua execução. É possível,
por exemplo, desenvolver um controle simples, utilizando um
único programador que saiba o progresso dos programas, ou,
ainda, um grande número de pessoas, com práticas rígidas e
bastante definidas de GCS.
A partir da década de 1960, com a ampliação das técnicas
de GCS, desenvolvedores começaram a aprimorar a produção,
promover redução de custos e atuar de modo a manter o
controle do progresso do projeto. Quando o software é
desenvolvido por terceiros, isso é ainda mais necessários, pois a
GCS possibilita que os desenvolvedores coordenem o trabalho
de diversas pessoas em um projeto comum, mesmo a distância.
Uma situação-problema na qual não há controle de
PRGLÀFDo}HVSRGHVHUSHUFHELGDQRH[HPSORDVHJXLU FRQÀJXUDomR
‡ 2 GHVHQYROYHGRU $ QHFHVVLWD UHDOL]DU DOWHUDo}HV QR
componente X, e o retira do repositório. Não há nenhum
403
registro que informe aos demais desenvolvedores que o
desenvolvedor A, está de posse do componente X.
‡1RGLDVHJXLQWHRGHVHQYROYHGRU$WHYHSUREOHPDVGH
saúde e não pode trabalhar.
‡1RHQWDQWRKRXYHXPSUREOHPDQRVLVWHPDFDXVDGR
pelo componente X.
‡2GHVHQYROYHGRU%UHWLUDXPDFySLDGHVVHFRPSRQHQWH
e realiza as alterações necessárias para que o sistema funcione
corretamente.
‡ 2 GHVHQYROYHGRU % GHYROYH R FRPSRQHQWH DR
repositório.
‡1RGLDVHJXLQWHRGHVHQYROYHGRU$UHWRUQDHFRQWLQXD
suas alterações no componente X (que já possui uma versão
diferente no repositório).
‡$SyVFRQFOXLURGHYROYHDRUHSRVLWyULRVREUHSRQGRDV
alterações feitas pelo desenvolvedor B.
‡4XDQGRRFRPSRQHQWHIRUQRYDPHQWHH[HFXWDGRRV
mesmos problemas que existiam antes do desenvolvedor
B alterá-lo tornarão a aparecer, e por não haver nenhum
mecanismo de controle que registre as alterações e os acessos
aos componentes, ninguém saberá como e onde o problema
foi gerado.
O exemplo citado, geralmente, é bastante comum, mas
gera transtornos ao desenvolvedor e à gerência por diversos
motivos: nem sempre as alterações são documentadas e
QRWLILFDGDVDFRPXQLFDomRUXLPLPSDFWDQDFRPSDWLELOLGDGH
GRVJUXSRVDIDOWDGHFRPSDWLELOLGDGHJHUDDWUDVRVQHFHVVLGDGH
de se fazer o mesmo trabalho duas vezes, desvio do escopo do
projeto e, certamente, a insatisfação do cliente.
Nas próximas seções, verificaremos alguns modelos de
reconhecimento internacional do que diz respeito a GCS.
3  *HUHQFLDPHQWR GH FRQȴJXUD©¥R
de software
As atividades relacionadas à GCS envolvem, basicamente,
‡3ODQHMDPHQWRGHDWLYLGDGHVGH*&6
‡,GHQWLILFDomRHDUPD]HQDPHQWRGHLWHQVGHFRQILJXUDomR
‡ &RQWUROH H DXGLWRULD GH PXGDQoDV QRV LWHQV GH
FRQILJXUDomR
‡ 2UJDQL]DomR GH LWHQV GH FRQILJXUDomR SRU PHLR GRV
FRPSRQHQWHVYHUVLRQDGRV
‡&ULDomRGHEDVHOLQHVHPPLOHVWRQHVGRSURMHWR
‡5HJLVWURHUDVWUHDPHQWRGHVROLFLWDo}HVGHPXGDQoDV
‡6XSRUWHDDOWHUDo}HVGHFRQFRUUHQWHV
‡&RPXQLFDomRGHPXGDQoDVHPLWHQVGHFRQILJXUDomR
bem como status de baselines e, ainda entre as pessoas
envolvidas.
Para realizar tais tarefas, é necessário seguir uma
ferramenta de GCS. Ela deve suprir todas as necessidades
relatadas, além das já citadas acima. Entre os itens necessários
a uma ferramenta de GCS, estão:
‡3RVVXLUXPUHSRVLWyULRVHJXURHHVFDORQiYHO
‡ &RQWURODU R YHUVLRQDPHQWR GRV LWHQV GH

‡,QWHJUDUHTXLSHVGHGHVHQYROYLPHQWR
‡3HUPLWLUDOWHUDo}HVFRQFRUUHQWHVJDUDQWLQGR
DLQWHJULGDGHGRVRIWZDUH
404 Engenharia de Software I 48
‡ 3RVVXLU PHFDQLVPRV GH FRPSDUDomR H imaturos, o desenvolvimento do software se dá por técnicos
PHVFODJHPGHLWHQVFRQFRUULGRV e gerentes, mas não necessariamente sendo seguido. Já em
‡ 5DVWUHDU VROLFLWDo}HV GH PXGDQoDV casos de softwares desenvolvidos em empresas maduras, o
bem como atividades atribuídas aos processo é constantemente documentado e melhorado. Assim,
GHVHQYROYHGRUHV o desenvolvimento dos projetos é visível porque o tempo todo
‡ &RQWURODU H DXGLWDU R DFHVVR H PXGDQoDV
o processo é controlado e mensurado.
realizadas pelas equipes em itens de
FRQÀJXUDomR
O CMM estabelece cinco processos evolutivos. Eles
‡3HUPLWLUDUHWRPDGDGRSURMHWRHPTXDOTXHU medem a maturidade do processo e o organiza, de modo que é
momento do ciclo do desenvolvimento, possível avaliar sua capacidade.
garantindo a integridade de seus itens naquele
dado momento (SOUZA, 2004, p. 26).

Na próxima seção, conheceremos a versão CMM.

4 - Versão CMM
O modelo Capability Maturity Model - Modelo de
Maturidade da Capacitação, doravante CMM, foi produzido
pelo Software Engineering Institute – SEI, nos Estados
Unidos. Sua primeira versão data de 1991. O propósito era
atentar a uma necessidade do governo federal dos EUA para
avaliar a capacitação dos fornecedores de software:

´3URFHVVRµ p XPD VHTrQFLD GH SDVVRV

realizados para atingir um determinado Figura 1. Fonte: Fonte: <http://www.batebyte.pr.gov.br/modules/conteudo/con-
objetivo, e pelo CMM, um “Processo de teudo.php?conteudo=1103>. Acesso em: 05 abr. 2017.

Software” é um conjunto de atividades, O CMM, assim, é responsável por identificar os níveis

métodos, práticas e transformações que as
pessoas usam para desenvolver e manter
o software e seus produtos associados. O
CMM tem seu foco no processo de software
por entender que a qualidade de um
VLVWHPDGHVRIWZDUHpIRUWHPHQWHLQÁXHQFLDGD
pela qualidade do processo utilizado para
desenvolvê-lo e mantê-lo. Portanto, uma
premissa do CMM é o foco no “processo”
da mesma forma que no “produto”, pois
por meio dos quais uma organização deve atuar para alcançar
a excelência nas produções de software. Por meio dos cinco
níveis estabelecidos, é possível entender a base necessária para
o próximo nível a ser construído: “Cada nível de maturidade é
composto de algumas “áreas-chave de processo” (exceção feita
ao Nível 1) consideradas como requisitos para se atingir um
nível de maturidade. Portanto, para se atingir um determinado
nível de maturidade, as áreas-chave de processo daquele nível
(e dos níveis inferiores) devem estar atendidas e o processo
enfocando apenas o “produto” se perde o
conhecimento de como produzi-lo melhor
por não se ter desenhado, conhecido e,
constantemente, melhorado o processo
utilizado para desenvolver o produto.
A “capacidade do processo de software”
descreve o conjunto de resultados esperados
que possa ser atingido quando se segue
o processo de software estabelecido. Já
a “maturidade do processo de software”
p R TXDQWR XP SURFHVVR HVSHFtÀFR p
H[SOLFLWDPHQWH GHÀQLGR JHUHQFLDGR PHGLGR
controlado e efetivo. Maturidade implica num
potencial de crescimento da capacidade e
indica tanto a riqueza do processo de software
de uma organização, quanto a consistência
na qual o processo é aplicado nos projetos
de toda a organização (SILVA, OLIVEIRA,
2003).
Entende-se que a evolução das empresas de software
faz com que os processos também evoluam. Assim, o foco
do CMM é fazer com que as pessoas que participem do
processo de desenvolvimento de software sejam capazes
de estar integradas a essa evolução. Em casos de processos
LQVWLWXFLRQDOL]DGRµ6,/9$2/,9(,5$
5 - Impedimentos à adoçao de GCS
Apesar de a GCS ser uma área fundamental diversas
vezes, há questões que dificultam sua implementação. Entre
os motivos, estão: o custo: por exigir diversos gastos, muitas
YH]HVD*&6pUHOHJDGDDFXOWXUDGDHPSUHVDDGLILFXOGDGHGH
algumas empresas em enfrentar mudanças faz com que se evite
D*&6RDXPHQWRQDIRUPDOLGDGHHQDEXURFUDFLDSRUVHUXPD
área que exige procedimentos detalhados, é considerada, por
PXLWRV H[WUHPDPHQWH EXURFUiWLFD FRQKHFLPHQWR VXSHUILFLDO
sobre a GCS: devido à dificuldade de alguns em aprofundar os
conhecimentos, é comum que seja uma área banalizada.
Pensando de modo geral, a prática de GCS é bastante
diversificada ao redor do mundo. Muitos países, como EUA,
por exemplo, grandes compradores de software, as práticas
de GCS são mais maduras, por exigir dos fornecedores regras
e normas de conduta. Já no Brasil, é uma área em ascensão,
motivada, principalmente, pela competitividade do mercado e
da busca de certificados de qualidade, como ISSO 9000, CMM,
SPICE, entre outros.
 49
6*HUHQFLDPHQWRGHFRQȴJXUD©¥RH
a abordagem de Sommerville
Companheiro nosso ao longo das aulas, Sommerville
(2011) trata, também, do gerenciamento de configuração. Ele
estabelece, para tanto, quatro discussões acerca do tema. Elas
serão discutidas a seguir:
6.1 - Gerenciamento de mudanças
O objetivo é garantir que o sistema evolua por meio da
prioridade às mudanças urgentes e efetivas. Está relacionado
com a análise de custos e de benefícios das mudanças propostas:
Existem muitas variantes desse processo em
XVRPDVSDUDVHUHPHÀFD]HVRVSURFHVVRVGH
gerenciamento de mudanças sempre devem ter
XPPHLRGHYHULÀFDomRFXVWHLRHDSURYDomRGH
mudanças. Esse processo deve entrar em vigor
quando o software é desenvolvido para entrega
aos clientes ou para implantação em uma
organização. O processo de gerenciamento
GH PXGDQoDV LQLFLDVH TXDQGR XP ¶FOLHQWH·
preenche e envia uma solicitação de mudança
(CR, do inglês change request) que descreve
a mudança requerida para o sistema. Pode
tratar-se de um relatório de bug, em que são
descritos os sintomas de um bug, ou uma
solicitação para adicionar funcionalidade extra
ao sistema. Algumas empresas tratam relatórios
de bugs e novos requisitos separadamente,
mas, em princípio, ambas são solicitações de
mudança. As solicitações de mudança podem
ser apresentadas por meio de um formulário de
solicitação de alteração (CRF, do inglês change
405
6.2 - Gerenciamento de versões
O gerenciamento de versões é responsável pelo processo
de acompanhamento de diferentes versões do software ou de
itens de configuração, bem como sobre os sistemas em que
tais componentes são usados. Ainda diz respeito à garantia
de que as mudanças realizadas não irão interferir uma nas
outras. Pode-se pensar em gerenciamento de versões como o
processo de se gerenciar codelines e baselines.
Essencialmente, uma codeline é uma sequência
de versões de código-fonte com versões
posteriores na sequência derivadas de versões
anteriores. Normalmente, as codelines são
aplicadas para componentes de sistemas,
havendo, assim, diferentes versões de cada
FRPSRQHQWH 8PD EDVHOLQH p XPD GHÀQLomR
GHXPVLVWHPDHVSHFtÀFR$EDVHOLQHSRUWDQWR
HVSHFLÀFD D YHUVmR GH FDGD FRPSRQHQWH
LQFOXtGDQRVLVWHPDPDLVXPDHVSHFLÀFDomRGDV
ELEOLRWHFDV XVDGDV DUTXLYRV GH FRQÀJXUDomR
etc. (SOMMERVILLE, 2011, p. 478).
O gerenciamento de versões exige ferramentas de
gerenciamento de versões. Estas, por sua vez, identificam,
armazenam e controlam o acesso a diferentes versões de
componentes.
6.3 - Gerenciamento de sistemas
O gerenciamento de sistemas diz respeito ao processo
de criação de um sistema completo e executável por meio da
construção e da ligação dos componentes do sistema: “As
ferramentas de construção de sistemas e as ferramentas de
gerenciamento de versões devem se comunicar na medida em
UHTXHVW IRUP (X XVR R WHUPR ¶FOLHQWH· SDUD
incluir qualquer stakeholder que não seja parte
da equipe de desenvolvimento, para que as
mudanças possam ser sugeridas, por exemplo,
pelo departamento de marketing de uma
empresa (SOMMERVILLE, 2011, p. 478).
A figura abaixo estabelece um processo de gerenciamento
de mudanças:
Figura 2. Sommerville, 2011, p. 478.
que o processo de construção envolve a realização de check-out
de versões de componentes do repositório pelo sistema de
gerenciamento de versões” (SOMMERVILLE, 2011). Assim,
a descrição de configuração que é utilizada para identificar
uma baseline também é usada na ferramenta de construção de
sistemas. Há três plataformas de sistemas envolvidas:
1. O sistema de desenvolvimento inclui
ferramentas de desenvolvimento como
compiladores, editores de código-fonte etc.
Os desenvolvedores realizam o check-out
de código do sistema de gerenciamento de
versões em um espaço de trabalho privado
antes de fazer as mudanças no sistema. Eles
podem desejar construir uma versão de
um sistema para testes em seu ambiente de
desenvolvimento antes da aprovação das
PXGDQoDV TXH À]HUDP SDUD R VLVWHPD GH
gerenciamento de versões. Isso envolve o uso
de ferramentas locais de construção que usam
versões de check-out de componentes no
espaço de trabalho privado.
2. O servidor de construção é usado para
FRQVWUXLU YHUV}HV GHÀQLWLYDV H WDPEpP
executáveis do sistema. Dessa forma, interage
estreitamente com o sistema do gerenciamento
de versões. Os desenvolvedores realizam
o check-in no sistema de gerenciamento
406 Engenharia de Software I
de versões antes de este ser construído. A
construção de sistema pode contar com
bibliotecas externas que não estão incluídas
no sistema de gerenciamento de versão.
3. O ambiente-alvo é a plataforma em
que o sistema é executado. Pode ser o
mesmo tipo de computador usado para o
desenvolvimento e a construção de sistemas.
No entanto, para os sistemas de tempo real
e embutidos, o ambiente-alvo é, geralmente,
menor e mais simples do que o ambiente de
desenvolvimento (por exemplo, um telefone
celular). Para os sistemas de grande porte,
o ambiente-alvo pode incluir bancos de
dados e outros sistemas COTS que não
podem ser instalados em máquinas de
desenvolvimento. Em ambos os casos, não
é possível construir e testar o sistema no
computador desenvolvido ou no servidor
de construção (SOMMERVILLE, 2011).
Assim, sistema de desenvolvimento e o servidor de
construção podem interagir com o sistema de gerenciamento
de versões, que, por sua vez, pode ser hospedado em um
servidor de construção e em um servidor dedicado. Em
sistemas embutidos, é possível instalar o ambiente de
simulação no mesmo ambiente de desenvolvimento de testes.
6.4 - Gerenciamento de releases
Por fim, o gerenciamento de releases, abordado por
Sommerville (2011), diz respeito à versão de um sistema de
software que é distribuída aos clientes. Há, nesse sentido, dois
tipos de releases: os releases principais, que fornecem nova
funcionalidade e os releases menores, que corrigem problemas
e reparam bugs a partir de erros relatados pelos clientes. Já
para softwares customizados, os releases se dão por meio de um
gerenciamento complexo. Muitas vezes, os releases especiais
do sistema precisam ser produzidos individualmente, para
cada cliente. Assim, uma empresa de software, ao vender um
produto, pode ter que gerenciar diversos releases ao mesmo
tempo.
Nessa perspectiva, os sistemas e processos de
gerenciamento devem ser projetados para fornecer
informações sobre cada release. Portanto, cada um deve ser
documentado de modo individual.
Retomando a aula
&KHJDPRVDRȴQDOGD¼OWLPDDXOD
Vamos recordar?
*HUHQFLDPHQWRGHFRQILJXUDomRGHVRIWZDUH
Já vimos em nossa introdução da aula que a gerência
de software volta-se à identificação, organização e controle
de mudanças no software em construção. Ela permite que
50
erros sejam minimizados, e que o software produzido ofereça
sua melhor qualidade.
,PSRUWkQFLDGRJHUHQFLDPHQWRGHFRQILJXUDomR
Vimos que as organizações, de modo geral, possuem
algum tipo de GCS, mesmo que não reconheçam sua execução.
É possível, por exemplo, desenvolver um controle simples,
utilizando um único programador que saiba o progresso dos
programas, ou, ainda, um grande número de pessoas, com
práticas rígidas e bastante definidas de GCS.
$WLYLGDGHVDVVRFLDGDVj6&0
Verificamos quais são as atividades a serem desenvolvidas
na SCM.
9HUVmR&00
O modelo Capability Maturity Model - Modelo de
Maturidade da Capacitação, doravante CMM, foi produzido
pelo Software Engineering Institute – SEI, nos Estados
Unidos. Sua primeira versão data de 1991. O propósito era
atentar a uma necessidade do governo federal dos EUA para
avaliar a capacitação dos fornecedores de software.
,PSHGLPHQWRVjDGRoDRGH*&6
Entendemos que, apesar de a GCS ser uma área
fundamental, diversas vezes há questões que dificultam
sua implementação. Entre os motivos, estão: o custo: por
H[LJLU GLYHUVRV JDVWRV PXLWDV YH]HV D *&6 p UHOHJDGD D
cultura da empresa: a dificuldade de algumas empresas em
HQIUHQWDUPXGDQoDVID]FRPTXHVHHYLWHD*&6RDXPHQWR
na formalidade e na burocracia: por ser uma área que exige
procedimentos detalhados, é considerada, por muitos,
H[WUHPDPHQWH EXURFUiWLFD FRQKHFLPHQWR VXSHUILFLDO VREUH
a GCS: devido à dificuldade de alguns em aprofundar os
conhecimentos, é comum que seja uma área banalizada.
*HUHQFLDPHQWRGHFRQILJXUDomRHDDERUGDJHP
GH6RPPHUYLOOH
Conhecemos o gerenciamento de configuração na
perspectiva de Sommerville.
Vale a pena
Vale a pena acessar
Vejam o link a seguir para conhecerem mais sobre
o CMM: <http://www.batebyte.pr.gov.br/modules/
conteudo/conteudo.php?conteudo=1103 >.