Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC TR 29110-5-6-2: Very Small Entities — Software Engineering Deployment Package
Practical software engineering guidance for VSEs based on ISO/IEC 29110 profiles
ISO/IEC TR 29110-5-6-2 provides a Deployment Package for software engineering within the VSE framework. It builds upon the Entry Profile (5-1-4) by adding deeper guidance on software-specific technical practices while maintaining the lightweight, outcome-oriented approach that makes 29110 accessible to small teams.
Think of 5-6-2 as the “how” to complement the Entry Profile’s “what.” Where 5-1-4 defines what work products to create, 5-6-2 provides concrete techniques for creating them — from use case modeling to test-driven development.
Software Engineering Practices in the Deployment Package
The Deployment Package organizes software engineering practices into three categories: requirements engineering, design and construction, and verification and validation. Each category includes recommended techniques, expected work products, and tailoring guidance for different project types.
| Practice Category | Recommended Techniques | Work Products | When to Tailor |
|---|---|---|---|
| Requirements Engineering | User stories, use cases, acceptance criteria (Gherkin), requirements prioritization (MoSCoW) | Product Backlog, Software Requirements Specification, Use Case Diagram | Internal tools → user stories only; safety-critical → full SRS with traceability |
| Design & Construction | Modular design, API-first, coding standards, continuous integration, refactoring | Software Architecture Document, Source Code, Coding Standards Document | Prototype → minimal design documentation; long-lived product → architecture records (ADRs) |
| Verification & Validation | Unit testing, integration testing, system testing, acceptance testing, static analysis, peer review | Test Plan, Test Cases, Test Report, Code Review Checklist | Low-risk → automated unit tests + manual acceptance; high-risk → full test matrix + independent review |
A common pitfall for VSEs is treating testing as a phase rather than an activity. When testing is scheduled as a phase at the end of development, teams inevitably run out of time and ship untested software. The Deployment Package emphasizes that testing activities must run in parallel with construction activities.
Engineering Insights: Technical Debt Management for Small Teams
VSEs operate under constant resource pressure and frequently take on technical debt to meet deadlines. The Deployment Package addresses this reality not by forbidding technical debt — which would be unrealistic — but by providing a technical debt register template. Each debt item is recorded with its estimated remediation effort and business impact. The Project Manager reviews the register during each planning cycle and allocates a fixed percentage of capacity (typically 15-20%) to debt reduction.
A second key insight is the definition of done (DoD) pattern. The Deployment Package provides a sample DoD checklist: code reviewed, unit tests passing (80%+ coverage), integration tests passing, static analysis clean, documentation updated, and acceptance criteria met. Each VSE adapts the DoD to their context and reviews it at the start of each iteration.
Selecting the Right Software Lifecycle Model
The Deployment Package does not prescribe a specific lifecycle model. Instead, it provides decision criteria: for well-understood requirements with stable technology, a sequential approach works; for exploratory projects with high uncertainty, iterative/incremental or Agile approaches are recommended. The key is that whatever model is chosen, the work products defined in 5-6-2 must be adapted to fit that model.
A 4-person team developing a SaaS analytics platform adopted the Deployment Package’s test-first approach. By writing acceptance tests before implementation, they reduced the bug-fix cycle from an average of 3 days (finding bugs during manual QA) to 4 hours (finding bugs during automated test execution). The upfront investment in test automation paid for itself within the first two sprints.
FAQs
Q: What is the difference between 5-1-4 (Entry) and 5-6-2 (Software Engineering)?
A: 5-1-4 defines the minimal set of processes and work products for a VSE to function. 5-6-2 provides richer, software-specific guidance on how to perform those processes effectively. Think of 5-1-4 as the baseline and 5-6-2 as the enhancement.
A: 5-1-4 defines the minimal set of processes and work products for a VSE to function. 5-6-2 provides richer, software-specific guidance on how to perform those processes effectively. Think of 5-1-4 as the baseline and 5-6-2 as the enhancement.
Q: Does 5-6-2 support Agile development?
A: Yes, strongly. The Deployment Package includes specific mapping between its processes and Scrum, Kanban, and XP practices. The work products map naturally to Agile artifacts: Product Backlog, Sprint Backlog, Definition of Done, and burndown charts.
A: Yes, strongly. The Deployment Package includes specific mapping between its processes and Scrum, Kanban, and XP practices. The work products map naturally to Agile artifacts: Product Backlog, Sprint Backlog, Definition of Done, and burndown charts.
Q: Is code review mandatory in the Deployment Package?
A: Peer review is mandatory in the Verification & Validation category, but the form is flexible. It can be pair programming (real-time review), pull request review (asynchronous), or formal inspection. The minimum requirement is that every code change is reviewed by at least one person other than the author.
A: Peer review is mandatory in the Verification & Validation category, but the form is flexible. It can be pair programming (real-time review), pull request review (asynchronous), or formal inspection. The minimum requirement is that every code change is reviewed by at least one person other than the author.
Q: How do I demonstrate compliance with 5-6-2?
A: Compliance is demonstrated through evidence of performing the defined practices. Key evidence includes: a maintained Product Backlog or SRS, test results (automated or manual), code review records, and iteration review minutes. The Deployment Package includes compliance checklists for self-assessment.
A: Compliance is demonstrated through evidence of performing the defined practices. Key evidence includes: a maintained Product Backlog or SRS, test results (automated or manual), code review records, and iteration review minutes. The Deployment Package includes compliance checklists for self-assessment.
