Best choice of SDLC

Question

I am studying SDLC models from a book. While attempting the exercise questions, I found these questions:

1. What is the best choice among process models to address tight schedules and cost of the software precisely?
2. What should be the best choice among different process models for development of any general software, such as library information system or inventory management system?
3. What are the best best areas of application of V-shape model?

Based on what I've learned, I think the answers are:

1. Spiral model. In this model risk analysis is done repeatedly at the start of any iteration.
2. I am not sure if we can have a "generalized" model for a general software. The most generalized model according to my learning is Waterfall as it has phases applicable to almost all types of software. But again it has its own limitations.
3. I can't think of applications where V-model is the best as it too is an extension of Waterfall model and is not considered to be practical.

Please correct me if I am wrong in answering these questions.

Answer 1

What is the best choice among process models to address tight schedules and cost of the software precisely?

It depends on what process models you are choosing. The Spiral Model does indeed to a better job than many at working within the constraints of a predefined schedule and gives good visibility into progress and has low overhead.

In his book Rapid Development, Steve McConnell identifies 10 different process models - Pure Waterfall, Code and Fix, Spiral, Modified Waterfalls (which includes a few variants), Evolutionary Prototyping, Staged Delivery, Evolutionary Delivery, Design-to-Schedule, Design-to-Tools, and using Off-the-Shelf Software (no development - purchase and integrate existing software).

Of his 10 models, Design-to-Schedule, Design-to-Tools, and Off-the-Shelf Software are the best at fitting into a predefined schedule. Pure Waterfall, Spiral, Modified Waterfalls, and Staged Delivery do a fair job. Spiral, Design-to-Tools, and Evolutionary Delivery are the best at managing cost and providing visibility.

Design-to-Tools and Design-to-Schedule aren't very common when talking about design methodologies at a high level. The idea behind Design-to-Tools is that you only design and implement things that are already supported by tools like libraries, code generators, and so on. You gain speed by focusing on integration, but lose control over the features since you don't implement novel functionality. Design-to-Schedule is like staged release, but you don't know how many releases you'll actually achieve.

If I had to choose a commonly discussed model, I would probably go with Spiral Model. But it depends on what the full set of process models to choose from are.

What should be the best choice among different process models for development of any general software, such as library information system or inventory management system?

There's no singular best choice - every development project is different. Referring back to Steve McConnell's Rapid Development, he rates his lifecycle models on various categories - working with poorly understood requirements, working with poorly understood architectures, ability to produce highly reliable systems, managing risks, customer visibility, management visibility, sophistication of development team, and others. And this is only one way to slice it.

What are the best best areas of application of V-shape model?

There are different representations of the V Model. Wikipedia identifies two common ones - Das V-Modell (commonly found in Germany), which is a project management methodology that includes quality management and control, and the more commonly used mapping between software testing activities and lifecycle activities.

The V-model really isn't a lifecycle model of it's own. It's often depicted as a waterfall, but the same left-side development activities are found in just about every project - there are always requirements, architecture, design, and code. The right side of the V maps testing activities to these. For example, your code maps to unit tests, your low level design maps to integration tests, your software requirements map to software verification and validation tests, your system requirements map to system verification and validation, and your concept of operations is tested by actually operating the software system in its deployment environment.

It doesn't matter what form these activities and outputs come in. Requirements may be a user story or a software requirements spec. Either way, once you have a stable requirement, you can use that requirement to begin to plan acceptance specifications. Likewise, whenever you have an idea of the code you are writing, you can begin to write unit tests.