Www.themegallery.com CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 02: Problems in Information Systems Development.

Slides:



Advertisements
Similar presentations
1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
Advertisements

Systems Analysis, Prototyping and Iteration Systems Analysis.
CSC340: Tutorial 1 Software Lifecycles TA: Yuan An Date: 9:00-10:00am, Fri. Oct. 3, 2003 Location: BA1130.
Unit 2. Software Lifecycle
CSE 470 : Software Engineering The Software Process.
Chapter 2 – Software Processes
SYSC System Analysis and Design
1 SOFTWARE LIFE-CYCLES Beyond the Waterfall. 2 Requirements System Design Detailed Design Implementation Installation & Testing Maintenance The WATERFALL.
Object-oriented Analysis and Design
CS 501: Software Engineering
Software Processes: Traditional CSCI102 - Systems ITCS905 - Systems MCS 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 Problems in Information Systems Development Based on Chapter 2 of Bennett, McRobb and Farmer: Object Oriented.
Information Systems Development Lecture 2: the idea of the Life Cycle.
Fundamentals of Information Systems, Second Edition
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
MSIS 110: Introduction to Computers; Instructor: S. Mathiyalakan1 Systems Investigation and Analysis Chapter 12.
CHAPTER 19 Building Software.
Software Life Cycle Model
S/W Project Management
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Chapter 1: Introduction to Systems Analysis and Design
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
2-Oct-15 Software Development Process E. Haodudin Nurkifli Teknik Informatika Universitas Ahmad Dahlan Kuliah 2 : Administrative dan Introduction 2 Oktober.
CS CS 5150 Software Engineering Lecture 3 Software Processes 2.
Installation and Maintenance of Health IT Systems
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Lecture 3 Managing the Development Project SFDV Principles of Information Systems.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Note Excerpts from Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R. Schach
13-January-2003cse LifeCycle © 2003 University of Washington1 Lifecycle CSE 403, Winter 2003 Software Engineering
Introduction to Systems Analysis and Design
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
Fifth Lecture Hour 9:30 – 10:20 am, September 9, 2001 Framework for a Software Management Process – Life Cycle Phases (Part II, Chapter 5 of Royce’ book)
© 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.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Slide 1 Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 1: Introduction to Systems Analysis and Design Alan.
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
The Rational Unified Process 1 EECS810: Software Engineering.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
© 2010 Bennett, McRobb and Farmer1 Challenges in Information Systems Development Based on Chapter 2 of Bennett, McRobb and Farmer: Object Oriented Systems.
Click to add text Systems Analysis, Prototyping and Iteration.
1 - 1 Systems Analysis and Design, Key Ideas Many failed systems were abandoned because analysts tried to build wonderful systems without understanding.
Requirements Engineering Process
Stand Up Comedy Project/Product Management
Prototyping life cycle Important steps 1. Does prototyping suit the system 2. Abbreviated representation of requirements 3. Abbreviated design specification.
Lecture 2 System Development Lifecycles. Building a house Definition phase Analysis phase Design phase Programming phase System Test phase Acceptance.
© Bennett, McRobb and Farmer 2005
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
CS223: Software Engineering Lecture 8: Requirement Engineering.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
Software Engineering, 8th edition. Chapter 4 1 Courtesy: ©Ian Sommerville 2006 FEB 13 th, 2009 Lecture # 5 Software Processes.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Welcome to Software Project Management. CONVENTIONAL SOFTWARE MANAGEMENT The BEST and WORST thing about software is its flexibility. 1.Software development.
Statement of Work Lecture. SOW The statement of work is the basis of the contract between the pro- poser and the customer, and is often incorporated into.
Development Process Based on Chapter 5 Bennett, McRobb and Farmer
Chapter 1: Introduction to Systems Analysis and Design
Problems in Information Systems Development
Requirements and the Software Lifecycle
Introduction to Software Engineering
Gathering Systems Requirements
Chapter 1: Introduction to Systems Analysis and Design
Gathering Systems Requirements
Chapter 1: Introduction to Systems Analysis and Design
Presentation transcript:

CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 02: Problems in Information Systems Development

Problems in Information Systems Development Jun-162

In this Lecture You Will Learn:  The Main players in an IS project  The problems in IS development  The underlying causes of these problems  How the stakeholder concept help identify ethical issues in IS development Jun-16 3

Main Players  Three main types of player are involved in an IS development project: end-usersThose who will benefit from the system’s outputs, directly or indirectly (end-users) owners or sponsorsThose who commission the project, pay for it or have the power to halt it (owners or sponsors) developersThose who will produce the software (developers) Jun-16 4

What Do We Mean by Problem?  An IS project may fail before delivery The LSE Taurus project was cancelled  An IS may fail after delivery The LAS system was withdrawn after implementation  An IS may be continue to be used, despite causing problems to its users, its owners or its developers Jun-16 5

End-user View  End-users may directly operate the software, or may be more remote, e.g. a manager who receives printed reports  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 Jun-16 6

Owner View  Owners care about meeting business needs and about value for money  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 Jun-16 7

Developer View  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 Jun-16 8

