MAIN REASONS FOR COST OF SOFTWARE

DEVELOPMENT
 Labour intensive
 Projects are very large
 Many people
 Span of time
 Development of system
 Is done in adhoc manner
 Frequent schedule slippage
 Cost overrunning
 Some projects are abandoned

The term SOFTWARE ENGINEERING was coined in conferences in 1960’s

under NATO

Program  system product

100 $ : 100$

RATIO IS HIGH BECAUSE

 Program does not need
 System has one component i.e. program
 Software is developed so that it can be used by other personals

The basic purpose o the software engineering is to develop a high quality software
at low cost.

QUALITY PYRAMID:-
This pyramid consist of following three parts

 Product revision
 Maintainability
 Flexibility
 Testability

 Product transition
 Portability
 Reversibility
 Interoperability
  Product operation
 Correctness
 Reliability
 Efficiency
 Integrity
 Usability

Cost can be calculated by applying different accounting principles.

Software development industry is largely interest in system products. Mostly the

commercial packages.

The software product fails because its design fails. To recover from the fault
changes are made so that it causes no failure in future. Due to this and other
reasons software must constantly undergo changes, which makes maintenance an
important issue with the software.

ALTITUDE / MYTHS TO SOFTWARE DEVELOPMENT

It includes
 Management
 Customer
 Practitioners

MANAGEMENT
 It has standards and procedures for building software what else is desired.
 Our programmers have started the art of software development tools, we
need to buy newest computers for them.
 If we get behind the schedule we need to add more programmers to be in ?
with the schedule.

CUSTOMER
 A general statement of objectives is sufficient to begin program with
writing, detailed would be added.
 Projects requirement continuously change, but change can be
accommodated because of flexibility of the software.

PRACTITIONER
 Once our program is completed and it starts functioning well, our work /job
is done.
 Unless the program gets running, its quality cannot be tested / accessed.
  The only delivery for a successful project is the working program.

SOFTWARE ENGINEERING is layered approach of process, methods and tools

organized in a way shown below.

PICTURES

Generically SOFTWARE ENGINEERING has the phases.

DEFINATION PHASE
“WHAT”
 System engineering
 Project planning
 Requirement analysis

DEVELOPMENT PHASE
“HOW”
 Software design
 Code generation
 Testing

MAINTENANCE PHASE
“CHANGE”
 Correction
 Adoption
 Enhancement
 Prevention

There are certain other activities “UMBERELLA ACTIVITIES” that occur

through out the process and include
 Project tracking and control
 Format technical reviews
 Software quality reviews.
 Software configuration management
 Document preparation and production
 Reusability management
 Risk management
 Measurement

COMMOM PROCESS FRAMEWORK MODEL

CAPIBILITY MATURITY METHOD.
Has fine level of maturity.
LEVEL 1:-
INITIAL
Purely adhock, only a few only a few things defined, success depends upon
individual’s effort.
LEVEL 2:-
REPEATABLES
Basic project management process used to track cost, schedule, functionality. Able
to repeat earlier success on similar projects.
Key process areas:
Software configuration management quality assurance, sub contract management.

LEVEL 3:-
DEFINES
All aspect of level 2 + software process for management and engineers are
documented standardized and integrated into software development process. All
projects use a documents and approved version process.
Key process areas:
KPA’s of level two + peer reviews inter group coordination product engineering,
integrated software management training program, organization process definition,
organization process focus.

LEVEL 4:-
MANAGED
All of level 3 + detailed measure of software process and product quality are
collected, measures used to control the process.
Key process areas:
KPA’s of level 3 + quality management and quantitative process management.

LEVEL 5:-
OPTIMIZATION
All of level 4 + continuous process improvement is attempted using feedback from
current process and from testing ideas and technologies.
Key process areas:
KPA’s of level 4 + process change management, technology change management
of defect prevention.
SEI MODEL
 Software development institute
Defines key process in terms of
 Goals
 Commitment
 Abilities
 Method of maintaining implementation
 Method of verifying implementation and activities

 This process model is a develop strategy that encompasses the whole

pyramid of process, methods stools layer along with generic phases
(definition, development and maintenance ).

 The process model for a project is selected to support the nature of the
