ロンドン大学で MSc Computer Science: Information Systems モジュールを履修中。

講義内容に関して記録した個人的なスタディノートです。

全 12 週のうち 1〜5 週目の内容を記録します。（1 週目開始：2024 年 10 月 14 日 / 5 週目終了：2024 年 11 月 17 日）

モジュール概要 #

Aims

The primary aim of the module is to describe enterprise information systems (EIS) and to set out the considerations and approaches used to implement (deploy) these systems in the business enterprise. This covers predominantly the Systems Development Life Cycle (SDLC) and the various methodologies used to formalise it, including waterfall and agile approaches, with particular emphasis on the Scrum method. In the course of this module students are introduced to a range of topics relevant to EIS deployment and the SDLC, including development planning and project management, analysis and documentation of user requirements, design (enterprise and technical architecture) and implementation (change management). The module also covers IT operations activities. In addition to describing the SDLC, students will be introduced to practical aspects associated with a career as an IS professional, and to social and organisational aspects of enterprise computing. This will include Intellectual Property, Digital Surveillance, Data Privacy and Ethical issues in computing.

Weeks

講義は Week 10 まで。Week 11, 12 は最終課題を作成する期間。

• Week 1: Introduction to Enterprise Information Systems (EIS)
• Week 2: Systems Development Life Cycle (SDLC) and IS project methodologies
• Week 3: Planning and Analysis
• Week 4: Design (Enterprise & Technical Architecture)
• Week 5: Scrum I – Roles, Activities & Ceremonies
• Week 6: Scrum II – Concepts
• Week 7: Conversion, Roll-out and Operations
• Week 8: Data Protection and Intellectual Property
• Week 9: Contracts, Defective Software and Cybercrime
• Week 10: Digital Surveillance, Ethical Issues in Computing and Business Planning

参考文書 #

Module reading list

Core Reading

• Essential SCRUM, Ken Rubin, Addison Wesley

Additional Reading

