Wellington Vasconcelos - Priorização de requisitos

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Instituto Tércio Pacitti de Aplicações e Pesquisas Computacionais - NCE

WELLINGTON GOMES DE VASCONCELOS

PRIORIZAÇÃO DE REQUISITOS VISANDO OBTER RETORNO DE

INVESTIMENTO

Rio de Janeiro

2013

ii

WELLINGTON GOMES DE VASCONCELOS

PRIORIZAÇÃO DE REQUISITOS VISANDO OBTER RETORNO DE

INVESTIMENTO

Monografia apresentada ao Instituto Tércio Pacitti

de Aplicações e Pesquisas Computacionais da

Universidade Federal do Rio de Janeiro, como parte

dos requisitos necessários à conclusão do curso de

especialização em Gerência de Desenvolvimento de

Sistemas Distribuídos com ênfase em Internet

(IS-Expert ).

Orientador: Rodrigo Toledo

Rio de Janeiro

2013

iii

AUTORIZAÇÃO

WELLINGTON GOMES DE VASCONCELOS, autorizo o Instituto Tércio Pacitti de

Aplicações e Pesquisas Computacionais (NCE) da UFRJ a divulgar total ou parcialmente a

presente monografia através de meio eletrônico e em consonância com a orientação geral do

SiBI.

Rio de Janeiro, 27/11/2013.

Assinatura

iv

RESUMO

Este estudo demonstra que a priorização de requisitos que agregam maior valor de

acordo com as necessidades dos usuários pode resultar em maior retorno de investimento.

Porém, muitas vezes, ocorre de um investimento em uma solução que não atende ao que

realmente era esperado. Desta forma, o sistema não possui os processos definidos de acordo

com a necessidade do negócio da organização. Um erro nas fases iniciais do processo de

desenvolvimento de software reflete uma análise de requisitos mal sucedida, na qual resultará

na produção de um software que não atende às expectativas dos stakeholders. O objetivo deste

trabalho é apresentar maneiras para avaliar requisitos, priorizando os que mais impactam, de

forma a atender as principais necessidades dos usuários e visando maior grau de retorno de

investimento. Então, o estudo, se divide os módulos de dois sistemas em dois tipos:

arquiteturais e pequenos conjuntos de funcionalidades que agregam valor. Então, juntamente

com a técnica de priorização Buy a Feature e também de análise de projetos visa responder a

seguinte questão: Como atender as necessidades e expectativas de stakeholders para retorno

de investimento através de priorização de requisitos que possuem maior valor na criação de

um sistema computacional?

Palavras-chave: Priorização de Requisitos, ROI, Retorno de Investimento, Buy a Feature

v

SUMÁRIO

1 INTRODUÇÃO ............................................................................................................................................ 6

1.1 CARACTERIZAÇÃO DO PROBLEMA .............................................................................................. 6 1.2 RELEVÂNCIA ...................................................................................................................................... 8

2 REFERENCIAL TEÓRICO ..................................................................................................................... 11

2.1 REQUISITOS ...................................................................................................................................... 11 2.2 ENGENHARIA DE REQUISITOS ..................................................................................................... 12 2.3 PRIORIZAÇÃO DE REQUISITOS ..................................................................................................... 14 2.4 BUY A FEATURE ............................................................................................................................... 15 2.5 METODOLOGIAS ÁGEIS ................................................................................................................. 16 2.6 TÉCINCAS DE ANÁLISE DE PROJETOS ........................................................................................ 17

3 METODOLOGIA DE PESQUISA ........................................................................................................... 20

3.1 TIPO DE PESQUISA ........................................................................................................................... 20 3.2 SELEÇÃO DOS SUJEITOS ................................................................................................................ 20 3.3 COLETA E ANÁLISE DE DADOS .................................................................................................... 21

4 DESCRIÇÃO DO CASO ........................................................................................................................... 22

4.1 CASO A - GPSPHONE ........................................................................................................................ 22 4.2 CASO B – SISVENDAS ...................................................................................................................... 23

5 ANÁLISE DO CASO ................................................................................................................................. 25

5.1 CASO A – GPSPHONE ....................................................................................................................... 25 5.2 CASO B – SISVENDA ........................................................................................................................ 28 5.3 CASO A X CASO B ............................................................................................................................. 30

6 CONCLUSÃO ............................................................................................................................................. 32

7 REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................................................... 34

8 ANEXOS...................................................................................................................................................... 36

8.1 ANEXO I – ORÇAMENTO DA EMPRESA 1 .................................................................................... 36 8.2 ANEXO II – ORÇAMENTO DA EMPRESA 2 ................................................................................... 38

6

1 INTRODUÇÃO

O objetivo deste trabalho é demonstrar que a priorização de requisitos que agregam

maior valor de acordo com as necessidades dos usuários pode resultar em maior retorno de

investimento. Para o experimento, é apresentado um estudo onde os módulos de dois sistemas

são avaliados, segundo Denne e Cleland-Huang (2004), como arquiteturais (AE) e como

pequenos conjuntos de funcionalidades que agregam valor (MMF), juntamente com a técnica

de priorização Buy a Feature e também de análise de projetos.

Este trabalho apresenta-se subdividido em 6 capítulos:

Inicia-se com o capítulo 2 onde se descreve o referencial teórico utilizado para

entendimento dos pontos principais a serem discutidos e que levaram à motivação da

confecção desse trabalho, tais como: Requisitos de Software, Engenharia de Requisitos,

Priorização de Requisitos, Técnica de Priorização Buy a Feature, Metodologias Ágeis e

Técnicas de Análise de Projetos.

A seguir, no capítulo 3 determina a metodologia de pesquisa a ser adotada, a seleção

de sujeitos e como ocorrera a coleta de dados. Foram utilizados 4 profissionais de Tecnologia

da Informação e 2 empresa cujo suas especialidades é o desenvolvimento de projetos de

software.

No capítulo 4, foi utilizado para detalhar as descrições dos casos onde são

apresentados os dois sistemas (GPSPHONE e SISVENDA) que serviram como base para o

andamento desta pesquisa.

O capítulo 5 especifica a análise dos casos da seguinte forma: Fora pedido para os

sujeitos que avaliassem os sistemas propostos, os profissionais para priorizar os módulos dos

sistemas e as empresa para fazerem um orçamento de quanto custaria cada módulo para ser

confeccionado.

Por fim, o capítulo 6 apresenta uma conclusão sobre a pesquisa mostrando pontos

como a importância de um requisito para um software, a priorização baseada na necessidade

do cliente e demonstra a maneira de observar se um projeto possui uma taxa de retorno de

investimento que atende às expectativas dos stakeholders.

1.1 CARACTERIZAÇÃO DO PROBLEMA

Os softwares são utilizados para apoiar a tomada de decisões e também como

ferramentas que auxiliam na execução de importantes atividades e tarefas nas organizações.

Porém, muitas vezes, ocorre de um investimento em uma solução que não atende ao que

7

realmente era esperado. Desta forma, o sistema não possui os processos definidos de acordo

com a necessidade do negócio da organização. Este trabalho visa responder a seguinte

questão: Como atender as necessidades e expectativas de stakeholders para retorno de

investimento através de priorização de requisitos que possuem maior valor na criação de um

sistema computacional? Para Freitas (2011), um software deve possuir características que

contribuam para a solução de problemas e melhoria da qualidade de trabalho dos usuários,

tendo como consequência a melhoria da qualidade do serviço ou produto da empresa à qual o

software se destina. Portanto, é preciso utilizar uma forma adequada de identificar e priorizar

