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.
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.
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
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.
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
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
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
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.
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
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.