ITM305 Midterm+Final Exam notes

22 Pages
Unlock Document

Information Technology Management
ITM 305
Jim Tam

ITM 305 – Exam Review Notes Computer Application A computer software program that executes on a computing device to carry out a specific set of functions. Information System A set of interrelated components that collect, process, store and provide as output for the information needed to complete business tasks. Project A planned undertaking that has a beginning and end and produced some definite result. System Analysis Those activities that enable a person to understand and specify what an information system should accomplish. Systems Design Those activities that enable a person to define and describe in detail the system that solves the need System Development The entire process consisting of all activities required to build, launch, and Lifecycle (SDLC) maintain an information system. - Identify the problem or need and obtain approval - Plan and monitor the project - Discover and understand the details of the problem or need - Design the system components that solve the problem or satisfy the need - Build, test, and integrate system components - Complete system tests and then deploy the solution Information Systems The actual approach used to develop a particular information system Development Process (aka: methodology) - Unified Express (UP) - Extreme Programming (XP) - Scrum - Most processes/methodologies now use Agile and Iterative development. Agile Development An information system development process that emphasizes flexibility to anticipate new requirements during development - Fast on feet; responsive to change Iterative Development An approach to system development in which the system is “grown” piece by piece through multiple iterations Ceremony The level of formality of a project; the rigor of holding meetings and producing documentation. System Controls Checks or safety procedures to protect the integrity of the system and its data. ITM 305 – Exam Review Notes Core Processes 1. Obtain approval to commence the project (core process 1) - Meet with key stakeholders, including executive management - Decision reached, approve plan and budget 2. Plan the Project - Determine the major components (functional areas) that are needed Supplier information subsystem Product information subsystem - Define the iterations and assign each function to an iteration Decide to do Supplier subsystem first Plan one iteration as it is small and straight forward - Determine team members and responsibilities 3. Discover and Understand Details - Do preliminary fact-finding to understand requirements - Develop a preliminary list of use cases and a use case diagram - Develop a preliminary list of classes and a class diagram 4. Discover and Understand Details - Define the user experience with screens and reports - Design the database (schema) Table design Key and index identification Attribute types Referential integrity - Design the system’s high level structure Browser, Windows, or Smart phone; OO or procedural Architectural configuration (components) Design class diagram Subsystem architectural design 5. Discover and Understand Details - Continue programming (build) - Build use case by use case - Perform unit and integration tests 6. Discover and Understand Details - Perform system functional testing - Perform user acceptance testing - Possibly deploy part of system Two general approaches to System Development Lifecycle 1. Predictive Approach (Waterfall Method) - Assumes project can be planned in advance and that the information system can be developed according to the plan - Requirements are well understood and/or have low technical risk Traditional Predictive SDLC - Earlier approach based on engineering - Typically have sequential Phases - Phases are related groups of development activities, such as planning, analysis, design, implementation, and deployment ITM 305 – Exam Review Notes Newer Adaptive SDLC - Emerged in response to increasingly complex requirements and uncertain technological environments - Always includes iterations where some of design and implementation is done from the beginning. Waterfall Model - SDLC that assumes phases can be completed sequentially with no overlap or iteration - Once a phase is completed, you move to the next phase, no going back.  Initialization  Planning  Analysis  Design  Implementation  Deployment  Support Spiral Model - First adaptive SDLC - Cycles run over and over again through development activities until completion 2. Adaptive Approach (Iterative Model) - Assumes the project must be more flexible and be able to adapt to changing needs as the project progresses - Requirements and needs are uncertain and/or have high technical risk -Some Analysis, Some Design, Some Implementation......More Analysis, More Design, More Implementation…....Even more Analysis, Even more Design, Even more Implementation...…Etc… Incremental Development - Completes portions of the system in increments - A system is implemented and partially deployed in steps during the project Gets part of working system into users’ hands sooner Walking Skeleton - Complete system structure is built early, but with bare-bones functionality ITM 305 – Exam Review Notes SDLC Support Phase - All information systems need to be supported once completed - Predictive SDLCs typically include support as a project phase - Adaptive SDLCs treat support as a separate project - Support Activities: Activities whose objective is to maintain and enhance the system after it is installed and in use Maintaining the system - Fix problems/error - Make minor adjustments - Update for changes in operating systems or environments Enhancing the system - Add desired functionality - Add or change functionality to comply with regulations or legislation Supporting the users - Ongoing user training - Help desk Methodologies - Includes a collection of techniques that are used to complete activities and tasks, including modeling, for every aspect of the project - Provides guidelines for every facet of system development: What to do when, why and how. - Specifies an SDLC with activities and tasks - Specifies project planning and project management models and reporting - Specifies analysis and design models to create - Specifies implementation and testing techniques - Specifies deployment and support techniques Model - An abstraction of an important aspect of the real world. - Makes it possible to understand a complex concept by focusing only on a relevant part - Each model shows a different aspect of the concept - Crucial for communicating project information ITM 305 – Exam Review Notes Some models of System Components include: - Flowchart - Data flow Diagram (DFD) - Entity-Relationship Diagram (ERD) - Structure Chart - Use-Case Diagram - Class Diagram - Sequence Diagram Some models used to manage the development process include - Gantt Chart - Organizational Hierarchy Chart - Financial Analysis Models – NPV, Payback Period Two Approaches to Software Construction and Modeling: 1. The Structured Approach - Earlier approach. - Assumes a system is a collection of processes that interact with data - Structured analysis, structured design, and structured programming 2. The Object-Oriented Approach - More recent approach. Assumes a system is a collection of objects that interact to complete tasks - Object: A thing in an information system that responds to messages by executing functions or methods (Class Diagrams) - Object-oriented analysis (OOA) - The process of identifying and defining the use-cases and sets of objects (classes) in the new system - Object-oriented design (OOD) - Defining all of the types of objects necessary to communicate with people and devices and showing how they interact to complete tasks - Object-oriented programming (OOP) - Writing statements that define the actual classes and what each of its objects does. Agile Development - A guiding philosophy and set of guidelines for developing information systems in an unknown, rapidly changing environment - Complements Adaptive SDLCs and Methodologies that support it - Takes adaptive and makes sure developers are fast on their feet to respond to changes - Value responding to change over following a plan - Value individuals and interactions over processes and tools - Value working software over comprehensive documentation - Value customer collaboration over contract negotiation Project Management What is a Project? - A planned undertaking with a defined beginning and end that produced a predetermined result and is usually constrained by a schedule and resources. ITM 305 – Exam Review Notes The need for Project Management - Only 32% of IT projects succeed - 44% late/over-budget/reduced scope - 24% failed Reasons for failure - Undefined project management practices - Poor IT management and poor IT procedures - Inadequate executive support for the project - Inexperienced project managers - Unclear business needs and project objectives - Inadequate user involvement Role of a Project Manager - Serve as a locus of control for a project team - organize and direct other people to achieve a planned result within a predetermined schedule and budget. Internal Responsibilities - Developing the project schedule - Recruiting and training team members - Assigning work to teams and team members - Assessing project risks - Monitoring and controlling project deliverables and milestones External Responsibilities - Act as the main contact for the project, represent the team, and communicate the team members' needs - Reporting the project’s status and progress - Working directly with the client (the project’s sponsor) and other stakeholders (client/customer, oversight committee/steering committee, users) - Identifying resource needs and obtaining resources Cost/Benefit Analysis - Net Present Value (NPV) - The present value of dollar benefits and dollar costs of a particular investment - Payback Period - the time period after which the dollar benefits have offset the dollar costs - Tangible Benefit - a benefit that can be measured or estimated in terms of dollars - Intangible Benefit - a benefit that accrues to an organization but that can’t be measured quantitatively or estimated accurately (customer satisfaction, increased levels of service, survival) Determining Project Risk & Feasibility Determine the organizational risks and feasibility - How well does the new system fit the organizational culture? Risk of negative impacts? Evaluate the technological risks and feasibility - Can the system be built by the team using technology needed? Training available? Assess the resource risks and feasibility - Are the needed resources available? Skilled people? ITM 305 – Exam Review Notes Identify the schedule risks and feasibility - Can the system be built in the amount of time available? Fixed Deadline? Project Management Body of Knowledge (PMBOK) - PMBOK is organized into 9 knowledge areas: Project Scope Management - Defining and controlling the functions that are to be included in the system as well as the scope of the work to be done by the project team Project Time Management - Creating a detailed schedule of all project tasks and then monitoring the progress of the project against defined milestones Project Cost Management - Calculating the initial cost/benefit analysis and its later updates and monitoring expenditures as the project progresses Project Quality Management - Establishing a comprehensive plan for ensuring quality, which includes quality control activities for every phase of a project Project Human Resource Management - Recruiting and hiring project team members; training, motivating, and team building; and implementing related activities to ensure a happy, productive team Project Communications Management - Identifying all stakeholders and the key communications to each; also establishing all communications mechanisms and schedules Project Risk Management - Identifying and reviewing throughout the project all potential risks for failure and developing plans to reduce these risks Project Procurement Management - Developing requests for proposals, evaluating bids, writing contracts, and then monitoring vendor performance Project Integration Management - Integrating all the other knowledge areas into one seamless whole Ceremony - The level of formality of a project; the rigor of holding meetings and producing documentation. Agile Project Management (APM) - An information systems development process that emphasizes flexibility to anticipate new requirements during development - Neither team members nor user completely understand the problems and complexities of the new system, so the project plan and execution of the project must be responsive to unanticipated issues. - "Chaordic" A plan that allows chaos while remaining controlled or ordered. Technology architecture - The set of computing hardware, network hardware and topology, and system software employed by the organization ITM 305 – Exam Review Notes Application architecture - The information systems that supports the organization (information systems, subsystems, and supporting technology) FURPS+ - Functional requirements - Usability requirements - Reliability requirements - Performance requirements - Security requirements + Even more categories… Use-Cases and User Goals - Use-Case - An activity that the system performs, usually in response to a request by a user. - User Goal Technique - One approach to identifying use cases. - Analyst identifies all users and then conducts structured interviews with each user to determine each user’s specific goals and objectives are. - By focusing on one type of user at a time, the analyst can systematically address the problem of identifying use cases. - The main goal of the analyst is to identify how a system can help the user(s) perform assigned tasks. - Subsidiary goals can include helping to streamline tasks, and enable the user to perform tasks that aren’t possible or practical with the current system. - Event Decomposition Technique - A technique used to identify use cases by breaking down all the external business events into elementary business processes that will cause the information system to respond, and each event leads to a use-case. Benefits: - Events are broader than Goals: Allows to capture temporal and state events. - Helps break down to right level of analysis (EBP) - Uses Perfect Technology Assumption to ensure functions that support the user specifically are identified. Steps to Event Decomposition Technique 1. Consider the external events in the system environment that require a response from the system - External Agent wants something resulting in a transaction. - External Agent wants some information - Data changed and needs to be updated - Management wants some information 2. For each external event, identify and name the use case that the system requires 3. Consider the temporal events that require a response from the system - Internal Outputs needed - Management Reports (Summary or Exception) - Operational Reports (Detailed Transactions) - Internal Statements and documents (including payroll) ITM 305 – Exam Review Notes - External Outputs needed - Statements, Status Reports, Bills, Reminders 4. For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case 5. Consider the state events that the system might respond to, particularly if it is a real-time system in which devices or internal state changes trigger use-cases. 6. For each state event, identify and name the use case that the system requires and then define the state change. 7. When events and use-cases are defined, check to see if they are required by using the perfect technology assumption. Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in later. Elementary Business Processes (EBP) - The most fundamental tasks in a business process, which leaves the system and its data in a stable and consistent state. Usually performed by one person in response to a business event. - Adds measurable business value. Event - Something that can occur at a specific place and time, can be precisely identified, and must be remembered by the system. Types of Events: - External Events: Events that occur outside the system. Usually initiated by an external agent or actor (a person or organizational unit that supplies or receives data form the system, i.e. a customer). When describing an external event, it is important to name the event so that the external agent is clearly defined (i.e. “Customer places an order.”) - Temporal Event: An event that occurs as a result of reaching a certain point in time, without external input. (i.e. producing payroll slips or quarterly reports.) - State Event: An event/process triggered by something that occurs within the system. Sometimes also called Internal Events. State events are similar to Temporal Events, but different in that they cannot be tied to a defined point in time.) (i.e. “Time to reorder stock” but not “Stock reorder date”) Identifying Events Events versus Prior Conditions/Responses - Not all the events leading up to an interaction with the system (event) are necessarily part of the event itself. The Sequence of Events: Tracing a Transaction’s Life Cycle - It is often useful to trace the sequence of events that lead to a transaction. A customer ordering a catalogue (Name and Address are entered into the system), Placing an order online, changing the order, checking the status of an order, or cancelling an order. All of these events are not directly tied to the transaction, but are all important events that can occur between the user and the system. Technology-Dependant Events and System Controls - Events that, during analysis, the analyst should ignore – usually consisting of design choices or System Controls, which are checks or safety procedures put in place to protect the integrity of the system. (i.e. Back-ups, Security, Intrusion Detection) ITM 305 – Exam Review Notes Perfect Technology Assumption - A statement that assumes that events are included in the analysis only if the system would be required to respond under virtually perfect conditions (no faults, no hardware limitations, accurate/reliable data provided) CRUD Technique - An acronym for Create, Read/Report, Update, and Delete (Archive) - Used to validate or cross-check Use-Cases, often for databases CRUD Technique Steps: 1. Identify all the data entities or domain classes involved in the new system. 2. For each type of data (data entity or domain class), verify that a use case has been identified that creates a new instance, updates existing instances, reads or reports values of instances, and deletes (archives) an instance. 3. If a needed use case has been overlooked, add a new use case and then identify the stakeholders. 4. With integrated applications, make sure it is clear which application is responsible for adding and maintaining the data and which system merely uses the data. Use-Case Diagrams - A UML model us used to graphically show use cases and their relationships to actors - “Actor” is the UML name for the end user - Automation Boundary separates the computerized portion of the application and the users who operate the application Use-Case Diagram Steps 1. Identify all the stakeholders and users who would benefit by seeing a use case diagram 2. Determine what each stakeholder or user needs to review in a use case diagram: each subsystem, for each type of user, for use-cases that are of interest 3. For each potential communication need, select the use-cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams 4. Carefully name each use case diagram and then note how and when the diagram should be used to review use-cases with stakeholders and users Use-Case Descriptions - For most use-cases, only a brief description is required. - For complex use-cases, fully developed descriptions are needed. Information required generally includes: - Use case name - Verb-Noun - Scenario (if needed) - A use case can have more than one scenario (special case or more specific path) - Triggering event - Based on event decomposition technique - Brief description - Written previously when use case was identified ITM 305 – Exam Review Notes - Actors - One or more users from use case diagrams - Related use cases (<>) - If one use case invokes or includes another - Stakeholders - Anyone with an interest in the use case - Preconditions - What must be true before the use case begins - Post conditions - What must be true when the use case is completed? - Use for planning test case expected results - Flow of activities - The activities that go on between actor and the system - Shown as a T-Chart with "Actor" on one side and "System" on the other, with action (x, y, z)/reaction (x.x, x.y, x.z…) listed below - Modelled with UML Activity Diagrams. - Exception conditions - Where and what can go wrong, corrections that need to be made. - Numbers correlate to reactions numbers from flow of activities. System Sequence Diagram (SSD) Notation - UML sequence diagram that shows stages of interaction between Actor and System - Actors depicted by stickman - System depicted by box with object name underlined - “Lifeline” or “Object Lifeline” shown by vertical dotted line under each object to show passage of time - Communication to System shown with a solid line - Communication from System shown with dotted line - “Loop Frame” notation is used to show repeating messages - “True/False” (Boolean) conditions State Machine Diagram - A UML diagram showing the life of an object in states and transitions State - A condition during an object’s life when it satisfies some criterion, performs some action, or waits for an event Transition - The movement of an object from one state to another state (arrow) Action Expression - A description of activities performed as part of a transition (description above arrow) ITM 305 – Exam Review Notes Pseudo state - The starting point of a state machine diagram (black dot) Origin state - The original state of an object before transition Destination state - The state to which the object moves after the transition Guard condition - A true false test to see whether a transition can fire Composite States - State containing other states and transitions (Printer can be “On” and either “Idle” or “Working”) Concurrent Paths - Multiple paths in composite state - Printer On i) (Ink empty, need refill, refilled) OR ii) (Idle, Printing, Complete) The Problem Domain - The specific are (or domain) of the user’s business need (or problem) that is within the scope of the new system. Brainstorming Technique - A technique to identify problem domain objects in which developers work with users in an open group setting. 1. Identify a user and a set of use cases
More Less

Related notes for ITM 305

Log In


Join OneClass

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

Sign up

Join to view


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.