Read Part 1 of this Case Study
We’re attempting a “crowdsourced bad driver reporting system” this semester, and because we need to be really productive, we’re using Enterprise Architect to model the project, field-test the Resilient Agile process, and to coordinate all of the student homework. Students communicate with each other and with me using a shared EA model.
This semester I’m working with a group of 15 Masters students and an aggregate effective time budget of 80 student hours per week. We’ve got about 12 usable weeks of student time, so it works out to a time budget of roughly 1000 student hours (that’s about half-a-person-year at 40 hours a week) over a 3 month schedule.
Resilient Agile is a flexible process in that it can be employed with traditional Scrum/Kanban sprints and backlogs, or alternatively we can leverage parallelism, and each student can be assigned a use case and develop their use case independently.
I’ve been a big fan of leveraging parallelism in software development since I was a programmer at NASA/JPL way back in the 80s when I rescued a late project using a “divide-and-conquer” coding strategy, so we’re trying to see how far we can push the limits on massively parallel development with student projects at USC. Communication and well-defined interfaces are key when team members are working in parallel, so the shared EA model is critically important.
Parallel modeling and development has also been a theme of our ICONIX JumpStart classes for the last 20 years, where we go into industry and work a client’s real project by splitting the class up into “lab teams”. Typically in ICONIX JumpStart classes we put 3 or 4 students on a package of use cases, whereas on this project each student got a single use case.
If you’re going to leverage parallelism in development you have to do things a little bit differently. Here’s an overview of the process we’re following:
1. Plan for Parallelism (identify dependencies and architect for parallelism)
2. Build the Right System (discover requirements, prototype areas of technical risk, and agree on conceptual designs)
3. Build the System Right (carefully review detailed designs)
4. Integrate as often as necessary
Enterprise Architect is a key enabler of the above process. I would never attempt this approach without a good solid modeling tool at the heart of it. This article will show how we’ve used EA to accomplish the 4 steps above.
