A Progressive Object-Oriented Internet Development Life Cycle

1 Introduction TO The essence of internet development

The problem of devising methodologies and life cycles for the development of software that are “scalable” [1] continues to be the subject of research [2][3][11][14][15][16][18][20] [22][27][29][30]. The discipline of Software Engineering, which was first recognized in 1969, seeks to resolve this problem. Though now more than a quarter of a century later, the early definition proposed by Fritz Bauer at the first major Software Engineering conference [21] still effectively describes it:

Software Engineering is “the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines.”

The concept of real machines here is key. The real machine considered in this thesis is one that is a combination of the hardware and software that is a product of the current state of technology.

In the sense that Brooks describes “the essence” of software as those difficulties that are inherent in the nature of software [10], a real machine is itself an essential difficulty that is imposed upon software engineering.

Technology has been said to be a self-amplifying agent of change [15]. Thus, in order to obtain software that works on a real machine, we must account for the essence of constant technological change that is ongoing with the real machine throughout the development life cycle.

The current rate of technological change is perhaps more profound now than ever before. Yourdon suggests that, as a profession, we tend to ignore evolutionary improvements of 10% in our machines [28]. Thus, to avoid risks in scheduling, costs, and performance that may be associated with a changing machine, we are only concerned if it is likely that the machine changes will exceed 10% during the development life cycle through implementation of a product. With a typical development life cycle of 18 months to two years [16], as recently as a few years ago a software product could be created for the same real machine that existed at the start of the project. However, with modern software development for the Internet, this is not the case. As Microsoft founder, Bill Gates, acclaimed, “the pace of [the evolution of the Internet] is so fast that the Internet is different every few months.” [16].

Recently, an instance of change in software development has coalesced from the amalgam of the Internet and its associated development tools. This instance of change has removed the possibility of having a stable real machine throughout development. We no longer only have to insure that the actual software product being developed will be successful; we must also insure that the development environment used to create the product is successful. The development environment being referred to consists of all the components used in developing a software product for a real machine. At the time in which this thesis was written, a typical development environment could include the following categories of components:

· Internet programming languages

· Hypertext design languages

· Web servers

· Programming environments

· Web authoring environments

· Server operating systems

· Workstation operating systems

· Web clients

The Internet has brought with it a new catch phrase know as “Internet time”, which characterizes the warped speed of software development today. In Internet time, a software engineer may begin a project, even of moderate size, and risk incurring at least a 10% change in the initial development environment by project completion. For one Internet project in particular that will be discussed in detail later, there was in fact a greater than 10% change in the development environment at four separate times in its development life cycle.

As a developer of Internet-based software, you must be able to adjust to the fact that even the specifications you are given by a software development leader such as Microsoft are not worth printing a hard copy of. A recent article of JavaWorld summarized this sentiment well [4]:

“In the Internet, verbs have no tenses and words have no fixed meaning.”

Microsoft product manager, Bill Koszewski, acknowledges that “The [software specifications for the web client, Internet Explorer,] seem to change daily…” [13]. Rawn Shah of JavaSoft’s on-line magazine, JavaWorld, has noted that “Instead of dealing with the issues of compatibility in different environments at the same time, you have the dilemma of compatibility in different environments at different times” [23].

One proposed solution to the essential problem of a dynamically changing development environment is to use a “Common Development Environment” [29] in which all of the components used for developing an Internet application are a part of a single vendor’s development environment component suite. Unfortunately, as experienced with the CASE tool methodology, in an open architecture heterogeneous environment such as those found in Internet development, a common development environment approach will not work.

The hypothesis of this thesis is that the dynamic change that takes place in the development environment of Internet-based products is a fundamental risk that can be assessed and managed. A progressive object-oriented Internet development life cycle that provides this risk management is introduced. Preliminary validation of the hypothesis, as applied to a real Internet-based development project, is discussed. The results show that the newly introduced development life cycle’s risk management does reduce the risk involved with a changing development environment.

2 Background and conceptual information

Throughout this thesis there are four recurring subjects:

· The Spiral Model of software engineering

· Prototyping

· Object-oriented life cycles

· The Server Team Intranet System

This section provides a background and conceptual orientation to these four subjects.

The exponential growth rate of the Internet has created a need for managing the dynamic chance associated with the development environment for Internet-based projects. The issue of the dynamic development environment will be discussed in great detail later. However, it is reasonable here to propose that there are deficiencies associated with traditional development life cycles that makes using their development strategies unreasonable for Internet-based projects. For example, life cycles such as the “waterfall” model, as shown in Figure 1, suggest that the development of software can occur in distinct stages. Software engineering via the waterfall model requires the development to take place in a linear fashion. The waterfall fails where there is uncertainty regarding what is required or how it can be built [7]. Thus, this development strategy could only be effective if the software’s requirements do not change throughout development. However, even before the recent explosion of the Internet, one could not assume that this would occur.

Figure 1. The Waterfall Model

The waterfall and models with similar strategies were phased out of mainstream development when it became apparent that software development had to be done in an iterative fashion. Several strategies followed that allowed for changes to occur more easily during the development process [2]. One of the most notable strategies was the Spiral Model, which was originally introduced by Barry Boehm in 1988 [7]. As shown in Figure 2, the Spiral Model iterates continually through four main steps:

Step 1. Determining objectives, alternatives, constraints

Step 2. Evaluate alternatives, identify, resolve risks

Step 3. Develop, verify next-level product

Step 4. Plan next iteration

Figure 2. The Spiral Model

The iterative nature of the Spiral Model makes it an ideal framework for identifying and acting on change throughout the development life cycle of a project.

A repeating theme of the Spiral Model is the use of prototyping. A prototype is a model of the software being developed that provides the most effective means for deriving the requirements of the product. When developing software in which an incremental plan is not practical, prototyping may be the best approach [2].

There are two types of prototypes: the throwaway prototype and the evolutionary prototype [2]. The throwaway version is one in which the prototype is used to assist in requirements definition, but is simply discarded after it is created. Alternatively, the evolutionary prototype is one in which each prototype is an incremental modification of the previous prototype that will eventually evolve into the product being developed. A form of evolutionary prototyping that will be called Best-Chance Prototyping is incorporated into the development life cycle introduced in this thesis.

A shortcoming of the Spiral Model is that it was based on a structured procedural form of programming. Since the use of a strictly structured procedural software development methodology is questionable as an effective means of producing software, this thesis includes revisions to the Spiral Model for object-oriented development. Various object-oriented approaches to development life cycles were considered when adapting the Spiral Model to the development life cycle presented in this thesis [3][14][17] [18][19][20][24][27][28][29][30].

