ES - Engenharia de Software I

ENGENHARIA DE SOFTWARE I
Engenharia de software.indd 1
18/7/2013 17:51:05
Process Black
Conselho Editorial EAD

Dris Cristina Gedrat
Thomas Heimman
Mara Salazar Machado
Andra de Azevedo Eick
Astomiro Romais
Obra organizada pela Universidade Luterana do Brasil.

Informamos que de inteira responsabilidade dos autores a
emisso de conceitos.
Nenhuma parte desta publicao poder ser reproduzida por
qualquer meio ou forma sem a prvia autorizao da Editora
da ULBRA.
A violao dos direitos autorais crime estabelecido na Lei n .610/98
e punido pelo Artigo 184 do Cdigo Penal.
Dados Internacionais de Catalogao na Publicao (CIP)
G216e Garcia, Lus Fernando Fortes.
Engenharia de software I / Lus Fernando Fortes Garcia. Canoas: Ed.
ULBRA, 2013.
104p.
1. Computao. 2. Engenharia de software. 3. Projeto e arquitetura de
software. I. Ttulo.
CDU: 681.3.41
Setor de Processamento Tcnico da Biblioteca Martinho Lutero - ULBRA/Canoas
ISBN 978-85-7528-490-2
Editorao: Roseli Menzen
Dados tcnicos do livro
Fontes: Palatino Linotype, Franklin Gothic Demi Cond
Papel: oset 75g (miolo) e supremo 240g (capa)
Medidas: 15x22cm
18/7/2013 17:51:20
Process Black
APRESENTAO
Prezados(a) alunos(a),
Sejam bem vindos(as) a disciplina de Engenharia de Software I.
Esta disciplina apresenta a proposta da rea de Engenharia de Software para
estruturao e organizao do processo de desenvolvimento de software, bem
como a sua rea coirm de Qualidade de Software.
Visa abordar e analisar os principais tpicos relacionados a desenvolvimento
profissional de software, contribuindo para a discusso dos pontos positivos e
negativos de cada conceito.
O objetivo principal da disciplina disseminar o conceito de respeito ao
software, isto , software atualmente importante demais na sociedade para ser
desenvolvido de forma artesanal, sem cuidados e projetos. As consequncias de um
desenvolvimento desleixado so terrveis em termos de perdas em vidas humanas
e perdas financeiras!
So abordados, na parte de Engenharia de Software, conceitos de Processos de
Software, de Engenharia de Requisitos, de Projeto e Arquitetura de Software, Testes
de Software e evoluo/Sistemas Legados.
Na segunda parte do texto, em Qualidade de Software, so apresentados conceitos
relacionados a Qualidade, Qualidade de Software em seus dois aspectos
Qualidade de Produtos de Software e Qualidade de Processos de Software,
bem como discutidos os modelos de Maturidade em Qualidade de Softwares,
representados pelo CMMI e pelo MPS.BR.
Todos os tpicos aqui discutidos tm aplicabilidade na vida prtica de um
profissional de desenvolvimento de software, seja ele um programador, um analista,
um arquiteto ou um testador. O sucesso do processo dado pela integrao correta
e juno de esforos de todos estes profissionais, em conjunto com os clientes/
usurios.
18/7/2013 17:51:20
Process Black
A Engenharia de Software est em constante atualizao e redesenho os Mtodos

geis so um dos exemplos mais claros disso. O estudo continuado da rea
imprescindvel para o seu sucesso profissional!
Um bom trabalho a todos!
Prof. Dr. Lus Fernando Fortes Garcia

Professor/pesquisador na ULBRA/Canoas e Faculdade Dom Bosco de Porto Alegre
Consultor em Carreiras de TI na ofiTIo Consultoria Ltda.
18/7/2013 17:51:20
Process Black
SOBRE O AUTOR
Lus Fernando Fortes Garcia, prof. Dr.
Doutor e mestre em Cincias da Computao pelo Instituto de Informtica da

UFRGS Universidade Federal do Rio Grande do Sul. Professor universitrio e
pesquisador nas reas de Engenharia de Software, Qualidade de de Software e
Governana de TI na ULBRA e Faculdade Dom Bosco de Porto Alegre.
Scio-diretor e consultor em carreiras de TI na ofoTIo consultoria Ltda.
18/7/2013 17:51:20
Process Black
ULBRA Educao a Distncia
18/7/2013 17:51:20
Process Black
SUMRIO
INTRODUO ENGENHARIA DE SOFTWARE .............................................................11

1.1 Computadores e Software .................................................................................11
1.2 Evoluo Histrica do Software ..........................................................................12
1.3 Questes sobre Desenvolvimento de Software .....................................................13
1.4 Enfoques do Desenvolvimento de Software ..........................................................14
1.5 Engenharia de Software .....................................................................................15
1.6 Pirmide da Engenharia de Software ..................................................................17
1.7 Princpios da Engenharia de Software .................................................................18
1.8 Qualidades Desejveis em um Software ..............................................................19
Atividades .............................................................................................................20
PROCESSOS DE SOFTWARE......................................................................................23
2.1 Processos e Software ........................................................................................23
2.2 Modelos de Processos de Software .....................................................................24
2.3 Modelo Cascata ................................................................................................24
2.4 Modelo Evolutivo ou Evolucionrio ......................................................................28
2.5 Modelo Iterativo Incremental...........................................................................29
2.6 Modelo Baseado em Componentes .....................................................................30
2.7 Modelo RUP Rational Unified Process .............................................................31
Atividades .............................................................................................................32
PROCESSO GEIS DE SOFTWARE..............................................................................33

3.1 Processos geis de Software .............................................................................33
3.2 XP Extreme Programming ................................................................................37
3.3 SCRUM .............................................................................................................39
Atividades .............................................................................................................42
ENGENHARIA DE REQUISITOS ..................................................................................43

4.1 Engenharia de Requisitos ..................................................................................43
18/7/2013 17:51:20
Process Black
4.2 Definies de Requisito .....................................................................................45

4.3 Tipos de Requisitos............................................................................................45
4.4 Processo da Engenharia de Requisitos ................................................................47
Atividades .............................................................................................................51
5
PROJETO E ARQUITETURA DE SOFTWARE ..................................................................53

5.1 Projeto e Arquitetura de Software ......................................................................53
5.2 Arquitetura de Sistema .....................................................................................53
5.3 Soluo Tcnica ................................................................................................55
5.4 Reuso em Projeto e Arquitetura de Software........................................................56
Atividades .............................................................................................................58
TESTE DE SOFTWARE ...............................................................................................61

6.1 Contexto atual do Teste de Software ..................................................................61
6.2 Definio de Teste de Software ..........................................................................62
6.3 Provveis defeitos e tipos de falhas ....................................................................63
6.4 Processo de Teste de Software ...........................................................................64
6.5 Classificao dos Teste de Software ...................................................................64
6.6 Tcnicas de Teste de Software ............................................................................65
Atividades .............................................................................................................66
EVOLUO de software ............................................................................................67

7.1 Evoluo de Software .........................................................................................67
7.2 Sistemas Legados..............................................................................................67
7.3 Estratgias em Sistemas Legados .......................................................................69
Atividades .............................................................................................................71
QUALIDADE.............................................................................................................73
8.1 Motivaes no estudo da Qualidade....................................................................73
8.2 Histrico da Qualidade ......................................................................................74
8.3 Definies da Qualidade ....................................................................................75
8.4 Princpios de Qualidade de Deming.....................................................................76
8.5 Ferramentas da Qualidade .................................................................................78
8.6 rgos de Certificao da Qualidade ..................................................................78
8.7 Fatores Humanos na Qualidade ..........................................................................79
8.8 5S na Qualidade ................................................................................................79
Atividades .............................................................................................................80
18/7/2013 17:51:20
Process Black
QUALIDADE DE SOFTWARE.......................................................................................81
9.1 Software ...........................................................................................................81
9.2 Qualidade de Software.......................................................................................82
9.3 Fatores da Qualidade de Software ......................................................................83
9.4 Aspectos da Qualidade de Software ....................................................................84
9.5 Normas da Qualidade de Software ......................................................................85
9.6 Enfoques da Qualidade de Software....................................................................85
Atividades .............................................................................................................89
10 MATURIDADE EM QUALIDADE DE SOFTWARE ............................................................91

10.1 Maturidade em Qualidade de Software .............................................................91
10.2 CMMI .............................................................................................................92
10.3 Nveis do CMMI ...............................................................................................93
10.4 reas Chave do CMMI ......................................................................................96
10.5 Representaes do CMMI ................................................................................97
10.6 Processo de implantao do CMMI ...................................................................98
10.7 SCAMPI avaliao do CMMI...........................................................................98
10.8 MPS.BR ..........................................................................................................98
Atividades ...........................................................................................................101
18/7/2013 17:51:20
Process Black
10
18/7/2013 17:51:21
Process Black
INTRODUO ENGENHARIA
DE SOFTWARE
Este captulo apresenta a grande rea da Engenharia de Software, seu histrico

junto aos desenvolvedores de software ao longo do tempo, alguns questes bsicas
que devem ser consideradas em todos os momentos pelos profissionais, suas
definies, etapas, focos (pirmide da Engenharia de Software), bem como seus
princpios e qualidades desejveis.
O principal objetivo deste captulo apresentar a Engenharia de Software como
uma alternativa prtica e adequada ao correto desenvolvimento de produtos de
software, com o devido respeito que estes produtos de software merecem.
1.1 Computadores e Software

Atualmente tem-se a total e completa onipresena dos computadores e
consequentemente do software em nossas vidas. Eles esto em forma de
computadores de mesa, servidores, notebooks, smartphones, tablets e mesmo
embarcados/embutidos nos mais diferentes aparelhos, desde geladeiras at em
um automvel. Sem eles, no podemos fazer uma ligao telefnica, acender uma
simples lmpada, fazer transaes financeiras, viajar de avio, entre outras coisas
do cotidiano.
Esses mesmos softwares podem ser considerados abstratos, intangveis,
complicados, diferentes, complexos e sem limitaes. Visto que no so regidos
pelas leis da fsica, a princpio no h limites em seu desenvolvimento. A ausncia
de limites, entretanto, fator complicador extremo para seu desenvolvimento.
18/7/2013 17:51:21
Process Black
12
importante ressaltar os inmeros aspectos positivos dos softwares em nossa
sociedade, como aumento de produtividade de uma empresa, velocidade de
processamento de dados e economia de tempo, entre outros. Entretanto quando
h falhas e bugs existem problemas ou aspectos negativos que no podem ser
ignorados:
Quedas de avies;
Desvios de msseis;
Colapsos em centrais telefnicas;
Desvios bancrios.
Para tornar, ento, o software mais confivel, robusto e eficaz, prope-se o estudo
e a aplicao da Engenharia de Software.
1.2 Evoluo Histrica do Software

Para fins de avaliao histrica do software, de seus tipos e de seus processos de
desenvolvimento, pode-se classific-los em 4 grandes geraes. Cada avano de
gerao agrega complexidade e aumento de demanda por software.
1. Gerao 1950 a 1960 Software para sistemas computacionais de grande

porte (Mainframes) com orientao de processamento em lotes (batch), com
distribuio limitada apenas a grandes empresas;
2. Gerao 1960 a 1975 Software para sistemas de mdio porte, com suporte
a acessos multiusurios, de tempo real, e bancos de dados. Nesta gerao,
inicia-se o acesso a softwares por empresas de menor porte;
3. Gerao 1975 a 1990 Software para computadores de pequeno porte

microcomputadores ligados em redes locais. Incio da utilizao por pessoas
fsicas e pequenas empresas, o que aumentou grandemente a demanda;
4. Gerao 1990 a atual Softwares distribudos em todas as reas da

sociedade, extremamente poderosos e complexos (sistemas inteligentes,
distribudos, paralelos), rodando em todos os tipos de dispositivos. Chega-se
ao pico da complexidade e da demanda.
importante ressaltar que a evoluo no para nesta 4. Gerao novas

pesquisas e desenvolvimentos esto sendo realizados em empresas e centros de
pesquisa espalhados por todo o mundo. Estes novos softwares esto cada vez
mais complexos e teis, e por isso precisam ser desenvolvidos com processos
produtivos e controlados.
18/7/2013 17:51:21
Process Black
1.3 Questes sobre Desenvolvimento de Software

O processo de desenvolvimento de software suscita algumas importantes questes
e sua discusso necessria:
Software desenvolvido, no fabricado Software, diferentemente de

outros produtos, como celulares e sapatos, normalmente desenvolvido
sob encomenda para clientes e aplicaes especficas. Cada software tende
a ser, em menor ou maior grau, diferente dos demais. Isso impede que
tcnicas de fabricao em escala (industriais) possam ser utilizadas em seu
desenvolvimento, que poderiam diminuir custos e prazos;
Software no desgasta Software, ao contrrio do hardware em que se pode

facilmente perceber o desgaste de peas e engrenagens no desgasta no sentido
literal da palavra. Entretanto, instalaes de software desgastam ao longo
do tempo, e, portanto, necessitam de manuteno e de reparos. Um exemplo
clssico a instalao de um sistema operacional em um microcomputador;
No incio, tem-se velocidade e estabilidade, mas, com o passar do tempo (e pela
instalao e desinstalao de programas, jogos, etc) a velocidade do sistema
cai e os problemas aparecem, como apresentado na figura 1.1.
13
Figura 1.1 Desgaste em Software.
Indice
de
falhas
Mortalidade
infantil
Desgaste
Tempo
Natureza mutvel do software Esta uma questo central no desenvolvimento

de software. Ao contrrio de outros produtos, em que as mudanas so raras
e, quando existem, so implementadas somente aps exaustivas discusses e
projetos/simulaes como em prdios, estradas e automveis o software
apresenta demandas de alteraes constantes, muitas vezes dirias. Estas
alteraes partem tanto dos clientes, que precisam acompanhar o mercado,
quanto dos governos e rgos de regulao, em formas de novas leis, novos
clculos de impostos e taxas. Portanto raramente pode-se considerar o
desenvolvimento de um software concludo.
18/7/2013 17:51:21
Process Black
14
Uma conferncia da OTAN (Organizao do Tratado do Atlntico Norte) entre 1968
e 1969 cunhou o termo Crise de Software, ao discutir e apresentar questes, na
poca, relacionadas ao desenvolvimento de softwares:
Cronogramas no observados atrasos constantes;
Projetos abandonados;
Mdulos que no operam corretamente quando combinados;
Programas que no fazem exatamente o que era esperado;
Sistemas to difceis de usar e que so descartados;
Sistemas que simplesmente param de funcionar.
importante refletir que passados mais de 40 anos muitos (a maioria) desses

problemas apresentados continuam a existir.
1.4 Enfoques do Desenvolvimento de Software

O desenvolvimento de software pode ser dividido em dois enfoques:
Artesanal;
Engenharia de Software.
O desenvolvimento Artesanal (tambm conhecido por Gambiarra, P.O.G e outros)

baseia-se exclusivamente em habilidades pessoais do desenvolvedor para a
construo do software. Apresenta um processo bastante simplificado, em que
normalmente, aps uma breve conversa do programador com o cliente para a
obteno dos requisitos, iniciada a programao, sem etapas importantes, como
anlise, projeto e testes. Implementa uma tcnica conhecida como tentativa e
erro.
um processo que, apesar de funcionar em alguns casos, muito arriscado para
os padres atuais da indstria de software. Tom de Marco, um dos precursores da
Engenharia de Software, afirma que na falta de padres expressivos, uma nova
indstria, como a de software, passa a depender de folclore.
O desenvolvimento baseado em Engenharia de Software, por sua vez, apresenta
uma abordagem mais sistemtica, produtiva, econmica e organizada do processo
de desenvolvimento, com a aplicao de etapas bem definidas, com documentao
e acompanhamento por profissionais habilitados e especializados em suas tarefas,
sendo estas relacionadas a requisitos, anlise, projeto, programao, testes e
implantao.
18/7/2013 17:51:21
Process Black
1.5 Engenharia de Software

A primeira definio da Engenharia de Software descreve-a como: Estabelecimento
e uso de slidos princpios de engenharia para que se possa obter economicamente
um software que seja confivel e que funcione eficientemente em mquinas reais,
por Fritz Bauer, em 1969.
15
Esta definio muito relevante, porque destaca claramente os aspectos mais

importantes da Engenharia de Software:
Estabelecimento e uso - Ou seja, no adianta definir e estabelecer regras e

processos, mas sim, necessrio seu efetivo uso para a obteno das vantagens
da Engenharia de Software;
Slidos princpios de engenharia - desenvolvimento de software baseado nos

mesmos princpios das engenharias tradicionais civil, eltrica que incluem
projetos, clculos, simulaes e testes;
Se possa obter economicamente Apresenta o maior fator motivador da

implantao da Engenharia de Software o econmico. O objetivo final da
Engenharia de Software produzir produtos com mais qualidade, com mais
produtividade, visando o lucro do desenvolvedor;
Que seja confivel No contexto atual da sociedade, este fator indispensvel

para a sobrevivncia de um software no mercado. Produtos no confiveis so
rapidamente descartados pelos usurios.
O SEI (Instituto de Engenharia de Software da Universidade Carnegie Mellon, USA)

