UNIESP (AFARP) ASSOCIAO DAS FACULDADES DE RIBEIRO PRETO

LU BARBOSA BRAGIONE

ENGENHARIA DE SOFTWARE LL

Ribeiro preto/SP
2017
 LU BARBOSA BRAGIONE

ENGENHARIA DE SOFTWARE LL

Trabalho apresentado como exigncia da

disciplina de Engenharia de Software ll do
curso de Sistemas de Informao, sob
orientao do professor Elaine Cristina R.
Santos

Ribeiro preto/SP
2017
 LISTA DE FIGURAS

Figura 1 - tabelas 1 e 2 ............................................................................................... 5

Figura 2 - VISO GERAL .......................................................................................... 13
Figura 3 - PROCESSO DE SOFTWARE .................................................................. 14
Figura 4 - gerenciamento de projeto ......................................................................... 19
Figura 5 - custos........................................................................................................ 22
 SUMRIO

1 REUSO DE SOFTWARE: ........................................................................................ 4

1.1 1.2 BENEFICIOS DO REUSO: .............................................................................. 4

1.2 REUSIO DE COTS: .............................................................................................. 6

1.3 1.4 LINHAS DE PRODUTO:.................................................................................. 7

2 VERIFICAO E VALIDAO DE SOFTWARE: .................................................... 9

2.1 CONCEITO DE DEFEITO, ERRO E FALHA DE SOFTWARE .............................. 9

2.2 FASES DO TESTE DE SOFTWARE: ................................................................. 10

2.3 ESTRATGIAS PARA GERAO DE CASOS DE TESTE ................................ 11

3 QUALIDADE DE SOFTWARE: .............................................................................. 13

3.1 QUALIDADE DO PRODUTO E DO PROCESSO: .............................................. 14

3.2 CAPABILITY MATURITY MODEL CMM .......................................................... 16

3.3 MELHORIA DE PROCESSOS DO SOFTWARE BRASILEIRO - MPS.BR ......... 17

4 GERENCIAMENTO DE PROJETOS DE SOFTWARE: ......................................... 19

4.1 METRICAS DE SOFTWARE:.............................................................................. 20

4.2 GERENCIAMENTO DE TEMPO: PLANEJAMENTO E MONITORAMENTO E

CONTROLE .............................................................................................................. 21

4.3 GERENCIAMENTO DE CUSTOS: PLANEJAMENTO E MONITORAMENTO E

CONTROLE: ............................................................................................................. 22
 4

1 REUSO DE SOFTWARE:

Conceito...
O termo Linha de Produto de Software uma adaptao do que vm sendo
utilizado internacionalmente como
Software Product-lines. Esse termo uma clara referncia s linhas de
produo das indstrias de
Manufatura, as quais, no final do sculo XIX, introduziram uma revoluo no
processo produtivo, sugerindo
O desenvolvimento sequencial de produtos, baseado em tarefas repetitivas,
executadas sempre pelas mesmas
Pessoas que dispunham dos recursos materiais que necessitavam.
Conforme Cohen, a definio de software product-line com maior aceitao
na indstria a de
Clements e Northrop que diz o seguinte:
Uma linha de produto de software um conjunto de sistemas que usam
software intensivamente,
Compartilhando um conjunto de caractersticas comuns e gerenciadas, que
satisfazem as necessidades
De um segmento particular de mercado ou misso, e que so desenvolvidos
a partir de um conjunto comum
De ativos principais e de uma forma preestabelecida (Clementes e Northrop).
Dentro desta definio, alguns termos devem ser destacados, pois
representam as caractersticas mais
Importantes de uma linha de produto e sustentam as principais vantagens
propostas pelo modelo.
Os termos so:
Conjunto comum de ativos,
Forma preestabelecida
Segmento particular de mercado ou misso.

1.1 1.2 BENEFICIOS DO REUSO:

Para mapear melhor as vantagens propostas pelo modelo, COHEN 2003,

 5

Classificou os benefcios de uma linha de produto de duas maneiras:

tangveis: benefcios que podem ser medidos diretamente,
Como reduo do time-to-market ou reduo de defeitos.
intangveis: benefcios que os desenvolvedores relatam, mas que no podem
Ser medidos em termos de mtricas. Esses benefcios podem incluir
satisfao
Do cliente, animo dos recursos, etc.
Em seu estudo, Cohen explora ainda mais essa classificao, apresentando
uma
Lista de benefcios das duas categorias.

