Scribd
Upload
48 views50 pages

Chap 2 Software Engineering Models

The document discusses various software engineering models including: 1) Traditional models like waterfall, prototyping, and synchronize-and-stabilize. 2) Iterative models like spiral, object-oriented, and cleanroom. 3) Agile models like open source software development, extreme programming (XP), and other agile methods. It also covers principles of software engineering and "laws" about software development projects.

Uploaded by

erdene khutag
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
48 views50 pages

Chap 2 Software Engineering Models

The document discusses various software engineering models including: 1) Traditional models like waterfall, prototyping, and synchronize-and-stabilize. 2) Iterative models like spiral, object-oriented, and cleanroom. 3) Agile models like open source software development, extreme programming (XP), and other agile methods. It also covers principles of software engineering and "laws" about software development projects.

Uploaded by

erdene khutag
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 50

Chap 2 Software Engineering Models

Spring 2020
Different Process Models
1. Build and fix – No plan, very bad model,
Develop then maintain– little plan and more
maintenance
2. Waterfall—Linear steps. Never go back
3. Incremental prototype – deliver by parts
4. Synchronize and stabilize – Microsoft. team
works independently then join for synchronize
then stabilize. Repeat.
5. Spiral – repeating cycle of plan—analysis—
develop--evaluate
Different Process Models(2)
6. Object Oriented – Cycle of software process
-based on object model
7. Cleanroom – good mathematics and statistics
for software engineering
8. 4-GT – Fourth Generation Technique
9. Agile –very flexible and dynamic for user’s
request
10. Service model – SOA/ESB Service Oriented
Architecture/Enterprise Service Bus
1. Build and Fix
No plan, no engineering. Just code, test and
correct, run, correct, run ……
2. Waterfall
3. Prototype model
Prototype
Rapid prototyping
Evolutionary Model
4. Synchronize and stabilize Model
• Model made by Microsoft around 1990.
• Begins with good requirement analysis –
interview potential customers.
• Draw up specification in detail
• Divide project into 3-4 steps of production
cycle
• Each cycle is performed by small sized teams
working in parallel.
Synchronize-and-Stabilize(2)
• At the end of each team gathers and test and
debug. (Synchronize)
• At the end of cycle (build) they finalize.
(stabilize)
• The products are always worked together and
gets total picture.
S&S model
5. Spiral Model (Boehm)
• Popular model for many practitioners
• Iterative model from small to large scale
6. OO Model
7. Cleanroom Software Eng (CSE)
8. ETVXM model
CSE and ETVXM
9. Open Source Software Model
• Based on Open Source Movement
• It is developed by many people free.
• Cooperative work
• Two phases –
– Initial development by multiple developers
– Once accepted, continue to improve.
– Seek GPL license for quality assurance.
OSS Phase 1
Development
OSS is Open Source Software.
One individual builds an initial version.
Publish to web or SourceForge for free download
See the reaction of people
Enough interest and downloads then
Ask feedback and suggestion for expansion
Extend the feature in cooperation
OSS Phase-2
Maintenance
• Report and correct defects (corrective
maintenance)
• Add additional functionality (perfective
maintenance)
• Port the program to a new environment
(adaptive maintenance)
Summary
Developers of OSS
• Two groups—
– Core group : Spend most of their time in
developing and maintaining the software
– Peripheral group : Who usually detects error and
send report. Occasionally, help in development.
Release new version as soon as developed. Core group
does minimal testing. It is done by peripheral
group.
Often attracts most capable people in the developer.
Quality can vary depending of the situation—but many
OSS have proven quality.
Newer Models
-- Component based development
Use COTS for development cycle
-- Aspect Oriented software Development (AOSD)
extended from Component based development but
focus on functionality of each “aspects” of software.
-- Agile Software development
Effective (rapid and adaptive) response to change
Effective communication among all stakeholders
Drawing the customer onto the team
Organizing a team so that it is in control of the work
performed
Aspect Oriented Software Devel.
XP (Extreme Programming)
Begins with the creation of “user stories”
Agile team assesses each story and assigns a cost
Stories are grouped to for a deliverable increment
A commitment is made on delivery date
After the first increment “project velocity” is used
to help define subsequent delivery dates for
other
5-Key characteristics of XP
Communication
Simplicity
Feedback
Respect
Encourage. 
Key Techniques of XP
User story
Pair Programming
Test before coding (TDD)
Class Exercise of Pair Programming
(Pair drawing)
Using one paper and one pen, draw any two
from the following.
A) World map with major country specified.
B) Typical keyboard (without seeing the actual
keyboard)
C) Arrangement of car interior (driver’s view)
D) Shape of a military tank (or airplane)
E) Sukbaatar square and buildings around.
10. Other Agile models
ASD (Agile Software Development) - Mission-driven planning
Component-based focus
DSDM(Dynamic Software Development Method) Active user
involvement is imperative.
Scrum -Development work is partitioned into “packets”
Crystal - family of process models that allow
“maneuverability” based on problem characteristics
FDD(Feature Driven Development)
Emphasis is on defining “features”
Software
Same as program?

Software is a set of items or objects that form a “configuration”


that includes;
programs
documents
data ... etc
Dual Role of software
Software is a product
-- Delivers computing potential
-- Produces, manages, acquires, modifies, displays, or transmits
information
Software
Software is a vehicle for delivering a product
-- Supports or directly provides system
functionality
-- Controls other programs (e.g., an operating
system)
-- Effects communications (e.g., networking
software)
-- Helps build other software (e.g., software tools)
Goals –build software which is
-- correct -- portable
-- reliable -- understandable
-- efficient -- useful
-- interoperable -- reusable
-- timely -- adaptable
-- visible -- user friendly
-- repairable -- maintainable (3 types)
-- evolvable -- verifiable
Software Engineering Principles
1) Rigor/Formality—mathematical, procedural
(managerial)
2) Separation of concern—role kept, phase oriented
—focused process
3) Modularity—unit based operation
4) Abstraction – simplification, formalization
5) Anticipation of change
6) Generality—applicable to many situation
7) Incrementally—more components can be added
Principles
Everything has reason to exist
KISS (Keep It Simple and Stupid)
Maintain Vision
What you produce, others will consume
Be open to future
Plan ahead for reuse
Think !!!!!!
Various laws
• Murphy’s Law: Anything that can go wrong,
will go wrong.
• Finagle’s Law : Anything that can go wrong,
will—at the worst possible moment (Law of
dynamic negative, Corollary to Murphy’s law)
• Hofstadter's Law --It always takes longer than
you expect, even when you take into account
Hofstadter's Law.
More laws
Parkinson’s Law 1 : Work expands so as to fill the
time available for its completion.
Law 2 : expenditures rise to meet income.
Wirth’s Law -- Data expands to fill the space
available for storage. (Corollary to Parkinson’s law)
Peter Principle : In a Hierarchy, Every Employee Tends
to Rise to His Level of Incompetence.
Dilbert Principle: leadership is nature's way of
removing morons from the productive flow.
• Software Peter Principle : a (dying) project will
become too complex little by little to be
understood even by its own developers
• Brook’s Law : Adding manpower to a late
software project makes it later.
• Student’s syndrome: People will start to fully
apply themselves to a task just at the last
possible moment before a deadline.
• Pareto Rule : 80 % of problem (performance or
achievement) comes from 20% of total
components (staff).
• Hawthorn Effect : Quality improves if the worker is
monitored.
• Grosch’s Law : Computer performance increases as
the square of the cost. If computer A costs twice as
much as computer B, you should expect computer A
to be four times as fast as computer B.
• Moor’s Law : No. of transistors in IC doubles every 2
years.
• Segal’s Law : A man with a watch knows what time
it is. A man with two watches is never sure.
• Harnon’s razor : Never attribute to malice(bad luck)
that which can be adequately explained by stupidity.
Conclusion
Software is hard to engineer due to its abstract
nature. Therefore, we should follow known
methods of team oriented software process
and always focus on quality!

You might also like