Professional Documents
Culture Documents
CH 1
CH 1
CH 1
Software Applications
system software
application software
engineering/scientific software
embedded software
product-line software
web applications
AI software
Software Evolution
The Law of Continuing Change (1974): E-type systems must be continually
adapted else they become progressively less satisfactory.
The Law of Increasing Complexity (1974): As an E-type system evolves its
complexity increases unless work is done to maintain or reduce it.
The Law of Self Regulation (1974): The E-type system evolution process is self-
regulating with distribution of product and process measures close to normal.
The Law of Conservation of Organizational Stability (1980): The average
effective global activity rate in an evolving E-type system is invariant over product
lifetime.
Software Evolution
The Law of Conservation of Familiarity (1980): As an E-type system evolves all
associated with it, developers, sales personnel, users, for example, must maintain mastery
of its content and behavior to achieve satisfactory evolution.
The Law of Continuing Growth (1980): The functional content of E-type systems
must be continually increased to maintain user satisfaction over their lifetime.
The Law of Declining Quality (1996): The quality of E-type systems will appear
to be declining unless they are rigorously maintained and adapted to operational
environment changes.
The Feedback System Law (1996): E-type evolution processes constitute multi-
level, multi-loop, multi-agent feedback systems and must be treated as such to achieve
significant improvement over any reasonable base.
Hardware Software
Manufactured Developed/engineered
Wears out Deteriorates
Built using components Custom built
Relatively simple Complex
Ch-2
Software Engineering-Layered Technology
A quality focus:-
Any engineering approach must rest on an organizational commitment to quality.
Total quality management, Six sigma philosophies foster a continuous process
improvement culture.
Process
It enables rational and timely development.
It defines framework that must be established for effective delivery of SE
technology.
It forms the basis for management control of software projects.
• Construction :
- This activity combines code generation and the testing that is required to
uncovered errors in the code.
• Deployment:
- The software is delivered to the customer who evaluates the delivered product
and provides feedback based on the evaluation.
Prototyping
It assists you and stakeholders to better understand what is to built when
requirements are fuzzy.
Prototyping paradigm
-begins with communication.
- planned quickly and modelling occurs
- quick design focuses on a representation of those aspects of the software that will
be visible to end users.
It serves as a mechanism for identifying software requirements.
Problems
Overall software quality or long-term maintainability is not considered.
As a Software Engineer make implementation compromises in order to get a
prototype working quickly.
Useful
The customer get feel for the actual system and developers get to build something
immediately
Key here is all the stakeholders should agree that the prototype is built to serve as
a mechanism for defining requirements.
Spiral Model
Originally proposed by Barry Boehm.
It couples the iterative nature of prototyping with the controlled and systematic
aspects of water fall model.
Process is represented as a spiral rather than as a sequence of activities with
backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral are chosen
depending on what is required.
Risks are explicitly assessed and resolved throughout the process.
It is a realistic approach to the development of large-scale systems and software.
The software evolves as the process progresses, the developer and customer better
understand and react at each evolutionary level.
It uses prototyping as a risk reduction mechanism.
It demands considerable risk assessment expertise and realise on this expertise for
success.
Problems
Lack of process visibility;
Systems are often poorly structured;
Special skills (e.g. in languages for rapid prototyping) may be required.
Applicability
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.