SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

AND

SOFTWARE DEVELOPMENT METHODOLOGIES

An application development life cycle is term used by software engineers and de-velopers to describe a process composed of a number of clearly defined and distinct work phases, for planning, designing, building, testing, and deploying an information system. The systems devel-opment life-cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. Following the assem-bly line manufacturing concept, an SDLC aims to produce high quality systems that meet or ex-ceed customer expectations, based on customer requirements, by delivering systems which move through each clearly defined phase, within scheduled time-frames and cost estimates. In order to create a software project, we must adhere to a Software Development Life Cycle (SDLC) model. It is a framework that describes the activities performed at each stage of an application development project. SDLC is the process consisting of a series of planned activities to develop or alter the software products. No matter which life cycle model is followed, the basic activities are included in all life cycle models (though the activities may be carried out in different orders in different life cycle models). SDLC is not limited to technical activity but actually begins with customer needs and evolves through processes and user requirements to develop a solution or support process. The primary objective of implementing a standardised SDLC policy is to provide coordinated excellent service, at reduced costs, to support the activity of customers and users. Setting goals and milestones beforehand or planning ahead increases the chances of success at any given task. Since long term goals are the most difficult to achieve, people come up with short term goals, which will slowly but surely help them to move in the right direction.   This way, the team is organised and their actions well-planned.

There are six phases in every software development life cycle:

STAGE 1: PLANNING AND REQUIREMENT ANALYSIS

Requirement analysis, the fundamental stage in SDLC, is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. This information is then used to plan the basic project approach and to conduct prod-uct feasibility study in the economical, operational, and technical areas. 

STAGE 2: DEFINING REQUIREMENTS

Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the customer or the market analysts. This is done through SRS, Software Requirement Specification document, which consists of all the product re-quirements to be designed and developed during the project life cycle. 

STAGE 3: DESIGNING THE PRODUCT ARCHITECTURE

SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements specified in SRS, usually more than one design ap-proach for the product architecture is proposed and documented in a DDS - Design Document Specification which is then reviewed by all the important stakeholders. A design approach defines all the architectural modules of the product and communication and data flow representation with the external and third party modules, which is then clearly defined with the minutest of the details in DDS. 

STAGE 4: BUILDING OR DEVELOPING THE PRODUCT

In this stage of SDLC the programming code is generated as per DDS. Developers have to follow the coding guidelines defined by their organization and programming tools like compilers, inter-preters, debuggers etc are used to generate the code. The different high level programming lan-guages, such as C, C++, Pascal, Java, and PHP, are chosen with respect to the type of software being developed. 

STAGE 5: TESTING THE PRODUCT

This stage is usually a subset of all the stages as in the modern SDLC models, i.e., the testing ac-tivities are mostly involved in all the stages of SDLC.  This stage refers to the testing only stage of the product where products defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS. 

STAGE 6: DEPLOYMENT IN THE MARKET AND MAINTENANCE

Once the product is tested and ready to be deployed it is released formally in the appropriate mar-ket. Sometime product deployment happens in stages like the product may first be released in a limited segment and tested in the real business environment UAT − User acceptance testing and then based on the feedback, the product may be released as it is or with suggested enhancements in the targeting market segment. After the product is released in the market, its maintenance is done for the existing customer base. Each phase produces deliverables required by the next phase in the life cycle.

Different types of projects have different requirements. Therefore, it is required to choose the SDLC phases according to the specific needs of the project. These different requirements and needs give us various software development approaches to choose from during software imple-mentation.

The different types of models we could chose from are :

1. Waterfall Model

2. V-Shaped Model

3. Spiral Method

4. Rapid Application Development (RAD) Method

5. Incremental Model & Iterative Model

6. Prototyping

7. Agile Development (Extreme Programming)

We are building a website. Internet is everywhere and e-commerce has taken the market on a wild ride. We want to a website that has a user friendly UI. A websites contains a lot of web pages and so we decided to proceed with the incremental model.

ITERATIVE AND INCREMENTAL METHOD

Incremental Method - In incremental model the whole requirement is divided into various builds. Multiple development cycles take place here, making the life cycle a “multi-wa-terfall” cycle.  Cycles are divided up into smaller, more easily managed modules.  Each module passes through the requirements, design, implementation and testing phases. A working version of software is produced during the first module, so you have working software early on during the software life cycle. Each subsequent release of the module adds function to the previous release. The process continues till the complete system is achieved.

ADVANTAGES OF INCREMENTAL MODEL:

Generates working software quickly and early during the software life cycle. This model is more flexible – less costly to change scope and requirements. It is easier to test and debug during a smaller iteration. In this model customer can respond to each built. Lowers initial delivery cost. Easier to manage risk because risky pieces are identified and handled during it’d iteration. 

