Role of Processes in Software Development

Introduction

The ultimate goal of any Software delivery is Client Satisfaction. If client is satisfied with the delivered software or project then it doesn't matter which technology was used or whether any process was followed or what architecture, design and agile methodologies were used. But if the client is unhappy then all applied processes, all latest technologies used to develop it and all applied design patterns/architecture methodologies seem useless. Then, why do we all emphasize to use them or follow them all the time? What is the importance of talking about these things and how much are these relevant for real-time software development?

Background

First of all, we should understand that processes are not merely responsible for timely delivery of software with high quality, but also to set us free from lots of high expectations of the client. All of us know there is no limit of expectations. If the delivery doesn't contain any problem and the client is satisfied with it, we are lucky. But if it is opposite, then we are in great trouble. Because once the software has been delivered, every valid reason for this situation is not more than lame excuses. And often, we face this kind of situation.

We will not discuss about the common design or architecture problems here but we will see later what leads us to make common mistakes while creating design and architecture for any application.

Let’s discuss the common reasons that make any client unhappy.

Delivered Software Doesn't Behave As Per the Actual Requirements

It's very sad part and even hard to realize for the IT world, 50% software fails just because of inadequate requirement management. This kind of problem falls under Inception and Elaboration phase. Inception phase provides only a very vague idea of the requirements like business rationale of the project and scope of the project, etc. During Elaboration phase, it is insisted to capture and freeze the requirements with mutual agreement and written approval by the Client and Stakeholders. So, after the delivery of software client could not disagree on its behavior. Only he can suggest some enhancements or modifications. All these suggestions can be easily converted to new requirements for the next phase.

Delivered Software Doesn’t Behave as Per the Expectations

Normally this kind of problem occurs due to ignorance of risks involved in the project or inadequate analysis for some of the common problems involved in almost applications like actual load on the application, number of concurrent users, expected performance, security, level of dependencies on external applications, etc. Often development team starts development without taking care of these points. Valid reasons could be applied here to justify the reasons for all this ignorance. But we should understand that when we get un-success everyone cares about every minute mistake and on the contrary when we get success no one cares even about big flaws (till it works smoothly). If requirements have been captured and finalized with proper risk analysis, this problem will rarely occur. Now this problem comes under risk analysis and mitigation plan. During elaboration phase, all major risks should be identified and communicated to client\stakeholders and proper mitigation should be prepared by the concerned person. All these help to identify the scope\boundary of project and dependencies of project on external systems and environment.

It Took More Time Than Proposed Delivery Date

Many times we are compelled to start development work without collecting and finalizing requirements, without proper planning of project, without any risk & mitigation plan for the project. That leads the development to very haphazard position and finally delays in achieving the deadlines. The reason behind this kind of situation is undue pressure from the client side. Only one thing can help here and that is just to try to convince the client for minimum use of processes and win the trust and faith of client on use of processes.

Lots of Problems Coming At the Time of Actual Use

If all high risks have not been identified and QA has not been done, let’s be ready to face this situation. Sometimes due to some external factors (like hosting of other applications on the same server that causes the performance issue for our application or our application uses some shared external database and due to some changes in database it breaks our application, etc.) lots of problems occur in our application. I do agree that these situations can occur even after risk & mitigation plan and QA. But chances are very less. And at this point of time, at least we can convince the client with adequate justification. One important thing is always follow best practices and try to apply design and development methodologies only as per the nature and requirement of the application.

Any Enhancement and Modification Shakes Complete Application

As I told initially, my endeavor here is not to identify the common mistakes of design and architecture. Yes, it’s true that these are also one aspect of reason for this situation. In the absence of Project Management process or Development Management process, this situation occurs. In a big and complex project, no one can do impact analysis of any new request for change or enhancement without following these processes.

Conclusion

If we would follow the processes, we shall be able to minimize the risks or at least we would have some valid reason for the worse situations. And the most important thing is when stakeholders\client will also play his defined role in all processes, he will more easily get convinced to understand and agree upon the reasons behind such situations. So processes always keep us in a safe situation and help both stakeholders and client mutually understand and visualize about the actual problem (what), accurate factor (why) and true solution (how) during the worst situation. The biggest challenge to follow any process is to make the stakeholders\client also aware of the processes and its importance from their point of view.

History

• 20^th January, 2008: Initial post