Software Engineering-I

Mahroos Shahid
 Objectives
• To understand the importance of Software
Engineering.
• To help students to develop skills that will
enable them to construct software of high
quality
• Software that is reliable.
• Software that is reasonably easy to
understand, modify and maintain
• To foster an understanding of why these skills
are important
Introduction
 What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...
 Software in Use
• system software
• real-time software
• Application software
• engineering/scientific software
• AI software
• WebApps (Web applications)
Software Crisis
 Software Crisis
 Term first used in late 1960s
 More powerful and cheaper hardware
resulted in
 More complex application
 Existing methods of software development were
not good enough
 Software development techniques could not be
scaled-up
 Software Crisis - Contd.
 Resulted in software projects which were:
 Late – sometimes by many years
 Over budget
 Unreliable
 Difficult to maintain
 Poor in performance
 Required new techniques and methods to
control the complexity inherent in “LARGE”
software systems.
 Software Engineering
Software Engineering as defined by IEEE

The application of a systematic, disciplined, quantifiable

approach to the development, operation and maintenance
of Software, that is application of engineering to software.

Software Engineering as defined by Ian Sommerville

Software Engineering is concerned with all aspects of

software production from early stages of system
specification through to maintaining the system after it
has gone into use..
Software Engineer Challenge

Software Engineering is not just

about producing software, but
about producing software in a
COST-EFFECTIVE manner.
 Well-Engineered Software

Provides the required functionality

 Reliable  Efficient
 User-friendly  Maintainable
 Cost-effective

11
 The Balancing Act!
• These requirements may be conflicting:
– Cost vs Efficiency
– Cost vs Reliability
– Efficiency vs User friendly
• Challenge is to balance these requirements.
 The Role of Software Engg.
(1)
A bridge from customer needs to programming implementation

Customer
Programmer

First law of software engineering

Software engineer is willing to learn the problem domain
(problem cannot be solved without understanding it first)
 The Role of Software Engg.
(2)
Customer:
Requires a computer system to achieve some business goals
by user interaction or interaction with the environment
in a specified manner

System-to-be

Environment
Software-to-be
User

Software Engineer’s task:

To understand how the system-to-be needs to interact with
the user or the environment so that customer’s requirement is met
and design the software-to-be

May be the Programmer’s task:

same person To implement the software-to-be
designed by the software engineer
15
 Breakdown of Development Effort Cost
Project Size: 1000 FP
No. Activity Effort 13 Configuration Mgt. 0.41%
1 Requirements 14 Integration 2.71%
3.84% 15 User Documentation 9.67%
2 Prototyping 4.50% 16 Unit Testing 4.50%
3 Architecture 2.25% 17 Function Testing 4.50%
4 Project Plans 1.33% 18 Integration Testing 3.84%
5 Initial Design 3.84% 19 System Testing 3.38%
6 Detailed Design 4.50% 20 Beta Testing 3.02%
7 Design Reviews 3.02% 21 Acceptance Testing 1.94%
8 Coding 13.50% 22 Independent Testing 3.38%
9 Reuse acquisition 1.13% 23 Quality Assurance 4.50%
10 Package Purchase 1.69% 24 Installation and Training 1.94%
11 Code Inspection 4.50% 25 Project Management
12 Independent V&V 5.42% 6.75%
 Allocation of Effort
• A typical project follows the 40-20-40 rules.
– 40% on Requirement, Specification, Architecture,
Design.
– 20% on Coding and Debugging.
– 40% on Testing.
• Boehm's successful project followed the 60-15-25
rules.
– 60% on Requirement, Specification, Architecture,
Design.
– 15% on Coding and Debugging.
– 25% on Testing.
• Alter a software system in Production maintenance
and modification effort is typically 50% - 75% of the
 Software Myths
• Old attitudes and habits are difficult to
modify
• Loose ends of software Myths are still
believed.
• Management myths.
• Customer myths.
• Practitioners myths.
 Software Myths – Part 1
• Adding people is a good way to catch
up when a project is behind schedule.

“Adding people to a late software

project makes it later (Brooks)”
 Software Myths – Part 2
• A general statement of objectives from
the customer is all that is needed to
begin a software project.
• Project requirements change continually
and change is easy to accommodate in
the software design.
Cost of Change
 Software Myths – Part 3
• Once a program is written, the software
engineer's work is finished.
• The only deliverable work product for a
successful project is the working program.
• Software engineering is all about the creation
of large and unnecessary documentation, and
not shorter development times or reduced
costs.
 References
 [PRS] Chapter 1