Author: daveparsonsnz

How the web saved my life

Well, OK, gross exaggeration, but not entirely untrue. I regularly receive those email offers from ‘daily deal’ web sites, where you get 24 hours to pick up a deal. I must confess some of these have been a bit dodgy. for example, what possessed me to buy a $65 video camera? Anyway, a few weeks ago there was an offer for a mole map and skin check, so I decided to take it up. Turned out I had a mole on my back that I couldn’t see that had to be urgently removed. The biopsy showed it wasn’t yet a melanoma, but had I not been inspired to have the skin check by my web-based daily deal it might have been a different story. Around the same time, I took up an offer to update my will. Luckily the two turned out not to be connected. Anyway, the purpose of this post is to encourage everyone to get regular skin checks. You never know, it might save your life.

Do you show the customer a class diagram?

I had an interesting email exchange with one of our extramural students who works as a Business Analyst. He was recently told by a developer that class diagram modelling should only be done by developers, not by the BA. However, I imagine the developer’s definition of ‘class diagram’ was the kind of detailed design level class diagram that developers might use. The type of class diagram we use in analysis is the domain model, which uses a subset of the notation of a class diagram. The role of the domain model in the analysis phase is to clarify business rules such as, for example:

  • can an account holder have more than one account?
  • how many courses can a student enrol for at any one time?
  • how many course credits comprise a degree?
  • how many standby tickets can be issued for a flight?
  • etc.

These types of rules can be expressed in text, but I personally think they are much better expressed in a domain model. This would only include business concepts and their relationships, with some key attributes, and possibly some core operations. Here is a very simple example:

Image

This part of a domain model expresses that a policy holder must hold one or more policies, that policies have one (and only one) policy holder, that zero or more claims can be made against a single policy, that claims have a reference number, that policies have a policy number, and that policyholders have a customer ID.

To me the diagram is simpler, clearer and more explicit than the text version of these 6 core business rules. The question is, I guess, whether your customer feels the same way. I would suggest that the effort involved in learning that a rectangle represents an important business concept, and that lines show important relationships between these concepts and their multiplicity, would be trivial compared to the benefits of clearer, unambiguous definition of business rules. I’d be interested to hear from any BAs about whether they do or don’t use domain models.

Learning with one-to-one devices

I’ve just attended the ‘through the Looking glass’ conference at Orewa College, which is in the second year using of student owned one-to-one digital devices in all classes. Some interesting themes are emerging, including:

  • use of one-to-one devices is becoming ‘normal’
  • teachers are becoming familiar with the boundaries between use of digital devices, and situations where more traditional tools and materials are still more appropriate (e.g. music manuscript books)
  • There is a point where the students have had enough use of digital devices and just want to get on with the activity.
  • on-line videos of instruction (preferably made by the students and teachers) are enabling not only ‘flipped classrooms’ but a more fluid model of teaching where no teacher to class presentations are required. Teaching becomes one to one
  • some teachers are embracing public tools from the students’ own lives like Facebook. others have reservations about this approach. Choice of tools is an ongoing debate and exploration.

Overall, the process involves finding out how one-to-one devices can be made to work in all subjects for all types of student. The staff and students at Orewa are making good progress on that journey.

Great new IT systems (not) Part 1

For many years we had a very workable timetabling system at the university, with local input and control. Now we have a new expensive centralised system that is not only determined to ensure our classes start at 8 and finish at 6 (‘utilisation’) but also to ensure that staff and students get different views of the timetable (it’s so secret I have to log in to see it), leading to great confusion and timewasting. I had half a class at my 8am lecture this morning due to this new system. Example 1 of how not to do software by putting macro corporate policy over practical requirements on the ground (more to follow)

Novopay – this year’s case study

With new classes about to start at Massey University in Systems Analysis and Design, and System Management and Testing, I could not have wished for a more topical local software systems disaster than the the New Zealand Novopay debacle. What a great case study in how not to procure, deliver, test or manage software! There can be few people in New Zealand who haven’t been affected by this deeply flawed system.