MSD - SW Development Life Cycle Models

• Build and fix model
• Waterfall model
• Spiral model
• Hermes
• V-Model
• Prince2
• Unified Process
• Extreme Programming (XP)
• Scrum
• The cathedral and the basar
• Manifesto for Agile SW Dev

There is no specific procedure in place.

sequential, fixed, not adaptive

Risk driven, incremental

--> Picture on p.32

The phase model forms the backbone of the project. It subdivides the life cycle of the project and creates the conditions for the project participants common understanding of the course of the project.

The HERMES phase model consists of four phases:

Initiation Define objectives in the study, work out requirements in sufficient detail for options to be developed and evaluated. The project order is created on the basis of the option selected.
Concept In the concept phase, the rough requirements documented in the study are fleshed out and completed as system requirements. Project-specific solution concepts are designed in detailed studies. They form part of the system architecture. This describes the system with its processes, functionality, system components and their integration into the system environment via interfaces.
Implementation Based on the system architecture, the detailed specifications are created and the system is developed according to those. This also includes testing as a prerequisite for the decision on preliminary acceptance.
Deployment In the deployment phase, the system is activated and then the decision on acceptance is made.

This scenarios can be modified according to the project characteristics

• Service/product
• Customized IT application
• Standard IT application
• Further development of IT application
• IT infrastructure
• Organizational adjustment
• Service/product (agile)
• Customized IT application (agile)

• Project steering
• Project management
• Agile development
• Project foundations
• Business organization
• Product
• IT system
• Procurement
• Deployment organization
• Testing
• IT migration
• IT operation
• Information security and data protection

The V-model is a graphical representation of a systems development lifecycle.

For rigorous development lifecycle models and project management models.

Key attribute are ”V”representation was to require proof that the products from the left-side of the V were acceptable by the appropriate test and integration organization implementing the right-side of the V.

(See p.34)

• Specification Stream
User Requirements Specification, Functional Requirement Specification, Design specification

• Testing Stream
Installation qualification (IQ), Operational qualification (OQ), Performance qualification (PQ)

• The users of the V-model participate in the development and maintenance of the V-model. A change control board publicly maintains the V-Model. The change control board meets anywhere from every day to weekly and processes all change requests received during system development and test.

• The V-model provides concrete assistance on how to implement an activity and its work steps, defining explicitly the events needed to complete a work step: each activity schema contains instructions, recommendations and detailed explanations of the activity.

1. Directing a Project (DP)

2. Starting up a Project (SU)

3. Initiating a Project (IP)

4. Managing Stage Boundaries (SB) :

5. Controlling a Stage (CS)

6. Managing Product Delivery (MP)

7. Closing a Project (CP)

8. Planning (PL)

- Initiation and closure of project

- Stage boundaries ( fraktionsübergreifende Zusammenarbeit)

- Ad hoc direction

- Aimed by Project board (no day to day activies covered)

- Actuall first process in prince

- Pre-Project process makes sure that pre-requisites for initiating the project are in place

- Need of a Project Mandate which defines in high level terms,  reason for the project, outcome

- Designing and appointing the Project Management Team

- Creating the Initiation Stage Plan

- justification to proceed with the project

- stable management

- Document and confirm that an acceptable Business Case exists for the project

- Provide the baseline for the decision-making processes required during the project’s life

- Ensure that the investment of time and effort required by the project is made wisely, taking
account of the risks to the project.

• Assure the Project Board that all deliverables planned in the current Stage Plan have been completed
• Provide the information needed for the Project Board to assess the continuing viability of the project
• Provide the Project Board with information needed to approve the current stage’s completion and authorise the start of the next stage, together with its delegated tolerance level
• Record any measurements or lessons which can help later stages of this project and/or other projects.

Monitoring and control activities of the Project Manager

• Authorising work to be done
• Gathering progress information about that work
• Watching for changes
• Reviewing the situation
• Reporting
• Taking any necessary corrective action.

Ensures that planned products are created and delivered

• Making certain that work on products allocated to the team is effectively authorised and agreed e accepting and checking Work Packages
• Ensuring that work conforms to the requirements of interfaces identified in the Work Package
• Ensuring that the work is done
• Assessing work progress and forecasts regularly
• Ensuring that completed products meet quality criteria
• Obtaining approval for the completed products.

execute a controlled close to the project, prepare input to the Project Board to obtain its
confirmation that the project may close

• Check the extent to which the objectives or aims set out in the Project Initiation Document
(PID) have been met
• Confirm the extent of the fulfilment of the Project Initiation Document (PID) and the
Customer’s satisfaction with the deliverables
• Obtain formal acceptance of the deliverables
• Ensure to what extent all expected products have been handed over and accepted by the
Customer
• Confirm that maintenance and operation arrangements are in place (where appropriate)
• Make any recommendations for follow-on actions
• Capture lessons resulting from the project and complete the Lessons Learned Report
• Prepare an End Project Report
• Notify the host organisation of the intention to disband the project organisation and resources.

Planning is a repeatable process, and plays an important role in other processes, main ones being:

• Planning an Initiation Stage (SL16)
• Planning a Project (IP2)
• Planning a Stage (SB1)
• Producing an Exception Plan (SB6).

- Framework to customize

- Use-Case-Driven

- Architecture-centric

- Iterative and incremental

Inception: Project started, Determine if project is worth it, Which ressouces needed?

Elaboration: Evaluate architecture, consider possbile application and cost

Construction: Develop and complete --> SW is designed, written and tested

Transition: Release, Updates upon on feedback, included User training, system conversions.

Business Modelling

Requirements

Analysis and Design

Implementation

Test

Deployment

Configuration Management

Project Management

Environment

• intended to improve software quality and responsiveness to changing customer requirements
• improve productivity and introduce checkpoints at which new customer requirements can be adopted

Communication: Everyone on a team works jointly at every stage of the project

Simplicity: strive to write simple code, saves time and efforts

Feedback: deliver software frequently, get feedback about it, and improve a product according to the new requirements

Courage: evaluate their own results without making excuses and ready to response

Rapid feedback

Assumed simplicity

Incremental changes

Incremental changes

Quality work