IN THE NAME OF ALLAH THE

MOST MERCIFUL AND THE

MOST BENEFICIAL
SOFTWARE ENGINEERING

LEHMAN’s LAW
MOORE’s LAW
BEST PRACTICES
PRESENTERS

SAADAT ULLAH KHAN

L1S00BSCS0103
DANISH RASHID KITCHLEW
L1S00BSCS0087
 Lehman’s law

• Evolution which expresses five associated

properties of software systems
 Lehman’s law
• 1 - THE LAW OF CONTINUING CHANGE
– Program concerning real world requirements
either undergo continual change or become
progressively less useful

• 2 - THE LAW OF INCREASING COMPLEXITY

– Changes to software system increase the
complexity of their construction and reduce
their degree of good structured ness with
detriment to quality
 Lehman’s law

• 3 - THE LAW OF PROGRAM EVOLUTION

Program evolution is a subject to a
dynamic which makes it and measure of
its development and system properties,
self regulating with statically determinable
trends and invariance.
 Lehman’s law

• 4 - THE LAW OF INVARIENT WORK RATE

During the active life of a program, the overall
activity rate in associated programming tasks is
statistically invariant
• 5 - THE LAW OF PERCEIVED COMPLEXITY
– During the active life of a program, the change
content (like additions and deletions) of
successive releases of the evolving program is
statically invariant
 Lehman’s law

• Lehman predicated his work at the time

on detailed studies of three large software
systems
– IBM’s OS-360
– DOS-360
– OMEGA which is a banking system
 Lehman’s law

• Lehman 1st law state that

• system maintenance
• Fault repair
• system must evolve changes to remain useful
• Lehman 2nd law state that
• as system change structure is degraded
• Additional costs
 Lehman’s law

• Lehman 3rd law state that

• system exceeds some minimal size
• large change increment is proposed
• change approval process must be re-initiated
• Lehman 4th law state that
• saturated state
• large software development teams are
unproductive
 Moore’s law

• what is Moore’s law

• Application of Moore’s law

• Present
• Future
 Moore’s law

• Moore's Law for Intel CPUs

 Moore’s law

Date Intel Transistors Technology

CPU (x1000)

1971.50 4004 2.3

1978.75 8086 31 2.0 micron

1982.75 80286 110 HMOS

1985.25 80386 280 0.8 micron CMOS

1989.75 80486 1200

1993.25 Pentium (P5) 3100 0.8 micron biCMOS

1995.25 Pentium Pro (P6) 5500 0.6 micron -- 0.25?

1998.5? Merced (P7) 14000 0.18 micron?

Moore’s law

• Moore's Law is coming into direct conflict

with the law of nature
• Intel’s chairman emeritus told the ability of
the industry to double the computing
power of a chip every 18 months may slow
Moore’s law

• "Some time in the next several years we

get to some finite limits, but not before we
get through five generations,
• According to one study, the physical
limitations could be reached by 2017.
Moore’s law
• Rivals like Advanced Micro Devices simply can't
keep up with the same level of research and
development as Intel
• example, a chip plant for making .25 micron
chips now costs between $2 and $2.5 billion to
construct. For future .18 micron chip plants, the
cost will jump to between $3 and $4 billion,
according to Moore.
Chip Progress May Soon Be Hitting Barrier

• It has been assumed in the industry that

the rate of progress would hold for at least
another 10 to 15 years.
• It has been assumed in the industry that
the rate of progress would hold for at least
another 10 to 15 years.
Moore’s law

• Intel is currently making most of its

processors on a .25 and .18 micron
process but is slowly moving production to
the more advanced .13 process.
• The next step is to move to a .10
production process.
• Carver Mead, a physicist and a pioneer in
semiconductor design, says that Moore's
Law will continue to account for the pace
of silicon technology advances until at
least 2014
• It might be accurate to warn of an
impending limit to the shrinking of today's
dominant chips, known as C.M.O.'s, or
complimentary metal oxide
semiconductors. But they believed they
had found an alternative approach, known
as silicon-on-insulator, that held great
promise at dimensions of 0.10 micron and
smaller.
BEST PRACTICES
• Technique that lead to desired results
through experience and research
• Commitment to use it is a commitment to
use all knowledge and technology to
ensure success.
• In SD it is a well defined method that
contributes to a successful step in product
development
SOME BEST PRACTICES

• Decomposition and composition

• Architecture and modularity
• Process model
• Matrices
• Software quality
• Configuration management
• Project management
• Prototyping
• Tools and environment
DECOMPOSITION & COMPOSITION

• Takes place at every level

