UML: Software Engineering Institute, Game Design guidance

  • Article

Interesting isn’t it that the game design discussion on the Software Engineering Institute site seems to end around 2005, just as life gets interesting for game design.  First of all the XBox team at Microsoft releases the XNA Game Studio, allowing for the first time for people, students, professors, hobbyists and others to build games that will work on a game console.  Flash games really took off.  Blizzard gets sold for 4 BILLION dollars to Activision.  WII comes into existence.

The basics are still there though, so I guess the SEI (Software Engineering Institute) is right in keeping the same guidance on their site.  To bad things aren’t more active, the game universe is certainly cooking these days.  Chris Satchell moves to ING (International Games) to work on improving their slot machines and so forth. 

Let’s now really start focusing on a step by step curriculum for Devschool.

Overall goal: Build a game from the ground up using a process that parallels Model Driven Design or Model Driven Architecture incorporating the tools built into the Visual Studio 2010 Team Systems.  There will be variations and since UML isn’t really a standard, just a standard that might have been. 

UML main failure has been “methodology above all else”. In the practical world of getting the job done, a philosophy of methodology above all else works when you need to:

  • Fill a government contract with paperwork
  • Burn customer money by creating paper deliverables that look nice
  • Confuse customers with lots of complex icons connected with very specific kinds of lines

UML is not meant to drive methodology above all else, it is suppose to allow you to have documentation, test and requirement tools that actually assist in the construction of software that is a service for customers.  If you produce software that only solves the immediate problem, then the software can’t adapt to the changing needs of customers, which should be the nature of software.

“Methodology above all else” leads to systems that have a great deal of paperwork trapped in file cabinets, directory folders and Sharepoint sites that no one looks at after the project reaches a certain point.  The SEI articles on Arcade Games certainly demonstrates that, 4 years since any new activity.   Microsoft’s discussions and guidance around Model driven development seems a little out of date as well.  This is not the glamour of Azure, XNA or Office, it is just the stuff that makes you a software or network architect, which pays good.  image

It is still important to review that work by SEI, but in the view of Visual Studio Team Systems CTP Modeling Projects, Team Foundation Server, and other integrated tools such as Microsoft Operational Management are important to building successful software, games as an example, that can thrive and adapt to the changing environment.

Using the SEI form, the Devschool blog will generally follow this curriculum (in the usual timeline followed by blogs):

The use of methodology is more to save you when dealing with customers, getting your invoices paid.  Appropriate use of methodology is a way to help you when your main developer has flown the coop, gotten sick or pregnant at a critical moment with respect to the project (I am reminded of a client who’s principle software architect died suddenly and they couldn’t get to his files).  An integrated methodology, like Visual Studio—Team Foundation Server—Microsoft Operational Management (MOM) can save you time when it really counts.

For the next few months, I will be reviewing how to build a game company using Visual Studio—Team Foundation Server—MOM/Azure, with the thread focused on real life use of methodology, not “methodology over all”.

If you need to get up to speed with UML, definitely visit the UML blog, in this case UML stands for Ulterior Motive Longue, who knew UML could be so much fun!