- The three process models chosen must be discussed using a critical, comparative and differentiative approach and supported by the literature.
- Ensure that the essay is well structured. A reminder that a basic essay comprises introduction, body, and conclusion. Use headings and subheadings for ‘signposting’ as appropriate.
- Write full sentences using your own words.
- Follow the correct submission requirements i.e., format and word count limit. Do not include graphics photos, diagrams, appendices, and lecture material. 3,000 words excluding
- reference list acceptable.
- Provide clearly referenced evidence to support your claims from your reading of books, journals, periodicals, and articles from the press that support your research for the essay (as citations in your text and included in your reference list).
- Use the Harvard Referencing system. You will find a useful guide at http://libweb.anglia.ac.uk/referencing/harvard.htm (up to 10 marks).
Software development Lifecycle
Software Development Lifecycle  is a process of developing or maintaining software. A software process is an abstract representation of a software process where all software projects undergo various phases, including requirements gathering, requirements analysis, system design, implementation, testing, deployment, and maintenance.
Various software process models describe multiple activities or tasks that take place during the process. Let us see what this process model means and other information associated with it.
What do software process models mean?
A process model in general is a development plan that specifies the standard process of developing a product.
However, being more precise, its definition states which activities to be performed by whom and in which order the activities will be performed with development and evaluation essentialities.
Software process models are coherent activity sets for identifying, specifying, designing, implementing, and testing software systems. The software process model basically refers to a process abstract representation, representing a procedure description from a specific perspective.
However, all the software processes involve the following:
- Specification – Specification defines what exactly the system should undertake what task.
- Designing and Implementation – Design defines the software systems organization, while implementation is about its subsequent execution.
- Validation – Validation checks and what the end customer requires from a specific system.
- Evolution – Evolution includes accommodating the changing software system requirements matching the user’s needs.
The process model selection is based on several factors. Here are a few things that need to be considered:
- Project type
- Project Complexity
- Project Requirements
- Project Scope and Scale
- Skills and experience required
- Project Goals
- Customer Involvement
- Delay Costs
- Resources and time available
- Programming and other tools required.
- Any other essentials
Considering Issues to be addressed while selecting a model
- What is the end goal of the project?
- What are the overall management requirements for the project?
- What specifications are required and how to represent them?
- What is the evaluation role in the project?
- How to design the ideas for project implementation and how to communicate them?
- What documentation are required for successful processing?
- What parallel activities can assist the development process?
- How the project should be signed off?
- What are the key requirements?
- What business size could be the best fit for a specific project implementation?
- Does it require consistent maintenance?
Software Development Activities
In software development , problem-solving comprises of subsequent activities:
- Recognition and Understanding of the Problem
Every process model begins with a basic understanding of the problem, including the end goal, how it could be achieved, what process could be followed, and many others.
- Feasibility Study
The feasibility study includes the project’s scope and the feasible possibilities that might be undertaken to achieve the end goal. This stage leads to the development of a feasibility report.
- Requirements analysis
Requirement analysis is all about examining the existing system, including how it works and its shortcomings, and proposing a new system that enumerates exactly what the new system will perform.
The common documents from the requirements analysis phase include the following:
- Feasibility report
- Software Requirements Specification Document
- System Designing
System designing indicates deriving a feasible solution that satisfies the software requirements. The common categorization of system designing-related activities is the creation of high-design, low-level design, and architectural design.
- The architectural design includes decision collections that are required to be common to all the components.
- The high-level design includes dividing the system into varied segments.
- The low-level design includes selecting the algorithms and data structures for a single component.
After confirming the architectural designing requirements and the creation of the system design, comes the necessity to implement the designed process.
The testing phase includes performing unit testing to ensure the quality and desired functionality of the designed system.
Once the implementation and testing phase is complete, the deployment of the process takes place. This includes the installation and analyzing the user experience to ensure that the software is built to match the user’s requirements.
Maintenance is another essential practice to ensure the longevity of software. The maintenance phase is performed in various forms. This includes
- Corrective maintenance is carried out to fix issues.
- Adaptive maintenance to make the software get going affected due to changes in the environment.
- Perfective maintenance is carried out to add features and enhance the performance of the existing one.
- Preventive maintenance is supported by refactoring in order to enhance maintainability.
Types of Software Process Models
The software frameworks, methodologies, and processes are abstractions that organizations can unswervingly use to execute their daily activities. And these processes can also be extended or modified by the flexible outlines to create custom step sets to specific software requirements.
Several software development life cycle models are explicitly created to attain diversified objectives. A few most popular models include:
The waterfall model was proposed by Winston Royce in 1970, where the software process components are arranged as a linear sequence with a flow of beginning-to-end approach and functions like a waterfall. Just like the waterfall flows from top to down, the waterfall model also undertakes activities with a top-down approach.
The waterfall model presents a software development process as various stages to be followed one after another. Since the process activities cascade from one phase to another, this model represents a waterfall-like process which is why it is known as the waterfall model.
The waterfall model  is a plan-driven process, which means planning and scheduling all the activities before beginning the software development.
The varied phases of a waterfall model include:
- Requirement Analysis
The system’s constraints and goals are built by having an in-depth consultation with the system users. These goals or constraints are then defined well in detail and serve as a system specification in the form of a Software Requirements Specification Document.
- Software and System Design
The System design process allocates all essential requirements to either software or hardware systems. The designing phase develops an overall system architecture, and the design includes the identification and description of the fundamental system abstractions and their association.
- Software Implementation and Unit Testing
The software design is further comprehended at this phase and transforms into a set of program units or programs. The implementation with unit testing includes the verification of each program unit to meet its specifications.
- Integration and System Testing
The individual program units verified from the previous phase are further integrated and tested during this phase. These program units are tested as a complete system to ensure that the desired software requirements are met. However, post-testing step, the software is delivered to the customer.
- Operations and Maintenance
This is the last phase of the waterfall model, where the software is installed and further put into practical use. Post-deployment and appropriate execution come to the maintenance phase, which involves amending the errors not identified earlier and enhancing the system unit’s implementation.
The drawback of the Waterfall Model
The major drawback of implementing the waterfall model is the complexity of accommodating the modifications after the entire process is underway. In this waterfall model, one phase has to be mandatorily completed before heading to the subsequent phase.
This model is appropriate when the needs are well understood and modifications are restricted or limited during the design process. Therefore, the waterfall model is considered suitable whenever a business system has some stable requirements.
But only a few businesses have stable requirements. Therefore, it is used for larger projects where the specific system is developed at various sites.
- Process rigidity
- Stronger steps order
- No parallel work
- No way back
- No incremental work
The waterfall model is suitable for below types of systems:
- Critical systems where there is an excellent requirement for an extensive security and safety analysis of the software design, specification, and implementation.
- Embedded systems where the software includes an interface with the hardware systems.
- Larger software systems where various companies are involved and may require complete specifications to enable the independent development of diversified subsystems.
Advantages of the Waterfall Model 
- It utilizes a pre-defined and clear structure
- It determines the end goal early
- It transforms the information appropriately
- It has an excellent documentation
- It is followed by meeting the user needs
- It requires a lesser need for any supporting systems
- It works well for projects where requirements are pre-defined and well-understood.
- It is easy to understand and use.
Disadvantages of the Waterfall Model
- The changes are difficult to be made in the waterfall model
- It excludes the focus on the end users
- It delays the testing phase as it could be done after completion only
- It’s more expensive to maintain
- It requires more training
- Higher amounts of vagueness and jeopardies.
- It is not suitable for projects where the needs are at a medium to a higher risk of modification.
Spiral Model was first introduced by Barry Boehm and was applied to the TRW Software Productivity System. The spiral model takes the stages of the waterfall model into repetitive loops with software design prototypes that are enhanced and refined into each look, just like a process going in a spiral.
The risk analysis added into the loops is a unique feature of the spiral model. In this model, the risk signifies situations that might be complicated for the team to attain its goals. Therefore, in each iteration, the prototype is evaluated for risk assessment. That is why this model is further categorized as a risk-driven model.
A Spiral Model Cycle!
A Spiral Model Cycle  undergoes the below-mentioned phases:
- Customer Communication
Customer communication is the first phase of the spiral model, where the stage focuses on establishing effective communication between the customer and developer.
The planning phase leads to the appropriate Planning for the whole process. This includes defining the resources required, timelines, and other essential information related to the project.
- Risk Analysis
The risk analysis phase is carried out to evaluate both management and technical risks identified till this stage.
This stage is responsible for building or developing one or more application representations.
- Development and Deployment
This stage involves the tasks for the appropriate development based on the user requirements and deploying it to users with proper installation and user support.
Advantages of Spiral Model
- It is suitable for mission-critical and larger projects,
- It was designed to include the best features from prototyping and waterfall models.
- It involves a unique feature of risk assessment.
- It is considered similar to the prototyping model, where the system’s initial version is developed and modified on the basis of inputs received from the customers.
Disadvantages of Spiral Model
- The addition of the risk assessment phase requires specific expertise.
- It can be an expensive model to use.
- It doesn’t work well for smaller-scale projects.
- The success of the project is highly based on the risk analysis phase.
The Agile Model Development  is considered one of the most creative and responsive efforts to address user requirements, focusing on delivering working business applications quickly.
Agile approaches follow an incremental or iterative, or evolutionary fashion. These are more concerned with managing and maintaining the user’s involvement with the help of special workshops and the application of design teams.
The delivered incremental stages tend to be smaller and restricted to shorter delivery periods only in order to ensure the rapid completion of the process.
The management strategies utilized in the agile approaches rely on enforcing the timeboxing, which is a strict target delivery dictating the scope and functionality to be delivered and adjustments made to meet the deadlines.
This approach is useful in changing environments and imposing partial solutions demands; therefore, it can be said that the agile approach supports the concurrent development notion and delivery phase with an overall pre-planned context.
The agile development approach follows below-mentioned characteristics
- All the requirements are assumed to be changed.
- Customers also participate during each iteration.
- Documentation is generated only when it is required.
- Systems evolve during a series of shorter iterations.
Extreme Programming of Agile Approach!
This extreme programming approach  to development is based on the continuous development and delivery of smaller functionality iterations. This approach consistently relies on constant code enhancement and user involvement.
Therefore, with this continuous user involvement requirement, it can be complicated for the teams to keep the customer’s interest active. This may make the team members unsuited to intense involvement. Also, prioritizing modification can be complicated as there are multiple stakeholders.
Here are the agile extreme programming development approach steps:
Practices of Extreme Programming
- Incremental Planning: In the incremental planning phase, the requirements are recorded in the story card form, and developers break down these stories into development procedures known as tasks.
- Small releases: Small releases include the minimal useful functionality set that first provides business value to the project. However, any further releases are considered an improvement to the first one.
- Simple designing: Simple designing follow-up is carried out to match the current requirements.
- Testing of first development: The extreme programming approach utilizes an automated unit test framework to write tests for a newer functionality piece before the functionality itself is implemented.
- Refactoring: The code is refactored continuously once possible code enhancements are discovered. This facilitates keeping the code more simple and maintainable.
- Pair Programming: In extreme programming, the developers work in pairs, checking each other’s work and providing desired support to perform a good job.
- Collective Ownership: The developers collaboratively work on all the system areas, and therefore no expertise islands are developed on the code leading to any developer changing anything scenario.
- Continuous Integration: As soon as a specific task is finished, it is integrated into the entire system, and after each integration, all the unit testing is required to be passed by the system.
- Sustainable Pace: Larger overtime amounts are not acceptable as they can lead to affecting the net effect, which further reduces the productivity and code quality.
- On-Site Customer: An end-user representative must be available all the time for the use of XP as the customer is considered a development team member who is responsible for bringing the system requirements for implementation.
Principles of Agile and XP approach
- The incremental development is supported using frequent and smaller system releases.
- Change is supported with the help of regular system releases.
- Customer involvement indicates a full-time team engagement with the team.
- Maintaining simplicity in the codes through constant refactoring.
- The process through pair programming scenarios with collective ownership leads to avoiding longer working hours.
Advantages of Agile XP
- It’s a lightweight model that best fits smaller or medium-sized projects.
- It emphasizes the final product.
- It follows an iterative approach.
- It produces a good team cohesion
- Its test-based approach ensures quality and requirements assurance.
Disadvantages of Agile XP
- It requires skills and experience.
- It is challenging to scale up to larger products where documentation is essential.
- The paired programming approach can be costly. Test case construction is complicated and requires specialized skills.
Critical Analysis of Software Process Models!
The critical analysis of the above-mentioned process models  can be done on various parameters. The critical analysis based on a few parameters is compiled below:
|At the beginning of the project
|Reset at each Spiral
|At the Beginning
|Primary Objective Setting
|At the beginning of the project
|Before each Spiral
|At the beginning of the module
|Appropriate Product Size
|At the beginning of the project
|Not much Costly
|In the end of the project
|In the end of module
|Only in the beginning
|At each spiral
|After all Spirals
|At each Module
|In each spiral
|At last of the module
Business and product requirements are consistently changing due to developments in varied sectors and that is what calls for tight market deadlines. The application of these ever-changing requirements makes the project completion pretty complicated.
Therefore, the limited versions stand restricted to deliver the desired business value. This is why the introduction of successive models took place. And based on the requirements and business size.
The above-mentioned critical analysis is done based on varied parameters however, it could be complicated to say that which one is the best. All of the above models are considered the best fit on the basis of implementation and business requirements.
 S. Kumar, N.K. Mishra, S.S. Mehta, pp. 12-14, “Critical Analysis of Software Process Models,” International Journal of Computer Applications 90975-8887) National Conference on Advances in Computing Applications.
 S. J. Zeil, Sept 2017, “Software Development Process Models” Old Dominion Univ.
 Ian Sommerville, Pearson, Tenth Edition, 2016, “Software Engineering,” ISBN 978-0-13-394303-0, published by Pearson Education.
 R. Sherman, Science Direct, 2015, “Waterfall Model”, Business Intelligence Guidebook.
 B. W. Boehm, 1998, pp. 61-72, “A Spiral Model of Software Development and Enhancement,” TRW Defense Systems Group, IEEE.
 A. Mujumdar, G. Masiwal, P. M. Chawan, June 2012, pp. 2015-2021 “Analysis of various Software Process Models,” International Journal of Engineering Research and Applications, Vol. 2, Issue 3, ISSN: 2248-9622.
 S. A. Ghanghro, M. A. Sawand, W. A. Channa, U. A. Kahif, M. H. Tunio, K. Kumar, Nooruddin, June 2021, pp. 2593- 2599, “Comparative Analysis of Software Process Models in Software Development,” International Journal of Advanced Trends in Computer Science and Engineering, Vol. 10, No. 3, ISSN: 2278- 3091.
 R. A. Haraty, G. Hu., 2018, pp. 325-331 “Software Process Models: A review and analysis,” International Journal of Engineering and Technology, DOI: 10.14419/ijet.v7i2.29.13206.