Carol Harstad Thesis - Directed Research Project

Running head: SOFTWARE DEVELOPMENT PROJECTS

SOFTWARE DEVELOPMENT PROJECTS:

A CASE STUDY OF FAILURE AND SUCCESS

Direct Research Project in Partial Fulfillment

of the Requirements for the Degree of Master of Science

Information Systems – Software Engineering Management

Submitted By

Carol A. Harstad, BS (IS-Pr)

1240 Apopka Lane, Kissimmee, Florida 34759

(863) 427-0890

[email protected]

Under the direct supervision of Dr. Ward Ulmer

Online Campus – Strayer University

September 2009

Software Development Projects

ACCEPTANCE PAGE

Strayer University Certificate of Approval Form

A DRP Entitled

SOFTWARE DEVELOPMENT PROJECTS: A CASE STUDY OF FAILURE AND SUCCESS

By

CAROL A. HARSTAD

We hereby certify that this DRP submitted by CAROL A. HARSTAD conforms to acceptable

standards, and as such is fully adequate in scope and quality. It is therefore approved as the

fulfillment of the requirement of the degree of Master of Science in Information Systems –

Software Engineering Management.

Approved: ___________________________________________

Supervising Faculty: ___________________________________________

Peer Review/Technical Advisor: ___________________________________________


ABSTRACT

To err is human, but to really foul things up you need a computer ~ Paul Ehrlich

When proper software engineering techniques and processes are neglected or ignored,

software development projects can suffer. They can cost more than estimated, take longer than

anticipated, be low in quality, and maintenance can be difficult. At worst, the project could be

completely abandoned. By using the proper processes and procedures, an organization has a

better chance of completing a high quality, maintainable software project on time, and less

expensive than one that is disorganized and in disarray.

The purpose of this study was to determine processes we can implement to ensure the

successful delivery of a development project. The main question that was answered by this

research project was; what can we do within the development process to ensure a successful

delivery of software projects and to avoid possible failure? To answer that question, the

knowledge areas of software engineering were laid out, examples of failures were discussed,

methods were outlined, and tools were identified. The results were obtained from websites,

textbooks, newspaper articles, websites, and industry publications.


TABLE OF CONTENTS

ACCEPTANCE PAGE.....................................................................................................................iABSTRACT....................................................................................................................................iiLIST OF FIGURES........................................................................................................................viCHAPTER 1 - INTRODUCTION...................................................................................................1

Context of the Problem................................................................................................................1Statement of the Problem.............................................................................................................2

FBI Virtual Case File...............................................................................................................2The Ariane 5 rocket (Flight 501).............................................................................................5The Federal Aviation Administration Advanced Automation System....................................5Other Software Development Failures....................................................................................5

Research Question and Subquestions..........................................................................................7Significance of the Study.............................................................................................................7Research Design and Methodology.............................................................................................8Objectives of the Study................................................................................................................8

CHAPTER 2 – LITERATURE REVIEW.......................................................................................9Software Project Challenges and Failure.....................................................................................9Reasons of Software Project Challenge or Failure....................................................................10Software Project Success...........................................................................................................10Conclusion.................................................................................................................................11

CHAPTER 3 – KNOWLEDGE AREAS OF SOFTWARE ENGINEERING..............................12Software Requirements..............................................................................................................12

Fundamentals.........................................................................................................................12Process...................................................................................................................................13Elicitation...............................................................................................................................14Analysis.................................................................................................................................14Specification..........................................................................................................................15Validation and verification....................................................................................................15

Software Design.........................................................................................................................16Software Construction...............................................................................................................17Software Testing........................................................................................................................17

Fundamentals.........................................................................................................................17Levels.....................................................................................................................................18Techniques.............................................................................................................................19


Software Maintenance...............................................................................................................20Fundamentals.........................................................................................................................20Key issues..............................................................................................................................21

Software Processes and Product Quality...................................................................................22Analysis and Findings................................................................................................................23

CHAPTER 4 – CAUSES OF CHALLENGED AND FAILED PROJECTS................................24Introduction to Challenged and Failed Projects.........................................................................24Causes of Challenged and Failed Projects.................................................................................24

Bad project planning..............................................................................................................24Vague objectives....................................................................................................................26Inadequate project requirements............................................................................................26Lack of risk management.......................................................................................................27Lack of scope management...................................................................................................27Inadequate project management methodology......................................................................28Inadequate development management methodology.............................................................28Inadequate quality management............................................................................................29Poor performance by suppliers of hardware/software...........................................................29Lack of resources...................................................................................................................29Lack of user involvement......................................................................................................30Lack of executive support......................................................................................................30Unrealistic expectations.........................................................................................................31Incorrect cost estimation........................................................................................................32Project restarts.......................................................................................................................32Technology incompetence.....................................................................................................33Insufficient senior staff on the team......................................................................................34Poor social skills....................................................................................................................34

Remedy Attempts of Challenged Projects.................................................................................34Analysis and Findings................................................................................................................35

CHAPTER 5 – PRACTICES FOR PROJECT SUCCESS............................................................37Introduction to Best Practices....................................................................................................37Best Practices.............................................................................................................................37

Stakeholder Management......................................................................................................37Proper project planning..........................................................................................................38Clear objectives.....................................................................................................................41


Clear project requirements and analysis................................................................................43Risk management...................................................................................................................43Change control.......................................................................................................................45Project management methodology........................................................................................45Development methodology....................................................................................................49Quality management..............................................................................................................49Supplier management............................................................................................................50Resource management...........................................................................................................51User involvement...................................................................................................................51Executive management support.............................................................................................52Realistic expectations............................................................................................................52Communication management................................................................................................53Competent staff......................................................................................................................53Iteration deliveries.................................................................................................................54

CHAPTER 6 – TOOLS & MODELS............................................................................................55Introduction to Tools and Models..............................................................................................55Project management software....................................................................................................55CASE tools................................................................................................................................56Diagrams and other graphical representations...........................................................................57Testing Tools.............................................................................................................................59

CHAPTER 7 – SUMMARY AND CONCLUSION.....................................................................60Summary....................................................................................................................................60Conclusion.................................................................................................................................61

REFERENCES..............................................................................................................................63APPENDIX A. REQUIREMENTS DOCUMENT.......................................................................68APPENDIX B. CHANGE REQUEST LOG.................................................................................71APPENDIX C. POSSIBLE THREATS FOR RISK MANAGEMENT........................................72


LIST OF FIGURES

