UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Instituto Tércio Pacitti de Aplicações e Pesquisas Computacionais - NCE
WELLINGTON ...
ii
WELLINGTON GOMES DE VASCONCELOS
PRIORIZAÇÃO DE REQUISITOS VISANDO OBTER RETORNO DE
INVESTIMENTO
Monografia apresentada ...
iii
AUTORIZAÇÃO
WELLINGTON GOMES DE VASCONCELOS, autorizo o Instituto Tércio Pacitti de
Aplicações e Pesquisas Computacion...
iv
RESUMO
Este estudo demonstra que a priorização de requisitos que agregam maior valor de
acordo com as necessidades dos ...
v
SUMÁRIO
1 INTRODUÇÃO ......................................................................................................
6
1 INTRODUÇÃO
O objetivo deste trabalho é demonstrar que a priorização de requisitos que agregam
maior valor de acordo co...
7
realmente era esperado. Desta forma, o sistema não possui os processos definidos de acordo
com a necessidade do negócio ...
8
de problemas acidentais ou inesperados. Segundo Silva e Benitti (2011), a utilização de
padrões na área de requisitos é ...
9
De acordo com Karlsson e Ryan (1996) um dos maiores riscos enfrentados por
organizações que desenvolvem software está as...
10
De acordo com Hermsdorf, V. O. et al. (2011) um erro proveniente da especificação
de requisitos detectado em uma fase a...
11
2 REFERENCIAL TEÓRICO
2.1 REQUISITOS
Requisitos são configurados como as necessidades que as partes interessadas levant...
12
3. Separa as partes formais e informais: Uma especificação de requisitos é como
um contrato que define o que os constru...
13
 Os stakeholders que utilizam o sistema falham em usar todas as capacidades do
sistema;
 Ocorre um grande volume de p...
14
Segundo Karlsson, Wohlin e Regnell (1998), os requisitos devem ser alocados em
diferentes versões do software e, para B...
15
 Atribuição Numérica: Através de uma escala de valores inteiros de 1 a 5, deve
ser identificado pelos stakeholders, em...
16
2.5 METODOLOGIAS ÁGEIS
O desenvolvimento de software ágil é fundamentado nos princípios declarado no
Manifesto Ágil que...
17
 Colaboração com clientes mais do que negociação de contratos;
 Responder a mudanças mais do que seguir um plano.
Par...
18
 Janela de oportunidades: Tempo decorrido entre o início do projeto e o
momento em que o produto final do projeto tem ...
19
Então Bordeuax-Rêgo(2010) afirma que o método do valor presente liquido (VPL) faz
uma comparação do investimento realiz...
20
3 METODOLOGIA DE PESQUISA
3.1 TIPO DE PESQUISA
Em estudo sobre técnicas de priorização de requisitos, percebe-se que sã...
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
r...
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 utiliz...
23
Mod2 AE Análise de Crédito – Utilizado no Pagamento de assinaturas.
Mod3 MMF
Onde estou? - Permite aos clientes saibam ...
24
Mod3 AE Cadastro de Clientes - Registrar Clientes que efetuam compras na loja
Mod4 MMF Gerenciar Vendas - Controlar as ...
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 consens...
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....
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 aprese...
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 sobr...
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 C...
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 C...
31
Sistemas Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4 Média
GPSPHONE 40,00 58,00 30,00 45,00 43,25
SISVE...
32
6 CONCLUSÃO
Softwares são ferramentas que auxiliam na execução de atividades, tarefas e tomadas
de decisões em organiza...
33
Para Cordeiro (2011) acredita-se que os requisitos priorizados podem servir como
referência para as etapas que constitu...
34
7 REFERÊNCIAS BIBLIOGRÁFICAS
COHN, M. Agile Estimating and Planning. New York: Addison-Wesley, 2006.
WITHALL, S. Softwa...
35
BERANDER, P. Prioritization of Stakeholder Needs in Software Engineering
Understanding and Evaluation. Thesis (Licentia...
36
8 ANEXOS
8.1 ANEXO I – ORÇAMENTO DA EMPRESA 1
37
38
8.2 ANEXO II – ORÇAMENTO DA EMPRESA 2
Próximos SlideShares
Carregando em…5
×

Wellington Vasconcelos - Priorização de requisitos

276 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
276
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
1
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Wellington Vasconcelos - Priorização de requisitos

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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. 6. 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. 7. 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. 8. 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. 9. 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. 10. 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. 11. 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. 12. 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. 13. 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. 14. 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. 15. 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. 16. 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. 17. 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. 18. 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 Lucro ROI  n n TMA VF TMA VF TMA VF TMA VF VPL )1()1()1()1( 3 3 2 2 1 1          . %)11( 120 1 InvestVPL    0 )1()1()1( 2 2 1 1        n n i VF i VF i VF VPLi 
  19. 19. 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. 20. 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. 21. 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. 22. 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. 23. 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. 24. 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. 25. 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. 26. 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. 27. 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. 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$47.000,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$ 45.353,22 6. Valor Presente Liquido para o custo = R$ 734,54 7. Retorno de Investimento (ROI): 0,016 moeda/real; 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. 28. 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 Tabela 13: Orçamento apresentado pela empresa 1. Id Valor Mod1 16,75 Mod2 20,25 Mod3 10,50 Mod4 21,25 Mod5 15,50 Mod6 15,75
  29. 29. 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. Utilizando os indicadores já especificados na seção 2.6 deste trabalho e, também, os 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; 9. Período de Investimento: Períodos de 1 ao 4; 10. Taxa de reajuste: 2,0; 11. Valor Presente Liquido para o Investimento = R$ 24.036,06 12. Valor Presente Liquido para o custo = R$ 695,67 13. Retorno de Investimento (ROI): 0,029 moeda/real;  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 Tabela 15: Orçamento apresentado pela empresa 2.
  30. 30. 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 Utilizando os indicadores já especificados na seção 2.6 deste trabalho e, também, os dados descriminados pela empresa contratante geram os seguintes valores que dizem respeito do projeto: 1. Janela de Oportunidades: 10 períodos; 2. Necessidade de Capital: R$40.000,00; 3. Período de Investimento: Períodos de 1 ao 4; 4. Taxa de reajuste: 2,0%; 5. Valor Presente Liquido para o Investimento = R$ 38.303,47 6. Valor Presente Liquido para o Custo = R$ 695,67 7. Retorno de Investimento (ROI): 0,018 moeda/real; 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. 31. 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. 32. 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. 33. 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. 34. 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.
  35. 35. 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. 36. 36 8 ANEXOS 8.1 ANEXO I – ORÇAMENTO DA EMPRESA 1
  37. 37. 37
  38. 38. 38 8.2 ANEXO II – ORÇAMENTO DA EMPRESA 2

×