V-Model

Lifecycle Process Model

Olman HernándezOlman HernándezKstico@netscape.netKstico@netscape.net

DePaul University

SE-470 Spring 03

Objectives Brief Description of the V-model Understand the basics of the model

History Principles Components Usage Guidelines Marketplace Analysis References

History 1986 - IABG for the Federal Ministry

of Defense 1991 – Obligatory standard 1992 – Federal Ministry of the

Interior 1997 - Comprehensive revision 2004 - Major Update Expected

Principles Independence of methods and tools Independence of Organizations Separation into “submodels” Orientation to activities and

products Adaptability of the model

Standardization The value of a standard

Reduction of cost in the entire lifecycle Improvement of software quality Better communication between

customer and contractor Regulations on 3 levels

Procedure (what) Allocation of methods (how) Functional tool requirements (what)

Structure All levels the regulations are

structured according to activity areas Systems development Quality assurance Configuration management Project management

Development standard developed for each area.

Levels of Standardization

Tool Requirements

Methods

Procedure

System Development

Quality Assurance

Configuration Management

Project Management

General Directives

Tool Requirements

Methods

Procedure

System Development

Quality Assurance

Configuration Management

Project Management

Procedure General directive 250 What has to be done:

Activities to be carried out Results that have to be produced Content of the results Roles

Lifecycle process model

Structure

Binding Regulations Activities Products

Supplements with regard to Authorities German Federal Armed Forces Civilian Federal Administration

Collection of Manuals Special topics

• Object Oriented Languages• Incremental Development• Use of Off-the-Shelf Products

Tailoring No important document is “forgotten” Tailoring relevant for tendering

Selection of the necessary activities and products

Deletion conditions The resulting subset of the Lifecycle is put

together in the Project Manual Technical Tailoring

Adapting to conditions during the course of the project

Tailoring Steps

Cooperation of Sub-models

Software Development

SD1-System Req. analysis Description of the Req. of the system and its

environment, Risk Analysis , and User Req. SD2–System design

Segmentation of the system into SW/HW SD3-SW/HW requirement analysis

Detail Technical Requirements SD4-Preliminary SW design

Structuring of the interfaces and interaction of SW components

Software Development SD5-Detailed SW design

Description of functionality, Data administration and error handling of SWC

SD6-SW implementation Coding in chosen programming language

SD7-SW integration Integration of modules

SD8-System integration Integration of SW and HW components

SD9-Transition to utilization Activities for Deployment into Production

Software Development

SWD 1 System

Requirements Analysis and Design

SWD 8

DP Integration

SWD 2

DP Requirements Analysis

and Desgin

SWD 9

System Integration

SWD 3

SW Requirements Analysis

SWD 4

Preliminary Design

SWD 5

Detailed Design

SWD 6

Implementation

SWD 7

SW Inte- gration

System

Segment Manual Information

SWCI Integration

Component

Integration

Program Documents (SWCI)

SWCI

Program Documents (Component)

Component

Module

Program Documents (Module)

System Requirements System Design System Integration Plan

DP Requirements DP Design DP Integration Plan

SW Requirements

SW Architecture Interface Design SWCI Integration Plan

Data-Dictionary SW Design

Legend: Proof activities (see QA)

SWD Activity

Quality Assurance QA1-Initialization

Generated the QA and Assessment Plan QA2-Assessment Preparation

Generation of unambiguous Assessment specification and procedures & Req. of Assessment Environment

QA3-Process Assessment of Activities Specified procedures were adhered to during the

realization of an activity QA4-Product Assessment

Assessment with respect to the formal criteria & the contents of the product. Assessment Report generated.

QA5-Reporting Assessment Reports are assessed in regular intervals

and the results submitted to PM.

Configuration Management

CM1-CM Initialization Generation of the CM plan and setting of the

CM resources CM2-Product and CM

Administration of products, configurations and rights

CM3-Change Management Controlled artifacts are recorded and

administered CM4-CM Services

General services (e.g Product Catalog)

Project Management PM1-Project Initialization PM2-Placement/Procurement PM3-Contractor Management PM4-Detailed Planning PM5-Cost/Benefit Analysis PM6-Phase Review PM7-Risk Management

Project Management PM8-Project Control PM9-Information Service/Reporting PM10-Training/Instruction PM11-Supplying Resources PM12-Allocation of Work Orders PM13-Staff Training PM14-Project Completion

Final Project Report

General View

General Directives

Tool Requirements

Methods

Procedure

System Development

Quality Assurance

Configuration Management

Project Management

Methods Allocation General directive 251 How is something to be done:

Methods used to perform activities Means of presentation in the results

Basic: specific/delimited aspect of the system E/R modeling,state transition modeling, functional

decomposition Complex:comprise of various methodical

components and integrate them into a total method Graphical Enginnering system, integrated software

technology

Methods Allocation Categories of methods: basic methods

that offer different solution approaches for a certain class of tasks. Only one required Estimation models: Function Point Method,

Constructive Cost Model Formal Specification: Temporal logic,

Mathematical Specification, Algorithmic Methods allocation

Allocation tables Methods interfaces

Allocation Table Briefly describe how the methods

are to be used in the individual activities

Methods Interfaces Describe what information is exchanged

between the individual methods and what to take into account when exchanging information.

General Directives

Tool Requirements

Methods

Procedure

System Development

Quality Assurance

Configuration Management

Project Management

Tool Requirements General Directive 252 What is to be used to do something:

Functional characteristics must the tools have

Introduces the Software Development Environment

Use for: Selection of tools Evaluation Further Development of tools

Tool Requirements SDE reference model

User Interface Work flow management Security and integrity requirements Software development Quality assurance Configuration Management Project Management Object Management

Benefits Is complete, All functional areas Is mature Complies w/ Best Practices Open source Supports when tendering Adaptable to circumstances Adapt to Phase Models. Living Methodology and Products

Drawbacks Does not include the maintenance

phase. It is considered a Scenario. Is project specific, does not extend

to the organization level.(Rev.2004) Delivery Vehicle. PDF format Lack of depth on some activities No Templates

Usage Guidelines When/How to Use

Basis for contracts Guideline Communication Basis

When not to Use Inexperience Development Team

Implementation Very easy to understand Wide application spectrum Tailoring, Organization and tool Independent Support, mostly German

Marketplace Analysis Key players

Change Control Board• Industrial and Public authority users• Obliged to deal with all submitted change request

IABG, Federal Ministry of the interior Products

In-Step by Microtool Market Data

EUROMETHOD, EU Project Basis of Austria’s IT-BVM and Switzerland’s HERMES DaimlerChrysler Aerospace,Defense and Civil Syst. Div. Siemens corporate Technology division Binding obligatory regulation in Germany (Civilian &

Defense)

V-Model and CMM

References IABG, English Version

http://www.v-modell.iabg.de/vm97.htm#ENGL

University of Bremen in Germany http://www.informatik.uni-bremen.de/gdpa/