Software Engineering - Lecture 02
-
Upload
asifuzzaman-hridoy -
Category
Education
-
view
971 -
download
3
description
Transcript of Software Engineering - Lecture 02
Software Engineering
Course Code: 331Lecture 02
“What happens in the ‘life’ of software”
Software Life Cycle
A structured set of activities required to develop a
software system. Many different software processes but all involve:
Specification – defining what the system should do; Design and implementation – defining the organization of
the system and implementing the system; Validation – checking that it does what the customer wants; Evolution – changing the system in response to changing
customer needs. A software process model is an abstract representation of
a process. It presents a description of a process from some particular perspective.
The software process
The waterfall model
Plan-driven model. Separate and distinct phases of specification and development.
Incremental development Specification, development and validation are interleaved.
May be plan-driven or agile. Reuse-oriented software engineering
The system is assembled from existing components. May be plan-driven or agile.
In practice, most large systems are developed using a process that incorporates elements from all of these models.
There are no right or wrong software processes.
Software process models
Code and Fix (1950–)
No process steps – no specs, docs, tests… No separation of concerns – no teamwork No way to deal with complexity
Code and Fix: Issues
Waterfall Model (1968)
Communication
The classic life cycle - oldest and most
widely used paradigm Known as “Linear sequential model” Activities ‘flow’ from one phase to
another If there are corrections, return to a
previous phase and ‘flow’ from there again
Major advantages: Good for planning and well-defined/repeated projects
Characteristics
Real projects rarely follow a sequential
flow Hard to state all requirements explicitly No maintenance or evolution involved Customer must have patience Any blunder can be disastrous Leads to “blocking states”
Drawbacks
Boehm’s first law
Problem Cost
Incremental Model
Each linear sequence produces a particular
“increment” to the software First increment typically core product; more
features added by later increments Allows flexible allocation of resources
Incremental Model
Software separated into different “increments”
- complete working portions Focus on delivery of operational product with
each increment - can be evaluated Useful when insufficient staff and can be
planned to manage technical risks, e.g. waiting for new hardware
Characteristics
The cost of accommodating changing
customer requirements is reduced. It is easier to get customer feedback on the
development work that has been done. More rapid delivery and deployment of useful
software to the customer is possible.
Benefits
The process is not visible.
Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.
System structure tends to degrade as new increments are added. Unless time and money is spent on refactoring to
improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.
Drawbacks
Prototyping
Prototypes
Horizontal Prototype
Vertical Prototype
A horizontal prototype tests a particular
layer (typically the GUI) of the system A vertical prototype tests a particular
functionality across all layers
Prototypes
Developer and customer determine objectives
and draft requirements Prototype quickly produced and evaluated by
customer Prototype then refined, and re-evaluated Process iterated, before final product
development Advantages: Customer participation and
better requirements
Characteristics
Customer may see prototype as working
model and expects fast results Developer compromised when producing
prototype quickly, e.g. different operating system or programming language
Drawbacks
Spiral Model (1988)
System is developed in series of evolutionary
releases Milestones for each iteration of the spiral Process does not end with delivery Reflects iterative nature of development
Spiral Model
Originally proposed by Boehm, couples
iterative nature of prototyping and the systematic aspects of waterfall model
Software is developed in series of incremental releases
Each iteration produces a more complete product
Better management through risk analysis(Modeling)
Characteristics
May be difficult to convince customers that
evolution is controllable Demands risk assessment expertise - major
risk will cause problems if not identified Relatively new and not widely used - cannot
determine performance
Drawbacks
Unified Process (1999)
Draws on best features of conventional
process models Emphasizes software architecture and design Integrates with UML modeling techniques
Unified Process
Fourth Generation Techniques (4GT)
"Design" Strategy
Testing
Requirements gathering
Implementation using 4GL
4GT Characteristics
Use of software tools that allow software engineer to specify s/w characteristics at higher level
The tools generate codes based on specification
More time in design and testing - increase productivity
Tools may not be easy to use, codes generated may not be efficient
Software processes are the activities involved in producing a software system.
Software process models are abstract representations of these processes.
General process models describe the organization of software processes. Examples of these general models include the ‘waterfall’ model, incremental development, and reuse-oriented development.
Requirements engineering is the process of developing a software specification.
Design and implementation processes are concerned with transforming a requirements specification into an executable software system.
Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.
Software evolution takes place when you change existing software systems to meet new requirements. The software must evolve to remain useful.
End
Key points