Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Risk Identification: Specific Techniques for Particular Perspectives. COMM80:

Slides:



Advertisements
Similar presentations
Requirements Engineering Process
Advertisements

4th Module: Information Systems Development and Implementation:
Options appraisal, the business case & procurement
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 27 Slide 1 Quality Management.
Systems Analysis and Design in a Changing World
Software Engineering CSE470: Process 15 Software Engineering Phases Definition: What? Development: How? Maintenance: Managing change Umbrella Activities:
Unit 10 University of Sunderland CSEM04 ROSCO Unit 10: The Rich Pictures Technique CSEM04: Risk and Opportunities of Systems Change in Organisations Prof.
SWE Introduction to Software Engineering
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
Professional Ethics and Responsibilities
Capability Maturity Model (CMM) in SW design
The Australian/New Zealand Standard on Risk Management
Fundamentals of Information Systems, Second Edition
A Gift of Fire Third edition Sara Baase
University of Sunderland CSEM04 ROSCO Unit 13 Unit 13: Risk Methods CSEM04: Risk and Opportunities of Systems Change in Organisations Dr Lynne Humphries.
Creator: ACSession No: 9 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringNovember 2005 Risk Management CSE300 Advanced Software Engineering.
Unit Slides by UK Versity.  Unit aims:  This unit aims to help the learner with an opportunity to develop their project management and research skills.
Chapter 24 - Quality Management 1Chapter 24 Quality management.
Chapter 24 - Quality Management
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes 1.
Effectively applying ISO9001:2000 clauses 5 and 8
What is Business Analysis Planning & Monitoring?
S/W Project Management
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
Dillon: CSE470: SE, Process1 Software Engineering Phases l Definition: What? l Development: How? l Maintenance: Managing change l Umbrella Activities:
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
Software Project Management Lecture # 8. Outline Earned Value Analysis (Chapter 24) Topics from Chapter 25.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
EARTO – working group on quality issues – 2 nd session Anneli Karttunen, Quality Manager VTT Technical Research Centre of Finland This presentation.
BMAN Integrative Team Project Week 2 Professor Linda A Macaulay.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Unit 1 University of Sunderland COMM80 Risk Assessment of Systems Change Risk Aspects and Context Covered in the Module COMM80: Risk Assessment of Systems.
IT Requirements Management Balancing Needs and Expectations.
This chapter is extracted from Sommerville’s slides. Text book chapter
Software Project Management Lecture 11. Outline Brain Storming session  Some simple discussion on questions and their answers  Case studies related.
Lecture 7: Requirements Engineering
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
QUALITY ASSURANCE MANAGEMENT CONTROLS Chapter 9. Quality Assurance (QA) Management is concerned with ensuring: 1) The information system produced by the.
Visible Communities Richard Bridge and Nadia Denton Visible Standards Team.
Pre-Project Components
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Slides prepared by Cyndi Chie and Sarah Frye1 A Gift of Fire Third edition Sara Baase Chapter 9: Professional Ethics and Responsibilities.
1 Chapter 3 1.Quality Management, 2.Software Cost Estimation 3.Process Improvement.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
© The McGraw-Hill Companies, Software Project Management 4th Edition Step Wise: An approach to planning software projects Chapter 2.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Requirements Engineering Process
Requisite Skills for IS Management and Interpersonal Skills.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
Software Project Management Lecture # 9. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
Risk Management Managing the Software Process - Risk Management Advanced Software Engineering COM360 University of Sunderland © 1998.
Software Engineering (CSI 321) Software Process: A Generic View 1.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
Systems Analysis Lecture 5 Requirements Investigation and Analysis 1 BTEC HNC Systems Support Castle College 2007/8.
Advanced Software Engineering Dr. Cheng
Software Quality Control and Quality Assurance: Introduction
Requirements Engineering Process
Systems Analysis and Design in a Changing World, 4th Edition
Requirements Analysis Scenes
DT249/4 Information Systems Engineering Lecture 0
Initiating systems development
Unit 10: The Rich Pictures Technique
THE BUSINESS ANALYSIS PROCESS MODEL
A Gift of Fire Third edition Sara Baase
How to Scope a Project.
Presentation transcript:

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Risk Identification: Specific Techniques for Particular Perspectives. COMM80: Risk Assessment of Systems Change Unit 5