The initial research that propagated the realization that there was an essential problem with current development life cycles and methodologies was observed during the initial development of a real object-oriented Internet-based project called STIS[1]. The STIS project was developed concurrently with this thesis and thus served as a “test-bed” for the processes introduced in the thesis. Portions of the development documentation from the STIS project are referred to throughout the thesis to provide validation for each of the newly proposed processes.

3 The changing development environment life cycle

Changeability is part of the essence of software engineering. As mentioned earlier, a new dimension of change is now detectable. This is the development environment of Internet projects. The change associated with the development environment must be addressed throughout the life cycle of the project.

The Changing Development Environment Life Cycle (CDE Life Cycle) that I am introducing is an elaboration of the Spiral Model. The iterative nature of the Spiral Model makes it an ideal candidate for identifying and acting on change throughout the life cycle of a project. However, the extreme nature of change inherent in the development environment for Internet projects is not addressed in the Spiral Model. The CDE Life Cycle incorporates a process for addressing this new essence of difficulty into an elaboration of the Spiral Model.

Boehm acknowledges that the Spiral Model is not complete and that “it needs further elaboration in such areas as risk identification to be fully usable in all situations” [7]. The CDE Life Cycle identifies the changing development environment as a new risk that must be managed. The ensuing risk management is administered across each iteration of the life cycle. In order to accomplish this, specialized processes are incorporated into each step of the CDE Life Cycle that allow for successful management of the changing development environment throughout project development.

The CDE Life Cycle, as shown in Figure 3, concurrently iterates through the same structure of the Spiral Model while incorporating the following four steps:

Step 1. Determine development environment alternatives

Step 2. Evaluate alternative development environments, identify and resolve CDE risk

Step 3. Develop, verify next-level object-oriented product using Best-Chance Prototype

Step 4. Plan next cycle with insight gained from the Best-Chance Prototype

Figure 3. The CDE Life Cycle

Both Figure 2 of the Spiral Model and Figure 3 of the CDE Life Cycle could be seen to imply that the number of iterations or cycles is fixed to four. This is not the case. In fact, Boehm acknowledges that the Spiral Model can generate additional internal iterations to allow experiences and hypothesis to be tested [7]. In following from the Spiral Model, the CDE Life Cycle does not fix the number of iterations.

To provide a means for life cycle timing, the CDE Life Cycle introduces the concept of development “phases”. A phase is a grouping of iterations in the CDE Life Cycle that are collectively considered to show how far along the project has come. The four phases of development with the CDE Life Cycle are:

· The Setup Phase

· The Architectural Definition Phase

· The Design Phase

· The Implementation Phase

These phases are discussed in detail later in this thesis.

3.1 Step 1: Determine Development Environment Alternatives

An iteration of the Spiral Model and subsequently the CDE Life Cycle begins with determining the objectives, alternatives, and constraints of the project. It is here that we must identify what alternatives are available for the development environment.

During the first step, the CDE Life Cycle identifies what alternatives are available for the development environment. At this time, a list of development environment components is generated within each of the development environment categories. This list will be referred to as the Development Environment Component List (DECL). It is possible to select one component from each category in the DECL to create a development environment. A methodology for choosing the best components from the DECL to form a development environment is presented later in this thesis.

It should be noted that no listing of development environment categories will be final. For example, in the early 1990s, there was no “Internet programming language”, whereas today there are well-known and widely-used languages such as Sun Microsystems’ Java and Microsoft’s ActiveX. At the time this thesis was written, some typical development environment categories for an Internet-based project would include [25]:

· Internet programming language — a programming language that allows the creation of truly complex Internet applications on a computer

· Hypertext design language — a language that provides the specification for transferring hypertext documents over the Internet

· Web client — a software application that enables you to access the World Wide Web.

· Web server — a software application that processes requests made by Web clients based on a set of rules for communicating on the Internet

· Internet programming tool — a Web application authoring tool that makes Internet-based applications easier to develop

· Web authoring tool — application that facilitates the creation hypertext and multimedia

· Operating System — the operating system running on the Web client

· Server Operating System — the operating system running on the Web server

Each time the CDE Life Cycle starts a new iteration, we enter Step 1 and create a DECL that consists of the development environment categories along with the components that are currently available in each category. Table 1 shows a DECL for the final phase of the CDE Life Cycle for the STIS project.

Table 1. Development Environment Component List (DECL) from STIS

3.2 Step 2: Evaluate Alternative Development Environments, Identify and Resolve CDE Risk

It is obviously very costly for a project to undergo continual change in the development environment throughout the development life cycle. For example, there is a monetary cost associated with:

· the purchase of new development components

· the reevaluation of customer requirements based on these components

· the training of additional skills to the development team in order to use these components

· the cost of acquiring additional team members who are capable of effectively implementing the product with these new components.

Therefore, we must assess the risk associated with the changing development environment in order to effectively measure and manage it. Boehm introduced a prioritized top-ten checklist of software risk items [8] that consists of:

· personnel shortfalls

· unrealistic schedules and budgets

· developing the wrong software functions

· developing the wrong user interface

· gold-plating

· continuing stream of requirements changes

· shortfalls in externally furnished components

· shortfalls in externally performed tasks

· real-time performance shortfalls

· straining computer science capabilities

It can be argued that a changing development environment can adversely contribute to these risks as well as many others. Table 2 gives scenarios that provide such arguments.

Table 2. CDE Scenarios for Boehm’s Top-ten List

Rather than altering the risk analysis techniques for these and other risk items [8], the CDE Life Cycle focuses on the changing development environment as a risk of its own and will hereafter refer to this risk as the ‘CDE risk item’.

The next step of the Spiral Model and, subsequently, the CDE Life Cycle is concerned with risk analysis and risk resolution. Since the changing development environment has been shown to be a fundamental risk to the development of Internet-based software products, the CDE Life Cycle incorporates specialized risk analysis and risk resolution techniques in order to manage the CDE risk item.

The process used by the CDE Life Cycle to determine the degree of risk associated with the CDE risk item is adapted from a guidebook on software risk abatement that Boehm refers to in several of his risk management publications [8][9][6]. In addition to Boehm’s certification of the guidebook, it is also “next-level” and thus provides a mechanism for how risk assessments are performed. This guidebook breaks the risk assessment process into three sub-processes:

· Risk Assessment Sub-process 1: Determine Impact of Risk Item

· Risk Assessment Sub-process 2: Determine Probability of Risk Occurrence

· Risk Assessment Sub-Process 3: Determine Degree of Impact

There are only four risk items considered in the guidebook: performance, support, cost, and schedule. Then, in the guidebook’s Risk Assessment Sub-process 1, an assessment is performed on each of these four risk items in order to determine their impact on a given project. It is important to note the guidebook indicates that these four risk items were not supposed to be the only four that exist or even to be a partitioning of a universal set of risks. The CDE Life Cycle focuses on the risk associated with the changing development environment.

Risk Assessment Sub-process 1: Determine Impact of Risk Item

