Chapters:

1. Software development life cycle

2. Requirement analysis (srs document)
3. Software project management
4. Software design
5. Coding and testing
6. maintainance
7. Quality management and reuse

Software engineering:

It is a systematic, cost-effective technique for software development. Step by step systematic approach.

Software development life Cycle:

it is a process to design, develop and test high quality softwares.

Stages of SDLC:
Planning

Deploy/ Defining/Analysis
Maintainance (SRS)

Testing Designing

Coding/
Implementation/
Building
Models of Software development life Cycle:
 Classical waterfall model:
Useful for small projects and requirements are fixed bcz we don’t have feedback during developing
phase so we cannot change it during developing if passed to next phase. When one phase complete
then other phase starts.
Steps:
 Feasibility study (achieveable or not)
 Requirement analysis and specification
 Designing Phase
 Coding and unit testing
 system testing and integration
 Maintainance(60 % efforts bcz bugs did not removed during developing)
 Advantages:
Base model, simple and easy, small projects
Disadvantages:
No feedback, NO Experiment, high risk, one team work at one time other wait for its phase.

 Iterative waterfall model:

In classical waterfall their was not any feedback system but in iterative feedback exist, if any error
occur in any stage then he can give feedback to previous stages so error should be removed.
Feedback is not given to feasibility study if requirement of user taken then cannot be changed.
Other than feedback rest of the other same.
There is no prototype in this model so user’s handles changes after complete project, bugs handle
after the project completion.
 Prototyping model: after customer evaluation if error occur in any phase then after taking feedback can move to prev
phase, feedback importand
 Customers not clear with idea
 Through away a model
 Good for technical and requirement risk
 Increase in cost of development
Information gether

Quick
Design

Refinement suggestion Build prototype Prototype Building Phase

incorporation

Customer
evaluation

Design
Iterative development with feedback

implement

Test

Maintain
  Evolutionary model: incremental + iteration

It is combination of iteration and incremental model.

We deliver some portion of software to customer. We take customer feedback and other stack
holder, if any error occur or requirement change then handle that errors.

Advantages:
Customer requirements are clearly described.
Better risk analysis and support changing environment
Better for long term projects
Disadvantage:
Cost, highly skill required, no suitable for small projects.

 Spiral Model: ( risk analysis):

 Object determination and identify alternative solutions.
 Identify and resolve the risk.
 Develop the next version of the product
 Review and plan for next phase
 All these steps will repeat until customer don’t satisfied.
 Cost directly proportional to the radius of circle

Important points:
Risk handeling, as these 4 task repeat the cost increase, it is also called meta model bcz it uses features of
all other model, use for large projects. It needs too much risk analysis which needs expert team.
  Big bang model:

 V-model:
Known as verification and validation model.
Verification means step by step, component by component check whether it is correct or not, in
validation we check the whole product.
It is the extension of waterfall. We do testing at every phase. Testing run parallel with each phase.
In design first we design the whole project in a big picture then we design the each module of
project. Then we design the sub modules.

Concept of Operation and

verification and maintenance
operation
validation

System verification
Requirements
and validation
and architecture
Project
Defination
Integration,test Project testing and
and verification integration
Detailed
design

Implementation or
Coding
 Time

Advantage:
Time saving, good project understand at beginning, every component is testable, progress tracked
easily, proactive test tracking (test before complete project)
Disadvantage:
No feedback, so less scope of changes, risk analysis not done, not good for big or object oriented
projects.

 Agile model: (Latest model in this era)

Agile means move quickly.
It is an iterative and incremental approach that emphasise flexibility, collaboration and rapid
delivery.
 We break project into small chunks(parts/iteration).
 We work it on parallel
 Release product in market
 Customer feedback
 Enhance project according to feedback
 Re-release the project.
 We do communication with customer on regular basis and don’t focus on documentation.
 Accept changes and focus on client requirement/feedback
 Documentation at end
Advantage:
Face to face communication with client, changes adopt quickly, less time
Disadvantages:
Less documentation, maintainance problem(face difficulty bcz we don’t do documentation)

Agile Methodologies:
I. SCRUM:
 It is a light weigth, iterative and incremental framework.
 it breakdown the development phases into stages or cycles known as sprints.
 Time is important bond, sprint is time ond
 The development time for each sprint is maximized and dedicatd.(manage one sprint at a
time)
 Scrum master communicate with customer on daily basis.
 Backlock is project planning, daily scrum meeting with team and customer, scrum master
head of team that communicate with client
 sprintBacklog:
 project Backlog:
Advantages:
Freedom & Advantages, high quality, low risk, reduce development time, customer satisfaction is important, review
current sprint before moving to next one. Work with small teams. No hierarical system
Disadvantages:
 More efficient for small team size, no change in sprint, can be change after review the product.

