Answer: (ii) Inability to manage complex software projects effectively

The Software Crisis (late 1960s onwards) refers to the widespread project failures — late deliveries, blown budgets, buggy software, and projects abandoned altogether — caused primarily by the growing complexity of software and the industry's inability to manage large, complex software projects using ad-hoc, unstructured methods.

Why the others are wrong:

• (i) Lack of programming languages — by the 1960s many languages (FORTRAN, COBOL, ALGOL) existed; the problem was not language availability.
• (iii) Insufficient hardware resources — hardware was advancing rapidly; the bottleneck was software management, not machine resources.
• (iv) Overuse of automation — automation was minimal; this was never the crisis trigger.

The crisis motivated the birth of software engineering as a discipline (application of engineering principles to software development), introducing structured processes, requirements analysis, design, testing, and project management.

Answer

(ii) Barry Boehm

Explanation

The Spiral Model was proposed by Barry Boehm. It is a risk-driven software development model that combines iterative development with systematic aspects of the waterfall model.

Final answer: (ii) Barry Boehm

Answer: (iii) Difficulties in managing the software projects

The Software Crisis refers to the period (from the late 1960s) when software projects increasingly failed — late deliveries, cost overruns, unreliable products. Its root cause was difficulties in managing complex software projects (poor planning, estimation, and process discipline), not technology shortages.

Why the others are wrong:

• (i) Lack of programming languages — many languages (FORTRAN, COBOL, etc.) already existed.
• (ii) The inability to write the software efficiently — writing code is not the core problem; managing large projects is.
• (iv) Failure of hardware components — hardware was improving; it was not the issue.

The crisis led to the emergence of software engineering as a disciplined, managed activity.

Solution

Correct Answer: (iii) Spiral

Explanation

The Spiral Model (Barry Boehm) is a risk-driven process model. Every loop of the spiral contains an explicit Risk Analysis phase, where risks are identified and resolved (often through prototyping) before the next loop begins.

Why other options are incorrect:

• (i) Waterfall - Linear and sequential; has no explicit risk analysis step.
• (ii) Code-and-Fix - Ad hoc coding with no planning or risk handling.
• (iv) Incremental - Delivers the product in increments, but does not build risk analysis into every cycle.

Key Points to Remember:

• Four quadrants of Spiral: Objective Setting, Risk Assessment & Reduction, Development & Validation, Planning.
• Best suited for large, complex, high-risk projects.

Answer: (iii) Spiral

Solution

Correct Answer: (iv) linear model and Prototyping model

Explanation

Incremental Model delivers system in increments (builds).

• Linear model (Waterfall) provides sequential phases (requirements→design→code→test) for each increment.
• Prototyping provides iterative feedback and early versions for each increment before final integration.

So each increment follows linear sequence, but overall product evolves via prototypes/increments.

Why others wrong:

• (i) Build-and-Fix is ad-hoc, not a model
• (ii) RAD is itself an incremental/high-speed variant, not parent
• (iii) Waterfall + RAD is redundant (RAD already contains incremental)

Answer: (iv) linear model and Prototyping model

Solution

Correct Answer: (ii) Barry Boehm

Explanation

The Spiral Model was originally proposed by Barry Boehm in his 1986 paper "A Spiral Model of Software Development and Enhancement".

It is a risk-driven evolutionary process model that combines features of the Waterfall and Prototyping models.

Why other options are incorrect:

• (i) IBM - Associated with early software processes but not spiral model
• (iii) Pressman (Roger Pressman) - Author of SE textbook, explained the model but did not propose it
• (iv) Royce (Winston Royce) - Proposed the Waterfall Model (1970), not Spiral

Key Points to Remember:

• 4 Quadrants of Spiral: 1. Objective Setting 2. Risk Assessment & Reduction 3. Development & Validation 4. Planning
• Best suited for large, complex, high-risk projects.

Answer: (ii) Barry Boehm

Solution

Correct Answer: (iii) Essential complexity of software

Explanation

In his paper "No Silver Bullet" (1986), Fred Brooks separates software difficulty into:

• Accidental complexity - caused by tools, languages and methods; technology can reduce it.
• Essential complexity - inherent in the problem itself (complexity, conformity, changeability, invisibility).

His argument: no single technique can give an order-of-magnitude improvement in productivity, because the hard part is the essential complexity of the problem, not the tools.

Why other options are incorrect:

• (i) Hardware cost and (iv) Database size - not part of Brooks' argument.
• (ii) Compilation time - a tool-level (accidental) issue.

Answer: (iii) Essential complexity of software

Answer: (iii) Spiral model

The Spiral model (Boehm, 1986) is the SDLC model that explicitly emphasizes risk analysis at every phase of development. Each loop (iteration) of the spiral walks through four quadrants:

1. Determine objectives (of the current iteration),
2. Identify and resolve risks — risk analysis/prototyping of risky areas,
3. Development and testing of the product increment,
4. Planning of the next iteration (customer evaluation/review).

The radius of the spiral grows with each iteration, and each pass increases the level of the product. Because the model returns to risk analysis in every loop, it is the best fit for large, high-risk, and complex projects.

Why the others are wrong:

• (i) Waterfall — a purely linear, sequential model with no explicit risk-analysis step.
• (ii) Incremental — delivers the product in parts; risk analysis is not its defining feature.
• (iv) Prototype — focuses on building throwaway prototypes to clarify requirements, not on iterative risk analysis.

Answer: (ii) Spiral Model

The Spiral model (Boehm) is the SDLC model that emphasizes iterative development — the software evolves through repeated loops, each pass refining the product and adding functionality while incorporating risk analysis, development, testing, and customer evaluation at every cycle.

Why the others are wrong:

• (i) Waterfall model — a purely linear/sequential model, not iterative.
• (iii) Code-and-Fix model — a simplistic informal "code then fix problems" approach, not a structured iterative model.
• (iv) Prototyping — although prototypes are built in iterations, the classic model that emphasizes iterative development combined with risk analysis is the Spiral model; prototyping is focused on requirement clarification rather than full iterative development.