Since the CDE risk item has been shown to be a fundamental risk item, an impact assessment is performed for the CDE risk incurred by each of the development environment component categories.

An impact assessment of the CDE risk item is provided in Table 3. The impact assessment identifies four categories of impact that a risk item can fall into:

· Catastrophic

· Critical

· Marginal

· Negligible

Then, the category of a risk item’s impact is determined by,

(1) The potential consequences if the desired outcome is not achieved

or,

(2) The potential consequences of undetected software errors or faults

Table 3. CDE Impact Assessment

Each of the potential consequences listed in Table 3 were directly adapted from those of the impact assessment for the performance risk item in the risk abatement guidebook. The performance risk item was chosen due to performance being a key issue for developers of Internet applications [29]. Performance has many meanings, but as applied to Internet-based development, Yourdon [30] defines it as a measure of the responsiveness to user demands. More specifically, Internet-based performance is defined by the following components:

· Efficient network performance

· Client memory requirement

· Client execution speed

In order to justify the descriptions of the CDE risk categories, each of its category descriptions are now compared to those of the performance risk item.

Catastrophic Impact:

The catastrophic impact categories of the performance risk item and the CDE risk item are shown in Table 4 and Table 5 respectfully.

RISK

IMPACT

Performance

Catastrophic

Failure to meet the requirement would [degrade system performance to a point which would] result in mission failure.

Significant degradation to non-achievement of technical performance.

Table 4. Catastrophic Impact Assessment for Performance

RISK

IMPACT

CDE

Catastrophic

Failure to meet the requirement would degrade the development environment to a point which would result in development project failure.

Significant degradation to non-achievement of an effective development environment.

Table 5. Catastrophic Impact Assessment for CDE (from Table 3)

The major difference between the catastrophic impact of the two impact assessments is in reference to what is degrading. The performance impact assessment focuses on the degradation of computer system performance. The CDE impact assessment focuses on the degradation of the development environment. A catastrophic impact would then be implied for a development project in which a changing development environment would cause the development project to fail.

Critical Impact:

Table 6 and Table 7 show the critical impact category for the performance risk item and the CDE risk item. Here, the focus again changes from the degradation of the computer system performance for the performance risk item to the degradation of the development environment for the CDE risk item. Note that on the 2^nd-row of Table 6, the term “degradation” is replaced by “reduction” just as was the case for the 2^nd-row of Table 7.

RISK

IMPACT

Performance

Critical

Failure to meet the requirement would degrade system performance to a point where mission success is questionable.

Some reduction in technical performance.

Table 6. Critical Impact Assessment for Performance

RISK

IMPACT

CDE

Critical

Failure to meet the requirement would degrade the development environment to a point where development project success is questionable.

Some reduction in the effectiveness of the development environment.

Table 7. Critical Impact Assessment for CDE (from Table 3)

In both cases, the degradation that causes a critical impact is said to cause the development project success to be ‘questionable’. Webster [26] describes questionable as not certain, reason for doubt, giving rise to doubt, uncertain, and lack of certainty. The adjective calibration [8] of these descriptions places questionable at a 55% to 85% probability. Questionable development project success is then a development project in which the probability of success is 55% to 85%. Thus CDE risk implying a critical impact would be a development project in which degradation of the development environment would cause a 55% to 85% probability of development project success.

Marginal Impact:

Again, as shown in Table 8 and Table 9, the degradation of the performance versus the degradation of the development environment is the focus of a marginal impact.

RISK

IMPACT

Performance

Marginal

Failure to meet the requirement would [degrade system performance to a point which would] result in degradation of secondary development project.

Minimal to small reduction in technical performance.

Table 8. Marginal Impact Assessment for Performance

RISK

IMPACT

CDE

Marginal

Failure to meet the requirement would degrade the development environment to a point which would result in degradation of a secondary development project.

Minimal to small reduction in effectiveness of development environment.

Table 9. Marginal Impact Assessment for CDE (from Table 3)

There is a resulting impact of degradation of a “secondary” development project here. Secondary is described by Webster [26] as occupying a subordinate or auxiliary position rather than that of a principle. A secondary development project would then be a portion of the development project that is not considered vital by the target customer, but is perhaps still listed as a low-priority requirement. The CDE risk item implying a marginal impact is a situation where the changing environment causes an auxiliary or subordinate system requirement not to be implemented.

Negligible Impact:

Just as in the other impact categories, Table 10 and Table 11 show that the negligible impact assessment of the performance risk item and the CDE risk item differ only in what degradation is focused on.

RISK

IMPACT

Performance

Negligible

Failure to meet the requirement would [degrade system performance to a point which would] create inconvenience or non-operational impact.

No reduction in technical performance.

Table 10. Negligible Impact Assessment for Performance

RISK

IMPACT

CDE

Negligible

Failure to meet the requirement would degrade the development environment to a point which would create inconvenience or non-operational impact.

No reduction in effectiveness of development environment.

Table 11. Negligible Impact Assessment for CDE (from Table 3)

The degradation is said to create an “inconvenience” or “non-operational” impact. When applied to definition by Webster [26], in which inconvenience means there is a state of being inconvenient, if there were an impact at all, it would be to place the system into an inconvenient stage. An example of CDE risk implying negligible impact would be a change to the development environment that requires an additional (or inconvenient) menu selection that wasn’t a listed requirement for the system.

An impact assessment was performed for the development categories of the STIS project during the latter phases of the CDE Life Cycle. Figure 4 is an excerpt from the final phase of the STIS project that shows each of its impact assessments along with the reasoning behind each choice of impact category. As the figure shows, the impact categories differed among the development environment component categories.

Once the impact has been assessed for the development environment component categories, Risk Assessment Sub-process 2 is used to determine the probability of the occurrence of the CDE risk for each of the components within these categories.

Figure 4. STIS Design Phase Sub-process 1

Risk Assessment Sub-process 2: Determine Probability of Risk Occurrence

In order to determine the probability of a CDE risk occurrence, it is necessary to identify what drivers affect or cause a changing development environment. In the CDE Life Cycle, the drivers of the CDE risk item are openness, industry support, media success, and adaptability. In Risk Assessment Sub-process 2, these drivers are used to determine the probability of a CDE risk occurrence for each potential component. A detailed description of these drivers is presented in Table 12.

The third column of Table 12 refers to ‘characteristics’ of the CDE drivers. It should be noted that these characteristics are a subset of the characteristics associated with the performance, budget, scheduling, and support risk items that were used in the discussion of risk abatement in [8]. This is a departure from Risk Assessment Sub-Process 1 in which only the performance risk item was used for the CDE adaptation. This is justifiable here due to the fact that the performance risk item is recognized as a “cornerstone risk” [8] that affects other risks. Thus, the association of this subset of risk abatement characteristics to the individual CDE drivers is based on how readily they related to each CDE driver. By using these original characteristics from risk abatement, Risk Assessment Sub-process 2 can be carried out in the CDE Life Cycle without the need to introduce completely new forms of software measurement.