Kanban:
Lean:
Extreme programming (XP):

 Rapid application development(RAD):

Used when Limited time and cost, it used multiple models of sdlc.
Client involvement in each phase
 Quick prototyping
 Iterative development
 Incremental release
 User involvement
 Time-boxing
 Parallel development

Team 1: business modeling => Data modeling => process modeling => Application modeling => Testing & turnover
Team 2: business modeling => Data modeling => process modeling => Application modeling => Testing & turnover
Team 1: business modeling => Data modeling => process modeling => Application modeling => Testing & turnover
business modeling => Data modeling => process modeling => Application modeling => Testing & turnover

 Incremental Model:
We design module by module, divide whole project into different parts.1st complete one module
deliver to customer then go on further modules.
Then add all module to make final project. Feedback at every module and steps

Like LMS of school, teacher, student and administration have different modules, we bulid them one
by one then combine to make a final project.

Module 1
Dev and testing implement
design

Requirements Module 2
Dev and testing Implement
design

Module 3 Dev and testing Implement

design
  Module by module working (work on each module seperately)
 Maximum customer attraction
 For large projects
 Flexible to
 Early release product demand( a part of project)

Software requirements & specifications: (Communication is the key)

 Experience gather system requirements and called system analyst

 It is the description what the system should do.
 Requirement engineering process of defining, documentation and maintaining requirement
in engineering process.
 It is a four steps process:
i. Feasibility: (think nothing is impossible, and gather all info and think is it possible).
Feasible in cost vice, time vice, possible to create
ii. Requirements Gathering/Elicitation: gather info from client, users and stack holders
and do brain storming about projects.
iii. Software requirement specifications. (SRS document)
iv. Software requirement validation: check and verify all details before signing the SRS
document
v. Software management tool to manage all this project. (may include zoom, google
meet)

 Requirement gathering steps:

 Communication/meet
 Group discussion from both sides
 Delphi technique (written discussion if introvert, iterative nature)(questionaire)
 Collaborative workshop
 Quality function deployment (high priroty functions)(v. important, just important not
important)
 Role play as different user
 Use case approach (visual / graphical representations)
 Requirement analysis:
 Flow Chart to analyse control flow
 Data flow diagram
 Tools for requirement engineering:
 Observation reports (user observation)
 Questionnaire (interviews, surveys and pools)
 Use cases (already rules of physical business converts into digital)
 User stories
 Requirements workshop
 Mind mapping (diagram to convert our idea into graphs)
 Role playing
 prototyping
Questions during gathering the information:
 what is the problem
 why is it important to resolve the problem
 what are the possible ways to solve the problem
 What exactly are the data input to the system and what exactly are the data output by the system?
 What are the likely complexities that might arise while solving the problem?

 If there are external software or hardware with which the developed software has to interface, then what exactly would
the data interchange formats with the external system be?
 The most important requirements problems that the analyst has to identify and eliminate are the problems of
anomalies, inconsistencies, and incompleteness. And these are resolved in SRS.

Parts of SRS Document:

 Functional requirement of the system
 Non-function requirement of the system
 Goals of implementation

Functional requirements: (mendatory)

Working areas of web like fetching, conversion of input into output, display of data, what we are
taking as input and which output is required.
Non Functional requirements: (desired functionality but not mendatory) expected charactristics in project, (security
check, storage BD, configuration, cost effective), we talk about user experince
Goals of implementation:
The goals of implementation part documents some general suggestions regarding development. These suggestions
guide trade-off among design goals. The goals of implementation section might document issues such as revisions to
the system functionalities that may be required in the future, new devices to be supported in the future, reusability
issues, etc.

Software requirement specification (SRS): (IEEE 830 is the world srs documentation standard)
Description of software that we are going to develop before coding purpose. It includes functional and
non functional requirements of a software projects. It describe the use cases (situations) that describe user
interaction.

SRS Structure:
 Introduction
 Purpose
 Intended audience
 Scope
 Definitions
 Reference
 Overall description:
 User interfaces
 System interfaces
 Constraints, assumptions and dependencies
 User Charactristics
 System features and requirements:
 Functional requirements
 Use cases
 External interface requirements
 Logical database requirements
  Non functional requirements
 Deliver for approval of client:

User Requirements:
 Easy and simple to operate
 Quick response
 Effectively handling operational errors
 Customer support

User requirement Specification: (URD user requirement document)

The user requirement document usually used in software engineering that specifies what the user expects the
software to be able to do.
It is a contractual agreement.
Client cannot be able to take extra feature other than URD, and developer have to complete all the features that are
mentioned in URD.

