Feature #20
Add support for shared "engineering" workflows
| Status: | New | Start date: | 04/09/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | Under consideration |
Description
Workflow system should be extensible and allow users to share there workflows with other projects (this way we are not expected to deliver the end-all-be-all workflow, and instead, the community can discover what workflows work best in the tool); system should ship with some basic workflow(s) in this case so it has something even at release
History
Updated by J. Simmons about 12 years ago
One possible engineering workflow (project features should support following all or part of the workflow as needed by the projects):
- get/make requirements (to understand what you are going to build)
- setup 1 or more teams/sub-projects (small scale still just 5-10 people all one team, big scale several sub-project teams)
- create tasks that link to derived requirements to establish traceability, in multi-team scenarios, tasks should be associated with the appropriate teams/sub-projects; in single team scenario, all tasks should get associated to the main team/project when there are multiple teams, usually need a PCT (team of teams)
- loop through below, each iteration move into more detail (lofi analysis, hifi analysis, cad parts, prototype, build, fly)
- do work (each iteration = more detail: lo-fi analysis, hi-fi analysis, produce cad parts, prototype, build, fly/test) <–if we're generalizing
- document (examples: procedures, BoM, drawings, parts, analyses docs, graphs, reports, meeting minutes, presentations, Requirements docs, etc)
- review/test
- update design
- approve – triggers next iteration
Updated by J. Simmons over 9 years ago
Comments from Chris - not sure this is a considerable investment of time/energy (can't even begin to estimate it without breaking it into sub-features) and not sure people would really want to use it.