The determination of the probability of the occurrence of the CDE risk item is made by using a next-level risk identification checklist that directly is adapted from those used for risk abatement in [8]. The next-level risk identification checklist for the CDE risk item is shown in Table 13.

Table 12. CDE Drivers

Table 13. Quantification of Probability for Development Environment Component Fail

As in the risk abatement next-level checklists, the purpose of Table 13 is to present a sample set of rules of thumb that can help determine the probability that the desired outcome will not occur. After each characteristic of each driver has been assigned a probability of occurrence value, we can then compute the CDE overall probability value by taking the average of these values. In the CDE Life Cycle, Risk Assessment Sub-process 2 is applied to each component in the DECL.

Figure 5 shows how Risk Assessment Sub-process 2 was applied to the Java programming language’s Java Development Kit (JDK) v1.1 for the STIS project.

Figure 5. CDE Probability Assessment for Java JDK v1.1 During STIS Project

Risk Assessment Sub-process 3: Determine Degree of Impact

Risk Assessment Sub-process 3 of the CDE Life Cycle is where the determination is made for whether a change needs to occur to the current development environment in order to lower the CDE risk. The current development environment is the group of components used to create the prototype of the previous iteration of the development life cycle[2]. The sub-process begins by taking the probability assessments from Risk Assessment Sub-process 2 and the category impact assessments of Risk Assessment Sub-process 1. These values are then used to compute the degree of CDE risk. Table 14 provides the measurement for the degree of CDE risk.

Table 14. Degree of CDE Risk (Adapted from AFCS Figure 2-3. Risk Assessment)

The resulting impact assessments from Table 14, as applied to each component, are then used to decide whether a change needs to be made within a development environment category. The degree of impact will range from High to None. The greater the degree of impact, the more weight should be given to the component probability assessments. For example, if the component, Java, of the Programming Languages Category is shown to have a 0.8 probability assessment and the category has a Catastrophic impact assessment, the degree of impact is High. In this case, if there is another component available with a lower probability assessment, a component change should be considered. On the other hand, if the Programming Languages Category has a Negligible impact assessment, a change may not be necessary.

Once Risk Assessment Sub-process 3 has been applied to every development environment category, the components with the lowest degree of impact should be selected. The combination of these components will be referred to as the Best-Chance Component List (BCCL) since they provide the best chance of creating a development environment that will suffer the least from the essential change implied by the Internet.

Figure 6 shows how Risk Assessment Sub-process 3 was applied to the Internet Programming Category with the Java JDK v1.02 during the final phase of the STIS project. As is shown in the figure, this particular development environment category was shown to have a High degree of impact.

Figure 6. Degree of Impact JDK v1.02

Figure 7 shows how Risk Assessment Sub-process 3 was applied to the Internet Programming Category with the Java JDK v1.1 during the final phase of the STIS project.

Figure 7. Degree of Impact for JDK v1.1

This figure shows that the degree of impact for JDK v1.1 was significantly lower than that of JDK v1.02 and in fact lowered the degree of impact to a Moderate risk level. The JDK v1.1 was subsequently chosen to be the component of the Internet Programming Languages category in the final BCCL of the STIS project.

3.3 Best-Chance Prototyping

The previous sections have shown how to effectively assess the CDE risk item. What now remains is how to manage that risk.

As already shown, the CDE risk item is a fundamental risk when developing Internet software. If the product being developed relies on a component of the Internet that is no longer considered able to sustain itself long enough to allow the product to be successful, the development process has failed.

In order to create a successful Internet-based product today, the development life cycle must be able to adapt to the changing development environment. Now that the CDE risk assessment has been performed and the BCCL has been compiled, the final process for Step 2 of the CDE Life Cycle is to apply an effective risk management technique.

The risk management technique that is incorporated by the CDE Life Cycle is the same basic type used in the Spiral Model: prototyping. In general, a prototype is a model of the software being developed that provides the most effective means for deriving the requirements of the product. Prototyping refines key processes, reveals obstacles and problems, and gives development teams more experience with new technologies and tools [22].

The CDE Life Cycle’s prototyping is called Best-Chance Prototyping. In Best-Chance Prototyping, the development environment used in the creation of each prototype and is the combination of the components in the BCCL. This development environment is expected to exhibit the minimum CDE risk. Using this policy when prototyping, the software will have a much greater chance of being compatible with the state of the Internet when the software is released. Additionally, the development of each Best-Chance Prototype will enhance the chances that the fundamental concepts of the product as documented in the requirement specifications are valid within the context of the latest Internet development environment components.

During each successive prototype, components of the development environment are expected to change, but the use of Best-Chance Prototyping will help minimize the extent of this change.

The actual development of Best-Chance Prototypes will be based on the current knowledge of the system being developed. Thus the detail of the prototype will increase as more knowledge is gained (i.e. as the number of iterations of the CDE Life Cycle increase). As depicted in Figure 3, the 1^st Best-Chance Prototype will be created during the initial iteration of the CDE Life Cycle. At this point, the only specification available for the generation of the prototype will come from initial system documentation. Thereafter, each new Best-Chance Prototype will continually evolve from the previous prototypes until they become the final product.

As will be discussed later, the STIS project incorporated four prototypes. For a detailed account of the STIS Best-Chance Prototypes, see Section 4 and Appendices D and E.

3.4 Step 3: Develop, Verify Next-Level Object-Oriented Product Using Best-Chance Prototype

Virtually all approaches to modern software engineering have adopted a model-based “philosophy” as discussed by Yourdon in [30]. Yourdon’s model gives a timing to the step in OOA/OOD/OOP to 1help map OO techniques onto a development life cycle. In a model-based philosophy, there are four models of the software product created during four development “phases”. These models include the requirement’s definition model, the analysis model, the design model, and the implementation model. The work provided in [22] shows how this model-based philosophy can be extended to the Spiral Model. This section describes how this extension was mapped to the CDE Life Cycle.

A model-based life cycle iterates through these models and, at the conclusion of each phase, a deliverable is generated [27]. Table 15 shows the association between the structured-based deliverables of the Spiral Model and that of the OO-based deliverables of the CDE Life Cycle.

Model	The Spiral Model	The CDE Life Cycle
Requirements Definition Model	Concept of Operation	System Specification
Analysis Model	Requirements Analysis	Object-Oriented Analysis
	Requirements Validation	OOA Validation
Design Model	Software Product Design	Object-Oriented Design
	Design Validation and Verification	OOD Validation and Verification
