Core activities
Specification defines need and constraints. Development designs and implements. Validation checks fitness. Evolution adapts after delivery.
Software project management · field guide
Software Engineering
Software engineering applies systematic, disciplined, measurable practices to building and evolving software. The management challenge is to choose a lifecycle, expose uncertainty early, and create feedback fast enough to steer.
ProcessLifecycleAgileScrumDevOpsImprovement
01 · Foundation
Product, project, and process
A product delivers continuing value; a project is a temporary effort that creates or changes it; a process is the repeatable way work flows. Confusing them causes local optimization—finishing a project while leaving an unmaintainable product.
Three constraints
Scope, time, and cost interact; quality and risk sit across all three. A changed constraint requires an explicit trade-off, not wishful compression.
Quality attributes
Maintainability, dependability/security, efficiency, and acceptability influence architecture and the definition of done.
Exam lens: verification asks “did we build the product right?”
Validation asks “did we build the right product?”
02 · Lifecycle choice
Predictive to adaptive
| Approach | Best fit | Strength | Main risk |
|---|---|---|---|
| Waterfall / predictive | Stable requirements, regulated gates | Up-front plan and traceability | Late feedback, costly change |
| Incremental | Value can ship in slices | Earlier benefit and learning | Architecture can erode |
| Iterative | Solution needs refinement | Repeated feedback improves fit | Convergence is not automatic |
| Spiral | Large, high-risk work | Risk-driven cycles and prototypes | Complex and management-heavy |
| Agile / adaptive | High change, close customer access | Frequent value and reprioritization | Needs discipline and engagement |
Selection rule: match the lifecycle to requirement uncertainty,
technical risk, delivery cadence, compliance needs, team maturity, and
stakeholder availability. “Hybrid” is deliberate tailoring—not random
mixing.
03 · Agile delivery
Short loops, usable increments
Product backlog
Ordered outcomes, features, fixes
Ordered outcomes, features, fixes
Sprint planning
Goal + selected work
Goal + selected work
Build & test
Daily coordination
Daily coordination
Review
Inspect the increment
Inspect the increment
Retrospective
Improve the system
Improve the system
Roles
- Product Owner: value and backlog order
- Scrum Master: effectiveness and impediments
- Developers: create a done increment
Artifacts
- Product backlog → product goal
- Sprint backlog → sprint goal
- Increment → definition of done
Agile is not
No plan, no documentation, or no architecture. Planning is continuous; documentation is sufficient and valuable; design evolves with feedback.
04 · Flow to operations
DevOps and continuous delivery
DevOps joins development and operations through shared ownership, automation, measurement, and learning. The pipeline turns every change into evidence.
Commit
Build
Automated tests
Security checks
Deploy
Observe
CI
Integrate small changes frequently; each integration triggers an automated build and test suite.
Continuous delivery
Every passing change is deployable. Production release remains a business decision.
Continuous deployment
Passing changes move automatically to production; monitoring and rollback are essential.
Useful measures
Lead time, deployment frequency, change failure rate, and recovery time reveal delivery-system health.
05 · Improvement
Improve the system
Plan
Identify a measurable problem and a small experiment.
Do
Run it with limited scope; capture evidence.
Check
Compare observed results with the hypothesis.
Act
Standardize, adapt, or abandon—and repeat.
Retrospectives, root-cause analysis, value-stream mapping, and process metrics support learning. Metrics should improve decisions, never become targets that invite gaming.
06 · Retrieval practice
Check your model
Why is iterative not the same as incremental?
Iterative work refines a solution through repetition; incremental
work adds usable slices. A project can use either or both.
A team deploys to a staging environment automatically, but production needs approval. What practice is this?
Continuous delivery. The release is always ready, but deployment to
production is a business decision.
Who orders the Scrum product backlog?
The Product Owner, while incorporating stakeholder and developer
input.
When is a predictive approach reasonable?
When scope and technology are stable, change is relatively low, and
governance or regulation benefits from planned phase gates.