- The design of the services, including all of the functional requirements, resources and capabilities needed and agreed
- The design of service management systems and tools, especially the Service Portfolio, for the management and control of services through their lifecycle
- The design of the technology architectures and management systems required to provide the services
- The design of the processes needed to design, transition, operate and improve the services, the architectures and the processes themselves
- The design of the measurement methods and metrics of the services, the architectures and their constituent components and the processes.
Monday, March 31, 2014
Five Aspects of Service Design
There are five aspects of design that need to be considered:
Business Value
With good Service Design it will be possible to deliver quality, cost-effective services and to ensure that the
business requirements are being met. The following benefits are as a result of good Service Design practice:
business requirements are being met. The following benefits are as a result of good Service Design practice:
- Reduced total cost of ownership (TCO): cost of ownership can only be minimized if all aspects of services, processes and technology are designed properly and implemented against the design
- Improved quality of service: both service and operational quality will be enhanced
- Improved consistency of service: as services are designed within the corporate strategy, architectures and constraints
- Easier implementation of new or changed services: as there is integrated and full Service Design, and the production of comprehensives Service Design Packages
- Improved service alignment: involvement from the conception of the service ensuring that new or changed services match business needs, with services designed to meet Service Level Requirements
- More effective service performance: with incorporation and recognition of Capacity, Financial, Availability and IT Service Continuity plans
- Improved IT governance: assists with the implementation and communication of a set of controls for effective governance of IT
- More effective service management and IT processes: processes will be designed with optimal quality and cost-effectiveness
- Improved information and decision-making: more comprehensive and effective measurements and metrics will enable better decision-making and continual improvement of service management practices in the design stage of the Service Lifecycle.
Saturday, March 29, 2014
Message Bus
An enterprise contains several existing systems that must be able to share data and operate in a unified manner in response to a set of common business requests.
Scenario One (problem)
Solution
Scenario Two (solution)
Scenario One (problem)
Solution
Scenario Two (solution)
Messaging Systems
Messaging makes applications loosely coupled by communicating asynchronously, which also makes the communication more reliable because the two applications do not have to be running at the same time. Messaging makes the messaging system responsible for transferring data from one application to another, so the applications can focus on what data they need to share but not worry so much about how to share it.
Channels — Messaging applications transmit data through a Message Channel, a virtual pipe that connects a sender to a receiver. A newly installed messaging system doesn’t contain any channels; you must determine how your applications need to communicate and then create the channels to facilitate it.
Messages — A Message is an atomic packet of data that can be transmitted on a channel. Thus to transmit data, an application must break the data into one or more packets, wrap each packet as a message, and then send the message on a channel. Likewise, a receiver application receives a message and must extract the data from the message to process it. The message system will try repeatedly to deliver the message (e.g., transmit it from the sender to the receiver) until it succeeds.
Multi-step delivery (or pipes & filters)— In the simplest case, the message system delivers a message directly from the sender’s computer to the receiver’s computer. However, actions often need to be performed on the message after it is sent by its original sender but before it is received by its final receiver. For example, the message may have to be validated or transformed because the receiver expects a different message format than the sender. A Pipes and Filters architecture describes how multiple processing steps can be chained together using channels.
Routing — In a large enterprise with numerous applications and channels to connect them, a message may have to go through several channels to reach its final destination. The route a message must follow may be so complex that the original sender does not know what channel will get the message to the final receiver. Instead, the original sender sends the message to a Message Router, an application component and filter in the pipes-and-filters architecture, which will determine how to navigate the channel topology and direct the message to the final receiver, or at least to the next router.
Transformation — Various applications may not agree on the format for the same conceptual data; the sender formats the message one way, yet the receiver expects it to be formatted another way. To reconcile this, the message must go through an intermediate filter, a Message Translator, that converts the message from one format to another.
Endpoints — An application does not have some built-in capability to interface with a messaging system. Rather, it must contain a layer of code that knows both how the application works and how the messaging system works, bridging the two so that they work together. This bridge code is a set of coordinated Message Endpoints that enable the application to send and receive messages.
Channels — Messaging applications transmit data through a Message Channel, a virtual pipe that connects a sender to a receiver. A newly installed messaging system doesn’t contain any channels; you must determine how your applications need to communicate and then create the channels to facilitate it.
Messages — A Message is an atomic packet of data that can be transmitted on a channel. Thus to transmit data, an application must break the data into one or more packets, wrap each packet as a message, and then send the message on a channel. Likewise, a receiver application receives a message and must extract the data from the message to process it. The message system will try repeatedly to deliver the message (e.g., transmit it from the sender to the receiver) until it succeeds.
Multi-step delivery (or pipes & filters)— In the simplest case, the message system delivers a message directly from the sender’s computer to the receiver’s computer. However, actions often need to be performed on the message after it is sent by its original sender but before it is received by its final receiver. For example, the message may have to be validated or transformed because the receiver expects a different message format than the sender. A Pipes and Filters architecture describes how multiple processing steps can be chained together using channels.
Routing — In a large enterprise with numerous applications and channels to connect them, a message may have to go through several channels to reach its final destination. The route a message must follow may be so complex that the original sender does not know what channel will get the message to the final receiver. Instead, the original sender sends the message to a Message Router, an application component and filter in the pipes-and-filters architecture, which will determine how to navigate the channel topology and direct the message to the final receiver, or at least to the next router.
Transformation — Various applications may not agree on the format for the same conceptual data; the sender formats the message one way, yet the receiver expects it to be formatted another way. To reconcile this, the message must go through an intermediate filter, a Message Translator, that converts the message from one format to another.
Endpoints — An application does not have some built-in capability to interface with a messaging system. Rather, it must contain a layer of code that knows both how the application works and how the messaging system works, bridging the two so that they work together. This bridge code is a set of coordinated Message Endpoints that enable the application to send and receive messages.
Message Endpoint
The application and the messaging system are two separate sets of software. The application provides functionally for some type of user, whereas the messaging system manages messaging channels for transmitting messages for communication. Even if the messaging system is incorporated as a fundamental part of the application, it is still a separate, specialized provider of functionality much like a database management system or a web server. Because the application and the messaging system are separate, they must have a way to connect and work together.
Connect an application to a messaging channel using a Message Endpoint, a client of the messaging system that the application can then use to send or receive messages.
Message Translator
Use a special filter, a Message Translator, between other filters or applications to translate one data format into another.
Chaining Transformations
Chaining Transformations
Message Router
Multiple processing steps in a Pipes and Filters chain are connected by Message Channels. A Message Channel decouples the sender and the receiver of a Message. This means that multiple applications can publish Messages to a Message Channel. As a result, a message channel can contain messages from different sources that may have to be treated differently based on the type of the message or other criteria. You could create a separate Message Channel for each message type (a concept explained in more detail later as a Datatype Channel) and connect each channel to the required processing steps for that message type. However, this would require the message
originators to be aware of the selection criteria for different processing steps, so that they can publish the message to the correct channel. It could also lead to an explosion of the number of Message Channels. Also, the decision on which steps the message undergoes may not just depend on the origin of the message. For example, we could imagine a situation where the destination of
a message changes by the number of messages that have passed through the channel so far. No single originator would know this number and would therefore be unable to send the message to the correct channel.
Insert a special filter, a Message Router, which consumes a Message from one Message Channel and republishes it to a different Message Channel channel depending on a set of conditions.
originators to be aware of the selection criteria for different processing steps, so that they can publish the message to the correct channel. It could also lead to an explosion of the number of Message Channels. Also, the decision on which steps the message undergoes may not just depend on the origin of the message. For example, we could imagine a situation where the destination of
a message changes by the number of messages that have passed through the channel so far. No single originator would know this number and would therefore be unable to send the message to the correct channel.
Insert a special filter, a Message Router, which consumes a Message from one Message Channel and republishes it to a different Message Channel channel depending on a set of conditions.
Parallel Processing
However, the overall system throughput is limited by the slowest process in the chain. To improve throughput we can deploy multiple parallel instances of that process to improve throughput. In this scenario, a Point-to-Point Channel with Competing Consumers is needed to guarantee that each message on the channel is consumed by exactly one of N available processors. This allows us to speed up the most time-intensive process and improve overall throughput. However, this configuration can cause messages to be processed out of order. If the sequence of messages is critical, we can only run one instance of each component or use a Resequencer.
Pipeline Processing
Connecting components with asynchronous Message Channels allows each unit in the chain to operate in its own thread or its own process. When a unit has completed processing one message it can send the message to the output channel and immediately start processing another message.
Pipes & Filters
Use the Pipes and Filters architectural style to divide a larger processing task into a sequence of smaller, independent processing steps (Filters) that are connected by channels (Pipes).
Message
Package the information into a Message, a data record that the messaging system can transmit
through a message channel.
A message consists of two basic parts:
through a message channel.
A message consists of two basic parts:
- Header – Information used by the messaging system that describes the data being transmitted, its origin, its destination, and so on.
- 2. Body – The data being transmitted; generally ignored by the messaging system and simply transmitted as-is.
Message Channel
Once a group of applications have a messaging system available, it's tempting to think that any application can communicate with any other application any time desired.
Saturday, March 22, 2014
Integration Styles - Application Integration Options
File Transfer — Have each application produce files of shared data for others to consume, and consume files that others have produced.
Shared Database — Have the applications store the data they wish to share in a common database.
Remote Procedure Invocation — Have each application expose some of its procedures so that they can be invoked remotely, and have applications invoke those to run behavior and exchange data.
Messaging — Have each application connect to a common messaging system, and exchange data and invoke behavior using messages.
Decision Criteria
Application coupling — Even integrated applications should minimize their dependencies on each other so that each can evolve without causing problems for the others. Tightly coupled applications make numerous assumptions about how the other applications work; when the applications change and break those assumptions, the integration breaks. The interface for integrating applications should be specific enough to implement useful functionality, but general enough to allow that implementation to change as needed.
Integration simplicity — When integrating an application into an enterprise, developers should strive to minimize changing the application and minimize the amount of integration code needed. Yet changes and new code will usually be necessary to provide good integration functionality, and the approaches with the least impact on the application may not provide the best integration into the enterprise.
Integration technology — Different integration techniques require varying amounts of specialized software and hardware. These special tools can be expensive, can lead to vendor lock-in, and increase the burden on developers to understand how to use the tools to integrate applications.
Data format — Integrated applications must agree on the format of the data they exchange, or must have an intermediate traslator to unify applications that insist on different data formats. A related issue is data format evolution and extensibility—how the format can change over time and how that will affect the applications.
Data timeliness — Integration should minimize the length of time between when one application decides to share some data and other applications have that data. Data should be exchanged frequently in small chunks, rather than waiting to exchange a large set of unrelated items. Applications should be informed as soon as shared data is ready for consumption. Latency in data sharing has to be factored into the integration design; the longer sharing can take, the more opportunity for shared data to become stale, and the more complex integration becomes.
Data or functionality — Integrated applications may not want to simply share data, they may wish to share functionality such that each application can invoke the functionality in the others. Invoking functionality remotely can be difficult to achieve, and even though it may seem the same as invoking local functionality, it works quite differently, with significant consequences for how well the integration works.
Asynchronicity — Computer processing is typically synchronous, such that a procedure waits while its subprocedure executes. It’s a given that the subprocedure is available when the procedure wants to invoke it. However, a procedure may not want to wait for the subprocedure to execute; it may want to invoke the subprocedure asynchronously, starting the subprocedure but then letting it execute in the background. This is especially true of integrated applications, where the remote application may not be running or the network may be unavailable—the source application may wish to simply make shared data available or log a request for a subprocedure call, but then go on to other work confident that the remote application will act
sometime later.
Shared Database — Have the applications store the data they wish to share in a common database.
Remote Procedure Invocation — Have each application expose some of its procedures so that they can be invoked remotely, and have applications invoke those to run behavior and exchange data.
Messaging — Have each application connect to a common messaging system, and exchange data and invoke behavior using messages.
Decision Criteria
Application coupling — Even integrated applications should minimize their dependencies on each other so that each can evolve without causing problems for the others. Tightly coupled applications make numerous assumptions about how the other applications work; when the applications change and break those assumptions, the integration breaks. The interface for integrating applications should be specific enough to implement useful functionality, but general enough to allow that implementation to change as needed.
Integration simplicity — When integrating an application into an enterprise, developers should strive to minimize changing the application and minimize the amount of integration code needed. Yet changes and new code will usually be necessary to provide good integration functionality, and the approaches with the least impact on the application may not provide the best integration into the enterprise.
Integration technology — Different integration techniques require varying amounts of specialized software and hardware. These special tools can be expensive, can lead to vendor lock-in, and increase the burden on developers to understand how to use the tools to integrate applications.
Data format — Integrated applications must agree on the format of the data they exchange, or must have an intermediate traslator to unify applications that insist on different data formats. A related issue is data format evolution and extensibility—how the format can change over time and how that will affect the applications.
Data timeliness — Integration should minimize the length of time between when one application decides to share some data and other applications have that data. Data should be exchanged frequently in small chunks, rather than waiting to exchange a large set of unrelated items. Applications should be informed as soon as shared data is ready for consumption. Latency in data sharing has to be factored into the integration design; the longer sharing can take, the more opportunity for shared data to become stale, and the more complex integration becomes.
Data or functionality — Integrated applications may not want to simply share data, they may wish to share functionality such that each application can invoke the functionality in the others. Invoking functionality remotely can be difficult to achieve, and even though it may seem the same as invoking local functionality, it works quite differently, with significant consequences for how well the integration works.
Asynchronicity — Computer processing is typically synchronous, such that a procedure waits while its subprocedure executes. It’s a given that the subprocedure is available when the procedure wants to invoke it. However, a procedure may not want to wait for the subprocedure to execute; it may want to invoke the subprocedure asynchronously, starting the subprocedure but then letting it execute in the background. This is especially true of integrated applications, where the remote application may not be running or the network may be unavailable—the source application may wish to simply make shared data available or log a request for a subprocedure call, but then go on to other work confident that the remote application will act
sometime later.
Thinking Asynchronously
Messaging is an asynchronous technology, which enables delivery to be retried until it succeeds. In contrast, most applications use synchronous function calls; for example: a procedure calling a sub-procedure, one method calling another method, or one procedure invoking another remotely through a remote procedure call (RPC) (such as CORBA and DCOM). Synchronous calls imply that the calling process is halted while the sub-process is executing a function. Even in an RPC scenario, where the called sub-procedure executes in a different process, the caller blocks until the sub-procedure returns control (and the results) to the caller. When using asynchronous messaging, the caller uses a send and forget approach that allows it to continue to execute after it sends the message. As a result, the calling procedure continues to run while the sub-procedure is being invoked.
Integration Problems
Interesting applications rarely live in isolation. Whether your sales application must interface with your inventory application, your procurement application must connect to an auction site, or your PDA’s PIM must synchronize with the corporate calendar server, it seems like any application can be made better by integrating it with other applications.
All integration solutions have to deal with a few fundamental challenges:
All integration solutions have to deal with a few fundamental challenges:
- Networks are unreliable. Integration solutions have to transport data from one computer to another across networks. Compared to a process running on a single computer, distributed computing has to be prepared to deal with a much larger set of possible problems. Often times, two systems to be integrated are separated by continents and data between them has to travel through phone-lines, LAN segments, routers, switches, public networks, and satellite links. Each of these steps can cause delays or interruptions.
- Networks are slow. Sending data across a network is multiple orders of magnitude slower than making a local method call. Designing a widely distributed solution the same way you would approach a single application could have disastrous performance implications.
- Any two applications are different. Integration solutions need to transmit information between systems that use different programming languages, operating platforms, and data formats. An integration solution needs to be able to interface with all these different technologies.
- Change is inevitable. Applications change over time. An integration solution has to keep pace with changes in the applications it connects. Integration solutions can easily get caught in an avalanche effect of changes – if one system changes, all other systems may be affected. An integration solution needs to minimize the dependencies from one system to another by using loose coupling between applications.
Friday, March 21, 2014
Tuesday, March 18, 2014
Software Philosophy
- Correct - Correctness is the key aspect of any software system. If a system doesn't do what it's supposed to, then what's the point?
- Simple - I adhere to the "Keep It Simple Stupid" (KISS) principle. Simple generally means small, so I strive to write small classes (generally under 100 lines) and small methods (generally under five lines). Doing so allows my classes and methods to adhere to the Single Responsibility Principle. I like to submit early and often, so that each submission is simple and easy for reviewers to understand. I believe in not writing code until it's actually needed, also known as the You Ain't Gonna Need It (YAGNI) principle. I agree with Donald Knuth's take on premature optimization - it is the root of all evil! I also love Tony Hoare's quote on simplicity - "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
- Well-named - Naming is so important in software. A little extra time spent upfront deciding on a good name pays dividends in the short-term and years down the road.
- Free from duplication - I adhere to the Don't Repeat Yourself (DRY) principle. Relentlessly seek duplication in your software and work to remove it.
- Automatically tested - Write automated unit tests as you write your production classes. Treat the automated tests as a first-class user of the production classes, let them reveal code smells, and address those smells! Write automated functional tests early and build up a suite that takes the drudgery out of manual testing.
- Consistent - Each team should have a set of conventions and use an automated tool (such as Sonar) to ensure the conventions are adhered to. It's more important to remain consistent than to fight over the actual conventions used.
- Documented - Every public package, class, and method should be documented. Every parameter and possible return value should be explained. Note that I agree with Robert Martin in that comments are a failure. As a developer, I strive to express myself in code so that I don't have to rely on comments to communicate my intent.
- Reviewed - Software should be reviewed early and often and code authours should be open to any feedback from reviews. Modern online code review tools (such asAtlassian Crucible) allow for painless reviews.
Sunday, March 16, 2014
Índice de Sharpe como Critério de Seleção de Projetos de Investimentos em Ambiente de Risco
Resumo
Apresenta a importância e aplicação dos riscos na decisão de seleção de projetos de investimento. De maneira geral, apresenta como as técnicas de gestão financeira podem ser aplicadas na seleção dos projetos de investimento e no balanceamento da carteira sob o ponto de vista econômico e financeiro. Além disso, propõe uma maneira de se calcular o risco econômico dos projetos através de simulação de variáveis aleatórias (Monte Carlo) do fluxo de caixa descontado e do uso do Índice de Sharpe como forma simplificada de ranquear projetos e balancear carteiras.
1. Objetivo
Segundo o Standard for Portfolio Management (Second Edition) do Project Management Institute (PMI®), “Portfolio is a collection of projects or programs and other works that are grouped together to facilitate effective management of that work to meet strategic business objectives. The organization may have more than one portfolio, each addressing unique business areas or objectives. Proposed initiatives become part of the portfolio when they are identified, selected, and/or approved”
A Gestão de Portfolio ou Portfolio Governance é o processo que subsidia a seleção, priorização e escolha de investimentos, monitora e controla os investimentos, comunica aos stakeholders e garante que os investimentos estejam alinhados aos objetivos estratégicos. Uma vez definidos os objetivos e as diretrizes estratégicas da empresa – a forma de como ela se estabelece ou quer se estabelecer no mercado – devem-se identificar critérios para gestão disto. Segundo Stratton (2005), “The proper use of a business case and sound project management practices are critical to the success of the Portfolio Management Process”. Esta ideia está apresentada na Figura 1. Se uma nova oportunidade nasce com uma ideia, então se deve avaliá-la tanto do ponto de vista estratégico, quanto do ponto de vista da agregação de valor econômico para a empresa como um todo. Não menos importante, as empresas devem estar capacitadas a gerenciar os projetos da melhor forma, para que o resultado vislumbrado sofra o mínimo de desvio possível. E caso existam desvios ou mudanças no ambiente, a Gestão de Portfolio deve oferecer soluções efetivas e oportunas para um reposicionamento estratégico.
Figura 1: Ciclo de Vida do Investimento em Ativos de Negócios
Fonte: Stratton (2005)
Segundo o Standard for Portfolio Management do Project Management Institute (PMI®), a Gestão de Portfolio depende de todas as definições estratégicas da empresa e recebe feedback dos projetos e programas em curso. A Figura 2 apresenta os processos de Gestão de Portfolio e sua interação com os demais processos de Gestão Estratégica, de Gestão de Programas e Projetos, e de Gestão Operacional.
Figura 2: Processo de Gestão de Portfolio em uma Empresa segundo o Standard for Portfolio Management do PMI®
Este artigo apresenta a importância e aplicabilidade dos riscos na decisão da seleção dos projetos de investimento e baseia-se nos trabalhos de Bernstein (1997), Gandra (2009) e na dissertação de Nikolaou (2009), em que o autor participou como co-orientador. De maneira geral, apresenta como as técnicas de gestão financeira podem ser aplicadas à seleção de projetos de investimentos e de balanceamento da carteira sob o ponto de vista econômico e financeiro. Também propõe uma maneira de se calcular o risco econômico do projeto através de simulação de variáveis aleatórias (Monte Carlo) do fluxo de caixa descontado e do uso do Índice de Sharpe como forma simplificada de ranquear projetos.
2. Breve Histórico sobre a Ciência da Racionalidade na Tomada de Decisões dos Investimentos e Aplicações Financeiras
Para que os gerentes de projeto e portfolios entendam como as decisões de investimento em projetos dos ativos de negócios (i.e., projetos que agregam valor às empresas) são tomadas, é recomendável entender a racionalidade econômica dos decision makers. Sendo assim, será mostrado um breve apanhado histórico do pensamento econômico na busca da construção do entendimento desta racionalidade.
Desde o século XVIII, quando o pai da economia moderna, Adam Smith, publicou o “A Riqueza das Nações”, o entendimento desta racionalidade vem sendo discutido e construído pelos economistas, matemáticos, estatísticos etc. Naquela época, Smith mostrava que os agentes econômicos agiam de acordo com o “interesse próprio”, que na versão moderna ficou estigmatizado erroneamente, conforme Gandra (2002), por “egoísmo”. Desta forma todo sistema econômico e social atingiria a prosperidade através de ações individuais.
O pioneiro a desvendar a psicologia da escolha em ambiente de incerteza foi o matemático suíço, Daniel Bernoulli, em seu artigo publicado nos Autos da Academia Imperial de Ciências de São Petersburgo em 1738. Ao introduzir o conceito de Utilidade Esperada (e não somente de valor esperado), ele afirmava que “o preço – e as probabilidades – não são suficientes para determinar o valor de algo. Embora os fatos sejam idênticos para todos, ‘a utilidade… depende das circunstâncias específicas de quem faz a estimativa… Não há razão para supor que … os riscos estimados por cada indivíduo devam ser considerados de mesmo valor’. A cada qual o seu próprio”. (ver Bernstein, 1997: 103) Embora por muito tempo não se tenha dado atenção ao artigo de Bernoulli, foi só em 1871 com a publicação de “The theory of political economy” de William Stanley Jevons que ideia de utilidade esperada ficou popular (embora seja difícil modelar e aplicá-la às decisões práticas da vida cotidiana). Para os que não lembram a “função utilidade” é representada pelas curvas (côncava, convexa e linear) dos perfis (averse, seeker e neutral) dos tomadores de decisões nas aulas de gerenciamento de riscos em projetos para certificação PMP®.
No século XIX, Karl Marx defendia em sua obra “O Capital” que o objetivo dos detentores do capital era obter mais dinheiro, “mais-valia” a partir de um montante inicial investido. Este princípio é sintetizado pela famosa função geral da circulação da mercadoria (D-M-D’), onde (D) é o dinheiro investido, (M) é a mercadoria comprada e (D’) é o dinheiro investido mais uma remuneração pelo trabalho de transformar o insumo em produto. Contudo, parte deste ganho deveria ser reinvestida no próprio sistema produtivo a fim de se manter a perpetuação no mercado. No processo de acumulação capitalista, para uma empresa se manter no mercado, além de investir em força de trabalho e em meios de produção para repor o capital depreciado, deveria investir também na expansão da firma. Como o próprio Marx (1993: vol. 2, 59) argumentava: “todo caráter da produção capitalista é determinado pela valorização do valor-capital adiantado, portanto, em primeira instância, pela produção do máximo possível de mais-valia; em segundo lugar, no entanto, pela produção de capital, portanto pela transformação de mais valia em capital. (…) O aumento constante do capital torna-se condição para a perpetuação do mesmo”.
Em 1936, o economista inglês, John Maynard Keynes, através da “Teoria Geral”, foi o divisor de águas ao sintetizar os fundamentos através dos quais os empresários decidem investir em um ativo de negócio em um ambiente não ergódigo (sob incerteza). Como a incerteza é a condição de normalidade do sistema econômico – ampliada em épocas de crise econômica e financeira – Keynes apresenta um modelo para sintetizar a racionalidade dos empresários quando decidem ou não por investir para agregar valor. Para ele, o investimento é uma decisão de composição de portfolio, onde o dinheiro a ser destinado aos bens de capital (máquinas, edifícios, e outros) concorre com aplicações em outros tipos de ativos na economia, tais como: ações, terra, derivativos, títulos governamentais, moedas e etc.
Para Keynes, ao contrário dos economistas clássicos (que viam a questão pela ótica dos custos e, desta forma, só avaliavam os preços relativos dos fatores de produção: capital, terra e trabalho), os empresários aplicariam intuitivamente o conceito de “Eficiência Marginal do Capital” (EMgK), em sua avaliação de investimento (ou composição de portfolio). De acordo com este conceito, a projeção da rentabilidade do investimento (ou da demanda pelos produtos) e o estado de expectativas de longo prazo – em contraposição ao perfil mais ou menos propenso ao risco de cada agente econômico: “animal spirit” – são fundamentais para a decisão de investir, ou seja, gerar novos projetos ou dar continuidade aos existentes. A EMgK é composta pela expectativa de receita menos o custo de reposição do capital operacional e investido (contando com os impostos, é claro!) e pela taxa de juros da economia. Macroeconomicamente, esta ideia pode ser resumida na seguinte função: EMgK = f(Ø, i), onde (i) é a taxa de juros da economia e (Ø) é o nível de incerteza dos empresários (ou o grau de confiança). Quanto maior a taxa de juros (i) e o nível de incerteza dos empresários (Ø), menor a EMgK e menor o investimento em bens de capitais, pois os agentes aplicariam seus recursos em títulos do governo (ou na compra da moeda), cuja remuneração justificaria o menor risco deste ativo, ao invés de investir, por exemplo, em uma nova fábrica (cuja remuneração é incerta). A expectativa de receita dependeria, assim, da incerteza ou do grau de confiança dos empresários na economia e nas suas projeções.
Em 1953, John von Neumann e Oskar Morgenstern publicaram “Theory of Games and Economic Behaviour”, introduzindo a Teoria dos Jogos no cenário acadêmico das Ciências Econômicas. Nas teorias da utilidade de Bernoulli e Jevons, o indivíduo opta isoladamente, ignorando o que os outros possam estar fazendo. Já na Teoria dos Jogos, duas ou mais pessoas tentam maximizar suas utilidades simultaneamente (assumindo que cada uma está consciente do que as outras estão fazendo). Assim, eles consideravam que a verdadeira fonte de incerteza residia nas interações das intenções dos indivíduos.
Sendo o investimento uma decisão de portfolio (carteira de ativos), em 1952, o Journal of Finance, publicou um artigo intitulado “Portfolio Selection” de Harry Markowitz. Mas foi só na década de 70 que ele ficou popular com a noção de que: para definir uma carteira, os investidores consideram o retorno esperado como algo desejável e a variância do retorno como algo indesejável. Esta foi a primeira vez que alguém quantificou risco objetivamente, mesmo sem mencionar a palavra, “risco”. Assim, Markowitz mostrou que um investidor não maximiza sua carteira, ou seja, que não é só a rentabilidade esperada de um ativo que importa na decisão de investir. O investidor diversifica sua carteira para se proteger das variações do mercado, assim ele mostrou que o “grau relativo de riscos” entre os ativos também é relevante para decisão. Isto lhe valeu um Prêmio Nobel de Economia em 1990. Em suma, a maioria dos investidores prefere um retorno menor de uma carteira diversificada, a “colocar todos os ovos na mesma cesta”, ainda que a aposta mais arriscada tenha maiores chances de gerar um retorno maior. Assim como na Teoria dos Jogos, muitas vezes, o investidor tenta maximizar a sua sobrevivência e não o seu lucro (ou resultado). É desta forma que as carteiras eficientes minimizam as coisas indesejáveis (variância) e maximizam aspectos desejáveis (retornos).
Markowitz (1952) determina as duas características fundamentais de uma carteira: o seu retorno esperado e a sua variância, esta última representando o risco da carteira. A primeira característica da carteira, seu retorno esperado, e simplesmente a média ponderada dos retornos dos ativos individuais que o compõe, conforme a seguir:
Onde:
- Xi é o percentual investido no ativo i; e
- (Ri) e o retorno esperado do ativo i.
A segunda característica fundamental de uma carteira é o seu risco, medido pela sua variância:
Quando se combinam estes dois critérios, encontra-se o gráfico com as seguintes características, onde os ativos localizados na curva de “fronteira de eficiência” (em vermelho na Figura 3) são aqueles que oferecem o maior retorno para um dado nível de risco. Desta forma, Markowitz ficou consagrado como o “Pai da Moderna Teoria dos Portfolios”.
Figura 3: Curva de “Fronteira de Eficiência” de Markowitz
Tal como é mostrado na Figura 4, quando o agente, no processo de seleção da carteira, opta por compô-la com ativos com correlações negativas, em média, a rentabilidade não se altera. Para o agente conservador, é melhor investir em uma Carteira(C), que não apresenta variação no tempo, que em um único ativo volátil no tempo.
Figura 4: Exemplo Teórico de Composição de Carteira para Minimizar Riscos
Tal como ilustra a Figura 5, na teoria, seria ótimo ter dois ativos perfeitamente não correlacionados de forma compor uma carteira com rentabilidade constante, contudo, o risco de uma carteira subdivide-se em:
- Risco Sistemático (Exógeno) => que não pode ser reduzido com manipulação na composição da carteira.
- Risco Não-Sistemático (Endógeno) => que pode ser reduzido com manipulação na composição da carteira.
Figura 5: Diferença entre Risco Não-Sistemático (Endógeno) e Risco Sistemático (Exógeno)
Fica claro que, na prática, sempre haverá Risco Sistemático, mas neste trabalho estamos preocupados na redução dos Riscos Não-Sistemáticos, doravante, serão denominados simplesmente como risco. Seguindo a linha de Markowitz esta sessão faz uma análise das correlações entre os papéis, a fim de determinar qual é a composição para se alcançar a uma carteira que minimiza o risco do agente avesso.
Baseado nas ideias expostas por Markowitz (1952), William Sharpe desenvolveu o Modelo do Índice Único, em 1963, que procurava simplificar a matriz de variâncias do modelo de Markowitz. Em 1964, Sharpe publicou seu célebre artigo Capital Asset Prices: A Theory of Market Equilibrium under conditions of risk2, estruturando, assim, o Capital Asset Pricing Model (CAPM), um modelo para precificação dos ativos em mercados de títulos de risco em equilíbrio. Segundo o CAPM, o retorno esperado de um título está positiva e linearmente relacionado ao risco sistemático do título. Ou seja, os indivíduos só aplicarão em um ativo com risco se o retorno esperado for suficientemente elevado para compensar o risco existente.
O CAPM é o modelo mais utilizado no mercado de capitais para o cálculo de retorno exigido pelos acionistas de uma empresa, de maneira a compensá-los pelo risco de seu investimento. Pode-se definir pelo CAPM o custo do capital próprio como: onde: E(R) é o retorno esperado (exigido) pelos acionistas de empresa, Rf é a taxa de juros livre de risco, E(Rm) corresponde ao retorno esperado da carteira de mercado e β é a medida do risco sistemático associado ao negócio.
O Índice de Sharpe (IS) expressa uma relação entre o retorno e o risco do papel (ou carteira). Ele é o resultado de uma razão, onde: o numerador é a média aritmética dos retornos excedentes oferecidos pelo papel ou carteira em um determinado período; e o denominador é o grau de dispersão dos valores em relação a esta média, ou Desvio Padrão (que expressará o risco da carteira). Quando se faz o ranking entre os papéis com base no Índice de Sharpe (IS), quanto maior o valor obtido, melhor a classificação. Amplamente utilizado na avaliação de fundos de investimento, o Índice de Sharpe (IS) se encaixa perfeitamente na teoria de seleção de carteira, mais especificamente no modelo CAPM, indicando um ponto na Curva de Fronteira Eficiente de Markowitz. O Índice de Sharpe (IS) costuma ser definido como:
Onde:
- E(rc) é o retorno esperado da carteira;
- rsr é o componente de Risk Free, ou o retorno de um ativo livre de risco que pode ser taxa de juros de um título do governo (em geral, para o caso brasileiro, pode-se adotar um ativo que renda a SELIC); e
- σc é a volatilidade da carteira.
Em termos práticos, esta história serve para elucidar que, hoje, há o entendimento de que, ao tomar decisões de investimentos, cada agente calcula o valor esperado de uma opção, defronta com o seu próprio grau de aversão ou propensão ao risco, avalia a rentabilidade e o risco do projeto em relação à carteira (e em relação ao planejamento estratégico) e monitora o mercado para ver o que os outros estão fazendo.
3. Aplicação das Teorias de Seleção de Carteiras em Seleção de Projetos
Se estas teorias podem ser aplicadas à escolha de uma carteira de investimento, elas também podem ser aplicadas à escolha da carteira de projetos. Para tanto, deve-se calcular os retornos dos investimentos e o riscos associados a cada um deles. Quanto aos cálculos dos retornos, as técnicas de Fluxo de Caixa Descontado para Cálculo do Valor Presente Líquido (VPL) e da Taxa Interna de Retorno (TIR) oferecem respostas satisfatórias. Pois estas técnicas permitem avaliar o quanto um ativo vale através do quanto ele pode render – agregar valor no futuro – aos seus interessados considerando o custo de oportunidade ou Custo Médio Ponderado do Capital, também conhecido como Weighted Average Cost Of Capital (WACC).
Abaixo, segue uma lista da Importância da Análise Econômica para a tomada de decisão em projetos em entidades com fins lucrativos:
- Permite subsidiar a decisão de Go / No Go de investimento respeitando o contexto estratégico da organização;
- Quando se congela uma linha de base de viabilidade, permite aos stakeholders enxergar melhor os objetivos do projeto;
- Auxilia a tomada de decisões sobre viabilidade de possíveis mudanças no projeto envolvendo escopo, cronograma, qualidade, custos e etc;
- Permite aos técnicos de diversas áreas desenvolverem sensibilidade do peso de suas decisões técnicas em termos econômicos;
- Permite ao público avaliar o preço de mercado de uma organização e de suas ações; e
- Permite alinhar os objetivos do projeto aos objetivos da organização, sendo assim, o canal de comunicação entre os gerentes do projeto e o gestor da organização.
3.1 Cálculo dos Retornos Através do VPL e TIR
Valor Presente Líquido (VPL), que consiste em apurar o valor presente de um fluxo de resultado projetado (custos e benefícios líquidos), utilizando-se de uma taxa mínima de atratividade para realizar o desconto do fluxo de caixa. A taxa mínima de atratividade (TMA = i), calculada através do WACC, e é a taxa mínima que a empresa deseja obter na aplicação de um projeto ou negócio. k é o número de períodos do fluxo. Através dele podemos tomar as seguintes decisões:
- VPL > 0 => representa uma agregação de valor superior à aplicação do dinheiro à TMA, ou seja, a rentabilidade do projeto mais que cobre o custo do capital;
- VPL = 0 => Significa que os fluxos de caixa do projeto são exatamente suficientes para remunerar o capital investido à taxa de retorno requerida pelos donos do capital; e
- VPL < 0 => Os fluxos de caixa do projeto não remuneram o capital investido à taxa requerida pelos donos do capital.
O VPL assume algumas características:
- Independe da magnitude dos fluxos de caixa (pequenos ou grandes);
- Leva em consideração o valor dos fluxos (ou dinheiro) no tempo;
- Os VPLs de diversos projetos são cumulativos, ou seja, pode-se somar e achar o valor da total carteira de projetos;
- Supõe que todos os fluxos futuros serão reinvestidos à mesma Taxa Mínima de Atratividade (TMA) – mas pode-se quebrar esta hipótese inserindo outras fontes de renda no modelo;
- Como vantagem, pode-se dizer que, o VPL pode ser calculado para fluxos de caixa não convencionais (com mais de uma inversão de sinal); é representado através de um único número, ou seja, se o VPL for maior que zero, então aceita-se o projeto; pode ser associado com valores de probabilidade para trabalhar sob riscos para se calcular a probabilidade de se atingir determinado valores, ou para saber o desvio padrão dos VPLs; e
- Como desvantagem, o VPL depende da TMA associada, o que pode representar uma dificuldade no cálculo a depender da natureza do projeto.
Taxa Interna de Retorno (TIR), A Taxa Interna de Retorno (TIR), em inglês IRR (Internal Rate of Return), é uma taxa de desconto hipotética que, quando aplicada a um fluxo de caixa, faz com que os valores das despesas, trazidos ao valor presente, seja igual aos valores dos retornos dos investimentos, também trazidos ao valor presente. O conceito foi proposto por John Maynard Keynes, de forma a classificar diversos projetos de investimento: os projetos cujo fluxo de caixa tivesse uma taxa interna de retorno maior do que a taxa mínima de atratividade deveriam ser escolhidos. Através dele podemos tomar as seguintes decisões:
- TIR > i (TMA) => Aceita-se o projeto
- TIR = i (TMA) => Indiferente entre aceitar ou não
- TIR < i (TMA) => Rejeita-se o projeto
A TIR assume algumas características:
- Independe da magnitude dos fluxos de caixa (pequenos ou grandes);
- Leva-se em consideração o valor dos fluxos (ou dinheiro) no tempo;
- As TIRs de diversos projetos NÃO são cumulativas, mas pode-se calcular a TIR da carteira;
- Supõe que todos os fluxos futuros serão reinvestidos à mesma Taxa Mínima de Atratividade (TMA) – mas pode-se quebrar esta hipótese inserindo outras fontes de renda no modelo;
- Como vantagem, pode-se dizer que, é representada através de um único número; e
- Como desvantagem, a TIR NÃO pode ser calculada para fluxos de caixa não convencionais (com mais de uma inversão de sinal), ou seja, existem fluxos não convencionais que apresentam mais de duas TIRs, assim, existe uma solução matemática, mas sem coerência econômica nos números.
3.2 Cálculo dos Riscos de Projetos Através de Simulação de Variáveis Aleatórias
Há um grande desafio em calcular os riscos econômicos dos projetos. Para os papeis de mercado, moedas, ouro, e outros ativos, temos a cotação diária, de forma a conseguir os inputs do comportamento passado, possibilitando extrair: a média, a mediana, a moda, a distribuição estatística, o desvio padrão, etc. Com base nestas informações históricas, pode-se fazer uma projeção do comportamento futuro.
Para projetos, o processo é diferente, o fato de ele ser um “esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo, através de elaboração progressiva”, não existe informações históricas tão bem padronizadas para que se possam calcular as estatísticas básicas. Sendo assim, depende-se da criação de cenários para simular n possibilidades de resultados.
Uma das soluções é considerar que os projetos do mesmo segmento de negócio serão descontados a uma TMA padrão (aqui há críticas acadêmicas, pois se o risco do projeto muda a taxa de desconto requerida deveria mudar também, mas não vamos explorar este aspecto neste trabalho) e calcular as diversas possibilidades de VPLs, bem como sua variância ou do desvio padrão (risco) através de simulações de números aleatórios (popularmente chamado de simulação de Monte Carlo(1) para fluxo de caixa descontado). O objetivo é fornecer uma distribuição dos possíveis valores de uma variável dependente (VPL ou TIR), depois de simular o comportamento de diversas variáveis independentes (de maneira aleatória). A primeira coisa a ser fazer é ter um modelo de fluxo de caixa do projeto. A Figura 6 ilustra uma representação clássica de fluxo de caixa em projetos de desenvolvimento da produção no segmento de Exploração e Produção (E&P) de Petróleo e Gás.
Figura 6: Fluxo de Caixa Clássico em Projetos de Desenvolvimento da Produção em Exploração e Produção (E&P)
Para calcular estas simulações, pode-se ter como input: os riscos de projeto (cronograma e custos), os riscos econômicos (juros, preço, cambial, etc), tributários (impostos, tarifas, etc) e operacionais (custos operacionais, variação na produção, na eficiência operacional, etc). Como exemplo, suponha que tenhamos um projeto de investimento em um determinado campo de petróleo, cujos riscos estejam associados à variação do preço do petróleo e da incerteza da curva de produção. Através de banco de dados, podemos encontrar curva de distribuição do preço do petróleo para inserir no modelo de fluxo de caixa, tal como mostra a Figura 7. Assim, podemos simular as incertezas que caem sobre a receita do projeto. Se o preço do petróleo estiver alto, melhor para a rentabilidade do projeto, caso contrário, pior.
Figura 7: Representação das Incertezas de Receita em um Projeto de Desenvolvimento da Produção em Exploração e Produção (E&P)
Para traduzir as incertezas geológicas, geofísicas e de elevação do petróleo, pode-se estimar que a dispersão da curva de produção assumisse uma distribuição triangular, de forma que, para todos os anos do ciclo do produto, são definidas distribuições variações entre (-15%, + 10%) em torno da curva mais provável. A Figura 8 representa esta incerteza.
Figura 8: Representação das Incertezas de Receita em um Projeto de Desenvolvimento da Produção em Exploração e Produção (E&P)
Uma vez definidos os parâmetros de insumos, pode-se partir para uma simulação através de 10.000 iterações aleatórias. Esta simulação trará como output uma curva de distribuição de probabilidades dos objetivos almejados ou uma curva de frequência dos VPLs encontrados. Como resultado destas simulações pode-se extrair também: a média, a mediana, a moda, a distribuição estatística, o desvio padrão, etc. Assim neste caso, o Desvio Padrão ou a Variância poderão ser assumidos como os riscos de viabilidade deste projeto. A Figura 9 apresenta esta curva de frequência acumulada e a probabilidade de se atingir os objetivos.
Figura 9: Curva de Frequência dos VPLs Encontrados em um Projeto de Desenvolvimento da Produção em Exploração e Produção (E&P)
Utilização do Índice de Sharpe como forma Simplificada de Ranquear Projetos de Investimento ou Balancear Carteiras.
Quando se calcula os VPLs e os Desvios Padrão do VPLs de diversos projetos, pode-se vislumbrar em uma solução do tipo Markovitz para balancear carteira, de forma que se considera o retorno e o risco para ranquear projetos. Se pensar em um gráfico, o eixo Y poderá ser ocupado pela rentabilidade de diversos projetos isoladamente (VPLs) e o eixo X pelo Desvio Padrão destes diversos VPLs (risco).
Para simplificar análise, será mostrado através de um exemplo como se pode utilizar o Índice de Sharpe para seleção econômica dos projetos de investimento. Suponha que uma empresa tenha $10.000 de orçamento global para escolher investir. Suponha que existam ao todo sete projetos distintos, independentes e mutuamente exclusivos. Para estes sete projetos, foi estimado o custo de investimento, o calculo dos VPLs, o cálculo dos Desvios Padrão dos VPLs e a Correlação entre os projetos. A Tabela 1 ilustra que se estes projetos forem selecionados pelo critério do maior Valor Presente Líquido, a carteira agregará à empresa $4.083 (correspondente à soma dos VPLs), além disso, os $10.000 serão investidos integralmente.
Tabela 1: Ranking de Projetos pelo Critério de Seleção pelo Valor do VPL
Agora suponha que ao invés de ranquear pelo critério do maior VPL, será utilizado o critério de maior Índice de Sharpe (que leva em conta os riscos). A Tabela 2 ilustra que, se estes projetos forem selecionados a partir do Índice de Sharpe, a carteira agregará à empresa $4.442 e haverá uma sobra de $600 que poderá ainda ser destinado à aplicação no mercado financeiro. Importante notar que o projeto “E” com maior VPL não aparece com melhor opção e o projeto “A”, que apresenta o segundo maior VPL, é descartado. Isto ocorre quando o risco passa a ser uma variável de análise.
Tabela 2: Ranking de Projetos pelo Critério de Seleção pelo Valor do VPL
Se mostrado graficamente (Figura 10), através do critério de Índice de Sharpe, percebe-se a solução encontrada é bem alinhada à Teoria de Markovitz. Os projetos localizados próximos à curva de “fronteira de eficiência” (em azul na Figura 10) são aqueles que oferecem o maior retorno para um dado nível de risco. Neste caso, a solução seria descartar os projetos “B” e “A”. A Figura 10 mostra ainda que, coincidentemente neste exemplo, o Critério de Seleção por VPL oferece um retorno menor (em $359) e requer um investimento global maior ($600). Além disso, o desvio padrão global da carteira selecionada pelo critério do maior VPL é $554 maior que o desvio padrão global da carteira selecionada pelo critério do maior Índice de Sharpe.
Figura 10: Ranking de Projetos pelo Critério de Seleção pelo Valor do VPL e pelo Índice de Sharp
Caso se queira combinar os resultados obtidos pelo Índice de Sharpe com outros critérios de seleção projetos adotados por uma instituição, pode-se utilizar a planilha tipo OLODUM para realizar esta ponderação para se chegar a uma conclusão não estritamente econômica. Mas isto fica a critério de cada instituição.
Figura 11: Exemplo de Planilha OLODUM para Ponderação dos Critérios de Seleção de Projetos
4. Conclusão
Foi mostrado neste trabalho como técnicas de análise econômica e financeira podem ajudar na escolha de carteira de projetos. Além disso, foi proposta uma maneira de se calcular o risco econômico dos projetos através de simulação de variáveis aleatórias (Monte Carlo) do fluxo de caixa descontado e do uso do Índice de Sharpe como forma simplificada de ranquear projetos e balancear carteiras.
A história sobre a ciência da racionalidade na tomada de decisões de investimentos tem mostrado que a avaliação de riscos é algo fundamental e inerente à análise. Isto porque os decision makers levam em consideração não só os retornos relativos aos ativos a serem selecionados, mas também os riscos (variância) dos retornos destes ativos. Desta forma, os Escritórios de Projetos (PMOs) de empresas privadas, que vislumbram gerenciar “portfolios”, devem reunir os seguintes skills:
- Disciplinas e Técnicas de Gestão de Projetos (este é ponto padrão dos PMOs);
- Disciplinas e Técnicas de Gestão da Estratégica (alguns PMOs apresentam); e
- Disciplinas e Técnicas de Gestão Econômica e Financeira (raramente se vê um PMO com estas características).
Sem o conhecimento e gestão destas disciplinas, um PMO pouco pode auxiliar os gestores na Tomada de Decisão e na Seleção de Projetos em entidades com fins lucrativos.
Rodrigo Mendes Gandra é especialista em Planejamento e Controle da OSX Construção Naval.
Bibliografia
BERNOULLI, Daniel. “Exposition of a New Theory on the Measurement of Risk”. Econometrica, vol. 22, n. 1, Jan/1954, p. 23-36. BERNSTEIN, Peter. Desafio aos Deuses: a Fascinante História do Risco. Rio de Janeiro: Elsevier, 1997 (21º Edição). GANDRA, Rodrigo M. “Adam Smith e a questão distributiva: uma breve resenha da literatura”. Texto para Discussão, n. 149. Niterói (RJ): UFF, 2002. GANDRA, Rodrigo M. “Crise mundial e seus efeitos: a decisão de investimento e a previsibilidade dos modelos econômicos”. Jornal dos Economistas, n. 236, ISSN: 1519-7387. Rio de Janeiro (CORECON-RJ): março de 2009, p.11-12. GANDRA, Rodrigo M.; GARRIDO, e Adriana Sokolik. “Vivemos um ‘círculo virtuoso’?”. Jornal dos Economistas, n. 219. Rio de Janeiro (CORECON-RJ): Out/2007, p.3-5. GANDRA, Rodrigo Mendes. “A Crise Econômica Mundial e seu Impacto em Projetos no Brasil”. Revista Mundo Project Management, ano 5, n. 26. Curitiba (PR), Abr-Mai/2009, p. 24-29. GANDRA, Rodrigo Mendes: e LOPES, Raphael de Oliveira Albergarias. “De Sun Tzu à Arte do General: Lições das Academias de Guerra para Gestão de Projetos Empresariais”. Revista Mundo Project Management, ano 7, n. 40. Curitiba (PR), Ago-Set/2011, p. 24-30. KEYNES, John Maynard. A Teoria Geral do Emprego, do Juro e da Moeda. São Paulo: Editora Atlas, 1992. (Original publicado em 1936) MARKOWITZ, Harry. “Portfolio Selection”. The Journal of Finance, vol. 7, n. 1, mar/1952, p. 77-91. MARX, Karl. O Capital - Crítica de Economia Política. São Paulo: Abril Cultural (Os Economistas, 1983). NIKOLAOU, Leftéris Nicolas. Minimização do risco através da manipulação da composição dos papeis em uma carteira de investimento: estudo de caso para as ações da Petrobras e Vale. Dissertação de Final de Curso do de Pós-graduação Latu Sensu em Finanças e Gestão de Risco do Instituto de economia (IE) da Universidade Federal do Rio de Janeiro e da Universidade Petrobras, Jun/2009. Project Management Institute (PMI). Project Management Body of Knowledge PMBoK ®. USA: 2004 (Third Edition). Project Management Institute (PMI). The Standard for Portfolio Management. USA: 2008 (Second Edition). SHARPE, W. F. (1964, September). “Capital asset prices: A theory of market equilibrium under conditions of risk”.Journal of Finance, 19(3), 425-442. STRATTON, Michael J. “Applying a Portfolio Management Process in the Enterprise Shared Services Environment”.Project Portfolio Management National Conference, 2005.
1 O nome "Monte Carlo" surgiu durante o Projeto Manhattan, durante a Segunda Guerra Mundial, no projeto de construção da bomba atômica. John von Neumann (também precursor da Teoria dos Jogos) e Stanislaw Ulan consideraram a possibilidade de utilizar o método, que envolvia a simulação direta de problemas de natureza probabilística relacionados com o coeficiente de difusão do nêutron em certos materiais.
Fonte: http://pt.wikipedia.org/wiki/Ficheiro:Montecarlo.svg
fonte: http://pmoacademy.com.br/indice-de-sharpe-como-criterio-de-selecao-de-projetos-de-investimentos-em-ambiente-de-risco/
Subscribe to:
Posts (Atom)