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 parte-se 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

2.1 Introduo ......................................................................................................................10

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

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

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

3. 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

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

4.1 Introduo ......................................................................................................................27

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

5. Implementao ......................................................................................................................35

5.1 Introduo ......................................................................................................................35

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

5.3 Gerenciamento de Configurao....................................................................................38

6. 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

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

7.1 Introduo ......................................................................................................................49

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

7.3 Reengenharia..................................................................................................................51

8. 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

9. 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

7

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.


8

(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.


9

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?


10

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, busca-


11

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


12

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.

(Fonte: http://www.wthreex.com/rup/process/ovu_proc.htm)

Org

aniz

ao

ao

long

o do

con

ted

o

Organizao ao longo do tempo

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.


13

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


14

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.


15

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?


16

(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


17

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


18

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.

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.

Modifica Requisitos Funcionais

Requisitos no Funcionais


19

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.

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

Estudo de viabilidade

Levantamento e anlise de requisitos

Especificao de requisitos

Validao de requisitos


20

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.


21

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


22

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.


23

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.


24

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.

Figura 3.5: Exemplo de uma matriz de rastreabilidade

A1 A2 A3 ... An RF1 RF2 ...

RFn

Exemplos de aspectos: Fontes de requisitos Solicitaes de stakeholders Regras de negcio


25

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.


26

(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?


27

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.


28

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


29

(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.

Figura 4.3: Exemplo de um modelo de dados para o projeto de um BD

Autor

Livro

Editora

Autor

Livro

EditoraPublicadoPublicado

EscreveEscrevecod_autornomenascimento

cod_editorarazaoenderecocidade

titulocod_autorcod_editoravalorpublicacaovolume

cod_autornomenascimento

cod_editorarazaoenderecocidade

titulocod_autorcod_editoravalorpublicacaovolume

(1,1)

(0,1)

(1,N)

(0,N)

(1,1)

(0,1)

(1,N)

(0,N)


30

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, considerando-

se 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


31

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


32

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 , entretanto, percebeu-

se 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.


33

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.


34

(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).


35

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).

Figura 5.1: Elementos de uma IDE

IDE

Editor LP

Depurador Editores Modelos

Testes


36

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 a implementao ser simplificada. Entretanto, os processos

frequentemente encontrados na prtica so aqueles que podemos denominar de ad-

hoc. 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


37

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.

Figura 5.2: Relao entre alguns mdulos de um sistema de administrao escolar

Mdulo de pr-requisitos

Mdulo de excluso de disciplinas

Mdulo de matrcula


38

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.


39

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


40

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.


41

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


42

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.


43

(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.


44

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.


45

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


46

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.


47

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.


48

(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

Engenharia de Software

Documents

Transcript of Engenharia de Software