Midterm Notes:

Chapter 1:

Define Information system and name 7 types of information systems:

Information system:

A set of people, systems, processes, data stores connected together with the use of information technology in order to aid in the everyday running and maintenance of an organization. It is used to collect, process and output the information required to support an organization.

Executive Management SystemTransaction Processing SystemManagement Information SystemDecision support systemsCommunication and collaboration systemsOffice automation systemsExpert systems

Identify different types of Stakeholders who use or develop information systems and give examples of each.

Stakeholder: The individuals directly involved in the project with the ability for executive decisions, they are the money men and the financial backing of a project. They include technical and non technical individuals. Internal and External employees.

Stakeholder:

Non technical User/ OwnerTechnical user (designers Builders)System AnalystProject ManagerBusiness DriversTechnology drivers.

Define the unique role of systems analysts in the development of information systems

Bridges the communication gap between technical and non technical users/ownersProblem Solver (Problem, Directive, Opportunity)Initiator of changeProcess Evaluator and Engineer

Identify those skills needed to successfully function as an information systems analyst

Problem solvingTechnology knowledge and TerminologyBusiness Knowledge and Terminology

EthicsPatienceCommunication skillsInterpersonal SkillsProgramming knowledge is an asset.People skillsFlexibility

Describe current business drivers that influence information system development

GlobalizationE-CommerceSecurityPartnershipKnowledge asset managementTQM Total Quality Management Continuos process Improvement CPI

Describe current technology drivers that influence information system development

Networks and the InternetMobile and WirelessObject Oriented DesignCollaborative TechnologiesEnterPrise applications

Briefly describe a simple process of developing information systems

Identify a problem, directive or opportunityAnalyse and understand the problemPropose possible solution requirements and expectationsIdentify alternatives beyond just the primary solutionChoose the best solutionsDesign the best solutionImplement the best solutionSupport the best solutionsEvaluate whether the new solution meets the needs and requirements of the stakeholders, if not begin again after finding a new system analyst.

4 steps of system development

System IntiationSystem AnalysisSystem DesignSystem Implmentation

Chapter 2:

Differentiate between front end and back end systems:

Front office extends to external partners and so forth

Back office is the operations of the company and internal users.

Describe different classes of information system applications and how the interate to supplement each other:

Business Knowledge – Infromation scope and vision – business data reqs-Database technologiesBusiness Processes – Functional Scope and Vision – business process requirements - Software TechnologiesBusiness Communications – communications scope and vision – interface requirements - Interface technologies

Chapter 3

Describe the motivation for a standard systems development process in terms of the capability maturity model:

FastEfficient therefore cost effectiveOrganizedDocumentedRedundant, easy to replace members due to implemented structure.

Differentiate between the system life cycle and a system development methodology

System lifecycle – System Design Process, support and maintenance Process then start over.System development methodology – derived from the system lifecycle, breaks it down further to:

Scope DefinitionProblem AnalysisRequirements analysisLogical DesignDecision AnalysisPhysical Design and integrationConstructions’ and testingInstallation and delivery

Then Life Cycle State of Maintenance and Design.

Problem: An issue causing inefficiency, loss of money or negative aspects within a companies practices, processes or system. The starting point of the project.

Directive: A mandate laid down by a system owner or executive, a piece of the system or process that must be included in the project.

Opportunity: A chance to improve the system, an open door to include a specific functionality into the system due to creating similar functionality for another aspect.

Catagorize Problems Directives OpportunitiesP improve performanceI improve informationE improve economics of the orgC improve control and securityE improve efficiencyS improve service

System Dev vs FAST phasesProject initiation: Scope definition, Problem analysisSystem Analysis: Problem analysis, Requirements analysis, logical designSystem Design: Physical design and integration, construction and testingSystem Implementation: Construction and testing, installation and delivery

Page 80 to 88 Read Once moreProject Intiation – Scope Definition and Analysis produce:Statement of WorkSystem improvement objectsInformation, functional and communications scope.

System Analysis: Problem analysis, Requirements analysis, logical designBusiness data requirementsBusiness process requirementsBusiness interface requirementsLogical Models for each

Decision AnalysisSystem Proposal/Architecture

