CENTRO CIÊNCIAS EXATAS E TECNOLÓGICAS

ODAIR JOSÉ DE ALMEIDA

ENGENHARIA DE SOFTWARE:
MODELOS DE PROCESSOS, CICLOS DE VIDA E MÉTRICAS DE
SOFTWARE

Londrina
2011
 ODAIR JOSÉ DE ALMEIDA

ENGENHARIA DE SOFTWARE:
MODELOS DE PROCESSOS, CICLOS DE VIDA E MÉTRICAS DE
SOFTWARE

Trabalho de dependência, apresentado à Universidade

Norte do Paraná - UNOPAR, como requisito parcial para
a obtenção de média bimestral na disciplina de
Engenharia de Software.

Orientador: Prof. Luis Cláudio Perini

Londrina
2011
 SUMÁRIO

1 INTRODUÇÃO...........................................................................................................3
2 papel do software.......................................................................................................4
3 características da engenharia de software................................................................6
4 modelos de processos...............................................................................................9
5 métricas de processo e projeto de software............................................................18
6 CONCLUSÃO...........................................................................................................20
REFERÊNCIAS..........................................................................................................21
 3

1 INTRODUÇÃO

Este trabalho apresentará conceitos, características, tipos e

aplicações, tais como as vantagens e desvantagens de Modelos de Processos,
Ciclos de Vida e Métricas de Software.

Hoje, no desenvolvimento de software, tomamos conta a cada dia de

novos conceitos e maneiras de progredir com sucesso ou não um projeto de
software. Para isto, temos vários conceitos e técnicas, que tornam prática e ágil a
maneira de desenvolver novas rotinas e novos produtos.

Como referido, será apresentado mais sobre a Métrica de Software,

que nada mais é que a maneira de se “medir” e conhecer todos os horizontes de um
software e realizar uma avaliação objetiva sobre o mesmo. Os Modelos de
Processos são as estratégias de desenvolvimento que abrangem as camadas de
processos, os métodos e as ferramentas. O Ciclo de Vida de um software trata da
concepção, planejamento, amadurecimento e possível deterioração das funções
requeridas do sistema, segmentando requisitos intermediários que permitam
a validação do desenvolvimento do software, isto é, a conformidade do software com
as necessidades exprimidas, e a verificação do processo de desenvolvimento, a
adequação dos métodos aplicados.
 4

2 PAPEL DO SOFTWARE

O software atualmente entrega um dos bens mais preciosos para

qualquer área do conhecimento mundial, a informação. Como veículo usado para
entrega do produto, o software age como base de controle do computador (sistemas
operacionais), para a comunicação das informações (redes), e para criação e o
controle de outros programas (ferramentas e ambientes de software).
A importância do software tem passado por mudanças significativas
em pouco mais de 50 anos. Antes, a busca por avanços tecnológicos que só visava
à parte de hardware dos computadores, deixando-os muito mais rápidos e eficientes
provocou uma crise no meio tecnológico, pois os softwares para controle dos
mecanismos físicos não tinham recebido tanta importância.
Com o advento da Internet, houve uma “ressurreição” por parte dos
programadores norte-americanos, concorrendo para a invasão dos softwares em
nossas vidas.
O Software é um elemento de sistema lógico e não de um sistema
físico, diferenciando muito do hardware. Ambos são produzidos por pessoas, mas a
relação entre as pessoas envolvidas é inteiramente diferente. Requerem a
construção de um “produto”, mas as abordagens são diferentes. O hardware tem
índice de falha alta no início de sua vida útil, se aprimora, mas sofre desgaste físico
ao longo de seu uso. O software não se desgasta com o seu uso, mas sofrerá
modificações durante sua vida, sendo que essas modificações o deterioram cada
vez que são feitas.
Um software pode abranger várias aplicações potenciais:
• Softwares de Sistemas: servem a outros sistemas;
• Software de Tempo Real: software que monitora, analisa
ou controla eventos do mundo real à medida que eles
ocorrem;
• Software Comercial: processamento de informações
comerciais é a maior área de aplicação de software;
• Software Científico e de Engenharia: processam números
complexos nas áreas científicas;
• Software Embutido: residem situados nas memórias ROM
 5

