Pandemic has exposed the vulnerabilities of _* ?
Episode — 01 of “ The Genesis of a Process Model”
The Novel Corona virus, the Pandemic of the Century has brought hysteria all over the world. The panic wave is on the roll with the humongous 5.9 million confirmed cases and over 320,000 deaths. The loss of lives is huge enough to be compared to a third world war set up by the invisible forces of infectious virus. This is causing disruption to markets and supply chains. Businesses are on the verge of end, and millions of people have lost their jobs and livelihoods. Stock markets witnessed their worst day since the 2008 crisis and oil prices saw their biggest fall in 29 years.
The corona virus COVID-19 affects all aspects of society and all dimensions of sustainable development. This paradigm shift exposes the necessity of digitization across sectors. Vitality of digitization of business and services has vested more software related projects that have survived the industry. On the other hand, the economic crisis following the epidemic outrage, has been leading to the loss of capital for software projects that might leave many projects dormant. But it is healthy that the bulk of new software projects have outnumbered the project getting halted.
The project success depends on the process and the project management. We are all familiar with the experience of cascading failures. Once the process model has failed to support efficient process management, the ability of project managers and stakeholders to coordinate across a complex array of teams falls apart. Unfortunately, in a time of crisis like this, when operating efficiency is most critical, the models that we rely on perform the worst. The problem is that we have not created models that withstand such vulnerable situations and were comfortable with processes that work well when everything is consistent and predictable but spiral into delay and failure when the unexpected occurs.
The epidemic has not devastated the existing software development process models but has exposed the vulnerabilities of such.
Hence the circumstances has necessitated the advent of new software process life cycle model that suits the pandemic or calamity conditions, exploit the bare minimum and available resources, employ risk analysis and engineer mitigation plan and help projects shape up well for the successful delivery of software and systems. Industry is forced to redesign itself to cater to the limitations and to the context of the current situation. “Panduring” process model is proposed in this report which is constructed based on the above arguments.
The series is structured to brief about the process model, describe about the proposed prescriptive and the descriptive model, process life cycle and the engineering life cycle.
A Software Process
A process is a structured set of activities, regardless of whether it is a mechanical process, a chemical process, or a software process. A process takes in a set of inputs and produces relevant outputs. Software processes are a structured set of activities required to produce a structured system. Any software process consists of four activities:
● Requirement Specification
● Design and Implementation
In the specification phase, systems requirements, software requirements, function and nonfunctional requirements are defined. Then the design phase decides the system architecture followed by implementation. After that, in the validation phase, the system is ensured whether it performs what it is expected to do on all occasions and adheres to user requirements. Finally, the evolution phase system evolves based on the changing customer requirements.
A software process also includes a process description. The process description consists of, but not limited to products, roles, pre and post conditions (entry and exit criteria)
Software Process Model
A software process model, like any other model, is the abstract representation of a software process. It describes the software process from a particular perspective and at different levels of abstraction. Models are helpful in expressing, explaining and analyzing the process. Process models contain information about different phases, activities, milestones, deliverable and additional related information such as descriptions of product flow, control flow, relationships to techniques, methods, tools, and relationship to roles. They can be represented in different forms or using different notations like graphical or natural language.
The necessity of software process models:
● To enhance understanding and communication
● To improve software development activities by providing means of measurement
● To support process and project management
● To guide the developers
There are two types of process models: prescriptive process models and descriptive process models. Prescriptive process models explain how something should be done. Descriptive process models describe how they are actually done in reality. Prescriptive models are the ideal cases. When we deploy them into practice they become descriptive. The descriptive models get evaluated, debated and improved to evolve a prescriptive model. But the evolution from descriptive to a prescriptive model consumes a considerable amount of time and effort.
Prescriptive process models can be further classified into two:
● Life-cycle process models
● Engineering process models
Life-cycle process models consider the entire life-cycle of a process model while engineering process models focus on only a fraction of the life cycle. Life-cycle process models are comparatively abstract and explain ‘what’ should be done but not ‘how’ something should be done. In contrast, engineering process models not only explain ‘what’ should be done but also ‘how’ they should be done.
Existing Prescriptive Process Models
Development process looks like the flow of water in a waterfall, moving step by step through the phases: analysis, implementation, testing and support. Every stage is gradually executed in this model. This model includes strict documentation and predefined features which are expected at every phase of SDLC. But since there are high risks and uncertainty, the waterfall model is not the best choice for projects which are subjected to frequent changes and also for long-term projects. Apart from that progress measurement is hard and identifying the problems in advance is quite not possible as the integration is done at the end.
Iterative Enhancement Model
In contrast to the waterfall model, a full list of requirements is not needed in this model. That is the development of the system can be started with only a part of requirements and can be expanded later. This process is a repetitive process where new versions can be released at every cycle. A separate component of the system is developed at each iteration and this developed component is added to the functional which was developed earlier. This model is a realization of the sequential approximation method. This model requires constant management and more resources compared to the waterfall model. Since all the requirements are not foreseen during the planning stage, explicit issues with design or architecture may occur. It is inappropriate for small projects. The process is difficult to manage. Highly qualified specialists are required for risk analysis and in some cases the risks are not completely determined even at the final stage of the project. Risks analysis requires involvement of the.
This model is a combination of the Waterfall and Iterative models with a significant emphasis on risk analysis. The main issue with the spiral model is when to proceed to the next stage. Even when the work of the previous stage is not completed, according to the plan, the shift happens to the next stage. The model can be expensive and requires excessive documentation when the intermediate stages are higher in number. Here also highly qualified professionals are required for risk control and not effective for small scale projects.
Rational Unified Process
This model is not a concrete development model. That is depending on the needs of the project, team and organizations; it can be tailored and adapted. In this model, phases define who, what, when, and how development will take place. This model requires the team members to be expertise in their field. The development process is too complex and disorganized. Reuse of components cannot be done here.
One of the advantages of this methodology is the customer is able to see the results by himself after each development iteration and is able to understand whether he is satisfied or not. On the other hand, one of its disadvantages is difficulty in resource and cost estimation when requirements are not present. Extreme programming is one of the practical uses of the agile model. It consists of short weekly meetings (Sprints). It requires a highly professional and client-oriented team because of the difficulties in measuring the final cost due to permanent changes. There can be conflicts between new requirements and existing architecture and the project may exceed the expected time due to all the changes and corrections.
So far we have seen what a process model is and seen about the existing process models. The study of existing models have exposed the vulnerability of such models and the next blog on ‘Genesis of a process model’ series will discuss the necessity of developing a new model and the approach that would be employed in building a new model from scratch.
The series: "Genesis of Process Model"
Episode 01 : Pandemic has exposed the vulnerabilities of _* ?
Episode 02 : The Panduring Process Model