Software Lifecycle will prepare us to understand the basic concepts behind the many software development process models. A lifecycle is a process that goes around and around, in other words, a process that goes through all of its phases and then repeats itself. In the context of software, a lifecycle is a series of distinct phases occurring one after the other. It has a beginning and an end. In any good software develop, we have to gather together all the things that the software application will be required to do and then analyze those requirements making sure that we have them all, we understand them all, and that there are no contradictions among them. In a nutshell, the requirements phase answers the question what does our software application need to do. To do any good software product, it needs to be designed, built, and tested carefully. And as if that weren't enough we must be able to maintain the software after it is in use, fix any defects that surface, and enhance it as user's needs change. In this essay, we are going to introduce you to a couple of the oldest and most fundamental software development process models, the Waterfall, Spiral, and Agile. They've been in use for years, and studying them can help us better understand not only the basic steps necessary to build a good piece of software. So, we're going to start out with an introduction to the software process Models. We will describe how it's used along with the advantages of the model, as well as the disadvantages.
Waterfall Model
This model begins with the Requirements phase. In this phase, we gather all of the requirements for the software product we're getting ready to build. The main goal of this phase is to reach a clear understanding of what our new software product needs to do. The next phase is the Design phase. During this stage, we typically design things like files and user interfaces. We also design the architecture of the product by defining classes of objects specifying the relationships and so on. The main goal of this phase is to create a complete design for the software product so that all the requirements are met and the design can be used to completely and correctly construct the software product. The next phase is the Implementation phase. After we have gathered the requirements and laid out the design it's time to start actually building the software product. Typically this is when the programmers begin creating all the database objects, programs, and other software objects necessary to fulfill the design. Next comes the Testing phase. In this phase, we test the product we built in the Implementation phase and verify that it meets the requirements we collected in the Requirements phase and that it conforms to the design we created in the Design phase. The final phase is Maintenance. In this phase we typically repair any defects that were found in the Testing Now, we have probably noticed that. Just like water in a waterfall, process execution flows downhill so to speak from one phase to the next. Once a phase has been completed, execution moves down to the next phase in line, and in just the same way that water does not flow back uphill execution does not turn around and go back to the previous phase. At least that's how it works if you follow the strictest interpretation of the model. In real life, however, there is usually an iterative relationship between any two adjacent phases. The advantages and disadvantages of the model. First, the advantages. The Waterfall Model is simple to understand and implement. Each phase is distinctly separate from the others, and they're executed sequentially one at a time with no repetitions, so following the process is like going down a checklist. It's a sequential step-by-step process, and that type of process is very easy for most people to understand. Since each phase has its own entry and exit criteria, it's easy to understand when each phase should end and the next phase should begin. The Waterfall Model is proven and well-known. Since the process clearly follows the fundamental steps of software development, it just stands to reason that it's been around for a long time, and has been used successfully. And because of that, there are a lot of software developers who are familiar with the model. It has been in widespread use for so long that there can't help but be lots of developers who have used it. The Waterfall Model is simple to manage. That's mainly due to the fact that the model is so rigid. All things considered, the Waterfall Model has been proven to be great for small projects. Recall that in the Waterfall Model the requirements need to be complete and well understood at the beginning of the project. Typically the smaller the project the smaller it’s set of requirements and the greater the likelihood that the development team can clearly and completely understand the requirements at the beginning of the process. So, as you can see, there are plenty of good things to be said about using the Waterfall process, especially if your project is relatively small. Unfortunately, there are some real drawbacks to using the Waterfall Model for anything more than a short, simple software development project. One of the most important of these is the stipulation that all the requirements must be clearly understood at the beginning of the process. For most software development projects this is a very difficult stipulation to meet. In fact, for even moderately complex projects it's almost impossible. Most software development projects get underway without a complete understanding of all the requirements. The team members may think they have a complete understanding, but in most cases they are mistaken. In fact, in a typical software development project none of the stakeholders will have a complete understanding of all the requirements. In other process models what normally happens is that as the process progresses through its phases new requirements are discovered, and the existing ones are corrected or refined. This is often because the stakeholders have opportunities to provide feedback throughout the project, so that leads us to another drawback to the Waterfall Model. Stakeholders don't have the opportunity to provide feedback throughout the project. The first point in the process where they provide feedback is during the Testing phase. The Testing phase is near the end of the process. During any software development project, it is critical to get stakeholder feedback as quickly as possible. This allows us to verify our requirements and our designs early in the process and hopefully make corrections to them before we get too far along in our project. In the Waterfall Model, however, stakeholders don't get the chance to provide feedback until after the Testing phase, which is the next to the last phase. This is extremely late in the software development process to be getting feedback from the stakeholders. This often leads to anxiety and impatience among the stakeholders as the project progresses. Recall that in the Waterfall Model problems are found during the testing phase, and these problems could be of any type, missing or incorrect requirements, flawed design, or defects in coding just to name a few. The number and nature of the problems found could have a disastrous effect on the project both in terms of cost and schedule.
Spiral Model:
1
. Evaluation/Determine Objectives
2
. Risk Analysis
Spiral Model is an iterative process, not a sequential one. In this model, we cycle or iterate through a collection of four basic steps over and over until our product is ready for release. Another aspect of the Spiral Model that makes it different is that it can be considered a risk-driven model. Risk management is actually built in as part of the model. As we cycle through each iteration, risks are analyzed, and a plan is developed to address them. In fact, the planning process itself is built into the model as we'll see in a minute. Each iteration has two main goals. The first is to increase the degree of system definition and implementation. In other words, during each pass through the process cycle, we define the project in more detail, and we produce more of the software product. Secondly, since this is, after all, a risk-driven process, we want to decrease the amount of risk each time through the cycle. The first step of each iteration is to evaluate the previous iteration and determine the objectives for the current iteration. When starting a new iteration, it is crucial to review the previous iteration in order to see how well we accomplished what was planned. We also need to commit as a team to our plan for the current iteration. That means we have to set objectives, select among alternatives, and work within our constraints. After we've completed our evaluation and determined our new objectives, we turn our attention to risk. With each new set of objectives and constraints comes a new set of risks, and these must be analyzed in order to determine their likelihood, their potential impact on the project, and how they should best be addressed. In order to address risk, the model suggests using simulation, benchmarks, models, and prototyping. Each of these are tools that we can use to better understand and mitigate risks to our project. The third step is engineering. After all, the whole point of the process is to actually build a piece of software. And while the software product itself is perhaps the most natural thing that comes to mind when we think about our project artifacts, it certainly is not the only one. Our project will be concerned with producing requirements; creating designs; writing code; creating test plans and testing the product, which includes unit testing, integration testing, and acceptance testing; and then releasing the finished product. The final step is planning. If you recall, we mentioned earlier that in addition to risk management planning is also built into the model. Specifically, the model stipulates that we should create a Lifecycle Plan, a Requirements Plan, a Development Plan, and an Integration and Test Plan. Each time we cycle through the process a new plan is created and executed.
First the advantages. As we mentioned earlier, the Spiral Model is a risk-driven process, and this happens to be one of its advantages. Using this model we can manage risks throughout the process from start to finish. Risks are reduced before they become problematic, as they are considered at all stage and stakeholders can better understand and react to risks. Another advantage of the Spiral Model is the way it allows us to evolve the software product throughout the process. It is a realistic approach to the development of large-scale software and Errors and unattractive alternatives are eliminated early. Its emphasis on planning is another advantage of the Spiral Model. Unlike many software process models, the act of planning is actually built into the model. In most of the models, it is assumed that the project team will conduct planning and review meetings. In a Spiral Model, it's actually a required part of the model. Each iteration includes a planning step, and that helps us keep our project on track. So, what about the disadvantages? First, it's important to realize that the Spiral Model is a somewhat complicated model and not easy to use. If you use the Spiral Model in a software development project, then the success of your project will be highly dependent upon your team's ability to accurately perform risk analysis. One further complication is the inevitable occurrence of overlap between iterations. There's a lot of work to be done when employing the Spiral Model, and for small projects, it's really overkilled. Smaller projects just don't need the level of sophistication built into the Spiral Model. One way to help gauge the appropriateness of using this model for your project is to weigh the cost of risk analysis against the cost of the entire project. If the cost of risk analysis is a major part of the overall cost, then it probably doesn't make good sense to use this model.
Agile Process is looking more closely at two popular iterative and incremental software development frameworks that are based on Agile principles and methods, Extreme Programming and Scrum. These two frameworks are very popular among Agile enthusiasts. We'll start with Extreme Programming and see how it uses some core values and a set of rules to gather the process of software development. We'll also examine a typical Extreme Programming release plan. Then we'll dive into Scrum. We'll look at its phases, the composition of the Scrum team, the roles within the team, the daily meeting, and the way that new releases are planned including handling the backlog and organizing Sprints. We'll also take a look at a very useful tool called the Burndown Chart along with a typical Scrum process flow and a quick look at the Scrum self-improvement process called a Sprint Retrospective. So, let's get started. The first Agile framework we're going to look at is called Extreme Programming or XP for short. We build the software application iteratively a little piece at a time. We deliver these little pieces in quick, short bursts, typically no more than 1-3 weeks at a time. Prior to each iteration, the team meets in a planning session to determine the work to be done during the iteration. XP's four key values. First is communication. XP recommends the development team have the customer available to them at all times. This allows for constant communication between the stakeholders and the developers. XP also recommends the use of pair programming. In pair programming, two developers work together at one workstation and support one another during the development process. The approach has been proven to be quite effective. The second value is simplicity. XP stresses that when we develop our designs and our code we keep things as simple as possible. Value number three is feedback, Developing good software is a team effort. So, the first point we'll see under feedback is testing. In XP testing should be continuous. Developers should run unit tests on their code every time there is a reason to do so, in other words, every time it changes. Finally, feedback is facilitated by implementing small releases of functionality. After all, if we try to jam pack dozens of function points into our next iteration, we now have to make sure that all of these dozens of function points are being tested, and if they are not passing our tests then we now have dozens of function points to repair.
Now that we understand the XP values, communication, simplicity, feedback, and courage, let's take a look at the five sets of XP rules. The first set of rules is concerned with planning, both release planning, and iteration planning. Keep in mind that a release is a larger unit of work. Its purpose is to deliver a healthy set of requirements to our customers. We actually deliver this set of requirements by dividing our work up into smaller chunks called iterations. The second set of rules deals with managing the XP project, and they're designed to make sure that each iteration proceeds as smoothly and as efficiently as possible. The third set of rules provides guidelines for directing our design process. First, we should prefer simplicity. Avoid complicated designs. This is not always easy, and it's not always attainable, but we should always strive for it. And given the choice between a simple design and a complicated one, we should always prefer the former. The fourth set of rules involves the coding process. First, we should make sure that the customer or business expert is available to our developers. Since relatively little time is spent analyzing and digesting the requirements, it is common that implementation details get overlooked at design time. This means that they have to be settled during implementation or coding. Developers will often come up with crucial questions during the coding process as to exactly how a specific feature should be implemented. The correct person to answer those questions is often the customer, so to keep our development team moving at a good pace we must keep the communication lines open so that issues can be resolved quickly. The fifth and final set of rules involves the testing process. XP insists on unit tests. All code must have them, and as we've stated previously they must be written before the code is actually written. If a bug is found and it got passed to the unit tests, new tests are created to test for that bug. And finally, acceptance tests should be run often, and their scores should be made available to all stakeholders. The advantages and disadvantages of the model. First, the advantages. Pair programming, a pair of programmers work on a code module and then having people switch pairs and work on different modules helps promote the idea of no owner code. This way each programmer becomes familiar with all the modules in a project thus spreading around the expertise to all the developers. Extreme Programming and Scrum, the composition of the Scrum team, the roles within the team, the daily meeting, and the way that new releases are planned including handling the backlog and organizing Sprints and Sprint Retrospective. Another advantage XP values, communication, simplicity, feedback, and courage, XP rules and helps to create a positive project cultured. The most important feature first. This allows the project to be stopped any time yet still be a useful state. Disadvantages, eliminate big design up front; it’s easy to forget how good design can pay for itself. XP requires a lot of overhead; the order of importance is subjective and can still be addressed by up-front design anyway; XP emphasizes teamwork communication and prioritizing but that’s because everything becomes harder and we need all that stuff even more. All XP rules work only when supported by another rule.
There are few most impactful compare and contrast, throughout of my research I have understood that in waterfall model there is a very clear picture of the final product, whereas in spiral model determined during product planning and agile model there is no clear picture end of the software product. Project cost and completion date in waterfall model determined during planning, whereas in the spiral model partially variable and in an agile set during the project. While during the project or after complete the project, knowledge transfer training prior to project in the waterfall, spiral model and in agile teamwork during the project. Finally, the probability of success in the waterfall is low, in spiral medium-low and in agile high.
Software Failures:
In this section, I explain software failure arisen at TSB group in April 2018 and the cyber-attack on Microsoft systems. Realities, TSB mobile app failure on 19 April 2018, TSB announced it would be upgrading its online systems between 4 pm on Friday 20 April and 6 pm on the following Sunday. A planned system upgrade was expected to shut internet and mobile banking services down for one weekend in April 2018 but ended up causing months of disruption. The issues emerged from TSB's turn to another managing an account stage following its split from Lloyds Saving money Gathering. This causes a course of disappointments anticipated client to access or make an exchange for them. Reason for failure, a new system has been developed by the Spanish banking group Banco Sabadell. It a new web and online platform that is meant to replace the existing one. The new system creates outages far longer than expected. Impact of failure, quickly after the new framework was exchanged on, numerous clients experienced issues signing in, while others were indicated points of interest from other individuals' records or off base credits and charges without anyone else. Clients remained bolted out of their records two weeks after the underlying blackout. With 40% of those attempting to call the bank unfit to address somebody, while holding up times have hurried to over 30 minutes. Misrepresentation has turned into an issue, with confounded clients being deceived into enabling access to their records.1.9 million individuals to lose access to web-based managing an account administration. As per Wired, TSB was intending to move the records of its 5.4 million clients from a more established IT framework that was utilized when the organization was a piece of Lloyds. In spite of the fact that the two banks isolated in 2013, TSB was all the while utilizing Lloyds' framework to deal with its clients. Action was taken, those attempting to sign in to versatile or web keeping money have been advised to close the application or web program completely and attempt once more. On the off chance that this doesn't work, the bank recommends visiting an ATM, TSB branch or the Mail station to see adjusts and take out money.
Another software failure Wanacvry fact, In May 2017, a vast ransomware assault called WannaCry hits different associations in the UK and around the globe. The WannaCry ransomware cryptoworm, directed PCs running the Microsoft Windows working framework by encoding information and requesting buy-off installments in the Bitcoin digital money. Reason for failure, EternalBlue, a third party organization releases a middleware for older Windows systems. Vulnerabilities are found in Microsoft operating systems installed in millions of computers around the world. EternalBlue software opens the door to the attack. WannaCry takes advantage of installing backdoors onto systems in order to infect them. Impact of failure, as indicated by Microsoft, the Windows forms that were defenseless against the assault were adaptations which were never again bolstered by Microsoft, for example, Windows 8 and Windows XP. The assault was evaluated to have influenced in excess of 200,000 PCs crosswise over 150 nations, with aggregate harms running from several million to billions of dollars. Security specialists accepted from starter assessment of the worm that the assault began from North Korea or organizations working for the nation. On 14 May, the first variation of WannaCry showed up with another and second off button registered on that day. Pursued by a second variation with the third and last off button the ransomware crusade was remarkable in scale as indicated by Europol, which appraises that around 200,000 PCs were tainted crosswise over 150 nations. As per Kaspersky Lab, the four most influenced nations were Russia, Ukraine, India, and Taiwan. One of the biggest organizations struck by the assault was the National Wellbeing Administration healing facilities in Britain and Scotland, and up to 70,000 gadgets – including PCs, X-ray scanners, blood-stockpiling coolers, and theatre hardware. On 12 May, a few NHS administrations needed to dismiss non-basic crises, and a few ambulances were redirected Nissan Engine Assembling UK in Tyne and Wear, Britain, stopped creation after the ransomware tainted a portion of their frameworks. Renault additionally halted generation at a few destinations trying to stop the spread of the ransomware. Spain's Telefónica, FedEx and Deutsche Bahn were hit, alongside numerous different nations and organizations around the world. The action was taken to recover, While Microsoft had discharged fixes beforehand to close the exploit. The assault was halted inside a couple of days of its revelation because of crisis patches discharged by Microsoft, and the disclosure of an off button that kept tainted PCs from spreading WannaCry further. Scientist Marcus Hutchins inadvertently found the off button space hardcoded in the malware. Enrolling a space name for a DNS sinkhole halted the assault spreading as a worm, in light of the fact that the ransomware just scrambled the PC's documents in the event that it was not able to interface with that area, which all PCs tainted with WannaCry before the site's enlistment had been not able to do.
References:
Software Process methodology:
https://www.youtube.com/watch?v=1UD1P-fDCiI
http://www.the-software-experts.com/e_dta-sw-process.php
https://www.guru99.com/waterfall-vs-agile.html
Waterfall vs. Agile: Which is the Right Development Methodology for Your Project?
https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban
http://efficientprograms.blogspot.com/2013/07/spiral-model-vs-waterfall-model-agile.html
Software failures:
https://www.bbc.co.uk/news/business-44370802
http://www.theweek.co.uk/93365/tsb-it-crisis-news
https://en.wikipedia.org/wiki/WannaCry_ransomware_attack