Figura 1 - tabelas 1 e 2

Fonte:
https://edisciplinas.usp.br/pluginfile.php/110500/mod_resource/content/1/Re%C3%BAso%20de%20Software.pdf
 6

Como era de se esperar, esses benefcios no vm de graa, por sinal, muito

longe disto.
A implantao e institucionalizao de uma linha de produto de software
muito custosa e,
Em consequncia disto, demanda muito cuidado e planejamento.
https://edisciplinas.usp.br/pluginfile.php/110500/mod_resource/content/1/Re
%C3%BAso%20de%20Software.pdf

1.2 REUSIO DE COTS:

H dois tipos de reuso de produtos COTS:

Sistemas de soluo COTS, soluo genrica de um nico fornecedor,
configurada
Para os requisitos do cliente.
Ex. Um sistema de gesto de bibliotecas
Sistemas integrados COTs, envolve a integrao de dois ou mais sistemas
COTs,
Talvez de diferentes fornecedores.
Ex. Um sistema ERP, como os da SAP, ORACLE, TOTVS etc.
Esta abordagem tem sido amplamente usada
Por empresas nas ltimas duas dcadas, para
Sistemas de Informao.
Vantagens:

Rapidez de implantao
No precisam dedicar muitos recursos para TI
A evoluo simplificada
Alguns riscos de desenvolvimento so evitados
possvel escolher as funes que necessita

Desvantagens/Riscos

Os requisitos precisam ser adaptados ao COTS

Quando os requisitos no podem ser adaptados, a
 7

Empresa precisa mudar seus processos de

Negcio.
A escolha do COTS que melhor se adequa
Empresa pode ser difcil e custosa,
Principalmente se no houver especialistas locais
E for preciso contratar consultores. Pode ser
Desastroso se errar.
O fornecedor do COTS controla a evoluo do
Sistema.

https://edisciplinas.usp.br/pluginfile.php/110500/mod_resource/content/1/Re
%C3%BAso%20de%20Software.pdf

1.3 1.4 LINHAS DE PRODUTO:

Definies Bsicas:
Tcnica de produo baseada em outras engenharias, fbricas que
desenvolvem uma mesma famlia de
Produtos com partes e recursos comuns.
Um conjunto de sistemas de software que:

Tm uma funcionalidade comum.

So construdos de uma forma prescrita visando uma misso
Especfica ou segmento de mercado.
So desenvolvidos utilizando componentes e recursos (ativos) de
Uma base comum.
Substancial economia de produo de software
Aplicvel em grupos de sistemas similares

Domnio: um conjunto de aplicaes existentes e futuras que compartilham

dados e
Funcionalidades comuns (tambm chamado de domnio de aplicao)
Anlise de domnio: o processo de identificar, coletar, organizar e
 8

representar as informaes
Relevantes de um domnio com base no estudo de sistemas existentes e suas
histrias de
Desenvolvimento, no conhecimento de especialistas no domnio, na teoria
subjacente e
Na tecnologia emergente dentro do domnio.
Um conjunto de sistemas intensivos em software que compartilha um conjunto
de caractersticas
Gerenciadas e comuns, que satisfaz a necessidades especficas de um
segmento de mercado em
Particular ou misso de uma empresa e que desenvolvido a partir de um
conjunto principal de
Recursos (ativos) de uma forma pr-estabelecida (Clementes and. Northrop
2002).
Podem ser implementadas usando geradores de aplicao, componentes,
frameworks, compilao
Condicional, aspectos, etc.
O reuso limitado e planejado.
https://edisciplinas.us
 9

2 VERIFICAO E VALIDAO DE SOFTWARE:

Diferena entre verificao e validao de software

1. Verificao:
2. Fizemos o software corretamente?
3. Esta atividade se resume em responder a esta pergunta. A verificao tem
o objetivo de avaliar se o que
4. Foi planejado realmente foi realizado; ou seja, se os requisitos e
funcionalidades documentados foram
5. Implementados, alm disso a verificao tambm pode ser realizada para
especificao de sistemas, para
6. Avaliar se os requisitos esto sendo documentados como deveriam e ainda
prever falhas ou inconsistncias
7. Entre requisitos.
8. Validao: Fizemos o software correto?
9. A validao tem o objetivo de avaliar se o que foi entregue atende as
expectativas do cliente; ou seja,
10. Se os requisitos, independente do que foi planejado, esto sendo
implementados para atender a regra de
11. Negcio do cliente, se o sistema realmente aquilo que o cliente quer e
est pagando para ter, A
12. Validao final do sistema realizada pelo prprio cliente ou usurio.

Ou seja:
Verificao (no contexto de testes) o conjunto de atividades que garante
Que o software implementa corretamente uma funo especfica, enquanto
validao garante que o mesmo corresponde aos requisitos
https://bugless.wordpress.com/2011/05/19/verificacao-validacao-e-teste-de-
software/

2.1 CONCEITO DE DEFEITO, ERRO E FALHA DE SOFTWARE

Muitas pessoas pensam que defeito, erro e falha so sinnimos. Porm, na

 10

rea de
Qualidade de Software, cada uma dessas palavras possui uma definio:
Defeito: resultado de um erro encontrado num cdigo ou num documento;
Erro: engano cometido por seres humanos;
Falha: resultado ou manifestao de um ou mais defeitos.
Exemplo: A aplicao entra em doping infinito, devido a um erro de lgica,
Ocasionando o travamento da mesma.
No exemplo acima citado, o defeito o looping infinito, que foi causado devido
a um
Erro de lgica do programador e a falha o travamento da aplicao.
Como podemos notar, o maior problema a falha, pois ela que afeta
diretamente o usurio.
Alm disso, um defeito poder demorar vrios anos para ocasionar uma falha,
sendo que ele j
Estava presente na aplicao, desde a sua instalao.

Erros so cometidos pelos programadores, ocasionando inconsistncias,

deficincias e comportamentos inesperados (fora da especificao).
Falhas so eventos notveis originados por defeitos.

https://www.desenvolvedormatteus.com.br/conceitos-testes-software/

2.2 FASES DO TESTE DE SOFTWARE:

Os testes devem estar presentes em todo o processo de desenvolvimento de

software,
Geralmente so divididos nas seguintes fases:
Testes de Unidade: a fase de testes onde cada unidade do sistema
testada individualmente.
O objetivo isolar cada parte do sistema e garantir que elas esto funcionando
conforme especificado,
Porm no garante que a integrao dessas partes ir funcionar
corretamente. Ex: no teste da funo que valida CPF,
O teste se resume apenas em checar se a funo capaz de dizer se o CPF
 11

vlido ou no.
Testes de Integrao: Nesta fase as unidades do sistema so testadas de
forma combinada, o objetivo detectar
Falhas na interao entre as unidades integradas. No faz parte desta fase
os testes de integrao com outros sistemas.
Ex: Na integrao do cadastro de clientes com a funo que valida CPF, as
duas unidades j foram testadas individualmente
Na fase de testes de unidade, porm neste momento que a interao entre
elas validada.
Testes de Sistema: Nesta fase o sistema testado completamente, ou seja,
todas as funcionalidades do sistema so testadas,
Assim como as integraes com outros sistemas que possam existir. Os
testes no se limitam apenas a requisitos funcionais,
Requisitos no funcionais tambm so testados nesta fase.
Testes de aceitao: Nesta fase sero testadas as funcionalidades requeridas
pelo cliente durante o projeto. Deve ser feito,
Preferencialmente, pelo usurio final.
Com os testes sendo executados em todas as fases do desenvolvimento
possvel detectar falhas com antecedncia e entregar
O sistema com mais qualidade. Alm disso, quanto antes a falha for detectada
mais barato para corrigi-la, evitando aumento de
Custo desnecessrio no projeto
http://www.matera.com/br/2013/07/19/fases-de-testes-de-software/

2.3 ESTRATGIAS PARA GERAO DE CASOS DE TESTE

A gerao de dados de teste de forma manual utilizada nas seguintes

Situaes:

Testes que envolvam tarefas mais intelectuais e que exijam anlise e

pensamento
Lgico;
Testes de usabilidade;
 12