So the model that emphasizes iterative development is the Spiral Model — option (ii).

Answer: (iii) Essential complexity of software

In his famous 1987 essay "No Silver Bullet — Essence and Accidents of Software Engineering", Frederick Brooks argues that the greatest difficulty in software engineering is the essential complexity of the software itself — the inherently complex conceptual structures (the "essence" of the problem) that cannot be removed by any tool, methodology, or "silver bullet"—unlike accidental complexities (programming language quirks, tooling) which can be reduced.

Why the others are wrong:

• (i) Hardware constraints — hardware has improved dramatically; it is not the fundamental bottleneck.
• (ii) Lack of skilled developers — a real concern but not the essential difficulty Brooks highlights.
• (iv) Inadequate documentation — an accidental/practice problem, not the inherent nature of software.

Brooks concludes that no single breakthrough can achieve an order-of-magnitude improvement in productivity, reliability, or simplicity because the essential complexity — requirements, design, interlocking concepts — is inherent to software.

Solution

Correct Answer: (b) Prototyping

Why?

When developing a GUI (Graphical User Interface), users need to see and interact with the interface early so that the design can be reviewed and improved through multiple iterations.

The Prototyping Model is well suited for this because it allows developers to:

• Create an early working model of the interface.
• Get quick feedback from users.
• Identify usability and design issues early.
• Refine the GUI through repeated iterations.

Why not the others?

• Spiral: Primarily focuses on managing risks in large and complex projects.
• Iterative Waterfall: Follows a more structured sequence and is less suited to rapid UI experimentation.
• Evolutionary: Evolves the system incrementally, but the standard model specifically associated with quickly exploring and refining a GUI is Prototyping.

Exam Tip: For questions about quickly designing, showing, testing, and refining a GUI, remember Prototyping Model → rapid visual feedback and iteration.

Solution

Correct Answer: (ii) Built-and-fix model

Explanation

Built-and-Fix (also called Build-and-Fix / Ad-hoc / Code-and-Fix):

• No formal design, just code → fix until works.
• Students use it for small assignments due to no planning overhead, immediate coding.

Other models too heavy for student programs:

• Waterfall needs full documentation
• Spiral/RUP are for large industrial projects.

Hence most popular for student programs is Build-and-Fix (though not recommended for professional work).

Answer: (ii) Built-and-fix model

Solution

Correct Answer: (a) Spiral Model

Explanation

Spiral Model is risk-driven - each loop has Risk Analysis quadrant (Boehm). Potential risks (technical, cost, schedule) best detected early via prototype and risk assessment.

• Waterfall detects risk late (testing)
• Incremental delivers but less risk focus
• Prototyping addresses UI risk only

Answer: (a) Spiral Model

Solution

Correct Answer: (iii) Parkinson's law

Explanation

• Parkinson's Law: "Work expands to fill the time available for its completion." → If 1 month work given 2 months, it will take 2 months.
• CASE tool - Software aid, not a law
• Pricing to win - Cost estimation strategy (bid low to win contract)
• Expert judgment - Estimation technique using expert opinion

Answer: (iii) Parkinson's law

Solution

Correct Answer: (iii) Statement is false

Explanation

Definition (IEEE): Software is collection of executable programming code, associated libraries and documentations - This statement is TRUE in standard view. So saying "Software is NOT considered to be collection..." is FALSE.

Options:

• (i) Statement is true → wrong, statement undervalues software
• (ii) Software is only data structures with algorithms → incomplete definition
• (iii) Statement is false → correct, software is considered that collection
• (iv) Statement underestimates software → also arguable, but (iii) is more direct correct as per exam key (software is that collection plus documentation). Some keys mark (iv) - but official Mumbai key is (iii) Statement is false.

Answer: (iii) Statement is false (alternative accepted: iv - statement underestimates software, as modern definition includes config data, docs, etc.)

Answer

(iii) Statement is false

Explanation

Software is more than executable code. It includes programs, associated data/configuration, libraries or other supporting components, and documentation required for operation, maintenance and use.

Therefore the statement saying software is not considered such a collection is false.

Final answer: (iii) Statement is false

Solution

Classical Waterfall Model (Winston Royce, 1970) - Detailed

Diagram:

Requirements Analysis & Specification
        ↓  (SRS Document)
System & Software Design
        ↓  (Design Docs)
Implementation (Coding)
        ↓  (Code)
Testing (Verification)
        ↓  (Test Report)
Deployment
        ↓
Maintenance

Each phase feeds next; verification at each gate; no overlap.

Phases in Detail:

1. Requirements - Elicit, analyze, specify, validate → SRS. Output: SRS.
2. Design - Architecture, DFD, ERD, modular decomposition, interface specs. Types: High-level & Detailed.
3. Implementation - Code as per standards, unit testing per module.
4. Testing - Integration + System testing against SRS; alpha/beta.
5. Deployment - Delivery, installation, user training.
6. Maintenance - Corrective, Adaptive, Perfective, Preventive (60% of lifecycle cost).

Advantages: Simple, easy to manage, document-driven, suitable for small stable projects.

Limitations: No working model till late, high risk, poor for changing requirements, not suitable for large complex/OO projects.

Advantages of the Spiral Model over the Basic Waterfall Model

The Spiral Model, proposed by Barry Boehm, is an iterative and risk-driven development model. Unlike the basic Waterfall Model, development proceeds through repeated cycles.

Major advantages

1. Risk analysis: Risks are identified and addressed explicitly in every spiral cycle.
2. Early customer feedback: Customers can review prototypes and intermediate versions early.
3. Handles changing requirements: Requirements can be refined as the project progresses.
4. Early prototyping: Prototypes can be developed to clarify uncertain requirements or technology.
5. Incremental development: The product grows through successive iterations rather than one final delivery.
6. Better visibility: Each cycle produces measurable work products and review points.
7. Suitable for large, complex projects: It is useful when technical or business risks are high.
8. Flexible: Changes can be incorporated without restarting the entire development process.
9. Continuous verification: Each iteration includes evaluation and review.

