RedCloud: RED in the Cloud

Requirements Engineering is probably the hardest part of Software Engineering because it spans widely differing areas of expertise, and because every single problem that you can think of occurrs here, too. Consider the following challenges.

• One of those tricky topics is the need to work with distributed teams, and to coordinate work among a diverse group of people, often spread globally across a supply network. Clearly, configuration and version control is a bona fide nightmare. Coordinating and planning work ahead are major obstacles. Ideally, there would be a visual schedule online that everybody can relate their work to.
• Probably the single most important aspect of requirements for any high-assurance domain like aerospace, transport, defense, utilies, medical and more is to be able to completely trace requirements: where does a requirement come from, and how does it manifest itself in the product? Part of this problem is to trace changes of specifications over time and collaborators. Again, this should occur online and in a visual fashion.
• One more thing to keep in mind is that the people that will collaborate to create requirements specification are often not expert programmers, or come from a different domain altogether. Existing versioning systems do not provide the degree of usability needed for this audience. Visualisation might also help here.

In these cases, a workflow platform to plan, coordinate, and visualize past and future activites would be needed. It should also allow to access and share specifications across space and time in a structured way and easily understandable way. That is what RedCloud does.

Core Ideas

RedCloud is based on the idea of describing an actual workflow as a UML activity diagram: ActivityRegions ("Swimlanes") represent people or organizations, ActionNodes ("Actions") represent work activities on any scales, and DataNodes ("Classes") represent work results (aka. artifacts).

Whenever project-related artifacts or activities are registered with RedCloud, they and their dependency get stored, and immediately visualized. Just by looking at the graph we can see what action led to what result, who did it, and when it was done.

RedCloud also has the notion of tense, and it can distinguish between past, present, and future tense. All actions and artifacts have a tense attached to them: if they are future tense, they represent plans, and may be changed. If they are in the present tense, it means they exist and are valid. So, they cannot be changed, they can only be superseded. If they are superseded, they may be marked as obsolete ("past tense").

Technology

The RedCloud server is implemented in Python with a MySQL database running on Docker. The front end relies on JavaScript using Bootstrap, and the GoJS library.

Availability

Currently, we are in the process of extending RedCloud to allow us to effectively handle large numbers of users, in particular students in a classroom, to monitor the application the usage and ressource consumption. These are necessary prerequisites to successfully running an application like this, so RedCloud is not publicly available at this time. We hope this will be the case in late summer or autumn of 2016. As RED, RedCloud will be open source under the Apache Licenses 2.0.

Having said that, a preview is available here. A final decision on where and how RedCloud will be hosted is still pending.

Features and limitations

RedCloud full implements the main ideas, and soon it will have the requisite administration and operation facilities. Whether it is truly practical the way it is or whether important concepts and features are missing will have to be determined the hard way. There are some issues, though, which might show ups as weak spots in the approach.

• Scalability: We expect that the traces become fairly large quickly. Also, we are currently only catering for a small number of parties in an activity, and do not support teams larger than 5 or 6. So, probably, we will need ways to abstract from a given workflow, such as outlining/folding, call abstraction, zooming, layering, or 3-dimensional presentation of activity diagrams.
• Templating: It may be required to provide templates for setting up projects, which others may than (re-)use to get started faster.
• Execution: (Re-)executing a plan (i.e., an activity in all future tense) should be possible if all actions are either connected to automatic tools, or hooked up to interactive shells to guide users through a procedure. This might include procedures in RED, so that RedCloud acts as an automation engine for RED.

In particular the abstraction idea needs to be pursued to whether and if so see how much extra work is needed before it is worthwhile to use RedCloud.