It sounds like you are describing what Steve McConnell called Waterfall with Subprojects. In this methodology, you waterfall through conceptualization, requirements engineering, and architectural design. Then, for every major component, you then proceed through a detailed design, coding, and testing phase. At the end, you integrate the components in a system testing phase.
Typically, this is done by multiple teams at the same time, each working on a separate component. However, because you were working alone, it probably resembled a more iterative approach. The key difference between Waterfall with Subprojects and a true iterative approach is when you do the integration. In Waterfall with Subprojects, it comes at the completion of all subprojects. With a truly iterative approach, it happens continuously and you are fully integrated at the end of every iteration.
V-model is an extension of Waterfall model, so don't expect it to be hugely different.
Basically, you follow V-model from left to right, just like in Waterfall model. In Waterfall, you do requirements, design, implementation, verification and finally maintenance. In the same way, in V-model, you do requirements, design, implementation, verification and maintenance: same steps in both cases.
The major differences with Waterfall are the way it is presented and the emphasis on testing.
Representing the flow as V-shape helps making the difference between everything which comes prior to coding (requirements, architecture and design) and everything which follows coding (essentially testing). While tests are just one of five steps in Waterfall, it looks like practically half of the process in V-model.
The diagram in your question is a bit more complicated. What it tries to show is that, for example, system design step leads not only to the system design document, like Waterfall model would suggest, but also the system tests design, which will later help writing system tests. The diagram just puts even more emphasis on testing. Finally, doing system test design helps in architecture design (it would be awkward to do architecture design regardless system test design).
Searching what other explanations on the internet, I can't avoid quoting the following article by Bhakti Satalkar:
The main difference between waterfall model and V model is that in waterfall model, the testing activities are carried out after the development activities are over. On the other hand in V model, testing activities start with the first stage itself. In other words, waterfall model is a continuous process, while the V model is a simultaneous process. As compared to a software made using waterfall model, the number of defects in the software made using V model are less. This is due to the fact, that there are testing activities, which are carried out simultaneously in V model. Therefore, waterfall model is used, when the requirements of the user are fixed. If the requirements of the user are uncertain and keep changing, then V model is the better alternative.
This explanation is misleading. It would be true only if you replace “V-model” in the quote by any Agile method.
Unlike the article states, in V-model, testing is done after the coding; for example, see Wikipedia:
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.
While, in V-model, system test design follows system design without waiting until product implementation is done, this doesn't mean that tests themselves are performed before coding. The author confounds V-model with Agile approaches like Test Driven Development (TDD) in Extreme Programming (XP).
Best Answer
The spiral software development process model is similar in structure to the waterfall model in that it follows a general flow:
Requirements -> Design -> Implementation -> Verification
That's pretty much what you see in the bottom right quadrant of the spiral diagram above. The difference is the spiral has a focus on risk and it also prescribes review and planning at each iteration of the spiral.
Concept of Operations is a pre-requirements document. It's pretty much a description of the software product before requirements are elicited. "S/W Requirements" refers to a formal specification of software requirements like a software requirements specification (SRS). Requirement validation is essentially testing for your requirements document to make sure that requirements are complete, unambiguous, verifiable, etc. "Product design" is architecture and high level design of the system. "Design V&V" is validation and verification of the product design.
Coding (or "prototyping") is done in each iteration of the sprial on the prototype (see the top right quadrant). In the fourth iteration when production coding begins, the prototype may be thrown out. The production code is written in the fourth iteration. It's not clear to me if the model addresses maintenance releases after the fourth iteration.
Although the sprial has "iterations" it's completely different from an iterative or incremental model where design, development, and testing is done in a cycle until the product is finished.