• BASED ON
Functionality
Relations between processes
Data movement
System / sub system / modules
ARCHITECTURE
Earliest product of design process
MEANING
• structures of the system
• comprise software components
• the externally visible properties of those
components
• the relationship among them
Phase of the architectural design
• Decomposing a system into a set of
interacting sub-systems
• At abstract level
– Depicted as block diagram
– Boxes represent a sub-system
• Notation represents
functional processing, data stores and
data movements between functions
BASIC MODELS

• DATA FLOW MODELS

• SEMANTIC DATA MODELS
• OBJECT MODELS
• INHERTANCE MODELS
DFD CONTEXT LEVEL

CIB REPORT
MANAGEMENT REPORTS
STATE BANK
MANAGEMENT
FINAL DECISION
STATEBANK REPORT
0
ACCOUNTS REPORT
REPAYMENT
FIDELITY CLIENT PAYMENT
MUDARBA ACCOUNT
PROPOSAL REQUEST
SYSTEM PROPOSAL & SCHEDULE

CLIENT INFO PAYMENT RECIPT

CLIENT
MONTHLY SCHEDULE CLIENT
 MANAGEMENT REPORT
MANAGEMENT

REQUEST
2
CLIENT 1 CIB REPORT
REQUEST MANAGEMENT GENERATE
VERIFICATION REQUIRED INFOMANAGEMENT
PROCEDURE REPORT
4
GENERATE
STATEBANK
UPDATE REQUEST STATE BANK REQUIRED INFO STATE BANK
STATE BANK
REC REPORT
REPORT
D1 REQUEST REC.

NEW CLIENT INFO

3 D3 REPAYMENT SCHD.
5
ADD NEW REPAYMENT
REPAYMENT INFO
CLIENT PRODUCTION
ACCONTS REPORT ACCOUNTS
PROCEDURE
CLIENT INFO

UPDATE CLIENT RECORD

CLIENT RECEIPT PAYMENT
D2 CLIENT REC.
REPAYMENT
CLIENT INFO
FINAL DECISION 7

6 PAYMENT
GENERATE PROPOSAL & CLIENT PAYMENT
REQUEST PROCEDURE
D1 REQUEST REC. PROPOSAL& SCHEDULE CLIENT
REPAYMENT
SCHEDULE
MONTHLY STATEMENT

UPDATE REPAYMENT 8
SCHD CREATE CLIENT INFO. UPDATE CLIENT
MONTHLY RECORD
D3 REPAYMENT SCHD.
STATEMENT
REPAYMENT INFO
D2 CLIENTS REC.

Zero level
MODULARITY

• Another level of decomposition

• Decomposition of sub-systems into
modules
• System decomposition and Modular
decomposition
• the component in modules are usually
smaller than sub-systems
DECOMPOSING MODELS

Which may be used when

decomposing a sub-system into
modules:
1 – AN OBJECT-ORIENTED MODEL

The system is decomposed into a set of

communicating objects.

Modules are objects with private state and

defined operations on that state.
2 – A DATA FLOW MODEL

• The system is decomposed into functional

modules which accept input data and
transform it, in some way to output data.

• A pipeline approach

• Modules are functional transformations

PROCESS MODELLING

• The outcome of process analysis is

process model.

• Involves studying existing processes

• Developing an abstract model of these
processes that capture their key
characteristics.
Elements of process model
ACTIVITY An activity is clearly defined objective, entry and exit condition. E.g.
coding a function or preparing a document.
PROCESS A process is a set of activities which have some coherence and
whose objective is generally agreed with in an organization. E.g. of
process is requirement analysis, architectural design, test planning
etc.
DELIVERABLE A deliverable is a tangible output of an activity which is predicated in
a project plan.
CONDITION A condition is either pre-condition which must hold before a process
or activity can start or a post-condition which holds after a process or
activity has finished.
ROLE A role is a bounded area of responsibility. E.g. configuration
manager, test engineer or software designer.
EXCEPTION An exception is a description of how to modify the process if some
anticipated or unanticipated event occur. They are often undefined
and handled by project managers and engineers.
COMMUNICATION An interchange of information between people or between people
and supporting computer systems.
Four fundamental process activities

• 1 – SOFTWARE SPECIFICATION
The functionality of the software and
constraints on its operation must be
defined.

• 2 – SOFTWARE DEVELOPMENT
The software to meet the specification
must be produced
Four fundamental process activities

• 3 – SOFTWARE VALIDATION
The software must be validated to ensure
that it does what the customer wants.

• 4 – SOFTWARE EVOLUTION
The software must evolve to meet
changing customer needs.
Some process models are

• THE WATERFALL MODEL

• EVOLUTIONARY DEVELOPMENT
• BOEHM’S SPIRAL MODEL
 MATRICES

Software metric is any type of measurement

which relates to a software system, process
or related documentation
EXAMPLES
• measures of the size of a product in lines
of code
• the Fog index which is a measure of the
readability of a product manual
• the number of reported faults in a
delivered software product
• the number of person / days required to
develop a system component.
CLASSES OF METRICS