System Design: Physical design and integration, construction and testingPhysical Specifications – database, process, User interfaceTraining documentationMiddle WareHardware requirements

System Implementation: Construction and testing, installation and deliveryUse CasesTestingEvaluation of requirements and deliverables

Cross-Lifecycle

Process and Project managementFeasibility studiesDocumentation and presentationFact finding

Sequential Development, WaterfallIterative

Chapter 4:

Project Management Traits – Project Management Life cycle:

1. Negotiate Scope – Scopinga. Product: what do you wantb. Quality: how good do you want it to be?c. Time: when do you want itd. Cost: How much are you willing to spende. Resources: What do I have to work with?

Creates Statement of Work

2. Identify Tasks – Planninga. Work BreakDown structure – project formed into Tasks/Milestones

3. Estimate Task Duration – Estimatinga. Optimistic Duration – Best possible outcomeb. Pessimistic Duration – worst outcomec. Expected Duration – Most Likely outcome

4. Specify Intertask Dependencies – Schedulinga. Gant Chart used to track:

i. Finish to Start Dependencies: must finish for the next to startii. Start to start dependencies: must start in combination

iii. Finish to finish dependencies: must finish at the same timeiv. Start to finish: start of one task signifies the next is done

b. Forward Scheduling: start with the project start date and plan forwardc. Reverse Scheduling: Start with the delivery date and work in reverse

5. Assign Resources – Organizing1. Resource Leveling: used to correct resource allocations2. critical path: the sequence of dependant taks that must be

accomplished before the project is complete3. Slack time: amount of acceptable delat

b. Peoplei. Recruit Talent

ii. Select best task for each person, know your people and limitationsiii. Promote team harmony

iv. Plan for the futurev. Keep the team small

c. Servicesd. Facilities and equipmente. Supplies and materialsf. Money

6. Direct the Team Effort – Directinga. Be consistantb. Provide supportc. Keep your promises, don’t make ones you cantd. Praise in public, Criticize in privatee. Be aware of morale danger pointsf. Set Realistic Deadlinesg. Set Reachable Targetsh. Explain and show rather then doi. Don’t rely on status reportsj. Encourage Team spirit

7. Monitor and Control Progress – Controllinga. Project Progress Reportsb. Change Management Requests for new releasesc. Expectations Management – Cost, Schedule, Scope/Quality vs Constraints and

Acceptsi. Management Expectations Matrix can be used

d. Schedule Adjustments – Critical Path analysisi. Are you making it? Do you need adjustments? PERT Charts help with

this.

8. Assess Project Results and Experiences – Closinga. Did the project meet or exceed stakeholder expectations?b. Was it on time?c. Was it on Budget?

Chapter 5:

The 5 phases of system analysis are:

1) The scope definition phase is the first phase of the analysis, it defines if the project is worthy of investigation. The main goal of this phase is to produce the “project charter” which defines the project scope, plan, methodology, standards, and so on. This phase is should be completed fairly quickly and achieve the following objectives:

a. Identify baseline problems and opportunitiesb. Negotiate baseline scopec. Assess baseline project worthinessd. Develop baseline schedule and budgete. Communicate the project plan

2) The problem analysis phase investigates the current system in detail. It evaluates the problem and where it is occurring in the system. The goal of this phase is to study and understand the problem domain well enough to thoroughly analyze its problems, opportunities and constraints. The final phase deliverable is to produce the “system improvement objectives” that address problems, opportunities and directives. The problem analysis phase typically includes the following tasks:

a. Understand the problem domain.b. Analyze problems and opportunities.c. Analyze business processes.d. Establish system improvement objectives.e. Update or refine the project plan.

f. Communicate findings and recommendations.3) The requirements analysis phase defines the business requirements for a new system. The definitions

of WHAT the business needs and not HOW to achieve it. The final deliverable and milestone of this phase is producing the “business requirements statement” which will fulfill the system improvement objectives identified in the previous phase. The requirements analysis phase includes the following tasks:

a. Identify and express system requirements.b. Prioritize system requirements.c. Update or refine the project plan.d. Communicate the requirements statement.

