Software development within the context of software ecosystems takes place utilizing the software platform of the ecosystem as a development asset. The platform itself obviates the require- ment of engineering every single module and part of a software product, instead providing community backed assets for common functionalities. Adopting a software platform and subsequently joining an ecosystem results in reaping the rewards of a common set of assets available for the developers that are utilizing the platform. On the other hand, joining an ecosystem and utilizing a software platform for development also provides assets and context which can both positively and negatively impact the value of a software product in development. These impacts are largely determined by the ecosystem, its characteristics and its inhabitants. The next two subsections will provide a general mathematical overview on how to integrate software development utilizing a software platform into a mathematical model specifying the cost and the value of software development as a financial option.
3.2.1
Modeling Software Development Costs
By adopting a platform, developers reap the cost savings provided by the assets delivered from the ecosystem. The cost savings are dictated by the number of assets provided by the ecosystem and their supporting materials, such as documentation, process and requirements. We begin to
formalize this notion by providing each phase of software development with a base cost, Ci, denoting
the cost incurred during the development phase i, where i denotes a phase within the software development life cycle. The base cost is parameterized by software cost-estimation techniques.
In each phase of software development, the ecosystem either obviates the development of or delivers a percentage of the assets that would be produced by that phase of the SDLC. To provide a basic example, consider the development of a basic GUI application for calculating software cost and value utilizing a waterfall model of development. The development of the GUI represents 25% of the software. By joining an ecosystem and engaging in platform software development, assets are acquired for creating a GUI from the platform. These assets include software requirements, the architecture of the GUI and its implementing source code, along with unit tests for common functionalities. When developing, analyzing and specifying requirements for the GUI, a certain percentage of those requirements are satisfied by the platform. These assets reduce the number of requirements that need to be developed, analyzed and specified, reducing the overall cost of the requirements phase of development.
In consideration of that scenario, let CReqsrepresent cost of the requirements phase without
utilizing platform development. CReqs represents the cost of the requirements phase if this applica-
tion was being built from the ground up. We also define Di, the reduction in development cost as a
result of asset acquisition from the platform in SDLC phase i. Continuing, CReqs0 is the cost of the requirements phase, utilizing the assets provided by the software platform:
CReqs0 = CReqs∗ (1 − DReqs) (3.1)
Continuing our scenario, assume CReqs = $4,000. The GUI accounts for 25% of the require-
ments, roughly $1,000. The platform provides 50% of the assets required to develop the GUI, or rather, 12.5% of the requirements and reduces the cost of the requirements phase of the SDLC by $500.
Expanding this concept over the duration of the SDLC, each phase has an associated base cost, a cost reduction as a result of platform asset utilization,
Assuming a basic model of the SDLC, there is a cost reduction that exists for each phase of the software development life cycle. The cost reductions result from the acquisition of assets from the platform and the ecosystem, and these assets in turn reduce the cost of engaging in that phase of development.
• Requirements – The platform and ecosystem provide a portion of requirements documenta- tion for any assets that will be utilized during the implementation phase. This documentation forms a part of the requirements specification and analysis. Additionally, developing with a platform may introduce design constraints that reduce the amount of requirements elicitation that occurs within this phase.
• Design – The platform and the ecosystem provide a foundation to the software being devel- oped. This foundation includes the architecture of any code or infrastructural assets that are utilized in the software project. The use of the platform, and subsequently the architecture, may result in less specification and fewer decisions being made during architectural design. • Implementation – The platform and the ecosystem provide a common base of code level
assets to the software being developed. Utilization of such assets obviates the need to develop custom implementations. However, while utilization of platform code assets may result in less code writing, it may result in more code integration.
• Verification & Validation – In a perfect world, every asset comes with test artifacts. How- everFor example, code artifacts should come with unit tests that would have to be written for a custom implemented module. However, that is not always the case. Code assets without test artifacts may require additional development investment to write tests, or may impact or influence a managers decision of whether to adopt a specific platform or not.
• Maintenance – The portions of the software that are composed from assets acquired from the platform are maintained by the members of the ecosystem that contribute to the platform. There may be an additional cost incurred as a results of the utilization of ecosystem assets. Utilization of third party assets requires education and understanding the assets being utilized.
Utilization of certain types of assets may reduce the extent to which developers engage in certain activities within one phase of software development, while increasing the need for other activities in that or a different phase. For example, acquisition of code modules may reduce the amount of code being written, but does not reduce and may increase the time spent during code integration.
3.2.2
Modeling Software Development Value
Just as each phase of the SDLC has an associated cost with engaging in software develop- ment, there is an associated value that is the return on that development investment. At the end of each phase of the SDLC, work products and development artifacts have, in theory, been created that represent the output of that phase. Just as with the cost, consider Vi, the base value derived
in phase i. Let Ai represent the added value contributed to the work products and artifacts as
a result of utilizing platform assets. Finally, Vi0 represents value of the work products produced, given platform utilization, which is the sum of the base value and the added value from platform development:
VReqs0 = VReqs∗ (1 + AReqs) (3.3)
3.2.3
Synthesizing Cost and Value
Having defined our timescale for our model (Section 3.1), as well as a conceptual model of software development cost (Section 3.2.1) as well as software development value (Section 3.2.2), we turn our attention to synthesizing these two models for cost and value into a single computational model. Consider the base form of the Black-Scholes in Equation 2.1:
C(S, t) = N (d1)S − N (d2)Ke−r(T −t) (3.4)
underlying asset, at time of valuation, subject to volatility modeled by N (d1), the cumulative normal
distribution function over a standard normal distribution, K represents the strike price, or the negotiated price of sale of the underlying asset, subject to the volatility modeled by N (d2), a
cumulative normal distribution function over a standard normal distribution. Because K represents a price paid in the future, we discount K back to the current value of money utilizing the riskless discount factor, Ke−r(T −t). We can substitute Equation 3.1 for K, the strike price of an option in software development:
C(t, i) = N (d1)S − N (d2)(Ci∗ (1 − Di))e−r(T −t) (3.5)
where Ci represents the cost incurred for pursuing development in period i and Di represents the
fractional discount in the strike price, incurred from using a platform engineering approach. Con- tinuing, we substitute Equation 3.3 for S, the sale price, in Equation 3.5, yielding the following equation:
C(t, i) = N (d1)(Vi∗ (1 + Ai)) − N (d2)(Ci∗ (1 − Di))e−r(T −t) (3.6)
where i represents a particular period of development, Vi represents the value derived from suc-
cessfully completing development period i and Ai represents the added value from using a platform
engineering approach. The resulting equation provides us with ‘profit’ from engaging in software development period i at time t, whose future value is discounted from the future time T back to the present day value.
However, this model only allows us to reason about a single period of software development, i, at time t, rather than successive periods of software development in the future. Expanding the equation to provide computation for future engagements in software development involves converting our difference to the summation of differences over the lifetime of a software project. We augment
Equation 3.6 as follows: C(t, i) = T X t=i N (d1)(Vi∗ (1 + Ai)) − T X t=i N (d2)(Ci∗ (1 − Di))e−r(τ −t) (3.7)
Because we are now summing the payoff from future investments in engaging in development, it is necessary to redefine the riskless discount term, e−r(T −t) to account for the time difference between today and the period of development, τ , and applying that discount to the investment we are adding to our summation. In simulation, this subtraction is really max(0, τ − t, as to prevent the occurence of asset appreciation from negative time differences, as asset appreciation is already modeled by the functions for volatility. Furthermore, because we are counting multiple periods of development, i has changed to be an index into a vector of software development periods. Since we are now counting the value accrued from future engagements in development, it becomes necessary to apply the riskless discount rate to the value term as well:
C(t, i) = T X t=i N (d1)(Vi∗ (1 + Ai))e−r(τ −t)− T X t=i N (d2)(Ci− Di)e−r(τ −t) (3.8)
Finally, we convert this equation into a probabilistic equation, taking into account random perturbations in both the cost and the value, as well as Pi,t, the probability of successful completion
of development period i during time period t. This probability serves as an indicator variable on the uncertain outcome of development. In stochastic simulation, it will be used to determine if a period of software development is succesful when engaging in that period of software development. Unlike financial options, which are either exercised or not, the outcome of a real option is subject to the success of the endeavor being considered. Pi,t serves to model the probability that the outcome
of software development is executed successfully. In the event of success, the project accrues the value corresponding to the spot price in the model; in the event of failure, some discount to the value accrued from development is applied. Because this equation will be used as the basis for our Monte Carlo simulation, it becomes prudent to compute the expected value of both the strike and
spot price, as follows:
C(S, t, i) =
T
X
τ =t
E[N (d1)(Vi∗ (1 + Ai))e−r(τ −t)] − Pi,tE[ T
X
τ =t
N (d2)(Ci∗ (1 − Di))e−r(τ −t)] (3.9)
In order to simplify this equation1 by using non-negative units for both the value and the
cost of development, we may rewrite this equation in the following form:
C(S, t, i) = −1∗(E[
T
X
τ =t
N (d1)(Vi∗(1+Ai))e−r(τ −t)−Pi,tE[ T
X
τ =t
N (d2)(Ci∗(1−Di))e−r(τ −t)]) (3.10)