TheVModel1

Running head: THE V-MODEL LIFECYCLE PROCESS MODEL

The V-Model Lifecycle Process Model: As a Software Development Standard

Joshua Thacker Object-Oriented Systems Analysis and Design Dr. Rhonda Syler November 1, 2009

TheVModel2

Abstract The V-Model is an approach to the system development life cycle process that uniquely combines the advantages of both the predictive and adaptive approaches to developing information systems and deserves careful consideration when planning a new information system. It is a generic process model, which means that it is independent of organization and project type and can be tailored to meet the needs of any project. As with any software development lifecycle model, there are advantages and disadvantages to the V-Model that should be taken into consideration when pondering the use of this particular model. This paper describes the V-Model from a high level view, and explains it in such a way that no previous knowledge is needed to gain insight from the information provided here.

TheVModel3

The V-Model Lifecycle Process Model: As a Software Development Standard There are many approaches to the planning and organization of projects that produce new information systems. For instance, the waterfall model is a predictive approach to the system development life cycle that assumes the various phases of a project can be completed sequentially without returning to the previous phases. There is also the spiral model, which is an adaptive approach, which cycles over and over again through development of activities until a project is complete. The V-Model is another approach to the system development life cycle process that uniquely combines the advantages of both the predictive and adaptive approaches to developing information systems and deserves careful consideration when planning a new information system. Overview The V-Model was designed by the IABG in Ottobrun, Germany, in cooperation with the Federal Office for Defense Technology and Procurement, for the Federal Ministry of Defense. It was conceived in an attempt to standardize software development for the government and the private sector. The V-Model uses standardized and methodical guidelines in order to obtain several objectives. These objectives include the reduction of software costs in the entire lifecycle, the improvement of software quality, and the improvement in communication between the customer and the contractor. The V-Model is a generic process model, which means that it is independent of organization and project type and can be tailored to meet the needs of any project. There are some important advantages that the V-Model offers over other models that make this approach a favorable selection.

TheVModel4

Three-Level Standardization Concept Lifecycle Process Model As shown in Figure 1, the V-Model has three levels: Procedures, Methods and Tool Requirements. The Procedures level, also known as the Lifecycle Process Model, addresses and answers the question, What needs to get done in order to successfully complete the project at hand? The Procedures level helps to establish a clear directive as to what activities need to be performed, the end result of those activities produced at final completion, and the meaning of the substance obtained from the end result. The execution and results of the activities are exactly described in great detail (see Figure 2). The Lifecycle Process Model can be extremely complex, but to simplify matters we can summarize the Procedures level into two concepts; activities and products. By doing this, we can avoid the complications of dealing with states and interdependencies of the Activity Schema and the Product Flow Schema. Activities are iterative actions known as work-steps in the development process. Depending on the level of difficulty, an activity can be broken down into a sub-activity. The highest level of notion (i.e., a generalized/broad work-step), is called the main activity, which is deemed as abstraction in programming. The final outcome of an activity is a product. A product can be a document, software, or hardware. As aforementioned, a product is the final result of an activity. Products just like activities can be dissected into smaller more manageable parts called sub-products. A product undergoes different states as it is generated, and these changes in states can only be triggered by an activity. As shown in Figure 3, a product can have the following states: Planned is the initial state in which the product is conceptualized. The product does not yet exist but begins to develop and unfold during this state.

TheVModel5

Processed is the state in which the product begins to take shape. The developer has complete control of the product and molds it according to the design specifications. Submitted is the state in which the developer has finalized the product according to the organizational requirements. The developer submits the product to the Quality Assurance team for analysis and review. If the product fails to meet the requirements specifications, the product is returned to the developer for further processing. If the product passes the Quality Assurance inspection, it moves to the Accepted state. Accepted is the state in which the product receives a version number. The product can continue to receive modifications and updates through validation from Change Management throughout its lifetime with new assigned and updated version numbers.

Allocation of Methods The second level, also known as the Allocation of Methods level (Methods), addresses and answers the question, How will the project reach its full completion? During this level, certain guidelines (methods) are determined and followed to aid in the completion of the system development activities addressed in the Procedures level (see Figure 2). The Methods level truly complements the Lifecycle Process Model by specifying how something is done. Before specifications are given to determine how something is done, the tasks or projects that need to be completed must be identified. This level sets the tone by legitimizing the selection and application of methods for all sub-models. For each activity a method is chosen and documented in the project manual. Functional Tool Requirements The third level, also known as the Functional Tool Requirements, addresses and answers the question, What tools will be used to follow the guidelines to perform these activities? Within this level, the system requirements (functional characteristics) that the tools must have to complete the delegated activities within various processes are identified (see Figure 2). These system requirements are based solely on the policies and procedures that are used by the