Why Things go Wrong  Whether a system is delivered or not,,many things can go wrong  Flynn(1998) categorizes the main causes as: Quality problems Productivity problems Jun-16 9

Quality Problems  The wrong problem is addressed Failure to align the project with business strategy  Wider influences are neglected Project team or business managers don’t take account of the system environment  Incorrect analysis of requirements Poor skill or not enough time allowed  Project undertaken for wrong reason Technology pull or political push Jun-16 10

Productivity Problems  Users change their minds  External events e.g. introduction of the Euro currency  Implementation not feasible May not be known at start of the projectMay not be known at start of the project  Poor project control Inexperienced management or political difficulties Jun-16 11

Ethics Issues and Stakeholder Problems  Some IS may affect people far beyond obvious users and owners of the system Cell-phone 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 store about you? Who by? And what it is used for? Jun-16 12

Stakeholder Analysis  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? Jun-16 13

Summary In this lecture you have learned about:  The main players in an IS project, and how they perceive the potential problems  The origins of the main types of problem  How stakeholder analysis can help identify ethical impacts of an IS? Jun-16 14

Avoiding the Problems Jun-1615

© Bennett, McRobb and Farmer In This Lecture You Will Learn:  The stages in the waterfall life cycle  About prototyping and incremental life cycles  The importance of project management  How users may be involved in a project  The role of CASE tools in systems development

© Bennett, McRobb and Farmer Problem Solving Model General problem solving model (adapted from Hicks, 1991).

© Bennett, McRobb and Farmer Project Life Cycles  A distinction should be made between  Systems development  Systems development which incorporates human, software and hardware elements  Software development  Software development which is primarily concerned with software systems  Two important phases are  Strategic Information Systems Planning  Business Modelling

© Bennett, McRobb and Farmer Waterfall Life Cycle  The traditional life cycle (TLC) for information systems development is also known as the waterfall life cycle model  So called because of the difficulty of returning to an earlier phase  The model shown here is one of several more or less equivalent alternatives  Typical deliverables are shown for each phase

© Bennett, McRobb and Farmer

© Bennett, McRobb and Farmer TLC Deliverables  System Engineering  High Level Architectural Specification  Requirements Analysis  Requirements Specification  Functional Specification  Acceptance Test Specifications Life cycle deliverables (adapted from Sommerville, 1992).

© Bennett, McRobb and Farmer TLC Deliverables  Design  Software architecture specification  System test specification  Design specification  Sub-system test specification  Unit test specification Life cycle deliverables (adapted from Sommerville, 1992).

© Bennett, McRobb and Farmer TLC Deliverables  Construction  Program code  Testing  Unit test report  Sub-system test report  System test report  Acceptance test report  Completed system Life cycle deliverables (adapted from Sommerville, 1992).

© Bennett, McRobb and Farmer TLC Deliverables  Installation  Installed System  Maintenance  Change requests  Change request report Life cycle deliverables (adapted from Sommerville, 1992).

© Bennett, McRobb and Farmer Problems with TLC  Real projects rarely follow such a simple sequential life cycle  Iterations are almost inevitable  Time elapses between system engineering and the final installation  The design is unresponsive to business changes during the project

© Bennett, McRobb and Farmer

© Bennett, McRobb and Farmer Strengths of TLC  Tasks in phases may be assigned to specialized teams  Project progress evaluated at the end of each phase  Manage projects with high levels of risks

© Bennett, McRobb and Farmer Prototyping Life Cycle

© Bennett, McRobb and Farmer Prototyping—Advantages  Early demonstrations of system functionality help identify any misunderstandings between developer and client  Client requirements that have been missed are identified  Difficulties in the interface can be identified  The feasibility and usefulness of the system can be tested, even though, by its very nature, the prototype is incomplete

© Bennett, McRobb and Farmer Prototyping—Problems  The client may perceive the prototype as part of the final system  The prototype may divert attention from functional to solely interface issues  Prototyping requires significant user involvement  Managing the prototyping life cycle requires careful decision making

© Bennett, McRobb and Farmer Spiral Model & Incremental Development

© Bennett, McRobb and Farmer Unified Software Development Process  Captures many elements of best practice  Main phases  Inception  Inception is concerned with determining the scope and purpose of the project  Elaboration  Elaboration focuses requirements capture and determining the structure of the system  Construction's  Construction's main aim is to build the software system  Transition  Transition deals with product installation and rollout

© Bennett, McRobb and Farmer Size of square relative to time spent on workflow Inception Elaboration Construction Transition Project Phases Iterations within each phase RequirementsAnalysisDesignImplementationTest Workflows

© Bennett, McRobb and Farmer User Involvement  Users can be involved in various ways  As part of the development team (DSDM)  Via a consultative approach  In fact gathering

© Bennett, McRobb and Farmer Computer Aided Software Engineering  CASE tools typically provide a range of features including  checks for syntactic correctness  repository support  checks for consistency and completeness  navigation to linked diagrams  layering  requirements tracing  report generation  system simulation  performance analysis  code generation

CSE323 Systems Analysis and Design 36 Jun-16 Next Lecture Requirements Capture and Requirements Analysis