Week 8: Building Systems

Patrick has returned to kick off a two-week series on System Development and Project Management, but Daniel will be back. I’ve returned to the Central Lecture Block series.

We start with some discussion of the three approaches to development:

  • The Waterfall Model. The development lifecycle is split into discrete stages: (1) requirements, (2) design, (3) implementation, (4) verification, (5) maintenance. Note how the first 3 steps correlate with Herbert Simon’s intelligence/design/choice! The Waterfall model is typically used for larger projects. Its name comes from the fact that, once a stage is completed, you don’t come back to it – water only falls down.
  • Iterative Development. Basically the same idea as the Waterfall model, but you lather, rinse, repeat until everything is as you want it.
  • Agile Development. This is a very modern approach, basically continuous iteration. It’s also very messy in a sense because all the stages blend together so it’s more like a whirlpool bubblebath thunderstorm than an elegant waterfall. But it has some very good values: constant communication, results over documentation; less planning, more action! To demonstrate Agile development, Patrick shows us a picture of a developer and a customer working on the same computer, but it’s taken from the side so it looks like one person with two heads. In a sense, that completes the metaphor! Another metaphor he throws in is that Agile Development is a bit like WYSIWYG HTML editors – the developer and the user see eye-to-eye.

Apparently, gathering user requirements is the hardest step. I’ll agree here. We had to make a database for INFS1603, and sometimes we had no idea what they wanted. “The worst way to find out what people want is to ask them directly”, Patrick explains. I’m reminded of Henry Ford’s quote, “If I’d asked people what they wanted, they’d have said ‘faster horses'”. Patrick implicitly proposes two alternatives:

  • Critical Success Factors (CSFs). Get a list of the key functionalities that the system has to have in order to be deemed successful.
  • Prototyping. Gather some basic requirements (CSFs?), make assumptions as necessary, and build a prototype – a fully-functional model – so the users can give feedback. This is pretty much what we did in INFS1603.

Patrick goes on to talk about design tools (data flow diagrams, Unified Modelling Language, physical design on paper, and the value of simplicity in web design – nothing too new). The point is made that you don’t always have to program your own software; you could use web services (Simple Machines Forum, MediaWiki, Drupal, phpBB, oh my!), or you could outsource your programming task, or you could even outsource the service that the software would have provided!

Finally, we hit some familiar territory with the implementation process. The four methods of conversion (direct, parallel, phased, pilot) are introduced though Patrick refers to ‘direct’ as ‘cut-over or flash-cut’, and ‘parallel’ as ‘redundancy mode’. He goes on to stress the importance of testing, documentation, and of course maintenance (which allegedly comprises “up to 80% of IS budgets”).

The case study for this week has two parts. The first part involves dissing an existing system and attributing all its faults to poor system development. Tony focused on communication issues. Part two was a debate about the merits of open source software. There are some formidable and quite knowledgeable people in my tutorial class.

The textbook reading for this topic is actually quite substantial. It covers a lot of business-y stuff like the different levels of organisational change (automation, rationalisation, redesign, paradigm shift), and the business case. I particularly like its guidelines for presenting a business case based on different types of arguments:

  • Faith. “I can’t prove it, but I have a feeling that we need this system because ___. You can trust me”. Did someone say ‘expert power from MGMT1001’?
  • Fear. Hit them where it hurts. Implement the system or go out of business. Implement the system or lose market share. Pretty much, um, negative faith?
  • Fact. Evidence speaks loudly, especially to managerial/business types. The textbook does a nice overview of concepts like Total Cost of Ownership (TCO), and Cost-Benefit Analysis. I suppose Return on Investment (ROI) is implied there, somewhere.

The textbook also gives a more precise perspective on Agile development, which it defines as “rapid delivery of working software by breaking a large project into small subprojects completed in short periods using iteration and continuous feedback”. It’s a mouthful, but it has everything! We are also exposed to some similar concepts like Rapid Application Development (RAD) and Joint Application Design (JAD), which share features with Agile (namely, speed and user-developer collaboration, respectively).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s