SOFTware is HARD

I had the opportunity to develop a prototype for a client and used Astah to capture the salient specifications as well as the requirements analysis. Mindmap To first understand the requirements, I used a mindmap to guide the user through the mean features of the application. What worked well in this instance was a role-based model (similar to use case modelling), i.e. list out all the roles involved in interacting with the application. Next, the features or use cases for each role gets listed out (“as a <role>, I want to be able to <feature>”) The final mindmap served as a form of an agreement on the scope of work. The final mindmap looked like the following:   Use Case Modelling Using Astah, I was able to easily convert the Mindmap into a set of Actors and Use Cases for further analysis. The model follows:   Domain Model As the prototype had dependencies on an existing application, some of the domain objects were deliberately taken from the the exi...

I originally had a great deal of difficult reconciling the differences amongst ITIL Change Management, Incident Management, and Problem Management. Having researched on the subjects and understanding them better now, I’ve tried to put the concepts together using a UML class diagram to capture my understanding and to keep it imprinted. Similarly, I wanted to differentiate the various categories of changes (Standard, Emergency, Normal) using an easy to understand & self-explanatory manner – a UML Activity Diagram!

This is a simplified diagram that captures the business process for a Life Insurance new business workflow. The high level process is captured using an UML Activity Diagram.

I had a mini-experiment to document my design in UML for a developer to write the corresponding code. The background and assumptions are: The application is an insurance quotation system Design is based on MVC, in particular, ASP.NET MVC Web caching is used The basic MVC application framework is in place (with sample codes) The developer is an intern from a local university What is designed to be developed is one of the modules in the entire application – this particular module is a dashboard Without going into the details of the use case document, I created the basic tenets: certain basic sequence of events as well as the View-Of-Participating-Classes (VOPC). The mini-experiment proved to be a success to my surprise. The following UML Sequence Diagrams capture the basic flow for the initial web request: The following UML Sequence Diagram depicts the sequence of events for subsequent access: Finally the VOPC UML Class Diagram follows:

Sometime ago, I was reviewing the alerts and notifications sent from various applications and systems. We needed to capture and store the content of the messages. I took the opportunity to re-architect the entire landscape by documenting the as-is, as well as the to-be. The UML Communication Diagram – an unsung hero – was used for this purpose. The as-is integration mess: The to-be design – looking a lot better:

Recently, I had been dealing with other areas of IT including operations & governance. The following Activity Diagram documents how a typical institution might have to respond to security incidents.

A mindmap review of the powerful Bible study material. Flash version can be found  here