Londrina2011

ODAIR JOSÉ DE ALMEIDA

CENTRO CIÊNCIAS EXATAS E TECNOLÓGICAS

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

SOFTWARE

Londrina2011

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

ODAIR JOSÉ DE ALMEIDA

SUMÁRIO

1 INTRODUÇÃO.....................................................................................................3

2 PAPEL DO SOFTWARE......................................................................................4

3 CARACTERÍSTICAS DA ENGENHARIA DE SOFTWARE.................................6

3.1 ATIVIDADES DA ENGENHARIA DE SOFTWARE...........................................7

4 MODELOS DE PROCESSOS..............................................................................9

4.1 MODELO DE SEQUENCIA OU LINEAR..........................................................9

4.2 MODELO DE PROTOTIPAGEM.....................................................................11

4.3 MODELO RAD................................................................................................11

4.4 OS MODELOS EVOLUCIONÁRIOS...............................................................12

4.4.1 Modelo incremental.....................................................................................12

4.4.2 Modelo espiral.............................................................................................13

4.5 OS MODELOS ÁGEIS....................................................................................14

4.5.1 A abordagem SCRUM.................................................................................15

4.5.2 A Programação Extrema (XP).....................................................................16

5 MÉTRICAS DE PROCESSO E PROJETO DE SOFTWARE.............................18

6 CONCLUSÃO.....................................................................................................20

REFERÊNCIAS.........................................................................................................21

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.

3

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

e é utilizado para controlar produtos e sistemas para o

4

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.

5

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.

6

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

7

especificação de requisitos antes que este seja utilizado como base para o

desenvolvimento do sistema.

8

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

9

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.

10

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:

11

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

12

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

13

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

14

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

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

15

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,

Abraçar mudanças e

Trabalho de qualidade.

16

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.

17

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.

18

É 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

19

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.

20

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

21