What is The V-Model Development Methodology?
The V-Model of software development uses a modified waterfall to provide a sequential development methodology that has feedback mechanisms between the pre-development and post-development phases of the lifecycle:
Instead of moving down in a linear way, the process steps are bent upwards after the 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 testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.
Unlike the standard waterfall model where each phase is only dependent on the prior phase (and is otherwise an independent activity), with the V-Model, the testing and integration phases on the right hand side interact with the ones on the left to provide feedback and insight for the next release.
Configuring the Releases and Phases in SpiraTeam
One of the first things we recommend doing in a new SpiraTeam project is building out the Releases and Phases necessary for a typical V-Model project. Using a Release for each project release, you can nest the different V-Model phases under the Release:
Make sure you set the Type of the top item to 'Major Release' and the child items to type 'Phase'.
Now we can look at how you use SpiraTeam during each of the phases:
Concept of Operations
In this phase the high level vision and scope for the project is defined. You can use the Components section of SpiraTeam to define the main areas of the system that will be designed:
In addition, you can use the Documents Management module to upload the screenshots, concept diagrams and other high-level brainstormed ideas that are going to be included in the project. They can be easily linked to the various requirements once they are created.
Requirements & Architecture
In the requirements and architecture phase, the team will define the high-level functional requirements, consider the constraints being placed on the system, and include the measures of performance, commonly called the '-ilities' (scalability, maintainability, etc.). These can be added to the Planning > Requirements part of SpiraTeam. The requirements in question can then be tagged with the 'Requirements & Architecture' phase of the release defined earlier.
The architecture of the finished system should also be considered, with the appropriate architecture diagrams being added to the Planning > Documents section of SpiraTeam as-needed.
Detailed Design
In the 'Detailed Design' phase, typically, you should be decomposing each of the functional requirements into system requirements that will be used to develop the system. In addition, for the more complex modules, it may be worth writing use cases to more clearly describe the business processes from a user's perspective.
SpiraTeam also allows you to create requirements of type 'Design Element' so that you can define some of the major design elements and have traceability across the entire requirements hierarchy using the built in Requirements Traceability Report (RTM). The requirements can be tagged to the Design or left assigned to the parent Release phase as appropriate.
Development
The Development phase includes all of the software coding and unit testing activities. The project manager will use the Tasks module of SpiraTeam to take each system requirement designed for this release and assign them to specific developers. The tasks may include coding, writing automated unit tests, provisioning appropriate DevOps infrastructure, etc.
As the code is written using your IDE of choice, SpiraTeam includes plugins for most of the popular IDEs so that your team can easily keep track of their assigned tasks and report back progress to the team lead.
Using the SpiraTeam Source Code module, all of the team's code check-ins and commits can be tracked against their assigned tasks.
During the development phase, the developers should be writing automated unit tests using the appropriate unit test framework for their language.
SpiraTeam includes plugins for the most common unit testing frameworks so that the QA lead can start to write test cases in SpiraTeam and have the unit test results appear in the dashboard
Integration Testing
In the Integration Testing phase, all of the individual code modules are integrated together for the first time (unlike in an agile project where it happens continuously). The QA lead will use SpiraTeam to create the test plan from the requirements tree, using the Requirements Test Coverage indicators an search features to ensure all requirements are adequately covered.
Automation functional testing tools such as Rapise can be used to automate and speed up the repetitive testing for large parts of the system as the testing progresses.
Once the system has passed all the functional and integration tests, it is ready for the end users.
User Acceptance Testing
In the UAT, testing phase, the end users who will use the different parts of the system are brought in to test the system. The testing will take the form of both running specific test cases that have been defined ahead of time as well as freeform testing where the users try to break the system in any way possible, trying as many "edge" cases as possible.
In either case, as defects are discovered, they are logged as bugs using either the SpiraTeam integrated defect logging that is built into the test execution module, or using the freeform defect logging functionality.
As the bugs are logged, the project managers work with the developers and testing team to fix and verify all the bugs until the system is deemed sufficiently stable for release, based on the defined acceptance criteria. For example the criteria could be: "all P1-3 bugs are fixed and all P1-3 test cases have been passed during the most recent retest".
Operations & Maintenance
Once the system is released, the SDLC doesn't end there. Using our KronoDesk help desk tool, the end users will have a way to report any support issues that they run into during normal operation.
If common trends are identified, the support team can work with the developers and testers to release knowledge base articles to help users and if issues are found, to log them through into SpiraTeam using the pre-built integration between KronoDesk and SpiraTeam.
In addition, the ideas and suggestions from the end users will be cycled back into the Concept of Operations phase for the next release of the system, using the same V-Model process.