1 / 37

Working Products

Working Products. Lecture 3 CIS 6101 – Software Processes and Metrics. Introduction. A working product at all times should be the ultimate goal for every software team. If far away, it’ll take time to get product back to a working state.

aretha
Download Presentation

Working Products

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. Working Products Lecture 3 CIS 6101 – Software Processes and Metrics

  2. Introduction • A workingproductat all times should be the ultimate goal for every software team. • If far away, it’ll take time to get product back to a working state. • Working Product does not mean product is feature complete or that all features are done. • Idea is to (if appropriate) show to customer (maybe for use) with the minimum possible number of unexplainable errors. • Such working products are said to be ‘essentiallyshippable,’ because the product could be shipped after a short period of verification testing and stabilization. • Team must keep product in a working state because a working product imparts greater flexibility and agility.

  3. Working Product vs Working Software • Working Product is meant to include not only the working software (commonly-used term) but also other • explicitdeliverables such as documentation, supporting infrastructure / web-site info and • implicitdeliverables such as expectation that there has been testing before the customer sees the product. • Working Software is thus only a part of the working product.

  4. Working Product Every Day • A working product is an underpinning of agile software development. • Agile development demands ability to get continual customer feedback. • Only way is to keep customers interested and provide workingsoftware on a regular basis. • Says to customers that ‘this’ is a product they can rely upon. • Working product gives the team an incredible amount of flexibility • to change directions and ability • to take / ship current version of software w/critical features the market demands. • Gives ‘power’ to development team from • Feeling in control, and using that control to respond to changing situations.

  5. Working Product Every Day • By having a working product everyday and fixingdefectsasyougo : • allows teams to focus on the customers, • reduces the buildup of technical debt in the product, because chances are very high that problems are caught as soon as possible. • All attempts must be made to prevent defects from reaching people whether they are testers or customers.

  6. Working Products and Quality • To keep a product in a working state, teams need to focus on the quality of everything they do! • When product is in a non-working state and changes are being made to it, technical debt is accumulating – a debt to be repaid later.. • Cost of fixing errors increases with time • As well as increased probability multiple problems will show up in the final product

  7. Putting Things into Perspective • To the team: What does it mean to ‘ship’ product every day to customers? • Ship means provide daily updates or a complete new version of the software to install. • Here are some issues:

  8. Issues Shipping Every Day (1 of 4) • Quality Assurance and Testing become critical • Ship every day? • One person cannot do all testing  automate as much testing as possible • Implies designing product and features for testability now as opposed to testing later. Need people available.

  9. Issues Shipping Every Day (2 of 4) • Is your documentation and web site going to be ready to reflect the new changes every day? • Need to work out automated way of updated web site while ensuring documentation • can be loadedoff the Internet and not just the local hard drive (i.e., updated live)

  10. Issues Shipping Every Day (3 of 4) • Must have your act together: • What happens when customer finds problem? • How to report to you? How to prioritize for urgent fixes? • How to minimize chances defect is fixed reliably w/o breaking something else? • When customer reports problem, • How to let customer know status of fix? • Let them know status of defect on line and when to expect fixes?

  11. Issues Shipping Every Day (4 of 4) • How to develop features that take a long time? • Wrong answer: wait until feature is complete and integrate • Find way to integrate features in piecemeal while ensuring product still works while telling users what to expect every day. • Get input from customers on the new features as they progress. • What if critical feature breaks in a daily release? • Customers must be able to easily report problem to you and back up to the prevoius day’s version while they wait for a fix. • Now you need to demonstrate responsiveness to your customers, because this is costing them money and time.

  12. Goal of Exercise – Ship Frequently • Ship product to customers as frequently as possible. • Shipping encourages teams to minimize their overhead while maximizing productivity so they can ship frequently and implement the features the customers need. • Shipping often is the ultimate goal. • May be only possible to ship once a week or once a month • Avoid only being able to ship a couple of times a year. • Important to ship and get your software installed and used on real problems as frequently as possible.

  13. Examples – Several Update Very Frequently • Eclipse – a reliable update mechanism is built into the software so that updates can be made at any time. • Renderware is a commercial game engine produced by Criterion that ships weekly • NortonAnti-Virus is updated whenever a new virus has been detected on the Internet • Microsoft regularly provides updates to Windows and Office tools. Its updates work.

  14. Counter Examples: Mission-Critical Apps • Not too practical for mission-critical systems where systems must be installed only after considerable caution. • But most systems are NOT mission-critical.

  15. Practices for Working Products • 1. No Broken Windows (read on your own) •  2. Be uncompromising about Defects! •  3. Barely Sufficient Documentation

  16. Practice 1 – No Broken Windows • Easy to make changes in a sloppy, haphazard way. • Once one sloppy change has been made, others will follow. • Never start the decay. • Clean up bad code immediately. • Ugly workarounds cause problems and are a symptom that the product is most likely not in a working state.

  17. Practice 2 – Be Uncompromising about Defects • Avoid a defect backlog! (List of Open Defects) • Defect backlogs burden teams with repetitive searching, sorting, categorizing tasks • Huge maintenance / management tasks here too! • Takes away from productive work. • A defect backlog makes it more difficult to find defects that MUST be fixed.

  18. Practice 2 – Defect Backlog – continued (2 of 3) • A defect backlog is a strong indicator • new features are being developed on top of defective code. • Longer the backlog: • greater probability backlog may never be eradicated. • greater probability defects shipped to customers. • greater time between defect introduced and fixed. the greater the cost to fix it.

  19. Practice 2 – Defect Backlog – Continued (3 of 3) • Be ruthless. • Decide to quickly fix it or mark that you won’t. • Once decided to fix, do so as quickly as possible. • Fix regressions immediately! • Do before any other changes are made to product. • Fix all known defects in a new feature before moving on to work on the next feature.

  20. Practice 3: “Barely Sufficient” Documentation (1 of 3) • So teams can concentrate on a working product, produce a minimal amount of time writing documents that are not part of the product, such as requirements and design documents. • Note: Talking about minimizing ‘internal documentation.’) • Externaldocumentation such as help and feature documentation is required by customers and should be considered as features. • Barely Sufficient Documentation is a feature of agile development.

  21. Practice 3: “Barely Sufficient” Documentation (2 of 3) • Sometimes documentation is required before a project can move on • But this imposes a linearity in development which is unhealthy and unrealistic. • Focus on what matters the most: working products. • Many projects work for years understanding requirements and writing documents before any product or code. • Customers don’t really know what they want until they see it.

  22. Practice 3: “Barely Sufficient” Documentation (3 of 3) • Examples of Barely Sufficient documentation: • Use of index cards for feature description • To describe essential facts • Gives something tangible for hands to discuss. • Collection of feature cards • Should be adequate documentation of requirements. • Design software collaboratively in front of a whiteboard. Great discussions! • Alternatively, use a sketchbook. • Put design details like relationships and code rationale w/source code (where it can easily be kept up to date) and extract them when using a tool such as JavaDoc.

  23. Dangers of Excessive Documentation • In a heavyweight development process, every feature had to be documented – every requirement, functional specifications, design documents, written test plans… bookshelves where kept. • Review meetings held for each document. • Progress was very slow – revising, reviewing…

  24. Practices for Working Products •  4. Continuous Integration •  5. Nightly Builds •  6. Prototypes

  25. Practice 4: Continuous Integration • Continuously integrate changes together. • Frequent integration ensures modules fit, and product continues to work with the changes. • Developers should integrate their work every day or many times a day. • Naturally, your team needs automated testing to help catch integration problems.

  26. Practice 5: Nightly Builds • Completely build your software one or more times per day including as many automated tests as possible to catch integration problems early. • Should be an installable product image always ready. • If build fails, fix first thing in morning! • No further integration until fix is done!! • Builds should be fast; • if not, something is wrong with the structure of the product; module dependencies, modules too large; worst of all, duplicated or unnecessary code

  27. Practice 6 – Prototyping • Prototype solutions to risky problems • helps increase chance of having a working product. • Prototyping is an inexpensive way to try out new ideas so that successful implementation is more likely later.

  28. Practice 6 – Prototyping the ‘True Prototype’ • The True Prototype • Here we test an implementation is used to understand a problem before it is implemented for real. • Prototype to get understanding of the risk • Perhaps prototype a solution to a problem to gain greater confidence you understand the problem. • Great for trying out risky features! • You also have an implementation to borrow from, even if it is only ideas, when implementing the complete solution. • Doesn’t have to be software • Can be a paper prototype, white board, w sticky notes for buttons / pull-down menus..

  29. Practice 6 – Prototyping the ‘True Prototype’ • A prototype is a quick and dirty implementation that explores key target areas of a problem. • Should not be production ready nor complete implementation of desired solutions. • Use as a reference only when implementing the complete solution to a problem. • Might even be implemented in a scripting language such as Python or Ruby to save time. • But recognize that they are a point of reference only when implementing the complete solution to a problem. • Downside – show to customers to demonstrate progress; they feel product appears done – even though some of what they see may be hardcoded!

  30. Practices for Working Products • 7. Don’t neglect Performance • 8. Zero Tolerance for Memory and Resource Leaks •  9. Coding Standards and Guidelines

  31. Practice 7 – Don’t Neglect Performance • Passionate feelings: • Some: strive for code clarity more than performance; then optimize the one to three percent of code that needs it. • Others: code for performance first, because if you don’t, you code will always be slow. • Code clarity should be first, but not at the expense of performance. • You must be concerned with performance and with clarity, with a strong bias toward the latter.

  32. Practice 8: Zero Tolerance for Memory and Resource Leaks • If your environment (language, environment) does experience leaks, have zero tolerance! • Resource leaks lead to unpredictable behavior such as program crashes, that can be exploited by hackers to compromise your customer’s computers. • Unfortunately, some lower level APIs that your application may use may leak memory. • Can only report to vendor • You might free allocated resources if you can; sometimes you cannot. • Sometimes in large applications when they stop it may take time for the OS to recover the available memory. • Lots of issues here. • Try to avoid memory leaks as much as you can. • We have today APIs that can hook up to your application to start and stop leak detection. • Note: no memory leak is acceptable. Not true that only the big ones count. A leak can put up a fence around the application’s primary memory such that the system cannot reuse that memory. Not good.

  33. Practice 9 – Coding Standards and Guidelines • What is good code and what coding practices team members like / dislike. • Get team members to agree on practices / conventions; consistent coding conventions that make code easier to read / understand. • Useful for others who join the team, as these will likely not be updated. • USAF: AFDSDC 300-8; The Software Development Process. • AFM 300-4, Data Elements and Codes.

  34. Practice 10 – Adopt Standards • Don’t reinvent the wheel. • Reuse as much as possible via ‘value-added.’ • One plum nowadays is Open Source. Lots of software available. • What Open Source is doing is significant. • Solutions can be offered. • Look at IBM: Eclipse IDE is open source project, but Ibm also uses Eclipse as a foundation for its own commercial products and allows third parties to develop their own commercial products on top of Eclipse. Being a free IDE has created a large community of developers who are comfortable with Eclipse and are also potential buyers of IBM’s other tools.

  35. Practices for Working Products •  11. Internationalize from the Start •  12. Isolate Platform Dependencies

  36. Practice 11 – Internationalize from Day One. • Get into the habit of ensuring your products are internationalized. • No extra overhead once you learn what is required. • Most growth is expected outside of English-speaking nations. • Implication is obvious. Think globally!

  37. Practice 12 – Isolate Platform Dependencies • If your code must support multiple platforms, a clean separation between • platform-specific code and • all the other code • is essential to have software that can be easily kept in a working state. • Examples dependencies: • operating systems, graphic subsystems, runtime environments, libraries, and user interface toolkits. • Isolate platform dependencies via an abstract interface, such as a Façade design pattern) to that the majority of the software is isolated from the platform-dependent code.

More Related