Data flow diagram (DFD): (also known as bubble chart)

 A graphical tool for communicating with users managers and other personels.
 Useful for analyzing existing as well as proposed systems
 A relatively simple technique to learn and use
 Focus on the movement of data between external entities and process, and between process and data stores
 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.

Why dfd?
It provides an overview of
 What data a system processes
 What transformations are performed
 What data are stored
 What results are produced
 Communication tool bw User and analyst
 Communication tool bw Analyst and system designer
DFD Elements:
 Source/Sinks (external entity) represent with rectangle
 Data flow represent with arrow and data flow written on arrow
 Process (fn) represent with circle
 DataBase represent with two parallel lines in horizontal
Source: from which we receive data
Sink: to which we are giving data

Types of data that can flow:

It flow from:
 External entity to process
  Process to external entity
 Process to store and back
 Process to process
Data that cannot flow:
 External entity to external entity
 External entity to store
 Store to external entity
 Store to store
Decomposition of DFD:
 A system is too big to show on a single DFD
 Decomposition is the iterative process of exploding data flow diagrams to create more details.

 Level 0: DFD means a whole big diagram of project, show less detail, only show full project working.
Example: user requesting admission, then it get admission as response from admin. It does not
describe how?

User System User2

 Level 1: Contains more detail of each module, as that module is further divided. In level 1 user and
response described in more detailed, in module vice.
Example:
User fill form that stored in db, then took test whose data also stored in DB, maintain student info &
data, generate report, admin check, admin send response, user get response from admin in the form
of accepted not not.

User P1 P2 User

P3
 Level 2: now each module divide into sub module, test module will be elaborated in separate graph,
similarly other modules.

More detailed chat that explains each process by dividing it into several parts

DFD of School Management system:

Level 0:

Level 1:

Level 2:
 Logical and physical DFD:
 In logical we talk about what we are actually trying to do, in physical we talk about implementation
who is going to use that software
 Logical DFD: concentrates on the system process and flow of data in the system. For example
in a Banking software system, how data is moved between different entities.
 Physical DFD: shows how the data flow is actually implemented in the system. It is more
specific and close to the implementation.

Data Dictionary: (list of all data items in dictionary)

 Name of items
 Aliases names
 Description
 Range of data values.

ER Diagram for requirement analysis:

We use to make graphical relationship of whole project’s entities relations.
Use Decision table for project requirements analysis:
If this and this condition is true then we have to to do this. If c2 and c3 true then we
do A2
 Choice1 choice2 choice3
Conditions:
C1
C2
C3
Actions:
A1
A2

Software design approaches:

1) function oriented design: see project as function and divide into small function and combine for big
 system is designed from a functional view point.
 Top-down decomposition
 Divide and conquer approaches
 DFD is used
2) Object oriented design:
 System is viewed as collection of objects
 Bottom up approaches
 UML is used
Software Project management:
 It is an art and science of planning and leading projects.
 Main goal is to enable a group of developers to work effectively towards successful completion of
projects.

Software Quality Attributes:

 Correctness as per user requirement
 Useability: ease to use
 Reliablity: if any error occur should be solve in quick
 Efficiency: best use of resources
 Maintainability: Ease of modification
 Scailability: can be scaled if is going to successed
 Profitablility: Operating on different environment
 Security: Protection is important
 Reuseability: part of one component can be use to another component
 Modularity: Dividing a thing into multiple modules
Capability Maturity Model: (CMM)
Improve or enhance software process to get optimal quality.

Maturity Levels in CMM:

1. Initial:
 Inconsistent
 Unpredictable
 uncontrolable
2. Repeatable
 Consistent
 Repeat
 Experience
 Similar task
 Realistic
 Non-documented
3. Defined
 Documented
  Standardized
 Integrated
 Risk management
4. Optimize managed
 Quantitative management
 Predictable (budget, time)

Software Design:
after SRS we make SDD software design document.
 Interface design:
Interaction between system and environment, internal system is ignored and we
focus just input of the system and the output of the system regardless what is
happening inside the software
 Architecture design:
Components of system:
 Their interfaces & responsibilities.
 Interaction between them
 Internal of components are ignored
 Detailed design:
 Focus on components internal design in details
 Internal DSA of component

Charactristics of good software design:

 Mush have all client requirements according to SRS
 Free from conflicts, ambiguity and incompleteness
 Explain each feature

Modularity in Software design:

We divide functionalities and make them modules which contains some
charactristics.

Approaches in system design:

 Top-down approach
 Bottom-up approach
Top-down approach:

 Use divide and conquer approach

 You need to have entire problem requirements
 Small or medium size projects
 Do decomposition of whole project
 Bottom up design approach:
 At initial level no need to have understanding of entire software project
 Start from low level functional modules
 Do composition/merging
 Like we do study for exam in last night

Estimation:
Project planning process:
 Beore development
 Focus on activities requirements for successful completion of the project
