Divengine StudioA process you run, not a document you read
Studio ships with the Unified Process: phases, iterations, milestones, disciplines, activities and work products are records, and the rules that connect them are explicit. Rigor stays lightweight because the software keeps track for you.
One supported process, not the limit
The Unified Process is the process Studio supports today. It governs when work happens and who decides. The engineering context it governs (records, typed traces, revisions, evidence and baselines) does not depend on it.
Records first
Requirements, decisions, models, tests and their traces mean the same thing whatever process produced them.
Process on top
Phases, milestones, readiness and change control add governance: who may change what, and when it was agreed.
Methods alongside
Process-orthogonal methods such as ESEM constrain what must be explicit, not the sequence of work, so they can apply within any process.
Four phases, four milestones, as many iterations as you need
Inception ends in Lifecycle Objectives, Elaboration in Lifecycle Architecture, Construction in Initial Operational Capability and Transition in Product Release. Each phase is planned in iterations with dates and goals.
- Activities per iteration, with discipline, owner, state and deadline
- Governed work products: the Vision, the architecture description, builds, reports
- Process roles assigned to people, discipline by discipline
Know what is missing before the milestone meeting
Readiness explains, criterion by criterion, what your process asks for and what is still missing: unapproved requirements, unreviewed use cases, work products without baseline, disciplines nobody covers, requirements without tests.
It is advice, not a gate: reaching a milestone stays a human decision, made with the facts in front of you.
Tailor the method to the project
A development case says how much each discipline, activity, work product and readiness criterion matters: required, recommended, optional or disabled, optionally per milestone. Studio ships a lightweight Standard case and an Existing System case for brownfield work, and you can create your own.
- Each Development keeps a snapshot of the case it applied, with its version
- Change the case later and re-apply it when you decide
What a development case decides
| Level | Effect |
|---|---|
| Required | Readiness reports it as “Missing” until it is there. |
| Recommended | Reported as “Not yet”, never as missing. |
| Optional | Available when useful, never reported as missing. |
| Disabled | Left out for this kind of Development. |
Readiness is always advisory: reaching a milestone stays a human decision.
Change requests with a memory
A change goes from submitted to triaged, accepted or rejected (with a written rationale), scheduled in a target iteration, implemented, verified and closed. It impacts explicit records, and from those records the existing traces lead to the decisions, models, code and tests that may need to change.
- Who decided, when and why, always recorded
- Change requests waiting for you appear in My work
Reproduce exactly what was agreed
Traces point to records; baselines point to the exact revisions that were in force. Studio takes one automatically when a milestone is reached, and you can take your own at any time. A revision held by a baseline is never deleted, so the context of a past decision can always be reconstructed.
Automatic
Every reached milestone freezes the baselined records and their traces.
Protected
Revisions referenced by a baseline are kept, whatever happens next.
Complete
Not just documents: the exact traces between them, so the picture is whole.
Process is only half of it
The process governs records: see how requirements, decisions, models and knowledge are captured and connected.