Final Exam

1
Final Exam

• Friday Dec. 10, 900 am, BSB 119
• Cover the material after midterm
• Lecture notes
• 30 True/False and Multiple choice questions 30
  points
• 2 Short answer questions 20 points

2
Project Presentation

• Email me power point presentation a day before
  the presentation
• 15 minutes. Each member should talk.
• 5 minutes discussion
• Peer evaluation
• Project report due at final exam day

3
Project Evaluation Criteria

• Objective and scope of the project
• System requirement specification
• Appropriate use of modeling tools
• Quality of presentation
• Overall evaluation

4
Success factors of IS development
5
Agenda

• How to measure system success?
• What factors lead to system success or failure?

6
How to measure system success?

• Stacie Petter, William DeLone and Ephraim McLean
  (2008) Measuring information systems success
  models, dimensions, measures, and
  interrelationships, European Journal of
  Information Systems (2008) 17, 236263.

7
DeLone and McLean IS success Model
8
Updated IS Success Model
9
System quality

• the desirable characteristics of an information
  system. For example ease of use, system
  flexibility, system reliability, and ease of
  learning, as well as system features of
  intuitiveness, sophistication, flexibility, and
  response times.

10
Information quality

• the desirable characteristics of the system
  outputs that is, management reports and Web
  pages. For example relevance, understandability,
  accuracy, conciseness, completeness, currency,
  timeliness, and usability.

11
Service quality

• the quality of the support that system users
  receive from the IS department and IT support
  personnel. For example responsiveness, accuracy,
  reliability, technical competence, and empathy of
  the personnel staff.

12
System use

• the degree and manner in which staff and
  customers utilize the capabilities of an
  information system. For example amount of use,
  frequency of use, nature of use, appropriateness
  of use, extent of use, and purpose of use.

13
User satisfaction

• users level of satisfaction with reports, Web
  sites, and support services. For example, the
  most widely used multi-attribute instrument for
  measuring user information satisfaction can be
  found in Ives et al. (1983).

14
Net benefits

• the extent to which IS are contributing to the
  success of individuals, groups, organizations,
  industries, and nations. For example improved
  decision- making, improved productivity,
  increased sales, cost reductions, improved
  profits, market efficiency, consumer welfare,
  creation of jobs, and economic development.

15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
What factors lead to system success or failure?

• Information Systems Success and FailureTwo Sides
  of One Coin, or Different in Nature? An
  Exploratory Study by Jeremy Fowler and Pat Horan

19
Abstract

• A considerable amount of IS research literature
  has investigated, among other things, the factors
  associated with IS success and failure.
• Four of the six factors associated with the
  success of IS were related to the factors
  associated with IS failure.

20
(No Transcript)
21
(No Transcript)
22
Lack of Effective Project Management
Skills/Involvement

• A lack of effective project management
  skills/involvement was found to be the most
  commonly cited reason for IS failure
• In order to be effective, project managers need
  to have good leadership, communication, and
  administrative skills, be technically competent,
  and hold a position that is senior enough to
  command respect. They need to be able to get
  people working together, getting them committed
  to the change and building confidence.

23
Lack of Adequate User Involvement

• Having a lack of adequate user involvement has
  been found to lead to decreased system use,
  increased project development cycles, and low
  levels of user satisfaction and commitment.
• In order to avoid these problems, it is vital IS
  practitioners involve all the relevant user
  groups in the development of IS. Through being
  involved in the development process, users are
  more likely to be committed to the IS, while
  gaining a sense of system ownership.

24
Lack of Top-Management Commitment to the Project

• When top-management are committed to a project
  they will do whatever is necessary throughout all
  stages of the ISs development and implementation
  to ensure it succeeds. Also, having
  top-management support has been identified as a
  key factor that can contribute to the escalation
  of commitment to troubled projects

25
Lack of Required Knowledge/Skills inthe Project
Personnel

• A lack of the required knowledge/skills in the
  project personnel can result in schedule overruns
  because of the need for the team to master new
  skills, and time and budget overruns because of
  inexperience with the undocumented idiosyncrasies
  of each new piece of hardware and software
• Combining team members from different departments
  or organizations can also cause special challenges

26
Poor/Inadequate User Training

• The goal of user training is to produce motivated
  users who possess the skills necessary to
  effectively use all the relevant features the new
  IS has to offer
• Without appropriate training, all of the previous
  hard work and planning may be made redundant by
  users who are dissatisfied with the IS, simply
  because they do not know how to use it properly.

27
User Resistance

• In order to counteract user resistance it is
  vital that developers make it a priority to
  involve users in the development process and ask
  them what they want from the new IS
• Users also need to be given a legitimate business
  rationale for using the new IS

28
(No Transcript)
29
Current trends in System Development
30
Overview

• The IS discipline is dynamic and always changing
• More complex system requirements have
  necessitated a whole new set of tools
