https://sebokwiki.org/w/api.php?action=feedcontributions&user=Bwells&feedformat=atomSEBoK - User contributions [en]2024-03-28T23:44:58ZUser contributionsMediaWiki 1.35.13https://sebokwiki.org/w/index.php?title=System_Disposal_and_Retirement&diff=35750System Disposal and Retirement2012-07-03T17:12:46Z<p>Bwells: </p>
<hr />
<div>Design for product or service disposal and retirement is an important part of system life management. At some point, any deployed system will become one of the following: uneconomical to maintain, obsolete, or unrepairable. A comprehensive systems engineering process includes an anticipated equipment phase-out period and takes disposal into account in the design and life cycle cost assessment. <br />
<br />
A public focus on sustaining a clean environment encourages contemporary systems engineering design to consider recycling, reuse, and responsible disposal techniques.<br />
== Topic Overview ==<br />
<br />
According to the [[INCOSE Systems Engineering Handbook]], “The purpose of the Disposal Process is to remove a system element from the operation environment with the intent of permanently terminating its use; and to deal with any hazardous or toxic materials or waste products in accordance with the applicable guidance, policy, regulation, and statutes" (INCOSE 2011).<br />
<br />
In addition to technological and economical factors, the system being developed must be compatible, acceptable, and ultimately address the design of a system for the environment in terms of ecological, political, and social considerations. In particular, the ecological considerations associated with system disposal or retirement is of prime importance. The most concerning problems of dealing with waste are identified below.<br />
<br />
* Air Pollution and Control <br />
* Water Pollution and Control <br />
* Noise Pollution and Control <br />
* Radiation <br />
* Solid Waste<br />
<br />
In the United States, the Environmental Protection Agency [[Acronyms|(EPA)]] and the Occupational Safety and Health Administration [[Acronyms|(OSHA)]] govern disposal and retirement of commercial systems; equivalent organizations perform this function in other countries.<br />
<br />
OSHA addresses hazardous materials under the 1910-119A List of Highly Hazardous Chemicals, Toxics, and Reactives (OSHA 2010). System Disposal and Retirement spans both commercial and government developed products and services. While both the commercial and government sectors have common goals, the methods used to accomplish disposition of materials associated with military systems are different.<br />
<br />
The [[Acronyms|(OSD AT&L)]] on-line reference provides guidance regarding military system disposal. Directive 4160.21-M in the ''Defense Material Disposition Manual'' implements the requirements of the federal property management regulation (FPMR) and other laws and regulations as appropriate regarding the disposition of excess, surplus, and foreign excess personal property (FEPP). Military system disposal activities are compliant with EPA and OSHA requirements.<br />
<br />
== Application to Product Systems ==<br />
<br />
Product system retirement may include system disposal activities or preservation activities (e.g., mothballing) if there is a chance the system may be called upon for use at a later time. [[Acronyms|OSD AT&L]] provides guidance for the preservation of military systems, such as naval ships and aircraft.<br />
<br />
[[Systems Engineering and Analysis]] has several chapters that discuss the topics of design for goals such as “green engineering,” reliability, maintainability, logistics, supportability, producibility, disposability, and sustainability. Chapter 16 provides a succinct discussion of “green engineering” considerations and “ecology-based manufacturing.” Chapter 17 discusses life cycle costing and the inclusion of system disposal and retirement costs (Blanchard and Fabrycky 2011).<br />
<br />
Some disposal of a system's components occurs during the system’s operational life. This happens when the components fail and are replaced. As a result, the tasks and resources needed to remove them from the system need to be planned well before the actual demand for disposal occurs. Planning must consider transportation of failed items, handling equipment, special training requirements for personnel, facilities, technical procedures, technical documentation updates, hazardous material (HAZMAT) remediation, all associated costs, and reclamation or salvage value for precious metals and recyclable components. Phase-out and disposal planning addresses when disposal should take place, the economic feasibility of the disposal methods used, and what the effects on the inventory and support infrastructure, safety, environmental requirements, and impact to the environment will be (Blanchard 2010). Disposal is the least efficient and least desirable alternative for the processing of waste material (Finlayson and Herdlick 2008). <br />
<br />
The EPA collects information regarding the generation, management, and final disposition of hazardous wastes regulated under the Resource Conservation and Recovery Act of 1976 (RCRA). <br />
<br />
EPA waste management regulations are codified at 40 C.F.R. parts 239-282. Regulations regarding management of hazardous wastes begin at 40 C.F.R. part 260. Most states have enacted laws and promulgated regulations that are at least as stringent as federal regulations. Due to the extensive tracking of the life of hazardous waste, the overall process has become known as the cradle-to-grave system. Stringent bookkeeping and reporting requirements have been levied on generators, transporters, and operators of treatment, storage, and disposal facilities that handle hazardous waste.<br />
<br />
See the EPA website for a comprehensive list of wastes, including resource conservation, hazardous wastes, and non-hazardous wastes. <br />
<br />
Unfortunately, disposability has a lower priority compared to other activities associated with product development. This is due to the fact that, typically, the disposal process is viewed as an external activity to the entity that is in custody of the system at the time. Some of the reasons behind this view include:<br />
<br />
*There is no direct revenue associated with the disposal process and the majority of the cost associated with the disposal process is initially hidden.<br />
*Typically, someone outside of systems engineering performs the disposal activities, thus the "not my problem" attitude is common. For example, neither a car manufacturer nor the car's first buyer may be concerned about a car's disposal since the car will usually be sold before disposal.<br />
<br />
The European Union’s Registration, Evaluation, Authorization, and Restriction of Chemicals (REACH) regulation requires manufacturers and importers of chemicals and products to register and disclose substances in products when specific thresholds and criteria are met (European Parliament 2007). The European Chemicals Agency [[Acronyms|(ECHA)]] manages REACH processes.<br />
<br />
Numerous substances will be added to the list of substances already restricted under European legislation; for example, a new regulation emerged when the Restriction on Hazardous Substances (RoHS) in electrical and electronic equipment was adopted in 2003.<br />
<br />
Requirements for substance use and availability are changing across the globe. Identifying the use of materials in the supply chain that may face restriction is an important system life management consideration. System disposal and retirement requires upfront planning and the development of a disposal plan to manage the activities. An important consideration during system retirement is the proper planning required to update the facilities needed to support the system during retirement, as explained in the ''California Department of Transportation Systems Engineering Guidebook''. <br />
<br />
Disposal needs to take into account environmental and personal risks associated with the decommissioning of a system and all hazardous materials need to be accounted for. The decommissioning of a nuclear power plant is a prime example of hazardous material control and exemplifies the need for properly handling and transporting residual materials resulting from the retirement of certain systems.<br />
<br />
The Defense Logistics Agency [[Acronyms|(DLA)]] is the lead military agency responsible for providing guidance for worldwide reuse, recycling, and disposal of military products. A critical responsibility of the military services and defense agencies is demilitarization prior to disposal.<br />
<br />
== Application to Service Systems ==<br />
An important consideration during service system retirement or disposal is the proper continuation of services for the consumers of the system. As service systems are retired, it is often integral to continue to provide the same quality and capacity of services offered by the system. As an existing service system is decommissioned, a plan should be adopted to bring new systems online that operate in parallel of the existing system so that service interruption is kept to a minimum. This parallel operation can occur over a significant period of time and needs to be carefully scheduled. Examples of parallel operation include phasing-in new Air Traffic Control (ATC) systems (FAA 2006), the migration from analog TV to new digital TV modulation (FCC 2009), the transition to Internet protocol version 6 (IPv6), maintaining water handling systems, and maintaining large commercial transportation systems, such as rail and shipping vessels.<br />
<br />
The ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]]'' provides planning guidance for the retirement and replacement of large transportation systems. Chapter 4.7 identifies several factors which can shorten the useful life of a transportation system and lead to early retirement, such as the lack of proper documentation, the lack of effective configuration management processes, and the lack of an adequate operations and maintenance budget (Caltrans, and USDOT 2005).<br />
<br />
== Application to Enterprises ==<br />
The disposal and retirement of large enterprise service systems requires a phased approach where capital planning is implemented in stages. As is the case of service systems, an enterprise system's disposal and retirement require parallel operation of the replacement system along with the existing (older) system to prevent loss of functionality for the users of the enterprise.<br />
<br />
==Other Topics==<br />
See the [[Acronyms|OSHA]] standard and [[Acronyms|EPA]] website for references that provide listings of hazardous materials. See the [http://www.dtc.dla.mil DLA Disposal Services website] for disposal services sites and additional information on hazardous materials.<br />
<br />
== Practical Considerations ==<br />
A prime objective is to design a product or service such that its components can be recycled after the system has been retired. The recycling process should not cause any detrimental effects to the environment.<br />
<br />
One of the latest movements in the industry is called green engineering. According to the Environmental Protection Agency (EPA), green engineering is the design, commercialization, and use of processes and products that are technically and economically feasible while minimizing:<br />
*The generation of pollutants at the source.<br />
*The Risks to human health and the environment.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Blanchard, B. S. 2010. ''Logistics Engineering and Management'', 5th ed. Englewood Cliffs, NJ: Prentice Hall, 341-342.<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
DLA. 2010. “Defense logistics agency disposition services.” In Defense Logistics Agency (DLA)/U.S. Department of Defense [database online]. Battle Creek, MI, USA, accessed June 19 2010: 5. Available at: http://www.dtc.dla.mil.<br />
<br />
ECHA. 2010. “European Chemicals Agency (ECHA).” In European Chemicals Agency (ECHA). Helsinki, Finland. Available at: http://echa.europa.edu/home_en.asp. <br />
<br />
EPA. 2010. “Wastes In U.S. Environmental Protection Agency (EPA)." Washington, D.C. Available at: http://www.epa.gov/epawaste/index.htm.<br />
<br />
European Parliament. 2007. Regulation (EC) no 1907/2006 of the european parliament and of the council of 18 december 2006 concerning the registration, evaluation, authorisation and restriction of chemicals (REACH), establishing a european chemicals agency, amending directive 1999/45/EC and repealing council regulation (EEC) no 793/93 and commission regulation (EC) no 1488/94 as well as council directive 76/769/EEC and commission directives 91/155/EEC, 93/67/EEC, 93/105/EC and 2000/21/EC. Official Journal of the European Union 29 (5): 136/3,136/280. <br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
OSHA. 1996. “Hazardous Materials: Appendix A: List of Highly Hazardous Chemicals, Toxics and Reactives.” Washington, DC, USA: Occupational Safety and Health Administration (OSHA)/U.S. Department of Labor (DoL), 1910.119(a).<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
<br />
Blanchard, B. S. 2010. ''Logistics Engineering and Management'', 5th ed. Englewood Cliffs, NJ: Prentice Hall, 341-342.<br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
DLA. 2010. “Defense logistics agency disposition services.” In Defense Logistics Agency (DLA)/U.S. Department of Defense [database online]. Battle Creek, MI, USA, accessed June 19 2010: 5. Available at: http://www.dtc.dla.mil.<br />
<br />
ECHA. 2010. “European Chemicals Agency (ECHA).” In European Chemicals Agency (ECHA). Helsinki, Finland. Available at: http://echa.europa.edu/home_en.asp. <br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
EPA. 2010. “Wastes In U.S. Environmental Protection Agency (EPA)." Washington, D.C. Available at: http://www.epa.gov/epawaste/index.htm.<br />
<br />
European Parliament. 2007. Regulation (EC) no 1907/2006 of the european parliament and of the council of 18 december 2006 concerning the registration, evaluation, authorisation and restriction of chemicals (REACH), establishing a european chemicals agency, amending directive 1999/45/EC and repealing council regulation (EEC) no 793/93 and commission regulation (EC) no 1488/94 as well as council directive 76/769/EEC and commission directives 91/155/EEC, 93/67/EEC, 93/105/EC and 2000/21/EC. Official Journal of the European Union 29 (5): 136/3,136/280. <br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
FSA. 2010. “Template for 'System Retirement Plan' and 'System Disposal Plan'.” In Federal Student Aid (FSA)/U.S. Department of Eduation (DoEd). Washington, DC, USA. Accessed August 5, 2010. Available at: http://federalstudentaid.ed.gov/business/lcm.html.<br />
<br />
IEEE 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
Ihii, K., C.F. Eubanks, and P. Di Marco. 1994. “Design for Product Retirement and Material Life-Cycle.” ''Materials & Design'' 15(4): 225-33. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Minneapolis-St. Paul Chapter. 2003. "Systems Engineering in Systems Deployment and Retirement, presented to INCOSE." Minneapolis-St. Paul, MN, USA: International Society of Logistics (SOLE), Minneapolis-St. Paul Chapter. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
OSHA. 1996. “Hazardous Materials: Appendix A: List of Highly Hazardous Chemicals, Toxics and Reactives.” Washington, DC, USA: Occupational Safety and Health Administration (OSHA)/U.S. Department of Labor (DoL), 1910.119(a). <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Capability Updates, Upgrades, and Modernization|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Systems Engineering Standards|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35749Capability Updates, Upgrades, and Modernization2012-07-03T17:10:17Z<p>Bwells: </p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The ''INCOSE UK Chapter Supplementary Guidance'' (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Supplementary Guidance'' (2010) points out, the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
In “Life extension of Civil Infrastructural works - a systems engineering approach” van der Laan (2008) provides a maintenance process that interacts with the system engineering process, represented by the V-model. His life extension (or modernization) process model includes reverse engineering to obtain the system definition necessary for the modernization process. Consideration of the total lifecycle of the system will result in the capture of all of the records necessary for later upgrade, but for many reasons, the systems engineer will find that the necessary information has not been captured or maintained.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Supplementary Guidance'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
van der Laan, Jan. 2008. “Life extension of Civil Infrastructural works - a systems engineering approach.” Proceedings of the 18th annual International Symposium of the International Council on Systems Engineering, Utrecht, the Netherlands.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35748Capability Updates, Upgrades, and Modernization2012-07-03T17:09:21Z<p>Bwells: </p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The ''INCOSE UK Chapter Supplementary Guidance'' (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Supplementary Guidance'' (2010) points out, the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
In “Life extension of Civil Infrastructural works - a systems engineering approach” van der Laan (2008) provides a maintenance process that interacts with the system engineering process, represented by the V-model. His life extension (or modernization) process model includes reverse engineering to obtain the system definition necessary for the modernization process. Consideration of the total lifecycle of the system will result in the capture of all of the records necessary for later upgrade, but for many reasons, the systems engineer will find that the necessary information has not been captured or maintained.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Supplementary Guidance'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
van der Laan, Jan. 2008. “Life extension of Civil Infrastructural works - a systems engineering approach.” Proceedings of the 18th annual International Symposium of the International Council on Systems Engineering, Utrecht, the Netherlands.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35747Capability Updates, Upgrades, and Modernization2012-07-03T17:05:10Z<p>Bwells: /* Practical Considerations */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Supplemental Guidance'' points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
In “Life extension of Civil Infrastructural works - a systems engineering approach” van der Laan (2008) provides a maintenance process that interacts with the system engineering process, represented by the V-model. His life extension (or modernization) process model includes reverse engineering to obtain the system definition necessary for the modernization process. Consideration of the total lifecycle of the system will result in the capture of all of the records necessary for later upgrade, but for many reasons, the systems engineer will find that the necessary information has not been captured or maintained.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Supplementary Guidance'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
van der Laan, Jan. 2008. “Life extension of Civil Infrastructural works - a systems engineering approach.” Proceedings of the 18th annual International Symposium of the International Council on Systems Engineering, Utrecht, the Netherlands.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35746Capability Updates, Upgrades, and Modernization2012-07-03T17:04:24Z<p>Bwells: /* Practical Considerations */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Supplemental Guidance'' points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
In “Life extension of Civil Infrastructural works - a systems engineering approach” van der Laan (2008) provides a maintenance process that interacts with the system engineering process, represented by the V-model. His life extension (or modernization) process model includes reverse engineering to obtain the system definition necessary for the modernization process. Consideration of the total lifecycle of the system will result in the capture of all of the records necessary for later upgrade, but for many reasons, the systems engineer will find that the necessary information has not been captured or maintained.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Supplementary Guidance'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
van der Laan, Jan. 2008. “Life extension of Civil Infrastructural works - a systems engineering approach.” Proceedings of the 18th annual International Symposium of the International Council on Systems Engineering, Utrecht, the Netherlands.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35745Capability Updates, Upgrades, and Modernization2012-07-03T17:03:37Z<p>Bwells: /* Practical Considerations */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Supplemental Guidance'' points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
In “Life extension of Civil Infrastructural works - a systems engineering approach” van der Laan (2008) provides a maintenance process that interacts with the system engineering process, represented by the V-model. His life extension (or modernization) process model includes reverse engineering to obtain the system definition necessary for the modernization process. Consideration of the total lifecycle of the system will result in the capture of all of the records necessary for later upgrade, but for many reasons, the systems engineer will find that the necessary information has not been captured or maintained.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Supplemental Guidance'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
van der Laan, Jan. 2008. “Life extension of Civil Infrastructural works - a systems engineering approach.” Proceedings of the 18th annual International Symposium of the International Council on Systems Engineering, Utrecht, the Netherlands.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35744Capability Updates, Upgrades, and Modernization2012-07-03T17:02:36Z<p>Bwells: /* Works Cited */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Supplemental Guidance'' points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
In “Life extension of Civil Infrastructural works - a systems engineering approach” van der Laan (2008) provides a maintenance process that interacts with the system engineering process, represented by the V-model. His life extension (or modernization) process model includes reverse engineering to obtain the system definition necessary for the modernization process. Consideration of the total lifecycle of the system will result in the capture of all of the records necessary for later upgrade, but for many reasons, the systems engineer will find that the necessary information has not been captured or maintained.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Guidebook'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
van der Laan, Jan. 2008. “Life extension of Civil Infrastructural works - a systems engineering approach.” Proceedings of the 18th annual International Symposium of the International Council on Systems Engineering, Utrecht, the Netherlands.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35743Capability Updates, Upgrades, and Modernization2012-07-03T17:00:05Z<p>Bwells: /* Works Cited */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Supplemental Guidance'' points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
In “Life extension of Civil Infrastructural works - a systems engineering approach” van der Laan (2008) provides a maintenance process that interacts with the system engineering process, represented by the V-model. His life extension (or modernization) process model includes reverse engineering to obtain the system definition necessary for the modernization process. Consideration of the total lifecycle of the system will result in the capture of all of the records necessary for later upgrade, but for many reasons, the systems engineer will find that the necessary information has not been captured or maintained.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Guidebook'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
van der Laan, Jan. 2008. “Life extension of Civil Infrastructural works - a systems engineering approach.” Proceedings of the 18th annual International Symposium of the International Council on Systems Engineering.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35742Capability Updates, Upgrades, and Modernization2012-07-03T16:58:57Z<p>Bwells: /* The Vee Model for Modifications */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Supplemental Guidance'' points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
In “Life extension of Civil Infrastructural works - a systems engineering approach” van der Laan (2008) provides a maintenance process that interacts with the system engineering process, represented by the V-model. His life extension (or modernization) process model includes reverse engineering to obtain the system definition necessary for the modernization process. Consideration of the total lifecycle of the system will result in the capture of all of the records necessary for later upgrade, but for many reasons, the systems engineer will find that the necessary information has not been captured or maintained.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Guidebook'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35741Capability Updates, Upgrades, and Modernization2012-07-03T16:56:59Z<p>Bwells: /* The Vee Model for Modifications */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Supplemental Guidance'' points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Guidebook'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35740Capability Updates, Upgrades, and Modernization2012-07-03T16:49:07Z<p>Bwells: /* Topic Overview */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Guidebook'' points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Guidebook'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35739Capability Updates, Upgrades, and Modernization2012-07-03T16:45:44Z<p>Bwells: /* Topic Overview */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineers performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed supplementary guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Guidebook'' points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Guidebook'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35738Capability Updates, Upgrades, and Modernization2012-07-03T15:35:54Z<p>Bwells: /* The Vee Model for Modifications */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineering performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed supplementary guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Guidebook'' points out (INCOSE UK Chapter 2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Guidebook'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=35737Capability Updates, Upgrades, and Modernization2012-07-03T15:33:40Z<p>Bwells: /* Topic Overview */</p>
<hr />
<div>Modernization and upgrades involve changing the product or service to include new functions, new interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2011) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) stress the importance of using Life Cycle Costs when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
[[Engineering Change Proposal (ECP) (glossary)|Engineering Change Proposals (ECP) (glossary)]] are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. [[Form, Fit, Function, and Interface (F3I) (glossary)]] is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
Product and service modernization occurs for many reasons. For example:<br />
*The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
*A customer or other stakeholder may desire a new capability for the system. <br />
*Some of the system components may be experiencing obsolescence, including the lack of spare parts. <br />
*New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in the ''INCOSE UK Chapter Guidebook'' (2010). <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering processes and principles that are employed during the upfront design, development, integration, and test. The primary differences between product and service modernization are the constraints imposed by the existing system architecture, design, and components. Modernizing a legacy system requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts makes it necessary for the systems engineering performing modernization to tailor the normal development process steps to fit the situation.<br />
<br />
The UK chapter of the INCOSE developed supplementary guidance to the ''INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010) This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
<br />
*type of system (space, air, ground, maritime , and safety critical);<br />
*missions and scenarios of expected operational usage;<br />
*policy and legal requirements that are imposed by certain agencies or business markets;<br />
*product or service life cycle costs; <br />
*electromagnetic spectrum usage expected, including change in RF emissions; <br />
*system Original Equipment Manufacturer (OEM) and key suppliers, and availability of parts and subsystems;<br />
*understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation;<br />
*system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems; and<br />
*the amount of regression testing to be performed on the existing software.<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
*legislative policy adherence review and certification;<br />
*safety critical review;<br />
*engineering change management and configuration control;<br />
*analysis of Alternatives;<br />
*warranty and product return process implementation; and<br />
*availability of manufacturing and supplier sources and products.<br />
<br />
==Application to Product Systems==<br />
<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritized change requests, and customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of [[Failure Modes and Effects Criticality Analysis (glossary)]] (FMECA) to understand the the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the Engineering Change Management principle of change control boards to review and implement product changes and improvements. [[Acronyms|OSD AT&L]] provides an on-line reference for product modernization and the use of an Engineering Change Proposal to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2011) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, [[Reverse Engineering (glossary)]] is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's [[Modernizing Legacy Systems]] (2003), states the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes.<br />
<br />
Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system. They point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation. <br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2011, 126–128) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products involve components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems are consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. <br />
<br />
Service system modernization, which spans large geographical areas, requires a phased-based change and implementation strategy. Transportation systems such as highways (i.e., Interstate Highways) provide service to many different types of consumers and span such large geographical areas. <br />
<br />
Modernization often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, TV cameras, and toll tags interface with the rest of the system. The California Department of Transportation's [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the [[Acronyms|SWEBoK]] (Abran, 2004).<br />
<br />
==Application to Enterprises ==<br />
<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization requires coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The Chapter Guidebook (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture.<br />
<br />
As an example, the global positioning system [[Acronyms|(GPS)]] is an enterprise system implemented by the US military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation.<br />
<br />
The air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard [[Vee (V) Model (glossary)|Vee Model (glossary)]] would be applied to a system modification. This Vee model is for the entire system; it applies to the whole aircraft, automobile, or other system. The key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Guidebook'' points out (2010), the Vee model may be entered multiple times during the life of the system.<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem may be introduced into the process at point B on the Vee model. Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original that necessitate modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. <br />
<br />
The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C in Figure 1 necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|Figure 1. The Vee Model for Modifications at the Three Different Levels (Figure Developed for BKCASE)]]<br />
<br />
There are many cases where the change to the system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels, but when there is, this must be identified and worked out with the customer and the other stakeholders.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Guidebook'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. <br />
<br />
The first method is called the “block” method. This means that a group of systems are being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. <br />
<br />
The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-off-the-Shelf Components===<br />
<br />
One of the more prominent considerations is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage for using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OSD(AT&L). “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''SWEBOK: Guide to the Software Engineering Body of Knowledge''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Disposal and Retirement|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
{{DISQUS}}</div>Bwellshttps://sebokwiki.org/w/index.php?title=Service_Life_Extension&diff=35736Service Life Extension2012-07-03T15:29:44Z<p>Bwells: /* Practical Considerations */</p>
<hr />
<div>Product and service life extension involves continued use of a product and/or service beyond its original [[Design Life (glossary)|design life (glossary)]]. Product and service life extension involves assessing the risks and the [[Life Cycle Cost (LCC) (glossary)|life cycle cost (LCC) (glossary)]] of continuing the use of the product or service versus the cost of a replacement system.<br />
<br />
[[Service Life Extension (SLE) (glossary)|Service life extension (SLE) (glossary)]] emphasizes reliability upgrades and component replacement or rebuilding of the system to delay the system’s entry into wear-out status due to prohibitively expensive sustainment, reliability, safety, and/or performance requirements that can no longer be met. The goal is typically to return the system to as new of a condition as possible while remaining consistent with the economic constraints of the program.<br />
<br />
SLE is regarded as an environmentally friendly way to relieve rampant waste by prolonging the use-life of retiring products and preventing them from being discarded too early when they still have unused value. However, challenged by fast-changing technology and physical deterioration, a major concern in planning a product SLE is considering to what degree a product or service is fit to have its life extended.<br />
<br />
==Topic Overview==<br />
<br />
Service Life Extension is typically required because:<br />
#The system no longer meets the system performance or reliability requirements,<br />
#The cost of operation and maintenance exceeds the cost of SLE, or the available budgets,<br />
#Parts are no longer available for repair and maintenance,<br />
#Operation of the system violates rules or regulations, such as environmental or safety regulations, or<br />
#Parts of the system are about to reach their operations life limits, which will result in items 1, 2, 3, or 4 occurring soon.<br />
It is best if the systems engineers use a pro-active approach that predicts ahead, so that SLE can be accomplished before the system fails to meet its requirements and before the operations and support costs rise above acceptable limits.<br />
<br />
Key factors and questions that must be considered by the systems engineer during service life extension include:<br />
*Current life cycle costs of the system; <br />
*Design life and expected remaining useful life of the system;<br />
*Software maintenance;<br />
*Configuration Management; <br />
*Warranty policy;<br />
*Availability of parts, subsystems, and manufacturing sources; and <br />
*Availability of system documentation to support life extension.<br />
<br />
System [[Design Life (glossary)|design life (glossary)]] is a major consideration for service life extension. System design life parameters are established early on during the system design phase and include key assumptions involving safety limits and material life. Safety limits and the properties of material aging are critical to defining system life extension. Jackson emphasizes that architecting for system resiliency increases system life. He also points out that a system can be architected to withstand internal and external disruptions (2007, 91-108). Systems that age through use, such as aircraft, bridges, and nuclear power plants, require periodic inspection to ascertain the degree of aging and fatigue. The results of inspections determine the need for actions to extend the product life (Elliot, Chen, and Swanekamp 1998, sec. 6.5).<br />
<br />
Software maintenance is a critical aspect of service life extension. The [[Legacy System (glossary)|legacy system (glossary)]] may include multiple computer resources that have been in operation for a period of many years and have functions that are essential and must not be disrupted during the upgrade or integration process. Typically, legacy systems include a computer resource or application software program that continues to be used because the cost of replacing or redesigning it is prohibitive. The Software Engineering Institute (SEI) has addressed the need for service life extension of software products and services and provides useful guidance in the on-line library for Software Product Lines (SEI 2010, 1). <br />
<br />
Systems engineers have found that service life can be extended through the proper selection of materials. For example, transportation system elements such as highway bridges and rail systems are being designed for extended service life by using special epoxy-coated steel (Brown, Weyers, and Spinkel 2006, 13).<br />
<br />
Diminishing manufacturing sources and diminishing suppliers need to be addressed early on in the service life extension process. Livingston (2010) in ''Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices'' provides a method for addressing product life extension when the sources of supply are an issue. He addresses the product life cycle model and describes a variety of methods that can be applied during system design to minimize the impact of future component obsolescence issues.<br />
<br />
During product and service life extension, it is often necessary to revisit and challenge the assumptions behind any previous life cycle cost analysis (and constituent analyses) to evaluate their continued validity and/or applicability early in the service life extension process.<br />
<br />
==Application to Product Systems==<br />
<br />
Product life extension requires an analysis of the life cycle cost associated with continued use of the existing product versus the cost of a replacement product. In the [[INCOSE Systems Engineering Handbook]], Chapter 3.3 points out that the support stage includes service life extension. Chapter 7 provides a framework to determine if a product’s life should be extended (INCOSE 2011). In [[Systems Engineering and Analysis]], Chapter 17 provides a Life Cycle Cost [[Acronyms|(LCC)]] methodology and emphasizes the analysis of different alternatives before making a decision on product life extension (Blanchard and Fabrycky 2011). <br />
<br />
For military systems, service life extension is considered a subset of modification or modernization. Military systems use well developed and detailed guidance for Service life extension programs [[Acronyms|(SLEP)]]. The Office of the Under Secretary of Defense (AT&L) provides an on-line reference for policies, procedures, planning guidance, and whitepapers for military product service life extension (DAU 2011). Continuous military system modernization is a process by which state of the art technologies are inserted continuously into weapon systems to increase reliability, lower sustainment costs, and increase the war fighting capability of a military system to meet evolving customer requirements throughout an indefinite service life. <br />
<br />
Aircraft service life can be extended by reducing the dynamic loads which lead to structural fatigue. The Boeing B-52 military aircraft and the Boeing 737 commercial aircraft are prime examples of system life extension. The B-52 was first fielded in 1955 and the Boeing 737 has been fielded since 1967; both aircraft are still in use today.<br />
<br />
For nuclear reactors, system safety is the most important precondition for service life extension. The system safety must be maintained while extending the service life (Paks 2010). Built-in tests, automated fault reporting and prognostics, analysis of failure modes, and the detection of early signs of wear and aging may be applied to predict the time when maintenance actions will be required to extend the service life of the product.<br />
<br />
==Application to Service Systems==<br />
<br />
For systems that provide services to a larger consumer base, service life extension involves continued delivery of the service without disrupting consumer use. Service life extension involves capital investment and financial planning, as well as a phased deployment of changes. Examples of these concepts can be seen in transportation systems, water treatment facilities, energy generation and delivery systems, and the health care industry. <br />
<br />
As new technologies are introduced, service delivery can be improved while reducing life cycle costs. Service systems have to continuously assess delivery costs based upon the use of newer technologies. <br />
<br />
Water handling systems provide a good example of a service system that undergoes life extension. Water handling systems have been in existence since early civilization. Since water handling systems are in use as long as a site is occupied (e.g., the Roman aqueducts), and upgrades are required as the population expands, such systems are a good example of "systems that live forever." For example, there are still U.S. water systems that use a few wooden pipes since there has been no reason to replace them. Water system life extension must deal with the issue of water quality and the capacity for future users (Mays, 2000). Water quality requirements can be further understood from the AWWA Manuals of Water Supply Practices (AWWA 2010).<br />
<br />
==Application to Enterprises==<br />
Service life extension of a large enterprise, such as NASA’s national space transportation system, involves service life extension on the elements of the enterprise, such as the space vehicle (shuttle), ground processing systems for launch operations and mission control, and space-based communication systems that support space vehicle tracking and status monitoring. Service life extension of an enterprise requires a [[holism (glossary)|holistic (glossary)]] look across the entire enterprise. A balanced approach is required to address the cost of operating older system components versus the cost required to implement service life improvements.<br />
<br />
Large enterprise systems, such as oil and natural gas reservoirs, which span broad geographical areas, can use advanced technology to increase their service life. The economic extraction of oil and natural gas resources from previously established reservoirs can extend their system life. One such life extension method is to pump special liquids or gases into the reservoir to push the remaining oil or natural gas to the surface for extraction (Office of Natural Gas & Oil Technology 1999).<br />
<br />
==Other Topics==<br />
<br />
Commercial product developers have been required to retain information for extended periods of time after the last operational product or unit leaves active service (for up to twenty years). Regulatory requirements should be considered when extending service life (INCOSE 2011).<br />
<br />
==Practical Considerations==<br />
The cost associated with life extension is one of the main inputs in the decision to extend service life of a product or a service. The cost of SLE must be compared to the cost of developing and deploying a new system, as well as the functional utility the user will obtain from each of the alternatives. It is often the case that the funding required for service life extension of large complex systems is spread over several fiscal planning cycles and is therefore subject to changes in attitude by the elected officials that appropriate the funding.<br />
<br />
The challenges with upgrading a system during use, which is often the case with SLE, must be understood and planned to avoid serious disruptions to the services the systems provide.<br />
<br />
Any SLE must also consider the obsolescence of the systems parts, including software, and the extent of the system redesign to eliminate the obsolete parts.<br />
<br />
==References== <br />
<br />
<br />
===Works Cited===<br />
<br />
AWWA. 2010. “AWWA Manuals of Water Supply Practices.” In American Water Works Association (AWWA). Denver, CO.Accessed August 5, 2010. Available at: http://www.awwa.org/Resources/standards.cfm?ItemNumber=47829&navItemNumber=47834.<br />
<br />
Blanchard, B. S., and W. J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Brown, M., R. Weyers, and M. Sprinkel. 2006. “Service Life Extension of Virginia Bridge Decks afforded by Epoxy-Coated Reinforcement.” ''Journal of ASTM International (JAI),'' 3(2): 13. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
Office of Natural Gas and Oil Technology. 1999. ''Reservoir LIFE Extension Program: Encouraging Production of Remaining Oil and Gas.'' Washington, DC, USA: U.S. Department of Engery (DoE). <br />
<br />
Paks Nuclear Power Plant. 2010. “Paks Nuclear Power Plant: Service Life Extension.” In Paks Nuclear Power Plant, Ltd.. Hungary, accessed August 5, 2010. Available at: http://paksnuclearpowerplant.com/service-life-extension.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
<br />
AWWA. 2010. “AWWA Manuals of Water Supply Practices.” In American Water Works Association (AWWA). Denver, CO.Accessed August 5, 2010. Available at: http://www.awwa.org/Resources/standards.cfm?ItemNumber=47829&navItemNumber=47834.<br />
<br />
Blanchard, B.S. 2010. ''Logistics engineering and management'', 5th ed. Englewood Cliffs, NJ, USA: Prentice Hall, 341-342.<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Brown, M., R. Weyers, and M. Sprinkel. 2006. “Service Life Extension of Virginia Bridge Decks afforded by Epoxy-Coated Reinforcement.” ''Journal of ASTM International (JAI),'' 3(2): 13. <br />
<br />
Caltrans and USDOT. 2005. ''Systems engineering guidebook for ITS,'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research & Innovation/U.S. Department of Transportation (USDOT), SEG for ITS 1.1: 278, 101-103, 107.<br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
DLA. 2010. “Defense logistics agency disposition services.” In Defense Logistics Agency (DLA)/U.S. Department of Defense [database online]. Battle Creek, MI, USA, accessed June 19 2010: 5. Available at: http://www.dtc.dla.mil.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
Gehring, G., D. Lindemuth, and W.T. Young. 2004. “Break Reduction/Life extension Program for CAST and Ductile Iron Water Mains.” Paper presented at NO-DIG 2004, Conference of the North American Society for Trenchless Technology (NASTT), March 22-24, New Orleans, LA, USA. <br />
<br />
Hovinga, M.N., and G.J. Nakoneczny. 2000. “Standard Recommendations for Pressure Part Inspection during a Boiler Life Extension Program.” Paper presented at ICOLM (International Conference on Life Management and Life Extension of Power Plant), May, Xi’an, P.R. China. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
ISO/IEC 2008. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.<br />
<br />
IEEE. 2010. IEEE Standard Framework for Reliability Prediction of Hardware. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
Ihii, K., C.F. Eubanks, and P. Di Marco. 1994. “Design for Product Retirement and Material Life-Cycle.” ''Materials & Design'' 15(4): 225-33. <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
ISO/IEC. 1997. “Systems Engineering for Commercial Aircraft.” Surrey, UK: Ashgate Publishing Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
L3 Communications. 2010. “Service Life Extension Program (SLEP).” Newport News, VA, USA: L3 Communications, Flight International Aviation LLC. <br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Office of Natural Gas and Oil Technology. 1999. ''Reservoir LIFE Extension Program: Encouraging Production of Remaining Oil and Gas.'' Washington, DC, USA: U.S. Department of Engery (DoE). <br />
<br />
Paks Nuclear Power Plant. 2010. “Paks Nuclear Power Plant: Service Life Extension.” In Paks Nuclear Power Plant, Ltd.. Hungary, accessed August 5, 2010. Available at: http://paksnuclearpowerplant.com/service-life-extension.<br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
Sukamto, S. 2003. “Plant Aging and Life Extension Program at Arun LNG Plant Lhokseumawe, North Aceh, Indonesia.” Paper presented at 22nd Annual World Gas Conference, June 1-5, Tokyo, Japan.<br />
<br />
----<br />
<center>[[Product and Service Life Management|< Previous Article]] | [[Product and Service Life Management|Parent Article]] | [[Capability Updates, Upgrades, and Modernization|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]</div>Bwellshttps://sebokwiki.org/w/index.php?title=Service_Life_Extension&diff=35735Service Life Extension2012-07-03T15:28:12Z<p>Bwells: /* Topic Overview */</p>
<hr />
<div>Product and service life extension involves continued use of a product and/or service beyond its original [[Design Life (glossary)|design life (glossary)]]. Product and service life extension involves assessing the risks and the [[Life Cycle Cost (LCC) (glossary)|life cycle cost (LCC) (glossary)]] of continuing the use of the product or service versus the cost of a replacement system.<br />
<br />
[[Service Life Extension (SLE) (glossary)|Service life extension (SLE) (glossary)]] emphasizes reliability upgrades and component replacement or rebuilding of the system to delay the system’s entry into wear-out status due to prohibitively expensive sustainment, reliability, safety, and/or performance requirements that can no longer be met. The goal is typically to return the system to as new of a condition as possible while remaining consistent with the economic constraints of the program.<br />
<br />
SLE is regarded as an environmentally friendly way to relieve rampant waste by prolonging the use-life of retiring products and preventing them from being discarded too early when they still have unused value. However, challenged by fast-changing technology and physical deterioration, a major concern in planning a product SLE is considering to what degree a product or service is fit to have its life extended.<br />
<br />
==Topic Overview==<br />
<br />
Service Life Extension is typically required because:<br />
#The system no longer meets the system performance or reliability requirements,<br />
#The cost of operation and maintenance exceeds the cost of SLE, or the available budgets,<br />
#Parts are no longer available for repair and maintenance,<br />
#Operation of the system violates rules or regulations, such as environmental or safety regulations, or<br />
#Parts of the system are about to reach their operations life limits, which will result in items 1, 2, 3, or 4 occurring soon.<br />
It is best if the systems engineers use a pro-active approach that predicts ahead, so that SLE can be accomplished before the system fails to meet its requirements and before the operations and support costs rise above acceptable limits.<br />
<br />
Key factors and questions that must be considered by the systems engineer during service life extension include:<br />
*Current life cycle costs of the system; <br />
*Design life and expected remaining useful life of the system;<br />
*Software maintenance;<br />
*Configuration Management; <br />
*Warranty policy;<br />
*Availability of parts, subsystems, and manufacturing sources; and <br />
*Availability of system documentation to support life extension.<br />
<br />
System [[Design Life (glossary)|design life (glossary)]] is a major consideration for service life extension. System design life parameters are established early on during the system design phase and include key assumptions involving safety limits and material life. Safety limits and the properties of material aging are critical to defining system life extension. Jackson emphasizes that architecting for system resiliency increases system life. He also points out that a system can be architected to withstand internal and external disruptions (2007, 91-108). Systems that age through use, such as aircraft, bridges, and nuclear power plants, require periodic inspection to ascertain the degree of aging and fatigue. The results of inspections determine the need for actions to extend the product life (Elliot, Chen, and Swanekamp 1998, sec. 6.5).<br />
<br />
Software maintenance is a critical aspect of service life extension. The [[Legacy System (glossary)|legacy system (glossary)]] may include multiple computer resources that have been in operation for a period of many years and have functions that are essential and must not be disrupted during the upgrade or integration process. Typically, legacy systems include a computer resource or application software program that continues to be used because the cost of replacing or redesigning it is prohibitive. The Software Engineering Institute (SEI) has addressed the need for service life extension of software products and services and provides useful guidance in the on-line library for Software Product Lines (SEI 2010, 1). <br />
<br />
Systems engineers have found that service life can be extended through the proper selection of materials. For example, transportation system elements such as highway bridges and rail systems are being designed for extended service life by using special epoxy-coated steel (Brown, Weyers, and Spinkel 2006, 13).<br />
<br />
Diminishing manufacturing sources and diminishing suppliers need to be addressed early on in the service life extension process. Livingston (2010) in ''Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices'' provides a method for addressing product life extension when the sources of supply are an issue. He addresses the product life cycle model and describes a variety of methods that can be applied during system design to minimize the impact of future component obsolescence issues.<br />
<br />
During product and service life extension, it is often necessary to revisit and challenge the assumptions behind any previous life cycle cost analysis (and constituent analyses) to evaluate their continued validity and/or applicability early in the service life extension process.<br />
<br />
==Application to Product Systems==<br />
<br />
Product life extension requires an analysis of the life cycle cost associated with continued use of the existing product versus the cost of a replacement product. In the [[INCOSE Systems Engineering Handbook]], Chapter 3.3 points out that the support stage includes service life extension. Chapter 7 provides a framework to determine if a product’s life should be extended (INCOSE 2011). In [[Systems Engineering and Analysis]], Chapter 17 provides a Life Cycle Cost [[Acronyms|(LCC)]] methodology and emphasizes the analysis of different alternatives before making a decision on product life extension (Blanchard and Fabrycky 2011). <br />
<br />
For military systems, service life extension is considered a subset of modification or modernization. Military systems use well developed and detailed guidance for Service life extension programs [[Acronyms|(SLEP)]]. The Office of the Under Secretary of Defense (AT&L) provides an on-line reference for policies, procedures, planning guidance, and whitepapers for military product service life extension (DAU 2011). Continuous military system modernization is a process by which state of the art technologies are inserted continuously into weapon systems to increase reliability, lower sustainment costs, and increase the war fighting capability of a military system to meet evolving customer requirements throughout an indefinite service life. <br />
<br />
Aircraft service life can be extended by reducing the dynamic loads which lead to structural fatigue. The Boeing B-52 military aircraft and the Boeing 737 commercial aircraft are prime examples of system life extension. The B-52 was first fielded in 1955 and the Boeing 737 has been fielded since 1967; both aircraft are still in use today.<br />
<br />
For nuclear reactors, system safety is the most important precondition for service life extension. The system safety must be maintained while extending the service life (Paks 2010). Built-in tests, automated fault reporting and prognostics, analysis of failure modes, and the detection of early signs of wear and aging may be applied to predict the time when maintenance actions will be required to extend the service life of the product.<br />
<br />
==Application to Service Systems==<br />
<br />
For systems that provide services to a larger consumer base, service life extension involves continued delivery of the service without disrupting consumer use. Service life extension involves capital investment and financial planning, as well as a phased deployment of changes. Examples of these concepts can be seen in transportation systems, water treatment facilities, energy generation and delivery systems, and the health care industry. <br />
<br />
As new technologies are introduced, service delivery can be improved while reducing life cycle costs. Service systems have to continuously assess delivery costs based upon the use of newer technologies. <br />
<br />
Water handling systems provide a good example of a service system that undergoes life extension. Water handling systems have been in existence since early civilization. Since water handling systems are in use as long as a site is occupied (e.g., the Roman aqueducts), and upgrades are required as the population expands, such systems are a good example of "systems that live forever." For example, there are still U.S. water systems that use a few wooden pipes since there has been no reason to replace them. Water system life extension must deal with the issue of water quality and the capacity for future users (Mays, 2000). Water quality requirements can be further understood from the AWWA Manuals of Water Supply Practices (AWWA 2010).<br />
<br />
==Application to Enterprises==<br />
Service life extension of a large enterprise, such as NASA’s national space transportation system, involves service life extension on the elements of the enterprise, such as the space vehicle (shuttle), ground processing systems for launch operations and mission control, and space-based communication systems that support space vehicle tracking and status monitoring. Service life extension of an enterprise requires a [[holism (glossary)|holistic (glossary)]] look across the entire enterprise. A balanced approach is required to address the cost of operating older system components versus the cost required to implement service life improvements.<br />
<br />
Large enterprise systems, such as oil and natural gas reservoirs, which span broad geographical areas, can use advanced technology to increase their service life. The economic extraction of oil and natural gas resources from previously established reservoirs can extend their system life. One such life extension method is to pump special liquids or gases into the reservoir to push the remaining oil or natural gas to the surface for extraction (Office of Natural Gas & Oil Technology 1999).<br />
<br />
==Other Topics==<br />
<br />
Commercial product developers have been required to retain information for extended periods of time after the last operational product or unit leaves active service (for up to twenty years). Regulatory requirements should be considered when extending service life (INCOSE 2011).<br />
<br />
==Practical Considerations==<br />
The cost associated with life extension is one of the main inputs in the decision to extend service life of a product or a service. It is often the case that the funding required for service life extension of large complex systems is spread over several fiscal planning cycles and is therefore subject to changes in attitude by the elected officials that appropriate the funding.<br />
<br />
==References== <br />
<br />
<br />
===Works Cited===<br />
<br />
AWWA. 2010. “AWWA Manuals of Water Supply Practices.” In American Water Works Association (AWWA). Denver, CO.Accessed August 5, 2010. Available at: http://www.awwa.org/Resources/standards.cfm?ItemNumber=47829&navItemNumber=47834.<br />
<br />
Blanchard, B. S., and W. J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Brown, M., R. Weyers, and M. Sprinkel. 2006. “Service Life Extension of Virginia Bridge Decks afforded by Epoxy-Coated Reinforcement.” ''Journal of ASTM International (JAI),'' 3(2): 13. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
Office of Natural Gas and Oil Technology. 1999. ''Reservoir LIFE Extension Program: Encouraging Production of Remaining Oil and Gas.'' Washington, DC, USA: U.S. Department of Engery (DoE). <br />
<br />
Paks Nuclear Power Plant. 2010. “Paks Nuclear Power Plant: Service Life Extension.” In Paks Nuclear Power Plant, Ltd.. Hungary, accessed August 5, 2010. Available at: http://paksnuclearpowerplant.com/service-life-extension.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R. C., D. Plakosh, and G. A. Lewis. 2003. ''[[Modernizing Legacy Systems]]''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
<br />
AWWA. 2010. “AWWA Manuals of Water Supply Practices.” In American Water Works Association (AWWA). Denver, CO.Accessed August 5, 2010. Available at: http://www.awwa.org/Resources/standards.cfm?ItemNumber=47829&navItemNumber=47834.<br />
<br />
Blanchard, B.S. 2010. ''Logistics engineering and management'', 5th ed. Englewood Cliffs, NJ, USA: Prentice Hall, 341-342.<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Brown, M., R. Weyers, and M. Sprinkel. 2006. “Service Life Extension of Virginia Bridge Decks afforded by Epoxy-Coated Reinforcement.” ''Journal of ASTM International (JAI),'' 3(2): 13. <br />
<br />
Caltrans and USDOT. 2005. ''Systems engineering guidebook for ITS,'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research & Innovation/U.S. Department of Transportation (USDOT), SEG for ITS 1.1: 278, 101-103, 107.<br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
DLA. 2010. “Defense logistics agency disposition services.” In Defense Logistics Agency (DLA)/U.S. Department of Defense [database online]. Battle Creek, MI, USA, accessed June 19 2010: 5. Available at: http://www.dtc.dla.mil.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B., and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
Gehring, G., D. Lindemuth, and W.T. Young. 2004. “Break Reduction/Life extension Program for CAST and Ductile Iron Water Mains.” Paper presented at NO-DIG 2004, Conference of the North American Society for Trenchless Technology (NASTT), March 22-24, New Orleans, LA, USA. <br />
<br />
Hovinga, M.N., and G.J. Nakoneczny. 2000. “Standard Recommendations for Pressure Part Inspection during a Boiler Life Extension Program.” Paper presented at ICOLM (International Conference on Life Management and Life Extension of Power Plant), May, Xi’an, P.R. China. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
ISO/IEC 2008. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.<br />
<br />
IEEE. 2010. IEEE Standard Framework for Reliability Prediction of Hardware. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
Ihii, K., C.F. Eubanks, and P. Di Marco. 1994. “Design for Product Retirement and Material Life-Cycle.” ''Materials & Design'' 15(4): 225-33. <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Factilies.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
ISO/IEC. 1997. “Systems Engineering for Commercial Aircraft.” Surrey, UK: Ashgate Publishing Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
L3 Communications. 2010. “Service Life Extension Program (SLEP).” Newport News, VA, USA: L3 Communications, Flight International Aviation LLC. <br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Office of Natural Gas and Oil Technology. 1999. ''Reservoir LIFE Extension Program: Encouraging Production of Remaining Oil and Gas.'' Washington, DC, USA: U.S. Department of Engery (DoE). <br />
<br />
Paks Nuclear Power Plant. 2010. “Paks Nuclear Power Plant: Service Life Extension.” In Paks Nuclear Power Plant, Ltd.. Hungary, accessed August 5, 2010. Available at: http://paksnuclearpowerplant.com/service-life-extension.<br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
Sukamto, S. 2003. “Plant Aging and Life Extension Program at Arun LNG Plant Lhokseumawe, North Aceh, Indonesia.” Paper presented at 22nd Annual World Gas Conference, June 1-5, Tokyo, Japan.<br />
<br />
----<br />
<center>[[Product and Service Life Management|< Previous Article]] | [[Product and Service Life Management|Parent Article]] | [[Capability Updates, Upgrades, and Modernization|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]</div>Bwellshttps://sebokwiki.org/w/index.php?title=Deploying,_Using,_and_Sustaining_Systems_to_Solve_Problems&diff=35734Deploying, Using, and Sustaining Systems to Solve Problems2012-07-03T15:25:00Z<p>Bwells: /* Disposal */</p>
<hr />
<div>This article considers the activities of the [[Systems Approach (glossary)|systems approach]] related to the deployment, sustainment, and use of a solution. Any of the activities described below may need to be considered [[concurrently (glossary)]] with the other activities in the systems approach. The final article in this knowledge area, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elements of systems engineering (SE).<br />
<br />
Part 3 of the SEBoK provides two additional knowledge areas that provide the engineering aspects of these steps of the systems approach. In knowledge area [[Product and Service Life Management]] and [[System Deployment and Use]] Part 3 explains the systems engineering aspects of deployment, operation, maintenance, logistics, service life extension, updates, upgrades, disposal and retirement of systems.<br />
<br />
A systems approach considers the total system and the total lifecycle of the system. All aspects of the system and the system through all time until the day users depose of the system and the external enterprises complete the handling of the disposed system products. Creation of the system is rarely the step that solves the stakeholder’s problems. It is the use of the system solution that solves the problem. So from this perspective the deployment, use and sustainment of the system are important concepts that must be a part of the systems approach.<br />
<br />
Engineered systems are eventually owned by an individual, team, or enterprise. Those who own the system during development may not be the ones who own the system when it is in operation. Moreover, the owners may not be the users; e.g., service systems may be used by the general public but owned by a specific business that is offering the service. The transition of a system from development to operations is often itself a complex task, involving such activities as training those who will operate the system, legal actions to complete the transfer, and establishing logistical arrangements so that the operators can keep the system running once the transition is completed.<br />
<br />
A complete systems approach must also consider the many enterprises involved in the system from initial conception through the completion of the disposal process. These enterprises are all stakeholders with requirements and they all have interfaces that must be considered as part of a total systems approach.<br />
<br />
There is very little in the literature pertaining to the application of the systems approach to these phases of the life cycle. However, a basic premise of this knowledge area is that the systems approach pertains to all phases of a system’s life cycle. Hence, to properly build systems to solve problems or for other uses, it can be inferred that the systems approach pertains to the deployment, use, and the sustainment of the systems. Many of the available references in this topic area are from SE literature rather than from literature associated with the systems approach so the reader should also see Part 3 of the SEBoK. <br />
<br />
===Deployment: the Transition from Development to Operation===<br />
<br />
Transferring custody of the system of interest (SoI), and responsibility for its support from one organization to another occurs during deployment and is often called transition (INCOSE 2011). Transition of a [[Product System (glossary)|product system (glossary)]] includes the integration of the system into the acquiring organization's infrastructure. Deployment and transistion must consider the activity of moving the system from the development to the operational locations along with the support systems necessary to accomplish the relocation.<br />
<br />
Transition includes the initial installation of a system while ensuring that it is compatible with the wider system and does not cause any significant wider system issues. This process of acceptance and release for use varies between domains and across businesses and enterprises and can be thought of as an initial assessment of the system’s [[Effectiveness (glossary)|effectiveness (glossary]] (Hitchins 2007). Generally, transition may be considered to have two parts: (1) ensuring that the new system [[Interoperability (glossary)|interoperates (glossary)]] with the systems around it and (2) ensuring the resulting system is safe and has other critical operational properties. <br />
<br />
It is particularly important to have considered [[Emergent Property (glossary)|emergent properties (glossary)]] when a new system is added to the existing organization's [[System of Systems (SoS) (glossary)|system of systems (SoS) (glossary)]] network, as well as the [[Complexity (glossary)|complexity (glossary)]] of the organization into which the new system is transitioned (see also [[Complexity]]). The more complex the receiving organization is, the more challenging the transition will be, and the greater the likelihood of unintended interactions and consequences from the new system's insertion. Dealing with the consequences of this complexity starts in transition and continues into operation, maintenance, and disposal. <br />
<br />
Transition of a [[Service System (glossary)|service system (glossary)]] is often performed in two stages. First, the service system infrastructure is accepted and released. Second, each realization of the service is accepted and released. There can be significant problems during the second stage if the required responsiveness of the service does not leave sufficient time to ensure that the service meets necessary functional and quality attributes, including interoperability, safety, and security. (See [[Service Systems Engineering]]).<br />
<br />
Transition and deployment of a system may introduce unique requirements that are not necessary for operation or use. These requirements can drive the design of the system and therefore, must be considered during the initial requirements and design stages. The most common examples are related to the need to transport the system or system elements, which often limits the size and weight of the system elements.<br />
<br />
Transition can also require its own [[Enabling System (glossary)|enabling systems (glossary)]], each of which can be realized using a systems approach.<br />
<br />
===Use: Operation===<br />
<br />
Use of the system to help enable delivery of user services is often called “operations” (INCOSE 2011). A system’s effectiveness is normally considered throughout the operational life of a system. For a complex system, [[Emergence (glossary)|emergent behavior (glossary)]] should be considered in three ways:<br />
#to identify and plan for emergent properties within the system realization process;<br />
#to incorporate mechanisms for identifying and handling unexpected emergent properties within the system during its use; and<br />
#to provide necessary procedures for dealing with wider system consequences of unexpected emergent properties in the enterprise; e.g., emergency responses or medical first aid.<br />
<br />
Operations require their own enabling systems, each of which can be realized using a systems approach.<br />
<br />
===System Sustainment and Maintenance===<br />
<br />
System sustainment requires maintenance of the system through its useful life (INCOSE 2011). In system terms, maintenance implements systems to deal with [[Entropy (glossary)|entropy (glossary)]] and maintaining the system of interest in a [[viable (glossary)]] state. Since an [[Open System (glossary)|open system (glossary)]] maintains its existence by continual exchange of energy, information, and materiel with its environment, one aspect of its maintenance must be the management of resources in the environment. <br />
<br />
Hitchins (2007) describes generic approaches to resource management and viability management based on system concepts. Resource management identifies the need to consider the acquisition, storage, distribution, conversion, and disposal of resources. Viability management should consider systems to maintain [[Homeostasis (glossary)|homeostasis (glossary)]] and means for ensuring [[Resilience (glossary)|resilience (glossary)]] to environmental disturbance and [[Adaptability (glossary)|adaptability (glossary)]] to environmental change.<br />
<br />
Maintenance will require its own enabling systems, each of which can be realized using a systems approach. Maintenance success is more likely if it is considered as part of the system concept and design well before the system enters service.<br />
<br />
===Disposal===<br />
<br />
A total lifecycle systems approach cannot be considered complete without consideration of how disposal of the system will be accomplished. The purpose of disposal is to remove a system element from the operational environment with the intent of permanently terminating its use, and to deal with any hazardous or toxic materials or waste products (INCOSE 2011).<br />
<br />
During disposal the entirety of the open system (glossary) crosses the boundary from the system side to the environment. A complete systems approach must consider how it crosses the boundary and what remains that must be managed by enterprises other than the ones that developed, used or sustained the system. Including disposal in the system approach expands the stakeholders, the enterprises and the external systems that must be considered.<br />
<br />
Disposal requires its own enabling systems, each of which can be realized using a systems approach. Some of these may be contained within the system boundaries and others may be external to the system. For the external disposal systems the interface where the handover occurs must be considered. As with maintenance, a large part of successful disposal requires related issues to have been considered early on in the system’s life cycle.<br />
<br />
SEBoK Part 3 [[Disposal and Retirement]] provides information on the engineering aspects of system disposal.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley and Sons.<br />
<br />
INCOSE. 2011. ''INCOSE Systems Engineering Handbook'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications, Kings College.<br />
<br />
===Primary References===<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Implementing and Proving a Solution|< Previous Article]] | [[Systems Approach Applied to Engineered Systems|Parent Article]] | [[Stakeholder Responsibility|Next Article >]]</center><br />
<br />
<br />
==Comments from SEBoK 0.5 Wiki==<br />
Please note that in version 0.5, this article was titled “Owning and Making Use of a System”.<br />
<br />
<html><br />
<iframe src="http://www.sebokwiki.org/05/index.php?title=Talk:Owning_and_Making_Use_of_a_System&printable=yes" width=825 height=200 frameborder=1 scrolling=auto><br />
</iframe><br />
</html><br />
<br />
{{DISQUS}}<br />
<br />
<br />
<br />
[[Category:Part 2]][[Category:Topic]][[Category:Systems Approach Applied to Engineered Systems]]</div>Bwellshttps://sebokwiki.org/w/index.php?title=Deploying,_Using,_and_Sustaining_Systems_to_Solve_Problems&diff=35733Deploying, Using, and Sustaining Systems to Solve Problems2012-07-03T15:24:32Z<p>Bwells: /* Disposal */</p>
<hr />
<div>This article considers the activities of the [[Systems Approach (glossary)|systems approach]] related to the deployment, sustainment, and use of a solution. Any of the activities described below may need to be considered [[concurrently (glossary)]] with the other activities in the systems approach. The final article in this knowledge area, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elements of systems engineering (SE).<br />
<br />
Part 3 of the SEBoK provides two additional knowledge areas that provide the engineering aspects of these steps of the systems approach. In knowledge area [[Product and Service Life Management]] and [[System Deployment and Use]] Part 3 explains the systems engineering aspects of deployment, operation, maintenance, logistics, service life extension, updates, upgrades, disposal and retirement of systems.<br />
<br />
A systems approach considers the total system and the total lifecycle of the system. All aspects of the system and the system through all time until the day users depose of the system and the external enterprises complete the handling of the disposed system products. Creation of the system is rarely the step that solves the stakeholder’s problems. It is the use of the system solution that solves the problem. So from this perspective the deployment, use and sustainment of the system are important concepts that must be a part of the systems approach.<br />
<br />
Engineered systems are eventually owned by an individual, team, or enterprise. Those who own the system during development may not be the ones who own the system when it is in operation. Moreover, the owners may not be the users; e.g., service systems may be used by the general public but owned by a specific business that is offering the service. The transition of a system from development to operations is often itself a complex task, involving such activities as training those who will operate the system, legal actions to complete the transfer, and establishing logistical arrangements so that the operators can keep the system running once the transition is completed.<br />
<br />
A complete systems approach must also consider the many enterprises involved in the system from initial conception through the completion of the disposal process. These enterprises are all stakeholders with requirements and they all have interfaces that must be considered as part of a total systems approach.<br />
<br />
There is very little in the literature pertaining to the application of the systems approach to these phases of the life cycle. However, a basic premise of this knowledge area is that the systems approach pertains to all phases of a system’s life cycle. Hence, to properly build systems to solve problems or for other uses, it can be inferred that the systems approach pertains to the deployment, use, and the sustainment of the systems. Many of the available references in this topic area are from SE literature rather than from literature associated with the systems approach so the reader should also see Part 3 of the SEBoK. <br />
<br />
===Deployment: the Transition from Development to Operation===<br />
<br />
Transferring custody of the system of interest (SoI), and responsibility for its support from one organization to another occurs during deployment and is often called transition (INCOSE 2011). Transition of a [[Product System (glossary)|product system (glossary)]] includes the integration of the system into the acquiring organization's infrastructure. Deployment and transistion must consider the activity of moving the system from the development to the operational locations along with the support systems necessary to accomplish the relocation.<br />
<br />
Transition includes the initial installation of a system while ensuring that it is compatible with the wider system and does not cause any significant wider system issues. This process of acceptance and release for use varies between domains and across businesses and enterprises and can be thought of as an initial assessment of the system’s [[Effectiveness (glossary)|effectiveness (glossary]] (Hitchins 2007). Generally, transition may be considered to have two parts: (1) ensuring that the new system [[Interoperability (glossary)|interoperates (glossary)]] with the systems around it and (2) ensuring the resulting system is safe and has other critical operational properties. <br />
<br />
It is particularly important to have considered [[Emergent Property (glossary)|emergent properties (glossary)]] when a new system is added to the existing organization's [[System of Systems (SoS) (glossary)|system of systems (SoS) (glossary)]] network, as well as the [[Complexity (glossary)|complexity (glossary)]] of the organization into which the new system is transitioned (see also [[Complexity]]). The more complex the receiving organization is, the more challenging the transition will be, and the greater the likelihood of unintended interactions and consequences from the new system's insertion. Dealing with the consequences of this complexity starts in transition and continues into operation, maintenance, and disposal. <br />
<br />
Transition of a [[Service System (glossary)|service system (glossary)]] is often performed in two stages. First, the service system infrastructure is accepted and released. Second, each realization of the service is accepted and released. There can be significant problems during the second stage if the required responsiveness of the service does not leave sufficient time to ensure that the service meets necessary functional and quality attributes, including interoperability, safety, and security. (See [[Service Systems Engineering]]).<br />
<br />
Transition and deployment of a system may introduce unique requirements that are not necessary for operation or use. These requirements can drive the design of the system and therefore, must be considered during the initial requirements and design stages. The most common examples are related to the need to transport the system or system elements, which often limits the size and weight of the system elements.<br />
<br />
Transition can also require its own [[Enabling System (glossary)|enabling systems (glossary)]], each of which can be realized using a systems approach.<br />
<br />
===Use: Operation===<br />
<br />
Use of the system to help enable delivery of user services is often called “operations” (INCOSE 2011). A system’s effectiveness is normally considered throughout the operational life of a system. For a complex system, [[Emergence (glossary)|emergent behavior (glossary)]] should be considered in three ways:<br />
#to identify and plan for emergent properties within the system realization process;<br />
#to incorporate mechanisms for identifying and handling unexpected emergent properties within the system during its use; and<br />
#to provide necessary procedures for dealing with wider system consequences of unexpected emergent properties in the enterprise; e.g., emergency responses or medical first aid.<br />
<br />
Operations require their own enabling systems, each of which can be realized using a systems approach.<br />
<br />
===System Sustainment and Maintenance===<br />
<br />
System sustainment requires maintenance of the system through its useful life (INCOSE 2011). In system terms, maintenance implements systems to deal with [[Entropy (glossary)|entropy (glossary)]] and maintaining the system of interest in a [[viable (glossary)]] state. Since an [[Open System (glossary)|open system (glossary)]] maintains its existence by continual exchange of energy, information, and materiel with its environment, one aspect of its maintenance must be the management of resources in the environment. <br />
<br />
Hitchins (2007) describes generic approaches to resource management and viability management based on system concepts. Resource management identifies the need to consider the acquisition, storage, distribution, conversion, and disposal of resources. Viability management should consider systems to maintain [[Homeostasis (glossary)|homeostasis (glossary)]] and means for ensuring [[Resilience (glossary)|resilience (glossary)]] to environmental disturbance and [[Adaptability (glossary)|adaptability (glossary)]] to environmental change.<br />
<br />
Maintenance will require its own enabling systems, each of which can be realized using a systems approach. Maintenance success is more likely if it is considered as part of the system concept and design well before the system enters service.<br />
<br />
===Disposal===<br />
<br />
A total lifecycle systems approach cannot be considered complete without consideration of how disposal of the system will be accomplished. The purpose of disposal is to remove a system element from the operational environment with the intent of permanently terminating its use, and to deal with any hazardous or toxic materials or waste products (INCOSE 2011).<br />
<br />
During disposal the entirety of the open system (glossary) crosses the boundary from the system side to the environment. A complete systems approach must consider how it crosses the boundary and what remains that must be managed by enterprises other than the ones that developed, used or sustained the system. Including disposal in the system approach expands the stakeholders, the enterprises and the external systems that must be considered.<br />
<br />
Disposal requires its own enabling systems, each of which can be realized using a systems approach. Some of these may be contained within the system boundaries and others may be external to the system. For the external disposal systems the interface where the handover occurs must be considered. As with maintenance, a large part of successful disposal requires related issues to have been considered early on in the system’s life cycle.<br />
<br />
SEBoK Part 3 [[Disposal and Retirement]] provides the information on the engineering aspects of system disposal.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley and Sons.<br />
<br />
INCOSE. 2011. ''INCOSE Systems Engineering Handbook'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications, Kings College.<br />
<br />
===Primary References===<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Implementing and Proving a Solution|< Previous Article]] | [[Systems Approach Applied to Engineered Systems|Parent Article]] | [[Stakeholder Responsibility|Next Article >]]</center><br />
<br />
<br />
==Comments from SEBoK 0.5 Wiki==<br />
Please note that in version 0.5, this article was titled “Owning and Making Use of a System”.<br />
<br />
<html><br />
<iframe src="http://www.sebokwiki.org/05/index.php?title=Talk:Owning_and_Making_Use_of_a_System&printable=yes" width=825 height=200 frameborder=1 scrolling=auto><br />
</iframe><br />
</html><br />
<br />
{{DISQUS}}<br />
<br />
<br />
<br />
[[Category:Part 2]][[Category:Topic]][[Category:Systems Approach Applied to Engineered Systems]]</div>Bwellshttps://sebokwiki.org/w/index.php?title=Deploying,_Using,_and_Sustaining_Systems_to_Solve_Problems&diff=35732Deploying, Using, and Sustaining Systems to Solve Problems2012-07-03T15:23:03Z<p>Bwells: </p>
<hr />
<div>This article considers the activities of the [[Systems Approach (glossary)|systems approach]] related to the deployment, sustainment, and use of a solution. Any of the activities described below may need to be considered [[concurrently (glossary)]] with the other activities in the systems approach. The final article in this knowledge area, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elements of systems engineering (SE).<br />
<br />
Part 3 of the SEBoK provides two additional knowledge areas that provide the engineering aspects of these steps of the systems approach. In knowledge area [[Product and Service Life Management]] and [[System Deployment and Use]] Part 3 explains the systems engineering aspects of deployment, operation, maintenance, logistics, service life extension, updates, upgrades, disposal and retirement of systems.<br />
<br />
A systems approach considers the total system and the total lifecycle of the system. All aspects of the system and the system through all time until the day users depose of the system and the external enterprises complete the handling of the disposed system products. Creation of the system is rarely the step that solves the stakeholder’s problems. It is the use of the system solution that solves the problem. So from this perspective the deployment, use and sustainment of the system are important concepts that must be a part of the systems approach.<br />
<br />
Engineered systems are eventually owned by an individual, team, or enterprise. Those who own the system during development may not be the ones who own the system when it is in operation. Moreover, the owners may not be the users; e.g., service systems may be used by the general public but owned by a specific business that is offering the service. The transition of a system from development to operations is often itself a complex task, involving such activities as training those who will operate the system, legal actions to complete the transfer, and establishing logistical arrangements so that the operators can keep the system running once the transition is completed.<br />
<br />
A complete systems approach must also consider the many enterprises involved in the system from initial conception through the completion of the disposal process. These enterprises are all stakeholders with requirements and they all have interfaces that must be considered as part of a total systems approach.<br />
<br />
There is very little in the literature pertaining to the application of the systems approach to these phases of the life cycle. However, a basic premise of this knowledge area is that the systems approach pertains to all phases of a system’s life cycle. Hence, to properly build systems to solve problems or for other uses, it can be inferred that the systems approach pertains to the deployment, use, and the sustainment of the systems. Many of the available references in this topic area are from SE literature rather than from literature associated with the systems approach so the reader should also see Part 3 of the SEBoK. <br />
<br />
===Deployment: the Transition from Development to Operation===<br />
<br />
Transferring custody of the system of interest (SoI), and responsibility for its support from one organization to another occurs during deployment and is often called transition (INCOSE 2011). Transition of a [[Product System (glossary)|product system (glossary)]] includes the integration of the system into the acquiring organization's infrastructure. Deployment and transistion must consider the activity of moving the system from the development to the operational locations along with the support systems necessary to accomplish the relocation.<br />
<br />
Transition includes the initial installation of a system while ensuring that it is compatible with the wider system and does not cause any significant wider system issues. This process of acceptance and release for use varies between domains and across businesses and enterprises and can be thought of as an initial assessment of the system’s [[Effectiveness (glossary)|effectiveness (glossary]] (Hitchins 2007). Generally, transition may be considered to have two parts: (1) ensuring that the new system [[Interoperability (glossary)|interoperates (glossary)]] with the systems around it and (2) ensuring the resulting system is safe and has other critical operational properties. <br />
<br />
It is particularly important to have considered [[Emergent Property (glossary)|emergent properties (glossary)]] when a new system is added to the existing organization's [[System of Systems (SoS) (glossary)|system of systems (SoS) (glossary)]] network, as well as the [[Complexity (glossary)|complexity (glossary)]] of the organization into which the new system is transitioned (see also [[Complexity]]). The more complex the receiving organization is, the more challenging the transition will be, and the greater the likelihood of unintended interactions and consequences from the new system's insertion. Dealing with the consequences of this complexity starts in transition and continues into operation, maintenance, and disposal. <br />
<br />
Transition of a [[Service System (glossary)|service system (glossary)]] is often performed in two stages. First, the service system infrastructure is accepted and released. Second, each realization of the service is accepted and released. There can be significant problems during the second stage if the required responsiveness of the service does not leave sufficient time to ensure that the service meets necessary functional and quality attributes, including interoperability, safety, and security. (See [[Service Systems Engineering]]).<br />
<br />
Transition and deployment of a system may introduce unique requirements that are not necessary for operation or use. These requirements can drive the design of the system and therefore, must be considered during the initial requirements and design stages. The most common examples are related to the need to transport the system or system elements, which often limits the size and weight of the system elements.<br />
<br />
Transition can also require its own [[Enabling System (glossary)|enabling systems (glossary)]], each of which can be realized using a systems approach.<br />
<br />
===Use: Operation===<br />
<br />
Use of the system to help enable delivery of user services is often called “operations” (INCOSE 2011). A system’s effectiveness is normally considered throughout the operational life of a system. For a complex system, [[Emergence (glossary)|emergent behavior (glossary)]] should be considered in three ways:<br />
#to identify and plan for emergent properties within the system realization process;<br />
#to incorporate mechanisms for identifying and handling unexpected emergent properties within the system during its use; and<br />
#to provide necessary procedures for dealing with wider system consequences of unexpected emergent properties in the enterprise; e.g., emergency responses or medical first aid.<br />
<br />
Operations require their own enabling systems, each of which can be realized using a systems approach.<br />
<br />
===System Sustainment and Maintenance===<br />
<br />
System sustainment requires maintenance of the system through its useful life (INCOSE 2011). In system terms, maintenance implements systems to deal with [[Entropy (glossary)|entropy (glossary)]] and maintaining the system of interest in a [[viable (glossary)]] state. Since an [[Open System (glossary)|open system (glossary)]] maintains its existence by continual exchange of energy, information, and materiel with its environment, one aspect of its maintenance must be the management of resources in the environment. <br />
<br />
Hitchins (2007) describes generic approaches to resource management and viability management based on system concepts. Resource management identifies the need to consider the acquisition, storage, distribution, conversion, and disposal of resources. Viability management should consider systems to maintain [[Homeostasis (glossary)|homeostasis (glossary)]] and means for ensuring [[Resilience (glossary)|resilience (glossary)]] to environmental disturbance and [[Adaptability (glossary)|adaptability (glossary)]] to environmental change.<br />
<br />
Maintenance will require its own enabling systems, each of which can be realized using a systems approach. Maintenance success is more likely if it is considered as part of the system concept and design well before the system enters service.<br />
<br />
===Disposal===<br />
<br />
A total lifecycle systems approach cannot be considered complete without consideration of how disposal of the system will be accomplished. The purpose of disposal is to remove a system element from the operational environment with the intent of permanently terminating its use, and to deal with any hazardous or toxic materials or waste products (INCOSE 2011).<br />
<br />
During disposal the entirety of the open system (glossary) crosses the boundary from the system side to the environment. A complete systems approach must consider how it crosses the boundary and what remains that must be managed by enterprises other than the ones that developed, used or sustained the system. Including disposal in the system approach expands the stakeholders, the enterprises and the external systems that must be considered.<br />
<br />
Disposal requires its own enabling systems, each of which can be realized using a systems approach. Some of these may be contained within the system boundaries and others may be external to the system. For the external disposal systems the interface where the handover occurs must be considered. As with maintenance, a large part of successful disposal requires related issues to have been considered early on in the system’s life cycle.<br />
<br />
SEBoK Part 3 provides the information on the engineering aspects of system disposal.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley and Sons.<br />
<br />
INCOSE. 2011. ''INCOSE Systems Engineering Handbook'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications, Kings College.<br />
<br />
===Primary References===<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Implementing and Proving a Solution|< Previous Article]] | [[Systems Approach Applied to Engineered Systems|Parent Article]] | [[Stakeholder Responsibility|Next Article >]]</center><br />
<br />
<br />
==Comments from SEBoK 0.5 Wiki==<br />
Please note that in version 0.5, this article was titled “Owning and Making Use of a System”.<br />
<br />
<html><br />
<iframe src="http://www.sebokwiki.org/05/index.php?title=Talk:Owning_and_Making_Use_of_a_System&printable=yes" width=825 height=200 frameborder=1 scrolling=auto><br />
</iframe><br />
</html><br />
<br />
{{DISQUS}}<br />
<br />
<br />
<br />
[[Category:Part 2]][[Category:Topic]][[Category:Systems Approach Applied to Engineered Systems]]</div>Bwellshttps://sebokwiki.org/w/index.php?title=Deploying,_Using,_and_Sustaining_Systems_to_Solve_Problems&diff=35731Deploying, Using, and Sustaining Systems to Solve Problems2012-07-03T15:22:14Z<p>Bwells: </p>
<hr />
<div>This article considers the activities of the [[Systems Approach (glossary)|systems approach]] related to the deployment, sustainment, and use of a solution. Any of the activities described below may need to be considered [[concurrently (glossary)]] with the other activities in the systems approach. The final article in this knowledge area, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elements of systems engineering (SE).<br />
<br />
Part 3 of the SEBoK provides two additional knowledge areas that provide the engineering aspects of these steps of the systems approach. In knowledge area [[Product and Lifecycle Management]] and [[System Deployment and Use]] Part 3 explains the systems engineering aspects of deployment, operation, maintenance, logistics, service life extension, updates, upgrades, disposal and retirement of systems.<br />
<br />
A systems approach considers the total system and the total lifecycle of the system. All aspects of the system and the system through all time until the day users depose of the system and the external enterprises complete the handling of the disposed system products. Creation of the system is rarely the step that solves the stakeholder’s problems. It is the use of the system solution that solves the problem. So from this perspective the deployment, use and sustainment of the system are important concepts that must be a part of the systems approach.<br />
<br />
Engineered systems are eventually owned by an individual, team, or enterprise. Those who own the system during development may not be the ones who own the system when it is in operation. Moreover, the owners may not be the users; e.g., service systems may be used by the general public but owned by a specific business that is offering the service. The transition of a system from development to operations is often itself a complex task, involving such activities as training those who will operate the system, legal actions to complete the transfer, and establishing logistical arrangements so that the operators can keep the system running once the transition is completed.<br />
<br />
A complete systems approach must also consider the many enterprises involved in the system from initial conception through the completion of the disposal process. These enterprises are all stakeholders with requirements and they all have interfaces that must be considered as part of a total systems approach.<br />
<br />
There is very little in the literature pertaining to the application of the systems approach to these phases of the life cycle. However, a basic premise of this knowledge area is that the systems approach pertains to all phases of a system’s life cycle. Hence, to properly build systems to solve problems or for other uses, it can be inferred that the systems approach pertains to the deployment, use, and the sustainment of the systems. Many of the available references in this topic area are from SE literature rather than from literature associated with the systems approach so the reader should also see Part 3 of the SEBoK. <br />
<br />
===Deployment: the Transition from Development to Operation===<br />
<br />
Transferring custody of the system of interest (SoI), and responsibility for its support from one organization to another occurs during deployment and is often called transition (INCOSE 2011). Transition of a [[Product System (glossary)|product system (glossary)]] includes the integration of the system into the acquiring organization's infrastructure. Deployment and transistion must consider the activity of moving the system from the development to the operational locations along with the support systems necessary to accomplish the relocation.<br />
<br />
Transition includes the initial installation of a system while ensuring that it is compatible with the wider system and does not cause any significant wider system issues. This process of acceptance and release for use varies between domains and across businesses and enterprises and can be thought of as an initial assessment of the system’s [[Effectiveness (glossary)|effectiveness (glossary]] (Hitchins 2007). Generally, transition may be considered to have two parts: (1) ensuring that the new system [[Interoperability (glossary)|interoperates (glossary)]] with the systems around it and (2) ensuring the resulting system is safe and has other critical operational properties. <br />
<br />
It is particularly important to have considered [[Emergent Property (glossary)|emergent properties (glossary)]] when a new system is added to the existing organization's [[System of Systems (SoS) (glossary)|system of systems (SoS) (glossary)]] network, as well as the [[Complexity (glossary)|complexity (glossary)]] of the organization into which the new system is transitioned (see also [[Complexity]]). The more complex the receiving organization is, the more challenging the transition will be, and the greater the likelihood of unintended interactions and consequences from the new system's insertion. Dealing with the consequences of this complexity starts in transition and continues into operation, maintenance, and disposal. <br />
<br />
Transition of a [[Service System (glossary)|service system (glossary)]] is often performed in two stages. First, the service system infrastructure is accepted and released. Second, each realization of the service is accepted and released. There can be significant problems during the second stage if the required responsiveness of the service does not leave sufficient time to ensure that the service meets necessary functional and quality attributes, including interoperability, safety, and security. (See [[Service Systems Engineering]]).<br />
<br />
Transition and deployment of a system may introduce unique requirements that are not necessary for operation or use. These requirements can drive the design of the system and therefore, must be considered during the initial requirements and design stages. The most common examples are related to the need to transport the system or system elements, which often limits the size and weight of the system elements.<br />
<br />
Transition can also require its own [[Enabling System (glossary)|enabling systems (glossary)]], each of which can be realized using a systems approach.<br />
<br />
===Use: Operation===<br />
<br />
Use of the system to help enable delivery of user services is often called “operations” (INCOSE 2011). A system’s effectiveness is normally considered throughout the operational life of a system. For a complex system, [[Emergence (glossary)|emergent behavior (glossary)]] should be considered in three ways:<br />
#to identify and plan for emergent properties within the system realization process;<br />
#to incorporate mechanisms for identifying and handling unexpected emergent properties within the system during its use; and<br />
#to provide necessary procedures for dealing with wider system consequences of unexpected emergent properties in the enterprise; e.g., emergency responses or medical first aid.<br />
<br />
Operations require their own enabling systems, each of which can be realized using a systems approach.<br />
<br />
===System Sustainment and Maintenance===<br />
<br />
System sustainment requires maintenance of the system through its useful life (INCOSE 2011). In system terms, maintenance implements systems to deal with [[Entropy (glossary)|entropy (glossary)]] and maintaining the system of interest in a [[viable (glossary)]] state. Since an [[Open System (glossary)|open system (glossary)]] maintains its existence by continual exchange of energy, information, and materiel with its environment, one aspect of its maintenance must be the management of resources in the environment. <br />
<br />
Hitchins (2007) describes generic approaches to resource management and viability management based on system concepts. Resource management identifies the need to consider the acquisition, storage, distribution, conversion, and disposal of resources. Viability management should consider systems to maintain [[Homeostasis (glossary)|homeostasis (glossary)]] and means for ensuring [[Resilience (glossary)|resilience (glossary)]] to environmental disturbance and [[Adaptability (glossary)|adaptability (glossary)]] to environmental change.<br />
<br />
Maintenance will require its own enabling systems, each of which can be realized using a systems approach. Maintenance success is more likely if it is considered as part of the system concept and design well before the system enters service.<br />
<br />
===Disposal===<br />
<br />
A total lifecycle systems approach cannot be considered complete without consideration of how disposal of the system will be accomplished. The purpose of disposal is to remove a system element from the operational environment with the intent of permanently terminating its use, and to deal with any hazardous or toxic materials or waste products (INCOSE 2011).<br />
<br />
During disposal the entirety of the open system (glossary) crosses the boundary from the system side to the environment. A complete systems approach must consider how it crosses the boundary and what remains that must be managed by enterprises other than the ones that developed, used or sustained the system. Including disposal in the system approach expands the stakeholders, the enterprises and the external systems that must be considered.<br />
<br />
Disposal requires its own enabling systems, each of which can be realized using a systems approach. Some of these may be contained within the system boundaries and others may be external to the system. For the external disposal systems the interface where the handover occurs must be considered. As with maintenance, a large part of successful disposal requires related issues to have been considered early on in the system’s life cycle.<br />
<br />
SEBoK Part 3 provides the information on the engineering aspects of system disposal.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley and Sons.<br />
<br />
INCOSE. 2011. ''INCOSE Systems Engineering Handbook'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications, Kings College.<br />
<br />
===Primary References===<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Implementing and Proving a Solution|< Previous Article]] | [[Systems Approach Applied to Engineered Systems|Parent Article]] | [[Stakeholder Responsibility|Next Article >]]</center><br />
<br />
<br />
==Comments from SEBoK 0.5 Wiki==<br />
Please note that in version 0.5, this article was titled “Owning and Making Use of a System”.<br />
<br />
<html><br />
<iframe src="http://www.sebokwiki.org/05/index.php?title=Talk:Owning_and_Making_Use_of_a_System&printable=yes" width=825 height=200 frameborder=1 scrolling=auto><br />
</iframe><br />
</html><br />
<br />
{{DISQUS}}<br />
<br />
<br />
<br />
[[Category:Part 2]][[Category:Topic]][[Category:Systems Approach Applied to Engineered Systems]]</div>Bwellshttps://sebokwiki.org/w/index.php?title=Deploying,_Using,_and_Sustaining_Systems_to_Solve_Problems&diff=35730Deploying, Using, and Sustaining Systems to Solve Problems2012-07-03T15:19:24Z<p>Bwells: </p>
<hr />
<div>This article considers the activities of the [[Systems Approach (glossary)|systems approach]] related to the deployment, sustainment, and use of a solution. Any of the activities described below may need to be considered [[concurrently (glossary)]] with the other activities in the systems approach. The final article in this knowledge area, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elements of systems engineering (SE).<br />
<br />
Part 3 of the SEBoK provides two additional knowledge areas that provide the engineering aspects of these steps of the systems approach. In knowledge area Product and Lifecycle Management and System Deployment and Use Part 3 explains the systems engineering aspects of deployment, operation, maintenance, logistics, service life extension, updates, upgrades, disposal and retirement of systems.<br />
<br />
A systems approach considers the total system and the total lifecycle of the system. All aspects of the system and the system through all time until the day users depose of the system and the external enterprises complete the handling of the disposed system products. Creation of the system is rarely the step that solves the stakeholder’s problems. It is the use of the system solution that solves the problem. So from this perspective the deployment, use and sustainment of the system are important concepts that must be a part of the systems approach.<br />
<br />
Engineered systems are eventually owned by an individual, team, or enterprise. Those who own the system during development may not be the ones who own the system when it is in operation. Moreover, the owners may not be the users; e.g., service systems may be used by the general public but owned by a specific business that is offering the service. The transition of a system from development to operations is often itself a complex task, involving such activities as training those who will operate the system, legal actions to complete the transfer, and establishing logistical arrangements so that the operators can keep the system running once the transition is completed.<br />
<br />
A complete systems approach must also consider the many enterprises involved in the system from initial conception through the completion of the disposal process. These enterprises are all stakeholders with requirements and they all have interfaces that must be considered as part of a total systems approach.<br />
<br />
There is very little in the literature pertaining to the application of the systems approach to these phases of the life cycle. However, a basic premise of this knowledge area is that the systems approach pertains to all phases of a system’s life cycle. Hence, to properly build systems to solve problems or for other uses, it can be inferred that the systems approach pertains to the deployment, use, and the sustainment of the systems. Many of the available references in this topic area are from SE literature rather than from literature associated with the systems approach so the reader should also see Part 3 of the SEBoK. <br />
<br />
===Deployment: the Transition from Development to Operation===<br />
<br />
Transferring custody of the system of interest (SoI), and responsibility for its support from one organization to another occurs during deployment and is often called transition (INCOSE 2011). Transition of a [[Product System (glossary)|product system (glossary)]] includes the integration of the system into the acquiring organization's infrastructure. Deployment and transistion must consider the activity of moving the system from the development to the operational locations along with the support systems necessary to accomplish the relocation.<br />
<br />
Transition includes the initial installation of a system while ensuring that it is compatible with the wider system and does not cause any significant wider system issues. This process of acceptance and release for use varies between domains and across businesses and enterprises and can be thought of as an initial assessment of the system’s [[Effectiveness (glossary)|effectiveness (glossary]] (Hitchins 2007). Generally, transition may be considered to have two parts: (1) ensuring that the new system [[Interoperability (glossary)|interoperates (glossary)]] with the systems around it and (2) ensuring the resulting system is safe and has other critical operational properties. <br />
<br />
It is particularly important to have considered [[Emergent Property (glossary)|emergent properties (glossary)]] when a new system is added to the existing organization's [[System of Systems (SoS) (glossary)|system of systems (SoS) (glossary)]] network, as well as the [[Complexity (glossary)|complexity (glossary)]] of the organization into which the new system is transitioned (see also [[Complexity]]). The more complex the receiving organization is, the more challenging the transition will be, and the greater the likelihood of unintended interactions and consequences from the new system's insertion. Dealing with the consequences of this complexity starts in transition and continues into operation, maintenance, and disposal. <br />
<br />
Transition of a [[Service System (glossary)|service system (glossary)]] is often performed in two stages. First, the service system infrastructure is accepted and released. Second, each realization of the service is accepted and released. There can be significant problems during the second stage if the required responsiveness of the service does not leave sufficient time to ensure that the service meets necessary functional and quality attributes, including interoperability, safety, and security. (See [[Service Systems Engineering]]).<br />
<br />
Transition and deployment of a system may introduce unique requirements that are not necessary for operation or use. These requirements can drive the design of the system and therefore, must be considered during the initial requirements and design stages. The most common examples are related to the need to transport the system or system elements, which often limits the size and weight of the system elements.<br />
<br />
Transition can also require its own [[Enabling System (glossary)|enabling systems (glossary)]], each of which can be realized using a systems approach.<br />
<br />
===Use: Operation===<br />
<br />
Use of the system to help enable delivery of user services is often called “operations” (INCOSE 2011). A system’s effectiveness is normally considered throughout the operational life of a system. For a complex system, [[Emergence (glossary)|emergent behavior (glossary)]] should be considered in three ways:<br />
#to identify and plan for emergent properties within the system realization process;<br />
#to incorporate mechanisms for identifying and handling unexpected emergent properties within the system during its use; and<br />
#to provide necessary procedures for dealing with wider system consequences of unexpected emergent properties in the enterprise; e.g., emergency responses or medical first aid.<br />
<br />
Operations require their own enabling systems, each of which can be realized using a systems approach.<br />
<br />
===System Sustainment and Maintenance===<br />
<br />
System sustainment requires maintenance of the system through its useful life (INCOSE 2011). In system terms, maintenance implements systems to deal with [[Entropy (glossary)|entropy (glossary)]] and maintaining the system of interest in a [[viable (glossary)]] state. Since an [[Open System (glossary)|open system (glossary)]] maintains its existence by continual exchange of energy, information, and materiel with its environment, one aspect of its maintenance must be the management of resources in the environment. <br />
<br />
Hitchins (2007) describes generic approaches to resource management and viability management based on system concepts. Resource management identifies the need to consider the acquisition, storage, distribution, conversion, and disposal of resources. Viability management should consider systems to maintain [[Homeostasis (glossary)|homeostasis (glossary)]] and means for ensuring [[Resilience (glossary)|resilience (glossary)]] to environmental disturbance and [[Adaptability (glossary)|adaptability (glossary)]] to environmental change.<br />
<br />
Maintenance will require its own enabling systems, each of which can be realized using a systems approach. Maintenance success is more likely if it is considered as part of the system concept and design well before the system enters service.<br />
<br />
===Disposal===<br />
<br />
A total lifecycle systems approach cannot be considered complete without consideration of how disposal of the system will be accomplished. The purpose of disposal is to remove a system element from the operational environment with the intent of permanently terminating its use, and to deal with any hazardous or toxic materials or waste products (INCOSE 2011).<br />
<br />
During disposal the entirety of the open system (glossary) crosses the boundary from the system side to the environment. A complete systems approach must consider how it crosses the boundary and what remains that must be managed by enterprises other than the ones that developed, used or sustained the system. Including disposal in the system approach expands the stakeholders, the enterprises and the external systems that must be considered.<br />
<br />
Disposal requires its own enabling systems, each of which can be realized using a systems approach. Some of these may be contained within the system boundaries and others may be external to the system. For the external disposal systems the interface where the handover occurs must be considered. As with maintenance, a large part of successful disposal requires related issues to have been considered early on in the system’s life cycle.<br />
<br />
SEBoK Part 3 provides the information on the engineering aspects of system disposal.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley and Sons.<br />
<br />
INCOSE. 2011. ''INCOSE Systems Engineering Handbook'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications, Kings College.<br />
<br />
===Primary References===<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Implementing and Proving a Solution|< Previous Article]] | [[Systems Approach Applied to Engineered Systems|Parent Article]] | [[Stakeholder Responsibility|Next Article >]]</center><br />
<br />
<br />
==Comments from SEBoK 0.5 Wiki==<br />
Please note that in version 0.5, this article was titled “Owning and Making Use of a System”.<br />
<br />
<html><br />
<iframe src="http://www.sebokwiki.org/05/index.php?title=Talk:Owning_and_Making_Use_of_a_System&printable=yes" width=825 height=200 frameborder=1 scrolling=auto><br />
</iframe><br />
</html><br />
<br />
{{DISQUS}}<br />
<br />
<br />
<br />
[[Category:Part 2]][[Category:Topic]][[Category:Systems Approach Applied to Engineered Systems]]</div>Bwells