pubs first

16
Generic Areas for Software Towo Toivola 2005-2012 Angles that you can use to set your brain on different gear when thinking of your software.

Post on 22-Oct-2014

226 views

Category:

Technology


0 download

DESCRIPTION

This is a simple tool that I have found very powerful when thinking about (specsing, buying, analysing..) software systems and projects. I'm not sure did I ever give this presentation, but I think one day I will.

TRANSCRIPT

Page 1: Pubs first

Generic Areas for Software

Towo Toivola 2005-2012

Angles that you can use to set your brain on different gear when thinking of your software.

Page 2: Pubs first

Towo Toivola Page 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.

Page 3: Pubs first

Towo Toivola Page 3

PUBS FIRST

P – Performance

U – Usability

B – Business support

S – Supportability

F – Functionality

I – Interoperability

R – Reliability

S – Security

T – Testability

(Tm) - Time

Page 4: Pubs first

Towo Toivola Page 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

• …

Page 5: Pubs first

Towo Toivola Page 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

• …

Page 6: Pubs first

Towo Toivola Page 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?

•…

Page 7: Pubs first

Towo Toivola Page 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

• …

Page 8: Pubs first

Towo Toivola Page 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.

Page 9: Pubs first

Towo Toivola Page 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

• …

Page 10: Pubs first

Towo Toivola Page 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

• …

Page 11: Pubs first

Towo Toivola Page 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

• …

Page 12: Pubs first

Towo Toivola Page 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

• …

Page 13: Pubs first

Towo Toivola Page 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

• …

Page 14: Pubs first

Towo Toivola Page 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.

Page 15: Pubs first

Towo Toivola Page 15

Example Quality Status Using areasTest area Todays quality Accuracy of estimate Comments

v 2.1

High High Logs needing some improvement

Fair Fair

High Fair

Fair Low Unpacker module

Fair Low Unpacker module

Fair High

Fair Low Stability of updates uncertain

Low Fair Unpacker module

NotesTest-case coverage is about: Low Test Cases drafted

Goal for release: 50% Green, 50% yellow, NO RED.

Functionality

Interoperability

Testability

Reliability

Performance

Usability

Supportability

Security

Page 16: Pubs first

Towo Toivola Page 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.