This document provides an overview of software engineering. It defines software engineering as a systematic approach to software analysis, design, implementation, and maintenance. It describes conventional software engineering methods including requirements analysis, design, construction, testing, and maintenance. It also covers software project management principles, quality assurance, metrics, estimation, risk management, and testing. The document is a comprehensive introduction to the key concepts and processes in software engineering.

1. Software Engineering

2. Definition


Software: The programs, routines and symbolic
language that controls the functioning of the
hardware and direct its operation.
Engineering: The application of scientific and
mathematical principals to practical ands such as
the design, manufacture & operation of efficient
and economical structures, machines, processes
and systems.

3. Definition

Software Engineering: A systematic
approach to the analysis, design,
implementation and maintenance of
software.

4. 1. Conventional Methods of
SE





Analysis Concepts and Principals
Analysis Modeling
Design Concepts and Principals
Architectural Design
User Interface Design

5. Software Life-cycle







Requirements Analysis
Design
Construction
Testing
Installation
Maintenance
Retirement

6. Analysis concepts and
Principals




Understand the Information domain of
the problem
Define the functionalities of the S/W
Represent the behavior of the S/W
Partition the models that models that
depict information, function and
behavior

7. Analysis Procedure


Requirements Collection
Customer Communication





(Questionnaire, Interviews etc.)
Modeling
Partitioning
Prototyping
Requirements Specification

8. Analysis Modeling
Data Object
Description
ER Diagram
Data Flow
Diagram
Data Dictionary
State Transition Diagram
Behavior/Control
Specification
Process/Function
Specification

9. Design Concepts & Principals

Data Design


Architectural Design


Relationship among structural elements
Interface Design


Data Structures
Human-Computer interaction
Procedural Design

Procedural description of S/W components

10. 2. Software Project
Management

Four P’s of Project Management




People
Product
Process
Project

11. Project Management…


People must be organized into effective
terms, motivated to do high-quality s/w work
and coordinated to do effective
communication.
The Product requirements must be
communicated from customer to developer,
partitioned into their constituent parts and
positioned for work by the software team.

12. Project Management…



The Process must be adapted to the people
and the problem
The Project must be organized in a manner
that enables the software team to succeed.
The Project Management also includes
Measurement and metrics estimation, risk
analysis, schedules, tacking and control.

13. Metrics


Measurement enables to improve the
software process, assist in planning,
tracking and control of a software
project and assess the quality of the
product that is produced.
Measures of specific attributes of the
process, project and product are used
to compute S/W metrics.

14. Metrics…

Metrics is a quantitative measure of the
degree to which a system, component
or process posses a given attribute.

15. Metrics Types



Size Oriented Metrics (LOC)
Function Oriented Metrics (FP)
Use Case Oriented Metrics (Use
Cases)

16. Estimation







Fundamentals
Inputs
Process
Outputs
Types
Metrics
Samples

17. Estimation fundamentals
NO zone
Know zone
Actual reqmts
Requirement clarity
• Accelerate progress into KNOW zone
• Advanced requirements gathering tech
• Approximate NO zone with risk

18. Estimation inputs


High quality requirements
Historical productivity rates








LOC/hr, FP/hr, Pgms/day
Application attributes
Project team experience
PM experience
Language used
Methodology used
Platform
Code complexity

19. Estimation inputs...

Cost data






S/w cost
H/w cost
Service charge
Salaries
Link
Miscellaneous - travel, team meet expenses etc,.

20. Estimating process







Identify the solution offerring - Organization std
process DB 5%
Freeze inventory and deliverables 50%
Alternative implementation techniques - build, buy,
outsource, tool based 10%
Gather other estimation inputs 20%
Perform estimate - Excel 10%
Create schedule - res, onsite/offshore 2%
Estimate the cost in $ 3%

21. Estimation outputs

Direct






Project size
Effort
Duration
Resources
Cost
Indirect


schedule
process

22. Estimation types




Functional
LOC
Method based
Experience based

23. Estimation - Metrics


Productivity : size/hrs
Quality




Product - achieve funct & tech
requirements
Process - defect removal rate, measures
Cost: price/prj.unit size
Customer satisfaction – prj time based
review

24. Estimation
Options
Delay Estimates
Depends on Similar Projects
Decomposition Techniques
Empirical models

25. Estimation
Decomposition Techniques
Software sizing
Function point sizing
Standard component sizing

26. Estimation
Problem based Estimation
LOC- based Estimation
FP- based Estimation
Process- based Estimation

27. Estimation
Empirical Models
LOC- oriented estimation models
E = 5.2*(KLOC)0.91
Walton-Felix Model
E = 5.5+.73*(KLOC)1.16
Bailey-Basali Model
E = 3.2+(KLOC)1.05
Boehm simple Model
E = 5.288+(KLOC)1.047
Doty Model for KLOC >9
E is effort in person months