os requisitos, que constituem o software.

Souza e Santander (2011) afirmam que não raramente negligencia-se o processo de

elicitação, análise, validação e documentação de requisitos. Isto ocorre por inúmeros motivos

tais como falta de um processo de engenharia de requisitos bem definido, falta de

comprometimento ou valorização dos envolvidos em relação à etapa de engenharia de

requisitos, uso de técnicas e estratégias inadequadas ao contexto organizacional que norteia os

trabalhos de engenheiros e clientes, pressão do cliente para entrega rápida de uma versão do

sistema, entre outros aspectos. O que se obtém como consequência é uso de práticas que

levam ao desenvolvimento de sistemas computacionais que não atendem em sua plenitude aos

anseios dos seus clientes e usuários.

Entretanto Withall (2007) diz que os requisitos definem o problema que terá de ser

solucionado: para que o sistema é e o que ele precisa resolver. Eles não definem a solução.

Um requisito é único, um objetivo mensurável que o sistema deve solucionar. Uma

especificação de sistema é um documento informando todas as suas exigências e acrescenta o

material de apoio necessário para torná-lo legível e compreensível. Ele tem de definir todas as

funcionalidades e outras características que o sistema deverá possuir.

Para Duan et al. (2009), alguns requisitos possuem maior impacto na satisfação dos

usuários em relação ao software. Ramires (2011) define que nas fases iniciais do processo de

desenvolvimento de software, os intervenientes do processo contribuem com ideias vagas e

incompletas relativamente aos seus objetivos. É frequente não haver uma ideia clara de quais

são os requisitos desejáveis. Deste modo é difícil definir requisitos a fim de se obter um

sistema que corresponda às expectativas.

Em complemento faz-se necessário utilizar um método para padronizar a escrita dos

requisitos de software para auxiliar na comunicação interna, facilitando o reuso do

conhecimento adquirido baseado em experiências reais e que se mostra eficiente na solução

8

de problemas acidentais ou inesperados. Segundo Silva e Benitti (2011), a utilização de

padrões na área de requisitos é considerada uma solução que “agiliza” o processo de

elicitação de requisitos de software e também pode aumentar a qualidade dos documentos

gerados e, também, que padrões de requisitos têm o objetivo de estabelecer requisitos com

uma maior qualidade de escrita, isso com maior agilidade e menor esforço.

Um erro nas fases iniciais do processo de desenvolvimento de software reflete uma

análise de requisitos mal sucedida, na qual resultará na produção de um software que não

atende às expectativas dos stakeholders. O objetivo deste trabalho é apresentar maneiras para

avaliar requisitos, priorizando os que mais impactam, de forma a atender as principais

necessidades dos usuários e visando maior grau de retorno de investimento.

1.2 RELEVÂNCIA

Freitas (2011) afirma que, a elicitação de requisitos é uma das atividades que ocorre

no início do desenvolvimento de software. Erros gerados nesta atividade, se não são

corrigidos, se estendem até o final do desenvolvimento e após a verificação de cada erro,

todas as fases anteriores precisam ser refeitas.

Nuseibeh e Easterbrook (2000) entendem que a maneira como os requisitos são

levantados e gerenciados influencia diretamente no sucesso de um projeto de software e

determina a qualidade dos sistemas entregues ao cliente.

Para Cohn (2006), a terceira razão pela qual o planejamento tradicional para

desenvolvimento de software não é conduzida de forma consistente para um produto de alto-

valor é porque a descrição do plano de trabalho não é priorizada de acordo com o valor para

seus usuário e clientes. Muitos planos tradicionais pressupõem que todas as atividades

identificadas serão concluídas. Isto significa que o trabalho é normalmente priorizado e

sequenciado pela equipe de desenvolvimento. Para o autor, o planejamento deve atender as

necessidades de alto-valor que são sequenciadas e priorizadas pelo cliente, sendo definidas na

atividade de análise de requisitos.

Ramires (2004) aponta que a definição de prioridades ajuda os stakeholders a definir

as bases do sistema e a focalizar a atenção nas reuniões, especialmente se estiver associada a

uma análise de risco. A identificação explícita de requisitos prioritários ajuda igualmente os

stakeholders responsáveis pelo desenvolvimento do sistema a decidir sobre a arquitetura e a

resolver os conflitos que surjam.

9

De acordo com Karlsson e Ryan (1996) um dos maiores riscos enfrentados por

organizações que desenvolvem software está associado ao não atendimento das necessidades

e expectativas dos usuários.

Souza e Santander (2011) entendem que o ponto inicial para reduzir os problemas de

elicitação de requisitos passa pela necessidade de utilizar estratégias que permitam levantar e

analisar requisitos da forma mais efetiva possível considerando particularmente o

usuário/cliente como maior detentor do conhecimento necessário a especificação e descrição

de uma necessidade apontada pelo mesmo. Contudo, sabe-se que elicitar informações sobre

necessidades de usuários em relação a sistemas computacionais não é um processo trivial,

pois, geralmente, o usuário possui uma visão simplificada da situação, na qual, na maioria das

vezes não se tem claro os resultados esperados. Uma possível solução que diminui

consideravelmente os problemas neste processo de elicitação e análise é fazer com que o

usuário/cliente seja considerado como protagonista do processo e o trabalho do engenheiro de

requisitos seja orientado sob esta perspectiva. Quando se descreve algum requisito, seja ele

funcional ou não, o envolvido na escrita assume um compromisso maior com o processo e as

avaliações do que se está escrevendo, o que ocorre quase que instintivamente.

Cordeiro (2011) consideram que são as necessidades dos usuários que justificam o

investimento em um projeto de software, não faz sentido que o foco principal do projeto seja

outro senão a solução para essas demandas. Embora essa seja uma afirmativa lógica, a

realidade mostra que são muito comuns os objetivos de um projeto de software se distanciar

das necessidades de seus usuários. Por esta razão, as fases de elicitação e análise de requisitos

podem ser compreendidas como base para todas as outras atividades relativas ao

desenvolvimento de software.

Os requisitos são definidos durante as fases iniciais no processo de desenvolvimento

de software e são considerados descrições comportamentais ou atributos de um sistema.

Então, a partir deles são geradas especificações a serem implementadas para atender às

necessidades dos stakeholders.

Souza e Santander(2011) também apontam que efetuar uma abordagem de análise de

problema e elicitação de requisitos voltada ao stakeholder mais importante do processo, o

cliente. Sob esta perspectiva é a partir das necessidades do cliente que surge um projeto de

software. Vários trabalhos realizados na área de engenharia de requisitos apresentam modelos

de elicitação nos quais o cliente é ou deve estar comprometido com uma visão de T.I. mais

aprofundada.

10

De acordo com Hermsdorf, V. O. et al. (2011) um erro proveniente da especificação

de requisitos detectado em uma fase avançada do desenvolvimento irá exigir retrabalho, com

possibilidade de introdução de novos erros.

Com isso, percebemos que é necessário que os stakeholders usuário ou não participem

ativamente como protagonista nos processos da Engenharia de Requisitos, principalmente nas

atividades de elicitação e análise. Por sua vez, o Analista de requisitos tem de identificar,

juntamente com as partes interessadas, quais são seus requisitos prioritários, possibilitando à

equipe de desenvolvimento a criação de um produto de alto-valor que terá ótima aceitação

pelos usuários finais satisfazendo às suas necessidades.

11

2 REFERENCIAL TEÓRICO

2.1 REQUISITOS

Requisitos são configurados como as necessidades que as partes interessadas levantam

como valorosas para seu contexto e que serão implementados em um software como

