VCE IT Theory Slideshows 2011+

By Mark KellyMcKinnon Secondary College

Vceit.com

PSM - Problem Solving Methodology

Contents

• The Steps• Analysis• Design• Development– Testing– Documentation

• Evaluation

Causes of information problems

• Here are some examples• See the PSM Analysis Activities slideshow

PSM• The “Problem Solving Methodology”

(PSM) is a model of steps to take when solving a problem.

The Official 2011 VCAA Glossary’sComplete PSM Steps

• Analysis

• Design• Development• Evaluation

The missing steps

• Documentation is not a separate step (but it is still done: it’s put under the development heading)

• (Informal) Testing also occurs during development.

MIA

• There is no formal testing phase in the new PSM.

• Implementation is also not mentioned.

ANALYSIS

Analysis

• Investigates the problem before attempting to solve it.

• Observe the existing system before doing anything else

• Like a doctor examines you before prescribing pills or surgery

Observing• Measure the

system’s performance

• Interview users• Refer to system logs

(e.g. errors, complaints, repairs)

• Examine system’s output

First question to ask• Is there really a problem?• Sometimes, there is no problem: that’s the best

the system can do• E.g. your home wireless network is not reaching

the claimed 54Mbps transfer speed mentioned on the box

• Not a problem: that’s only a theoretical maximum which is never likely to be actually achieved.

Don’t bother

• Can’t solve problems that don’t actually exist• But you can waste a lot of time and money

trying.

Second question • Can it be fixed?• Technical feasibility• Some problems

cannot be fixed, e.g. a horse’s broken leg.

• Pointless to even try.• Don’t waste time and

money on a hopeless cause.

Third question• Is it worth fixing?• Economic feasibility• Some problems are not worth the necessary

time, money and effort

• You can maybe get a pushbike to do 150km/h but surely it’s easier to get a motorbike instead?

And more questions

• Legal feasibility – can you fix it without breaking any laws?

• Operational feasibility – if you fix it, do you have the staffing, equipment, skill base, money etc to continue to operate it?

Scope of the solution• What can the solution do? • What can't the solution do? • The boundaries or parameters of the solution. • How will the solution benefit the user?

Constraints• What conditions need to be considered when

designing a solution? E.g. – cost, – speed of processing, – requirements of users, – legal requirements, – security, – compatibility, – level of expertise, – capacity, – availability of equipment

If the answers are not all “YES”

• GIVE UP• Cancel the project• Better to give up now than to proceed and

waste far more time and money on a doomed project.

Determine solution requirements

• What information does the solution have to provide?

• What data is needed to produce the information?

• What functions does the solution have to provide?

Solution Requirements

• Put into a logical design.• Lays down the specifications of the new or

modified system.• Specifies what it should be able to achieve.

Logical Design

• Like a “wish list” of features• Only lists specifications, e.g. “should be able

to produce 20,000 invoices in 2 hours with 99.9% accuracy”

But

• The logical design does not attempt to say how these objectives will be achieved.

• Don’t jump to conclusions about what software, hardware etc will be needed.

• Just define what you want it to do.

These requirements can be

• Functional - what the solution is required to do• Non-functional, which attributes the solution

should possess, such as– user-friendliness, – reliability, – portability, – robustness, – maintainability.

ToolsLogical design tools to assist in determining the

