Software Engineering. Lecture No. 01. For computer Science & Engineering Syllabus. Its very useful for class study.

1. Course Code: 331
Lecture 02

2. Software Life Cycle

 “What happens in the „life‟ of software”

3. The software process

 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.

4. Software process models

 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.

5. Code and Fix (1950–)


6. Code and Fix: Issues

 No process steps – no specs, docs, tests…
 No separation of concerns – no teamwork
 No way to deal with complexity

7. Waterfall Model (1968)


8. Communication


9. 

10. 

11. 

12. 

13. Characteristics

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

14. Drawbacks

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”

15. Boehm‟s first law


16. Problem Cost


17. Incremental Model


18. 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

19. Characteristics

 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

20. Benefits

 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.

21. Drawbacks

 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.

22. Prototyping


23. Prototypes


24. Horizontal Prototype


25. Vertical Prototype


26. Prototypes

 A horizontal prototype tests a particular layer
(typically the GUI) of the system
 A vertical prototype tests a particular functionality
across all layers

27. Characteristics

 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

28. Drawbacks

 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

29. Spiral Model (1988)


30. Spiral Model

 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

31. Characteristics

 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)

32. Drawbacks

 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

33. Unified Process (1999)


34. 

35. 

36. 

37. 

38. 

39. 

40. Unified Process

 Draws on best features of conventional process
models
 Emphasizes software architecture and design
 Integrates with UML modeling techniques (more on
this later)

41. Fourth Generation
Techniques (4GT)
Requirem ents
gathering

"Design"
Strategy
Implementation
using 4GL
Testing

42. 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

43. Key points

 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