Software Engineering - Lecture 02
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Software Engineering - Lecture 02

on

  • 899 views

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

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

Statistics

Views

Total Views
899
Views on SlideShare
899
Embed Views
0

Actions

Likes
0
Downloads
64
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software Engineering - Lecture 02 Presentation Transcript

  • 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