03/12/2001 © Bennett, McRobb and Farmer 2002 1 Problems in Information Systems Development Based on Chapter 2 of Bennett, McRobb and Farmer: Object Oriented.

Slides:



Advertisements
Similar presentations
The Software Project Management Discipline Succes software projects require careful planning and good use of iterative approaches. Understanding risks.
Advertisements

Chapter 20 Introduction to Systems Development and Systems Analysis Copyright © 2012 Pearson Education 20-1.
SWE Introduction to Software Engineering
03/12/2001 © Bennett, McRobb and Farmer 2002 Refining the Requirements Model Based on Chapter 8 of Bennett, McRobb and Farmer: Object Oriented Systems.
1 Chapter 5: The F1ive Steps in Problem Analysis The five steps in problem analysis. Team Skill 1.
03/12/2001 © Bennett, McRobb and Farmer What Are Information Systems? Based on Chapter 1 of Bennett, McRobb and Farmer: Object Oriented Systems.
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
03/12/2001 © Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
03/12/2001 © Bennett, McRobb and Farmer Modelling Concepts Based on Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Requirements Analysis
Overview of Software Requirements
03/12/2001 © Bennett, McRobb and Farmer Activity Diagrams Based on Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
03/12/2001 © Bennett, McRobb and Farmer Development Process Based on Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Requirements Analysis 2. 1 Req. Capture b502.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Requirements.
1 SWE Introduction to Software Engineering Lecture 11 - Requirements Engineering Processes.
03/12/2001 © Bennett, McRobb and Farmer Requirements Capture Based on Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
03/12/2001 © Bennett, McRobb and Farmer What Are Information Systems? Based on Chapter 1 of Bennett, McRobb and Farmer: Object Oriented Systems.
Sharif University of Technology Session # 4.  Contents  Systems Analysis and Design Sharif University of Technology MIS (Management Information System),
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes 1.
Paul Mundy Concept notes A brief summary of your project idea.
Project Management What The Heck Is That?. Why Do We Need Project Management? Critical towards delivery of effective IT initiatives Ensures we align projects.
Refining the Requirements Model
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
PROJECT RISK MANAGEMENT Presentation by: Jennifer Freeman & Carlee Rosenblatt
PROJECT RESOURCES AND RISKS By Catherine Cowper. AVAILABLE RESOURCES When doing a project there are various resources that need to be made available for.
Project Design Assumptions, Pre-conditions, Risks.
CIS 321—IS Analysis & Design Chapter 4: Analysis— Investigating System Requirements.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
2-Oct-15 Software Development Process E. Haodudin Nurkifli Teknik Informatika Universitas Ahmad Dahlan Kuliah 2 : Administrative dan Introduction 2 Oktober.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Where Agile Business Meets Agile Development Agile Building Blocks: People Dave Yardley.
Software Requirements Engineering: What, Why, Who, When, and How
Lecture 3 Managing the Development Project SFDV Principles of Information Systems.
A Business Plan What is a business plan? What is the role of a business plan? What are the types of business plans? © Karen Devine 2009.
Semester 2 Situation analysis TESL 3240 Lecture 3.
This Space For Rent. Quiz According to Moore, what group should have the most say in what police are supposed to do? (A) Clients (B) Citizens (C) Offenders.
03/12/2001 © Bennett, McRobb and Farmer 2005 Refining the Requirements Model Based on Chapter 8 of Bennett, McRobb and Farmer: Object Oriented Systems.
© Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
© 2010 Bennett, McRobb and Farmer1 Development Process Based on Chapter 5 Bennett, McRobb and Farmer Object Oriented Systems Analysis and Design Using.
CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 02: Problems in Information Systems Development.
1 Performance Measures A model for understanding the behavior of our work Presented by Wendy Fraser.
© 2010 Bennett, McRobb and Farmer1 Requirements Analysis 2: Realizing Use Cases Based on Chapter 7 of Bennett, McRobb and Farmer: Object Oriented Systems.
STEP 4 Manage Delivery. Role of Project Manager At this stage, you as a project manager should clearly understand why you are doing this project. Also.
03/12/2001 © Bennett, McRobb and Farmer What Are Information Systems? Based on Chapter 1 of Bennett, McRobb and Farmer: Object Oriented Systems.
Project Management Planning and Control Techniques  5th Edition u ISBN: u Rory Burke.
Requirements / Specifications. 01/18/10CS-499G2 Requirements Determine what the customer needs (wants) the software to do  What are requirements?  An.
© 2010 Bennett, McRobb and Farmer1 Challenges in Information Systems Development Based on Chapter 2 of Bennett, McRobb and Farmer: Object Oriented Systems.
Module CC3002 Post Implementation Issues Lecture for Week 7
Requirements Engineering Process
© Bennett, McRobb and Farmer 2005
Software Project Management Lecture # 9. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
USE CASE Pertemuan 7 Matakuliah: Konsep object-oriented Tahun: 2009.
Engineering Economics Lecture 18 Project Management 6 January 2010.
Risk management. Definition and Aim  Risk management is examine systematically all risks and react on them, taking into account all the effects of.
PROJECT MANAGEMENT Software Engineering CSE
1 Requirements Analysis Lecture # Recap of Requirements Elicitation - 1 Requirements elicitation deals with discovering requirements for a software.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
Ashima Wadhwa.  Probably the most time-consuming project management activity.  Continuous activity from initial concept through to system delivery.
ITK-AM’05 © J.Stirna Analys och modellering av kommunikativa system och system för sammarbe Analysis and Modelling of Communicative Systems Janis Stirna.
1 Team Skill 1 Analyzing the Problem … Part 1: 5 steps in Problem Analysis Based on “Software Requirements Management, A use case approach”, by Leffingwell.
Development Process Based on Chapter 5 Bennett, McRobb and Farmer
Problems in Information Systems Development
DSS & Warehousing Systems
Introduction to Requirements
By Kean Tak, MSc, Lecturer at RUPP
CIS12-3 IT Project Management
Chapter 5: Software effort estimation
Introduction to Project Management
Presentation transcript:

03/12/2001 © Bennett, McRobb and Farmer Problems in Information Systems Development Based on Chapter 2 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (2 nd Edition), McGraw Hill, 2002.

06 January 2002 © Bennett, McRobb and Farmer In This Lecture You Will Learn: n The main players in an IS project n The problems in IS development n The underlying causes of these problems n How the stakeholder concept helps identify ethical issues in IS development n The costs of problems and ethical issues

06 January 2002 © Bennett, McRobb and Farmer The Main Players n Three main types of player are involved in an IS development project: –Those who will benefit from the system’s outputs, directly or indirectly (end-users) –Those who commission the project, pay for it or have the power to halt it (owners or sponsors) –Those who will produce the software (developers)

06 January 2002 © Bennett, McRobb and Farmer What Do We Mean by Problem? n An IS project may fail before delivery –The Taurus project was cancelled n An IS may fail after delivery –The LAS system was withdrawn after implementation n An IS may be continue to be used, despite causing problems to its users, its owners or its developers

06 January 2002 © Bennett, McRobb and Farmer End-user View n End-users may directly operate the software, or may be more remote, e.g. a manager who receives printed reports n Typical concerns include: –A system that is promised but not delivered –A system that is difficult to use –A system that doesn’t meet its users’ needs

06 January 2002 © Bennett, McRobb and Farmer Owner View n Owners care about meeting business needs and about value for money n Typical concerns include: –Projects that overspend their budget (may no longer have a net benefit) –Systems that are delivered too late –Badly managed projects –Systems that are rendered irrelevant by events

06 January 2002 © Bennett, McRobb and Farmer Developer View n IS developers sometimes have a difficult time –Budget and time constraints often conflict with doing the job properly –Users and owners may not know how to ask for what they really want –Technologies, development approaches and business needs all constantly change

06 January 2002 © Bennett, McRobb and Farmer Why Things Go Wrong n Whether a system is delivered or not, many things can go wrong n Flynn (1998) categorizes the main causes as: –Quality problems –Productivity problems

06 January 2002 © Bennett, McRobb and Farmer Quality Problems n The wrong problem is addressed –Failure to align the project with business strategy n Wider influences are neglected –Project team or business managers don’t take account of the system environment n Incorrect analysis of requirements –Poor skills or not enough time allowed n Project undertaken for wrong reason –Technology pull or political push

06 January 2002 © Bennett, McRobb and Farmer Productivity Problems n Users change their minds n External events –E.g. introduction of the Euro n Implementation not feasible –May not be known at start of the project n Poor project control –Inexperienced management or political difficulties

06 January 2002 © Bennett, McRobb and Farmer Ethics Issues and Stakeholder Problems n Some IS may affect people far beyond obvious users and owners of the system –Cellphone companies collect data about subscribers’ calls and physical movements –This data can be passed to police and many other government agencies –Do you know what data is stored about you? Who by? And what it is used for?

06 January 2002 © Bennett, McRobb and Farmer Stakeholder Analysis n This approach tries to identify everyone affected by a proposed IS –Who are the stakeholders? –How does the system affect each group? –What are their legitimate concerns? –Are there any legal implications, e.g. Data Protection Act in the UK?

06 January 2002 © Bennett, McRobb and Farmer Summary In this lecture you have learned about: n The main players in an IS project, and how they perceive the potential problems n The origins of the main types of problem n How stakeholder analysis can help identify ethical impacts of an IS

06 January 2002 © Bennett, McRobb and Farmer References n Flynn (1998) (For full bibliographic details, see Bennett, McRobb and Farmer) See also