Engenharia de Software

Direitos: Esta obra foi disponibilizada sob uma Licena Creative Commons Atribuio Uso no-comercial
3.0 Brasil.
Direitos de distribuio e publicao: CAPES/MEC, conforme Pargrafo nico, do Artigo 5, da
Resoluo CD/FNDE n 24 de 04 de Junho de 2008.
Universidade Federal de Juiz de Fora

Reitor: Henrique Duque de Miranda Chaves Filho
Instituto de Cincias Exatas
Diretor: Rubens de Oliveira
Departamento de Cincia da Computao
Chefe: Custdio Gouvea Lopes da Motta
Curso de Licenciatura em Computao
Coordenao: Fernanda Claudia Alves Campos
Organizao
Jos Maria Nazar David
Comisso Editorial
Eduardo Barrre
Fernanda Claudia Alves Campos
Reviso Gramatical
Hortncia Cezar Pinto
Editorao Eletrnica
Eduardo Barrre
Jos Maria Nazar David.

Fundamentos de Engenharia de Sofware / Jos Maria Nazar
David 2013.
72 f. : il.
Material Didtico Curso de Licenciatura em Computao
da Universidade Federal de Juiz de Fora, Juiz de Fora, 2012.
1. Educao Distncia. 2. Engenharia de Software. 3.
Teste de Software. 4. Qualidade de Software. I. Ttulo.
Apresentao
Este material foi desenvolvido para apoiar a disciplina de
Fundamentos de Engenharia de Software (carga horria: 30
horas) do curso de Licenciatura em Computao da Universidade
Federal de Juiz de Fora. Para a conduo desta disciplina partese do pressuposto de que o aluno j cursou a disciplina de
Modelagem de Sistemas, pois alguns conceitos abordados
necessitam do entendimento da importncia da atividade de
modelagem no processo de desenvolvimento de software.
O objetivo desta disciplina fornecer uma viso geral do
processo de desenvolvimento de software, bem como discutir a
importncia das organizaes adotarem a abordagem mais
adequada ao seu contexto. No se busca com isso, esgotar a
discusso sobre as diferentes etapas do processo de
desenvolvimento e os artefatos gerados nas atividades. Em cada
captulo, as atividades realizadas para o desenvolvimento dos
artefatos so discutidas, bem como exemplos prticos so
oferecidos para ilustrar a criao e a sua importncia para o
software.
Sobre o autor:
Jos Maria N. David, professor da disciplina de Engenharia de
Software com mais de vinte anos de experincia na rea de
desenvolvimento de software, inicialmente como Analista de
Sistemas e, posteriormente como professor. Recentemente tem
se dedicado pesquisa dos diferentes aspectos envolvidos no
Desenvolvimento Distribudo de Software. mestre e doutor em
Engenharia de Sistemas e Computao pela Universidade
Federal do Rio de Janeiro (COPPE/UFRJ) e professor do
Departamento de Cincia da Computao da Universidade
Federal de Juiz de Fora (UFJF).
Iconografia
Conhea os diversos cones utilizados nos materiais didticos desenvolvidos pelos
professores e tutores do curso de Licenciatura em Computao DCC/UFJF:
Pesquise.
Exerccios.
Material complementar
(texto, vdeo, etc.)
disponvel na Internet.
Leitura Complementar.
Comentrio do Autor.
Tome nota.
Concluso ou sntese
de contedo.
Fique atento.
Sumrio
1.
Introduo................................................................................................................................7
2.
Processos de Software ...........................................................................................................10
3.
4.
5.
6.
7.
2.1
Introduo ......................................................................................................................10
2.2
Modelo em Cascata ........................................................................................................11
2.3
O Processo Unificado (RUP)............................................................................................11
2.4
O Modelo Evolucionrio .................................................................................................14
Engenharia de Requisitos de Software ..................................................................................17

3.1
Introduo ......................................................................................................................17
3.2
O Processo de Engenharia de Requisitos .......................................................................19
3.3
Gerenciamento de requisitos .........................................................................................24
Projeto de Sistemas ...............................................................................................................27

4.1
Introduo ......................................................................................................................27
4.2
Alguns conceitos de projeto de software.......................................................................30
Implementao ......................................................................................................................35
5.1
Introduo ......................................................................................................................35
5.2
Reutilizao de software ................................................................................................36
5.3
Gerenciamento de Configurao....................................................................................38
Teste de Software ..................................................................................................................44

6.1
Introduo ......................................................................................................................44
6.2
Verificao e Validao...................................................................................................45
6.3
Testes Unitrios ..............................................................................................................46
6.4
Testes de Sistema ...........................................................................................................47
Manuteno e Evoluo de Software ....................................................................................49

7.1
Introduo ......................................................................................................................49
7.2
Transformao de Arquitetura .......................................................................................51
7.3
Reengenharia..................................................................................................................51
8.
9.
Gerncia da Qualidade...........................................................................................................53
8.1
Introduo ......................................................................................................................53
8.2
Garantia e Padres de Qualidade...................................................................................56
8.3
Planejamento de Qualidade ...........................................................................................57
8.4
Controle de Qualidade....................................................................................................58
8.5
Melhoria de Processos ...................................................................................................58
Planejamento e Gerenciamento de Software .......................................................................64

9.1
Introduo ......................................................................................................................64
9.2
Estimativa de preo do software....................................................................................65
9.3
Plano de projeto .............................................................................................................67
9.4
Programao de projeto.................................................................................................70
Referncias Bibliogrficas..........................................................................................................72
EADDCC032 Fundamentos de Engenharia de Software
1. Introduo
Antes de iniciarmos a apresentao dos temas associados Engenharia de
Software cabe definirmos o que podemos considerar como software, bem como o seu
significado. Muitas vezes considera-se que esse termo se refere apenas aos
programas de computadores e s suas instrues. Entretanto, ele se relaciona a
qualquer artefato gerado no processo de desenvolvimento de programas de
computadores que, ao serem executados, apresentaro as funcionalidades desejadas
pelos usurios.
Por que devemos ter cuidado ao desenvolvermos software? A evoluo da
Internet e a crescente complexidade das formas de interao tm demandado sistemas
com funcionalidades tambm complexas. Tais sistemas tm sido constantes nas
nossas vidas gerando uma dependncia em diferentes momentos. Por exemplo, nos
negcios, nas cincias, e no dia a dia de nossas vidas. Hoje podemos encontrar
software nos carros, nos eletrodomsticos, nos telefones, e outros. Mais ainda: a
quantidade de software que foi desenvolvido no passado e que necessitam de
modificaes para evolurem e se adequarem a um novo contexto tecnolgico e de
negcios.
Alm disso, muitos sistemas legados continuam em funcionamento demandando
pesquisas em relao s formas de evoluo, adaptao s novas tecnologias e
aperfeioamento em termos de artefatos existentes. Essas pesquisas tm investigado
solues para facilitar a manuteno buscando-se melhorias em termos de qualidade,
produtividade e custo.
Mas, por que ainda encontramos projetos que consomem um tempo elevado para
realizar entregas de produtos? Por que os custos ainda so altos em relao aos
produtos que so entregues? Por que ainda encontramos erros no produto final e o
custo de manuteno to alto? Um dos motivos associados a essas perguntas est
relacionado ausncia de um processo de desenvolvimento e da adoo de boas
prticas de projeto de software. As outras respostas a essas perguntas sero
apresentadas ao longo dos prximos captulos, outras sero deixadas como exerccios
para discusso ou pesquisa.
7
(1) Pesquise, pelo menos, dois motivos pelos quais ainda se

produz software com defeito.
(2) Pesquise pelo menos dois motivos que podem elevar o custo
de evoluo de um software.
Esta apostila est organizada da seguinte forma: o prximo captulo apresenta

alguns processos da Engenharia de Software. Eles so responsveis pela organizao
das sequncias de atividades que apoiaro a construo dos sistemas; no Captulo 3,
os aspectos relacionados s necessidades das pessoas envolvidas neste projeto so
abordados, desde o levantamento e anlise at a especificao e construo de
documentos que descrevem essas necessidades. O Captulo 4 discute os diferentes
conceitos envolvidos no projeto (design) de software, bem como os artefatos que
podem ser construdos para representar as diferentes caractersticas que um projeto
desta natureza requer. J o prximo captulo parte dos conceitos e artefatos
previamente apresentados, e trata dos aspectos para construo de um cdigo
executvel a implementao do software. O Captulo 6 apresenta os conceitos
envolvidos no teste de software com o intuito de oferecer artefatos que funcionem
corretamente, mas tambm que atendam s necessidades das diferentes pessoas
interessadas no perfeito funcionamento do software (stakeholders). O Captulo 7
apresenta os conceitos envolvidos na manuteno e evoluo do software. Discute
tambm a necessidade de termos um processo para gerenciar mudanas nos artefatos
produzidos em cada etapa do desenvolvimento de software. O Captulo 8 apresenta os
conceitos bsicos sobre qualidade de software. Apresenta tambm os principais
atributos de qualidade e a influncia desses atributos no processo de desenvolvimento
e manuteno de software. Por fim, o Captulo 9 trata de questes do planejamento de
do gerenciamento de projetos de software.
Exerccios
(1) O que software?
(2) Em relao ao processo de desenvolvimento de software, podemos
afirmar que, ao terminarmos de escrever um programa o trabalho
de desenvolvimento terminou?
(3) Em relao aos artefatos entregues ao cliente, podemos afirmar
que o nico artefato entregue em um projeto bem sucedido o
cdigo executvel?
(4) Por que devemos construir software sem defeitos?
(5) Apesar dos avanos da Engenharia de Software em relao s
metodologias e prticas de desenvolvimento de sistemas, por que
no conseguimos garantir um sistema livre de erros antes de
entreg-lo ao cliente?
(6) De uma forma geral, por que os custos de manuteno de sistemas
ainda so altos?
2. Processos de Software
Este captulo tem como objetivo discutir o conceito de processos de software,

bem como apresentar alguns modelos de processo que so frequentemente
utilizados no desenvolvimento de software. Ao trmino deste captulo o leitor
ser capaz de identificar as vantagens e desvantagens da utilizao de diferentes
processos com o intuito de aplic-los no desenvolvimento de produtos
2.1
Introduo
Processos podem ser caracterizados como um procedimento ou uma poltica para

a construo de software. Artefatos so construdos ao longo do processo de
desenvolvimento de software de diferentes formas, considerando-se as atividades, os
recursos e os diferentes papeis envolvidos. Diferentes processos tm sido propostos na
literatura de Engenharia de Software com diferentes objetivos considerando-se os
contextos nos quais a organizao est envolvida. Mas, o que caracteriza um processo
como o mais adequado? Ao mencionarmos o contexto, como o fator que determina a
escolha de um processo especfico de desenvolvimento, nos referimos aos seguintes
elementos, por exemplo: maturidade da organizao para desenvolver software,
natureza do produto que ser desenvolvido, bem como ao domnio no qual a aplicao
ser utilizada.
Um processo de desenvolvimento de software engloba algumas prticas que
possuem como objetivos gerar artefatos com o foco na qualidade e oferecer
mecanismos para que as atividades possam ser continuamente melhoradas. A escolha
de um processo ir definir a qualidade dos artefatos gerados nas diferentes etapas do
desenvolvimento
Um processo de desenvolvimento, portanto, especifica os artefatos que sero
gerados, os papeis e os recursos para o desenvolvimento das atividades. Alm disso,
oferece uma sequncia de atividades cujo objetivo maior orientar as pessoas
envolvidas em relao aos produtos e responsabilidades. Atravs do conhecimento
associado ao processo de desenvolvimento de software os artefatos, bem como as
atividades, podero ser acompanhados, medidos e avaliados. Como resultado, busca10
se uma previsibilidade dos eventos ocorridos, e uma melhoria contnua das atividades
ali desempenhadas.
2.2
Modelo em Cascata
O ciclo de vida em cascata parte do princpio de que as etapas de especificao

de requisitos, projeto, implementao, teste e verificao so realizadas uma aps a
outra. Ou seja, para realizar a etapa de projeto necessrio que os artefatos
relevantes que foram gerados na etapa anterior estejam disponveis. Desta forma, os
artefatos de projeto so gerados a partir da finalizao dos requisitos. Entretanto,
muitas vezes essas etapas se sobrepem e as informaes geradas nas etapas so
trocadas, pois nem todos os artefatos so gerados sem defeitos.
Uma das consequncias da utilizao deste modelo no desenvolvimento de
software o retrabalho decorrente da ausncia de informao ou de equvocos na
compreenso dos requisitos. Portanto, este modelo frequentemente se mostra
adequado no desenvolvimento de sistemas em que os requisitos so conhecidos na
sua totalidade, so estveis e o domnio bem conhecido. Como consequncia deste
fato, todos os artefatos podem ser verificados e revises podem ser realizadas em
cada etapa. Mais ainda, possvel ter uma viso geral e mais abrangente dos
requisitos que sero efetivamente implementados.
Mas, nem sempre os requisitos so efetivamente conhecidos e so estveis
exigindo um retrabalho ao retornar s etapas anteriores e modificando cada artefato
previamente construdo. Consequentemente, sistemas mal estruturados podem ser
construdos. Mais ainda, muitas vezes o tempo para entregar a verso final pode ser
extenso.
2.3
O Processo Unificado (RUP)
O objetivo deste modelo de processo foi unificar as abordagens previamente

existentes evidenciando as seguintes dimenses: as fases e os fluxos de trabalho. As
11
fases correspondem ao tempo. o aspecto que se relaciona dinmica do processo.