University of Sunderland COMM80 Risk Assessment of Systems Change Objectives of Unit To focus on specific techniques for risk identification that fit well with particular perspectives –To practise their use. To evaluate the techniques.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Personnel Perspective. Possible approaches: –generic techniques of brainstorming and interviews. –RAMESES questionnaires –SSM’S (Soft System Methodology’s) rich pictures. Typical personnel risks: (re)training, demotivation loss of personnel, resistance to change.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change SSM’S rich pictures. Rich pictures were developed within SSM for understanding problem situations. They are not limited to use in a risk management approach and are more typically used to define systems requirements or examine problematic, unstructured, situations. A “free form” pictorial format is recommended this represents structures, processes and issues of the organisation. In the context of this module this would particularly be from a risk/conflict perspective.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Rich Picture Example (from Avison and Fitzgerald’s IS Developemnt: Methodologies, Techniques and Tools. McGraw- Hill, 2nd Edition, The Secretary of a growing Professional Association believed many of its operations could be computerised: including membership, examination, and tuition administration. Before commissioning any new systems she wanted an overview of where potential benefits would be found and what problems might exist. A consultancy looked at what was going on in the organisation and created an initial rich picture of the situation. This is shown on the next slide.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Rich Picture for the Scenario This picture demonstrates a a fairly high level some personnel type risks, for instance: conflict between the secretary and the education secretary about the how and what to computerise Worries of the education assistant about the thought of automation - should alert to the risk of poor usage, resistance, also need for training and support.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Rich Picture Example A vehicle rental company (VCR) rents cars and vans to private and business users. They have had a significant rise in the level of business rentals and predict that this will be the fastest growing market sector over the next five years. VCR is trying to decide whether to establish a separate corporate service operation to target medium to large organizations. VCR’s aim is to become a sole supplier of vehicle rentals to its corporate customers. (from Linda MacAulay’s “Requirements Engineering”, Springer-Verlag London Ltd).

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Rich Picture for the Scenario

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Detail of Rich Picture Area of agreement denoted by “handshake ” Area of conflict denoted by “crossed swords”

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change SSM’S rich pictures. Typically a rich picture of a situation should contain main structures both formal and informal elements of process. Sets of rich pictures of a situation for different stakeholders can be created and compared.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Systems Development Perspective. Typical systems development risks: missed deadlines, exceeded costs, poor quality software, skills shortages Possible approaches: SEI’s SRE’s comprehensive taxonomy based questionnaire. The RAMESES systems specification matrix.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change SEI’s Taxonomy Based Questionnaire (TBQ) Assumption: project team members have a lot of tacit risk information. – The TBQ provides an instrument for unearthing this. The taxonomy is based on –risks identified in the literature on software development (e.g. Boehm’s “top ten”), –SEI team members’ experience and –Analysis of the field trials results of the method. –It identifies characteristics of software development.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change The SEI Taxonomy Risk Class: Product Engineering Risk Element: Requirements Attributes: Stability, Completeness, Clarity, Validity, Feasibility, Precedent, Scale Risk Element: Design Attributes: Functionality, Difficulty, Interfaces, Performances, Testability, Hardware Constraints, Non- developmental software Risk Element: Code and Unit Test Attributes: Feasibility, Testing, Code/Implementation Risk Element: Integration and Test Attributes: Environment, Product, Risk Element : System Engineering Specialities Attributes: Maintainability, Reliability, Safety, Security, Human Factors

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change The SEI Taxonomy Risk Class: Development Environment Risk Element: Development Process Attributes: Formality, Suitability, Process Control, Familiarity,Product Control. Risk Element: Development System Attributes: Capacity, Suitability, Usability, Familiarity, Reliability, System Support, Deliverability. Risk Element: Management Process Attributes: Planning, Project Organisation, Management Experience, Program Interfaces. Risk Element: Management Methods Attributes: Monitoring, Personnel Management, Quality Assurance, Configuration Management. Risk Element: Work Environment Attributes: Quality Attitude, Co-operation, Communication, Morale.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change The SEI Taxonomy Risk Class: Programme Constraints Risk Element: Resources Attributes: Staff, Budget, Schedule, Facilities. Risk Element: Contract Attributes: Type of Contract, Restrictions, Dependencies. Risk Element: Program Interfaces Attributes: Customer, Associate Contractors, Subcontractors, Prime Contractor, Corporate Management, Vendors, Politics.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Using SEI’s TBQ The questionnaire that has been developed –presents a structured set of (193) questions concerning every attribute in the taxonomy. –The questionnaire focuses on software development –It is used in an interview conducted by independent assessors with small groups of project staff. Only peers are included in an interview group - the presence of a manager has been found to be inhibiting.

Unit 5 University of Sunderland COMM80 Risk Assessment of Systems Change Using SEI’s TBQ The questions vary from A.1-a (No.1) to C.3-g (No. 193).