e é utilizado para controlar produtos e sistemas para o

mercado consumidor e industrial;
• Software de Computadores Pessoais: processadores de
textos, planilhas, multimídias, diversão;
• Software para Web: incorpora ações executáveis em
browsers, como linguagens e protocolos;
• Software de Inteligência Artificial (A.I): utilizam algoritmos
não numéricos para resolver problemas complexos que
não são passíveis de computação ou análise direta.

Cercado de mitos e realidades, o software tornou-se elemento chave

na evolução de sistemas e produtos baseados em computador. O software é
composto por programas, dados e documentos. Cada um desses itens constitui
uma configuração, que é criada como parte do processo de Engenharia de
Software, que tem o intuito de fornecer uma estrutura para construção de um
software de alta qualidade.
 6

3 CARACTERÍSTICAS DA ENGENHARIA DE SOFTWARE

Engenharia de Software é a criação e a utilização de engenharia a

fim de se obter software de maneira econômica, que seja confiável e que trabalhe
eficientemente em máquinas reais, atendendo os objetivos de seus usuários. É uma
tecnologia de camadas, sendo sua base o foco na qualidade. Seu fundamento é o
processo. É o adesivo que mantém unidas as camadas de tecnologia e permite o
desenvolvimento racional do software. Os métodos de engenharia de software
fornecem a técnica de como fazer para construir o software. As ferramentas
fornecem apoio automatizado ou semi-automatizado para os processos e métodos.
Existem também as fases genéricas da engenharia de software,
independente do tamanho do projeto, sua aplicação ou de sua complexidade. São
elas:
• Fase de Definição: os requisitos-chaves do software são
identificados;
• Fase de Desenvolvimento: como os dados devem ser
estruturados, a linguagem que será utilizada, as interfaces,
etc.;
• Fase de Manutenção: focalizam as modificações associadas
com a correção de erros, as adaptações necessárias á
medida que o ambiente do software evolui.
Essas fases são complementadas por atividades guarda-chuva, que
são aplicadas ao longo de todo processo de software. São elas:
• Acompanhamento e controle de projetos de software;
• Revisões técnicas formais;
• Garantia de qualidade de software;
• Gestão de configuração de software;
• Preparação e produção de documentos;
• Gestão de reutilização;
• Medição e
• Gestão de riscos.
 7

3.1 ATIVIDADES DA ENGENHARIA DE SOFTWARE

Diferentes tipos de organizações abordam a engenharia de requisitos de

formas radicalmente diferentes. Uma companhia aeroespacial que especifica
sistemas de software e hardware muito complexos, não utilizará o mesmo processo
de engenharia de requisitos de uma empresa que desenvolve produtos de consumo
para computadores pessoais. No entanto, as diferenças entre estes processos
encontram-se geralmente no nível de detalhe dos processos. Num nível abstrato,
todos os processos de engenharia de requisitos podem seguir alguns métodos.
Antes de apresentar os modelos de ciclo de vida para o processo de engenharia de
requisitos, torna-se necessário compreender melhor as atividades nele envolvidas.
As atividades do processo de engenharia de requisitos são as seguintes:
• Os requisitos do sistema são obtidos através de consultas aos
stakeholders, documentação do sistema, conhecimento do domínio e
estudos de mercado. Este processo é também conhecido como
levantamento de requisitos.
• Os requisitos são analisados em detalhe e os diferentes stakeholders
negociam para decidirem que requisitos serão aceitos. Este processo é
necessário visto que é inevitável o aparecimento de conflitos entre
requisitos de diferentes fontes, existência de informação incompleta ou
então os requisitos podem ser incompatíveis com o orçamento
disponível para o desenvolvimento do sistema. Existe, no entanto,
alguma flexibilidade na negociação dos requisitos para que seja
possível concordar acerca do conjunto de requisitos para o sistema.
• Os requisitos aceitos durante o processo de negociação são
documentados com um nível de detalhe apropriado. Em geral, é
necessário existir um documento de especificação de requisitos que
seja compreendido por todos os stakeholders. Isto significa que os
requisitos devem ser detalhados utilizando linguagem natural e
diagramas. Podem também ser produzidos documentos de sistema
mais detalhados tais como modelos de sistema.
Todos os requisitos obtidos nas atividades anteriores devem ser
cuidadosamente verificados para apurar se estão completos e são consistentes.
Este processo tem como finalidade detectar potenciais problemas no documento de
 8

