Introduction (See attachment for full article)

For the past several years I’ve enjoyed a mostly informal association with the University of Southern California Center for Systems and Software Engineering (USC CSSE).  I was on-staff at USC a few years ago teaching SysML and Model Based Systems Engineering, but for the last few years I’ve been mentoring Computer Science grad students in two Masters courses: CS577 Software Engineering and CS590 Directed Research.   The Directed Research (DR) course is basically a mechanism for students who are about to graduate from the Masters program but are one or two units short of the required number to pick them up by participating in a project with a mentor from industry (that would be me).   Students are expected to work 5 hours per week per unit.  

Teaching at USC is fun (I graduated from SC back in ancient times), gives me an opportunity to work with a lot of bright young software engineers, to stay current on new technology (in particular cloud-connected mobile app development) and also gives me an excuse to work with Prof. Boehm (author of Balancing Agility and Discipline among numerous other titles), who has happily taken an interest in some of my ideas related to improving productivity by innovating better software processes and allowing me to test my ideas out with USC grad students.  

This process work has included the development of the Resilient Agile process, an attempt to develop a better agile methodology which started out as an experiment called Massively Parallel Use Case Modeling that we did with the CS577 class a few years ago where we developed a complete location-based advertising system by handing one use case to each of 47 grad students and having each student develop their use case independently.  

This semester I’m working with a group of 15 Masters students, mostly taking a single unit of  DR.  One student is taking two units, so my team has an effective time budget of 80 student hours per week.  Although the semester at USC is 16 weeks long, by the time the student teams get formed, and with midterms and finals, 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. 

Because I like challenges, we’re attempting a “crowdsouced bad driver reporting system” this semester, and because we need to be really productive, we’re using Enterprise Architect to coordinate all of the student homework.  This is the first article in a series that will describe our progress.

Are we crazy to think that we can get this system built in 3 months with a total of half-a-person-year of developer time?  Stay tuned for our next article to see how we’re doing.

Read Part 2 of this Case Study