DISADVANTAGES OF INCREMENTAL MODEL:

Needs good planning and design. Needs a clear and complete definition of the whole system before it can be broken down and built incrementally. Total cost is higher than waterfall. 

WHEN TO USE THE INCREMENTAL MODEL:

This model can be used when the requirements of the complete system are clearly defined and understood. Major requirements must be defined; however, some details can evolve with time. There is a need to get a product to the market early. A new technology is being used

Resources with needed skill set are not available There are some high risk features and goals. 

The other models :

WATERFALL MODEL:

The waterfall Model is a linear sequential flow. In which progress is seen as flowing steadily down-wards (like a waterfall) through the phases of software implementation. This means that any phase in the development process begins only if the previous phase is complete. The waterfall approach does not define the process to go back to the previous phase to handle changes in requirement. The waterfall approach is the earliest approach that was used for software development.

AdvantagesDisadvantages

Easy to explain to the user· Structures ap-proach.· Stages and activities arewell defined· Helps to plan and schedule the project· Verifi-cation at each stage ensures early detection of errors / misunderstanding· Each phase has specific deliverables

Assumes that the requirements of a system can be frozen· Very difficult to go back to any stage after it finished.· Little flexibility and adjusting scope is difficult and expensive.· Costly and re-quired more time, in addition to detailed plan

V-SHAPED MODEL:

It is an extension for waterfall model, Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The major difference be-tween v-shaped model and waterfall model is the early test planning in v-shaped model.

AdvantagesDisadvantages

Simple and easy to use.· Each phase has spe-cific deliverables.· Higher chance of success over the waterfall model due to the develop-ment of test plans early on during the life cycle.· Works well for where requirements are easily understood.

Very inflexible, like the waterfall model.· Little flexibility and adjusting scope is difficult and ex-pensive.· Software is developed during the im-plementation phase, so no early prototypes of the software are produced.· Model doesn’t pro-vide a clear path for problems found during testing phases.· Costly and required more time, in addition to detailed plan

PROTOTYPING MODEL:

It refers to the activity of creating prototypes of software applications, for example, incomplete ver-sions of the software program being developed. It is an activity that can occur in software develop-ment. It used to visualise some component of the software to limit the gap of misunderstanding the customer requirements by the development team. This also will reduce the iterations may occur in waterfall approach and hard to be implemented due to inflexibility of the waterfall approach. So, when the final prototype is developed, the requirement is considered to be frozen.

AdvantagesDisadvantages

Reduced time and costs, but this can be disad-vantage if the developer lose time in developing the prototypes· Improved and increased user involvement

Insufficient analysis· User confusion of proto-type and finished system· Developer misunder-standing of user objectives· Excessive develop-ment time of the prototype· Expense of imple-menting prototyping

SPIRAL METHOD (SDM):

It is combining elements of both design and prototyping-in-stages, in an effort to combine advan-tages of top-down and bottom-up concepts. This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects. This model uses many of the same phases as the waterfall model, in es-sentially the same order, separated by planning, risk assessment, and the building of prototypes and simulations.

AdvantagesDisadvantages

Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because im-portant issues are discovered earlier.· Early in-volvement of developers· Manages risks and develops system into phases

High cost and time to reach the final product.· Needs special skills to evaluate the risks and assumptions· Highly customized limiting re-us-ability

EXTREME PROGRAMMING (AGILE DEVELOPMENT):

It is based on iterative and incremental development, where requirements and solutions evolve through collaboration between cross-functional teams.

AdvantagesDisadvantages

Decrease the time required to avail some sys-tem features.· Face to face communication and continuous inputs from customer representative leaves no space for guesswork.· The end result is the high quality software in least possible time duration and satisfied customer

Scalability· Skill of the software developers· Ability of customer to express user needs· Doc-umentation is done at later stages· Reduce the usability of components.· Needs special skills for the team.

Rapid application development (RAD) is both a general term used to refer to alterna-

tives to the conventional waterfall model of software development as well as the name for

James Martin's approach to rapid development. In general, RAD approaches to software

development put less emphasis on planning tasks and more emphasis on development. In

contrast to the waterfall model, which emphasizes rigorous specification and planning,

RAD approaches emphasize the necessity of adjusting requirements in reaction to knowl-

edge gained as the project progresses. This causes RAD to use prototypes in addition to or

even sometimes in place of design specifications. RAD approaches also emphasize a flexi-

ble process that can adapt as the project evolves rather than rigorously defining specifica-

tions and plans correctly from the start. In addition to James Martin's RAD methodology,

