Textbook Notes (368,875)
Canada (162,227)
Chapter 11

Chapter 11 - Acquiring Information Systems Through Projects.docx

5 Pages
68 Views
Unlock Document

Department
Computer Science
Course
Computer Science 1032A/B
Professor
Diane Goldstein
Semester
Winter

Description
CHAPTER 11 – ACQUIRING INFORMATIN SYSTEMS THROUGH PROJECTS 1. HOW CAN INFORMATION SYSTEMS BEACQUIRED? ­ 4 basic methods for acquiring software applications: o 1. Buy it and Use it as is o 2. Buy it and customize it  most common method o 3. Rent/Lease it o 4. Build it yourself ­ acquiring software applications is the same as acquiring information systems ­ acquiring information system is more than just obtaining and installing software, involves incorporating software into the current tech infrastructure and integrating software into the data and procedures people use to make things happen in org ­ fig 11-1 ­ new software is not the same as acquiring new information systems because there’s a lot more to think about in systems than just software ­ even if software is free, org will face cost of integrating software with current hardware, data and procedures in the org  costs can exceed costs of software itself 2. WHATARE PROJECTS, WHAT IS IT PROJECT MANAGEMENT,AND WHAT DOES PMBOK MEAN? ­ when an org acquires an info system it has embarked on a project ­ project management body of knowledge (PMBOK) o developed by Project Management Institute 1996 o a project consists of a temporary endeavor undertaken to create a unique product, service or result ­ projects represent change in an org ­ IT Projects: projects that have a large info tech (IT) component (in terms of budget or personnel) or projects that require fundamental changes to business processes because new IT supports change in business processes ­ IT projects affect data, people and procedures ­ Information technology project management (ITPM): collection of techniques and methods that project managers use to plan, coordinate and complete IT projects ­ Guide to PMBOK suggests that there are 5 process groups in any project: initiating, planning, executing, controlling and monitoring, and closing ­ Each of these process groups can be related to one of the 9 project knowledge areas: integration mgmt., scope mgmt., time mgmt., cost mgmt., quality mgmt., human resource mgmt., cost mgmt., quality mgmt., comm mgmt., risk mgmt., procurement mgmt. ­ PMI  global institute that has certified over 260k Project management professionals (PMP) o Also offers Certified Associate in Project Management Program includes intro to PM ­ Canadian Coalition for Tomorrow’s ICT Skills  orgs are looking for business professionals who have knowledge, skills and personal qualities to lead and support the effective, competitive use of IT ­ ITPM is central to the skills needed for orgs to adapt appropriately to an increasing complex business environment 3. WHYARE IT PROJECTS SO RISKY ­ IT faces risks of cancellation, being delivered on time, etc ­ Most IT project definitions are not easily graphically represented  makes it difficult for people to understand what system will look like, how it will behave when its finished, lack of good model is a risk ­ Good estimates for IT projects difficult to develop because tech is always changing ­ Hard to monitor progress: system requirements change as the system is developed, the bigger the system and longer the project, more change in requirement ­ Primary risks do not necessarily emerge from tech  lack of experience in team, lack of top mgmt. support, lack of participation, etc ­ Fig 11-2  read left to right (beginning of project to end) ­ Model tells us 3 things about it project risk: o 1. Project performance has to be evaluated on whether project was on budget/on time (process performance) o 2. Evaluated on whether expected benefits from project were realized (product performance) o 3, shows us 2 pathways:  1. Forces of evil: involves structural risk, volatility risk, project process performance  when structural risk is high, project is large/technical  high levels of structural risk is associated with high volatility risk  volatility risk high, project process performance tends to be lower  2. Forces of good: involve knowledge resources, organizational support, project management practices and both process and product performance  all relationships among items are positively related 4. WHATARE SYSTEMS ANALYSIS AND DESIGNAND SDLC? ­ systems analysis and design: process of creating and maintaining information systems  concerns IS not just comp programs ­ systems development: not exclusively a technical task undertaken by programmers and hardware specialists ­ requires coordinated teamwork by specialists and non specialists with business knowledge ­ agile method: development methods such as rapid application development (RAD), object oriented systems development (OOD) and extreme programming (XP) The Systems Development Life Cycle (SDLC) ­ systems development life cycle (SDLC): classical process used to acquire information systems ­ 1970s  project managers agreed on basic tasks needed to be performed to successfully acquire and maintain information systems ­ 5 phase systems development process: o 1. Systems definition o 2. Requirements analysis o 3. Component design o 4. Implementation o 5. System maintenance ­ fig 11-3 ­ acquisition begins when business planning process IDs need for new system ­ developers in the first phase: systems definition, use managements statement of the system needs to begin to define the new system ­ resulting project plan is the input into 2 phase (requirement analysis)  ID particular features and functions of new system ­ output of above phase is a set of approved user requirements which becomes the primary input used to design system components ­ phase 4, developers implement, test and install new system ­ maintenance phase: description of fixes and new requirements ­ cycle starts again Step 1: Defining the System Define System Goals and Scope ­ 1 step define goals and scope of new IS Assess Feasibility ­ aim: eliminate inappropriate projects before forming a project development team ­ feasibility has 4 dimensions: cost, schedule, technical, organizational ­ feasibility can only be approximate ­ technical feasibility: whether existing IT is likely to be able to meet needs of new system ­ organizational feasibility: concerns whether new system fits within orgs customs, culture, charter or legal requirements Step 2: Requirements Analysis ­ forming project team and develop requirements ­ development of project requirements is essentially mgmt. of scope in IT project ­ when developing requirements, team normally consists of IT personnel and user reps ­ work of analysis and design is often completed by business analysts and system analysts ­ business analyst: focus on current system and procedure and interact with stakeholders of system ­ system analyst: more technically focused IT professionals who understand tech ­ during requirement definition: team consists of business and system analysts ­ during design and implementation: emphasis shifts to programmers, testers and database designers ­ during integrated testing and conversion: team will be of testers and business users ­ important for users to have active involvement and to take ownership of the project throughou
More Less

Related notes for Computer Science 1032A/B

Log In


OR

Join OneClass

Access over 10 million pages of study
documents for 1.3 million courses.

Sign up

Join to view


OR

By registering, I agree to the Terms and Privacy Policies
Already have an account?
Just a few more details

So we can recommend you notes for your school.

Reset Password

Please enter below the email address you registered with and we will send you a link to reset your password.

Add your courses

Get notes from the top students in your class.


Submit