Pubs first
Download as PPT, PDF0 likes338 views
The document introduces 'Pubs First(TM)', a framework designed to categorize software aspects into performance, usability, business support, supportability, functionality, interoperability, reliability, security, testability, and time. It serves as a checklist to help assess software quality and facilitate discussions on various software features and requirements. While not revolutionary, it aims to standardize evaluations and assist in making informed decisions regarding software releases.
Pubs first
- 1. Generic Areas for Software Angles that you can use to set your brain on different gear when thinking of your software. Towo Toivola 2005-2012
- 2. Disclaimer • There is nothing revolutionary about PUBS FIRST(Tm), it is simply an extended version of FURPS. • The definitions are my own. I’m sure there are better ones, but these are good enough to be used. • The point of PUBS FIRST(Tm) aspect split is to help you in your work. Don’t use it if it bothers you. • It is generic. Thus there is always a more accurate split for your software if you wish to make one. • PUBS FIRST(Tm) split should be useful to all as a checklist. • PUBS FIRST(Tm) is useful if you need to standardize the split between very different software’s. • In theory you could just use the ‘F’ word for everything, but it wouldn’t be much of a split then, would it. Towo Toivola Page 2
- 3. PUBS FIRST P – Performance U – Usability B – Business support S – Supportability F – Functionality I – Interoperability R – Reliability S – Security T – Testability (Tm) - Time Towo Toivola Page 3
- 4. Performance is.. Ability of the software to cope with large loads and challenging tasks, the speed with witch it can handle normal tasks, and how it will perform in low-end environments. For example • Can it sort a million pictures in 10 minutes • Can it process a 1GB file • Can it find an internet page quickly enough • Can it handle 1000 simultaneous users • … Towo Toivola Page 4
- 5. User experience is.. How nice is it for intended users of the software to do whatever it is that the software is intended for. For example • Is it easy to install • Is it easy to configure • Is it easy to complete basic use- cases • Is it easy to understand the software’s purpose • Does it feel fantastic to use • … Towo Toivola Page 5
- 6. Business support is.. How well the software supports our company in doing our business? For example: •Amount/ratio of successful installs? •How many active users? •Can we up/cross-sell ? •What are users clicking? •… Towo Toivola Page 6
- 7. Supportability is.. How easy and cheap is it for your organization to support the software. For example • Is it easy for end user to contact support, describe the situation, and receive help • Is it easy to debug / fix (remotely) • Is it easy to reinstall to all customers • Is it easy and cheap to implement fixes and improvements to the software without introducing bugs • How little the software created contacts • … Towo Toivola Page 7
- 8. Functionality is.. How much of the visioned features are working properly in the software. This is the classical “does it do what was intended”. Typically people think of this first when thinking of “how ready is the software”. Some people also stop right there. That’s why TFIRPUSS is needed. Towo Toivola Page 8
- 9. Interoperability is.. How well the software co-exists with possible environments where it may be used. Includes • Co-existing with other products made by the same organization • Operating systems • Hardware • 3rd party applications that will work together with the software • Common 3rd party applications that may just happen to exist in the same system • … Towo Toivola Page 9
- 10. Reliability is.. How well you can rely on the software behaving in an expected manner. Includes • No crashes • No hangs • Same input generates same output, every time • Repeating actions many, many times does not cause a problem • No unintended feeling of random behaviour • … Towo Toivola Page 10
- 11. Security is.. How hard is it for someone to intentionally use the software to benefit illegally, or hurt you or your users. Includes.. • Functionality is only accessible to authorized users • Application will not execute unintended arbitrary commands • The software does not break any laws in the country where it is used/sold • It is hard for others to pretend to be the software • … Towo Toivola Page 11
- 12. Testability is.. How convenient is it to test the software and report problems. Includes • Availability of builds • Identifiability of builds • Tools available for testing • Debug logging clarity and availability • Installability • Controllability • Automation interfaces • … Towo Toivola Page 12
- 13. Time (Tm) is.. How much time do we have to do all this? What kind of hurry do we expect? Is timing more important than features? Or security? Or performance.. Includes.. • Absolute timing, a calendar date for release • Subjective timing: resources in relation to amount of work • The importance of timing, is it a driver or a passanger • … Towo Toivola Page 13
- 14. What’s PUBS FIRST(Tm) Good For? • Checklist when coming up with use-cases and requirements • Unified reporting of quality status • Terms for discussing different aspects of software • Checklist when designing test cases that should be run against the software • Checklist when you are thinking “Is there anything that prevents us from releasing?” • Help for creating a trade-off matrix when setting project/release goals (Time! Quality! Features!!!!) ..it does not replace common sense or good engineers, but augments them. Towo Toivola Page 14
- 15. Example Quality Status Using areas Test area Todays quality Accuracy of estimate Comments v 2.1 Testability High High Logs needing some improvement Functionality Fair Fair Interoperability High Fair Reliability Fair Low Unpacker module Performance Fair Low Unpacker module Usability Fair High Supportability Fair Low Stability of updates uncertain Security Low Fair Unpacker module Notes Test-case coverage is about: Low Test Cases drafted Goal for release: 50% Green, 50% yellow, NO RED. Towo Toivola Page 15
- 16. Levels in the Quality Situation So, what is ‘Fair’ then? This is a highly subjective matter, largely depending on the gut feeling of the QE/SM making the estimate. I could put it like this: Low: Clearly below expectations. Unacceptable for any regular delivery. Seriously needs effort. Fair: Typical software of this kind in our organization. Nothing glamorous, but doesn’t suck either. High: This attribute is in especially good shape. It will fair favourably compared to other similar software. We are proud of it. Towo Toivola Page 16