define que Engenharia a aplicao sistemtica de conhecimentos cientficos na
criao e construo de solues com um bom custo-benefcio para a resoluo de
problemas prticos da sociedade.
O IEEE (Instituto de Engenheiros Eletricistas e Eletrnicos, dos Estados Unidos)
define a Engenharia de Software como: Aplicao de uma abordagem sistemtica,
disciplinada e quantificvel para o desenvolvimento, operao e manuteno do
software.
O IEEE edita o SWEBOK (Guide to the Software Engineering Body of Knowledge),
que o corpo de conhecimento que apresenta de forma completa a Engenharia de
Software, suas reas de conhecimento e as suas disciplinas relacionadas.
As reas da Engenharia de Software, segundo o SWEBOK, so:
Requisitos de software;
Projeto de software;
Construo de software;
18/7/2013 17:51:21
Process Black
16
Teste de software;
Manuteno de software;
Gerenciamento de configurao de software;
Gerenciamento de engenharia de software;
Processo de engenharia de software;
Ferramentas e mtodos da engenharia de software;
Qualidade de software.
A rea de Requisitos de Software aborda a elicitao, anlise, especificao e

validao de requisitos de software.
Projeto de Software definido como o processo de definio da arquitetura,
componentes, interfaces e outras caractersticas de um sistema ou componente,
assim como o resultado desse processo.
Construo de software se refere criao detalhada de software relevante e
funcional a partir de uma combinao de codificao, verificao, teste unitrio,
teste integrado e debugging.
Teste de software consiste numa verificao dinmica do comportamento de
um programa em um conjunto finito de casos de teste contra o comportamento
esperado.
Manuteno de software aborda defeitos e novos requisitos durante a operao
do software.
Gerncia de Configurao de Software um processo que envolve a gesto de
projetos, as atividades de desenvolvimento, manuteno e garantia.
A Gerncia de Engenharia de Software pode ser definida como a aplicao de
atividades de gesto - planejamento, coordenao, medio, monitoramento,
controle e divulgao para garantir que o desenvolvimento e a manuteno de
software seja sistemtica, disciplinada e quantificada.
O processo de engenharia de software inclui atividades tcnicas e de gesto dentro
dos processos do ciclo de vida de software. Alm disso, est preocupado com a
definio, implementao, avaliao, gerenciamento da mudana e melhorias nos
prprios processos do ciclo de vida de software.
Ferramentas de desenvolvimento de software so ferramentas baseadas em
computador que apoiam os processos de ciclo de vida de software. Os mtodos
impe uma estrutura na atividade de engenharia de software.
18/7/2013 17:51:21
Process Black
A rea de Qualidade de Software enfoca questes relacionadas qualidade

do software, tanto do produto quanto do processo de desenvolvimento do
software.
As disciplinas relacionadas com a Engenharia de Software, segundo o SWEBOK,
incluem, so:
Engenharia da computao;
Cincia da computao;
Administrao;
Matemtica;
Gesto de projetos;
Gesto da qualidade;
Ergonomia de software;
Engenharia de sistemas.
17
1.6 Pirmide da Engenharia de Software

A Engenharia de Software pode ser representada em forma de uma pirmide (figura
1.2), em que os conceitos mais importantes ficam em sua base e os mais volteis
(e menos importantes) em seu topo.
Figura 1.2 Pirmide da Engenharia de Software
O conceito mais importante no estudo e prtica da Engenharia de Software seu

foco na qualidade, ou seja, o atendimento e satisfao dos desejos e necessidades
do usurio. Esta a razo de ser da Engenharia de Software.
A qualidade garantida pelo uso de processos de desenvolvimento de software
corretos e robustos, com produtividade e eficincia. Estes processos podem ser
ditos tradicionais como modernamente denominados de geis.
Os processos, por sua vez, so implementados atravs de mtodos, que descrevem
como o software deve ser desenvolvido.
18/7/2013 17:51:21
Process Black
18
E, finalmente, as ferramentas so facilitadoras de todo esse processo. Nesta
categoria entram as linguagens de programao, ferramentas de modelagem,
ferramentas de teste, entre outras. So volteis, pois facilmente so superadas e
substitudas por novas e que apresentam melhor desempenho.
1.7 Princpios da Engenharia de Software

A Engenharia de Software, com seu foco em qualidade, baseia-se em uma srie de
princpios, que so declaraes gerais e abstratas, e que descrevem as propriedades
desejadas dos processos de desenvolvimento e de seus produtos relacionados.
Os principais princpios abordam tpicos como:
Rigor e formalismo O processo de desenvolvimento de software uma

atividade baseada fortemente em criatividade e inspirao. O rigor e o
formalismo devem coexistir como forma de complemento a esta criatividade.
As prprias linguagens de programao j aplicam este princpio, visto que
desvios e falhas de codificao no so toleradas pelos compiladores.
Separao de preocupaes Este princpio visa tratar individualmente

de diferentes aspectos de um problema, de forma a concentrar esforos
separadamente. Segundo ele, a nica forma de dominar a complexidade do
projeto separar as preocupaes e decises do projeto. Primeiramente, algum
deve tentar isolar problemas que esto menos relacionados com outros. Como
exemplos desta separao, pode-se considerar regras de negcio e interface.
Modularizao O princpio da modularizao visa primordialmente dividir

a complexidade. Softwares que no so divididos de alguma forma so
considerados monolticos, enquanto softwares baseados em mdulos so
chamados de modulares. O principal benefcio da modularizao que
ela permite que o princpio da separao de preocupaes seja aplicado em
duas fases. Primeiramente quando tratarmos dos detalhes de cada mdulo
isoladamente (ignorando detalhes dos outros mdulos) e, posteriormente,
quando tratarmos das caractersticas globais de todos os mdulos, incluindo
seus relacionamentos, o que possibilita interlig-los para formar um sistema
ntegro e coeso. Em software modulares, busca-se bastante coeso (todas as
informaes relacionadas ao mdulo devem estar contidas no mesmo) e pouca
inter-relao (necessidade de ligao entre mdulos distintos).
Abstrao Processo pelo qual se identifica os aspectos importantes de um

fenmeno, ignorando seus detalhes.
Antecipao de mudanas Princpio que prega a habilidade de evoluo

do software, pela preparao prvia para mudanas. Atualmente, pela
18/7/2013 17:51:22
Process Black
disseminao dos processos geis de desenvolvimento de software, este

princpio bastante controverso.
Generalizao Princpio que orienta o foco do desenvolvimento no problema

mais geral e abrangente do negcio do cliente, partindo posteriormente para
os problemas mais especficos e detalhados.
Incrementabilidade - o princpio que busca a perfeio ou a obteno dos

objetivos atravs de passos que evoluem (ou so incrementados) ao longo do
tempo.
19
Estes princpios apresentados devem ser considerados como guias de boas

prticas para os processos de desenvolvimento de software, independentemente
se tradicionais ou geis.
1.8 Qualidades Desejveis em um Software

Tanto os processos de desenvolvimento quanto os produtos de software, para terem
sucesso e aceitao no mercado, devem apresentar qualidades bsicas, como:
Corretude O software deve ser correto, isto , funcionar de acordo com sua
especificao formal.
Confiabilidade Um software considerado confivel quando os seus usurios

podem depender dele. Este conceito, porm, bastante relativo e depende dos
tipos de usurios envolvidos. O prprio sucesso de mercado um indicador de
confiabilidade: produtos no confiveis no sobrevivem por muito tempo.
Robustez Um software, para ser robusto, deve apresentar capacidade de

recuperar-se de erros e problemas no previstos, como quedas de energia,
falhas de hardware etc. O nvel de robustez requerido depende do tipo de
aplicao jogos e aplicaes simples podem ter robustez menor que aplicaes
de misso criticam, como controles de usinas nucleares.
Performance A qualidade de performance diz respeito ao desempenho

do software em determinado hardware. Problemas de performance afetam
principalmente sua usabilidade e, assim como a robustez, dependem do
propsito da aplicao.
Amigabilidade Qualidade de um software com facilidade de utilizao por

parte de usurios. Esta qualidade relativa e depende do nvel e perfil do
usurio.
Manutenabilidade Qualidade de todos os softwares com facilidade de

alteraes aps sua liberao. Pode ser classificada como corretiva, que
possibilita a correo de defeitos e problemas; perfectiva, que possibilita a
18/7/2013 17:51:22
Process Black
20
melhoria continua do produto ao longo do tempo de vida til; e adaptativa, que
aborda a adaptao do software a diferentes plataformas computacionais.
Reusabilidade Qualidade de processo de desenvolvimento que prega a

reutilizao no somente de cdigo-fonte, mas de aspectos de projeto e teste.
Portabilidade Qualidade do software com capacidade de execuo em

diferentes plataformas computacionais. Esta qualidade atualmente
importante devido ao grande nmero de plataformas computacionais a
disposio do usurio computadores de mesa, notebooks, smarthphones e
tablets, por exemplo.
Interoperabilidade Qualidade referente ao software que permite interao

com demais software para fins de compartilhamento de dados e informaes.
Um exemplo bastante conhecido de software com interoperabilidade do
Microsoft Oce, que permite a troca de dados entre seus aplicativos de
edio de texto, planilha eletrnica e de apresentaes, sem necessidade de
redundncia.
Atividades
Complete com V (verdadeiro) ou F (falso) para as seguintes afirmaes:
Engenharia de Software se caracteriza pelo estabelecimento de slidos princpios
para se obter software confivel e que funcione.
O objetivo final da Engenharia de Software o lucro e a confiabilidade.
Definir a linguagem de desenvolvimento mais importante do que definir o
processo de desenvolvimento.
Rigor e formalismo anulam o fato do desenvolvimento de software ser baseado em
criatividade e inspirao.
O objetivo da modularizao produzir software com baixa coeso e muito interrelacionamento.
Bibliografia
ANDRADE, Vtor. Introduo ao Guia SWEBOK. Disponvel em http://www.cin.ufpe.
br/~processos/TAES3/slides-2012.2/Introducao_SWEBOK.pdf.
GUSTAFSON, David. Engenharia de Software. Porto Alegre: Bookman, 2003.
PRESSMAN, Roger. Engenharia de Software, uma abordagem profissional. 7. Edio. Porto Alegre:
McGraw-Hill/Bookman, 2011.
SCHACH, Stephen. Engenharia de Software: Os Paradigmas Clssico e Orientado a Objetos. 7.
Edio. So Paulo: McGraw-Hill, 2009.
18/7/2013 17:51:22
Process Black
SOMMERVILLE, Ian. Engenharia de Software. 9. Edio. So Paulo: Pearson, 2011.

TONSIG, Srgio Luiz. Engenharia de Software Anlise e Projeto de Sistemas. So Paulo: Futura,
2003.
Gabarito:
V
21
18/7/2013 17:51:22
Process Black
22
18/7/2013 17:51:22
Process Black
PROCESSOS DE SOFTWARE
Este captulo apresenta os Processos de Desenvolvimento de Software e os Modelos

de Desenvolvimento de Software Tradicionais.
Estes modelos so importantes como guias de boas prticas em ambientes
tradicionais de desenvolvimento de software. So discutidos aspectos positivos e
negativos de cada modelo, bem como sua aplicabilidade.
2.1 Processos e Software

Processo de software, segundo Sommerville (2011) um conjunto de atividades
relacionadas que levam produo de software, e um conjunto de etapas ou nveis
que formam o que se convencionou chamar de ciclo de vida de um software.
Independentemente do modelo de processo de software, se tradicional ou gil,
pode-se destacar cinco atividades ou etapas fundamentais para o processo de
desenvolvimento de software:
Especificao Requisitos e funcionalidades que devem ser implementadas

no software o que deve ser feito;
Projeto Etapa onde define-se como o software dever ser desenvolvido

como o software ser feito;
Implementao Etapa relacionada a codificao (programao) do

software;
Validao Etapa onde o software deve ser validado (testado) frente aos
requisitos;
Evoluo Etapa posterior entrega/homologao que visa manter/corrigir e

evoluir o software.
18/7/2013 17:51:22
Process Black
24
2.2 Modelos de Processos de Software

Um modelo de processo de software uma representao abstrata do processo.
Ele apresenta a descrio de um processo a partir de uma perspectiva particular,
mostrando as atividades e sua sequncia (Sommerville, 2011). So usados para
expressar abordagens de desenvolvimento de software e, geralmente, podem
e devem ser adaptados e personalizados para atendimento de demandas
especficas.
Os modelos podem, ento, ser classificados em Artesanais, Tradicionais ou
geis.
Artesanais Modelos de desenvolvimento sem qualquer preocupao formal

com a Engenharia de Software. No h etapas, documentos ou papis (atores)
formalmente definidos. popularmente conhecido como gambiarra.
Tradicionais Modelos clssicos, que foram criados a partir da dcada de 1970

e implantam a maioria dos conceitos e prticas da Engenharia de Software;
geis Modelos modernos, criados a partir de dissidncias entre Engenheiros

de Software e grupos de desenvolvedores experientes, que questionam e se
opem a vrios princpios da Engenharia de Software. Sugerem novas prticas
e abordagens para o desenvolvimento de software.
Os modelos geis especialmente a Extreme Programming (XP) e o SCRUM sero

detalhadamente abordados no prximo captulo deste material.
2.3 Modelo Cascata

O modelo Cascata (ou waterfall) o modelo de desenvolvimento de software mais
antigo e mais clssico. Ainda bastante utilizado em empresas de desenvolvimento
de software ao redor do mundo, entretanto, em verses adaptadas/atualizadas.
A verso original do modelo extremamente rgida e linear - no poderia ser
utilizada atualmente frente ao novo contexto mundial, que apresenta mudanas
frequentes de requisitos, equipes multidisciplinares com trabalho em paralelo, entre
outras limitaes ao modelo original. O fato de exigir particionamento inflexvel
do projetos em etapas estanques dificulta a resposta aos requisitos de mudana
dos clientes.
O modelo cascata particularmente adequado a grandes projetos de software, como
sistemas de ERP, e a equipes de desenvolvimento geograficamente distribudas,
em que a diviso de etapas e a documentao so fatores positivos para a gerncia
do projeto.
18/7/2013 17:51:22
Process Black
25
As etapas do modelo cascata podem ser observadas na figura 2.1:

Figura 2.1 - Modelo Cascata. Fonte: (Sommerville, 2011)
Etapa de Engenharia de Requisitos Esta etapa inclui o processo de engenharia

de requisitos (O QUE deve ser feito), com fases de elicitao (obteno atravs
de entrevistas, questionrios, prottipos), especificao (usando tcnicas de
modelagem como UML, atravs de diagramas de casos de uso, classes e sequncia)
e validao e verificao (verificar se tanto os requisitos esto descritos e modelados
tecnicamente corretos - em UML correta, por exemplo - quanto se representam os
anseios corretos dos clientes/usurios).
Os profissionais responsveis por esta etapa incluem os Analistas, tanto Analistas de
Negcios e quanto Analistas de Sistemas. Os Analistas de Negcios profissionais
com perfil mais especializado em regras de negcios e gesto de pessoas
normalmente ficam com as primeiras etapas, relacionadas abordagem e obteno
dos requisitos, e os Analistas de Sistemas com as etapas seguintes, relacionadas ao
registros/especificao e validao/verificao dos requisitos.
Um subprocesso da Engenharia de Requisitos pode ser observado na figura 2.2:
18/7/2013 17:51:23
Process Black
26
2.2 Engenharia de Requisitos. Fonte: (SOMMERVILLE, 2011)
Destaca-se a subetapa de Estudo de Viabilidade, onde so realizados estudos

de viabilidade tcnica e econmica acerca do possvel desenvolvimento do
software.
Os fatores que devem ser levados em considerao nesta subetapa incluem
viabilidade comercial/econmica (o mercado para sua comercializao) e tcnica
(os conhecimentos tcnicos requeridos para seu desenvolvimento, em plataforma
computacional - desktop, mvel, distribuda -, linguagens de programao, sistemas
de banco de dados e testes).
Neste ponto, costuma-se dividir o software em dois tipos: Software de Prateleira
e Software sob Encomenda. Software de Prateleira aquele desenvolvido pela
empresa ainda sem nenhum cliente especfico, para posterior venda em empresas
especializadas, em lojas e sites de comrcio eletrnico. Software sob Encomenda,
por sua vez, aquele desenvolvido pela empresa sob encomenda particular e direta
de determinado cliente.
Ao contrrio que se pode pensar, mesmo Softwares sob Encomenda devem
passar por esta subetapa, visto que mesmo tendo garantia a comercializao
podem apresentar problemas tcnicos e/ou de projetos, relacionados a prazos
e custos. Insistir no desenvolvimento de um software com viabilidade incerta
ter problemas no futuros, como perdas de mercado, perdas financeiras e atrasos,
bem como problemas relacionados imagem da empresa e dos profissionais
envolvidos.
Projeto Esta etapa inclui atividades relacionadas definio da melhor soluo
tcnica a ser aplicada no desenvolvimento do software. Aqui define-se COMO
o software ser feito sem, necessariamente, faz-lo/implement-lo.
18/7/2013 17:51:23
Process Black
O profissional responsvel por esta etapa conhecido por arquiteto de software,

