L2 l3 l4  software process models
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

L2 l3 l4 software process models

on

  • 1,229 views

 

Statistics

Views

Total Views
1,229
Views on SlideShare
1,229
Embed Views
0

Actions

Likes
0
Downloads
18
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

L2 l3 l4 software process models Presentation Transcript

  • 1. 1Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh ““Einstein looked for a simplified definition of nature as he believed that God is notEinstein looked for a simplified definition of nature as he believed that God is not complex or arbitrary. No such belief will work for Software Engineers as Softwarecomplex or arbitrary. No such belief will work for Software Engineers as Software Engineering is complex and arbitrary” – Fred BrooksEngineering is complex and arbitrary” – Fred Brooks Lecture 2, 3 and 4Lecture 2, 3 and 4 Software ProcessSoftware Process
  • 2. The software process  A structured set of activities required to develop a software system Specification; Design; Validation; Evolution.  A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. 2Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 3. Generic software process models  The waterfall model Separate and distinct phases of specification and development.  Evolutionary development Specification, development and validation are interleaved.  Component-based software engineering The system is assembled from existing components.  They are not mutually exclusive- used together, often 3Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 4. Waterfall model Requir ements definition System and software design Implementa tion and unit testing Integration and system testing Oper ation and maintenance 4Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 5. Waterfall model phases Requirements analysis and definition Consultation with system user System and software design System design partitions the requirements to hardware or software systems software design involves indentifying and distributing software abstractions. Implementation and unit testing Unit testing involves verifying that each unit meets its specification 5Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 6. Waterfall model phases Integration and system testing Testing as a complete system. Software is delivered to customer Operation and maintenance Longest software life cycle phase. Involves correcting errors that were not discovered early, improvement of system units and evolution Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh 6
  • 7. Waterfall model benefits  The result of each phase is one or more approved documents  Fits with other process models Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh 7
  • 8. Waterfall model problems  Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.  Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.  Few business systems have stable requirements.  The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.  One phase has to be complete before moving onto the next phase- that is absent in reality where overlapping is common. 8Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 9. Waterfall model problems  Prone to Software freeze, problems are left for later resolution, ignored or programmed around.  May result inefficient software and badly structured design 9Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 10. Evolutionary development  Based on the idea of 1. developing an initial implementation 2. Exposing this to the user for comments 3. Refining and retuning through many versions until an adequate system is developed. 10Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 11. Evolutionary development  Exploratory development Objective is to work with customers to evolve a final system from an initial outline specification. Should start with well-understood requirements add new features as proposed by the customer. 11Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 12. Evolutionary development  Throw-away prototyping Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed. Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh 12
  • 13. Evolutionary development Concurr ent activities Valida tion Final version Development Intermedia te versions Specification Initial version Outline description 13Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 14. Evolutionary development  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. 14Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 15. Component-based software engineering  Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.  Happens when people working on project know of designs or code which is similar to that required  This approach is becoming increasingly used as component standards have emerged. 15Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 16. Component-based software engineering  Process stages Component analysis ○ What components are required, what are available Requirements modification ○ Not exactly what you need is found, so would you use that or modify your requirements? System design with reuse ○ Design the system in a way so that others are able to reuse your system Development and integration ○ Combining all of the reusable components Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh 16
  • 17. Benefits of CBSE  Quick development  Low cost Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh 17 Drawbacks of CBSE  Mostly never meets requirements  Needs expert knowledge on component analysis, reusability and integration  Less innovation  More or less depends on the pros and cons of the components.
  • 18. Reuse-oriented development Requirements specification Component analysis Development and integ ration System design with reuse Requirements modification System validation 18Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 19. Incremental delivery  An in-between approach that combines waterfall and evolutionary model  Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.  User requirements are prioritised and the highest priority requirements are included in early increments.  Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. 19Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 20. Incremental delivery Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh 20 Valida te increment Develop system increment Design system architectur e Integrate increment Validate system Define outline requirements Assign requirements to increments System incomplete Final system
  • 21. Incremental development advantages  Customer value can be delivered with each increment so system functionality is available earlier.  Early increments act as a prototype to help elicit requirements for later increments.  Lower risk of overall project failure.  The highest priority system services tend to receive the most testing.  User engagement with the system  Accelerated delivery of customer services 21Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 22. Incremental development disadvantages  Increments should be relatively small (20,000 LoCs)  Each increment should provide system functionality  Difficult to map customer’s requirements onto increments of right size  Hard to identify common facilities that are needed for all increments 22Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 23. Incremental development disadvantages  Progress can be hard to judge and problems hard to find because there is no documentation to demonstrate what has been done.  The normal contract may include a specification; without a specification, different forms of contract have to be used.  Without a specification, what is the system being tested against?  Continual change tends to corrupt software structure making it more expensive to change and evolve to meet new requirements. 23Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 24. Spiral development  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. 24Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 25. Spiral model of the software process Risk anal ysis Risk anal ysis Risk anal ysis Risk anal ysis Proto- type 1 Prototype 2 Prototype 3 Oper a- tional protoype Concept of Oper ation Simulations , models , benchmar ks S/W requir ements Requir ement validation Design V&V Product design Detailed design Code Unit test Integ ration test Acceptance testService Develop , verify next-level pr oduct Evalua te alterna tives, identify, resolv e risks Deter mine objecti ves, alterna tives and constr aints Plan ne xt phase Integ ration and test plan Development plan Requir ements plan Life-cy cle plan REVIEW 25Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 26. Spiral model sectors  Objective setting Specific objectives for the phase are identified.  Risk assessment and reduction Risks are assessed and activities put in place to reduce the key risks.  Development and validation A development model for the system is chosen which can be any of the generic models.  Planning The project is reviewed and the next phase of the spiral is planned. 26Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 27. Agile methods  Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods:  Focus on the code rather than the design;  Are based on an iterative approach to software development;  Are intended to deliver working software quickly and evolve this quickly to meet changing requirements.  Agile methods are probably best suited to small/medium-sized business systems or PC products. 27Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 28. Principles of agile methods 28Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 29. Problems with agile methods  It can be difficult to keep the interest of customers who are involved in the process.  Team members may be unsuited to the intense involvement that characterises agile methods.  Prioritising changes can be difficult where there are multiple stakeholders.  Maintaining simplicity requires extra work.  Contracts may be a problem as with other approaches to iterative development. 29Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 30. Extreme programming  Perhaps the best-known and most widely used agile method.  Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is only accepted if tests run successfully. 30Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 31. The XP release cycle Breakdown stories to tasks Select user stories for this release Plan release Release software Evaluate system Develop/integ rate/ test software 31Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 32. Extreme programming practices 1 Incremental planning Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these Stories into development ŌTasksÕ. Small Releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple Design Enough design is carried out to meet the current requirements and no more. Test first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable. 32Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 33. Extreme programming practices 2 Pair Programming Developers work in pairs, checking each otherÕs work and providing the support to always do a good job. Collective Ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers own all the code. Anyone can change anything. Continuous Integration As soon as work on a task is complete it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of over-time are not considered acceptable as the net effect is often to reduce code quality and medium term productivity On-site Customer A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation. 33Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 34. XP and agile principles  Incremental development is supported through small, frequent system releases.  Customer involvement means full-time customer engagement with the team.  People not process through pair programming, collective ownership and a process that avoids long working hours.  Change supported through regular system releases.  Maintaining simplicity through constant refactoring of code. 34Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 35. Requirements scenarios  In XP, user requirements are expressed as scenarios or user stories.  These are written on cards and the development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates.  The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates. 35Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 36. Story card for document downloading Downloading and printing an article First, you select the article that you want froma displayed list.You then have to tell the systemhow you will pay for it - this can either be through a subscription, through a company account or by credit card. After this, you get a copyright formfromthe systemto fill in and, when you have submitted this, the article you want is downloaded onto your computer. You then choose a printer and a copy ofthe article is printed.You tell the systemifprinting has been successful. Ifthe article is a print-only article, you canÕt keep the PDF version so it is automatically deleted fromyour computer. 36Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 37. Testing in XP  Test-first development.  Incremental test development from scenarios.  User involvement in test development and validation.  Automated test harnesses are used to run all component tests each time that a new release is built. 37Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 38. Task cards for document downloading Task 1: Implement principal workflow Task 2: Implement article catalog and selection Task 3: Implement payment collection Payment may be made in 3 different ways.The user selects which way they wish to pay. Ifthe user has a library subscription, then they can input the subscriber key which should be checked by the system.Alternatively, they can input an organisational account number. Ifthis is valid, a debit ofthe cost ofthe article is posted to this account. Finally, they may input a 16 digit credit card number and expiry date.This should be checked for validity and, if valid a debit is posted to that credit card account. 38Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 39. Test case description Test 4:Test credit card validity Input: Astring representing the credit card number and two integers representing the month and year when the card expires Tests: Check that all bytes in the string are digits Check that the month lies between 1 and 12 and the year is greater than or equal to the current year. Using the first 4 digits ofthe credit card number, check that the card issuer is valid by looking up the card issuer table. Check credit card validity by submitting the card number and expiry date information to the card issuer Output: OK or error message indicating that the card is invalid 39Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 40. Test-first development  Writing tests before code clarifies the requirements to be implemented.  Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly.  All previous and new tests are automatically run when new functionality is added. Thus checking that the new functionality has not introduced errors. 40Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 41. Pair programming  In XP, programmers work in pairs, sitting together to develop code.  This helps develop common ownership of code and spreads knowledge across the team.  It serves as an informal review process as each line of code is looked at by more than 1 person.  It encourages refactoring as the whole team can benefit from this.  Measurements suggest that development productivity with pair programming is similar to that of two people working independently. 41Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 42. Rapid application development  Agile methods have received a lot of attention but other approaches to rapid application development have been used for many years.  These are designed to develop data- intensive business applications and rely on programming and presenting information from a database. 42Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 43. RAD environment tools  Database programming language  Interface generator  Links to office applications  Report generators 43Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 44. A RAD environment DB prog ramming langua ge Interface gener ator Office systems Repor t gener ator Database mana gement system Rapid application development environment 44Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 45. Visual programming with reuse File Edit Views Layout Options Help General Index Menu component Date component Range checking script Tree display component Draw canvas component User prompt component + script 12th January 2 000 3.876 45Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh
  • 46. ReferenceReference  Software Engineering by Ian Sommerville, Chapter 4 and 17, 7th Edition. Rushdi Shams, Lecturer, Dept of CSE, KUET, Bangladesh 46