TheVModel6

Organization to manage the business. The Functional Tools Requirements also legitimize the selection and application of tools for all sub-models. It not only complements the Lifecycle Process Model but supports the Allocation of Methods level by using one or more tools. A tool is defined as a, software product/support that facilitates the development, modification, and maintenance of models or components required for the success of the IT system (Satzinger, Jackson, & Burd, 2004). Functional Sub-model Concept As shown in Figure 1, the V-Model also has four sub-models. All three levels (i.e., Procedures, Methods, and Tool Requirements) of the V-Model are structured according to the sub-models functional principals. Each sub-model consists of activities and generates products. The activities and products are interdependent of each other to achieve the project goal. Products are never stagnant and continue to be molded as the project grows continuously being refined, updated, and detailed throughout the activities. This modification process can continue to occur as long as the version number is updated. As shown in Figure 4, the four sub-models are: Project Management (PM), System Development (SD), Quality Assurance (QA), and Configuration Management (CM). Project Management Project Management assists in the planning, monitoring, and controlling of the system development project while passing information to the other sub-models. This sub-model states that staff members play an important role in the planning of the activities. The staff members should help with the estimating and deciding of the time schedule. Each Project Management sub-model has a job selection and project members are matched with specific roles. Project Management is comprised of 14 main activities:

TheVModel7

1. Project Initialization consists of creating a project specific V-Model. The organizational framework is planned and documented in a project plan. The framework is solely based off of the project manual. 2. Placement/Procurement evaluates the feasibility requirements by reviewing the requests for proposals by subcontractors. 3. Contractor Management ensures all contracts are satisfied. 4. Detailed Planning utilizes the specifications in the project manual and establishes a detailed plan for the project. 5. Cost/Benefit Analysis each solution proposal is evaluated according to its cost benefit analysis and a profitability solution is developed. 6. Phase Review validates the project status according to the planned documentation. 7. Risk Management detects and mitigates project risks with prevention measures. 8. Project Control controls the flow and progress of the project. 9. Information Service/Reporting allows information to be available to stakeholders. 10. Training/Instruction trains all active project participants to ensure they have the necessary knowledge to fulfill their roles. 11. Supplying Resources assesses the needed resources for project completion. 12. Allocation of work orders initiates job sections by the work orders. 13. Staff Training introduces project members to their job sections where they are informed and trained in order to complete their tasks. 14. Project Completion consists of writing a final project report which contains all project experiences. System Development System Development is the second sub-model and it controls the activities in the development of the system project. System Development places a high emphasis on off-the-

TheVModel8

shelf components. Off-the-shelf components are given special attention in the System Design phase. Feasibility studies are performed based on requirements and off-the-shelf components are assessed. System Development is comprised of eight activities: 1. System Requirements Analysis is a specification from an external point-of-view (i.e., user specifications). 2. System Design deals with the conception and integration of the system architecture. 3. SW/HW Requirements Analysis updates the operational and technical requirements with regard to the software and hardware requirements. 4. Preliminary SW design involves the designing of the software architecture, interface description, and integration plan. 5. Detailed SW Design elaborates and fine-tunes the integration description and software architecture while the specifications, details for modules, components, and database are created. 6. SW Implementation shapes the modules, components, and databases into a compiled and executable form. 7. SW Integration realizes and incorporates the modules, components, and databases in several steps. 8. Transition to Utilization ensures tasks in the system are operational in the intended environment. Quality Assurance Quality Assurance is the third sub-model. It attests to the quality of the activity and product requirements and ensures the other sub-models are informed and comply within specified standards before acceptance is validated. This sub-model assesses the products and processes of a given project and operates in the short-run. Since the V-Model is a project process model and not an organizational process model, there are no long-run plans dealing with

TheVModel9

continuous improvements. It compares the products and processes with plans, standards, and definitions. Quality Assurance is comprised of five activities: 1. QA Initialization coordinates the procedural and organizational scope and all specifications are documented in a QA plan. 2. Assessment Preparation contains the criteria, definition methods, test cases, environment, and produces the assessment plan. 3. Process Assessment of Activities assesses the processes to ensure they are sufficient. 4. Product Assessment assesses the product. The product is either accepted and enters the accepted state or it is rejected and goes back to the processed state. 5. QA Reporting evaluates the number of problems, severity of problems, classification of problems, the cause of problems, and documents all in an assessment report. Configuration Management Configuration Management is the fourth sub-model and it guarantees that a product can be uniquely identified by asserting control modifications and integrity parameters that manage the generated products. Configuration Management is comprised of four activities: 1. CM Planning defines the organizational framework, needed resources, and tools by documenting them in the CM plan. 2. Product and Configuration Management administers the product library and the configuration of the entire system. 3. Change Management manages changes in three steps: (1) change is requested and registered; (2) change is evaluated for acceptance or rejection; (3) if changes are accepted, they are then implemented and all affected by new change are informed. 4. CM Services aid in the project development (i.e., catalog software products, coordinating interfaces, backups, release management, and recording project history).

