6 Systems Engineering Plan
6.1 Project Overview
6.1.1 Objectives
Per [1, Sec. 2.3.4.1], the project planning process establishes plans for accomplishing project objectives within project constraints. This section defines the project’s technical and programmatic objectives.
Technical Objectives:
- Develop an open source MCP server that bridges AI assistants with SysML v2 models
- Integrate with Git providers for model storage and version control (GitLab as reference)
- Integrate with SysML v2 API for model validation and querying
- Support both stdio and HTTP transport for flexible deployment
Programmatic Objectives:
- Demonstrate INCOSE systems engineering principles for academic capstone
- Produce three academic publications:
- GVSETS 2026: AI-augmented MBSE with MCP (Mar-Apr 2026)
- Grammar Transposition: KEBNF to tree-sitter methodology (2026)
- INCOSE 2027: SE benchmark for AI evaluation (2027)
- Establish open source project with community contribution potential
- Contribute tree-sitter-sysml grammar to tree-sitter organization
- Position within SysML v2 ecosystem: complement Sysand (package management) and SysGit (commercial platform)
6.1.2 Scope
In Scope:
- MCP protocol implementation (tools, resources)
- Git provider API integration (read, list, commit, MR) with GitLab as reference
- SysML v2 API client (projects, elements, queries, validation)
- Basic SysML v2 textual parsing
- Container deployment support
- SE documentation (SEP, SyRS, ADD, VVP, RTM)
- Demonstration workflow: GitLab + Duo + OpenCode
Out of Scope:
- Full SysML v2 grammar compliance (current scope is documented subset per Section 12.2; full compliance is future work)
- Multi-agent architectures
- Additional Git providers (GitHub, Gitea) - architecture supports, not implemented
- AI benchmarking framework (future INCOSE paper topic)
- Direct GitLab upstream integration (remains independent open source)
6.1.3 Constraints
| Constraint | Impact | Mitigation |
|---|---|---|
| 15-week timeline | Limits feature scope | Prioritized phased delivery |
| No local container builds (macOS) | CI-only container testing | Document in VVP, test in CI |
| SysML v2 API server complexity | Optional dependency | Basic parsing works offline |
| Academic deliverables parallel | Shared effort required | Clear RACI, integrated schedule |
6.2 Lifecycle Model
We adopt a hybrid approach: Agile sprints for implementation velocity with formal SE gates (SRR, PDR, CDR) for academic rigor.
Pre-work: Early January 2026 - Initial research into SysML v2 specifications and prior art.
Week: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
├────┴────┼────┴────┼────┴────┴────┴────┴────┴────┼────┴────┴────┴────┤
│ Concept │ Design │ Implementation │ Validation │
│ │ │ │ & Delivery │
│ │ │ │ │
SRR PDR ─────── Sprints ─────── CDR Final
(Wk2) (Wk4) (Wk12) (Wk15)
6.3 Technical Reviews
| Review | Week | Purpose | Participants |
|---|---|---|---|
| SRR (System Requirements Review) | 2 | Baseline requirements, approve SEP | Andrew Dunn, Greg Pappas, Dr. Rapp |
| PDR (Preliminary Design Review) | 4 | Approve architecture, confirm build plan | Andrew Dunn, Greg Pappas, Dr. Rapp |
| CDR (Critical Design Review) | 12 | Verify implementation, approve for delivery | Andrew Dunn, Greg Pappas, Dr. Rapp |
6.4 Review Entry/Exit Criteria
6.4.1 System Requirements Review (SRR)
- Entry: Problem statement defined, stakeholders identified, draft SEP
- Exit: SyRS baselined, SEP approved, risks identified, PDR scheduled
6.4.2 Preliminary Design Review (PDR)
- Entry: Requirements stable, architecture concepts documented
- Exit: ADD approved, interfaces defined, implementation plan confirmed
6.4.3 Critical Design Review (CDR)
- Entry: Implementation complete, V&V executed
- Exit: All acceptance criteria met, ready for delivery
6.5 Schedule
| Week | Dates | Phase | Key Activities | Deliverables |
|---|---|---|---|---|
| 0 | Jan 1-11 | Pre-work | Research SysML v2 specs, prior art analysis | Research notes |
| 1 | Jan 12-18 | Concept | Finalize plan, set up repos, Quarto scaffold | This plan document |
| 2 | Jan 19-25 | Concept | Requirements elicitation, stakeholder analysis | SRR: SEP v1, SyRS v1 |
| 3 | Jan 26-Feb 1 | Design | Architecture development, interface definition | ADD draft |
| 4 | Feb 2-8 | Design | Design review, V&V planning | PDR: ADD v1, VVP v1 |
| 5 | Feb 9-15 | Impl | Phase 1: tree-sitter-sysml grammar foundation | Grammar scaffold, 10% coverage |
| 6 | Feb 16-22 | Impl | Phase 2: Extended grammar | Requirements, actions |
| 7 | Feb 23-Mar 1 | Impl | Phase 2: Extended grammar | 50% coverage target |
| 8 | Mar 2-8 | Impl | Phase 3 start, GVSETS draft prep | MCP server integration |
| 9 | Mar 9-15 | Impl | Phase 3: MCP server integration | sysml_parse, repo tools |
| 10 | Mar 16-22 | Impl | Phase 3 complete | Full tool suite |
| 11 | Mar 23-29 | Impl | Integration testing, bug fixes | Stable release |
| 12 | Mar 30-Apr 5 | V&V | V&V execution, CDR prep | CDR: V&V results |
| 13 | Apr 6-12 | Delivery | Paper revision, demo prep | GVSETS final paper |
| 14 | Apr 13-19 | Delivery | Documentation finalization | Final docs |
| 15 | Apr 20-25 | Delivery | Capstone submission | Final documentation package |
6.6 Key Milestones
| Date | Milestone |
|---|---|
| Jan 12 | Concept phase begins (Week 1) |
| Jan 18 | Plan review with Greg Pappas and Dr. Rapp |
| Feb 14 | SRR and PDR conducted |
| Mar 23 | GVSETS draft paper submitted |
| May 1 | GVSETS notification of acceptance |
| Jun 5 | GVSETS final paper submitted |
| Jul 23 | GVSETS final presentations due |
| Aug 11 | GVSETS paper presentation (Novi, MI) |
| Apr 25 | Capstone deliverables complete |
6.7 Configuration Management
6.7.1 Version Control
- Branching Model: GitLab Flow (main + feature branches, MRs required)
- Commit Convention: Conventional Commits (feat:, fix:, docs:, chore:)
- Protected Branches: main requires MR approval
6.7.2 Artifact Versioning
| Artifact | Versioning Scheme |
|---|---|
| Software | SemVer (v0.1.0, v0.2.0, …) |
| SE Documents | Date-based (SEP-2026-01-22) or revision (SyRS v1.0, v1.1) |
| Container Images | Git SHA + SemVer tags |
6.7.3 Baseline Management
| Baseline | Contents | Established At |
|---|---|---|
| Requirements Baseline | SyRS v1.0 | SRR (Week 2) |
| Design Baseline | ADD v1.0, VVP v1.0 | PDR (Week 4) |
| Product Baseline | Software v1.0, final docs | CDR (Week 12) |
6.8 Risk Management
Per [1, Sec. 2.3.4.4], the risk management process identifies, analyzes, treats, and monitors risks throughout the project lifecycle.
6.8.1 Risk Categories
| Category | Description |
|---|---|
| Technical | Risks related to technology choices, implementation complexity |
| Schedule | Risks related to timeline, resource availability |
| External | Risks from external dependencies, stakeholder changes |
| Quality | Risks related to defects, compliance, acceptance |
6.8.2 Risk Scoring
Likelihood: Low (1) / Medium (2) / High (3)
Impact: Low (1) / Medium (2) / High (3)
Risk Score: Likelihood × Impact (1-9)
6.8.3 Risk Register
| ID | Risk Description | Category | L | I | Score | Treatment Strategy | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| R1 | SysML v2 API server difficult to deploy locally | Technical | 1 | 2 | 2 | Avoided: Repository tools implemented without API dependency; SysML v2 API deferred to post-capstone. | Andrew | Mitigated |
| R2 | GVSETS paper deadline aggressive given parallel implementation | Schedule | 2 | 2 | 4 | Accept: Draft deadline Mar 23 with 5-week buffer to final (Jun 5). Benchmark execution remains critical path. | Andrew | Open |
| R3 | Stakeholder availability for reviews limited | External | 1 | 2 | 2 | SRR and PDR completed Feb 14 with all stakeholders present. | Greg | Closed |
| R4 | Rust MCP SDK or tree-sitter bindings have limitations | Technical | 1 | 3 | 3 | rmcp SDK and tree-sitter Rust bindings proven by working implementation (5 MCP tools, 22 tests passing). | Andrew | Closed |
| R5 | Container testing blocked on local macOS development | Technical | 3 | 1 | 3 | Accept: CI-only container validation; document limitation in VVP. Local testing uses native Rust binaries. | Andrew | Open |
| R6 | Scope expansion from ecosystem exploration | Schedule | 2 | 1 | 2 | Accepted: Scope expanded to 7 projects (grammar benchmark, kebnf converter, PhD planning) but did not impact GVSETS publication, tree-sitter-sysml release, or MCP server delivery. Expanded scope provides deeper ecosystem understanding that strengthens future work articulation in publications. Managed via multi-agent orchestration with specialized skills and personas. | Greg | Mitigated |
| R7 | SysML v2 specification changes during project | External | 1 | 2 | 2 | OMG spec stable; grammar achieves 99.6% external file coverage. No spec changes encountered. | Andrew | Closed |
| R8 | Grammar complexity requires external scanner | Technical | 2 | 2 | 4 | 100% training file coverage and 99.6% external coverage achieved without external scanner. All constructs (expressions, constraints, states, actions) handled by pure grammar.js. | Andrew | Closed |
| R9 | Tree-sitter org may not accept grammar contribution | External | 2 | 1 | 2 | Accept: Standalone value regardless. GitLab vendor/grammars/ is alternative contribution path. Grammar benefits MBSE community either way. | Andrew | Open |
6.8.4 Risk Monitoring
Risks will be reviewed at each technical review (SRR, PDR, CDR) and during weekly sync meetings. New risks should be added to this register with initial assessment.
Escalation Criteria: Risks with Score ≥ 6 require immediate mitigation plan and advisor notification.
6.9 Review Status
This section tracks actual review completion status. Entry/exit criteria are defined in Section 6.3.
Attendees for all reviews:
- Andrew Dunn (Technical Lead, GitLab Public Sector)
- Greg Pappas (SE Lead, DoD Army AFC-DEVCOM)
- Dr. Stephen Rapp (Advisor, Wayne State University ISE)
6.9.1 Status Summary
| Review | Target Date | Actual Date | Entry Criteria | Exit Criteria | Status |
|---|---|---|---|---|---|
| SRR | Jan 25, 2026 | Feb 14, 2026 | Met | Met (with caveats) | Complete |
| PDR | Feb 8, 2026 | Feb 14, 2026 | Met | Met (with caveats) | Complete |
| CDR | - | - | Pending | Pending | Not Started |
6.9.2 SRR Readiness Checklist
Entry Criteria (per Section 6.3):
Artifacts Reviewed:
| Artifact | Section | Status |
|---|---|---|
| SEP v1 | Section 6.1 through Section 6.8 | Complete |
| Stakeholder Analysis | Section 8.1 | Complete |
| Stakeholder Needs | SN-001 through SN-015 | Complete |
| Stakeholder Requirements | SR-001 through SR-015 | Complete |
| SyRS v1 | Chapter 7 | Complete |
| Risk Register | Section 6.8 | Complete |
Exit Criteria:
Caveats (accepted per tailoring rationale):
- Interface requirements (IR-xxx) deferred — formal IDs not required at this stage; interfaces documented informally in Section 10.10
- Stakeholder validation conducted informally through iterative development rather than formal interviews
- Requirements baselined with understanding that implementation discoveries (particularly benchmark execution) may drive updates
Tailoring Rationale: SRR was conducted to bootstrap the project and inform the GVSETS publication as the primary capstone deliverable. Requirements have evolved as scope expanded through implementation. Post-capstone work will proceed informally in sprint-based iterations. Per INCOSE Handbook 4.3.4, this tailoring is appropriate for a software-intensive academic project with a small team.
6.9.3 PDR Readiness Assessment
Entry Criteria (per Section 6.3):
Artifacts Reviewed:
| Artifact | Section | Status |
|---|---|---|
| ADD v1 | Section 10.1 through Section 10.14 | Complete (context diagram, component architecture, trade study, deployment modes) |
| VVP v1 | Section 11.1 through Section 11.8 | Drafted (verification strategy, test cases, CI pipeline) |
| RTM | Section 16.1 through Section 16.4 | Complete (4 trace layers) |
Exit Criteria:
Caveats (accepted per tailoring rationale):
- VVP requirement IDs need reconciliation (FR-Umcp→FR-MCP naming mismatch) and substantive update to reflect actual implementation test structure
- ADD tool definitions need update to reflect Phase 1 actual tool names vs. planned names
- Same tailoring philosophy as SRR: implementation-informed, GVSETS-focused, post-capstone work proceeds informally
Tailoring Rationale: Architecture was validated by successful implementation (tree-sitter integration, 5 MCP tools operational, 100% training coverage) prior to formal PDR closure. This “build then verify” approach is appropriate for a rapid-iteration academic project per INCOSE Handbook 4.3.4.
6.9.4 Action Items
| Review | Item | Owner | Due | Status |
|---|---|---|---|---|
| SRR | Baseline SyRS after advisor approval | Greg | Feb 14 | Complete |
| SRR | Update SEP with review outcomes | Andrew | Feb 14 | Complete |
| PDR | Complete ADD draft | Andrew | Feb 14 | Complete |
| PDR | Draft VVP strategy | Greg | Feb 14 | Complete |
| PDR | Reconcile VVP requirement IDs (FR-Umcp→FR-MCP) | Andrew | Feb 14 | Complete |
| PDR | Update ADD tool definitions to match implementation | Andrew | Feb 14 | Complete |
| PDR | Update VVP test cases to reflect actual test structure | Andrew | - | In Progress |
Action items updated after Feb 14, 2026 SRR/PDR closure session with Greg Pappas.