Understanding System Integration

Introduction

• Many systems exist to improve and transform organizations.
• Some organizations operate independent systems across departments.
• Systems may lack an abstract architectural view, leading to interoperability failures.
• An architectural view of the system should be a priority to avoid design issues.
• Integrating designed and developed systems ensures flexibility, speed, cost-effectiveness, standardization, data integrity, reliability, and robustness, especially in large organizations.
• Integration benefits the IT, energy, and financial services industries.

Key Areas of Focus for Students

• The Systems Integration (SI) process, approaches, drivers, tools, and techniques needed for successful SI, along with critical success factors and best practices.
• How to integrate a proposed system with existing or planned systems.
• Addresses the System Integration problem using architectures as the basis and then addresses the evaluation of the architectures.
• The theory and practice of business process integration.
• Legacy and new systems integration methods.
• Business-to-business integration techniques.
• Integration of commercial-off-the-shelf (COTS) products.
• Interface control and management.
• Testing and integrated program management practices.
• Integrated Business Continuity.

Indicative Content

• The System of Systems Integration Problem encompasses Human, Organizational, Societal Cultural, Economic, and Technological aspects.
• Includes processes, approaches, drivers, tools, and techniques required for successful SI, critical success factors, and best practices in Systems Integration.
• The role of architectures is vital in Systems Integration.
• Integration in a System of Systems and a Federation 60 of Systems.
• Model-Based Architecture, Design, and Integration.
• Systems of Systems Interoperability.
• Evaluation of architectures.
• Measures of Performance and Effectiveness.
• Assessment of System Capabilities is important.
• Analysis of Alternatives.
• Case studies and examples from the Information Technology (IT), energy, and financial services industry illustrate the concepts discussed.
• Theory and practice of Business Process Integration, Legacy Integration, New Systems Integration, Business-to-Business Integration, integration of Commercial-off-the-shelf (COTS) products, Interface Control and Management, Testing, Integrated Program Management, Integrated Business Continuity Planning (BCP).
• Specific focus is given to issues of interface integration and interoperability of systems.

Key Terminologies

• System
• Systems thinking
• System Integration
• System Architecture
• Project

System

• An array of components designed to accomplish a particular objective according to plan.
• Many sub-systems are designed, combined, and intended to achieve a specific objective set by the Project manager.

Systems Thinking

• Involves understanding an entity in terms of its purpose, in three steps.
• Identify a containing whole (system) of which the thing to be explained is a part.
• Explain the behavior or properties of the containing whole.
• Explain the behavior or properties of the thing to be explained in terms of its role(s) or function(s) within its containing whole.

System Integration

• A combination of inter-related elements to achieve a common objective(s).

System Architecture

• Defines the high-level structure, exposing the gross organization as a collection of interacting components.
• Elements needed to model a software architecture include:
  • Components, Connectors, Systems, Properties and Styles.

Project

• System developers and architects cannot do anything without first establishing various projects, whether new or existing.
• Involves understanding what a project is, factors that influence it, and who the owners are.
• A project is a temporary endeavor undertaken to accomplish a unique product or service.
• Attributes:
  • Unique purpose.
  • Temporary.
  • Requires resources, often from various areas.
  • Should have a primary sponsor and/or customer.
  • Involves uncertainty.

Project Origins

• New or changed IS development projects originate from problems, opportunities, and directives, and are always subject to one or more constraints.
• Problems; current, suspected, or anticipated undesirable situations that prevent the business from achieving its purpose, goals, and objectives.
• Opportunity; a chance to improve business, increase revenue, profit, services, or decrease costs.
• Directive; a new requirement imposed by management, government, or some external influence from an internal or external source.

Project Context

• Projects must operate in a broad organizational environment.
• Project managers need a holistic systems view.

Stakeholders

• People involved in or affected by project activities.
• Include:
  • Project sponsor and team.
  • Support staff.
  • Customers and users.
  • Suppliers.
  • Project opponents.