especificação de requisitos antes que este seja utilizado como base para o
desenvolvimento do sistema.
 9

4 MODELOS DE PROCESSOS

A integração dos modelos de processo de software durante o

processo de análise, desenvolvimento e finalização de um software tem se tornado
cada vez mais importante e essencial para que a qualidade se una com a
rentabilidade, tornando os softwares desenvolvidos por grandes empresas do ramo,
mais rentável para a mesma e satisfatória para os clientes que o adquirem.
Os Modelos de Processos em engenharia de software são
escolhidos com base na natureza do projeto e sua aplicação, nos métodos e
ferramentas a serem utilizados, e nos controles e nos produtos intermediários e
finais que serão requeridos. Um ciclo de soluções de problemas é aplicado ao
projeto, onde se avalia a situação atual do problema, a definição do problema,
desenvolvimento técnico e solução do problema. Cada modelo que será
apresentado a seguir possui particularidades, classificações e modos de serem
implantados distintos, mas sempre objetivando a maior qualidade possível na
concepção de um software confiável. Com o intuito de mostrar as diferenças entre
as duas linhagens de modelagem de processos de software, serão mostrados os
principais modelos e suas diferenças, melhorias no desenvolvimento e também os
contras de cada modelo.

4.1 MODELO DE SEQUENCIA OU LINEAR

Também chamado de Modelo Clássico ou Modelo em Cascata.

Sugere uma abordagem sistemática seqüencial para o desenvolvimento de software,
que começa no nível do sistema e progride através da análise, projeto, codificação,
teste e manutenção. Esse modelo abrange as seguintes atividades:
• Modelagem e engenharia do sistema: o trabalho começa com
o levantamento e estabelecimento de requisitos para todos os
elementos do sistema. Essa visão de sistema é essencial
quando o software precisa interagir com outros elementos tais
como hardware, pessoas e base de dados. Inclui um conjunto
de necessidades a nível estratégico e no nível da área de
negócios;
• Análise e requisitos de software: o processo de definição de
 10

requisitos é intensificado e focalizado especificamente no

software, quanto a sua função, o comportamento, o
desempenho e a interface. Os requisitos do sistema são
documentados e revistos com o cliente;
• Projeto: o projeto é um processo de múltiplos passos que
enfocam quatro atributos distintos do programa: estrutura de
dados, arquitetura do software, representações das interfaces
e detalhes procedimentais. Traduz a representação do
software que pode ser avaliada quanto à qualidade, antes que
a codificação tenha início;
• Geração de código: o projeto é traduzido para uma linguagem
de máquina;
• Testes: depois de gerado o código, os testes do programa se
iniciam. Focam os aspectos lógicos internos do software,
garantindo que todos os comandos sejam testados;
• Manutenção: certamente o software sofrerá mudanças depois
de ser implantado. Quando erros são encontrados, serão
necessárias modificações, para melhorar seu desempenho e
suas funcionalidades. A manutenção reaplica cada uma das
fases precedentes para corrigir alguma deficiência, não
precisando projetar um novo programa.
Apesar de ser um dos modelos mais antigos e ainda ser um dos
mais utilizados, esse modelo apresenta as seguintes desvantagens:
• Projetos reais raramente seguem o fluxo seqüencial inicial;
• É difícil para o cliente estabelecer todos os requisitos
explicitamente;
• Uma versão executável não ficará disponível até o projeto
terminar;
• Membros da equipe de projeto ficam ociosos esperando
outros membros da equipe completar suas tarefas.
Mesmo possuindo essas desvantagens, esse modelo ainda é
significativamente melhor do que uma abordagem aleatória para o desenvolvimento
de software.
 11

