We have made more improvements to the requirements language, and we’ve now started using it for project
management and effort tracking. First, you can now specify work packages for requirements. A work package also contains an estimate of the effort needed to implement the work package. You can also define which team member is responsible. In addition, as the implementation progresses, you can register actual work hours and degree of completeness for work packages. Work packages can be marked as “seen by customer” and “accepted by customer”.
To get an overview over the project, we supply several assessments. The most interesting one shows the work packages (optionally only for a given person and/or project milestone), and a little progress bar that reflects the implementation progress on the work package. The color of the progress bar changes to orange if the percentage of used effort is bigger than the percentage of work done (“bad trend”) and it becomes red if the effort is bigger than the allocated effort. Finished ones become green. There is also a little traffic light that shows “seen by customer” as yellow and “accepted by customer” as green. It’s red otherwise. Here is a screenshot:
Note how this “language” once again blurs the line between classical languages and more “application-like” things like forms or reports… (as a consequence of projectional editing!)
We are not positioning mbeddr as a standalone requirements engineering and project tracking tool (even though it is quite good at that). However, integrating these aspects into the tool makes a lot of sense for those teams that already use mbeddr for implementation. Combined with the existing support for tracing from example code to the requirements as well as for integrated design documents, mbeddr is rapidly shaping up to become a highly integrated environment for all aspects of embedded software development. In our current projects, we essentially never leave MPS/mbeddr.