Implementation Model	Detailed Design	Detailed Object-Oriented Design
	Code	Object-Oriented Programming
	Unit Test	Unit Test
	Integration and Test	Integration and Test
	Acceptance Test	Acceptance Test
	Implementation	Implementation.

Table 15: Development Life Cycle Deliverables

Milestone deliverables are generated in Step 3 of the CDE Life Cycle. This is in part due to the fact that the Spiral Model generates them here. Additionally, it has been shown that by creating prototypes, developers gain experience with object-oriented analysis, design, and programming [22]. Subsequently, the next step in the CDE Life Cycle follows the cyclic creation of the Best-Chance Prototypes and is thus the natural location for a development life cycle’s object-oriented techniques. So, as the Spiral Model groups all product deliverables for each phase of the product in its 3^rd step [7], the CDE Life Cycle groups all product deliverables for each model in its 3^rd step. The strategy used for the placement of the individual deliverables within Step 3 of the CDE Life Cycle was based upon studies on managing iteration in object-oriented projects [14][20][27], object-oriented life cycles [17][28], iterative object-oriented development using the Spiral Model [18][22], and case studies in object oriented analysis and design [28][30].

Each of CDE Life Cycle’s product models are now discussed along with the associated model deliverables.

Requirements Definition Model:

During the 1^st iteration of the CDE Life Cycle, we are in what is generally referred to as the “Setup Phase” [22] where the highest-level system requirements are specified. The requirements definition model is generated in the setup phase.

The requirements definition model is high-level in that is should be in the language of the users so that the software engineer and the software user [17] can agree it upon. Therefore, there is generally no object-based model during requirements definition and it is unnecessary to prepare an object-based specification at this time.

In the CDE Life Cycle, it is suggested that a high-level System Specification is developed in which traditional systems analysis techniques are used to describe the function and performance of the product and the constraints that will govern its development [21]. A System Specification describes the objectives and constraints of the project, the high-level system architecture, the project’s subsystems, and projected development project issues. A System Specification generated for the STIS project is available in Appendix B.

Even though there are no purely object-oriented techniques being utilized in the Setup Phase, Yourdon found that using traditional systems analysis techniques such as those used in creating a System Specification are very useful for latter object-finding [30]. Thus, the creation of the System Specification will facility the production of the next-level model by providing insight for the Object-Oriented Analysis.

Once the System Specification is developed, the CDE Life Cycle continues through Step 4[3] of the 1^st phase of life cycle iterations and then through Step 1 and Step 2 of the second phase of iterations. At such time, the development life cycle will have yielded its next-level Best-Chance Prototype and we are ready to create the analysis model.

Analysis Model:

When the CDE Life Cycle reaches the next iteration of Step 3, we enter what is known as the “Architecture Definition Phase” [22] where the system’s analysis model is developed from the system requirements.

In the CDE Life Cycle, the milestone document associated with the analysis model consists of the resulting documentation of an Object-Oriented Analysis (OOA). The standard mapping from the OOA model to a documentation set consists of process descriptions, data definitions, structures, architectural components, and relationships [30].

There is usually sufficient detail in the Architecture Definition Phase to produce voluminous documentation. Yourdon states that such large amounts of the OOA model documentation should be avoided. In addition, he suggests that the analysis documentation consist primarily of a CASE tool encyclopedia, which captures the entire OOA model [30]. The OOA documentation for the STIS project was created with a CASE object-modeling tool known as Playground[4]. Portions of this OOA model documentation for the STIS project are available in Appendix C of this thesis.

After completing the OOA model, the CDE Life Cycle proceeds through the remainder of the current iteration and enters the next iteration, where the next-level Best-Chance Prototype is developed. The feedback associated with this prototyping leads to further development of object classes in the OOA model [17] and brings the CDE Life Cycle to the development of the 3^rd-phase product model, known as the Design Model.

Design Model:

The design model is generated during the 3^rd phase of iterations of the CDE Life Cycle in which we have entered what I will refer to as the Design Phase. This phase is not defined in [22], but is necessary to have a phase between OOA and OOP (i.e. OOD).

Even since the waterfall methodology was popular, software engineers have made a distinction between analysis and design [2]. Where, analysis usually takes place with the assumption that “perfect” technology is available and design takes place with the assumption that the system will be implemented on hardware platform X, under operating system Y, and with programming language Z [30]. With the presence of a changing development environment, it has been shown that we can not assume that X, Y, and Z will remain constant. However, by the time we have entered the Design Phase, the risk management processes associated with the CDE Life Cycle in previous phases will have created the best-chance for X, Y, and Z to be the final development environment components.

In the CDE Life Cycle, the design model will take the form of the documentation associated with an Object-Oriented Design (OOD) methodology. Yourdon recommends that the design documentation consist primarily of a CASE tool encyclopedia which captures the entire OOD model [30]. Upon completing this milestone document, the 3^rd phase iterations of the CDE Life Cycle continues through Step 4 and we enter the final phase in which the implementation model is created.

Implementation Model:

Upon the completion of the final Best-Chance Prototype, the CDE Life Cycle enters the “Development Phase” [22] in which the final model of the product, known as the implementation model, is developed.

At this point, the OOD model for the Design Phase is reviewed and refined to create a final, detailed OOD model, known as the implementation model. This model will then be used by the software engineers to implement the product via Object-Oriented Programming (OOP).

The deliverables associated with the implementation model are the final OOD model, and the completed, 1^st release of the OO product.

The next section of this thesis discusses to processes associated with Step 4 of the CDE Life Cycle that have been referred to in this step.

3.5 Step 4: Plan Next Cycle With Insight Gained From Best-Chance Prototype

In Boehm’s original paper on the Spiral Model [7], the entire discussion of the model’s 4^th Step consisted of:

“An important feature of the spiral model, as with most other models, is that each cycle is completed by a review involving the primary people or organizations concerned with the product. This review covers all products developed during the previous cycle, including the plans for the next cycle and the resources required to carry them out. The review’s major objective is to ensure that all concerned parties are mutually committed to the approach for the next phase.”

Since there is no need to alter this discussion in order to adapt to a changing development environment, the CDE Life Cycle incorporates Step 4 of the Spiral Model as is.

Upon entering Step 4 of the CDE Life Cycle, a review of the current iteration takes place. The deliverables associated with this review are Requirements Plan, Life-Cycle Plan, Development Plan, and Integration and Test Plan.

The Requirement’s Plan and the Life-Cycle Plan are generated during the Setup Phase of the CDE Life Cycle following the review of the System Specification.

The Development Plan is generated during the Architecture Definition Phase of the CDE Life Cycle following the documentation of the OOA model.

The Integration and Test Plans are generated during the Design Phase of the CDE Life Cycle following the documentation of the OOD model.

The CDE Life Cycle concludes at Step 3 during the Implementation Phase and thus, there are no deliverables generated in Step 4.

