Unit 2.

System Development Life Cycle

System Analyst:
A system analyst is a person responsible for the development of software
and hardware solution to the efficient working of the organization. Analysts study
the environment and problems of an organization to determine whether a new
information method can provide solution to the problem.
The main job of system analyst is to provide right type of information, in right
quantity at the right time in post effective manner to the management or the end
user.

Roles of System Analyst:

 Defining IT requirements of organization
 Gathering Data/Facts
 Analyzing the problem
 Setting priority amongst requirements
 Problem solving
 Drawing Specification
 Designing System
 Evaluating System

1. Defining IT requirements of organization:

The most imp and difficult task of an analyst is to understand the
organization’s requirement’s information. It includes interviewing
users finding out what information is they are using in the current
system.
2. Gathering Data/Facts:
For gathering data or facts, written documents are important
because these documents represent the formal information flow in
the system. The analyst studies documents such as input forms,
output records, invoices etc to understand how data are passed
and used in the present system.
3. Analyzing the problem:
 After gathering data or facts the analyst analyses the working of
current system and find out to what extent it meet the user’s
needs.
4. Setting priority amongst requirements:
In the organization there are many types of users, each user has
different types of information needs. It may not e possible to
satisfy the requirements of everyone due to limited availability of
resources so it is necessary to give priority. The priorities are set
on the basis of urgency and importance of user’s need.
5. Problem solving:
The system analyst helps IT users to solve their information
problems. In that role he must understand the problem and
suggest solutions.
6. Drawing specification:
The analyst obtains the input and output specification for optimal
functioning of the system to be developed.
7. Designing system:
Once the specifications are accepted by the management the
analyst gets on to the design of the system. The analyst must be
aware of the latest design tools for the system design so analyst
also knows as architect.
8. Evaluating system:
An analyst must critically test the performance of the designed
system with specifications after it has been in use for a
reasonable period of time.

Change Agent

The analyst may be viewed as an agent of change. A candidate system is designed

to introduce change and reorientation in how the user organization handles
information or makes decisions. Then, it is important that the user accepts
change. For user acceptance, analysts prefer user participations during design and
implementation. Analyst carefully plans, monitors and implements change into
the user domain because people inherently resist changes. In the role of a change
agent, Systems Analyst may use different approaches to introduce changes to the
user organization.

Investigator & monitor

A systems analyst may investigate the existing system to find the reasons for it’s
failure. The role of an investigator is to extract the problems from existing
systems and create information structures that uncover previously unknown
trends that may have a direct impact on organization. The role of a Monitor is to
undertake and successfully complete a project. In this role, analysts must monitor
programs in relation to time, cost and quality.

Architect

The analyst’s role as an architect is liaison between the user’s logical design
requirements and the detailed physical system design. As architect the analyst
also creates a detailed physical design of candidate systems. A systems analyst
makes the design of information system architecture on the basis of end user
requirements. This design becomes the blue print for the programmers.

Motivator
System acceptance is achieved through user participation in its development, effective user
training and proper motivation to use the system. The analyst’s role as a motivator becomes
obvious during the first few weeks after implementation and during times when turnover
results in new people being trained to work with the candidate system.

Psychologist
In system development, systems are built around people. The analyst plays the role of
psychologist in the way s/he reaches people, interprets their thoughts, assesses their behaviour
and draws conclusions from these interactions. Psychologist plays a major role during the phase
of fact finding.

Introduction of Systems Development Life Cycle (SDLC)

An effective System Development Life Cycle (SDLC) should result in a high quality
system that meets customer expectations, reaches completion within time and cost
evaluations, and works effectively and efficiently in the current and planned Information
Technology infrastructure.
System Development Life Cycle (SDLC) is a conceptual model which includes policies
and procedures for developing or altering systems throughout their life cycles.
Phases of SDLC
Systems Development Life Cycle is a systematic approach which explicitly breaks down
the work into phases that are required to implement either new or modified Information
System.

Feasibility Study or Planning

 Define the problem and scope of existing system.
 Overview the new system and determine its objectives.
 Confirm project feasibility and produce the project Schedule.
  During this phase, threats, constraints, integration and security of system are
also considered.
 A feasibility report for the entire project is created at the end of this phase.
