CHAPTER 1

SOFTWARE & SOFTWARE ENGINEERING

COURSE NAME

SOFTWARE
ENGINEERING
(UNDERGRADUATE)
CSC 3114
MD RAIHAN MAHMUD
(UNDERGRADUATE) LECTURER, CS, AIUB
 Slide - 2
WHY SYSTEM FAILS?

 The system fails to meet the business requirements for which it was developed.The system is either
abandoned or expensive adaptive maintenance is undertaken.
 There are performance shortcomings in the system, which make it inadequate for the users’ needs.
Again, it is either abandoned or amended incurring extra costs.
 Errors appear in the developed system causing unexpected problems. Patches have to be applied at
extra cost.
 Users reject the implemented system, lack of involvement in its development or lack of commitment
to it.
 Systems are initially accepted but over time become un-maintainable and so pass into disuse.

2
 Slide - 3
SCOPE OF SOFTWARE ENGINEERING

 The aim of Software Engineering is to solve Software Crisis:

 Late
 Over budget
 Low quality with lots of faults
 Software crisis is still present over 35 years later!
 Slide - 4
SOFTWARE CHARACTERISTICS

 A logical (intangible) rather than a physical system element

 Being developed or engineered but not being manufactured
 Software cost concentrating in engineering, not in materials
 Software does not “wearing out” but “deteriorating”(not destroyed after lifetime like
hardware, but backdated by aging that needs to update)
 Software is a ‘differentiator’ (different sub-systems, e.g. cashier’s workstation in a supermarket)
 Without “spare parts” in software maintenance (no extra useless features in software)
 Most software continues to be custom-built (based on the requirements)
 Slide - 5
GOAL: COMPUTER SCIENCE VS. SOFTWARE ENGINEERING

 CS: to investigate a variety of ways to produce software, some good and some bad
 SE: to be interested in only those techniques that make sound economic sense
 Slide - 6
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

 A structured set of activities required to develop a software system

 The way we produce software, including:

1. Requirements Analysis
2. Designing/Modeling
3. Coding /Development
4. Testing
5. Implementation/Integration phase
6. Operation/Maintenance
7. Documentation
 Slide - 7
GOOD & BAD SOFTWARE

 Good software is maintained—bad software is discarded

 Different types of maintenance

 Corrective maintenance [about 20%]
- Modification to fix a problem
 Enhancement [about 80%]
- Perfective maintenance (modification to improve usability,…) [about 60%]
- Adaptive maintenance (modification to keep up-to-date) [about 20%]
- Preventive maintenance (modification to avoid any future error) [about 20%]
 Slide - 8
FAULTS IN SOFTWARE DEVELOPMENT PHASES
 60 to 70 percent of faults are specification and design faults

 Data of Kelly, Sherif, and Hops [1992]

 1.9 faults per page of specification
 0.9 faults per page of design
 0.3 faults per page of code

 Data of Bhandari et al. [1994]

Faults at end of the design phase of the new version of the product
 13% of faults from previous version of product
 16% of faults in new specifications
 71% of faults in new design
 Slide - 9
COST OF DETECTION & CORRECTION OF A FAULT
 Slide - 10
COST OF DETECTION & CORRECTION OF A FAULT
 Slide - 11
COST OF CHANGE
 Slide - 12
PRODUCT BATHTUB CURVE MODEL
“Infant Mortality/Early Failure Period” --
due to design or 2. Normal Operation (Useful Life):
Most bugs have been fixed.
Failure Rate manufacturing defects
The software runs reliably.

Low and steady failure rate.

“Wear-out” --
1. Early Failure (Infant Mortality):
due to cumulative
affects of environments 3. Aging or Wear Out Period:
High failure rate due to undiscovered bugs.
Software becomes outdated.
Frequent patches and updates are common.
“Useful Life Period" Incompatibilities with newer systems or user
Failure rate decreases over time as bugs are fixed. demands.

Failure rate increases as the software is no

longer maintained or supported.

Time
 Slide - 13
SOFTWARE ACTUAL FAILURE CURVE

Increased failure rates

due to side effects
Failure Rate

Actual Curve

Change Idealized Curve

Time
 Slide - 14
WHAT IS SOFTWARE ENGINEERING?

 Technologies that make it easier, faster, and less expensive to build high-quality computer
programs
 A discipline aiming to the production of fault-free software, delivered on time and within
budget, that satisfies the users’ needs

 An engineering: set of activities in software production

 The philosophy and paradigm of established engineering disciplines to solve what are
termed software crisis
 Slide - 15
SOFTWARE APPLICATION

 System software (control computer hardware such as OS)

 Business software (commercial application for business users, SAP, ERP)
 Engineering and scientific software (e.g. statistical analysis-SPSS, Matlab)
 Embedded software (e.g. autopilot, biometric device)
 Personal computer software (e.g. Microsoft Office)
 Web-based software (use over the internet with a browser, e.g. Gmail)
 Artificial intelligence software (interact with computer, HCI, ame)
 Slide - 16
SOFTWARE MYTHS (MANAGEMENT)

 Myth 1: We already have a book full of standards and procedures for building software.
Wouldn’t that provide my people with everything they need to know?
 Myth 2: My people have state-of-the-art software development tools; we buy them the
newest computers.

 Myth 3: If we get behind schedule, we can add more programmers and catch up.

 Myth 4: If I outsource the software project to a third party, I can relax and let that firm build
it.
 Slide - 17
SOFTWARE MYTHS (CUSTOMER)

 Myth 1: A general statement of objectives is sufficient to begin writing programs – we can fill
in the details later.

 Myth 2: Project requirements continually change, but change can be easily accommodated
because software is flexible.
 Slide - 18
SOFTWARE MYTHS (PRACTITIONER)

 Myth 1: Our job is done once we write the program and get it to work.

Fact: the sooner you begin writing code, the longer it will take you to get done.

 Myth 2: I cannot assess the program's quality until it is “running. "

 Myth 3:The working program is the only deliverable work product for a successful project.

 Myth 4: Software engineering will make us create voluminous and unnecessary

documentation, invariably slowing us down.
 Slide - 19
REFERENCES

 R.S. Pressman & Associates, Inc. (2010). Software Engineering: A Practitioner’s Approach.
 Kelly, J. C., Sherif, J. S., & Hops, J. (1992). An analysis of defect densities found during software
inspections. Journal of Systems and Software, 17(2), 111-117.
 Bhandari, I., Halliday, M. J., Chaar, J., Chillarege, R., Jones, K., Atkinson, J. S., & Yonezawa, M. (1994).
In-process improvement through defect data interpretation. IBM Systems Journal, 33(1), 182-214.

SB