BISM 1201 Final - Summary Transforming Business with Information Systems PDF

Preview

Summary

by woody ...

Description

BISM 1201 Excel: 1) Min; Max; 2) Year; Day; Hour; Minute; 3) Left; 4) Error.Type; IfError; 5) VLookup; 6) And; Or; If; 7) Index; 8) Sum; 9) &; 10) Rept; 11) Len Week 5 – Week 12 MP4 & Excel Examples & Tutorial Business Management: 1) Information System Development (Lecture 5-7,11) 2) Business Intelligence (Lecture 8-10,12) Lecture 5 – Lecture 12 Lecture Slides & Tutorial Example Final Exam Lecture 5 & 6 Information System Development (ISD) – Introduction 1) Introduction a. ISD also be known as System Analysis and Design b. Process of Creating and Maintaining IS c. Involve all Five Components of IS: - Computer Programming: Hardware; Software;(Programe) + Data - Procedure; People

d. Unlike software, the ISD never “off-the-shelf” (现成的), must Construct or Adapt procedures to fit in the people and business who use the software. e. Requirements of ISD: (more than Programming and Technical expertise) It requires: - Business process knowledge and Management skills; - Technical skills & Non-technical skills( human relation skills & interview 面试 & group dynamic skills) - Knowledge of business activities - Skills to develop job description and to train staff - Collaboration of Business 业务 & Technical specialists 技术专家: sometimes seeming to speak different language. 2) Difficulty and Risky

a. Many projects are “Not finished” “Over budget” “Over time” “Do not accomplish it goals” b. May produce “good” software, but not work to user’s expectations. (This mismatch is very difficult to solve, and usually falls to category c.) c. Difficulty of “Requirements Determination 要求确定” - A moving target (features; need; prioritize; bigger system-longer project-more changing requirements; needed data; collapsing timelines) d. Scheduling and budgeting difficulty - Done many times before general agreement - How long to: build the system; create data model; testing; develop & document procedures - Financial side: cost? Rate of reture? e. Changing technology - Diverse system environment within the system - After agreement, during development, the technology maybe changing f. Diseconomies of scale - Adding more people in a project – making project latter - Tasks can’t be quickened up 不能加快 – schedules can be compressed only so far 从目前 为止进行压缩 g. Risks evident in all activities – the risks must be managed 3) Solutions of “Difficulty and Risky” To solve these problems, the “Development methodologies 发展方法” are emerged. The “System Development Lifecycle” is at the center of the most common “Development methodologies”. Basic tasks are combined into these seven phrases. [Type 1 category SDLC method]

Phrase1: Planning – Phrase2: Analysis – Phrase3: Design – Phrase4: Development – Phrase5: Testing – Phrase6: Implementation – Phrase7: Maintenance [Type 2 category SDLC method]

Phrase1: System Planning and Selection – Phrase2: System Analysis – Phrase3: System Design – Phrase4: System Implementation and Operation 4) Waterfall Model (comprises one iteration of the SDLC five phases) a. System Definition (system planning stage): Management’s Statement defines New System.

“Team of users” and “IS Professionals” assigned to “assess feasibility” (e.g. A small company may hire a “consultant” to work with “managers and key employees”) Step 1: Define the “goal” of the “new system” (Alignment with “Business”) To facilitate the “Competitive Strategy” (Identify supporting business process & Improve decision making) (e.g. Create quality relationships with quality customers – Use those relationship to generate revenue) Step 2: Define the “scope” of the “new system” (By “customers” “business process”-users be impacted “physical location” “functional area”) A clear “definition of scope” simplifies “Requirement determination” & “Development work”-what other systems will be relevant (many other stakeholders within the organization) Step 3: Asses “feasibility” • Cost / Economic feasibility (i.e. the financial cost) o Approximated, “back-of-the-envelope” analysis 粗略分析 (A back-of-theenvelope calculation is a rough calculation, typically jotted down on any available scrap of paper such as an envelope. It is more than a guess but less than an accurate calculation or mathematical proof.) o Purpose: eliminate infeasible ideas as soon as possible

• • • • • • • •

o Net present value (NPV), return on investment (ROI), break-even analysis, business case. Schedule feasibility (i.e. the timetable) Difficult to determine but a rough estimate is needed Technical feasibility (i.e. can we build/run/maintain this) Is the proposed system able to be built using existing information technology? Organizational / cultural feasibility (i.e. will the staff use this) Does the proposed system fit the customs, culture, charter 宪章 and legal requirements of the organization? Legal feasibility Measures how well a solution can be implemented within existing legal and contractual obligations