Tarefas dinmicas;
Em sistemas que apresentam ciclo de vida curto.

Os dados de entrada so gerados baseados nas sadas esperadas e

inseridos com
Intuito de analisar o comportamento dos programas o que acaba sendo uma
forma muitas
Vezes tendenciosa, considerando que o produto final ser executado de forma
a percorrer
O caminho esperado pela equipe de desenvolvimento, ou visando a satisfazer
determinado
Requisito de teste.
A gerao automatizada de dados de testes:
Consiste na utilizao de ferramentas
Que executem os testes na aplicao, por meio da implementao de scripts.
Dessa forma,
A ferramenta simula uma utilizao do software testado e verifica os
resultados esperados.
Em geral utilizada nas seguintes situaes:

Quando envolver tarefas repetitivas;

Aplicaes com ciclos de vida longos;
Testes que devem ser feitos com maior frequncia.

http://www.inf.ufg.br/mestrado/sites/www.inf.ufg.br.mestrado/files/uploads/Dis
sertacoes/Disserta%C3%A7%C3%A3o-Daniel-Gomes-de-Oliveira-29092016.pdf
 13

3 QUALIDADE DE SOFTWARE:

Viso Geral:
Na dcada de 80, o fator qualidade emergiu como uma necessidade bsica
na luta pelo
Mercado cada vez mais competitivo.
O termo qualidade definido ambiguamente e diferentes significados
Podem ser atribudos a ele, em diferentes situaes e de acordo com a opinio
ou
Enfoque de quem faz uso.
O termo faz parte da linguagem cotidiana e a viso popular que se tem do
conceito
De qualidade pode ser muito diferente de como ele usado profissionalmente.
Viso Popular:

Algo abstrato
Perfeio
Luxo e questo de gosto

Viso Profissional:

Conformidade aos requisitos

Adequao ao uso

Figura 2 - VISO GERAL

 14

Fonte: https://edisciplinas.usp.br/pluginfile.php/57546/mod_resource/content/1/Aula8-QualidadeSoftware.pdf

3.1 QUALIDADE DO PRODUTO E DO PROCESSO:

Figura 3 - PROCESSO DE SOFTWARE

Fonte: www.RafaelAmaral.com.br

Um Processo Software um conjunto de atividades, parcialmente ordenadas

 15

com a finalidade
De obter um produto de software e considerado um dos principais
mecanismos para se obter
Um software de qualidade (Wikipdia).
Ento, tudo que precisamos para gerar um produto de software de qualidade
um bom Processo
De Software que se adapte realidade de uma empresa. Porm, no basta
apenas implement-lo,
Ou seja, deve-se ter o gerenciamento do processo como um todo a fim de
garantir que ele seja
Executado corretamente entre os envolvidos, ou caso contrrio, o caos tomar
conta de tudo
Trazendo o resultado inverso do que se esperava.
Em outras palavras, a qualidade de software estar em conformidade com
requisitos funcionais
E de desempenho explicitamente declarados de desenvolvimento, que devem
ser claramente documentados
E as caractersticas implcitas que so esperadas de todo o software
desenvolvido.
Outra caracterstica importante de um Processo de Software que ele visa
diminuio de falhas,
Ou seja, elaborar de forma sistemtica Casos de Teste a fim de identificar e
corrigir erros j na
Fase inicial do projeto. Corrigir erros no incio do projeto bem mais barato
do que depois de entregue.
Em outras palavras, entregar um produto de software sem falhas garante a
confiabilidade,
Eficincia e integridade do produto.
Por que utilizar um Processo de Software?
Mais de 30% dos projetos so cancelados antes de serem finalizados.
Mais de 70% dos projetos falham nas entregas das funcionalidades.
Os custos extrapolam em mais de 180% do oramento inicial.
Os prazos excedem em mais de 200% os cronogramas originais.
Fonte: www.RafaelAmaral.com.br
 16

3.2 CAPABILITY MATURITY MODEL CMM

O CMMI (Capability Maturity Model Integration) evoluiu e integrou diversos

