User Acceptance Driven Development Methodology - A Paradigm Shift in SDLC

All of us are thought, trained and mentored while entering into any job that “Client Satisfaction” is the ultimate goal of any project, be it a Development or Testing and “Communication” as the modem to achieve. Enough researches are being done and theories have been written on the importance of communication, impact of lack of communication and scores of ways to improve them. Still we have been seeing more often that not, failures in converting the “User Requirements” into “Functional/System Requirements” and eventually we get deprived of the expected goal (goal can be translated as project schedules or the project itself). This shows that strangely and very evidently that there is a bay of gap between the knowledge and its implementation

Human brain is the most complex puzzle to be understood by any scientific measures. “System requirement gathering”; what we mean by this is an attempt to understand such a puzzle. When we get to deal with a group of clients, the situation is more nested. We have lot of jargons; basically tools to help us out in such scenarios, like Defect Prevention (DP) techniques, Defect Detection (DD) techniques, Quality Assurance (QA) techniques, Quality Control Measures (QC) and so on. One of the common steps in each of these tools is “Review”; one handy and supposedly powerful component.

With all these tools, technologies and frameworks (simply different jargons?!), we start the development activity followed by requirement gathering (understanding??!!) series, then testing (suggest to start simultaneously, but we never could do!!?). Best of the world brains (available in the company) work together hence takes birth a product. Filled with jittery, the product is sent to the users for the evaluation what we call it as User Acceptance Testing (User Acceptance testing is the opportunity for the End user to assess the product in any way deemed necessary and appropriate to determine whether or not the product is what they wanted). During this activity, the Client verifies the product from his usability perspective. In simple terms, the client check if this product is what he wanted

I am not particularly worried about the fate of the product but the very process described above. If we scan through the process with a magnifying lens and little more attention, it can be see that we started off with discussion with “Clients” and ended with “Clients”. Where we get missed-out big time is Client’s involvement during the make of the product. As I am part of the software building process, I do understand that many of us would counter me that “the entire process is fragmented into different phases and each have a milestone or artifact to be delivered which eventually is sent out to the client for their sign off”.

If I were to picture the actual process we follow using one of the development process frameworks, it would look like the picture below.

The above picture represents the Waterfall Model, a typical and one of the conventional software development life cycles (SDLC) with all the major milestones/phases. I do not remember seeing “User Acceptance” as a milestones or phases in the model. But it’s always expected to be understood (of course without saying) that User Acceptance is one of the activities and part of testing phases.

To evidence this thought further, we can take one of the more testing friendly models, V- Model. When the importance of the testing activities were realized (theoretically), the V-Model was proposed (along with few more) focused around testing. This actually fragments “Testing” into different types as against different development phases. This model certainly improved the understanding of testing as a process but the nucleus of this model is to align the different testing methods to development phases in order to reduce the gap between these two activities (Testing & Development).

I think this is how we have been overseeing an important and an isolated phase in software development life cycle; i.e. we failed to see that User Acceptance testing encapsulates a little more than testing “alone”.

Emphasizing “User Acceptance” as a delivery milestone, the picture below visualizes the User Acceptance based software development model, at the simplest level possible. This is just a re-draw of waterfall model with a paradigm shift. The shift is from Software Development process to the User Centric Software Development Model

One of the potential challenges in this model could be “Educating the User” about the system at each phase. Because a static system is not too easy to understand, perhaps this is could be one of the primary culprits why testing doesn’t start before the actual coding is either complete or close to complete (even though we have enough visionaries talking about this in every seminar or symposium).

When the dynamic system (executable) is built and sent to the client for acceptance, the possibility of change being introduced into the system is significantly high and so the cost of introducing those changes In the Cost to Quality tradeoff, the later has always been a candidate to compromise more so with ‘testing’ as an activity. The good news is that we do see some early signs of realization that quality assurance processes (testing) contribute as much as any other SDLC activities towards the quality of the product

At the operational aspect, increased user involvement can reduce the developer’s headroom (freedom). This can influence slippage in schedule. We go back to the same trade off again; on the Cost to Quality, schedule contributes to Cost and User Acceptance contributes to Quality and again later is the potential candidate for compromise

“Agile Methodology” naturally backs the User Acceptance Driven Software Development approach. An immediate solution to most of the challenges described above is on the offering with Agile. At the simplest form, Agile helps us to run the software development marathon in small sprints, a clustered waterfall model, if I may say so.

Agile helps us to run in sprints and they can be even at a functional point level. Agile model provides the luxury of doing analysis, design, development and so testing even at each functional point level. At the end of each sprint, we get an executable (dynamic). Now we can certainly bring in the User to do an acceptance activity and hence signoff. This adds one more reason to look at “Agile” methodology.

Thereby, ‘Agility – Agile methodology’ brings in the client intimacy into the development process, this should help the software development teams to match the software requirements to the business requirements.