SOFTware is HARD

UML appears to be dying in the light of the Agile development movement. working software over comprehensive documentation Many have wrongly interpreted this to mean no documentation. I recently read up C4 model for software architecture that describes the software architecture of a system from different depth & perspectives and for a different audience. The author promotes the use of a common vocabulary to describe software architecture using simple-to-understand diagrams. I attempt to do similar in this post using the same case study as that of the C4 article. The differences are: I do not wish to go into  Class (the 4th C) as that requires too much implementation details I replace the 4th C with Concept as I personally find the Conceptual model more relevant and important in appreciating the business domain.   Using Astah , I figured out how I can model the 4C software architecture efficiently using UML. Mind-Mapping I started with a Mind...

Capture user stories in the form of: As a <user role/type> I want <some action/ feature/ goal>, so that < benefits from/ reasons for it> Capture acceptance tests in the form of: GIVEN (some context/precondition) [ AND (some more context/precondition) ...] WHEN (event/action performed by user) THEN (expected outcome - what should happen to satisfy user requirement from the user story statement above). See https://www.infoq.com/articles/standardize-requirements-scrum

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...

Full presentation available here . A list of salient points follows: How to define success? Developers want Agility & Change Operations want Availability & Stability F1 car lifecycle Design –> Develop –> Test –> Deploy –> Support Support (Operations) need to always provide feedback to Design (Development) Engineers need to work hand-in-hand with Operations Success must be measured F1: Telemetry and monitoring are required to deliver drivers’ results IT Systems: Performance data collection and analysis as well as performance monitoring are required to deliver success Monitoring is critical in managing change Need to constantly monitor and manage impact of change. Need to provide feedback for where the car: Is fast – where things are done right Is slow – where to optimise and improve Failed – where to fix Three key aspects that impact application performance Concurrency Data volume Resources Where does one find the real bottlenecks? Not of...

Let’s admit it: any form of system documentation is not up-to-date . The moment we start producing it, it is out-of-date. If that is the case, we should do with minimum (perhaps, lean) system documentation that is kept current. This begs the next question: How little is enough? If I imagine myself taking over a system from someone else, I believe the minimum/ lean system documentation should contain the following: Solution Design description of the high-level process flow description of the main modules/ services in the system what are the architecturally significant use cases or main functions of the system? what processes/ components make up the system? E.g. Are there web-based applications? Are there batch processes? what are the databases in use? What are the primary (entity) tables in use? what output is generated by the system? E.g. Are there printed output? Are there output for system integration? Are there messages (emails/ SMS) sent? what systems are integra...

These are some tools recommended by a book for .NET CI: White ( http://white.codeplex.com/ ) for automated testing of Windows Forms Selenium ( http://seleniumhq.org/ ) for automated testing of Web Applications Non-Sucking Service Manager ( http://iain.cx/src/nssm ) for running applications as Windows Services FitNesse ( http://www.fitnesse.org/ ) for automating Acceptance Testing FitSharp ( http://www.syterra.com/FitSharp.html ) for .NET FxCop ( http://www.microsoft.com/downloads/en/details.aspx?FamilyID=917023f6-d5b7-41bb-bbc0-411a7d66cf3c ) for analysing .NET code SandCastle ( http://sandcastle.codeplex.com/ ) for compiling documentation HelpFile Builder ( http://shfb.codeplex.com/ ) WiX ( http://wix.sourceforge.net/ ) for building Windows installation packages Publishing of: ClickOnce using Mage ( http://msdn.microsoft.com/en-us/library/acz3y3te.aspx  and http://msdn.microsoft.com/en-us/library/xhctdw55.aspx ) or MsBuild Web Application using MsDeplo...

I chanced upon an article on agile estimation that I read with interest in InfoQ. Many of the techniques are not new with the exception of the WAG generator. I find such estimation techniques to be very useful even if the subject matter is not software-related. Check out InfoQ: Estimation Toolkit

A mindmap review of a book on agile practices. Flash version can be found here

The mindmap review of this book. Flash version can be found here

A mindmap review of a book abour Agile Practices. Flash version can be found here

Comparison table: Skill level of developers: Possible hybrid approach for Brownfield projects Site survey Engineering Discovery Re-engineer Generate Test Acceptance Deployment What went wrong with a particular government project? Requirement solicitation happened prior to any development (as part of the tender exercise) Vendor organisation (especially management) isn’t agile enough but customer insisted on unprecedented RAD approach Supposed prototyping team is Overworked – had to develop the prototype during office hours and prepare for presentation after that Not agile enough Not trained to be agile What went wrong with a particular private out-sourced project? Requirement solicitation happened prior to any development (as part of the requirements specification Requirements specification was contractual Customer isn’t agile enough and was not well-prepared for SCRUM (lack of training, knowledge and acceptance) Project started with Wa...

At times, it is a good idea to deferred decisions until the last responsible moment. In so doing, more information may be made available such that a more informed decision can be made. Deferred Decision - Delay commitment (decision or making a choice) until the last responsible moment (when inaction would results in a potentially irreversible outcome)