project , the application domain tool available with controls and deliverable
required.

 It considers a range of common process models by making no agreement on

a “BEST” process model.
THE LINEAR SEQUENTIAL MODEL.
Also called the waterfall model or classic life-cycle.

Sequential set of phases:-

 System information engineering and modeling
 Software requirement and analysis
 Design
 Code generation
 Testing
 Maintenance

ADVANTAGES:
 Simple to implement and manage
 Well used

DISADVANTAGES:
 Real projects are not sequential
 Cannot state requirements completely early
 Customers cannot see system until after testing
 Development often results in, parts of project being “blocked”
 Emphasis is on case of project management
 Methods does not scale up to large project as well

THE PROTOTYPYING MODEL

The prototyping model is used when some aspects of the system are not well
defined.
BASIC STEPS:
Requirement gathering
Obtain requirements from customer
Identify areas of uncertainty
Quick design and build
Quick design of aspects of system visible to customer
Quick development of a prototype implements
Customer evaluation of a prototype
Prototype used to refine the requirement of the system

These basic steps are repeated until the requirements are well defined
Should discard prototype and build the real system.
ADVANTAGES:
Customer can provide input to the system early during the development of
prototype and will usually get a system which does what he requires.
Reduce problems in requirements which are the most expensive to fix.

DISADVANTAGES:
Customer sees a working version early and unless they have the basic
knowledge of the process, cannot understand, why it should be thrown
away.
Customer sees the prototype built quickly may not understand why the
“real” version takes so long.
Developer may makes implementation decisions to get the prototype
working quickly and these may be carried over to “real” system.

THE RAD MODEL

The rapid application development (RAD) model is a high speed adaptation of the
linear sequential model which uses a component based construction approach.
Requirements must be well understand and project scope constructed.
Attempt to create full functional systems in 2-3 months.
Primary application domain is information systems.
PHASES
BUSSINESS MODELING
What information drives the business process?
What information is generated?
Who generates it?
Where the information does goes?
Who processes it?

DATA MODELING
Define a set of data objects needed to support the application and the
relationship between these objects.

PROCESS MODELING
Data objects and transformation defined to implement business
functions.
Provide add, modify, delete, retrieve for all data objects.

APPLICATION GENERATION
Use 4GL techniques.
Use components.
 Testing and turn over.
Test new components and combinations of components in the
application.

For larger applications, we can use RAD model if system can be decomposed and
teams apply the RAD model to each other component.

EVALUTIONARY SOFTWARE ENGINEERING PROCESSING MODELS:-

Products of several kinds are produced over the passage of time. There is a
need that there must be some model, evolutionary in nature and iterative as well,
which will accommodate all the changes. In the evolutionary process model
common is the spiral model and for the iteration we repeat some simple model a
number of times.

1- incremental model
2- combination of ideas

LINEAR PROCESS MODEL + PROTOTYPING MODEL

 Each linear sequence produces a deliverable increment on a
previous delivery.
 Linear sequence can overlap in time.
 Unlike prototyping, each delivery in the incremental models
is an operational product.
 Increments can be organized to account for staffing levels and
reduce technical risks.

THE SPIRAL MODEL:

Proposed by BOEHM in 1988
It is divided into a number of frameworks activities or task regions.
It can also be useful for rapid development of incremental versions
The number of most variants could be between 3-6
Being evolutionary combines prototyping with the aspect of linear
sequential model

CUSTOMER:
Establish effective communication between developer and customer.
PLANNING:
Project management activities. Its defines the available resources as well as
the time lines “deadlines for each phase to be completed”.
THE RISK ANALYSIS:
It accesses technical and management risks.
ENGINEERING:
It says to build one or more representation of the application.
 CONSTRUCTION AND RELEASE:
It considers the construction, testing and installation along with the user
support.
CUSTOMER EVALUATION:
Feedback from the customer on changes to the installed stages.

In some variants a decision is made after customer evaluation to continue or not

with the project. there are certain advantages and disadvantages of the spiral
model.

ADVANTAGES:
It matches the reality in the sense that the requirements change over the life
of the project
It has the type of prototyping, the customer has early input into the system
Many adaptations possible
Requires consideration of risks at all stages of development.