Neste sentido, cada fase comporta as iteraes que iro produzir os artefatos
programados para cada ocasio. J os fluxos de trabalho correspondem s disciplinas
do desenvolvimento de software. So elas: modelagem de negcios, requisitos, anlise
e projeto (design), implementao, teste, implantao, gerncia de configurao e
mudana, gerenciamento de projeto e ambiente. Considerando-se as duas dimenses,
muitas vezes o processo unificado mencionado na literatura como um modelo de
processo hbrido. Percebemos uma sequncia de atividades prxima do modelo em
cascata previamente discutido.
O RUP um processo iterativo no qual as disciplinas so apresentadas em cada
etapa ao longo da dimenso do tempo. Portanto, podemos supor que ele oferece as
vantagens dos modelos que surgiram anteriormente, e propem as mesmas disciplinas
do RUP. Nessa dimenso, o modelo iterativo sugere as seguintes fases do ciclo de
vida do software: iniciao, elaborao, construo e transio.
Organizao ao longo do contedo
Organizao ao longo do tempo
(Fonte: http://www.wthreex.com/rup/process/ovu_proc.htm)
Figura 2.1: Fases e disciplinas do RUP

Na fase de Iniciao o objetivo realizar uma anlise econmica do sistema
partindo-se do conhecimento do negcio no qual o projeto est inserido. Como
resultado, busca-se uma anlise da viabilidade do projeto. Para tanto, estimativas
iniciais so realizadas, bem como riscos so analisados e escopos so definidos.
12
Na fase de Elaborao, alguns objetivos so bem definidos, tais como: os

requisitos para o sistema so especificados, bem como uma arquitetura preliminar
definida. Nada impede que nesta etapa um prottipo seja desenvolvido e apresentado
com o intuito de verificar a viabilidade do projeto, por exemplo. Mais ainda, riscos so
continuamente aprimorados buscando-se aqueles mais significativos para o atual
estgio em que o projeto se encontra.
Na fase de Construo o foco est nos aspectos de implementao. Espera-se
nesta fase que os modelos estejam finalizados e revistos, bem como a arquitetura
esteja adequada aos incrementos que foram realizados nos artefatos. Mais ainda, os
riscos so monitorados e medidas so tomadas para mitig-los.
Na fase de Transio a maior parte dos artefatos j foi desenvolvida e
parcialmente verificada. O sistema como um todo se encontra pronto para ser
entregue, bastando uma avaliao da verso final por um grupo de usurios. Portanto,
testes ainda so necessrios e defeitos ainda podero ser retirados do produto. Mais
ainda, nada impede que sugestes e pedidos de melhorias possam ser realizados.
Modificaes so realizadas e o produto final entregue.
Atravs do desenvolvimento iterativo elementos so integrados de forma
incremental, pois os requisitos so passveis de mudanas. Com isso, as mudanas
nos requisitos so consideradas durante todo o processo. Essas mudanas podem
acarretar revises nos artefatos j planejados e projetados, bem como testes que
podero identificar erros mais cedo. Como resultado, entregas so realizadas mais
cedo, e fundamental que os riscos no projeto sejam tratados continuamente.
Entretanto, ao considerarmos a possibilidade de modificaes em requisitos exige
um gerenciamento no processo de mudanas no sentido de garantir que os artefatos
se relacionam. Mais ainda, novos requisitos podem exigir mudanas arquiteturais que
reduzam a qualidade do produto, bem como podem gerar sistemas mal estruturados.
RUP trata das seguintes prticas: (i) o software desenvolvido interativamente.
Artefatos so construdos atravs de vrias iteraes das quais participam os
diferentes interessados; (ii) durante as diferentes etapas e iteraes requistos so
gerenciados considerando-se que eles podem evoluir conforme os interessados
comeam a visualizar as funcionalidades e as entregas dos artefatos; (iii) arquiteturas
devem ser construdas tomando como base os componentes de software. Estes
13
componentes so responsveis, em parte, pela facilidade de evoluo, pela qualidade

e pelo custo reduzido dos artefatos que so produzidos em cada etapa; (iv) artefatos
so modelados visualmente. Casos de uso, por exemplo, apoiam significativamente o
desenvolvimento a partir da abordagem do RUP. Fornecem um suporte a partir dos
diagramas e das descries do comportamento das funcionalidades. Esta modelagem
pode ser realizada, por exemplo, com o suporte de uma ferramenta; (v) a qualidade do
software continuamente verificada considerando-se os padres de produto e de
processo estabelecidos; e, por fim (vi) mudanas so controladas no sentido de
verificar, por exemplo, a sua viabilidade em termos dos recursos e da tecnologia
necessrios, e dos custos envolvidos.
Krutchen, P., 2003, The Rational Unifies Process An

Introduction, Addison-Wesley.
um livro que oferece uma viso geral do RUP, e apresenta os
conceitos principais para uma leitura introdutria.
2.4
O Modelo Evolucionrio
Neste modelo os artefatos so produzidos gradativamente, conforme o

conhecimento sobre o domnio de aplicao do sistema adquirido. Para tanto duas
abordagens so utilizadas para este modelo. So elas:
(I) Desenvolvimento exploratrio: neste tipo o sistema evolui de acordo com o
conhecimento de novas funcionalidades, artefatos so produzidos em constante
interao com o cliente.
(II) Prottipos descartveis: esta tcnica apoia a identificao das necessidades dos
usurios a partir da construo de prottipos que sero apresentados aos
stakeholders com o objetivo de verificar a real necessidade dos requisitos, bem como
a sua consistncia.
14
Entretanto,
alguns
problemas
surgem
ao
utilizarmos
este
modelo
de
desenvolvimento. O primeiro deles diz respeito visibilidade do processo. Sem um

processo perfeitamente visvel, as atividades e as suas dependncias no so
apresentadas aos desenvolvedores no sentido de gerenci-las. Outro problema est
relacionado s mudanas frequentes que este sistema est sujeito. Tais mudanas
esto associadas aos artefatos gerados nas etapas de desenvolvimento. Como
resultado, sistemas mal estruturados podem ser construdos, bem como a associao
entre os diferentes artefatos pode ser mais facilmente perdida. Para apoiar essas
atividades, um gerenciamento das mudanas mais rigoroso pode ser necessrio
exigindo o suporte de ferramentas especficas para o controle das modificaes. Este
assunto ser mais explorado nos prximos captulos.
A utilizao deste modelo pode ser interessante, portanto, para sistemas de
pequeno porte, com um nmero menor de funcionalidades. Pois, gerenciar as
mudanas de um nmero significativo de requisitos pode significar o fracasso e a
descontinuidade do projeto. Em algumas situaes, nas quais um nmero maior de
funcionalidades exigido, um modelo de processo que associe o modelo em cascata e
o modelo evolucionrio pode ser utilizado. Ou seja, em situaes nas quais os
requisitos so conhecidos e estveis pode ser utilizado o modelo em cascata. Em
outros momentos, nos quais os requisitos no so perfeitamente conhecidos, bem
como no so estveis, pod ser empregado o modelo evolucionrio. Este processo
frequentemente denominado de misto.
Exerccios
(1) O que um processo de desenvolvimento de software?
(2) Justifique a necessidade de um processo de desenvolvimento de
software.
(3) Considere um determinado sistema cujos requisitos no foram,
previamente, bem definidos e no eram estveis. Ou seja, modificaes

frequentes nos mesmos ocorriam ao longo das atividades de
desenvolvimento. Para tanto, foi utilizado apenas o modelo em cascata.
Quais as implicaes da utilizao desse modelo para o desenvolvimento
do sistema?
15

(4) Considere os seguintes conceitos do RUP: fases, disciplinas, artefatos, e
papeis. De que forma eles se relacionam em um processo de

desenvolvimento de software?
(5) Em algumas situaes a abordagem evolucionria para o
desenvolvimento de software apresenta algumas vantagens em relao
abordagem em cascata. Em outras situaes, a utilizao do modelo
em cascata pode ser mais eficaz no sentido de construir sistemas que
atendam s necessidades dos usurios. Comente esta afirmao e
apresente pelo menos uma vantagem e uma desvantagem da utilizao
da abordagem evolucionria em relao abordagem em cascata.
Utilize um exemplo para ilustrar a sua resposta.
(6) Considere que preciso desenvolver um sistema cujos objetivos gerais
so inicialmente conhecidos; porm, no foram adequadamente
identificados todos os requisitos (entrada, processamento e sada). Qual
o modelo de processo para o desenvolvimento seria mais adequado?
Quais os problemas frequentemente encontrados quando este modelo
aplicado? Justifique a sua resposta utilizando exemplos
16
3. Engenharia de Requisitos de Software
Este captulo tem como objetivo apresentar o processo de Engenharia de

Requisitos e a sua relao com as diferentes etapas do processo de
desenvolvimento de software. Adicionalmente, cada etapa do processo e os
produtos de software gerados em cada uma delas sero discutidos. Ao final do
captulo, o leitor deve ser capaz no apenas de compreender a importncia da
Engenharia de Requisitos no processo de desenvolvimento de software, mas de
especificar um sistema.
3.1
Introduo
Sistemas so desenvolvidos de acordo com as necessidades dos usurios e das

organizaes. Essas necessidades podem estar relacionadas tanto s funcionalidades
quanto s restries impostas ao funcionamento do sistema. Por exemplo: (i) o sistema
deve permitir que o usurio imprima um relatrio dos alunos matriculados at um
determinado dia; e (ii) o tempo mnimo para gerar este relatrio deve ser de 2 minutos.
Entretanto, para que essas necessidades sejam devidamente descritas cabe ao
desenvolvedor compreender o processo de negcio que ser automatizado, bem como
o contexto no qual ele est inserido. Por exemplo, o local em que o sistema ser
frequentemente executado, os recursos (hardware e software) disponveis, entre
outros.
Percebam que essas necessidades no dizem respeito descrio da forma pela
qual as funcionalidades sero executadas. Esta descrio dever ser realizada
posteriormente, a partir do momento em que o desenvolvedor compreendeu o conjunto
de tarefas que sero realizadas, o seu impacto nos negcios da organizao, bem
como o relacionamento dos diferentes processos de negcio da organizao. Em
relao a este ltimo, podemos mencionar que no basta, por exemplo, entender a
forma pela qual a matrcula de um aluno ser automatizada pelo sistema, mas tambm
os diferentes relacionamentos deste processo com aqueles que sero executados pela
17
rea financeira da escola. Mais ainda: necessrio identificar os usurios, bem como
compreender a(s) forma(s) pela(s) qual(is) eles iro interagir com o sistema.
As necessidades so descritas atravs dos requisitos funcionais e no funcionais
do sistema. Os requisitos funcionais esto relacionados s funcionalidades executadas
pelo sistema, o seu comportamento diante das entradas e sadas dos dados. J os
requisitos no funcionais dizem respeito s restries para que essas funcionalidades
sejam executadas dentro dos padres de qualidade esperados. Por exemplo:
segurana, confiabilidade, portabilidade, tempo de entrega do produto, privacidade,
entre outros. Considere o sistema escolar que apresenta como requisito funcional
permitir que o aluno realize o pagamento da matrcula logo aps a escolha das
disciplinas. Entretanto, para que esta funcionalidade seja executada nos padres de
qualidade definidos pela escola, este pagamento deve oferecer uma segurana e
confiabilidade satisfatrias para a efetivao da matrcula.
Percebemos, portanto, que existe um relacionamento entre os requisitos
funcionais e no funcionais. Eles interagem de tal forma que um tipo pode modificar o
outro. Por exemplo, se a organizao no for capaz de fornecer um nvel de segurana
e confiabilidade satisfatrio para o aluno, o requisito funcional que trata do pagamento
da matrcula no poder ser especificado.
Requisitos
Funcionais
Modifica
Requisitos no
Funcionais
Figura 3.1: Relacionamento entre requisitos

Mas, se os requisitos no funcionais esto relacionados aos atributos de
qualidade do sistema, no possvel colocarmos todos os atributos no mesmo patamar
para que eles sejam atendidos? Por exemplo, o usurio necessita de portabilidade,
escalabilidade, confiabilidade, segurana, facilidade de uso e desempenho, todos no
mesmo patamar. No, nem sempre eles podem ser atendidos no mesmo nvel e
necessitam, portanto que se estabelea uma prioridade para que eles sejam atendidos.
18
No processo de Engenharia de Requisitos diferentes artefatos so gerados. So

exemplos destes artefatos: (i) descrio de casos de uso; (ii) diagramas de casos de
uso; (iii) modelos; e (iv) documento de especificao dos requisitos, entre outros.
Mesmo que o processo seja conduzido satisfatoriamente, necessrio
certificarmos de que esses produtos esto corretos. Considerando-se o processo de
desenvolvimento de software, quanto mais cedo um erro for identificado em um artefato
especfico, mais facilmente ele poder ser corrigido e, consequentemente, menor o
custo para a sua correo. Alm dos erros relacionados a uma compreenso
equivocada de uma necessidade, outros erros podem estar relacionados a requisitos
inconsistentes e/ou conflitantes. Uma das formas de identificarmos erros nos artefatos
atravs da realizao de revises. Elas podem envolver diferentes stakeholders e ser
realizadas atravs de reunies.
3.2
O Processo de Engenharia de Requisitos
Diferentes autores propem um processo para a Engenharia de Requisitos. No

contexto desta disciplina, adotaremos o modelo proposto por Sommerville (2009).
Neste processo, o autor prope as seguintes etapas: (i) estudo de viabilidade, (ii)
levantamento e anlise de requisitos, (iii) especificao de requisitos e (iv) validao de
requisitos. Para cada etapa alguns artefatos so gerados. A seguir discutiremos cada
uma das etapas, bem como os artefatos e a importncia de cada um deles para o
processo de desenvolvimento de software.
Estudo de
viabilidade
Levantamento e
anlise de requisitos
Especificao
de requisitos
Validao de
requisitos
Figura 3.2: Etapas da Engenharia de Requisitos
(i) Estudo de Viabilidade

Este estudo tem como objetivo principal avaliar a viabilidade de se desenvolver o
sistema considerando-se as necessidades dos usurios. Atravs desta etapa,
procuramos antecipar os riscos de iniciarmos o desenvolvimento de um sistema que
19
no trar os benefcios esperados. Para tanto, busca-se identificar, brevemente, os

requisitos do negcio que ser modelado durante o processo de desenvolvimento.
Alm disso, cabe descrever o sistema e a forma pela qual ele poder apoiar a
organizao nos seus diferentes processos.
Entretanto, quando mencionamos que esta etapa de Engenharia de Requisitos
gera como resultado um relatrio de viabilidade, muitos questionam o contedo deste
documento. Cabe enfatizar que ele no deve refletir um estudo longo, pois a descrio
detalhada dos requisitos no faz parte desta etapa. um documento que descreve,
sucintamente, as vantagens que o sistema poder trazer para a organizao
apresentando as diferentes formas de utilizao no contexto dos processos de negcio.
Mais ainda: busca responder, brevemente algumas questes relacionadas utilizao
do sistema considerando-se as tecnologias e sistemas j existentes na organizao.
Neste momento, custo e prazo so elementos essenciais para justificar, o no, a
continuidade do processo de desenvolvimento.
Por fim, ser produzido um relatrio que ir, ou no, recomendar a continuidade
do processo de desenvolvimento. Alm disso, cabe justificar a recomendao de
continuidade do processo, ou ento sugerir que o escopo do sistema seja modificado
em decorrncia dos seguintes aspectos: tecnologia, pessoal, prazo, custo, entre outros.
(ii) Levantamento e Anlise de Requisitos

Depois de identificada a viabilidade para prosseguir com o desenvolvimento do
software, cabe aos analistas procurarem entender com mais detalhes as reais
necessidades do cliente. Para tanto, necessrio lanar mo de algumas tcnicas que
podero apoiar esses analistas na compreenso do contexto no qual os processos de
negcio esto inseridos. Alm disso, eles necessitaro ter um conjunto de informaes
que os ajudaro na compreenso das relaes desses processos. Mas cuidado, parece
simples, no ? Se perguntarmos aos usurios o que eles necessitam parece ser
suficiente, mas no to simples assim. Isso acontece por vrios motivos. Vejamos
ento alguns deles a seguir.
20
Muitas vezes achamos que a atividade de levantamento e anlise de requisitos

simples. Isto se deve ao fato de que ela se refere ao entendimento dos processos de
negcio e suas relaes, tecnologia e pessoal envolvidos, aos sistemas existentes,
aos desejos dos usurios, s necessidades e objetivos da organizao, entre outros.
Pois ento no to simples quanto parece, no ?
Algumas tcnicas so frequentemente propostas na literatura para apoiar as
atividades de levantamento e anlise de requisitos. So exemplos dessas tcnicas:
(I) Entrevistas: questes so formuladas para diferentes stakeholders para que
algumas caractersticas sejam identificadas seja em relao a um sistema que est
em produo, ou ento para um sistema que ser desenvolvido;
(II) Prototipagem: um prottipo pode ser caracterizado por uma sequncia de interfaces
relacionadas, cujo objetivo ilustrar o funcionamento de algum requisito. Atravs
delas alternativas de interface podem ser avaliadas e, ao mesmo tempo, os usurios
passam a ter uma ideia do funcionamento do sistema. Como resultado, riscos de
projeto podem ser minimizados. Uma caracterstica de um prottipo que deve ser
levada em considerao ao adotarmos esta tcnica que ele no deve exigir um
tempo considervel do analista. A figura abaixo ilustra um prottipo de uma interface.
Figura 3.3: Exemplo de um prottipo de um frum de discusses associado a um

quadro de avisos
21
Como resultado, artefatos podem ser produzidos para serem utilizados nas
prximas etapas da Engenharia de Requisitos. So eles:
Declarao da(s) necessidade(s);
Escopo do problema;
Clientes, usurios e outros stakeholders;
Lista de requisitos;
Conjunto de cenrios de uso;
Prottipos
Dentre os artefatos produzidos nesta etapa, cabe citar tambm os diferentes
modelos capazes de representar diferentes aspectos obtidos durante o entendimento

das necessidades dos usurios e dos processos que se deseja automatizar. Mas, por
que modelos? Modelos esto relacionados a linguagens grficas que muitas vezes so
mais fceis de serem utilizadas e compreendidas do que a linguagem escrita. Mais
ainda, cada modelo pode documentar um diferente aspecto do sistema. Por exemplo,
os diagramas de sequncia podem enfatizar a sequncia dos eventos e os diagramas
de casos de uso podem retratar as interaes com o mundo exterior.
Nesta etapa, os requisitos devem ser priorizados, bem como ordenados conforme
as necessidades e urgncia do cliente. Por exemplo, em um sistema acadmico
possvel entregar, inicialmente, o mdulo de cadastro de disciplinas. Esta priorizao
tambm est relacionada ao modelo de processo de desenvolvimento adotado. No
RUP, por exemplo, entregas relacionadas aos mdulos iniciais so negociadas e
decises so tomadas. Como resultado, clientes tm suas necessidades prontamente
satisfeitas, e os desenvolvedores podem ter certeza dos prazos e oramentos a serem
cumpridos. Adicionalmente, estimativas so realizadas considerando-se o esforo e o
impacto do requisito que ser entregue.
(iii)
Especificao de Requisitos
Identificadas as necessidades e gerados os artefatos das etapas anteriores, a

especificao de requisitos tem como objetivo produzir um documento contendo, dentre
outras informaes, as funes, as restries e os atributos de qualidade que sero
imprescindveis para o sistema. O documento resultante pode ser escrito contento
modelos gerados na etapa de anlise com o intuito de auxiliar na clareza e na preciso
das informaes ali contidas.
22
Diferentes padres de documentos so propostos na literatura de Engenharia de

Software. O IEEE prope um formato que contm as informaes necessrias para as
etapas posteriores. J Sommerville (2011) sugere um formato diferente separando os
requisitos funcionais e no funcionais em duas categorias. So elas: de usurios e de
sistema. O que diferencia cada uma das categorias o nvel de abstrao em que cada
requisito descrito. Nos requisitos de usurios, encontramos uma declarao em alto
nvel, que interessa fundamentalmente aos stakeholders que no necessitam de um
detalhamento. J nos requisitos de sistema so fornecidos detalhes que interessam
basicamente aos projetistas, implementadores e testadores.
Figura 3.4: Diferentes tipos de requisitos
(iv)
Validao de Requisitos
Considerando-se o modelo adotado para o desenvolvimento de software, quanto

mais cedo ambiguidades e forem identificados, custos podem ser reduzidos,
produtividade e qualidade dos artefatos podem ser melhoradas. Para tanto, so
necessrias validaes dos artefatos buscando-se identificar a consistncia dos
requisitos em relao aos objetivos inicialmente definidos. Mais ainda, so verificados
os aspectos relacionados clareza e a preciso das descries dos requisitos bem
como o nvel de detalhamento adotado e a ausncia de alguma funcionalidade.
Muitas vezes, requisitos difceis de serem testados podem ser especificados, ou
ento o custo de test-lo pode ser muito alto exigindo simulaes inviveis
considerando-se os recursos existentes. Por exemplo, para um sistema de automao
industrial a avaliao de valores associados temperatura e presso podem exigir
ambientes de simulaes que tornariam o custo de desenvolvimento alto.
23
3.3
Gerenciamento de requisitos
Uma vez finalizados os artefatos relacionados ao levantamento e anlise de
requisitos, bem como realizadas as entregas e homologaes do documento de

requisitos, as prximas etapas do processo de desenvolvimento podem ser iniciadas.
Em cada etapa, posterior Engenharia de Requisitos, mudanas podem ser
necessrias e, portanto, devem ser analisadas em relao sua viabilidade. Requisitos
podem estar equivocados, erros podem ser identificados exigindo modificaes nos
artefatos produzidos. O gerenciamento de requisitos diz respeito identificao,
controle e rastreamento do impacto das mudanas em relao aos artefatos j
entregues. Para tanto se torna necessrio o rastreamento em relao, por exemplo, s
fontes dos requisitos, as suas dependncias e o impacto da mudana em relao aos
processos envolvidos e aos diferentes interessados naquele requisito que ser
impactado pela mudana.
Requisitos funcionais podem ser rastreados em relao a diferentes aspectos, tais
como: (i) solicitaes de stakeholders, (ii) regras de negcio associadas, e (iii) outros
requisitos funcionais que podem ser afetados. Por exemplo, considere um sistema de
matrculas de uma escola, ao modificar o requisito funcional RF1: cadastrar disciplinas
que so pr-requisitos da disciplina Engenharia de Software pode ser necessrio
consultar os coordenadores dos cursos que adotam esta disciplina na sua grade
curricular. Esses coordenadores foram identificados atravs de solicitaes registradas.
Para tanto, essas solicitaes devem estar registradas em um documento que fornea
esta informao. Um exemplo deste documento a matriz de rastreabilidade.
Matrizes de rastreabilidade so estruturas de dados que informam os
relacionamentos entre os Requisitos Funcionais (RFi, i=1,..n) e diferentes aspectos.
Exemplos de aspectos:
A1
RF1
RF2
...
RFn
A2
A3
...
An
Fontes de requisitos
Solicitaes de stakeholders
Regras de negcio
Figura 3.5: Exemplo de uma matriz de rastreabilidade
24
Exerccios Resolvidos:
(1) Pesquise outros motivos que podem dificultar o levantamento e a anlise dos
requisitos do sistema que ser desenvolvido.
Resposta: Problemas de escopo (limite do sistema mal definido, detalhes
tcnicos desnecessrios so especificados); Problemas de entendimento;
Problemas de volatilidade.
(2) Por que em algumas situaes entrevistas no so to teis para apoiar o
levantamento de requisitos?
Resposta: (i) Especialistas usam terminologias e jarges especficos. (ii) Alguns
conhecimentos de domnio so to familiares que so difceis de explicar.
Exerccios
(1) Qual a diferena entre requisitos funcionais e no funcionais?
(2) Considere um sistema para gerenciar o atendimento de pacientes em
uma clnica mdica e idealize algumas funes e restries existentes.
(3) Algumas tcnicas foram apresentadas no corpo do texto para apoiar o
levantamento de requisitos. Pesquise na literatura outra tcnica que
poderia ser utilizadas para esta finalidade.
(4) Alm dos requisitos no funcionais apresentados no corpo do texto,
pesquise outros requisitos no funcionais que podem ser especificados
para um sistema.
(5) Os requisitos funcionais so mais difceis de serem quantificados?
Podemos ento afirmar que, em etapas posteriores, caso eles no sejam
quantificados, podemos ter custos elevados para analis-los e verificar
se eles esto de acordo com a especificao?
(6) Uma falha na especificao de um requisto funcional (RF) no tem o
mesmo efeito em relao falha na especificao de um requisto no
funcional (RNF). Ao cometermos um erro em um RF, podemos afirmar
que apenas aquela funcionalidade no ter serventia, enquanto que
uma falha em um RNF pode significar a inutilidade do sistema. Comente
esta afirmao e apresente umexemplo para ilustrar a sua resposta.
(7) Pesquise outras tcnicas que poderiam ser utilizadas para apoiar as
revises de requisitos.
25
(8) Alguns formatos de documento de requisitos so propostos na literatura

de Engenharia de Software. Pesquise sobre esses formatos e proponha
um formato identificando o contedo de cada seo. Defina um sistema
bem simples e gere um documento de requisitos para este sistema.
(9) O gerenciamento de requisitos necessrio por diversos motivos. Alm
daqueles apresentados no corpo do texto pesquise outros motivos que
justificam as atividades de gerenciamento de requisitos.
(10)
Por que utilizamos matrizes de rastreabilidade?
(11) Alm dos relacionamentos ilustrados no corpo do texto, pesquise

outros que podem ser documentados em uma matriz de rastreabilidade.
(12) Como justificar a importncia da engenharia de requisitos e dos
produtos gerados ao longo de cada etapa deste processo?
26
4. Projeto de Sistemas
Este captulo tem como objetivo apresentar a etapa de projeto (design) no

contexto do processo de desenvolvimento de software. Adicionalmente, busca
relacionar os artefatos produzidos nesta etapa com aqueles que foram descritos
nos captulos anteriores. Ao trmino deste captulo, o leitor deve ser capaz de
compreender a importncia desta etapa, e dos artefatos gerados, para o
desenvolvimento de software.
4.1
Introduo
A etapa de projeto (design) de software est relacionada s atividades cujo
objetivo gerar artefatos que representam modelos do software. Tais modelos podem
ter como foco os seguintes aspectos: arquitetura, interface humano-computador, banco
de dados, ou classes que compem o sistema, entre outros. So construdos tendo
como objetivo atender aos requisitos funcionais, bem como aos requisitos no
funcionais. Ao utilizarmos representaes atravs de modelos atributos de qualidade
podem ser avaliados e melhorados tendo como foco os requisitos no funcionais
especificados previamente. Por exemplo, ao definirmos uma estrutura de dados no
momento de projeto estamos interessados no apenas nas funcionalidades que esta
estrutura poder fornecer, mas tambm em nos aspectos como desempenho, custo,
entre outros.
Modelos e representaes geradas na etapa de projeto tm como objetivo
detalhar e definir tecnologias a serem utilizadas na criao do software. Por exemplo: o
projeto de dados e classes gera, como artefatos, as classes de projeto (com um nvel
de detalhamento maior) e as estruturas de dados mais adequadas s necessidades do
sistema que est sendo desenvolvido. J o projeto arquitetural tem como foco os
estilos arquiteturais que sero utilizados e o projeto de interface humano-computador
busca definir as formas de interao com os usurios, bem como o desenho das telas
(interfaces) que sero utilizadas.
Mas, qual objetivo de gerar esses modelos e representaes? Alm de produzir
uma documentao do sistema, que servir de base para futuras modificaes e
evolues, esses artefatos permitem a realizao de revises com o foco na qualidade.
27
Atravs desses artefatos possvel modificar e testar determinadas funcionalidades

antes de implement-las. Como resultado, podemos antecipar a identificao de
possveis defeitos no software e reduzir os custos de implementao e garantir que
determinados requisitos (funcionais e no funcionais) sejam atendidos.
De uma forma geral, o objetivo produzir modelos e descries que satisfaam
aos requisitos (funcionais e no funcionais) considerando a diversidade de situaes
que foram percebidas na Engenharia de Requisitos, bem como buscando uma
convergncia para os negcios e objetivos da organizao. Os artefatos gerados
devem servir no apenas como uma referncia para as etapas posteriores
(implementao teste e implantao), mas como recursos para comunicar as decises
tomadas com o foco nos requisitos. Mais ainda servem para apoiar as revises e, como
resultado, informar sobre a corretude dessas decises. atravs dessas atividades
que as ambiguidades, erros e omisses podem ser identificados.
Para exemplificar alguns tipos de projetos e os diagramas gerados, podemos
citar:
(i) o projeto de classes, apresenta cada classe, desenhada na etapa de anlise,
em elementos com um nvel de detalhamento maior. A figura abaixo ilustra um
diagrama de projeto a partir do diagrama de classes:
Figura 4.1: Exemplo de um modelo com classes de projeto
28
(ii) o projeto arquitetural define o relacionamento entre os diferentes elementos

que compem o sistema. A figura abaixo ilustra a arquitetura de alto nvel
(viso geral) de um sistema de administrao escolar. As representaes dos
sistemas e relacionamentos no mostram propriedades entre eles.
Figura 4.2: Exemplo de um modelo abstrato de uma arquitetura para um sistema

(iii) o projeto de banco de dados apresenta as diferentes estruturas e seus
relacionamentos considerando-se os requisitos funcionais e no funcionais,
bem como as consultas frequentes que so realizadas. A figura abaixo ilustra
um projeto de banco de dados apresentado na disciplina de Banco de Dados.
Autor
(1,1)
cod_autor
nome
nascimento
Escreve
(1,N)
Livro
(0,N)
Publicado
titulo
cod_autor
cod_editora
valor
publicacao
volume
(0,1)
Editora
cod_editora
razao
endereco
cidade
Figura 4.3: Exemplo de um modelo de dados para o projeto de um BD
29
Mas, existem algumas diretrizes para a construo dos diagramas de projeto?

Quais os princpios que norteiam as suas construes? Inicialmente, vamos partir do
princpio de que todo projeto de software deve ser modular. A modularidade permite
que a evoluo do projeto acontea de uma forma mais simples, sem que a alterao
de uma parte exija a modificao de outras partes. Alm disso, incrementos podem ser
liberados mais facilmente. Por exemplo, considere que um mdulo trate da matrcula
dos alunos em um sistema de administrao escolar, e outro mdulo considera a
matrcula das disciplinas, e as suas dependncias. A modularidade permite que apenas
a relao de dependncias entre as disciplinas seja modificada sem que o mdulo de
matrcula seja alterado. Adicionalmente, um mdulo de avaliao de disciplinas pode
ser liberado posteriormente.
Alm da modularidade, um projeto de tratar das representaes dos dados, da
arquitetura, das interfaces entre os mdulos e dos seus componentes. Mais ainda,
cada componente deve tratar das estruturas de dados adequadamente, considerandose as vantagens e desvantagens da utilizao de cada uma delas. Esses componentes
devem utilizar uma notao que comunique para os interessados os seus significados,
e tratar as funcionalidades de forma independente.
4.2
Alguns conceitos de projeto de software

Alm da modularizao, um conceito que deve ser considerado no projeto de
software a abstrao. Ele se refere simplificao das caractersticas que interessam

em um contexto especfico. Ao abstrair, apresentamos apenas as caractersticas que
interessam para uma determinada realidade. Por exemplo, no contexto de um sistema
de administrao escolar os diagramas apresentam apenas as caractersticas que
interessam em relao aos alunos. Ao tratarmos a matrcula de um determinado curso,
no cabe apresentarmos o endereo de cada aluno. Esta caracterstica pode ser
abstrada para este contexto. Entretanto, ao considerarmos o mdulo de cadastro de
cada aluno o endereo um atributo que deve ser considerado.
No basta criarmos mdulos sem nenhum critrio. Dois conceitos so
fundamentais quando consideramos a definio de um mdulo. So eles: a coeso e o
acoplamento. Ao falarmos da coeso de um mdulo estamos interessados na sua
robustez funcional. Ele est relacionado a uma nica atividade. J o acoplamento est
30
relacionado dependncia do mdulo com outros para realizar uma determinada

atividade. Para realizar uma atividade ser necessria a execuo de um mdulo que
por sua vez chama outros mdulos. Desta forma, a modificao de um mdulo pode
acarretar na modificao dos mdulos a eles associados. Por exemplo, um mdulo de
cadastro de alunos deve realizar apenas o cadastro (alta coeso). Se ao realizar o
cadastro ele necessita executar funes de um mdulo financeiro (alto acoplamento),
as modificaes no mdulo de cadastro poderiam no ficar limitadas apenas a este
mdulo. Portanto, para um projeto satisfatrio devemos buscar sempre uma alta
coeso e um baixo acoplamento entre os mdulos.
Outro conceito diz respeito aos padres que podem ser utilizados no projeto. Mas,
muitas vezes os projetistas questionam a necessidade de utilizarmos padres. Por que
eles so importantes? Padres esto relacionados documentao das melhores
prticas, eles descrevem uma estrutura que foi anteriormente utilizada e que foi bem
sucedida. Normalmente eles esto relacionados s melhores prticas considerando-se
o contexto e as foras que atuam na utilizao do padro. Por exemplo, alguns padres
de projeto mencionam a estrutura de classes mais adequadas para serem utilizadas
em um contexto.
Muitas vezes os mdulos devem ser projetados de uma forma que o acesso s
informaes desnecessrias seja controlado. Nem todos os usurios necessitam
acessar e visualizar determinadas informaes. Por exemplo, um aluno no necessita
ter acesso s informaes financeiras da escola. Se ele necessita apenas acessar os
dados da disciplina, os custos associados mesma no necessita ser apresentado ao
aluno. Este conceito est relacionado ocultao de informao. Mas, apenas a
visualizao e o acesso so as vantagens da ocultao de informao? Quais as
consequncias da ocultao de informao? Ao abstrairmos uma informao e, ao
mesmo tempo, ocultarmos esta informao alguns erros no so propagados para
outros mdulos. Somente as informaes necessrias so enviadas para outros
mdulos associados. Portanto, a associao entre ocultao de informao e
abstrao sempre vantajosa para o projeto de sistemas.
A modularizao adequada, associada aos conceitos de abstrao e ocultao de
informao nos leva ao conceito de independncia funcional. Desta forma, no basta
considerarmos apenas uma alta coeso e um baixo acoplamento, se as caractersticas
desnecessrias no forem desconsideradas, bem como os aspectos de acesso
31
informao tambm no forem tratados. A independncia funcional resulta em um

mdulo que possui poucas interaes com outros mdulos. Mais ainda, apresenta
interfaces desses mdulos simplificadas, pois mostram apenas os parmetros
necessrios para as interaes. Consequentemente, as manutenes sero mais
fceis, pois as alteraes no mdulo no acarretam alteraes nos mdulos a eles
associados. Mais ainda, este mdulo poder ser substitudo por outro que trar mais
funcionalidades, ou poder ser reutilizado em outro projeto.
O conceito de refinamento est relacionado ao conceito de abstrao. Ao
refinarmos um mdulo estamos tratando do detalhamento das funcionalidades ali
encontradas. Samos de um conceito mais abstrato, em alto nvel, e refinamos o
mdulo com o intuito de apresentar os detalhes, por exemplo, da sua implementao.
Sucessivos refinamentos podem ser aplicados ao mdulo at o momento em que os
detalhes necessrios so apresentados. Por exemplo: considere um mdulo para tratar
a matrcula de um aluno. Como submdulos podemos exemplificar: (i) o mdulo de
incluso; (ii) o mdulo de excluso de um aluno; e (iii) o mdulo de alterao de um
registro de aluno. Cada um desses submdulos possui um submdulo de busca pelo
nome do aluno ou pelo nmero de matrcula, alm dos algoritmos de busca utilizados.
Muitas vezes os mdulos so construdos de uma forma inadequada, ou ento ele
evolui para um projeto que no corresponde s melhores prticas da Engenharia de
Software. Consequentemente, ele pode ser refatorado no sentido de melhorar as suas
caractersticas, funes e comportamentos. Mas, o que pode ser refatorado para
melhorar as suas caractersticas. Por exemplo, um determinado trecho de cdigo foi
construdo utilizando-se uma estrutura em Java <switch ... case>, entretanto, percebeuse que este trecho poderia ser tratado utilizando-se o conceito de polimorfismo
(Orientao a Objetos). Neste caso, uma refatorao poderia ser aplicada a este
cdigo no sentido de aproveitar as vantagens que o conceito de polimorfismo pode
trazer para o projeto. A refatorao pode retirar do cdigo elementos que so
desnecessrios, ou ento que podem facilitar as manutenes do mdulo. Neste
contexto, redundncias de cdigos podem ser eliminadas e algoritmos ineficientes
podem ser substitudos.
32
Exerccio Resolvido:
(1) Um sistema com um nico mdulo (monoltico) apresenta uma srie de problemas
principalmente no que diz respeito evoluo do sistema. Entretanto, se dividirmos
em uma quantidade significativa de mdulos, o custo de integrao dos mdulos
pode se tornar muito alto, enquanto o custo para manter cada mdulo pode ser
reduzido. Por que no devemos projetar os sistemas como monolticos? Quais as
desvantagens desta deciso de projeto?
Resposta: Ao tomar uma deciso de projeto de um sistema monoltico algumas
dificuldades, principalmente no que diz respeito evoluo do sistema. Mdulos
que esto relacionados a uma funcionalidade especfica e que so independentes
funcionalmente permitem uma integrao mais fcil com um custo mais baixo.
Entretanto, o custo para manter o mdulo pode aumentar. Encontrar o tamanho
adequado de cada mdulo um desafio que dever ser resolvido pelo projetista.
(1) Alm dos exemplos apresentados no coropo do texto, pesquise, pelo

menos, dois tipos de refatorao que poderiam ser aplicados a um
cdigo para melhorar a sua qualidade.
(2) Pesquise o conceito de framework para apoiar o projeto de
software e verifique a(s) forma(s) pela(s) qual (is) ele pode apoiar o
projeto de software.
Exerccios
(1) Relacione os seguintes conceitos de projeto: (i) modularizao e
reutilizao; e (ii) abstrao e modularizao.
(2) Por que a abstrao, a modularizao e a ocultao da informao so
conceitos fundamentais para o projeto de software? Utilize um para
ilustrar a sua resposta.
(3) Relacione os princpios de projeto com as diferentes etapas do modelo
RUP.
(4) De que forma a modularizao pode facilitar o planejamento da
construo de um sistema e o processo de teste de cada mdulo?
(5) Em algumas situaes devemos implementar sistemas monolticos pois,
somente assim podemos conseguir o desempenho desejado. Comente
esta afirmao apresentando exemplos para ilustrar a sua resposta.
33
(6) Pesquise, pelo menos, dois padres que podem ser utilizados no projeto
de um sistema de administrao escolar. Descreva as vantagens e as
foras associadas aos padres especificados.
(7) A reutilizao de um mdulo est relacionada ao uso do mdulo em
outros contextos. Portanto, basta tratarmos a independncia funcional
que garantiremos a reutilizao do mdulo. Pesquise os elementos que
afetam diretamente a reutilizao de um mdulo e relacione esses
elemntos ao conceito de independncia funcional.
(8) Considere o conceito de refatorao e apresente as formas pelas quais
ele interage com os conceitos previamente discutidos (modularizao,

acoplamento, abstrao e ocultao de informao).
34
5. Implementao
Este captulo tem como objetivo apresentar alguns aspectos da etapa de

implementao de um sistema. Ao trmino deste captulo o leitor ser capaz de
identificar duas abordagens para apoiar a implementao de software. So elas:
reutilizao de componentes e gerncia de configurao. Associadas a essas
abordagens algumas prticas de implementao duas discutidas.
5.1
Introduo
Segundo Sommerville (2011), esta etapa pode ser considerada como a mais
crtica do processo de desenvolvimento. Neste momento do processo, o cdigo

executvel ser gerado conforme as especificaes das etapas anteriores.
O desenvolvimento de um cdigo executvel frequentemente apoiado por uma
plataforma de desenvolvimento de software. Esta plataforma oferece um conjunto de
ferramentas para apoiar as diferentes atividades de desenvolvimento, tais como: (i) um
editor grfico de modelos, por exemplo, UML, que sero transformados em cdigo
executvel. Este cdigo necessita ser editado e, portanto necessita de um suporte de
um editor de cdigo para uma linguagem especfica, apoiado por um compilador
integrado; (ii) um sistema que permita realizar a depurao do cdigo que est em
desenvolvimento; e (iii) ferramentas integradas de testes de integrao dos mdulos.
Ferramentas de apoio ao desenvolvimento normalmente so integradas em um
ambiente, denominado IDE (Integrated Development Environment).
Editor LP
Testes
IDE
Depurador
Editores
Modelos
Figura 5.1: Elementos de uma IDE
35
Alm dos aspectos envolvidos na programao, tais como as boas prticas de

programao, esta etapa trata da aderncia aos padres de processo e de produto
determinados pela equipe de qualidade. Mais ainda: importante considerar os
artefatos gerados nas etapas anteriores, bem como os processos definidos em cada
etapa.
Alguns exemplos de IDE: o NetBeans (www.netbeans.org); e o Eclipse

(www.eclipse.org), baseado em plug-ins.
No contexto desta disciplina (Fundamentos da Engenharia de Software) cabe

ressaltar duas abordagens normalmente consideradas quando tratamos dos aspectos
de implementao de software. So elas: reutilizao de software e gerncia de
configurao.
5.2
Reutilizao de software
Reutilizao de artefatos no processo de implementao no recente.
Desenvolvedores frequentemente lanam mo desta tcnica ao utilizarem as

bibliotecas de linguagens de programao. Entretanto, com o surgimento de novas
demandas para o desenvolvimento de software, tais como qualidade dos artefatos, alta
produtividade e baixo custo, as abordagens para reutilizao tambm evoluram.
Desenvolvimento de software a partir da reutilizao est associado ao processo
de construo de sistemas a partir de um conjunto de artefatos, incluindo cdigos, j
existentes. Portanto, podemos pensar que se vamos unir trechos de cdigo
(bibliotecas) para construir um sistema, ento o processo de desenvolvimento ser
simplificado. Porm, isto nem sempre verdade. Em sistemas relativamente pequenos
que exigem um conhecimento limitado do domnio no qual ele ser aplicado,
provavelmente
implementao
ser
simplificada.
Entretanto,
os
processos
frequentemente encontrados na prtica so aqueles que podemos denominar de adhoc. No existe uma sistematizao do reuso.
Ao sistematizarmos a reutilizao atravs de padres de procedimentos podemos
obter uma srie de benefcios, tais como: os custos de implementao podem ser
36
reduzidos, a produtividade e a qualidade podem ser aumentadas. Alm disso, aspectos

relacionados portabilidade de artefatos podem ser adequadamente tratados, bem
como a confiabilidade e a segurana desses artefatos (Sametinger, 1997).
A reutilizao pode apoiar no apenas a etapa de implementao, mas qualquer
etapa do processo de desenvolvimento, pois esta abordagem no est restrita
apenas ao cdigo produzido. Podemos afirmar que a reutilizao est associada
a qualquer artefato que foi especificado, projetado, implementado e avaliado
para reuso.
Podemos ento generalizar a utilizao desta abordagem para os processos de

implementao. Certamente, no podemos afirmar que a reutilizao sempre oferecer
benefcios. Se os artefatos foram desenvolvidos para reutilizao, a probabilidade de a
implementao ser bem sucedida maior.
Por outro lado, desenvolver software sem um suporte adequado da reutilizao
pode significar que muitas partes so redundantes. Uma modificao em uma
funcionalidade que se repete em uma quantidade significativa de artefatos pode
significar um aumento no custo de implementao e teste, e, ao mesmo tempo, uma
reduo na confiabilidade desses artefatos. Mais ainda, como resultado, o tempo para
a liberao de um mdulo pode ser maior.
Considere, por exemplo, um mdulo que verifica os pr-requisitos das disciplinas
de um determinado curso. Este mdulo reutilizado em dois mdulos diferentes. So
eles: o mdulo de matrcula e o de excluso de disciplina do curso. Uma alterao no
sistema de pr-requisitos requer apenas que o mdulo correspondente seja modificado.
Esta alterao ir refletir em ambos os mdulos que o reutilizam. Caso contrrio, a
mesma modificao deveria ser replicada para os dois mdulos.
Mdulo de pr-requisitos
Mdulo de excluso
de disciplinas
Mdulo de
matrcula
Figura 5.2: Relao entre alguns mdulos de um sistema de administrao

escolar
37
Em relao tecnologia utilizada para apoiar a reutilizao, podemos afirmar que

a programao orientada a objetos contribui significativamente para a adoo desta
abordagem na etapa de implementao. Entretanto, o reuso no depende desta
tecnologia. A adoo de reuso poder ser mais difcil, mas ela no est associada a
uma tecnologia especfica.
Se a modificao de um determinado artefato necessria para decidirmos pela
adoo de reuso para a implementao, cabe avaliarmos os efeitos que esta atividade
trar para o projeto como um todo. Nem sempre a adoo de reso pode ser vantajosa.
Necessitamos, portanto de formas para julgarmos se as funcionalidades disponveis em
um determinado mdulo so adequadas para a implementao de um novo artefato.
Reuso est associado s ideias e conceitos utilizados para a implementao de um
artefato e, portanto, necessitamos de mecanismos para documentar este artefato para
que ele possa, posteriormente, ser reutilizado.
5.3
Gerenciamento de Configurao
Finalizadas as atividades de implementao, mudanas podero ocorrer a
qualquer momento. Elas decorrem no apenas do surgimento de novos requisitos, mas

tambm de alteraes naqueles j existentes.
Pesquise: por que mudanas ocorrem nos sistemas que j esto em

produo?
A partir do momento em que as alteraes foram aprovadas e o processo de

modificao inicia, problemas podem ocorrer. Por exemplo, um mdulo foi alterado,
testado e disponibilizado (Mdulo matrcula (1) Figura xx). Posteriormente, a
alterao pode ser desfeita por falta de informaes, tais como: por que foi feita?
(Mdulo matrcula (2) Figura xx). Mais ainda, ela no foi desfeita, porm a verso
incorreta foi utilizada para ser integrada ao sistema.
38
Figura 5.3: Mdulo com alterao desfeita pelo Desenvolvedor 2

Gerenciamento de Configurao um processo cujo objetivo adotar medidas e
prticas para garantir que as mudanas durante o processo de desenvolvimento sero
bem sucedidas. Isto significa que as verses corretas sero utilizadas, bem como
informaes relacionadas ao processo de mudana estaro disponveis, tais como: (i)
quem alterou?; (ii) por que alterou?; (iii) quem solicitou? (iv) por que solicitou? , dentre
outras. Associadas a essas mudanas podemos mencionar as atividades que delas
decorrem, tais como: integrao dos componentes, e compilao dos mdulos de
acordo com a configurao desejada. Por exemplo: considere um sistema de
administrao escolar com os seguintes mdulos: matrcula, pagamento, e incluso de
disciplinas. Suponha que dois desenvolvedores estejam alterando dois mdulos
distintos: matrcula e pagamento (Figura xx (1)), mas no tm o suporte de um
sistema de gerncia de configurao. Ao trmino das modificaes, verses erradas
podem ser integradas (Figura xx (2) e (3)), alteraes realizadas no mdulo de
matrcula tambm podem deixar de funcionar.
Figura 5.4: Alteraes em mdulos distintos: problemas de integrao de

mdulos
Duas atividades so frequentemente mencionadas na literatura ao abordar o
gerenciamento de configurao: gerenciamento de verses e integrao de mdulos
39
que compem o sistema. Sommerville (2011) acrescenta o rastreamento de problemas

como outra atividade bsica para o gerenciamento de configurao. Esta ltima trata
das sinalizaes de desenvolvedores que esto trabalhando em um determinado
mdulo para identificar um problema especfico. No exemplo anterior do sistema de
administrao escolar o desenvolvedor do mdulo de matrcula poderia ser informado
sobre a alterao que est em andamento tanto no mesmo mdulo, quanto em outro
mdulo que se relaciona a este. Como resultado, um sistema de gerenciamento de
configurao poderia adotar diferentes polticas para tratar esta situao. Por exemplo:
no permitir que dois desenvolvedores modifiquem o mesmo mdulo ao mesmo tempo,
permitir que eles alterem o mesmo mdulo ao mesmo tempo, porm ao gravar o
mdulo o desenvolvedor seria informao que o mdulo est sendo alterado por outro
e permitiria que eles interagissem para resolver um possvel impasse.
Pesquise outras polticas de gerncia de configurao diferentes

daquelas que foram apresentadas no corpo do texto.
Portanto, podemos considerar que a gerncia de configurao est relacionada

ao controle de verses de mdulos que foram geradas em decorrncia de solicitaes
de mudanas, de correes identificadas posteriormente entrega do sistema, de
defeitos identificados a qualquer momento, ou ento de alteraes no hardware que
podem exigir tambm mudanas na implementao. Sem um sistema de gerncia de
configurao esforos podem sem desperdiados a partir do momento em que um
desenvolvedor altera uma verso equivocada. Mais ainda, podem gerar retrabalho e,
como consequncia, aumentar os custos, gerar atrasos e reduzir a qualidade do
sistema.
As atividades de gerncia de configurao (GC) no esto associadas apenas
etapa de implementao e aos artefatos produzidos nesta etapa. GC deve ser
utilizada em todas as etapas do processo de desenvolvimento de software.
Desde a Engenharia de Requisitos at a Implantao do sistema, passando pela
Gerncia de Qualidade.
40
Alm de apoiar o processo de mudana oferecendo informaes relativas s

diferentes verses produzidas, podemos encontrar tambm dentre as atividades de GC
procedimentos para registrar e processar as mudanas. So esses procedimentos que
nos apoiaro, por exemplo, nas anlises das viabilidades de mudanas. Atravs
desses registros poderemos encontrar informaes tais como: por que a mudana foi
realizada, quais os requisitos que esto associados a ela, quantas vezes ela foi
solicitada, dentre outras informaes.
Se um mecanismo eficiente para gerenciar a configurao durante a
implementao de um mdulo, problemas relacionados qualidade podem surgir em
decorrncia, por exemplo, da no utilizao de um padro estabelecido, ou ento pela
liberao de um artefato equivocado para a equipe de qualidade. Podemos afirmar,
portanto, que as atividades de Gerncia de Configurao esto fortemente
relacionadas Gerncia de Qualidade.
A gerncia de configurao no est associada apenas ao controle de verses
resultantes de modificaes durante o processo de implementao. Ela est associada
tambm ao gerenciamento de diferentes verses em decorrncia da liberao do
produto para diferentes plataformas de hardware e software. Por exemplo, sistemas
operacionais diferentes que so utilizados por clientes distintos que necessitam adquirir
o produto, ou ento em funo de requisitos especficos de determinados clientes que
necessitam ser gerenciados.
Figura 5.5: Exemplo de gerncia de configurao entre plataformas distintas

Os gerentes de configurao necessitam manter o controle das diferenas entre
as verses produzidas e liber-las corretamente para clientes especficos. Esses
clientes podem utilizar sistemas operacionais diversificados e, portanto, necessitam de
41
configuraes tambm especficas para as suas necessidades. Por exemplo, para as

verses que utilizam o sistema operacional Windows foi disponibilizado o mdulo que
permite realizar matrculas atravs de dispositivos mveis. Portanto, h necessidade de
liberar este mdulo apenas para os clientes que utilizam a plataforma Windows.
(1) Considerando a produtividade e a confiabilidade, por que podemos afirmar que a
abordagem de reutilizao oferece benefcios para as atividades de
implementao?
Resposta: Em relao produtividade podemos afirmar que uma quantidade

reduzida de cdigo ser construda, ao mesmo tempo em que podemos utilizar
cdigos j amplamente avaliados (confiabilidade).
(2) Suponha que verses incorretas de mdulos foram utilizadas e, mesmo assim, o
sistema continua executando sem indicar erros. Por que isso possvel? Quais as
consequncias de se utilizar verses incorretas de um mdulo para compor um
sistema?
Resposta: Mdulos com verses que no pertencem a uma mesma verso do
sistema podem executar sem apresentar erro, entretanto, as funcionalidades no
esto de acordo com os requisitos especificados. Frequentemente, no uma
atividade fcil a identificao desse tipo de erro. Como resultado, inconsistncias
podero ser geradas afetando o banco de dados do sistema.
Exerccios
(1) Por que vantajosa a utilizao de IDE para apoiar a implementao de
um artefato?
(2) Quais os fatores no tcnicos que podem significar obstculaos para
adoo de reso para as atividades de implementao?
(3) Alm das IDE exemplificadas no corpo do texto, pesquise outras que
esto disponveis para utilizao.
(4) Compare as funcionalidades de duas IDE disponveis para utilizao.
42
(5) Considerando a qualidade e o custo, por que podemos afirmar que a

abordagem de reutilizao oferece benefcios para as atividades de
implementao?
(6) Identifique, pelo menos, dois riscos para as atividades de
implementao que podem surgir com a adoo de reso.
(7) Alm da possibilidade de controlar as verses que esto sendo geradas,
por que gerenciar a configurao de um sistema durante a
implementao?
(8) A rastreabilidade est associada associao de diferentes artefatos no
processo de desenvolvimento de software. Por que um suporte
rastreabilidade importante durante o processo de implementao? De
que forma um sistema de gerncia de configurao pode apoiar a
rastreabilidade?
(9) De que forma a gerncia de configurao dos artefatos produzidos nas
etapas de Engenharia de Requisitos e Projeto podem afetar os mdulos
produzidos na etapa de Implementao?
(10) Uma funo da gerncia de configurao controlar sistematicamente
as mudanas do software. Para tal, torna-se necessrio uma ferramenta

para apoiar o controle de verses. Cite pelo menos trs funcionalidades
dessa ferramenta.
43
6. Teste de Software
Este captulo tem como objetivo discutir sobre a importncia dos processos de
teste de software, bem como sobre os artefatos produzidos nesta etapa.
Adicionalmente, apresenta os conceitos relacionados a teste de software, de
uma forma geral, evidenciando as atividades de verificao e validao.
6.1
Introduo
Muitas vezes nos depararmos com a seguinte pergunta: se o software
construdo considerando as metodologias, os processos e as ferramentas, por que

ainda encontramos tantos erros nos produtos? Erros e defeitos em software podem
acarretar falhas na execuo do cdigo, acarretar uma insatisfao do usurio e gerar
custos altssimos para a reparao. Nosso dia a dia est cada vez mais dependente
dos softwares. Eles podem ser encontrados em toda a parte. Portanto, a cada dia
percebemos que no mais espao para sistemas com baixa qualidade.
A qualidade est relacionada a diversos fatores, tais como: o produto
desenvolvido no realiza as funes de acordo com o que foi especificado, ou realiza
as funcionalidades que no foram especificadas. Mais ainda, muitas vezes no
encontramos uma funcionalidade na especificao do sistema, mas que deveria ser
definida. Outros problemas se relacionam indiretamente com os erros e defeitos. So
eles: no existe um cuidado na construo dos artefatos e eles acabam sendo de difcil
compreenso.
Mas, por que um erro ou defeito de software ocorre? Diferentes razes podem
acarretar em um erro ou defeito, mas frequentemente elas esto relacionadas a
especificaes erradas ou imprecisas. Portanto, podemos deduzir que um erro na
especificao pode se arrastar durante todo o processo de desenvolvimento, e, como
resultado, o custo para identificarmos e corrigir certamente ser maior. Por qu?
Quanto mais cedo identificarmos e corrigirmos um erro, maior ser a

probabilidade de construirmos software com qualidade.
44
Um erro ou defeito tambm pode estar relacionado ao processo de

desenvolvimento, ou at mesmo qualificao da mo de obra envolvida neste
processo que pode gerar artefatos equivocados. Por exemplo, um erro em um modelo
pode gerar srios problemas que so difceis de serem identificados.
Mesmo que todos os possveis caminhos em um programa sejam testados, no
podemos garantir que ele estar correto e que nenhuma falha ocorrer a partir deste
momento. Isto se relaciona ao fato de que no podemos garantir que todos os
possveis dados (entradas e sadas) foram avaliados. Mesmo que tivssemos todas as
entradas e sadas conhecidas elas podem ser inmeras tornando invivel o processo
de teste, por exemplo, como poderamos testar todas as entradas e sadas de uma
calculadora? Outro motivo est relacionado forma pela qual as especificaes so
construdas, gerando muita impreciso e ambiguidade. Portanto, no podemos garantir
que em um software nunca encontraremos uma falha ou defeito. Uma forma de reduzir
esta probabilidade utilizar diferentes formas de verificao e validao nas etapas do
processo de desenvolvimento.
6.2
Verificao e Validao
As formas de verificao buscam garantir que o programa atende a sua
especificao, se os diferentes artefatos esto de acordo com a sua especificao. J,

atravs das formas de validao buscamos ter a certeza de que todas as
funcionalidades esperadas foram implementadas. Se o produto corresponde s
expectativas do usurio, no apenas realizando todas as funcionalidades, mas
resolvendo o problema que foi definido no momento da especificao.
Frequentemente alguns autores relacionam as formas de verificao a uma busca
constante seguinte pergunta: estamos desenvolvendo o software corretamente? J
as formas de validao se associam s respostas seguinte pergunta: estamos
desenvolvendo o software correto? Os processos de verificao e validao (V&V)
ocorrem, portanto, nas diferentes etapas do desenvolvimento do software. Por
exemplo, podemos desenvolver um sistema de administrao escolar para o qual o
documento de requisitos foi desenvolvido, supostamente, de acordo com as
necessidades dos usurios. Desta forma, as outras etapas ocorreram conforme
previstas pelo modelo de processo adotado. So elas: projeto (design), implementao
45
e testes. Alm disso, todas as revises foram feitas nos artefatos, conforme previsto.
Entretanto, o sistema no foi aprovado pelos usurios, ou seja, as funcionalidades
esperadas no foram adequadamente implementadas. O sistema, portanto, no foi
validado e necessita de correes.
Em relao ao processo de desenvolvimento, quanto mais cedo os erros e
defeitos forem identificados, menor o esforo para resolv-los. Requisitos devem ser
validados no sentido de identificar erros, omisses, ambiguidades e inconsistncias. No
momento da validao dos requisitos eles sero revistos e atravs dos casos de testes
verifica-se se eles so capazes de serem testveis.
Percebemos, ento que a Verificao e a Validao so abordagens que se
complementam. Ao utilizarmos as tcnicas de V&V estticas (inspees e revises)
defeitos podem ser identificados agilizando o processo de desenvolvimento e
aumentando a qualidade dos artefatos. Entretanto, as tcnicas estticas no so
capazes de avaliar se o software cumpre todas as necessidades do usurio em relao
aos processos operacionais. Ou seja, o software atende s especificaes, mas no
apoia os processos operacionais conforme as necessidades dea organizao. Mais
ainda, essas tcnicas no so capazes de avaliar aspectos como desempenho,
escalabilidade, portabilidade, entre outros requisitos no funcionais.
J os testes de software esto relacionados s tcnicas dinmicas, atravs das
quais as implementaes so avaliadas com a utilizao de dados de teste. Esto
relacionados execuo do programa, e seus diferentes caminhos, no sentido de
identificar os defeitos considerando-se os dados de entrada e sada. A partir dos
resultados, anomalias so identificadas e os cdigos dos diferentes caminhos so
corrigidos. So denominados na literatura de testes funcionais.
6.3
Testes Unitrios
Outro tipo de teste que devemos realizar em um sistema durante a etapa de
implementao diz respeito aos elementos utilizados. Por exemplo, mtodos ou

funes devem ser testados considerando-se as diferentes chamads realizadas e os
parmetros utilizados.
46
Ao projetarmos os testes unitrios devemos ter certeza de que todos os possveis

caminhos foram exercitados e que no existem erros em relao entrada e sada dos
dados esperados. Portanto, todos os valores provveis dos atributos associados, por
exemplo, a um objeto especfico devem ser conhecidos. Adicionalmente, todos os
possveis estados do objeto tambm devem ser exercitados com os dados de entrada e
observando as sadas esperadas.
Mas, se considerarmos todos os estados, e as suas possveis combinaes, no
podemos elevar os custos de testes e, como resultado os custos de desenvolvimento?
Certamente, isso possvel. Portanto, devemos selecionar aqueles casos de teste que
nos fornecero resultados satisfatrios, tanto no que diz respeito s funcionalidades
bem sucedidas, como naquelas que possuem defeitos. Um caso de teste est
relacionado avaliao de uma funcionalidade especfica, por exemplo, uma tentativa
de matricular um aluno no cadastrado.
6.4
Testes de Sistema
Esses testes esto relacionados integrao dos componentes. Neste momento,
todos os componentes so avaliados considerando-as suas interfaces e o

comportamento esperados por eles a partir do momento em que so integrados. No
uma atividade trivial, e necessita de uma estratgia para que possam ser integrados.
Por exemplo, o acrscimo de um mdulo de cadastro de disciplinas, j devidamente
testado, pode levar identificao de defeitos em outros mdulos, tais como, os
mdulos de cadastro de alunos e/ou de matrcula.
(1) Suponha que um determinado sistema seja desenvolvido de acordo com os
conceitos do paradigma de orientao a objetos. Assim sendo, os testes funcionais,
ou de caixa preta, parecem adequados. Comente esta afirmao.
Resposta: Os testes funcionais, ou de caixa preta, no so suficientes para que
todos os caminhos sejam testados. Nos sistemas que implementam o paradigma de
Orientao a Objetos difcil prever todas as combinaes de eventos, entradas e
sadas, que permitem que os objetos se comuniquem.
47
(2) Testes de software podem ser caros e demorados, tendo em vista a quantidade de
testes a serem realizados. Alm disso, nem todos os defeitos podem ser
detectados. De que forma as revises e inspees podem auxiliar no processo de
teste de software?
Resposta: A afirmao est correta. Os testes podem ser caros e demorados
principalmente quando tratamos de sistemas complexos. Mais ainda, no podemos
garantir que todos os defeitos sejam detectados, considerando-se, sobretudo, todos
os possveis conjuntos de dados, e as suas combinaes que deveriam ser
testados. As inspees e revises poderiam reduzir as incertezas de forma que os
erros poderiam ser identificados em etapas anteriores aos testes, como tambm
no permitir que os erros sejam propagados para as etapas seguintes do processo
de desenvolvimento de software.
Exerccios
(1) De que forma a compreenso inadequada dos artefatos pode acarretar erros e
defeitos?
(2) Suponha que um defeito foi identificado e devidamente corrigido. Por que
devemos repetir os testes associados ao elemento aps o reparo do defeito?
(3) Considere um sistema de administrao escolar e apresente, pelo menos, trs
casos de testes hipotticos para os seguintes mdulos: (i) mdulo de matrcula,
(ii) mdulo de cadastro de aluno, e (iii) mdulo de cadastro de disciplina.
(4) Suponha que o sistema especificado em sala de aula ser desenvolvido de
acordo com os conceitos de orientao a objetos. Assim sendo, os testes de
caixa preta, ou funcionais, parecem ser adequados. Comente esta afirmao e
utilize exemplos para ilustrar a utilizao desta abordagem.
(5) Testes de software podem ser caros e demorados, tendo em vista a
quantidade de avaliaes a serem realizadas. Alm disso, nem todos os
defeitos podem ser detectados. Comente essa afirmao e apresente as
formas pelas quais as revises podem auxiliar no processo de teste de
software.
(6) Como podemos planejar um teste em um processo de desenvolvimento que
adota o RUP?
48
7. Manuteno e Evoluo de Software
Este captulo tem como objetivo apresentar os conceitos de manuteno e

evoluo de software buscando ressaltar a importncia dessas atividades para a
engenharia de software. Ao trmino deste captulo, o leitor ser capaz de
compreender os processos de evoluo e por que as mudanas acontecem
durante o ciclo de vida do software.
7.1
Introduo
At o momento vimos os aspectos relacionados ao desenvolvimento de software,
incluindo os diferentes processos e os contextos nos quais eles podero ser utilizados.
Posteriormente ao trmino do desenvolvimento, a entrega do produto ao cliente, e a
sua colocao em operao, parece que nenhuma atividade ser feita, no mesmo?
Pois no desta forma que sempre acontece em relao ao software. Comeam agora
as atividades de manuteno e evoluo do produto. Algumas modificaes ocorrem
para corrigir erros que no foram detectados no momento que deveriam, por exemplo,
nas atividades de verificao e validao. Outras modificaes acontecem para
otimizar alguns requisitos no funcionais, tais como desempenho, portabilidade,
escalabilidade, entre outros.
Ento, se nada disso acontecer parece que no precisamos modificar o produto.
Podemos considerar isso como verdadeiro?
Isso seria verdade se as condies que afetam os requisitos funcionais no
alterassem, ou seja, se o contexto no qual o produto executa no modificasse. Dentre
as condies que afetam o contexto podemos citar: as regras de negcio, o mercado,
as legislaes que apoiam o mercado, o surgimento de novos requisitos funcionais,
que por sua vez podem demandar alteraes nos requisitos no funcionais, as
imposies de modificaes no oramento que demandam alteraes no cronograma,
entre outras.
Mas, dependendo do tempo em que o produto foi desenvolvido, no poderia ser
melhor refazer todo o projeto? s vezes isto pode acontecer, mas uma deciso difcil
de ser tomada levando-se em considerao a importncia e o valor que o sistema
legado representa para a organizao. Os funcionrios j foram treinados, o
49
conhecimento adquirido por eles em relao s tecnologias envolvidas, entre outros

aspectos que justificam a continuidade do sistema e a sua manuteno.
Mudanas devem acontecer e necessitamos implementar um processo para
gerenci-las. Ao realizar as alteraes uma quantidade significativa de verses pode
ser gerada e, essas verses precisam ser controladas, sem haver interrupes nos
processos organizacionais. Sobre este aspecto j tratamos no Captulo que discute a
etapa de Implementao. Cabe Gerncia de Configurao tratar dos aspectos
decorrentes do processo de manuteno de software.
Existem diversos tipos de manutenes, mas no contexto desta disciplina vamos
nos basear nos trs tipos descritos por Sommerville (2011). So eles: (i) a manuteno
corretiva, cujo objetivo consertar os defeitos no software; (ii) a manuteno adaptativa
que busca adaptar o software, por exemplo, a ambientes que utilizam outros sistemas
operacionais, outros requisitos que surgiram em decorrncia desta necessidade, ou
ento, outros aplicativos que iro interagir com o software; e (iii) a manuteno
evolutiva, cujo objetivo acrescentar novos requisitos funcionais ao sistema para que
ele atenda necessidades dos usurios ou dos novos processos que surgiram.
Diante dos diferentes tipos apresentados podemos concluir que devemos estar
preparados para as modificaes do software, pois grande parte dos sistemas ir
evoluir. Caso contrrio, a execuo do processo automatizado por esses sistemas
poder ser interrompida. Devemos, portanto, investir esforos no sentido de utilizar
boas prticas de desenvolvimento de software buscando reduzir os custos de
manuteno. Quando falamos de boas prticas estamos nos referindo a um vasto
conjunto de atividades que contribuem para a qualidade dos artefatos que sero
produzidos. Por exemplo, documento de requisitos contendo especificaes claras,
precisas e completas, projetos arquiteturais que contemplem as caractersticas no
funcionais e os princpios de projeto prioritrios, cdigo aderente aos padres
previamente definidos, entre outras prticas.
Pesquisas em Engenharia de Software tm demonstrado que, mesmo que as

boas prticas demandem um custo adicional, este custo menor do que os
custos adicionais, em manuteno.
50
7.2
Transformao de Arquitetura
Muitas vezes a arquitetura do software necessita ser modificada, por exemplo, de
uma arquitetura centralizada para distribuda. Essa modificao pode ser decorrente de
alguns fatores, tais como (SOMMERVILLE, 2009): (i) sistemas distribudos oferecem
um custo menor para desenvolvimento; (ii) as interfaces grficas oferecidas podem
promover as interaes em diferentes locais; e (iii) o acesso distribudo pode viabilizar
os negcios das organizaes. Entretanto, migrar sistemas, que foram desenvolvidos
em uma ocasio em que as tecnologias eram bem diferenciadas podem oferecer
dificuldades para a transformao de arquitetura. Por exemplo, a estrutura em que eles
foram projetados, em termos de componentes, pode dificultar a reorganizao do
sistema.
7.3
Reengenharia
Sistemas legados necessitam ser modificados e, para tanto, fundamental que
eles possuam uma estrutura que facilite a sua compreenso e alterao, considerandose tempo e custo. Muitas vezes, eles no podem ser descontinuados e, portanto,
precisam passar por um processo de reengenharia. Neste processo, nenhuma
funcionalidade acrescentada ao sistema. Envolve alteraes na sua estrutura com o
objetivo de tornar a manuteno mais fcil.
sempre possvel fazermos reengenharia? Um dos objetivos da reengenharia
reduzir os riscos e os custos de manuteno. Entretanto, os custos dependem de uma
srie de fatores. Por exemplo, de pessoal qualificado para realizar as atividades de
reengenharia e, das tecnologias e recursos de hardware disponveis.
Em alguns tipos de sistema, em especial aqueles que foram desenvolvidos para
web necessitam de modificaes frequentes. Essas modificaes decorrem de
aspectos de usabilidade, de desempenho ou de algum ajuste em outros requisitos no
funcionais. Mais ainda, sistemas cujos requisitos tm uma probabilidade maior de
alterao e necessitam de um prazo de entrega mais rpido. Como resultado,
necessitam de mudanas para adequar a estrutura e arquitetura s necessidades.
51
(1) Considere os conceitos envolvidos na manuteno de software e cite pelo
menos dois fatores, alm daqueles j mencionados no texto, e justifique a
adoo de cada um deles, que poderiam contribuir para a elevao dos custos
das atividades de manuteno.
Resposta: Outros fatores que elevam os custos de manuteno:
Instabilidade da equipe: frequentemente h necessidade de
contrataes para substituir um participante. Mesmo que a contratao
tenha um nvel de exigncia compatvel com o projeto, existem riscos
envolvidos em relao adaptao do participante ao projeto.
Habilidade da equipe para conduzir o processo de manuteno
considerando os padres de qualidade estabelecidos pela empresa.
(2) Considere a necessidade de acrescentar funcionalidades depois que um sistema

estiver em operao. Por que os custos de manuteno podem ser altos?
Resposta: Alguns fatores podem contribuir para que o custo de manuteno
deste sistema seja alto. So eles:
A equipe que desenvolveu o sistema j foi desfeita e o conhecimento
no foi adequadamente armazenado.
A documentao no foi devidamente realizada considerando o
relacionamento entre os artefatos produzidos nas diferentes etapas do
processo de desenvolvimento.
No existem ferramentas adequadas para o projeto das novas
funcionalidades, nem mesmo mo de obra especializada.
Exerccios
(1) Cite os tipos de manuteno e apresente exemplos para ilustrar a sua
resposta.
(2) Qual a diferena entre transformao de arquitetura e reengenharia no
contexto de manuteno de software?
(3) sempre possvel realizarmos manutenes em software? Caso no seja
possvel, apresente situaes nas quais a manuteno no seria vivel.
(4) Considere um sistema web cujos requisitos sofrem modificaes
frequentes. Diante desta situao sugira um processo de
desenvolvimento e justifique a sua utilizao neste contexto.
(5) Considerando que um dos objetivos da reengenharia reduzir os riscos
de manuteno, apresente as formas pelas quais esses riscos podem ser
reduzidos e cite exemplos para ilustrar a sua resposta.
(6) Alm da habilidade e estabilidade da equipe, existem outros fatores que
poderiam contribuir para a reduo dos custos de manuteno?
52
8. Gerncia da Qualidade
Aps a leitura deste captulo voc ser capaz de conhecer o significado de

qualidade de software, bem como a sua importncia para o processo de
construo de software. Alm disso, saber a relao entre o gerenciamento da
qualidade e o processo de desenvolvimento de software. Para tanto,
discutiremos as influncias entre medio de produto e processo. Algumas
mtricas de software que podero auxiliar na quantificao do produto sero
apresentadas.
8.1
Introduo
Ao falarmos de qualidade de software normalmente estamos preocupados em
definir padres de processos e produtos que sero decorrentes da aplicao desses

padres. Mais ainda, associados a esses padres devemos encontrar uma vasta
documentao que nos auxiliar no s na aplicao desses padres, na sua
conformidade, mas na determinao das medies mais adequadas. Normalmente
denominamos de garantia de qualidade o processo de determinao de padres, tanto
de processo quanto de produtos. J o controle de qualidade se relaciona verificao
se os padres so aplicados.
Considerando
os processos de
desenvolvimento
de
software
de
gerenciamento de qualidade, cabe mencionar que eles no deveriam ser realizados

pelo mesmo grupo, ou por pessoas que pertenam a ambos. Isto se deve ao fato de
que as pessoas poderiam ser influenciadas pela verificao da conformidade dos
produtos gerados nas diferentes etapas do desenvolvimento.
No basta seguirmos padres de processo e produtos. O gerenciamento da
qualidade vai alm da aderncia a esta determinao.
Considerando a dificuldade em determinarmos especificaes para a qualidade

de software, qual o significado de qualidade?
53
Podemos dizer que a qualidade de software est associada aderncia do

software a sua especificao. Porm, discutimos nos captulos anteriores sobre a
dificuldade de gerarmos uma especificao clara e precisa. Mais ainda, dependendo do
contexto de utilizao do software os requisitos podem mudar. Certamente esta
dificuldade deve ser considerada no processo de construo de um sistema e no
gerenciamento da qualidade.
Independente da dificuldade de avaliarmos a qualidade de software baseada nos
requisitos cabe mencionarmos que devemos verificar e validar os produtos gerados nas
diferentes etapas do processo de desenvolvimento. A qualidade de um produto est
associada realizao dos requisitos funcionais e no funcionais. Ou seja, no basta
que o sistema implemente as funcionalidades necessrias ao produto, mas que estas
funcionalidades sejam atendidas em um nvel mnimo de exigncia dos requisitos no
funcionais. Por exemplo, no basta implementarmos um componente que apresente
um vdeo de uma aula em uma qualidade satisfatria se o udio no est sincronizado
em decorrncia de uma exigncia de desempenho que a rede local no oferece.
Portanto, cabe definirmos aqueles requisitos no funcionais prioritrios para os
sistemas, pois jamais conseguiremos implementar um produto que tenham todos os
atributos de qualidade em seu valor mximo.
Podemos ento associar os padres de processo aos padres de produto? Os
processos padronizados certamente tero uma probabilidade maior de gerar produtos
com qualidade, mas no podemos garantir que basta apenas considerarmos os
processos.
Padres de
processo
Padres de
produto
Figura 8.1: Relao entre processo e produto

Mais ainda, os padres de produtos, e as medies realizadas nesses produtos
so indicadores para que melhorias contnuas no processo possam ser implementadas.
O fato que no podemos abandonar os padres de processo e de produto , pois
associados a eles esto representadas as melhores prticas da organizao. Por
exemplo, ao definirmos um padro para o documento de requisitos representamos um
formato e as informaes necessrias para um determinado domnio. Alm disso, no
54
deixamos de representar as informaes que um determinado usurio gostaria de

encontrar neste documento. Como resultado os clientes (internos) tambm podem
adotar as mesmas prticas representadas, dando continuidade ao nvel de qualidade
inicialmente estabelecida.
Processo
Produto
Melhorias
Medies
Figura 8.2: Relao entre mtricas de processo e produto

Padres devem ser fceis de serem seguidos, e verificados, em termos de tempo
e custo. Muitas vezes nos deparamos com situaes nas quais os padres
estabelecidos levam os desenvolvedores a um desperdcio de tempo e esforo para a
sua realizao. Como resultado, eles no so seguidos e todo o esforo para implantar
um programa de qualidade pode ser perdido.
Mas, ento cada organizao estabelece os seus padres? No existe uma
diretriz para que esses padres sejam estabelecidos e seguidos? Existe sim. Ao
desenvolver padres as empresas devem se basear em determinaes de
organizaes nacionais e internacionais. O IEEE (Institute of Electrical and Electronics
Engineers) uma organizao que determina alguns padres para o desenvolvimento
de software, por exemplo, o padro IEEE 829 para a documentao de testes de
software.
Padres de processos e de produtos esto fortemente relacionados. Ao
estabelecermos um processo, que representa as melhores prticas da organizao que
desenvolve software, podemos avali-lo conforme as mtricas estabelecidas. Por
exemplo, o custo para a sua execuo, o seu tempo de execuo, entre outras. Esses
processos padronizados podem gerar produtos tambm padronizados. Mtricas de
produtos tambm podem ser estabelecidas com o objetivo de determinar a sua
qualidade. Por exemplo, a quantidade de defeitos encontrados em um cdigo na
realizao de um teste. Ao confrontarmos os resultados das medies realizadas no
processo e nos produtos resultantes da sua execuo, possvel avaliarmos a
efetividade deste processo, e identificarmos as suas fraquezas e foras. Como
resultado, ajustes podero ser realizados no intuito de melhorar os produtos gerados.
55
Portanto, medies podem ser utilizadas para realizar estimativas e aperfeioamentos

no processo.
Mas, como podemos aperfeioar um processo? Atravs de atributos especficos
como, por exemplo, o tempo mdio para aliberao de um artefato para testes, o
nmero de defeitos encontrados em um produto pode significar que o processo de
reviso no foi adequadamente conduzido, entre outros indicadores. Entretanto, uma
atividade de melhoria de processo no to simples quanto parece, pois nem sempre
as mtricas so facilmente coletadas e relacionadas s atividades de processo que
conduziro
um
aperfeioamento.
Muitas
vezes
os
prprios
analistas
desenvolvedores no entendem a necessidade de se fazer uma coleta de mtricas e,

naturalmente, criam uma resistncia.
8.2
Garantia e Padres de Qualidade

A relao entre processo e produto, que acabamos de discutir, est associada ao
conceito de Garantia da Qualidade. De uma forma geral, ela estabelece os padres de

processo e de produto. As atividades podem ser apoiadas por ferramentas
computacionais com o objetivo de auxiliar na coleta de dados e na avaliao das
medies realizadas. Ao definirmos padres de processos, portanto, buscamos garantir
que os padres de produtos sero obtidos. Cabe ao processo de garantia da qualidade
verificar se esses padres esto de acordo com as especificaes. Atravs deste
processo asseguramos que as melhores prticas da Engenharia de software sero
seguidas, bem como a produtividade da equipe de desenvolvimento poder ser
acompanhada e constantemente melhorada. Como resultado, os custos do processo
podero ser reduzidos.
Mas, por que padronizar processos? No bastaria conhec-lo atravs, por
exemplo, de sua modelagem em uma linguagem grfica? Ao padronizar processos, e
definir as medies efetuadas, estamos representando no apenas as melhores
prticas de desenvolvimento para um contexto especfico da organizao, mas
assegurando que todos seguiro as mesmas prticas em diferentes projetos. Mais
ainda, que as atividades relacionadas a todos os projetos podero ser acompanhadas
por um conjunto de medies, evitando assim a repetio de erros em novos projetos.
Entretanto, no basta apenas representar um processo atravs de uma linguagem
56
grfica. O gerenciamento da qualidade vai alm da definio de padres de processo e

produto, como veremos a seguir.
Exemplos de padres de processos podem ser encontrados em

http://demoiselle.sourceforge.net/process/ds/1.2.3-BETA1/
O gerenciamento da qualidade envolve a definio de padres de processo e de

produto, bem como o acompanhamento contnuo dos processos de desenvolvimento.
Atravs deste acompanhamento, mtricas so estabelecidas e resultados so
analisados buscando uma melhoria contnua em busca da qualidade dos produtos. Os
resultados so relatados para a gerncia e para os clientes (Sommerville, 2011).
8.3
Planejamento de Qualidade
O planejamento da qualidade envolve as atividades que tm por objetivo definir
um plano de qualidade que contemple as qualidades para o produto, bem como a

forma pela qual elas sero avaliadas. Mas, o que qualidade? Diz respeito aos
atributos prioritrios para um projeto especfico, aqueles que tm uma importncia para
o contexto no qual ele ser aplicado. Portanto, se o contexto modifica ento cada plano
deve selecionar processos especficos, bem como atributos e a forma pela qual eles
sero avaliados. Dentre esses atributos cabe mencionar: segurana, eficincia,
escalabilidade, entre outros.
Garantia de
Qualidade
Controle de
Qualidade
Planejamento da
Qualidade
Definio de padres
de processo e de
produto
Definio de padres
de processo e de
produto
Verificao da
aderncia aos
padres
Figura 8.3: Etapas da gerncia da qualidade
57
8.4
Controle de Qualidade
Envolve os processos de verificao de que os padres esto sendo utilizados.
Uma maneira de verificarmos se os artefatos gerados durante o processo de

desenvolvimento esto aderentes aos padres definidos atravs de revises e
inspees de software. O processo de reviso envolve as atividades que tem por
objetivo descobrir erros, falhas e omisses em relao aos padres definidos. Com
isso, diferentes artefatos podem estar envolvidos neste processo, tais como:
documentos de especificao, artefatos de projeto, cdigos, planos de teste, entre
outros. Ao se descobrir alguma no conformidade decises podem ser tomadas e
melhorias definidas buscando-se aprimorar a qualidade dos produtos.
As atividades de inspees buscam identificar erros e defeitos nos programas.
Envolvem atividades tais como, identificao de variveis no adequadamente
nomeadas e inicializadas, parmetros que esto indevidamente utilizados e fora de
ordem. Enfim, ao buscar no conformidades, as atividades de inspees procuram
antecipar a identificao de erros que s poderiam ser identificados posteriormente nos
testes. Como resultado, muitos defeitos so descobertos mais cedo promovendo
ajustes e melhorias que comprometeriam a qualidade se descobertos apenas na etapa
de testes unitrios ou de integrao, por exemplo.
Pesquise outros tipos de inspees que poderiam ser realizadas em

um processo de garantia de qualidade.
8.5
Melhoria de Processos
Mesmo que os processos sejam padronizados h necessidade de evolu-los e

modific-los para atender as exigncias e foras de mercado para que o produto
continue competitivo. Evoluir um processo significa melhor-lo de acordo com o
contexto (tecnolgico, organizacional, entre outros tipos) e as prioridades da empresa
que desenvolve software. Para tanto, necessrio, inicialmente, compreend-lo para
que as atividades, recursos, e produtos possam ser modificados em direo
qualidade, produtividade e aos baixos custos.
58
Anteriormente discutimos a relao produto e processo buscando apresentar a

relao entre esses dois fatores. Entretanto, no podemos transpor os efeitos desta
relao, que existe na indstria de manufatura, para a produo de software. Ao
falarmos de software, estamos nos referindo a um produto intangvel. No construmos
software da mesma forma que desenvolvemos um produto na indstria de manufatura.
Existem, portanto, outros fatores que interferem diretamente na produo de software.
So eles: a tecnologia envolvida, os recursos humanos disponveis, os custos e o
cronograma para liber-lo, entre outros.
Figura 8.4: Exemplo de fatores que influenciam a gerncia da qualidade

Em alguns projetos, um fator ter um peso maior do que outro. Por exemplo, para
um projeto pequeno, com uma equipe reduzida, um processo bem definido no
garantia de qualidade de produto. Neste contexto, a habilidade, a experincia e o
conhecimento tcnico da equipe pode ter um efeito maior nos resultados (Sommerville,
2011).
Pesquise por que, em projetos grandes, que envolvem uma quantidade

significativa de mdulos, nos quais as equipe esto geograficamente
distribudas, o processo um fator importante para a qualidade dos
artefatos de software?
Mas, qual o significado de melhoria de processo? muito simples dizermos que

um processo precisa ser melhorado. Entretanto, necessitamos de uma teoria que apoie
as atividades necessrias para que possamos obter resultados satisfatrios. Por
59
exemplo, precisamos identificar que o processo no est adequado, ao mesmo tempo,

necessitamos analisar as informaes obtidas e tomar as devidas aes para modificar
o processo.
Portanto, no existe um processo padro de desenvolvimento de software que
possa ser reutilizado em diferentes processos, nem mesmo existem regras que possam
nortear a modelagem de um processo que gere artefatos com qualidade. Existem sim,
boas prticas de desenvolvimento de projeto e de programao que podem ser
adaptadas s organizaes e aos tipos de projeto. Alm dos tipos de projeto, do seu
tamanho, cada organizao tem as suas caractersticas que muitas vezes impedem
utilizar um processo complexo. Mesmo se uma pequena empresa desenvolvesse o
mesmo tipo de software, os processos devem ser adaptados aos diferentes contextos
envolvidos.
As atividades de Melhoria de Processos esto relacionadas s definies dos
atributos que nortearo os esforos e os recursos necessrios. Processos possuem
alguns atributos, tais como (Sommerville, 2011): capacidade de compreenso,
aderncia aos padres, confiabilidade em relao aos erros que podem influenciar a
qualidade do produto, capacidade do processo evoluir, agilidade para entregar um
produto, entre outros. De uma forma geral, ao identificarmos as melhorias dos
processos estamos relacionando as mtricas associados aos seus atributos. Em
seguida, com base nos resultados obtidos anlises so realizadas e modificaes so
implementadas nos processos com o intuito de otimizar as suas caractersticas
prioritrias.
No possvel tratar de todos os atributos no sentido de otimiz-los. Portanto,
fundamental definirmos aqueles que so prioritrios para um determinado contexto. A
articulao entre eles tambm um desafio que necessita ser devidamente
compreendida e tratada.
Podemos ento, concluir que as atividades de melhoria de processos envolvem a
medio dos atributos prioritrios para a organizao , e a avaliao do processo
tendo como base os atributos obtidos. A partir da atividade de anlise, as fraquezas
so identificadas e as mudanas so implementadas. Suponha, por exemplo, que em
um processo de desenvolvimento, a agilidade para a concluso do processo e a
entrega do sistema seja um atributo prioritrio. Esta prioridade foi identificada
60
considerando-se os elementos de contexto no qual o projeto est inserido, tais como,

as exigncias do mercado e dos clientes. Diante disto, algumas medidas foram
realizadas e os resultados obtidos conduziram os gerentes a adotarem aes para
melhorar o processo de implementao com o objetivo de acelerar as entregas dos
artefatos.
8.5.1. Modelos para Melhorias de Processos
Existem diferentes modelos para avaliar a maturidade dos processos das

organizaes que desenvolvem software. O Instituto de Engenharia de Software (SEI Software Engeneering Institute) uma organizao que estabeleceu modelos para
avaliar esta maturidade. O CMMI (Capability Maturity Model Integration) um exemplo
de modelo cujo objetivo integrar outros modelos de maturidade. Possui duas
instncias. So elas: por estgio e contnua. A primeira compatvel com o modelo
anterior ao CMMI, cujos nveis variam de 1 a 5 (Inicial, Repetitivo, Definido,
Gerenciado, e Otimizado). Cada nvel oferece algumas reas chave do processo que
permitem o acompanhamento da maturidade em termos de atividades realizadas. Por
exemplo, no nvel 2, de uma forma geral, o foco est na verificao da repetio
contnua de tarefas. Para tanto, so analisadas as seguintes reas chave de processo:
Gerenciamento de requisitos, Planejamento de projetos de software, Superviso e
rastreamento do projeto de software, Gerenciamento de subcontratao, Garantia da
qualidade, e Gerenciamento de configurao.
A segunda instncia do CMMI contnua oferece um nvel de detalhamento
maior entre as reas de processo. Desta forma, 22 reas com uma escala associada
de 0 a 5. Essas reas so distribudas entre as seguintes categorias: gerenciamento de
processos (5 reas de processo), gerenciamento de projetos (6 reas de processo),
engenharia (6 reas de processo), suporte (5 reas de processo). Por exemplo, para a
categoria Engenharia so definidas as seguintes reas de processo: gerenciamento de
requisitos, desenvolvimento de requisitos, soluo tcnica, integrao de produto,
verificao, e validao.
61
Outras reas de processo, bem como uma descrio mais detalhada sobre
cada uma delas pode ser encontrada em http://www.sei.cmu.edu/
O MPS-BR (Melhoria de Processo do Software Brasileiro) um modelo para

avaliar a qualidade dos processos de empressas brasileiras. dividido em 7 nveis, e,
para cada nvel, atribudo um perfil de processos.
Uma descrio mais detalhada sobre o Modelo de Melhoria de Processo do

Software Brasileiro, bem como os manuais e guias que descrevem as
atividades recomendadas podem ser encontrados em http:
www.softex.br/mpsbr/.
Em relao ao MPS-BR, podemos afirmar que ele permite uma implementao

gradual em empresas de pequeno e mdio porte.
(1) Considerando o conceito de padres de produto e a importncia para a
determinao de padres de processo, exemplifique um padro de um produto e
relacione com um processo ressaltando a importncia neste contexto.
Resposta: Padres de comentrios para uma classe no desenvolvimento orientado

a objetos podem reduzir o esforo de aprendizagem para um trabalho de
manuteno que dever ser realizado posteriormente no cdigo.
(2) O contexto no qual o processo executado tambm pode influenciar a relao

entre o processo e os resultados gerados. Considere, por exemplo, um processo
de implementao de software e exemplifique, pelo menos, dois aspectos de
contexto que poderiam alterar os resultados obtidos.
Resposta: Nem todo processo pode ter um impacto positivo nos resultados. Por
exemplo: um processo de inspeo pode reduzir o esforo e custo de teste, mas,
por outro lado, pode aumentar o tempo de desenvolvimento devido s reunies.
62
Exerccios
(1) Pesquise outros padres que podem auxiliar no gerenciamento da
qualidade de software.
(2) Cite pelo menos trs tipos de inspees e justifique a sua adoo em um
processo de verificao de inspeo.
(3) Considerando os stakeholders e a caracterstica intangvel do software,
por que no podemos afirmar que a qualidade est associada
verificao dos requisitos previamente especificados.
(4) Defina dois atributos de qualidade, pesquise o seu significado, e
determine a forma pela qual eles sero avaliados em um plano de
qualidade de software.
(5) Alm dos atributos apresentados no corpo do texto, pesquise um
atributo de processo e apresente a forma pela qual ele pode se
relacionar com a melhoria do processo.
(6) Escolha uma etapa do processo de desenvolvimento, e um processo
para a produo de um artefato. Em seguida, identifique um atributo

prioritrio associado ao processo e justifique a sua escolha no contexto
de uma organizao.
(7) O processo de gerenciamento de configurao pode ser considerado
como parte do processo de gerenciamento da qualidade. De que forma

tais processos se relacionam?
(8) O modelo CMMI apresenta algumas vantagens em relao ao modelo
anterior (CMM). Dentre elas, podemos citar a possibilidade de

integrao com outros modelos, tais como: gesto de recursos
humanos, aquisio de software e engenharia de sistemas. Comente
esta afirmao e apresente as vantagens desta integrao.
63
9. Planejamento e Gerenciamento de Software
Este captulo tem como objetivo apresentar uma viso geral do planejamento e
programao de projetos, bem como discutir alguns apectos sobre estimativa de
preo de um software no contexto de gerenciamento de projetos. Ao trmino
deste captulo, o leitor deve ser capaz de compreender a importncia desses
conceitos para a construo de software.
9.1
Introduo
Um projeto de desenvolvimento de software pode iniciar de diferentes maneiras.
Dentre elas cabe citar: a necessidade de adaptar um sistema existente s novas

tecnologias, a necessidade de corrigir um defeito em decorrncia de mudanas
inadequadas, a necessidade de evoluir as funcionalidades para atender a um
determinado mercado ou cliente, ou ento a necessidade de criar um novo produto.
Para tanto necessrio planejar projetos e programar as atividades para que elas
aconteam no momento previsto, considerando-se diferentes aspectos, tais como o
custo, o prazo de entrega os recursos disponveis, dentre outros. O planejamento diz
respeito diviso das atividades e associao aos recursos necessrios para o
projeto. Alm disso, nesta etapa cabe prever no apenas os riscos, e definir formas
para mitig-los, bem como os eventuais problemas que podem ocorrer com o objetivo
de planejar as solues. A partir de um plano de projeto, avaliaes e
acompanhamentos frequentes podem ser realizados com o objetivo de cumprir as
metas e os cronogramas previstos.
O planejamento de projeto no acontece apenas nas etapas iniciais, mas tambm
ao longo do seu desenvolvimento quando necessitamos rever os recursos reais que
sero utilizados. Segundo Sommerville (2011), necessitamos de um plano de projetos
em trs etapas distintas do projeto. Inicialmente, ao propor um oramento do projeto
so previstas algumas atividades e uma estimativa necessria para propor um custo
inicial. Posteriormente, ao iniciar o projeto, as atividades, os recursos, os custos e os
prazos so revistos, bem como as entregas so planejadas e acordadas entre os
stakeholders. Durante o desenvolvimento do produto, cabe rever os prazos a partir do
momento em que novas informaes so adquiridas, e mudanas so solicitadas pelos
64
stakeholders, como resultado, negociaes so necessrias e novas estimativas

ocorrero. Mais ainda, cabe rever a programao das atividades, bem como o
cronograma inicialmente acordado.
9.2
Estimativa de preo do software

Ao iniciarmos um projeto de desenvolvimento de software, uma das primeiras
perguntas que fazemos qual o preo que devemos atribuir para este produto?.
Muitas vezes os desenvolvedores se enganam ao associar o preo apenas aos custos
de desenvolvimento, por exemplo, tempo estimado para o desenvolvimento vezes o
valor da hora de trabalho de um analista, mais o lucro desejado. Entretanto, no a
forma adequada para o clculo do preo do produto, principalmente quando estamos
tratando de um sistema complexo, que utiliza uma quantidade significativa de
ferramentas e abordagens para a melhoria da qualidade do sistema. Podemos afirmar
ento que um dos fatores que influenciam diretamente na composio do preo do
produto est relacionado aos requisitos (funcionais e no funcionais), e forma pela
qual eles so apresentados ao desenvolvedor.
Mas, cabe aqui uma pergunta: dependendo do modelo de processo utilizado, no
temos uma viso geral, completa, dos requisitos. No modelo incremental, por exemplo,
o produto ir evoluir conforme o conhecimento dos requisitos, do processo de negcios
e do domnio. Neste caso, como podemos realizar uma estimativa do produto? Muitas
vezes a estimativa deve ser baseada no conhecimento prvio do domnio da aplicao,
ou ento nas informaes obtidas em um nvel de detalhamento nem sempre
suficiente. Com o andamento do projeto, novas estimativas devem ser feitas e um
replanejamento se faz necessrio. Existe, portanto, uma probabilidade de apresentar
um custo irreal, mas devemos buscar a utilizao de tcnicas que nos levem a uma
estimativa razovel para compor o custo do software.
Suponhamos que uma empresa deseja desenvolver um sistema de administrao
escolar e que ela ainda no tem exatamente os requisitos necessrios para este
sistema. O desenvolvedor estima um valor com base no seu conhecimento e na sua
experincia, bem como no oramento que a escola possui. Posteriormente,
negociaes sero necessrias para que, de posse dos requisitos, as funcionalidades
65
essenciais sejam implementadas e as entregas realizadas. Requisitos levantados e

acordados podem ser acrescentados ao sistema aps um novo oramento.
Ao compor o custo de um software devemos considerar todos os fatores capazes
de nos proporcionar uma estimativa mais otimista. Inicialmente, somos levados a
considerar apenas os esforos de desenvolvimento dos artefatos. Entretanto, para
calcular o custo de um produto necessrio considerarmos os custos dos stakeholders
envolvidos, os custos relacionados a alugueis, equipamentos, treinamentos, entre
outros.
Figura 9.1: Composio do preo de um software

Alm desses fatores, Sommerville (2011) acrescenta alguns outros que podem
indiretamente afetar a composio do preo do produto. Por exemplo: (i) caso o
sistema possua requisitos que mudam com frequncia, a organizao poder reduzir o
custo e, medida que novos requisitos forem solicitados, novos preos so acordados;
(ii) o cdigo-fonte pode no ser entregue ao cliente e reutilizado em outros projetos
pelo desenvolvedor, reduzindo assim o custo; (iii) a organizao pode reduzir o custo
no sentido de conquistar o mercado e gerar oportunidades de expanso; e (iv) em
decorrncia da situao financeira da organizao e do momento em que o mercado se
encontra, pode ser vantajoso reduzir os lucros para garantir um contrato. Enfim, so
diversos fatores que compem o custo de um software. No objetivo da disciplina,
abordar exaustivamente as diferentes tcnicas e modelos para estimar o esforo de
desenvolvimento e os custos envolvidos.
66
Modelos e tcnicas para a estimativa de esforo e custo podem ser

encontradas em:
(1) BOEHM, B., 2000, COCOMO II Model Definition Manual, Center for
Software Engineering, University of Southern California, Disponvel em:
<http:// csse.usc.edu/csse/research/COCOMOII/cocomo2000.0/
CII_modelman2000.0.pdf>.
(2) VAZQUEZ, C. E., SIMES, G. S., ALBERT, R. M., 2013, Anlise de pontos
de funo: medio, estimativas e gerenciamento de projetos de

software. 13. ed. So Paulo: rica.
9.3
Plano de projeto
Planos de projeto so documentos que contm os registros das atividades que
sero realizadas, bem como os recursos necessrios e disponveis, as pessoas

envolvidas e que esto associadas a alguma atividade, e o cronograma para a
realizao do projeto. Marcos e produtos a serem entregues tambm so
especificados. Adicionalmente, este documento deve conter os riscos que porventura
aconteam e as formas para gerenci-los.
Segundo Sommerville (2011) um plano de projeto pode conter a seguinte estrutura:

1. Introduo (objetivo e restries)
2. Organizao de Projeto (equipe de desenvolvimento, pessoas e papis)
3. Anlise de riscos (riscos e estratgias para e reduo)
4. Requisitos necessrios de hardware e software
5. Estrutura analtica (diviso do trabalho em atividades, identificao dos
marcos, e os produtos a serem entregues)
6. Programao do projeto (dependncias entre as atividades, tempo para
atingir cada marco e a alocao das pessoas)
7. Mecanismos de monitoramento e de elaborao de relatrios.
Associado a um plano de projeto, podemos encontrar os seguintes planos: (i)

plano de qualidade, contendo as polticas, procedimento e padres adotados pela
67
organizao; e (ii) plano de gerenciamento de configurao, descrevendo os

procedimentos e polticas para o gerenciamento de configurao, entre outros.
Pesquise outros planos que poderiam estar associados ao plano de projeto,

no sentido de definir, claramente, as atividades, as polticas adotadas, e os
requisitos necessrios para que o mesmo seja bem sucedido.
Durante o tempo do projeto eventos negativos para que as atividades sejam bem
sucedidas podem ocorrer, tais como: um equipamento no foi entregue no momento
previsto, oramento do projeto foi reduzido, demisses ocorreram, entre outros. Tais
eventos podem significar um risco para o projeto e, portanto necessitam ser
devidamente monitorados e mitigados. Eles podem afetar tanto a programao prevista
quanto a qualidade dos artefatos gerados. Portanto, medidas so necessrias para
evit-los.
Por que o gerenciamento de riscos importante para o projeto? Eles devem
receber toda a ateno necessria para que as entregas sejam realizadas conforme
planejadas, bem como para que os produtos sejam desenvolvidos a acordo com os
padres e procedimentos de qualidade adotados.
Diversos fatores podem gerar riscos para um projeto, tais como: (i) mudana de
tecnologia; (ii) descontinuidade de um processo organizacional; (iii) descontinuidade do
suporte de um fornecedor de uma ferramenta de apoio ao desenvolvimento de
software; (iv) requisitos que modificaram; e (v) estimativas incorretas.
Identificao
Anlise
Planejamento
Monitoramento
Figura 9.2: Etapas do gerenciamento de projetos

Aps a identificao, cada risco deve ser analisado considerando probabilidade
de ocorrncia no contexto do projeto. Entretanto, este contexto se modifica, bem com a
probabilidade e efeitos. Por exemplo, um analista de sistemas, especialista em uma
tecnologia pode sair do projeto tanto no incio do cronograma quanto no final do
projeto. Porm, a sua sada no incio no ter o mesmo impacto do que na reta final do
projeto. A probabilidade de ocorrncia tambm deve ser levada em considerao
diante do contexto, da motivao, do salrio e benefcios, entre outros fatos.
68
O prximo passo do gerenciamento de riscos diz respeito ao planejamento. Esta

etapa define as estratgias para gerenciar aqueles riscos prioritrios, considerados
mais importantes diante do contexto em que o projeto se encontra. Por exemplo, como
devemos proceder se, por acaso, um determinado equipamento apresentar um defeito?
Para tanto, um plano de contingncia descrevendo todas as aes necessrias deve
ser criado e, frequentemente avaliado. Alm de um plano de contingncia outras
estratgias so frequentemente encontradas na literatura de gerenciamento de
projetos. Dentre elas cabe citar, a estratgia de sobreposio de tarefas. Atravs desta
estratgia, os riscos de se perder um membro do projeto, considerado chave para a
atividade que est em andamento, podem ser avaliados e as tarefas podem ser
executadas por dois participantes com o intuito de minimizar esses riscos.
Aps analis-los e estabelecer uma estratgia para mitig-los, os riscos devem
ser constantemente monitorados ao longo do projeto. Esta atividade busca evidncias
para antecipar a ocorrncia de um evento (negativo) que possa se materializar em um
risco. Por exemplo: atrasos constantes nas entregas de equipamentos fornecidos por
um determinado fabricante devem ser monitorados, pois, caso seja necessria uma
entrega de emergncia no certo que podemos contar com este fabricante. Outro
exemplo: motivao baixa da equipe pode significar solicitaes de desligamento, ou
ento atrasos no cronograma.
Caso algum risco no seja tratado problemas graves podem acontecer a ponto de
influenciar o andamento do projeto. Muitas vezes, renegociaes de prazos e entregas
so necessrios no apenas em decorrncias dos eventos negativos (riscos) que no
foram devidamente monitorados, mas tambm das aes de mitigao no foram
eficazes. Como resultado, cronogramas devem ser revistos e renegociados.
Entretanto, durante o desenvolvimento do projeto uma srie de eventos podem ter
alterado os objetivos organizacionais, os requisitos inicialmente acordados, e as
prioridades da organizao. Tais eventos podem at mesmo exigir mudanas severas
nas atividades do projeto resultando em outro projeto, ou ento na sua interrupo.
69
9.4
Programao de projeto
A partir do momento que as tarefas so planejadas cabe decidir sobre a

organizao das mesmas, bem como a forma pela qual elas sero executadas. Tarefas
so dependentes de outras e um atraso na execuo de uma tarefa pode acarretar em
um replanejamento do cronograma. Certamente esta no o nico motivo pelo qual
um cronograma pode ser modificado. Caso o plano de projeto seja alterado, novos
requisitos seja elicitados, h uma necessidade de se modificar o cronograma. Portanto,
independente do modelo adotado e do conhecimento adquirido nas etapas iniciais de
projeto, um cronograma necessrio para que o acompanhamento das atividades
possa ser realizado.
Nesta etapa de programa o de projetos tempo e recursos so estimados e as

atividades so organizadas em um conjunto de diagramas, cada um oferecendo uma
visualizao diferenciada. Para tanto, o processo de programao ocorre da seguinte
maneira (Sommerville, 2011): a partir dos requisitos de software as atividades so
identificadas, bem como as suas dependncias. Associada a cada atividade
normalmente procuramos informar o seu tempo estimado de durao, o nmero de
pessoas para realiz-las, e a data de trmino. Em seguida, cabe estimar os recursos
para que elas possam ser bem sucedidas e alocar as pessoas que executaro cada
atividade. Por fim, diagramas so criados de acordo com as necessidades de
visualizao do cronograma. So exemplos desses diagramas: (i) grficos de barras,
tambm denominados grfico de Gantt; e (ii) redes de atividades.
Pesquise exemplos de grficos de barras e grficos de Gantt para

ilustar o cronograma de um projeto.
70
Exerccios
(1) Ao se planejar um projeto de software marcos devem ser estabelecidos,
bem como os produtos a serem entregues devem ser definidos. Com
base nesta afirmao, discuta a importncia da definio de marcos e de
produtos no planejamento e no gerenciamento de projetos de software.
Utilize um exemplo para ilustrar a sua resposta.
(2) Considerando os fatores que podem compor os custos de um projeto de
software, descreva outros fatores, alm daqueles que foram
mencionados no corpo do texto, que podem influenciar o preo do
produto.
(3) Para cada fator identificado no corpo do texto, que pode gerar um risco
para o projeto, exemplifique uma situao associada a um projeto de
desenvolvimento de um sistema de administrao escolar.
(4) Alm dos fatores apresentados no texto, identifique outros fatores de
risco e exemplifique com uma situao para ilustr-lo.
(5) Identifique dois riscos para um projeto de desenvolvimento de software,
analise a sua probabilidade de ocorrncia e estabelea uma estratgia
para mitig-los.
71
Referncias Bibliogrficas
PRESSMAN, R., 2011, Engenharia de Software: Uma Abordagem Profissional,
7. ed. , McGraw-Hill.
SOMMERVILLE, I., 2011, Engenharia de Software, 9.ed., So Paulo: Pearson
Prentice Hall.
SAMETINGER, J., 1997, Software Engineering with Reusable Components,
Springer-Verlag.
Eclipse.org. Site oficial do ide eclipse. Disponvel em: http://www.eclipse.org/.
Acesso em: maro de 2013.
NetBeans.org. Site oficial do ide netbeans. Disponvel em:
http://www.netbeans.org/. Acesso em: maro de 2013.
Software Engineering Institute Disponvel em: http://www.sei.cmu.edu/. Acesso
em: abril de 2013.
MPS.BR - Melhoria de Processos do Software Brasileiro Disponvel em:
www.softex.br/mpsbr/. Acesso em abril de 2013.
72

Engenharia de Software

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Engenharia de Software

Transféré par

Droits d'auteur :

Formats disponibles

Direitos: Esta obra foi disponibilizada sob uma Licena Creative Commons Atribuio Uso no-comercial

Universidade Federal de Juiz de Fora

Jos Maria Nazar David.

Processos de Software ...........................................................................................................10

Modelo em Cascata ........................................................................................................11

O Processo Unificado (RUP)............................................................................................11

O Modelo Evolucionrio .................................................................................................14

Engenharia de Requisitos de Software ..................................................................................17

O Processo de Engenharia de Requisitos .......................................................................19

Gerenciamento de requisitos .........................................................................................24

Projeto de Sistemas ...............................................................................................................27

Alguns conceitos de projeto de software.......................................................................30

Reutilizao de software ................................................................................................36

Teste de Software ..................................................................................................................44

Testes Unitrios ..............................................................................................................46

Testes de Sistema ...........................................................................................................47

Manuteno e Evoluo de Software ....................................................................................49

Transformao de Arquitetura .......................................................................................51

Garantia e Padres de Qualidade...................................................................................56

Planejamento de Qualidade ...........................................................................................57

Melhoria de Processos ...................................................................................................58

Planejamento e Gerenciamento de Software .......................................................................64

Estimativa de preo do software....................................................................................65

Plano de projeto .............................................................................................................67

EADDCC032 Fundamentos de Engenharia de Software

EADDCC032 Fundamentos de Engenharia de Software

(1) Pesquise, pelo menos, dois motivos pelos quais ainda se

Esta apostila est organizada da seguinte forma: o prximo captulo apresenta

EADDCC032 Fundamentos de Engenharia de Software

EADDCC032 Fundamentos de Engenharia de Software

Este captulo tem como objetivo discutir o conceito de processos de software,

Processos podem ser caracterizados como um procedimento ou uma poltica para

EADDCC032 Fundamentos de Engenharia de Software

O ciclo de vida em cascata parte do princpio de que as etapas de especificao

O Processo Unificado (RUP)

O objetivo deste modelo de processo foi unificar as abordagens previamente

EADDCC032 Fundamentos de Engenharia de Software

fases correspondem ao tempo. o aspecto que se relaciona dinmica do processo.

Organizao ao longo do contedo

Organizao ao longo do tempo

Figura 2.1: Fases e disciplinas do RUP

EADDCC032 Fundamentos de Engenharia de Software

Na fase de Elaborao, alguns objetivos so bem definidos, tais como: os

EADDCC032 Fundamentos de Engenharia de Software

componentes so responsveis, em parte, pela facilidade de evoluo, pela qualidade

Krutchen, P., 2003, The Rational Unifies Process An

Neste modelo os artefatos so produzidos gradativamente, conforme o

EADDCC032 Fundamentos de Engenharia de Software

desenvolvimento. O primeiro deles diz respeito visibilidade do processo. Sem um

previamente, bem definidos e no eram estveis. Ou seja, modificaes

EADDCC032 Fundamentos de Engenharia de Software

papeis. De que forma eles se relacionam em um processo de

EADDCC032 Fundamentos de Engenharia de Software

3. Engenharia de Requisitos de Software

Este captulo tem como objetivo apresentar o processo de Engenharia de

Sistemas so desenvolvidos de acordo com as necessidades dos usurios e das

EADDCC032 Fundamentos de Engenharia de Software

Figura 3.1: Relacionamento entre requisitos

EADDCC032 Fundamentos de Engenharia de Software

No processo de Engenharia de Requisitos diferentes artefatos so gerados. So

O Processo de Engenharia de Requisitos

Diferentes autores propem um processo para a Engenharia de Requisitos. No

Figura 3.2: Etapas da Engenharia de Requisitos

(i) Estudo de Viabilidade