modelos de maturidade
Anteriormente desenvolvidos (SW-CMM, SE-CMM, IPD-CMM), consolidando
um framework que
Consistente com a norma ISO/IEC 15504 ou SPICE (Software Process
Improvement and Capability dEtermination).
O CMMI possui uma arquitetura basicamente composta pela definio de um
conjunto de reas de processo,
Organizadas em duas representaes diferentes: um modelo por estgio,
semelhante ao SW-CMM e um modelo contnuo
, semelhante ISO/IEC 15504. Seu objetivo representar metas e
recomendaes genricas para orientar a
Melhoria de processos em geral, no existindo solues prontas para serem
institucionalizadas. Na busca por
Melhorias relevantes, cabe a cada organizao entender e interpretar as
recomendaes em relao ao contexto,
Objetivo e estratgia de negcio. A gesto de competncias tambm
apontada como um objetivo das organizaes
Que buscam a melhoria seguindo os modelos de maturidade. Na perspectiva
do SW-CMM, a rea-chave de processo
"Programa de Treinamento" (TP - Nvel 3) tem como objetivo "desenvolver os
perfis e conhecimentos dos indivduos
De forma que eles possam exercer seus papis, eficiente e eficazmente" No
modelo CMMI por estgio,
Na rea de processo "Treinamento Organizacional" (OT Nvel 3) possui o
mesmo objetivo e orienta a organizao a:
Identificar as necessidades de treinamento, tanto tcnicos (para atuao
especfica em projetos) quanto operacionais
(Para atuao em processos organizacionais do dia-a-dia); disponibilizar
treinamentos; desenvolver mecanismos que
 17

Assegurem sua efetividade.

Os requisitos so analisados e validados:
Analisar sistematicamente os requisitos derivados para assegurar que eles
so
Necessrios e suficientes.
Validar os requisitos para assegurar que os produtos resultantes sero
executados
Conforme esperado
http://www.artigos.com/artigos/708-cmmi-um-dos-principais-modelos-da-
qualidade-e-o-mps-br-modelo-adaptado-a-realidade-brasileira.

3.3 MELHORIA DE PROCESSOS DO SOFTWARE BRASILEIRO - MPS.BR

O Modelo de Melhoria de Processo de Software Brasileiro (MPS.Br),

Tambm conhecido por Melhoria de Processo de Software (MPS) (SOFTEX,
2012) foi desenvolvido pela Associao para Promoo da Excelncia do
Software Brasileiro (SOFTEX) e visa melhoria do processo de software,
Preferencialmente, em micro, pequenas e mdias empresas; e baseado nas
Normas ISO/IEC 12207:2008, ISO/IEC 15504, ISO/IEC 20000, CMMI-DEV
e
CMMI-SVC, O MPS est dividido em quatro componentes:

1. Modelo de Referncia MPS para Software (MR-MPS-SW): contm

2. Os nveis de maturidade, processo e atributos do processo de
3. Melhoria de software voltados ao desenvolvimento de software,
4. Em conformidade com as normas ISO/IEC 15504-2.
5. Modelo de Referncia MPS para Servios (MR-MPS-SV): contm
6. As definies dos nveis de maturidade, processos e atributos do
7. Processo de software voltados a servios de software, em
8. Conformidade com os requisitos de modelos de referncia de
9. Processo da Norma Internacional ISO/IEC 15504-2;
10. Mtodo de avaliao: guia de boas prticas para a aquisio de
11. Software e servios.
 18

12. Modelo de Negcio: descreve regras de negcio para

13. Implementao do MPS-SW e MPS-SV.

http://www.acervodigital.ufpr.br/
 19

4 GERENCIAMENTO DE PROJETOS DE SOFTWARE:

Viso Geral:
O Gerenciamento de Projeto de Software a arte de confrontar os objetivos
da
Concorrncia, gerenciar riscos e superar obstculos para liberar com xito um
produto que
Atenda s necessidades dos clientes (que pagaram por ele) e dos usurios.
O fato de que to
Poucos projetos sejam indiscutivelmente bem-sucedidos o comentrio
suficiente sobre a
Dificuldade da tarefa.

Figura 4 - gerenciamento de projeto

Fonte: http://www.facom.ufu.br/~bacala/MDS/RUP-Gerenciamento%20de%20Projetos.pdf
 20

http://www.facom.ufu.br/~bacala/MDS/RUP-
Gerenciamento%20de%20Projetos.pdf

4.1 METRICAS DE SOFTWARE:

As mtricas devem ser simples, objetivas, fceis de coletar, fceis de

interpretar e difceis
De interpretar incorretamente. A coleta das mtricas deve ser automatizada
e no-intrusiva,
Ou seja, no deve interferir nas atividades dos desenvolvedores. as mtricas
devem contribuir
Para a avaliao da qualidade no incio do ciclo de vida, quando os esforos
para melhorar a
Qualidade do software so eficazes. Tendncias e valores absolutos de
mtricas devem ser usados
Ativamente pelas equipes de gerenciamento e de engenharia para informar o
andamento e a qualidade
Em um formato consistente. A seleo de um conjunto mnimo ou mais
extenso de mtricas depender
Das caractersticas e do contexto do projeto. Se ele for grande ou tiver
requisitos rigorosos de
Confiabilidade ou segurana e as equipes de desenvolvimento e avaliao
tiverem um timo conhecimento
Sobre mtricas, talvez seja til coletar e analisar as mtricas tcnicas. O
contrato pode exigir que
Determinadas mtricas sejam coletadas ou a organizao pode estar
tentando aperfeioar habilidades e
Processos em reas especficas. No h uma resposta simples que se adapte
a todas as circunstncias.
O Gerente de Projeto deve selecionar o que apropriado quando o Plano de
Mtricas for produzido.
No entanto, quando voc apresentar um plano de mtricas pela primeira vez,
convm manter a simplicidade,
Em vez de se arriscar e cometer erros.
 21

4.2 GERENCIAMENTO DE TEMPO: PLANEJAMENTO E MONITORAMENTO E

CONTROLE

O Gerenciamento de Tempo rene os processos necessrios para assegurar

que o projeto seja implantado
No prazo previsto. Ento so definidas as atividades para a realizao dos
subprodutos do projeto,
De forma a serem realizadas em uma sequncia lgica e
interdependentemente das demais atividades previstas,
Estimando-se o tempo e os recursos disponibilizados para a sua execuo. A
partir da, constri-se um cronograma
Fsico-financeiro, que permitir um controle das tarefas e possveis mudanas
no projeto (HOZUMI, 2006).
O planejamento estabelece metas e uma sequncia desejada de eventos para
atingi-las. O controle faz
Com que os eventos se aproximem da sequncia desejada e inicia a
reprogramao quando a sequncia no
For vivel ou desejvel.
O monitoramento e controle so processos que visam observar e acompanhar
a execuo do
Projeto, permitindo que potenciais problemas possam ser antecipadamente
identificados
Para que aes corretivas sejam tomadas antes de os problemas tomarem
propores incontrolveis.
Dessa forma, todo o planejamento do empreendimento acompanhado
continuamente junto sua execuo,
A fim de que os recursos e os custos utilizados estejam dentro dos nmeros
pr-estabelecidos.
Controlar o cronograma o processo de monitoramento do andamento do
projeto para a atualizao de seu
Progresso e gerenciamento das mudanas feitas na linha de base do
cronograma. O controle do cronograma
Est relacionado a:
 22

1. Determinao da situao atual do cronograma do projeto;

2. Influncia nos fatores que criam mudanas no cronograma;
3. Determinao de que o cronograma do projeto mudou; e
4. Gerenciamento das mudanas reais conforme ocorrem.

4.3 GERENCIAMENTO DE CUSTOS: PLANEJAMENTO E MONITORAMENTO E

CONTROLE:

o processo de monitoramento e registro dos resultados da execuo das

Atividades de qualidade para avaliar o desempenho e recomendar as
mudanas necessrias.
Inclui os processos envolvidos em estimativas, oramentos e controle dos
custos,
De modo que o projeto possa ser terminado dentro do oramento aprovado.
Deve considerar os
Requisitos das partes interessadas para captura de custos.
O gerenciamento dos custos de projeto preocupa-se principalmente com os
custos dos
Servios necessrios para completar as atividades do projeto.
O custo de um projeto baseia-se no planejamento de todas as atividades
futuras, sequenciadas
Logicamente, de acordo com o ciclo de vida definido.

Figura 5 - custos

Fonte: http://repositorio.ufsm.br/bitstream/handle/1/75/Monografia2_Bernardi_Debora_Cole.pdf?sequence=1
23