A Case Study of the Systems Engineering Process in Healthcare Informatics Quality Improvement. Systems Engineering. Ali M. Hodroj
|
|
- Denis McCarthy
- 2 years ago
- Views:
Transcription
1 A Case Study of the Systems Engineering Process in Healthcare Informatics Quality Improvement By Ali M. Hodroj Project Report submitted to the Faculty of the Maseeh School of Engineering and Computer Science at Portland State University in partial fulfillment of the requirements for the degree of Master of Engineering In Systems Engineering Approved: Professor Herman Migliore, Director of Systems Engineering 1
2 Table of Contents Contents ABSTRACT...3 INTRODUCTION PROBLEM STATEMENT OBJECTIVE AND PROCEDURE PROBLEM CONTEXT JUSTIFICATION FOR A NEW SYSTEM... 4 SYSTEMS APPROACH TO HEALTHCARE INFORMATICS HEALTHCARE AS A COMPLEX SYSTEM [OMITTED PROPRIETARY INFORMATION]... 5 SYSTEMS ENGINEERING PROCESS SYSTEMS ENGINEERING OVERVIEW PROCESS OVERVIEW CONCEPT/CONTEXT EXPLORATION VIEW FUNCTIONAL ANALYSIS VIEW REQUIREMENTS ANALYSIS VIEW ARCHITECTURAL ANALYSIS VIEW TEST VIEW SYSTEM CONCEPT CURRENT SYSTEM MISSION STATEMENT PROPOSED SYSTEM CONCEPTUALIZATION CONCEPT DEFINITION ITERATION 2: HIGH-LEVEL SYSTEM ITERATION 3: [OMITTED PROPRIETARY INFORMATION] ITERATION 4: [OMITTED PROPRIETARY INFORMATION] ITERATION 5: [OMITTED PROPRIETARY INFORMATION] ITERATION 6: [OMITTED PROPRIETARY INFORMATION] CONCLUSION REFERENCES
3 Abstract A systems engineering approach was used to improve and develop a clinical quality improvement system for a major biomedical informatics solutions provider. Development efforts spanned the system life cycle and involved project stakeholders. Requirements were developed and alternative designs where conceptualized. The best alternative design concept was selected based on research and analysis in the view of requirements. A detailed design was embodied in a prototype system that was evaluated and found not to meet requirements completely. The design was revised, including a tradeoff where total system value as well as additional trade-off criteria were incorporated to satisfy a constraint regarding leveraging an existing product within the healthcare provider market space. The revised system design was validated and approved by project stakeholders within the company. The project progressed through different iterative systems engineering life cycle phases, where the conceptualized solution was viewed in context of requirements, functions, possible architectures, and validation and verification approaches. The same four-fold process was applied recursively at each sub-system to facilitate the proper selection of solution concepts at different layers of abstraction. The purpose of this paper is to present a case study of the systems engineering process and how was it was applied to ensure that the proposed system met all project stakeholder requirements. 3
4 Introduction 1.0 Problem Statement This masters project report is the outcome of an academic case study and industrial work conducted in the light of the Master of Engineering program in Systems Engineering at Portland State University. The scope of this project encompasses the process of following a systems approach to the design of a healthcare quality improvement system based on the implementation of a quality function deployment process, a systems engineering tool, through clinical quality reporting of clinical performance measures for healthcare providers. The process consists of (1) systems requirements definition, (2) specification and collection of data through systems modeling, (3) design, validation, and verification of appropriate system models, (4) trade-off analysis for selecting the most balanced design alternatives, and finally (5) the development of implementation and evaluation plans for meeting the target system functions, quality attributes, and performance metrics. 1.1 Objective and Procedure The objective is to follow a systems approach at implementing a performance measurement framework that can report on healthcare delivery quality as well as indicators for clinical quality improvement. Form a systems engineering perspective, a performance measure is a statistic computed from information in a given system trace. 1.2 Problem Context 1.3 Justification for a new System 4
5 Systems Approach to Healthcare Informatics 2.0 Healthcare as a Complex System The decision to take a systems approach towards a healthcare informatics system stems from the fact that the US Healthcare is itself a complex system of many interdependencies and heterogeneous components. The United States has a unique system of healthcare delivery. It is unlike any other health care system in the world. Most developed countries have national health insurance programs run by the government and financed through general taxes. Almost all citizens in such countries are entitled to receive healthcare services. Such is not the case in the United States, where not all Americans are automatically covered by health insurance. The US healthcare delivery system is not a formal system in the true sense, even though it is called a system when reference is made to its various features, components, and services. The US healthcare system is unnecessarily fragmented due to continuous periodic changes, mainly in response to concerns with cost, access, and quality [8]. Figure 1 demonstrates the complexity of healthcare delivery in the United States. Many organizations and individuals are involved in healthcare. These range from educational and research institutions, medical suppliers, insurers, payers, and claims processors to healthcare providers. Figure 1: US healthcare system structure 2.1 5
6 Systems Engineering Process 3.0 Systems Engineering Overview Systems engineering is a methodology and framework for managing technological complexity. The application of systems engineering revolves around three core principles: systems management, requirements/architecture definition, as well as systems integration and verification. Systems engineering focuses on the system as a whole by holistically emphasizing its total operation. It assumes a non-reductionist engineering perspective by looking at a system from the outside through its interactions with other systems and the environment that it operates within. Such approach demands not only the engineering design of the system, but also the external factors that govern and constrain the design. Systems engineering also adopts a management perspective in order to control the total system development effort for the purpose of achieving an optimum balance of all system elements. It is a process of transforming an operational need into a description of systems parameters and integrates such parameters to optimize the overall system effectiveness. 3.1 Process Overview The systems engineering process applied in this project is adapted from a recursive systems engineering lifecycle pattern, CCFRAT: Context, Concept, Functions, Requirements, Answers, and Test [1]. CCFRAT is a hierarchical systems engineering methodology applied at every level of system abstraction, design, and decomposition. This methodology is used to develop the system boundaries at each level of system interaction, abstraction, and/or design. The CCFRAT process is a modification of the Function, Requirement, Answer, and Test (FRAT) simplified systems engineering process [3]. The process is named Context, Concept, FRAT (CCFRAT), after the six views of any system required by this method. The CCFRAT model was developed by adding two additional holistic views to the classic FRAT model. The new holistic views are the context view and the concept view. These two new views focus on the value set constraining the total system context and the controlling concept set associated with the relationships contained in the core design process [1]. With these six views in place, the systems engineering process proceeds in a recursive, stepwise fashion to design, model, and develop systems at lower and lower levels of details until the system has been fully described and modeled. In other words, the conceptual, contextual, functional, requirements, architecture, and validation sum of all views at the lowest level of details shall be equivalent to those six views at the highest level of detail. The first step in a CCFRAT process is the establishment of the system context, including a definition of a current system abstraction frame. The system context view is focused on the external relationships and connections associated with the system of interest. This view records the driving need for the system as well as the system value network, external stakeholders and controlling value sets. The figure below provides a conceptual model of the system context view: 6
7 Figure 2: Conceptual model of a system context view Once the system context is established, a conceptual view of the system is derived. The conceptual view focuses on the system interest as well as its current level of abstraction, level of decomposition and abstraction boundary for a specific set of system concepts. The core four system views, function view, requirements view, architecture view, and test view can be evaluated, analyzed, documented, and modeled in a number of ways. The concept view establishes a wellcoordinated and executable set of rules for system definition and analysis. The concept view details the semantics, processes, and approach used to evaluate and analyze the system represented in the current context. The following figure outlines the conceptual model of a system context view: Figure 3: Conceptual model of a system concept view 7
8 As the six views (Context, Concept, Functions, Requirements, Architecture, and Test) are being developed, a logical mapping between each of the layers is established as shown in Figure 4 below: Context, Concept, Functions, Requirements, Answers, Tests CCFRAT CCFRAT CCFRAT CCFRAT CCFRAT CCFRAT CCFRAT CCFRAT CCFRAT governs System Concept C Sub-System Concept C.1 Sub-System Concept C Sub-System Concept C.3 System Function F Concept C.1.1 Concept C.1.2 Concept Concept + C.2.1 C Concept C.3.1 Concept C.3.2 Sub-system Function F.1 Sub-system Function F Sub-system Function F Function F.1.1 Function F.1.2 Function F.2.1 Function F.3.1 Function F.3.2 Figure 4: CCFRAT recursive systems engineering process Each system in a CCFRAT process is has six views that are used to identify the logical relationships important to the system at each level of abstraction and development. These six views are, the context view (defines the system context and meta-system), the concept view (defines the conceptual relationship inside the system), functional view (defines what the system does), requirements view (defines how well the functions are done), the answer view (defines how the function is performed), and the test view (defines how you know that the answer meets the functions and stated requirements). As CCFRAT methods and processes are used to recursively model and design the system of interest, system models and descriptions are developed at lower and lower levels of detail. At the same time, the number of unique system solutions is reduced and the design space is further constrained. At each abstraction level the system is modeled and evaluated against the given concept and value constraint context. 8
9 Figure 5: CFRAT process used in this case study This CCFRAT systems engineering approach was followed, but tailored as indicated in Figure 5 to better suit the scale of the this project and the incremental approach used to develop the overall target system through a sequence of individual iterations. For example, the Context and Concept stage where combined in an overall Concept Exploration phase based on the scope of each individual sub-system. There were also continuous opportunities to involve key end users throughout different project phases to validate that the system would meet their needs. The concept of operations was incrementally updated when needed to reflect the specific effects of individual iterations as they were concluded. 3.2 Concept/Context Exploration View The system concept/context view details the relationships between the system functions and architectural design as well as specifying the appropriate level of abstraction for system modeling. Both concept and context views are combined together to emphasize the system boundaries and provide a common abstraction layer for the complete system under development. With these two holistic views in place, relationship models, structural models, and other types of non-hierarchical system interactions can be more readily evaluated without undergoing detailed functional analysis of each component in the proposed system. Figure 6 below shows how this view is decomposed at different levels of abstraction. 9
10 Figure 6: recursive concept decomposition at different levels of abstraction 3.3 Functional Analysis View Functional analysis creates a function hierarchical pattern that has equivalent functional behavior at each level in the functional abstraction hierarchy. At every level of abstraction in the system, functional analysis is performed to decompose the system under analysis into a set of functions that satisfy the original system objective. Figure 7 below shows how this view is decomposed at different levels of abstraction. Figure 7: recursive functional decomposition at different levels of abstraction 3.4 Requirements Analysis View The purpose of the requirements analysis view is to obtain a thorough and detailed understanding of the business need and constraints at every level of abstraction in the system, and to break it down into a discrete set of measurable requirements, which are then clearly defined, reviewed, and agreed upon with the project stakeholders. The primary goal of this view is to create a detailed set of specifications on how well the system must perform. These specifications form the constraints, non-functional requirements, and quality attributes of the system. Within our CFRAT process, the requirements are used to construct an architecture utility tree which is later used for criteria to perform trade-off analysis between different proposed solution architectures. Figure 8 below shows how this view is decomposed at different levels of abstraction. 10
11 Figure 8: recursive requirements decomposition at different levels of abstraction 3.5 Architectural Analysis View The architectural analysis view is two-fold: (1) identification of the appropriate solution answers to which all current system functions can be allocated and requirements can be met, and (2) identification of a set of architecture alternatives that are compared and synthesized through an architecture trade-off analysis method. This phase evaluates the solution concepts in order to understand the consequence of each choice decision with respect to meeting requirements and system functions. A result of this phase is identifying areas of potential risks within the architecture of the complex system. In this view there are three main activities performed at each level of abstraction: (1) identification of architectural approaches (solution concepts/answers) that meet the defined functions in the Functions view, (2) generation of a quality attribute tree that maps to the Requirements view, and (3) analyzing and comparing architectural approaches through tradeoff and sensitivity analysis where the quality tree attributes are prioritized and used as the main trade-off analysis criteria. This process is an adaptation of the Software Engineering ATAM (Architectural Analysis and Trade-off Method) pioneered by the Software Engineering Institute (SEI) at Carnegie Mellon University [2]. The principal benefit of this method is the ability to see if a proposed overall architecture will live up to the requirements expectations. The trade-off analysis helps one understand the strengths and weaknesses of the system. More so, this view within our process forms the core of applying systems engineering principles where constraints are put under investigation for two primary reasons: (1) to investigate and prioritize the importance of each constraint, and (2) to investigate the interdependencies between constraints and how the relationship between them affects the decision to select the appropriate solution concept. The result of this is to provide the systems engineer with a set of trade-off points acting as gauges that the stakeholders can monitor every time a solution concept is evaluated. The following sections summarize three main categories that requirements are categorized under in order to generate a utility tree for trade-off analysis End User Quality Attributes Performance The degree to which a system or component accomplishes its designated functions within a given set of constraints, such as speed, accuracy, or memory usage. Availability The degree to which a system or component is operational and accessible when required for use. Usability The ease with which a user can learn to operate, prepares inputs for, and interprets outputs of a system or component. 11
12 Security The degree to which a system is able to protect its data, restrict access, as well as authorize and authentication certain users. Engineering Quality Attributes Maintainability The ease with which a system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. Portability The ease with which a system or component can be transferred from one hardware or software environment to another. Reusability The degree to which a system or other work product can be used in more than one system. Testability The degree to which a system or component facilitates the establishment of test criteria and the performance tests to determine whether those criteria have been met. Business Quality Attributes Time to Market The length of time it takes from a product being conceived until it s available for production. Cost and Benefits Potential costs and revenues that may be incurred or generated as a result of selecting a specific system or component. Project Lifetime The intended lifetime of the system in production. Targeted Market The target market segment that the system will operate in. Legacy Integration The ability to integrate the proposed system or component with current existing systems. 3.6 Test View The purpose of the test view within this process is to identify the verification and validation requirements for the system. Verification is the confirmation that the selected solution concept fulfills the requirements and functions allocated to it. Validation is the confirmation that requirements are correct and that the functions and requirements, when taken in combination, satisfy the system-level mission needs. Validation and verification activities take place as part of each CFRAT phase within our systems engineering process. The approach to verification and validation is accomplished through several methods: Testing Exercising and observing system behavior by comparing its outputs to expected outcomes. Demonstration Prototyping of the system through an engineering effort to implement a subset of its functionality that can be used to verify whether the concept is technically feasible or not. Similarity Comparing computational results from the system or component against results obtained from an identical system. 12
13 Analysis/Inspection The analysis of the static system representation to discover problems or potential areas of risk. Simulation and Modeling The simplified representation of the system behavior through a computational model in order to develop a level of understanding of the interaction of the parts of the system as well as the system as a whole. 13
14 System Concept 4.0 Current System 4.1 Mission Statement 4.2 Proposed System Conceptualization 4.3 Concept Definition After the high-level stakeholder needs where identified and prioritized, alternative concepts were defined at the highest level of abstraction in the system. Conceptual designs where developed from these alternatives for consideration resulting in the following possible concepts: 4.4 Iteration 2: High-Level System Context Functions Requirements Architectures Utility Tree 14
15 4.5 Iteration 3: Concept Functions Requirements Architectures Test 4.6 Iteration 4: Functions Requirements Architectures Utility Tree 15
16 Test 4.7 Iteration 5: Functions Requirements Architectures Utility Trees Test 4.8 Iteration 6: Context [Omitted Proprietary Information] Functions Requirements Architectures Utility Tree 16
17 Test 17
18 Conclusion In this case study, systems engineering was used to capture all stakeholder needs in the most effective way possible. This ensures that all requirements were gathered and consistent across all stakeholder needs and in alignment with the primary system objective. The definition of the system was carried out through a hierarchical recursive systems engineering process. The definition of the system was completed through conceptual, functional, requirements, architectural, and validation decomposition. At each decomposition layer in the system hierarchy, system views were based-lined with customers and stakeholders before the next level of analysis is started. Roll-up reviews were also conducted to make sure that the top-level system objectives have not been modified in the subsequent analysis. The end result yielded a definition of a system that is sufficient enough to provide the development team with the definition of the system to be delivered and how it will operate in a production environment. The utilization of a systems approach to the development of a clinical performance measurement system proved to be successful and recommended. The end result of the approach was meeting all stakeholder needs in an iterative fashion while reducing system complexity and balancing the system s quality attributes in the most effective way possible. 18
19 References [1] Simpson, J.J. and Simpson, M.J., "System Integration Frameworks." Proceedings of the 15 th Annual International Symposium of the International Council on Systems Engineering (Rochester, NY, July, 2005). [2] Abowd, G., Bass, L., Clements, P., Kazman, R., Northrop, L., and Zaremski, A. Recommended Best Industrial Practice for Software Architecture Evaluation. Technical Report, Software Engineering Institute, CMU/SEI-96-TR-025, ESC-TR , January 13, [3] Mar, B.W., and Morais, B.G., "FRAT A Basic Framework for Systems Engineering." Proceedings of the Twelfth Annual International Symposium of the International Council on Systems Engineering, Las Vegas NV, [4] Drools. online. [5] Physicians Quality Reporting Initiative. online. [6] Linder, J.A., Ma, J., Bates, D.W., Middleton, B., Stafford, R.S. Electronic Health Record Use and the Quality of Ambulatory Care in the United States, Archives of Internal Medicine, July 9, 2007; 167 (13): [7] O Toole MF, Kmetik KS, Bossley H, Cahill J, Kotsos T, et al. Electronic Health Record Systems: The vehicle for implementing performance measures. American Heart Hospital Journal (3): [8] McGlynn E, Asch S, Adams J, et al. The quality of health care delivered to adults in the United States. N Engl J Med. 2003;348(26): [9] Institute of Medicine (U.S.). Committee on Quality of Health Care in America. Crossing the quality chasm: a new health system for the 21st century.washington, D.C.: National Academy Press;
The Role of the Software Architect
IBM Software Group The Role of the Software Architect Peter Eeles peter.eeles@uk.ibm.com 2004 IBM Corporation Agenda Architecture Architect Architecting Requirements Analysis and design Implementation
NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0
NASCIO EA Development Tool-Kit Solution Architecture Version 3.0 October 2004 TABLE OF CONTENTS SOLUTION ARCHITECTURE...1 Introduction...1 Benefits...3 Link to Implementation Planning...4 Definitions...5
What is ISO/IEC 15288? (A Concise Introduction)
Dr. Harold "Bud" Lawson 2004-10-13 1 (10) What is ISO/IEC 15288? (A Concise Introduction) What if all or the majority of the people of an organization (independent of their personal background and role)
3SL. Requirements Definition and Management Using Cradle
3SL Requirements Definition and Management Using Cradle November 2014 1 1 Introduction This white paper describes Requirements Definition and Management activities for system/product development and modification
Software Development Life Cycle
4 Software Development Life Cycle M MAJOR A J O R T TOPICSO P I C S Objectives... 52 Pre-Test Questions... 52 Introduction... 53 Software Development Life Cycle Model... 53 Waterfall Life Cycle Model...
Chapter 4. Preliminary System Design. Electrical & Computer Engineering School of Engineering THE COLLEGE OF NEW JERSEY
Chapter 4 Preliminary System Design 1 What is it? Developing design requirements from system-level requirements for subsystems and major system elements Preparing development, product, process, and material
Leveraging CMMI framework for Engineering Services
Leveraging CMMI framework for Engineering Services Regu Ayyaswamy, Mala Murugappan Tata Consultancy Services Ltd. Introduction In response to Global market demand, several OEMs adopt Global Engineering
Systems Development Life Cycle (SDLC)
DEPARTMENT OF BUDGET & MANAGEMENT (SDLC) Volume 1 Introduction to the SDLC August 2006 Table of Contents Introduction... 3 Overview... 4 Page 2 of 17 INTRODUCTION 1.0 STRUCTURE The SDLC Manual consists
Software Architecture. New wine in old bottles? (i.e., software architecture global design?, architect designer)
Software Architecture New wine in old bottles? (i.e., software architecture global design?, architect designer) Overview What is it, why bother? Architecture Design Viewpoints and view models Architectural
The MCSE Methodology. overview. the mcse design process. if a picture is worth a thousand words, an executable model is worth a thousand pictures
The MCSE Methodology overview if a picture is worth a thousand words, an executable model is worth a thousand pictures The MCSE methodology the mcse methodology (méthodologie de conception des Systèmes
ITS Projects Systems Engineering Process Compliance Checklist
ITS Projects Systems Engineering Process Compliance Checklist FHWA Final Rule (23 CFR 940) This checklist is to be completed by the MDOT or LPA Project Management Staff. Please refer to the accompanying
SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT
SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original
Software Development in the Large!
Software Development in the Large! Peter Eeles Executive IT Architect, IBM peter.eeles@uk.ibm.com IBM Rational Software Development Conference 2007 2007 IBM Corporation Agenda IBM Rational Software Development
Kunal Jamsutkar 1, Viki Patil 2, P. M. Chawan 3 (Department of Computer Science, VJTI, MUMBAI, INDIA)
Software Project Quality Management Kunal Jamsutkar 1, Viki Patil 2, P. M. Chawan 3 (Department of Computer Science, VJTI, MUMBAI, INDIA) ABSTRACT Quality Management is very important in Software Projects.
An Approach to Software Architecture Description Using UML
An Approach to Software Architecture Description Using UML Henrik Bærbak Christensen, Aino Corry, and Klaus Marius Hansen Department of Computer Science, University of Aarhus Aabogade 34, 8200 Århus N,
JOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,
U.S. Dept. of Defense Systems Engineering & Implications for SE Implementation in Other Domains
U.S. Dept. of Defense Systems Engineering & Implications for SE Implementation in Other Domains Mary J. Simpson System Concepts 6400 32 nd Northwest, #9 Seattle, WA 98107 USA Joseph J. Simpson System Concepts
NSF Workshop: High Priority Research Areas on Integrated Sensor, Control and Platform Modeling for Smart Manufacturing
NSF Workshop: High Priority Research Areas on Integrated Sensor, Control and Platform Modeling for Smart Manufacturing Purpose of the Workshop In October 2014, the President s Council of Advisors on Science
A Comparison of SOA Methodologies Analysis & Design Phases
202 A Comparison of SOA Methodologies Analysis & Design Phases Sandra SVANIDZAITĖ Institute of Mathematics and Informatics, Vilnius University Abstract. Service oriented computing is a new software engineering
Introduction to SOA governance and service lifecycle management.
-oriented architecture White paper March 2009 Introduction to SOA governance and Best practices for development and deployment Bill Brown, executive IT architect, worldwide SOA governance SGMM lead, SOA
Practice Overview. REQUIREMENTS DEFINITION Issue Date: Revision Date:
DEPARTMENT OF HEALTH AND HUMAN SERVICES ENTERPRISE PERFORMANCE LIFE CYCLE FRAMEWORK PRACTIICES GUIIDE REQUIREMENTS DEFINITION Issue Date: Revision Date: Document
PROJECT SCOPE MANAGEMENT
5 PROJECT SCOPE MANAGEMENT Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully
SOFTWARE ARCHITECTURE QUALITY EVALUATION
SOFTWARE ARCHITECTURE QUALITY EVALUATION APPROACHES IN AN INDUSTRIAL CONTEXT Frans Mårtensson Blekinge Institute of Technology Licentiate Dissertation Series No. 2006:03 School of Engineering Software
Karunya University Dept. of Information Technology
PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main
Requirements engineering
Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and
Agile Master Data Management TM : Data Governance in Action. A whitepaper by First San Francisco Partners
Agile Master Data Management TM : Data Governance in Action A whitepaper by First San Francisco Partners First San Francisco Partners Whitepaper Executive Summary What do data management, master data management,
Overview. Software engineering and the design process for interactive systems. Standards and guidelines as design rules
Overview Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering Iterative design and prototyping Design rationale A. Dix, J.
Software Engineering UNIT -1 OVERVIEW
UNIT -1 OVERVIEW The economies of ALL developed nations are dependent on software. More and more systems are software controlled. Software engineering is concerned with theories, methods and tools for
Building Reusable Testing Assets for a Product Line
Building Reusable Testing Assets for a Product Line John D. McGregor Visiting Scientist - SEI Senior Partner - Korson-McGregor Associate Professor - Clemson University johnmc@cs.clemson.edu Qualifications
Software Engineering Reference Framework
Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of
4.1 Domain Analysis. Object-Oriented Software Engineering Practical Software Development using UML and Java
4.1 Domain Analysis Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing The process by which a software engineer learns about the domain to better
What methods are used to conduct testing?
What is testing? Testing is the practice of making objective judgments regarding the extent to which the system (device) meets, exceeds or fails to meet stated objectives What the purpose of testing? There
Managing Software Product Line
* F 2 - Rules for Qualification of Developing and Managing Software Product Line F. Ahmed Electrical & Computer Engineering University of Western Ontario London Ontario, Canada, N5A5B9 sgraha5@uwo.ca L.F.
General Problem Solving Model. Software Development Methodology. Chapter 2A
General Problem Solving Model Software Development Methodology These focus on understanding what the problem is about Chapter 2A Concerned with understanding more about the nature of the problem and possible
Course Description. Course Audience. Course Outline. Course Page - Page 1 of 14
Course Page - Page 1 of 14 Solution Architecture Training: SA Practitioner's Guide (Extended) BSP-2325 Length: 4 days Price: $ 2,995.00 Course Description The course covers stakeholder identification,
Lecture 8. Systems engineering L E C T U R E. SIMILAR process. Zuzana Bělinová. Faculty of Transportation Sciences, CTU in Prague
L E C T U R E 8 SIMILAR process LECTURE 8 - OVERVIEW Theoretical foundations of many methodologies - Typical SE process SYSTEMS ENGINEERING BASIC FACTS Systems Engineering is responsible for creating a
Web Application Architectures
Web Engineering Web Application Architectures Copyright 2013 Ioan Toma & Srdjan Komazec 1 Where we are? # Date Title 1 5 th March Web Engineering Introduction and Overview 2 12 th March Requirements Engineering
Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)
Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which
KNOWLEDGE MANAGEMENT SYSTEMS LIFE CYCLE
KNOWLEDGE MANAGEMENT SYSTEMS LIFE CYCLE Main Topics of This Lecture Challenges in building KM Systems Compare CSLC and KMSLC User s vs. Expert s Characteristics Stages of KMSLC 2-2 CHALLENGES IN BUILDING
Requirements and Duncker Diagrams
Requirements and Duncker Diagrams Table of Contents Reading...1 The Systems Engineering Method...2 Customer Expectations (Project Objectives and Mission Profile)...4 The Iterative Nature of the System
Enterprise Architecture Glossary by Set
Set: Enterprise Architecture (EA) Glossary Term Source Enterprise architecture terms based on NASCIO,, and other industry best practices. Description Albers Equal Area Projection egsc.usgs.gov A projection
11 Tips to make the requirements definition process more effective and results more usable
1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to
Engineering a EIA - 632
es for Engineering a System EIA - 632 SE Tutorial es for Engr Sys - 1 Fundamental es for Engineering a System Acquisition and Supply Supply Acquisition es for Engineering A System Technical Management
Classical Software Life Cycle Models
Classical Software Life Cycle Models SWEN 301 Trimester 1, 2015 Lecturer: Dr Hui Ma Engineering and Computer Science Lecture slides make use of material provided on the textbook's companion website Motivation
Process Models and Metrics
Process Models and Metrics PROCESS MODELS AND METRICS These models and metrics capture information about the processes being performed We can model and measure the definition of the process process performers
Formal Software Testing. Terri Grenda, CSTE IV&V Testing Solutions, LLC www.ivvts.com
Formal Software Testing Terri Grenda, CSTE IV&V Testing Solutions, LLC www.ivvts.com Scope of Testing Find defects early Remove defects prior to production Identify Risks Unbiased opinion When Should Testing
8. Master Test Plan (MTP)
8. Master Test Plan (MTP) The purpose of the Master Test Plan (MTP) is to provide an overall test planning and test management document for multiple levels of test (either within one project or across
CHAPTER 24 SOFTWARE PROJECT SCHEDULING. Overview
CHAPTER 24 SOFTWARE PROJECT SCHEDULING Overview The chapter describes the process of building and monitoring schedules for software development projects. To build complex software systems, many engineering
Applying 4+1 View Architecture with UML 2. White Paper
Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was
Information system for production and mounting of plastic windows
Information system for production and mounting of plastic windows MARCEL, MELIŠ Slovak University of Technology - Faculty of Material Sciences and Technology in Trnava, Paulínska 16 street, Trnava, 917
CDC UNIFIED PROCESS PRACTICES GUIDE
Document Purpose The purpose of this document is to provide guidance on the practice of Requirements Definition and to describe the practice overview, requirements, best practices, activities, and key
Quality Management. Lecture 12 Software quality management
Quality Management Lecture 12 Software quality management doc.dr.sc. Marko Jurčević prof.dr.sc. Roman Malarić University of Zagreb Faculty of Electrical Engineering and Computing Department of Fundamentals
Agile Master Data Management
A better approach than trial and error by First San Francisco Partners 2 Common MDM initiative and benefit Customer Optimization Improve up-sell, cross-sell and customer retention Access full-customer
Chapter 11: Integration- and System Testing
Chapter 11: Integration- and System Testing Chapter 14: Testing (2/2) Object-Oriented Software Construction Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Software Lifecycle Activities...and
ITIL v3 Process Cheat Sheets
CEB Infrastructure Leadership Council ITIL v3 Process Cheat Sheets 2014 CEB. All rights reserved. IEC8051414SYN 1 ITIL v3 Process Cheat Sheets The ITIL v3 process cheat sheets include a definition, description
SYSTEM ANALYSIS CHAPTER 5. Expected Outcomes
CHAPTER 5 SYSTEM ANALYSIS Expected Outcomes To discuss requirements determination To study methods in gathering requirements To discuss the logical modeling of processes by referring to Data Flow Diagram
Transforming Business Requirements into System Solutions
Paper MA07 Transforming Business Requirements into System Solutions Yongcun Zhang, Genentech, Inc., South San Francisco, CA The use of software products such as SAS System has contributed to companies
OSI Solution Architecture Framework
OSI Solution Architecture Framework Enterprise Service Center April 2008 California Health and Human Services Agency Revision History REVISION HISTORY REVISION/WORKSITE # DATE OF RELEASE OWNER SUMMARY
UNIFACE Component-based. Development Methodology UNIFACE V7.2. 151157206-00 Revision 0 Dec 2000 UMET
UNIFACE Component-based Development Methodology UNIFACE V7.2 151157206-00 Revision 0 Dec 2000 UMET UNIFACE Component-based Development Methodology Revision 0 Restricted Rights Notice This document and
Architecture Centric Development in Software Product Lines
Architecture Centric Development in Software Product Lines Aurangzeb Khan DCE, College of E & ME National University of Science and Technology (NUST), Pakistan Farooque Azam DCE, College of E & ME National
A methodology for secure software design
A methodology for secure software design Eduardo B. Fernandez Dept. of Computer Science and Eng. Florida Atlantic University Boca Raton, FL 33431 ed@cse.fau.edu 1. Introduction A good percentage of the
SYSTEMS ENGINEERING INFORMATION MODELS JOSEPH JAMES SIMPSON A THESIS. Presented to the Faculty of the Graduate School of the
SYSTEMS ENGINEERING INFORMATION MODELS by JOSEPH JAMES SIMPSON A THESIS Presented to the Faculty of the Graduate School of the UNIVERSITY OF MISSOURI-ROLLA In Partial Fulfillment of the Requirements for
Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali
Software development life cycle Software life cycle: Software Engineering - II ITNP92 - Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 abb@cs.stir.ac.uk Spring 2014 (elicitation)
Requirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao
Requirements Analysis Concepts & Principles Instructor: Dr. Jerry Gao Requirements Analysis Concepts and Principles - Requirements Analysis - Communication Techniques - Initiating the Process - Facilitated
Section 3: Program Portfolio Management
Section 3: Program Portfolio Management This section describes how the Biomass Program develops and manages its portfolio of RDD&D activities. It identifies and relates different types of portfolio management
Overview of the System Engineering Process. Prepared by
Overview of the System Engineering Process Prepared by Ed Ryen, PE Maintenance ITS March 2008 Introduction This document provides a high level look at the Systems Engineering Process for ITS projects.
A Comparison of Requirements Specification Methods from a Software Architecture Perspective
A Comparison of Requirements Specification Methods from a Software Architecture Perspective Len Bass John Bergey Paul Clements Paulo Merson Ipek Ozkaya Raghvinder Sangwan August 2006 TECHNICAL REPORT CMU/SEI-2006-TR-013
The role of integrated requirements management in software delivery.
Software development White paper October 2007 The role of integrated requirements Jim Heumann, requirements evangelist, IBM Rational 2 Contents 2 Introduction 2 What is integrated requirements management?
Extend the value of your core business systems.
Legacy systems renovation to SOA September 2006 Extend the value of your core business systems. Transforming legacy applications into an SOA framework Page 2 Contents 2 Unshackling your core business systems
Software Project Models
INTERNATIONAL JOURNAL OF TECHNOLOGY ENHANCEMENTS AND EMERGING ENGINEERING RESEARCH, VOL 1, ISSUE 4 135 Software Project Models Abhimanyu Chopra, Abhinav Prashar, Chandresh Saini Email-abhinav.prashar@gmail.com,
Lecture 1 IEGR 459: Introduction to Logistics Management and Supply Chain. James Ngeru Industrial and System Engineering
Lecture 1 IEGR 459: Introduction to Logistics Management and Supply Chain James Ngeru Industrial and System Engineering Objectives Address Logistics in General Terms and definitions Describe the need for
Testing a Software Product Line
Testing a Software Product Line John D. McGregor December 2001 TECHNICAL REPORT CMU/SEI-2001-TR-022 ESC-TR-2001-022 Pittsburgh, PA 15213-3890 Testing a Software Product Line CMU/SEI-2001-TR-022 ESC-TR-2001-022
Best Practices Statement Project Management. Best Practices for Managing State Information Technology Projects
State of Arkansas Office of Information Technology 124 W. Capitol Ave. Suite 990 Little Rock, AR 72201 501.682.4300 Voice 501.682.4020 Fax http://www.cio.arkansas.gov/techarch Best Practices Statement
Scope Planning (IS PM 5. Lecture, 2012 Spring)
Scope Planning Project success is determined by its usefulness or profitability: in increase of revenue in savings of costs The main reason to change existent information system is to get more benefits
Software Test Plan (STP) Template
(STP) Template Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. This
Chap 1. Introduction to Software Architecture
Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)
Requirements Management John Hrastar
Requirements Management John Hrastar NASA Project Management Conference March 30-31, 2004 University of Maryland Conference Center Introduction Three aspects of requirements management Requirements in
Mastering increasing product complexity with Collaborative Systems Engineering and PLM
Mastering increasing product complexity with Collaborative Systems Engineering and PLM Thierry Ambroisine Dassault Systèmes 10 rue Marcel Dassault, 78140 Vélizy Villacoublay, France thierry.ambroisine@3ds.com
AC 20-148 REUSABLE SOFTWARE COMPONENTS
AC 20-148 REUSABLE SOFTWARE COMPONENTS December 7, 2004 12/7/04 AC 20-148 CONTENTS Paragraph Title Page 1. Purpose....1 2. Motivation for this Guidance....1 3. Document Overview...1 4. General Guidelines
SOA: The missing link between Enterprise Architecture and Solution Architecture
SOA: The missing link between Enterprise Architecture and Solution Architecture Jaidip Banerjee and Sohel Aziz Enterprise Architecture (EA) is increasingly being acknowledged as the way to maximize existing
What You Need to Know About Transitioning to SOA
What You Need to Know About Transitioning to SOA written by: David A. Kelly, ebizq Analyst What You Need to Know About Transitioning to SOA Organizations are increasingly turning to service-oriented architectures
Quantification and Traceability of Requirements
Quantification and Traceability of Requirements Gyrd Norvoll Master of Science in Computer Science Submission date: May 2007 Supervisor: Tor Stålhane, IDI Norwegian University of Science and Technology
Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements
Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements
Requirements Traceability. Mirka Palo
Requirements Traceability Mirka Palo Seminar Report Department of Computer Science University of Helsinki 30 th October 2003 Table of Contents 1 INTRODUCTION... 1 2 DEFINITION... 1 3 REASONS FOR REQUIREMENTS
Evaluation of the Iceland State Financial and Human Resource System REPORT OF THE INDIVIDUAL EVALUATOR. Annex 2 SYSTEM AND SOFTWARE QUALITY
Evaluation of the Iceland State Financial and Human Resource System REPORT OF THE INDIVIDUAL EVALUATOR Annex 2 SYSTEM AND SOFTWARE QUALITY This paper lists the properties used in the two main models in
Elite: A New Component-Based Software Development Model
Elite: A New Component-Based Software Development Model Lata Nautiyal Umesh Kumar Tiwari Sushil Chandra Dimri Shivani Bahuguna Assistant Professor- Assistant Professor- Professor- Assistant Professor-
Introduction and Overview
Introduction and Overview Definitions. The general design process. A context for design: the waterfall model; reviews and documents. Some size factors. Quality and productivity factors. Material from:
Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3
Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3 1 Mälardalen University, Västerås, Sweden, ivica.crnkovic@mdh.se 2 ABB Corporate Research,
Architecture Definitions
Architecture Definitions Dana Bredemeyer Bredemeyer Consulting Tel: (812) 335-1653 Fax: (812) 335-1652 Email: dana@bredemeyer.com Web: Ruth Malan Bredemeyer Consulting Tel: (812) 335-1653 Fax: (812) 335-1652
What is a life cycle model?
What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each
Issues in Information Systems Volume 15, Issue I, pp. 52-60, 2014
ORGANIZATIONALLY AGNOSTIC BUSINESS MODELING: HOW TO MAKE BUSINESS ARCHITECTURE ADAPTABLE TO ORGANIZATIONAL CHANGE Carlos E. Martinez, The MITRE Corporation, cmartinez@mitre.org Sheila A. Cane, The MITRE
Model, Analyze and Optimize the Supply Chain
Model, Analyze and Optimize the Supply Chain Optimize networks Improve product flow Right-size inventory Simulate service Balance production Optimize routes The Leading Supply Chain Design and Analysis
Agile Master Data Management A Better Approach than Trial and Error
Agile Master Data Management A Better Approach than Trial and Error A whitepaper by First San Francisco Partners First San Francisco Partners Whitepaper Executive Summary Market leading corporations are
The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision of resources to support service requirements.
CAPACITY AND AVAILABILITY MANAGEMENT A Project Management Process Area at Maturity Level 3 Purpose The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision
LDAP Authentication Configuration Appendix
1 Overview LDAP Authentication Configuration Appendix Blackboard s authentication technology is considered a focal point in the company s ability to provide true enterprise software. Natively, the Blackboard
CMMI for Development Quick Reference
CAUSAL ANALYSIS AND RESOLUTION SUPPORT (ML5) The purpose of Causal Analysis and Resolution (CAR) is to identify causes of selected outcomes and take action to improve process performance. SG 1 Root causes
CDC UNIFIED PROCESS PRACTICES GUIDE
Purpose The purpose of this document is to provide guidance on the practice of Modeling and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements.
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material,
A Variability Viewpoint for Enterprise Software Systems
2012 Joint Working Conference on Software Architecture & 6th European Conference on Software Architecture A Variability Viewpoint for Enterprise Software Systems Matthias Galster University of Groningen,
Christina Wallin ABB Corporate Research Department of Industrial IT 721 78 Västerås +46 (0)21 34 50 74 christina.wallin@se.abb.
Christina Wallin ABB Corporate Research Department of Industrial IT 721 78 Västerås +46 (0)21 34 50 74 christina.wallin@se.abb.com Software Development Lifecycle Models The Basic Types Rikard Land Mälardalens