INTRODUCTION TO

SOFTWARE
ENGINEERING

BY: HAFIZ ABDUL SALAM

[email protected]
 WHAT IS SOFTWARE?
• COMPUTER PROGRAMS AND ASSOCIATED
DOCUMENTATION
• SOFTWARE PRODUCTS MAY BE DEVELOPED FOR A
PARTICULAR CUSTOMER OR MAY BE DEVELOPED FOR A
GENERAL MARKET
• SOFTWARE PRODUCTS MAY BE
• GENERIC - DEVELOPED TO BE SOLD TO A RANGE OF DIFFERENT
CUSTOMERS
• CUSTOM - DEVELOPED FOR A SINGLE CUSTOMER ACCORDING
TO THEIR SPECIFICATION
 WHAT ARE THE ATTRIBUTES OF GOOD
SOFTWARE?
THE SOFTWARE SHOULD DELIVER THE REQUIRED
FUNCTIONALITY AND PERFORMANCE TO THE
USER AND SHOULD BE MAINTAINABLE,
DEPENDABLE AND USABLE.
• MAINTAINABILITY
• SOFTWARE MUST EVOLVE TO MEET CHANGING NEEDS
• DEPENDABILITY
• SOFTWARE MUST BE TRUSTWORTHY
• EFFICIENCY
• SOFTWARE SHOULD NOT MAKE WASTEFUL USE OF SYSTEM
RESOURCES
• USABILITY
• SOFTWARE MUST BE USABLE BY THE USERS FOR WHICH IT WAS
DESIGNED
 SOFTWARE - CHARACTERISTICS
• SOFTWARE HAS A DUAL ROLE. IT IS A PRODUCT, BUT ALSO
A VEHICLE FOR DELIVERING A PRODUCT.

• SOFTWARE IS A LOGICAL RATHER THAN A PHYSICAL

SYSTEM ELEMENT.

• SOFTWARE HAS CHARACTERISTICS THAT DIFFER

CONSIDERABLY FROM THOSE OF HARDWARE.

• - SOFTWARE IS DEVELOPED OR ENGINEERED, IT IS NOT

MANUFACTURED IN THE CLASSICAL SENSE.

• - SOFTWARE DOESN’T “WEAR OUT”.

• - MOST SOFTWARE IS CUSTOM-BUILT, RATHER THAN BEING

ASSEMBLED FROM EXISTING COMPONENTS.
 TYPES OF SOFTWARE
• SYSTEM SOFTWARE- A COLLECTION OF PROGRAMS
WRITTEN TO SERVICE OTHER PROGRAMS AT SYSTEM
LEVEL.
FOR EXAMPLE, COMPILER, OPERATING SYSTEMS.

• REAL-TIME SOFTWARE- PROGRAMS THAT

MONITOR/ANALYZE/CONTROL REAL WORLD EVENTS AS
THEY OCCUR.

• BUSINESS SOFTWARE- PROGRAMS THAT ACCESS,

ANALYZE AND PROCESS BUSINESS INFORMATION.

• ENGINEERING AND SCIENTIFIC SOFTWARE - SOFTWARE

USING “NUMBER CRUNCHING” ALGORITHMS FOR
DIFFERENT SCIENCE AND APPLICATIONS. SYSTEM
SIMULATION, COMPUTER-AIDED DESIGN.
 TYPES OF SOFTWARE

• EMBEDDED SOFTWARE-:
EMBEDDED SOFTWARE RESIDES IN READ-ONLY
MEMORY AND IS USED TO CONTROL PRODUCTS
AND SYSTEMS FOR THE CONSUMER AND
INDUSTRIAL MARKETS. IT HAS VERY LIMITED AND
ESOTERIC FUNCTIONS AND CONTROL CAPABILITY.

• ARTIFICIAL INTELLIGENCE (AI) SOFTWARE:

PROGRAMS MAKE USE OF AI TECHNIQUES AND
METHODS TO SOLVE COMPLEX PROBLEMS. ACTIVE
AREAS ARE EXPERT SYSTEMS, PATTERN
RECOGNITION, GAMES
 TYPES OF SOFTWARE
• INTERNET SOFTWARE :
PROGRAMS THAT SUPPORT INTERNET ACCESSES
AND APPLICATIONS. FOR EXAMPLE, SEARCH
ENGINE, BROWSER, E-COMMERCE SOFTWARE,
AUTHORING TOOLS.

• SOFTWARE TOOLS AND CASE ENVIRONMENT :