4.2 MODELO DE PROTOTIPAGEM

Como o próprio nome indica, será criado um protótipo, um projeto

rápido do software. Para isso, o cliente define um conjunto de objetivos gerais para o
software, mas não identifica detalhadamente requisitos de entrada, processamento e
saída. Através de uma entrevista, cliente e desenvolvedor procuram definir os
requisitos, objetivos gerais do software, identificam necessidades conhecidas e
áreas que precisam de mais definições. Esse processo compreende:
• Ouvir o cliente;
• Construir/revisar o protótipo;
• Cliente testa o protótipo.
Dessa entrevista um projeto rápido é realizado. Esse projeto rápido
parte de um protótipo, que serve como um mecanismo de identificação dos
requisitos do software. Serve como um primeiro sistema, aquele que normalmente
deverá ser descartado. Os usuários experimentam o sistema real, enquanto os
desenvolvedores sentem a sensação de construírem algo imediato. Contudo isso
provoca as principais desvantagens desse modelo:
• O cliente percebe que o protótipo é o que realmente ele quer
sem se dar conta que esse protótipo funciona precariamente;
• O desenvolvedor para ser mais rápido pode se utilizar de
meios que ele mesmo não conhece a fundo, como um
algoritmo ineficiente, e acaba por esquecer por que eram
inadequadas, mas que tomam parte do sistema final.
Para que isso não ocorra é necessário que as regras sejam bem
explícitas quanto à entrega do projeto, descartando o protótipo inicial e entregando o
software real no final do projeto.

4.3 MODELO RAD

O RAD (Rapid Application Development), desenvolvimento rápido de

aplicação, é um modelo de desenvolvimento incremental que enfatiza um ciclo de
desenvolvimento extremamente curto. É uma adaptação de alta velocidade do
modelo linear, mas baseada em construção de componentes. Abrange as seguintes
fases:
 12

• Modelagem do negócio: fluxo de informações entre as

funções do negócio;
• Modelagem dos dados: o fluxo de informação, definido como
parte da fase de modelagem é refinado num conjunto de
objetos de dados, que são necessários para dar suporte ao
negócio;
• Modelagem de processos: os objetos definidos na fase
anterior são transformados para conseguir o fluxo necessário
para implementar uma função do negócio;
• Geração de aplicação: o RAD considera o uso de técnicas de
quarta geração;
• Teste e entrega: como o RAD enfatiza o reuso muitos dos
componentes já devem ter sido testados. Isso reduz o tempo
de entrega e tempo total de testes.
Apesar dessa rapidez, o RAD também gera algumas desvantagens,
tais como:
• Recursos humanos tão grandes quanto a complexidade do
projeto;
• Desenvolvedores comprometidos com a rapidez. Caso não
haja esse comprometimento, os projetos RAD falharão:
• Nem todos os tipos de aplicação são apropriadas para o RAD;
• Riscos técnicos elevados, o RAD não é aconselhável, pois
pode ocorrer a incompatibilidade de tecnologias.

4.4 OS MODELOS EVOLUCIONÁRIOS

Esses modelos são interativos, caracterizados de forma a permitir

aos engenheiros de software desenvolver versões cada vez mais completas do
software.

4.4.1 Modelo incremental

Combina elementos do modelo seqüencial com a filosofia interativa

da prototipagem. Cada seqüência produz um incremento, sendo o primeiro chamado
 13

de núcleo do produto. Os requisitos básicos são satisfeitos, mas muitas