Spiral vs Waterfall

Waterfall	Spiral
Mostly sequential	Iterative
Risk analysis is not the central driver	Risk analysis is central
Changes are expensive after a phase is completed	Changes can be incorporated between iterations
Customer feedback is relatively late	Customer feedback occurs repeatedly
Best when requirements are stable	Useful when requirements/risks are uncertain

Conclusion: The spiral model provides greater flexibility and systematic risk management than the basic waterfall model, although it is more complex and can cost more to manage.

Waterfall vs Spiral Model — Comparison

Waterfall Model

A linear-sequential model where each phase (Requirements → Design → Implementation → Testing → Deployment → Maintenance) must be fully completed before the next begins, with formal documents at each stage.

Features: rigid phase gates, no overlapping phases, requirements frozen early, heavy documentation.

Best for: small/medium projects with clear, stable, well-understood requirements; projects where the technology is known.

Drawbacks: changes are difficult/expensive to accommodate; errors discovered late are very costly; users see the product only at the end.

Spiral Model

An iterative (evolutionary) model where each loop of the spiral passes through four quadrants: planning → risk analysis → engineering (build/test) → customer evaluation, progressively developing prototypes/increments. It is driven by risk analysis.

Features: iterative refinement; each cycle adds functionality; risk-driven; customer feedback each cycle; combines features of waterfall + prototyping.

Best for: large, complex, high-risk projects (mission-critical, embedded systems); projects where requirements are uncertain.

Drawbacks: expensive (requires skilled risk analysts); can be slow; hard to manage with fixed budgets; not suitable for small/low-risk projects.

Comparison table

Aspect	Waterfall Model	Spiral Model
Approach	Linear, sequential	Iterative (spiral loops)
Risk analysis	Not explicitly handled	Central — done every cycle
Requirements	Fixed early; changes hard	Can evolve each iteration
Customer involvement	Only at milestones	At every cycle (evaluation)
Prototyping	Not used	Used for risky areas
Documentation	Heavy	Moderate (per cycle)
Cost	Lower for simple projects	Higher (risk experts, repeated cycles)
Suitability	Clear, stable requirements	Complex, high-risk, evolving projects
Feedback	Late (after delivery)	After each iteration
Management	Simple milestones	Requires risk-management discipline

Summary

• Waterfall = simple, linear, best when requirements are fixed and the project is low-risk.
• Spiral = iterative, risk-driven, best for large, complex, high-risk systems.
  The choice depends on project size, requirement stability, and risk level.

Decision Matrix: Waterfall vs Incremental vs Spiral for a Safety-Critical System

Selection criteria

For a safety-critical system a failure can cause injury or loss of life, so risk handling matters most. The other criteria are requirement volatility, feedback and delivery.

Comparative matrix

Criterion	Waterfall	Incremental	Spiral
Risk	Weak: risks surface late, mostly during testing	Moderate: risk handled per increment	Strong: explicit risk analysis in every loop
Requirement volatility	Poor: requirements frozen early	Good: new needs go into later increments	Good: requirements refined every loop
Feedback	Late: only after testing/delivery	After every increment	After every loop (prototype + review)
Delivery	Single big-bang release	Early partial working releases	Versions/prototypes; final release after several loops

Weighted score (scale 1 to 5, illustrative)

Criterion (weight)	Waterfall	Incremental	Spiral
Risk (0.4)	2	3	5
Volatility (0.2)	1	4	4
Feedback (0.2)	1	4	4
Delivery (0.2)	2	5	3
Weighted total	1.6	3.8	4.2

Example: Spiral = 0.4(5) + 0.2(4) + 0.2(4) + 0.2(3) = 4.2.

Justification

• Risk has the highest weight because hazards in a safety-critical system must be found and removed early.
• Spiral scores highest: each loop has a risk-analysis step, prototypes are evaluated, and verification can be repeated before the next loop.
• Waterfall gives strong documentation but finds risks too late and cannot absorb change.
• Incremental gives early feedback but has no built-in risk analysis.

Decision: Spiral, keeping Waterfall-style rigorous documentation, reviews and verification inside each loop. If the requirements are well understood and risk is low, Incremental is the fallback.

Note: scores and weights are judgement-based; state your assumptions in the exam.

Characteristics of Software vs Hardware

Software is a logical, non-physical product and differs fundamentally from hardware. The classic distinguishing characteristics (per Pressman/Sommerville):

1. Software is developed/engineered, not manufactured

• Hardware: after design, mass-manufactured (identical copies are cheaply produced on a production line, e.g., a chip made millions of times).
• Software: after design, it is created once and copied — every copy costs almost nothing, but the "manufacturing" is the one-time development cost. Quality must be built in during design, not added later on a production line.

2. Software does not "wear out" (but it does degrade)

• Hardware: follows a bathtub curve — high early failure rate (infant mortality), then a low constant failure rate, then rising failures as components wear out (corrosion, fatigue).
• Software: does not wear out physically. Failures come from design/latent defects, which surface when new usage paths are exercised. Over time, repeated changes introduce new errors, so the software appears to degrade (the "deterioration" is really a result of changes/de-facto error introduction), until it is re-engineered or retired.

3. Much of software is custom-built, not assembled from components

• Hardware is largely built from standard off-the-shelf components.
• Software components are more custom and intertwined; true component reuse is harder, so most software is constructed to fit a specific customer.

4. Software is intangible / loses its nature over time

• Software has no physical mass; it appears as programs, data, and documents. Project progress is not visible ("software has no physical presence"), making schedule and progress measurement difficult compared to hardware.

5. Software is complex, changeable, and not governed by physical laws