funcionalidades, atributos ou alguma outra característica que ele deva contemplar. Com os

requisitos bem especificados fornece a visão de que o sistema é e sobre o que ele tem de fazer.

Young (2004) afirma que requisitos são atributos necessários em um sistema para que

ele tenha valor e utilidade para os clientes e usuários. Então, Robertson (2006) explica que os

requisitos são como algo que o produto deve fazer ou uma característica que o produto deve

ter, e que é necessário ou desejado pelos stakeholders.

Ramires (2011) entende que os requisitos são a definição de pontos de vista dos

stakeholders sobre o sistema. Estes pontos de vista entram no processo de desenvolvimento

de software e originam um conjunto de soluções.

Withall (2007) afirma que os requisitos definem o problema que terá de ser

solucionado: para que o sistema é e o que ele precisa resolver. Eles não definem a solução.

Um requisito é único, um objetivo mensurável que o sistema deve solucionar. Uma

especificação de sistema é um documento informando todas as suas exigências e acrescenta o

material de apoio necessário para torná-lo legível e compreensível. Ele tem de definir todas as

funcionalidades e outras características que o sistema deverá possuir.

Os requisitos podem ser de dois tipos:

Requisitos funcionais: Uma parte importante que diz o sistema tem de fazer, as

atividades que o sistema está habilitado a executar.

Requisitos não funcionais: representam um grande contexto de desempenho,

segurança, capacidade nos quais o sistema deve contemplar.

Então Withall (2010) define alguns princípios genéricos para aplicar em qualquer

ocasião de especificação de requisitos:

1. Especifica o problema, não a solução: os requisitos definem “o que, mas não

como”, não têm o papel de tentar especificar a solução ou parte dela. Essa é uma distinção

importante para não ser quebrada;

2. Especifica o problema, não o projeto: Requisitos definem o que o sistema deve

fazer: Eles são os objetivos. Um projeto é a mobilização de uma equipe em uma duração

temporária para alcançar seus objetivos.

12

3. Separa as partes formais e informais: Uma especificação de requisitos é como

um contrato que define o que os construtores e fornecedores devem entregar. Os requisitos se

constituem na parte formal da especificação: o que oficialmente o sistema deve fazer. Outras

coisas são informais.

4. Evitar repetições: Expressar cada unicamente cada item. Repetições criam

trabalhos extras e abrem oportunidades de inconsistências.

Segundo Magalhães (2006), para que um software seja considerado de qualidade é

preciso que esteja em conformidade com os seus requisitos, atenda as expectativas do cliente

e seja bem aceito por seus usuários.

2.2 ENGENHARIA DE REQUISITOS

Souza e Santander (2011) afirmam que a engenharia de requisitos tem um papel

fundamental no processo de desenvolvimento de software. Particular atenção deve ser

dedicada ao processo e técnicas utilizados para gerar especificações de requisitos não

ambíguas, consistentes e completas.

Para Cordeiro (2011) o processo é constituído por várias etapas e ações que devem ser

realizadas com o objetivo de obter um produto de software.

Withall (2010) define um par de princípios para orientar todo o processo de requisitos

ágil:

1. Distinguir problema da solução: Este princípio diz que é boa prática para

reconhecer o que fazer e como fazer separadamente e o que será priorizado. Descriminando o

que poderá ser avaliado qualitativamente e o comparar os méritos das soluções sugeridas.

2. Se encontrar um requisito, grave-o e de tal forma que alguém possa encontrá-

lo: Este princípio diz onde e em qual forma os requisitos serão guardados.

Então Sommerville e Sawyer (1997) apontam alguns problemas ao processo de

engenharia de requisitos:

Normalmente ultrapassa o orçamento ou tempo planeado;

As pessoas envolvidas não têm tempo/reursos suficientes para realizar as

tarefas requeridas;

Existem queixas acerca do entendimento/conclusões do documento produzido;

Os stakeholders que desenvolvem o sistema queixam-se de trabalho inútil

devido a erros nos requisitos;

13

Os stakeholders que utilizam o sistema falham em usar todas as capacidades do

sistema;

Ocorre um grande volume de pedidos de alteração logo após a entrega do

sistema aos stakeholders;

De acordo com Cordeiro (2011), um software deve possuir características que

contribuam para a solução de problemas e a melhoria da qualidade de trabalho dos usuários,

tendo como consequência a melhoria da qualidade do serviço ou do produto da empresa.

Portanto, é preciso utilizar uma maneira adequada para identificar (elicitar) e priorizar tais

aspectos, que constituem os requisitos.

Souza e Santander (2011) explicam que, considerando as boas práticas da engenharia

de requisitos, existe uma suposta agilidade no envio de e-mail ou realização de telefonema, no

qual isenta o próprio usuário do desconforto de uma análise mais aprofundada sobre o

problema. Esta falsa agilidade pode ser percebida pelas inúmeras falhas, inconsistências e

esforço extra nas empresas de desenvolvimento de software que adotam a mesma prática. E

que é necessário fazer com que o cliente realize uma descrição mais aprofundada do problema

que quer solucionar, incentivando o mesmo a envolver sua equipe no projeto podendo

mensurar com mais precisão a complexidade do trabalho a ser desenvolvido e

consequentemente entender e valorizar o trabalho de engenharia necessário para elaborar uma

solução computacional para esse problema. Com a grande possibilidade do envolvimento do

cliente no processo há dados iniciais concisos e com qualidade, os quais possibilitam reduzir

os contatos posteriores com usuários e clientes, permitindo desta forma, focar os esforços no

desenvolvimento do projeto nas fases posteriores. Para os autores, na maioria das vezes o

responsável por encaminha a solicitação de um novo projeto pode não deter todas as

informações necessárias para um novo projeto. Sendo assim, sugerem que o contato seja

induzido com perguntas objetivas direcionadas aos usuários chaves, fazendo com que a

equipe se envolva com o processo melhorando a Engenharia de Requisitos.

Em complemento Cordeiro (2011) afirma que a elicitação de requisitos tem sido

reconhecida como uma das etapas determinantes para a qualidade de software. Para Larman

(2004), requisitos são capacidades e condições às quais o sistema – e de forma mais ampla, o

projeto – deve atender. Definem também que uma elicitação ineficaz traz consequências que

podem levar ao fracasso do projeto. Isso pode ser explicado pelo fato de tal etapa constituir a

base para as atividades subsequentes. Se a base é mal construída, as falhas decorrentes daí

podem continuar acontecendo e até mesmo se tornar mais complexas posteriormente.

14

Segundo Karlsson, Wohlin e Regnell (1998), os requisitos devem ser alocados em

diferentes versões do software e, para Berander (2004), a seleção “correta” dos requisitos que

farão parte de cada versão é a etapa principal em direção ao sucesso de um projeto ou

produto.

No entendimento de Ramires (2011), um requisito que pode ser aceito por um

stakeholder pode não ser aceito por outro. O processo de decisão na negociação envolve

procurar uma única alternativa (ponto de intersecção) dentro de um conjunto de opções

aceitáveis pelos participantes e tecnologicamente possíveis.

Para Cordeiro (2011) as técnicas de elicitação visam à identificação dos requisitos. No

entanto, devido a restrições de tempo e orçamento, pode ser difícil atender a todos os

requisitos identificados para um sistema. Os requisitos geralmente são desenvolvidos em

etapas e a priorização ajuda a definir quais devem ser implementados primeiro.

Pressman (2002) cita a necessidade de conformidade aos requisitos funcionais, aos

padrões de desenvolvimento claramente documentados e às características implícitas

