SDLCs

All Software Development Life Cycle models have similar stages. Some are sculpted to have more, some a little less. depending on the application. These ideas exist in all of the models, and the "classic" Waterfall model is commonly found in the design of websites, databases and small to medium software projects.

There are 3 assignments associated with this section, and you should also be familiar with the terms and concepts for the exam. The assignments are to:

Write a report on the history and evolution of agile SDLC
Use and apply the Waterfall SDLC in a project - typically a website, database or a small program (<1000 lines of code)
Use and apply agile methods and processes in a team development, typically a multi-part application

These assignments can overlap with other subjects such as PDP, Web Authoring, OOP, Database and Internet.

Classic Design Model

The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.

The Waterfall model is the earliest SDLC approach that was used for software development.

The waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. In this waterfall model, the phases do not overlap.

Stages

The following is an outline of each stage with an example of it's application to the development of a website, as an example.

Requirement Gathering and analysis − All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document. Speak with the customer- what is the aim of the site? What do they want it to do? What are the elements or features that must be included? There may be a case for defining user, functional and non-functional requirements of the site. Explore the detail of these aspects of requirements here.
System Design − The requirement specifications from first phase are studied in this phase and the system design is prepared. This system design helps in specifying hardware and system requirements and helps in defining the overall system architecture. For a website, you may create a mock-up of the finished site- this would require the creation of a Sitemap to show the structure of the overall site and wire-frame(s) to show the structure of a typical page. The customer would approve the design before any of the coding begins for the site.
Implementation − With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing. On a site, using an agile approach, the customer may sign-off on each page or section as it is developed, flagging any changes that had to be made.
Integration and Testing − All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures. Bugs are flagged and fixed. For a website. at this stage we may upload the site to a test server for tests such as speed testing and verify correct rendering on multiple devices.
Deployment of system − Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market. The site may be moved from a "test server" to a "live server" and is available to the target population.
Maintenance − There are some issues which come up in the client environment. To fix those issues, patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment. A full discussion of the types of maintenance is not covered here but there are 4 general types:
1. Corrective- fixing of bugs not detected or foreseen during the development and testing stages
2. Adaptive- there may be a change made such that the software might work with less RAM or on a slower CPU (different hardware) or to allow it to run on a different Operating System (software).
3. Perfective - tweaking aspects such as the appearance, addition of a new attribute or removal of unnecessary elements identified by the user- to try to achieve total perfection for the user.
4. Preventative - Improve reliability or security, efficiency, or effectiveness- for example- probe the software for vulnerabilities (as could be exploited by a hacker) and look for areas of weakness that can be strengthened.

WaterfallProcess

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model, phases do not overlap.

Waterfall Model - Application

Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors. Some situations where the use of Waterfall model is most appropriate are −

Requirements are very well documented, clear and fixed.
Product definition is stable.
Technology is understood and is not dynamic.
There are no ambiguous requirements.
Ample resources with required expertise are available to support the product.
The project is short.

Waterfall Model - Advantages

The advantages of waterfall development are that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order.

Some of the major advantages of the Waterfall Model are as follows −

Simple and easy to understand and use
Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
Phases are processed and completed one at a time.
Works well for smaller projects where requirements are very well understood.
Clearly defined stages.
Well understood milestones.
Easy to arrange tasks.
Process and results are well documented.

Waterfall Model - Disadvantages

The disadvantage of waterfall development is that it does not allow much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage.

The major disadvantages of the Waterfall Model are as follows −

No working software is produced until late during the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model.
It is difficult to measure progress within stages.
Cannot accommodate changing requirements.
Adjusting scope during the life cycle can end a project.
Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.

SW Failures

As the software industry developed and began to be used in a wider variety of industries, the size of the projects became larger and more complicated.

Projects went from hundreds of lines of code to thousands, tens of thousands of lines, hundreds of thousands and then millions of lines of code. It was because of the failures associated with traditional methods that a new way of approaching software design and implementation was needed. There are some interesting figures here from an IBM study showing where the costs arise, and another story here that quantifies these costs.

Agile Manifesto

The Agile manifesto is based on 12 principles, with 4 pillars derived from the principles. The four pillars say that, while there is value in the things on the right, we value the things on the left more.

V-Model

Spiral Model

RAD Model

Incremental Model

Agile SDLC

Agile means adaptive. Doing something in a way that is faster to change and adapt to changes in the environment. Find out more about the agile methods here. Forms of agile SDLC include:

RAD
Iterative Model
V-Model
Spiral Model

There are many. In general, agile models are preferred where:

there is a lot of uncertainty
the scale of the project is quite large
complexity is part of the project

Agile Model - Pros and Cons

Agile methods are being widely accepted in the software world recently. However, this method may not always be suitable for all products. Here are some pros and cons of the Agile model.

The advantages of the Agile Model are as follows −

Is a very realistic approach to software development.
Promotes teamwork and cross training.
Functionality can be developed rapidly and demonstrated.
Resource requirements are minimum.
Suitable for fixed or changing requirements
Delivers early partial working solutions.
Good model for environments that change steadily.
Minimal rules, documentation easily employed.
Enables concurrent development and delivery within an overall planned context.
Little or no planning required.
Easy to manage.
Gives flexibility to developers.

The disadvantages of the Agile Model are as follows −

Not suitable for handling complex dependencies.
More risk of sustainability, maintainability and extensibility.
An overall plan, an agile leader and agile PM practice is a must without which it will not work.
Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines.
Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong direction.
There is a very high individual dependency, since there is minimum documentation generated.
Transfer of technology to new team members may be quite challenging due to lack of documentation.

Agile Tools

One of the tools we will use is a Kanban or Scrum Board. We have found trello quite a good tool to communicate the ideas of Kanban in class. You can do an example in class of "To do" "In progress" and "Complete" for a very simple version of the board... decide how to assign tasks to people/ allow people pull tasks, color code for a category or priority, add weightings (effort/time) and deadlines/targets... all very easy to use.

There are also plugins that can enhance the use of trello such as

Kanban WIP for Trello
Trello Folds (Kanban for Trello)

There is a full tutorial here that you will find useful as a resource and as a guide. Play with it, try it out and see what you think.

Dev-Ops

A compound of development (Dev) and operations (Ops), DevOps is the union of people, process, and technology to continually provide value to customers.

What does DevOps mean for teams? DevOps enables formerly siloed roles - development, IT operations, quality engineering, and security - to coordinate and collaborate to produce better, more reliable products.

By adopting a DevOps culture along with DevOps practices and tools, teams gain the ability to better respond to customer needs, increase confidence in the applications they build, and achieve business goals faster. Teams that adopt DevOps culture, practices, and tools become high-performing, building better products faster for greater customer satisfaction. This improved collaboration and productivity is also integral to achieving business goals like these:

Accelerating time to market
Adapting to the market and competition
Maintaining system stability and reliability
Improving the mean time to recovery

Find free courses online to complement this module.

Page updated

Google Sites

Report abuse