Vous êtes sur la page 1sur 25

UNIT-2 System Development Life Cycle

Q. Explain SDLC Phases in Brief?There is various software development approaches defined

and designed which are used during development process of software, these approaches are also
referred as Software Development Process Models (e.g. Waterfall model). Each process model
follows a particular life cycle in order to ensure success in process of software development.

Software life cycle models describe phases of the software cycle and the order in which those
phases are executed. Each phase produces deliverables required by the next phase in the life
cycle. Requirements are translated into design. Code is produced according to the design which
is called development phase. After coding and development the testing verifies the deliverable of
the implementation phase against requirements.

There are following six phases in every Software development life cycle model:

1. Recognition of need and problem Definition

2. Feasibility study
3. Analysis
4. Design
5. Implementation
6. Post implementation and maintenance

1. Recognition of need and Problem Definition:

It is the first stage of information system development cycle. This gives a clearer
picture of what actually the existing system is. The preliminary investigation must define the
scope of the project and the perceived problems, opportunities and directives that triggered
the project.
The preliminary investigation includes the following tasks:
a. List problems, opportunities and directives.
b. Negotiate preliminary scope.
c. Assess project worth.
d. Plan the project.
e. Present the project and plan.
Q. Explain Feasibility study in detail? Or Write short note on Feasibility Study?
2. Feasibility Study:
The statement dont try to fix it unless you understand it apply describe the
feasibility study stage of system analysis. The goal of feasibility study is to evaluate
alternative system and to purpose the most feasible and desirable system for
It consists of the following:
a. Statement of the problem
b. Summary of findings and recommendations
c. Details of findings
d. Recommendations and conclusions
There are basically six types of feasibility are addressed in the study.
1. Technical feasibility
2. Economic feasibility
3. Motivational feasibility
4. Schedule feasibility
5. Operational feasibility
6. Cost /benefit analysis

1. Technical Feasibility: The technical feasibility study compares the level of technology
available in the software development firm and the level of technology required for the
development of the product. Here the level of technology consists of the programming
language, the hardware resources, Other software tools etc. In short it is solution for
Does the company have the technological resources to undertake the project? Are the processes and procedures

conducive to project success?

2. Economic Feasibility: The economic feasibility study evaluates the cost of the software
development against the ultimate income or benefits gets from the developed system.
There must be scopes for profit after the successful Completion of the project . Illustrate
the cost/benefit of the new system by applying a suitable cost/benefit analysis method
such as the payback method.
3. Motivational feasibility: In this feasibility study the investigator analyzing software
developer motivation. Motivation has been identified as a crucial factor in software
productivity and software failure. However previous work suggests that conventional
approaches to motivation which are based on reward and recognition are not appropriate
for software engineering. The evidence suggests that the technical context of software
engineers' work is important to their motivation (e.g. the technical challenge and
complexity of their work and the development tools they use).
4. Schedule feasibility: It is study of current status of company resources including
technical and human resources and their working schedules. In Short it is answer for
Does the company currently have the time resources to undertake the project? Can the
project be completed in the available time?
5. Operational feasibility: Operational feasibility study tests the operational scope of the
software to be developed. The proposed software must have high operational feasibility.
The usability will be high.

6. Cost /benefit analysis:

Feasibility studies typically involve cost/benefit analysis. In the process of feasibility
study, the cost and benefits are estimated with greater accuracy. If cost and benefit can be
quantified, they are tangible ; if not , they are called intangible.

Q. What is System analysis? Or explain roles of System Analysts?
3. System Analysis:
System analysis is not a preliminary study. It is an in-depth study of end user
information needs that produces functional requirements that are used as the basis for the
design of a new information system.
System involves detailed study of:
The information needs of the organization and end user.
The activities, resources and products of any present information system.
The information system capabilities required to meet your Information needs.
This phase is to collect all the required information for developing the software.
Here the analyst make use of various information gathering tools and technique. After a
careful analysis of the system the analyst come up with an analysis report.
The main objectives of preliminary analysis is to identify the customer's needs, evaluate system
concept for feasibility, perform economic and technical analysis, perform cost benefit analysis
and create system definition that forms the foundation for all subsequent engineering works.
There should be enough expertise available for hardware and software for doing analysis.

While performing analysis, the following questions arise.

How much time should be spent on it?

As such, there are no rules or formulas available to decide on this. However, size,
complexity, application field, end-use, contractual obligation are few parameters on
which it should be decided.
Other major question that arises is who should do it.
Well an experienced well-trained analyst should do it. For large project, there can be an
analysis team.

Roles of Software System Analyst

