Notes - ITM 305 TUE (1).pdf

Midterm Preparation Don't even set trip, we gonna be prepared asf Bros Email: [email protected] Send money: [email protected] There are Podcasts for each chapter, way better than his recorded lectures innit Textbook:...

Midterm Preparation Don't even set trip, we gonna be prepared asf Bros Email: [email protected] Send money: [email protected] There are Podcasts for each chapter, way better than his recorded lectures innit Textbook: 🏴󠁧󠁢󠁥󠁮󠁧󠁿 https://mygust.com/uploads/BOOK-Systems_analysis_and_design_in_a_changin.pdf More Notes for Extra Practice: https://docs.google.com/document/d/1XHWUEcYXkV-SE7nA8iM1auej26xyINYwrc9ai26IQ0c/ edit?usp=sharing ITM 305 Notes QUIZLET FOR TERMS: https://studyable.app/set/8Vj1DyigkIXg45rJjas8 Prakrit scheming this class like: WEEK 1 - Introduction to Networking HIS SLIDES —> PODCAST FORM. YESSUH: *login from non tmu account * https://notebooklm.google.com/notebook/46015974-76a2-4101-861a-e63a3f91a6f7/ audio Midterm: *says everything on slides is important for test* What is a Systems Analyst? - Systems analysts implement, maintain, and support IT and information systems to meet the business needs of organizations - Average base pay for System Analyst is $119,000 - Ex. of systems analysis might be making a change to some computer code to achieve a task, fixing a faulty air-conditioning system, or analyzing the routines in your life to stop a mistake from happening! Computer Application (App) A computer software program that executes on a computing device to carry out a specific set of functions. Modest scope Information System A set of interrelated components that collects, processes, stores, and provides as output the information needed to complete business tasks. It's like making a sandwich (comp. app) vs running the restaurant (info. system) Broader in scope than “app” Includes database and related manual processes Computer Application (App) Examples: 1. Microsoft Word: A word processing application used to create documents, letters, and reports. 2. Spotify: A music streaming app that allows users to listen to songs, create playlists, and discover new music. 3. WhatsApp: A messaging app that enables users to send messages, make voice and video calls, and share images or videos. 4. Google Maps: A navigation app that provides directions, traffic updates, and location information. Information System Examples: 1. Airline Reservation System: This system allows users to search for flights, book tickets, manage passenger data, and handle payments. It includes not only a user-facing app but also databases, processing systems, and back-end tools for managing customer and flight data. 2. Customer Relationship Management (CRM) System: A tool like Salesforce helps businesses manage customer interactions, track sales, and store customer data. It includes various apps, a database, and integration with email and social media. 3. Hospital Management System: This information system integrates patient records, billing, scheduling, and inventory management for hospitals. It handles data entry from various departments and manages data flow between them.  4. Enterprise Resource Planning (ERP) System: Systems like SAP or Oracle help manage core business processes such as finance, human resources, and supply chain operations across an organization. In summary: Apps are usually more limited in scope (specific tasks). Information systems encompass broader functionalities, often involving multiple apps, databases, and processes. Systems Analysis - Activities that enable a person to understand and specify what an information system should accomplish. Systems Design - Activities that enable a person to define and describe in detail the system that solves the need. Systems Analysis Example: Imagine a company wants to build an inventory management system to keep track of stock levels, supplier information, and sales orders. Systems Analysis Activities: Understanding the problem: The analyst meets with warehouse staff, managers, and suppliers to understand the current inventory process, pain points (e.g., delays in stock updates), and requirements (e.g., real-time stock tracking, automatic reordering when items run low). Identifying the system’s objectives: The system should track all inventory, trigger reorder notifications, and provide reporting on stock levels, sales, and supplier performance. Documenting requirements: The analyst creates a requirements document that outlines the functionality, such as user roles (warehouse staff, managers), processes (updating stock, placing orders), and integration needs (with suppliers’ systems). Systems Design Example: Once the analysis phase is complete, the project moves into the systems design phase, where the detailed solution is outlined. Systems Design Activities: Defining the system architecture: The designer chooses the technical architecture, such as whether to build the system as a web application with a cloud-based database. Detailed design of components: Each part of the system is designed in detail. For instance, the inventory management module will include forms for entering new stock, tables to display inventory data, and automatic alerts when stock is low. Designing the database: The designer creates a database structure to store product information, supplier details, order history, and user profiles. This includes tables, relationships, and constraints. User Interface (UI) design: The designer creates mockups of what the user screens will look like (e.g., forms for updating stock, dashboards for managers), ensuring the system is easy to use. In summary: Systems Analysis helps define what the system needs to do. Systems Design focuses on how the system will achieve those goals in technical detail. Software Development Process 1. Understand the need (business need) 2. Capture the vision 3. Define a solution 4. Communicate the vision and solution 5. Build the solution 6. Confirm that the solution meets the need 7. Launch the solution system System Development Life Cycle (SDLC) System Development Life Cycle (SDLC) The process consists of all activities required to build, launch, and maintain an information system. Six core processes are: 1. Identify the problem or need and obtain approval. 2. Plan and monitor the project.  3. Discover and understand the details of the problem or need. 4. Design the system components that solve the problem. 5. Build, test, and integrate system components. 6. Complete system tests and then deploy the solution. Project A planned undertaking that has a beginning and end and that produces some definite result. Used to develop an information system. Requires knowledge of systems analysis and systems design tools and techniques. System Development Process The actual approach used to develop a particular information system (also known as methodology). 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 Complete small part of system (mini-project), then repeat processes to refine and add more, then repeat to refine and add more, until done Agile is a form of Iterative Midterm: *he says this is good for M/C questions* Core Process 1: Identify the Problem and Obtain Approval Identify the problem and document the objective of the system Preliminary investigation System Vision Document Obtain approval to commence the project (core process 1) Meet with key stakeholders, including executive management Decision reached, approve plan and budget  Core Process 2: Plan the Project Determine the major components (functional areas) that are needed Define the iterations and assign each function to an iteration Determine team members and responsibilities Core Process 3: Discover and Understand Details 1. Preliminary fact-finding: ○ Example: The project team interviews staff to learn exactly how they manage inventory, what information they need, and their pain points. 2. Develop use cases: ○ Example: A use case is developed for “updating stock,” which describes how a warehouse worker updates stock quantities after receiving shipments. 3. Develop a class diagram: ○ Example: A class diagram is created to show how the system will organize data like product information, suppliers, and orders. Core Process 4: Design System Components 1. Design the database: ○ Example: The system’s database will include tables for products, suppliers, and stock levels. 2. Design high-level structure: ○ Example: The team decides the system will be a web app, accessible on desktop computers. 3. Architectural configuration: ○ Example: The system will consist of a front-end interface for staff to use, and a back-end database to store inventory data. 4. Design class diagram: ○ Example: A class diagram shows relationships between different entities like “Product,” “Supplier,” and “Order.” Core Process 5: Build, Test, and Integrate 1. Continue programming: ○ Example: The developers write code to build the stock tracking system. 2. Build use case by use case:  ○ Example: First, they complete the use case for “updating stock,” followed by “adding new products.” 3. Perform unit and integration tests: ○ Example: Each part of the system is tested individually (unit tests), and then tested together to make sure everything works properly (integration tests). Core Process 6: Complete System Testing and Deploy the System 1. System functional testing: ○ Example: The entire system is tested to make sure it functions as expected, including stock updates, order placements, and reporting. 2. User acceptance testing: ○ Example: Store managers and warehouse staff use the system to ensure it meets their needs. 3. Possibly deploy part of the system: ○ Example: The stock tracking feature might be deployed first, with other features added later. System Development Life Cycle (SDLC) Agile Development: ○ Example: Using Agile, the development team builds the system in small, functional increments, allowing for flexibility and frequent feedback from users. Each iteration delivers a part of the system, like stock tracking or reporting, for early testing and refinement. WEEK 2 - Requirement Gathering & Specification POD LINK FOR CH.2: https://notebooklm.google.com/notebook/65c39682-577d-4ce5-91ed-92ba39674c0c/audio Systems Analysis Activities: Involve discovery and understanding Systems Analysis Activities 1. Gather Detailed Information ○ Methods: Interviews, questionnaires, reviewing documents, observing business processes, researching vendors, collecting comments and suggestions. 2. Define Requirements ○ Tasks: Model functional requirements and define non-functional requirements (How fast is it and how useful it is for example)(Making sure its a joy to use). 3. Prioritize Requirements ○ Categories: Essential, Important, and Nice-to-Have. 4. Develop User-Interface Dialogs ○ Focus: Design the flow of interaction between the user and the system. 5. Evaluate Requirements with Users ○ Approach: Engage users for feedback and adapt requirements based on their input and changes. Information Gathering Techniques 1. Interviewing Users and Other Stakeholders ○ Purpose: To gather detailed insights, requirements, and expectations directly from those involved or affected. 2. Distributing and Collecting Questionnaires ○ Purpose: To obtain structured feedback and data from a larger group of users or stakeholders. 3. Reviewing Inputs, Outputs, and Documentation ○ Purpose: To understand existing systems, workflows, and documentation to inform new system design and requirements. 4. Observing and Documenting Business Procedures ○ Purpose: To gain a practical understanding of current processes and identify areas for improvement. 5. Researching Vendor Solutions ○ Purpose: To explore available tools, technologies, and solutions that may meet the project's needs. 6. Collecting Active User Comments and Suggestions ○ Purpose: To incorporate user feedback and recommendations into the system design and development process. Themes for Information Gathering Questions Additional Techniques Observe and Document Business Processes ○ Watch and Learn: Gain insights by observing current processes in action. ○ Document with Activity Diagram: Use activity diagrams to capture and illustrate the flow of business processes (details in the next section). Research Vendor Solutions  ○ See What Others Have Done: Investigate how similar problems have been addressed by others. ○ Sources: Explore white papers, vendor literature, and competitor solutions to understand available options. Collect Active User Comments and Suggestions ○ Feedback on Models and Tests: Gather user input on prototypes and test scenarios to refine and improve system design. ○ Users Know It When They See It: Utilize user feedback to validate design choices and ensure they meet user expectations. What Are Requirements? System Requirements ○ Functional Requirements: The activities the system must perform. Examples: functions that users carry out. Use Cases: Detailed descriptions of how users will interact with the system to achieve specific goals. ○ Non-Functional Requirements: Other system characteristics. Examples: How fast is it Constraints, performance goals, and overall system quality attributes. FURPS Requirements Acronym Functional Requirements: The specific behaviors and functions that the system must perform. Usability Requirements: The ease with which users can learn, operate, and interact with the system. Reliability Requirements: The system's ability to maintain performance over time and under various conditions. Performance Requirements: The speed, responsiveness, and efficiency of the system. Security Requirements: Measures and controls to protect the system and data from unauthorized access and threats. + (Plus): Additional categories, which can include: ○ Supportability: Ease of maintenance and support. ○ Scalability: The system's ability to handle increased loads or expanded functionality. ○ Compliance: Adherence to regulatory and legal standards. Additional Requirements Categories Design Constraints ○ Description: Specific restrictions related to hardware and software that must be considered during design. Implementation Requirements ○ Description: Requirements specifying the languages, tools, protocols, and other technologies to be used. Interface Requirements ○ Description: Requirements for how the system will interface and integrate with other systems. Physical Requirements ○ Description: Constraints related to physical facilities and equipment that support the system. Supportability Requirements ○ Description: Criteria for automatic updates, enhancement methods, and overall ease of maintaining and supporting the system. Stakeholders Stakeholders  ○ Description: Individuals or groups who have an interest in the successful implementation and outcome of the system. Internal Stakeholders ○ Description: Individuals within the organization who are affected by or have an interest in the system. External Stakeholders ○ Description: Individuals or groups outside the organization who are impacted by or have an interest in the system. Operational Stakeholders ○ Description: Users who regularly interact with the system and use it in their day-to-day activities. Executive Stakeholders ○ Description: Individuals who may not interact directly with the system but are affected by its outcomes or have a financial or strategic interest in it. Some Analysis and Design Models Reasons for Modeling Learning from the Modeling Process: Gain insights and understanding through the process of creating models. Reducing Complexity by Abstraction: Simplify complex systems by creating abstract representations. Remembering All the Details: Ensure that all aspects of the system are documented and remembered. Communicating with Development Team Members: Facilitate clear communication and collaboration within the development team. Communicating with Users and Stakeholders: Ensure various users and stakeholders understand the system and its functionalities. Documenting for Future Maintenance/Enhancement: Provide a reference for future updates and maintenance of the system. Use Cases - Midterm: *Study the symbols, he will ask what it represents on the midterm* and actors - Midterm: * Which is an example of a temporal event* - Midterm: *Is this person an actor, stakeholder, or etc. in this scenario* Definition: An activity that the system performs, usually in response to a request by a user. Purpose: Define functional requirements of the system. Decomposition: Analysts break down the system into a set of use cases (functional decomposition). Techniques for Identifying Use Cases: ○ User Goal Technique ○ Event Decomposition Technique  Naming Convention: Use Verb-Noun format for naming each use case (e.g., "Place Order"). User Goal Technique: Specific Steps 1. Identify Potential Users ○ Determine all potential users for the new system. 2. Classify Users by Functional Role ○ Group users based on their functional roles (e.g., shipping, marketing, sales). 3. Classify Users by Organizational Level ○ Further categorize users by their organizational level (e.g., operational, management, executive). 4. Interview Users ○ Interview each type of user to gather a list of specific goals they have for the new system, including current goals and potential innovative functions. 5. Create Preliminary Use Cases ○ Develop a preliminary list of use cases organized by user type. 6. Resolve Duplicates and Inconsistencies ○ Identify and resolve any duplicates or inconsistencies in the use case names. 7. Identify Shared Use Cases ○ Determine where different types of users require the same use cases. 8. Review with Users and Stakeholders ○ Review the finalized list of use cases with each type of user and relevant stakeholders to ensure completeness and accuracy. Use Case Diagrams Definition ○ A Use Case Diagram is a UML (Unified Modeling Language) model used to graphically represent use cases and their relationships with actors. Unified Modeling Language (UML) ○ UML: A standardized modeling language used for specifying, visualizing, and documenting the design of information systems. Actor ○ Definition: In UML, an Actor represents an end user or another system that interacts with the system being designed. ○ Primary Actors: The primary actors are those who initiate the use cases and interact with the system to achieve specific goals. System Boundary ○ Definition: The System Boundary represents the limits of the total application, distinguishing what is part of the system from what is external to it. Automation Boundary ○ Definition: The Automation Boundary separates the computerized components of the application from the user interactions, illustrating which parts of the system are automated and which are managed by users. WEEK 3 - Use Case Modeling with Use Case Diagrams POD LINK FOR CH.3: https://notebooklm.google.com/notebook/1d31043e-d402-4aaf-accc-4529b33accf3/audio Event Decomposition Technique Overview 1. Identify Events: Types of Events 1. External Events: Occur outside the system, usually initiated by an external actor (e.g., customer actions). 2. Temporal Events: Triggered by reaching a specific point in time. 3. State Events: Triggered by changes within the system or by its internal state. 2. Naming Use Cases: 1. For each event, determine the corresponding use case that describes the system's response to the event. 3. Steps to Apply EDT: 1. Identify External Events:  Look for actions or requests from outside the system that need a response. Example: A customer buys a product. 2. Determine Use Cases for External Events: Name a use case that describes the system’s response. Example: Process Purchase Order. 3. Identify Temporal Events: Determine events that occur based on time schedules or deadlines. Example: Monthly payroll processing. 4. Determine Use Cases for Temporal Events: Name a use case that addresses these time-based events. Example: Generate Monthly Payroll Report. 5. Identify State Events: Find events triggered by internal state changes. Example: Inventory levels fall below the reorder point. 6. Determine Use Cases for State Events: Name a use case for internal state-triggered events. Example: Reorder Inventory. 7. Apply the Perfect Technology Assumption: Focus on functions directly related to events; exclude system controls like login, logout, or error handling. 8. Avoid Data or Status Error Conditions: Do not include error handling or system control events in the initial analysis. Benefits of EDT Broader Event Capture: Includes temporal and state events, not just user goals. Right-Level Decomposition: Helps in breaking down processes into elementary business processes (EBPs), which are fundamental tasks performed by a single person in response to an event. Perfect Technology Assumption: Ensures focus on core functions and not system controls or error handling. Example Events Temporal Event: Automatically finalize class lists on a predetermined date to prevent further enrollment. State Event: When a course section is full and the waitlist reaches 20 students, automatically create a new course section.  1. Temporal Event: On a predetermined date and time, automatically finalize class lists so no further enrollment is allowed. 2. State Event: When a course section is full and the waitlist hits 20 students, automatically create a new course section. Modified Use Case Model Student: ○ Display Scheduled Course-Sections ○ Enroll in Course-Section ○ Waitlist for Course-Section ○ Display Timetable ○ Drop Course-Section ○ Cancel Waitlist System: ○ Finalize Class Lists ○ Open New Course-Section Generalization – Use Case Use a Generalization relation to show that a specialized use case is a particular way to achieve the goals expressed by another general use case. The open arrowhead should point at the more general use case. Note: This concept is rarely used but presented for completeness. Generalization - Actors You can draw a Generalization link between actors. A specialized actor, such as Club Customer, inherits the use cases of the generalized actor, such as Customer. The arrowhead should point at the more general actor. The specialized actor can have its own additional use cases not available to other actors. Scope of a Use Case Primary Use Case: A logical unit of functionality identified as a user requirement of the system. It is typically performed by one person, in one place, at one time, leaves the business data in a consistent state, and generates some business value.  Secondary Use Case: A refinement of the Use Case Model that includes or extends Primary Use Cases. Structure of a Use Case A Use Case describes the behavior of a business system from the business user’s point of view. It should describe in plain business terms how the user interacts with the system and what the system does in response, without detailing internal implementation. Example 1 – Simple Use Case Actors: Customer, Sales Assistant Use Case: Take Order Nature of the «include» Relationship The «include» relationship allows steps from one Use Case to be included in another. This is useful when the included steps occur as a recognizable sequence in many contexts. For example, capturing Customer details might be needed in multiple Use Cases. Example 2 – Shared Common Steps Base Use Cases: Customer Order, Return Faulty Goods Included Use Case: Identify Customer When to Use the «include» Relationship Use the «include» relationship after the initial description of all main Use Cases. Identify common sequences of user-system interaction and extract them into separate flows if necessary. Each included Use Case is essential for the complete description of the base Use Case Week 4 - Use Case Descriptions POD LINK FOR CH.4: https://notebooklm.google.com/notebook/32b2ef35-f5c0-4621-820a-e253b17fdac3/audio Use Case Descriptions - Write a fully developed use case description for more complex use cases - Typical use case description templates include  - Name - Verb noun - Scenario (if needed) - Can have more than one scenario (special case or specific path) - Triggering event - Based on event decomp technique - Brief description - Written previously when use case was identified - Actors - One or more users from use case diagrams - Related use cases (includes/extends) - If one invokes another - Stakeholders - Anyone with interest in use case - Preconditions - What must be true before case begins - Postconditions - What must be true when case is completed - Use for planning test case expected results - Flow of activities - Activities that go on between actor and system - Exception conditions - Where and what can go wrong Documenting Workflows with Activity Diagrams - Workflow - Sequence of processing steps that completely handle one business transaction or customer request - Activity Diagram - Describes user and system activities, the actor doing each activity and the sequential flow of these activities  - Useful for showing graphical model of workflow - UML diagram When to Use Activity Diagrams - Main reason to use is to model workflow behind system being designed - Also useful for - Analyzing use case by describing actions what actions need to take place and when - Describing complicated sequential algorithm - Activity diagrams do not give detail on how objects behave or collaborate Components - Activity is ongoing execution of step in workflow (e.g operation or transaction) - Represented with rounded rectangle - Text in activity box should represent activity - Swim lanes - Vertical columns where activities of actor and system are shown - Process flow - Sequence in which activities occur Week 5 - Domain Classes POD LINK FOR CH.5: https://notebooklm.google.com/notebook/fff04b8b-de84-46a3-baed-0ac5a98cc976/audio Outline - “Things” in the Problem Domain - Data entities - Domain classes - The Domain Model Class Diagram Where to use Class Diagrams? - Class diagram is static diagram used to model static view of system - Static view - Describes vocabulary of system - Generally UML diagrams are not directly mapped with any object oriented programming languages but class diagram is an exception - Class diagram clearly shows mapping with object oriented languages such as Java and C++ - Generally used for construction purpose Things in the Problem Domain - Problem domain - Specific area or domain of users business need that is within scope of new system - Things - Items users work with when accomplishing tasks that need to be remembered - E.g products, sales, shippers, customers, invoices, payments, etc. - Modeled as domain classes or data entities - Techniques for identifying - Brainstorming Technique - Use checklist of all usual types of things typically found and brainstorm to identify domain classes of each type - Noun Technique - Identify all nouns that come up when system is described, determine if each is a domain class, an attribute, or not something we need to remember Details about Domain Classes - Attribute - Describes one piece of information about each instance of class - Customer has first name, last name, phone number - Identifier or Key - One attribute uniquely identifies an instance of the class - Required for data entities, optional for domain classes - Customer ID identifies a customer - Not doing this in UML - Compound attribute - Two or more attributes combined into one structure to simplify model - E.g address rather than including number, street, city, state, zip code separate - Sometimes identifier or key is compound attribute Attributes and Values - Class is a type of thing - Object is a specific instance of class  - Each instance has its own values for an attribute Association vs. Relationship - Called association on class diagram in UML - Multiplicity is term for number of associations between classes - 1 to 1 or 1 to many - Called relationship on ERD in database class - Cardinality is term for number of relationships in entity relationship diagrams - 1 to 1 or 1 to many - Both apply in two directions Minimum and Maximum Multiplicity - Associations have minimum and maximum constraints - Minimum is zero, association is optional - If minimum is at least one, association is mandatory Types of Associations - Binary Association - Associations between exactly two different classes - E.g course section includes students, members join club - Unary Associations (recursive) - Associations between two instances of same class - E.g person is married to person, part is made using parts The Domain Model Class Diagram - Class - Category of classification used to describe collection of objects - Domain Class - Classes that describe objects in the problem domain - Class Diagram - UML diagram that shows classes with attributes and associations - Can include methods if it models software classes - Domain Model Class Diagram - Class diagram that only includes classes from problem domain, no methods Domain Class Notation - Domain class has no methods  - Class name is always capitalized - Attribute names are not capitalized and use camelback notation - UML notation for multiplicity: - Association Class - Association that is treated as class in many to many association because it has attributes that need to be remembered More Complex Issues about Classes - Generalization/Specialization - Hierarchical relationship where subordinate classes are special types of the superior classes - Often called inheritance hierarchy - Superclass - Superior or more general class in a generalization/specialization hierarchy - Subclass - Subordinate or more specialized class in a generalization/specialization hierarchy - Inheritance - Concept that subclasses classes inherit characteristics of more general superclass  - Abstract class - Class that allow subclasses to inherit characteristics but never gets instantiated - Concrete class - Class that can have instances UML SYMBOLS MIDTERM STUDY