que tradicionalmente foi, antes, um programador experiente, com boa viso tanto
tcnica quanto relacionada gerncia de projetos prazos, riscos e custos.
Um subprocesso desta etapa pode ser observado na figura 2.3:
2.3 Projeto de Software. Fonte: (SOMMERVILLE, 2011)
27
A partir da especificao dos requisitos (produto da fase anterior do modelo

cascata) o arquiteto inicia a definio da soluo tcnica, incluindo a arquitetura
do sistema (diviso do sistema em mdulos e suas interfaces (ligaes),
especificao de partes de cdigo, chegando definio de estruturas de dados
(como matrizes e listas encadeadas) e, ainda, se necessrio, exemplos de
algoritmos que possam guiar o programador na maneira mais adequada na
implementao do software. Nesta fase, na prtica, so definidos tanto o ambiente
de desenvolvimento, as linguagens de programao, os bancos de dados e os
frameworks a ser utilizados.
considerada fase vital para o sucesso do desenvolvimento do software, visto que
uma implementao incorreta (ou no adequada) pode levar a baixo desempenho
(principalmente relacionado a integrao com bases de dados), duplicidade
desnecessrias de dados, entre outros problemas.
Implementao Nesta fase, ocorre a codificao/programao dos requisitos
de software, baseado nas definies tcnicas da fase de projeto. A implementao
atualmente utiliza linguagens de programao visuais e orientadas a objeto, com
ambientes de desenvolvimento fceis e amigveis.
O profissional responsvel por esta etapa conhecido por Programador ou
Desenvolvedor, cujo perfil apresenta excelentes capacidades lgicas e analticas.
18/7/2013 17:51:23
Process Black
28
Teste de Software Esta etapa visa aplicar testes de software que buscam descobrir
erros e falhas que porventura tenham ficado desde as etapas anteriores. O processo
de teste nunca 100% efetivo, e muitos erros certamente ainda restaro para
serem descobertos em ambiente de produo, ou seja, pelos prprios clientes e
usurios.
O profissional desta etapa do modelo de desenvolvimento conhecido
genericamente como Testador, com variaes entre Gerente de Testes, Projetista
de Testes, Testador, Automatizador de Testes, entre outros.
O subprocesso (figura 2.4) de teste envolve deste o teste unitrio e especfico de
cada componente/mdulo do software (teste de componente), passando por um
teste de integrao destes componentes/mdulos (teste de sistema) e chegando
ao teste de aceitao por parte do cliente/usurio, tambm conhecido por teste
de homologao.
2.4 Teste de Software. Fonte: (SOMMERVILLE, 2011)
Evoluo Esta fase inicia aps a entrega do produto de software e inclui atividades
de manuteno e evoluo do software (figura 2.5).
2.5 Evoluo de Software. Fonte: (SOMMERVILLE, 2011)
2.4 Modelo Evolutivo ou Evolucionrio

O Modelo Evolutivo baseia-se no levantamento rpido de requisitos, projeto
rpido e na construo evolutiva de prottipos de software, que sero avaliados
e refinados at a liberao do mesmo. O Modelo Evolutivo pode ser observado
na figura a seguir:
18/7/2013 17:51:24
Process Black
29
2.6 Modelo Evolutivo. Fonte: (SOMMERVILLE, 2011)
Seu objetivo principal a solidificao (certeza) nos requisitos juntos aos clientes/
usurios, sendo a direo do desenvolvimento determinada pela experincia
operacional.
A aplicabilidade do Modelo Evolutivo d-se em sistemas interativos de pequeno
e mdio portes e sistemas com ciclo de vida curto, para aplicaes especficas e
datadas. Um software de gerncia de um sorteio de uma emissora de rdio pode ser
considerado um exemplo de aplicabilidade do modelo, visto que simples, agrega
funcionalidades aos poucos (cadastros de participantes, cadastros de brindes e,
finalmente, mecanismos de sorteio). Alm da simplicidade, este software ter uma
vida til bastante curta, em paralelo com o perodo de vigncia da promoo.
Como problemas, pode-se citar a falta de visibilidade geral do processo, a m
estruturao tcnica do sistema (pelos projetos rpidos e sem cuidados) e a
necessidade de profissionais especializados em linguagens de prototipao rpida.
Outro problema a ser destacado a necessidade constante de iterao por parte do
cliente/usurio final nas etapas de validao das verses intermedirias, que pode
levar a um grande descontentamento e stress em ambas as partes.
2.5 Modelo Iterativo Incremental

O modelo Iterativo-Incremental baseia-se na premissa da constante evoluo e
alterao dos requisitos, de modo que no seria interessante tanto aguardar por
uma improvvel estabilizao quanto desenvolver completamente o sistema para
depois adequ-lo na manuteno.
O processo do modelo Iterativo-Incremental (figura 2.7) parte de um conjunto de
requisitos iniciais e estveis, e com base nestes, projeta a arquitetura completa do
18/7/2013 17:51:24
Process Black
30
sistema (principal diferena em relao ao modelo Evolutivo visto anteriormente).
Com base na arquitetura e na agregao dos demais requisitos, o sistema vai
sendo construdo, passo a passo, com atividades tradicionais de anlise-projetocodificao e testes.
2.7 - Modelo Iterativo-Incremental. Fonte: (Sommerville, 2011)
Como possvel principal problema deste modelo destaca-se a dependncia extrema

da definio dos requisitos por parte dos clientes, o que pode afetar criticamente
o projeto em relao a prazos e principalmente seus custos.
2.6 Modelo Baseado em Componentes

O Modelo Baseado em Componentes prev o desenvolvimento do software
atravs da integrao de componentes pr-prontos disponveis no mercado.
Atualmente, existem vrias empresas no mercado atuando exclusivamente na
fabricao de componentes genricos a serem utilizados em projetos especficos
de desenvolvimento de aplicaes de software.
O processo deste modelo inicia com a tradicional especificao de requisitos, mas,
posteriormente, ao invs de fases como projeto e codificao, parte para uma
pesquisa e anlise de componentes disponveis e, caso seja necessrio, para sua
modificao antes da integrao no produto de software final (Figura 2.8).
2.8 - Modelo Baseado em Componentes. Fonte: (Sommerville, 2011)
18/7/2013 17:51:25
Process Black
Certamente nem todos os requisitos particulares podem ser implementados somente

com componentes pr-prontos, levando a uma necessidade de desenvolvimento
prpria dos restantes.
Como principal problema do Modelo Baseado em Componentes destaca-se a
necessidade de confiana na qualidade do componente adquirido junto a terceiros,
bem como a possvel necessidade de modificao em softwares que podem no
apresentar documentao adequada.
31
A aplicabilidade deste modelo d-se em aplicaes de software tradicionais/

clssicos, ou seja, com poucos requisitos especficos, como softwares de cadastros
e emisso de relatrios.
2.7 Modelo RUP Rational Unified Process

O modelo RUP (Rational Unified Process) um modelo de desenvolvimento de
software derivado da UML e do respectivo processo unificado de desenvolvimento
de software, que separa um conjunto de atividades a partir de um conjunto prdefinido e bem conhecido de fases.
Aborda trs perspectivas:
Fases do projeto;
Atividades do projeto;
Boas prticas de desenvolvimento.
2.9 - Modelo RUP.
18/7/2013 17:51:25
Process Black
32
As fases do modelo RUP (figura XX) incluem:
Iniciao - define o escopo do projeto;
Elaborao define os requisitos e a arquitetura do sistema;
Construo desenvolvimento do software;
Transio implantao do software.

As boas prticas do RUP versam sobre:
Desenvolvimento iterativo do software;
Gerncia de requisitos;
Utilizao de arquiteturas baseadas em componentizao;
Modelagem visual
Verificao da qualidade do software;
Foco em Controle de mudanas do software.
Atividades
O modelo cascata, em sua verso original, pode ser usado por equipes globais que
trabalhem em paralelo ...
Softwares desenvolvidos sob encomenda no precisam passar pela subetapa de
estudo de viabilidade, pois j tem cliente garantido ...
O subprocesso de projeto de arquitetura considerado muito importante pois pode
evitar problemas de integrao com bases de dados ...
O modelo evolutivo se aplica quando os projetos so longos e tero ciclo de vida completo ...
O modelo incremental apresenta forte dependncia do relacionamento com o cliente ...
O modelo baseado em componentes favorece a reusabilidade do software ...
Bibliografia
TONSIG, Srgio Luiz. Engenharia de Software Anlise e Projeto de Sistemas. So Paulo: Futura, 2003.
Gabarito:
F
18/7/2013 17:51:25
Process Black
PROCESSO GEIS DE SOFTWARE
Este captulo apresenta os Processos geis de desenvolvimento de software,

discutindo os conceitos de agilidade, GAP (Gerenciamento gil de Projetos), XP
(Extreme Programming) e SCRUM.
Os processos geis tornaram-se excelentes alternativas aos processos tradicionais
de desenvolvimento de software, visto que implementam/abordam de forma
atual/moderna vrias questes fundamentais do processo de software, como o
gerenciamento de requisitos mutveis.
3.1 Processos geis de Software

O principal conceito envolvido neste captulo o conceito de Agilidade:
Agilidade a habilidade de criar e responder a mudanas como forma de manter a
lucratividade num ambiente turbulento de negcios Highsmith, 2002;
Os chamados mtodos geis surgem em paralelo fevereiro de 2001 - a um novo

contexto da indstria de desenvolvimento de software, onde, nestes novos tempos,
temos uma grande demanda de software e, adicionalmente, de um software cada
vez mais complexo sistemas inteligentes, distribudos, computao em nuvem etc.
Alm disso, junta-se a este panorama o aumento da questo dos requisitos mutantes,
devido a mudanas de mercado, de governo (leis, taxas, impostos etc.).
Entretanto, apesar do movimento ter sido formalizado em 2001, os principais
conceitos envolvidos so mais antigos, como citados em (RICO, 2005):
Times auto-organizveis em pesquisa desde 1951, com Bachuk e Goode;
Prototipao (em Engenharia de Software) 1982, com McCracken e Jackson;
18/7/2013 17:51:26
Process Black
34
Releases e iteraes desde 1975, com pesquisas de Basili e Turner;
Envolvimento do cliente desde 1978, em artigos de Von Hippel.
Os Mtodos geis so uma tentativa patrocinada originalmente por um grupo

de desenvolvedores/programadores experientes e consultores (Kent Beck,
notadamente) que questionam e se opem s prticas de at ento da Engenharia
de Software de abordagem e minimizao de uma srie de problemas da rea
de desenvolvimento de software clssica/tradicional:
Suposio de que seja possvel prever o futuro;
Baixa interao com clientes;
nfase em documentos e processos.
Uma famosa pesquisa, o Chaos Report, do instituto de pesquisas Standish Group,

monitora h dcadas o mercado de projetos de desenvolvimento de software,
classificando-os em sucesso, problema e fracasso.
Figura 3.1 Chaos Report. Fonte. Standish Group.
Outro fator analisado pelo Standish Group, dentro do contexto do desenvolvimento

de software envolve a questo do percentual das funes utilizadas em um sistema
tpico de software. A pesquisa descobriu que:
Partes sempre usadas: 07%
Partes raramente usadas: 19%
Partes nunca usadas: 45%
Partes utilizadas as vezes: 29%
Como se pode ver, gasta-se muito tempo e dinheiro desenvolvendo softwares que
provavelmente nunca sero usados.
18/7/2013 17:51:26
Process Black
O movimento, ento, surge com a publicao de um manifesto com quatro questes

principais (www.agilemanifesto.org/):
1.
Indivduos e interaes mais do que processos e ferramentas;
2.
Software em funcionamento mais do que documentao abrangente;
3.
Colaborao com o cliente mais do que negociao de contratos;
4.
Responder a mudanas mais do que seguir um plano.
35
O principal objetivo deste manifesto Satisfazer o cliente, entregando, rapidamente

e com frequncia, sistemas com algum valor, ou seja, com entregas funcionais e
frequentes, com preparao e tratamento de requisitos mutveis, com pessoal de
desenvolvimento e negcios trabalhando juntos e com troca direta de informaes,
sem burocracias.
Os princpios dos Mtodos geis incluem:
Satisfao do cliente atravs de entrega contnua e adiantada de software com

valor agregado;
Mudanas nos requisitos so bem vindas, mesmo tardiamente;
Entregar frequentemente software funcionando;
Pessoal de desenvolvimento e negcios trabalhando junto;
Indivduos motivados;
Conversas presenciais;
Andamento do progresso medido pelo funcionamento do software;
Desenvolvimento sustentvel;
Busca da excelncia tcnica e do bom design;
Simplicidade;
Equipes auto-organizveis;
Reflexes peridicas.
A grande abordagem dos Mtodos geis surge da manipulao correta das

conhecidas variveis de um projeto de software em busca do sucesso e da
qualidade. Enquanto os processos Tradicionais manipulam (tanto positivamente
quanto negativamente) a qualidade, mantendo fixos o tempo, escopo e custo, os
projetos geis focam-se no escopo, mantendo fixos, por sua vez, tempo, qualidade
e custo.
18/7/2013 17:51:26
Process Black
36
Uma possvel comparao entre os modelos Tradicionais e geis de desenvolvimento
de software pode ser observada na tabela 3.1:
Tabela 3.1 Comparao entre Enfoques.
Item
Enfoque Clssico
Enfoque gil
Gerenciamento
Controle absoluto
Colaborao e Liderana
Papis/atores
Individual
Equipes (auto-organizadas)
Cliente
Importante (no incio)
Crtico (sempre)
Desenvolvimento
Tradicional (cascata e outros)
gil (XP e outros).
Esta comparao, mais especificamente relacionada visibilidade, adaptabilidade,

valor de negcio e ao risco pode ser analisada nos grficos abaixo, onde o eixo vertical
representa o item analisado e o eixo horizonte representa o tempo (Figura 3.2):
Figura 3.2 Comparao gil x Tradicional. Fonte: www.versionone.com
As principais metodologias geis incluem:
FDD Feature Driven Development;
Extreme Programming;
Lean Development;
Crystal;
Scrum;
18/7/2013 17:51:26
Process Black
As caractersticas comuns a todos os mtodos geis citados acima incluem focar

nas pessoas (desenvolvedores e clientes) e no focar em processos e documentaes
rgidas e detalhadas.
Visam, ao final, mesmo contrapondo vrias premissas da Engenharia de Software,
ser considerados como um conjunto coeso e consistente de Boas Prticas para
projetos de desenvolvimento de software.
37
3.2 XP Extreme Programming

A Extreme Programming a principal metodologia de desenvolvimento gil, criada
por Kent Beck, Ron Jeffries e Ward Cunningham.
Surge como uma alternativa aos modelos tradicionais de desenvolvimento
de software, representados principalmente pelo Modelo Cascata. focada
primordialmente na figura do programador, sem contudo apresentar nveis
hierrquicos no processo de desenvolvimento. Normalmente indicada para
programadores experientes, que com XP ganham liberdade para codificar.
As premissas ou princpios do modelo XP baseiam-se numa mudana de proposta
de atitude dos desenvolvedores, no sentido de:
Tomar decises importantes o mais tarde possvel ;
Implementar somente o necessrio neste momento;
No implementar cdigo desnecessrio (ao contrrio do princpio de

Antecipao de Mudanas da Engenharia de Software);
Feedback rpido e constante;
Simplicidade;
Alta qualidade de cdigo-fonte;
Destes, pode-se apontar valores a serem destacados:
Respeito;
Comunicao;
Coragem;
Simplicidade;
Feedback.
A XP destina-se, ainda, a um cenrio bem definido dentro do mbito global de

desenvolvimento de software, em:
Grupos pequenos de 2 a 10 desenvolvedores;
Projetos pequenos de 1 a 12 meses previstos;
Softwares pequenos at 250.000 linhas de cdigo.
18/7/2013 17:51:26
Process Black
38
Os papis profissionais em uma equipe XP incluem:
Programadores;
Coach (treinadores ou tcnicos) normalmente o programador mais experiente

do grupo, responsvel pelo controle da equipe nos instantes iniciais do
projeto;
Tracker (acompanhador) programador responsvel pela gerncia do projeto,

em relao s estimativas e cobrana de tempos e custos;
Cliente - a participao do cliente real ou representado por um desenvolvedor

fator chave no sucesso de um projeto de desenvolvimento XP. Ao cliente
cabe a tarefa de escrever histrias (requisitos).
O XP representado por um conjunto de 12 prticas originais/oficiais. O

atendimento das prticas garante o ambiente necessrio ao desenvolvimento XP.
Planejamento
Fases pequenas
Metforas
Design simples
Testes
Refatorao
Programao pareada
Propriedade coletiva do cdigo
Integrao contnua no projeto
Semana de trabalho de 40horas
Permanncia do cliente junto ao time de desenvolvimento
Padronizao do cdigo
O processo de um projeto XP tipicamente apresenta as seguintes etapas:
Seleo de histrias (story cards) contendo os requisitos do cliente;
Seleo de um par livre para programao pareada Atividade no aleatria,

visto que o objetivo da programao pareada o desenvolvimento das
habilidades de todos os elementos da equipe;
Seleo, dentro da histria, de um carto contendo uma necessidade

especfica;
Discusso, em par, das alteraes recentes no software;
18/7/2013 17:51:27
Process Black
Testes o teste considerado um dos principais seno o principal pilar de

sucesso e segurana no modelo XP. Os desenvolvedores costumam executar
testes antes, durante e depois da codificao, visando garantir que o cdigo
adicionado ao projeto est correto e funciona adequadamente; Engloba tanto
testes unitrios quanto testes funcionais;
Codificao No XP, na programao pareada, somente um desenvolvedor

programa/codifica. O outro desenvolvedor deve ficar ao lado, analisando o
cdigo e propondo contraexemplos e planos de testes; Este cdigo sempre
poder ser refatorado, ou seja, melhorado em busca de excelncia tcnica e
adequao a um padro oficial de codificao da equipe. Visto tambm que a
documentao em um projeto XP bastante reduzida, na etapa de codificao
enfatizada a necessidade de incluso de comentrios padronizados junto s
linhas de cdigo;
Integrao Integrao final do cdigo ao repositrio do projeto do

software.
39
XP normalmente funciona muito bem, desde que respeitadas suas caractersticas

bsicas (equipes pequenas e experientes, projetos curtos e dinmicos, entre outras).
Entretanto, quando o cenrio do desenvolvimento no adequado (cliente no est
disposto a participar/colaborar, projetos grandes - e estveis -, necessria uma
especificao completa do software antes do processo iniciar, os programadores
no so suficientemente experientes e capazes de autogerenciamento) XP no deve
ser imposta fora, j que certamente ir gerar mais problemas do que solues.
3.3 SCRUM
SCRUM o principal framework do Gerenciamento gil de projetos (GAP) que,
segundo Highsmith (Highsmith, 2004) um conjunto de valores, princpios e
prticas que auxiliam equipes de projetos a entregar produtos ou servios de valor
em um ambiente complexo, instvel e desafiador.
Os principais objetivos do GAP incluem:
Inovao contnua;
Adaptabilidade de pessoas, produtos e processos;
Reduo dos tempos de entrega planejamento de curto prazo;
Resultados confiveis anlise do progresso real do projeto;
Simplicidade;
Foco na soluo, ao invs de foco nos problemas;
Remoo de barreiras ao orgulho da execuo;
18/7/2013 17:51:27
Process Black
40
Engajamento e poder s pessoas;
Para tanto, so sugeridas boas prticas no Gerenciamento gil de Projetos,

especificamente em projetos de desenvolvimento de software:
Foco e envolvimento de pessoas clientes e desenvolvedores;
Foco em iteraes entregas parciais;
Plano de projeto de alto nvel e alta qualidade;
Segundo Chin (2004), a aplicabilidade ideal de GAP em projetos de desenvolvimento

de software d-se em:
Projetos de desenvolvimento de novos produtos nico cliente;
Projetos de desenvolvimento de novas plataformas/tecnologias nico

cliente.
GAP, ainda segundo Chin, no adequado para desenvolvimento de projetos

meramente operacionais, independente do tipo de cliente (nico ou em forma de
conglomerado). Entretanto, este conceito mais recentemente est sendo bastante
questionado, principalmente pela comunidade de desenvolvimento de projetos
de software geis.
SCRUM foi criado por Jeff Sutherland e Ken Schwaber, baseados no artigo The new
product development Game, de Hirotaka Takeuchi e Ikujiro Nonaka, de 1986.
SCRUM pode ser definido como um framework para tratamento e resoluo de
problemas complexos e adaptativos, enquanto produtiva e criativamente entregam
produtos com o mais alto valor possvel, sendo ento leve e simples de entender,
porm, difcil de dominar. importante frisar que SCRUM no apenas um
processo nem uma tcnica, mas sim um framework dentro do qual so possveis
empregar vrios processos e diversas tcnicas.
Scrum , ento, um processo iterativo e incremental para desenvolvimento
de projetos com foco em comunicao e trabalho em equipes, preocupado,
primordialmente, com os fatores tempo e valor de negcio. O tempo (time boxes)
destacado no SCRUM por ser limitado e aplicado a tudo, incluindo deste reunies
a sprints.
O cenrio ideal de aplicao do framework SCRUM so projetos com aspectos
de tecnologia (plataformas) complexos, com requisitos adaptveis e dinmicos
(igualmente complexos).
O processo do SCRUM d-se atravs da figura 3.3.
18/7/2013 17:51:27
Process Black
Figura 3.3 SCRUM. Fonte: http://epf.eclipse.org/wikis/scrumpt/Scrum/guidances/supportingmaterials/resources/ScrumLargeLabelled.png
41
Os eventos ou cerimnias do SCRUM incluem tradicionalmente:
Reunio de planejamento de release (requisitos completos) mais de 8 horas

de durao;
Reunio de planejamento da Sprint (requisitos selecionados) 8 horas de

durao;
Sprint de 2 a 4 semanas de durao;
Reunio diria de acompanhamento 15 minutos de durao, em p, com as

questes:
O que eu fiz ontem;
O que vou fazer hoje;
Encontrei algum problema/impedimento?
Reunio de reviso da Sprint 4 horas de durao;
Reunio de retrospectiva da Sprint 4 horas de durao.
Os papis do SCRUM incluem:
PO (Product Owner) Responsvel pelos requisitos/conhecimento do negcio;
SCRUM Master Responsvel pelo processo SCRUM;
Time SCRUM Implementadores do SCRUM.
Os artefatos (documentos, relatrios e grficos) do SCRUM so normalmente

representados por:
Product Backlog Lista geral/completa de requisitos priorizados pelo PO;
Spint Backlog Subconjunto de requisitos selecionados pelo Time Scrum;
Grfico de Burndown Grfico de acompanhamento do SCRUM.
18/7/2013 17:51:27
Process Black
42
Atividades
Em se tratando de desenvolvimento gil, o teste de software no apresenta
importncia, uma vez que realizado em paralelo ao desenvolvimento.
Mtodos geis so fortemente dependentes de interao com o cliente.
Os princpios nos quais se baseiam os mtodos geis so facilmente aplicveis a
equipes globais.
O conceito de agilidade est fortemente associado a manter a lucratividade frente
a turbulncia dos mercados.
No SCRUM, o PO (product owner) no apresenta relevncia considervel no
time de desenvolvimento.
Bibliografia
CHIN, G. Agile Project Management: how to succeed in the face of changing project requirements.
2004. NY: Amacon.
GUSTAFSON, David. Engenharia de Software. 2003. Porto Alegre. Editora Bookman.
HIGHSMITH, J., Agile Project Management, Creating innovative products. 2004.
AddisonWesley.
PRESSMAN, Roger. Engenharia de Software, uma abordagem profissional. 7. Edio. 2011. Porto
Alegre. Editora McGraw-Hill/Bookman.
RICO, David. Agile Methods for Developing Internet Products, Customer Satisfaction, and Firm
Performance. 2005. Disponvel em http://davidfrico.com/rico05b.pdf,
SBROCCO, Jos. Metodologias geis Engenharia de Software sob medida. 1. Edio. So Paulo:
rica, 2012.
SHORE, James. WARDEN, Shane. A Arte do Desenvolvimento gil. Rio de Janeiro: Alta Books,
2008.
2003.
Gabarito:
F
18/7/2013 17:51:27
Process Black
ENGENHARIA DE REQUISITOS
Este captulo apresenta a Engenharia de Requisitos, a etapa que pode ser

considerada como a mais importante em todo processo de desenvolvimento de
software.
Nesta etapa definido o que o software deve fazer e, caso isto seja definido errado
ou incompleto, estes erros sero replicados nas etapas subsequentes.
4.1 Engenharia de Requisitos

Requisitos estabelecem o que o software deve fazer, servios que o software
deve fornecer e definem as restries sobre suas operaes e implementao
(SOMMERVILLE, 2011).
A etapa de Engenharia de Requisitos, de qualquer modelo de desenvolvimento de
software, tradicional ou gil, certamente pode ser considerada a mais importante
de todas (entre requisitos, projeto, codificao, teste, implantao, manuteno),
visto que todo processo inicia por aqui e, sendo assim, quaisquer erros nesta
fase so replicados nas demais, alguns inclusive impossibilitando sua deteco
e correo.
Outro complicador na Engenharia de Requisitos vem do fato desta etapa ser a etapa
com maior interao entre pessoas, isto , interao entre Analistas (de Negcio
e Sistemas), Desenvolvedores e Clientes/Usurios. Infelizmente esta relao e/ou
gesto de pessoas (abordagem, comunicao, confiana etc.) no faz parte do perfil
da maioria dos profissionais de desenvolvimento de software, o que induz a erros,
inconsistncias, falhas e lacunas em todo processo.
18/7/2013 17:51:28
Process Black
44
O cenrio atual de desenvolvimento de software, exibido na figura 4.1, mostra
claramente que a rea de Requisitos merece ainda pouco mais de 5% dos
investimentos em desenvolvimento de software, mesmo que sabidamente seja
crtica e responsvel por mais da metade (55%) dos erros do software. Estes erros,
quando descobertos e tratados no incio, ainda na fase de requisitos, tm um custo
relativo de correo bastante baixo (fator 1). Entretanto, quando no descobertos
a tempo, na fase de requisitos, so replicados nas etapas de projeto e codificao
e seu custo e esforo de correo passa a ser multiplicado at por 100 vezes (fator
10 a 100) o custo inicial.
Figura 4.1 Custos de manuteno Fonte: (vila e Spinola, 2007)
% do custo
de desenvolvimento
% dos erros
introduzidos
Anlise de
requisitos
55
30
1 - 1.5
10
1-5
Projeto
25
Codificao e teste
de unidade
50
Teste
10
Validao e
documentao
10
Manuteno
% dos erros
encontrados
22
Custo relativo
de correo
10 - 100
Na figura 4.2, tambm disponibilizada no artigo de vila e Spinola (2007), tem-se

os fatores crticos de sucesso no processo de desenvolvimento de software. Esta
tabela confirma que, de oito fatores crticos, ao menos metade (fatores 1, 2, 4 e 6)
so diretamente relacionados a Requisitos de Software.
Figura 4.2 Fatores Crticos. Fonte: (vila e Spinola, 2007)
Fatores crticos
1. Requisitos incompletos
%
13.1%
2. Falta de envolvimento do usurio
12.4%
3. Falta de recursos
10,6%
4. Expectativas irreais
9,9%
5. Falta de apoio executivo
9,3%
6. Mudana de requisitos e especificaes
8,7%
7. Falta de planejamento
8,1%
8. Sistema no mais necessrio
7,5%
18/7/2013 17:51:28
Process Black
Requisitos so importantes no processo de desenvolvimento de software para:
Estabelecer base de concordncia entre desenvolvedor/cliente;
Estabelecer uma referencia para a validao do produto final;
Diminuir retrabalho no processo de desenvolvimento.
45
4.2 Definies de Requisito

Requisitos podem ser definidos, em forma crescente de complexidade e abrangncia,
como em vila e Spinola (2007):
Descries das funes e restries do software;
Propriedade que o software deve exibir para resolver algum problema do

mundo real;
Condio ou capacidade que deva ser alcanada ou estar presente em um

sistema para satisfazer um contrato, padro, especificao ou outro documento
formalmente imposto.
4.3 Tipos de Requisitos

Requisitos tradicionalmente so classificados, primariamente, como:
Requisitos de Usurio Documentos e diagramas para clientes, contendo, em

linguagem acessvel (s vezes mesmo linguagem natural), as principais funes
e servios a serem disponibilizados no software;
Requisitos de Sistema Documentos e diagramas mais estruturados, com

detalhes tcnicos e operacionais do sistema, para todos os envolvidos no
processo de desenvolvimento do software, desde analistas, arquitetos,
programados e testadores. Escritos em linguagem tcnica de alto nvel,
normalmente utilizando UML.
Outra classificao possvel dos requisitos aborda:
Requisitos Funcionais;
Requisitos No Funcionais;
Requisitos de Domnio.
Os Requisitos Funcionais descrevem as funcionalidades e funes do software,

como o sistema deve reagir a entradas de dados, bem como o seu comportamento
esperado.
18/7/2013 17:51:28
Process Black
46
Exemplos de Requisitos Funcionais:
O software deve gerar relatrio de todos os clientes cadastrados;
O mdulo de contas a receber deve listar todos os clientes com contas vencidas
a mais de 30 dias;
O cliente deve ser identificado no sistema pelo seu nmero de CPF.
Os Requisitos No Funcionais expressam condies e restries que devem ser

atendidas pelo software, como restries de tempo, padres de desenvolvimento
e de utilizao, padres de usabilidades, entre outros. Podem ser divididos entre
vrios subtipos, como:
Requisitos de produto;
Requisitos de eficincia;
Requisitos de desempenho;
Requisitos de espao;
Requisitos de confiabilidade;
Requisitos de portabilidade;
Requisitos organizacionais;
Requisitos de entrega;
Requisitos de implementao;
Requisitos de padres;
Requisitos externos;
Requisitos de interoperabilidade;
Requisitos ticos;
Requisitos legais;
Requisitos de privacidade;
Requisitos de segurana.
Como exemplos de Requisitos No Funcionais, pode-se citar:
O software deve ser compatvel com os navegadores web Internet Explorer e

Firefox;
O software deve exibir o resultado das consultas em at 3 segundos em

operaes que envolvam banco de dados;
18/7/2013 17:51:28
Process Black
Os dados dos clientes devem ser mantidos criptografados dentro do banco de

dados.
Os Requisitos de Domnio so herdados do domnio da aplicao (financeiro,

educacional, industrial, hospitalar etc.) e refletem diretamente as suas caractersticas.
So considerados superiores aos Requisitos Funcionais e geralmente descrevem
caractersticas gerais a toda aplicao. Como exemplos destes requisitos, tem-se:
O desconto mximo em operaes de venda no sistema ser de 10%;
O clculo da mdia final nas disciplinas presenciais dar-se- pela mdia

aritmtica entre todas as notas.
47
4.4 Processo da Engenharia de Requisitos

A Engenharia de Requisitos aborda etapas e atividades relacionadas a toda vida til
dos requisitos no software, desde sua obteno at sua manuteno e atualizao
aps o desenvolvimento do software.
Pode ser dividido em dois grandes processos: Produo e Gerncia de Requisitos,
onde ambos apresentam atividades essenciais para o sucesso do software.
O processo de Produo de Requisitos envolve atividades de:
Levantamento/Elicitao/Obteno;
Anlise e negociao;
Registro/Documentao;
Validao;
Verificao.
A etapa de Levantamento/Elicitao/Obteno responsvel pela obteno dos

requisitos do software junto ao stakeholders (clientes e usurios diretamente
envolvidos com o software). Para tanto, so desenvolvidas tcnicas e utilizadas
ferramentas como:
Entrevistas conversas pessoais ou mediadas por computador entre analistas

e stakeholders;
Questionrios documentos enviados por email previamente com questes

envolvendo o que deve ser feito, como e por que?;
Prototipao construo conjunta de softwares provisrios junto aos

stakeholders;
Como abordado anteriormente esta etapa, dentre todas do processo de Engenharia

de Requisitos, certamente a mais complicada e arriscada dada a exigncia de
18/7/2013 17:51:28
Process Black
48
comunicao e interao entre pessoas. Normalmente existem problemas clssicos
a serem abordados nesta fase, como:
Stakeholders no sabem o que querem ou como deve funcionar;
Desenvolvedores com baixo conhecimento do domnio de negcios do

software;
Problemas de comunicao entre as partes envolvidas conflitos, ambiguidades

e obviedades no formalmente definidas;
A etapa de Anlise e Negociao crucial no processo de Produo de Requisitos,

visto que responsvel, em um primeiro momento, pela anlise de viabilidade
tcnica e comercial em relao ao desenvolvimento dos requisitos ( possvel
desenvolver com as tcnicas, ferramentas e conhecimentos atuais? Tem sentido
para o conjunto do sistema ser desenvolvido? O requisito no duplicado ou
contraditrio com algum outro requisito?) e, posteriormente, caso seja necessrio,
novos contatos com os stakeholders para negociao/readequao de ajustes nos
requisitos anteriormente levantadas. Os mesmos problemas da etapa anterior so
enfrentados aqui, multiplicados pela necessidade de negociao, que pode levar
a desgostos e insatisfaes por partes dos envolvidos.
A etapa de Registro/Documentao responsvel pelo registro formal dos requisitos
em documentos oficiais de requisitos da empresa. Este registro necessrio para
posterior consulta, controle e evoluo dos requisitos. Estes documentos podem
ser tanto utilizando linguagem natural (o que desaconselhvel, j que textos so
propcios a problemas de interpretao) ou usando linguagens de modelagem
como a UML (Unified Modeling Language), com seus diagramas de:
Casos de uso;
Classe;
Sequncia;
Atividades.
A etapa de Verificao responsvel pela anlise da documentao dos requisitos

(produzida na etapa anterior) em busca de erros, falhas, ambiguidades, omisses e
inconsistncias internas do processo de obteno e registro. Erros de modelagem
UML, por exemplo, devem ser corrigidos nesta etapa.
J na etapa de Validao, busca-se o ciente e aprovado dos Stakeholders em relao
aos requisitos. Esta assinatura de aprovao no deve ser considerada como
definitiva visto que, como j foi comentado, alteraes nos requisitos so comuns
e muitas vezes inevitveis.
18/7/2013 17:51:28
Process Black
O processo de Gerncia de Requisitos aborda as atividades seguintes ao processo

de Produo de Requisitos, com etapas de:
Controle de mudanas;
Gerncia de configurao;
Rastreabilidade;
Qualidade de Requisitos.
49
Este processo de Gerncia de Requisitos ainda incomum junto a desenvolvedores

de software dada sua complexidade e custo elevados. Entretanto, sua utilizao
vem crescido ao longo do tempo junto com o crescimento das implementaes de
modelos de maturidades de qualidade de software, como CMMI e MPS.BR, que
formalmente os exigem desde os nveis mais iniciais. A constatao vigente de
que no basta apenas levantar e registrar os requisitos para uso imediato pelos
desenvolvedores, mas, principalmente, so necessrias etapas posteriores, que
possibilitem sua correta gerncia, armazenamento e controle ao longo do tempo,
seno, perde-se completamente seu valor em momentos de manuteno/evoluo
do software.
A etapa de Controle de Mudanas encarregadas do controle dos requisitos em
relao ao longo do tempo, controlando as mudanas ocorridas desde a sua criao.
Um histrico de mudanas importante para poder identificar os autores das
mudanas, seus motivos e o que efetivamente mudou nos requisitos. Esta uma
tarefa bastante complicada para ser gerenciada manualmente, sendo indicado o
uso de ferramentas computacionais especficas. O subprocesso do Controle de
Mudanas inclui:
Verificao da validade da solicitao da mudana;
Identificao de todos os requisitos afetados na mudana e suas

dependncias;
Estimar custos e prazos da mudana;
Obter aceite e aprovao da mudana.
A Gerncia de Configurao aborda os critrios de integridade no processo de

manuteno dos requisitos, desde sua criao at seu descarte (somente aps
o trmino da vida til do software). Define que seja desenvolvido um plano
formalizado que inclua atores (pessoas), artefatos (documentos) e ferramentas.
A etapa de Rastreabilidade visa acompanhar todas mudanas sofridas por
um requisito, mas no somente por ele, e sim por todos os demais requisitos
envolvidos/relacionados. Normalmente utiliza-se uma matriz de rastreabilidade,
em que os relacionamentos entre requisitos so modelados. Um exemplo clssico
18/7/2013 17:51:28
Process Black
50
da necessidade de controle de rastreabilidade em um sistema comercial d-se
no controle da frmula de juros: no possvel alterar a frmula em apenas um
mdulo (aquele que solicitou a alterao), mas sim em todos os demais que a
utilizam, seno, provavelmente teremos, em diferentes partes do sistema, juros
calculados de forma diferente, refletindo em relatrios e fechamentos que jamais
estaro corretos, para completa desordem dos contadores.
A Qualidade dos requisitos descrita na norma IEEE 830, que aborda caractersticas
como:
Correo;
No Ambiguidade;
Completude;
Consistncia;
Verificabilidade;
Modificabilidade.
A norma IEEE 830 tambm descreve uma estrutura genrica para um documento
de requisitos, composto de:
Prefcio;
Introduo;
Glossrio;
Requisitos de usurio;
Arquitetura do sistema;
Requisitos de sistema;
Modelos de sistema;
Evoluo de sistema;
Apndices;
ndice.
18/7/2013 17:51:29
Process Black
Atividades
Requisitos incompletos e falta de envolvimento do usurio so fatores crticos
de sucesso no desenvolvimento de software porque 55% dos investimentos em
desenvolvimento de software se concentram nesta rea.
51
Requisitos so importantes, porm, no estabelecem referncia para a validao

do produto final.
Requisitos apresentam condio ou capacidade que deve ser alcanada para
atender a uma especificao formal.
Requisitos de domnio so mais facilmente identificveis que requisitos funcionais
e no funcionais.
A etapa de anlise e negociao de requisitos est diretamente relacionada com a
anlise de viabilidade.
Bibliografia
AVILA, Ana. SPINOLA, Rodrigo. Introduo Engenharia de Requisitos. Revista
Engenharia de Software edio especial. 2007. Editora DevMidia. Disponvel
em: http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-aengenharia-de-requisitos/8034
PRESSMAN, Roger. Engenharia de Software, uma abordagem profissional. 7. Edio.
Porto Alegre: McGraw-Hill/Bookman, 2011.
SCHACH, Stephen. Engenharia de Software: Os Paradigmas Clssico e Orientado a
Objetos. 7. Edio. So Paulo: McGraw-Hill, 2009.
SOMMERVILLE, Ian. Engenharia de Software. 9. Edio. So Paulo: Pearson,
2011.
TONSIG, Srgio Luiz. Engenharia de Software Anlise e Projeto de Sistemas. So
Paulo: Futura, 2003.
Gabarito:
F
18/7/2013 17:51:29
Process Black
52
18/7/2013 17:51:29
Process Black
PROJETO E ARQUITETURA
DE SOFTWARE
Este captulo apresenta a etapa de Projeto e Arquitetura de Software, onde define-se

como o software ser construdo em termos de soluo tcnica. Outro conceito
importante discutido neste captulo o de Reuso, que prega a ampla reutilizao
de todos os conceitos e artefatos possvel no processo de desenvolvimento de
software.
5.1 Projeto e Arquitetura de Software

Se na etapa de Engenharia de Requisitos resumidamente definimos O QUE
deve ser feito no processo de desenvolvimento de software, na etapa de Projeto e
Arquitetura de Software define-se COMO o software deve ser construdo, sem,
entretanto, chegarmos a codific-lo de fato.
Nesta fase, devem ser estudadas e definidas as melhores solues tcnicas, tanto
em nvel de modelo/arquitetura, quanto em termos de Linguagens de Programao,
Sistemas Gerenciadores de Banco de Dados etc.
O sucesso da fase seguinte codificao (programao) depende das indicaes
e regras oriundas desta fase de projeto.
5.2 Arquitetura de Sistema

A definio da arquitetura de um sistema visa identificar os subsistemas (mdulos)
que o constituem e o seu framework de controle e comunicao (SOMMERVILLE,
2011). Constitui-se da identificao dos componentes e suas comunicaes.
18/7/2013 17:51:29
Process Black
54
A definio formal da arquitetura de um sistema visa:
Possibilitar a comunicao entre os envolvidos no desenvolvimento do

sistema;
Possibilitar a discusso e anlise do sistema, tanto em termos de requisitos

quanto em termos de solues tcnicas;
Possibilitar futuro reuso das solues propostas.
Toda arquitetura de um sistema deve incluir ou preocupar-se com as seguintes

caractersticas:
Desempenho;
Proteo;
Segurana;
Disponibilidade;
Facilidade de manuteno.
Um dos principais tpicos de discusso nesta fase do desenvolvimento de

software est relacionado granularidade dos mdulos, isto , ao tamanho dos
mdulos. Se tivermos poucos mdulos, e portanto mdulos de grande tamanho, a
manuteno do sistema pode ser facilitada, mas certamente aspectos de reuso sero
prejudicados. J numa situao inversa (muitos mdulo de pequeno tamanho) o
reuso pode ser facilitado ao preo de uma gerncia bem mais complicada.
Decises a serem tomadas em projetos de arquiteturas incluem tambm
(SOMMERVILLE, 2011):
Existe uma arquitetura genrica de aplicao que possa ser usada?
Como o sistema ser distribudo?
Quais estilos de arquitetura so apropriados?
Qual ser a abordagem fundamental usada para estruturar o sistema?
Como o sistema ser decomposto em mdulos?
Qual estratgia deve ser usada?
Como o projeto de arquitetura ser avaliado?
Como a arquitetura do sistema deve ser documentada?
Modelos de arquitetura mostram como o sistema estruturado em subsistemas e

como os dados so compartilhados atravs das interfaces (SOMMERVILLE, 2011).
18/7/2013 17:51:29
Process Black
So considerados parte da documentao do sistema e normalmente so compostos

por submodelos (documentos) de:
Processos;
Interface;
Relacionamentos;
Distribuio.
55
Os trs modelos de arquiteturas mais comuns em sistemas computacionais

tradicionais (no incluindo aqui sistemas inteligentes, sistemas distribudos ou
mesmo computao em nuvem) so:
Modelo de repositrio Baseado em um repositrio central, que pode ser um

computador de grande porte (mainframe) ou um SGBD (Sistema Gerenciador
de Banco de Dados). Indicado para aplicaes que manipulam grandes
quantidades de dados. Como desvantagem principal, pode-se destacar
a dependncia total do ponto central. Caso ele estrague, toda aplicao
comprometida irremediavelmente.
Modelo Cliente-Servidor Baseado em uma rede de computadores, em que

partes do sistema so distribudas nos computadores da rede, que podem atuar
tanto como servidores quanto como clientes em momentos especficos. Neste
modelo, cada computador autnomo e fornece apenas seus servios, sendo
que em caso de problema somente seus servios so comprometidos. Como
os computadores de uma rede de computadores so mais comuns e baratos
que os modelos de grande porte uma soluo indicada para ambientes com
restries oramentrias. Igualmente torna fcil a ampliao da soluo apenas
pela incluso de novas mquinas na rede.
Modelo em Camadas Baseado em empilhamento de camadas de software,

tornando um modelo mais conceitual que prtico/implementvel. Um exemplo
de arquitetura em camadas d-se no modelo OSI de redes de computadores.
5.3 Soluo Tcnica

Alm da definio e estruturao do sistema em subsistemas e mdulos, funo
do projeto a definio da melhor soluo tcnica para o sistema em questo.
A soluo tcnica deve ser analisada frente a vrios critrios de deciso:
Tipo de aplicao;
Tamanho da aplicao;
18/7/2013 17:51:29
Process Black
56
Plataforma computacional Desktop, mvel, web, etc.
Quantidade prevista de dados a serem armazenados e manipulados pela

soluo;
Capacitao tcnica da equipe de desenvolvimento;
Disponibilidade de fornecedores e assistncia tcnica/suporte.
Por exemplo, para um sistema pequeno, com poucos dados e aplicao/acesso via
web pode-se indicar uma soluo envolvendo linguagem de programao PHP
com um banco de dados tipo MySQL. J para uma soluo de grande porte, com
grande volume de dados e de transaes, incluindo distribuio de servios, uma
escolha mais adequada envolveria linguagem de programao JAVA e banco de
dados ORACLE.
O erro neste momento pode ser bastante grave no futuro, na etapa de manuteno
do sistema (mesmo ainda quando este no seja considerado legado), visto que
mudanas estruturais, de linguagens de programao e mesmo de banco de dados
no so mais possveis (e caso sejam incluem um volume de trabalho muito acima
do aceitvel).
5.4 Reuso em Projeto e Arquitetura de Software

Partindo das constataes de que o processo de desenvolvimento de software
pode ser considerado lento, difcil, arriscado e consequentemente caro, uma das
melhores solues envolve o reuso (reutilizao), tanto de cdigos (abordagem
mais comum) quanto com enfoque mais sistmico, que prope reuso desde os
requisitos, envolvendo as arquiteturas de projeto, passado pelos cdigos e chegando
a planos de teste.
O reuso de software traz uma srie de benefcios, como:
Aumento de confiana, visto que o software baseia-se em algo que j foi usado
e testado;
Reduo de risco, visto que os maiores custos no processo de desenvolvimento

esto relacionados concepo original do software;
Uso eficiente de pessoas, visto que um mdulo reusado carrega o conhecimento

do profissional que o desenvolveu;
Conformidade com padres, visto que a homogeneizao de interfaces e dados

fica facilitada pelo reuso de mdulos sabidamente aderentes ao padro;
Desenvolvimento acelerado.
18/7/2013 17:51:29
Process Black
Entretanto o reuso no fcil de ser obtido, visto que no automtico,

apresentando uma curva de aprendizagem difcil, com overhead e falta de motivao
nos primeiros momentos.
Como fatores negativos ou problemas relacionados ao reuso, tem-se, por exemplo
(SOMMERVILLE, 2011):
Custos de manuteno aumentados;
Problemas de ferramentas;
Problemas de compreenso dos mdulos existentes;
Problemas relacionados biblioteca de mdulos.
57
Portanto, o reuso deve ser encarado como um aspecto cultural na empresa de

desenvolvimento de software, baseado em programas de consultoria para aes de
convencimento e treinamento e, ento, considerados como patrimnio intelectual
e at mesmo financeiro da empresa.
O Reuso antigamente era colocado em prtica apenas baseado em aes de copypaste, no uso de rotinas, funes e procedimentos e uso de bibliotecas de cdigos
prontos. Atualmente o reuso d-se pelo uso de padres de projeto (design patterns),
frameworks e componentizao (bibliotecas de componentes).
Padres de projeto podem ser considerados solues j testadas para problemas de
modelagem que ocorrem com frequncias em situaes especficas. Cada Padro de
Projeto descreve um problema especfico que ocorre frequentemente nos ambientes
de desenvolvimento de software e, ento, descreve a/uma soluo de forma a poder
reus-la inmeras vezes em novas situaes. Seria um reuso amplo de ideias, no
somente de cdigo-fonte.
J frameworks so considerados aplicaes quase prontas, faltando apenas prover
as partes faltantes, que normalmente so especficas para cada aplicao. Uma boa
analogia em relao a frameworks o conceito de pr-pizza, onde temos a base de
po, o molho de tomate e at mesmo o queijo, tudo previamente colocado; Caso
queiramos uma pizza especfica, calabresa por exemplo, basta completa-la com
os ingredientes faltantes.
O conceito de framework funciona melhor em domnio de negcios definidos, isto
, uma empresa de desenvolvimento de software para a rea de sade pode ter
um framework bsico desenvolvido e, sob demanda, complet-lo para aplicaes
de vrios portes, como sistemas de controle hospitalar (grande), clnicas mdicas
(mdio) e consultrios (pequeno porte), sendo que a base a mesma (clientes,
convnios mdicos, processos do Ministrio da Sade etc.).
18/7/2013 17:51:29
Process Black
58
Um framework, para ser realmente til e fazer a diferena do processo de
desenvolvimento de software, deve ser:
Reusvel;
Amplamente documentado;
Fcil de usar;
Extensvel;
Seguro;
Eficiente;
Completo o quanto possvel.
Gera, com isso, economia de tempo e dinheiro, aumento da qualidade,

compatibilidade entre softwares do mesmo domnio de aplicao e armazenamento
do conhecimento dos especialistas. importante frisar, porm, que estes grandes
benefcios aparecem somente a mdio e longo prazo.
Atividades
O tamanho dos mdulos diretamente proporcional a sua capacidade de reuso.
Reuso de software reduz riscos porque os maiores custos esto relacionados a
concepo original do software.
O uso de frameworks no promovem/facilitam o reuso de software.
Software pode ser considerado patrimnio intelectual e financeiro da empresa
quando reuso promovido.
O desenvolvimento de um framework de uma aplicao gera benefcios a curto
prazo, ou seja, j em seu primeiro uso.
18/7/2013 17:51:30
Process Black
Bibliografia
59

2003.
Gabarito:
F
18/7/2013 17:51:30
Process Black
60
18/7/2013 17:51:30
Process Black
TESTE DE SOFTWARE
Este captulo discute o processo de Teste de Software e sua importncia tanto para
o processo de desenvolvimento de software quanto para a sociedade.
apresentado o contexto atual da rea, as definies de Teste de Software, os
provveis defeitos e falhas que podem ser encontrados em produtos de software,
bem como o processo formal e as tcnicas de teste.
6.1 Contexto atual do Teste de Software

Atualmente tem-se uma completa dependncia dos softwares no mundo
moderno, sendo que quase tudo que conhecemos possui um software embutido
ou controlado por um, como em celulares, carros, avies, televisores, redes de
comunicao telefnica, redes de transmisso de energia, redes de fornecimento
de gua potvel, sistema financeiro e bancrio, entre vrios outros produtos e
processos do cotidiano.
Pesquisas antigas, do ano 2000, j comprovavam perdas financeiras da ordem de
60 bilhes de dlares com erros de software, que hoje, certamente pela maior
quantidade e complexidade dos softwares mais modernos - esto com cifras de
trs ou quatro dgitos em bilhes de dlares. Essa mesma pesquisa mostrou que,
caso fossem feitos mais testes e estes testes fossem mais abrangentes e eficientes,
ao menos 50% destas perdas poderiam ser economizadas e vidas poupadas.
Testes de Software tornam-se, ento, fatores cruciais para a Qualidade de Software,
sem, entretanto, ser sinnimo de Qualidade de Software. A satisfao de um cliente/
usurio (qualidade) passa pelo correto funcionamento do software (sem erros/
falhas), mas este fator no o nico e nem, em muitos casos, o principal fator. Tal
18/7/2013 17:51:30
Process Black
62
constatao no diminui a importncia desta etapa do processo de desenvolvimento
de software, muito pelo contrrio.
Alguns erros clssicos da rea de Teste de Software so bem conhecidos e
apresentaram consequncias desastrosas, tanto em perdas financeiras quanto em
perdas de vidas humanas:
Choque da Estao Climtica enviada para pesquisa em Marte Perda de US$

165 milhes;
Avio comercial Airbus A320 abatido por engano 290 vtimas fatais;
Mquinas de radiao em tratamento de cncer dezenas de vtimas fatais;
Sistema de ambulncia (SAMU) de Londres em 1992 - vrias vtimas fatais;
Queda de avio comercial A300 em 1994 264 vtimas fatais;
Mssil Scud na Guerra do Golfo 30 vtimas fatais;
Vrios colapsos de telefonia Milhes de pessoas atingidas.
Estes exemplos reforam tanto a necessidade de desenvolvimento de software com

mais respeito e cuidado quanto a necessidade de processos de testes de software
mais abrangentes e eficazes.
Este respeito (pregado em amplitude pela Engenharia de Software como um
todo) advm de fatos cientificamente comprovados como o que diz que, mesmo
em softwares construdos com bastante cuidados, so esperadas (consideradas
normais) 5 (cinco) a 10 (dez) falhas a cada mil linhas de cdigo.
6.2 Definio de Teste de Software

O Teste de Software pode ser definido, de forma mais simples, como o processo
de executar um programa com o objetivo de revelar a presena de erros.
A partir desta definio, pode-se verificar que o processo de teste sempre
incompleto e no garante a inexistncia de erros no programa (nenhum processo
de teste de software garante 100% de inexistncia de erros).
Em uma definio mais completa/complexa tem-se que Teste de Software consiste
na verificao dinmica do funcionamento de um programa em um conjunto finito
de casos de testes, cuidadosamente selecionado dentro de um domnio infinito de
entradas, contra seu funcionamento esperado.
Analisando parte a parte da definio completa acima tem-se:
Verificao dinmica Necessidade de execuo do programa (apesar de

existirem mtodos de teste que podem ser executados sem a execuo do
programa);
18/7/2013 17:51:30
Process Black
Conjunto finito Os casos de teste so infinitos conceitualmente, sendo que

ento necessrio selecionar alguns mais apropriados;
Seu funcionamento esperado O teste basicamente consiste na comparao entre

o resultado obtido na execuo contra o resultado esperado conceitualmente/
oficialmente (normalmente a partir dos requisitos de software).
63
A terminologia da rea de Teste de Software inclui termos que precisam ser bem
definidos:
Falta Causa de um mau funcionamento;
Falha Efeito observvel no desejvel;
Erro Diferena entre o valor obtido e o valor teoricamente correto;
Exceo Evento causador da suspenso da execuo do programa;
Anomalia Qualquer coisa observada no programa que no est de acordo

com as expectativas (requisitos);
Verificao Estamos construindo certo o produto?
Validao Estamos construindo o produto certo?
Orculo Entidade responsvel pela determinao do valor teoricamente

correto.
Os Testes de Software so regidos por uma srie de princpios:
No planejar o teste assumindo que o programa est correto;
Caso de teste bem sucedido aquele que tem alta probabilidade de detectar
erros ainda no descobertos;
Testes devem ser executados por outras pessoas que no o autor do

programa;
Dados de teste devem ser sempre invlidos e no esperados;
Sempre necessrio previamente determinar os resultados esperados;
Casos de testes devem ser mantidos por toda vida til do sistema.
6.3 Provveis defeitos e tipos de falhas

Os provveis defeitos em um produto de software normalmente so gerados por
seres humanos e:
Podem ocorrer desde a especificao de requisitos;
So gerados na comunicao entre stakeholders;
Continuam presentes nos programas mesmo aps processos de manuteno;
18/7/2013 17:51:30
Process Black
64
Encontram-se em partes do cdigo-fonte raramente usadas;
Quanto antes revelados, mais barato fica sua correo.
Os tipos de falhas mais comuns em software incluem:
Algoritmo Erros de lgica de programao;
Sintaxe Erros de escrita de cdigos-fonte;
Preciso Erros relacionados a tipos de dados em frmulas matemticas;
Sobrecarga Erros relacionados a estouros de capacidade em estruturas de

dados;
Coordenao Erros relacionados coordenao de sistemas distribudos;
Recuperao Erros relacionados recuperao de eventos inesperados, como

falhas de energia;
Hardware Erros (raros) de hardware.
6.4 Processo de Teste de Software

O Teste de Software deve ser implementado atravs de um processo documentado
e bem conhecido. Ele no deve ser considerado apenas uma das etapas do processo
de desenvolvimento de software aquela aps a codificao , mas sim deve
ser feito em paralelo a todas as etapas do processo de desenvolvimento, testando
desde requisitos at mesmo testes de software.
O processo de teste deve incluir etapas de:
Planejamento Definir os objetivo do processo de tese;
Projeto Projeto detalhado do plano de testes (conjunto de testes a serem

executados);
Execuo Execuo do programa com os casos de teste;
Anlise dos resultados Confronto entre os dados obtidos na execuo e os

dados teoricamente corretos.
6.5 Classificao dos Teste de Software

Os Testes de Software podem ser, para fins de estudo e anlise de aplicabilidade,
considerados como:
Estticos Inspeo do cdigo-fonte sem execut-lo;
Dinmicos Os mais tradicionais, que executam o programa para realizao

dos testes;
18/7/2013 17:51:31
Process Black
Simblicos Processo de execuo do programa com dados simblicos

utilizao de grafos;
Formais Teste de programa baseado em provador de teoremas

matemticos.
6.6 Tcnicas de Teste de Software
65
As tcnicas mais conhecidas de Teste de Software so:
Teste Funcional (ou Caixa Preta) Testa os requisitos funcionais do software,

sem acesso a detalhes de codificao;
Teste Estrutural (ou Caixa Branca) Teste da estrutura interna (cdigo-fonte)

do programa.
Alm desta classificao clssica, pode-se classific-los em:
Teste de Unidade;
Teste de Integrao;
Testa a integrao entre os mdulos do sistema testa a interface/

comunicao entre mdulos;
Teste de Validao;
Testa cada mdulo do programa separadamente;
Testa a conformidade do software com os requisitos originais,

normalmente dividido em teste Alfa (teste no ambiente do
desenvolvedor) e teste Beta (teste no ambiente do usurio);
Teste de Sistema;
Testes de segurana (acessos), estresse (condies anormais de volumes

de dados e acessos) e desempenho (tempo de resposta).
Muitas das tcnicas acima podem ser automatizadas, isto , implantadas em

processos automticos de testes, baseados em scripts programados pelos
testadores com base nos requisitos do software. A automao forte aliada em
testes de grandes volumes de dados, entretanto exigem profissionais de teste com
habilidades de programao.
18/7/2013 17:51:31
Process Black
66
Atividades
Teste de Software pode ser usado como sinnimo de Qualidade de Software.
O processo de Teste de Software, quando executado de forma correta, visa
garantir a inexistncia de erros no programa.
Teste de Software deve ser realizado tendo em vista que o software, por definio
de construo, contm erros.
Falhas de sobrecarga esto associadas ao mau projeto de estrutura de dados.
Testes funcionais e estruturais so complementares.
Bibliografia
PRESSMAN, Roger. Engenharia de Software, uma abordagem profissional. 7. Edio.
Porto Alegre: McGraw-Hill/Bookman, 2011.
SCHACH, Stephen. Engenharia de Software: Os Paradigmas Clssico e Orientado a
Objetos. 7. Edio. So Paulo: McGraw-Hill, 2009.
SOMMERVILLE, Ian. Engenharia de Software. 9. Edio. So Paulo: Pearson: 2011.
TONSIG, Srgio Luiz. Engenharia de Software Anlise e Projeto de Sistemas. So
Paulo: Futura, 2003.
Gabarito:
F
18/7/2013 17:51:31
Process Black
EVOLUO DE SOFTWARE
O objetivo deste captulo permitir uma discusso inevitvel em relao a produtos

de software: O que fazer quando o software comea a chegar perto do final de
seu ciclo de vida? Qual abordagem aplicar? Mant-lo? Substitu-lo? Descart-lo?
Atualiz-lo?
Essa discusso importantssima, visto que normalmente somente pensa-se
no processo de desenvolvimento de um software, sua concepo, e no na sua
manuteno e posterior aposentadoria.
7.1 Evoluo de Software

Softwares so produtos inerentemente mutveis, isto , sofrem diversas mudanas
e correes ao longo de sua vida til. A evoluo do software necessria tambm
para manter sua utilidade/aplicabilidade, pois caso o cenrio de utilizao/contexto
mude, ele precisa acompanhar/ser atualizado, caso contrrio se tornar intil e at
mesmo perigoso para a organizao.
Outro fator decisivo para a anlise da evoluo do software o ROI (retorno do
investimento), sendo que o investimento no desenvolvimento de um software
bastante alto e um processo de risco, portanto, busca-se a utilizao do sistema
por vrios anos.
7.2 Sistemas Legados

Sistemas legados so softwares que foram desenvolvidos h um bom tempo
muitas vezes mais de uma dcada e que continuam desempenhando um papel
estratgico decisivo na organizao.
18/7/2013 17:51:31
Process Black
68
Entretanto, depois de tanto tempo, os sistemas no so mais os originalmente
desenvolvidos, tendo sofrido diversas alteraes devido a:
Mudanas Internas;
o
Mudanas na organizao da empresa;
Mudanas de gesto na empresa;
Mudanas de pessoas e cargos na empresa;
Mudana de ramo de atividade por parte da empresa;
Erros no sistema que devem ser reparados;
Incluso de novas tecnologias na infraestrutura da empresa;
Mudanas Externas;
o
Mudanas na economia regional, nacional e internacional;
Alteraes de leis e regras;
Mudanas de sistema monetrio e troca de moedas;
Em relao s pessoas fator crtico no desenvolvimento de software os legados

sofrem consideravelmente, visto que provavelmente nenhuma pessoa envolvida
na sua criao ainda permanea nos quadros da empresa, gerando o fato de que
ningum mais o conhece integralmente. Este fato coloca importncia extra na
documentao de um sistema de software.
Pode ser considerado fcil o processo de atualizao ou migrao de plataformas de
hardware ou redes de computadores, entretanto, a mudana de softwares certamente
no . uma estratgia de negcios extremamente arriscada, visto que:
Processos corporativos e de sistemas altamente entrelaados;

o
Alterao no sistema, levando alteraes de processos, e vice-versa;
Regras de negcios e restries corporativas inseridas no sistema e no

documentadas em nenhum outro lugar.
Tecnicamente tambm existem vrios problemas relacionados aos sistemas legados,

como:
No h estilo ou padro de programao, j que diferentes pessoas ao longo

do tempo alteraram o cdigo;
18/7/2013 17:51:31
Process Black
Linguagem de programao obsoleta - Dependendo do tempo de vida do

legado, este pode ter sido escrito em linguagens antigas, como COBOL, o que
dificulta encontrar mo-de-obra, suporte e documentao;
Raramente existe especificao/documentao completa do sistema legado;

o
Documentao original perdida;
Documentao original presente, porm desatualizada;
Em alguns casos no se tem acesso ao cdigo-fonte, somente ao executvel,

o que leva necessidade de engenharia reversa ou construo de mdulos
externos que contornem este problema;
Estrutura do sistema corrompida, que leva a problemas de performance e

segurana;
Dados espalhados (replicados) em vrios arquivos.
69
7.3 Estratgias em Sistemas Legados

O tratamento de Sistemas Legados normalmente resume-se a quatro estratgias/
abordagens, sendo que a deciso entre elas depende de vrios fatores, tcnicos e
de negcios:
Descartar o sistema;
Manter o sistema;
Transformar o sistema;
Substituir o sistema.
A deciso entre selecionar uma ou outra estratgia deve considerar aspectos

como:
Perspectiva de negcios Valor do sistema para a empresa;
Perspectiva tcnica avaliao de qualidade tcnica remanescente no

sistema;
Ambiente
o
Estabilidade do fornecedor;
Taxa de falhas do sistema;
Desempenho atual;
Custos de manuteno;
Capacidade de interoperabilidade;
18/7/2013 17:51:31
Process Black
70
Software legado
o
Facilidade de utilizao e compreenso;
Documentao;
Dados;
Desempenho;
Linguagem de programao
A estratgia de Descartar o sistema considerada uma estratgia radical e

definitiva, visto que prega simplesmente que o sistema seja descartado, junto com
seus dados e regras. Tal ao somente pode ser considerada em casos onde, por
exemplo, a empresa est abandonando uma rea de negcios especfica e, portanto,
este sistema e seus dados no so mais importantes.
Na estratgia de Manter o sistema tem-se o foco na manuteno tanto reparativa
quanto adaptativa do software, visando a extenso da sua vida til. Normalmente
requer um grande investimento, visto que todos os fatores negativos acima
descritos encontram-se presentes. Normalmente neste foco no so acrescidas
novas funcionalidades ao sistema, apenas mantidas as atuais, o que leva cada vez
mais inevitvel obsolescncia da aplicao.
Para a manuteno do sistema so considerados fatores como:
Equipe de profissionais - Que devem ser fluentes tanto na linguagem de

programao legada quanto na rea de negcios do sistema;
Fatores tcnicos do programa Idade, linguagem, banco de dados etc.
Na manuteno importante a definio e real utilizao de um processo de

manuteno, que tem etapas de:
Solicitao de alterao;
Anlise de impacto Relevante para a aprovao ou no da alterao;
Planejamento da mudana Com muito cuidado para no danificar partes

boas do sistema;
Implementao da mudana;
Release/entrega do sistema.
O planejamento da mudana/manuteno crtico tambm no fator custo, pois

os custos de mudana podem chegar a ser 100 vezes maiores do que o custo de
desenvolvimento.
18/7/2013 17:51:31
Process Black
Na estratgia de Transformar o sistema abordada a alterao (modernizao)

da estrutura do sistema, isto , sua converso para solues tcnicas mais modernas
e seguras. Um exemplo de analogia de transformao de sistema seria no caso de
transformao de uma casa com paredes de madeira para paredes de alvenaria.
Neste caso, assim como no sistema, nenhuma nova funcionalidade acrescida na
casa, apenas as paredes existentes so modernizadas.
71
Em sistemas, esta transformao d-se normalmente pela substituio de uma

linguagem de programao legada (como COBOL) por uma linguagem mais atual,
como JAVA, ou mesmo a substituio de bancos de dados antigos e restritos como
CLIPPER para modernos sistemas gerenciadores de bancos de dados como ORACLE.
Uma das vantagens mais evidentes desta estratgia a reduo de custos e de
riscos envolvidos, entretanto, como desvantagem, temos a manuteno das
funcionalidades originais do sistema.
Na estratgia de Substituir o sistema aplica-se um processo de migrao que
pode ser bem longo e complexo do sistema legado para um novo sistema,
desenvolvido do zero. Normalmente neste momento considera-se a implantao
de sistemas de ERP (Enterprise Resource Planning), que, entretanto, no podem ser
considerados como soluo mgica para todos os problemas de TI da empresa.
Uma possvel soluo generalizada para sistemas legados, em relao as quatro
estratgias, pode se dar considerando fatores como qualidade do software legado
e seu valor de mercado:
Baixa qualidade e baixo valor de mercado Descartar o sistema;
Baixa qualidade e alto valor de mercado Transformar o sistema;
Alta qualidade e baixo valor de mercado Substituir o sistema;
Alta qualidade e alto valor de mercado Manuteno do sistema.
Atividades
Sistemas Legados podem apresentar problemas por causa de dados replicados e
estrutura corrompidas.
Dentro da perspectiva tcnica, a estratgia de descartar o sistema normalmente
abordagem mais adequada se o sistema apresenta baixa qualidade.
Substituir o sistema uma opo quando o valor de mercado alto.
O processo de migrao traz embutido o risco de se considerar a implantao de
um ERP uma soluo mgica.
Migrar plataformas de software mais fcil que atualizar infraestrutura.
18/7/2013 17:51:31
Process Black
72
Bibliografia
2003.
Gabarito:
V
18/7/2013 17:51:32
Process Black
QUALIDADE
O objetivo do captulo apresentar a rea de Qualidade, as motivaes para seu

estudo, seu histrico (desde 4000 AC), suas definies e seus princpios, definidos
por Deming.
Adicionalmente, abordamos as ferramentas de qualidade, os rgos certificadores e
os fatores humanos envolvidos na qualidade, bem como uma introduo ao 5s.
8.1 Motivaes no estudo da Qualidade

Podemos destacar inmeros aspectos importantes para motivar o estudo da
qualidade na rea de TI, especialmente da chamada Qualidade de Software:
Exportaes Crescimento das exportaes de software e servios, onde os

clientes externos exigem certificaes de qualidade como CMMI;
Licitaes Crescimento da exigncia de certificaes de qualidade em

licitaes do considerado maior cliente de TI do mercado, o governo (em todas
suas esferas);
Melhoria de Processos A melhoria dos processos de desenvolvimento de

software leva a uma maior produtividade e consequentemente a uma maior
lucratividade;
Crescimento Profissional Os conceitos de qualidade impactam e guiam

mudanas de comportamento e atitudes por parte dos profissionais de
desenvolvimento de software;
Globalizao;
Diferencial competitivo;
Padres internacionais.
18/7/2013 17:51:32
Process Black
74
Outro forte motivador pode ser visto na figura 8.1, que infelizmente ainda
representa vrias reas dos setores produtivos. Acredita-se que somente com
qualidade possvel mudar este cenrio.
Figura 8.1 Cenrio mundial da Qualidade.
mdia mundial
mdia japonesa
Brasil
peas rejeitadas
200/milho
10/milho
23000 a 28000/milho
retrabalho
2%
0,001%
30%
prazo de entrega
3 dias
2 dias
35 dias
treinamento
XX
10% das horas de

trabalho
1% das horas de
trabalho
Entretanto, o maior e mais forte fator motivador no estudo da qualidade o

lucro, que vem pela reduo de custos, estreitamento de laos com clientes e
fornecedores, correta delegao de competncias, com o consequente aumento
da lucratividade.
8.2 Histrico da Qualidade

A Qualidade um conceito antigo os primeiros registros remontam a 4000 AC, na
construo das pirmides do Egito - que entrou no centro das atenes depois da
Segunda Guerra Mundial, notadamente no Japo, pela necessidade de reconstruo
das fbricas e reconquista do mercado.
Um contexto histrico da Qualidade pode ser dividido em trs grandes
momentos:
Figura 8.2 Contexto Histrico da Qualidade
18/7/2013 17:51:32
Process Black
No primeiro momento, at a dcada de 1920, tem a dependncia da inspeo em

massa dos produtos no Taylorismo, um por um, pela no confiana nos processos
produtivos. Esse modelo no seria mais possvel no contexto atual da indstria pelo
grande volume de produo e consumo. Um dos mais notveis exemplos desta
poca pode ser visto no filme Tempos Modernos, com Charles Chaplin.
Em um segundo momento, no ps-guerra, tem-se uma evoluo para o chamado
Controle da Qualidade, normalmente uma seleo estatsticas de produtos a
serem retirados das linhas de produo para serem avaliados. Ao invs da anlise
da totalidade dos produtos apenas 2 ou 3% dos produtos so avaliados, no conceito
de lote. Caso estejam com problemas todo o lote condenado.
75
J no cenrio atual, desde a dcada de 1980, tem-se o foco da Qualidade na melhoria

preventiva dos processos de produo, ou seja, ao invs de se focar na deteco
e correo de produtos defeituosos, mais inteligente pesquisar e melhorar os
processos produtivos. neste cenrio que se insere a Qualidade de Software e
seus processos, ferramentas e certificaes.
8.3 Definies da Qualidade

Qualidade difcil de ser formalmente conceituada, visto que apresenta um
conceito relativo, isto , seu conceito diferente para diferentes envolvidos em
diferentes momentos e aspectos. O conceito mais aceito define qualidade como
Satisfao do usurio, isto , um produto tem qualidade quando satisfaz o seu
usurio/cliente.
Vrios autores tambm apresentam definies acerca do termo Qualidade:
Deming - Aperfeioamento contnuo e firmeza de propsitos. Compreender

o que acontece, construir e interpretar estatsticas e agir aperfeioando. No
h respostas corretas, apenas respostas geradas pelos mtodos usados para
ger-las. O objetivo deve ser as necessidades do usurio presentes e futuras.
Juran - Adequado ao uso.
Crosby - Conformidade com os requisitos, fazer certo da primeira vez.
Feigenbaum - O total das caractersticas de um produto e de um servio

referentes a marketing, engenharia, manufatura e manuteno, pelas quais o
produto ou servio, quando em uso, atende s expectativas do cliente.
Oakland - Atendimento s exigncias do cliente.
Ishikawa - Fabricar produtos mais econmicos, mais teis e sempre satisfatrios

para o consumidor.
18/7/2013 17:51:32
Process Black
76
Falconi - produto ou servio de qualidade aquele que atende perfeitamente,

de forma confivel, de forma acessvel, de forma segura e no tempo certo
s necessidades dos clientes. O verdadeiro critrio da boa qualidade a
preferncia do consumidor.
Dicionrio Aurlio - Qualidade como propriedade, atributo ou condio das

coisas ou das pessoas capaz de distingui-las das outras e de lhes determinar
a natureza.
NBR ISO 8402 - Qualidade a totalidade das caractersticas de uma entidade

que lhe confere a capacidade de satisfazer s necessidades implcitas e
explcitas.
As chamadas dimenses da qualidade ajudam na sua definio e so descritas

como:
Desempenho caractersticas primrias de operao de um produto;
Caractersticas secundrias/features Caractersticas secundrias ou opcionais

(no bsicas) de um produto;
Confiabilidade Probabilidade de falha de um produto;
Conformidade Grau de atendimento a padres por parte de um produto
Durabilidade Durabilidade prevista de um produto;
Capacidade de receber assistncia tcnica Incluindo velocidade, custo e

facilidade de conserto;
Esttica Qualidade subjetiva (julgamento pessoal) relacionada aparncia,

gosto, cheiro;
Qualidade percebida Influncia da origem (local) e fabricante do produto,

por exemplo, relacionado a produtos chineses;
Prontido de atendimento Capacidade de atendimento imediato ao

produto.
8.4 Princpios de Qualidade de Deming

W. Edwards Deming (1900-1993), um dos maiores autores da rea de Qualidade
definiu um conjunto de princpios relacionados qualidade de um produto:
Propsitos - Criar constncia de propsitos para melhoria de produtos e

servios;
Filosofia Encarar Qualidade como uma nova filosofia e adot-la

fortemente;
18/7/2013 17:51:32
Process Black
Dependncia da inspeo em massa Suspend-la pela melhoria dos

processos;
Negociao baseada apenas no preo Acabar com esta prtica nociva;
Sistema de produo e servios - Melhorar sempre e constantemente;
Treinamento - Instituir o treinamento e um programa educacional;
Liderana Adotar, instituir e incentivar a plena liderana;
Medo - Afastar o medo dos empregados quando da execuo de suas

tarefas;
reas de apoio - Derrubar as barreiras entre as reas de apoio/

departamentos;
Slogans, exortaes e metas Elimin-las entre os empregados;
Cotas numricas - Eliminar as cotas numricas como fator de qualidade;
Orgulho - Remover as barreiras ao orgulho da execuo;
77
Deming tambm considera Qualidade como um processo cclico, como no ciclo

PDCA:
Qualidade Diminuio do custo Melhoria da Produtividade Ganho de
Mercado Crescimento dos negcios Mais Competitividade Qualidade
Figura 8.3 - Ciclo PDCA - Fonte: http://www.sobreadministracao.com/wp-content/uploads/2011/06/ciclo-pdca.jpg
18/7/2013 17:51:32
Process Black
78
8.5 Ferramentas da Qualidade

A Qualidade pode ser trabalhada e materializada em diversas ferramentas,
algumas bem simples e outras mais complexas. Alguns exemplos de ferramentas
de qualidade so:
Check-lists (folhas de verificao) Como utilizados em decolagens de avies,

at que todos os itens a serem verificados estejam analisados e corretos, no
possvel continuar com a decolagem;
Diagramas de Pareto Ferramenta grfica para priorizao de problemas, pela

ordenao da frequncia de ocorrncia;
Diagramas de Causa-Efeito Tambm conhecidos como Espinha de Peixe ou

Diagrama de Ishikawa, visa identificar as causas de um problema pela relao
entre o efeito e suas causas causadoras;
Histogramas;
Grficos de disperso Exibem a mudana dinmica entre variveis

relacionadas;
Fluxogramas Grficos simples de ordenao e encadeamento de etapas;
Sistemas de informao Sistemas computacionais, desde os mais simples

controles at sistemas complexos como sistemas ERP;
Brainstorm Tcnica de gerao de ideias que envolve a contribuio espontnea

de cada participante;
Relatrios de auditoria.
8.6 rgos de Certificao da Qualidade

Os principais rgos pblicos ou privados de certificao da Qualidade
incluem:
ISO - International Organization for Standartization;
IEC - International Electrotechnical Commission;
IEEE - Institute of Electrical and Eletronics Engineering;
ANSI - American National Standards Institute;
ABNT -Associao Brasileira de Normas Tcnicas;
18/7/2013 17:51:33
Process Black
Tambm pode-se incluir aqui entidades independentes especializadas em

determinadas reas de produo, que medem, analisam e atestam atravs de
certificaes de reconhecimento de Qualidade, como:
ABIC Associao Brasileira da Indstria de Caf;
ABCP Associao Brasileira de Cimento Portland;
ABICAB - Associao Brasileira da Indstria de Chocolate, Cacau, Amendoim,

Balas e Derivados.
79
8.7 Fatores Humanos na Qualidade

A rea de Qualidade fortemente ligada cultura organizacional da empresa, e
normalmente apresenta forte resistncia a mudanas, entre todos os envolvidos
de todas as reas (alta administrao, gerentes intermedirios e pessoal de
produo).
O tratamento deste problema normalmente deve basear-se em um projeto de
mudanas que deve iniciar e ser apoiado pelos nveis superiores, atravs de
um projeto piloto. O CMMI, na qualidade de software, por exemplo, baseia-se
fortemente nesta ideia quando em seu nvel 2 aponta que a qualidade deva iniciar
pela definio de um (ou mais) projeto-piloto.
8.8 5S na Qualidade
O conceito de 5S (Cinco Sensos) na Qualidade surge no perodo ps-guerra
industrial japons, onde o sucesso da reconstruo passa diretamente pela
capacidade de produo de suas fbricas e pela qualidade dos seus produtos.
Senso 1 Seiri Utilizao
Senso 2 Seiton - Ordenao
Senso 3 Seisou - Limpeza
Senso 4 Seiketsu - Asseio
Senso 5 Shitsuke Autodisciplina
18/7/2013 17:51:33
Process Black
80
Atividades
Qualidade um conceito associado somente a processos, dissociado da satisfao
do usurio.
Qualidade um processo com fim em si mesmo, sem a caracterstica de ser
cclico.
Diagramas de Pareto so teis para definir a relao causa-efeito de um
problema.
Grficos de disperso e diagramas de Pareto so ferramentas de quantificao de
problemas.
Qualidade est associada s dimenses de desempenho e durabilidade.
Bibliografia
KOSCIANSKI, A. Qualidade de Software. Novatec, 2006..
2003.
Gabarito:
F
18/7/2013 17:51:33
Process Black
QUALIDADE DE SOFTWARE
Este captulo apresenta a especializao da Qualidade em produtos de software,

sua definio, os fatores e aspectos da qualidade, bem como suas normas.
Os enfoques da qualidade de software produto de software e processo de software
tm especial destaque no texto.
9.1 Software
Software , certamente, um produto diferente dos demais que estamos acostumados,
como televisores, celulares, automveis e outros, visto que um produto:
Intangvel;
Complicado;
Diferente;
Entretanto, um produto, e como tal pode (e deve) ser discutido em relao sua
qualidade.
O processo de desenvolvimento de software discutido desde seus primrdios,
mas foi efetivamente analisado em 1968, na Conferncia das Naes Unidas sobre
Software, que apresentou problemas relacionados a:
Cronogramas no observados;
Projetos abandonados;
Mdulos que no operam corretamente quando combinados;
Programas que no fazem exatamente o que era esperado;
18/7/2013 17:51:33
Process Black
82
Sistemas to difceis de usar que so descartados;
Sistemas que simplesmente param de funcionar.
Esses problemas, adicionados aos problemas do aspecto no repetitivo do processo

de desenvolvimento (tornando a tarefa difcil e imprevisvel), do problema da
delimitao do seu escopo e do problema da volatidade dos requisitos contribuem
fortemente para a necessidade de uma pesquisa e aplicao dos conceitos de
Qualidade na rea de Software.
9.2 Qualidade de Software

A Qualidade de Software pode ser definida como:
A qualidade de software um conjunto de caractersticas ou fatores de

software, que determinam o nvel de eficincia do software em uso, em relao
ao atendimento das expectativas dos clientes (IEEE).
Conformidade a requisitos funcionais e de desempenho explicitamente

declarados, a padres de desenvolvimento claramente documentados e a
caractersticas implcitas que so esperadas de todo software profissionalmente
desenvolvido (PRESSMAN)
A motivao para a busca da Qualidade de Software vem de:
Aumento da qualidade do produto;
Diminuio do retrabalho;
Maior produtividade;
Reduo do tempo para atender o mercado (time to market);
Maior competitividade;
Maior preciso nas estimativas.
Entretanto, a maior motivao para a implantao de um processo de Qualidade

vem dos clientes e usurios do software O cliente, o REI. Estes clientes/usurios
querem/exigem:
Atendimento aos requisitos especificados;
Defeito zero;
Alto desempenho;
Baixo custo;
Desenvolvimento rpido;
18/7/2013 17:51:33
Process Black
Facilidade de uso;
Eficincia nos servios associados;
Inovao.
83
Portanto, para que um software tenha efetivamente qualidade ele deve:
Preencher as expectativas do cliente;
Ser obtido dentro de um prazo previsto;
Ser produzido dentro de custos pr-estabelecidos;
Conformar com as especificaes de requisitos previamente estabelecidas;
Definir claramente o seu objetivo, a sua finalidade e o seu propsito;
Especificar seus requisitos para atender s necessidades do usurio;
Produzi-lo e utiliz-lo dentro de processos bem estabelecidos.
9.3 Fatores da Qualidade de Software

Os fatores da Qualidade de Software podem ser classificados em:
Implcitos visveis somente para os desenvolvedores/aspectos tcnicos;

o
Flexibilidade Facilidade de modificao;
Manutenabilidade Esforo necessrio para remover defeitos;
Testabilidade Facilidade de execuo de testes;
Eficincia Quantidade de recursos para cumprir determinada

tarefa;
Interoperabilidade Integrao das partes de um sistema;
Reusabilidade Possibilidade de reaproveitamento de software/

partes;
Portabilidade Capacidade de usar diferentes plataformas;
Estimativas Exatido nas estimativas de custo/prazo/esforo;
Estabilidade Extenso do ciclo de vida onde ele mantm a

qualidade.
18/7/2013 17:51:34
Process Black
84
Explcitos Visveis para os usurios/clientes do software.

o
Usabilidade Expressa a facilidade de uso;
Confiabilidade Capacidade de dependncia do software, por

determinado perodo de tempo;
Integridade Controle de acesso ao sistema;
Prazo Prazo estimado de entrega;
Informaes sobre o progresso Relatrios descrevendo o progresso;
Tempo de atendimento Tempo gasto para as manutenes;
Retorno do Investimento Retorno em forma de benefcios.
9.4 Aspectos da Qualidade de Software

Ao contrrio do senso comum, que Qualidade de Software est relacionada somente
ao seu processo de desenvolvimento, Qualidade de Software permeia software em
pelo menos quatro aspectos:
No Processo de Desenvolvimento
o
Definir um processo adequado para o ciclo de desenvolvimento;
Selecionar e aplicar mtodos adequados de anlise, projeto e

implementao;
Definir processos adequados de verificao e validao (testes);
Sistematizar os testes por meio de planos, procedimentos e documentos

de teste;
Utilizar ferramentas adequadas;
Aplicar normas e padres pertinentes;
Gerenciar a configurao do software;
Acompanhar e avaliar a evoluo das especificaes de requisitos;
No Processo de Aquisio
o
Buscar o produto mais adequado para a soluo do problema;
Comprovar o bom funcionamento do produto;
Garantir a existncia de bons fornecedores por meio de existncia de

treinamento e manuais de documentao.
18/7/2013 17:51:34
Process Black
No Processo de Integrao
o
Especificar de forma precisa os componentes a serem integrados;
Definir uma estratgia de integrao;
Sistematizar as fases de desenvolvimento do software
85
No Processo de Utilizao
o
Definir o processo de utilizao;
Definir os procedimentos de utilizao;
Fornecer treinamento aos usurios;
Definir os responsveis pelo software;
Manter os equipamentos hospedeiros;
Receber, em tempo, informaes precisas e corretas.
9.5 Normas da Qualidade de Software
ISO 9126 qualidade de produto
ISO 14598 qualidade de produto
ISO 12119 pacotes de software
ISO 12207 Processo/ciclo de vida
ISO 9000-3 ISO 9001 para software
CMM e CMMi
MPS.BR
PSP
SPICE
Entre outros.
9.6 Enfoques da Qualidade de Software

A Qualidade de Software pode ser encarada em dois enfoques:
Qualidade de Produto de Software;
Qualidade de Processo de Software.
18/7/2013 17:51:34
Process Black
86
A Qualidade de Produto de Software tratada inicialmente pela norma ISO 9126
(NBR 13596), de 1991 (em processo de atualizao para a norma ISO 25000) que
define Qualidade de Produto como Um conjunto de atributos que tm impacto na
capacidade do software de manter o seu nvel de desempenho dentro de condies
estabelecidas por um dado perodo de tempo.
A norma ISO 9126 dividida em quarto partes (livros):
9126-1 Modelo de qualidade de software;
9126-2 Mtricas externas;
9126-3 Mtricas internas;
9126-4 Mtricas para qualidade em uso.
A aplicao da norma ISO 9126 d-se em:
Definio dos requisitos de qualidade de um produto de software;
Avaliao das especificaes do software durante o desenvolvimento para

verificar se os requisitos de qualidade esto sendo atendidos;
Descrio das caractersticas e atributos do software implementado, por

exemplo nos manuais de usurio;
Avaliao do software desenvolvido antes da entrega ao cliente;
Avaliao do software desenvolvido antes da aceitao pelo cliente.
A norma ISO 9126 apresenta um conjunto da caractersticas e sub-caractersticas

a serem consideradas no processo de avaliao da qualidade do software:
Funcionalidade - Satisfaz s necessidades;

o
Adequao;
Acurcia;
Interoperabilidade;
Conformidade;
Segurana de acesso;
Confiabilidade Tolerante a falhas;

o
Maturidade;
Tolerncia a falhas;
Recuperabilidade;
18/7/2013 17:51:34
Process Black
87
Usabilidade - Fcil de usar;

o
Intelegibilidade;
Aprensibilidade;
Operacionalidade;
Eficincia Rpido, enxuto;

o
Tempo;
Recursos;
Manutenabilidade - Fcil de modificar;

o
Analisabilidade;
Modificabilidade;
Estabilidade;
Testabilidade;
Portabilidade Fcil de portar para diferentes plataformas computacionais

o
Adaptabilidade
Capacidade de instalao
Conformidade
Capacidade de substituio
Em adio norma ISO 9126, que traz as caractersticas pelas quais o produto
software deve ser avaliado, necessrio a definio de um processo formal de
avaliao, que dado na norma ISO 14598. A norma 14598 descreve, ento, um
processo ideal de avaliao de produtos de software e composta de seis partes/
livros:
ISO-IEC 14598-1: Viso Geral;
ISO-IEC 14598-2: Planejamento e Gesto;
ISO-IEC 14598-3: Processo para desenvolvedores;
ISO-IEC 14598-4: Processo para adquirentes;
ISO-IEC 14598-5: Processo para avaliadores;
ISO-IEC 14598-6: Documentao de mdulos de avaliao.
18/7/2013 17:51:34
Process Black
88
O processo definido na norma ISO 14598 composto de uma srie de
atividades:
Figura 9.1 - ISO 14598 Processo de Avaliao de Produto de Software.
A Qualidade de Processo de Software baseia-se na melhoria dos processos de

desenvolvimento de software tradicionais ou geis.
Um processo de desenvolvimento de software considerado imaturo traz vrios
problemas tanto ao processo em si quanto ao produto resultante:
Improvisado;
Dependente de profissionais;
Indisciplinado;
Baixa produtividade;
Baixo sucesso em previses e estimativas;
Altos custos de manuteno;
Problemas frequentes.
18/7/2013 17:51:34
Process Black
Os modelos e normas da Qualidade de Processo de Software incluem:
ISO 9000-3 Adaptao da norma ISO 9000 para produtos de software;
ISO 12207 Definio de processo, atividades, tarefas e artefatos de

desenvolvimento de software (tradicional);
o
Aquisio;
Fornecimento;
Desenvolvimento;
Operao;
Manuteno;
CMMI
MPS.BR
89
Atividades
Fatores de qualidade de software explcitos so mais percebidos pelos clientes do
que fatores implcitos.
Qualidade de software um conceito associado unicamente ao processo de
desenvolvimento, sendo quantificada no processo de testes.
Qualidade no processo de software se ocupa da minimizao de problemas no
produto final de software.
possvel analisar a qualidade de produtos de software somente com a ISO 9126.
Consultoria um dos aspectos da qualidade de software.
Bibliografia
KOSCIANSKI, A. Qualidade de Software. Novatec, 2006.
PRESSMAN, Roger. Engenharia de Software, uma abordagem profissional. 7. Edio. Porto Alegre.
18/7/2013 17:51:35
Process Black
90
SOMMERVILLE, Ian. Engenharia de Software. 9. Edio. So Paulo. Pearson, 2011.
2003.
Gabarito:
V
18/7/2013 17:51:35
Process Black
10
MATURIDADE EM QUALIDADE
DE SOFTWARE
O captulo apresenta o conceito de Maturidade em Qualidade de Software, bem

como os modelos mais famosos atualmente: O internacional CMMI e o nacional
MPS.BR.
O objetivo principal deste captulo, alm da apresentao dos modelos e seus
conceitos e nveis, capacitar o leitor tanto na importncia de sua implantao
como na correta seleo de modelo e de nvel de maturidade para cada realidade
de organizao.
10.1 Maturidade em Qualidade de Software

A qualidade de processos de desenvolvimento de software baseia-se em um
trip:
Processos;
Ferramentas;
Pessoas.
Todos estes aspectos devem ser igualmente abordados e melhorados para que
se tenha um processo de desenvolvimento maduro, que possa ser analisado
e classificado/ranqueado. Infelizmente, na rea de TI, apesar de possuirmos
grande domnio da rea de ferramentas sistemas operacionais, linguagens de
programao, sistemas gerenciadores de banco de dados, redes de computadores
etc. tem-se ainda srios problemas relacionados parte de processos (regras de
negcios em diferentes domnios de aplicao) quanto pessoas (especialmente
relacionados a comunicao e confiana).
18/7/2013 17:51:35
Process Black
92
Define-se maturidade o quanto um processo est:
Definido;
Gerenciado;
Medido;
Controlado;
Efetivo.
10.2 CMMI
O CMMI (Capability Maturity Model for Software Integration) uma estrutura de
modelo de maturidade de processos de desenvolvimento de software internacional,
definido inicialmente em 1986, no SEI (Instituto de Engenharia de Software) da
Universidade Carnegie Mellon, nos Estados Unidos da Amrica.
O CMMI foi desenvolvido sob encomenda do Departamento de Defesa Americano,
que procurava uma forma tanto de avaliar a capacidade de seus fornecedores de
software quanto de melhorar-lhes seus processos de desenvolvimento.
O seu foco foi definido em dois aspectos que at hoje garantem a efetividade e o
sucesso do modelo:
Foco em PROJETOS (projetos de curto prazo);
Foco em PEQUENOS PASSOS (nveis).
Adicionalmente, sua proposta baseia-se na experincia prtica das empresas, refletir

o melhor estado da prtica, ser documentado e ser pblico.
Atualmente, est na verso 1.3, e todos os materiais relacionados esto disponveis
no site oficial http://cmmiinstitute.com/. O CMMI indicado para grandes e mdias
empresas de desenvolvimento de software, com capacidade de investimento na
faixa de R$ 500.000 ou mais.
Figura 10.1 - Pgina oficial do CMMI Fonte: http://cmmiinstitute.com/.
18/7/2013 17:51:35
Process Black
Os objetivos do CMMI incluem:
Guiar organizaes a conhecerem e melhorarem seus processos de software;
Identificar prticas para um processo de software maduro, definindo as

caractersticas de um processo de software efetivo;
Descrever como as prticas de engenharia de software evoluem sob certas

condies;
Organizar os estgios de evoluo da melhoria dos processos em cinco nveis

de maturidade;
93
10.3 Nveis do CMMI

O CMMI organizado em cinco nveis de maturidade:
Figura 10.2 - Nveis do CMMI
No CMMI nvel 1 (nvel inicial) esto todas as empresas de desenvolvimento de

software que ainda no iniciaram seus processos de melhoria, e tem-se as seguintes
caractersticas (problemas):
No h repetibilidade dos processos;
Em crise h abandono de procedimentos;
As chances de sucesso baseiam-se em habilidades pessoais/GURUS/

HERIS;
Sucesso, qdo existe, em projetos com experincia anterior;
Tentativas isoladas de manuteno de procedimentos do processo;
As qualidades pertencem as pessoas, no aos processos;
Estimativas/cronogramas no realistas;
Mesmo o planejado no seguido (falta de costume).
18/7/2013 17:51:36
Process Black
94
A visibilidade (ou falta de) dos processos em nvel 1 nula, onde no h detalhes
do processo:
Figura 10.3 - Visibilidade do CMMI nvel 1
Para avanar ao CMMI nvel 2 comum:
Necessidade de mudana cultural;
Resistncia a mudanas;
Reaes intransigentes;
Falta de credibilidade de que d/dar certo;
Introduo gradativa de KPAs (reas chave de processos).
O CMMI nvel 2 (repetvel) considerado o primeiro nvel com qualidade no processo

de desenvolvimento de software e apresenta as seguintes caractersticas:
Polticas de gerncia de desenvolvimento de software definidas e seguidas;
Utilizao de experincias anteriores, de maneira formalizada e no

intuitiva;
Projetos usam processos definidos, documentados, usados, disseminados,

medidos, fiscalizados e com rotinas de melhoria;
Incluso de gerncia de projetos;
Compromissos assumidos com bases realistas;
Compromissos assumidos com base em requisitos documentados;
Desenvolvimento acompanhado e revisado (custos, prazos, etc...);
Mecanismos formais de correo de desvios;
Incluso de gerncia de requisitos;
A definio de processos feita por projeto pode no haver padronizao na

organizao;
Disciplina ao executar projetos;
Processos repetveis com resultados esperados;
As qualidades pertencem aos projetos, no mais s pessoas.
18/7/2013 17:51:36
Process Black
No CMMI nvel 2, a visibilidade do processo j maior, com mais possibilidades

de verificaes e correes:
Figura 10.4 - Visibilidade do CMMI nvel 2
95
No CMMI nvel 3 (definido), a qualidade evolui de projetos especficos para toda

a organizao, baseado principalmente em fortes programas de treinamento.
Apresenta as seguintes caractersticas:
Processos estabelecidos e padronizados na organizao no somente repetio

de sucessos de projetos anteriores;
Estabelecimento de infraestrutura de processos adaptveis a mudanas;
Aderncia ao processo mesmo em crise;
Processos ainda em nvel qualitativo;
Foco em documentao;
Processos de engenharia de software e gerenciais aplicados;
Oportunidade de escolha das melhores prticas;
Treinamento (tcnico e gerencial);
Possibilidade de adaptao dos processos s necessidades dos clientes;
Os processos pertencem organizao e no aos projetos.
No CMMI nvel 4 (gerenciado) o foco principal aborda mtricas, tanto qualitativas

quanto quantitativas. Apresenta as seguintes caractersticas:
Estabelecimento de metas quantitativas para processos e produtos;
Avaliao e anlise contnua do desempenho;
Melhoria no controle de processos e produtos;
Gesto baseada quantitativamente;
Proficiente em mtricas/anlise destas;
Base de dados de processo;
Gerenciamento de riscos.
18/7/2013 17:51:36
Process Black
96
E no nvel mximo do CMMI (nvel 5 em otimizao), procura-se manter e
expandir o modelo de maturidade em todos os processos de todos os projetos.
Apresenta as seguintes caractersticas:
Melhoria contnua de processos;
Identificao de pontos fracos e defeitos;
Ao preventiva;
Mudanas de tecnologia com base em anlises de custo/benefcio;
Aes visando reduzir retrabalho e desperdcio;
Melhoria da produtividade.
10.4 reas Chave do CMMI

As reas chaves (ou reas de processos) so usadas pelo CMMI para a avaliao
dos processos. Correspondem a um grupo de prticas relacionadas a uma rea do
desenvolvimento de software que, quando executadas, satisfazem um conjunto de
objetivos de melhoria de qualidade.
Prtica Objetivo rea de Processo
A tabela abaixo (figura 10.5) apresenta as reas de Processo dos cinco nveis do
CMMI:
Figura 10.5 reas Chaves do CMMI (todos os nveis)
Nvel
CMMI
rea Chave
CM Gerncia de configurao
MA Medio e anlise
PP Planejamento de projetos
PMC Acompanhamento de projetos
PPQA Garantia da qualidade do processo e produto
REQM Gerenciamento de requisitos
SAM Gerenciamento de acordos com fornecedores
PI Integrao de produto
RD Desenvolvimento de requisitos
TS Soluo tcnica
VER Verificao
18/7/2013 17:51:36
Process Black
Nvel
CMMI
97
rea Chave
OPD Definio do processo organizacional
OPF Foco no processo organizacional
OT Treinamento organizacional
IPM Gerenciamento integrado de projeto
DAR Deciso formal
RSKM Gerenciamento de riscos
QPM Gerenciamento quantitativo de projetos
OPP Desempenho do processo organizacional
CAR Anlise de causa
OID Inovao organizacional
10.5 Representaes do CMMI

O CMMI permite a representao da maturidade do processo de desenvolvimento
de software de duas maneiras:
Contnua Permite diferentes nveis de maturidade para diferentes reas

chave. Uma empresa de teste de software pode certificar somente as reas
chaves mais relevantes ao processo da empresa teste de software;
Estagiada Cada nvel representa um conjunto fixo de reas chaves.
Figura 10.6 Representaes de nveis do CMMI. Fonte: http://3.bp.blogspot.com/-m1T0Tf0K15A/T5MHd1eRbeI/AAAAAAAADFM/08MdfyK7niU/s400/CMMI.jpg
18/7/2013 17:51:36
Process Black
98
10.6 Processo de implantao do CMMI

O processo de implantao de CMMI, independente do nvel buscado, tipicamente
implementado com a ajuda de uma consultoria especializada e apresenta as
seguintes etapas:
Treinamento CMMI;
GAP analysis Anlise de lacunas no processo atual;
Melhoria do processo atual;
Elaborao de artefatos Processos, documentos, guias, templates etc.;
Implantao do CMMI em um projeto;
SCAMPI B Avaliao extraoficial do CMMI;
Correo de desvios;
SCAMPI A Avaliao oficial do CMMI.
10.7 SCAMPI avaliao do CMMI

O SCAMPI (Standard CMMI Appraisal Method for Process Improvement ou Mtodo
Padro de Avaliao CMMI para Melhoria de Processos) o mtodo oficial utilizado
em implantaes CMMI.
Normalmente dividido em dois momentos:
SCAMPI B Avaliao extraoficial do processo, normalmente realizado pela

mesma consultoria responsvel pela implantao. Visa detectar possveis falhas
e desvios remanescentes no processo de melhoria. importante para dar rumo
e segurana em direo avaliao final.
SCAMPI A Avaliao oficial do CMMI, conduzida por uma auditoria oficial.

Aps a anlise de documentos e processos, bem como de reunies com todos
os envolvidos, delibera-se e, caso no haja no conformidades, emite-se o
certificado oficial, que apresenta validade definida.
10.8 MPS.BR
O MPS.BR, acrnimo de Melhoria de Processo do Software Brasileiro, uma
adaptao ou verso do CMMI adequada a nossa realidade. indicado para
empresas de desenvolvimento de software de micro, pequeno e mdio porte, cujo
custo um fator crtico e projetos so pensados somente em pequeno prazo.
18/7/2013 17:51:37
Process Black
Est em desenvolvimento contnuo desde 2003 e envolve os trs ramos brasileiros

da rea de TI (Tecnologia da Informao):
Mercado Representado pela SOFTEX e RioSoft;
Academia Representado pela Coppe/UFRJ e CESAR;
Governo Representado pela CenPRA e Celepar.
99
Este foco triplo certamente um dos fatores de sucesso do modelo, visto que
tudo foi criado e implementado segundo os anseios de todas as reas envolvidas.
Atualmente est amplamente difundido para outros pases do Mercosul, como
Argentina, Peru etc. Hoje, conta-se com 400 empresas certificadas nos diversos
nveis MPS.BR.
composto por guias oficiais, que incluem:
Guia geral descrio geral do MPS.BR, detalhando o modelo de referncia

(MR-MPS), seus componentes e as definies comuns necessrias para seu
entendimento e aplicao;
Guia de aquisio Recomendao para a conduo de compras de software

e servios correlatos. Elaborado para guiar as instituies que iro adquirir
produtos de software;
Guia da avaliao Descrio do processo de avaliao, os requisitos para

o avaliador e para a avaliao, o mtodo e os formulrios para guiar a
avaliao.
A estrutura do MPS.BR dada em trs modelos oficiais:
Modelo de Referncia (MR-MPS)

o
Contm os requisitos a serem cumpridos pelas empresas que desejam

estar em conformidade com o MPS.BR;
Definies dos nveis de maturidade da capacitao de processos;
Mtodo de Avaliao (MA-MPS)

o
Processo de avaliao, os requisitos para averiguao da

conformidade;
Descrito de forma detalhada no guia de avaliao;
Modelo de Negcio (MN-MPS)

o
Descrio das regras para a implementao do MPS.BR pelas empresas

de consultoria, software e de avaliao.
18/7/2013 17:51:37
Process Black
100
O principal diferencial em relao ao CMMI a implantao em sete nveis (de
nvel A at nvel G), que possibilita, com isso, uma implantao mais gradual e
adequada a pequenas empresas. O custo de implantao tambm bem mais
reduzido e pode ser negociado com rgos de fomento estatal.
Figura 10.7 - Modelo MPS.BR Sete nveis de maturidade. Fonte: www.softex.br/mpsbr/
Uma grande contribuio do MPS.BR frente ao CMMI so as capacidades, isto ,

atributos de cada processo, indicando o quanto um processo ou rea chave est
madura, frente o nvel de maturidade MPS.BR de A a G:
1.1 Processo executado
2.1 Processo gerenciado
2.2 Resultado do processo (produtos) so gerenciados
3.1 Processo definido
3.2 Processo est implementado
18/7/2013 17:51:37
Process Black
Atividades
CMMI um modelo adequado a empresas com baixa capacidade de
investimento.
O objetivo do CMMI incluir guiar as organizaes a conhecerem e melhorarem
seus processos de software, identificando prticas para um processo de software
maduro.
101
O nvel 1 do CMMI trata do detalhamento dos processos, com visibilidade

mxima.
O nvel G do MPS.BR apresenta requisitos e projetos como gerenciados.
O modelo MPS.BR tende a ser mais indicado para empresas de pequeno porte.
Bibliografia
KOSCIANSKI, A. Qualidade de Software. Novatec, 2006.
TONSIG, Srgio Luiz. Engenharia de Software Anlise e Projeto de Sistemas. So Paulo: Futura, 2003.
Gabarito:
F
18/7/2013 17:51:37
Process Black
102
18/7/2013 17:51:38
Process Black
103
18/7/2013 17:51:38
Process Black
104
18/7/2013 17:51:38
Process Black

ES - Engenharia de Software I

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

ES - Engenharia de Software I

Transféré par

Droits d'auteur :

Formats disponibles

ENGENHARIA DE SOFTWARE I

Conselho Editorial EAD

Obra organizada pela Universidade Luterana do Brasil.

A Engenharia de Software est em constante atualizao e redesenho os Mtodos

Prof. Dr. Lus Fernando Fortes Garcia

Lus Fernando Fortes Garcia, prof. Dr.

Doutor e mestre em Cincias da Computao pelo Instituto de Informtica da

ULBRA Educao a Distncia

INTRODUO ENGENHARIA DE SOFTWARE .............................................................11

PROCESSO GEIS DE SOFTWARE..............................................................................33

ENGENHARIA DE REQUISITOS ..................................................................................43

4.2 Definies de Requisito .....................................................................................45

PROJETO E ARQUITETURA DE SOFTWARE ..................................................................53

TESTE DE SOFTWARE ...............................................................................................61

EVOLUO de software ............................................................................................67

10 MATURIDADE EM QUALIDADE DE SOFTWARE ............................................................91

ULBRA Educao a Distncia

Lus Fernando Fortes Garcia, prof. Dr.

Este captulo apresenta a grande rea da Engenharia de Software, seu histrico

1.1 Computadores e Software

ULBRA Educao a Distncia

Colapsos em centrais telefnicas;

1.2 Evoluo Histrica do Software

1. Gerao 1950 a 1960 Software para sistemas computacionais de grande

3. Gerao 1975 a 1990 Software para computadores de pequeno porte

4. Gerao 1990 a atual Softwares distribudos em todas as reas da

importante ressaltar que a evoluo no para nesta 4. Gerao novas

1.3 Questes sobre Desenvolvimento de Software

Software desenvolvido, no fabricado Software, diferentemente de

Software no desgasta Software, ao contrrio do hardware em que se pode

ULBRA Educao a Distncia

Figura 1.1 Desgaste em Software.

Natureza mutvel do software Esta uma questo central no desenvolvimento

ULBRA Educao a Distncia

Cronogramas no observados atrasos constantes;

Mdulos que no operam corretamente quando combinados;

Programas que no fazem exatamente o que era esperado;

Sistemas to difceis de usar e que so descartados;

Sistemas que simplesmente param de funcionar.

importante refletir que passados mais de 40 anos muitos (a maioria) desses

1.4 Enfoques do Desenvolvimento de Software

O desenvolvimento Artesanal (tambm conhecido por Gambiarra, P.O.G e outros)

1.5 Engenharia de Software

ULBRA Educao a Distncia

Esta definio muito relevante, porque destaca claramente os aspectos mais

Estabelecimento e uso - Ou seja, no adianta definir e estabelecer regras e

Slidos princpios de engenharia - desenvolvimento de software baseado nos

Se possa obter economicamente Apresenta o maior fator motivador da

Que seja confivel No contexto atual da sociedade, este fator indispensvel

O SEI (Instituto de Engenharia de Software da Universidade Carnegie Mellon, USA)

ULBRA Educao a Distncia

Gerenciamento de configurao de software;

Gerenciamento de engenharia de software;

Processo de engenharia de software;

Ferramentas e mtodos da engenharia de software;

A rea de Requisitos de Software aborda a elicitao, anlise, especificao e

A rea de Qualidade de Software enfoca questes relacionadas qualidade

ULBRA Educao a Distncia

1.6 Pirmide da Engenharia de Software

O conceito mais importante no estudo e prtica da Engenharia de Software seu

ULBRA Educao a Distncia

1.7 Princpios da Engenharia de Software

Rigor e formalismo O processo de desenvolvimento de software uma

Separao de preocupaes Este princpio visa tratar individualmente