Software Development Process Assignment

SOFTWARE QUALITY
1. Meet customer requirements in terms of functionality
2. Meet customer expectations in terms of performance, reusability,
compatibility
3. Cost to purchase by customers
4. Time to release by development organization
SOFTWARE DEVEOPMENT PROCESS
Requirements gathering
Analysis and planning
Design (Logical representation)
Coding (Physical representation)
Testing
Release and Maintenance
SOFTWARE DEVELOPMENT PROCESS MODELS
1. Waterfall Model (Requirements are clear)
2. Prototype Model (Requirements are ambiguous (Confusion))
3. Spiral Model (Requirements are enhancing)
4. Agile Model (Requirements are changing)
Waterfall Model: Requirements are clear and constant

Prototype Model: Requirements are ambiguity, the software organization is
developing sample model first and then go to real
software.
Spiral Model: When the requirements are enhancing e.g. eseva
Agile Model: When the customer requirements are suddenly changing. E.g.
Mobile Application
Note 1:
All software development models are derived from waterfall model
(Linear sequential model)
Note 2:
Above all software development process models are maintaining
single stage of testing and that stage is conducting by same development
people.
Testing is of two types they are SQA & SQC
Software Quality Assurance (SQA) The monitoring and
measuring the strength of development process is called SQA
Software Quality Control (SQC) The validation of software
product w.r.t customer requirements and expectations.

FISH MODEL
(Multiple stages of development and testing)
Analysis Design Coding
Maintenance
BRS SRS HLD & LLD system testing
Test Software changes
Real Time Terms of System Testing
BRS:
Business requirement specification is defining the requirements of the
customer to be developed as new software. This document is also known as
customer requirement specification (CRS) and user requirement specification
(URS)
SRS:
Software requirement specification is defining functional
requirements to be developed and system requirements to be used
(converting non-technical information in to technical information. Derived
from BRS). E.g. Bank deposit = addition (Functional requirements) + some
languages (System requirements)
Review:

The completeness and correctness of a document is estimating
by responsible people through reviews. E.g. walk through (study from first
line to last line of document), inspections (searching for a particular issue),
and peer reviews (comparing with other documents)
Design:
HLD:
High-level design document defines the overall architecture of system
from root module (e.g. login) to leaf module (e.g. logout). This document is
also known as architecture design or external design.
LLD:
Low-level design document defines the internal architecture of
corresponding module of functionality. This document is also known as
internal design documents. E.g. Website like yahoo.
Prototype:
A sample model of software is called prototype. It consists of
interface (screens) without having functionality.
Program:
It indicates a set of executable statements, some statements in
program are taking inputs, some statements are performing process and
other statements are displaying output.
Module (unit) is a combination of programs and the software is a combination
of modules.
White Box Testing Techniques:
These are program based testing
techniques. These techniques are also known as glass box testing (or)
open box testing. The responsible people are using these techniques to
verify internal structure of corresponding program.
System Testing: