System Development Approaches

System Development Approaches
Chapter Two Part I

Chapter objectives explain the system development life cycles
understand the different system development methodologies Evaluate the different system development methodologies weakness and strengths

Chapter subtopics Process oriented methodologies Blended methodologies
Object oriented methodologies Rapid application methodologies People oriented methodologies Organizational oriented methodologies

System Development Life Cycle
Traditional SDLC (conventional SDLC, Waterfall): basis for many systems development approaches since the 1970s; It has the following basic structure (Avison & Fitzgerald, 2006) Feasibility study (what aspects ????) What will happen if the system is infeasible? System investigation (what aspects???? Detail investigation using fact finding techniques Systems analysis (analyzing and structuring …)

Cont… Remarks Systems design Implementation Review and maintenance
What to design? Implementation Coding, testing, training and installation (how???) Review and maintenance To confirm organizational learning and address changes Remarks The out put of one stage is an input to the other It is sequential

Process oriented methodologies …
Under process oriented methodologies Structured analysis, design and implementation of Information system (STRADIS) developed by Gane and Sarson (1979) by incorporating work of Stevens et al. (1974), Yourdon System Method (1978), Myers (1975 and 1978), and Jackson System Development (JSD) (1975)

Gane and Sarson’s STRADIS Methodology
The focus of this methodology is with the selection and organization of program modules and interfaces that would solve predefined problem It assumes that there is no multiple interpretation of the problems Has no contribution to defining of the problems However IS requires both analysis and design to be addressed Gane and Sarson wrote book on the methodology but it discuss the techniques used by the methodology It is applicable to any information system irrespective of size This method is relevant to backlog of system waiting to be developed and insufficient resources to study the new system

Phases of system Development
It has three phases Initial study Detailed study Defining and designing alternatives Physical design

Initial study This phase attempt to select a system for study that brings development in competing environment Main selection criteria is cost and benefits each option Systems are viewed as contributing toward increasing revenues, avoiding costs or improving services It involves construction of an overview of data flow diagram of existing systems and its interfaces Estimate of time and costs of the detailed investigation Initial study report will be reviewed by management to decide whether to continue with the system study or not It is equivalent to the feasibility study

Detailed study In this stage, the existing system is investigated in detail Potential users of the system are identified They exist at three levels senior managers with profit responsibility – system “commissioner” Middle managers of the department to be affected End users, people who are actually working with the system Then the analysts identify their interests and requirements by interviewing them

Detailed design … The analysts Identify interfaces with other systems
Constructs current and the new logical DFD of the system DFDs are constructed at various levels where the lower level DFD should be specified using the appropriate process logic representation (Level 0, level 1, Level 2, etc ) Identify interfaces between various systems Detailed DFD and process logic entered into the data dictionary The initial system study cost and benefit estimates are revised with the new information

Detailed Design … As a summary for detail design
A definition of the user community for the new system Logical model of the current system – overall DFD, interfacing systems, detailed DFD for each important processes, logic specification for each basic process, A statement of increased revenue/avoidable cost/improved service Estimation of system cost and a firm cost/time budget for the next phase

Outputs of Detailed Design
Definition of the user community for a new system Logical model of the current system Detailed data flow diagram for each important process Logic specification for each basic process Data definition at appropriate level Statement of increased revue/avoided costs/improved services that provided by the new system Estimate of costs – system cost, firm cost/time budget for the next phase (defining a menu of alternatives)

Defining and Designing alternatives
In this phase, the analyst defines alternative solutions to the existing system problems The organizational objectives are translated into system objectives Organizational objectives Increased revenue, lower cost or improved services Can you list other organizational objectives?

Defining and Designing …
System objectives It is at lower level and states what the system should do to help management achieves organizational objectives System objectives should be stated to be measurable Improving the timeliness of information – weak objective Better to state as To produce the monthly sales analysis report by the forth working day of the following month Try to list other system objectives as example?

System objectives are used To construct the logical DFD of the new system Existing system DFD will be used as a base The new system DFD brings changes in the data flow, process and stores of the existing system New DFD should be designed to the required detail to show that the most important system objectives are being met The methodology then enters into design phase

In the design phase, the analyst and the designer work together to develop alternative implementation designs Alternative 1 low budget, fairly quick implementation, which may not meet all the objectives Alternative 2 Mid budget, medium term version, which achieves a majority of the system objectives Alternative 3 Higher budget, more ambitious version achieving all the objectives

For each alternatives, the designer will include statements covering The parts of the DFD that would be implemented The user interface (terminals, reports, query facilities, and so on) The estimated costs and benefits The outline implementation schedule The risks involved The final report is presented to the relevant decision makers and commitment made on one alternative

Physical Design The design team refines the chosen alternative into a specific physical design which involves All the details of the DFD must be produced including all the error and exception handling . All process logic, report and screen formats designed The physical files or database will be designed. It is based on the data store content defined before The data stores need rationalizing, and the technique of normalization is utilized to consolidate and simplify the data stores into logical groupings Derive a modular hierarchy of functions from the DFD

Physical Design … The designer seeks to identify either two structures that any commercial data processing system exhibit, Transform center and Transaction –center. Transform Transaction Once this high level functional hierarch types have been identified from the DFD, the detail of the modules in the hierarchy and the communication between them is constructed

Top-Down or Modular Programming

Structure Chart Created Using Structured Design Technique

Physical Design … Includes cost estimation of the new system
Professional time and computer test time required to develop the identified modules Computer system required The peripheral and data communication costs The professional time required to develop the user documentation and train users The time of the users who interact with the system The professional time required to maintain and enhance the system during its life time

Yourdon Systems Method (YSM)
This method uses functional decomposition or top down design in which a problem is successively decomposed into manageable units It also uses event partitioning It is more of middle out approach It starts by drawing high level context diagram which indicates system boundaries and thus sources and sinks Emphasis is on modeling of the organization and the system

Yourdon System Method …
It has three major phases Feasibility study – looks the present system and its environment Essential modeling Environment model that defines system boundary and events that come from environment as stimuli using context diagram An event may be flow oriented, temporal and control event Behavioral model is a model of the internal behavior of the system that deal with the environment successfully Uses DFD, ERD diagram and state transition diagram (shows object state change), event matrix diagram Implementation modeling – define boundary of automation, allocate process to devices and software environments

Limitation of this method
Documentation is towards the developers ETHICS End users involvement is less – only towards the beginning ETHICS, SSM As the process takes longer time , there is obvious invisible backlog.(waiting longer for systems) Agile Emphasis on hard thinking SSM

Question for Discussion
What is the assumption of STRADIS about system problem? When do you use STRADIS? What are the development phases of STRADIS and main system development activities What is the limitation of STRADIS as a system development methodology? Many systems development use no methodology. What is its implication? What are the tools and techniques of STRADIS?

Blended Methodologies
Structured Systems Analysis and Design Method (SSADM) Information Engendering (IE) Mersie (read)

Blended Methodologies : SSADM:
Developed in UK by consultants Learmoath and Burchett Management systems and the Central computing and communication Agency (CCCA) This methodology provides detailed rules and guidelines for developers – highly structured method Standards are exercised by completing pre-printed documents or through supporting software tools such as data dictionary Has seven stages within five module framework with its own set of plans, timescales, controls and monitoring procedure Documentation pervades all phases of system development 30

Phases of SSADM Feasibility study Requirement analysis Requirement specification Logical system specification Physical design But does not have implementation and maintenance phase

Blended methodologies …
Phase I- Feasibility study Stage -0- Feasibility Define the problem Define what the system will do and constraints Weakness of the current system Develop and select feasibility options Create feasibility report, Selected Option

Cont.. Phase 2: Requirements Analysis
Stage 1: Investigation of current environment Repeat the works in feasibility study in great detail Understanding the requirements of the new system Construct DFD up to level 2 Entity model is being developed Major deliverables: Current System Description, Current Physical Data Flow Model, Current Environment Logical Data Model, Requirements Catalogue, Audit, Control and Security Requirements, Constraints List, User Catalogue

Cont’d - Requirement analysis
Stage 2: Business system options The function of the new system is determined and agreed Requirements specified in greater detail A number of system options outlined with its cost, development time scale, technical constraints, physical organization, volumes, training requirements, benefits and impacts on the organizations One is selected for detailed design by the management The selected option documented in detail as a basis for system specification Major deliverables: Selected Business System Option

Cont.. Phase 3: Requirements specification
Stage 3: Definition of requirements investigation and analysis are replaced by specification and design Logical entity model refined with normalization (3rd Normal form) Components of each function (in terms of inputs, outputs, and events or enquiry triggers) Prototypes are developed for critical dialogs and menu structures to users Entity life histories – an entity should have at least one creation and deletion event

Cont.. Phase 3: Requirements specification
Life history documents events affecting each entity type and model the applicable business rules Use event/entity matrix E.g. student – applicant, registered student, graduate System objectives verified and functions are checked for completeness of definition Major Deliverables Required System Description Required System Data Flow Model Required System Logical Data Model Function Definitions

Cont…Phase 4: logical system specification
Stage 4-Technical system options The environment in which the system operate, in terms of the hardware and software configurations, development strategy, organizational impact and system functionality is determined Analysts show constraints on each technology on time and cost maxima and minima Indicate system constraints which include performance, security, and service level requirements that must be met Analyst undertake impact analysis on various technical options Chosen options should be agreed with management

Cont… Stage 5-Logical design
Provides a statement what the system is required to do Dialog structures, menu structures, and designs are defined for particular users or user roles Requires user involvement in the design Rules for validating data entered the system specified All requirements for physical design are placed at this stage such as rules of validating data entered into the system Major Deliverables : Process Modules and Interface Layouts

Cont…Phase 5-Physical design
Stage -6-Physical design More role is required by technology people Logical data model converted into a design appropriate for the database management system Map the components of each logical function and their mapping onto the physical components of the operational system Actual hardware and software configuration Rapid application and reuse may be integrated as appropriate Quality assurance reviews based on structured walkthroughs Major deliverables: Optimized Physical Data Design, Program Specifications, Process Data interfaces

Three important techniques -in SSADM
Logical data modeling The process of identifying, modeling and documenting the data requirements of the system being designed. The result is a data model containing entities (things about which a business needs to record information), attributes (facts about the entities) and relationships (associations between the entities).

Cont… Data Flow Modeling:
The process of identifying, modeling and documenting how data moves around an information system. Data Flow Modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow).