In this we do estimation of:
 Size of project
 Cost
 Time/Duration
 Effort
Cost estimation depends on:
 Size of software
 Hardwares we use
 Tools and licences
 Skilled personal
 Travel & communication
 Training & Support

Software Testing:
 Use to find bugs/errors/faults in the software
 With minimum resources, times and bugs we can identify maximum bugs.

Verification vs Validation:

Verification:
 In verification we prevent errors during production
 Phase by phase verification
 Done by developer
 Includes unit testing, integration testing and reviews
  Static nature
Validations:
 detect errors
 do on final product
 by testers
 includes white box testing and black box testing
 dynamic nature

Principle of software testing:

 identify as many bugs as possibles
 easrly testing save your resources
 start with a proper test plan
 as per user requirement
 focus more on heavy bugs areas
 go for functional and non-functional testing

Unit/Module testing:
Do testing of Each source
Integration testing:
 incremental testing (top to down & bottom-up integrated test)
 non-incremental testing (Big bang)=> combine all unit tested modules then test
whole project.

System Testing:
 test of whole complete system
 don’t focus on internal work
 focus on input and output
 black box testing
 verify the overall functionality of the system
 do alpha testing(test by developer), beta testing (other stack holders do testing)
 we also do non-functional testing like: performance testing, load testing, stress
testing,scalability testing etc.

White box Testing:

 transparent and structural testing
 focus on internal structure testing
 applied on unit and integration level testing
  Techniques in unit testing: statement coverage, branch coverage, data flow coverage,
path coverage
 Tools: sql map, Nunit,vera unit

Black box Testing:

 Focus on input and output
 Internal code and structure is ignored
 No programming language
 Tools: selenium, applitools, appium
Software maintainance:
 Cover more time in maintainance
 Update , bug fix, optimization, light weigth
 Do not change core function while updation
CPM:
Shortest path to perform a task.
Risk Management:
It is an uncertain event or condition that if occurs has a positive or negative effect on a
project objectives.
Risk management plan is a document that a project manager prepares to foresee risks,
estimate impacts and define responses to risks.
Risk Assessment:
rank the risk in term of damage, determine the probability of risk
 Identification
 Analysing
 Priortize risk => RA=severity(danger) X probability of risk
Risk Controlling:
Action to reduce the risk event probability of happen
 Planning
 Monitoring
 Resolution of the problem

Risk mitigation:
Reduce the impact of risk event
Types of risk:
 Budget
 Time risk
 Technical risk
 Operational risk
 Business risk
Risk control/mitigration strategy:
 Risk avoidance
 Risk transfer
 Risk reduction
 Risk monitoring
Risk assessment strategy:
1)Proactive: plan before any event to avoid risk
2)Reactive: make plan to face event if any bad event happen

Project estimation techniques:(planning phase)

The different parameters of project
 Project size
 Effort required to complete the project
 Project duration
 Project cost
Classification of estimation techniques:
 Empericl estimation
 Heuristic estimation
 Analytical estimation

 Empericl estimation:
Common sense and educated guess
Prior experience of similar projects
Expert judgement techniques
Delphi cost estimation
 Heuristic estimation
 Cocomo model(constructive cost model)
Estimate on line on codes or number of functions
Three modes of cocomo model:
 Organic
Small size project with experience team
 Semi-detached: medium size project
 Embedded: large project

Person month(pm): unit to calculate person’s effort to develop software, calculated

with graph, axis includes time and number of person
Basic COCOMO:
it computes software development effort, time and cost as a function f pogram size.
Formula:
Effort=a1 X ( KLOC )power a2 PM => vlues are fixed
Tdev =b1 X (EFFORT) power b2 Months

KLOC= kilo line of codes

30000 lines= 30KLOC

Formula to calculate staff size:

Average staff size = E/D Persons e=effort, D= development size

When projet size is known the productivity level may be calculated as:

P= KLOC/E X KLOC/PM

CPM: critical path method

Use to calculate minimum time to complete operations

Verification:
Question before or during the project, wether we are doing right or not
it is done by developer during development, unit testing
Validation:
after completion we question have we buit right thing according to requirements.
It is done by tester, system testing

Types of testing:
4 levels
i. Unit testing:
Testing during development, test of each unit or function or module
ii. Integration:
Test during integration of units after integration
a. Bang bang
b. Top-down
c. Bottom up
d. mixed
 iii. System testing:
After developing whole system
Two categorized
a. Based on who is doing testing/ functional
 Alpha => development team
 Beta => friendly customers
 Acceptance => user or customer do test
b. Performance/non functional:
we apply different loads
 Volume
 Load
 Stress
 Security
 Configuration
 Compatibility
 Recovery

iv. Regression:
During maintainance phase

Error seeding: