ISD Lecture 2 Systems development Flashcards
Describe Formalised Methods
Methods as described in textbooks etc.
It can, for example, be SCRUM or XP. Formalized methods usually prescribe how a development situation must be approached in a methodical way independent of the type of context.
Describe Method-in-Action
The methods actually used by developers.
In actual development practice, formalized ISD methods are rarely applied in their entirety, nor as originally intended by their creators, although they may provide a template to guide development practice. Different developers will not interpret and apply the same method in the same way. Therefore, on any development project, the method-inaction is uniquely enacted by the developer.
Describe Development Context
The context in which the systems are developed and used.
The framework acknowledges the complexity and dynamic nature of the business context in which development takes place. Even if different development contexts are similar in some respects, a context is always unique.
Describe Plan-Driven development
Plan-driven development is a more formal specific approach to creating an application.
Plan-Driven development is discrete stages with a specific end product, stage-limited commitment, specialization, bureaucracy, documentation. Used when uncertainty is low.
Plan-driven methods are most successful when the context has the following characteristics
- Requirements are stable
- Technology is well known and mature
- Everything happens as one would expect
- We are not taking on much new or unknown
- We have done something similar before
Describe Agile development
Agile development refers to a group of software development methodologies based on iterative development.
Short iterations, feature planning, dynamic prioritization, feedback, and change. Used when uncertainty is high. Overall is agile based on feedback*
Understanding development model
Relationship between formalised methods and methods-in-action based on roles of method, development context, developers, information processing system
The characteristics of the system
- Purpose
- Complexity
- Solved vs unsolved
- Mature technology vs new technology
- Unique vs standard
- Systems and change
What is the context?
The context is the foundation of IS development and implementation: IS is developed in the context and used in the context.
The framework considers one context called the development context – it might make more sense to divide it into two:
the development context and the
implementation context
Different context organizations
A single organization (e.g. an organization developing a system for internal use)
Several organizations (e.g. several organizations collaborating about a suply-chain management system)
A virtual organization (e.g. developing a new web-shop).
Society….
Why does the context matter
- Context is unique
- Not possible to transform a system without context
- Cannot easily be analysed
- Culture
- Turbulence
Strategies for change
o Proactive versus re-active
o Problem-solving versus innovation
o Incremental versus radical
Roles of methods
Rational Roles
Political roles
Rational roles
Reduce complexity:
For example by dividing a complicated process into smaller and more manageable and less complex steps.
Facilitate project management:
e.g. by creating transparency by having developers do interim products that makes it possible to evaluate the progress.
Allow skill specialization:
by defining roles and activities that can be allocated to specific developers.
Standardization:
by having several projects in the same organization work in similar ways, thereby making it easier to share developers and experience.
Economics:
E.g. by improving productivity.
Learning: E.g. getting new employees integrated faster because they can read and learn how things are done in this organization.
Quality:
Reduce the reliance upon individual developer skills.
Political roles
Assure customers
that projects work in a proper way that reflects ”best-practice”.
Legitimate specific ways
of working or specific roles in the development process.
contribute to Percieved professionalization
As a power base
for specific developers that become respected and certified experts in using the method.
Plan-Driven - when uncertainty is low
Discrete stages with a specific end product Stage-limited commitment Signoff end products In-stage quality control Specialization Bureaucracy Documentation
Agile – when uncertainty is high
Short iterations Feature planning Dynamic prioritization Feedback and change Teamwork Customer collaboration
What is method-in-action
What’s the “right” method will depend on e.g. resources, constraints, needs, wishes in the specific context, developer capabilities, and the nature of the system.
Methods-in-action must balance between relying on individuals (craft) and relying on processes.
Problems with Plan-Driven development
Formally strict
Require a structure that often cannot be found in the field
Inflexible when changes occur
Cost-/risk intensive when deviating from the original plan
Method-in-action the challenge
methods-in-actions have to be changed whenever the context changes.
Whenever there are major changes in the context such as new customers, new domains, new technologies etc. we have to reconsider our methods-in-action, and in many cases we get surpriced when what used to work doesn’t work any more.
Method-in-action the problems
Predictability:
We have difficulties estimating how much time and other resources we need.
Costs:
Development and implementation gets more expensive that originally expected.
Change:
We have difficulties implementing the organizational changes that are needed to benefit from the new system.
Quality:
New systems do often not work properly in the context they should support, users do not find the systems usable.
Value:
We have difficulties realzing the expected benefits from IT investments, maybe nobody actually takes responsibility for doing so.
The Developers
From technical experts in computer science such as programmers and database specialits to business analysts, HCI people and change agents.
The developers factor one
Skills
Developers have dramatic impact on productivity and quality. Their experience, domain and technical knowledge is vital.
The skills of the developers
The ability to communicate and collaborate with client and users
Analytical skills
Creative skills
Compositional skills (: The skill to come up with a new system and to imagine how the existing system and the existing context can be composed into a whole system)
Good Judgement based on experience
The developers factor two
Motivation
IS development & implementation is not routine work, and there will be surprises that require substantial efforts. Commitment and motivation are vital.
What are developers motivated by
- New technology
- Ownership
- Work with top management
- Trust and autonomy
How to use system development
Before starting up a new project you really need to understand:
The context:
What are the key characteristics that you need to consider for this particular project? Which consequences do they have for the methods-in-action?
The developers:
What are we good at? Where do we lack experience? Which methods could you apply to compensate for lack of experience?
The systems to be developed:
What is the nature of the system? What is really important? What is difficult? Which developer capabilities are needed? Which methods?
The formal methods:
Which methods should we chose, and how should we tailor them to this particular project?
And – to some degree – design:
The methods-in-action that you are going to use
And you have to continuously re-design this process as you gets wiser and learn more about these elements.
Reflections and Relations with system development
Lack of consideration of value creation
The end result in the framework is the new system – not the benefits or business value, and the formal methods / methods-in-actions which are discussed, are concerned with the development of the system – not with the creation of benefits or business value.
