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 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
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