Introduction

• A Staged Model for the Software Life Cycle by Václav T. Rajlich and Keith H. Bennett

Key Concepts in Software Lifecycle

• Software goes through various developmental and operational phases, akin to life stages in humans.
• These stages correspond to different levels of maturity: young, mature, and senior.
• The stages also represent different operational states: healthy vs. unhealthy.
• Focus should be placed on the software's lifecycle stage rather than its chronological age.
• An iterative development approach can be adapted to each stage, but the objectives and methodologies may differ.

Waterfall Lifecycle "Stages"

1. Requirements
2. Analysis
3. Design
4. Implementation
5. Validation
6. Release
7. Maintenance
8. Retirement

Limitations of the Waterfall View

1. Requirements
2. Analysis
3. Design
4. Implementation
5. Validation
6. Release
7. Maintenance
8. Retirement

• Waterfall sees software activities as a linear process.
• This model doesn't seamlessly integrate with iterative and agile methodologies.
• Waterfall Life Stages do not fit into iterative development

Staged Software Lifecycle Model (Rajlich, Bennett 2000)

• Initial Development: Delivery of the first operational version.
• Evolution: Expansion of features and capabilities, potentially with significant changes.
• Servicing: Bug fixes and minor functional adjustments.
• Phaseout: No further updates; software still in use.
• Closedown: Software is completely retired.

Stage: Initial Development

New software is developed to meet initial requirements.

• This stage is time-bound and includes:
  • Requirements
  • Design
  • Implementation
• Foundational elements determined:
  • Technologies: Choice of programming languages, libraries, APIs, etc.
  • Architecture: Components, interactions, deployment type (cloud-based, desktop, etc.)
  • Domain Expertise: Knowledge crucial for future evolutions.

Stage: Evolution

Adapt the application to the ever-changing user and operating environment

• Add new features
• Correct mistakes and misunderstandings
• Iterative changes, modifications, and deletions
• Respond to knowledge gained (learning) by developers and users, the result of the learning process. Features may change 30% or more from learning during an iteration.
• Program typically grows in size and functionality
• Release often depends on business issues, alpha, beta, and is vague
• Evolution is possible due to software architecture and knowledge of the software team

Stage: Servicing

Program no longer evolves

• When software is aging, decayed, or legacy
• Program no longer evolves - it decays, stabilizes, or management decision not to support evolution
• Large difference between evolution and servicing (Y2K example)
• Changes are limited to patches and wrappers - low cost but cause further deterioration
• Very different process from Evolution
  • No need for senior engineers
  • Process is stable and can be easily measured and managed

Stage: Phaseout

No more evolution, servicing, or changes

• System may still be in production. Used, but not encouraged.
• Users must work around deficiencies

Stage: Closedown

Software is disconnected from users

• Current life of successful software: 10 - 20 years (?)
• Users are directed to a replacement
• "Exit Strategy" is needed
• Changing to another system requires training
• Data may need to be archived for legal and business reasons
• Data may need to be migrated

Characteristics: Expertise

Initial Development
Evolution
Servicing
Phaseout
Closedown

• Critical during initial development and evolution
• Requires broad knowledge and expertise to evolve the software
• Evolution expertise ≥ Initial development expertise
• Less important during servicing, even less during phaseout, and may return to some importance in closedown

Characteristic: Architecture

Initial Development
Evolution
Servicing
Phaseout
Closedown

• Initial architecture during initial development
• Re-architecting during evolution is almost always necessary
• During servicing, architecture gets more and more behind needed changes

Characteristic: Software Decay

Initial Development
Evolution
Servicing
Phaseout
Closedown

• Architecture degrades -> greater need of expertise (experts required)
• However, experts tend to leave during this time and are replaced with less experienced personnel
• Less expertise -> more degradation
• Reengineering attempts to reverse decay but is very difficult
• Wrapping is often the solution until a new system can be built

Characteristic: Economics

Initial Development
Evolution
Servicing
Phaseout
Closedown

• Initial development - little return, time to market of utmost importance (evolution, not as necessary)
• Evolution - making money, and resources to make changes
• Servicing - revenues fall, key team players move on. It can be outsourced. Legacy.

Scenario

Initial Development
Evolution
Servicing
Phaseout
Closedown

• Initial development is waterfall based, non-iterative
• Cannot support evolution
• Project moves into servicing
• The only solution is moving into phaseout but start a new initial development

Scenario

Initial Development
Evolution
Servicing
Phaseout
Closedown

• Initial development is by "genius", lone coder, or group
• Evolution passed to those less experienced
• Moves from evolution into servicing

Scenario: Open Source Transition

Initial Development
Evolution
Servicing
Phaseout
Closedown

• Software initially developed as a proprietary solution is released as open source.
• Community contributions invigorate the evolution stage, extending the lifespan of the software.

Scenario: Acquisition and Integration

Initial Development
Evolution
Servicing
Phaseout
Closedown

• A large corporation acquires software.
• The acquiring company integrates it into an existing product suite, moving it from servicing or phaseout back to evolution.

Scenario: Regulatory Changes

Initial Development
Evolution
Servicing
Phaseout
Closedown

• New regulations or compliance requirements are introduced.
• Software in the servicing or phaseout stage may either be updated to comply, re-entering the evolution stage or be retired, moving to close down.

Scenario: Platform Shift

Initial Development
Evolution
Servicing
Phaseout
Closedown

• A shift in platform (e.g., from desktop to mobile or cloud) necessitates a complete re-engineering.
• The software moves back to initial development or a parallel evolution stage.

Scenario: Forking

Initial Development
Evolution
Servicing
Phaseout
Closedown

• The software is forked due to disagreements within the development team or user community.
• Each fork may independently enter its separate lifecycle stage, offering a case study in divergent evolutions.

Scenario: Competitive Replacement

Initial Development
Evolution
Servicing
Phaseout
Closedown

• A competitive software product significantly outperforms the existing software.
• Accelerated transition from evolution or servicing stages directly to phaseout or closedown.

Scenario: Sudden Loss of Expertise

Initial Development
Evolution
Servicing
Phaseout
Closedown

• Key developers or a significant portion of the development team leaves the company.
• Rapid transition from evolution to servicing due to the loss of expertise.

Scenario: Financial Constraints

Initial Development
Evolution
Servicing
Phaseout
Closedown

• The developing company faces financial difficulties.
• Software quickly moves from evolution to servicing or phaseout as resources are reallocated to more profitable ventures.

Scenario: Niche Markets

Initial Development
Evolution
Servicing
Phaseout
Closedown

• Software serves a particular niche market.
• It may remain in the servicing stage for an extended period, supported by a small but dedicated user base.

Scenario: AI and Automation

Initial Development
Evolution
Servicing
Phaseout
Closedown

• Introducing AI algorithms or automation tools significantly changes the feature requirements.
• Software may re-enter the initial development or evolution stage to integrate these advanced capabilities.