• Complexity is inherent (Brooks' essential complexity). Software is flexible — it can be changed late in the cycle more easily than hardware — but this flexibility also invites requirements churn ("software can be changed at any time").
• No physical constraints (no friction, no gravity) govern software, so its behaviour is discrete/logical, and all failures trace back to human/design errors.

Summary table

Aspect	Hardware	Software
Production	Manufactured in volume	Developed once, then copied
Failure pattern	Wears out (bathtub curve)	Doesn't wear out; fails from design defects
Change	Physically expensive to change	Easy to change logically, but risky to manage
Tangibility	Physical	Intangible (logic)
Scope of reuse	Standard components common	Reuse still difficult
Quality focus	Production process	Design and process discipline

Solution

What is Software Engineering?

Definition (IEEE): Application of systematic, disciplined, quantifiable approach to development, operation and maintenance of software.

Definition (Fritz Bauer, 1969): Establishment and use of sound engineering principles to obtain economically software that is reliable and works efficiently on real machines.

Nature: Layered Technology:

• Quality Focus (bedrock)
• Process (framework: SDLC, Umbrella activities)
• Methods (technical how-to: analysis, design, testing)
• Tools (CASE automation)

Goal: Deliver high-quality software on time, within budget, meeting user needs (resolve Software Crisis of 1960s).

Solution

1. Waterfall Model (Classic / Linear Sequential)

Definition: Oldest SDLC, proposed by Winston Royce (1970). Phases in linear cascade where each phase must complete before next begins. Output of one is input to next. No overlap.

Phases:
Requirements → System & Software Design → Implementation (Coding) → Testing (Verification) → Deployment → Maintenance

Requirements
     ↓
  Design
     ↓
Implementation
     ↓
 Verification
     ↓
 Maintenance

Characteristics: Simple, document-driven, easy to manage. Each phase has review & gate.

2. When to Prefer Spiral over Waterfall

Spiral is risk-driven, iterative, incremental (Barry Boehm, 1986). Four quadrants per loop: Objective setting, Risk analysis, Development, Planning.

Prefer Spiral when:

Condition	Why Waterfall fails
High risk / unknown requirements	Waterfall assumes frozen requirements
Large, complex, innovative projects	Spiral prototypes & risk mitigation each loop
Requirements change frequently	Waterfall costly to change later
Need early risk detection (technical/feasibility)	Waterfall discovers risk late in testing
Long-term projects needing incremental releases	Spiral gives successive prototypes
Budget / cost uncertainty	Spiral evaluates cost-risk each cycle

Example Situations:

• New OS / AI product where feasibility unknown
• Defence / aerospace where failure cost high
• Startup product with evolving customer needs

Conclusion: Use Waterfall for small, well-understood, stable-requirement projects (e.g., payroll system). Use Spiral for large, risky, complex projects.

Agile Development vs Conventional Sequential Process

Sequential process (e.g. Waterfall): requirements, design, coding, testing and delivery happen once, in fixed order.
Agile: software is built in short iterations (sprints) of 1 to 4 weeks, each producing a working increment, with continuous customer involvement.

Comparison

Aspect	Agile	Conventional sequential
Iteration	Many short iterations; every cycle repeats analysis, design, code and test	Single pass through each phase; no return to earlier phases without rework
Customer participation	Continuous: customer reviews every iteration and prioritizes the backlog	Mainly at the start (requirements) and end (acceptance)
Requirement change	Welcomed, even late; changes enter the backlog for later sprints	Resisted; requirements frozen early, changes are costly
Software delivery	Frequent, working increments (every sprint)	One delivery at the end of the project
Documentation	Light; working software valued over documents	Heavy, formal, phase-wise
Risk	Found early through frequent feedback	Found late, during testing
Planning	Adaptive; plan per iteration	Detailed up-front plan
Suitable for	Changing or unclear requirements	Stable, well-understood requirements

Conclusion

Agile gives faster feedback, easier handling of change and earlier value to the customer. A sequential process gives predictability and thorough documentation, which suits fixed, stable requirements. Examples of Agile methods: Scrum, XP, Kanban.

Solution

Software Engineering Process

Set of framework activities + umbrella activities to build software.

Framework Activities:

1. Communication - Requirement elicitation from stakeholders
2. Planning - Estimation, scheduling, risk
3. Modeling - Analysis (requirements model) + Design (architecture, component)
4. Construction - Code generation + Testing
5. Deployment - Delivery, support, feedback

Umbrella Activities (throughout):

• Project tracking, Risk management, Quality assurance, Configuration management, Technical reviews, Measurement

Process provides structure and stability to produce quality product predictably. Models include Waterfall, Incremental, Spiral, Agile.

Software Myths — Definition & Types

Definition

Software myths are misleading, erroneous beliefs about software and the software process that have been propagated over the years. They can cause serious problems because they set unrealistic expectations and encourage bad practices — for management, customers, and developers alike. They are dangerous precisely because they "sound reasonable."

Types of Software Myths (Pressman's classification)

1. Management myths (believed by managers)

• "We already have a book of standards and procedures for building software — that's all my people need." — Standards without a proper, well-defined process don't guarantee quality.
• "If we get behind schedule, we can add more programmers and catch up." — Adding people late to a project often slows it down (communication overhead, re-training) — the "Mythical Man-Month" effect.
• "We can outsource/copy and adapt software from another project, so it will be cheap and quick." — Software is rarely that portable; adapting external software still requires full engineering.

2. Customer myths (believed by customers)

• "A general statement of objectives is enough; you (developers) can fill in the details later." — Ambiguous requirements lead to the wrong product; detailed requirements must be agreed before design.
• "Software requirements change continuously, but change is easy to absorb." — The cost of change grows steeply as the project progresses; changes are cheapest early and very expensive late.

3. Practitioner (developer) myths (believed by developers)

• "Once the program is written and 'works', our job is done." — Programs that appear to work may still be full of defects; "working" ≠ correct/reliable/maintainable.
• "Until I get the program running, I have no way of assessing its quality." — Quality (reviews, design assessment) can and must be evaluated from the very first phase.
• "Software engineering is just about producing documentation — it makes the work slower." — The discipline (reviews, testing, planning) reduces overall cost by preventing rework.
• "Testing will make the software reliable." — Testing can find defects but cannot prove their absence; reliability is designed-in, not added by testing.
• "The only deliverable is the working program." — Documentation, models, and specs are essential for maintenance and future evolution.

Why they matter

Each myth, if believed, causes poor decisions: skipping requirements, overstaffing late, treating testing as a safety net, ignoring documentation — all of which inflate cost and destroy quality. Recognizing and dispelling these myths is a first step toward a disciplined software process.

Summary table

Category	Example myth	Reality
Management	"More programmers = faster"	More people late = slower
Customer	"Details can be filled in later"	Late change is very costly
Practitioner	"It runs, so it's done"	Working ≠ correct, reliable, maintainable

Software Development Life Cycle (SDLC) + Waterfall vs Agile

SDLC — Phases

The Software Development Life Cycle is a structured process for developing software. Its phases:

1. Communication / Requirement Gathering — collecting user & system requirements, feasibility study.
2. Planning — project planning, estimation, scheduling, risk analysis.
3. Modeling / Analysis & Design — analyzing requirements; producing design (architecture, data design, interface design).
4. Construction / Coding — implementation of the design in code (unit testing during coding).
5. Testing — verification & validation, defect fixing (integration, system, acceptance).
6. Deployment / Delivery — installation, release, user training.
7. Maintenance — corrective, adaptive, perfective, preventive changes after delivery.

Any SDLC model arranges these phases in a particular order with particular feedback.

Waterfall Model

• Linear-sequential: each phase must be completed before the next begins; no overlap; document-driven.
• Phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance (with strict phase-exit gates).
• Advantages: simple, disciplined, well-documented; works when requirements are fixed and clear; easy to manage milestones.
• Disadvantages: no feedback loops; late discovery of requirement/design errors is costly; not suitable for uncertain/volatile requirements.

Agile Model

• Iterative-incremental: the product is built in short sprints/iterations (1–4 weeks), each delivering a working increment.
• Principles: customer collaboration over contract negotiation, working software over comprehensive documentation, responding to change over following a plan; continuous feedback, self-organizing teams, daily stand-ups, frequent releases (Scrum, XP, Kanban).
• Advantages: adaptable to changing requirements; early and continuous delivery of value; high customer involvement; risks visible early.
• Disadvantages: less emphasis on documentation; requires close/full-time customer availability; hard to scale/estimate precisely for very large distributed projects.

Comparison table

Aspect	Waterfall	Agile
Approach	Linear sequential	Iterative & incremental
Requirements	Fixed/known upfront	Evolving; change welcomed
Customer involvement	At milestones	Continuous throughout
Delivery	Single release at end	Frequent working increments
Documentation	Heavy/documented	Minimal ("just enough")
Feedback	Late (after phase)	Each iteration
Best for	Stable, well-understood projects	Dynamic, evolving requirements
Risk handling	High risk if delayed discovery	Risks surfaced early per sprint

Solution

Waterfall Model in Detail (with Diagram)

See Q37 for diagram/phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance (linear, no overlap, gated).

Advantages:

• Simple, easy to understand and manage
• Clear milestones, documentation at each phase
• Works well for small, stable-requirement projects
• Discipline, predictability

Limitations:

• No working software till end → late risk discovery
• Difficult to accommodate change (frozen SRS)
• Customers see product late (poor feedback)
• Not suitable for large, complex, OO, high-risk projects
• Testing only at end → costly fixes

Ideal for: payroll, library systems where requirements well-understood.

Software Cost Estimation and Boehm's COCOMO Model

1. Software cost estimation

Software cost estimation is the process of predicting the effort, development time and cost required to develop and maintain a software system.

It is usually based on factors such as:

• Size of the software, often measured in KLOC (thousand lines of code).
• Required reliability and complexity.
• Team capability and experience.
• Tools and technology.
• Schedule and development environment.

2. Basic COCOMO

Boehm's COCOMO (Constructive Cost Model) estimates development effort and schedule from software size.

For the basic model:

Effort (person-months) = a × (KLOC)^b

Development Time (months) = c × (Effort)^d

The coefficients depend on the project mode.

Mode	Effort equation	Time equation
Organic	2.4 × KLOC^1.05	2.5 × Effort^0.38
Semi-detached	3.0 × KLOC^1.12	2.5 × Effort^0.35
Embedded	3.6 × KLOC^1.20	2.5 × Effort^0.32

3. Given problem

Embedded project = 50 KLOC

For an embedded project:

Effort = 3.6 × (50)^1.20

Effort ≈ 393.61 person-months

Now calculate development time:

Tdev = 2.5 × (393.61)^0.32

Tdev ≈ 16.92 months

Final result

• Estimated effort ≈ 393.6 person-months
• Estimated development time ≈ 16.9 months (about 17 months)

Exam note: This calculation uses the Basic COCOMO coefficients for the Embedded mode, which is the standard interpretation of the question.

Solution

Prototyping Model

Definition: Build quick prototype (throwaway or evolutionary) to clarify unclear requirements via customer feedback, then build actual product.

Steps: Requirements Gathering (vague) → Quick Design → Build Prototype → Customer Evaluation → Refine Prototype → Engineer Final Product

Advantages:

• Requirement clarity, better customer involvement
• Early risk detection, reduces rework
• Demonstrates feasibility

Problems / Disadvantages:

• Customer may confuse prototype with product (expects quick delivery)
• Developer may take shortcuts (poor design compromises)
• Scope creep, cost/schedule uncertainty
• Extra effort if throwaway prototype discarded

Use when: Requirements vague, GUI-heavy, innovative, human-computer interaction systems.

Solution

(i) Project Manager

Role: Overall leadership, responsible for success/failure.
Responsibilities: Project planning, scheduling, budgeting, resource allocation, risk management, stakeholder communication, monitoring & control, delivery & closure. Makes go/no-go decisions.

(ii) Project Leader / Team Lead

Role: Technical lead for a module/team, bridge between manager and developers.
Responsibilities: Task breakdown & assignment, technical guidance, code reviews, daily stand-ups, resolving technical impediments, status reporting to PM, ensuring quality & deadlines for his team.

(iii) System Analyst

Role: Bridge between customer and development team.
Responsibilities: Requirement elicitation & analysis, feasibility study, modelling (DFD/ERD/UML), preparing SRS, prototyping, validating requirements with client, assisting in system design. Ensures what to build is correct.

(iv) Developer / Programmer

Role: Implements the system.
Responsibilities: Detailed design, coding as per standards, unit testing, debugging, documentation, integration support, maintenance fixes. Follows coding guidelines and participates in reviews.

Together they form the classic hierarchy: Manager → Leader → Analyst → Developer covering management, analysis, and construction.

People Selection, Motivation, Team Effectiveness and PSP

Software quality depends heavily on the people who develop it. A project manager must build a team with suitable skills, keep members motivated and make the team work effectively.

1. People selection

The manager should match people to roles based on:

• Technical knowledge and experience.
• Problem-solving ability.
• Communication skills.
• Ability to work in a team.
• Reliability and discipline.
• Interest in the project and willingness to learn.

Poor selection can lead to skill gaps, conflicts, delays and defects.

2. Motivation

Common motivators include:

• Meaningful and challenging work.
• Recognition and constructive feedback.
• Opportunities for learning and career growth.
• Appropriate responsibility and autonomy.
• Fair rewards and working conditions.
• Clear goals.

Managers should understand individual differences rather than assuming the same motivation works for everyone.

3. Team effectiveness

An effective IT team needs:

• Clear roles and responsibilities.
• Shared objectives.
• Good communication.
• Trust and cooperation.
• Appropriate leadership.
• Mechanisms for resolving conflicts.
• Regular progress and quality reviews.

4. Personal Software Process (PSP)

The Personal Software Process is a disciplined process framework that helps individual developers measure and improve their own software work.

Typical PSP practices include:

1. Planning and size/effort estimation.
2. Recording actual time and defects.
3. Design and code reviews.
4. Defect prevention and removal.
5. Postmortem analysis to improve future estimates and practices.

How far can PSP provide a solution?

PSP can improve individual discipline, estimation, quality awareness and defect management. It gives developers quantitative feedback about their own performance and helps them improve their process.

However, PSP does not directly solve organizational problems such as selecting the right people, compensation, leadership, team conflict or company culture. Those require management practices. PSP is therefore a supporting solution, not a complete people-management solution.

Conclusion: Effective software teams require both sound people management and disciplined individual processes such as PSP.

Solution

1. Risk Management Techniques (Any Two)

Risk management is the process of identifying, analyzing, and controlling risks that may affect a software project.

1. Risk Avoidance

Risk avoidance means eliminating the source of a risk so that it does not affect the project.

Example: If the requirements are unclear or technically uncertain, a prototype can be developed first. This helps validate the requirements and feasibility before full-scale development.

2. Risk Transfer

Risk transfer means shifting the responsibility or impact of a risk to a third party.

Example: A company may outsource a technically complex module to an experienced vendor or purchase insurance to transfer the financial impact of a risk.

Other risk-management techniques:

• Risk Reduction/Mitigation: Reduce the probability or impact of a risk, e.g., use incremental development and regular testing.
• Risk Retention/Acceptance: Accept a low-impact risk when the cost of avoiding it is greater than its possible loss.

---

2. Capability Maturity Model (CMM)

The Capability Maturity Model (CMM) defines five levels of software-process maturity. Each higher level represents a more disciplined, measurable, and continuously improving development process.

Neat Diagram

        Level 5 — Optimizing
        Continuous Process Improvement
                    ↑
        Level 4 — Managed
        Quantitatively Managed Process
                    ↑
        Level 3 — Defined
        Organization-wide Standard Process
                    ↑
        Level 2 — Repeatable
        Basic Project Management Processes
                    ↑
        Level 1 — Initial
        Ad-hoc / Chaotic Process

Level 1 — Initial

• The software-development process is ad-hoc and chaotic.
• There are few defined processes or controls.
• Project success depends heavily on individual effort and experience.

Level 2 — Repeatable

• Basic project-management practices are established.
• Requirements, cost, schedule, and project progress are tracked.
• Successful practices from previous projects can be repeated.

Level 3 — Defined

• Software processes are documented, standardized, and integrated across the organization.
• A common standard process is followed by different projects.
• Activities such as training, peer reviews, and process definition are established.

Level 4 — Managed

• Processes and product quality are measured quantitatively using metrics.
• Statistical and quantitative techniques are used to monitor and control processes.
• Management can predict process performance and quality more reliably.

Level 5 — Optimizing

• The organization focuses on continuous process improvement.
• Defects are prevented and processes are improved using measurement and feedback.
• New technologies and improved development practices are adopted when beneficial.
• Key improvement areas include defect prevention, technology change management, and process change management.

Conclusion

Thus, CMM progresses from an uncontrolled/ad-hoc process at Level 1 to a continuously improving process at Level 5.

Solution

What is Risk?

Potential uncertain event that, if occurs, negatively affects project objectives (cost, schedule, quality) - Boehm. Types: Project (staff, budget), Technical (tech failure), Business (market).

Why Analysis is Done?

Risk Analysis = Assess $Probability × Impact$ (Exposure). Purposes:

1. Prioritize - Focus on high-exposure risks first (Pareto)
2. Estimates contingency - Buffer time/budget
3. Mitigation planning - Decide Avoid/Transfer/Reduce/Accept
4. Monitoring - Triggers and tracking
5. Decision making - Go/no-go, prototype vs full build

Without analysis, management is reactive → cost/schedule overrun. With analysis, proactive, reduces failure chance by 30-50%.

Example: $P=0.6, Impact= High (5) → RE=3.0$ gets mitigation budget before $P=0.2, Impact=2$.

Solution

Agile Process

Manifesto: Individuals over processes, Working software over docs, Customer collaboration over contract, Responding to change over plan.

Characteristics: Iterative-incremental, time-boxed sprints (1-4 weeks), continuous feedback, self-organizing teams, CI/CD.

Advantages:

• Fast delivery, early ROI
• Handles changing requirements
• Higher customer satisfaction, quality via continuous testing
• Reduced risk, transparency (daily stand-ups, boards)

One Agile Model - Scrum

Roles: Product Owner, Scrum Master, Dev Team
Artifacts: Product Backlog → Sprint Backlog → Increment
Ceremonies:

1. Sprint Planning
2. Daily Scrum (15 min)
3. Sprint Review (demo)
4. Retrospective

Backlog → Sprint (2 weeks) → Potentially Shippable Increment → Repeat

Example: E-commerce built sprint-wise: Sprint1 login, Sprint2 catalog, etc., with demo to product owner each sprint.

Healthcare Application: Requirement Analysis and SDLC Strategy

1. Requirement analysis

Stakeholders: patients, doctors, administrators, pharmacy/lab staff, payment provider.
Key points: health data is sensitive, so privacy and security are critical; requirements are expected to evolve after the pilot, so the process must absorb change.

2. Major functional requirements

• FR1 Patient registration and login
• FR2 Doctor search and appointment booking
• FR3 Online consultation (video/chat)
• FR4 Upload and view medical reports
• FR5 Doctor issues e-prescription; patient views/downloads it
• FR6 Online payment and receipts
• FR7 Notifications and reminders
• FR8 Admin: manage users, doctors and reports

3. Major non-functional requirements

Quality	Requirement
Security & privacy	Encrypted data, role-based access, consent, audit log, compliance with health-data laws
Availability	High uptime, especially for consultations
Performance	Fast page loads, smooth video, large report uploads
Usability	Simple UI for non-technical patients and elderly users
Reliability/Integrity	Prescriptions and reports must never be lost or altered
Scalability	Handle growth in patients and doctors
Interoperability	Work with payment gateways and hospital systems

4. Appropriate SDLC strategy

Iterative-incremental with prototyping, run in an Agile/Spiral style.

• Requirements are unclear and will change after the pilot, so a one-pass Waterfall is unsuitable.
• Build and release in increments: registration and booking first, then consultation, then reports and prescriptions, then payments.
• Use the pilot deployment as a feedback cycle; update the backlog before the next increment.
• Add a risk review in every cycle (Spiral element) because of the sensitive data.

5. One prototyping activity

Build a throw-away UI prototype of the appointment booking and online consultation flow (clickable wireframes). Show it to a few patients and doctors, collect feedback on screens, navigation and steps, then refine the requirements before coding.

6. Two risks that influence process selection

Risk	Effect on process choice
Requirement volatility after the pilot	Needs an iterative/incremental model with change handling
Data privacy / regulatory compliance and security breaches	Needs early and repeated security review (risk analysis every cycle), traceable documentation

Other possible risks: payment-gateway failures, video-service downtime, low user adoption.

Conclusion

An iterative, incremental, prototype-driven process with risk analysis (Agile/Spiral hybrid) fits best: it manages changing requirements while keeping security and privacy under control.

Solution

PERT Chart

Program Evaluation & Review Technique - Network diagram for uncertain durations. Uses optimistic (O), most likely (M), pessimistic (P) → $T_e = (O+4M+P)/6$. Nodes = events, arrows = activities. Finds critical path (longest). Probabilistic.

O—→A—→B—→ End  (with 3 estimates per arrow)

PERT vs Gantt

Aspect	PERT	Gantt
View	Network / dependencies	Bar chart / timeline
Duration type	Uncertain (3-point)	Fixed/deterministic
Shows dependencies	YES (critical path)	Weakly (bars)
Best for	Large R&D, high uncertainty, interdependent tasks	Small, stable, simple schedule
Complexity	High	Simple visual

When to use:

• PERT: Project manager faces high uncertainty / R&D (e.g., new software product), need to analyze risk and critical path.
• Gantt: Routine / Well-understood project, progress tracking for team, stakeholder presentation.

Often used together: PERT for planning, Gantt for monitoring.

Solution

Risk Management Activities (Boehm / SEI)

1. Risk Identification - List potential risks: product, project, business (e.g., staff turnover, requirement change, tech failure, schedule slippage). Techniques: checklist, brainstorming, Delphi.
2. Risk Analysis - Assess probability ($P$) and impact ($I$), exposure $RE = P \\times I$. Qualitative vs quantitative.
3. Risk Prioritization / Ranking - Order by exposure; Pareto 80/20. High-exposure handled first.
4. Risk Planning / Mitigation - Avoid, transfer, reduce, accept. Contingency plans, prototypes, incremental delivery.
5. Risk Monitoring & Control - Track triggers, reassess, execute mitigation, status reports.
6. Risk Resolution / Mitigation Execution - Implement actions.

Some books group as: Assessment (Identification+Analysis+Prioritization) → Control (Planning+Resolution+Monitoring).

Is Prioritization Possible? YES

Yes, risks MUST be prioritized because resources limited.

Method:

• Compute Risk Exposure = Probability × Impact (or Risk Leverage)
• Build Risk Table sorted descending. E.g.:

Risk	P	Impact (1-5)	RE	Priority
Staff leaving	0.7	4	2.8	1
Requirement change	0.6	3	1.8	2
Tech not mature	0.3	5	1.5	3

• High RE = high priority. Use risk matrix / cutoff.

Example: In E-commerce project, payment gateway integration failure (P=0.5, Impact=5, RE=2.5) is prioritized over minor UI delay (P=0.8, Impact=1, RE=0.8). Top risks get mitigation budget and weekly monitoring; low risks accepted.

Conclusion: Prioritization is not only possible but essential for effective risk management.

Agile Development Process — Detailed Explanation & Advantages

What is Agile?

Agile is an iterative-incremental software development philosophy/methodology that emphasizes early and continuous delivery of valuable working software, customer collaboration, and the ability to respond quickly to change — rather than following a rigid, up-front plan. It emerged from the Agile Manifesto (2001):

We value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan.

How the Agile process works

1. Product backlog — the customer/product owner maintains a prioritized list of requirements (user stories: short descriptions of features from a user's perspective).
2. Sprints/iterations — development occurs in fixed-length cycles (typically 1–4 weeks). Each sprint selects a set of backlog items and delivers a working, potentially shippable increment.
3. Sprint planning, daily stand-ups, sprint review, retrospective — short ceremonies keep the team aligned, demo work, and improve the process each sprint.
4. Continuous feedback — the customer reviews each increment; new/evolving requirements are fed back into the backlog for future sprints.
5. Self-organizing, cross-functional teams — the team collectively plans and owns delivery; roles like Scrum Master/Po facilitate.

Popular agile frameworks/methods

• Scrum — roles (Product Owner, Scrum Master, Development Team), events (sprint, daily stand-up, review, retrospective), artifacts (product backlog, sprint backlog, increment).
• Extreme Programming (XP) — engineering practices: pair programming, test-driven development (TDD), continuous integration, refactoring, simple design, small releases.
• Kanban — continuous flow with a visual board/WIP limits.
• Lean, FDD, DSDM etc.

Advantages of Agile

1. Rapid, continuous delivery of value — working software is delivered in weeks, not months; stakeholders see results early and often.
2. Adaptability to change — changing requirements are welcomed and absorbed across sprints, unlike the waterfall's lock-down.
3. Higher customer satisfaction — constant customer collaboration ensures the product matches real needs (lower risk of building the wrong product).
4. Early risk & issue detection — issues surface in early increments when fixes are cheap.
5. Improved quality — TDD, continuous integration, reviews, and frequent testing keep defects down.
6. Better communication & team morale — self-organizing teams, daily coordination, and retrospectives foster ownership and collaboration.
7. Faster feedback loop — each sprint's demo validates assumptions and corrects direction.

Disadvantages / when it struggles (for balance)

• Requires active, available customer involvement (hard in some projects).
• Less up-front documentation may hurt long-lived/compliance-heavy systems.
• Hard to estimate total cost/schedule precisely at the start.
• Scales with difficulty to very large, distributed programs (needs framework adjustments like SAFe).

Summary table

Aspect	Agile
Approach	Iterative & incremental (sprints)
Requirements	Evolving; backlog prioritization
Delivery	Every sprint (working increment)
Customer role	Continuous collaboration
Team	Small, cross-functional, self-organizing
Quality practices	TDD, CI, refactoring, pair programming
Best for	Dynamic requirements, customer-focused products

Summary: Agile builds software in short iterative cycles with continuous customer feedback and working deliverables — delivering value early and adapting to change, with major advantages in flexibility, quality, communication, and customer satisfaction (with trade-offs in documentation and upfront estimation).

Solution - Short Notes (Any Two)

a) Software Reuse

Using existing assets (code, design, docs, COTS) in new projects. Types: Application system reuse, Component reuse, Object/function reuse. Benefits: Quality, cost, time saved. Problems: Not invented here, component trust, maintenance. Approaches: COTS, Product lines, Libraries.

b) Spiral Model (Barry Boehm)

Risk-driven iterative model with 4 quadrants: Objective setting → Risk analysis → Development & Validation → Planning next loop. Each spiral = version. Best for large/high-risk projects; supports prototyping. Costly for small projects.

c) Six Sigma

