Content deleted Content added
No edit summary |
m Reverted edits by 81.77.108.90 (talk): not providing a reliable source (WP:CITE, WP:RS) (HG) (3.4.13) |
||
| (535 intermediate revisions by more than 100 users not shown) | |||
Line 1:
{{Short description|Software development methodology}}
{{More citations needed|date=September 2018}}
[[File:Systems Engineering Process II.svg|thumb|upright=2|The V-model of the Systems Engineering Process<ref name="FHWA 05">[http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/14158.htm ''Clarus Concept of Operations.''] {{Webarchive|url=https://web.archive.org/web/20090705102900/http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/14158.htm |date=2009-07-05 }} Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005</ref>]]
{{Software development process}}
In [[software development]], the '''V-model'''<ref>[[Kevin Forsberg]] and [[Harold Mooz]], "The Relationship of System Engineering to the Project Cycle", in Proceedings of the First Annual Symposium of National Council on System Engineering, October 1991: 57–65.</ref> represents a [[software development process|development process]] that may be considered an extension of the [[waterfall model]] and is an example of the more [[V-model|general V-model]]. Instead of moving down linearly, the process steps are bent upwards after the [[source code|coding]] phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of [[Software testing|testing]]. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.
== Project definition phases ==
===
In the [[requirements analysis]] phase, the first step in the verification process, the [[requirements]] of the system are collected by analyzing the needs of the [[User (computing)|user(s)]]. This phase is concerned with establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated.
The user requirements document will typically describe the system's functional, interface, performance, data, security, etc. requirements as expected by the user. It is used by business analysts to communicate their understanding of the system to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase. See also [[Functional requirements]].
There are different methods for gathering requirements of both soft and hard methodologies including; interviews, questionnaires, document analysis, observation, throw-away prototypes, [[use case]], and static and dynamic views with users.
=== System
[[Systems design]] is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly.
The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, [[data structure]]s etc. It may also hold example business scenarios, sample windows, and reports to aid understanding. Other technical documentation like entity diagrams, and data dictionaries will also be produced in this phase. The documents for system testing are prepared.
=== Architecture design ===
The phase of the design of [[computer architecture]] and [[software architecture]] can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their [[Interface (computer science)|interface]] relationships, [[Coupling (computer science)|dependencies]], [[database]] [[Table (database)|tables]], architecture diagrams, technology details, etc. The integration testing design is carried out in the particular phase.<ref>
[http://istqbexamcertification.com/what-is-v-model-advantages-disadvantages-and-when-to-use-it/ What is V model - Advantages, disadvantages and when to use it]</ref>
=== Module design ===
The [[modularity (programming)|module design]] phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly.
The low-level design document or program specifications will contain a detailed functional logic of the [[Modular programming|module]], in [[pseudocode]]:
* database tables, with all elements, including their type and size
* all interface details with complete [[API]] references
* all dependency issues
* [[error message]] listings
* complete input and outputs for a module.
The unit test design is developed in this stage.
== Validation phases ==
In the V-model, each stage of the design phase has a corresponding stage in the validation phase.<ref>{{cite web |url=http://www.pharmpro.com/Articles/2008/03/GAMP-Standards-For-Validation-Of-Automated-Systems/ |title=GAMP Standards For Validation of Automated Systems |author1=DeSpautz, Joseph |author2=Kenneth S. Kovacs |author3=Gerhard Werling |publisher=Pharmaceutical Processing |date=11 March 2008 |access-date=28 February 2012 |archive-url=https://web.archive.org/web/20120508022817/http://www.pharmpro.com/Articles/2008/03/GAMP-Standards-For-Validation-Of-Automated-Systems/ |archive-date=8 May 2012 |url-status=dead |df=dmy-all }}</ref> The following are the typical phases of validation in the V-Model, though they may be known by other names.
=== Unit testing ===
In the V-Model, Unit Test Plans (UTPs) are developed during the module design phase. These UTPs are executed to eliminate bugs at the code level or unit level. A unit is the smallest entity that can independently exist, e.g. a program module. Unit testing verifies that the smallest entity can function correctly when isolated from the rest of the codes/units.
===
Integration Test Plans are developed during the Architectural Design Phase. These tests verify that units created and tested independently can coexist and communicate among themselves. Test results are shared with the customer's team.
=== System testing ===
System Tests Plans are developed during the System Design Phase. Unlike Unit and Integration Test Plans, System Test Plans are composed by the client's business team. System Test ensures that expectations from the application developed are met. The whole application is tested for its functionality, interdependency, and communication. System Testing verifies that functional and non-functional requirements have been met. Load and performance testing, stress testing, [[regression testing]], etc., are subsets of system testing.
=== User acceptance testing ===
User Acceptance Test (UAT) Plans are developed during the Requirements Analysis phase. Test Plans are composed by business users. UAT is performed in a user environment that resembles the production environment, using realistic data. UAT verifies that the delivered system meets the user's requirement and the system is ready for use in real-time.
== Criticism ==
The V-Model has been criticized by [[Agile software development|Agile]] advocates and others as an inadequate model of software development for numerous reasons.<ref>[https://www.bdtask.com/blog/v-model-in-software-development "V Model In Software Development"], accessed October 14, 2024 (updated)</ref><ref>[https://web.archive.org/web/20190915230955/http://www.clarotesting.com/page11.htm "The Dangerous & Seductive V Model"], archived version from September 15, 2019</ref><ref>[http://www.exampler.com/testing-com/writings/new-models.pdf "New Models for Test Development"], accessed January 6, 2013</ref> Criticisms include:
# It is too simple to accurately reflect the software development process, and can lead managers into a false sense of security. The V-Model reflects a project management view of software development and fits the needs of project managers, accountants and lawyers rather than software developers or users.
# Although it is easily understood by novices, that early understanding is useful only if the novice goes on to acquire a deeper understanding of the development process and how the V-Model must be adapted and extended in practice. If practitioners persist with their naive view of the V-Model they will have great difficulty applying it successfully.
# It is inflexible and encourages a rigid and linear view of software development and has no inherent ability to respond to change.
# It provides only a slight variant on the [[waterfall model]] and is therefore subject to the same criticisms as that model. It provides greater emphasis on testing, and particularly the importance of early test planning. However, a common practical criticism of the V-Model is that it leads to testing being squeezed into tight windows at the end of development when earlier stages have overrun but the implementation date remains fixed.
# It is consistent with, and therefore implicitly encourages, inefficient and ineffective approaches to testing. It implicitly promotes writing test scripts in advance rather than exploratory testing; it encourages testers to look for what they expect to find, rather than discover what is truly there. It also encourages a rigid link between the equivalent levels of either leg (e.g. user acceptance test plans being derived from user requirements documents), rather than encouraging testers to select the most effective and efficient way to plan and execute testing.
# It lacks coherence and precision. There is widespread confusion about what exactly the V-Model is. If one boils it down to those elements that most people would agree upon it becomes a trite and unhelpful representation of software development. Disagreement about the merits of the V-Model often reflects a lack of shared understanding of its definition.
== Current state ==
Supporters of the V-Model argue that it has evolved and supports flexibility and agility throughout the development process.<ref>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.640.3024&rep=rep1&type=pdf "Toward Agile Systems Engineering Processes"], accessed August 9, 2022</ref> They argue that in addition to being a highly disciplined approach, it promotes meticulous design, development, and documentation necessary to build stable software products. Lately, it is being adopted by the medical device industry.<ref>{{cite book | chapter-url=https://link.springer.com/chapter/10.1007%2F978-3-642-30439-2_13?LI=true | doi=10.1007/978-3-642-30439-2_13 | chapter=Barriers to Adopting Agile Practices when Developing Medical Device Software | title=Software Process Improvement and Capability Determination | series=Communications in Computer and Information Science | date=2012 | last1=McHugh | first1=Martin | last2=McCaffery | first2=Fergal | last3=Casey | first3=Valentine | volume=290 | pages=141–147 | isbn=978-3-642-30438-5 }}</ref><ref>[http://eprints.dkit.ie/144/ "A Software Process Development, Assessment and Improvement Framework, for the Medical Device Industry "]</ref>
==
* [[Product lifecycle management]]
* [[Systems development life cycle]]
== References ==
{{Reflist}}
== Further reading ==
* Roger S. Pressman:''Software Engineering: A Practitioner's Approach'', The McGraw-Hill Companies, {{ISBN|0-07-301933-X}}
* Mark Hoffman & Ted Beaumont: ''Application Development: Managing the Project Life Cycle'', Mc Press, {{ISBN|1-883884-45-4}}
* Boris Beizer: ''Software Testing Techniques.'' Second Edition, International Thomson Computer Press, 1990, {{ISBN|1-85032-880-3}}
{{Commons category|V-models}}
{{Software engineering}}
{{Interwiki extra|qid=Q1142155}}
{{DEFAULTSORT:V-Model (Software Development)}}
[[Category:Software development process]]
| |||