CSC2407 Introduction To Software Engineering Semester 2

CSC2407 Introduction to Software Engineering Semester 2, 2014 Assignment

Find an example of a significant software project failure. Assume “significant” means greater than $30 million US/Australian dollars or equivalent. Describe the project and its failure circumstances in your own words, citing your sources, with a length between 200 and 500 words. Identify two major reasons why the project failed, each in a short paragraph or sentence.

Describe the waterfall model in your own words, including each phase in two to four sentences. Consider a scenario where requirements are finalized but change during design. Explain the problem with the waterfall model in this situation and suggest modifications to handle such changes. Discuss the advantages of the waterfall model and when it is appropriate. Also, summarize the benefits of incremental delivery with an example where waterfall might be inappropriate.

Using the provided task list with durations and dependencies, create necessary diagrams and answer questions related to project scheduling without using management software: draw an activity network, produce a Gantt chart showing earliest start and finish times, identify the critical path and its length, analyze potential delays for non-critical tasks, allocate tasks to four engineers for shortest project duration explaining why an 8-week completion is impossible, and reassign tasks allowing for parallel work with at least two engineers per task, aiming to complete the project as early as possible.

Paper For Above instruction

The challenge of managing complex software projects is exemplified by numerous high-profile failures that have cost organizations millions of dollars and led to significant repercussions. One notable example is the US Federal Aviation Administration's (FAA) Communications and Navigation System (CNS)/Air Traffic Control System Command Center, which faced a significant failure illustrating the pitfalls in large-scale software development. This project, initiated in the late 1980s and operationally critical, suffered from scope creep, poor risk management, and inadequate testing, culminating in a costly and delayed deployment that required substantial rework (Federal Aviation Administration, 1990). The failure was primarily due to a lack of clear communication between stakeholders and development teams, and inadequate adaptation to changing requirements during implementation. These issues led to system deficiencies that compromised air traffic control operations, costing over $1 billion, well beyond initial estimates. The case underscores the importance of disciplined project management, thorough testing, and flexible development models capable of accommodating requirement changes.

Two major reasons contributed to this project's failure. First, poor requirement management and stakeholder communication resulted in unclear specifications that evolved during the project, highlighting the inadequacy of traditional linear models for such dynamic environments. Second, insufficient testing and quality assurance procedures allowed systemic issues to persist into deployment, ultimately affecting safety-critical operations. Both reasons reflect a lack of adaptive planning and risk mitigation strategies essential in complex software systems.

The waterfall model is a linear, sequential approach to software development that divides the process into distinct phases: requirement analysis, system design, implementation, testing, deployment, and maintenance. Each phase must be completed before the next begins, establishing clear milestones and deliverables, which facilitates management and documentation. However, in scenarios where requirements change during development, this model can become problematic due to its rigidity.

In situations where finalized requirements are later found to be incorrect during the design phase, the waterfall model's inflexibility creates significant problems. It presupposes that all requirements are known and static from the outset, making late changes costly and difficult to implement. To address this, the model should be adapted by introducing iterative feedback loops, allowing for reassessment and revision of requirements at each stage, thereby enhancing adaptability and reducing rework.

The advantages of the waterfall model include its straightforward structure, ease of management, and suitability for projects with well-understood, stable requirements. It provides clear documentation and defined milestones, which simplify tracking progress. An example where it is appropriate is in developing avionics systems, where safety standards demand thorough verification and validation at each stage, and requirements are unlikely to change mid-project.

Incremental delivery offers important benefits, notably allowing parts of the system to be delivered and evaluated early, reducing risks, and accommodating changing requirements gradually. This approach enables feedback incorporation and facilitates more flexible project management. However, the waterfall model assumes that all components can be fully defined upfront, which makes it unsuitable for projects where evolving needs are anticipated or requirements are not fully understood from the beginning.

In project scheduling, the tasks outlined include various dependencies and durations. An activity network illustrates the tasks’ sequence, illustrating start and finish points marked as pseudo-activities. Constructing this network helps visualize dependencies, identify critical paths, and calculate earliest start and finish times. For example, tasks like T1, T2, T3, etc., depend on preceding tasks, requiring meticulous planning to ensure the project’s timely completion.

Using the task durations and dependencies, a Gantt chart can be drawn showing when each task begins and ends based on earliest start times. This visual tool aids in identifying the critical path—the sequence of tasks with zero slack time—which determines the project's minimum duration. For instance, tasks T1, T2, T3, T8, T12 (as an example), may form the critical path, with a total length equating to the sum of their durations, indicating where delays would directly impact the end date.

Allocating tasks to four engineers for a shortest possible timeframe demonstrates the importance of parallel work and resource management. If all tasks are worked on sequentially, the total project duration equals the sum of all task durations. But with multiple engineers and overlapping tasks, the project can be completed faster. Nonetheless, practical constraints such as task dependencies and resource limitations prevent completing all tasks in the minimal theoretical timeframe (8 weeks). The effort distribution and overlapping cannot reduce durations below certain limits set by dependencies and the need for sequential completion of some tasks.

Allowing tasks of length two weeks or longer to be worked on concurrently by two or more engineers further accelerates progress. This parallel effort requires strategic assignment to optimize resource use while respecting dependencies. The goal is to minimize the total project duration by maximizng concurrency. The resulting staff allocation plan would show overlapping assignments and parallel task execution, leading to a potentially earlier completion date, although complete elimination of duration overlaps is not feasible due to fixed dependencies.

References

• Federal Aviation Administration. (1990). Report on CNS/ATM System Failures. FAA Technical Report.
• Sommerville, I. (2011). Software Engineering (9th ed.). Addison-Wesley.