características suplementares deixam de ser elaboradas. O núcleo do produto é
utilizado pelo cliente para uso e avaliação e um plano é elaborado para o próximo
incremento. Esse plano visa à melhoria das funcionalidades e atendimento das
necessidades dos clientes. Esse processo se repete até que o produto completo
seja entregue. É um processo totalmente interativo. Os primeiros incrementos são
versões simplificadas do produto final, mas oferecem capacidades que servem aos
usuários, além de uma plataforma de avaliação. A principal exigência é que se tenha
uma pessoa experiente para o levantamento de requisitos, pois se não houver o
projeto final fica prejudicado.

4.4.2 Modelo espiral

Combina a natureza interativa da prototipagem com os aspectos

controlados e sistemáticos do modelo linear. Fornece potencial para
desenvolvimento rápido de versões incrementais do software. Desenvolve-se com
isso um software com base em várias séries de versões incrementais, ou seja,
versões mais completas a cada interação. Tipicamente existem de três a seis
regiões de tarefas em um modelo espiral, que são:
• Comunicação com o cliente: estabelece efetiva comunicação
entre desenvolvedor e o cliente;
• Planejamento: necessário para definir recurso, prazos e
outras informações relativas ao projeto;
• Análise de riscos: tarefas que avaliam riscos, tanto técnicos
quanto gerenciais;
• Engenharia: referente à construção de uma ou mais
representações da aplicação;
• Construção e liberação: tarefas necessárias para construir,
testar, instalar e fornecer apoio ao cliente;
• Avaliação pelo cliente: necessário para obter a realimentação
do cliente, com base na avaliação das representações do
software criadas durante o estágio de engenharia e
implementadas durante o estágio de instalação.
Depois do início do projeto, as equipes de desenvolvimento se
 14

movem em volta da espiral, no sentido horário, a partir do centro. Diferentemente

dos modelos clássicos de processo, que terminam quando o software é entregue, o
modelo espiral pode ser adaptado para aplicação ao longo da vida do software. É
um modelo com abordagem realística para desenvolvimento de sistemas e
softwares de grande porte. Contudo, o que se mostra uma desvantagem muito
grande para o resultado final, é a necessidade real de um desenvolvedor muito
experiente para avaliar os riscos do projeto, o que pode definir o sucesso ou o
fracasso do projeto.

4.5 OS MODELOS ÁGEIS

Os métodos ágeis diferem largamente no que diz respeito à forma de serem

gerenciados. Alguns métodos são suplementados com guias para direcionar o
gerenciamento do projeto, mas nem todos são aplicáveis. São considerados como
um sistema de gerenciamento de projeto complementar e adequado.
Uma característica comum dos processos ágeis é a capacidade de funcionar
em ambientes muito exigentes que tem um grande número de incertezas e
flutuações (mudanças) que podem vir de várias fontes como: equipe em processo de
formação que ainda não trabalharam juntas em outros projetos, requisitos voláteis,
baixo conhecimento do domínio de negócio pela equipe, adoção de novas
tecnologias, novas ferramentas, mudanças muito bruscas e rápidas no ambiente de
negócios das empresas: novos concorrentes, novos produtos, novos modelos de
negócio.
Sistemas de gerenciamento de projetos lineares e prescritivos, neste tipo de
ambiente, falham em oferecer as características necessárias para responder de
forma ágil as mudanças requeridas. Sua adoção pode incrementar
desnecessariamente os riscos, o custo, o prazo e baixar a qualidade do produto
gerado, desgastando a equipe e todos os envolvidos no processo.
A abordagem Scrum, para gestão de projetos ágeis, leva em consideração
planejamento não linear, porém de maneira mais exaustiva e está focada em
agregar valor para o cliente e em gerenciar os riscos, fornecendo um ambiente
seguro. Pode ser utilizada na gestão do projeto aliada a uma metodologia de
 15

desenvolvimento como Programação Extrema, FDD, OpenUP, DSDM, Crystal e