• ‘Object-Oriented Systems Analysis and Design’, Bennett, Mc Robb and Farmer
• ‘IT Architectures and Middleware’, Britton & Bye
• ‘Information Systems Development’ (3rd edition) – David Avison and Guy Fitzgerald, McGraw Hill
• ‘The Mythical Man Month’, Fred Brooks‘A Gift of Fire’,
• Sara Baase, 5th edition, Pearson International Edition, 2012
• ‘Succeeding with Agile’, Mike Cohn
• Scrum Body of Knowledge (free download here: https://www.scrumstudy.com/sbokguide/download-free-buy-sbok#new-sbok-download)

Week 1: Introduction to Enterprise Information Systems #

概要

This topic engages students to explore what Enterprise Information Systems comprise, how they have evolved, how they are used in industry, and why digital information systems are essential in modern life.

キーコンセプト

This topic includes:

• What is information?
• What is a system?
• What is a socio-technical system?
• How has enterprise computing evolved?
• How complexity and miscommunication can lead to failure of IS.

レクチャーリスト

• Introduction to EIS
  • Lecture 1: Introduction
• Evolution of EIS
  • Lecture 2: Evolution of modern EIS
• IT System Complexity and Failure
  • Lecture 3: Why IT systems fail?

Lecture 1: Introduction to Enterprise Information Systems (EIS) #

詳細は省略。モジュール全体で学ぶ内容についての概要説明。

Lecture 2: Evolution of modern EIS #

詳細は省略。情報を扱うシステムやコンピュータの発展の歴史についての説明。

Lecture 3: Why IT systems fail? #

IS are hugely complex, new and fast-changing, so it’s not surprising they fail.

• National Programme for IT (2002): series of complex projects to modernise healthcare systems in the UK’s NHS, cancelled after 10 years and
• An IT problem in May 2017 caused cessation of all BA flights from Heathrow and Gatwick, affecting 75,000 passengers across 70 countries.
• Horizon project(2021): a faulty computer system introduced to post offices in the UK in 1999 resulted in mistaken criminal prosecutions for fraud against users of the system.

There are some reasons.

• Miscommunication between business users (who commission the IT system) and the software company (which provides the system).
• Lack of engagement between user and project team over the course of the project.
• Failure to accommodate changing business requirements.
• Failure to introduce the technology-driven change across the enterprise in a manged and proactive way.

Week 2: Systems Development Life Cycle (SDLC) and Methodologies #

概要

This topic introduces the types of systems development projects in organisations (custom build and configuration projects). It then outlines the generic approach (SDLC) to building an IS and introduces the related concept of IS development methodologies, covering the differences between the two broad types - waterfall and agile methodologies.

キーコンセプト

This topic includes:

• What is a structured approach to building EIS and why adopt it?
• What are the generic stages in building an EIS?
• What is systems integration?
• What are the distinguishing features of waterfall and agile methodologies?

レクチャーリスト

• Systems Development Life Cycle (SDLC)
  • Lecture 1: Preliminary concepts
  • Lecture 2: SDLC phases
• Systems Development Methodologies
  • Lecture 3: Methodologies

Lecture 1: Preliminary concepts #

Business have 2 main options to acquire IS:

1. build one
   • build by teams of in-house or outsourced software developers
   • usually a significant effort
   • requires collaboration between business and IT specialists
   • main advantage of this approach is that the customer gets a solution that is designed to meet their specific requirements
2. licence a ready-made IS
   • huge market for enterprise software applications
   • requires effort to implement and configure
   • most EIS now provided as SaaS
     • Most organisations now use SaaS solutions because they are easier to produce / install and can be flexed to match business demand
   • even though already build, software applications need to be “configured” to reflect the company’s operations and “integrated” with existing operations and “populated” with data.

Main challenges in conducting IS projects:

• identifying and articulating the business need, the return on investment and the business requirement.
• communicating business requirements and changes to developers, stakeholders.
• managing and participating in the development process.
• implementing the process and technology changes across the organisation.
• operating the process and solution effectively for the life cycle of the solution.

BIS(Business information systems) have a natural life cycle of use in organisations:

1. commissioned (planned, designed, bought or built)
2. operated (turned on and used in live mode to deliver business value)
3. decommissioned (turned off)

Lecture 2: SDLC phases #

The systems development lifecycle sets out a formal or a semi-formal wayin which the approach to building a more efficient information systemcan happen.

Why do we follow generic stages?

• Creating systems is not intuitive.
• Failures occur (too) often.
• Project are late, over budget or delivered with fewer features than planned.

Commissioning an IS generally follows a predicable life cycle with four main stages:

1. Plan (a proposal for a new - or updated - system is approved, and a plan in made)
2. Analyse (a detailed specification for the system needs is agreed)
3. Design (the technical and operational details of the system are completed)
4. Deploy (the system is implemented in live mode)

Sometimes the SDLC stages are followed sequentially…

Plan
 -> Analyse
     -> Design
         -> Deploy

…and sometimes they deliberately overlap (iteration)

Plan   ->  Analyse
 ^           |
 |           v
Deploy <-  Design

Lecture 3: Methodologies #

There are two main types of systems development methodology, waterfall methodologies and agile methodologies. Waterfall is “structured” and agile is “iterative”. There is no perfect methodology - each has advantages and disadvantages.

Waterfall

• Distinct phases: outputs from preceding phase form inputs to subsequent phase - each phase substantially completed before next phase starts.
• Liner approach and plan, with clearly defined milestones and endpoints.
• Hierarchical teams with clearly defined roles and management.
• Formalised customer interaction and governance.

Waterfall core roles:

• Project manager
• Business Analyst
• Developer

Advantages:

• predictable
• intuitive for developers and users
• familiar and available skills
• easier to estimate and plan

Suited to projects that are:

• well-defined
• predictable
• unlikely to undergo significant change

Disadvantages:

• greater effort (and investment) required in Planning and Analysis phases
• hard to define requirements up front - so system may not do what is required
• sometimes limited interaction between business and development teams
• little visibility of product until late stage of development
• less responsive to change (organisational, market, regulation, technology …)

Agile

Scrum core roles:

• product owner
• scrum master
• developer

Advantages:

• better at accommodating changing requirements
• encourages closer engagement between scrum team and user
• empowers development team
• reflective, controlled (timeboxed)

Suited to projects that are:

• requirements are not clearly defined
• fast changing volatile business environment
• time to market is the priority

Disadvantages:

• business users need to understand basic Scrum processes
• Scrum team needs to follow Scrum disciplines
• need to know when to stop sprinting
• distributed Scrum can be hard

Week 3: Systems Development Life Cycle Phases I and II #

概要

This topic introduces students to the concept of work in the organisation, and the nature of projects. It summarises the planning activities conducted in phase I of the SDLC and highlights some of the challenges in analysis of user requirements (phase II).

キーコンセプト

This topic includes:

• What is a project and how does it relate to work in an organisation?
• What are the activities conducted in Phase I of the SDLC (Initiation, Feasibility)?
• What are the activities conducted in Phase II of the SDLC (Analysis – gathering, documenting and refining user requirements)?

レクチャーリスト

• Projects and Work in an Organisation
  • Lecture 1: Introduction and overview: Projects and work in an organisation
• SDLC Phase I
  • Lecture 2: Starting a project (Initiation and Feasibility)
• SDLC Phase II
  • Lecture 3: SDLC Phase II – Gathering, documenting and refining user requirements

Lecture 1: Introduction and overview: Projects and work in an organisation #

1. Operations
   • Day-to-day delivery of products or services
2. Incremental improvement
   • Minor changes to business processes and roles
3. Step change
   • Significant changes to business processes and roles
4. Transformational change
   • Major (transformational) change - ambitious, major break with the past

Phase 3, 4 requires projects or programmes.

• Project - is a collaborative enterprise to either create new products or services or to deliver specific business value.
• Programme - is group of related projects aimed at delivering coordinated business outcomes.
• Portfolio - is a group of related programmes to deliver overall business outcomes in an enterprise.

Example of portfolio, programme, project

• Portfolio: CrossRail_2021
  • Objective: Build a cross-city transit system in London
• Programme: CrossRail_Infrastructure
  • Objective: Design and build rail, rolling stock and stations for Crossrail
• Project: CrossRail_Rolling Stock
  • Objective: Specify, procure and test trains for CrossRail transit system

Project

• A project is a “one off” activity with a start & end date
• A project has defined goals that deliver business value (e.g. new capability, compliance, cost savings)
• A project has a temporary organisations (project manager/team) and a defined budget (or at least agreed costs)
• Project management practices include activities such as budgeting, reporting, risk assessment, milestone planning…
• Projects are rarely implemented in isolation: usually there are many competing business ideas but limited resources - so a trade-off is necessary.
• Projects are approved, declined or delayed based on value added to the business balanced against risks of implementing the project (or of realising benefits)

Lecture 2: Starting a project (Initiation and Feasibility) #

Planning:

1. assess business value
2. identify project governance
3. develop a work plan

1. assess business value

• IS projects are identified and initiated by business people to meet business needs
• A project sponsor initiates the project proposal and identifies the value it will deliver to the business
• The value can be “tangible” (measurable); “intangible” (hard to quantify); “mandatory”;

2. identify project governance

• Project governance describes how the project will be run and managed
• Governance involves settings up the structures and guidelines for the project (e.g. appointing steering committee members and duties)
• Governance mechanisms will be influenced by the methodology chosen (waterfall or agile)
• Project teams are temporary structures. They are created to achieve a specific goal and are then disbanded.
• The size and shape of the project team sill vary according to the project - and it may change as the project progresses

3. develop a work plan

• A work plan is needed to indicate time, effort and resources required to complete the project
  • In waterfall methodologies, the work plan is usually a “sequential list of tasks” needed to complete a project.
  • In agile methodologies, the work plan is determined by the “product backlog”.
• Estimation - the process of determining the time, skills and effort (and thus the cost) required to complete the project

Lecture 3: SDLC Phase II – Gathering, documenting and refining user requirements #

A “requirement” is a statement of what the system must do or a characteristic it must have

• functional requirement (FR): something the system must do - e.g. the system must calculate insurance premium tax for every insurance quote
• non-functional requirement (NFR): relates to performance or usability - e.g. the system must be available to all users more than 99.99% of the time

Why do problems arise when defining use requirements?

• users may not know what they want!
• …or may disagree about what they want
• …or may not be able to express clearly what they want
• …or it may not be possible to ask users directly so requirements have to be guessed
• …or analysts interpret the requirement incorrectly

But mostly… it’s because things “change”, all the time

• Business requirement changes
• Regulatory environment changes
• Users change their minds
• Technology changes
• People and organisations change
• Financial circumstances change

i. Gathering high-level business requirements

high-level business requirements are usually developed by “talking to users”:

• interviews
• joint application development (JAD)
• questionnaires
• observations
• analysis of existing system

ii. Documenting requirements

what user needs to know about the system (process-oriented) is generally different from what the engineer needs to know (technology-oriented). it’s difficult to communicate “exactly” between two parties!!

many different approaches have been taken to documenting systems requirements, e.g. “functional specification” and “use cases”.

• functional specification: describes the data of a system, describe the operation of the system.
• use case: describes functions performed by users of a system

requirements in agile projects are documented as “user stories”: short, simple descriptions of a business need told from user’s perspective.

Examples of user story:

- "As a <type of user> I want <some goal> so that <some business benefit accrues>"
- Resident Parking: As a resident I want to reserve parking online so that I do not get a parking fine.
- Theatre ticket booking: As tourist, I want to book theatre tickets in advance so that I save time queueing.
- Overdraft limit alert: As an account holder, I want to get SMS alerts of my bank balance so that I stay within my overdraft limit.

iii. Refining requirements by continuous iteration

initially user requirements are defined at a very high level (e.g. we need a new online banking system). requirements need sufficient detail to allow the programmer to build the system (e.g. if account balance is overdrawn by customer overdraft limit, block outgoing payments from account).

Week 4: SDLC Phase III - Design #

概要

This topic describes the design activities conducted during phase III of the SDLC. It introduces the concept of ‘architecture’ in EIS, setting out the purpose of both Enterprise Architecture and Technical Architecture. Finally, it describes the nature and importance of systems integration, which is an essential element of most development projects.

キーコンセプト

This topic includes:

• What is IT architecture?
• What is an Enterprise architecture and why is it valuable in an organisation?
• What is the purpose of a technical architecture? What are the typical components (tiers) of a TA?
• What is systems integration and what typically needs to be integrated in IS design?

レクチャーリスト

• Design
  • Lecture 1: Rationale for deliberate design of IS
• Enterprise Architecture
  • Lecture 2: Enterprise Architecture
• Technical Architecture
  • Lecture 3: Technical Architecture
• Systems Integration
  • Lecture 4: Systems Integration

Lecture 1: Rationale for deliberate design of IS #

Typical enterprise IT environments are messy.

Deliberate design make the solution:

• efficient - operates quickly and correctly
• maintainable - can be fixed easily if it breaks
• less expensive - not complex; optimal use of resources
• easy to integrate with other systems - standard, predictable APIs and interfaces
• flexible - adaptable to different circumstances, different platforms, environments

Enterprise and Technical architecture

• Enterprise architecture covers strategic IT design decisions for the organisation (people, suppliers, systems, standards, processes, policies, etc.)
• Technical architecture covers technical design decisions for a particular solution (e.g. how Oracle Financials should be configured in a company)

Lecture 2: Enterprise Architecture #

in many enterprises, IS investment is often:

• reactive and focused on short term needs
• incomplete (addresses part but not all of the solution)
• uncoordinated - addresses specific (departmental) rather than overall (corporate) business needs
• made independently of constraints (people, legacy systems …)
• poorly informed and not robustly justified or challenged

to address these shortcomings, a company can develop an enterprise architecture (EA)

• an EA is a design or plan for the complete IT environment that summarises strategic design decisions governing the use of IT in an enterprise.
• an EA is an idealised configuration of the organisation’s systems - applications, data and infrastructure.
• EA takes a corporate, holistic, long-term view of the IT needs of the enterprise

EA is not part of the SDLC

• it’s a business/IT design developed once every few years and refined frequently
• EA nonetheless provides guidelines for each individual system design.

Types of strategic design decisions

• commercial: by or build a solution?
• consumer: cloud or on-premise?
• data: shared/distributed data?
• standards: e.g. MS Office or Google Docs? Mac or PC? Agile or waterfall?
• people: permanent staff/contractor rations? Insourced or outsourced developers? Onshore or offshore teams?
• suppliers: formal/informal procurement approach? strategic suppliers? procurement criteria?
• infrastructure: security approach? performance criteria? data protection decisions? systems management?

To develop an EA, an enterprise architect must:

• understand the organisation’s strategic business objectives
• understand the way the industry works
• be aware of technology developments/trends in the industry

artefacts created in developing an EA include:

1. guiding principles
2. an EA framework
3. a migration plan

Lecture 3: Technical Architecture #

TA sometimes described as a “solution architecture” or a “system architecture”

TA is conducted during stage 3 of the SDLC and is necessary to ensure that the system operates efficiently

Purpose of a TA - a TA helps project engineers make informed technology design decisions:

• how software and hardware components fit together
• which application component runs on which hardware platform
• where cost trade-offs can be made
• which control points nad interfaces are required
• non-functional aspects of the systems (reliability, scalability, security, etc.)
• where systems integration is required …

TA components (simplified)

• Software components
  • Presentation layer (UI components)
  • Application layer (business logic, API)
  • Data layer (access logic, storage)
• Hardware components
  • clients (computers, tables, phones, IoT devices)
  • servers (mainframes, VMs, rack mounted, PCs)
  • networks (Local Area Network (LAN), Wide Area Network (WAN), Asvmmetric Digital Subscriber Line (ADSL) …)

Lecture 4: Systems Integration #

systems need to be designed so that they can work together:

• integration of data to ensure consistency and integrity
• integration of front-end and back-end components to ensure functionality
• integration of hardware and software components to ensure operability
• integration with third party and public systems to ensure interoperability

Week 5: Scrum Methodology I - Roles and Activities #

概要

This topic introduces students to the Scrum development methodology. This popular agile methodology is used extensively in the technology industry to build IS products and is increasingly used in other industries to develop enterprise IS.

キーコンセプト

This topic includes:

• Scrum basics - the fundamental Scrum cycle
• The roles in Scrum projects and how they differ from traditional project development roles
• The main activities/ceremonies in the Scrum cycle
• Task estimation in a Scrum project
• Project management tools and techniques in Scrum

レクチャーリスト

• Scrum Roles
  • Lecture 1: Scrum roles and skills
• Scrum Activities
  • Lecture 2: Scrum activities
• Estimation
  • Lecture 3: Estimation
• Scrum project management tools and techniques
  • Lecture 4: Tools and techniques

Lecture 1: Scrum roles and skills #

• Product Owner
  • Primary Function
    • achieving maximum business value for the project
  • Actions
    • articulating customer requirements
    • maintaining business justification for the project
  • Skills
    • Scrum Expert
    • Business domain knowledge
    • Excellent communication skills
    • Scrum processes knowledge
    • Ability to handle uncertainties
    • Negotiation skills
    • Approachable
    • Proactive
    • Decisive
    • Pragmatic
    • Goal-Oriented
• Scrum Master
  • Primary Function
    • ensuring that the Scrum team is provided with an environment conductive to completing the project successfully
  • Actions
    • guiding, facilitating, and teaching Scrum practices to everyone involved in the project
    • clearing impediments for the team
    • ensuring that Scrum processes are being followed
  • Skills
    • Scrum Expert
    • Servant Leader
    • Moderator
    • Problem Solver
    • Approachable
    • Motivator
    • Perceptive
    • Mentor
    • Coordination skills
    • Introspective
• Development Team
  • Primary Function
    • understanding the requirements specified by the Product Owner and creating the deliverables of the project
  • Actions
    • working on the User Stories in the Sprint Backlog to create the deliverables
    • following the SCRUM process in design, development, testing
  • Skills
    • Knowledge of Scrum
    • Collaborative
    • Self-organizing
    • Highly motivated
    • Proactive
    • Technical experts
    • Cross-functional outlook
    • Team player
    • Independent
    • Responsible
    • Intuitive
    • Goal-Oriented
    • Introspective

Lecture 2: Scrum activities #

Sprints

• in the Scrum methodology, work is performed in iterations or cycles called Sprints
• sprints are timeboxed - fixed start and end date, usually the same duration (2-4 weeks)
• no changes of scope or personnel during a Sprint
• work completed in a Sprint should create something of value to business
• typically, multiple consecutive Sprints in a project

Meetings

• sprint planning
  • before sprint execution, Scrum team and product owner assemble Sprint content
  • agree Sprint goal, identify prioritised features/tasks in the product backlog, create “Sprint backlog”
  • estimate the effort required to complete each task in Sprint
  • fill Sprint backlog to capacity (right number of sized tasks)
• daily scrum (“stand-up”) scrum master, developers, product owner
  • timeboxed (15 minutes)
  • scrum team members participate
  • product owner does not participate
• sprint review (“show and tell”) team members and invited customers meet to look at output
  • end of Sprint, timeboxed (up to 4 hours), informal meeting
  • Scrum team presents to attendees
  • open to all interested parties - users/customers/sponsors/stakeholders
  • demo of potentially shippable product increment - completed work - not vapourware or ppt …
• sprint retrospective scrum master, developers, product owner discuss each sprint and assess lessons learnt
  • end of Sprint, 60-90 minutes timebox, Scrum team/PO reflect on Sprint
  • talk about what went well and what did’t - informal & relaxed
  • hosted by Scrum Master, who presents broad questions for team to answer
  • presents a regular opportunity to inspect and adapt the process
• project retrospective team members and invited customers meet to discuss project and assess lessons learnt

Lecture 3: Estimation #

Story Points

• User stories are estimated in story points
• estimates the magnitude of a PBI
• intentionally unit-less measurement designed to describe the relative difference in effort required
• common method of estimation uses points on modified Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 20, 50
• reflects the inevitable uncertainty in estimating very large stories

Estimation Guidelines

• Estimate as a team - facilitation, not direction, from scrum master
• Estimates are not commitments - estimates are estimates!
• Focus on accuracy, not precision to get a “good enough” estimate
• relative, not absolute, estimates - people generally better at this

Lecture 4: Tools and techniques #

• Kanban board
• Velocity
• Burndown Chart