We need to document our company's system development life cycle (SDLC) process.
So we going down the V-Model levels, and for each level, drawing a process diagram showing the flow of human processes along the way, e.g., the Requirements department does a 'gather requirements' activity, then an 'evaluate requirements' activity, then structures them, and so on (just examples, of course). So we have come up with a diagram for many of each of the V-Model levels.
But .. challenge: Then some bright spark pointed out that different projects have different scopes/sizes (call it the Size Category -- e.g., it could be just a tweak (relative to an existing project) up to a whole new platform). So… for each project as it traverses the V-Model level, depending on the project size, not all the SDLC activities (e.g., full evaluate requirements) would actually need to be performed…
So. ... ok, one way would to, for each diagram, just add notes like "if you don't need to do 'Evaluate Requirements' then don't do it…
The challenge would be to find a visual way that is complete, correct and elegant (both correct and elegant …) to show this.
As usual, I assume that my company is not the first company to run into this.
I could think up a seqeunce of mathematical set assertions defining a 'graph', but that would not be a visual diagram.
Your comments? Ideas?
Thanks,
Avraham
I most commonly use SPEM to capture processes, and I do it with Eclipse Process Composer (EPF) or IBM Method Composer. In that language and in those tools, you can define a base process and extend or subset it in a variety of ways collectively known as process variability.
Primary process elements in SPEM are roles, work products, and tasks; there are also collections of tasks into capability patterns or delivery processes. Additionally, there are various kinds of guidance such as examples, templates, supplementary materials, checklists, and tool mentors.
In general, it is important to define at least the primary process elements and not merely the tasks performed in a work flow. However, having said that, let's focus on the work flow. A workflow (capability pattern or activity) is a sequenced set of tasks with flows ordering them. In addition, there are control nodes like merge, decision, fork, and join. If you want to be lighter-weight and less formal, it's ok I think to annotate flows and optional and provide cases under which they should be perform ("optional, to be included for safety-critical systems" for example), rather than use the somewhat more formal variability semantics.
I hope this helps.
- b