sia lesson 1-6.pdf

LESSON 1 – INTRODUCTION TO SYSTEM INTEGRATION SIA 101 – 1ST SEM ORGANIZATIONAL PROCESS THE ORGANIZATION STRUCTURE Information systems should align with Its purpose is to Identifies the flow of busin...

LESSON 1 – INTRODUCTION TO SYSTEM INTEGRATION SIA 101 – 1ST SEM ORGANIZATIONAL PROCESS THE ORGANIZATION STRUCTURE Information systems should align with Its purpose is to Identifies the flow of business processes to ensure efficiency and authority within business/organization. effectiveness. Structures can vary and are often temporary. FOUR FRAME MODEL: - proposed by Lee Bolman and Terrence Deal. FOUR GENERAL TYPES OF ORGANIZATIONAL/BUSINESS STRUCTURE: a. STRUCTURAL FRAME a. FUNCTIONAL STRUCTURE Classify the roles and responsibilities. Groups of people based on similar tasks, Focus on defining the controls to coordinate skills, or jobs. effectively. Quick decision-making (adaptive) is its Follows organization structure/charts advantage. b. HUMAN RESOURCE FRAME Alignment between the needs of organizations and employees. “The company grows with the nurture, motivate and satisfied employee.” c. POLITICAL FRAME Individual and Group Interest. b. DIVISIONAL STRUCTURE Building relations and connections. Negotiation is done to secure resources. Coordinate inter-group relationships. Conflict and power are key issues. The division of labor in this kind of structure will ensure greater output of varieties of d. SYMBOLIC FRAME similar products. Branches Organizational culture shapes the behaviour to reinforce the mission and vision. Stories, rituals, and ceremonies to motivate and unify their teams. c. MATRIX STRUCTURE METHODS IN SYSTEM INTEGRATION Combines functional and product-based Determines how data is passed across team groupings. different departments within an organization. Expect more responsibility per individual. Productive and open to innovative ideas. FOUR TYPES OF SYSTEM INTEGRATION: a. HORIZONTAL INTEGRATION Subsystem complies with subjects outside the organization. Chain of connected systems. Employs Enterprise Service Bus (ESB) for communication. d. PROJECT-BASED STRUCTURE The teams are based on the number of members needed to produce. Common in IT Solution companies. Ensures the right personnel are assigned to appropriate roles. b. VERTICAL INTEGRATION Subsystem concerns the communication and sharing of information within the company. Operation Level to Management Level. Can be costly as new functionalities may require additional storage. c. STAR INTEGRATION ADVANTAGES OF SYSTEM INTEGRATIONS: Spaghetti Integration Increased productivity Subsystems are connected ino multiple Better management and analysis subsystems. Lower costs Commonly used in M-Commerce Improved customer satisfaction DISADVANTAGES OF SYSTEM INTEGRATIONS: Security Issues Complex Upgrading SYSTEM ARCHITECTURE - Involves designing the conceptual structure, behaviors, dataflows, and view of the system. d. COMMON DATA FORMAT INTEGRATION Avoids constant data conversion between different application formats. Uses Enterprise Application Integration (EIA) as middleware to enable seamless data flow without major database changes. LESSON 2 – PROJECT SOURCE AND INFORMATION SYSTEM SIA 1 – 1ST SEM PROJECTS PROJECT LIFE CYCLE - It is a temporary endeavour to produce unique task - The phases a project goes through from initiation to or services. completion SOURCE OF PROJECT: PROBLEM - Current, suspected, or anticipated undesired situations. OPPORTUNITY - Improving existing problems or exploring potential systems. DIRECTIVES - New requirements from management, government, or external influences, often mandates from internal or external sources. Projects require organization and management; they cannot be run in isolation. STAKEHOLDERS - people involved in or affected by project activities. CEO Development Team Support Staff Customers Suppliers IMPORTANCE OF STAKEHOLDERS: INTEGRATION SYSTEM Relationship among stakeholders - A process of joining sub-systems and ensuring that Know the Four Frames of Organization it is functioning as expected. Senior Executives INFORMATION SYSTEM Managing a project involves many different aspects - The connection of data, applications, APIs, and that need to be tracked and followed up upon. devices across your IT organization to be more efficient, productive, and agile. Project Task Schedule Involves different components Resources Revolves of Information Process Identify Risk Variety of Purpose COMPONENTS OF INFORMATION SYSTEM: TYPES OF SYSTEMS: a. HARDWARE a. TRANSACTION PROCESSING SYSTEMS (TPS) It is a physical technology that works with Operational-Level Systems information. Provide the key data Automated or semi-automated tracking of b. SOFTWARE activity. Application program used to control and coordinate the hardware components. Payroll Systems Used for analyzing and processing data. Order Processing Systems Set of instructions used for processing Reservation Systems information. Stock Control Systems Systems for Payments and Funds c. DATABASE Transfers It is a place where data (unorganized raw facts or figures) is collected and frrom which b. MANAGAMENT INFORMATION SYSTEMS (MIS) it can be retrieved by querying it using one or more specific criteria. Middle Managers Provide performance evaluation reports and d. NETWORK short-term goal assessments Telecommunication networks Sales Management systems Consists of both physical devices and Inventory Control Systems software. Budgeting Systems Management Reporting Systems e. HUMAN RESOURCES (PEOPLE) Personnel Systems Associated with manpower required to run and manage the system. c. DECISION SUPPORT SYSTEM o End-Users – the people who benefit in the implementation of information Knowledge-Based System system. Senior Managers o Developers and Administrators Projection of the potential effects of decisions. f. PROCEDURES Describe how specific data are processed Group Decision Support Systems and analyzed in order to get the answers for Comp Supported Cooperative Work which the information system is designed. Logistics systems Financial Planning Systems d. EXECUTIVE INFORMATION SYSTEM (EIS) Strategic-Level Information Systems Analytics to pinpoint long term goal. Executives R1/XCON DENTRAL PXDES MYCIN f. ENTERPRISE COLLABORATION SYSTEM (ECS) Facilitate efficient information sharing, utilizing tools like the Internet, groupware, software, and networks. Trello Microsoft Word, Excel, PowerPoint Google Docs, Slides, Sheets g. PROCESS CONTROL SYSTEMS (PCS) Industrial Control Systems Equipment during manufacturing Test the process and return data for monitoring and troubleshooting. h. TEXT PROCESSING SYSTEMS (TPS) Automated process of analyzing text data Getting insights from customer feedback to automating varying processes in customer service. Chatbots i. ELECTRONIC DOCUMENT MANAGEMENT SYSTEM (EDMS) Software system for organizing and storing different kinds of documents. Helps users to organize and store paper or digital documents. Electronic Communication Teleconference Video Conferencing LESSON 3 – SYSTEM DEVELOPMENT LIFE CYCLE SIA 101 – 1ST SEM SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) SDLC METHODOLOGIES: A systems approach to describe a process. WATERFALL MODEL Transform a newly developed project into an Linear Sequential Lifecycle Model operational one. The oldest among SDLC models. It is a multistep, iterative process, structured Government Contractors in a methodical way. Full Documented Technical and Non-Technical A rigid structure that demands all system requirements be defined before designing. SEVEN PHASES OF SDLC: Identifying problems, opportunities, and objectives. Determining information requirements Analyzing system needs Designing the recommended system Developing and documenting software Testing and maintaining the system Implementing and evaluating the system V-MODEL Executes in a sequential manner in V-shape. Directly associated with the testing phase. ITERATION FOUR TYPES OF PROTOTYPING: Common to waterfall approach delivered into Rappid Throwaway Prototyping mini projects. Evolutionary Prototyping Rational Unified Process Incremental Prototyping Extreme Prototyping BIGBANG Software development and coding. No to minimal planning. SPIRAL Large Development Project Highly customized product, and incorporate user feedback RAPID APPLICATION DEVELOPMENT (RAD) No specific planning involves. DEVOPS PROTOTYPING Developers and Operations teams work Initial outcome together closely. Gather the feedback and can be Teams must have flexible resources. implemented through the rest of SDLC. AGILE “Fast failure” is a good thing. Stakeholder driven development EFFECTIVE SDLC: Meet stakeholders’ expectations. Completion within TIME and COST evaluations. System can be maintain throughout life cycles. LESSON 4 – SYSTEM REQUIREMENTS SIA 101 – 1ST SEM You must understand the problem to create an FEATURES THAT MUST BE INCLUDED TO SATISFY elicited requirement. BUSINESS REQUIREMENT: Outputs CHARACTERISTICS OF A GOOD SYSTEM Inputs REQUIREMENTS: Processes Timing Describes what, not how Controls Atomic, a single purpose Volume Unique Sizes Documented and Accessible Frequencies Identifies its Owner Approved by its Owner WAYS OF FINDING NECESSARY FACTS IN Traceable DIFFERENT WAYS: Necessary Complete Sampling Unambiguous Research and Site Visiting Quantitative and Testable Observation of Work Identifies Applicable States Environment Questionnaires Use of Shall, Should and Will. Interviews Mandatory requirement should be express System Prototyping using Shall Joint Requirement Planning Avoid Certain Words (Optimize, maximize, and minimize should not be used.) ORGANIZATION PHASE REQUIREMENTS CYCLE: Elicitation Phase (Raw Requirements) Classification and Categorization Organization Phase (Organized Req) Functional vs. Nonfunctional Requirements Analysis Phase (Analyzed Req) Prototype Phase (Complete Req) USER REQUIREMENTS Transform to Specs (Complete Req) - these are statements in Natural language plus diagrams of services the system provides, together with its operational constraints. ELICITATION PHASE Information Gathering True and Real Requirements SYSTEM REQUIREMENTS 5W and H - covers the overall requirements that include (who does it, what, where, when, why, how is it functional and non-functional requirements. done) FUNCTIONAL REQUIREMENTS Security o User Role Access of Information Describe what the system should do. o Who want can do what It includes: o Survivability – e.g. system will need to o What inputs the system should survive fire natural catastrophes, etc. accept. Operating Requirements o What outputs should the system produce. o Physical Constraints (size, weight) o What data the system should store o personnel availability & skill level that other systems might use. o accessibility for maintenance o What computations the system o environmental conditions should perform. Lifecycle Requirements o The timing and synchronization of the o Maintainability above. o Portability Economic Requirements – Restriction to immediate and long-term costs. NON-FUNCTIONAL REQUIREMENTS Development Limit Global Constraints o Resource and Time Limitation o Methodological Standard THE CHALLENGE OF NON-FUNCTIONAL REQUIREMENTS: ANALYSIS PHASE Hard to model Represents the transformation of the Usually stated informally, and so are: requirements. o often contradictory o difficult to enforce during development PROTOTYPE PHASE o difficult to evaluate for the customer prior to delivery In this way poorly understood requirements may be tested and perhaps strengthened, corrected, or refined. EXAMPLE OF NON-FUNCTIONAL REQUIREMENT: Often done as proof of concept and serves to induce feedback from both the stakeholders Interface Requirements - We can ask “how will the new system interface with its and engineers. environment?” o You can provide prototype User interfaces USER REQUIREMENT SPECIFICATION (URS/URD) o “user-friendliness” emphasizing its Outlines precisely what the User (or particular constraints customer) is expecting from this system. o Provide a particular Interfaces constraint with other systems Includes: Performance Requirements – You may o Functional Requirement provide a specific: o Non-Functional Requirement o Time - response time o Throughput - transactions per second SYSTEM REQUIREMENT SPECIFICATION DESIGN THINKING APPROACH: A detailed description of the system services. Empathize – Learn about the audience. o What do we agree to provide? Define – Sharpen key questions. o A structured document setting out Ideate – Brainstorm and create solutions. detailed descriptions of the system Prototype – Build representations of one or services. more ideas. o Written as a contract between client Test – Test ideas and gain user feedback. and contractor. TOOLS USED IN DEVELOPING AND UNDERSTAND SYSTEM REQUIREMENT: Affinity Diagrams Force-Field Analysis Ishikawa Fishbone (cause-and-effect) Diagrams Pareto Diagrams Pugh Charts Quality Function Deployment (QFD) CAUSE AND EFFECT ANALYSIS This diagram-based technique, which combines Brainstorming and Mind Map Consider all possible cause of the problem. HOW TO USE CAUSE AND EFFECT ANALYSIS: Identify the problem Work out the major factors involved Identify possible causes Analyze your diagram LESSON 4.1 – ISO/IEC 25010 (STANDARD SOFTWARE PRODUCT QUALITY) SIA 101 – 1ST SEM ISO/IEC FUNCTIONAL SUITABILITY - The system provides functions that meet stated and International Organization for implied needs when used under specified Standardization conditions. International Electrotechnical Commission Functional completeness - the set of functions covers all the specified tasks and ISO/IEC 25000 SERIES OF STANDARDS intended users' objectives. Functional correctness - Degree to which a SquaRE (System and Software Quality product or system provides accurate results Requirementa and Evaluation) when used by intended users. Framework for evaluation of software product Functional appropriateness - Degree to quality. which the functions facilitate the o ISO/IEC 9126 – Quality Model accomplishment of specified tasks and o ISO/IEC 14598 – Process objectives. 2500n 2501n 2502n 2503n 2504n PERFORMANCE EFFICIENCY Quality - Product performs its functions within specified time Management Model Measurement Requirement Evaluation Division and throughput parameters and is efficient in the use of resources (such as CPU, memory, storage, network devices, energy, materials) under specified conditions. ISO/IEC 25010 Time Behavior - Degree to which the - satisfies the stated and implied needs of its various response time and throughput rates of a stakeholders, and thus provides value. product or system, when performing its Functional Suitability functions, meet requirements. Performance Efficiency Resource Utilization - Degree to which the amounts and types of resources used by a Compatibility product or system, when performing its Interaction Capability functions, meet requirements. Reliability Capacity - Degree to which the maximum Security limits of a product or system parameter meet Maintainability requirements. Flexibility Safety COMPATIBILITY User Assistance - can be used by people - Exchange information with other products, systems with the widest range of characteristics and or components, and/or perform its required capabilities to achieve specified goals in a functions while sharing the same common specified context of use. environment and resources. Self-descriptiveness - presents appropriate information, where needed by the user, to Co-existence - can perform its required make its capabilities and use immediately functions efficiently while sharing a common obvious to the user without excessive environment and resources with other interactions. products, without detrimental impact on any other product. Interoperability - Degree to which a system, RELIABILITY product or component can exchange - Performs specified functions under specified information with other products and mutually conditions for a specified period of time. use the information that has been exchanged. Faultlessness - performs specified functions without fault under normal operation. Availability - is operational and accessible INTERACTION CAPABILITY when required for use. - Can be interacted with specified users to exchange Fault Tolerance - it operates as intended information in the user interface to complete specific despite the presence of hardware or software tasks in a variety of contexts of use. faults. Recoverability - in the event of an Appropriateness Recognizability - Degree to interruption or a failure, a product or system which users can recognize whether a product can recover the data directly affected and re- or system is appropriate for their needs. establish the desired state of the system. Learnability - Degree to which the functions of a product or system can be learnt to be used by specified users within a specified SECURITY amount of time - Defends against attack patterns by malicious actos Operability - Degree to which a product or and protects information and data so that persons or system has attributes that make it easy to other products or systems have the degree of data operate and control. access appropriate to their types and levels of User Error Protection - Degree to which a authorization. system prevents users against operation errors. Confidentiality - ensures that data are User Engagement - Degree to which a user accessible only to those authorized to have interface presents functions and information access. in an inviting and motivating manner Integrity - ensures that the state of its system encouraging continued interaction. and data are protected from unauthorized Inclusivity - can be used by people of various modification or deletion either by malicious backgrounds (such as people of various ages, action or computer error. abilities, cultures, ethnicities, languages, Non-repudiation - can be proven to have genders, economic situations, etc.). taken place so that the events or actions cannot be repudiated later.  Accountability - the actions of an entity can FLEXIBILITY be traced uniquely to the entity. - Degree to which a product can be adapted to Authenticity - the identity of a subject or changes in its requirements, contexts of use or resource can be proved to be the one system environment. claimed. Adaptability - Degree to which a product or Resistance - sustains operations while under system can effectively and efficiently be attack from a malicious actor. adapted for or transferred to different hardware, software or other operational or usage environments. MAINTAINABILITY Scalability - Degree to which a product can - Effectiveness and efficiency with which a product or handle growing or shrinking workloads or to system can be modified to improve it, correct it or adapt its capacity to handle variability. adapt it to changes in environment, and in Installability - Degree of effectiveness and requirements. efficiency with which a product or system can Modularity - is composed of discrete be successfully installed and/or uninstalled components such that a change to one in a specified environment. component has minimal impact on other Replaceability - Degree to which a product components. can replace another specified software Reusability - a product can be used as an product for the same purpose in the same asset in more than one system, or in building environment. other assets. Analysability - which it is possible to assess the impact on a product or system of an SAFETY intended change to one or more of its parts, - Degree to which a product under defined conditions to diagnose a product for deficiencies or to avoid a state in which human life, health, property, causes of failures, or to identify parts to be or the environment is endangered. modified. Operational Constraint - Degree to which a Modifiability - a product or system can be product or system constrains its operation to effectively and efficiently modified without within safe parameters or states when introducing defects or degrading existing encountering operational hazard. product quality. Risk Identification - Degree to which a Testability - test criteria can be established product can identify a course of events or for a system, product, or component and operations that can expose life, property or tests can be performed to determine whether environment to unacceptable risk. those criteria have been met. Fail Safe - automatically place itself in a safe operating mode, or to revert to a safe condition in the event of a failure. Hazard Warning - provides warnings of unacceptable risks to operations or internal controls so that they can react in sufficient time to sustain safe operations. Safe Integration - can maintain safety during and after integration with one or more components. LESSON 5 – MODELING REQUIREMENTS SIA 101 – 1ST SEM SYSTEM MODELING CLASSIFICATION OF SYSTEM MODELS: Abstract models of a system with models Context Model presenting a different pov of that system. Interaction Model Represent the aspects of a system and its Structural Model environment. Behavioral Model Natural Language is used to write both user and system requirements. Graphical Notation, always based on Unified CONTEXT MODEL Modeling Language (UML). Visualize how the system will be placed in an environment with other system. Boundaries GRAPHICAL NOTATION Working with stakeholders to produce system Facilitating discussion about system. functionality Documenting an existing system. Detailed system description that can be used SYSTEM BOUNDARIES to generate a system implementation. Define what is inside and what is outside the system. Profound effect on the system requirements. SYSTEM PERSPECTIVES: Political Judgment External - The context or environment of the system. Interactions - Interactions between a system PROCESS MODELS and its environment, or between the Shows the alignment of system to the components of a system. business proccesses. Structural - The organization of a system ; Data Flow Diagrams Structure of the data that is processed by the UML Activity Diagrams system. Behavioral - Dynamic behavior of the system and how it responds to events. DATA FLOW DIAGRAM (DFD) Shows the way information flows through a process or system. It can be physical (how) and logical (what). It has 3 levels. DFD NOTATIONS & SYMBOLS: DFD LEVEL 2+ Break processes down into more detailed subprocesses. DFD LEVEL 0 Also know as context diagram. It show a single node process and its connection to external entities. DFD LEVEL 1 INTERACTION MODEL: It show a single node process and its User Interaction - Model user interaction it subprocess. helps to identify user requirements. Additional data flows and data stores. System-System Interaction – Highlights the communication problems that may arise. Components Interaction - Helps us understand if a proposed system structure is likely to deliver the required system performance and dependability. STRUCTURAL MODEL Display the organization of a system in terms of the components that make up that system and their relationships. Can be static and dynamic. Discussing and designing the system architecture. BEHAVIORAL MODELS Dynamic Model - System responds to a stimulus from its environment. TYPES OF STIMULI: Data - Some data arrives that has to be processed by the system. Events - Some event happens that triggers system processing. Events may have associated data, although this is not always the case. DATA-DRIVEN MODELING - Stimuli to process the input data and generate its associated output. Utilize to analyze of requirements. WHY DO WE MODEL: “We build models so that we can better understand system we are developing”. “We build models of complex system because we cannot understand such system in its entirely”. ONLINE TOOLS: Lucidchart Draw.io GenMyModel Gliffy Creately EVENT-DRIVEN MODELING - How a system responds to external and internal events ; State and its transition to another state. STATE MACHINE MODELS Show the system’s responses to event stimuli often used for modelling real-time systems. UML State Diagram A model has states as nodes and events as arcs between these nodes. LESSON 6 – UNIFIED MODELING LANGUAGE SIA 101 – 1ST SEM UNIFIED MODELING LANGUAGE ACTIVE CLASSES - Standard terminologies and diagram conventions - Initiate and control the flow of activity. for object-oriented. PASSIVE CLASSES THREE AMIGOS (Object Management Group): - Store data and serve other classes. Grady Booch Jim Rumbaugh Ivar Jacobson VISIBILITY MARKERS - Signify the accessibility of the information within the class. STRUCTURAL DIAGRAMS: - Applies in attributes and operations. Class Package Object Component Composite Structure BEHAVIORAL DIAGRAMS: Use Case Sequence Activity State CLASS DIAGRAMS - Models the static structure of a system. MULTIPLICITY - It shows relationship among classes, object, - Indicates number of instance of one class linked attributes and operations. to an instance of another class. CLASS DIAGRAM RELATIONSHIP: COMPOSITION Association - Strong ownership between whole and its part. Inheritance/Generalization Aggregation Composition Dependency ASSOCIATION - Static relationship between classes. DEPENDENCY - The changes to the definition of one may cause changes to the other but not the other way around. INHERITANCE/GENERALIZATION - A specialized version of another class. OBJECT DIAGRAMS Represents an instance of a particular moment. Object relationship of a system. Focus on the Functionalities. Show connection between instance, value, slots and links. It verifies the completeness and accuracy of class diagram. AGGREGATION - Show how classes is compose of other classes, Independent  CLASS OBJECT It represents static aspects of a system. It represents the behavior of a system in real time. It doesn’t include dynamic changes. It captures runtime changes of a system. It never includes attributes or data values of an It includes attributes and data values of any instance. instance. Class diagram manipulates the behavior of objects Objects are instances of classes. PACKAGE DIAGRAMS COMPONENT DIAGRAMS Organizing model for middle to large scale Modeling the physical aspects of object- system. oriented systems. Package contains classes, access, and Responsible for one clear aim within the document. entire system and only interacts with other Simplify complex class diagrams. essential elements on a need-to-know basis. Shows structures and dependencies. SYMBOLS OF COMPONENT DIAGRAMS: Component Symbol - It represents a modular part of a system that encapsulates One package imports the functionality of its contents and whose manifestation is other package. replaceable within its environment. Source added to target package. One package requires help from functions of Interface Symbol other package. o Provided Interface - interfaces where Source available to target packae. a component produces information used by the required interface of another component. o Required Interface - interfaces where a component requires information in order to perform its proper function. Port Symbol - represented using a square along the edge of the system or a component. - help expose required and provided interfaces of a component.