1 / 39

George Blank University Lecturer

George Blank University Lecturer. CS 602 Java and the Web. Object Oriented Software Development Using Java Chapter 9. Iterative Development. This chapter of the text is an introduction to iterative development with a case study to illustrate it.

lindsay
Download Presentation

George Blank University Lecturer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. George Blank University Lecturer

  2. CS 602Java and the Web Object Oriented Software Development Using Java Chapter 9

  3. Iterative Development • This chapter of the text is an introduction to iterative development with a case study to illustrate it. • Grady Booch of Rational Software has stated that the critical idea in the Rational Unified Process is Iterative Development.

  4. A Working Product • The output of every iteration is working code. The first iteration may not do much, but it is complete, testable, executable, and deliverable.

  5. Iterative Development • Iterative Development is successively enlarging and refining a system through multiple iterations, using feedback and adaptation. • Each iteration will include requirements, analysis, design, and implementation. • Iterations are timeboxed.

  6. Timeboxing • Timeboxing is a best practice in which the deadline is not flexible. If the team cannot finish within the scheduled time, features are eliminated in order to produce some working code by the deadline. • There are several good reasons for timeboxing.

  7. Motivation for Timeboxing an Iteration • Parkinson’s Law “Work expands so as to fill the time available for its completion.” The team has to focus, make decisions to make available executable and tested system on a given date. Otherwise resources are wasted and little is accomplished.

  8. Enforcing Priorities • Prioritization and Decisiveness Short timeboxed iterations force a development team to make decisions regarding the priority of work and risks, identify what is of the highest business or technical values.

  9. Happy Teams • Team Satisfaction The team should finish a set target everyday which gives a psychological advantage for individual and team satisfaction. This is better than lingering on things for months.

  10. Maintaining Support • Stakeholder Confidence Completing the system in a set time span which gives confidence to the stakeholder of the system for future projects. Projects that lose the support of the stakeholders are frequently cancelled.

  11. Managing Risk • A key purpose of iterative development is managing risk. Usually the riskiest part of development is done first, so that if a disastrous risk event occurs, time has not been wasted on activities that have no remaining value.

  12. The Greatest Risk • The greatest risk in any software is almost always that it will not fulfill its main purpose. For example, most people use an ATM to withdraw money. Since that is the main function, if it does not work, the whole system must be considered a failure. • Therefore, to develop an ATM, work on cash withdrawal first. (The highest risk) After that, worry about less used functionality such as making deposits and balance inquiries.

  13. Critical Tasks • Since the greatest risk is always a quality risk, that the system will not accomplish its main purpose or critical task, it is important for team members to know what aspect of the delivered product is critical for customer satisfaction. • For example, most people only pay attention to a bridge when it is washed away or closed for repairs. They are usually more interested getting across the river than admiring the bridge.

  14. Risk Case Study • To illustrate the importance of risk driven development focused on critical tasks, I want to give an example based on one of the most incompetent software designs I have ever encountered. • It is not an accident that this program was developed for government use, as government tends to have lower quality standards than commercial users. It is a public library Internet catalog developed by SirsiDynix, a company that makes a good living selling bad software to government users.

  15. The Critical Task • For the critical task, we should consider the main reason that someone would want to use an Internet library catalog. That task would be to request a book. While there are enough flaws in this program to be analyzed for a full semester course, we will look only at the process of requesting a book.

  16. Case Study • The case study is the automated on-line catalog of the Morris County, New Jersey library system, called the Morris Automated Information Network, and available at http://catalog.mainlib.org/ . • Actually, the search screen, the main entry point for the system, is quite good, suffering mainly from being too busy, as shown on the next page.

  17. M.A.I.N. Search Page

  18. Example • To illustrate a search, imagine that you are looking for a book by Tom Clancy, but do not remember the name of the book. So you do an “author” search on Tom Clancy. • The next screen shows the result. Note that the results are listed by publication date (which is neither announced nor selectable by the program) and there are 233 entries, or 12 pages of material to look through at 20 items per page.

  19. Partial results from search

  20. Process • Note that there are two options listed beside each book, “Details” and “Keep.” While neither indicates that you can reserve the book (the critical task), “Keep” seems close. • After laboriously paging through 12 pages and finding three books you are interested in, marking them “Keep,” you try to figure out what to do next. You see an option for “Kept” at the top of the page, so you select that.

  21. Kept List

  22. Dead End • Now what do you do? • The answer is “Start Over.” There is absolutely no way to reserve a book on your kept list! The best you can do is print out the list and take it to the library and ask the librarian to reserve it for you.

  23. Actual Process • If instead of selecting “Keep” you had selected “Details,” you would have come to a separate page for each book. While you still do not have an option to reserve a book, if you look closely at the small print, you will see that you can “place hold” on this book. This is actually the way to reserve the book, although there are several more steps, including reentering your 13 digit library card number and your pin number and your local library separately for each book you reserve. See the following pages.

  24. Book Page Place Hold

  25. Place Hold Screen

  26. The Final Insult • Note that it is only after a long and frustrating process including an unrecoverable dead end that you discover that you need a pin number to reserve a book. You will probably decide that it is easier to go buy the book at a book store than it is to use the library! • All of this frustration could have been avoided if the developer had focused on the critical task and made sure that it was easy to accomplish.

  27. Risk Driven Development • Iterative Development is thus also Risk Driven Development. The highest risks are eliminated before time, effort, and money are spent on activities with less value and risk. As risks are eliminated, confidence in the project increases. If a risk event forces redesign or cancellation of the project, a minimum of time and money has been wasted.

  28. Three Main Risks in Software Development • Quality • Will the system do a good job of meeting the need for which it is being developed? • Schedule • Will the system be completed when it is needed and while resources are available? • Budget • Can the system be finished with the money allocated and will it deliver value for that cost?

  29. Value Delivered • By doing the critical task first, you ensure that the customer will see value in the product before spending a great deal of money. This creates a better customer relationship which tends to inspire the entire development team. No one likes to “work in the dark,” where you don’t know whether anything you do matters. • It is always easier to work when you are getting positive reinforcement from supervisors and clients.

  30. Importance of Feedback • With iterative development, the customer sees each iteration, and changes can be made while that can still be done without a major impact on cost and schedule. • Before iterative development, a customer only saw the final product, and the normal reaction was some variation on; “I don’t really know what I want, but that is not it!” There is much higher customer satisfaction when the customer sees intermediate products.

  31. Refactoring • Section 9.4 of the text gives a good case study of the refactoring process. • Refactoring is a key opportunity in object-oriented development. Because objects are small and self-contained with well-defined interfaces, changes have limited impacts on the system. You should consciously seek to improve existing code.

  32. Factory Design Pattern • Section 9.5.6 discusses the Factory Method design pattern. Several variations on Factories have become widely used design patterns. • You have probably already used a JUnit TestSuite factory method when you developed a test suite for the chapter 6 homework.

  33. Factory Pattern (Gang Of Four) • Context/Problem • Who should be responsible for creating objects when there are special considerations, such as complex logic,a desire to separate the creation responsibilities for better cohesion, and so forth? • Solution • Create a Pure Fabrication object called a Factory that handles the creation.

  34. Advantages of Factory Objects • Separate the responsibility of complex creation into cohesive helper objects. • Hide potentially complex creation logic • Allow introduction of performance-enhancing memory management strategies,such as object caching or recycling.

  35. A Simple Factory Pattern Source: Muhammad Mosa, Simple Factory Pattern side by side with Abstract Pattern, http://www.c-sharpcorner.com/

  36. Microsoft Class Factories • Microsoft uses class factories as a basic technology for instantiating objects in Active X, the Component Object Model (COM and COM+) and in Dot Net. • It is a very basic design pattern that is very effective.

  37. Drawing Pad Application • The other important part of this chapter is illustrating the various Java widgets and their use. The use of layouts, various components and action listeners are important skills for this class. I suggest that you might get more out of the drawing pad exercise if you type it in yourself and modify it to your own tastes instead of getting it from the author’s web site.

  38. These are useful tools! • The code that you use and develop in this class will help you create a personal code library that will provide a good starting point for many of your future projects. • I recommend that you develop a personal CD of code for future use. I did that throughout my career and it was a great help to me professionally.

  39. Bibliography • Jia, Xiaoping, Object Oriented Software Development Using Java. Addison Wesley, 2003

More Related