• The Unified Process (UP)
• Radical, adaptive approaches, including Agile
  Development, Extreme Programming, and Scrum
• Object frameworks and components to increase
  productivity and quality

31
Adaptive Approaches to Development
Characteristics

• Less emphasis on up-front analysis, design, and
  documentation
• More focus on incremental development
• More user involvement in project teams
• Reduced detailed planning
• Used for near-term work phases only
• Tightly control schedules by fitting work into
  discrete time boxes
• More use of small work teams that are
  self-organizing

32
The Unified Process (UP)

• Object-oriented system development methodology
  (system development process)
• Offered by Rational/IBM, UP developed by Booch,
  Rumbaugh, and Jacobson
• UP should be tailored to organizational and
  project needs
• Highly iterative life cycle
• Project will be use-case driven and modeled using
  UML

33
The Unified Process Life Cycle

• UP life cycle
• Includes four phases which consist of iterations
• Iterations are mini-projects
• Inception develop and refine system vision
• Elaboration define requirements and design and
  implement core architecture
• Construction continue design and implementation
  of routine, less risky parts
• Transition move the system into operational
  mode

34
The Unified Process Life Cycle
35
UP Life Cycle Model Showing Phases, Iterations,
and Disciplines (Figure 16-4)
36
http//www.youtube.com/watch?vgDDO3ob-4ZYfeature
related
37
The Agile Development Philosophy and Values

• Responding to change over following a plan
• An agile project is chaordic both chaotic and
  ordered
• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation

38
Agile Modeling Principles

• AM is about doing the right kind of modeling at
  the right level of detail for the right purposes
• Use models as a means to an end instead of
  building models as end deliverables
• Does not dictate which models to build or how
  formal to make those models
• Has basic principles to express the attitude that
  developers should have as they develop software

39
Extreme Programming (XP)

• An adaptive, agile development methodology
  created in the mid-1990s
• Takes proven industry best practices and focuses
  on them intensely
• Combines those best practices (in their intense
  form) in a new way to produce a result that is
  greater than the sum of the parts

40
XP Core Values

• Communication
• In open, frequent verbal discussions
• Simplicity
• In designing and implementing solutions
• Feedback
• On functionality, requirements, designs, and code
• Courage
• In facing choices such as throwing away bad code
  or standing up to a too-tight schedule

41
Some XP Practices

• Planning
• Users develop a set of stories to describe what
  the system needs to do
• Testing
• Tests are written before solutions are
  implemented
• Pair programming
• Two programmers work together on designing,
  coding, and testing
• Simple designs
• KISS (Keep it simple, stupid) and design
  continuously

42
Some XP Practices (continued)

• Refactoring
• Improving code without changing what it does
• Owning the code collectively
• Anyone can modify any piece of code
• Continuous integration
• Small pieces of code are integrated into the
  system daily or more often
• System metaphor
• Guides members towards a vision of the system

43
Some XP Practices (continued)

• On-site customer
• Intensive user/customer interaction required
• Small releases
• Produce small and frequent releases to
  user/customer
• Forty-hour work week
• Project should be managed to avoid burnout
• Coding standards
• Follow coding standards to ensure flexibility

44
Scrum

• A quick, adaptive, and self-organizing
  development methodology
• Named after rugbys system for getting an
  out-of-play ball into play
• Responds to a current situation as rapidly and
  positively as possible
• A truly empirical process control approach to
  developing software

45
http//www.youtube.com/watch?vvmGMpME_phgfeature
related
46
Scrum Philosophy

• Responsive to a highly changing, dynamic
  environment
• Focuses primarily on the team level
• Team exerts total control over its own
  organization and work processes
• Uses a product backlog as the basic control
  mechanism
• Prioritized list of user requirements used to
  choose work to be done during a Scrum project

47
Components and the Development Life Cycle

• Component purchase and reuse is a viable approach
  to speeding completion of a system
• Purchased components can form all or part of a
  newly developed or re-implemented system
• Components can be designed in-house and deployed
  in a newly developed or re-implemented system

48
Components

• Software modules that are fully assembled and
  ready to use
• Reusable packages of executable code
• Have well-defined interfaces to connect them to
  clients or other components
• Public interfaces and encapsulated implementation
• Standardized and interchangeable
• Updating a single component does not require
  relinking, recompiling, and redistributing an
  entire application

49
Component Standards and Infrastructure

• Interoperability of components requires standards
  to be developed and readily available
• Components might also require standard support
  infrastructure
• Networking standards are required for components
  in different locations

50
Services

• New method of software reuse enabled by
  Internetexternal services identified and used
  for applications
• Called Web services and service-oriented
  architecture (SOA)
• Microsoft .NET is service standard based on SOAP
  (Simple Object Access Protocol)
• Java 2 Web Services (J2WS) is service standard
  for services in Java

51
Component Communication Using SOAP
52
(No Transcript)
53
(No Transcript)