UNIT–II | SOFTWARE PROJECT MANAGEMENT

SDLC MODEL SELECTION — JUSTIFICATION

Selecting and Justifying the Most Appropriate SDLC Model

Student Details
Name Shah Smit Miteshkumar

Enrollment / Roll No. 202307020107

Division CSE

Privacy-Preserving Federated Learning Platform for Edge AI and TinyML — a

decentralized ML framework enabling resource-constrained edge devices to
Project Definition / Title
collaboratively train models using privacy-preserving techniques, without
transmitting raw data off-device.

Date 17 / 08 / 2026

1. Project Context

Project: Privacy and Security in Federated Learning and TinyML

A decentralized machine-learning framework that lets resource-constrained edge/TinyML devices
collaboratively train models using privacy-preserving techniques (e.g., secure aggregation, differential privacy,
lightweight cryptography) without transmitting raw data off-device.

2. Selected SDLC Model

SPIRAL MODEL
Selection Rule applied: "High risk / uncertainty → Spiral"

The project's dominant characteristic is not schedule pressure or a need for rapid customer-facing releases — it is deep
technical uncertainty across cryptography, distributed learning, and constrained hardware. The comparison table's own
Selection Rule maps "high risk / uncertainty" directly to the Spiral model, and every risk-related row in the table (Risk
Tolerance, Team Structure, Main Strength) independently points to the same conclusion.

3. Justification Using the Selection Table (5+ Parameters)

Framework Guidance
Parameter How It Applies to This Project
(Spiral)

Privacy-preserving FL for TinyML is an active research area.

Exactly how much cryptographic overhead a given
microcontroller can absorb, which privacy technique
Uncertain / risk-driven
Requirements (differential privacy vs. secure multi-party computation vs.
(matches Spiral)
homomorphic encryption) gives the best privacy-vs-accuracy
trade-off, and how aggregation should be tuned are not
knowable up front — they emerge from experimentation.

The project combines four hard problems at once — distributed

systems, applied cryptography, machine-learning convergence,
High complexity with and extreme hardware constraints (kilobytes of memory,
Project Complexity
uncertainty limited battery). This compound complexity is exactly what the
Spiral model is built to manage through repeated risk-driven
cycles.
 Framework Guidance
Parameter How It Applies to This Project
(Spiral)

The single biggest technical risk already identified for this

project is edge nodes lacking the power/battery capacity to run
High risk / uncertainty — local training and cryptographic protocols simultaneously,
Risk Tolerance
particularly suitable causing device dropout. Spiral's dedicated Risk Analysis phase in
every cycle is designed precisely to surface and mitigate risks
like this before heavy investment.

Delivering this project needs specialists in cryptography,

TinyML/model quantization, and distributed ML — a team
Team Structure / Requires strong technical /
profile the Spiral model explicitly assumes, since each cycle
Expertise risk-analysis capability
depends on rigorous technical risk assessment rather than fixed-
role handoffs.

Because the project's core value proposition is avoiding data-

protection penalties (GDPR/DPDP-style regulation), compliance
Regulatory Useful where risk
risk has to be re-evaluated as the design evolves — not signed
Compliance management is important
off once at the start. Spiral folds this naturally into its recurring
risk-analysis step.

As new attack vectors, lighter-weight cryptographic primitives,

or better quantization techniques appear in the literature, the
High, especially with
Change Frequency design needs to absorb them. Spiral's cyclical structure
uncertainty
accommodates frequent redesign far better than a fixed, front-
loaded plan.

This is the single strength the project needs most: an SDLC

model whose core purpose is to find and neutralize technical
Risk identification and
Main Strength risk (e.g., battery drain, cryptographic latency, model-
mitigation
convergence degradation) before it becomes a costly failure late
in development.

4. Alignment with Spiral's Objectives, Characteristics and Strengths

Objectives
Spiral's objective is to build the system through repeated Plan → Risk-Analysis → Engineer → Evaluate cycles, resolving
the highest-impact unknown first each time. Applied here, the first spiral would prototype and stress-test the core
question — can a target microcontroller run local training plus lightweight secure aggregation within its power/memory
budget — before any spiral commits to a full privacy stack or production-scale deployment across many edge nodes.
Characteristics
Spiral blends the structure of Waterfall with the flexibility of Iterative development, and formally embeds risk analysis
into every pass rather than treating it as a one-time exercise. That matches this project's need to keep re-checking, cycle
after cycle, whether a chosen cryptographic technique still holds up as new research findings, attack vectors, or hardware
constraints surface — something none of the other three models require by design.
Strengths
Spiral's core strength — systematic risk identification and mitigation — is precisely the capability this project depends on
most. It lets the team validate feasibility incrementally (quantized model → lightweight crypto → full secure-aggregation
pipeline) instead of discovering a fatal battery-life or latency problem only after the entire framework has been built,
which would be far more costly to fix under Waterfall or Agile.

5. Why the Other Models Are Less Suitable

Model Why It Is Less Suitable Here

Requires clear, stable, well-understood requirements and low change frequency. This
Waterfall project's privacy/crypto design is still evolving through research — locking requirements
upfront would force costly rework whenever a better technique is found.

Agile / Scrum Handles changing requirements well, but has no dedicated risk-analysis phase. It optimizes
 Model Why It Is Less Suitable Here

for delivering working increments to a customer, not for systematically de-risking a

technically uncertain, hardware-constrained research problem before committing
engineering effort.

Supports evolving requirements through repeated refinement, but — like Agile — lacks
Iterative Spiral's explicit, formal risk-assessment step at every cycle, which is the specific capability this
project needs most given its dominant technical-feasibility risk.

6. Conclusion
Given evolving, research-driven requirements; high technical and hardware complexity; a high-risk feasibility question at
the project's core (battery/compute overhead of on-device cryptography); the need for a specialist, risk-analysis-capable
team; and ongoing regulatory-compliance sensitivity, the Spiral model is the most appropriate SDLC choice for the Privacy
and Security in Federated Learning and TinyML project. It allows the team to de-risk the hardest technical questions early
and cheaply, cycle by cycle, before scaling the framework to full deployment.