• Importance:
  • Project managers must manage relationships.
  • The four organizational frames help meet stakeholder needs.
  • Senior executives are very important stakeholders.

Factors for Project Success

• Executive support.
• User involvement.
• Experienced project manager.
• Clear business objectives.
• Minimized scope.
• Standard software infrastructure.
• Firm basic requirements.
• Formal methodology.
• Reliable estimates.

Understanding Organizations

• A formal organization can be analyzed using four frames:
  • Structural- Focuses on roles, responsibilities, coordination, and control.
  • Human Resources- Focuses on harmony between the organization's and people's needs.
  • Political- Charts define power, and organizations are coalitions of varied individuals and interest groups with conflict.
  • Symbolic- Focuses on symbols, culture, and meanings.

Organizational Structure

• Most people understand organizational charts.
• Structure can change when other changes are needed.
• Basic organizational structures:
  • Functional
  • Project
  • Matrix
• It depends on the company and/or the project.
• Helps define roles and responsibilities of members.
• A system of tasks and reporting policies gives direction in completing projects.
• A structure allows effective work habits and attitude development.

Types of Structures

• Functional- people with similar tasks, skills, or jobs are grouped functionally to enable quick communication and learning.
• Divisional- the company will coordinate inter-group relationships to create a work team that can readily meet the needs of a certain customer or group of customers. The division of labor in this kind of structure will ensure greater output of varieties of similar products.
• Matrix- People are grouped by function and by product team to increase autonomy, responsibility, and innovation.
• Project- Organizational structure that puts teams together based on the number of members needed to produce the product or complete the project.

Project and Product Life Cycles

• A project life cycle is a collection of project phases.
• Vary by project or industry.
• May include concept, development, implementation, and support.
• Phases of the Project Life Cycle:
  • Project Feasibility
    • Concept —> Development
    • Management Plan —> Project Plan
    • Preliminary Cost Estimate —> Budgetary Cost Estimate
    • 3-level WBS —> 6+-level WBS
  • Project Acquisition
    • Implementation —> Close-out
    • Last work package —> Completed work
    • Definitive cost estimate —> Lessons learned
    • Performance reports —> Customer acceptance
• SLDC phases:
  • Identifying problems, opportunities, and objectives
  • Determining information requirement
  • Analyzing system needs
  • Designing the recommended systems
  • Developing and documenting software
  • Testing and maintaining the system
  • Implementing and evaluating the system.
• Products also have life cycles.

Systems Development Life Cycle

• (SDLC) is a framework for describing the phases involved in developing and maintaining information systems.
• Projects can follow:
• Predictive models: where scope, schedule, and cost can be predicted.
• Adaptive models: Mission-driven, component-based, using time-based cycles.

Predictive Life Cycle Models

• Waterfall model has linear stages and support.
• Spiral model includes iterations.
• Incremental release model provides for progressive development.
• Prototyping model clarifies user requirements.
• RAD model produces systems quickly without sacrificing quality.

Adaptive Life Cycle Models

• Extreme Programming (XP): Paired developers write tests for their code. XP teams include developers, managers, and users.
• Scrum: Iterative development uses sprints, normally lasting thirty days and scrum meetings happen daily.

Project Life Cycles

• Applies to all projects, regardless of the product.
• Product-cycle models vary.
• Most large IT systems are developed as a series of projects.
• Project management is done in all of the product life cycle phases.

Project Phases and Management Reviews

• Projects must pass each phase.
• Management reviews (phase exits/kill points) evaluate progress, success, compatibility.

Topic 1: Requirements

• A system cannot be analyzed, designed, implemented, and evaluated unless the problem is understood and requirements are elicited.
• Requirements are the basis of system development.
• System architects use the requirements of the system analyst to design the architectural view, and account for all integrations.
• Subtopics:
  • Requirements elicitation, documentation, and maintenance, modeling tools, methodologies, and testing.
