SDLC

SDLC is the process of developing information systems through investigation, analysis, design,
implementation and maintenance. SDLC is also known as information systems development or
application development. It is also known as Waterfall Model

The software development life cycle (SDLC) is the entire process of formal, logical steps taken to
develop a software product. The phases of SDLC can vary somewhat but generally include the
following:

Requirements Analysis
Extracting the requirements of a desired software product is the first task in creating it. While
customers probably believe they know what the software is to do, it may require skill and experience in
software engineering to recognize incomplete, ambiguous or contradictory requirements.

Specification
Specification is the task of precisely describing the software to be written, in a mathematically rigorous
way. In practice, most successful specifications are written to understand and fine-tune applications that
were already well-developed, although safety-critical software systems are often carefully specified
prior to application development. Specifications are most important for external interfaces that must
remain stable.

Software architecture
The architecture of a software system refers to an abstract representation of that system. Architecture is
concerned with making sure the software system will meet the requirements of the product, as well as
ensuring that future requirements can be addressed. The architecture step also addresses interfaces
between the software system and other software products, as well as the underlying hardware or the
host operating system.

Coding
Reducing a design to code may be the most obvious part of the software engineering job, but it is not
necessarily the largest portion.

Testing
Testing of parts of software, especially where code by two different engineers must work together, falls
to the software engineer.

Documentation
An important task is documenting the internal design of software for the purpose of future maintenance
and enhancement. Documentation is most important for external interfaces.

Software Training and Support

A large percentage of software projects fail because the developers fail to realize that it doesn't matter
how much time and planning a development team puts into creating software if nobody in an
organization ends up using it. People are occasionally resistant to change and avoid venturing into an
unfamiliar area, so as a part of the deployment phase, its very important to have training classes for the
most enthusiastic software users (build excitement and confidence), shifting the training towards the
neutral users intermixed with the avid supporters, and finally incorporate the rest of the organization
into adopting the new software. Users will have lots of questions and software problems which leads to
the next phase of Software.

Maintenance
Maintaining and enhancing software to cope with newly discovered problems or new requirements can
take far more time than the initial development of the software. Not only may it be necessary to add
code that does not fit the original design but just determining how software works at some point after it
is completed may require significant effort by a software engineer. About 2/3 of all software
engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing
bugs.

Process Models
There are several methodologies or models that can be used to guide the software development
lifecycle. Some of these include:
--Linear or Waterfall Model
--Rapid Application Development (RAD)
--Joint Application Development (JAD)
--Prototyping Model
--Fountain Model
--Spiral Model
--Build and Fix
--Synchronize-and-Stabilize

Rapid Application Development

“Rapid Application Development (RAD) is an incremental software development process model that
emphasises a very short development cycle typically 60-90 days”.The RAD approach encompasses the
following phases:
1.Business Modelling
2.Data Modelling
3.Process Modelling
4.Application Generation
5.Testing and Turnover

Business Modelling
The information flow among business functions is modeled in am way that answers the following
questions:
1.What information drives the business process?
2.What information is generated?
3.Who generates it?
4.Where does the information go?
5.Who processes it?

Data Modelling
The information flow defined as part of the business modelling phase is refined into a set of data
objects that are needed to support the business.The characteristic of each object is identified and the
relationship between these objects are defined.

Process Modelling
The data objects defined in the data-modelling phase are transformed to achieve the information flow
necessary to implement a business function. Processing the descriptions are created for
adding,modifying,deleting or retrieving data object.

Application Generation
RAD assumes the use of the RAD tools like VB,VC++,Delphi etc rather than creating
software using conventional third generation programming languages. The RAD works to reuse
existing program components or create reusable components. In all cases,automated tools are used to
facilitate construction of the software.

Testing and Turnover

Since the RAD process emphasizes reuse,many of the program components have already
been tested. This minimize the testing and development time.

Continued...

Certifications In SDLC:

SDLC Online certification

Website:http://www.expertrating.com/details.asp?examid=376&catid=23

Process Models in SDLC

Prototyping Model

Prototyping is the process of quickly putting together a working model in order to test various aspects
of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an
integral part of the system design process, where it is believed to reduce project risk and cost. Often
one or more prototypes are made in a process of incremental development where each prototype is
influenced by the performance of previous designs, in this way problems or deficiencies in design can
be corrected

Product development tends to move along four axes,

--Ideas to product
--Low technology to high technology
--Drawings to code
--Appearance and behavior to performance
Ideas for improving the product, whether in terms of requirements, understanding the users, or
designing a solution, tend to occur within the early phases along each axis. Proper use of prototyping
can help keep the development effort focused on those early phases until the solution is well
defined.The process of prototyping involves the following steps

1.Identify basic requirements

Basic requirements including the input and output information desired. In this step, the editing rules,
security issues will be typically ignored as this is just a rough idea on what it will be like.

2.Develop Initial Prototype

After identifying the basic requirements then you will be set to develop an initial prototype and in this
initial prototype will include only user interfaces. For example data entry screens and reports.

3.Knowledge Worker Reviewing

This will be the step where the iterative process of prototyping starts where knowledge workers first
initiate this step, they will evaluate the prototype and give out feedback such as suggestions on
changing a certain part or additions of certain element. The involvement of more knowledge workers is
important because it will help resolve any discrepancies in areas such as terminology and operational
processes.

4.Revise and Enhancing the Prototype

A final step in prototyping is to revise and enhance the prototype according to any suggestions from the
knowledge workers. If there’s any changes and addition you did in this step, you will be required to
repeat step 3 and 4 again.

Waterfall Model

The best-known and oldest process is the waterfall model, where developers follow these steps in order.
They state requirements, analyze them, design a solution approach, architect a software framework for
that solution, develop code, test (perhaps unit tests then system tests), deploy, and maintain. After each
step is finished, the process proceeds to the next step, just as builders don't revise the foundation of a
house after the framing has been erected. If iteration is not included in the planning, the process has no
provision for correcting errors in early steps , so the entire (expensive) engineering process may be
executed to the end, resulting in unusable or unneeded software features.

In old style (CMM) processes, architecture and design preceded coding, usually by separate people in a
separate process step.

Joint Application Development

JAD (Joint Application Development) is a methodology that involves the client or end user in the
design and development of an application, through a succession of collaborative workshops called JAD
sessions. Chuck Morris and Tony Crawford, both of IBM, developed JAD in the late 1970s and began
teaching the approach through workshops in 1980.Joint Application Development (JAD) is a
development methodology system originally used for designing a computer-based system, but can be
applied to any development process. It involves continuous interaction with the users and different
designers of the system in development. JAD centers around a workshop session that is structured and
focused. Participants of these sessions would typically include a facilitator, end users, developers,
observers, mediators and experts. JAD allows for a faster development process and minimizes errors at
the same time. JAD also improves the quality of the final product by focusing on the up-front portion
of the development lifecycle, thus reducing the likelihood of errors that are expensive to correct later
on.

The JAD process is based on four simple ideas:

1.People who actually do a job have the best understanding of that job.
2.People who are trained in information technology have the best understanding of the possibilities of
that technology.
3.Information systems and business processes rarely exist in isolation -- they transcend the confines of
any single system or office and affect work in related departments. People working in these related
areas have valuable insight on the role of a system within a larger community.
4.The best information systems are designed when all of these groups work together on a project as
equal partners.

General JAD Principles

The general principles of JAD apply to performing all of these tasks. JAD sessions adhere to these
principles:

--Involve the stakeholders, including the project sponsor and manager, tech writer, and subject matter
experts as part of the project team [Hol93]. In some companies, the largest user stakeholder co-leads
with the technical lead. Some companies rotate IS professionals into the user groups [Fin95] or move
user experts into the IS group [Eng96] for duration of the project.

--JAD teams must have support from upper management, both to allow the time and effort spent, and to
accept the team's conclusions and results.

--A technical facilitator with skills in both systems analysis and group dynamics is essential; someone
who can speak both the languages of customer and developer [Eng96, Hol93, Lev95]. With a neutral
facilitator, scribe, high level business sponsor, project manager, end users, and programmers, this
schematic results in faster and more exact application development [Kno95].

--Ensure that each stakeholder has a representative empowered with decision-making - JAD sessions
are working sessions. Mid-level managers are preferred over executives [Eng96].

--The sessions may rotate-in special workers, typically subject matter experts or members of the line
staff, to answer detailed questions.

--Users drive the speed of the project in this phase. Sessions are scheduled at the discretion of the user,
but weekly meetings are recommended (older JAD forms required lockin-style sessions).

--Each session should last about 2 hours, although rush projects may justify 4hr sessions (effectiveness
drops quickly after the 2hr point). JAD teams should not be more than 15 people, and should be
properly selected [Kno95].

--Each session must produce JAD minutes, which contains attendees' resolutions, action items, and
open issues. The facilitator sends copies to all team members and their managers. This is a critically
important deliverable to maintain project momentum, accountability, political visibility, and to avoid
rework and priority shifting.
Fountain Model

The Fountain Model is a highly iterative approach that is well-suited to object-oriented software
development. The Fountain Model allows for the fact that there is considerable overlap of activities
throughout the development cycle — although some activities can't start before others.Just as a
fountain’s water rises up and falls back to the pool below, in object-oriented software development, the
general workflow from analysis through design to implementation is overlaid with iterative cycles
across many phases.

Spiral Model

The spiral model is a Systems Development Life Cycle methodology that combines features of
prototyping with the waterfall methodology. The spiral model is often favored for large, complex
projects.

Steps in the spiral model include:

1.The new system requirements are defined. This usually involves interviewing a number of users
representing all the end users of the system.
2.A preliminary system design is created.
3.An initial prototype of the new system is constructed from the preliminary design. This is usually a
scaled-down system, and represents an approximation of the final product’s characteristics.
4.After evaluating the strengths, weaknesses and risks of the first prototype, a second prototype is
developed and tested.
5.If the risk is considered to be too great, the client may choose to terminate the project at this point.
Risk factors to be considered include development cost overruns, operating-cost miscalculation, etc.
6.Subsequent prototypes are developed until the customer is satisfied that the latest prototype
represents the desired product.
7.The system is constructed, based on the final prototype.
8.The final system is evaluated and tested. Routine maintenance is carried out continually to prevent
large-scale failures and to minimize downtime.

Build and Fix Model

Build and Fix (also known as Ad-Hoc Development) is the least structured of the Systems
Development Life Cycle methodologies. It relies heavily on the expertise of the individual team
members. With the Build and Fix method, developers write some code, then continue to modify it until
it seems to work and the customer is satisfied. With poor planning, this strategy can be risky and, if
executed poorly, it can push developer effort into the project's maintenance stage.

Synchronize-and-Stabilize Model

Synchronize-and-stabilize (also called sync-and-stabilize) is a Systems Development Life Cycle

methodology in which teams work concurrently on individual application modules. They frequently
synchronize their code with that of other teams, and debug or “stabilize” their code regularly
throughout the development process.
The sync-and-stabilize model offers advantages over the classic waterfall model, which is sequential in
nature. Because sync-and-stabilize development allows for changes at any point throughout the
process, it is inherently more flexible, and allows responsiveness to changing business requirements.