In the next section, the STIS project is discussed in detail to show how the CDE Life Cycle is scalable to develop an object-oriented, Internet-based product.

4 The Server Team Intranet System

An Internet-based project, known as the Server Team Intranet System (STIS), was developed concurrently with this thesis. While STIS was developed strictly separate of this thesis for a real client, it served as a “test bed” for the new concepts and processes proposed in this thesis.

Throughout each of the discussions leading up to this section, portions of development documentation from the STIS project were provided to show real-life examples of CDE Life Cycle deliverables. In this section, the STIS project will be presented in its entirety to show a real-life example of how the CDE Life Cycle is scalable to develop an object-oriented Internet-based software product.

The structure of this section will follow the four phases of the CDE Life Cycle as they were applied to the STIS project:

1. STIS Setup Phase

2. STIS Architectural Definition Phase

3. STIS Design Phase

4. STIS Implementation Phase[5]

At the conclusion of this section, a comparative analysis is performed on each of the STIS Best-Chance Prototypes in order to provide verification that the CDE Life Cycle does in fact reduce the CDE risk associated with the development of Internet-based products. The larger deliverables, screen captures, and actual code associated with the development of the STIS project are proved in Appendices A-E and are referred to throughout this section.

4.1 STIS Setup Phase

As mentioned in Section 1, the highest-level system requirements are specified in the Setup Phase of the CDE Life Cycle. It is then appropriate for this section to begin by explaining what the STIS project was meant to fulfill and how it came to be.

The STIS project was developed for IBM Alliance Partner, Technology Service Solutions (TSS). More specifically, STIS was developed for a technical team within TSS known as The IBM PC Server Team. As the team’s name suggests, this team was responsible for providing service support for IBM PC Server products. The team’s clients had generally invested from between $5,000 to $50,000 in each of their IBM server products and typically more than that in the software that operates on them. With this stated, clients had very high expectations for IBM to provide effective service and support for these products. IBM placed the responsibility for providing this service and support on the IBM PC Server Team. In general, when clients of IBM PC Server products encountered problems with their systems, the IBM PC Server Team was responsible for determining the cause of the problems and then to devise solutions for these problems.

Before the development of this thesis, the IBM PC Server Team had many resources at its disposal for performing problem determination and for devising solutions for IBM PC Server clients. These resources took the form of hard-copy documentation on the products, internal LAN-based automated information tools, and the human knowledge-bases of experienced team members. As the Internet became an effective means for locating technical information, it became apparent that the IBM PC Server Team could utilize this new resource in its efforts. Additionally, the internal version of the Internet, now known as the Intranet, began to become a common way of harnessing the “Information Superhighway” for internal use within companies. The STIS project is an Intranet system for the IBM PC Server Team. The primary objectives for STIS were:

· To create a heterogeneous system capable of accessing and pulling information from all IBM PC Server Team information resources.

· To increase the IBM PC Server Team’s productivity and effectiveness.

STIS began as an idea for an Intranet system that was elaborated into the STIS System Proposal included in Appendix A. The proposal included a high-level prototype of STIS, which is referred to as STIS Prototype 1. The screen captures, HTML code, and development environment for this prototype are available in Appendix D.

Though STIS Prototype 1 was developed before the concept of the CDE Life Cycle, several of the ideas associated with this thesis were realized at that time. For example, while performing initial research for a development environment with which to create STIS, it became apparent that there would be a problem with maintaining a stable development environment throughout the development life cycle.

Once the STIS System Proposal was reviewed and subsequently approved for development, a development life cycle needed to be selected. At this stage, a requirement of the life cycle was that it had to be iterative in order to allow the product to evolve over time. After significant preliminary life cycle research, the Spiral Model [7] was found to be adaptable to an Internet-based project and was chosen as the development life cycle for STIS.

At the point that the Spiral Model was selected as the development life cycle for STIS, the first iteration of the Spiral Model was already complete. Step 1 and Step 2 of the initial iteration produced STIS Prototype 1. Step 3 produced the STIS System Proposal already discussed. And, in Step 4, the Spiral Model was selected for the Life-Cycle Plan.

The second iteration commenced while still in what is now considered the Setup Phase. Upon beginning this iteration, Step 1 commenced when a list of objectives, alternatives, and constraints was compiled. Initial risk analysis as shown in Step 2 of the Spiral Model was performed and STIS Prototype 2 (detailed in Appendix E) was created. At this point in the STIS project, the processes for generating a DECL and a BCCL were not yet available. The research for the development environment of the 2^nd prototype was performed by sifting through the massive amounts of news media on the Internet, downloading shareware products, and making an “educated guess” as to what development environment would have the best chance of becoming the final STIS development environment.

The compilation of the development environment for STIS Prototype 2 took place as summarized in Table 16.

Prototype 2 Component Research	Notes and Decisions
Development Environment Research:
Server Operating System:	Windows 95 Operating System had a modern UI and an abundance of compatible web-based development applications available.
Programming Language:	Java programming language was the only web-based programming environment available.
Programming Environment:	Wilson WindowWare Inc’s WinEdit Environment was recommended by The JavaSoft Press’ “Core Java” (p. 34).
Web Server:	Only web server available for the Windows 95 operating system was Microsoft’s Personal Web Server.
Web Authoring Tool:	Microsoft FrontPage v1.0 was created for use in conjunction with Microsoft Personal Web Server.
Current Environment Assessment:	The initial prototype (STIS Prototype 1) was generated with manual HTML entered into Microsoft Notepad. Anything more modern should be used in STIS Prototype 2.
New Environment Obtained: Server Operating System: Programming Language: Programming Environment: Web Server: Web Authoring Tool:	Windows 95 JavaSoft’s Java Development Kit v1.0 Wilson WindowWare Inc.’s WinEdit32 Microsoft Personal Web Server v1.0 Microsoft FrontPage v1.0

Table 16. STIS Prototype 2 Research and Notes

The code, screen captures, and selected research papers from STIS Prototype 2 are available in Appendix E.

Upon completion of STIS Prototype 2, Step 3 of the Spiral Model commenced. With the insight gained for the second iteration of prototyping, the Setup Phase concluded with the STIS System Specification, which included a Requirements Plan and a Life-Cycle Plan for Step 4. The STIS System Specification (including the Requirements Plan and the Life-Cycle Plan) is available in Appendix B.

It should again be noted that there were in fact two prototypes generated during the Setup Phase for STIS. This demonstrates that the Spiral Model, and for that matter, the CDE Life Cycle, do not restrict the development to four iterations, but instead allow an unspecified number of iterations within the four distinct phases.

4.2 STIS Architecture Definition Phase

