A Case Study of the Systems Engineering Process in Healthcare Informatics Quality Improvement. Systems Engineering. Ali M. Hodroj

Size: px
Start display at page:

Download "A Case Study of the Systems Engineering Process in Healthcare Informatics Quality Improvement. Systems Engineering. Ali M. Hodroj"

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

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

More information

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0

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

More information

What is ISO/IEC 15288? (A Concise Introduction)

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)

More information

3SL. Requirements Definition and Management Using Cradle

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

More information

Software Development Life Cycle

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...

More information

Chapter 4. Preliminary System Design. Electrical & Computer Engineering School of Engineering THE COLLEGE OF NEW JERSEY

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

More information

Leveraging CMMI framework for Engineering Services

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

More information

Systems Development Life Cycle (SDLC)

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

More information

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) 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

More information

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. 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

More information

ITS Projects Systems Engineering Process Compliance Checklist

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

More information

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT

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

More information

Software Development in the Large!

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

More information

Kunal Jamsutkar 1, Viki Patil 2, P. M. Chawan 3 (Department of Computer Science, VJTI, MUMBAI, INDIA)

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.

More information

An Approach to Software Architecture Description Using UML

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,

More information

JOURNAL OF OBJECT TECHNOLOGY

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,

More information

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 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

More information

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 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

More information

A Comparison of SOA Methodologies Analysis & Design Phases

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

More information

Introduction to SOA governance and service lifecycle management.

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

More information

Practice Overview. REQUIREMENTS DEFINITION Issue Date: Revision Date:

Practice Overview. REQUIREMENTS DEFINITION Issue Date: <mm/dd/yyyy> Revision Date: <mm/dd/yyyy> DEPARTMENT OF HEALTH AND HUMAN SERVICES ENTERPRISE PERFORMANCE LIFE CYCLE FRAMEWORK PRACTIICES GUIIDE REQUIREMENTS DEFINITION Issue Date: Revision Date: Document

More information

PROJECT SCOPE MANAGEMENT

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

More information

SOFTWARE ARCHITECTURE QUALITY EVALUATION

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

More information

Karunya University Dept. of Information Technology

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

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

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 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,

More information

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 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.

More information

Software Engineering UNIT -1 OVERVIEW

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

More information

Building Reusable Testing Assets for a Product Line

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

More information

Software Engineering Reference Framework

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

More information

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 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

More information

What methods are used to conduct testing?

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

More information

Managing Software Product Line

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.

More information

General Problem Solving Model. Software Development Methodology. Chapter 2A

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

More information

Course Description. Course Audience. Course Outline. Course Page - Page 1 of 14

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,

More information

Lecture 8. Systems engineering L E C T U R E. SIMILAR process. Zuzana Bělinová. Faculty of Transportation Sciences, CTU in Prague

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

More information

Web Application Architectures

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

More information

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) 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

More information

KNOWLEDGE MANAGEMENT SYSTEMS LIFE CYCLE

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

More information

Requirements and Duncker Diagrams

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

More information

Enterprise Architecture Glossary by Set

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

More information

11 Tips to make the requirements definition process more effective and results more usable

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

More information

Engineering a EIA - 632

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

More information

Classical Software Life Cycle Models

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

More information

Process Models and Metrics

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

More information

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 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

More information

8. Master Test Plan (MTP)

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

More information

CHAPTER 24 SOFTWARE PROJECT SCHEDULING. Overview

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

More information

Applying 4+1 View Architecture with UML 2. White Paper

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

More information

Information system for production and mounting of plastic windows

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

More information

CDC UNIFIED PROCESS PRACTICES GUIDE

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

More information

Quality Management. Lecture 12 Software quality management

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

More information

Agile Master Data Management

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

More information

Chapter 11: Integration- and System Testing

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

More information

ITIL v3 Process Cheat Sheets

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

More information

SYSTEM ANALYSIS CHAPTER 5. Expected Outcomes

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

More information

Transforming Business Requirements into System Solutions

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

More information

OSI Solution Architecture Framework

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

More information

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 UNIFACE V7.2 151157206-00 Revision 0 Dec 2000 UMET UNIFACE Component-based Development Methodology Revision 0 Restricted Rights Notice This document and

More information

Architecture Centric Development in Software Product Lines

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

More information

A methodology for secure software design

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

More information

SYSTEMS ENGINEERING INFORMATION MODELS JOSEPH JAMES SIMPSON A THESIS. Presented to the Faculty of the Graduate School 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

More information

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

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)

More information

Requirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao

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

More information

Section 3: Program Portfolio Management

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

More information

Overview of the System Engineering Process. Prepared by

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.

More information

A Comparison of Requirements Specification Methods from a Software Architecture Perspective

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

More information

The role of integrated requirements management in software delivery.

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?

More information

Extend the value of your core business systems.

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

More information

Software Project Models

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,

More information

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 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

More information

Testing a Software Product Line

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

More information

Best Practices Statement Project Management. Best Practices for Managing State Information Technology Projects

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

More information

Scope Planning (IS PM 5. Lecture, 2012 Spring)

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

More information

Software Test Plan (STP) Template

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

More information

Chap 1. Introduction to Software Architecture

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)

More information

Requirements Management John Hrastar

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

More information

Mastering increasing product complexity with Collaborative Systems Engineering and PLM

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

More information

AC 20-148 REUSABLE SOFTWARE COMPONENTS

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

More information

SOA: The missing link between Enterprise Architecture and Solution Architecture

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

More information

What You Need to Know About Transitioning to SOA

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

More information

Quantification and Traceability of Requirements

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

More information

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

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

More information

Requirements Traceability. Mirka Palo

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

More information

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 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

More information

Elite: A New Component-Based Software Development Model

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-

More information

Introduction and Overview

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:

More information

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 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,

More information

Architecture Definitions

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

More information

What is a life cycle model?

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

More information

Issues in Information Systems Volume 15, Issue I, pp. 52-60, 2014

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

More information

Model, Analyze and Optimize the Supply Chain

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

More information

Agile Master Data Management A Better Approach than Trial and Error

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

More information

The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision of resources to support service requirements.

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

More information

LDAP Authentication Configuration Appendix

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

More information

CMMI for Development Quick Reference

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

More information

CDC UNIFIED PROCESS PRACTICES GUIDE

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.

More information

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 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,

More information

A Variability Viewpoint for Enterprise Software Systems

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,

More information

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. 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

More information