esperadas de todo software profissionalmente desenvolvido. A ausência de conformidade com

os requisitos é falta de qualidade.

Logo, Ambrózio (2008) afirma que empregar a rastreabilidade de requisitos possibilita

um gerenciamento das correções e das alterações de requisitos, permitindo verificar os seus

efeitos sobre o orçamento do projeto. A rastreabilidade de um requisito consiste em identificar

e manter os artefatos que o originam, como os planos de negócios, e os artefatos originados a

partir de cada requisito, como os artefatos de desenho, de implementação e de testes.

2.3 PRIORIZAÇÃO DE REQUISITOS

Segundo Ramires (2011) estudos recentes comprovam que dos projetos de software

concluídos, apenas uma pequena parte corresponde às expectativas, tendo-se observado que o

problema se centra principalmente numa deficiente análise de requisitos. Então, Souza e

Santander informam que a engenharia de requisitos tem um papel fundamental no processo de

desenvolvimento de software. Particular atenção deve ser dedicada ao processo e técnicas

utilizados para gerar especificações de requisitos não ambíguas, consistentes e completas.

Para Cordeiro (2011) acredita-se que os requisitos priorizados podem servir como

referência para as etapas que constituem o processo de desenvolvimento de software.

A seguir serão listados alguns métodos são destacados para a priorização de requisitos:

15

Atribuição Numérica: Através de uma escala de valores inteiros de 1 a 5, deve

ser identificado pelos stakeholders, em qual nível cada requisito corresponde;

Métodos dos 100 pontos: Distribui-se 100 pontos para os requisitos e aos mais

importantes atribuem-se os maiores;

Triagem de Requisitos: Define a prioridade dos requisitos, define recursos e

aperfeiçoa a probabilidade de sucesso do projeto através de subconjuntos de requisitos;

Método AHP (Analytic Hierarch Process): Utiliza-se em casos que múltiplos

objetivos estão presentes. Usa-se a comparação por pares para calcular a importância de cada

requisito.

Buy a Feature: Prática de priorização de histórias ou funcionalidades e consiste

em “comprar” as histórias mais importantes de um determinado produto.

Como descrito, é possível utilizar métodos para identificar os requisitos prioritários

para que seja possível atender às necessidades e expectativas dos stakeholders.

2.4 BUY A FEATURE

A técnica tem como objetivo priorizar requisitos através de uma relação de features.

Para essa lista é necessário os clientes atribua valores a cada uma delas, podendo utilizar

preços fictícios ou o real valor do custo de desenvolvimento.

Torna-se necessário para esse jogo uma reunião com vários clientes com a intenção de

motivá-los a comprar o produto, descobrir quais recursos irão satisfazê-los. Para isso, abre-se

uma negociação entre os clientes, pois, o jogo consiste em distribuir entre os eles valores que,

certamente, não será suficiente para a compra de todas as features. Assim, com a junção de

dois clientes, por exemplo, eles conseguirão comprar as desejadas e não terão como adquirir

outras. Como resultado, terá a priorização do que realmente terá valor para eles.

Sendo assim, os clientes compram as features que necessitam para próxima versão,

usando dinheiro do jogo que ele recebe. Alguns requisitos receberão um preço maior do que

um cliente possa comprá-lo, dando o incentivo para os clientes juntarem seus valores para

adquirir características mais importantes.

Escolher os requisitos corretos pode ser a diferença entre o fracasso em curto prazo ou

o sucesso em longo prazo. Esta escolha é feita, muitas vezes, pelo gerente sem envolver os

clientes interessados. Com esta técnica, os clientes ajudam a definir a solução que mais lhes

agregam valores, melhorando qualidade do produto e a satisfação do usuário.

16

2.5 METODOLOGIAS ÁGEIS

O desenvolvimento de software ágil é fundamentado nos princípios declarado no

Manifesto Ágil que foi criado pela Aliança Ágil. Segundo Cohn (2006), este manifesto foi

escrito e assinado por dezessete “lightweight methodologists", como eram chamados na

época. Em seu documento deram um nome à forma como eles estavam desenvolvendo

software e forneceram uma lista de declarações. Com isso, foram definidos quatro valores

principais:

Os indivíduos e suas interações acima de procedimentos e ferramentas;

O funcionamento do software acima de documentação abrangente;

A colaboração dos clientes acima da negociação de contratos;

A capacidade de resposta às mudanças acima de um plano pré-estabelecido

Libardi e Barbosa (2010) explicam que o Manifesto Ágil não rejeita os processos e

ferramentas, a documentação, a negociação de contratos ou o planejamento, mas

simplesmente mostra que eles têm importância secundária quando comparado com os

indivíduos e interações, com o software funcionando, com a colaboração com o cliente e as

respostas rápidas a mudanças e alterações.

Os princípios do desenvolvimento ágil estão divididos em 12 princípios:

Garantir a satisfação do consumidor entregando rapidamente e continuamente

softwares funcionais;

Softwares funcionais são entregues frequentemente (semanas, ao invés de

meses);

Softwares funcionais são a principal medida de progresso do projeto;

Até mesmo mudanças tardias de escopo no projeto são bem-vindas.

Cooperação constante entre pessoas que entendem do 'negócio' e

desenvolvedores;

Projetos surgem através de indivíduos motivados, e que deve existir uma

relação de confiança.

Design do software deve prezar pela excelência técnica;

Simplicidade;

Rápida adaptação às mudanças;

Indivíduos e interações mais do que processos e ferramentas;

Software funcional mais do que documentação extensa;

17

Colaboração com clientes mais do que negociação de contratos;

Responder a mudanças mais do que seguir um plano.

Para Libardi e Barbosa (2010) uma característica das metodologias ágeis é que elas

são adaptativas ao invés de serem preditivas. Dessa forma, elas se adaptam a novos fatores

durante o desenvolvimento do projeto, ao invés de tentar analisar previamente tudo o que

pode ou não acontecer no decorrer do desenvolvimento. Os autores também explicam que os

métodos ágeis utilizados para desenvolvimento de software é um diferencial que promete

aumentar a satisfação do cliente agregando maior valor ao produto final, produzindo software

alta qualidade e acelerando os prazos de desenvolvimento de projetos.

De acordo com Cohn (2006) as equipes ágeis valorizam mais o software funcionando

do que a documentação abrangente, obtendo uma versão estável, progressivamente

aumentando o produto no final de cada interação. Isto faz com que seja possível desde o

início, o feedback frequente sobre o produto e o processo. Como o software desenvolvido

cresce a cada interação, pode ser exibido para os usuários prováveis ou reais. Os comentários

destes usuários são utilizados no processo de desenvolvimento para certificar de que a equipe

está sempre trabalhando com os recursos mais bem valorizados e que esses recursos irão

satisfazer as expectativas dos usuários.

Então os processos ágeis definem adições incrementais para o software que será

envolvido por expansões graduais de um conjunto de requisitos. A especificação de requisitos

é suficiente para mostrar para o cliente que o que ele espera para o software foi entendido e

obter sua aprovação. Então, ao iniciar o desenvolvimento, especificam-se os requisitos

detalhadamente para o que é preciso.

2.6 TÉCINCAS DE ANÁLISE DE PROJETOS

Segundo Bordeuax-Rêgo (2010), o método mais utilizado para a analise de

investimento é o fluxo de caixa descontado. Ele depende da projeção dos fluxos da estimativa

de valor residual e da determinação da taxa de desconto. Diz também que, a projeção do fluxo

de caixa do projeto é a etapa fundamental do orçamento de capital. Normalmente, se