4) The logical design phase further documents business requirements using system models that illustrate data structures, business processes, data flows and user interfaces (Object models can be used and more analysts are doing so). The final phase deliverable and milestone is producing a “business requirements statement” which is the same as the requirements analysis phase due to the logical design being a graphical representation (prototypes) of the requirements. The logical design phase encompasses the following tasks:

a. Structure functional requirementsb. Prototype functional requirementsc. Validate functional requirementsd. Define acceptance test cases

5) The decision analysis phase is where the project team identifies candidate solutions, analyze those candidate solutions and recommend a target system that will be designed, constructed and implemented. This is where the analyst can evaluate off the shelf solutions and determine the best course of action whether it be design in house or implement a pre-built solution. The deliverable and milestone for this phase is the “system proposal” that will fulfill the business requirements defined in the requirements analysis, logical design phases. The decision analysis phase contains the following objectives:

a. Identify candidate solutionsb. Analyze candidate solutionsc. Compare candidate solutionsd. Update the project plane. Recommend a system solution

Study Models:

Page 162, 163, 164, 178

Requirements Discovery:

Fact FindingJRP – Joint Requirements Planning

BPR Methods:

Documents to know: 170, 171

Requestion for Information systemsProblem Statement DocumentationProblems Opportunities Objectinves and constraints MatrixCause and Effect Analysis

Chapter 6:

The requirements discovery process consists of what activities?

The requirements discovery phase consists of the following activities: Problem discovery and analysis

o Problem must be identified then analysed.o Must ensure one does not mistake a symptom as the source of

the problem itself. This can lead to the wrong problems being

solved resulting in new issues arising from the system implementation.

o Problem discovery and analysis can be made easier through the use of tools such as the Ishikawa/Fishbone diagram.

Ishikawa Diagram Graphical tool used to identify, explore, and depict

problems and the causes and effects of those problems. It is often referred to as a cause-and-effect diagram or a fishbone diagram.

• Problem at right (fish head)• Possible causes drawn as "bones" off main

backbone• Brainstorm for 3-6 main categories of possible

causes

Requirements discovery o Given an understanding of problems, the systems analyst can start to define requirements.

o This phase can employ the following method to aid the analyst in the discovery of the problem:

Fact-finding – the formal process of using research, meetings, interviews, questionnaires, sampling, and other techniques to collect information about system problems, requirements, and preferences. It is also called information gathering or data collection.

• Extremely critical in the requirements analysis phase. Once completed, fact-finding uses the following tools:

• Use Cases• Data Models• Object Models

Are used to document facts and conclusions drawn from these facts.

Documenting and analyzing requirements o Requirements and Facts must be documented in a precise,

organized, understandable and meaningful way.o Documenting the draft requirements, analysts can use the following tools:

• Use cases: to describe system functions from the external users perspective and in a manner and terminology the users understand.

• Decision tables: used to document an organizations complex business policies and decision-making rules.

• Requirements tables: used to document each specific requirement.

o Analyze requirements to resolve problems and conflicts that have risen during the requirements discovery phase.o Typical problems that can arise are:

• Missing requirements• Conflicting requirements• Infeasible requirements• Overlapping requirements• Ambiguous requirements

o Formalizing requirements for easy communication between the system owners and the system developers.o The document use is:

Requirements Definition Document – A formal document that communicates the requirements of a proposed system to key stakeholders and serves as a contract for the systems project.

Synonyms Requirements definition report Requirements statement Requirements specification Functional specifications

o Communicated to stakeholders or steering body once completed.

Requirements Managemento Requirements management - the process of managing change to the requirements.

o Over the lifetime of the project it is very common for new requirements to emerge and existing requirements to change. Studies have shown that over the life of a project as much as 50 percent or more of the requirements will change before the system is put into production. o Requirements management encompasses the policies, procedures, and process that govern how a change to a requirement is handled.

Identifies and labels how a change request should be submitted, how it is analyzed for impact to scope, schedule and cost, how it is approved or rejected, and how the change is implemented if approved.

Ishikawa Diagram page 211

Fact finding:1. Sampling of Existing Documentation forms and files2. Research and Site Visits3. Observation of work environment4. Questionnaires5. Interviews6. Discovery Prototyping7. Joint Requirements Planning