System analyst in an IT organization is a person, who analyzes the requirement of proposed
system and ensures that requirements are conceived and documented properly & correctly. Role
of an analyst starts during Software Analysis Phase of SDLC. It is the responsibility of analyst
to make sure that the developed software meets the requirements of the client.

System Analysts have the following responsibilities:

Analyzing and understanding requirements of intended software

Understanding how the project will contribute in the organization objectives
Identify sources of requirement
Validation of requirement
Develop and implement requirement management plan
Documentation of business, technical, process and product requirements
Coordination with clients to prioritize requirements and remove and ambiguity
Finalizing acceptance criteria with client and other stakeholders

After the preliminary analysis, the analyst should report the findings to management, with
recommendations outlining the acceptance or rejection of the proposal.

Q. What is System Design? Or write short note on System Design?

4. System Design:
System design can be viewed as the design of user interface, data, process and system
The process involved in manipulation of data & output design represents:-
o File structure, storage devices etc
o Database is also designed in this phase
o Changes to be made in the organizational structure of the firm are outlines
o Input, Output, files, forms and procedures are planned
o Finally standards for testing, documentation, system control are designed.

Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation.

For assessing user requirements, an SRS (Software Requirement Specification) document is

created whereas for coding and implementation, there is a need of more specific and detailed
requirements in software terms. The output of this process can directly be used into
implementation in programming languages.

Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS. Software designers are use DFD, ERD, structured charts etc.

Software Design Levels
Software design yields three levels of results:

Architectural Design - The architectural design is the highest abstract version of the
system. It identifies the software as a system with many components interacting with
each other. At this level, the designers get the idea of proposed solution domain.
High-level Design- The high-level design breaks the single entity-multiple component
concept of architectural design into less-abstracted view of sub-systems and modules and
depicts their interaction with each other. High-level design focuses on how the system
along with all of its components can be implemented in forms of modules. It recognizes
modular structure of each sub-system and their relation and interaction among each other.
Detailed Design- Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs. It is more detailed towards
modules and their implementations. It defines logical structure of each module and their
interfaces to communicate with other modules.
Q. Explain S/W Design strategies?
Software Design Strategies:
1. Structured Design
Structured design is a conceptualization of problem into several well-organized elements of
solution. It is basically concerned with the solution design. Benefit of structured design is, it
gives better understanding of how the problem is being solved. Structured design also makes it
simpler for designer to concentrate on the problem more accurately.
Structured design is mostly based on divide and conquer strategy where a problem is broken
into several small problems and each small problem is individually solved until the whole
problem is solved.
The small pieces of problem are solved by means of solution modules. Structured design
emphasis that these modules be well organized in order to achieve precise solution.
These modules are arranged in hierarchy. They communicate with each other. A good structured
design always follows some rules for communication among multiple modules, namely -
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
A good structured design has high cohesion and low coupling arrangements.

2. Function Oriented Design

In function-oriented design, the system is comprised of many smaller sub-systems known as
functions. These functions are capable of performing significant task in the system. The system
is considered as top view of all functions.
Function oriented design inherits some properties of structured design where divide and conquer
methodology is used.
This design mechanism divides the whole system into smaller functions, which provides means
of abstraction by concealing the information and their operation.. These functional modules can
share information among themselves by means of information passing and using information
available globally.