1 – CONTROL METRICES.

2- PREDICTOR METRICES
1 – CONTROL METRICES
• Control metrics are those used by management
to control the software process
• Example of these metrics are effort expended,
elapsed time and disk usage
• Estimates and measurements of these metrics
can be used in the refinement of the project
planning process.
• provide information about process quality
 2- PREDICTOR METRICES
• Predictor metrics are measurements of a
product attribute that can be used to
predict an associated product quality
• the readability of a product manual may be
predicted by estimating its FOG INDEX
(Gunning 1962)
• the ease of maintenance of a software
component may be predicted by measuring
its cyclomatic complexity (McCabe 1976).
SOFTWARE QUALITY

• Quality is the fitness of a system for its

intended uses
• maintained by quality assurance team
• roles of the quality assurance team is the
development of product and process
standards
Product standards

• Product standards define characteristics

that all product components should
exhibit. An example of product standard is
a review form which defines the
information to be collected during a
review
Process standards

• Process standards define how the

software product should be conducted. An
example of a process standard is a
procedural definition of how design
reviews should be organized.
Quality standards

• Some quality standards are.

– US DoD
– ANSI
– BSI
– NATO
– IEEE
Product & Process standards
PRODUCT STANDARDS PROCESS STANDARDS

Design review form Design review conduct

Document naming standards Submission of documents to CM

Procedure header format Version release process

Ada programming style standard Project plan approval process

Project plan format Change control process

Change request form Test recording process

CONFIGURATION MANAGEMENT

• takes over control of system after they

have been developed
• planning this management process must
start during system development
• plan should be developed as part of the
overall project planning process.
SOFTWARE PROJECT PLANNING
PROCESS Organization Requirements Funding &
Policy allocated 2 SW resources

Identification of
SDLC

ESTIMATION

PLANNING

REVIEWS

Distribute SDP to
affected
groups
It Includes

• CONFIGURATION ITEM
IDENTIFICATION
• THE CONFIGURATION DATA BASE
• CHANGE MANAGEMENT
• VERSION AND RELEASE
MANAGEMENT
 Submit change request

CHANGE Review change request Customer response /

MANAGEMENT
comments

NO
If
Query Send it back to
requester with
comments
Yes

Give reason to client why

Accep NO you reject change
t request
chang
Yes e
Remains pending unless
customer closes it
Assign change to team
member

Check out required SCI

Make changes

Check in SCI

Perform review test

Maintain modification history

VERSION MANAGEMENT
Submit change request

Project manager review

Decide whether this change will effect

version, release, both, nothing

Assign CR to team member

Incorporate changes

Review and regression testing

Change version / release / both / none

accordingly

Maintain modification history

RELEASE MANAGEMENT
SCI request

SCCB review

Verifying / Checking required SCI from integrity and

completeness

SCCB authorized

Is approved NO
from SCCB

Release to affected groups

Maintain log
PROJECT MANAGEMENT

• MANAGEMENT ACTIVITIES

• PROJECT PLANNING

• PROJECT SCEDULING
MANAGEMENT ACTIVITIES

Proposal writing
Project costing
Project planning and scheduling
Project monitoring and reviews
Personnel selection and evaluations
Report writing and presentations
PROJECT PLANNING
PLAN DESCRIPTION
Quality plan Describe the quality procedures and standards that
will be used in a project

Validation plan Describe the approach, resources and schedule

used fro system validation

Configuration management plan Describe the configuration management procedures

and structures to be used

Maintenance plan Predicts the maintenance requirements of the

system, maintenance costs and effort required

Staff development plan Describe how the skills and experiences of the
project team members will be developed
SOFTWARE CONFIGURATION
MANAGEMENT
SCM planning

Documented SCM plan

Approve
d from
No SCCB

Yes

Establish SCM library

Configuration control Item release

PROJECT SCEDULING
• demanding task for software managers
• Managers estimates the time and
resources required to complete activities
• organize them in a coherent sequence
• involves separating the total work involves
in a project into separate activities
• judging the time required to complete
these activities
 GANTT CHART :
ANALYSIS 8DAYS
DESIGN 10 DAYS
DEVELOPMENT 14 DAYS
DOCUMENTATATION 7 DAYS
TESTING 9 DAYS
DEBUGGING 9 DAYS
IMPLEMENTATION 8 DAYS

ACTIVITIES WEEKS

1 2 3 4 5 6 7 8 9 10
 Detailed WBS in one of the two Project manager calls a
forms:1- modules and sub modules group meeting
2modules and sub modules with their
complexity

PM shall brief team

members about

PERT ESTIMATION requirements,

expectations and
constraints

EQUATION Each member develop three types of