TheVModel10

Considerations Advantages Model. Perhaps the most important advantage that the V-Model has over other models is that it is organizational and project independent so that each project - at start - can be tailored into a specific Project V-Model (see Figure 5). The fact that end-users participate and play a crucial role in the development and maintenance of the V-Model is a key advantage since it ensures that the final product is tailored to the needs of the actual users. Lastly, there is a high level of control before actions are taken place on the system, as a change control board meets once a year to process all received requests. Methods. The V-Model offers a limited number of highly defined and described methodologies that aids the project manager in quick selection of methods best suited to complete the project goals. These methodologies support both structured and object-oriented system development. Tools. The tools provided in the V-Model are tested and proven and have shown high levels of productivity with prior projects. A collection of tools are organized so that the developer can better fulfill completion of the product according to their functional and nonfunctional requirements. The selection of tools depends on the definition of the system requirements, and each tool is chosen according to which requirement it fulfills. Disadvantages Model. The V-Model addresses the development of software within a given project rather than an entire Organization, meaning that once the project has reached completion, the VModel ceases to exist. Also, sub-models cover all aspects of an activity but only from a high level view. Once the project team reveals the conceptual level, there are no principles to follow.

TheVModel11

Lastly, it is easy to assume a thorough review and inspection has been done but there are no measurable guidelines outlined in the V-Model for the inspection process. Methods. While offering, a limited number of methods is an advantage in the selection process, it neglects to offer all of the potential methods that could have been used consideration for other options is not available. Tools. The System Development Environment in the V-Model includes guidelines for hardware development; however, there are no hardware tools defined or described by the VModel. Summary In summary, the V-Model is a software development lifecycle process model that incorporates aspects from both the typical Waterfall (predictive) and Unified Process (adaptive) models. As shown in Figure 6, the model can be represented as a V shape where on the top of the left side are the high level concepts. As one descends down the V through the definition of sequence and elaboration of detail (verification), the testing techniques associated with the design are shown. At the base of the V, begins the coding phase. The model considers coding and testing during this phase of the software development process equal. As one ascends up the right side of the V through the assembly and performance assurance sequence (validation), the requirements specifications are defined and subsequently a product is completed, implemented, and maintained.

TheVModel12

References Forsberg, K., & Mooz, H. (1998). System Engineering for Faster, Cheaper, Better. California: Center for Systems Management, Inc. Forsberg, K., & Mooz, H. (1992). The Relationship of System Engineering to the Project Cycle. Engineering Management Journal (No. 3), 36-43. Graham, D. (2002, July 1). Architecture & Design. Retrieved October 10, 2009, from Dr. Dobb's: http://www.ddj.com/architect/184414873 IABG Information Technology. (2009). V-Model. Retrieved October 12, 2009, from IABG: http://www.iabg.de/infokom/software_einfuehrung/v-modell_en.php IABG Information Technology. (n.d.). V-Model Lifecycle Process Model. Retrieved October 12, 2009, from IABG: www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2004). Object-Oriented Analysis and Design with the Unified Process (1st ed.). Course Technology, Cengage Learning. Schuppan, V., & Ruwurm, W. (2000). A CMM-based evaluation of the V-Model 97. In Software Process Technology (Vol. 1780/2000, pp. 69-83). Mnchen, Germany, Europe: Springer Berlin / Heidelberg. V-ModellXT authors and others. (2006). V-Modell XT, Version 1.3 English. Retrieved October 1, 2009, from Fundamentals of the V-Modell: http://v-modell.iabg.de/v-modellxt-html-english/index.html#toc0

TheVModel13

Figure 1. Cube architecture representation of the Three-Levels of Standardization with Functional Sub-Models

TheVModel14

Figure 2. General structure of questions a given level addresses in the V-Model

TheVModel15

Figure 3. A transition of states a product goes through caused by activities

TheVModel16

Figure 4. Functional Sub-model framework

TheVModel17

Figure 5. Contractual and Technical aspects associates with tailoring

TheVModel18

Figure 6. Overview of the Technical aspect of the System Development Project Cycle