V-Model: differenze tra le versioni

Versione delle 16:45, 24 giu 2009

Versione attuale delle 16:31, 24 giu 2019

(20 versioni intermedie di 17 utenti non mostrate)

Riga 1:

{{S|software}}

{{T|inglese|informatica|marzo 2009}}

Il '''V-model''' o '''Modello a V''' è un [[Processomodello software]]di insviluppo particolaredel èsoftware]], un'estensione del [[Modellomodello a cascata]]. Il modello invece di discendere lungo una linea retta, dopo la fase di [[Programmazione (informatica)|programmazione]] risale con una tipica forma a V. Il modello dimostra la relazione tra ogni fase del ciclo di vita dello sviluppo del software e la sua fase di [[Collaudo del software|testing (Collaudo del software)]].

[[ImageFile:V-model.JPG|''V-model SDLC''|450px|thumb|right|Il modello a V o V-model è un processo di sviluppo software.]]

Il V-model realizza un metodo ben strutturato, in cui ogni fase e'è implementabile dalla documentazione dettagliata della fase precedente. Le attività di testtesting, come il testtesting della fase di progetto, iniziano già all'inizio del progetto prima della codifica e ciò consente di risparmiare un ampio tempo di progetto.

Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time.

{{portal|Software Testing}}

== Verification Phase ==

=== Requirements analysis ===

In the [[Requirements analysis]] phase, the [[requirements]] of the proposed system are collected by analyzing the needs of the [[User (computing)|user(s)]]. This phase is concerned about 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, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back 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]], and [[Non-functional requirements]]''

=== System Design ===

[[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, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.

===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 this phase.

===Module Design===

The [[modularity (programming)|module design]] phase can also be referred to as low-level design. The designed system is broken up in to 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 [[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 ==

===Unit Testing===

In the V-model of software development, [[unit testing]] implies the first stage of [[dynamic testing]] process. According to software development expert [[Barry Boehm]], a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer.

It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted [[Programming style|coding standards]]. Testing is usually [[White box testing|white box]]. It is done using the Unit test design prepared during the module design phase. This may be carried out by software testers, software developers or both.

===Integration Testing===

In [[integration testing]] the separate modules will be tested together to expose faults in the [[Interface (computer science)|interfaces]] and in the interaction between integrated components. Testing is usually [[Black box testing| black box]] as the code is not directly checked for errors. It is done using the integration test design prepared during the architecture design phase. Integration testing is generally conducted by software testers.

===System Testing===

[[System testing]] will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is [[Test automation|automated]] using testing tools.

Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.

<!-- The following description is unaccaptable in and overview article

===User Acceptance Testing===

''Main article [[Acceptance testing]]''

Acceptance testing:<br />

- To determine whether a system satisfies its acceptance criteria or not.<br />

- To enable the customer to determine whether to accept the system or not.<br />

- To test the software in the "real world" by the intended audience.<br />

Purpose of acceptance testing:<br />

- To verify the system or changes according to the original needs.<br />

Procedures for conducting the acceptance testing:<br />

Define the acceptance criteria:<br />

- Functionality requirements.<br />

- Performance requirements.<br />

- Interface quality requirements.<br />

- Overall software quality requirements.<br />

Develop an acceptance plan:<br />

- Project description.<br />

- User responsibilities.<br />

- Acceptance description.<br />

- Execute the acceptance test plan.<br />-->

==Voci correlate==

*[[Dual Vee Model]]

*[[Systems Development Life Cycle]]

*[[Product lifecycle management]]

== Note ==

{{reflist}}

{{Unreferenced|date=October 2008}}

== Approfondimenti ==

Line 71 ⟶ 8:

* Mark Hoffman & Ted Beaumont: ''Application Development: Managing the Project Life Cycle'', Mc Press, ISBN 1883884454

* Boris Beizer: ''Software Testing Techniques.'' Second Edition, International Thomson Computer Press, 1990, ISBN 1-85032-880-3

==Altri progetti==

{{interprogetto}}

==Collegamenti esterni==

* [{{cita web|http://www.bucanac.com/documents/The_V-Model.pdf |A paper by Christian Bucanac]}}

{{interprogetto|commons=Category:V-models}}

* {{cita web | 1 = http://www.iacis.org/iis/2004_iis/PDFfiles/Boggs.pdf | 2 = The SDLC and SixSigma | accesso = 13 gennaio 2009 | urlarchivio = https://web.archive.org/web/20070929144804/http://www.iacis.org/iis/2004_iis/PDFfiles/Boggs.pdf | dataarchivio = 29 settembre 2007 | urlmorto = sì }}

* [http://www.bucanac.com/documents/The_V-Model.pdf A paper by Christian Bucanac]

* {{cita web | 1 = http://www.elucidata.com/refs/sdlc.pdf | 2 = SDLC for small and medium DB applications | accesso = 13 gennaio 2009 | urlarchivio = https://web.archive.org/web/20070423113916/http://www.elucidata.com/refs/sdlc.pdf | dataarchivio = 23 aprile 2007 | urlmorto = sì }}

* [http://www.iacis.org/iis/2004_iis/PDFfiles/Boggs.pdf The SDLC and SixSigma]

* [http://www.elucidata.com/refs/sdlc.pdf SDLC for small and medium DB applications]

{{Software Engineering}}

{{T|inglesePortale|informatica|marzo 2009ingegneria}}

[[Categoria:Teorie della programmazione]]

[[Categoria:Ingegneria del software]]

[[af:V-Model]]

[[ca:Model V]]

[[de:V-Modell]]

[[en:V-Model]]

[[es:Método en V]]

[[fr:Cycle en V]]

[[ja:Vモデル]]

[[ko:V 모델]]

[[nl:V-model]]

[[pt:Modelo_V]]

[[ru:V-Model]]

[[zh:V模型]]