other approaches to rapid development include Agile methods and the spiral model. RAD

is especially well suited (although not limited to) developing software that is driven by user

interface requirements. Graphical user interface builders are often called rapid application

development tools.

The James Martin RAD methodology[edit]

Phases in the James Martin approach to RAD

The James Martin approach to RAD divides the process into four distinct phases:

1.Requirements planning phase – combines elements of the system planning and sys-

tems analysis phases of theSystems Development Life Cycle (SDLC). Users, managers, and

IT staff members discuss and agree on business needs, project scope, constraints, and sys-

tem requirements. It ends when the team agrees on the key issues and obtains manage-

ment authorization to continue.

2.User design phase – during this phase, users interact with systems analysts and de-

velop models and prototypes that represent all system processes, inputs, and outputs. The

RAD groups or subgroups typically use a combination of Joint Application Development

(JAD) techniques and CASE tools to translate user needs into working models.User De-

sign is a continuous interactive process that allows users to understand, modify, and even-

tually approve a working model of the system that meets their needs.

3.Construction phase – focuses on program and application development task similar to

the SDLC. In RAD, however, users continue to participate and can still suggest changes or

improvements as actual screens or reports are developed. Its tasks are programming and

application development, coding, unit-integration and system testing.4.Cutover phase – resembles the final tasks in the SDLC implementation phase, including data conversion, testing, changeover to the new system, and user training. Compared with traditional methods, the entire process is compressed. As a result, the new system is built, delivered, and placed in operation much sooner.[6]

Pros and cons of rapid application development

modern Information Technology environment many systems are now built using some de-

gree of Rapid Application Development. Not necessarily the James Martin approach. In ad-

dition to Martin's methodology Agile methods and the Rational Unified Process are often

used for RAD development.

The advantages of RAD include:

Better Quality. By having users interact with evolving prototypes the business functional-

ity from a RAD project can often be much higher than that achieved via a waterfall model.

The software can be more usable and has a better chance to focus on business problems

that are critical to end users rather than technical problems of interest to developers.

Risk Control. Although much of the literature on RAD focuses on speed and user involve-

ment a critical feature of RAD done correctly is risk mitigation. It's worth remembering that

Boehm initially characterized the spiral model as a risk based approach. A RAD approach

can focus in early on the key risk factors and adjust to them based on empirical evidence

collected in the early part of the process. E.g., the complexity of prototyping some of the

most complex parts of the system.More projects completed on time and within budget. By focusing on the development of incremental units the chances for catastrophic failures that have dogged large waterfall projects is reduced. In the Waterfall model it was common to come to a realization after six months or more of analysis and development that required a radical rethinking of the entire system. With RAD this kind of information can be discovered and acted upon earlier in the process.[2] [8]

The disadvantages of RAD include:

The risk of a new approach. For most IT shops RAD was a new approach that required ex-

perienced professionals to rethink the way they worked. Humans are virtually always

averse to change and any project undertaken with new tools or methods will be more

likely to fail the first time simply due to the requirement for the team to learn.

Requires time of scarce resources. One thing virtually all approaches to RAD have in com-

mon is that there is much more interaction throughout the entire life-cycle between users

and developers. In the waterfall model, users would define requirements and then mostly

go away as developers created the system. In RAD users are involved from the beginning

and through virtually the entire project. This requires that the business is willing to invest

the time of application domain experts. The paradox is that the better the expert, the

more they are familiar with their domain, the more they are required to actually run the

business and it may be difficult to convince their supervisors to invest their time. Without

such commitments RAD projects will not succeed.

Less control. One of the advantages of RAD is that it provides a flexible adaptable

process. The ideal is to be able to adapt quickly to both problems and opportunities. There

is an inevitable trade-off between flexibility and control, more of one means less of the

other. If a project (e.g. life-critical software) values control more than agility RAD is not ap-

propriate.Poor design. The focus on prototypes can be taken too far in some cases resulting in a "hack and test" methodology where developers are constantly making minor changes to individual components and ignoring system architecture issues that could result in a better overall design. This can especially be an issue for methodologies such as Martin's that fo-cus so heavily on the User Interface of the system.[9]Very large systems. RAD typically focuses on small to medium-sized project teams. The other issues cited above (less design and control) present special challenges when using a RAD approach for very large scale systems.

WHY WE CHOSE RAD MODEL

RAD Model was best choice for our case.We were having a small team and our time was limited.We also wanted to build something something that can be customized to different types of ecom-merce user needs.We wanted a design which we can extend further as needed. And user can help improve the product during the entire project cycle.E-commerce system is very much dependent on its UI/UX and we wanted to improve it step by step to get the most desired and pleasant User experience.