developers, engineering and innovation introduction: how should we approach it? what do we do...

28
Developers, Engineering and Innovation Introduction: How should we approach it? What do we do naturally? What should we be doing to ensure successful development? This involves looking at: Systems development as developers •Engineering •Thinking •Art and Design

Post on 19-Dec-2015

213 views

Category:

Documents


0 download

TRANSCRIPT

Developers, Engineering and Innovation

Introduction:

• How should we approach it?• What do we do naturally?• What should we be doing to ensure successful development?

This involves looking at:

Systems development

as developers

•Engineering•Thinking•Art and Design

Developers, Engineering and Innovation

It can be made cheaplyIt can be made quickly

It can be made to a high standard

- choose any two

Is this always going to be true?

Systems Development adage:

Engineering is often advanced as the most

suitable model for Software or Systems development….

What does it really have to offer?

“Engineering relies on codifying scientific knowledge about a technological problem domain in a form that is directly useful to the practitioner, thereby providing answers for questions that commonly occur in practice.”

Engineering as the model for Software development….

Developers, Engineering and Innovation

WHAT ENGINEERING IS:

1. Engineering emerges from exploitation of craftsmen solving problems

2. These problems are often solved by using local materials with no anticipated resale

3. If the demand for such products is sufficiently high and exceeds the output of skilled craftsmen the production design is systematised together with a training program for practitioners

4. Recurrent problems of design and build lead to a scientific analysis of the problems, which is then merged with the craft side

The evolution of engineering The evolution of engineering as a scientific discipline….as a scientific discipline….

Developers, Engineering and Innovation

Routine engineering tasks require you to recognise patterns and adapt the task to the environment

In engineering there are two types of design task:

• Routine• Innovative

Innovative projects can be highly prestigious but are unlikely to be given to novices and usually take more time and money

Developers, Engineering and Innovation

Developers, Engineering and Innovation

De Bono’s Video

Developers, Engineering and Innovation

De Bono’s VideoHis main conclusions are that human beings are brilliant at pattern matching

- even when we haven’t ever seen the actual image before

or if the “object” we need to

recognise and use our experience to match is entirely

conceptual i.e. not entirely “real”

and possibly misoriented:

Developers, Engineering and Innovation

55

55

55

5 55

How many 5s are there?

Developers, Engineering and Innovation

and this is?

Developers, Engineering and Innovation

De Bono’s Video exposition of thinking and the discipline of engineering indicates that the mechanism of pattern matching is part of the way we operate naturally and is a strong force which is extremely useful in the engineering environment

Revisiting methodologies….Revisiting methodologies….

Developers, Engineering and Innovation

Currently in Information Systems practice, knowledge about techniques that work is rarely shared effectively with workers on later projects

In Information Systems Development, virtually every project is treated as an original – only the second type of task appears to exist - INNOVATION

Let’s examine Information Systems Development:

often equated with Software Engineering or Systems Engineering:

Revisiting methodologies….Revisiting methodologies….

Waterfall or Traditional

Structured Methods (SSADM)

RAD – Rapid Applications Development

Developers, Engineering and Innovation

SSM

ETHICS

How much innovation is involved in these methodologies?

- and how much do they require adherence to

standards?

Revisiting methodologies….Revisiting methodologies….

Waterfall or Traditional

modularisation and structure; NOT hacking; sequential; limited iteration

Structured Methods (SSADM)

Focus on data, tasks, techniques and tools; aims to provide increased rigour (too recipe-driven?); often unwieldy, difficult for individuals to understand and master

Developers, Engineering and Innovation

Soft Systems Methodology

Focus on human activities, on Weltanschauung; analysis through action research; only concerns analysis, not development and implementation, difficult to teach and know when a stage has been completed; no pre-conceived notions of a “solution”

Revisiting methodologies….Revisiting methodologies….

RAD – Rapid Applications Development

Focus on speed of development;high user involvement and use of prototyping; prioritisation essential; use of CASE tools; risk of quick and dirty solutions – "licence to hack"

Developers, Engineering and Innovation

Effective Technical & Human Implementation of Computer-based Systems - ETHICS

Computer systems an organisational issue, not technical; measures job satisfaction; participative - change process through negotiation; needs facilitation; 15 key steps prescribed; essentially QUICKETHICS = requirements analysis only

CASECASE tools: should perform the following functions:

use diagrams for planning, analysis, design and code-generation

solicit information about objects and their relationships so a complete set of information is built up

store the meaning of diagrams, rather than just the symbols

check for accuracy, integrity and completeness (AIC)

allow multiple types of diagrams for representation of analysis and design

enable users to draw program procedures that show conditions, loops, case-structures and other constructs

enforce structured modelling that permits accuracy and consistency checks

coordinate diagrams & check for consistency so that together they have AIC

allow all this information to be shared by other analysts and designers

ensure consistency between developers working on various projects

Developers, Engineering and Innovation

RAD:

CASECASE tools: should perform the following functions:

use diagrams for planning, analysis, design and code-generation

solicit information about objects and their relationships so a complete set of information is built up

store the meaning of diagrams, rather than just the symbols

check for accuracy, integrity and completeness (AIC)

