ISO/IEC 29110-5-1-1: Very Small Entities — Management and Engineering Guide

Systems and Software Engineering — VSE Management and Engineering Guide for Basic Profile

Management Processes for the Basic Profile

ISO/IEC 29110-5-1-1 defines the management and engineering processes required for a VSE to operate at the Basic profile (Profile 2). This is the most widely adopted profile in the 29110 series because it provides a practical balance between process discipline and lean overhead. The standard is organized into two primary process groups: Project Management (PM) and Software Implementation (SI). Each process group specifies objectives, outcomes, roles, responsibilities, work products, and detailed activity descriptions that a VSE can follow directly without customization for small-team contexts.

The Basic profile is designed so that a single person can fulfill multiple roles. For a 5-person VSE, one individual commonly serves as both Project Manager and Quality Assurance lead, while developers handle software implementation and configuration management. The key engineering insight is to separate concerns in the process definition while allowing role consolidation in practice.

The Project Management process covers six key outcomes: project plan development, plan assessment and revision, progress monitoring and control, requirement change management, project review and evaluation, and project closure. Each outcome is accompanied by a detailed activity diagram and work product template. The standard provides templates for the Project Plan (a 3-5 page document suitable for small projects), the Progress Status Record, the Requirements Specification, and the Project Closure document. These templates are explicitly scoped for VSE use — for example, the Project Plan template excludes sections on subcontractor management and organizational-level resource planning that would be irrelevant for most VSEs.

Process Area Key Outcomes Essential Work Products Recommended Frequency
Project Management (PM) 6 outcomes — plan, assess, monitor, change control, review, close Project Plan, Progress Status Record, Requirements Spec, Change Request Log, Project Closure Plan at start; status weekly; review at milestones; close at end
Software Implementation (SI) 8 outcomes — requirements analysis, architectural design, detailed design, coding, unit test, integration, system test, delivery Software Requirements Spec, Software Architecture, Design Document, Code, Test Cases, Test Report, User Documentation Iterative per development cycle; full test at each release
Configuration Management 3 outcomes — identify items, control changes, audit configurations Configuration Management Plan, Configuration Item List, Change Request Records, Baseline Records Continuous; baseline at each milestone; audit at project closure
Quality Assurance 3 outcomes — plan QA activities, perform process audits, escalate non-conformances QA Plan, Audit Reports, Non-Conformance Reports, QA Records QA plan at start; audits at each milestone; continuous monitoring
Engineering case study: A 12-person embedded systems VSE implemented the Basic profile over 4 months. The primary measurable improvements were: (1) project schedule estimation error reduced from +/-50% to +/-20%, (2) customer-reported defects decreased by 60% due to formalized test processes, and (3) team member productivity increased 25% because the Requirements Specification template eliminated ambiguity during implementation.

Engineering Processes and Technical Depth

The Software Implementation process in ISO/IEC 29110-5-1-1 follows a traditional waterfall-to-iterative lifecycle adapted for VSE constraints. The standard recognizes that most VSEs cannot afford separate requirements analysts, architects, developers, and testers. Therefore, the SI process describes a streamlined approach where a single developer-tester role handles implementation, unit testing, and integration, with peer reviews serving as the primary verification mechanism. The architectural design outcome is particularly important — it requires only a high-level system context diagram and component decomposition, not the exhaustive UML documentation typical of larger projects.

Engineering warning: the most common failure point when adopting the Basic profile is neglecting the Configuration Management process area. VSEs often treat version control as optional (“we use Git anyway”) without a formal CM plan. The standard requires identifying which artifacts are configuration items, establishing baselines at milestones, and maintaining a change log. Without these formalities, even Git-tracked projects suffer from undocumented branch merges and lost requirement traceability.

A notable feature of the Basic profile is its explicit acceptance of iterative development. While the process descriptions are presented linearly for clarity, the standard notes that “the activities described in this profile may be performed iteratively.” This is a pragmatic recognition that VSEs typically operate in short development cycles with frequent customer feedback. The Requirements Specification can be a living document updated each iteration, and the architectural design can evolve as the team gains better understanding of the system.

A critical process safety consideration: the Basic profile requires a formal project closure activity including a post-mortem analysis. VSEs under schedule pressure frequently skip this step, but the standard positions it as mandatory because small teams cannot afford to repeat the same mistakes across projects. The post-mortem should answer three questions: (1) What worked well that we should repeat? (2) What did not work that we should change? (3) What unexpected events occurred and how can we prepare for them next time? Even a 30-minute closure meeting with simple notes provides disproportionate value for future projects.

Frequently Asked Questions

Q: Is the Basic profile compatible with waterfall development?
A: Yes. While the standard acknowledges iterative approaches, the process outcomes are lifecycle-neutral. A team using a traditional waterfall model can satisfy all Basic profile outcomes by completing the PM and SI activities in their natural sequence. The key is that all outcomes must be demonstrated — in waterfall, this means requirements must be fully specified before design begins, which the standard supports.
Q: What is the effort overhead of maintaining Basic profile compliance?
A: For a typical 10-person VSE, the overhead is approximately 5-10% of total project effort, mostly in the form of time spent on progress tracking, quality audits, and configuration management. This overhead decreases to 3-5% after the first year as processes become routine. The defect reduction and schedule predictability gains typically outweigh this overhead by a factor of 3:1.
Q: How does the Basic profile handle subcontractors or third-party components?
A: The Basic profile assumes a single-project, single-team context. If a VSE uses subcontractors, it should consider transitioning to the Intermediate profile (ISO/IEC 29110-5-3) which includes acquisition and supply processes. For third-party components, the Configuration Management process requires identifying and version-tracking all external dependencies.
Q: Can the Basic profile be certified by an external body?
A: Yes. ISO/IEC 29110 is certifiable, and several certification bodies worldwide offer VSE profile assessments. The assessment process for the Basic profile typically takes 2-3 days for a 10-person VSE. The standard includes a conformity assessment framework in ISO/IEC 29110-2 and ISO/IEC 29110-3 that defines the requirements for certification bodies performing VSE assessments.

Leave a Reply

Your email address will not be published. Required fields are marked *