Our product is part of a service for end-to-end application prototyping applications. Prototyping is usually a complex task combining many different expertises: doing requirement analysis, transforming those formal diagrams into UML diagrams (classes, activities, and for our work use cases), designing data relations based on those diagrams, and finally evaluating your prototype. Our editor allows requirement analysts to design a complete use case diagram in an online interactive web editor, or load use case diagram components created based on a requirements document into the editor. Users can add and remove components such as use cases and actors, rename them, add descriptions, and use case steps. Between these components, relationships can be added, such as associations between actors and use cases, and generalizations between two actors. Our application allows for rapid development of use case diagrams, because of the intuitive use of our editor. Existing components can be loaded and spread our over the editor canvas with a button. Components in the editor can be easily moved with the mouse, their attributes can be edited by clicking on a node and using the menu that pops up and shows all relevant fields for each component type.
Our client is Guus Ramackers, a professor at the Leiden Institute of Advanced Computer Science. He has relevant experience as a Senior Principal Product Manager at Oracle (in the United States), which shows in how his requirements were clear and concise. At first our meeting were in person but eventually we did online calls exclusively. Guus was always happy to see new results which is by itself very motivating. Guus was also the client of another team, who would work on a different aspect of the UML project. Due to this we sometimes had meetings together with the other team which was helpful, as they ask sometimes questions that are relevant to us but we didn't think of yet. There were also master students who worked on this project. Two of them, Bram and Max, were of great assistance to us. We could ask them technical questions any time and they often attended meetings to answer questions and because they were also interested in our progress. Overall the project we were dealt was a tough one, but the client and the master students did everything they could to make it uncomplicated.
We had members with various skills, but most of the project consisted of technologies that we had not used before. This meant the project was a learning experience for all of us. Although we each had different approaches to learning these new technologies, our more experienced members were always prepared to help when issues arose. Not everyone was always present during our scrum and client meetings, but our collaboration sessions every Thursday were a great way to work on issues that appeared during the sprint, or getting work done together. We do think that it was hard to work with members of various experience levels, but we learned a lot through giving and receiving help.