Step 4: Estimation (The real estimation process) 1) Estimates (time & dollars) can be problematic: lack of precision, lack of credibility. 2) Estimating = just “theory” = average of many people’s guess 3) “Project manager” sum up estimates – take results to management – management negotiates (justification, but negotiation causes problem, that is a negative impact) 4) Start with “optimistic 乐观的 schedule” – Ends up “Late”(Developers/Managers not take project deadlines seriously) Step 5: Form a Project Team If deemed feasible, the “project team” is created. Normally includes “IT personnel” & “User”, for the duration of the project. Typically includes:  Managers;  System/Business analysts (IT professionals with a knowledge of business & technology);  Programmers, architects and software tester;  Users (Through entire SDLC process; Have involvement through the development process, not just begin or end) b. Requirements Analysis: Identify features and functions.

1) If the requirements are wrong, the system will be wrong. 2) Determine & Document features and functions Interview users and all stakeholders – Document requirement (Various techniques: Examine “existing system”; Review “reports, forms, queries, application features; Security and control.) 3) Functional & Non-functional requirements (e.g. Security)

4) May involve “Creation of a data model for a new database” 5) Approve requirement - Later requirements changed, most work/cost is involved. (exponential increase 指数增 长) - Requirements should be approved “before” A project continues. (Requirements should be planned down to every possible level of details. The extent of the plan.) - Modern approach: “definitive requirement”明确的要求 – priority feature 优先功能; “abstracted requirement”抽象的要求 – rest of the feature 其余功能. (The heart of “Agile development”) c. Design, Development and Testing: Based on approved user requirements.

Each of the “five components” designed at this stage. [Hardware design] determined by “project team” Specifications 规格 and Source 来源/Vendor 供应商 [Software design] depends on “source” (also called “software” as “process model”) Off-the-shelf 现成; Off-the-shelf with alternatives; Custom-developed 定制开发 programs [Database design] [Procedure design] for “users” and “operational personnel” Normal(正常), Backup(备份), Failure recovery(故障修复) procedures [People] duties and responsibilities for “new jobs” and “revised jobs 修改工作” Step1: Build - “Components/ Modules” constructed “independently” then “combined” - “Document” - “Review” (Some components may be “outsourced” 外包) Step2: Test - Unit testing (Individual components) - System/Integration testing - Ensure all Sequences 顺序 of action (Both normal and incorrect actions) - Labor intensive 劳动密集 (almost always empirical 经验的) - Very late stage testing (another topic issue within business/ industry)

Step3: Train Users must be trained to use the “new system” Step4: Convert (take the system “live”) Stop doing the things the “old way” – Start using the “new information system” d. Implementation: Implement, test and install new system System Conversion -Strategy1: Pilot 单位测试 Organization implement “entire system” on “single, limited” unit. If system fails, only affect limited boundary, reduce exposure. -Strategy2: Phased 阶段测试 “new system” installed in “phases” – test “each phases” – “continue” until installed at “entire” organization. Can’t be used in “tightly integrated” systems -Strategy3: Parallel 平行测试 “new system” and “old system” run the testing parallelly. Expensive & Time consuming (Data be entered twice) but Easy fallback position (excellent verification of result, reduce risk!) -Strategy4: Plunge 跳跃测试 Direct installation. (install new, discontinue old) No backup position (high risk!)

e. Maintenance: Fix errors, add new functions and maintain system

1) Very “costly” stage (frequently more than 50% overall project cost) 2) Fixing or adapting system - Patch 补丁 Applied to “all copies” of a commercial software product; Bundled as “service packs”. - Minor enhancement 小改进

“Adaptation” to new requirements (done via “service pack”) - Major enhancement 大改进 “new version” of software product; Start of “new cycle” of SDLC - Failures “hardware” and “database” failure also need to be fixed 5) Some features of “Waterfall Model”

a. Highly sequenced 高度排列 within an overall cycle b. Designed for projects management c. Various approval stages/gates 批准阶段, so it is important to have effective management & control) d. Difficult to come back up the “waterfall” 6) Some problems with SDLC a. Traditional SDLC/ Waterfall/ Plan-driven/ Classical model “Linear sequence” of “non-repeated” phases is BAD, “iteration” is GOOD. (iteration – cornerstone of collaboration) b. Requirements “documentation” difficulty - “Business requirement” change – “Documented requirement” incomplete or obsolete. (Too much time/effort on “planning” or “plan has a short life”) - “Analysis paralysis”分析瘫痪 (Too much time on “Documentation”, then hampers the progress) - Large system, impossible job to definitely complete all planning at the very first stage. c. “Scheduling, Planning, Budgeting” difficulty - Large project, time and cost estimation always way off. - Difficult to plan every detail.

