Executive Summary
Software Development Life Cycle (SDLC) according to Stackify.com, can be defined as a process that produces software with the highest quality and lowest cost in the shortest time. (Stackify, 2017) What this means is, SDLC provides a detailed plan for how the project life cycle will be developed, modified, sustained and replaced with newer software systems as time goes on. SDLC is simple, it documents the plan a PM needs in order to formulate, implement and most importantly execute their strategy.
In most projects, there are the usual processes utilized to manage a project: phase management, planning, control, resource management, communication, procurement and integration. (MindTools, 2018) But when managing technical projects, we focus more on activities such as planning, cost, risk analysis, design, coding, testing and maintenance even after project closure. Plus, feedback from the users. Feedback from clients is imperative to a project, how else will the stakeholder know their project has met the objective? How else can project success be measured if feedback is not received and implemented?
In this paper, we will focus our research on how IT project management is influenced by SDLC using Agile, Iterative and Spiral model.
These three models were selected specifically to demonstrate how well they work IT projects during its SDLC in the field of software communication. Though each model has its advantages, there are also its disadvantages that limit the SDLC if the proper selection process is not set.
Problem Statement
Choosing a project management methodology can be tricky, each project model has its pros and con. There are six major SDLC models, namely, Waterfall Model, Agile Model, Iterative Model, V-Shaped Model, Big Bang Model, and Spiral Model. Each SLDC model has its purpose and if utilized well can help project success tremendously but if the wrong model is used on a project that isn’t fitting for it, project failure is imminent.
There are factors such as organizational goals, key business drivers, constraints, stakeholders, risk, complexity, size of the project and most importantly cost. All these factors have to be weighed in when selecting a methodology that works best for a project. According to Ben Putano, the following questions are needed to be asked:
1. What are the needs of the user?
2. How can we better meet those needs?
3. How can we improve technical performance?
He believes that without asking and finding answers to those questions in that particular order, PM’s run the risk of creating a well-functioning app that no one can use.
So how do you select the right model for a technical project? By “understanding how each project management methodology can create the greatest positive impact — and how each can derail your organization’s likelihood of project success.” (Alexander, 2018)
So that it is possible to achieve project success, one or more SDLC methodologies can be utilized for IT project management. But which one is the best? “While selecting the right SDLC methodology is challenging, the challenge is not insurmountable.” (Bhunu, 2007) With a well-defined understanding of the project objectives, an accurate framework for support, and strong communication channels, choosing the right SDLC is possible.
Agile Model
Agile software processes are an iterative and incremental based development, where requirements are changeable according to customer needs. (Sharma, Sarkar, Gupta, 2012)
Simply put, Agile focuses on planning, iterative development and customer feedback. As important as those factors are, Agile needs customer feedback and satisfaction in order to accomplish its objectives and maintain its culture.
How agile works is, it is made up of “short developmental cycles are created to provide constant software updates when developing a product or a service” (Alexander, 2018)
When using Agile, there are certain principles IT project managers must take into account:
1. Satisfying the client- constant communication with stakeholders and making sure their objectives are met.
2. Continuous software development- agile isn’t a one-time sprint cycle, there will always be a need to update the current version.
3. Changing requirements- with continuous software development comes change, requirements change, objectives, therefore, change because stakeholders want a new feature added in.
4. Communication- PMs, developers, stakeholders and vendors must be in constant communication. There has to be an effective line of communication opened where all parties involved are collaborating. Whether remotely or in office, there has to be a transfer of information.
5. Sustainable development- due to the constant updates depending on the scale of the project, the software must be able to sustain itself before needing an upgrade.
6. Lesson learned- usually, lesson learned is applied at the end of a project after closing but since Agile software doesn’t always end, reflection on the project should be done regularly in order to be more effective in the next iteration.
There are 12 know principles for Agile, the above-summarized principles mentioned are principles that I believe need to be understood and taken into consideration when utilizing Agile. It acts as a guide to PMs in letting him or her know that change is inevitable, change should be welcomed and not dreaded. It also focuses on communication with all parties involved including the users. When discussing Agile, Waterfall usually follows close by. Waterfall can be defined as a model that “creates a system with a linear and sequential approach. It develops systematically from one phase to another in a downward fashion.” (The Economics Times, 2018)
According to Moira Alexandre from CIO, opportunities exist when agile is combined with other methodology. She goes on to say “combining other methodologies such as waterfall to create a hybrid solution. Companies sometimes use waterfall to handle one or more phase — such as planning — where these do not require rapid or repetitive steps… once a project enters the development phase, rapid and repetitive changes require a different approach and this is where agile kicks in to deliver the best results in the shortest amount of time.” (Alexandra, 2018)
It is very common to combine these two methodologies together, as what Alexandra calls a hybrid. Using agile, we focus more on the flexibility and productively it provides for technical projects while waterfalls, is popular with upper management and finance organization because of its simplicity and easy to understand nature. Though two entirely different functions, they work well together.
The way to make it work is by:
1. Account management
2. Change-order
3. Explicit closure of discovery
4. Stipulating a not-to-exceed for each major functional area
According to David Taber, those 4 ways showcase how to mix two different methodologies to produce a successful project by communication, monitoring and open to change.
In my organization, we have combined both Waterfall and Agile for many of our software projects. During the planning/iteration stages, waterfall model was used. Waterfall was used because of its simple technique of sequential approach. The tasks follow itself or are a continuation of a previous task that brings about improvement in every iteration. But when it comes down to the development and monitoring phases, agile model was used. As Taber stated, the best way is to follow the above steps and a project modelled after two methodologies are headed for success majority of the time.
We were to manage the implementation of a software for an engineering company. They hired us to plan out the project while their engineers installed the software across 80 powerlines in the western region of Pennsylvania. Waterfall was first used to organize the project, estimate deadlines, provide status updates that both upper management and their engineers can understand. After the project plans were put in place and approved by the stakeholders, we proceeded to use agile for the development –installing of the software- stage. Fortunately for us, we were well versed with combing waterfall and agile, so there was a smooth transition from one model to the next. The project was a success, issues that arose were risks we had already identified earlier on with waterfall. So, when they appeared during the agile phase, we already had a solution for it.
Though there are disadvantages of combing two models, such as it is expensive. In waterfall, testing is usually done towards the end of SDLC, to then go back in so late in the development stage is very costly and stakeholders would more than likely not be pleased with the sudden changes. Waterfall is purely based on assumption and project requirements that can always change. Agile as well also has its faults with testing. Using agile means there should be resources whose main priority is testing. There are lots of testing that takes place during the whole lifecycle and not just at the end like waterfall. Alternatively, regardless of whether it’s at the end or during the project, there is still a lot of testing required which is costly and can slow the project schedule. But together they reduce their disadvantages and implement their advantages.
Iterative Model
In a technical project, iterative model is needed during the development stage of the project. This is where the bulk of the work is done. From development to testing to integration.
The iterative model can be defined as “a particular implementation of a software development life cycle (SDLC) that focuses on an initial, simplified implementation, which then progressively gains more complexity and a broader feature set until the final system is complete.” (Powell-Morse, 2016)
Iterative model is dependent on the previous phase before it can begin or add any substantial value to the project. Its functionality can be developed early in the life cycle which then produces results early and periodically.
Occasionally, in my organization, we undergo internal projects in order to regenerate funds and not just rely solely on outside funding or client work. My boss and a few members of upper management decided to build a software called Likita. Likita’s function is to provide booking services for hospitals. Many hospitals in Lagos, Nigeria still rely heavily on manual input of appointments. Likitas function is to cut that process down and rely solely on automated software and text messages to clients about their bookings. Basically, simplifying the process for hospital staff.
For this project, we started off with agile methodology but veered towards iterative as we realized that each time we onboard a new hospital there was always something new to add or tweak. Therefore, we had to adopt the use of Iterative model. As stated above Iterative model can be useful when a system has to be updated for a newer software eg. iOS but a disadvantage is iterative model can also run up the cost. That is exactly what happened with Likita.
Likita ended up costing 3x what they initially put in and the number is still rising. This project started in 2015, almost 4 years later, the project is not done yet. Each time a hospital comes on board, the system crashes. Endless testing and reconfiguration are too constant with Likita. Each component of the project is built separately. Some iterations can start when another iteration starts while others can only be started when one iteration finishes. Technical projects like these are very time consuming and cannot overlap due to its rigidness.
Throughout that project, there has been what Amir Ghahrai calls incremental development.
He defines it as “a method of software development where the model is designed, implemented and tested incrementally (a little more is added each time) until the product is finished.” (Ghahrai, 2018) Very similar to Iterative, it differs slightly. Incremental model is broken down to into multiple parts and worked on separately then brought back together. Those small parts pass through a series of process called “RDCT- requirements, design, coding and testing phase”. (Prameela, Dhumpati, 2015)
In the requirement phase, the specification of the software is collected; design phase the functions of the software is designed; code- all coding for software or bug fixes are done in this increment and lastly test- once deployed it must be tested.
Advantages of using incremental model are similar to iterative, they both are fast-paced, flexible, no major change required in the scope, errors can easily be spotted. But the disadvantages are as its flexible it is also rigid, they cannot overlap one must be complete before moving to the next stage, time-consuming and requires good planning/design.
To lessen the disadvantage, ensure to plan early and accurately.
In our case, my organization did plan but they did not plan for the on-boarding issue of when a new hospital is added, a new software must be created in order to encompass it. Because iterative doesn’t allow the developers to work backwards, the developers cannot go back and re-tweak the issues, everything on the projects is always forward and added in as a new iteration. As you can see its actually a never-ending cycle for us.
When using iterative model, it requires a series of testing, as tedious as that is, with iterative model it is imperative this step is not skipped. According to Shivageeta Choodi, the “key to successful use of an iterative software development lifecycle is rigorous validation of requirements and testing of each version of the software against those requirements within each cycle of the model”. He went on to discuss the 5 ways in which iterative testing should be tested.
The software developed at each of the iterations will go through the following test phases:
• Unit testing (UT)
• Component testing (CT)
• Integration testing (IT)
Once the entire product requirements are met, that is, during the final iterations, the product goes through the following test phases:
• System integration testing (SIT)
• Acceptance testing (Choodi, 2006)
The above forms of testing emphasize the need for many different ways of testing. Without testing, there is no way of knowing if the product meets the requirements and user satisfaction. Likita developers ran a series of tests, the majority of the resource hours were clocked as testing, sometimes a week of testing. Though this impacted their ability to run demos on the new features and begin trails. Had they not run tests then I can honestly say there would not have been customers to onboard which ultimately will run up the cost and yield no return.
Spiral Model
Similar to the Iterative model, Spiral model follows a similar approach in iterative repetition style. Spiral model has 4 known phases, planning, risk analysis, engineering and evaluation. (Half, 2018) Each phase is repeated over and over again throughout the duration of the projects life. Hence the term spiral.
In 1988, Boehm introduced a new form of model, Spiral model. He famously phrased it as “start small, think big”. (Boehm, 1988) What that means is, before you can fully understand the project, you must “determine its objectives, evaluate alternatives, and identify and resolve risks, develop and test and plan the next iteration.” (Ruparella, 2010)
To expand more on the 4 main phases:
• Determine its objective- team members and PM must gather the product objectives, its requirements and design specifications.
• Evaluate alternatives/ identify 7 resolve risks- development team is meant to enumerate all possible threat to the project and prioritize them organize them from greatest to least critical.
• Develop and test- the product is developed then tests are run. This is very important as it provides feedback from stakeholders, users, it also shows how the product holds up and if changes are needed.
• Plan the next iteration- once the above phases are complete and resolved, the next iteration is drawn up and these steps are reused until project closure.
Selecting a model is critical to the project, the above phases should be generated at the beginning of project planning if the IT PM decides to use the spiral model they have to be prepared for series of testing in order for the SDLC of a project to run smoothly. When a cycle within the spiral model progresses, a prototype occurs, it is then compared to see if it follows the project requirements and goes through testing. A key benefit of spiral model is it attempts to contain the project risks and costs at the outset. Another benefit is products that have design flexibility and allows changes at several stages of the project. Unlike our project, changes weren’t welcome because it had to work a certain way and they only change that was acceptable was the design layout but not the app productivity.
But with all benefits comes the disadvantages.
According to Nayan Ruparella, Spiral model’s main difficulty is it requires very adaptive project management, flexible contract mechanisms between the stakeholders and between each cycle of the spiral, and it relies heavily on the systems designers’ ability to identify risks correctly for the forthcoming cycle. (Ruparella, 2010) What this means is the project plan should not be rigid. It must be able to change at any given time and if such a change does occur, the stakeholder should be receptive to the change to better the product or stay on schedule. With risk management, the risks are identified in order to determine the amount of time and effort to be expended for each activity.
Another disadvantage is a large number of transitional stages. “As a result, a vast amount of documentation. Time management may be difficult. Usually, the end date of a project is not known at the first stages.” (Gurendo, 2015)
From my experience working as a technical PM, I have been opportune to work on various technical projects and realize that each project requires a different model plan. No two projects are the same, though they may have similar objectives, they should still be handled as different projects.
I managed a project that had the same characteristics as Spiral. It involved continuous cycles that seemed to never end. Our clients wanted a mobile app for their laundry company. They wanted to revamp the way clients did their laundry. The app is meant to allow users to select clothes for pickup eg. shirts, undergarments, trousers, jeans, skirts etc. The number of items, the type of wash, dry cleaning, regular wash, ironing etc. and the available time and date for pickup and payment option. Once their selection has been made it then gets sent to the client’s admin user where a staff will have a software (built by us) that links the orders to their system.
Once received, the driver will also have a software (built by us) similar to FedEx, UPS, and other delivery trucks that track their movement so users can have real-time updates and see where their truck is (similar to Uber). This project was to take 3 months and cost $8,000. Identical to the process of Spiral, we laid out the SDLC for it.
We identified the objectives of the stakeholders (mentioned above). We identified the constraints and applied a risk assessment on the project. The risks and constraints we identified were UI constraints for mobile devices, client processor speed, different platforms (iOS, Android, Windows), and broken configuration. These were our main constraints. Or so we thought. As the project commenced, one of our developers quit. There was no way to plan for that.
We were one resource short and already stretched thin. We had to rush to find a remote contract developer that could temporarily fill his position in. After that initial road bump, development moved smoothly. We had completed phase one which was design and testing for the user interface app. Next phase was testing. Testing and review went well with barely a hitch. Part one of the project was completed, the user app was ready and working. The next iteration begins. Like phase one we identified the objectives, the risks and alternatives for the admin personnel app.
When it was time for testing, the system failed. Our technical structure did not fit into the processor they had. We had to go to the drawing board and start over as we could not go back to the iteration. We ran into this problem continuously each iteration phase had an issue syncing.
There were many changes but no real development because each issue was different and not relative. A 3-month project turned in to 11 months, to date, it is an ongoing project. Initial cost has doubled and time management and available resources have been challenging.
Conclusion
From my point of view, having understood what it entails to manage a technical project through SDLC, I would merge models together. From the research conducted, models can work together as a hybrid model, and usually work very well together. Each model has its benefits and disadvantage, and more likely than not they cancel the bad once merged. Or they can amplify the bad if two models that are complete opposites merge together.
In the problem statement above, there were 3 questions that needed to be answered:
1. What are the needs of the user?
2. How can we better meet those needs?
3. How can we improve technical performance?
So far, we have found 2 out of 3.
1. What are the needs of the user?
The needs of the users are found during requirement gathering. SDLC models provide a way for IT project managers to find these requirements because before a project can be managed documentation and full understanding of the product and the reason for it must be established. SDLC models require that to be the first thing discovered before project planning.
2. How can we better meet those needs?
Testing. Using customers and focus groups to test products are the definite way to find out if you have met their needs.
“Quality and efficiency are best served by testing software as early as possible in the life cycle.” (Choodi, 2006) For efficiency to be measured accurately, it is up to the PM to tailor the testing process so it is best suited for the SDLC. Accurate results should be produced at this level.
3. How can we improve technical performance?
This is the third question I believe is yet to be answered because can it ever be improved fully? Like all software, there will always be an upgrade after it. There will be a newer more improved way the software can run and in this case, there will be a newer more improved way of managing a project during its SDLC. But there will also be people that argue that this new way is not adequate or is the update required. Why fix what’s not broken. You cannot please everyone.
Implementation
The agile, Iterative and Spiral methodology can be very complicated. If complete documentation and requirements are identified early on in a project, them selecting the right model for your SDLC can be achieved.
The following plan of action should be implemented:
• Establish a strategic approach: find out what the needs are for the project. Understand your stakeholder’s requirements and objectives, how will that tie into what it is their perspective users need. Which SDLC model works well with communication and status updates. Will the stakeholders be able to interpret your report without you being in the room explaining it line by line?
• Design/development: what type of product is required. The design of a product is one of the key ways to implement which type of model to use. If it is a software that requires continuous updates like apps for iOS and Android, models such as iteration and spiral can be used.
• Testing: the software requires testing, trails and feedback from test users. In this stage, we need a model that is receptive to frequent testing. Waterfall, for instance, is not the model to choose due to its disadvantage of late testing. Testing for software can happen at any time during the project life cycle. This is usually where a project cost can run over due to series of regression testing. A suitable model needs to predict the risks ahead and not just which model works well with the design.
• Deploying and maintenance: good IT PMs do not just plan for the SDLC they also have contingency plans for after the project is complete and approved by stakeholders. When a product is launched the next step is updating it based on user request. A technical project is never truly complete because updates and maintenance will also be needed.
The key to implementing the best model for your SDLC is to ensure it can get you from point A to point B with the least amount of issues and delays. If after the four processes and the project is still in disarray, then that model is not the right approach or one of the steps needs to be re-evaluated.