DISADVANTAGES:
Customer may be consult about control of the process in the spiral model, it
could lead to difficulties in contract negotiations.
Requires considerable expertise in risk assessment
Has not been as widely a use as linear sequential model.

COMPONENT ASSEMBLY MODEL

It employs variants of the spiral model with framework of tasks. Construction tries
to force reuse of the developed components by:
Attempting to modify candidate component for use in the system
Using the component if they exist
Developing new components where necessary and then adding them to
component library
Constructing the application from library components
It is said to reduce 70% development cycle time over 30% of project cost and
increases productivity twice

THE CONCURRENT DEVELOPMENT MODEL

Also called “concurrent engineering”
Process represented by a network of activities
Each activity has a state
Each activity exist simultaneously with other activities
Event from activities can trigger changes of state in other activities
 Diagram
FORMAL METHODS MODEL:
A formal method is used to develop mathematical specification of software
An example of a formal method model is clean room software engineering
(developed by IBM)
formal method can discover ambiguity, incompleteness, inconsistencies and
errors in specification or design.
CURRENT PROBLEMS:
Time consuming and expensive
Few software engineering have background in formal methods
Not a good tool to communicate a specification or design to a
technical unsophisticated customer
Important in safety critical applications
Will grow in more general usage

FOURTH GENERATION TECHNIQUES:

A high level description of the system is developed, and 4GL tools
generated the application
It combined with computer aided software engineering (ASE) and
component assembly methods, could become an important development
approach in a range of application domains

DIAGRAM

SOFTWARE SYSTEM SIZE:

Small telephone exchange – 500000 lines of code
Space shuttle on board system – 1000000 lines of code
Large telephone exchange – 2000000 lines of code
Telephone network software – 3000000 lines of code

If printed code of a software system (ignore documentation)

100000 lines of code <=> 400 m of printout
1000000 lines of code <=> 4 km of printout
LEHMAN’S LAW:
Software systems always need to be maintained as they evolve.
OBSERVATIONS BY LEHMAN
Continues change:
A program must change in a real world environment or become less
and less useful
Increasing complexity:
Changing a program will increase the complexity of the program
(unless active methods are made to avoid this)
Program evolution:
Program evaluation is self regulating and can use matrices (such as
size, number of errors) to find statically significant trends
Conservation of organizational stability over the lifetime of the
system. The rate of development is approximately constant and
independent of resources used to develop the system
Conversation of familiarity
Over the lifetime of the system, the rate of change of the system is
approximately constant

MOORE’S LAW:
MIP/$ and Memory/$ relationships double approximately every two years.
Has been true for two decades and expected to continue for at least
another two decades
Has enable the size and complexity of the system being developed to
continue to increase
This increase in size and complexity has forced development to new
software engineering methods as old methods fails to scale up
The new area of rapid development is in distributed networked
environments with many embedded applications
(MIP/$ = millions of instructions per second per dollar)

BEST PRACTICE:
What are some of concepts or models?
Which most software engineers would consider important in dealing?
What constitutes “best practice” in software engineering?
 ABSTRACT AND INFORMATION HIDING
Decomposition and composition
Architecture and modularity
Process model
Matrices
Software quality
Configuration management
Project management
Analysis and design methods and notations
Prototyping
Tools and environments

SYSTEM ENGINEERING:-
A system of high technology having software, hardware, people, database,
documentation and procedures. The system engineering helps to translate a
customer’s need into a model of systems that make use of one or more or all of the
components. He begins by taking a broader view called “world view”

WV = {D1, D2, D3,………..Dn} where

Di = {E1, E2, E3,…………Ej} Domain
Ej = {C1, C2, C3,………..Ck} Specific Element

C is the technical component e.g. (a computer program, a reusable computer

program components, a module, a class or an object or program language
statement). A business product domain or product is analyzed to establish all basic
requirements. Focus is then narrowed to a domain “view” where each of the
system elements is analyzed individually. Each element is allocated to one or more
engineering components which are then addressed by the relevant engineering
disciplines.