7) Alternatives to Traditional SDLC

Agile approach (light-weight methodology): based on the idea of incremental & evolutionary a. Team has a “different attitude” to development b. Emphasis on “people & cooperation” over “processes and tools” c. “Working software” important than “Documentation” d. “Customer collaboration” 客户协作 over “Contract negotiation” e. “User involvement” at the level of “true collaboration” f. “Responding to change” over “Following a plan” (plan has short half-life 半衰期) 8) Tutorial questions 1. Describe the phases/stages of the system development lifecycle (SDLC) These stages are: Definition, Analysis, Design, Build/Test/Implementation, Maintain. 2. Define feasibility study. Feasibility study: Define a business problem or a new opportunity – Investigating options available for the best solution – Making a recommendation – Estimating the probability of success. 3. What is the difference between systems analysis and systems design? Systems analysis is the detailed study and documents of the “as is” situation(不予改变) AND the requirements for the new system. Systems design is the development of a technical specification(技术条件) that details the system inputs, outputs, and interface(交界面) as well as the hardware, software, databases, telecommunications(远程通讯), personnel(全体人员), and procedures needed to provide a solution for the requirements developed in the analysis stage. Systems design also provides a blueprint for integrating these various components. 4. Why is it important for everyone in business organisations to have a basic understanding of the systems development process? The “End users” possess the business knowledge The “IS staff” needs to develop all of the components of the system’s design. For this reason, “user input” is critical to the acquisition and/or design of “a successful IS”. 5. Discuss the various types of feasibility studies. Technical, Economic, Behavioural, and Organizational feasibilities are different facets( 方面) of the analysis. Technical – Determines if the current hardware and software platform is appropriate as well as whether the system should be developed in house(内部的) or purchased from a vendor. Economic – determines if the project has an acceptable financial risk and whether the organization can afford it. Behavioral – determines if the corporate culture is open to the change. Organizational – determines whether the organization has any external issues that would preclude 妨碍 the project from being successful and whether the project meshes 相符合 with the company’s strategic plan.

Lecture 7 Information System Development (ISD) – Agile, SCRUM, Extreme, Programming (XP – brief introduction) 1) Agile methodologies – an overview - “Agile development” is not a methodology in itself, it is an “umbrella term” that describes “several Agile methodologies”. - Aiming at “Adaptive” rather than “Predictive”. - In 2001, it includes: XP, SCRUM, D(dynamic)SDM, F(feature)DD. Each of them has a “slightly different” approach. - Popularity/ Taken-up: 50% SCRUM; 20% SCRUM with XP; 12% XP (80% SCRUM or XP) 2) SCRUM – an introduction - An Agile process, delivering “highest business value” in the “shortest time”. - Rapidly and Repeatedly (every 2 weeks to 1 month) inspect “actual working software”. - The business sets “priorities”. (Teams self-organize, the best way to deliver highest priority features) - Anyone can see “real working software” every 2 weeks to 1 month, and determine to “release it as is” or “continue to enhance it for another sprint” (Product progress in a series of “month-long sprints”) - No specific engineering practice prescribed 规定 - “Requirements” capture from “a list of product backlog”

3) SCRUM – sprint - SCRUM “make progress”取得进展 in a series of “sprint” (Similar to Extreme Programming iterations) - Typical duration: 2 weeks – 4 weeks at most

(4 weeks is most popular, planed based on how long a team can commit to “keeping change” out of the sprint) *No change during the sprint! - Scope of each sprint: frozen but can be reduced if necessary - Time period: keep constant (constant duration – better rhythm) - During sprint: the product is “designed, coded, tested” 4) SCRUM – Sequential 顺序 vs Overlapping 重叠 development Rather than do “one thing at a time”, SCRUM do “everything all the time”. (everything: requirements – design – code – test)