Figure 1. September 11, 2001. (Photo obtained from http://delong.typepad.com/images/911.gif) 4Figure 2. Standish CHAOS Summary (by percent) (Galorath, 2008).............................................9Figure 3. Microsoft Project Sample View.....................................................................................40Figure 4. Sample Gantt Chart (Stellman & Greene, 2009)............................................................40Figure 5. Systems Development Life Cycle (SDLC) (U.S. Department of Justice, 2003)...........46Figure 6. Success Potential Chart (The Standish Group, 1994)....................................................47Figure 7. PERT Chart (Image released to public domain by: Jeremy Kemp, 2005).....................55Figure 8. Sample Gantt Chart (Stellman & Greene, 2009)............................................................56Figure 9. Class Diagram................................................................................................................57Figure 10. Data Modeling Process.................................................................................................58Figure 11. Entity Relationship Diagram........................................................................................58


SOFTWARE ENGINEERING METHODS

CHAPTER 1 - INTRODUCTION

Context of the Problem

What issues can a company face if they perform a software development project

inappropriately? If not done properly, developing a new software package can be lengthy, taking

longer than expected to reach completion. Additionally, it can result in low quality, more

expensive, and harder to maintain software. Improper design and planning could possibly lead to

disastrous results. This paper shows that by applying the proper methods and procedures to the

development process, and using the proper tools, an organization can avoid these issues and

develop a high quality, less expensive, easier to maintain software in a timely manner (Software

Engineering, 2009).

The Institute of Electrical and Electronics Engineers (IEEE) defines software engineering

as “the application of a systematic, disciplined, quantifiable approach to the development,

operation, and maintenance of software (The Joint Task Force on Computing Curricula, 2004).”

A software engineer “focuses on the computer as a problem-solving tool (Pfleeger & Atlee,

1998).” In essence, developing a software application is similar in nature to building a puzzle. If

some of the pieces are missing, you will end up with a puzzle that is incomplete and virtually

useless. However, depending on which pieces are missing, the puzzle could provide some

usefulness, and give part of the picture, but you may still be enticed to throw it away.

This paper presents acceptable software engineering methods, tools, and procedures. It also

presents the issues an organization could face if they are not used. Areas of concern included in

the study are as follows: modeling, planning and managing, securing the requirements, design,

programming, testing, delivering, maintaining, evaluating, and improvement.


Statement of the Problem

Proper software engineering methods are required for a high quality software solution. Not

using the proper methods could result in software that is low in quality, expensive, hard to

maintain, and take longer to build (Software Engineering, 2009). Most universities teach the

proper methods to their students, however many organizations do not allow their consistent use

due to time constraints and other reasons, and they pay the price for such practice.

Sometimes, an organization will see the deadline, and decide that the proper planning and

designing will take too much time they could be using for coding. Additionally, there are

programmers who feel that proper planning is unnecessary and just busy work. This is often seen

in Extreme Programming, where the programmers sometimes try to skip most processes and

jump immediately into programming. In essence, they are skipping the essential pieces that

would inevitably prevent them from back stepping and reworking.

If the organization does not perform proper planning and design, they may miss essential

pieces to the solution that could prevent disaster. If they miss enough of the solution, they may

have to scrap the entire project and start over. The worst possible outcome could be catastrophic

(Glass, 1997). Webster’s dictionary defines catastrophic as “utter failure.” While there are many

projects that have ended in failure, the following cases show just how catastrophic a failure can

be.

FBI Virtual Case File.

The Federal Bureau of Investigation needed to bring its software into the 21st century. They

needed “a networked system for tracking criminal cases that was designed to replace the

bureaus’ antiquated paper files (Eggen & Witte, 2006).”


After several years of development, and $170 million, The Federal Bureau of

Investigation’s Virtual Case File system was considered incomplete and unusable. It was deemed

a failure and ultimately sent to the grand ole project graveyard. Attributed to its failure was “poor

conception and muddled execution of the steps needed to make the system work (Eggen & Witte,

2006).” Another issue attributed to the demise of the Virtual Case File project was the open-

ended contract with SAIC, with few safeguards. SAIC knew there were issues with the project,

but failed to notify the client that the project would not work. They kept collecting payments and

forging ahead with the project.

After the terrorist attacks in September of 2001, the system became top priority. The FBI

moved up deadlines, expanded requirements, and ultimately the costs ballooned (Eggen & Witte,

2006). SAIC should have been experts in the field of software engineering, yet failed in their

responsibilities to ensure that the project was successful.

The Office of the Inspector General attributed the following reasons to the delay and costs

of the Virtual Case File system (Office of the Inspector General, 2007):

poorly defined and evolving design requirements

contracting weaknesses

IT investment management weaknesses

lack of an Enterprise Architecture

lack of management continuity and oversight

unrealistic scheduling of tasks

lack of adequate project integration, and

inadequate resolution of issues raised in reports


Now that the system was scrapped after several years and $170 million, a new system

needed to be completed. The new system, called Sentinel, was estimated to run $425 million.

Add that to the amount previously spent on the Virtual Case File system, and ultimately, you

have a system that cost the FBI nearly $600 million, not to mention delivery of a system that was

needed many, many years earlier. If the system had been in place at the time, it is thought that

the United States could have prevented the activities of September 11, 2001.

Figure 1. September 11, 2001. (Photo obtained from http://delong.typepad.com/images/911.gif)


The Ariane 5 rocket (Flight 501)

“Ariane 5 ECA is [a] version of the Ariane 5 launcher. It is designed to place payloads

weighing up to 9.6 [tons] into geostationary transfer orbit [(or low Earth orbit)] (European Space

Agency, 2006).” “On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in failure.

Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the

launcher veered off its flight path, broke up and exploded (LIONS, 1996).”

This disaster was due to an incorrect variable conversion in the software running the rocket.

Considered one of the most expensive bugs in history, the Ariane 5 prototype cost US$1 billion

to build.

The Federal Aviation Administration Advanced Automation System

Another huge failure in the history of software development was the Federal Aviation

Administration (FAA) Advanced Automation System (AAS). This project was in development

for thirteen years before it was realized to be a “train wreck.” It was a $2.6 billion disaster, of

which $1.5 billion was considered unsalvageable for future development. “At its peak, the AAS

program was costing the government $1 million a day, 2,000 IBM employees, and producing a

hundred pages of documentation per line of code.” It was considered “the greatest debacle in the

history of organized work (Rosenberg, 2008).”

Other Software Development Failures

In addition to the above-mentioned disasters, many more can be used to show how

disastrous a project can be. For example:


The California Department of Motor Vehicle system cost $45 million and was

ultimately cancelled (McManus, 1994).

The American Airlines CONFIRM Reservation System was cancelled after three

and a half years, $125 million, and the use of 500 technical personnel (Confirm

Project, 2009).

Sydney Water Corp aborted a project midway through, after spending US$32

million due to inadequate planning and specifications, which led to numerous

change requests (Charette, Why Software Fails, 2005).

Allstate planned to automate all of its office operations in a project projected that

was estimated to take five years and cost $8 million. Six years and $15 million later,

they set a new deadline and a new budget of $100 million (Glass, 1997).

Westpac Banking Corporation decided in 1988 to redefine its information systems.

The plan estimated five years and $85 million to complete the project. After 3 years

and $150 million, they cancelled the project because there was little to show for it,

and eliminated 500 development jobs (Glass, 1997).

In the mid-1990’s, Canada decided to create the Canadian Gun Registry to make

owners register their guns. The system was estimated to cost $1 million. However,

by 2004, it hovered more closely to $750 million and was not operational (Charette,

Why Software Fails, 2005).

Although not a huge disaster in terms of budget or scheduling time, there is a recent

incident worth mentioning pertaining to the U.S Department of Veterans Affairs.

Whether by human error, or coding error, (some believe it was a coding error)

thousands of veterans were sent letters indicating they had a debilitating and fatal


disease. While they did eventually send out letters apologizing for the error, many

of the rightfully concerned patients had already gone out and racked up thousands

of dollars of unnecessary medical bills to obtain second opinions (Charette,

"Coding" Error Creates Anxiety Among US Veterans, 2009).

Research Question and Subquestions

The purpose of this research is to determine the following: What can we do within the

software development process to ensure a successful delivery of software projects and to avoid

possible failure? To answer this question, this paper addresses the following subquestions:

1. What are the knowledge areas of software engineering?

2. What are causes of failures in software development projects?

3. What methods can we implement to ensure successful completion of a software

project?

4. What tools are available that will allow a project a better possibility of success?

Significance of the Study

This case is significant because it shows organizations and software engineers the

importance and proper use of methods to develop software and what can happen if they do not

make use of available tools. As discussed in the context of the problem, if an organization does

not properly plan, design, and test an application, catastrophic disasters can occur.


Research Design and Methodology

This research is a qualitative in nature case study, using literature review and personal

experience. In addition to textbooks, sources will also include newspaper articles, company

websites, government papers, and industry publications. The author currently holds a Bachelors

of Science degree in Computer Information Systems, and near completion of the Masters of

Science degree in Information Systems with an emphasis on Software Engineering Management.

Additionally, she has over eighteen years experience with software development in all phases of

the process. She has realized that learning is a never-ending process and keeps an open mind to

new technologies and methods.

Objectives of the Study

Based on the findings of this study, organizations are shown the importance of proper

procedures to create high quality, inexpensive, maintainable software in a timely manner

(Software Engineering, 2009). It also shows the consequences if proper methods are not used.

This study covers the main knowledge areas of Software Engineering (SWEBOK, 2004), the

software development process, methods and tools that can be used in the software development

process, and the consequences of omittance.


CHAPTER 2 – LITERATURE REVIEW

The secondary research will consist of textbooks, newspaper articles, company websites,

and government and industry publications. Most sources agree that software project failure is just

a part of life in the development world and we learn from our mistakes. However, there is some

disagreement among sources of the actual percentage of successes and failures. Some sources

distinguish a difference between failure and challenged projects. Failure is complete failure and

ultimate cancellation of the project. The projects that are challenged include projects that run

over budget, over schedule, and offer less features than outlined in the requirements specification

(The Standish Group, 1994).

Software Project Challenges and Failure

The Standish Group reports approximately a twenty-four percent failure rate and a forty-

four percent challenged rate. Oxford University reports ten percent for failures and seventy-four

percent for challenged projects. The article in the Communications of the ACM reported an

abandoned rate of only nine percent (Sauer, Gemino, & Reich, 2007).

1994 1996 1998 2000 2002 2004 20090

10

20

30

40

50

60

16

27 26 2834

29 32

53

33

46 49 51 5344

3140

2823

15 1824

SucceededChallengedFailed

Figure 2. Standish CHAOS Summary (by percent) (Galorath, 2008)


In addition to failures, according to information gathered by Galorath (2008), projects

averaged between forty-nine and fifty-seven percent of overrun budgets, and between thirty-three

and sixty-two percent of projects failed to meet schedules. These projects are considered in the

challenged category as set forth by The Standish Group (1994).

According to the British Computer Society, failures cost tens of billions of British Pounds

in the European Union, and according to the National Institute of Standards and Technology

(NIST), software defects cost nearly $60 billion annually (Galorath, 2008).

Reasons of Software Project Challenge or Failure

Many sources agree that software project failures have a correlation to their size. Sauer,

Gemino & Reich (2007) report that as the effort, duration, or team, increases in size, so does the

risk of underperformance. The Standish Group agrees that the longer the duration in projects the

higher the result in challenge rates (The Standish Group, 1994). While there many reasons for

project failure, there is a consensus among the sources as to the basic reasons, which are

inadequate requirement specifications, lack of communication, poor design, and unrealistic

schedules and budgets.

Software Project Success

The Standish Group reported that approximately thirty-two percent of projects are

considered successful (see Error: Reference source not found). Oxford University and the British

Computer Society estimated a sixteen percent success rate. The Standish Group (1994) firmly

believes that projects that are broken into smaller sub-projects with incremental implementations

(otherwise known as iteration development) have a higher success rate.


There was one source, Alleman (2009), that claimed he believed the Standish Report to be

naïve and flawed, and possibly only used as a marketing ploy. However, of all the sources

researched, The Standish Group appears to be the most forgiving in the calculated success rates,

as the other sources reported success rates half that of which The Standish Group reported.

Conclusion

There is no question that all sources agree there are too many software project failures.

What they differ in opinion on, is the causes of the failures and the actual percentage of failures

and what exactly constitutes a failure. What we can learn from past software project failures are

the issues that can be faced, and determine the proper strategies to ensure a better chance at

success.


CHAPTER 3 – KNOWLEDGE AREAS OF SOFTWARE ENGINEERING

According to the IEEE Computer Society, software engineering is defined as “(1) The

application of a systematic, disciplined, quantifiable approach to the development, operation, and

maintenance of software; that is, the application of engineering to software and (2) The study of

approaches as in (1) (IEEE Computer Society, 2009)."

In order to understand the processes needed to ensure a successful software development

project, it is essential to know the ordinary and typical parts and processes that make up a

development project. This chapter covers the processes, or knowledge areas, of a project from its

inception to completion. It follows the general layout of the generally accepted knowledge areas

required for most development projects as set forth by SWEBOK (2004) with additional

information not provided by SWEBOK (2004). The information within this chapter is not all-

inclusive. It is important to know that this information should be used in combination with

information from all other chapters of this paper.

Software Requirements

Software requirements are properties that must be exhibited by developed software or

adapted to solve a particular problem (SWEBOK, 2004). Software requirements should be

written by all stakeholders in a project so that everyone has a clear understanding of what it

needed, what is feasible, and what can be delivered within the constraints of the project.

Fundamentals.

Before specifying the requirements, we must be aware of, and identify, all stakeholders in a

project via stakeholder analysis. A stakeholder can be anyone inside or outside an organization


that can affect, or be affected, positively or negatively, by the project. For more information on

stakeholder analysis, refer to Chapter 5.

Requirements are either a product requirement or a process requirement. A product

requirement is a requirement within the software application. A process requirement is a

constraint on the development. The language needed to program the application is an example of

a process requirement. In addition, a requirement may be functional or non-functional.

Functional requirements are tasks (or capabilities) that the software must perform, such as

calculating payroll or printing paychecks. Non-functional requirements are constraints or quality

requirements that must be attached to the software, such as the look and feel of the application

(SWEBOK, 2004).

Requirements should be cohesive, complete, consistent, correct, current, externally

observable, feasible, unambiguous, mandatory and most importantly, verifiable. If a requirement

is not verifiable, it must be modified so that it can be verifiable. An example of an unverifiable

requirement would be if it states the requirement must always, or never, exhibit a certain

property. In this scenario, infinite testing would be required (Requirement, 2009) which is not

feasible in any application.

Process.

While the requirements are initially defined at the beginning of the project, it is a

continuous process throughout the lifecycle of the project. Once the initial requirements are

created, requirements should go through a change control process known as requirements

management or scope management to avoid a vast array of problems that may arise. For

example, requirements may be added that were not initially identified. Therefore, scope


management will allow for the analysis of such a requirement to determine its impact on the

project.

Elicitation.

Elicitation is the process of obtaining requirements from all stakeholders and other sources

in a project and requires good lines of communication. Other terms that may be used to describe

this process are "requirements capture," "requirements discovery," and "requirements acquisition

(SWEBOK, 2004)." Some people may refer to this process as “requirements gathering,”

however, this term falsely suggests that the requirements are only collected from the customer. In

fact, the requirements may come from sources such as goals (or software objectives), domain

knowledge, stakeholders, operational environment, and organizational environment.

Upon identification of all sources, elicitation may begin. Elicitation may take the forms of

interviews, conceptual modeling, prototype creation, moderated brainstorm meetings, and

observation (SWEBOK, 2004).

Analysis.

Once the requirements have been identified, requirements analysis must be performed.

Requirements analysis is the process of detecting and resolving conflicts and ensuring that

requirements are within the boundaries of the software application. Any conflicts brought to light

by this process can be remedied prior to the start of design and development.

Requirements will be classified and prioritized, and determination will be made if the

requirement is volatile or stable and to what extent the requirement affects the scope of the

project. The requirements will also be allocated to components, which will allow further analysis

to take place (SWEBOK, 2004). Additionally, conceptual modeling will aid in the discovery of

unforeseen requirements and possible conflicts in the analysis process. Conflicts may arise not


only between requirements, but between stakeholders as well. Conflict resolution can analyze the

situation and discussions can be made to determine which requirement should take priority. It is

possible that there is another way to incorporate certain conflicting requirements so that they do

not conflict with each other.

Specification.

Depending on the size of a given project, it may require one or all of a system definition

document, a system requirements specification, a software definition document, and a software

requirements specification. Projects that have a scope beyond the software may require all

documents, whereas a simple software application may only require the software requirements

specification (SWEBOK, 2004).

The software requirements specification is usually all that is needed on projects that only

require the development of a software package and not additional system requirements like you

would find for an airliner. This document will outline all the requirements and their analyses and

“provide a realistic basis for estimating product costs, risks and schedules.” It will include a set

of use cases, or functional requirements, and non-functional requirements, otherwise known as

constraints. This document will also allow an organization to “develop validation and

verification plans more productively (SWEBOK, 2004).”

Validation and verification.

The process of validating ensures that the software engineer understands the requirements

for the project and that they describe the software to be developed. Additionally, the

requirements must be verified so that they are understandable, consistent, and complete

(SWEBOK, 2004).


Validation can be performed by reviews and prototyping. Prototyping can be used to

validate the developers understanding of the requirements. If the developer is incorrect in any

assumptions, the prototype validation will provide a means of feedback to correct his

understanding.

Software Design

“If I can’t picture it, I can’t understand it.” ~ Albert Einstein

The software design process consists of the architectural and detailed designs and allows

software engineers to provide models that create a roadmap to the application development.

Models should depict structural as well as behavioral descriptions and can be function-oriented

or object-oriented in nature. Structural descriptions can be accomplished by using such tools as

class and object diagrams, component diagrams, deployment diagrams, entity-relationship

diagrams, and structure charts. Behavioral descriptions can be depicted via activity diagrams,

data flow diagrams, decision tables, flowcharts, sequence diagrams, state-chart diagrams, and

pseudocode (SWEBOK, 2004).

Architectural designs describe how software is organized into components. Detailed

designs describe the specific behavior of the components. In addition to behavior, issues that

software design must address are concurrency, event control and handling, component

distribution, error and exception handling, fault tolerance, interaction, presentation, and data

persistence. In order to maintain a good quality software design, it is important for it to be

maintainable, portable, testable, traceable, correct, and robust (SWEBOK, 2004).


Software Construction

Software construction is accomplished through a “combination of coding, verification, unit

testing, integration testing, and debugging.” The main concepts that apply to software

construction are to minimize complexity, anticipate change, construct for verification, and

maintain standards (SWEBOK, 2004). When maintaining standards, it is important to pick a set

of standards and stick to them. Do not use one set of standards for one area of the construction

and another set of standards for another area. Typical standards used are those that are put out by

IEEE, the ISO, or the Object Management Group.

Software Testing

Fundamentals.

Failures can occur because of many reasons. Requirements may have been unintentionally

omitted in the requirements document, there may be requirements that are impossible to

implement, the design could be faulty, or the coding could be wrong. The testing process allows

the team to locate faults in the system by fault identification, classify them, and correct or

remove them (Pfleeger & Atlee, 1998).

Many types of faults can occur in a software application. Possible faults that may occur and

should be tested for are: algorithmic faults, syntax faults, computation and precision faults,

documentation faults, stress or overload faults, capacity or boundary faults, timing or

coordination faults, throughput or performance faults, recover faults, hardware and software

faults, and standards and procedure faults (Pfleeger & Atlee, 1998).

When faults are found, they should be classified. Classification allows the team to identify

areas in the design or development processes that may need to be modified to prevent or reduce


faults in the future. IBM developed a classification system called orthogonal defect

classification. Within this classification process, they identify a fault as either a fault of omission

or a fault commission, and place it under the following classifications: function, interface,

checking, assignment, timing/serialization, build/package/merge, documentation, or algorithm

(Pfleeger & Atlee, 1998).

Levels.

There are typically three levels of testing, which are unit, integration, and system testing.

During unit testing, tests are done on individual software pieces, or components. Integration

testing is the tests run to verify the interaction between components. System testing is the tests

run on the system as a whole. The following are the objectives of the testing knowledge area as

per SWEBOK (2004):

Acceptance/qualification testing

Installation testing

Alpha and beta testing

Conformance/Functional/Correctness testing

Reliability achievement and evaluation

Regression testing

Performance testing

Stress testing

Back-to-back testing

Recovery testing

Configuration testing

Usability testing


Techniques.

Several testing techniques can be used to test the application. Some are based on the

software engineer’s intuition and experience such as ad-hoc and exploratory testing, and some

others are specification-based techniques such as equivalence testing, boundary-value analysis,

decision tables, finite-state machine-based testing, testing from formal specifications and random

testing (SWEBOK, 2004). In addition, there are tools available for the testing process, which are

covered in Chapter 6.

The control-based technique is another technique that includes control-flow-based criteria,

data flow-based criteria, and reference models for code-based testing. Fault-based techniques

include error guessing and mutation testing. Usage-based techniques include operational profile

and software reliability engineered testing (SWEBOK, 2004).

Finally, there are techniques based on the nature of the application such as object-oriented

testing, component-based testing, web based testing, GUI testing, testing of concurrent programs,

protocol conformance testing, testing of real-time systems, and testing of safety-critical systems

(SWEBOK, 2004).

In addition to the testing techniques, various test-related measures can be used. Program

measurements can be used to determine how many lines of code exist, and if the number of lines

coincides with, or exceeds, any code restraints placed on the application. It may be necessary to

double check the written code and see if anything can be reduced to simpler terms. Fault types,

classification and statistics can be used to determine the frequency of faults occurring in the

system and allow strategies to be designed to avoid these faults in the future.

Sometimes, based on project limitations, a client may allow a certain percentage of faults to

occur, as no software is 100% perfect. Fault density measures allow the team to count the faults


in the system so they can attempt to bring the faults below a certain level as indicated by the

client.

Software Maintenance

Upon completion of the software development project, new user requirements will surface,

operating environments will change, and defects will be discovered (SWEBOK, 2004), all of

which will require maintenance. Maintenance related activities are not unlike development

activities. The activities involved in maintenance are analyzing requirements, evaluating design,

writing and reviewing code, testing changes, and updating documentation (Pfleeger & Atlee,

1998).

Fundamentals.

The four types of maintenance are corrective maintenance, adaptive maintenance,

perfective maintenance and preventive maintenance. They can be reactive or proactive, and

geared toward corrections or enhancements (SWEBOK, 2004).

Corrective maintenance is maintenance geared toward fixing bugs and correcting defects. It

is a reactive type of maintenance meant for corrections (SWEBOK, 2004) and does not provide

new capabilities. Sometimes, the corrective maintenance may just be user interaction, such as

manually adjusting the layout for a report. The developer can then later alter the code to print the

report properly without user interaction (Pfleeger & Atlee, 1998).

Adaptive maintenance is the process of assessing environmental changes and adapting the

software with secondary changes (Pfleeger & Atlee, 1998). It is a reactive type of maintenance

geared toward making enhancements to the new environment (SWEBOK, 2004) however, it

does not incorporate new capabilities. An environmental change can be a change in the operating


system or a change in other parts of the system, such as an upgraded payroll system that is tied

into the application.

Perfective maintenance evaluates and updates the software to improve performance, make

enhancements, or provide maintainability. It is a proactive type of maintenance geared toward

making enhancements (SWEBOK, 2004) and is not a result of defects. For example, if the code

for an application is confusing, it may be rewritten so that it is easier to maintain in the future.

Preventive maintenance is the process of detecting and correcting hidden errors before they

become operational errors, improving reliability, and providing a gateway for future

development and maintainability. It is a proactive type of maintenance meant for corrective

measures (SWEBOK, 2004) before they become active defects.

Key issues.

While maintenance is a necessary process in software development, issues do arise such as

technical issues, management issues and maintenance costs. Technical issues consist of limited

understanding, testing time and cost, impact analysis, risk assessment, and maintainability

(SWEBOK, 2004). Limited understanding is a big issue if the developer was not part of the

original development process. He must first familiarize himself with the system before

attempting to make any modifications. If the modifications that are needed are code changes, the

better the code was documented, the easier it will be for him to understand.

In addition to limited understanding, testing can be another big issue. There is a calculation

based on the number of changes that need to be made that indicates the number of interfaces that

need to be tested. “If a system has m components and we need to change k of them, there are

k * (m – k) + k * (k – 1)/2

interfaces to be evaluated for impact and correctness (Gerlich & Denskat, 1994).”


Management issues that can be faced are resource use versus benefit achieved, maintaining

staffing requirements, process challenges, priorities of management personnel, and low morale.

If management feels other projects are higher priority, it will be difficult to get the resources to

perform the needed maintenance.

Maintenance cost estimations include the money spent during maintenance and lost

opportunities for new development. Many organizations use a popular cost estimation method

called COCOMO II to calculate the estimated maintenance costs.

Software Processes and Product Quality

Striving for quality is a number one skill a software engineer must possess. If any process

or product is low in quality, the entire development effort, not to mention future efforts, could be

in jeopardy. Repeat business will most likely not occur if a client receives a product that is not of

high quality within their definition. The client’s expectations of quality should be determined at

the same time the requirements are defined. This is important, as quality to a client may depend

on trade-offs that are required during the development process, and other reasons.

IEEE12207.0-96 defines some quality management processes that not only encourage

quality, but aid in finding potential problems. The processes included in this standard are as

follows: quality assurance, verification, validation, review, and audit processes (SWEBOK,

2004). When these processes are used, quality is not guaranteed, but a better quality product is

more likely.


Analysis and Findings

While it may seem that there many areas covered within each process, they are essential to

the creation of a successful development project. As discussed earlier, if any pieces to the

processes are omitted, you may end up with a development project that is riddled with defects,

and possibly lead to abandonment.


CHAPTER 4 – CAUSES OF CHALLENGED AND FAILED PROJECTS

Introduction to Challenged and Failed Projects

The term challenged can mean any number of issues, or combination of issues that indicate

a project is not a success. Issues that can classify a project as challenged can include going over

budget, exceeding the set time schedule, missing functionality or features, missing requirements,

bug filled releases, and more. A project failure is one in which aborting the project is the only

feasible option.

Causes of Challenged and Failed Projects

While there are many causes for challenged or failed software development projects, the

actual challenge or failure can be attributed to one, or many, of those causes. As you will see,

many times, one cause leads to another. Many of the causes covered in this section are widely

used in publications pertaining to project failure. Other causes that are covered here are not as

widely covered, but are important nonetheless. The following sub-sections detail each cause.

Bad project planning.

“Because if you have a strong foundation like we have, then you can build or rebuild

anything on it. But if you've got a weak foundation you can't build anything”

~ Jack Scalia

As the quote describes, you must have a good foundation for any project. You cannot build

a bridge without a solid foundation, or it will most definitely fall to pieces. Building a software


application follows the same theory. The project plan is the foundation from which the

development team will build. If the foundation is bad, so will be the project, and it could very

well collapse. Bad project planning means the planning and scheduling of the project are not

accurate, therefore resulting in incorrect timetables, resource allotments and cost allocations.

Bad planning includes everything from not planning at all, to not planning enough, to not

updating the plan once it is in place. Many times, bad planning is a result of inexperienced

personnel creating the plans, such as customers, marketing personnel, or sales people. Issues

typically overlooked are activities that may seem insignificant, such as file setups, test data

setups, and more, but when you accumulate enough of those “insignificant” issues, you end up

spending valuable time on issues you thought you would be using on another task.

Not planning for possible risks can be another issue related to bad planning. Planners do

not always plan for possible risks that may be associated to the project or the personnel

developing the project. For example, if an employee suddenly fell ill or quit, and that issue is not

accounted for during risk management, and hence the planning, you could find yourself behind

schedule (McConnell, 2001).

In addition to inadequate planning, a plan may not be accurate due to inadequate

requirement specifications. If the requirement specifications are missing key pieces to the

project, it will not be accounted for in the project plan or the design, and hence the development.

Another issue that an organization can face when planning is reusing previous plans or

using prepackaged plans. The current project can easily have issues that are not covered in the

reused or prepackaged plan (McConnell, 2001).


Project managers must also keep the plans up to date. If a plan is not updated frequently,

activities can be omitted and milestones missed. If the project is going over budget or getting

behind, you may not find out until it is too late to compensate and remedy the situation.

Vague objectives.

Objectives state what is needed, what the ultimate goal of the project will be, and why it is

needed. If the objectives are vague, requirements will not be properly defined, and the system

may end up inadequate. With vague objectives, the development team will not know why the

project is being done, or what it is meant to do. Because of this, many assumptions may be made

during the requirement specification stage, and they might not match what the client initially

wanted done, or there will be constant discussions for clarifications. Lack of clear objectives will

usually result in development rework, low morale, schedule extensions and additional costs.

Inadequate project requirements.

Inadequate, ambiguous, and constantly changing project requirements can severely derail a

software development project (The Standish Group, 1994). Inadequate requirements can result

from confusion over what constitutes a requirement, poor customer involvement, and

inexperience. Once the requirements specification has been completed, more requirements can

be added, causing what is known as scope creep. If the additional requirements are allowed to be

added without scope management process in place, scope creep can occur and cause a project to

get uncontrollable and lead to possible disaster (Satzinger, Jackson, & Burd, 2007).


Lack of risk management.

Risk management is the process of identifying risks, assessing them, and taking steps to

reduce them to an acceptable level (Stoneburner, Goguen, & Feringa, 2002). Risk management is

an essential part of the software development project. It allows the team to determine the

probability and impact of any risks that could affect the project. If risk management is not

incorporated into the project, problems can occur and cause severe setbacks to the project and

substantial unforeseen costs could be added to the project.

The risks that can affect the project are not only risks that can occur during the project such

as the illness of a developer, but also the risks that can occur after delivery, such as software

hackers and data loss. The former risks can add time and cost to the project, whereas the latter

risks can cause damage to the delivered product, damage to the organization using the

application, and additional costs to repair.

Lack of scope management.

Just as the lack of risk management can affect a project, so can the lack of scope

management. Scope management is similar in nature to risk management, but deals directly with

issues that occur during a software development project as opposed to actual risks. If issues are

not managed, the potential could be unexpected extended schedule time and increased costs.

Scope management is put into place to reduce scope creep as discussed earlier. Issues that

may arise during a project, typically originate from the customer. “A simple attribute addition

can affect the database, input forms, output forms, control algorithms, update algorithms, system

testing plans and tests, data conversions, system interfaces, and system and user documentation

(Satzinger, Jackson, & Burd, 2007).”


In addition, without scope management, additions to the project may occur as requests from

end-users that are not approved by the sponsor. This may lead to trouble, as the sponsor may not

have included the addition in the project requirements for a specific reason.

Inadequate project management methodology.

Project management methodology is the process, or framework, put into place to guide the

project in an organized manner. It is a set of guidelines or principles to keep the project on track.

It can consist of an approach, forms, templates, and checklists among other things (Charvat,

2003).

A project without a project management methodology, or an inadequate one, put into place

will ultimately result in an unorganized development project. Projects need structure and

guidance, and without that structure and guidance, milestones can be missed, costs can become

unmanageable, and the project can fail. Additionally, there can be inadequate communications

between team members, and the wasting of time on purposeless tasks. The project management

methodology must also be good for the project. It is possible to choose the wrong methodology

for the project, hence resulting in possible disaster.

Inadequate development management methodology.

Not having an adequate development management methodology is nearly as bad as not

having a project management methodology. Typically, in large companies, a project manager

may manage several projects at once. To help in this endeavor, there should be in a development

management methodology as well. Without a development management methodology, there


could be “serious shortfalls in the overall management, administration, execution,

standardization, and reporting of projects (Rittinghouse, 2004).”

Inadequate quality management.

Quality can have different meanings to different people. A development team might qualify

quality as having no bugs, whereas a client might qualify quality as having an application that

meets their needs. The client may accept a few bugs here and there and still consider it high

quality, but if it does not meet their needs, then to them, it is not of high quality. The project

manager must be able to communicate with the client to find out exactly how they define quality.

If they do not, the quality assurance team may pass an application as bug-free, but of low quality

to the client.

Poor performance by suppliers of hardware/software.

In order to get a project delivered on time, any hardware or software that is purchased from

another vendor must be delivered on time, and work as expected. If it is not delivered on time,

obviously, delays to the project may occur. If the product does not perform as expected,

scheduling extensions may be made to make the products work together. If scheduling delays

occur, there could be added costs to the project, not to mention the additional unexpected work

that is needed to be done to get the products to work together.

Lack of resources.

A project must have all the available resources at the proper times. If a resource is not

available or assigned to another task, not only will the scheduling be in jeopardy (The Standish


Group, 1994), but customer confidence can also be lost. You should never have to explain to a

customer that a task is not completed at the proper time because you did not have the resource to

do it. Resource allocation should be addressed by making use of resource management and

should be addressed at the beginning of the project to allow time to make sure that the resources

are available when needed.

Lack of user involvement.

User involvement is essential to the success of a project. Without user involvement, or

insufficient user involvement, the development team is left to do the users responsibilities

themselves. Users typically give input on the requirements they need, input on the functions

required, and input on the design, design test cases, provide test data, and analyze test results

(Hoffman, 2002). If the development team is required to complete the user's portion of the

project, not only is it possible that the system will not be delivered as the users expect, but may

not function as they expect as well. Another possibility is that the schedule could be extended

since the development team is typically resourced to do other tasks while the users perform these

tasks. If the schedule is extended, the costs are increased. If the development team is creating the

test data, the results could be completely opposite from what the users would expect because the

development team does not know, first hand, how the business is run (Hoffman, 2002).

Lack of executive support.

Executive support is an essential part of developing a new software project. Without

executive support, it gets extremely difficult to get the resources the team needs to complete a

project. Additionally, resources that the project already has, could possibly be taken away


periodically to work on other things that the executives believe are more important. These issues

can cause delays to the project, and possibly additional costs due to the delays.

Unrealistic expectations.

Many times, clients do not have the technological competence to know how long it will

take to develop a project. They may have a preconceived idea of how long they believe the

project, or certain parts of the project should take. It is up to the project manager and

development team to make sure the client completely understands the scope of the project and

what is involved to make the project come to life. If the team does not convey this information to

the client and make them understand, the client may be disappointed.

The client may push to have certain milestones completed by certain dates. If those dates

are unreasonable, the development team will be stressed to meet deadlines, and that could be

disastrous to the project. When a team is pushed to unreasonable deadlines, they may drop

features, skip steps, and ultimately deliver a project that is unsatisfactory, if even usable, to the

client.

Another example of unrealistic expectations can come into play if the sales person sells

features that are obviously not included in the software. The client may be expecting to see a

feature in the application that was never meant to be there. The developers are then scrambling to

implement features they had no idea they were to be developing.

Unrealistic expectations also come into play when the development team tries to please all

the users, all the time. The following quote sums it up:


“You can please some of the people all the time, and all the people

some of the time, but you can’t please all the people all the time”

~ John Lydgate

Incorrect cost estimation.

When estimating costs, it is necessary to account for as much of the expenses associated

with the project as possible. Many times, organizations fail to incorporate costs such as software

licenses, equipment and other purchases needed for development of the application. Additional

unforeseen costs can be incurred due to other issues if not accounted for during risk management

such as, extending the schedule, hiring additional personnel, and more. This is also "one of the

major factors in the breakdown of relationships between IT people and their clients (DeWeaver

& Gillespie, 1997)."

Project restarts.

According to a study done by The Standish Group (2004), restarting a project is one of the

major causes of both scheduling and cost extensions. “For every 100 projects that start, there are

94 restarts. This does not mean that 94 of 100 will have one restart, some projects can have

several restarts (The Standish Group, 1994).”

Restarting a software development project is sometimes the best solution to a project that

has gone off-track. If a project has gone off-track, development could continue, but result in a

project that fails to meet the requirements of the client. Another option would be to cancel the

project. The obvious result of restarting a project is the extension in the schedule, and ultimately

additional costs. The later the restart is done, the longer the extension, and the higher the costs.


Another type of restart can occur when a project is stopped for some reason, and restarted

in the future from the stopping point. Some reasons for this type of restart may be lack of

funding, change in leadership at the client location, or any of a number of other reasons. The

problem with this type of restart is that the personnel working on the project must re-familiarize

themselves with the project and try to get back on track.

Technology incompetence.

Technology incompetence can cause problems when developing a software application.

Sometimes, this means the developers are using a new technology that they have not had much

experience using. It could also mean that a developer is inexperienced and somewhat new to

developing applications. This results in a learning curve being added to the project, hence

extending schedule time.

If a developer is technologically inexperienced, it means that he has not learned what

works, what does not work, and how to deal with issues that occur in a timely manner. An

inexperienced developer may write too much code, hence increasing time needed to accomplish

that task. They may not account for potential errors, therefore causing more bugs and errors in

the product than would have been there if an experienced programmer had done the coding. If

these issues are caught by the quality assurance team, the application goes back to the developer

to be fixed. If the quality assurance team does not catch the issues, the application could be

delivered with bugs and errors. Either way, the application must be corrected, hence adding time

to the schedule.

Technology incompetence is not limited to the developers of a software project. If the

project manager is not familiar with the technology being used, they may not properly schedule


the time needed to develop the project. If the sales person is not familiar with the technology,

they may promise a product that cannot be delivered, or a product that will essentially not meet

the needs of the client.

Insufficient senior staff on the team.

Having insufficient, or inexperienced, senior staff on the team can cause turmoil in the

development process. With little or no prior experience, it is difficult to know what can go wrong

during a project, and may not have the social skills needed to manage a project. The result could

be changes in project leadership, possible project staff turnover, scheduling extensions, and

increased costs.

Poor social skills.

Social skills are a necessity to work in teams. Rarely is a software development project

initiated, designed, planned, developed and used by only one person. Typically, there are many

people involved including executives, users, project management, developers, testers, quality

assurance personnel, and more. When working with this many people, social skills are a

necessity. Without good social skills, disagreements ensue, arguments flourish, teamwork falls

apart, communication is difficult, and the project could possibly suffer a fatality.

Remedy Attempts of Challenged Projects.

Now that you have a clear understanding of the issues that can be faced when creating a

software development project, let us look at the remedies often used when those issues arise

(Glass, 1997).


Schedule extensions

Reduction in scope of project

Work overtime

Add development staff

Reduce quality (less testing, etc)

Implementation of better management procedures

Change in project manager or team

More funds

Pressure on suppliers by withholding payment

Better development methodologies

Pressure on suppliers by threat of litigation

Change of technology used on the project

Restarting the project

Abandoning the project

Analysis and Findings

When creating a software development project, causality plays a huge role throughout the

project. Causality is the relation between a cause and its effect. In the case of creating a software

development project, the effect of one cause is typically another cause that will have its own

effect that will be the cause to yet another effect.

For example, if the requirements specification is supposed to have fifteen functions, but

only accounts for ten, the plan will only allot time and resource allocation for the ten functions.

When the design is completed for the ten specified functions, the development and testing will


include those ten functions. If, at that point, it is discovered that five functions were inadvertently

left out, they will need to be added to the requirements specification, the plan and the design. The

developers will then need to not only add in the new functions, but also ensure that they work

with the functions already created and retest the entire system. As you can see, by omitting a few

functions at the beginning of the project, a substantial amount of time has been added since

someone will be required to take the time to add the functions to the documentation, the plan and

the design. Once those are complete, the developers have to stop what they are doing and go

back and add the functions to the application. Then, they need to retest the entire system to make

sure the new additions work as intended.


CHAPTER 5 – PRACTICES FOR PROJECT SUCCESS

Introduction to Best Practices

Having a successful project can be a pipe dream. In order to ensure a successful project,

there are practices that should be consistently maintained. If done properly, successful project

completion is no longer a dream, but a reality.

Best Practices

Stakeholder Management.

Indentifying the stakeholders of a project should be the first task completed. “A stakeholder

is anyone who has a vested interest in the project, can be affected by the change initiative that the

project represents, or has the power to influence the project.” Chellar (2009) explains, “Failure to

understand the stakeholders can kill a project.” Possible stakeholders for a project may include

organization owners or partners, department heads, managers, staff, regulatory bodies, suppliers,

customers, or competitors (Chellar, 2009).

Stakeholder analysis identifies the stakeholders of the project, the importance of each, and

what possible role they may play in the project. Since stakeholders can have a negative as well as

a positive effect on the project, the analysis can be used to develop strategies to get effective

support and reduce obstacles (Management Sciences for Health and the United Nations

Children's Fund).

It is important to realize the negative stakeholders as well as the positive, because they can

create obstacles to the project. For example, the project could possibly create an automated way

of doing something that will inevitably lead to corporate downsizing. Those individuals that

would be losing their jobs will surely cause obstacles to prevent the application from being


successful. The analysis will allow you to identify those obstacles ahead of time, and prepare a

strategy in which to deal with them.

Proper project planning.

Planning the project can make or break the whole project. According to Brown’s (2008)

first law of IT physics, “planning is a continuous process, not a one-time event.” A manager

cannot simply create the plan and walk away expecting it to go as planned without changes. If

the plan is not consistently maintained, milestones will be missed, deliveries will be delayed, and

costs could escalate out of control. Project planning encompasses almost all other practices that

should ensure a successful project. In addition to the scheduling, planning includes resource

planning, communication planning, and risk management.

In order to start a plan, objectives, stakeholders (defined earlier), and deliverables must be

identified. This portion can be completed via the objectives and requirements documents. Once

these items have been identified and analyzed, the project schedule can be initiated. The

requirements document will allow the manager to see what tasks need to be done, and schedule

them. Project scheduling not only gives the team a roadmap in which to follow, but it should also

provide a layout of the tasks that need to be completed, the resources required to complete the

tasks, the amount of effort to complete the tasks, and costs associated with each task. For the

purpose of this document, we will focus on the scheduling in this section, as other information is

covered under the appropriate area elsewhere in this chapter.

In the beginning, the schedule will be a high-level overview of the project tasks to be

completed. Without detailed requirements, it is difficult, if not impossible, to create a detailed

schedule. Once the requirements have been defined and analyzed, a work breakdown structure


(WBS) must be completed. The planner will use the tasks from the WBS, assign resources

(which may be people, items, tools or services), define critical paths, and more, to create the

detailed schedule.

In order to create the schedule, dependencies must also be taken into consideration. A

dependency occurs when one task is dependent on another task before it can start or finish. There

can be four types of dependencies including finish to start, start-to-start, start to finish, and

finish-to-finish (Stellman & Greene, 2009). Finish to start is a type of dependency where the

finish of one task is required before the next task can begin. An example of finish to start is the

start of application development is dependent on the finish of the design. The development

cannot be started until there is a design in place from which to work. Start to start is a type of

dependency where the start of one task is required before the start of another task can occur. Start

to finish requires a task to start before another task can finish. Finally, finish to finish is a

dependency where the completion of one task is required to complete another task.

Once the WBS has been completed, resources assigned and dependencies accounted for,

the schedule can be created and costs assigned. There are many popular applications that can be

used for project scheduling, which are covered more in detail in Chapter 6. Popular applications

will allow outputs such as task lists, cost reports, budget reports, resource reports, Gantt charts

and more. The following illustration shows what Microsoft Project 2007 looks like in the typical

task view. This illustration shows a Work Breakdown Structure (WBS) on the left and a Gantt

chart on the right.


Figure 3. Microsoft Project Sample View.

The following illustration shows a sample Gantt chart.

Figure 4. Sample Gantt Chart (Stellman & Greene, 2009).

“Each task is represented by a bar, and the dependencies between tasks are represented by

arrows. Each arrow points to either the start or the end of the task, depending on the type of

predecessor. The black diamond between tasks D and E is a milestone, or a task with no


duration. Milestones are used to show important events in the schedule. The black bar above

tasks D and E is a summary task, which shows that these tasks are two subtasks of the same

parent task. Summary tasks can contain other summary tasks as subtasks (Stellman & Greene,

2009).”

In addition to scheduling, project-planning software can also assist in completing cost

estimations. Applications such as Microsoft Project allow you to assign salary information to

people resources and per task costs to tasks. The application will then allow you to generate cost

and budget related reports.

Clear objectives.

Objectives are part of Scope Management and clear objectives are important to a project.

They are brief statements, written in business terms to describe what the project will accomplish.

A good way to set objectives is by using the SMART principle, which states that objectives

should be Specific, Measurable, Achievable, Realistic, and Time-bound. Webster (1999) gives

the following outline as a guide to the questions that should be answered:

Why? (Background)

Why does the organization need this project?

What is the business case?

What is the background and history that got you where you are now?

What triggered the project at this time?

What is the problem/opportunity being addressed?

Are there any other related projects running?

What? (Scope)


How does the organization want to go about it?

What is this project to do, and what are the options?

What is it not to do?

What changes are expected as a result of this project?

What return on investment is the organization looking for and how will it be

measured?

What will the success of this project look like?

What other options were considered?

What factors of prime importance in reaching this plan of action?

What are the deliverables and expectations?

How (Project Objectives)

How should it be approached?

What objectives should be set?

What measurable outcomes are foreseen?

What will the tangible results be?

When is it wanted by?

What resources are there?

What is the budget?

What authority do you have?

What are the boundaries and priorities?

Who? (The People)

Who are the stakeholders and how do you keep them happy?

What would those involved like to see happen?


What are the political dimensions?

Who is in support?

Is there anyone against this project succeeding?

Where do you need to tread carefully?

Has this project been tried before and if so, what was the outcome?

Are there any no-go areas?

Clear project requirements and analysis.

In addition to objectives (defined above), requirements are also a part of Scope

Management. Where objectives are brief statement of overall project needs, the requirements are

detailed specifications that tell what the new software application will contain. The requirements

must be clear and complete. Please refer to APPENDIX A for a sample template of a

requirements document. Take note that the requirements document (or software requirement

specification) may take many formats, and the attached appendix is only an example.

Once the requirements document has been completed, a requirement analysis should be

done to ensure that the requirements stated are clear, complete, explicit, and non-conflicting. If

this step is not done, there could be conflict and confusion later in the project.

Risk management.

Risk management is of utmost importance to any project. In risk management, all possible

risks are identified and documented prior to the start of the project, but should be done during

every phase of the project. Risks can be anything that could cause a negative impact to a project.

The process of risk management is to identify the possible risks, analyze them, plan a strategy to


take, and track, control, and communicate them to the proper personnel (Higuera, 1996). The

main concept behind risk management is prevention and correction.

Risks can originate from many sources. They may originate within the application itself,

the development team, the customer or their business practices, and even from outside sources

such as the government. If, for example, you are developing an accounting module for an

application, one of the possible risks that could affect the application would be if the government

is planning to increase taxes. Another possible risk that a project could face would be if one of

the developers suddenly fell ill and was unavailable as a resource.

The first step in identifying possible risks is to identify possible sources of risks. Common

sources can be natural threats such as floods, earthquakes and hurricanes. A second common

type of threat can be human threats such as unintentional data entry, network attacks, malicious

software upload and unauthorized access to confidential information. The third common type of

threat could be environmental such as electrical outages or pollution (Stoneburner, Goguen, &

Feringa, 2002). Refer to Appendix C for a table of possible types of threats.

Once possible threats have been indentified, they should be analyzed not only for

possibility (high/medium/low), but also for impact. Impact could be as simple as bad data, or as

important as lost revenue, system repair, human injury or damage to an organization’s credibility

(Stoneburner, Goguen, & Feringa, 2002). As in an earlier example, if a developer should fall ill,

the impact on the project will be loss of a resource and possible schedule extension. Another

issue may allow outsiders to access confidential information. Yet another issue may be as simple

as an end user entering incorrect data such as a wrong state abbreviation like XX.

After the possible threats have been analyzed, strategies must be put into place to ensure

the threats are avoided or corrected. Strategies must take into consideration cost to benefit. If the


cost outweighs the benefit, the strategy may be to allow the possible risk. In the event of

incorrect data entry, validation may be put into place that will only allow correct entry, within

reason. For example, while entering a state abbreviation, the application can be set up to allow

the user only to select from a list of acceptable states. In the event a developer should fall ill,

there can be a backup plan to replace the developer with other personnel if he will be unavailable

to the point where the schedule is severely affected.

Change control.

Just as objectives and requirements are part of Scope Management, so is change control.

Change control is extremely important. If it is not implemented, scope creep may occur and the

project could get uncontrollable. Any time a change is requested, no matter how small, it should

be logged. A decision then needs to be made on the priority of the change (high/medium/low)

and what impact the change will have on the project. Is the change something that can easily be

added to a section that has not yet been developed? What impact will the change have on other

parts of the application? How will the change affect the workload, schedule, resources or budget

(Satzinger, Jackson, & Burd, 2007)? Is it possible that the change could be saved and added after

delivery as part of a value added upgrade?

Please refer to Appendix B for a sample of a Change Request Log. This is only a sample,

and may take many forms.

Project management methodology.

"A methodology is a set of guidelines or principles that can be tailored and applied to a

specific situation (Charvat, 2003)." The methodology, or framework, is everything that should be


done over the lifespan of the project, including steps, procedures, templates, documents,

checklists, and more. Some types of formal methodologies that can be adopted are the traditional

approach, Critical Chain Project Management (CCPM), Rational Unified Process (RUP),

Extreme Project Management, Event Chain Methodology, Agile Project Management, System

Development Life Cycle (SDLC), and PRINCE2. The following figure shows a typical SDLC

life cycle, however remember that planning should be revisited often and updated, not just once

as it appears in the life cycle.

Figure 5. Systems Development Life Cycle (SDLC) (U.S. Department of Justice, 2003)

As part of project management, the manager can assess the potential success of the project,

and implement strategies to ensure a successful project. The Standish Group (1994) created a

weighted “success potential” chart that can be used to predict the potential for success of a

project. What they have done is taken criteria that have shown success in projects and assigned

point values based on importance. If a project has the criteria, the points are assigned. If the


project does not have the criteria, it gets zero points for that category. There is the potential of

100 points total and the higher the points a project has, the more the success rate. Areas within

the success criteria are covered in other sections of this chapter.

Success Criteria Points DMV CONFIRM HYATT ITAMARATI User Involvement 19 NO (0) NO (0) YES (19) YES (19) Executive Management Support 16 NO (0) YES (16) YES (16) YES (16) Clear Statement of Requirements 15 NO (0) NO (0) YES (15) NO (0) Proper Planning 11 NO (0) NO (0) YES (11) YES (11) Realistic Expectations 10 YES (10) YES (10) YES (10) YES (10) Smaller Project Milestones 9 NO (0) NO (0) YES (9) YES (9) Competent Staff 8 NO (0) NO (0) YES (8) YES (8) Ownership 6 NO (0) NO (0) YES (6) YES (6) Clear Vision and Objectives 3 NO (0) NO (0) YES (3) YES (3) Hard-working, Focused Staff 3 NO (0) YES (3) YES (3) YES (3) TOTAL 100 10 29 100 85

Figure 6. Success Potential Chart (The Standish Group, 1994).

As you can see, the more points assigned to a project, the better the potential. The

California DMV project that was identified in Chapter 1 as a disaster that was cancelled only had

10 points. The Hyatt project (The Standish Group, 1994) was considered a success, and as you

can see, had 100 points. The American Airlines CONFIRM project (another covered in Chapter

1 as a failure) with only 29 points, was also cancelled. Banco Itamarati, with a point value of 85,

was a successful project and along with other strategic maneuvers allowed them to move from

47th to 15th place in the Brazilian banking industry (The Standish Group, 1994).

In addition to predicting success in a project, the project manager can also estimate project

performance. Earned Value Analysis (EVA) measures the project performance in terms of scope,

time and cost. Before you can make this measurement, Makar (2009) shows there three questions

to be answered:

How much work did you plan to complete to this point in time (Planned Value or

PV)?

How much work was actually completed to date (Earned Value or EV)?


How much did it cost to complete the work so far (Actual Cost or AC)?

For this sample, we will assume the project being worked on is as follows:

One year project budgeted at $120,000

Reporting period at 9 months

Team has completed 50% of the project (should have completed 75%)

Spent $108,000 to date

PV = (Planned % Complete) * (Project Budget) = .75 * $120,000 = $90,000

EV = (Actual % Complete) * (Project Budget) = .50 * $120,000 = $60,000

AC = $108,000

The cost and schedule variances are now calculated using the above calculations:

Cost Variance (CV) = EV – AC = $60,000 - $108,000 = -$48,000

Schedule Variance (SV) = EV – PV = $60,000 - $90,000 = -$30,000

Since both of these numbers are negative, we can know that we are currently running over

budget and behind schedule. Now, we can use these calculations to find the cost performance

index (CPI) and the schedule performance index (SPI). If those calculations are less than one, the

project is behind schedule, equal to or more than one, the project is on or ahead of schedule.

CPI = EV / AC = $60,000 / $108,000 = .56

SPI = EV / PV = $60,000 / $90,000 = .67

Now that we have these numbers, and we know that the project is behind schedule, we can

find out approximately how much it will cost to complete the project with a schedule extension

by dividing the original budgeted amount by the cost performance index (CPI):

EAC = BAC / CPI = $120,000 / .56 = $214,285.71


As you can see from these calculations, at the current rate, we are completing the project,

and the current costs, we will end up going over our $120,000 budget by approximately $94,285.

With this in mind, we can then make a decision how to proceed. We can either cut back on scope

or extend the schedule and accept the budget overrun.

Development methodology.

A software development methodology is a framework that is used to structure, plan, and

control the process of developing an information system (Centers for Medicare and Medicaid

Services, 2008). There are several types of development methodologies, many of which

crossover and combine with each other. A few can also be considered both development and

project management methodologies, such as System Development Life Cycle (SDLC).

Examples of development methodologies include Waterfall, Incremental, Spiral, Rapid

Application Development (RAD), Agile Software Development, Dynamic Systems Development

Model (DSDM), Extreme Programming (XP), Feature Driven Development (FDD), Joint

Application Development (JAD), and Lean Development (LD).

Quality management.

“The main objective of Quality Management is to produce a system that is easy to use, fit

for its intended purpose, robust, reliable, and maintainable (Satzinger, Jackson, & Burd, 2007).”

Quality control should be performed during all milestones and delivery points of the project. The

system must be developed to the purpose as set forth by the client. It should also be easy to

understand and learn. Strong help systems should be available within the application and

documentation should be available to the end user. Tasks should be easy and efficient to


perform, so the least amount of steps needed to perform a certain task should be taken into

consideration. A user should not have to click through fifteen totally unrelated screens to

perform a typical everyday task (Satzinger, Jackson, & Burd, 2007).

Quality management is made of three components, which are control, assurance and

improvement. Control ensures products meet the customer’s requirements. Assurance ensures

that standards of quality are met by monitoring and evaluation. Improvement is the processes put

into place in order to strive to improve from lessons learned. One way improvement can be

achieved is by monitoring via assurance. Logs are made and when low quality issues begin to

repeat themselves, a strategy is put into place to avoid those issues in the future.

For example, if a problem in the Graphical User Interface (GUI) layout is repetitive, the

designer can be approached and steps taken to ensure that problem stops appearing. It could be

as simple as the designer is unaware of the problem, or that he is aware but does not bother to fix

it for whatever reason. Then the problem will be monitored in the future, and if it is found that

the designer continues to ignore the problem, he can be dealt with by management. If the

problems are severe enough, it may even be time to replace that designer. Quality up front is

better than quality after rework, because it simply saves time.

Supplier management.

Supplier management is important because suppliers must supply their product on time. If

suppliers deliver beyond the intended delivery date, it can extend the project scheduling efforts.

While there are times when this can be accepted as an exception to the rule, it cannot be a

continuous occurrence. One remedy for consistently late deliveries is to change suppliers.


Depending on the item being purchased, this may not be an option. There are times when other

remedies such as litigation may be the only option.

Resource management.

Managing resources is an important activity during a project. If a resource is not going to

be available during a project or any portion thereof, alternate strategies must be made to ensure

the project does not run over schedule. If the manager is using an application such as Microsoft

Project, resources can be managed and tracked within the software.

Risk management is also related to resource management. Back to our example of a

developer falling ill, risk management would have identified that as a possible risk, and the

manager should have a backup plan in place. The backup plan could be that the project proceeds

in other areas awaiting the developers return, or maybe another resource is used in his place.

User involvement.

Projects require user involvement. There is really no way around this. Users must be able to

lead in the requirements specifications. They are the ones who know what they need and how the

business runs. The project team can guide the users, but they do not know the details of the

clients business. Users must also lead in the functional requirements of the system. Again, the

project team can guide them, but the project team does not know details about the clients

business.

Partial user involvement is necessary in the technical design of the system as well. What

the project team believes to be a nice design may not be appealing to the user at all. Finally, the

users must design the test cases to be used to test the system. While the project team can easily


come up with their test cases, they do not know the clients business, and therefore may miss

something of great importance to the client (Hoffman, 2002).

Executive management support.

Support from executive management is a necessity. Without it, many times, a project will

fail. Say, for example, you need to requisition a new resource because one of your developers

was just called to active duty in the military. Without executive support, you may not get the new

person for months, and the schedule could suffer terribly because of it. Maybe you need to

purchase something for the project and executive management needs to approve it. If you cannot

make the purchase, will the project continue? Will it need to be stopped and sent to the great

project graveyard in the sky?

Realistic expectations.

Many users are not technologically competent enough to know what can and cannot be

achieved with an application, or the extent of the costs for some wanted features. It is the project

team’s responsibility to keep the users informed of the limitations considering the available time,

technology, and budget. They may not ask for something that they believe is too difficult to

accomplish, but in reality is quite simple. On the other hand, they may ask for something that

they believe is easy, but in reality is very difficult and may extend the schedule another year

which they have no intention of doing. The project team can explain the difficulty involved if the

users ask for something that is not covered in the current state of time and budget criteria.


Communication management.

Everyone knows, or should know, that communication is the key to success. Whether it is

personal, business, or other relationships, without communication, systems can break down.

Consider a project as a relationship with your clients, coworkers, and managers. Everyone must

be able to communicate to get the job done.

If there is a communications process in use, everyone will be familiar with it, and

communication will be made much easier. Maybe the organization requires the channel of

communication to go through certain people and managers in a certain order. Maybe one person

on the team is expecting another person to make a communication that is not in his duties and

therefore the issue is never communicated to anyone.

Perhaps part of the communications management process is to have a fifteen-minute daily

meeting for quick status updates, or an end of the week meeting to see what was accomplished

that week, and what will be accomplished the next week. However the project team deals with

communication, it should be consistent, and it should work. If it does not work, the team needs to

figure out why and made adjustments so that it does work.

Competent staff.

Without competent staff, a project can easily fail. If the manager does not manage the

project, how will anyone know where he or she is in the project, if it is on schedule, if it is

meeting requirements, and if it is within budget? Likewise, without a competent developer, how

do we know the development process is being done properly before the quality control people

check the work?


A project simply needs competent personnel in order to attain success. Everyone needs to

do their job to the best of their ability, and corrected if it is found they are not.

Iteration deliveries.

Delivering a project in iterations is good practice. If the project has one huge delivery at the

end, possible problems may surface that can cause a lot of rework to be done. It is possible that

the project does not meet the user’s needs as they expected. If the project is delivered in

iterations, the users can be checking a small portion of the application while developers are still

working on another section. If issues arise, corrections can be made much sooner, and possibly

avoid a severe extension to the schedule and increased costs.


CHAPTER 6 – TOOLS & MODELS

Introduction to Tools and Models

Many tools can be used to manage, design, and test a project. Some tools go so far as

automatically generating code for the application. Many organizations find that by using

available tools, development time can be cut down dramatically.

Project management software

Project management software can not only allow a project manager to set up a project

schedule, but also assign resources, predecessors, constraints, percent complete, start and end

dates, and more. The output can be very helpful when communicating to the client, other team

members or upper management. Output from project management software can typically include

PERT charts, Gantt charts, resource charts, baseline reports, budget reports, resource reports,

cash flow reports, and more.

Project Evaluation and Review Technique (PERT) is a project management model. The

lines are typically activities to be performed, and the nodes are milestones (Internet Center for

Management and Business Administration, Inc., 2007). The following illustration shows a PERT

chart:

Figure 7. PERT Chart (Image released to public domain by: Jeremy Kemp, 2005)


Gantt charts are visual representations of a project schedule and its work breakdown

structure. The following illustration shows the Gantt chart that was introduced in the proper

project planning section of Chapter 5:

Figure 8. Sample Gantt Chart (Stellman & Greene, 2009).

CASE tools

A CASE tool is “a computer-aided system engineering tool designed to help a systems

analyst complete development tasks (Satzinger, Jackson, & Burd, 2007).” There are several types

of CASE tools available such as UML Modeling, Microsoft Visio (not technically a CASE tool,

but can be used as one), Visible Analyst, Embarcadero Describe, and a line of Rational software.

CASE tools can be considered upper CASE or lower CASE, and are used to support design,

debugging, development, testing, maintenance, and implementation activities, among others.


Diagrams and other graphical representations

There are other common graphical representations used to show how a system should

operate. These other representations are flowcharts, data flow diagrams, entity-relationship

diagrams, structure charts, use case diagrams, class diagrams, and sequence diagrams.

CatalogSeasonYearDescriptionEffectiveDateEndDate

PackagePackage IDDescriptionSalesPrice

Inventory ItemInventory IDSizeColorOptionsQuantityOnHandAveragecostReorderQuantity

Product ItemProduct IDVendorGenderDescriptionSeasonNormalPriceSpecialPrice

ShipperShiper IDNameAddressContactNameTelephone

Return ItemQuantityPriceReasonConditionDisposal

Order ItemQuantityPriceBackorderStatus

ShipmentTracking No.DateSentTimeSentShippingCostDateArrivedTimeArrived

CustomerAccount No.NameBillingAddressShippingAddressDayPhoneNightPhone

OrderOrder IDOrderDatePriorityCodeShipping&HandlingTaxGrandTotal

Order TransactionDateTransactionTypeAmountPaymentMethod

Web OrderEmailAddressReplyMethod

Telephone OrderPhoneClerkCallStartTimeLengthOfCall

Mail OrderDateReceivedProcessorClerk

1..* 0..*

1..*

0..1

0..*

0..*

0..*

0..*

0..*

0..*1

1

1

1

1

1..*

1

1

0..*

1..*

1..*

1..*

1

Figure 9. Class Diagram


Figure 10. Data Modeling Process

Figure 11. Entity Relationship Diagram


Testing Tools

When the testing process is being performed on the application, there are tools that can be

used to aid in the process. Static and dynamic code analysis tools are tools available to report

information pertaining to the written code. When the programming is executing, dynamic

analysis is done, and static analysis is done when it is not executing. Examples of tools available

for static analysis include code analyzers, structure testers, data analyzers, and sequence

checkers. An example of a dynamic tool is a program monitor that reports the applications

behavior (Pfleeger & Atlee, 1998).

In addition to the tools available for testing the actual written code, tools are available for

the planning and running of the tests such as capture and replay (or capture and playback) tools,

stubs and drivers, automated testing environments, and structured test case generators (Pfleeger

& Atlee, 1998).


CHAPTER 7 – SUMMARY AND CONCLUSION

Summary

Surveys show that software development failures occur too often. Based on findings of the

surveys, we can see the issues that can ultimately cause such failures. Most of these causes can

be directly attributed to certain knowledge areas of software engineering. If we make ourselves

experts in those knowledge areas, we can better manage, plan, design, develop, test and maintain

our projects. We can also see, from the evidence given, that by not using methods and processes

for one knowledge area carries defects or issues into other knowledge areas.

Once initiation of the project begins, a plan is created for the project. The requirements are

then completed, which leads into the design. Upon completion of the design, the development

begins. After the application has been developed, it is then tested, implemented and maintained.

At each stage of this process, the plan is consistently updated and maintained in order to keep the

development effort on track. If planning is not done, or done inadequately, the whole project

could be inaccurately estimated in terms of time, cost, and resource allocation and the team will

be unable to detect late or missed milestones.

Other issues that can be attributed to challenged and failed projects include: vague

objectives, inadequate requirements, lack of risk and scope management, inadequate project or

development management, inadequate quality management, poor performance by suppliers, lack

of resources or user involvement, lack of executive support, unrealistic expectations, incorrect

cost estimation, technology incompetence, insufficient staff, and poor social skills.

On the other hand, if the opposite of the above is present in the development process, there

is a better chance at success. Better planning leads to better time and cost estimation. Better

requirement specifications lead to more complete and correct design and development. Better


development leads to a better overall project. If the client is happy with the delivered product,

they will return for future efforts.

Conclusion

“Mistakes are a part of being human. Appreciate your mistakes for what

they are: precious life lessons that can only be learned the hard way.

Unless it's a fatal mistake, which, at least, others can learn from.”

~ Al Franken

Regardless of which studies you look at, the percentage of software development failures

and challenges are too high. The purpose of this research project was to determine the activities

we can do to ensure a successful delivery of software development projects and avoid failure.

To be successful, we must know the knowledge areas of software engineering. We must

know the causes of past failures to avoid future failures. We must be familiar with the proper

processes, methods, and tools of the various knowledge areas. We can learn from the mistakes

we have made, or the mistakes of others.

Too many organizations bypass important processes and procedures because they think

they will save time. In the end, they do not save time. They do however, go over budget, over

time, and end up with a low quality product, if the project even makes it to completion. They can

end up reworking parts of the application because they did not take the time up front to ensure

the requirements are as complete and correct as possible. They may not have taken the time to

design the system properly. Any time a developer needs to go back and rewrite code, it must be

retested and documented, and needs to go back through quality control. Additionally, if the


developer does not properly document the code as he is writing it, it will be nearly impossible to

maintain in the future.

If we are to raise the success rate of software projects, we must be sure that all curriculums

teach the necessary fundamentals of the knowledge areas. Additionally, organizations must be

more proactive and ensure their teams are knowledgeable in software engineering and proven

methods. If they are not adequately knowledgeable, it is worth the expense to ensure they are

properly taught.

The time added to a project by following all proper processes may be irritating or

cumbersome to some, but is a necessity in order to complete a successful software development

project.


REFERENCES

Alleman, G. B. (2009, April 29). Standish Report and Naive Statistics. Retrieved July 25, 2009, from Herding Cats: http://herdingcats.typepad.com/my_weblog/2009/04/standish-report-and-poor-statistics.html

Baltzan, P., & Phillips, A. (2009). Business Driven Information Systems (2nd ed.). The McGraw-Hill Companies, Inc.

Brenner, R. (2001, April 25). Restarting Projects. Point Lookout , 1 (17) . Chaco Canyon Consulting.

Brown, N. V. (2008). 11 "Laws of IT Physics". Off-Line and Off-Budget: The Dismal State of Federal Information Technology Planning (pp. 8-9). http://hsgac.senate.gov/public/_files/BrownTestimony.pdf.

Burd, S. D. (2006). Systems Architecture. Boston, Massachusetts: Thomson.

Carnegie Mellon. (2009). Software Engineering Institute. Retrieved July 11, 2009, from Software Engineering Institute: http://www.sei.cmu.edu/

CBC News. (2004, February 13). Gun registry cost soars to $2 billion. Retrieved July 30, 2009, from CBC News Canada: http://www.cbc.ca/canada/story/2004/02/13/gunregistry_rdi040213.html

Centers for Medicare and Medicaid Services. (2008, March 27). Selecting a Development Approach. Retrieved August 10, 2009, from U.S. Department of Health and Human Services: http://www.cms.hhs.gov/SystemLifecycleFramework/Downloads/SelectingDevelopmentApproach.pdf

Charette, R. (2009, August 26). "Coding" Error Creates Anxiety Among US Veterans. Retrieved August 26, 2009, from IEEE Spectrum: Risk Factor: http://spectrum.ieee.org/blog/computing/it/riskfactor/coding-error-creates-anxiety-among-us-veterans

Charette, R. (2005, September). Why Software Fails. Retrieved July 30, 2009, from IEEE: Spectrum: http://www.spectrum.ieee.org/computing/software/why-software-fails

Charvat, J. (2003). Project Management Methodologies. Hoboken, NJ: John Wiley & Sons, Inc.

Chellar, D. (2009, June 25). Who Are Your Stakeholders? Retrieved September 4, 2009, from The Project Management Hut: http://www.pmhut.com/who-are-your-stakeholders

Confirm Project. (2009, July 12). Retrieved July 12, 2009, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Confirm_Project&oldid=301706064


DeWeaver, M. F., & Gillespie, L. C. (1997). Real-world Project Management: New Approaches for Adapting to Change and Uncertainty. New York, NY: Quality Resources.

Eggen, D., & Witte, G. (2006, August 18). The FBI's Upgrade That Wasn't: $170 Million Bought an Unusable Computer System. The Washington Post , p. A01.

Erdil, K., Finn, E., Keating, K., Meattle, J., Park, S., & Yoon, D. (2003). Software Maintenance As Part of The Software Life Cycle. Tufts University. Department of Computer Science.

European Space Agency. (2006, March 12). First Ariane launch of 2006. Retrieved August 10, 2009, from ESA News: http://www.esa.int/esaCP/SEMAJ8MVGJE_index_0.html

Galorath, D. (2008, June 7). Software Project Failure Costs Billions. Retrieved July 25, 2009, from SEER: http://www.galorath.com/wp/software-project-failure-costs-billions-better-estimation-planning-can-help.php

Gerlich, R., & Denskat, U. (1994). A Cost Estimation Model for Maintenance and High Reuse. Proceedings, ESCOM 1994. Ivrea, Italy.

Glass, R. L. (1997). Software Runaways: Monumental Software Disasters. Prentice Hall.

Haughey, D. (2008). Project Planning: A Step by Step Guide. Retrieved August 10, 2009, from Project Smart: http://www.projectsmart.co.uk/project-planning-step-by-step.html

Higuera, R. P. (1996). Software Risk Management. Pittsburgh, PA: Carnegie Mellon University.

Hoffman, G. (2002, August 8). Why IT Projects Fail: Lack of User Involvement. Retrieved August 10, 2009, from Montana Associated Technology Roundtables: http://www.matr.net/article-4206.html

IEEE Computer Society. (2009, July 11). IEEE: The world's leading professional association. Retrieved July 11, 2009, from IEEE: The world's leading professional association: http://www.ieee.org/portal/site

IEEE-CS/ACM Joint Task Force. (1999, October). Engineering Code of Ethics. Computer Society Connection , 84-88.

Internet Center for Management and Business Administration, Inc. (2007). PERT. Retrieved August 15, 2009, from NetMBA: http://www.netmba.com/operations/project/pert/

Johnson, J., Boucher, K. D., Connors, K., & Robinson, J. (2001, February). Collaboration: Development & Management (Collaborating on Project Success). Retrieved July 20, 2009, from SoftwareMAG.com - The IT Software Journal: http://www.softwaremag.com/archive/2001feb/collaborativemgt.html

Leveson, N. G. (2004). Role of Software in Spacecraft Accidents. Journal of Spacecraft and Rockets 4 .


LIONS, P. J. (1996, July 19). ARIANE 5 - Flight 501 Failure - Report by the Inquiry Board. Retrieved July 25, 2009, from Massachusetts Institute of Technology (MIT): http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

Long, L. N. (2008, January). The Critical Need for Software Engineering Education. Retrieved July 11, 2009, from Software Technology Support Center: http://www.stsc.hill.af.mil/Crosstalk/2008/01/0801Long.html

Lowry, G. (2009, June 2). ASP.net Forums: Community. Retrieved July 11, 2009, from Microsoft ASP.net: http://forums.asp.net/p/1429826/3201693.aspx

Lynch, J. (2009, April 23). CHAOS Summary 2009. Retrieved July 20, 2009, from The Standish Group International: http://www1.standishgroup.com/newsroom/chaos_2009.php

Makar, A. (2009, July 22). Earned Value Management Tutorial. Retrieved August 10, 2009, from Tactical Project Management: http://www.tacticalprojectmanagement.com/earned-value-management-tips/who-is-afraid-of-eva.html

Management Sciences for Health and the United Nations Children's Fund. (n.d.). Stakeholder Analysis. Retrieved September 4, 2009, from The Guide to Managing for Quality: http://erc.msh.org/quality/ittools/itstkan.cfm

McConnell, S. (2001, September). The Nine Deadly Sins of Project Planning. Retrieved August 12, 2009, from Construx.com: http://www.construx.com/Page.aspx?hid=1190

McManus, J. (1994). Risk Management in Software Development Projects. Burlington, Massachusetts: Butterworth-Heinemann.

Office of the Inspector General. (2007, August). Sentinel Audit III: Status of the Federal Bureau of Investigation’s Case Management System. Retrieved July 25, 2009, from United States Department of Justice: http://www.usdoj.gov/oig/reports/FBI/a0740/intro.htm

Office of the Inspector General. (2005, February). The Federal Bureau of Investigation's Management of the Trilogy Information Technology Modernization Project. Retrieved July 25, 2009, from United States Department of Justice: http://www.usdoj.gov/oig/reports/FBI/a0507/findings.htm

Parikh, G., & Zvegintzov, N. (1983). Tutorial on Software Maintenance. Silver Spring, MD: IEEE Computer Society Press.

Pfleeger, S. L., & Atlee, J. M. (1998). Software Engineering. Upper Saddle River, New Jersey: Pearson Education, Inc.

Project Shrink Publishing. (2007, August 25). Software Requirements Management. Retrieved August 10, 2009, from Software Projects: http://www.softwareprojects.org/software-requirement-management-01.htm


Qassim, A. A. (2008, June 10). Why Information Systems Projects Fail: Guidelines for Successful Projects. Retrieved July 25, 2009, from INTOSAI Working Group on IT Audit: http://www.intosaiitaudit.org/intoit_articles/26_p12top17.pdf

quality assurance. (2009). Retrieved August 20, 2009, from Merriam-Webster Online Dictionary: http://www.merriam-webster.com/dictionary/quality assurance

Requirement. (2009, August 19). Retrieved August 24, 2009, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Requirement&oldid=308942062

Rittinghouse, J. W. (2004). Managing Software Deliverables. Burlington, MA: Digital Press.

Rosenberg, S. (2008). Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software. New York: Three Rivers Press.

Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2007). Systems Analysis and Design in a Changing World (4th ed.). Boston, Massachusetts: Thomson.

Sauer, C., Gemino, A., & Reich, B. H. (2007, November). The impact of size and volatility on IT project performance. 50 (11), pp. 79-84.

Simon, P. (2009, June 5). Why New Systems Fail - Theory and Practice Collide. Retrieved July 25, 2009, from Phil Simon Systems - Optimizing Enterprise Systems: http://www.philsimonsystems.com/sitebuildercontent/sitebuilderfiles/chapter1.pdf

Software Engineering. (2009, July 6). Retrieved July 11, 2009, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Software_engineering&oldid=300600273

Sommerville, I. (2007). Software Engineering (8th ed.). London: Pearson Education Limited.

Stellman, A., & Greene, J. (2009, August 14). Software Project Planning Practices: Project Schedule. Retrieved August 15, 2009, from Applied Software Project Management: http://www.stellman-greene.com/aspm/content/view/18/38/

Stoneburner, G., Goguen, A., & Feringa, A. (2002). Risk Management Guide for Information Technology Systems. Gaithersburg, MD: National Institute of Standards and Technology.

SWEBOK. (2004). Guide to the Software Engineering Body of Knowledge. (A. Abran, J. W. Moore, P. Bourque, & R. Dupuis, Eds.) Los Alamitos, California: The Institute of Electrical and Electronics Engineers, Inc.

The Joint Task Force on Computing Curricula. (2004, August 23). Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering . IEEE Computer Society.

The Standish Group. (1994). The Chaos Report. Retrieved July 20, 2009, from The Standish Group International: http://www.standishgroup.com/sample_research/chaos_1994_1.php


U.S. Department of Justice. (2003). Information Resources Management. Washington, DC: Department of Justice.

U.S. House of Representatives. (2001). Proc. of the Aviation Subcommittee Meeting. Washington, DC.

Webster, G. (1999). Managing Projects At Work. Brookfield, VT: Gower Publishing Limited.


APPENDIX A. REQUIREMENTS DOCUMENT

Project Name: Requirements Document (version 1.0)

Project:Date(s):Prepared by:

Document status: __ Draft __ Proposed __ Validated __ Approved

1. IntroductionThis document contains the system requirements for project name. These requirements have been derived from several sources, including brief listing of most important sources.

1.1 Purpose of This DocumentThis document is intended to guide development of project name. It will go through several stages during the course of the project:

1. Draft: The first version, or draft version, is compiled after requirements have been discovered, recorded, classified, and prioritized.

2. Proposed: The draft document is then proposed as a potential requirements specification for the project. The proposed document should be reviewed by several parties, who may comment on any requirements and any priorities, either to agree, to disagree, or to identify missing requirements. Readers include end-users, developers, project managers, and any other stakeholders. The document may be amended and re-proposed several times before moving to the next stage.

3. Validated: Once the various stakeholders have agreed to the requirements in the document, it is considered validated.

4. Approved: The validated document is accepted by representatives of each party of stakeholders as an appropriate statement of requirements for the project. The developers then use the requirements document as a guide to implementation and to check the progress of the project as it develops.

1.2 How to Use This DocumentWe expect that this document will be used by people with different skill sets. This section explains which parts of this document should be reviewed by various types of readers.

Types of ReaderIn this section, list the different types of reader this document is aimed at. For example, Flash programmers, graphic designers, end-users, project managers, etc. For each type of reader, clearly state which sections are most pertinent to them, and which may be safely skipped.

Technical Background RequiredDescribe here the technical background needed to understand the document in general, and any particular expertise or understanding that is needed for specific sections.

Overview SectionsList here the sections that should be read by someone who only wishes to gain an overall understanding of the project, or which should be read first before technical requirements are reviewed.

Reader-Specific SectionsIn this section, name any parts of the document which are intended only for one or another of the reader types identified above, and which may therefore be skipped by other readers.


Section Order DependenciesIf readers will need to read certain sections in a specific order, note those sections here. Also, point out any sections that may be read independently with no loss of understanding.

1.3 Scope of the ProductInclude a brief narrative here that describes the product as you intend it to be realized. Use this section to define boundaries and set expectations.

1.4 Business Case for the ProductWhy is this product required? How will it contribute to the goals of your institution? This section can be used when requirements are being negotiated, to assess whether a particular change is a good idea. This section also helps readers understand why certain requirements have been included. 1.5 Overview of the Requirements DocumentIf your project is small to medium in size, include a summary of the requirements here. This may be a numbered list of the most important requirements. The purpose of this section is to give the reader a general understanding of the requirements and focus attention on the most critical ones. This section may also help point readers to the specific requirements that are of particular interest to them.

2. General DescriptionThis section will give the reader an overview of the project, including why it was conceived, what it will do when complete, and the types of people we expect will use it. We also list constraints that were faced during development and assumptions we made about how we would proceed.

This section contains a nontechnical description of the project, usually in narrative form, which may serve to acquaint new readers with the purpose of the project. It also sets the stage for the specific requirement listing which follows.

2.1 Product PerspectiveWhy have you chosen to develop this product? What need does it serve? Who are the primary stakeholders, who is developing the project, and who will benefit from the finished product?

2.2 Product FunctionsWhat does your product do? What activities can users perform while using it? List the main functions that you will build into your product here.

2.3 User CharacteristicsWho do you expect to use your finished product, and why? What is their technical background, their training or education, their motivation to use it? What obstacles might they encounter, and what specialized skills will they need?

2.4 General ConstraintsDid you work under any constraints such as platform or development environment? Did you have to make your product compatible with any existing software or other products currently in use?

2.5 Assumptions and DependenciesIn this section, list any assumptions you made about your project (for example, did you assume that the finished product would need to be delivered over the internet?). If your project depends on any particular technical infrastructure, or requires administrators or others with specific skills, note that here.

3. Specific Requirements This section of the document lists specific requirements for name of project. Requirements are divided into the following sections:


1. User requirements. These are requirements written from the point of view of end users, usually expressed in narrative form.

2. Reporting requirements.3. System and Integration requirements. These are detailed specifications describing the functions

the system must be capable of doing.4. Security Requirements5. User Interface requirements. These are requirements about the user interface, which may be

expressed as a list, as a narrative, or as images of screen mock-ups.

3.1 User RequirementsList user requirements here.

3.2 Reporting RequirementsList reporting requirements here.

3.3 System and Integration RequirementsList detailed system requirements here. If your system is large, you may wish to break this into several subsections. Include dependencies on existing systems.

3.4 Security Requirements

3.5 User Interface RequirementsList interface requirements here; or include screen mockups. If you use mockups, be sure to explain major features or functions with narrative to avoid confusion or omission of desired features.

4. High-Level Technology Architecture(e.g. web-based, Unix, etc.)

5. Customer SupportHow will it be supported internally?

6. AppendicesIf you wish to append any documents, do so here. You may wish to include some or all of the following:

Personas and scenarios developed for this project Transcripts of user interviews, observations, or focus groups Copies of communications which contain user requirements Original project proposals or other historical documents Lists of similar projects or products, with notes about how they differ from yours A list of requirements which were "wish-listed" or marked unfeasible at present Original screen mockups, if they are relevant

7. GlossaryInclude a glossary of definitions, acronyms, and abbreviations that might be unfamiliar to some readers, especially technical terms that may not be understood by end-users or domain-specific terms that might not be familiar to developers.

8. ReferencesList references and source documents, if any, in this section.

9. IndexIf your document is very large, consider compiling an index to help readers find specific items.


APPENDIX B. CHANGE REQUEST LOG

(Client Name)(Project Name)

Change Request Log

REQ #

CHANGEDESCRIPTION

PRIORITY (H/M/L)

DATE REPORTED

REQUESTEDBY

DATE RESOLVED STATUS RESOLUTION/COMMENTS


APPENDIX C. POSSIBLE THREATS FOR RISK MANAGEMENT

Threat Source Motivation Threat ActionsHacker, cracker Challenge

EgoRebellion

HackingSocial engineeringSystem intrusion, break-insUnauthorized system access

Computer Criminal Destruction of informationIllegal information disclosureMonetary gainUnauthorized data alteration

Computer crime (e.g., cyber stalking)Fraudulent act (e.g., replay, impersonation, interception)Information briberySpoofingSystem intrusion

Terrorist BlackmailDestructionExploitationRevenge

Bomb/TerrorismInformation warfareSystem attack (e.g., distributed denial of service)System penetrationSystem tampering

Industrial Espionage Competitive advantageEconomic espionage

Economic exploitationInformation theftIntrusion on personal privacySocial engineeringSystem penetrationUnauthorized system access(access to classified, proprietary, and/or technology-related information)

Insiders (poorly trained, disgruntled, malicious, negligent, dishonest, or terminated employees)

CuriosityEgoIntelligenceMonetary gainRevengeUnintentional errors and omissions (e.g. data entry error, programming error)

Assault on an employeeBlackmailBrowsing of proprietary informationComputer abuseFraud and theftInformation briberyInput of falsified, corrupted dataInterceptionMalicious code (e.g., virus, logic bomb, Trojan horse)Sale of personal informationSystem bugsSystem intrusionSystem sabotageUnauthorized system access

Carol Harstad Thesis - Directed Research Project

Education

Transcript of Carol Harstad Thesis - Directed Research Project