Project Life Cycle Requirements

Software projects do not happen all at once. They progress through a sequence of phases that together constitute the project life cycle. Each phase has a defined purpose, a specific set of activities, and a set of deliverables that feed into the next phase. Understanding this structure is fundamental to managing software development effectively — and to understanding where OOP analysis and design skills fit within the larger process.

This course is part of the Object-Oriented Analysis and Design Fundamentals Series. The series is primarily concerned with defining what users expect from the system and then designing a software solution that fulfills those expectations. This module introduces the project life cycle as the framework within which that work occurs.

In OOP software development, the project life cycle consists of seven phases. While generic software development methodologies use terms like Initiation, Planning, Design, Implementation, and Deployment, this course uses OOP-specific terminology that maps more precisely to the activities involved:

1. Project Initiation — The project begins by identifying the need for a new software product or a modification to an existing one. The goals and objectives of the project are defined. User expectations, high-level requirements, and stakeholder needs are established. A preliminary feasibility assessment is conducted. This phase corresponds to what generic methodologies call Initiation and Planning combined.
2. Problem Analysis — The problem domain is analyzed in depth. The resources of the problem domain are identified and defined — each with a purpose and an interface. This is the phase where the team figures out what the business needs, independent of any implementation decisions. Use cases and logical models are the primary tools.
3. Architectural Analysis — The overall system architecture is established. Non-functional requirements such as response time, data distribution, scalability, and security are evaluated. The architectural choices made here define the constraints within which object design and construction must operate.
4. Object Design — The internal implementation of each problem domain resource is defined. Software-specific classes are added to support the use of domain resources — controllers, user interfaces, and data accessors. The model is refined iteratively through repeated passes comparing analysis and design work products.
5. Construction — The software is built according to the object design. This phase corresponds to what generic methodologies call Implementation or Development. Coding, unit testing, integration, and regular reviews are the primary activities. Vendor class libraries are evaluated and selected during this phase.
6. Installation — The completed software is deployed to the production environment. User training is conducted during this phase. Deployment may be phased or full rollout depending on the project's deployment model.
7. Maintenance — After installation, the software enters maintenance, which continues for as long as the software is in use. This involves ongoing support, defect correction, updates, and performance monitoring. It is also the phase where the software's lifecycle may end if the system becomes obsolete or is replaced.

Each phase is an essential part of the lifecycle. Together they ensure the project is systematically managed from the initial idea through to the operational stage, increasing the likelihood of success and reducing risk at each step.

This module describes the individual phases making up the project life cycle for developing software using an object-oriented approach. The first course in the Object-Oriented Analysis and Design Fundamentals Series is primarily concerned with defining the users' expectations for the system — which is the work of the Project Initiation phase.

A basic understanding of how the entire software development process fits together is valuable. Without this context, it is easy to apply the right technique at the wrong phase, or to skip a phase entirely in the belief that it is optional. Each phase exists because the work it produces is required input for the phases that follow.

The software industry does not have a single standardized development process. Different methodologies have grown out of different types of problems and industries, each exhibiting the unique characteristics of the domain it was designed to serve. Software development methodologies typically focus on one of three domains:

1. Standard business systems
2. Real-time or embedded systems
3. Internal or system software

Because each domain has fundamentally different constraints — a payroll system has very different reliability and timing requirements from a pacemaker firmware or an operating system kernel — no single methodology serves all of them equally well. This is why so many methodologies exist and why experienced developers must understand the underlying principles rather than memorizing the rules of any one process.

Since the original development of structured OOP methodologies, iterative and agile approaches have become dominant for business application development. Scrum, Kanban, and Extreme Programming emerged from the recognition that sequential phase completion is rarely achievable in practice — requirements change, architectural assumptions prove wrong, and design reveals gaps in the analysis. Modern OOP projects typically cycle through analysis, design, and construction multiple times, refining the model at each pass. The seven phases described in this course remain valid in iterative contexts — they describe what work must be done, not necessarily the order in which it must be completed in a single pass.

Given the diversity of software development methodologies, this course focuses on the processes and techniques common to most of them. The fundamental methods and tools of OOP software development are consistent across current development processes regardless of the methodology adopted:

• Use cases for capturing user expectations and system requirements
• Interaction diagrams (sequence and communication diagrams) for modeling object collaboration
• Class diagrams for defining the structure of the software model
• UML 2.x as the standard visual language for expressing all of these models

Learning these fundamental methods and tools provides the skills to incorporate and customize a methodology that best meets the needs of your development environment. Because these techniques transfer across methodologies, they remain applicable whether your team follows a structured phase-based process or an iterative agile approach.

In this module, you will learn about:

1. The components of a software development methodology
2. The phases making up the project life cycle for developing OOP software
3. The scope of each project life-cycle phase
4. How UML 2.x fits into the OOP software development process