TOOLS AND PROGRAMS THAT HELP THE
CONSTRUCTION OF APPLICATION SOFTWARE AND
SYSTEMS. FOR EXAMPLE, TEST TOOLS, VERSION
CONTROL TOOLS.
 Common issues
•The final Software doesn´t fulfill the needs
of the customer.
•Hard to extend and improve: if you want
to add a functionality later is mission
impossible.
•Bad documentation.
•Bad quality: frequent errors, hard to use, ...
•More time and costs than expected
 ??????WHAT???????
I. THE FINAL SOFTWARE DOESN´T FIT THE NEEDS
OF THE CUSTOMER
II. HARD TO EXTEND AND IMPROVE: IF YOU WANT
TO ADD A FUNCTIONALITY LATER IS MISSION
IMPOSSIBLE BAD DOCUMENTATION, BAD SOFTWARE
DESIGN
III. BAD QUALITY: FREQUENT ERRORS, HARD TO
USE...
IV. MORE TIME AND COSTS THAN EXPECTED
Problems in Software
Development
LIMITATIONS OF NON-ENGINEERED SOFTWARE

Requirements
Here is the problem!!

Software
• ONE OF THE PROBLEMS WITH COMPLEX SYSTEM DESIGN IS THAT
YOU CANNOT FORESEE THE REQUIREMENTS AT THE BEGINNING OF
THE PROJECT. IN MANY CASES, WHERE YOU THINK YOU CAN START
WITH A SET OF REQUIREMENTS, THAT SPECIFIES THE COMPLETELY THE
PROPERTIES OF YOUR SYSTEM YOU END UP WITH....
 SOFTWARE PRODUCTION HAS A POOR
TRACK RECORD
EXAMPLE: SPACE SHUTTLE SOFTWARE
• COST: $10 BILLION, MILLIONS OF DOLLARS MORE THAN PLANNED
• TIME: 3 YEARS LATE
• QUALITY: FIRST LAUNCH OF COLUMBIA WAS CANCELLED BECAUSE OF A
SYNCHRONIZATION PROBLEM WITH THE SHUTTLE'S 5 ONBOARD
COMPUTERS.
• ERROR WAS TRACED BACK TO A CHANGE MADE 2 YEARS EARLIER WHEN A
PROGRAMMER CHANGED A DELAY FACTOR IN AN INTERRUPT HANDLER FROM 50
TO 80 MILLISECONDS.
• THE LIKELIHOOD OF THE ERROR WAS SMALL ENOUGH, THAT THE ERROR CAUSED
NO HARM DURING THOUSANDS OF HOURS OF TESTING.

• SUBSTANTIAL ERRORS STILL EXIST.

• ASTRONAUTS ARE SUPPLIED WITH A BOOK OF KNOWN SOFTWARE PROBLEMS
"PROGRAM NOTES AND WAIVERS".
Ariane 5 Flight 501

Cause: design errors in the software

Conclusion
Programming is NOT enough!
It is not enough to do your best: you must
Know what to do, and THEN do your best.
-- W. Edwards Deming
And Since…

A clever person solves a problem.

A wise person avoids it.
- Albert Einstein
SOLUTION
 SOFTWARE ENGINEERING

• APPLICATION OF A SYSTEMATIC, DISCIPLINED,

QUANTIFIABLE APPROACH TO THE DEVELOPMENT,
OPERATION AND MAINTENANCE OF SOFTWARE; THAT IS,
THE APPLICATION OF ENGINEERING TO SOFTWARE.
 BY “DİSCİPLİNED” WE MEAN:

• EACH PROCESS İS FOLLOWED USİNG ORGANİZATİONAL

PRİNCİPLES (E.G. WHO MANAGES WHOM, WHO İS
RESPONSİBLE FOR WHAT?),
• INTERMEDİATE RESULTS ARE CAREFULLY DOCUMENTED, AS
WELL AS FİNAL RESULTS,
• ACTİONS ARE TRACEABLE AS TO THEİR CAUSES,
İNDİVİDUALS İNVOLVED, TİME OF OCCURRENCE AND
CİRCUMSTANCES.
21
 BY “SYSTEMATIC” WE MEAN
• FOLLOWING A WELL-DEFINED SEQUENCE OF ACTIVITIES,

- IN WHICH DESIRED OUTPUTS (DELIVERABLES) ARE WELL-DEFINED

- BY USING WELL-DEFINED INPUTS

(I.E. DOCUMENTED SYNTAX, SEMANTICS, CONTEXT AND OTHER RELEVANT PROPERTIES OF THE
INPUT)

- IN A WELL-DEFINED PROCESS
(E.G. USING ORGANIZATIONAL STANDARDS FOR INTERPROCESS COMMUNICATION, DATA
FORMATS, ERROR HANDLING ETC.)