subdivide em investimento inicial e fase de operação do projeto que gera os fluxos de caixa

líquidos anuais.

Para isso é necessário conhecer os indicadores Financeiros:

18

Janela de oportunidades: Tempo decorrido entre o início do projeto e o

momento em que o produto final do projeto tem que ser substituído por um outro mais

adequado as necessidades do mercado.

Necessidade Total de Capital: Total de recursos financeiros necessários para

executar um projeto.

Período de Investimento: Tempo decorrido entre o início do projeto e instante

de tempo em que o projeto não requer novas injeções de capital.

Período de Recuperação: Tempo necessário para recuperar o capital investido.

Período Lucrativo: Instante de tempo a partir do qual o total das receitas supera

o total das despesas.

Taxa Mínima de Atratividade - TMA: Entende-se como Taxa de Mínima

Atratividade a melhor taxa, com baixo grau de risco, disponível para aplicação do capital em

análise. Existem várias taxas que podem ser usada para estimar a TMA e as que mais

impactam são:

o Taxa Básica Financeira (TBF);

o Taxa Referencial (TR);

o Taxa de Juros de Longo Prazo (TJLP);

o Taxa do Sistema Especial de Liquidação e Custódia (SELlC).

Valor Presente Liquido: O valor presente de recebimentos e pagamentos

futuros descontados a uma TMA, menos o custo do investimento inicial. O VPL é uma função

decrescente da TMA, significando que quanto maior for (TMA) menor será o VPL e, por

consequência, mais difícil à viabilização de projetos, isto é, encontrar projetos com VPL > 0.

Entende-se também que o valor da taxa a ser utilizada em um processo de descapitalização do

fluxo de caixa deve ser a TMA da empresa.

Retorno sobre investimento: É a relação entre o dinheiro ganho ou perdido

através de um investimento, e o montante de dinheiro investido.

Taxa interna de retorno: Taxa de juros necessários para igualar o valor de um

investimento (valor presente) com os seus respectivos retornos futuros.

Invest

VPL

Invest

LucroROI

n

n

TMA

VF

TMA

VF

TMA

VF

TMA

VFVPL

)1()1()1()1( 3

3

2

2

1

1

.%)11(

1201

InvestVPL

0)1()1()1( 2

2

1

1

n

n

i

VF

i

VF

i

VFVPLi

19

Então Bordeuax-Rêgo(2010) afirma que o método do valor presente liquido (VPL) faz

uma comparação do investimento realizado com o valor presente de fluxo de caixa gerados

pelo projeto. Se observarmos bem, vemos que o método do payback descontado faz, período a

período, a atualização do saldo (investimento – valor presente do fluxo). Ao chegar ao final, o

saldo acumulado do payback descontado é, portanto, o próprio Valor Presente Líquido do

projeto. Os autores ainda afirmam que, VPL leva em conta todos os fluxos de caixa, e não

apenas o instante de tempo em que o saldo acumulado se torna positivo. Assim pode nos dar

uma medida de riqueza adicionada (VPL maior que zero) ou destruída (VPL menor que zero).

Em conclusão, quando o VPL é maior do que zero, o projeto pode ser aceito. Quando

VPL é igual à zero, é indiferente, podendo ser aceito ou não. Logo, se o VPL é menor que

zero, o projeto será rejeitado.

20

3 METODOLOGIA DE PESQUISA

3.1 TIPO DE PESQUISA

Em estudo sobre técnicas de priorização de requisitos, percebe-se que são abordadas,

principalmente, técnicas que trabalham com identificação das necessidades com maior valor

para os stakeholders no processo de desenvolvimento de software, porém, muitos poucos

falam de técnicas para redução de custo. Tendo em vista que a pesquisa exploratória tem

como preocupação central proporcionar maior familiaridade com o problema tornando-o mais

explícito ou construindo hipótese a cerca do tema, este trabalho se baseará no neste tipo de

pesquisa. Seu desenvolvimento terá como base material já elaborado constituído

principalmente de livros e artigos científicos.

3.2 SELEÇÃO DOS SUJEITOS

A seleção dos sujeitos foi feita no Centro de Computação da Aeronáutica e

profissional da iniciativa privada, mais precisamente do setor de desenvolvimento de

software. Então, eles são apresentados abaixo:

Entrevistado 1: Washington Gomes de Vasconcelos, Especialista em

Engenharia de Software pela Universidade Federal de Minas que trabalha como Analista de

Sistemas Sênior na empresa ENGESOFT de Belo Horizonte;

Entrevistado 2: Alberto Carlos El Kaid Santos, Bacharel em Ciência da

Computação e exerce a função de Chefe da Sub Seção de Testes do Centro de Computação da

Aeronáutica do Rio de Janeiro;

Entrevistado 3: Hudson Ummen Veloso, Bacharel em Engenharia da

Computação e exerce a função de Chefe da Sub Seção de Analise do Centro de Computação

da Aeronáutica do Rio de Janeiro como Analista de Sistemas;

Entrevistado 4: Rodrigo Santos Borges, Especialista em Gerência de Projetos

pela FGV-RJ e exerce a função de Chefe da Seção de Gerenciamento de Projetos do Centro

de Computação da Aeronáutica do Rio de Janeiro como Gerente de Projetos;

Também, para o estudo foi necessário coletar dados com empresas especializadas em

desenvolvimento de software como as seguintes:

Empresa 1: WTD3 Informática LTDA;

Empresa 2: MindTek – Informática & tecnologia.

21

3.3 COLETA E ANÁLISE DE DADOS

A coleta de dados será feita a partir de envio de planilhas, pelos sujeitos, onde serão

relacionados seis módulos para dois sistemas. Também serão utilizados os orçamentos das

empresas entrevistadas como base para a pesquisa de mercado. Os dados serão interpretados e

auxiliarão na identificação de técnicas para serem utilizadas na priorização de requisitos para

redução de custos e calculo de retorno de investimento.

22

4 DESCRIÇÃO DO CASO

O trabalho consiste em aplicar a técnica de Buy a Feature para a priorização de

requisitos e utilizar técnicas de análise de projetos, como VPL (Valor Presente Liquido), para

obter uma estimativa de retorno de investimento para confecção de software.

Como objeto de estudo foi definido dois sistemas diferentes e seus módulos foram

priorizados por um Analista de Sistema, um Cientista da Computação, um Gerente de Projetos

e um Engenheiro da Computação.

Os módulos são divididos em 2 tipos, segundo Denne e Cleland-Huang (2004) :

Elementos Arquiteturais (AE): Permitem que a arquitetura seja entregue de

acordo com a demanda, reduzindo ainda mais o investimento inicial necessário para se

executar um projeto.

Minimum Marketable Feature (MMF): De acordo com Denne e Cleland-

Huang (2004), são módulos com pequenos conjuntos de funcionalidades que podem ser

entregues de forma rápida e que criam valor para o negócio.

Para o estudo foram definidos dois sistemas:

GPSPHONE: Software para ser utilizado como navegador GPS em celulares

com a funcionalidade de localizar amigos e serviços de assinaturas para acesso ao sistema.

SISVENDAS: Sistema utilizado para auxilio na gerencia e tomada de decisões

de uma empresa com fins de estocar e vender produtos. Com isso o sistema faz controle de

estoque, gastos, vendas e produtos.

A coleta dos dados para a pesquisa foram enviadas, para os entrevistados, as duas

tabelas 1 e 2, citadas nos itens 4.1 e 4.2 respectivamente, referentes aos requisitos dos

sistemas em questão. Então, baseado na técnica Buy a Feature, foram disponibilizadas para

eles 100 moedas fictícias para cada sistema, nas quais, teriam de indicar quanto pagariam por

cada módulo baseando em funcionalidades que agregariam valor para seu negócio.

4.1 CASO A - GPSPHONE

Definiu-se que o software será produzido modularmente e cada entrega seria

disponibilizada em uma unidade de tempo. A tabela abaixo descreve a divisão dos módulos

necessários a serem produzidos para o sistema:

Id Tipo Nome e Descrição

Mod1 AE Serviço de Assinatura - permite que os clientes se inscrevam e/ou cancelam

a assinatura do serviço.

23

Mod2 AE Análise de Crédito – Utilizado no Pagamento de assinaturas.

Mod3 MMF Onde estou? - Permite aos clientes saibam a sua localização geográfica em

todos os momentos.

Mod4 MMF Navegador - permite aos clientes escolher e seguir a melhor rota entre dois

pontos.

Mod5 AE Grupo de Amigos - permite aos clientes criar um grupo, solicitar a adesão de

grupos existentes e cancelar uma filiação existente.

Mod6 MMF Onde estão meus amigos? - Revela o paradeiro de pessoas que pertencem ao

mesmo grupo de familiariza. Tabela 1: Definição dos módulos do sistema GPSPHONE

Os módulos estão dispostos na seguinte sequencia e relação de dependência:

Figura 1: Sequência de módulos do Sistema GPSPHONE

Abaixo as indicações de valores por entrevistado:

Id Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4

Mod1 30,00 5,00 20,00 20,00

Mod2 20,00 5,00 15,00 15,00

Mod3 15,00 30,00 15,00 20,00

Mod4 15,00 40,00 30,00 20,00

Mod5 15,00 10,00 10,00 15,00

Mod6 5,00 10,00 10,00 10,00

Tabela 2: Priorização de acordo com os entrevistados - GPSPHONE

4.2 CASO B – SISVENDAS

A tabela abaixo descreve a divisão dos módulos necessários a serem implementados

para o sistema:

Id Tipo Nome e Descrição

Mod1 AE Cadastro de Produtos- Registrar produtos a serem vendidos

Mod2 MMF Gerência de Estoque - Controle de Estoque de produtos disponibilizados

24

Mod3 AE Cadastro de Clientes - Registrar Clientes que efetuam compras na loja

Mod4 MMF Gerenciar Vendas - Controlar as vendas efetuadas na loja

Mod5 MMF Registro de gastos - Registro de gastos efetuados pela Loja

Mod6 MMF Fluxo de caixa - Permite ao Gerente calcular o fluxo de caixa da loja

Tabela 3: Definição dos módulos do sistema SISVENDAS

Os módulos estão dispostos na seguinte sequencia e relação de dependência:

Figura 2: Sequência de módulos do Sistema SISVENDA

Abaixo as indicações de valores por entrevistado:

Id Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4

Mod1 17,00 10,00 20,00 20,00

Mod2 16,00 20,00 20,00 25,00

Mod3 17,00 10,00 5,00 10,00

Mod4 25,00 20,00 30,00 10,00

Mod5 15,00 22,00 10,00 15,00

Mod6 10,00 18,00 15,00 20,00

Tabela 4: Priorização de acordo com os entrevistados – SISVENDA

25

5 ANÁLISE DO CASO

De acordo com a técnica de Buy a Feature, foi necessário que os entrevistados

entrassem em um consenso, pois foram utilizadas 300 moedas por sistema, mas teriam apenas

100, para cada um, para a resolução do problema. Conclui-se então que para os clientes os

módulos dos sistemas mais prioritários foram os que eles depositaram os valores maiores.

5.1 CASO A – GPSPHONE

A técnica de Buy a Feature prevê que uma reunião deveria ser feita para chegar a um

consenso sobre qual o valor de cada módulo. Para este trabalho, a tabela abaixo foi gerada

calculando a média dos valores discriminados pelos entrevistados, na qual, não interfere nos

resultados:

Id Valor

Mod1 18,75

Mod2 13,75

Mod3 20,00

Mod4 26,25

Mod5 12,50

Mod6 8,75

Tabela 5: Resultado da média dos valores dos entrevistados – GPSPHONE

O período para as entregas de cada módulo do sistema ficou definido de acordo com a

tabela que segue:

Sequência Período de Desenvolvimento

1 2 3 4 5 6 7 8 9 10

S1

Mod 1

Mod 2

Mod 3

Mod 4 Mod 5

Mod 6

Tabela 6: Período de desenvolvimento do sistema GPSPHONE

Tendo isto, foi pedido para as empresas que fizessem uma avaliação e um orçamento

para cada módulo do sistema específico.

Abaixo as suas respostas:

Empresa 1:

Módulos Valor

26

Mod 1 R$ 6.834,00

Mod 2 R$ 5011,88

Mod 3 R$ 7.290,00

Mod 4 R$ 9.568,13

Mod 5 R$ 4.556,25

Mod 6 R$ 3.189,38

Total R$ 36.450,00

Tabela 7: Orçamento apresentado pela empresa 1.

Então, utiliza-se a tabela criada pelos stakeholders com a priorização dos módulos

para gerar o fluxo caixa para o período de desenvolvimento. Como discriminado abaixo:

Módulo Tipo

Fluxo de Caixa

1 2 3 4 5 6 7 8 9 10

Mod3 MMF -19.136,25 52,50 52,50 52,50 52,50 52,50 52,50 52,50 52,50 52,50

Mod4 MMF

-9.568,13 26,25 26,25 26,25 26,25 26,25 26,25 26,25 26,25

Mod6 MMF

-7.745,63 21,25 21,25 21,25 21,25 21,25 21,25 21,25

Tabela 8: Fluxo de Caixa para o sistema GPSPHONE de acordo com a empresa 1.

Utilizando os indicadores já especificados na seção 2.6 deste trabalho e, também, os

dados já descriminados pela empresa contratante, podem-se chegar aos seguintes valores que

dizem respeito do projeto:

1. Janela de Oportunidades: 10 períodos;

2. Necessidade de Capital: R$ 36.450,00;

3. Período de Investimento: Períodos de 1 ao 3;

4. Taxa de reajuste: 2,0;

5. Valor Presente Liquido para o Investimento = R$ 20.658,74

6. Valor Presente Liquido para o custo = R$ 734,54

7. Retorno de Investimento (ROI): 0,035 moeda/real;

Empresa 2:

Módulos Valor

Mod 1 R$ 8.000,00

Mod 2 R$ 5.000,00

27

Mod 3 R$ 10.000,00

Mod 4 R$ 10.000,00

Mod 5 R$ 7.000,00

Mod 6 R$ 7.000,00

Total R$ 47.000,00

Tabela 9: Orçamento apresentado pela empresa 2

Então, utiliza-se a tabela criada pelos stakeholders com a priorização dos módulos

para gerar o fluxo caixa para o período de desenvolvimento. Como discriminado abaixo:

Módulo Tipo

Fluxo de Caixa

1 2 3 4 5 6 7 8 9 10

Mod3 MMF -23.000,00 52,50 52,50 52,50 52,50 52,50 52,50 52,50 52,50 52,50

Mod4 MMF

-10.000,00 26,25 26,25 26,25 26,25 26,25 26,25 26,25 26,25

Mod6 MMF

-14.000,00 21,25 21,25 21,25 21,25 21,25 21,25 21,25

Tabela 10: Fluxo de Caixa para o sistema GPSPHONE de acordo com a empresa 2.


dados já descriminados pela empresa contratante, podem se chegar aos seguintes valores que

dizem respeito do projeto:


2. Necessidade de Capital: R$47.000,00;






Após a reunião de negociação dos stakeholders, gera-se o um fluxo de caixa com base

nos dados especificados pela equipe de pesquisa das empresas contratantes e, utilizando os

indicadores financeiros já especificados na seção 2.6 deste trabalho, define-se se um projeto é

viável e sua taxa de retorno de investimento (ROI).

Com isso, de acordo com o orçamento de cada empresa contatada e baseando na

analise feita pelos entrevistados, o projeto a ser executado pela primeira empresa é mais

vantajoso do que o orçado pela outra empresa, pois sua taxa de ROI é maior.

28

5.2 CASO B – SISVENDA

A técnica de Buy a Feature prevê que uma reunião deveria ser feita para chegar a um

consenso sobre qual o valor de cada módulo. Para este trabalho, a tabela abaixo foi gerada

calculando a média dos valores discriminados pelos entrevistados, na qual, não interfere nos

resultados:

Tabela 11: Resultado da média dos valores dos entrevistados – SISVENDA

Os períodos para a confecção de cada módulo do sistema ficou definido de acordo

com a tabela que segue:

Sequência Período de Desenvolvimento

1 2 3 4 5 6 7 8 9 10

S1 Mod 1

Mod 2

Mod 3

Mod 4 Mod 5 Mod 6

Tabela 12: Período de desenvolvimento do sistema SISVENDA

Tendo isto, foi pedido para as empresas já descriminadas que fizesse uma avaliação e

um orçamento para cada módulo do sistema específico. Abaixo as suas respostas:

Empresa 1:

Módulos Valor

Mod 1 R$ 4.187,50

Mod 2 R$ 5.112,50

Mod 3 R$ 2.625,00

Mod 4 R$ 5.312,50

Mod 5 R$ 3.875,00

Mod 6 R$ 3.937,50

Total R$ 25.050,00


Id Valor

Mod1 16,75

Mod2 20,25

Mod3 10,50

Mod4 21,25

Mod5 15,50

Mod6 15,75

29

Então, utiliza-se a tabela com a priorização dos módulos e gera-se o fluxo caixa para o

sistema.

Módulo Tipo

Fluxo de Caixa

1 2 3 4 5 6 7 8 9 10

Mod 2 MMF -9.300,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00

Mod 4 MMF

-7.937,50 31,75 31,75 31,75 31,75 31,75 31,75 31,75 31,75

Mod 5 MMF

-3.875,00 15,50 15,50 15,50 15,50 15,50 15,50 15,50

Mod 6 MMF -3.937,50 15,75 15,75 15,75 15,75 15,75 15,75

Tabela 14: Fluxo de Caixa para o sistema SISVENDA de acordo com a empresa 1.


dados já descriminados pela empresa contratante, o que faz-se possível chegar aos seguintes

valores que dizem respeito do projeto:

1. Janela de Oportunidades:10 períodos;

8. Necessidade de Capital: R$ 25.050,00;






Empresa 2:

Módulos Valor

Mod 1 R$ 5.000,00

Mod 2 R$ 8.000,00

Mod 3 R$ 5.000,00

Mod 4 R$ 8.000,00

Mod 5 R$ 7.000,00

Mod 6 R$ 7.000,00

Total R$ 40.000,00


30

Então, utiliza-se a tabela com a priorização dos módulos e gera-se o fluxo caixa para o

sistema.

Módulo Tipo

Fluxo de Caixa

1 2 3 4 5 6 7 8 9 10

Mod 2 MMF -

13.000,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00

Mod 4 MMF

-

13.000,00 31,75 31,75 31,75 31,75 31,75 31,75 31,75 31,75

Mod 5 MMF

-

7.000,00 15,50 15,50 15,50 15,50 15,50 15,50 15,50

Mod 6 MMF -7.000,00 15,75 15,75 15,75 15,75 15,75 15,75

Tabela 16: Fluxo de Caixa para o sistema SISVENDA para a empresa 2


dados descriminados pela empresa contratante geram os seguintes valores que dizem respeito

do projeto:


2. Necessidade de Capital: R$40.000,00;


4. Taxa de reajuste: 2,0%;


6. Valor Presente Liquido para o Custo = R$ 695,67


Após a reunião de negociação dos stakeholders, gera-se o um fluxo de caixa com base

nos dados especificados pela equipe de pesquisa das empresas contratantes e, utilizando os

indicadores financeiros já especificados na seção 2.6 deste trabalho, define-se se um projeto é

viável e sua taxa de retorno de investimento (ROI).

Com isso, de acordo com o orçamento de cada empresa contatada e baseando na

analise feita pelos entrevistados, o projeto a ser executado pela primeira empresa é mais

vantajoso do que o orçado pela outra empresa, pois sua taxa de ROI é maior.

5.3 CASO A X CASO B

Para esta seção foi pedido para os profissionais em tecnologia da informação que

avaliassem os dois sistemas informando, ainda baseado na técnica de priorização utilizada no

estudo, com 100 moedas, por quanto comprariam cada sistema e resultou-se na seguinte

tabela:

31

Sistemas Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4 Média

GPSPHONE 40,00 58,00 30,00 45,00 43,25

SISVENDA 60,00 42,00 70,00 55,00 56,75

Tabela 17: Respostas dos entrevistados

Então, baseado nesses dados, se conclui que para os entrevistados o segundo sistema é

de maior valia do que o primeiro. Na análise dos casos A e B, chegou-se às taxas para os

melhores projetos apresentados pelas empresas de 0,035 ROI para o GPSPHONE e 0,029 ROI

para o SISVENDA.

Entretanto, se analisarmos os valores financeiros, para o segundo sistema ser melhor

investimento que o primeiro, deveria ter uma taxa de, aproximadamente, ROI 1,30 vezes

melhor do que o primeiro. Calculo este obtido através da divisão das médias do SISVENDA

pelo GPSPHONE.

Conclui-se então que para os usuários o SISVENDA é mais rentável que o

GPSPHONE, porém o seu retorno de investimento é relativamente menor do que o outro.

Porém, se ele tivesse 1,30 vezes mais retorno de investimento seria um projeto mais rentável.

32

6 CONCLUSÃO

Softwares são ferramentas que auxiliam na execução de atividades, tarefas e tomadas

de decisões em organizações. Porém, o investimento em uma solução que não atende às

expectativas dos stakeholders ocasiona perda de tempo e recursos. Para Freitas (2011), um

software deve possuir características que contribuam para a solução de problemas e melhoria

da qualidade de trabalho dos usuários, tendo como consequência a melhoria da qualidade do

serviço ou produto da empresa à qual o software se destina.

O processo de elicitação, análise, validação e documentação de requisitos por alguns

motivos como falta de processo, de comprometimento dos envolvidos, uso de técnicas

inadequadas e pressão para entregas rápidas, levam ao uso de práticas que não atendem aos

anseios de clientes e usuários.

De acordo com Withall (2007) diz que os requisitos definem o problema que terá de

ser solucionado: para que o sistema é e o que ele precisa resolver. Eles não definem a solução.

E, para Duan et al. (2009), alguns requisitos possuem maior impacto na satisfação dos

usuários em relação ao software. Erros nas fases de analise de sistemas podem impactar no

desenvolvimento do software causando defeitos em áreas principais do sistema.

Então Karlsson e Ryan (1996) um dos maiores riscos enfrentados por organizações

que desenvolvem software está associado ao não atendimento das necessidades e expectativas

dos usuários.

Cordeiro (2011) explica que as técnicas de elicitação visam à identificação dos

requisitos. No entanto, devido a restrições de tempo e orçamento, pode ser difícil atender a

todos os requisitos identificados para um sistema. Os requisitos geralmente são desenvolvidos

em etapas e a priorização ajuda a definir quais devem ser implementados primeiro.

Então, no entendimento de Ramires (2011), um requisito que pode ser aceito por um

stakeholder pode não ser aceito por outro. O processo de decisão na negociação envolve

procurar uma única alternativa (ponto de intersecção) dentro de um conjunto de opções

aceitáveis pelos participantes e tecnologicamente possíveis.

O desenvolvimento de software ágil é fundamentado nos princípios declarados no

Manifesto Ágil que foi criado pela Aliança Ágil. Libardi e Barbosa (2010) explicam que ele

não rejeita os processos e ferramentas, a documentação, a negociação de contratos ou o

planejamento, mas simplesmente mostra que eles têm importância secundária quando

comparado com os indivíduos e interações, com o software funcionando, com a colaboração

com o cliente e as respostas rápidas a mudanças e alterações.

33

Para Cordeiro (2011) acredita-se que os requisitos priorizados podem servir como

referência para as etapas que constituem o processo de desenvolvimento de software. Então,

utilizamos para este trabalho a técnica Buy a Feature é uma espécie de jogo onde se resulta na

priorização de histórias ou funcionalidades e consiste em “comprar” as mais importantes de

um determinado produto.

Então, se reúnem vários clientes com a intenção de motivá-los a comprar o produto,

descobrir quais recursos irão satisfazê-los. Para isso, abre-se uma negociação entre os clientes,

pois, o jogo consiste em distribuir entre os eles valores que, certamente, não serão suficientes

para a compra de todas as features. Assim, com a junção de dois clientes, por exemplo, eles

conseguirão comprar as desejadas e não terão como adquirir outras. A técnica tem como

objetivo priorizar requisitos através de uma relação de features. Para essa lista é necessário os

clientes atribua valores a cada uma delas, podendo utilizar preços fictícios ou o real valor do

custo de desenvolvimento.

Segundo Bordeuax-Rêgo (2010), o método mais utilizado para a análise de

investimento é o fluxo de caixa descontado. Ele depende da projeção dos fluxos da estimativa

de valor residual e da determinação da taxa de desconto.

Através dessa priorização, gera-se uma tabela com valores (em moedas) para cada

módulo de entrega que são utilizados como entradas de capital e o custo (em dinheiro) para a

produção de cada módulo, expressando a necessidade de capital a ser investido para a

execução do projeto. Então, o Valor Presente Líquido é definido para o custo e para as

entradas. Com isso, defini-se uma taxa de retorno através da unidade ROI que é obtida com a

operação moeda por dinheiro. Conclui-se que, quanto maior a taxa de ROI mais vantajoso é o

projeto.

34

7 REFERÊNCIAS BIBLIOGRÁFICAS

COHN, M. Agile Estimating and Planning. New York: Addison-Wesley, 2006.

WITHALL, S. Software Requirement Partterns. Washington D.C.: Mycrosoft Press, 2007

BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponível em

http://agilemanifesto.org, acesso em 06/06/2013.

FREITAS, A. L. P. Priorização de requisitos para o desenvolvimento de software: uma

abordagem multicritério utilizando o método AHP. [EDITORIAL]. Produto & Produção,

vol. 12, n. 2, p. 87 - 107, jun. 2011.

DE SOUZA, C. F.; SANTANDER, V. F. A. Uma Proposta de Elicitação e Análise de

Requisitos no Contexto de Médias e Pequenas Empresas de Desenvolvimento de Software.

Anais do WER11 - Workshop em Engenharia de Requisitos, Rio de Janeiro - RJ, Brasil, p.

285-296. abr. 28-29, 2011.

CORDEIRO, A. G. Priorização de requisitos e avaliação da qualidade da qualidade de

software segundo a percepção dos usuários. [EDITORIAL]. Ciência da Informação, vol. 40,

n. 2, p. 160 – 179, mai./ago. 2011.

SILVA, R. C.; BENITTI, F. B. V. Padrões de Escrita de Requisitos: Um mapeamento

sistemático da literatura. Anais do WER11 - Workshop em Engenharia de Requisitos, Rio

de Janeiro, Brasil, p. 285-296. abr. 28-29, 2011.

RAMIRES, J. J. C. V. Negociação de requisitos no processo de desenvolvimento de

software. Lisboa, 2004. Dissertação (Mestrado em Informática). Faculdade de Ciências,

Universidade de Lisboa, Lisboa, 2004.

AMBRÓSIO, B. G. Modelagem da fase de requisitos em processos de desenvolvimento de

software: Uma abordagem utilizando dinâmicas de sistemas. Viçosa, 2008. Dissertação (Pós-

Graduação em Ciência da Computação). Universidade Federal de Viçosa, Viçosa, 2008.

HERMSDORF, V. O., et al. Modelagem da atividade de elicitação de requisitos utilizando a

técnica de entrevista: uma abordagem utilizando dinâmica de sistemas. Anais do WER11 -

Workshop em Engenharia de Requisitos. Rio de Janeiro, Brasil, p. 309 – 320. abr. 28-29,

2011.

LIBARDI, P. L. O.; BARBOSA, V. Métodos Ágeis. Limeira, 2010. Dissertação (Pós-

Graduação em Computação) Faculdade de Computação, Universidade Estadual de Campinas,

Limeira, 2010.

DUAN, C. et al. Towards automated requirements prioritization and triage.

Requirements Engineering, v. 14, p. 73–89, 2009.

PRESSMAN, R.S. Engenharia de Software. 5. ed., Rio de Janeiro: McGraw-Hill, 2002. 843p. KARLSSON, J.; WOHLIN, C.; REGNELL, B. An evaluation of methods for prioritizing

software requirements. Information and Software Technology. v.39, p. 939-947, 1998.

http://agilemanifesto.org/

http://www.uenf.br/Uenf/Downloads/POS-ENGPRODUCAO_2397_1294410424.pdf

http://www.uenf.br/Uenf/Downloads/POS-ENGPRODUCAO_2397_1294410424.pdf

35

BERANDER, P. Prioritization of Stakeholder Needs in Software Engineering

Understanding and Evaluation. Thesis (Licentiate of Technology in Software Engineering) - Department of Systems and Software Engineering, Blekinge Institute of Technology, Sweden, 2004, 172p. KARLSSON, J.; RYAN, K. Supporting the selection of Software Requirements. In: INTERNATIONAL WORKSHOP ON SOFTWARE SPECIFICATION AND DESIGN

(IWSSD ‘96), 8th. Proceedings, p. 146-149. 1996.

YOUNG, R.R. The requirements engineering handbook. Boston: Artech House, p. 251. 2004.

Bordeaux-Rêgo, Ricardo. Viabilidade econômico-financeira de projetos / Ricardo

Bordeaux-Rêgo, Gorete Pereira Paulo, Ilda Maria de Paiva Almeida Spritzer, Luiz Péres

Zotes. 3 ed. – Rio de Janeiro : Editora FGV, 2010.

Denne, Mark e Cleland-Huang, Jane. Software by numbers: low-risk and High return

development, Prentice Hall, 2004.

36

8 ANEXOS

8.1 ANEXO I – ORÇAMENTO DA EMPRESA 1

38

8.2 ANEXO II – ORÇAMENTO DA EMPRESA 2

Wellington Vasconcelos - Priorização de requisitos

Documents

Transcript of Wellington Vasconcelos - Priorização de requisitos