Upon beginning the 3^rd iteration of the Spiral Model with STIS, the CDE Life Cycle was just beginning to take form. The DECL and processes for attaining the BCCL had been introduced. However, the concept of the Architecture Definition Phase was not intact. Thus, Step 1 began by compiling a list of the development environment alternatives available for the next-level product. Interestingly, within the 3-weeks that had transpired between the end of the 2^nd iteration and the beginning of the 3^rd iteration, much of the alternatives for the development environment for STIS had changed. The resultant DECL is shown in

Figure 8. As the figure shows, there were more compatible web servers (Microsoft IIS, Lotus Domino, Netscape FastTrack), a new Internet programming language (Microsoft ActiveX), and a new version of the web authoring tool used in STIS Prototype 2 (Microsoft Frontpage v1.1).

Figure 8. DECL for Architecture Design Phase of STIS Project

The process of risk assessment, as discussed in Section 1.2, was not fully elaborated and thus not implemented on this DECL. Thus, the BCCL was compiled by using a more stringent process than in the Setup Phase, but still mainly consisting of an “educated guess”. Table 17 shows how the BCCL for the 3^rd iteration of the STIS project was selected:

Prototype 3 Component Research	Notes and Decisions
DECL Research:
Internet Programming Language:	New JDK released by JavaSoft’s JDK 1.02 available in beta ActiveX v2.0 released as beta.
Programming Environment:	Microsoft released free beta of Microsoft J++ Java Development Environment. Symantec released Preview 1 of Visual Café
Web Server:	Microsoft Internet Information Server won PC Magazine’s Editor’s Choice for “Department Intranet Web Server”. Microsoft IIS v2.0 (beta) released Lotus Domino v1.0 (beta) released.
Server Operating System:	Windows NT Server v4.0 released
Client Operating System:	Windows NT Workstation v4.0 released
Web Authoring Tool:	Microsoft FrontPage 1.1 available for download free. PC Magazine’s Editor’s Choice for “Web Authoring Tool”. Microsoft FrontPage v2.0 (beta) released
Web Client:	Microsoft Internet Explorer v3.0 released Netscape Navigator v3.0 released
For BCCL Need to Change:	· Operating System · Programming Language · Programming Environment · Web Server · Web Authoring Tool · Web Client
BCCL Obtained:
Server Operating System:	Windows NT Workstation v4.0.
Programming Language:	JavaSoft’s JDK v1.02.
Programming Environment:	Microsoft J++ v1.0b1
Web Server:	Microsoft IIS v2.0
Web Authoring Tool	Microsoft FrontPage 1.1
Web Client:	Microsoft Internet Explorer v3.0

Table 17. STIS Prototype 3 Research and Notes

The resulting STIS prototype 3 is documented in detail in Appendix F. Upon completing this prototype, an object-oriented analysis (OOA) was performed. The OOA model that resulted is available in Appendix C. This concluded the 3^rd iteration of the development life cycle and, consequently, the Architecture Definition Phase of the STIS project.

4.3 STIS Design Phase

The STIS Design Phase began with the full gamut of concepts and processes utilized in the CDE Life Cycle. Thus, in this section, each of the deliverables associated with the CDE Life Cycle are presented for the Design Phase of the STIS project. Figure 9 shows the Design Phase DECL.

Figure 9. DECL from Design Phase of STIS Project

Each of the development environment components of this DECL were then subjected to the risk assessment techniques of Step 2. In Risk Assessment Sub-process 1, a CDE Risk Impact Assessment was performed. The result is shown in Figure 10.

Figure 10. STIS Design Phase Sub-Process 1

In Risk Assessment Sub-process 2, a Probability Quantification was performed for each of the components listed in the DECL. The results of those chosen for the BCCL are shown in Figures 11-16.

Figure 11. STIS Design Phase Sub-Process 2 (Java JDK 1.1)

Figure 12. STIS Design Phase Sub-Process 2 (Visual Café Preview 2)

Figure 13. STIS Design Phase Sub-Process 2 (Microsoft IIS v3.0)

Figure 14. STIS Design Phase Sub-Process 2 (Microsoft FrontPage97)

Figure 15. STIS Design Phase Sub-Process 2 (Netscape Navigator v4.0)

Figure 16. STIS Design Phase Sub-Process 2 (Excite Search Engine v2.0)

Then, in Risk Assessment Sub-process 3, a degree of impact was performed with each category from Risk Assessment Sub-process 2. The BCCL was then generated as a result of choosing those components that provided the lowest degree of impact from Risk Assessment Sub-process 3. Table 18 shows the resulting BCCL.

Prototype 4 Component Research	Notes and Decisions
For BCCL, need to change:	· Operating System · Programming Language · Programming Environment · Web Server · Web Authoring Tool · Web Client
BCCL Obtained:
Programming Language:	JavaSoft’s JDK v1.1
Programming Environment:	Symantec’s Visual Café Preview 2
Web Server:	Microsoft IIS v3.0 Active Server
Web Authoring Tool:	Microsoft FrontPage97
Web Client:	Netscape Navigator v4.0 (beta)
Web Search Engine:	Excite v2.0

Table 18. STIS Prototype 4 Research and Notes

At this point, the STIS Prototype 4 became the 1^st true STIS Best-Chance Prototype. The screen captures, code, and assorted research literature used for performing Risk Assessment Sub-process 2 is available in Appendix G.

The preceding deliverables were to be the last for the STIS project. The project was discontinued for an assortment of reasons, including:

· The developer of this thesis and the STIS project was scheduled to graduate before the project could be completely implemented and would no longer be an employee of TSS upon graduation.

· The management who controlled the destiny of the STIS project came to the conclusion that without the original developer, there were no resources available to maintain the system and thus no desire to see it through implementation.

Therefore, the Implementation Phase of the STIS project never occurred and is not available for discussion in this thesis. Fortunately, the STIS project did provide the longevity necessary to provide much verification and validation of the processes and concepts proposed in this thesis. In the final subsection of Section 2, an analysis is performed to show how the CDE risk did have a profound affect on the development of the STIS project and, further, how the application of the CDE Life Cycle allowed for effective management of this risk.

4.4 An Analysis of the STIS Project

Four prototypes of the STIS project were presented in this section. As noted, STIS Prototypes 3 and 4 were the only prototypes that incorporated the majority of the CDE Life Cycle processes. Furthermore, STIS Prototype 4 was the only Best-Chance Prototype. In this subsection, an analysis is performed on the four prototypes to demonstrate:

1. The CDE Risk adversely affected each of the STIS prototypes

2. By using the CDE Life Cycle, the CDE Risk was minimized for Prototype 4 and would have been for the proceeding Prototypes if they had been developed with the full CDE Life Cycle.

Table 19 shows five major development environment categories that existed throughout the STIS project. As the table shows, there was not one entry in the table that existed in two or more prototypes. Further, there are four entries in the table that are no longer supported: WebEdit, IBM WebExplorer v1.0, Netscape FastTrack, and the Java JDK v1.0.

	Programming Language	Web Authoring Tool	Web Server	Web Client	Programming Environment
