System Analysis and Design

System Analysis is a process of collecting and interpreting facts, identifying the

problems, and decomposition of a system into its components.
System Design is a process of planning a new business system or replacing an
existing system by defining its components or modules to satisfy the specific
requirements.
System Development Life Cycle
Software Development Life Cycle (SDLC) is a process used by the software
industry to design, develop and test high quality software. The SDLC aims to
produce a high-quality software that meets or exceeds customer expectations,
reaches completion within times and cost estimates. SDLC includes a detailed
plan for how to develop, alter, maintain, and replace a software system.
How does it work?
Software Development Life Cycle (SDLC) works by lowering the cost of
software development while simultaneously improving quality and shortening
production time. SDLC achieves these apparently divergent goals by
following a plan that removes the typical pitfalls to software development
projects. That plan starts by evaluating existing systems for deficiencies.
Next, it defines the requirements of the new system. It then creates
the software through the stages of design, development, testing, and
deployment. By anticipating costly mistakes like failing to ask the end user
for suggestions, SDLC can eliminate redundant re work and after-the-fact fixes.
Stages of SDLC
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.
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 an SRS (Software Requirement Specification) document which
consists of all the product requirements to be designed and developed
during the project life cycle.
3. Designing Product- SRS is a reference for software designers to come
out with the best design for the software. Hence, with the requirements
defined in SRS, multiple designs for the product architecture are present
in the Design Document Specification (DDS). This DDS is assessed by
market analysts and stakeholders. After evaluating all the possible
factors, the most practical and logical design is chosen for the
development.
4. Building\Developing 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 hassle.
Some popular languages like C/C++, Python, Java, etc. are put into use as
per the software regulations.
5. Product Testing and Integration - After the development of the
product, testing of the software is necessary to ensure its smooth
execution. Although, minimal testing is conducted at every stage of
SDLC. Therefore, at this stage, all the probable flaws are tracked, fixed,
and retested. This ensures that the product confronts the quality
requirements of SRS.
6. Deployment and Maintenance of Product - After detailed testing, the
conclusive product is released in phases as per the organization’s
strategy. Then it is tested in a real industrial environment. Because it is
 important to ensure its smooth performance. If it performs well, the
organization sends out the product as a whole. After retrieving beneficial
feedback, the company releases it as it is or with auxiliary improvements
to make it further helpful for the customers.

SDLC Models
The most common SDLC models are:
1. Waterfall Model - It is the first sequential-linear model because the
output of the one stage is the input of the next stage. It is simple and easy
to understand, which is used for a small project. The various phases of the
waterfall model are as follows:
a. Requirement analysis
b. Feasibility study
c. Design
d. Coding
e. Testing
f. Installation
g. Maintenance
2. Iterative Model - This model leads the software development process in
iterations. It projects the process of development in cyclic manner
repeating every step after every cycle of SDLC process.
Iterative development is a way of breaking down the software
development of a large application into smaller pieces.
3. Spiral Model - This model considers risk, which often goes un-noticed
by most other models. The model starts with determining objectives and
constraints of the software at the start of one iteration. Next phase is of
prototyping the software. This includes risk analysis. Then one standard
SDLC model is used to build the software. In the fourth phase of the plan
of next iteration is prepared.
4. Verification & Validation Model - It is an extended version of the
waterfall model. It will implement in two phases wherein the first phase,
we will perform the verification process, and when the application is
ready, we will perform the validation process. In this model, the
implementation happens in the V shape, which means that the verification
process done under downward flow and the validation process complete
in the upward flow.
 5. RAD Model - A software project can be implemented using this model if
the project can be broken down into small modules wherein each module
can be assigned independently to separate teams. These modules can
finally be combined to form the final product.
6. Hybrid Model - The hybrid model is used when we need to acquire the
properties of two models in the single model. This model is suitable for
small, medium, and large projects because it is easy to apply, understand.
Benefits of SDLC

 Gives a defined view of the entire system, resources, timeline, and goals
 Design reviews help to ensure the reliability and quality of the final
product
 Enhanced control over large or complex projects
 Involves comprehensive and explicit steps
 Provide goals and deliverables that meet the standards of each party
involved in the project, requires keeping detailed documentation
throughout the entire process
 Easy evaluation of costs and growth of the developed system

Disadvantages of SDLC

 Increased development time and cost

 System details should be specified beforehand
 The volume of documentation increases with time
 Inflexibility when it comes to changes
 Outdated processes

Requirements Determination

Requirement describe the 'what' of a system not the "how". Requirement