INFORMATION ENGINEERING:
It is a system engineer approach used to define architecture that enable a business
to use information efficiently. Its basic intents is to derive comprehensive data and
an application along with technology infra structure that will meet the needs of the
business strategy, the objectives and the goals of each business area information
engineering encompasses (ISP). Information engineering planning, business area
analysis (BBA) and application specific analysis, which are necessary parts of
engineering.
PRODUCT ENGINEERING
It begins with system analysis. The system engineer identifies customer’s needs,
determines economics and technical feasibility and allocates functions and
performance to software, hardware, people and databases (key engineering
components). An architectural model is produced and representation of each major
subsystem can be developed. Finally system engineer can create a reactive system
model that can be used as basis for a simulation of performance and behavior. The
system engineer task finishes with the creation of system specification. A
document that focuses the foundation for all subsequal works.

Diagram

If communications succeed and a complete model of the system is created a solid

foundation is established for the construction of the system.

SYSTEM SPECIFICATION OUTLINE

REQUIRMENT
First technical step in the software engineering is requirement
analysis. A general statement of software is refined into a concrete specification
that becomes the foundation for all software engineering activities that follow.

Diagram

To get a better understanding of what is required model are created, problem is

partitioned and representations that depict the essence of requirements and later on
implementation details are developed.
In many cases it is not possible to specify a problem completely at any early stage.
Prototyping provides an alternative approach that results in an executable model of
the software from which requirements can be refined. In order to conduct
prototyping properly special tools are techniques are required.
A software requirement specification is developed as a consequence of analysis.
Review is essential to ensure that the developer and costumer have the same
perception of the system. Unfortunately even with the best methods the problem is
that, that the problem keeps changing.

Diagram

It is a team oriented approach to requirements gathering. It has been developed

and applied during early stages of analysis and specification. This approach does
not work very well. Because of misunderstanding important information is omitted
and consequently a successful working relationship is never established.

QFD: - QUALITY FUNCTION DEPLOYMENT

Uses interviews, observation, survey, examination of historical data for
joint application development (JAD) .

SOFTWARE DESIGN: -

Diagram

We say a comprehensive model exist when all the design activities have been
completed.

DATA DESIGN: -
It translates the data object defined in the analysis as model into data structure that
resides within the software.

Diagram

ARCHITECTURAL DESIGN: -
It use information flow characteristic described in the analysis model to derive a
DFD structure.

Diagram

Transform mapping is an application to an information flow that exhibits different

boundaries between incoming and outgoing data. The DFD is mapped into a
structure that allocates control to input a processing model hierarchies, where as
the transaction mapping is applied, when a single information item causes flow to
branch along one of the many paths.
Then in this case the DFD is mapped into a structure that acquires and evaluates a
transaction. Another sub-structure controls all potential processing action based on
a transaction.

Diagram

DESIGN PROCESS
It begins with task analysis, a design activity that define user interface along with
defining user task and actions using either elaborative or object oriented
approaches.

++++++++++++++++
MISSING
++++++++++++++++
DESIGN OF REAL TIME SOFTWARE: -
The design of real software covers all the aspects of conventional software
engineering. While introducing new sets of design, criteria and concerns, because
of the fact that the real time software must respond to a real world events in a time
frame dictated by those events all classes of design become more complex.
It is difficult often in practical to device software design from larger system
oriented issues because real time software is either clock or event driver. The
designer must consider function and performance of both hardware and software.
Interrupt processing and data transfer rate distribute and data basis, operating
system, specialized P.L and synchronization methods are just sum of the concerns
of the real time system designer.
The analysis of real time system takes into consideration mathematical modeling
and simulation. Queuing and network models enable the system engineering to
access the overall response time and sizing issues. Formal analysis tools provide a
mechanism for real time system simulation. Software design for real time systems
can be predicated on a conventional design methodology that extends data flow
oriented design by providing a notation and approach that addresses real time
system characteristics. Alternatively design methods that take into consideration
the use of unique notation or specialized language can also be applied.
A software design for a real time system remains a challenge. Progress has been
made. Methods do exist but realistic assessment of the state of the art suggest
much more yet remains to be done.
CLEAN ROOM SOFTWARE ENGINEERING: -
Clean room software engineering is a formal approach to software development
that can lead to software of remarkably high quality. It uses box structure
specification (formal methods) for analysis and design modeling. It emphasizes on
correctness verification rather then testing as the primary mechanism for finding
and removing errors. Statistical usage is applied to develop the failure rate
information necessary to certify the reliability of delivered software.

The clean room approach begins with analysis and design method that use box
structure representation. A box encapsulates the system or some of its aspects at a
specific level of its abstraction. BLACK BOXES (as used in aero planes) are used
to represent the extremely observable behavior of a system. State boxes
encapsulate state data and operations where as clean box is used to model the
procedural design i.e. implies by the data and operations of a state box. When the
box structure design is completed, correctness application is applied. The
procedural design for a software component is partitioned into a series of sub
functions.

In order to prove the correctness of each sub function exist, functions are defined
for each of sub functions and a set of sub proves are applied. If each exit function
condition is satisfied then the design must be correct.

Once correctness verification completed statistical usage testing starts. In a set of

usage scenarios determining the probability of use of each of the scenario and then
defining random tests that confirm to the probabilities. The error records that
results combined with compiling component and certification models to enable
mathematical computation of projected reliability for the software component

The clean room philosophy is a rigorous approach to software engineering. It is

actually a software process model that emphasis mathematical verification of
correctness and certification of software reliability. The bottom line is extremely
low failure rates which would be difficult or rather impossible to achieve using
less formal methods.

SOFTWARE REUSE (Component based software engineering)

Components reuse offers inherent benefits in software quality, developer’s
productivity and overall system cost and yet many road blocks must be overcome
before the reuse process model is widely used throughout the industry. A verity of
reused artifacts can be acquired by a software engineer. These include technical
representation of the software (e.g. specifications, architectural models, design and
code) document, test data and even process related task, i.e. inspection techniques.

REUSE PROCESS
Encompasses DOMAIN ENGINEERING
Intent of DE is to identify, construct, catalog
and disseminate a set of software artifacts in
particular domain.
Concurrent sub process SOFTWARE ENGINEER
Then extract these artifacts for reuse during the
development of a new system

Analysis and design technique for reusable components draw on the same
principals and concepts that are part of software engineering practice. Reusable
components should be design with in an environment that establishes standard
data structures, interface program and architectures for each application domain.
Components based development uses a data exchange model, tools, structures
storage and an underline object model to construct application from preexisting
components. The object model generally confirm to one or more component
standards e.g.

OMG object management group

CORBA common object request broker architecture
That define manner in which the application can access reusable objects
classification schemes enable a developer to define and retrieve reusable
components and confirm to a model that identifies concept, content and context.
Enumerated classification faceted classification and attribute value classifications
are representative of many component classification schemes.
The economic of software reuse is addressed by single question. Is it cost
effective to build less and reuse more? In general the answer is “yes” but a
software project planner must consider the non trivial costs associated with the
adaptation and integration of reusable components.

REENGINEERING: -

It occurs at two levels of abstractions

Business level
Software level

It focuses on
Business process with intent of making changes to improve
competitiveness in some area of business
 Examining information system and application with the intent of
restricting or reconstructing them so that they exhibit higher quality

Business process reengineering (BPR) defines business goals identifies and

evaluates exiting business processes. In the context of defined goals, specifies and
designs revised processes and prototypes, refines and instantiates them with in a
business. Like information engineering BPR has focus that extents beyond the
software. The result of the BRP is often the definition of the ways in which IT can
better support the business.
A software reengineering process model has a series of following activities.
Inventory analysis
Document restructuring
Reverse engineering
Program and data restructuring
Forward engineering

The intent of all these activities is to create versions of existing programs that
exhibit high quality and better maintainability. Program that would be viable well
into the coming days.
Inventory analysis enables an organization to access each application
systematically with the intent of determining the candidate elements for
engineering. Where as document restructuring creates a frame work of
documentation which is helpful and necessary for the long term support of an
application.
Reverse engineering is the process of analyzing a program in an effort to extract
data architectural and procedural design information and finally forward
engineering reconstructs a program using modern software engineering practices
and using the information learned during the reverse engineering.
The cost and benefits of reengineering can be determined quantitatively. Cost of
the status quo (i.e. the cost associated with on going maintenance of an existing
application) are compared with the projected costs of the reengineering and the
resultant reduction in maintenance costs. In almost every case in which a program
has along life but currently exhibit poor maintainability, reengineering represents a
cost effective business strategy.