outras.

4.5.1 A abordagem SCRUM

Scrum é um esqueleto de processo que contém grupos de práticas e

papéis pré-definidos. Os principais papéis são:
• Scrummaster, que mantém os processos (normalmente no lugar
de um gerente de projeto)
• Proprietário do Produto, que representa os stakeholders e o
negócio
• Equipe, um grupo multifuncional com cerca de sete pessoas e
que fazem a análise, projeto, implementação, teste etc.
As atividades mais comuns são:
• Cada sprint é uma iteração que segue um ciclo e entrega
incremento de software pronto.
• Um backlog é conjunto de requisitos, priorizado pelo Product
Owner (responsável por conhecer as necessidades do cliente);
• Há entrega de conjunto fixo de itens do backlog em série de
interações curtas ou sprints;
• Breve reunião diária, ou daily scrum, em que cada participante
fala sobre o progresso conseguido, o trabalho a ser realizado
e/ou o que o impede de seguir avançando (também chamado de
Standup Meeting ou Daily Meeting, já que os membros da equipe
geralmente ficam em pé para não prolongar a reunião).
• Breve sessão de planejamento, na qual os itens do backlog para
uma sprint (iteração) são definidos;
• Retrospectiva, na qual todos os membros da equipe refletem
sobre a sprint passada.
O Scrum é facilitado por um Scrum Master, que tem como função
primária remover qualquer impedimento à habilidade de uma equipe de entregar o
objetivo do sprint. O Scrum Master não é o líder da equipe (já que as equipes são
auto-organizadas), mas atua como um mediador entre a equipe e qualquer influência
 16

desestabilizadora. Outra função extremamente importante de um Scrum Master é o

de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum,
motivando-os e mantendo o foco na meta da Sprint.
Scrum permite a criação de equipes auto-organizadas, encorajando
a comunicação verbal entre todos os membros da equipe e entre todas as
disciplinas que estão envolvidas no projeto.
Um princípio chave do Scrum é o reconhecimento de que desafios
fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma
abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem
empírica, aceitando que o problema não pode ser totalmente entendido ou definido,
focando na maximização da habilidade da equipe de responder de forma ágil aos
desafios emergentes.
Uma das grandes vantagens do Scrum, porém, é que não tem
abordagem "receita de bolo" do gerenciamento de projetos e tem como objetivos
atingir qualidade através da aplicação de uma série de processos prescritos.

4.5.2 A Programação Extrema (XP)

Programação extrema (do inglês eXtreme Programming), ou

simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que
irão desenvolver software com requisitos vagos e em constante mudança. Para isso,
adota a estratégia de constante acompanhamento e realização de vários pequenos
ajustes durante o desenvolvimento de software.
Os cinco valores fundamentais da metodologia XP são:
• Comunicação,
• Simplicidade,
• Feedback,
• Coragem e
• Respeito.
A partir desses valores, possui como princípios básicos:
• Feedback rápido,
• Presumir simplicidade,
• Mudanças incrementais,
 17

