IITM · Software Engineering · Week 4

Software Project Management
— Hinglish Notes 📒

Lectures + slides + graded assignment, sab kuch ek jagah. Overview → Estimation → Scheduling → Risk → Agile/Scrum → Pivotal Tracker, aur end me saare 14 assignment questions with full explanation.

Estimation
Scheduling
Risk Mgmt
Agile + Scrum
// is week ka syllabus, Gantt chart style me 😄
01

Project Management Overview

Pichle weeks me humne requirements gather karna aur UI design karna seekha. Ab sawaal ye hai — ye saara kaam actually hoga kaise? Kaun karega, kab karega, kitne paise lagenge? Yahi manage karta hai Project Manager (PM) — project ka "boss".

Project Manager ki key responsibilities

  • Client ↔ Team bridge: PM customers/stakeholders aur dev team ke beech ka main point of contact hota hai. Ensure karta hai ki customer ki needs address ho rahi hain.
  • Team banana aur manage karna: Sahi log dhundhna, sahi task dena, aur track pe rakhna. Technology decisions me team + outside experts dono se consult karna.
  • Scheduling: Requirements ko major activities me todna → activities ko tasks me todna → dependencies check karna → plan banana.
  • Estimation: Size, effort, time, cost — sab estimate karna (client ko batana padta hai kitna charge hoga).
  • Risk management: Risks identify karna, assess karna, aur mitigation plans (Plan A/B/C) ready rakhna.
  • Configuration management: Final system kaise configure hoga — tools, documentation, modules combine karna, versions manage karna.
  • Timely + within-cost delivery ensure karna.

Plan & Document vs Agile perspective

Plan & DocumentAgile
Goal: software engineering ko predictable banana in budget & schedule. Start me heavy planning + documentation.Start me cost/schedule predict nahi karta. Customers ke saath frequent iterations me kaam.
WBS, Gantt charts, milestones, COCOMO jaisi techniques.User stories ko difficulty ke hisaab se points dete hain, per-iteration completed points record karte hain → realistic estimate milta hai.
02

Project Estimation Techniques

Estimation kyun? Cost establish karne ke liye (client ko batana hai), schedule banane ke liye, aur bidding/contract ke liye. Jitni zyada detail project ki hogi, utna accurate estimate. Exact estimate possible nahi hota.

Key Estimation Parameters

  • Size of code: Lines of code (LOC). 1 KLOC = 1000 LOC.
  • Effort: Measured in person-months (PM). 1 person-month = ek individual ka ek month ka typical kaam.
  • Time (duration) aur Cost (₹₹).
Person-month ka funda (assignment me direct aata hai! 🔥)
Agar project = 12 person-months:
developers × months = person-months
→ 12 developers × 1 month ✅  |  4 devs × 3 months ✅  |  2 devs × 6 months ✅
Bas multiply karke check karo total match karta hai ya nahi.

A. Empirical Estimation (experience-based)

Empirical = experience of people jo similar projects complete kar chuke hain.

1. Expert Judgement

Expert problem ko thoroughly analyze karke ek educated guess deta hai — har component ka cost estimate karke sabko combine karta hai.

Drawbacks: human errors, individual bias (favourite tech ke taraf), optimistic estimates (specially contract jeetne ke liye), kuch areas me knowledge ki kami (e.g. DB me expert but plugins me nahi). Group of experts se bhi solve nahi hota — group bhi biased ho sakta hai, assertive/senior members dominate kar sakte hain.

2. Delphi Technique (expert judgement ke drawbacks ka solution)
  1. Ek coordinator har expert ko SRS + estimate form deta hai.
  2. Experts anonymously apne estimates coordinator ko submit karte hain.
  3. Coordinator summary compile karke publish karta hai.
  4. Process kai rounds repeat hota hai jab tak consensus na aaye.

Anonymous + coordinator + repeated rounds = Delphi — assignment Q3 me exactly yahi scenario tha!

B. Heuristic Estimation (mathematical models)

Heuristic = mathematical expressions se parameters ke beech relationships model karna. Sabse famous: COCOMO.

COCOMO (COnstructive COst MOdel) — Boehm, 1981
Effort = a × (SIZE in KLOC)b   person-months

a aur b project ke type pe depend karte hain:

TypeMatlabFormula
OrganicWell-understood application; small & experienced team2.4 × KLOC1.05
Semi-detachedExperienced + inexperienced ka mix; limited related experience3.0 × KLOC1.12
EmbeddedHardware se strongly coupled; large team, many inexperienced3.6 × KLOC1.20
COCOMO ke steps (summary)
  1. Product ka type decide karo (organic / semi-detached / embedded).
  2. Har module ka LOC estimate karo.
  3. Formula se initial estimate nikalo.
  4. Effort Adjustment Factor (EAF) — 15 cost drivers (product, computer, personnel attributes etc.) ke multipliers ko multiply karo.
  5. Final estimate = Initial × EAF.
Solved example (Amazon Seller Portal — lecture wala)
Type: semi-detached, Size: 4 KLOC →
Effort = 3.0 × 41.12 = 15.83 PM (initial)
Cost @ ₹75,000/person/month ≈ 16 × 75,000 = ₹12 lakhs.
EAF = 1.40 × 1.08 × 1.13 × 0.95 = 1.62 →
Final = 15.83 × 1.62 = 25.65 PM

Fun fact from lecture: British Computer Society survey (1000+ projects) me 92% project managers ne formulas nahi, experience se estimate kiya tha. 😅

03

Project Scheduling

Main activities in scheduling (order yaad rakho)

  1. Saari major activities identify karo.
  2. Har activity ko tasks me break down karo (→ WBS).
  3. Tasks ke beech dependencies determine karo.
  4. Har task ka time duration estimate karo.
  5. Is info ko represent karo — chart / graph / network.
  6. Task start & end dates nikalo.
  7. Critical path determine karo — wo chain of tasks jo project ki total duration decide karti hai.
  8. Tasks ko resources allocate karo (people, equipment).

Work Breakdown Structure (WBS)

Project ko tree structure me todo:

  • Root = project ka naam (assignment Q5!)
  • Internal node = activity jo aur chhote parts me break ho sakti hai (Q7!)
  • Leaf = task jo ek developer ko allocate + schedule ho sakta hai (Q6!)
  • Ek task ≈ roughly 2 weeks ka development time.

Example (Task Manager project): Root = Task Manager → children = Requirement gathering & analysis, Design, Development → leaves = Gather requirements, Generate SRS, Component diagram, Database schema, User interface, Task planner, Task organizer, Task reviewer.

Activity Network

WBS ke leaf nodes activity network ke nodes ban jaate hain. Arrows dependencies dikhate hain + har task ka duration likha hota hai. Isse pata chalta hai kya sequential hai (e.g. catalog mgmt → inventory mgmt → order tracking) aur kya parallel chal sakta hai (e.g. payment, sales, feedback tracking ek saath).

Gantt Chart

Special bar chart — har bar ek task/activity, aur bar ki length ∝ planned time duration. Team ko visually dikhata hai kaun sa task kab start/end hota hai, kya parallel hai, kya dependent.

Gantt chart padhne ke rules (assignment Q8 ke liye):

  • Do bars same time pe start → parallel/concurrent tasks.
  • Bar B tabhi start jab bar A khatam → dependency (A must finish before B).
  • Overlapping bars → dono simultaneously chal rahe hain.
04

Risk Management

Risk kya hai? Ek anticipated unfavourable event jo project ke dauraan ho sakta hai. Anticipated — kyunki past experience se hum predict kar sakte hain. Unfavourable — kyunki ye project ko delay/derail kar sakta hai. Software intangible hota hai, isliye risks identify karna aur mushkil (ghar banate waqt construction dikhta hai, code ka progress "dikhta" nahi).

3 types of risks (assignment me 5 questions isi se! 🎯)

TypeKya hota haiExamplesMitigation
Technical risk Project ke technical aspects se related; team ki insufficient knowledge about the product se hota hai. Kisi bhi phase me ho sakta hai. Wrong function/UI ban gaya (ambiguous requirements ki wajah se); external component up-to-mark nahi. Clients se communicate karo, prototype bana ke feedback lo; external components ke liye benchmarking + regular inspection.
Project risk Non-technical problems: budget, schedule, personnel, resources, customer-related. Budget exceed ho gaya; schedule slip; team me domain knowledge ki kami; log chhod ke chale gaye (personnel shortfall). Milestones + regular meetings; relevant experience wale developers company ke andar/bahar se hire karo; backup plans.
Business risk Product ke business aspects ko harm — market me problem. Product complete hone tak market me competitive nahi raha; gold plating (unnecessary features jo client ne maange hi nahi). Market explore karo similar products ke liye, gaps address karo; gold plating ke liye clients se poochho + cost-benefit analysis.
Quick trick for exams 🧠
• Problem code/tech/product-knowledge se hai → Technical risk
• Problem budget/schedule/people/domain-knowledge se hai → Project risk
• Problem market/competition/business value se hai → Business risk
Note: "developers ke paas domain knowledge nahi" = personnel/staffing issue = Project risk (technical nahi — technical risk product ki technical knowledge ke baare me hai).

Risk Assessment — Risk Table

PM team se worst-case scenarios poochh ke ek risk table banata hai:

  • Har risk ko Probability (P): 0–100%
  • Impact (I): negligible(1), marginal(2), critical(3), catastrophic(4)
Risk Exposure = P × I

Table ko descending order me sort karo → sabse upar wale (highest P×I) risks ko pehle deal karo. Saare risks handle nahi kar sakte, most important pe focus karo.

Lecture example: Schedule slippage (60%×3=1.8), Lack of e-commerce experience (60%×3=1.8), Personnel shortfall (40%×3=1.2), DB scaling (20%×2=0.4).

05

Project Management in Agile — Scrum

Agile me team size roughly 4–9 people. Development organize karne ka ek popular framework: Scrum. Iska heart hai Sprint — ek short time-boxed period (typically 1–2 weeks) jisme team fixed amount of work complete karti hai. Complex project chhote pieces me break hota hai.

3 Scrum roles

  • Development Team: Actual kaam karne wale — sirf coders nahi! Designers, developers, testers — jo bhi sprint ka kaam complete karne ke liye chahiye.
  • Product Owner: Client ↔ dev team interface. Sabse important kaam: sab inputs leke sprint ke work ko prioritize karna, taaki client ko max value mile.
  • Scrum Master: Ensure karta hai ki scrum ki saari activities sahi chal rahi hain; PO ko value define karne me, team ko deliver karne me, aur org ko scrum samajhne me help karta hai.

Scrum activities (sequence yaad rakho)

  1. Sprint Planning: PO + Scrum Master + Dev team. Do questions: "Is sprint me kya kaam ho sakta hai?" aur "Kaise hoga?". Time-boxed: ~2 hours per week of iteration. Yahin product backlog ke items prioritize hote hain.
  2. Daily Scrum / Standup: Daily meeting. Har member 3 questions ka answer deta hai: kal kya kiya? aaj kya kar raha hoon? kya blockers hain?
  3. Sprint Review: Sprint khatam hone ke baad — team demonstrate karti hai jo complete hua (to-do/in-progress → done).
  4. Sprint Retrospective: Evaluation — team dynamics, processes, tools kaise rahe; kya achha gaya, kya nahi; improvement plan next sprints ke liye.

Product Backlog, Points & Velocity

Product Backlog: User stories/requirements se derived prioritized list of work. Prioritization sprint planning meeting me hoti hai (PO + devs consensus se decide karte hain, e.g. "is sprint me 1a aur 2a karenge").

Points: Har user story ko difficulty ke hisaab se points milte hain.

Velocity: Ek sprint me team kitne points complete kar paati hai.

Velocity = points completed per sprint

Example: Sprint 1 me "Add catalog" (2 pts) + "Add inventory item" (2 pts) complete → velocity = 4. Ab next sprint me team confidently 4-point ka kaam utha sakti hai. Stories/points per iteration count karke average nikalo → poore project ka time/effort/cost estimate.

Scheduling: Plan & Document vs Agile

Plan & DocumentAgile
Project start me hi schedule; tasks me breakdown; Gantt charts + milestones.User stories + points; velocity se iterations schedule hote hain; progress = kitni stories deliver hui per iteration.
06

Pivotal Tracker (Tool Tutorial)

Agile ideas ko practice me laane wala project management tool — user stories aur velocity track karta hai. Key concepts:

  • Current iteration / Backlog: Jo stories abhi chal rahi hain ya current iteration ke liye prioritized hain (product backlog jaisa).
  • Icebox: ❄️ "Dumping place" — ideas/stories jo abhi prioritize nahi hui (e.g. future ka "customer feedback" feature).
  • Iteration length set kar sakte ho (e.g. 2 weeks) aur team members add kar sakte ho.
  • Story create karo: type (feature), priority, points assign karo (e.g. Add catalogue item = 2 points).
  • Epics: Related user stories ka collection/group (e.g. "Catalogue management" epic, "Inventory management" epic).
  • Velocity set karo (e.g. 4) → stories members ko assign karo → Start → finish hone pe product owner accept karta hai → story Done.
  • Analytics bhi milta hai — poore project ka clear picture, team sync me rehti hai.
07

Graded Assignment — 14 Questions Solved

Har question pe click karke answer + explanation dekho. Concept ka reference notes ke sections me diya hai. 👇

Q1Project requires 240 person-months. Kaunse statements true hain? (MSQ)
A. 240 developers needed ❌ (240 devs × 1 month bhi ho sakta hai, but "requires 240 developers" as a fixed statement galat hai)
B. 10 developers × 2 years ✅
C. 120 developers × 2 months ✅
D. 24 developers × 10 years ❌
Answer: B, C
Kyun? Formula: devs × months = person-months.
B: 10 × 24 months (2 yrs) = 240 ✅ · C: 120 × 2 = 240 ✅ · D: 24 × 120 months = 2880 ❌.
Ref: Section 2 → person-month ka funda.
Q2S1: Estimation based on experience of similar projects. S2: Estimation based on mathematical models. Correct option?
C. Statement 1 → Empirical, Statement 2 → Heuristic ✅
Answer: C
Kyun? Empirical = experience/experts of similar past projects. Heuristic = mathematical expressions se modelling (jaise COCOMO). Dono definitions seedha lecture se. Ref: Section 2A vs 2B.
Q3Experts + coordinator, SRS + form, anonymous submission, summary published, process repeated. Kaunsi technique?
A. Expert judgement ❌ (usme coordinator/anonymity/rounds nahi hote)
B. Delphi technique ✅
C. COCOMO ❌ (wo mathematical model hai)
Answer: B
Kyun? Keywords match karo: coordinator + anonymous estimates + repeated rounds = Delphi ka exact definition. Ref: Section 2A → Delphi.
Q4Smartwatch software (hardware-coupled), 50,000 LOC, EAF = 1.62. Final estimated effort?
A. 394 ❌ (ye sirf initial estimate hai, EAF multiply karna bhool gaye)
D. 638 ✅
Answer: D (638 PM)
Solution step-by-step:
1. Hardware se strongly coupled → Embedded project → a=3.6, b=1.20.
2. Size = 50,000 LOC = 50 KLOC.
3. Initial = 3.6 × 501.20 ≈ 3.6 × 109.3 ≈ 393.5 PM (option A yahi trap hai!).
4. Final = 393.5 × 1.62 ≈ 637.5 ≈ 638 PM. ✅
Ref: Section 2B → COCOMO steps (initial → EAF → final).
Q5Given WBS me "Task Manager" (root) kya hai?
A. the project name ✅
Answer: A
Kyun? WBS tree ka root = project ka naam hota hai. Yahan "Task Manager" root node hai. Ref: Section 3 → WBS structure.
Q6WBS me "Task planner" (leaf node) kya hai?
C. a task which can be allocated to a developer and scheduled ✅
Answer: C
Kyun? WBS ka leaf node = wo task jo directly ek developer ko de sakte ho aur schedule kar sakte ho (~2 weeks ka kaam). "Task planner" leaf level pe hai. Ref: Section 3 → WBS.
Q7WBS me "Design" (middle node) kya hai?
B. an activity which can be further broken down into smaller tasks ✅
Answer: B
Kyun? "Design" internal/middle node hai — uske neeche Component diagram, Database schema, User interface hain. Internal node = activity jo aur break down hoti hai. Ref: Section 3 → WBS.
Q8Gantt chart observations — correct statements select karo (MSQ)
A. Component design starts after UI & DB schema complete ❌
B. User interface and database design can start at the same time ✅
C. Update status and reschedule task both are done concurrently ✅
D. Task manager must complete before task reviewer starts ✅
Answer: B, C, D
Kyun? Chart me: Component design ka bar sabse pehle hai (0 se), UI/DB uske baad — to A ulta hai ❌. UI aur DB schema ke bars same point pe start → B ✅. Update status & Reschedule status ke bars overlap (same time window ~90 pe) → C ✅. Task reviewer ka bar Task manager ke bar khatam hone ke baad start hota hai → D ✅. Ref: Section 3 → Gantt reading rules.
Q9E-shopping app develop ho rahi hai; developers ke paas sufficient domain knowledge nahi. Risk type?
A. Technical risk ❌
B. Project risk ✅
C. Business risk ❌
Answer: B
Kyun? Ye personnel/staffing problem hai — team ke logon me domain knowledge ki kami. Personnel-related issues = Project risk (budget, schedule, personnel, resources). Ref: Section 4 → risk types table + trick.
Q10(Same scenario) Is risk ko mitigate kaise karein?
C. By hiring developers with relevant experience within the company and/or outside the company ✅
Answer: C
Kyun? Domain knowledge ki kami ka lecture-wala mitigation: sahi experience wale log hire karo — company ke andar se ya bahar se. Option A (prototypes) technical risk ka mitigation hai, B (benchmarking) external components ka. Ref: Section 4 → Project risk mitigation.
Q11Project ne estimated budget exceed kar diya. Risk type?
B. Project risk ✅
Answer: B
Kyun? Budget problems = non-technical = Project risk (definition me explicitly "problems in budget, schedule, personnel..." likha hai). Ref: Section 4.
Q12Text editor develop hua, but market me competitive nahi hai. Risk type?
C. Business risk ✅
Answer: C
Kyun? Market competitiveness = product ke business aspects ko harm = Business risk. Lecture ka exact example bhi yahi tha. Ref: Section 4.
Q13(Same scenario) Is business risk ko mitigate kaise karein?
C. By exploring the market for similar products ✅
Answer: C
Kyun? "Not competitive" ka mitigation: market explore karo similar products ke liye, unke gaps address karo. Hiring/training (D) project risk ke liye hai, prototypes (A) technical ke liye. Ref: Section 4 → Business risk mitigation.
Q14Risk table diya hai (P & I). Kaunsa risk PM ko sabse pehle deal karna chahiye?
RiskPIP × I
Personal shortfall40%20.80 🥇
Insufficient knowledge of product20%30.60
Schedule slippage30%20.60
Vulnerability in external components10%30.30
A. Personal shortfall ✅
Answer: A
Kyun? Risk = P × I calculate karo, descending sort karo, highest wala pehle. 0.40×2 = 0.8 sabse zyada hai. Ref: Section 4 → Risk table.