solution requirements include ...• context diagrams, • data flow diagrams and • use case diagrams• Logical Data Dictionaries (e.g. “What data

should be in a sales contract?• Hierarchy Charts / Organisational chart• Decision Trees

If all the answers are “YES”...

• All data collected during analysis needs to be documented for later reference.

• Each step in the PSM must be fully and properly finished before the next step begins

Finally• The client, or boss, gives approval to move

onto the next step: design

DESIGN

Design...

• How the solution will work• What interfaces and outout will look like

Need to design

• Hardware needs• Software needs• Training and documentation requirements• Procedures that need to be created or

changed• Evaluation criteria

Tools

• data dictionaries and data structure diagrams, • input-process-output (IPO) charts,• flowcharts, • pseudocode, • object descriptions.

Designing how bits of the solution fit together – e.g.

• Website pages, style sheets, scripts; • Database queries, forms, reports; • Program modules, procedures, functions.

Useful tools for this• Website: storyboards, site maps• Database: entity-relationship diagrams, data

flow diagrams, structure charts, • Multipurpose: hierarchy charts, context

diagrams, use cases.

Design• Consider alternative designs• More than one way to skin a cat• Some designs may be technically great,

but unacceptable because of constraints

Design

• Every solution has both pros and cons• What’s acceptable to a developer might

be impossible for the client• Selecting a design strategy means

achieving maximum “pros” with minimum “cons”

• What is a pro or con varies from client to client

Physical Design Tools

• These actually plan how to build a system

• They give instructions on what to do–Physical data dictionaries (e.g.

“Customer_Surname is string, 25 characters”)–Data Flow Diagrams...

Physical Design Tools

–Storyboards–Flow Charts, Nassi-Shneiderman charts–Structure Charts–IPO charts –Layout diagrams / mockups –Pseudocode

Designing appearances

• layout diagrams, • annotated diagrams/mock ups• prototypes

Designing the evaluation criteria

• What measures will be used to judge whether or not the solution requirements have been met?

• Should relate to the solution requirements identified in the analysis stage’s logical design.

Design

• Must be documented• If successful, will lead to Development

phase. If not, cancel the project.• Is used as a strict instruction manual

during the following phases, particularly during…

DEVELOPMENT

Development

• Often involves a coordinated team using project management to monitor their progress and manage their actions and resources.

Acquire equipment

• Hardware is bought off-the-shelf or custom built.

• Software is bought off-the-shelf or custom programmed.

• Custom equipment is very expensive and slow to create, but suits the user’s needs perfectly.

• Off-the-shelf equipment is far cheaper, easier to get and has more support, but needs to offer all the functionality the user needs.

Validation

• Checks for the reasonableness of data being input, mainly:– Range checks– Existence checks– Type checks

• Can be done manually or electronically

INFORMAL TESTING

Informal testing• Software and hardware are assembled• Informal testing carried out at each stage of

development:– Component testing: ensures each component works

as it should in isolation (e.g. a software module, a hardware device)

– Integration testing: ensures components work properly together. e.g. a memory chip can communicate properly with a CPU; a software module receives the right data from another module.

Testing Activities

• Deciding:– What needs to be tested (e.g. Formulas, buttons,

media, links, communications)?– How will each thing be tested?– What test data, if any, will be used?– What are the expected results?

• Conducting the tests• Recording the actual results• Correcting any identified errors.

Testing types

• Unit testing – tests system components in isolation to see if they behave properly

• Integration testing – tests components once they have been integrated with other components.

• Often components are all fine by themselves, but errors arise when they try to exchange data.

User Documentation

• Once the system is finished and mature, documentation is written.

• See here for the documentation slideshow• See Onscreen user doc slideshow

After development: formal testing

• Informal “check as you go” testing occurred during development

• Formal testing is an official procedure that proves the system works as it should

• The objectives specified in the analysis phase’s logical designare confirmed one by one

Formal testing

• May also involve user acceptance testing (UAT)

• The customer, or typical people who will be using the system for real, use it and report their findings.

Formal testingClient – “Show me that it can produce 10,000

invoices in 5 hours”Developer – OK. Watch…[Time passes]Client – “OK. Now show me the improved

readability”Developer – “Compare this new output with

sample output from the old system.”Client - “Good. Now show me…”etc

EVALUATION

Evaluation• Evaluation is not testing!• Not trying to prove the system works – that

was established during testing!• Establishes the success or failure of a project• Studies the new system to determine if it has

achieved the ambitions it had set out in the logical design.

When to evaluate?• Not too soon after implementation – users

still maybe uncomfortable with it, may not feel “expert” yet

• Not too long after implementation – users will have forgotten the old system and be unable to compare them

• Let users use the new system long enough to be comfortable (e.g. a month of daily use, six months of weekly use)

How to evaluate

• Measure whenever possible – time operations, count errors, add up costs etc

• Interview or survey only when opinions are being evaluated – e.g. Is it easy to use?, Do you feel comfortable?, Is it fun? Is the output attractive?

• Don’t ask “Do you think the new system is faster/more accurate than the old one?”

• Cold, hard facts are more reliable.

What to evaluate

• Evaluate the criteria laid down during design.• These criteria should be based on the

specifications set out in the logical design.• If the original aim was to make a system faster

and more accurate, evaluate its speed and error rate.

Evaluation methods

• For each criterion to evaluate (e.g. speed) there needs to be a method with which to evaluate it. E.g.

• Speed – Time how long it takes to produce output

• Accuracy – count the number of errors recorded in the error log

• Fun to use – interview users and ask their opinion

Remember

• Evaluation criteria are topics to study• Evaluation methods are actions

taken to study the topic.• Each criterion has a

corresponding method.

Efficiency criteria

• Speed• Output produced in a given time• Amount of labour required• Total Cost of Ownership of the system– Including initial cost, running costs, repairs,

upgrades, consumables, training

Effectiveness criteria

Generally: Quality of the product.• Accuracy / error rate• Reliability• Attractiveness of output, readability• Ease of use

Effectiveness criteria• Fun factor• Accessibility• Portability• Security• Compatibility with existing equipment• Expandability, flexibility• Ruggedness• Etc etc

By Mark KellyMcKinnon Secondary Collegevceit.com

These slideshows may be freely used, modified or distributed by teachers and students anywhere on the planet (but not elsewhere).

They may NOT be sold. They must NOT be redistributed if you modify them.

IT APPLICATIONS SLIDESHOWS