Quality strategy aiming 3.4 defects per million opportunities. DMAIC: Define-Measure-Analyze-Improve-Control. Uses statistical tools (SPC). Levels: White/Yellow/Green/Black Belt. Focus on defect prevention, process variation reduction.

d) Verification and Validation

V&V: Ensure quality.

• Verification: Are we building product right? (Static: reviews, inspections) vs
• Validation: Are we building right product? (Dynamic: testing).
  Both throughout SDLC; V&V plan includes reviews, testing (unit → acceptance) and audits.

Spiral Model - Short Note

Proposed by: Barry Boehm in 1986. It is an iterative, risk-driven software development model where the project is developed in a series of spiral cycles (repeated loops), each of which passes through four phases.

Four Phases of Each Spiral Cycle

1. Planning - Determine objectives, alternatives and constraints for that cycle; finalize deliverables and the schedule.
2. Risk Analysis - Evaluate alternatives, identify and resolve risks (prototypes are built for risky areas). This is the distinguishing feature of the model.
3. Engineering - Development and testing of the product for the current increment.
4. Customer Evaluation - The customer reviews the output, gives feedback, and approves the next cycle.

Key Characteristics

• Combines waterfall + prototyping + incremental development, with emphasis on risk handling.
• Each loop produces a prototype of the system; the final prototype is the finished system.
• Strong documentation control and support for reuse.
• Requirements can change between cycles, so it is very flexible.

Advantages

• Risk is analyzed and resolved early, so costly failures are avoided.
• Good for large, complex, high-risk projects.
• Customers see working results early and can give feedback.
• Accommodates requirement changes easily.

Disadvantages

• Complex and expensive to manage (risk analysis needs expertise).
• Hard to estimate cost and schedule.
• Not suitable for small or low-risk projects.
• Risk prototypes may not cover all modules.

When to Use

Projects that are large, critical and risk-prone, where risk must be controlled at every phase - e.g. defence, aerospace and large enterprise systems.