allow multiple types of diagrams for representation of analysis and design

enable users to draw program procedures that show conditions, loops, case-structures and other constructs

enforce structured modelling that permits accuracy and consistency checks

coordinate diagrams & check for consistency so that together they have AIC

allow all this information to be shared by other analysts and designers

ensure consistency between developers working on various projects

Developers, Engineering and Innovation

RAD:

ability to rework prototypes into the full working system

generate technical documentation automatically

I-CASEI-CASE tools additionally will have:

Developers, Engineering and Innovation

RAD:

understand diagrams

We are demanding that systems development tools should be able to:

coordinate diagrams

ensure they are consistent

share everything with other developers

share everything with other projects

understand a prototype so it can be used

use all this info to generate documentation

Developers, Engineering and Innovation

RAD:

Developers, Engineering and Innovation

can this be done in a systems design medium

(which RAD might portray) in which the starting point

is always to innovate?

Question is:

We are demanding systems development tools to:

BE KNOWLEDGEABLE

This may lead to the conclusion that this can

only happen if innovation is abandoned

The drive for reuseability, integration and automated

consistency leads to massive amounts of

STANDARDISATION

well, mostly!

Developers, Engineering and Innovation

RAD:

Crampton-Smith & Tabor

Developers, Engineering and Innovation

“Interaction design cannot dispense with scientific method and engineering knowledge; indeed, familiarity with computing technology is as essential to an interaction designer as building technology is to an architect…

The Role of the Artist-Designer

Chapter 3 of Winograd’s book: Bringing Design to Software

interaction design deals primarily with values, preferences, and meanings - with, if you like, aesthetics and semantics - it can have neither a universal predictive theory nor always-reliable methods to generate solutions.”

Developers, Engineering and Innovation

Crampton-Smith & Tabor

“You can say, for instance, that a certain color of type will be legible to most readers, but cannot say with the same certainty that readers will or will not like it…

So informed instinct is as important as is principle…

the interaction designer needs to break rules and overturn precedents, as well as be able to follow them.”

Developers, Engineering and Innovation

Crampton-Smith & Tabor

in the design process outlined by them:

“In … we went through the five design stages… cycling back through them more than once:

“few individual design decisions are startlingly innovative; the creative task is to forge a coherent and consistent whole, in terms of logic, representation, and the users’ world.”

•understanding•abstracting•understanding•structuring•representing

•abstracting•representing

•understanding•structuring and representing

•detailing•over halfway through the design work - screen and interaction design begins - structure and design work so far almost invisible - obvious only if it has not been done well: the more skilfully it is achieved, the more transparent it is

Developers, Engineering and Innovation

The product…creates an alteration in the mind of the user.

Crampton-Smith & Tabor

“We do not mean to deny the utility of templates,

interface guidelines, and all those rules of thumb…”

“a design that serves well both the particular material and the particular audience

cannot be adduced from principles alone…”

the customary assumption, that substance - the real thing - is separate from appearance, is misleading.

For the user: WYGIWYS: What you get is what you see.

THE INTERFACE IS THE PRODUCT

Developers, Engineering and Innovation

Constantine: OOPSLA Conference, 1996

What are systems for? They are tools! i.e. to help people accomplish something, by making it easier, simpler, faster or possible (& may be fun)

Unfortunately, we don't necessarily provide the tools in the right form and formats if we don't understand the answers to certain questions: "What are the users doing? What are they trying to accomplish? What is it that they intend to do and are attempting? What do they need to accomplish this?"

How do we supply what the users really need?

We may supply elegant and sophisticated software but not necessarily the tools which fit with what users are trying to accomplish. USER ROLES

Developers, Engineering and Innovation

Those User Roles are not constant or necessarily divided between different workers, but do require different sets of tools:

A focus on relationships between users and systems, not on users as such, gives a better view of what we should provide:

using a word processor you can be a writer, editor or publisher (roles)

• Writer: you want the machine to let you type and not interrupt with grammar or spelling options• Editor: interested in spelling, grammar and arranging paragraphs• Publisher: not interested in the words in but in the arrangement on the page, the flow, the columns

Constantine: OOPSLA Conference, 1996

Developers, Engineering and Innovation

The heart of his work is the ESSENTIAL use-case model

• an abstract case of purpose-directed usage

• idealised and technology-independent

• an extension of OO use-cases for soft eng

• an essential use-case represents the external black box view of supplied functions

• complete, well-defined, meaningful to user

• purpose, not concrete steps or mechanisms

what a user, in a role, is trying to accomplish rather than how

• simplified and generalised

Constantine: OOPSLA Conference, 1996

Developers, Engineering and Innovation

Name(= do something)

User action model System responsemodel

To show these usage-case models you can use a structured narrative -a dialogue

GetCash - actual

User action system response

insert card

enter pin

press keypress keyenter amountconfirmtake cardtake money

read stripeprompt for pinverify pindisplay option menudisplay account menuprompt amountdisplay amountreturn card

identify

make choicetake money

verify IDoffer choices

GetCash - essential

User action system response

For Example: at an ATM

Constantine: OOPSLA Conference, 1996