• Requirements are statements that identify the essential needs of a system for value and utility.

Characteristics of Good Requirements

• Describes what, not how.
• Atomic.
• Unique.
• Documented and Accessible.
• Identifies Its Owner.
• Approved.
• Traceable to source.
• Necessary.
• Complete.
• Unambiguous.
• Quantitative and testable.
• Identifies applicable states.
• States Assumptions.
• Uses Shall, Should, and Will.
• Avoids Certain Words like optimize, maximize, and minimize.

Requirements Life Cycle

• Elicitation Phase: The starting point of the requirements engineering process is an elicitation process that involves a number of people to ensure consideration of a broad scope of potential ideas and candidate problems.
• Organisation Phase: There is the simple classification and categorization, e.g., functional vs. nonfunctional requirements.
• Analysis Phase: Represents a transformation.
• Prototype Phase: Poorly understood requirements may be tests refined.
• Requirements documentation and specification: Represents the requirements as the finished product of the stakeholder requirements team.

Requirements Elicitation

• Requirements determination addresses the gathering and documenting of true and real requirements for the Information System that is being developed.
• Requirements are the wants and/or needs of the user within a problem domain,.
• Questions:
  • Who does it?
  • What is done?
  • Where is it done?
  • When is it done?
  • How is it done?
  • Why is it done?

Systems Requirements

• Characteristics or features that must be included to satisfy business requirements.
• Included aspects:
  • Outputs
  • Inputs
  • Processes
  • Timing
  • Controls
  • Volumes, sizes, and frequencies
• Data/Information collected about; people, organization, work, and work environment.
• Fact-Finding Methods:
• Sampling of existing documents, forms, etc.
• Research and site visits (participation).
• Observation of the work environment.
• Questionnaires and Interviews.
• Prototyping.
• JAD/Joint requirements planning (JRP).

Types of Requirements

• User Requirements: Natural language statements and diagrams of services and constraints.
  • Categorized into functional and non-functional requirements.
  • Functional requirements describe what the system should do.
  • Non-functional requirements consist of Constraints adhered to during development.
• System requirements:
  • What we agree to provide.
  • System services.
  • A contract between Client and contractor.

Functional Requirements

• What inputs the system should accept.
• What outputs the system should produce.
• What data the system should store.
• What computations the system should perform.
• The timing and synchronization of the above.

Non-Functional Requirements

• Global constraints on a system related to:
  • Development costs, operational costs, performance, reliability.
• Requirements:
  • Hard to model, usually informal, and are contradictory.
  • Can be difficult to enforce during development and evaluate for the customer before delivery
• Define system properties and constraints, such as reliability, response time, and storage, device capability, and system representations.

Specification

• Specifying requirements can mandate a particular programming language or development method.
• May be more critical than functional, such that if these are not met, the project could fail.
• Examples of NFR:
  • Interface requirements - how will the new system interface with its environment, user interfaces, and other systems.
  • Performance requirements, like time and throughput rates.
  • Security - permissible flows, and the limits and what, who can do.
  • Operating requirements: physical constraints (size, weight), & accessibility and environmental conditions.
  • Lifecycle requirements.
  • Limits on development.
  • Economic requirements - E.g. restrictions on immediate and/or long-term costs.

Requirements Documentation

• Includes:
  • User Requirements Specification Document outlining customer expectations.
  • System requirements specification Document outlining the what and how.
  • The URS document outlines precisely what the User (or customer) is expecting from this system.
  • User Requirement Specification may incorporate the functional and Functional Requirements
• Documents contain information on:
  • Functional Requirements.
  • Non-Functional Requirements.
• System Requirements Specification Document:
  • Detailed descriptions of system services.
  • Structured contract between client and contractor.

System Tools

• Tools that aid in developing & understanding systems REQ'TS - Affinity diagrams - Force-field analysis - Ishikawa fishbone (cause-and-effect) diagrams - Pareto diagrams - Pugh charts - Quality function deployment (QFD)