28. Estimation
Timeline Chart
Work tasks
1.1 Identify Need
xxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxxxx
milestone
1.2Define desired----
Week1
D1
D2
D3
D4
D5
Week2
D1
D2
Week3
D3
D4
D5

29. Tracking
Work Tasks
1.1 Identify Need
xxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxxxx
milestone
1.2Define desired-----
Project Table
Planned
Start
Wk1 d1
Actual
Start
Wk1 d1
Planned
Complete
Wk1 d2
Actual
Complete
Assigned Effort
Person
Allocated
Notes

30. Estimation
Project Plan
1 Introduction
2 Project Estimate
3 Risk Management Strategy
4 Schedule
5 Project Resources
6 Staff Organization
7 Tracking and Control Management
8 Appendices

31. Risk Management




What can go wrong ?
What is the likelihood (Probability) ?
What will the damage be (Impact) ?
What can we do about it ?

32. Reactive Rick Management




Project team reacts to risks when they occur
Mitigation – plan for additional resources in
anticipation of fire fighting
Fix on failure - resources are found and
applied when the risk strikes
Crisis management - failure does not
respond to applied resources and project is in
jeopardy

33. Proactive Risk Management


Formal risk analysis is performed
Organization corrects the root causes of
risk



TQM concepts and statistical SQA
Examining risk cources that lie beyond the
bounds of the s/w
Developing the skill to manage change

34. Risk Management Paradigm
Identify
Control
Track
Analyze
Plan

35. 3. Software Quality


Conformance to explicit and implicit
customer requirements
Striving for excellence in reliability and
functions by continuous [process]
improvement, supported by statistical
analysis of the causes of failure.

36. Measuring S/W Quality

+

=

No. of errors & defects, severity, type,
cause, effort to correct
Design measures, Complexity,
structure, flow
Defect removal efficiency, statistical
SQA data, design quality metrics

37. A Quality Metric



E = total errors found before delivery
D = total defects found after delivery
Defect removal efficiency (DRE) =
E / (E+D)

38. Software Quality




S/w Quality is achieved through a disciplined
approach called Software Engineering
S/w Quality can be defined, described, and
measured.
S/w Quality can be assessed before any code
has been written
S/w Quality cannot be tested into a product

39. Software Quality Assurance




SQA Goals:
To improve s/w quality by monitoring
both the process and the product
To ensure compliance with all local
standards for software engineering
O ensure that any product defect,
process variance or standards
noncompliance is noted and fixed

40. Formal Technical Reviews




A meeting conducted by technical
people for technical people
A technical assessment of a work
product created during the s/w
engineering process
A S/w Quality Assurance mechanism
A training ground

41. Review Process



Establish Review Guidelines
The review meeting
Review reporting and record keeping

42. 4. Software Testing

43. What is Software Testing?




Any activity aimed at evaluating an
attribute or capability of a program or
system, to verify that it meets its required
results.
It is the process of executing software in a
controlled manner.
Testing is the process of executing a
program with an intent to find errors.
A process of verification and validation.

44. IEEE-Definition of Testing
“The process of exercising or evaluating a
system by manual or automatic means to
verify that it satisfies specified requirements
or to identify differences between expected
and actual results.”

45. Steps in Testing

Determine the goals and what is to be
measured in the test



Satisfy the Requirements
Reliability
Decide how to test




Inspections
walkthrough
manual
automation

46. Steps in Testing (contd...)




Develop test plans and test cases
Determine the expected results
Execute the test cases
Compare the results

47. Levels in Software Testing

Unit Testing




Individual units are tested
Confirms the module is coded correctly
Types are Black Box testing & White Box testing
Integration Testing


Test the sub systems and modules and its
interfaces
Checks if they function properly and meet the
system requirements.

48. Levels in SoftwareTesting

System Testing



Black box Testing.
Entire system is tested as an entity.
User Acceptance Testing

Testing the finished product with respect to the
user perception.

49. Points to remember while Testing







Testing is the process of executing a program to find
an error.
It is impossible to test any module or system
completely.
There are practical and theoretical limitations.
Correcting an error can introduce another error.
Testing can prevent errors. Find them early.
Testing is best done by independent testers.
Generally the person who codes the module carries
out the Unit Testing

50. Why is Testing required?

General




Business




Developers are not infallible
Requirement implications are not seen
Find the bugs and limitations
Post release debugging is too expensive
Reputation,sales,operations all affected
Hazardous bugs(life/property)
Professional



Test case design challenging, rewarding
Good testing gives confidence in work
Systematic test is effective

51. Definitions

Bug/Defect



Validation


Deviation from specification or standard
Anything that causes customer dissatisfaction
Test phase of life cycle. It is the process of checking if what
has been specified, is what the user actually wanted.
Verification

Quality control activity. It is the checking or testing of items,
including software, for conformance and consistency with an
associated specification.