Unit 1: Software development process
Managing Software Projects notes · PTU syllabus (MBA 943-18)
On this page
Unit summary
Software runs modern business, yet software projects are notorious for overruns. This unit covers the evolving role of software, the software crisis and myths, software engineering as a layered technology, process models — waterfall, prototyping, RAD, evolutionary, agile and component-based development — and choosing an appropriate methodology.
After this unit you can
- Explain the evolving role of software and the software crisis
- Identify software myths and explain the layered technology of software engineering
- Compare software process models
- Choose an appropriate development methodology
PTU syllabus topics
- Evolving role of software
- software crisis and myths
- layered technology
- process models — waterfall
- prototyping
- RAD
- evolutionary
- agile
- component-based development
- choosing an appropriate methodology
Waterfall
Stable requirements
Late feedback
Prototyping
Unclear requirements
Scope creep
RAD
Fast delivery with strong teams
Needs modular systems
Agile (Scrum)
Changing requirements
Less documentation
Topic 1
Evolving role of software
- Software is both a product (delivering computing capability) and a vehicle for delivering products (operating systems, networks, tools).
- Eras: batch systems → real-time and multi-user → distributed and embedded → object-oriented, internet and mobile → cloud, AI and SaaS.
- Categories: system software, application software, engineering and scientific, embedded, product-line, web and mobile apps, AI software.
- Characteristics: software is developed, not manufactured; it does not wear out but deteriorates through changes; most is custom-built or assembled from components.
Topic 2
The software crisis and software myths
- Software crisis: projects late, over budget, unreliable, hard to maintain, not meeting requirements.
Management myths
"We have standards, so we are fine"; "If behind schedule, add more programmers"
Customer myths
"A general statement of objectives is enough to start"; "Changes are easy because software is flexible"
Practitioner myths
"Once the program works, the job is done"; "The only deliverable is working code"
- Brooks's law: adding people to a late software project makes it later.
Topic 3
Software engineering: a layered technology
- Tools
Automated support — CASE, IDEs, version control
- Methods
Technical how-tos — analysis, design, coding, testing
- Process
Framework of activities, KPAs, milestones
- Quality focus
Foundation — commitment to quality
Topic 4
Software process models
Waterfall (linear sequential)
Requirements → design → coding → testing → maintenance, in sequence
Requirements are clear and stable
Prototyping
Build a quick model to clarify requirements, refine with users
Requirements are unclear
RAD (rapid application development)
Component reuse and parallel teams for very short cycles (60–90 days)
Modular systems, time pressure
Evolutionary — incremental
Deliver in increments, each adding features
Early partial delivery needed
Evolutionary — spiral (Boehm)
Iterative cycles with explicit risk analysis
Large, high-risk projects
Component-based development
Assemble systems from reusable components
Mature component libraries exist
- 1
Requirements analysis
- 2
System design
- 3
Implementation (coding)
- 4
Testing
- 5
Deployment
- 6
Maintenance
Topic 5
Agile development
- Agile Manifesto (2001): individuals and interactions over processes and tools; working software over documentation; customer collaboration over contract negotiation; responding to change over following a plan.
- 1. Product backlog:
- 2. Sprint planning:
- 3. Sprint (1–4 weeks): Daily stand-up
- 4. Sprint review: Demo to stakeholders
- 5. Sprint retrospective: Improve the process
- Roles: product owner, scrum master, development team. Other methods: Kanban, Extreme Programming (pair programming, test-driven development), Lean, SAFe for scale; DevOps integrates development and operations through continuous integration and delivery.
Topic 6
Choosing an appropriate methodology
- Factors: clarity and stability of requirements, project size and complexity, risk, customer availability, team skills and distribution, regulatory and documentation needs, time-to-market.
Requirements
Fixed upfront
Evolving
Documentation
Heavy
Light, just enough
Customer involvement
At start and end
Continuous
Delivery
Single release
Frequent increments
Suits
Regulated, fixed-scope contracts
Fast-changing markets, product development
Key terms
- Software crisis
- Chronic problems of late, costly, unreliable software
- Brooks's law
- Adding people to a late project makes it later
- Prototyping
- Building a quick model to clarify requirements
- Spiral model
- Iterative model with explicit risk analysis
- Scrum
- Agile framework using time-boxed sprints
Quick revision
- Role and characteristics of software; categories.
- Software crisis; management, customer, practitioner myths.
- Layers: quality, process, methods, tools.
- Waterfall, prototyping, RAD, incremental, spiral, component-based; agile and Scrum; DevOps.
- Choosing a method; plan-driven vs agile.
Important exam questions
Practice questions written to the PTU exam pattern for this unit's syllabus: short answers (Section A style) and long answers (Sections B and C style).
Short-answer questions
- Q1.Why does software not wear out?
- Q2.State two management myths about software.
- Q3.What is Brooks's law?
- Q4.Name the layers of software engineering.
- Q5.When is prototyping preferred?
- Q6.State the four values of the Agile Manifesto.
Long-answer questions
- Q1.Explain the evolving role of software and the software crisis.
- Q2.Discuss software myths and software engineering as a layered technology.
- Q3.Compare waterfall, prototyping, RAD and spiral models.
- Q4.Explain agile development and the factors in choosing a methodology.
Stuck on this unit?
Message SBS on WhatsApp for help with Managing Software Projects, or to ask about studying MBA at Synetic.