Analysis and Specification
 Gather, analyze, and validate the information.
 Define the requirements and prototypes for new system.
 Evaluate the alternatives and prioritize the requirements.
 Examine the information needs of end-user and enhances the system goal.
 A Software Requirement Specification (SRS) document, which specifies the
software, hardware, functional, and network requirements of the system is
prepared at the end of this phase.

System Design
 Includes the design of application, network, databases, user interfaces, and
system interfaces.
 Transform the SRS document into logical structure, which contains detailed and
complete set of specifications that can be implemented in a programming
language.
 Create a contingency, training, maintenance, and operation plan.
 Review the proposed design. Ensure that the final design must meet the
requirements stated in SRS document.
 Finally, prepare a design document which will be used during next phases.

Implementation
 Implement the design into source code through coding.
 Combine all the modules together into training environment that detects errors
and defects.
 A test report which contains errors is prepared through test plan that includes test
related tasks such as test case generation, testing criteria, and resource
allocation for testing.
 Integrate the information system into its environment and install the new system.

Maintenance/Support
 Include all the activities such as phone support or physical on-site support for
users that is required once the system is installing.
 Implement the changes that software might undergo over a period of time, or
implement any new requirements after the software is deployed at the customer
location.
 It also includes handling the residual errors and resolve any issues that may exist
in the system even after the testing phase.
 Maintenance and support may be needed for a longer time for large systems and
for a short time for smaller systems.
Phases of system development
Recognition of need
One must know what the problem is before it can be solved. The basis for a candidate system is
recognition of a need for improving an information system or a procedure. For eg: a supervisor
may want to investigate the system flow in purchasing or a bank president has been getting
complains about the long lines in the drive-in. This need leads to a preliminary survey or an
initial investigation to determine whether alternative systems can solve the problems. It entails
looking into the duplication of efforts, bottleneck, inefficient existing in procedures or whether
parts of the existing system would be candidates for computerization.

Problem definition
The first step in the problem solving and decision making process is to identify and define the
problem. Therefore, before a program is written for solving a problem, it is important to define the
problem clearly. For most software projects, systems analysts approach the user requirements and
define the problem that a system aims to solve. A design specification describes the program input,
output and functionality of the programs of the system. Note that the program input may be entered by
the user through any input devices or retrieved from data stores. whereas program output may be
stored, printed or displayed on screen, etc. In addition to verifying the correctness of program input,
output and functionality, it is important to ensure that any planned user-computer interactions be
approved by the users.

Factors affecting the system development –

Successful systems development means delivering a system that meets user and organisational
needs–on time and within budget. There is no formula for achieving this, but the following factors are
known to have impact on success:

Involvement–getting users and other stakeholders involved in systems development is critical for most
systems development projects. Having the support of top-level managers is also important. The
involvement of users throughout the development will mean they are less likely to resist the software
when it is delivered.

Degree of Change–a major factor that affects the quality of systems development is the degree of
change associated with the project. The scope can vary from implementing minor enhancements to an
existing system, up to major reengineering. The project team needs to recognise where they are on this
spectrum of change.

Managing Change–the ability to manage change is critical to the success of systems development. New
systems inevitably cause change. Unfortunately, not everyone adopts easily, and the increasing complexity
of systems can multiply the problems. Managing change requires the ability to recognize existing or
potential problems and deal with them before they become a serious threat to the success of the new or
modified system. Here are some of the most common problems:

Fear that the employee will lose his or her job, power or influence within the organization

Belief that the proposed system will create more work than it eliminates.

Reluctance to work with “computer people”

Anxiety that the proposed system will negatively alter the structure of the organization

Belief that other problems are more pressing than those solved by the proposed system or that the
system is being developed by people unfamiliar with “the way things need to get done”

Unwillingness to learn new procedures or approaches.

SDLC Models : Waterfall Model –

The Waterfall Model was the first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model. It is very simple to understand and use

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 this Waterfall model, typically,
the outcome of one phase acts as the input for the next phase sequentially.
The following illustration is a representation of the different phases of the Waterfall
Model.
  Requirement Gathering and analysis − All possible requirements of the system