Prototype 1	N/A	NotePad	N/A	IBM WebExplorer v1.0	N/A
Prototype 2	JDK 1.0	WebEdit	Netscape FastTrack	Netscape Navigator v1.02	WebEdit
Prototype 3	JDK 1.02	FrontPage 1.1	MS IIS v2.0	Microsoft Explorer v3.0	Microsoft J++ v1.0b3
Prototype 4	JDK 1.1	FrontPage97	MS Active Server.	Netscape Navigator v4.0	Symantec Visual Café Preview 2

Prototype X	JDK 1.1	FrontPage97	MS Active Server	Netscape Navigator v4.0	Symantec Visual Café v1.0

Table 19: Major Development Environment Categories for STIS Project

The time that elapsed between the creation of each STIS prototype was approximately 1.5-months. Since the completion of STIS Prototype 4, that time had again elapsed and Step 2 of the CDE Life Cycle was again applied in order to see if the trend of the CDE risk that was shown in Table 19 continued to occur. The final row of the table shows that only one of the categories would have chanced to create the next-level BCCL. Additionally, the trend of change in the development environments appears to be moving more towards simply upgrading to the next-level version of the component that was used in the previous Prototype.

From this preliminary data, one can infer that Internet-based development can be adversely affected by CDE risk. Further more, the CDE Life Cycle not only reduces the CDE risk, but is shown to provide the best-chance for attaining the development environment that will be used when the development life cycle reaches the Implementation Phase.

5 Discussion And Conclusion On The CDE Life Cycle

The development of software for the Internet is new to the discipline of Software Engineering. The risk associated with a dynamic development environment, now known as the CDE risk, is just being realized. There is a need in the discipline to develop scalable methodologies and development life cycles capable of managing this CDE risk.

As yet, no solutions for this risk in the form of scalable methodologies and development life cycles have been vigorously validated. Solutions such as the “Common Development Environment” [29] have only been proposed and are most likely not scalable to the complexity of the Internet.

The CDE Life Cycle presented in this thesis proposes as a scalable solution for the risk of a changing development environment. Although extensive validation of this solution has not yet occurred, the STIS project provides preliminary validation that the CDE Life Cycle effectively manages the CDE risk associated with the development of Internet applications.

Bibliography

[1] Basili, V., & Musa, J.D. (1991, September) The Future of Engineering Software: A Management Perspective. IEEE Computer, pp. 90-96.

[2] Blum, B. (1992). Software Engineering: A Holistic View. New York: Oxford University Press.

[3] Blum, B. (1994, November). A Taxonomy of Software Development Methods. Communications of the ACM, pp. 82-94.

[4] Blundon, W. (1996) Java and ActiveX: Java Wins on the Internet, but the Intranet rules. [On-line]. Available: http://www.javaworld.com/javaworld/jw-09-199 6/jw-09-blundon.html.

[5] Boehm, B. (1981). Software Engineering Economics. New Jersey: Princeton-Hall, Inc.

[6] Boehm, B. (1984, January). Verifying and Validating Software Requirements and Design Specifications. IEEE Computer, pp. 75-87.

[7] Boehm, B. (1988, May). A Spiral Model of Software Development and Enhancement. IEEE Computer, pp. 61-72.

[8] Boehm, B. (1989). Tutorial: Software Risk Management. Washington, DC: IEEE Computer Society Press.

[9] Boehm, B. (1991, January). Software Risk Management: Principles and Practices. IEEE Software, pp. 32-41.

[10] Brooks, F. (1987, April). No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, pp. 10-19.

[11] Brooks, F. (1995). The Mythical Man-Month. New York: Addison-Wesley Publishing Company.

[12] Cornell, G., Horstmann, C. (1996). Core Java. California: SunSoft Press.

[13] Erickson, J. (1996) MS Explorer: The Perpetual Crunch Mode. [On-line]. Available: http://nytsyn.com/live/News3/226_081396_155942_28214.html.

[14] Fayad, M., & Cline, M. (1996, September). Managing Object-Oriented Software Development. IEEE Computer, pp. 26-31.

[15] Garmus, D., & Herron, D. (1996). Measuring the Software Process. New Jersey: Princeton-Hall, Inc.

[16] Gates, B. (1996). The Road Ahead. New York: Penguin Books Ltd.

[17] Henderson-Sellers, B., & Edwards, J. (1990, September). Object-Oriented Systems Life Cycle. Communications of the ACM, pp. 142-159.

[18] Khan, E., Al-A’ali, M., & Girgis, M. (1995, October). Object-Oriented Programming for Structured Procedural Programmers. IEEE Computer, pp. 48-57.

[19] Korson, T., & McGregor, J. (1990, September). Understanding Object-Oriented: A Unifying Paradigm. Communications of the ACM, pp. 40-60.

[20] Pittman, M. (1993, January). Lessons Learned in Managing Object-Oriented Development. IEEE Software, pp. 43-53.

[21] Pressman, R. (1992). Software Engineering: A Practitioner’s Approach. New York: McGraw-Hill, Inc.

[22] Sadr, B., & Dousette, P. J. (1996, September). An OO Management Strategy. IEEE Computer, pp. 33-38.

[23] Shah, R. (1996) A Portable Hill of Beans: New Java Beans API brings object-orientation’s grail of portability and reuse to the Java industry. [On-line]. Available: http://www.javaworld.com/javaworld/jw-09-1996/jw-09-javabeans.html.

[24] Snyder, A. (1993, January). The Essence of Objects: Concepts and Terms. IEEE Software, pp. 31-42.

[25] Stanek, W. (1996). HTML, Java, CGI, VRML, SGML Web Publishing Unleashed. Indianapolis: Sams.net Publishing.

[26] Webster’s Ninth New Collegiate Dictionary. (1991). Merriam-Webster, Inc.

[27] Williams, J. (1996, September). Managing Iteration in OO Projects. IEEE Computer, pp. 39-43.

[28] Yourdon, C. (1994). Object-Oriented Systems Design. New Jersey: Princeton-Hall, Inc.

[29] Yourdon, E. (1996, August). Java, The Web, and Software Development. IEEE Computer, pp. 25-30.

[30] Yourdon, E., & Argila, C. (1996). Case Studies in Object Oriented Analysis and Design. New Jersey: Princeton-Hall, Inc.

Appendices

[1] STIS is an acronym for Server Team Intranet System, which is discussed in detail in Section 4.

[2] In the case in which there is no previous prototype (i.e. the 1^st iteration of the life cycle).

[4] Playground® is an shareware object-modeling tool created by Peter Coad’s Object International.

[5] As discussed later in this section, the STIS Implementation Phase did not occur in its entirety.