Because the crux of options investment analysis is normalizing the value of assets with respect to the present date and a future date, the first step in this model is to develop a concept of time that lays the foundation for our model.
Parameterization of the duration of a period is left to the modeler. Given the definition of a period, let t, τ, and T represent variables of unit period, where t represents the current period of development (e.g., the 7th 30-day period of development), τ represents the period of completion of a particular phase of development (e.g., requirements will be completed by the third 30-day period of development) and T represents the time-horizon of development (e.g., how far in the future we can foresee development). In practice, the time horizon may represents the period corresponding to the date at which the software is released, an arbitrary date after release during maintenance phases of development or the date of retirement or decomissioning of the system. t, τ, and T are related such that t ≤ τ ≤ T
A phase of software development is a specific development phase or activity, such as require- ments ellicitation or testing, that occurs within one or more periods of development and culminates upon the completion of the final period of development for that phase of the SDLC. Transition from a period t to a period t + 1 is instantaneous. For example, assume that a period is measured as a single month. The requirements phase of software project might take three months or three periods as represented in our model. At the end of the third period, the requirements phase of development has completed. Furthermore, each period, occuring within a phase of the software development life cycle, has a cost that is incurred instantaneously upon beginning development in that period. This cost represents the cost of the act of engaging in the development during that period. If a phase of the SDLC spans multiple periods, the cost of that phase of the software development life cycle may be divided equally among the periods that compose the phase of the software development life cycle, subject to variations arising from parameterization. Finally, each period of development results in a revenue from the investment made to engage in development in that period. As with the cost, the revenue can be divided equally among the periods in which that phase of development occurs. Again, the return on investment is subject to parameterization by the modeler.
The pay-off from engaging in development during a particular period and phase in the SDLC is valued based on the work products produced. However, the common unit of measurement for both the cost and the value or pay-off is in Dollars in order to keep the mathematics simple and relational. This model for the value of software is reasonable because for any work completed on a task, there exists a work-product output whose value can be assessed. While the value of the work-product may be zero, that is a detail for simulation, rather than our model. Additionally, valuing the work-products of a phase of software development is reasonable due to extant modes
of contracting and subcontracting wherein a prime contractor may contract a phase or portion of a software project to a sub-contractor. That scenario describes a buyer-seller relationship between the contractor and sub-contractor, with the contractor paying money for assets produced by the sub-contractor. This contracting mode of development is quite frequent in military or government software acquisition. This contractor / sub-contractor relationship mirrors the mode of production in which an organization that develops software operates; namely, that the organization produces software, and, in exchange for the labor expense of developing the software, they receive assets as a result of that development. Finally, yet another equally valid view of value is that the value derived from software development represents ‘earned value,’ which provides a perspective on project performance and progress [23].
3.1.1
Options Treatment of Waterfall Model
The Waterfall model, popularized in the 1960s and 1970s, represents the most traditional form of software development, mirroring the design and development of physical goods. Traditional models of waterfall development divides development into 5 phases: requirements, design, imple- mentation, verification and validation, and maintenance. Each phase of development is entered in its sequential order for a duration of time. In the most rigid models of waterfall development, the completion of a phase of development results in work products that are set-in-stone and cannot be changed, or rather, previous phases of development cannot be revisited. While the waterfall model of software development has numerous shortcomings, detailed by a myriad of publications decrying it and its effectiveness, it serves as a good pedagogical example and starting point for applying to investment options valuation. Figure 3.1 provides a graphical depiction of the waterfall method of software development.
When applying investment options analysis, each phase represents one or more periods of investment. Each phase has an initial investment, equivalent to the cost of the option, plus the some fractional portion of the development cost, up to and including 100%. At the end of that period, work products delivered represents the spot-price of the development. Each phase of the software development life cycle, ocurring in one or more development periods, incurs a cost at the beginning of the period and derives a value or earned value or pay-off at the end of the phase.
Figure 3.1: Waterfall Method of Development
3.1.2
Options Treatment of Iterative-Incremental Model
Iterative-incremental models of software development provide a more modern alternative to the now pedagogical waterfall model. In iterative-incremental development, the entire duration of development is split among a number of iterations. Each iteration represents a full cycle of each of the traditional phases of the software development life cycle or variations on it. During each iteration, a single increment of the software project is under development. An increment might represent a feature, module or subsystem of the software product. Figure 3.2 provides a visual aid in understanding an iterative-incremental software devleopment process.
Applying options value analysis to iterative-incremental styles of development begins with selecting a period that is compatible with the development pace and duration of each iteration. While iterations are subject to variable time extension, use of timeboxing, or strictly fixed length it- erations, as a development mechanism makes iterations function as a standard unit of time. Through utilization of timeboxing, it seems appropriate to set the period of investment to the same duration as an iteration; however, a single increment may span more than one iteration. Similar to the wa- terfall model, each iteration of software development incurs a cost at the beginning of development and affords a payout at the end of each iteration.
However, this coarse grained examination of the iterative-incremental development process represents only a single view of the options value treatment. Since each iteration is considered a full
cycle of the SDLC, iterations could be further subdivided into each phase of the SDLC within an iteration. A more fine grained view accurately represents that at any given stage in development within an iteration, the option to cease development always exists; however, this may not be an improvement over the coarse grained model described above. By taking a micro-level view of each phase of the SDLC within each iteration that develops each increment results in significantly smaller periods, or the use of fractional periods within the options value formulations. Furthermore, the time duration of a phase of the SDLC within the iterative-incremental model of software development may not be equal across all phases, e.g., requirements may last longer than testing. Finally, the possibility exists that a particular increment may last longer than a single iteration; however, multi- period increments are less troublesome than fractional phases of development within a given period as each period represents yet another point where decision making can be made and the model can be re-evaluated.