Another characteristic of functions is that when a program calls a function, the function changes
the state of the program, which sometimes is not acceptable by other modules. Function oriented
design works well where the system state does not matter and program/functions work on input
rather than on a state.
Design Process
The whole system is seen as how data flows in the system by means of data flow
DFD depicts how functions changes data and state of entire system.
The entire system is logically broken down into smaller units known as functions on the
basis of their operation in the system.
Each function is then described at large.
3. Object Oriented Design
Object oriented design works around the entities and their characteristics instead of functions
involved in the software system. This design strategies focuses on entities and its characteristics.
The whole concept of software solution revolves around the engaged entities.
Let us see the important concepts of Object Oriented Design:
Objects - All entities involved in the solution design are known as objects. For example,
person, banks, company and customers are treated as objects. Every entity has some
attributes associated to it and has some methods to perform on the attributes.
Classes - A class is a generalized description of an object. An object is an instance of a
class. Class defines all the attributes, which an object can have and methods, which
defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities are defined by means
of methods or procedures.
Encapsulation - In OOD, the attributes (data variables) and methods (operation on the
data) are bundled together is called encapsulation. Encapsulation not only bundles
important information of an object together, but also restricts access of the data and
methods from the outside world. This is called information hiding.
Inheritance - OOD allows similar classes to stack up in hierarchical manner where the
lower or sub-classes can import, implement and re-use allowed variables and methods
from their immediate super classes. This property of OOD is known as inheritance. This
makes it easier to define specific class and to create generalized classes from specific
Polymorphism - OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned same name. This is called
polymorphism, which allows a single interface performing tasks for different types.
Depending upon how the function is invoked, respective portion of the code gets
Design Process
Software design process can be perceived as series of well-defined steps. Though it varies
according to design approach (function oriented or object oriented, yet It may have the following
steps involved:
A solution design is created from requirement or previous used system and/or system
sequence diagram.

Objects are identified and grouped into classes on behalf of similarity in attribute
Class hierarchy and relation among them is defined.
Application framework is defined.

Q. Explain Software Design Approaches in Brief?

Software Design Approaches

Here are two generic approaches for software designing:
1. Top Down Design
We know that a system is composed of more than one sub-systems and it contains a number of
components. Further, these sub-systems and components may have their on set of sub-system
and components and creates hierarchical structure in the system.
Top-down design takes the whole software system as one entity and then decomposes it to
achieve more than one sub-system or component based on some characteristics. Each sub-system
or component is then treated as a system and decomposed further. This process keeps on running
until the lowest level of system in the top-down hierarchy is achieved.
Top-down design starts with a generalized model of system and keeps on defining the more
specific part of it. When all components are composed the whole system comes into existence.
Top-down design is more suitable when the software solution needs to be designed from scratch
and specific details are unknown.
2. Bottom-up Design
The bottom up design model starts with most specific and basic components. It proceeds with
composing higher level of components by using basic or lower level components. It keeps
creating higher level components until the desired system is not evolved as one single
component. With each higher level, the amount of abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from some existing
system, where the basic primitives can be used in the newer system.
Both, top-down and bottom-up approaches are not practical individually. Instead, a good
combination of both is used.

Q. Describe term Software User Interface Design?

Software User Interface Design
User interface is the front-end application view to which user interacts in order to use the
software. User can manipulate and control the software as well as hardware by means of user
interface. Today, user interface is found at almost every place where digital technology exists,
right from computers, mobile phones, cars, music players, airplanes, ships etc.

User interface is part of software and is designed such a way that it is expected to provide the
user insight of the software. UI provides fundamental platform for human-computer interaction.

UI can be graphical, text-based, audio-video based, depending upon the underlying hardware
and software combination. UI can be hardware or software or a combination of both.

The software becomes more popular if its user interface is:

Simple to use
Responsive in short time
Clear to understand
Consistent on all interfacing screens
UI is broadly divided into two categories:

Command Line Interface

Graphical User Interface
Command Line Interface (CLI)
CLI has been a great tool of interaction with computers until the video display monitors came
into existence. CLI is first choice of many technical users and programmers. CLI is minimum
interface a software can provide to its users.

CLI provides a command prompt, the place where the user types the command and feeds to the
system. The user needs to remember the syntax of command and its use. Earlier CLI were not
programmed to handle the user errors effectively.

A command is a text-based reference to set of instructions, which are expected to be executed

by the system. There are methods like macros, scripts that make it easy for the user to operate.

CLI uses less amount of computer resource as compared to GUI.

CLI Elements
A text-based command line interface can have the following elements:

Command Prompt - It is text-based notifier that is mostly shows the context in which
the user is working. It is generated by the software system.

Cursor - It is a small horizontal line or a vertical bar of the height of line, to represent
position of character while typing. Cursor is mostly found in blinking state. It moves as
the user writes or deletes something.

Command - A command is an executable instruction. It may have one or more

parameters. Output on command execution is shown inline on the screen. When output
is produced, command prompt is displayed on the next line.

Graphical User Interface

Graphical User Interface provides the user graphical means to interact with the system. GUI can
be combination of both hardware and software. Using GUI, user interprets the software.

Typically, GUI is more resource consuming than that of CLI. With advancing technology, the
programmers and designers create complex GUI designs that work with more efficiency,
accuracy and speed.

GUI Elements
GUI provides a set of components to interact with software or hardware.

Every graphical component provides a way to work with the system. A GUI system has
following elements such as:

Window - An area where contents of application are displayed. Contents in a window

can be displayed in the form of icons or lists, if the window represents file structure. It is
easier for a user to navigate in the file system in an exploring window. Windows can be
minimized, resized or maximized to the size of screen. They can be moved anywhere on
the screen. A window may contain another window of the same application, called child

Tabs - If an application allows executing multiple instances of itself, they appear on the
screen as separate windows. Tabbed Document Interface has come up to open multiple
documents in the same window. This interface also helps in viewing preference panel in
application. All modern web-browsers use this feature.

Menu - Menu is an array of standard commands, grouped together and placed at a

visible place (usually top) inside the application window. The menu can be programmed
to appear or hide on mouse clicks.

Icon - An icon is small picture representing an associated application. When these icons
are clicked or double clicked, the application window is opened. Icon displays
application and programs installed on a system in the form of small pictures.

Cursor - Interacting devices such as mouse, touch pad, digital pen are represented in
GUI as cursors. On screen cursor follows the instructions from hardware in almost real-
time. Cursors are also named pointers in GUI systems. They are used to select menus,
windows and other application features.

Q. Explain System Implementation Phase of SDLC?

5. System Implementation:

Implementation is the stage where theory is converted into practical. The implementation is a
vital step in ensuring the success of new systems. Even a well designed system can fail if it is not
properly implemented.

System Implementation includes following activities:

Structured Programming
In the process of coding, the lines of code keep multiplying, thus, size of the software increases.
Gradually, it becomes next to impossible to remember the flow of program. If one forgets how
software and its underlying programs, files, procedures are constructed it then becomes very
difficult to share, debug and modify the program. The solution to this is structured
programming. It encourages the developer to use subroutines and loops instead of using simple
jumps in the code, thereby bringing clarity in the code and improving its efficiency Structured
programming also helps programmer to reduce coding time and organize code properly.

Structured programming states how the program shall be coded. Structured programming uses
three main concepts:

Top-down analysis - A software is always made to perform some rational work. This
rational work is known as problem in the software parlance. Thus it is very important
that we understand how to solve the problem. Under top-down analysis, the problem is
broken down into small pieces where each one has some significance. Each problem is
individually solved and steps are clearly stated about how to solve the problem.

Modular Programming - While programming, the code is broken down into smaller
group of instructions. These groups are known as modules, subprograms or subroutines.
Modular programming based on the understanding of top-down analysis.

Structured Coding - In reference with top-down analysis, structured coding sub-divides
the modules into further smaller units of code in the order of their execution.

Functional Programming
Functional programming is style of programming language, which uses the concepts of
mathematical functions. A function in mathematics should always produce the same result on
receiving the same argument. In procedural languages, the flow of the program runs through
procedures, i.e. the control of program is transferred to the called procedure. While control flow
is transferring from one procedure to another, the program changes its state.

Functional programming uses the following concepts:

First class and High-order functions - These functions have capability to accept
another function as argument or they return other functions as results.

Pure functions - These functions do not include destructive updates, that is, they do not
affect any I/O or memory and if they are not in use, they can easily be removed without
hampering the rest of the program.

Recursion - Recursion is a programming technique where a function calls itself and

repeats the program code in it unless some pre-defined condition matches. Recursion is
the way of creating loops in functional programming.

Strict evaluation - It is a method of evaluating the expression passed to a function as an

argument. Functional programming has two types of evaluation methods, strict (eager)
or non-strict (lazy). Strict evaluation always evaluates the expression before invoking
the function. Non-strict evaluation does not evaluate the expression unless it is needed.

Programming style
Programming style is set of coding rules followed by all the programmers to write the code.
When multiple programmers work on the same software project, they frequently need to work
with the program code written by some other developer. This becomes tedious or at times
impossible, if all developers do not follow some standard programming style to code the

An appropriate programming style includes using function and variable names relevant to the
target task, commenting code for the convenience of reader and overall presentation of code.
This makes the program code readable and understandable by all, which in turn makes
debugging and error solving easier. Also, proper coding style helps ease the documentation and

Coding Guidelines
Practice of coding style varies with organizations, operating systems and language of coding

The following coding elements may be defined under coding guidelines of an organization:

Naming conventions - This section defines how to name functions, variables, constants
and global variables.

Indenting - This is the space left at the beginning of line, usually 2-8 whitespace or
single tab.

Whitespace - It is generally omitted at the end of line.

Operators - Defines the rules of writing mathematical, assignment and logical operators.
For example, assignment operator = should have space before and after it, as in x =

Control Structures - The rules of writing if-then-else, case-switch, while-until and for
control flow statements solely and in nested fashion.

Line length - Defines how many characters should be there in one line, mostly a line is
80 characters long.

Functions - This defines how functions should be declared and invoked, with and
without parameters.

Variables - This mentions how variables of different data types are declared and

Comments - This is one of the important coding components, as the comments included
in the code describe what the code actually does and all other associated descriptions.
This section also helps creating help documentations for other developers.

Q. Explain Software Implementation Challenges?

Software Implementation Challenges
There are some challenges faced by the development team while implementing the
software. Some of them are mentioned below:

Code-reuse - Programming interfaces of present-day languages are very sophisticated

and are equipped huge library functions. Still, to bring the cost down of end product, the
organization management prefers to re-use the code, which was created earlier for some
other software. There are huge issues faced by programmers for compatibility checks
and deciding how much code to re-use.

Version Management - Every time a new software is issued to the customer, developers
have to maintain version and configuration related documentation. This documentation
needs to be highly accurate and available on time.

Target-Host - The software program, which is being developed in the organization,
needs to be designed for host machines at the customers end. But at times, it is
impossible to design software that works on the target machines.

6. Post implementation and Maintenance:

It is process of incorporating changes in the implemented existing system

i. Enhancement: Adding new functions or additional capability of the system.

ii. Adaptation: Customizing the software to run in a new environment.

iii. Correction: Correcting the bugs in the existing software.

Q. Explain a term Software Documentation?

Software Documentation
Software documentation is an important part of software process. A well written document
provides a great tool and means of information repository necessary to know about software
process. Software documentation also provides information about how to use the product.

A well-maintained documentation should involve the following documents:

Requirement documentation - This documentation works as key tool for software

designer, developer and the test team to carry out their respective tasks. This document
contains all the functional, non-functional and behavioral description of the target

Source of this document can be previously stored data about the software, already
running software at the clients end, clients interview, questionnaires and research.
Generally it is stored in the form of spreadsheet or word processing document with the
high-end software management team.

This documentation works as foundation for the software to be developed and is majorly
used in verification and validation phases. Most test-cases are built directly from
requirement documentation.

Software Design documentation - These documentations contain all the necessary

information, which are needed to build the software. It contains: (a)High-level software
architecture, (b) Software design details, (c) Data flow diagrams, (d) Database design

These documents work as repository for developers to implement the software. Though
these documents do not give any details on how to code the program, they give all
necessary information that is required for coding and implementation.

Technical documentation - These documentations are maintained by the developers and

actual coders. These documents, as a whole, represent information about the code. While
writing the code, the programmers also mention objective of the code, who wrote it,
where will it be required, what it does and how it does, what other resources the code
uses, etc.

The technical documentation increases the understanding between various programmers

working on the same code. It enhances re-use capability of the code. It makes debugging
easy and traceable.

There are various automated tools available and some comes with the programming
language itself. For example java comes JavaDoc tool to generate technical
documentation of code.

User documentation - This documentation is different from all the above explained. All
previous documentations are maintained to provide information about the software and
its development process. But user documentation explains how the software product
should work and how it should be used to get the desired results.

These documentations may include, software installation procedures, how-to guides,

user-guides, uninstallation method and special references to get more information like
license updation etc.

Q. Explain Factors Affecting Systems Development Success?

Factors Affecting Systems Development Success
Successful systems development means delivering a system that meets user and
organizational needs on time and within the budget. Years of experience in completing
systems development projects have resulted in the identification of number of factors that
contribute to the success or failure of system development. These factors include
the degree of change involved with the project,
quality of the project planning,
Organizational experience with the systems development process
Use of computer aided software engineering tools.

1. Degree of Change
The degree of change associated with the project is a major factor that affects the
quality of systems development. The scope can vary from implementing minor changes
to an existing system to major changes involving reengineering. It is very important for
the project team to recognize where they are on this spectrum of change.

Managing Change
Ability to manage change is a critical factor to the success of Information Systems
development. The Development of new information systems will invariably affect
the work environment and habits of users. It is unfortunate to note that, not everyone
adapts easily to these changes. This problem will multiply with the increasing complexity
of systems.

Managing change requires the ability to recognize existing or potential problems,
particularly ones that are concerns of users and deal with them before they become a
serious threat to the success of the new or modified system.

Several of the most common problems are listed below.

1. An Employee may feel that he/she will loose his/her job, power , or influence within
the organization.
2. Some employees may be unwilling to work with computers and computer staff.
3. The staff may believe that the proposed system will create more work than it
4. The staff may be worried that the proposed system will negatively alter the structure of
the organization.
5. The staff may not be willing to learn new procedures or approaches.
6. The staff may believe that other problems are more pressing than those solved by the
proposed system.
7. The staff may be worried that the system is being developed by people unfamiliar with
the way things need to get done.

Coordinating effort from all those who are involved or who have interest in the Information
System being developed, is needed to prevent or deal with these type of problems. One remedy is
simply to talk with all the people concerned and identify their biggest concerns. Subsequently the
management can deal with those concerns and try to eliminate them. Once these immediate
concerns are addressed, people can become part of the project team.

2. Quality of Project Planning

Another key factor that contributes to the success of system development is the quality
of project planning. When the project is bigger, it is more likely that poor planning will
lead to significant problems.
Poor systems development planning can be deadly.
Eg. A company developed navigational software that was partly responsible for an air
plane crash Colombia.
Failures of large system projects are due to the following reasons.
1. Fall behind schedule
2. Exceed budget
3. Do not meet expectations
Proper planning can minimize the likelihood of occurrence of these type of problems.

3. Project Management Tools

Project management is the process of planning, scheduling, directing, controlling and the
development of an acceptable system at a minimum cost within a specified time frame.
Even for small systems development projects, some type of project management must be

Although the steps of systems development seem straightforward, larger projects can become
complex, requiring hundreds of separate activities. For these systems development efforts,
formal project management methods and tools become essential.
A PERT (Program Evaluation and Review Technique) chart is a graphical network model
that shows a projects activities and the relationships between those activities. It is a formalized
approach to develop a project schedule.
A Gantt chart is a simple horizontal bar chart that shows project tasks against a calendar. Each
bar represents a named project task. It is used for planning, monitoring, and coordinating

4. Organizational Experience with the Systems Development Process

Another key factor that contributes to the success of system development is the
Organizational Experience with the Systems Development Process. One way to measure this
experience is the Capacity Maturity Model (CMM). CMM is a standardized framework for
assessing the maturity level of an organizations software development process. CMM is
organized into five maturity levels.
Level 1- Initial: At this level system development projects do not follow a consistent
process. Each development team uses its own tools and methods. Skills and experiences of the
team determine whether the project is successful or notAlmost all organizations start at level1.

Level 2- Repeatable: At this level, project management processes and practices are
established to track project costs, schedules and functionality. The focus is on project
management. Although a system development process is always followed, it may vary from
project to project. Success or failure is still a function of the skills and experiences of the project
team. However demanding effort is made to repeat earlier project successes. Effective project
management practices lay the foundation for standardized processes in the next level.

Level 3- Defined: In this level, a standard system development process (Sometimes

called a methodology) is purchased or developed. A tailored version of this process is
used for all the projects to develop and maintain information systems and software. As a
result of using the standardized system development processes for all projects, each
project results in consistent and high quality deliverables and documentation.

Level 4- Managed: In this level, organizations use detailed measures of the system
development process. This will help the organization to manage the process and improve
software and system quality.

Level 5- Optimized: In this level all aspects of the system development process is
continuously monitored and improved.
It is very important to recognize that each level is a prerequisite for the next level.

5. Use of Computer-Aided Software Engineering (CASE) Tools

They are tools design to automate many of the tasks required in a systems development. CASE
tools also enforce devotion to the systems development life cycle. Think of CASE tools as
software that is used to design and implement other software.
Q. What is SDLC or SDLC Model? List and explain SDLC models in Brief?

SDLC Models:
SDLC, Software Development Life Cycle is a process used by software industry to design,
develop and test high quality softwares. The SDLC aims to produce a high quality software that
meets or exceeds customer expectations, reaches completion within times and cost estimates.
SDLC is the acronym of Software Development Life Cycle.
It is also called as Software development process.
The software development life cycle (SDLC) is a framework defining tasks
performed at each step in the software development process.
ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be
the standard that defines all the tasks required for developing and maintaining software.

Q. What is SDLC?
SDLC is a process followed for a software project, within a software organization. It consists of
a detailed plan describing how to develop, maintain, replace and alter or enhance specific
software. The life cycle defines a methodology for improving the quality of software and the
overall development process.
The following figure is a graphical representation of the various stages of a typical SDLC.

A typical Software Development life cycle consists of the following stages:

Stage 1: Planning and Requirement Analysis
Requirement analysis is the most important and fundamental stage in SDLC. It 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 product feasibility study in the economical, operational, and
technical areas.
Planning for the quality assurance requirements and identification of the risks associated with the
project is also done in the planning stage. The outcome of the technical feasibility study is to
define the various technical approaches that can be followed to implement the project
successfully with minimum risks.

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
requirements 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
approach for the product architecture is proposed and documented in a DDS - Design Document
This DDS is reviewed by all the important stakeholders and based on various parameters as risk
assessment, product robustness, design modularity , budget and time constraints , the best design
approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party modules (if any).
The internal design of all the modules of the proposed architecture should be clearly defined with
the minutest of the details in DDS.
Stage 4: Building or Developing the Product
In this stage of SDLC the actual development starts and the product is built. The programming
code is generated as per DDS during this stage. If the design is performed in a detailed and
organized manner, code generation can be accomplished without much disturb.
Developers have to follow the coding guidelines defined by their organization and programming
tools like compilers, interpreters, debuggers etc are used to generate the code. Different high
level programming languages such as C, C++, Pascal, Java, and PHP are used for coding. The
programming language is 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, the testing
activities are mostly involved in all the stages of SDLC. However 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
market. Sometime product deployment happens in stages as per the organizations. business
strategy. The product may first be released in a limited segment and tested in the real business
environment (UAT- User acceptance testing).
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.

SDLC Models
There are various software development life cycle models defined and designed which are
followed during software development process. These models are also referred as "Software
Development Process Models". Each process model follows a Series of steps unique to its type,
in order to ensure success in process of software development.

Following are the most important and popular SDLC models followed in the industry:
Waterfall Model
Spiral Model
Q. Explain Waterfall Model in Detail?
1. Waterfall Model design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to
ensure success of the project. In "The Waterfall" approach, the whole process of software
development is divided into separate phases. In Waterfall model, typically, the outcome of one
phase acts as the input for the next phase sequentially.
Following is a diagrammatic representation of different phases of waterfall model.

The sequential phases in Waterfall model are:

Requirement Gathering and analysis: All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification doc.
System Design: The requirement specifications from first phase are studied in this phase
and system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.
Implementation: With inputs from 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.
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.
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.
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.
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 Pros & Cons
The advantage of waterfall development is 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.
The disadvantage of waterfall development is that it does not allow for 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 following table lists out the pros and cons of Waterfall model:

Pros Cons

Simple and easy to understand and No working software is produced until late during the life
use cycle.
Easy to manage due to the strictness High amounts of risk and uncertainty.
of the model . each phase has specific Not a good model for complex and object-oriented
deliverables and a review process. projects.
Phases are processed and completed Poor model for long and ongoing projects.
one at a time. Not suitable for the projects where requirements are at a
Works well for smaller projects where moderate to high risk of changing. So risk and
requirements are very well uncertainty is high with this process model.
understood. It is difficult to measure progress within stages.
Clearly defined stages. Cannot accommodate changing requirements.
Well understood milestones. No working software is produced until late in the life
Easy to arrange tasks. cycle.
Process and results are well Adjusting scope during the life cycle can end a project.
documented. Integration is done as a "big-bang. at the very end, which
doesn't allow identifying any technological or business
bottleneck or challenges early.

Q. Explain Spiral Model in Detail?
2. Spiral Model design
The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals.
Identification: This phase starts with gathering the business requirements in the baseline
spiral. In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in this phase.
This also includes understanding the system requirements by continuous communication
between the customer and the system analyst. At the end of the spiral the product is deployed in
the identified market.
Design: Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and final design
in the subsequent spirals.
Construct or Build: Construct phase refers to production of the actual software product
at every spiral. In the baseline spiral when the product is just thought of and the design is
being developed a POC (Proof of Concept) is developed in this phase to get customer
Then in the subsequent spirals with higher clarity on requirements and design details a working
model of the software called build is produced with a version number. These builds are sent to
customer for feedback.
Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and
monitoring technical feasibility and management risks, such as schedule slippage and
cost overrun. After testing the build, at the end of first iteration, the customer evaluates
the software and provides feedback.
Following is a diagrammatic representation of spiral model listing the activities in each phase:


Based on the customer evaluation, software development process enters into the next iteration
and subsequently follows the linear approach to implement the feedback suggested by the
customer. The process of iterations along the spiral continues throughout the life of the software.
Spiral Model Application

Spiral Model is very widely used in the software industry as it is in synch with the natural
development process of any product i.e. learning with maturity and also involves minimum risk
for the customer as well as the development firms. Following are the typical uses of Spiral
When costs there is a budget constraint and risk evaluation is important.
For medium to high-risk projects.
Long-term project commitment because of potential changes to economic priorities as the
requirements change with time.
Customer is not sure of their requirements which is usually the case.
Requirements are complex and need evaluation to get clarity.
New product line which should be released in phases to get enough customer feedback.
Significant changes are expected in the product during the development cycle.
Spiral Model Pros and Cons
The advantage of spiral lifecycle model is that it allows for elements of the product to be added
in when they become available or known. This assures that there is no conflict with previous
requirements and design.
This method is consistent with approaches that have multiple software builds and releases and
allows for making an orderly transition to a maintenance activity. Another positive aspect is that
the spiral model forces early user involvement in the system development effort.
On the other side, it takes very strict management to complete such products and there is a risk of
running the spiral in indefinite loop. So the discipline of change and the extent of taking change
requests is very important to develop and deploy the product successfully.
The following table lists out the pros and cons of Spiral SDLC Model:

Pros Cons

Changing requirements can be Management is more complex.

accommodated. End of project may not be known
Allows for extensive use of prototypes early.
Requirements can be captured more Not suitable for small or low risk
accurately. projects and could be expensive for
Users see the system early. small projects.
Development can be divided into smaller Process is complex
parts and more risky parts can be Spiral may go indefinitely.
developed earlier which helps better risk Large number of intermediate stages
management. requires excessive documentation.

Q. Explain RAD Model in Detail?
3. RAD Model:

What is RAD?
Rapid application development (RAD) is a software development methodology that uses
minimal planning in favor of rapid prototyping. A prototype is a working model that is
functionally equivalent to a component of the product.
In RAD model the functional modules are developed in parallel as prototypes and are integrated
to make the complete product for faster product delivery.
Since there is no detailed preplanning, it makes it easier to incorporate the changes within the
development process. RAD projects follow iterative and incremental model and have small
teams comprising of developers, domain experts, customer representatives and other IT
resources working progressively on their component or prototype.
The most important aspect for this model to be successful is to make sure that the prototypes
developed are reusable.
RAD Model Design
RAD model distributes the analysis, design, build, and test phases into a series of short, iterative
development cycles. Following are the phases of RAD Model:
Business Modeling: The business model for the product under development is designed
in terms of flow of information and the distribution of information between various
business channels. A complete business analysis is performed to find the vital
information for business, how it can be obtained, how and when is the information
processed and what are the factors driving successful flow of information.
Data Modeling: The information gathered in the Business Modeling phase is reviewed
and analyzed to form sets of data objects vital for the business. The attributes of all data
sets is identified and defined. The relation between these data objects are established and
defined in detail in relevance to the business model.
Process Modeling: The data object sets defined in the Data Modeling phase are
converted to establish the business information flow needed to achieve specific business
objectives as per the business model. The process model for any changes or
enhancements to the data object sets is defined in this phase. Process descriptions for
adding , deleting, retrieving or modifying a data object are given.
Application Generation: The actual system is built and coding is done by using
automation tools to convert process and data models into actual prototypes.
Testing and Turnover:The overall testing time is reduced in RAD model as the
prototypes are independently tested during every iteration. However the data flow and the
interfaces between all the components need to be thoroughly tested with complete test
coverage. Since most of the programming components have already been tested, it
reduces the risk of any major issues.

Following image illustrates the RAD Model:

RAD Model Vs Traditional SDLC
The traditional SDLC follows a rigid process models with high emphasis on requirement
analysis and gathering before the coding starts. It puts a pressure on the customer to sign off the
requirements before the project starts and the customer doesn.t get the feel of the product as there
is no working build available for a long time.
The customer may need some changes after he actually gets to see the software, however the
change process is quite rigid and it may not be feasible to incorporate major changes in the
product in traditional SDLC.
RAD model focuses on iterative and incremental delivery of working models to the customer.
This results in rapid delivery to the customer and customer involvement during the complete
development cycle of product reducing the risk of non conformance with the actual user
RAD Model Application
RAD model can be applied successfully to the projects in which clear modularization is possible.
If the project cannot be broken into modules, RAD may fail. Following are the typical scenarios
where RAD can be used:
RAD should be used only when a system can be modularized to be delivered in
incremental manner.
It should be used if there.s high availability of designers for modeling.
It should be used only if the budget permits use of automated code generating tools.
RAD SDLC model should be chosen only if domain experts are available with relevant
business knowledge.
Should be used where the requirements change during the course of the project and
working prototypes are to be presented to customer in small iterations of 2-3 months.

RAD Model Pros and Cons

RAD model enables rapid delivery as it reduces the overall development time due to reusability
of the components and parallel development.

RAD works well only if high skilled engineers are available and the customer is also committed
to achieve the targeted prototype in the given time frame. If there is commitment lacking on
either side the model may fail.
Following table lists out the pros and cons of RAD Model:
Pros Cons

Changing requirements can be Dependency on technically strong team

accommodated. members for identifying business
Progress can be measured. requirements.
Iteration time can be short with use of Only system that can be modularized can
powerful RAD tools. be built using RAD.
Productivity with fewer people in short Requires highly skilled
time. developers/designers.
Reduced development time. High dependency on modeling skills.
Increases reusability of components Inapplicable to cheaper projects as cost
Quick initial reviews occur of modeling and automated code
Encourages customer feedback generation is very high.
Integration from very beginning solves a Management complexity is more.
lot of integration issues. Suitable for systems that are component
based and scalable.
Requires user involvement throughout
the life cycle.
Suitable for project requiring shorter
development times.