5) SCRUM framework - Roles (Product owner; SCRUM master; Team) Product owner: define the “features” of the product; decide on release “date and content”; responsible for “profitability” of the product (ROI); “prioritize” features according to “market value”; “adjust” features and “priority” every iteration, as needed; “accept or reject” work result. SCRUM master: Represent “management” to the project; Responsible for enhancing SCRUM “values and practices”; Ensure that the “team” is fully “functional” and “productive”; Enable “close cooperation” across all roles and functions; Shield 保护 the team from external interferences 外部干扰. SCRUM team: Typically, 5-9 people; Cross-functional (programmers, testers, analysts, user experience designers…); Members should be full-time (exceptions: database administrator); Self-organizing (ideal: no title, “flat” team, but rarely possibility) * Scalability 延展性 (Is the “size” of SCRUM team “adjustable”?) - Typically, 5-9 people; - Comes from “teams of teams”; - Scaling factors: type of application; team size; team dispersion 团队分散; project duration. (SCRUM has been used on “multiple 500+ person” projects.) - Ceremonies (Sprint planning; Sprint review; Sprint retrospective 回顾; Daily SCRUM meeting) Sprint planning: - Team “select” items (can commit to completing) from “product backlog” + “create” the “sprint backlog”. During this process, “tasks” are identified and estimated, “collaboratively” (not alone by SCRUM master) - High-level design: “work” estimated. Create User Stories: A user story describes functionality that will be valuable to either a user or purchaser of a system or software. Valuable functionality

User stories are written from the end user’s point of view. For example: "As a returning customer, I want to find a meal that I have ordered before." From end user’s point of view Prioritize the User Stories: Product owner prioritizes the user stories in the product backlog by working with your customers to understand what they value and by working with your team to understand risks and dependencies. Working with customer to understand what they value & Working with team to understand risk and dependencies + Prioritize the users’ stories in the product backlog Product owner specifies priorities by assigning a rank to each user story to indicate the order in which the team should implement them. Ranking & Ordering Estimate the User Stories: Team collaboratively estimates each user story in story points. Story points: - A unit of measure for expressing the overall size of a user story, feature or other piece of work. - Relative values that do not translate directly into a specific number of hours. - Help a team quantify the general size of the user story. Collaboratively + Using “story point” (overall size, feature, piece of work, relative value) Sprint Review: 1. Presenting “accomplished work” during the sprint. (Whole team participates) 2. Form: A demo of new feature 3. Informal (2-hour preparation time rule, no slides) Sprint Retrospective: (project management) 1. Periodically take a look at what is (is not working 不起作用) 2. 15-30 minutes 3. Done after every sprint Daily SCRUM meeting: 1. Daily 2. 15 minutes 3. Stand-up 4. Not for problem-solving 5. Whole word is invited but only team members, SCRUM Master, product owner can talk. - Artifacts (Product backlog; Sprint backlog; Burndown charts) Product backlog: 1. The requirements; 2. A list of “desired work” on the project 3. “Ideally expressed” – each item has “value” to users or customers of the product 4. “Prioritized” by the product owner 5. “Reprioritized” at the start of the sprint.

Burndown Charts: (macro view) 1. Note the “difference” to the “next item” of documentation. 2. A project management tool: measure “Work to be done” v “time”

6) Project management – PERT chart - PERT: Program Evaluation and Review Technique - A graphical network model: tasks and the relationship between them - Critical path: “Sequence” of activities; Determine the “earliest date” of work completing

7) Extreme Programming (XP) – a brief introduction - “Software development”: be used as a part of SCRUM - An Agile methodology - Takes the “best practices” of software development & Extend them to the “extreme” (Focus intensely on “proven industry practices”成熟的行业实践 ＋ Combine them in “unique ways” to “get better results”) - Fit nicely with SCRUM (SCRUM: no specific engineering practices, XP done here)

8) Extreme Programming (XP) – Pair Programming - Two programmers, sit together, in front of a workstation 工作站 One “enter” code – Helm – Keyboard and mouse doing implementation One “review” the code and “thinks” – Tactician – Think about the implications & possible problems - “Pair programing, is a dialog between two people, trying to simultaneously program & understanding how to program better” Kent Beck (Originator of XP) - Second most important practice after tests - Pairs “change” continuously (few times in a day): “every programmers” know “all aspects” of the system; “a programmer” can be easily “replaced” in the “middle” of the project - Cost 10-15% more than “stand-alone programming” but Less defects (15%) because of simple code (fewer lines of code). 9) On-site customer 现场客户 - Heavy influence on “changing the SDLC” - User stories are “not detailed”, so there are always “questions” to ask the customer - “Software developers” have “continuous access” to a “real live customer” (someone who actually be using the system) - The “customer” must always be “available” To “resolve ambiguous”; “set priorities”; “provide test cases”. 10) Tutorial questions: Agile ISD Q1: Explai...