estimates
E = a + 4b + c / 6 1- best case estimate
2- normal case estimate
SD = C – A / 6 3- worst case estimate

PM will summarizes the estimates

using the pert estimation equations

Documented estimates
DESIGN
• A software design is a model of real world system
that has many participating entities and
relationships
• It acts as a basis for detailed implementation
• It serves as a communication medium between
the designers of sub systems
• It provides information to system maintainers
about the original intentions of the system
designers
DESIGN METHODS
A DATA FLOW MODEL It is used where the system is modeled using the data
transformations which take place as it is processed.

AN ENTITY RELATION MODEL It is used to describe the logical data structures being used.

A STRUCTURAL MODEL Used where the system components and their interactions are
documented.

AN OBJECT ORIENTED MODEL It will include an inheritance model of the system, a model of how
objects are composed of other models.
DESIGN STRATIEGIES
• FUNCTIONAL DESIGN
• The system is designed from a functional point
of view, starting with high level view and
progressively refining this into a more detailed
design.
• OBJECT DESIGN
• The system is viewed as a collection of objects
rather than as functions. It is based on the idea
of information hiding.
PROTOTYPING

• A prototype is a model of an application. It

simulates the user interface and important
functions of the program being modeled
ADVANTAGES
• Better collection of customer requirements.
• Cost saving.
• Increased quality.
• Evaluation of new interface techniques and functions.
• Demonstration of feasibility.
• Sales tool.
• Defines a clear specification.
• Allows early testing.
• Demonstration of early progress.
• Increases user satisfaction.
• Results in a better design.
BOAR’S REPORT

• BOAR reported that 20 to 40 percent of all

system problems can be traced to
problems in the design process while 60 to
80 percent can be traced to problems to
inaccurate requirements definitions
TYPES OF PROTOTYPING

• 1 – LOW FIDELITY PROTOTYPING

• 2 – HIGH FIDELITY PROTOTYPES

LOW FIDELITY PROTOTYPING

• limited function and limited interaction

prototypes
• constructed to depict concepts, design
alternatives, and screen layouts
• constructed quickly and provide limited or
no functionality.
• Users do not exercise
HIGH FIDELITY PROTOTYPES

• fully interactive
• User can enter data, respond to the
messages, open windows and in general
interact with the prototype just as they
would a real application
PROTOTYPING IN SOFTWARE
PROCESS

• EVALUTIONARY PROTOTYPING
• THROW-WAY PROTOTYPING
EVALUTIONARY PROTOTYPING
• deliver a working system to end-users
• based on idea of developing an initial
implementation
• exposing this to user comment
• refining this through many stages until an
adequate system has been developed
• used for the development of AI (artificial
intelligence) systems
THROW-WAY PROTOTYPING

• validate or derive the system requirements

• extends the requirements analysis process
with the intention of reducing overall life
cycle costs
• clarify requirements
• provide additional information for
managers to assess process risks
TOOLS

• The most significant productivity increases

in manufacturing or building processes
have come about when human skills are
augmented by powerful tools
• One man and a bulldozer probably shift
more earth in a day than 50 men working
with hand tools
TOOLS

• Improve the productivity of engineering

designers
• Since the early 1980’s, a wide range of
tools to support software development
have been developed
Different level of case tech.

• PRODUCTIVE PROCESS SUPPORT

TECHNOLOGY

• PROCESS MANAGEMENT TECHNOLOGY

• META CASE TECHNOLOGY

PRODUCTIVE PROCESS SUPPORT
TECHNOLOGY

• This includes support for process activities

such as specification, design,
implementation, testing and so on
PROCESS MANAGEMENT
TECHNOLOGY
• This includes tools to support process
modeling and process management.
META CASE TECHNOLOGY

• Meta case tools are generators which are

used to create production-process and
process management support tools.
TOOL TYPES
TOOL TYPES
Management tools
Editing tools
Configuration management tools
Prototyping tools
Methods support tools
Language processing tools
Program analysis tools
Testing tools
Debugging tools
Documentation tools
Re-engineering tools
EXAMPLES
PERT tools, estimation tools
Text editor, diagram editors, word processors
Version management systems, change
management systems
Very high level languages, user interface
generators
Design editors, data dictionaries, code generators
Compilers, interpreters
Cross reference generators, static analyzers,
dynamic analyzers
Test data generators, file comparators
Interactive debugging systems
Page layout programs, image editors
Cross reference systems, program restructuring
systems.
ENVIRONMENTS

• DEFINATION
• A software engineering environment (SEE)
is a set of hardware and software tools
which can act in combination in an
integrated way to provide support for the
whole of the software process from initial
specification through to testing and
system delivery.
ENVIRONMENTS

• The term “environment” is used to

describe a vast range of support system
ranging from simple systems that support
program development in a single language
to very large systems offering support for
multiple projects using many different
languages and design methods.