to be developed are captured in this phase and documented in a requirement
specification document.
 System Design − The requirement specifications from first phase are studied in
this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture.
 Implementation − With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next phase.
Each unit is developed and tested for its functionality, which is referred to as Unit
Testing.
 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.

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 phase 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
The Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and the final
design in the subsequent spirals.
Construct or Build
The 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
feedback.
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 the customer for feedback.
Evaluation and Risk Analysis
Risk Analysis includes identifying, estimating and monitoring the 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.
The following illustration is a representation of the Spiral Model, listing the activities in
each phase.
Based on the customer evaluation, the software development process enters 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.
The advantages of the Spiral SDLC Model are as follows −
 Changing requirements can be accommodated.
 Allows extensive use of prototypes.
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in better risk management.
The disadvantages of the Spiral SDLC Model are as follows −
 Management is more complex.
 End of the project may not be known early.
 Not suitable for small or low risk projects and could be expensive for small
projects.
 Process is complex
 Spiral may go on indefinitely.
  Large number of intermediate stages requires excessive documentation.

RAD (Rapid Application Development) model –

The RAD (Rapid Application Development) model is based on prototyping and
iterative development with no specific planning involved. The process of writing the
software itself involves the planning required for developing the product.

Rapid application development 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 the 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.

RAD Model Design

RAD model distributes the analysis, design, build and test phases into a series of short,
iterative development cycles.
Following are the various phases of the RAD Model −
Business Modelling
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 Modelling
The information gathered in the Business Modelling 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 Modelling
The data object sets defined in the Data Modelling 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 the 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.
The following illustration describes the RAD Model in detail.

Prototyping Model –
Prototyping is defined as the process of developing a working replication of a
product or system that has to be engineered. It offers a small scale facsimile of
the end product and is used for obtaining customer feedback as described
below:
The Prototyping Model is one of the most popularly used Software Development
Life Cycle Models (SDLC models). This model is used when the customers do
not know the exact project requirements beforehand. In this model, a prototype
of the end product is first developed, tested and refined as per customer
feedback repeatedly till a final acceptable prototype is achieved which forms the
basis for developing the final product.
In this process model, the system is partially implemented before or during the
analysis phase thereby giving the customers an opportunity to see the product
early in the life cycle. The process starts by interviewing the customers and
developing the incomplete high-level paper model. This document is used to
build the initial prototype supporting only the basic functionality as desired by
the customer. Once the customer figures out the problems, the prototype is
further refined to eliminate them. The process continues until the user approves
the prototype and finds the working model to be satisfactory.
There are four types of models available:

A) Rapid Throwaway Prototyping –

This technique offers a useful method of exploring ideas and getting customer
feedback for each of them. In this method, a developed prototype need not
necessarily be a part of the ultimately accepted prototype. Customer feedback
helps in preventing unnecessary design faults and hence, the final prototype
developed is of better quality.
B) Evolutionary Prototyping –
In this method, the prototype developed initially is incrementally refined on the
basis of customer feedback till it finally gets accepted. In comparison to Rapid
Throwaway Prototyping, it offers a better approach which saves time as well as
effort. This is because developing a prototype from scratch for every iteration of
the process can sometimes be very frustrating for the developers.

C) Incremental Prototyping – In this type of incremental Prototyping, the final

expected product is broken into different small pieces of prototypes and being
developed individually. In the end, when all individual pieces are properly
developed, then the different prototypes are collectively merged into a single
final product in their predefined order. It’s a very efficient approach that reduces
the complexity of the development process, where the goal is divided into sub-
parts and each sub-part is developed individually. The time interval between the
project’s beginning and final delivery is substantially reduced because all parts
of the system are prototyped and tested simultaneously. Of course, there might
be the possibility that the pieces just do not fit together due to some lack of
ness in the development phase – this can only be fixed by careful and complete
plotting of the entire system before prototyping starts.

D) Extreme Prototyping – This method is mainly used for web development. It

is consists of three sequential independent phases:
D.1) In this phase a basic prototype with all the existing static pages are
presented in the HTML format.
D.2) In the 2nd phase, Functional screens are made with a simulated data
process using a prototype services layer.
D.3) This is the final step where all the services are implemented and
associated with the final prototype.