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 was 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 stuffs and how much these are relevance 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 Client. All of us know there is no limit of expectations. If the delivery doesn’t contain any problem and Client is satisfied with it, we are lucky. But if it is opposite then we are in great trouble. Because once Software has been delivered, every valid reason for this situation is not more than lame excuses. And often we face this kind of situations.

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 on the common reasons that make any Client unhappy.

Delivered Software doesn’t behave as per the actual requirements

Its very sad part and even hard to realize for 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 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 these ignorance. But we should understand that when we get un-success everyone cares on 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 requirement, 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 situations is undue pressure from 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 problem 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 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 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 be got convinced to understand and agree upon the reasons behind such situations. So processes always keep us in safe situation and help both stakeholders and Client mutually understand and visualize about 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 his point of view.