analysis bridges the gap between system level requirements and software
design. Requirement analysis allows the system analyst to refine the software
allocation and build models of the data, functional and behavioural domains that
will be treated by software. The process of requirement analysis also helps to
bridge the communication gap between the customer and the developer.

System Design
System Design is the process of designing the architecture, components, and
interfaces for a system so that it meets the end-user requirements.

Types of System Design are:

 Physical Design - Physical design relates to the actual input and output
processes of the system. It focuses on how data is entered into a system,
verified, processed, and displayed as output.
 Logical Design - Logical design relates to an abstract representation of
the data flow, inputs, and outputs of the system. It describes the inputs
(sources), outputs (destinations), databases (data stores), procedures (data
flows) all in a format that meets the user requirements.

Test Planning

A system is tested for a line response, volume of transactions, stress, recovery

from failures and usability. System testing requires a test plan that consist of
several key activities and steps for program, string, system and user acceptance
testing.

A test plan consists of following activities:

1. Prepare a test plan

2. Specify conditions for user acceptance testing
3. Prepare Test data for Program Testing
4. Prepare test data for Transaction Path Testing
5. Plan User Training
6. Compile/Assemble Programs
7. Prepare Job Performance Aids
8. Prepare Operational Documents

Communication

Communication is the process of sharing the ideas, information, view from one
party to another party.
Interviewing

Interview is a conversation between two or more people where questions are

asked by the interviewer to obtain information from the interviewee. The
interview method of collecting data involves presentation of oral-verbal stimuli.

Presentation Skills

A presentation is a fast and potentially effective method of getting things done

through other people. In managing any project, presentations are used as a
formal method for bringing people together to plan, monitor and review its
process. It allows you to ask questions and to initiate discussion.

Risk Analysis

The main objective of risk analysis is to identify all possible risk and document
a plan to counter the risk in case of unlikely event occurring. When an
undesirable event occurs, it might be too late to counter the consequences unless
adequate planning has been done to mitigate the risk.

The types of Risk are:

1. Manpower Risk
2. Technology
a. Using New Technology
b. Using Outdated Technology
3. Business Risk

Feasibility Study
Feasibility Study in Software Engineering is a study to evaluate feasibility of
proposed project or system. Feasibility study is carried out based on many
purposes to analyze whether software product will be right in terms of
development, implantation, contribution of project to the organization etc.

Types of Feasibility Studies

 Technical - Engineers ask whether the correct technology exists to

develop a project.
 Economic - They look at costs and benefits.
 Legal - They look at any barriers to legal implementation, for instance,
privacy issues or safety concerns.
 Operational - They look at how systems can be maintained after being
built.
 Schedule - They look at chronology for a project.
In general, a feasibility study should cover all of the salient points on whether a
project is reasonable, and should have documentation related to any concerns.

Joint Application Development

JAD (Joint Application Development) is a software development approach
which engages the client and/or the end users for designing and developing the
system. As compared to other primitive SDLC model, Joint Application
Development model leads to faster progression of the system development
which has better client approval.

This model furthermore, is vast when it comes to agile delivery wherein the
software products need to be developed as well as shipped in short iterations
depending on agreements among the industrial as well as industry stakeholders
which are termed as Minimum Viable Product (MVP).

JAD Participants

The people involved in a JAD session are typically:

 Facilitator - The facilitator is the person who conducts or moderates the
meeting.  This person should not be an expert in systems development. 
  Scribe - The scribe is the person who can formally document everything
that happens in the JAD.  This person needs to have a strong knowledge
of software development.
 Customers - Customers are the primary group who will discuss the
requirements of the system as well as the scope and boundaries of the
project. 
 Developer - Developers should be present at the JAD, but not as drivers
of the session.  A developer’s role at a JAD is to listen and gather
information.

Phases of JAD Model

1. Define Specific Objectives: The facilitator, in partnership with

stakeholders, set all the objectives as well as a list of items which is then
distributed to other developers and participants to understand and review.
This objective contains elements like the scope of this projected system,
its potential outcome, technical specification required, etc.
2. Session Preparation: The facilitator is solely responsible for this
preparation where all relevant data is collected and sent to other members
before time. For better insight, research carried out to know about the
system requirement better and gather all the necessary information for
development.
3. Session Conduct: Here the facilitator is accountable to identify those
issues which have to be working out for making the system error-free.
4. Documentation: After the product is developed, the records and
published documents are put forward into the meeting so that the
stakeholders and consumers can approve it through the meeting.

Benefits of JAD

 Improved Delivery Time: The time required for developing a product

using JAD model is lesser and efficient than that of other traditional
models.
 Cost Reduction: Efficiently analyzing the requirements and facts with