- WHOSE OUTPUTS ARE IN TURN USED SIMILARLY AS INPUTS IN SUBSEQUENT PROCESS(ES),

- UNTIL THE FINAL OUTPUT IS ACHIEVED,

- AND WHERE THE CORRECTNESS OF THE OUTPUT IS VERIFIABLE.

NOTE: THE “INPUTS” AND “OUTPUTS” MOST OFTEN REFER TO REQUIREMENTS, SOFTWARE
SPECIFICATIONS, THE SOFTWARE ITSELF, DOCUMENTATION, TEST INPUTS/OUTPUTS AND SIMILAR
SOFTWARE ARTIFACTS.
BACK
 BY “QUANTİFİABLE” WE MEAN:
• THE SİZE AND EXTENT OF THE REQUİRED EFFORT

(SİZE OF OUTPUT CODE, DATA, DOCUMENTATİON, MANPOWER,

DURATİON, BUDGET FOR DEVELOPMENT, EXPECTED ERROR RATE AND
USER SUPPORT)

ARE PREDİCTABLE WİTHİN JUSTİFİABLE AND ACCEPTABLE BOUNDS

23
 Software Engineering
Objective
To produce software that is:

• On time: is deliver at the established date.

• Reliable: doesn´t crash.

• Complete: good documentation, fulfill

customer needs.
Software
Development
Process/Life Cycle
SDLC,
A framework that describes the
activities performed at each stage of a
software development project.
 SDLC PHASES
Requirements Gathering and Analysis
Design
Development
Testing
Implementation
Maintenance
STEPS
 REQUIREMENTS GATHERING:
 Requirement gathering and analysis is the first stage and
major stage of any SDLC model. This phase is basically the
brainstorming phase because it has the many sub stages
for like Feasibility Analysis Stages to check how much idea
can put into action for development.

 Customer Interview
 BASIC REQUIREMENTS:

 Feasibility
 Scalability
 Hardware
 Input
 Out
 Interface
 Fast Speed
 User Friendly
 ANALYSIS:

 At this stage the system is divided into smaller

parts to make it easier more manageable for the
developers, designers, testers, project managers
and other professionals who are going to work
on the software in the latter stages.
 ANALYSIS STEPS:

❖Objective
❖Criteria
❖Review
❖Approval
 DESIGN:

 In this phase the design of the system is designed. The

Design is developed by The analysts and designers. The
System analyst design the logical design for the designers
and then designer get the basic idea of designing the
software design of Front end and back end both.

 Understandable Interface.
 User Friendly/Easy to Use.
 Fast Speed.
 CODING:
 It is the logical part of the development process. In this
phase lots of brains are working for coding and get the
final successful result for the software. In this A team of
programmers is assigned by the company to work on the
software.

 C++
 Java
 C#
 TESTING:

 By process of coding, then the final process

testing is proceeding. When the software is ready
it is sent to the testing department where Quality
Analysts test it thoroughly for different errors by
forming various test cases.

 Dynamic
 Static
 Errors
 IMPLEMENTATION:
 This is the final phase of the software
development life cycle. In this stage, if the
software runs on various systems by users or
buyers. If it runs smoothly on these systems
without any error, then it is considered ready to be
launched.
 ADVANTAGE:

➢Increased development speed

➢Increased product quality
➢Improved tracking & control
➢Improved client relations
➢Decreased project risk
➢Decreased project managementoverhead
 EXAMPLE:

 Design Calculator For

Customer.

➢Requirements Gathering.
➢Analysis.
➢Design.
 SDLC MODELS
TO HELP UNDERSTAND AND IMPLEMENT
THE SDLC PHASES VARIOUS SDLC
MODELS HAVE BEEN CREATED BY
SOFTWARE DEVELOPMENT EXPERTS,
UNIVERSITIES, AND STANDARDS
ORGANIZATIONS.
 WHY USING SDLC
•
MODLES
Provides basis for project planning,
estimating & scheduling
• Provides framework for standard set
of terminologies, activities &
deliverables
• Provides mechanism for project tracking
& control
• Increases visibility of project progress to
all stakeholders
 ADVANTAGES
• Increased development speed
• Increased product quality ‘
• Improved tracking & control
• Improved client relations
• Decreased project risk
• Decreased project management overhead
COMMON LIFE CYCLE MODELS

• Waterfall
• Spiral/Iterative
• Agile
WA T E R F A L L MODEL
Analysis
Design
Development
Testing
Deployment
Maintenance
CONTD..

•OLDEST AND MOST WELL-KNOWN SDLC MODEL

FOLLOWS A SEQUENTIAL STEP-BY-STEP PROCESS
FROM REQUIREMENTS ANALYSIS TO
MAINTENANCE.
•SYSTEMS THAT HAVE WELL-DEFINED AND
UNDERSTOOD REQUIREMENTS ARE A GOOD FIT
FOR THE WATERFALL MODEL
 STRENGTHS

• Easy to understand, easy to use

• Provides structure to inexperienced staff
Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than
cost or schedule
 WEAKNESSES
•ALL REQUIREMENTS MUST BE FULLY SPECIFIED
UPFRONT
•DELIVERABLES CREATED FOR EACH PHASE ARE
CONSIDERED FROZEN – INHIBITS FLEXIBILITY CAN GIVE
A FALSE IMPRESSION OF PROGRESS
•DOES NOT REFLECT PROBLEM-SOLVING NATURE OF
SOFTWARE DEVELOPMENT – ITERATIONS OF PHASES
INTEGRATION IS ONE BIG BANG AT THE END
•LITTLE OPPORTUNITY FOR CUSTOMER TO PREVIEW THE
SYSTEM (UNTIL IT MAY BE TOO LATE)
 WHEN T O USE THE
W A T E R F A L L MODEL

• Requirements are very well known

Product definition is stable Technology
is understood
• New version of an existing product
Porting an existing product to a new
platform.
 SPIRAL / I T E R AT I V E MODEL
Requirements
Analysis

Requirements Design
Gathering

R e p e at
Enhancement

Maintenance
Iterative
Development

Quality
Deployment Assurance
 SPIRAL MODEL

• Spiral Model is a “risk-driven” iterative

model Divides a project into iterations
• Each iteration deals with 1 or more
risks
• Each iteration starts with small set of
requirements and goes through
development phase (except
Installation and Maintenance) for
those set of requirements.
CONTD..

• Iterate until all major risks addressed and

the application is ready for the Installation
and Maintenance phase (production)
• Each of the iterations prior to the
production version is a prototype of the
application.
• Last iteration is a waterfall process
 STRENGTHS

•PROVIDES EARLY INDICATION OF INSURMOUNTABLE

RISKS, WITHOUT MUCH COST
• CRITICAL HIGH-RISK FUNCTIONS ARE DEVELOPED FIRST
THE DESIGN DOES NOT HAVE TO BE PERFECT
•USERS SEE THE SYSTEM EARLY BECAUSE OF RAPID
PROTOTYPING TOOLS
• USERS CAN BE CLOSELY TIED TO ALL LIFECYCLE STEPS
EARLY AND FREQUENT FEEDBACK FROM USERS
 WEAKNESSES

• TIME SPENT FOR EVALUATING RISKS TOO

LARGE FOR SMALL OR LOW-RISK PROJECTS
• TIME SPENT PLANNING, RESETTING
OBJECTIVES, DOING RISK ANALYSIS AND
PROTOTYPING MAY BE EXCESSIVE THE
MODEL IS COMPLEX
• RISK ASSESSMENT EXPERTISE IS REQUIRED
SPIRAL MAY CONTINUE INDEFINITELY
• MAY BE HARD TO DEFINE OBJECTIVE,
VERIFIABLE MILESTONES THAT INDICATE
READINESS TO PROCEED THROUGH THE NEXT
ITERATION
 WHEN TO USE SPIR A L MODEL
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
For medium to high-risk projects
• Users are unsure of their needs
Requirements are complex New
product line
• Significant changes are expected (research
and exploration)
 AGILE MODEL

Discover

Test

Design Discover
Develop
Test

Design Discover
Develop
Test

Design
Develop
 AGILE MODEL

• SPEED UP OR BYPASS ONE OR MORE LIFE CYCLE PHASES

• USUALLY LESS FORMAL AND REDUCED SCOPE USED
FOR TIME-CRITICAL APPLICATIONS
• USED IN ORGANIZATIONS THAT EMPLOY
DISCIPLINED METHODS
 SOME AGILE METHODS

• Rapid Application Development

• (RAD) Scrum
• Extreme Programming (XP)
• Adaptive Software Development
• (ASD) Feature Driven Development
• (FDD) Crystal Clear
• Dynamic Software Development Method
• (DSDM) Rational Unify Process (RUP)
 AGILE MODEL S T R E N G T H S

•DELIVER A WORKING PRODUCT FASTER THAN CONVENTIONAL