Cont… Entity Event Modeling :A two-stranded process:
Entity Behavior Modeling: identifying, modeling and documenting the events that affect each entity and the sequence (or life history) in which these events occur, and Event Modeling: designing the process to coordinate entity life histories for each event.

Cont… Entity-event modelling
An entity may be effected by several events. An event may effect several entities. This can be represented by a matrix (Entity Event Matrix) separately for each entity (Entity Life History) separately for each event (Effect Correspondence Diagram)

SSADM- features a structured approach: well-defined structure for its use, for training, and for managing projects supported by CASE tools clearly defined deliverables and quality review checkpoints relies on availability of skilled personnel Assumption; systems development is about providing technical solutions to business problems

Information Engineering (IE)

Clive Finkesltein (1970s) first used the term data modelling methodology that developed in Australia Later, he collaborated with James Martin and wrote two- volume books on IE Martin with Texas Instruments (TI) developed Information engineering facility (IEF), a toolset to support the methodology However, there are different versions of IE for different development environments such as packaged-based approach, Rapid Application Development and object oriented based version

Information Engineering
IE is “an interlocking set of formal techniques in which enterprise models, data models and process models are built... and are used to create and maintain data processing systems” IE is a comprehensive methodology covering all aspects of the life cycle Viewed as a framework within which a variety of techniques are used to develop good quality IS in an efficient way IE has a philosophy of practicality (proven and practical approach) and applicability (used in different industries)

Other philosophies Data used by information systems are stable than the process that act upon them Methodology that identifies underlying organization’s data has a stable base on which to develop the IS IS based on process will fail because of constant change of this base as requirements change IE also recognizes that processes have be identified in detail during development of IS – balancing the modeling of data and process as required IE uses standard diagrams as communication tools with users

Major phases of Information Engineering
Information strategy planning to build an information architecture and strategy to support overall business objectives and needs of the organization Business area analysis to understand the individual business areas and determine their system requirements

Cont… systems planning and design Construction and cutover
to establish the behavior of the systems in a way that the user wants and that is achievable using technology Construction and cutover The objective is to build and implement the systems as required by the three previous levels

Phase 1 - Information strategy planning
Is not part of IS development activities corporate management and planners assess the organization: business mission, objectives, performance measurements, organization structure, major business functions and information needs The result of this analysis is the information architecture which form the base for next phases It involves the performance of four tasks

Con… Current situation analysis
Organization current position, weakness, strengths Analysis of technical environment Definition of preliminary information architecture (data subject areas such customers,) Executive requirement analysis Definition of information needs, priorities, responsibilities, and problems of managers Identification of business goals and how technology can help to achieve those goals

Cont’d … Architecture definition
Identification of global entity types and the decomposition of functions within the subject areas (like customer, products business systems architecture (a statement of the ideal systems required in the organization) Technological requirement/architecture required to support the system Definition of information system organization to support the strategy

Cont’d Information strategy plan
Logical business groupings, each of each form analysis project by its own right, Preparation of business evaluations such strategies for achieving the architecture, migration plan, etc Preparation of Information strategy plan such as priorities for development and work programs for high priority projects

Phase 2 - business area analysis
Treat business areas identified before individually The main tasks are Entity and function analysis – identify entities and relationships, ERD model Identify functions and dependencies, represent with function hierarchy diagrams Interaction analysis Examines relationships between data and functions Uses function/entity type interaction matrix

Business area analysis: …
Current system analysis models the existing system in order that the models can be compared in the confirmation stage It also includes the construction of procedure data flow diagrams involve all affected end-users in iteratively building: a detailed data model, a detailed process model, entity/process matrices

Business area analysis: techniques
data model entity relationship modeling attribute collection normalization canonical synthesis (using bubble charts- a directed links between data items) Canonical synthesis is a technique for pulling together all the data identified in separate parts of the organization whether they be in reports, screen forms and so on

Cont… Confirmation Planning for design
It is cross-checking of the results of the above for completeness, correctness and stability Planning for design Definition of design areas (identify parts of the model to be developed) Evaluation of implementation/transition sequences Planning of design objects Identify reusable objects or components from internal and external sources Design internal objects for reusability

Phase 3: Systems planning and design
Two stages (Business system design and Technical Design) concerned with how selected processes in the business are implemented in procedures and how these procedures work use the logical data and process models to design the external representations of the system end-user involvement is essential identify and use reusable procedures

Major tasks and steps in this phase
Systems planning Major tasks and steps in this phase Preliminary data structure design Convert data models into chosen DBMS System structure design Convert business process to procedures Interactions are shown by DFD Procedure design Data navigation diagrams (access path analysis, preparation of dialog flows and the drawing of action diagrams (hierarchically structured dialogues and menus)

Planning for technical design
System planning … Confirmation Checks completeness, correctness and usability Planning for technical design it involves the definition of implementation areas and the preparation of technical design plans

System planning … Technical design in this phase include
physical database design, file design, refinement of data base structure, etc Software design – definition of programs, modules, reuse templates, design of programs/modules, screen displays, menu flows, report layouts Cutover design – design of software and procedures for bridging and conversion, definition of user training Operations design – design of the security and contingency procedures, performance monitoring procedures Verification of design System test design Implementation planning

Phase 4: Construction and cutover
Construction: (system generation and system construction) Create databases create modules and programs, unit testing system testing, documentation Cutover (controlled changeover) Preparation , Conversion and final testing conduct training install the system, review implementation Construction is completed once the acceptance criteria are satisfied

IE techniques ; General
Entity analysis : identifies all the things that the enterprise may want to hold data about. Function analysis and process dependency : takes a function (a major business activity) of the enterprise and breaks it down into elementary business processes. From this, two diagrams are prepared: the process decomposition diagram, which shows the breakdown of a business function, and process dependency diagram, which shows the interdependencies of business processes

Cont… Entity type lifecycle analysis : describes the significant business changes to entities and the effect of these changes Normalization : provides a formal means of confirming the correctness of the entity model. Cluster analysis : helps define the scope of design areas for proposed business systems. Data flow and data analysis : makes a comparison possible between the business area models and the systems currently supporting this business area

Information Engineering: Features
organization-wide perspective aligned with strategic business planning comprehensive emphasis on user involvement e.g. JAD, evolves by incorporating new techniques, concepts, technologies e.g. RAD, object-oriented concepts

Cont… evolves from practice e.g. shortened ISP phase
emphasis on automation e.g. 4GLs, prototypes primarily for database transaction processing systems little event or behavior modeling flexible paths through the methodology e.g. reverse engineering and re-engineering

Questions What did you observe as a major difference between process oriented approaches and blended approaches? What is the main philosophical assumption in the design of system under SSADM and IE? What are the system development life cycle under SSADM and IE? What are the system development techniques?

Object-Oriented Development Methdology

Object oriented Analysis methodology (OOAM)
There are many different approach for OOA For example books by Booch (1994), Coad and Yourdon (1991), Jacobson et al (1999), Mathiassen et al. (2000) Two well known approaches Object-Oriented Analysis (OOA) by Coad and Yourdon (1991) Rational Unified Process (RUP) Almost all use UML

How to Model Real World? Models in systems development environment
Computation-oriented model (50s ~ 60s) Data-oriented model (70 ~ 80s) Object-oriented model (90s ~ ) Balanced view between data and computation

Object-oriented model
Why O-O Model? Possible to directly represent real world objects in the computer system Thus, solves the so-called impedance mismatch problem. ( Read more on this concept) Software system Real world Data-oriented model Software system Real world Object-oriented model

The common /standard tool
UML Almost all Object oriented approaches uses it Is an industry standard modeling tool It provides a wide variety of notations for representing many aspects of software development Powerful, but complex language Can be misused to generate unreadable models Can be misunderstood when using too many exotic features

Five Major activities Finding classes and objects
Identifying structure Generalization and specialization Whole-part Identifying subjects A sort of grouping to reduce complexity Defining attributes Defining services

Finding classes and objects

Chapter Two System development Methodologies
Part II

Evolutionary Methodologies

Evolutionary methdology
RAD Extreme Programming (XP) Prototyping Agile Web Development Information System Etc

Evolutionary Development
Stages or incremental approach A complete system evolves over time Prototyping has closely associated with this Changing requirements over time are expected and are catered for Highly appropriate for situations where requirements are difficult to discover in advance, and also where systems are complex Promotes user participation in system development

Environmental changes
Why we need speedy system development Rapidly changing business needs Business environment competitive, customer focussed and operate in more international context Systems should be developed and maintained quickly But information system development unable to react to this business needs in most organizations

Need of an Evolutionary Model
Business and product requirements often change as development proceeds. Tight market deadlines make completion of a comprehensive software product impossible but a limited version must be introduced to meet competitive and business pressures. A set of core product or system requirements is well understood, but the details of product or system extensions have yet to be defined.

Agile Development

Agile Development Many variants of agile development Major motive
“Users simply do not know what they want. Sometimes they may think they do but when a system is developed for them they realize that this was not what they wanted. Yet having seen the system, they now know what they do not want, and they are a little nearer to understanding what is that they probably want.”

Cont… Agile Model–Driven Development (AMDD) – Scott Ambler (3rd ed. The Object primer) Are you agile or fragile? Agile: Latin: fast, flexible, mobile In SE context: lightweight as opposed to heavyweight Very short cycles Process with few documents Process is regularly discussed Collective code ownership Customer participates in the development process

Cont… First things first
Generate as much business value in the shortest time possible Deliver early, cyclic and incremental development process Make the development process as lightweight as possible Adapt the developmental process to changed environmental conditions (a philosophy that embraces change as the norm) Examples under such a philosophy RAD XP SCRUM

Agile Development Philosophy of Agile in Manifesto (Beck, et. al., 2001) Individuals and their interaction weigh more than defined process and tools Running programs weigh more than extensive documentation Cooperation with the customer weighs more than contract negotiations Responding to changes weighs more than adhering to a plan

Agile Development Agile is characterized by: Iteration
Short life cycles Minimalism Emergence (of new ideas and creative thinking) Risk acceptance People oriented Collaboration and communication

Most cited methodologies oriented towards speed of development
Focused on speedy system development RAD (James Martin (1991) (Requirement Planning, User Design, Construction, Cutover) DSDM (dynamic system development methodology) Focused on programming software quickly XP (attempts to support quicker development) Focused on Web development WISDM ( a modification of multi-view for web development)

Rapid Application Development
A systems development methodology created to radically decrease the time needed to design and implement information systems E.g. James Martin (1991) developed RAD in the context of IE methodology RAD is a combination of tools and techniques in other system development approaches

Characteristics of RAD
Not based on the traditional system development life cycle Uses evolutionary/prototyping approach Focuses on identifying important users and involving them through workshops at early stage Obtain commitment from business users Requires tools with sophisticated repository Uses I-CASE tools (integrated CASE tools) and Code generators

Characteristics… Incremental development
Time boxing (various fixed times – 90 days … Functionality is variable or reducible As opposed to traditional where (time and resources are variable than functionality)

Cont…

Requirements planning
Phases of RAD Requirements planning User design Construction Cutover

1. Requirement planning Puts much emphases on early efforts
Task is to define requirements Two techniques used are Joint requirements planning (JRP) and Joint application Design (JAD) JRP identifies high level requirements of the system through workshop Participants are high level managers who have the vision and understanding of the overall system objectives Create commitment to the goal of the sytem Identify priorities

2. User design Uses JAD as the main technique for user design
It contains both analysis and design Prototyping is advocated to enable quick exploration of processes, interfaces, reports, screens, dialogs, and so on User design is developed with four diagramming technique of entity modelling, functional decomposition, data flow diagramming and action diagram Participants need to be familiar with the techniques Business language is used than technical language Uses to toolset to store designs and definitions of terms

3. Construction phase Takes user design into detail design and code generation Undertaken by information system professionals Generates series of prototypes for user reviews Prototypes are revised based on user change requests Done by small teams, three or four experts The teams are SWAT, skilled with advanced tools

3. Construction ... Uses maximum possible existing designs and codes
One developer for particular part of the system Each part is developed in four to six weeks, For approved design, code generated and the system is tested System integration is done All associated documentation is produced database is optimized

Cut over Comprehensive testing with realistic data in operational situations Users trained with the system Organizational changes implemented Cut over implemented by running the old and new system Uses evolutionary or time box approach to development and implementation Implementation of system is in a 90 days life cycle 80% of the system functionality produced in 90 days

Main feature of RAD The Pareto principle (80/20) MoSCoW rules
(functionality vs efforts ) MoSCoW rules The Must haves (With out this totally impossible… The Should haves (To get maximum benefit.. The Could haves (if time and resource allows The Wont’ haves (will not be delivered.. JAD workshops and Prototyping Sponsor and champion (committed), Toolsets

Extreme Programming

Extreme Programming (XP)
Supports quick development of software for small and medium size organization More of a series of principles for development than step by step methodology It is lightweight methodology Does not have complex rules and documentation It is an agile approach than a software engineering

XP ... Focuses on team work , informal meeting on daily basis
Encourage honest communication between managers, customers and developers Concrete and rapid feedback stressed through continuous testing Quality and customer changes are acceptable even late into the life cycle Customer define requirements in user stories in stead of requirement document Stories contains few sentences that show how long will take to implement

XP ... Critical component of user story is test senario
Testing is upfront Detail requirement captured through face to face discussion between customer and developers Several acceptance testing is done Architectural spike used to identify difficult technical or design problems Spike is very simple program to explore potential solutions Paired program – one keys and the other think more strategically on the function of the whole appraoch Moving people around to speared knowledge

Phases of XP Planning Designing Developing codes Productionanalizing

Planning Define the scope of the project Identify priority functions
Define contents of increment Estimates financial costs and Plan schedules for release of increments Define agreed quality level

2. Designing Design is made on the principle of simplicity, feedback and courage and enabling incremental change Simplicity implies use the easiest approach Use participative approach by involve all stakeholders – collective code ownership Not dependent on key programmers and analyst Create spike solution to reduce the risk of missing requirements

3. Developing the code Done on the principle of paired programming, testing using programmer and user data, gaining rapid feedback and continuously integrating with already implement code Every released of the developing project given to users two to five iterations Each iteration cost of coding a small part and then adding another feature and testing Overtime is not a solutions for projects in difficulty but re- planning in the planning team

4. Productionalizing It is part of the developing phase
But tests at this time ensures fitness for production of the whole system This phase naturally runs into maintenance Documentation is not the primary concern but delivery of the software

XP summery Light weight methodology Uses daily communications
Develops each part quickly Employs principle of simplicity, pair programming and iterative development Customers are part of developer teams Focus on software delivery than documentation

Organization Oriented Methodologies
Part II

SSM: Soft Systems Methodology
Rationale: Hard Systems Thinking (HST) focus on Data and Processes Ignores the people aspect: culture, concepts, perspectives etc HST tries to solve a poorly defined problem, ill defined problems HST assumes a single problem or a well defined problem. However, HST considers problem situations

The Mess We Have Created
“We ‘Systems People’ are a living nightmare of our own creation. Infatuated with buzz words and toys, we have lost sight of the reasons we are in business. We have created many myths to perpetuate the ‘Black Box’ syndrome and hide the fact that we really don’t know what we’re doing” (Patton, 1994)

“Hard” vs “Soft” Systems thinking
Checkland (1981): soft systems approaches organizations are complex, with problems which are “fuzzy”, ill-defined, not well-structured, and where multiple points of view exist hard systems approaches focus on the certain and precise in situations e.g. structured approaches, SSADM assume there is, and consider, only one point of view

“Soft” systems thinking
systems do not exist as such, but are an abstract concept representing a way of seeing and understanding the real world: a “holon” e.g. “the education system” the “system” is not some part of the real world but is the organized process of enquiry itself subjective, depending on background, experience, beliefs need to understand and explore the whole and its context models are not representations of real world activity but are constructed in order to help debate it

Motivation for SSM Checkland wanted to adapt the ideas of systems theory to form a practical “methodology”: a study of methods for application in a particular situation Not a development methodology: a methodology to identify changes Human problem and process oriented, not technique oriented A number of models built representing different viewpoints Exploration of problem situations to decide on action for desirable changes

is an organised but flexible process that deals with situations,
briefly, SSM: is an organised but flexible process that deals with situations, someone sees as problematic that call for action to improve them so as to make these situations more acceptable less full of tensions and unanswered questions. it is a process of “thinking your way to taking sensible action, to improve the situation” based on systems ideas

SSM -Features Real world seen as an ever-changing flux of events and ideas SSM a process for managing in this environment Systems concepts employed as a means of organising our thoughts about a problem situation - NOT as a description of real world activity. SSM is a learning system SSM is participative Checkland (1989)

Thus, what is SSM? A systemic process of learning For exploring problem situations in organizations For suggesting changes which will be helpful and achievable SSM is a system of enquiry and has to be participative the role of the SSM “expert” is to help the people in the problem situation carry out their own study

Checkland and Scholes (1990) p
Checkland and Scholes (1990) p. 6: “the basic shape of the approach is to formulate some models which it is hoped will be relevant to the real-world situation, and use them by setting them against perceptions of the real world in a process of comparison. That comparison could then initiate debate leading to a decision to take purposeful action to improve the part of real life which is under scrutiny”

SSM –assumption the situation is a product of a particular history
the improvers are the users of SSM the focus is the search for one (or more) “world view”: a set of assumptions about reality the world view is extracted from the problem situation through debate on the purpose of the organisation the world view forms the basis for describing system requirements implemented changes will change the nature of the problem situation as perceived: continuous cycle of learning

Why SSM? Practical and flexible approach to managing change
Holistic approach that takes a wide range of factors into account, inc. social and political aspects Aims to suggest change that is meaningful and feasible in the organisational context Is highly participative

SSM steps/stages (mode 1)
1. The problem situation unstructured 2. The problem situation expressed: Rich Picture 3. Root definitions of relevant systems 4. Conceptual models 5. Comparison 6. Feasible, desirable changes 7. Action to improve the problem situation

SSM - Seven Stages 7. Action to improve the problem situation.
1. The problem situation: unstructured 6. Feasible, desirable changes. 2. The problem situation: expressed 5. Comparison of 4 with 2 The Real World Systems Thinking about the Real World 3. Definition of Relevant Systems (Root Definitions) 4. Conceptual Models (Human Activity Models) Checkland (1981)

the problem situation: Unstructured
Problems in Human Activity systems are more diffuse There is seldom no obvious solution It is important to avoid seeing solutions Entering the problem situation “A situation in which there are perceived to be problems” Don’t concentrate on “the” problem We may enter the problem situation as external consultants, or work on our own problem situations.

(See Fig 24.1, p. 471 in Avison & Fitzgerald (2003))
explore the problem situation: to understand the “real” causes problem owners: those on whose behalf the study has been initiated actors: those taking part in the situation, other stakeholders analysts attempt to reveal many possible views of the situation the structure of the problem situation: physical layout, reporting structure, formal and informal communication patterns activities carried out climate: relationships between structure and activities

the problem situation : expressed
Exprsend : Rich Picture The expression should be as rich as possible Do not impose a particular structure Collect as many impressions as possible As many possible choices of relevant systems should be possible.

express the problem situation more “formally”
no particular way prescribed, but rich pictures are often used as a communication technique elements include: clients, actors, tasks, the environment, problem areas, conflicts, concerns, controlling bodies, other stakeholders, relationships, issues exploration, discussion, communication: to help move from thinking about the problem situation towards thinking about what can be done about it

Rich pictures graphical representation of the organisation or work area self explanatory and easy to understand a subjective process: there is no “correct” picture “hard” facts: e.g. activities, departmental boundaries, physical and geographical layout, product types, resources, “soft” facts: concerns, conflicts, socio-organisational roles, political issues, relationships, employee needs, rich pictures help: - to identify what is really important in the situation - people understand their role in the organisation - to define aspects of the organization to be addressed by the information system

Thus, what to put in a rich picture
Structure, e.g. departmental or organisation boundaries, geographical considerations, people and institutions. Process - activities, information or material flows. Climate - the relationship between structure and process, and any associated problems. ‘Soft facts’ - concerns, conflicts, views. Environment - external interested bodies, factors affecting the organisation. The typical technique to help us explore the problem situation is the ‘rich picture.’ Rich pictures are mainly for the analyst but can also be used (as long as the content will not offend or breach confidence) with clients to discuss a situation, or even as a means of getting their perceptions.

rich picture - example

Commonly used symbols External observers / People interested parties
Flows A boundary How can I….? Concerns, views Conflict

rich pictures observation coffeetime yet? boundary idea! crossed swords =friction iconic representations - drawn together into a picture which sums up the important elements of the problem situation

An example rich picture from the Community Health Unit of a local Health Authority.

Thinking about the problem situation
What important tasks are taking place? What issues have you identified? Name “relevant systems” (of human activity)

Primary tasks and issues
Rich pictures also help to identify primary tasks and issues primary tasks tasks the organisation must perform as part of its purpose: what is central to this organisation? the boundaries of primary task systems coincide with a real world manifestation: e.g. a functional boundary as in a personnel system issues topics or matters of concern or conflict generally the boundaries of issue-based systems do not map on to real world boundaries: e.g. a system to resolve disagreements about resource usage

definitions of relevant systems: root definitions
the problem solver imagines and names “relevant systems”: a way of looking at the problem situation which provides useful insights a system is a perceived, meaningful grouping of people, objects and activities e.g. problem theme = conflicts between two departments a relevant system = a systems that redefines departmental boundaries identify one or more relevant systems for each problem theme a subjective process, several relevant systems should be identified, both primary task systems and issue-based systems

Relevant systems Relevant to exploring, debating and changing the problem situation Relevant from some “world view” - Weltanschauung More than one - choose a variety of views, ideas Phrase as “A system to ….” Identify the W that makes them meaningful and the main transformation.

Root definitions a root definition is created for each relevant system
relevant systems are a focus for debate and exploration root definition: a concise, verbal definition expressing the nature of a purposeful activity system regarded as relevant to exploring the problem situation useful in exposing different views expresses the core purpose of a “purposeful activity system” and is always a transformation of some input entity into a new form of entity (output)

root definitions short textual statements which define the important elements of the relevant system being modelled - rather like mission statements they follow mainly the form: a system to do X by (means of) Y in order to Z what the system does - X how it does it - Y why it’s being done - Z

Root definition should be:
Short definition of a relevant system Defines who would be involved, purpose, viewpoint from which it’s defined, “A system to….” Remember: NOT a description of what happens in the real world. Why ??????? We usually work with several definitions

“Who is doing what for whom, to whom are they answerable, what assumptions are being made, and in what environment.” (Checkland) However, we use the CATWOE terminology The CATWOE checklist is usually used to make sure that these elements are explicitly or implicitly included.

use the CATWOE checklist to ensure that six essential characteristics are included
The current situation is left behind, and the ideal situation is examined Taking systems that are relevant to the problem, the root definition or definitions are captured by using the mnemonic C A T W O E

the CATWOE checklist: C ustomers = victims or beneficiaries of T A ctors = those who do T (carry out activities) T ransformation = the conversion of input to output (core process together with input and output) W eltanschauung = the assumptions, the world view which makes T meaningful in context (rationale for the system existing) O wner = those who pay and could stop T (the system) E nvironment = elements outside the system which it takes as given (Constraints in the environment that will limit the ideal situation

Building RD & using CATWOE
Either: Write a root definition, Validate it using CATWOE as a checklist Define any missing elements Rewrite RD to include them Or: Define CATWOE Write a RD that includes all of them. Some leading practitioners criticise this approach. The original approach was the first; nowadays, the second is also common. Only omit CATWOE elements for a good reason.

Root Definition Example
A Department of Computing owned system by which academic staff define a unit syllabus in accordance with university standards for unit definition such that the unit will make the expected contribution to the route, provide clear learning objectives for students and be deliverable in practice within the constraints on staff time and other resources within the department.

CATWOE for unit planning example
C Students A Academic staff T Route’s requirement for unit  requirement met by unit syllabus meeting criteria stated (i.e. objectives, deliverable in practice) W Importance of clear definition of units to route planning and student learning; units should have a defined place within the route. O Department E University standards for unit definition, time and resource constraints

building conceptual models: Human activity models
develop a conceptual model for each root definition: an informal diagram of something relevant to the situation not a model of the situation, but a diagram of the activities of what the system described by the root definition will do conceptual models are used to structure enquiry into the problem situation, not for checking that the model matches the real world the process of building root definitions and conceptual models is an iterative process of debate and modification moving towards an agreed definition

Conceptual models Checkland & Scholes (1990)
assemble and structure the minimum necessary activities to carry out T base this on logical contingency: to convert raw materials into a finished product, you first need to obtain the raw materials identify the monitor and control activities and the operational activities structure similar activities in groups together use arrows to show logical contingency

activity (conceptual) models
representation of the minimum set of activities necessary to ‘do’ the root definition activities modelled by verbs Thus from root definition, conceptual human activity models are derived About 7 +/-2 verbs to carry out the operational tasks are drawn out to form an operational sub-system A monitoring and control sub-system is included in order to determine Efficiency, Effectiveness, Efficacy, and (Ethicality and Elegance) of the model.

activity models - symbols
verb + noun phrase activity - ‘do something’ A logical dependency arrow - activity A must come before B, or if activity A is done badly - so will B B boundary example use

A system needs control mechanisms which allow it to survive in a changing environment and to adapt to change. These will require performance criteria to be defined for the model, and the model should provide for them to be monitored. Three types of performance measure are used in SSM, though two others have been suggested. These are known as the 3 (or 5) Es.

The 3 (or 5) E’s Efficacy: does the means work, does it actually achieve the transformation? Efficiency: does it use the minimum necessary resources? Effectiveness: is the transformation meeting the longer term aim? Also Ethicality and Elegance. What might they be for the course example or the clinic example?

activity model - example
A university owned and operated system to award degrees and diplomas to suitably qualified candidates (X), by means of suitable assessment (Y), (in conformance with national standards), in order to demonstrate the capabilities of candidates to potential employers (Z).

measures of performance - example
E1 (efficacy) - are degrees and diplomas awarded? E2 (efficiency) - how many degrees and diplomas, of what standard, are awarded for the resource consumed? E3 (effectiveness) - do employers find the degrees and diplomas a useful way of assessing the qualities of potential employees?

Conceptual modeling: activities
Identify minimum necessary set of activities Define topics & time allocation Document unit to university standards Appreciate university standards for unit definition Appreciate unit’s expected contribution to route Define learning objectives Decide method of delivery Appreciate time & resource constraints

Conceptual Model External Conditions 1. Develop strategies and plans
Govt. policies, regulations 2. Acquire the necessary resources to implement 6. Assess progress 3. Establish and review programmes and initiatives 5. Execute programmes and initiatives 4. Plan for implementation 8. Monitor all activities 9. Take control action 7. Define Performance criteria

the complete conceptual model
root definition CATWOE activity model measures of performance

the complete model - example
enroll students design education programmes appreciate national standards educate students allot resources and carry out assessment award degrees + diplomas to students reaching acceptable levels monitor for E1, E2, E3 take control action E1 (efficacy) - are degrees and diplomas awarded? E2 (efficiency) - how many degrees and diplomas, of what standard, are awarded for the resource consumed? E3 (effectiveness) - do employers find the degrees and diplomas a useful way of assessing the qualities of potential employees?

final-levels of resolution
each activity may be modelled at a higher level of resolution - in other words a new root definition is prepared specific to that activity and a conceptual model built which further defines the set of (more detailed) activities necessary to accomplish it. in this way complex situations with many activities can be modelled without losing a sense of the overall shape of the problem

One important point- : modelling
Conceptualizing through “relevant systems” Techniques that can be used Root definitions CATWOE Framework Human activity models … All affected by our world view (W)

As the W indicates, each root definition reflects a different way of conceiving the problem situation. Checkland (1987) provides the example of a prison, which it can be helpful to consider as; a punishment system, a rehabilitation system, a system to deter, a system to protect society and as a ‘university of crime’

comparing conceptual models with perceived reality: Comparison
this debate creates new perceptions of reality, suggests new relevant systems, and concentrates thought on possible changes use informal discussion, formal questioning, scenario writing based on operating the models, trying to model the real world using the conceptual model Comparison

comparison with the real world
Once the SSM practitioner has several root definitions, with accompanying conceptual model, CATWOE, and measures of performance (which together constitute rigorous and defensible conceptual systems) (s)he is ready to look at the problem situation again.

this is usually through formal questioning
formal questioning supported by creation of a matrix comparing activities in the model with the activities in the real world the aim is to compare the models with the real world to find an accommodation between different interests in the situation which is seen to be an improvement of the initial problem situation not a “solution” in the hard systems thinking sense

thus the objective is to compare the defensible conceptual version of what might happen, with what really does happen in the situation. At this stage it is often easy to spot activities which are poorly done, or not done at all, and make recommendations for improvements. Comparisons may be simply set out in tabular form

Thus; The purpose is to open up a debate, not to present THE solution!
Three major ways of doing it: 1. Ordered questioning about the problematic situation 2. Historical comparison 3. What features of CM are different from reality and why? SSM articulates a social process in which Ws are held up for examination and their implications, in terms of human activities, are made explicit and discussed

assessing feasible and desirable changes: Changes
analysis of changes proposed in Stage 5 to create proposals for those considered feasible and desirable In case of business applications it may or may not involve the construction of an information system Change

Changes agreed upon must be “systemically desirable”
truly relevant to the situation Derived from root definition and conceptual models. Changes must be “Culturally Feasible” Final debate is on cultural feasibility perceived as meaningful within the particular culture and its world view

a consensus is a rare special case among groups of people, and usually occurs only with respect to issues which are trivial or not contentious SSM works with the idea of finding an accommodation among a group of people with a common concern

Simple tabular representation can be used
The activities in the conceptual model are set out in the left hand column, with proposed changes in the right hand column. More complex tables may be developed to suit the situation. This assessment will normally lead to suggestions for real- world improvements based on the logic of the conceptual model.

Thus , Stage 6 should see an accommodation developing among concerned actors over what changes, if any, are both desirable in terms of the models and feasible given the history, culture and politics prevailing When accommodations are found, action can be taken that alleviates some of the initial unease and, therefore, improves the problem situation.

action to improve the situation: Action
the previous stages recommend action to improve the situation Implement the desirable and feasible changes Changes could be: Structural Procedural Attitudinal no methods described for implementing changes /“solutions”

The change is seldom implementation of a new system, instead change in structure, in procedures and in attitudes. There should be a discussion between "concerned actors". Changes are easier to implement if they are result of iterations.

The conclusion of the methodological cycle is more likely to lead to the emergence of another, different problem situation than it is to provide a ‘solution’. Ending a systems study is therefore, for Checkland, an arbitrary act. Problem resolving should be seen as a never-ending process in which participants’ attitudes and perceptions are continually explored, tested and changed, and they come to entertain new conceptions of desirability and feasibility.

SSM – for IT related projects in genral
Can be pulled to any IT projects where there design, development and implementation involves significant human element Systems/software development (at different stages), infrastructure design and development, IT training need assessment and evaluation, IT product adoption

Why SSM for IS? It’s NOT a complete development method.
But has been extended with techniques for IS Useful for IS-related problem “solving.” Used in Feasibility Requirements capture IS Planning IS success evaluation The aim is to have systems which are seen as relevant, fit the organization, and are used.- ISD project success IS support activities - but which activities?

An Information System “Data Manipulation” System
Organisational (Human) Activity SERVED SYSTEM IT SYSTEM Develop Operate Maintain Modify Processed Data Data STORAGE NETWORKS SERVING SYSTEM Checkland and Howell (1998)

SSM in Information System Dev’t
Implication of prior model: The development of a good information system can derive only from a prior declared account of the human action served OR The necessary features of the serving system can only be determined by examining firstly the served system

SSM in Information System Dev’t
According to (Winter, Brown and Checkland, 1995), SSM in IS development can be seen as; Organisational Analysis (use SSM) Understand what the organisation is taken to be Understand what the organisation will therefore do Identify and define organisational performance criteria Identify and define operational information requirements Identify and define performance information requirements Proceed with contemporary SD approach Checkland and Scholes (1990) also suggest: SSM could enrich the information requirements definition steps of other methodologies

Publications in the area of information systems show that many researchers have tried to use SSM to improve the requirements determination process in IS development. (see Al-Humaidan and Rossiter, 2004; Mingers, 1995; Lopes & Bryant, 2004; Stowell, 1995; Stowell, 1997; Wilson, 1990, and others).

SSM and UML Figure 1. Proposed framework for mixing of SSM and UML for a systemic business process modeling (Based on a generic action research methodology following Checkland and Holwell, 1998, p. 27)

SSM and UML

Using SSM Not intended as a prescriptive set of steps.
Start anywhere, finish anywhere, repeat ad lib. Adapt as necessary.

SSM: criticisms too subjective
- all viewpoints are considered equally valid ignores political and social structures shaping people’s views assumes improvement can occur just by changing people’s views without changing the social structures that shape our views ignores issues of conflict and coercion and the difficulties of avoiding superficial consensus

Summary- SSM Evolved in two modes
for fuzzy, ill-structured problem situations for problem exploration not prescriptive or technique-oriented action research oriented: experience in use of SSM helps to refine the methodology used in different ways by different users in different circumstances is it just a “front end”? practicality? Is it too vague? is it just consensus seeking?

review questions Which one of the 7 steps is important? Explain the “systems thinking world” stages in SSM ? Reading Assignment: “People oriented Methodologies “

End of Chapter Two

System Development Approaches

Similar presentations

Presentation on theme: "System Development Approaches"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

System Development Approaches

Similar presentations

Presentation on theme: "System Development Approaches"— Presentation transcript:

Similar presentations

About project

Feedback