• Abraçar mudanças e
• Trabalho de qualidade.
Dentre as variáveis de controle em projetos (custo, tempo, qualidade
e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização
de funcionalidades que representem maior valor possível para o negócio. Desta
forma, caso seja necessário a diminuição de escopo, as funcionalidades menos
valiosas serão adiadas ou canceladas.
A XP incentiva o controle da qualidade como variável do projeto,
pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é
compensado por perdas (ou até impedimentos) a médio e longo prazo.
 18

5 MÉTRICAS DE PROCESSO E PROJETO DE SOFTWARE

Métrica de Software nada mais é que a maneira de se “medir” e

conhecer todos os horizontes de um software e realizar uma avaliação objetiva
sobre o mesmo. É fundamental para qualquer atividade de engenharia e a de
software não é exceção. Referem-se a um amplo campo de medições de software
de computador. Objetiva a melhorá-lo continuadamente. Pode ser usada ao longo de
um projeto, na estimativa, no controle de qualidade, na avaliação de produtividade e
no controle do projeto. São analisadas por gerentes de software e coletadas por
engenheiros de software.
Um engenheiro de software faz medições para obter indicadores.
Um indicador é uma métrica, uma combinação de métricas, que fornecem
compreensão de um processo de software, de um projeto de software ou do produto
propriamente dito. Indicadores de projeto permitem ao gerente de projeto de
software avaliar o status de um projeto em andamento, acompanhar riscos
potenciais, descobrir áreas problemas antes que elas se tornem críticas, ajustar
fluxo de trabalho e tarefas e avaliar a capacidade da equipe de projeto de controlar a
qualidade dos produtos do trabalho de software.
O único meio racional para aperfeiçoar qualquer processo é medir os
atributos específicos, desenvolver um conjunto de métricas significativas e depois
usar as métricas para fornecer indicadores que levarão a uma estratégia de
aperfeiçoamento. Essas métricas de processos de software podem fornecer
benefícios significativos, à medida que a organização trabalha para aperfeiçoar seu
nível geral de maturidade de processo.
Métricas de processo de software são usadas com finalidade
estratégica. Medidas de projeto de software são táticas, adaptando o fluxo de
trabalho e as atividades técnicas do projeto. À medida que o trabalho técnico se
inicia, outras métricas começam a ter importância. A taxa de produção, representada
por páginas de documentação, horas de revisão, pontos pro função e linhas de
código-fonte são medidas. Os objetivos são duplos: primeiro essas métricas são
usadas para minimizar o cronograma de desenvolvimento, fazendo ajustes
necessários para evitar atrasos, problemas e riscos em potencial; segundo, para
avaliar a qualidade do produto durante sua evolução e, quando necessário, modificar
a abordagem técnica para aperfeiçoara qualidade.
 19

É sugerido que cada projeto deve medir:

• Entradas: medidas dos recursos necessários para fazer o
trabalho;
• Saídas: medidas dos produtos intermediários ou finais criados
durante o processo de engenharia de software;
• Resultados: medidas que indicam a efetividade dos produtos
finais.
As medidas diretas do processo incluem custo e esforço aplicados.
Nesse tipo de medida estão as linhas de código produzidas, velocidade de
execução, tamanho da memória e defeitos relatados durante certo período.
Medidas indiretas incluem funcionalidade, qualidade, complexidade,
eficiência, confiabilidade, manutenibilidade. Métricas por ponto de função são
originadas usando uma relação empírica baseado em medidas de contagem direta
do domínio e avaliação da complexidade do software.
Por conseguinte, métricas resultam em mudança cultural. Coletar
dados, calcular e analisar métricas são três passos que devem ser implementados
para iniciar um programa de métrica. Em geral uma abordagem orientada a metas
ajuda a organização a focalizar as métricas adequadas para o negócio. Criando um
referencial de métricas, obtém uma melhor compreensão do trabalho e do produto
 20

6 CONCLUSÃO

O presente trabalho teve por objetivo mostrar os diferentes Modelos

de Processos utilizados na Engenharia de Software para produzir um sistema que
atenda as necessidades dos clientes, sempre focando a qualidade do produto final.
Essas qualidades são definidas através de suas medições, ou métricas obtidas por
engenheiros de software ao analisar os dados de produção, estimativa de tempo, e
viabilidade do processo.
Não existe um modelo que seja referência e sim modelos que se
encaixam segundo as necessidades dos desenvolvedores de software, segundo o
domínio onde será aplicado. Contudo, as métricas são de extrema importância no
sucesso do produto final independentemente do modelo de processo escolhido, pois
a métrica visa à qualidade do software final.
 21

REFERÊNCIAS

PRESSMAN, Roger S.. Engenharia de Software. 5ª Edição. Rio de Janeiro:

MacGraw-Hill, 2002.

<http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software> acessado
em 05-05-2011