LINEAR DEVELOPMENT MODEL
•CUSTOMER FEEDBACK AT EVERY STAGE ENSURES THAT THE END
DELIVERABLE SATISFIES THEIR EXPECTATIONS
•NO GUESSWORK BETWEEN THE DEVELOPMENT TEAM AND THE
CUSTOMER, AS THERE IS FACE TO FACE COMMUNICATION AND
CONTINUOUS INPUTS FROM THE CLIENT
 WEAKNESSES

• For larger projects, it is difficult to judge the

efforts and the time required for the project
in the SDLC.
• Since the requirements are ever changing,
there is hardly any emphasis, which is laid on
designing and documentation. Therefore,
chances of the project going off the track
easily are much more
 QUIZ

……..1……..

FIND OUT WHAT THE CLIENT

WANT THE SOFTWARE TO DO
1. Requirements Analysis

Find out what the client want the software to do

 ………2……….

HOW ARE YOU GOING TO BUILD

YOUR APPLICATION AND HOW
WILL IT BE
2. Design

Planning the software solution

……….3……….

CODE!!!
3. Implementation
Code!!!
 ……….4……….

TRY EVERYTHING TO MAKE SURE IS

WORKING CORRECTLY

TEST TECHNIQUES INCLUDE, BUT

ARE NOT LIMITED TO, THE PROCESS
OF EXECUTING A PROGRAM OR
APPLICATION WITH THE INTENT OF
FINDING SOFTWARE BUGS
4. Testing

Executing the application trying to find software bugs

 …..5…..
MAINTENANCE
• MAINTENANCE AND ENHANCING SOFTWARE TO COPE WITH NEWLY
DISCOVERED PROBLEMS OR NEW REQUIREMENTS CAN TAKE FAR MORE
TIME THAN THE INITIAL DEVELOPMENT OF THE SOFTWARE.
• IT MAY BE NECESSARY TO ADD CODE THAT DOES NOT FIT THE ORIGINAL
DESIGN TO CORRECT AN UNFORESEEN PROBLEM OR IT MAY BE THAT A
CUSTOMER IS REQUESTING MORE FUNCTIONALITY AND CODE CAN BE
ADDED TO ACCOMMODATE THEIR REQUESTS.
• IT IS DURING THIS PHASE THAT CUSTOMER CALLS COME IN AND YOU SEE
WHETHER YOUR TESTING WAS EXTENSIVE ENOUGH TO UNCOVER THE
PROBLEMS BEFORE CUSTOMERS DO.
• SOFTWARE MAINTENANCE ACTIVITIES INCLUDE ANY SOFTWARE
ENGINEERING ACTIVITY ORIENTED TO CHANGE AN EXISTING SOFTWARE
PRODUCT OR TO IMPROVE OR PLAN FOR FUTURE CHANGES.
5. Maintenance

Any activity oriented to

change an existing software
product.
 WHY SOFTWARE ENGINEERING?
• MAJOR GOALS:
- TO INCREASE SOFTWARE PRODUCTIVITY AND QUALITY.
- TO EFFECTIVELY CONTROL SOFTWARE SCHEDULE AND
PLANNING.
- TO REDUCE THE COST OF SOFTWARE DEVELOPMENT.
- TO MEET THE CUSTOMERS’ NEEDS AND REQUIREMENTS.
- TO ENHANCE THE CONDUCTION OF SOFTWARE ENGINEERING
PROCESS.
- TO IMPROVE THE CURRENT SOFTWARE ENGINEERING
PRACTICE.
- TO SUPPORT THE ENGINEERS’ ACTIVITIES IN A SYSTEMATIC AND
EFFICIENT MANNER.
 WHAT IS THE DIFFERENCE BETWEEN SOFTWARE
ENGINEERING AND COMPUTER SCIENCE?

Computer Science Software Engineering

is concerned with
➢ theory ➢ the practicalities of developing
➢ fundamentals ➢ delivering useful software

Computer science theories are currently insufficient to act as a

complete underpinning for software engineering, BUT it is a
foundation for practical aspects of software engineering
 WHAT IS THE DIFFERENCE BETWEEN SOFTWARE
ENGINEERING AND SYSTEM ENGINEERING?

• SOFTWARE ENGINEERING IS PART OF SYSTEM ENGINEERING

• SYSTEM ENGINEERING IS CONCERNED WITH ALL ASPECTS OF
COMPUTER-BASED SYSTEMS DEVELOPMENT INCLUDING
• HARDWARE,
• SOFTWARE AND
• PROCESS ENGINEERING
• SYSTEM ENGINEERS ARE INVOLVED IN
SYSTEM SPECIFICATION
ARCHITECTURAL DESIGN
INTEGRATION AND DEPLOYMENT