business executives and stakeholders will make less effort to develop the
system and hence less cost will be required for the entire development
process.
  Better Understanding: Since the entire requirement is analyzed by
business executives, followed by a cautious choice of developers and
team member who can professionally interact with each other better
usually helps in understanding the product development better.
 Improved Quality: Since all the key decision makers and stakeholders of
the project are involved in the development of the project so there is the
least chance of error and hence the product quality becomes better and
more accurate.

Drawbacks of JAD

 Time Commitment - Depending on the size of the project, a JAD may

require a significant time commitment. All JAD participants must be able
to meet at the designated times and will need to suspend all other
activities for these periods.
 JAD Commitment - The organization must have a clear understanding
of the approach and guidelines of a JAD. A JAD can only produce
effective and productive results if the organization is firmly committed to
this approach.

Structure Walkthrough

A structured walkthrough, a static testing technique performed in an organized

manner between a group of peers to review and discuss the technical aspects of
software development process. The main objective in a structured walkthrough
is to find defects in order to improve the quality of the product.
Structured walkthroughs are usually NOT used for technical discussions or to
discuss the solutions for the issues found. As explained, the aim is to detect
error and not to correct errors. When the walkthrough is finished, the author of
the output is responsible for fixing the issues.

Code Walkthrough

Code Walkthrough is a form of peer review in which a programmer leads the

review process and the other team members ask questions and spot possible
errors against development standards and other issues.
Code Review

Code Review is a systematic examination, which can find and remove the
vulnerabilities in the code such as memory leaks and buffer overflows.

Design Review

A design review is a milestone within a product development process whereby a

design is evaluated against its requirements in order to verify the outcomes of
previous activities and identify issues before committing to - and if need to be
re-prioritise - further work because if errors are made during the design process,
they will ultimately reflect themselves in the code and final system.

Code walkthrough is informal process where code is executed at any time.

Author of code leads the code walkthrough. Code review is formal process
where review is done line by line in the formal meeting of developers and
QA engineers.

Prototyping

Prototyping is an experimental process where design teams implement ideas

into tangible forms from paper to digital. Teams build prototypes of varying
degrees of fidelity to capture design concepts and test on users. With prototypes,
you can refine and validate your designs so your brand can release the right
products.

Database Design

Database Design is a collection of processes that facilitate the designing,

development, implementation and maintenance of enterprise data management
systems. Properly designed database are easy to maintain, improves data
consistency and are cost effective in terms of disk storage space. The database
designer decides how the data elements correlate and what data must be stored.

The main objectives of database designing are to produce logical and physical
designs models of the proposed database system.
The logical model concentrates on the data requirements and the data to be
stored independent of physical considerations. It does not concern itself with
how the data will be stored or where it will be stored physically.

The physical data design model involves translating the logical design of the
database onto physical media using hardware resources and software systems
such as database management systems (DBMS).

Objectives of Database Design are:

1. Controlled Redundancy
2. Ease of Learning and use
3. Data Independence etc.

Software Metrics

A software metric is a measure of software characteristics which are measurable

or countable. Software metrics are valuable for many reasons, including
measuring software performance, planning work items, measuring productivity,
and many other uses.

Software metrics can be classified into three categories −

 Product metrics − Describes the characteristics of the product such as
size, complexity, design features, performance, and quality level.
 Process metrics − These characteristics can be used to improve the
development and maintenance activities of the software.
 Project metrics − This metrics describe the project characteristics and
execution. Examples include the number of software developers, the
staffing pattern over the life cycle of the software, cost, schedule, and
productivity.

Software quality metrics are a subset of software metrics that focus on the
quality aspects of the product, process, and project. These are more closely
associated with process and product metrics than with project metrics.

Need of Software Quality Metrics

 1. To define and categorize elements in order to have better understanding
of each and every process and attribute.
2. To evaluate and assess each of these process and attribute against the
given requirements and specifications.
3. Predicting and planning the next move w.r.t software and business
requirements.
4. Improving the Overall quality of the process and product, and
subsequently of project.

Features of good Software Quality Metrics

 Should be specific to measure the particular attribute or an attribute of

greater importance.
 Comprehensive for wide variety of scenarios.
 Should not consider attributes that have already been measured by some
other metric.
 Reliable to work similarly in all conditions.
 Should be easy and simple to understand and operate.

Criteria for Software Collection

1. Reliability
2. Functionality
 3. Capacity
4. Flexibility
5. Security
6. Performance
7. Cost etc.

Software Evaluation
Sources for Evaluation are:
1. Benchmark Programs (Minimum Hardware Configuration, Testing etc/)
2. Experience to other users (Satisfied or not)
3. Product Reference Module (System Capabilities)