691:. If for example the vehicle's air bags are found to automatically fill with air after driving long distances, this will without a doubt lead to customer complaints (or hopefully problem reports during the testing phase). In turn, these produce a change request (see Figure 2 on the right), which will probably justify a change. Nevertheless, a – most likely simplistic – cost and benefit analysis has to be done, after which the change request can be approved. Following an analysis of the impact on the car design and production schedules, the planning for the implementation of the change can be created. According to this planning, the change can actually be realized, after which the new version of the car is hopefully thoroughly tested before it is released to the public.
676:
121:
711:
has regulations that govern how changes are to be made and documented. The main requirement is that a thorough review of a proposed change be performed by a multi-disciplinary team to ensure that as many possible viewpoints are used to minimize the chances of missing a hazard. In this context, change
489:
Document that describes the requested change and why it is important; can originate from PROBLEM REPORTS, system enhancements, other projects, changes in underlying systems and senior management, here summarized as REQUIREMENTS (Dennis, et al., 2002). Important attribute: ‘go/no-go decision’, i.e. is
400:
The implementation of the change in the new SYSTEM RELEASE is verified for the last time, now by the project manager. Maybe this has to happen before the release, but due to conflicting literature sources and diagram complexity considerations it was chosen to model it this way and include this issue.
614:
According to the
Pennsylvania State University Libraries (2004) definition, DOCUMENTATION is “rinted material which accompanies other materials (usually non-book), and which explains, gives instructions for use, or otherwise functions as a guide to the major materials.” In this context, it can also
310:
The extent of the change (i.e. what other items the change effects) is determined in a CHANGE IMPACT ANALYSIS. It could be argued that this activity leads to another go/no-go decision, or that it even forms a part of the
Analyze change request activity. It is modeled here as a planning task for the
641:
Besides just ‘changes’, one can also distinguish deviations and waivers. A deviation is an authorization (or a request for it) to depart from a requirement of an item, prior to the creation of it. A waiver is essentially the same, but than during or after creation of the item. These two approaches
296:
Based on the CHANGE REQUEST, its CHANGE TECHNICAL FEASIBILITY and CHANGE COSTS AND BENEFITS, the change committee makes the go/no-go decision. This is modeled as a separate activity because it is an important process step and has another role performing it. It is modeled as a sub-activity (without
671:
and when this change is propagated it probably causes other code fragments to change as well. After the initial test results seem satisfactory, the documentation can be brought up to date and be released, together with the software. Finally, the project manager verifies the change and closes this
500:
Distinct entry in the collection of all changes (e.g. for a project); consists of a CHANGE REQUEST, CHANGE TECHNICAL FEASIBILITY, CHANGE COSTS AND BENEFITS, CHANGE IMPACT ANALYSIS, CHANGE PLANNING, TEST REPORT and CHANGE VERIFICATION. Not all these have to be included if the process is terminated
476:
Document describing a problem that cannot be solved by a level 1 help desk employee; contains items like date, contact info of person reporting the problem, what is causing the problem, location and description of the problem, action taken and disposition, but this is not depicted in the diagram
437:
A few concepts are defined by the author (i.e. lack a reference), because either no (good) definitions could be found, or they are the obvious result of an activity. These concepts are marked with an asterisk (‘*’). Properties of concepts have been left out of the model, because most of them are
836:
Actually, there is no need for both a requirement for new functionality and a problem detected to occur in order to get a change request. Usually only one of the two will. Modeling them as unordered activities approximately approaches this meaning. An alternative would be to create two separate
58:
Change request management has been embraced for its ability to deliver benefits by improving the affected system and thereby satisfying "customer needs," but has also been criticized for its potential to confuse and needlessly complicate change administration. In some cases, notably in the
131:
There are six main activities, which jointly form the change request management process. They are: Identify potential change, Analyze change request, Evaluate change, Plan change, Implement change and Review and close change. These activities are executed by four different
707:, where improvised changes involving the bypassing of a stage in a reactor train was at the origin of the accident. The change had not been properly thought out, documented and risk-assessed, so that the event of breach of containment had not been identified. In the US,
283:
The project manager determines the costs and benefits of the proposed CHANGE REQUEST, resulting in CHANGE COSTS AND BENEFITS. This and the above sub-activity can be done in any order and they are independent of each other, hence the modeling as unordered activities.
662:
company then looks into the technical and economical feasibility of implementing this change and consequently it decides whether the change will actually be realized. If that indeed is the case, the change has to be planned, for example through the usage of
352:
The changes resulting from
Execute change have to be propagated to other system parts that are influenced by it. Because this and the above sub-activity are highly dependent on each other, they have been modeled as concurrent activities.
162:
is the role that requests a change due to problems encountered or new functionality requirements; this can be a person or an organizational entity and can be in- or external to the company that is asked to implement the change.
513:
Concept that indicates whether or not “reliable hardware and software, technical resources capable of meeting the needs of a proposed system can be acquired or developed by an organization in the required time” (Vogl, 2004).
99:
Notes: In the process below, it is arguable that the change committee should be responsible not only for accept/reject decisions, but also prioritization, which influences how change requests are batched for processing.
63:
domain, more funds and work are put into system maintenance (and change request management) than into the initial creation of a system. Typical investment by organizations during initial implementation of large
342:
The change is ‘programmed’; this activity has a strong relationship with
Propagate change, because sometimes the change has to be adapted to other parts of the system (or even other systems) as well.
96:, technological advances and demanding customers. Because many systems tend to change and evolve as they are used, the problems of these industries are experienced to some degree in many others.
526:
The expected effort required to implement and the advantages (e.g. cost savings, increased revenue) gained by implementing the change. Also named economic feasibility (Vogl, 2004).
566:, including systems, subsystems, assemblies, subassemblies, units, sets, accessories, computer programs, computer software or parts” (Rigby, 2003); has (overlapping)
205:
The change builder is the person who plans and implements the change; it could be argued that the planning component is (partially) taken on by the project manager.
438:
trivial and the diagram could otherwise quickly become too complex. Furthermore, some concepts (e.g. CHANGE REQUEST, SYSTEM RELEASE) lend themselves for the
92:
Change request management is also of great importance in the field of manufacturing, which is confronted with many changes due to increasing and worldwide
363:
The change builder tests whether what (s)he has built actually works and satisfies the CHANGE REQUEST. As depicted in the diagram, this can result in an
659:
120:
703:
is recognized as critical to safety. Undocumented, not properly risk assessed changes are a recipe for disaster. An eminent example of this is the
550:“A scheme, method or design for the attainment of some objective or to achieve something ” (Georgetown University, n.d.), in this case the change.
325:
of the change. Some process descriptions (e.g. Mäkäräinen, 2000) illustrate that is also possible to ‘save’ changes and process them later in a
625:“erchandise issued for sale or public showing” (Princeton University, 2003). Consists of one or more ITEMS and the accompanying DOCUMENTATION.
923:
895:
708:
430:
of each activity, i.e. the data. These deliverables or concepts are described in Table 3; in this context, the most important concepts are:
713:
675:
635:
A determination of whether or not the result of the change implementation fulfills the requirements established earlier (Rigby, 2003).
17:
273:
The project manager determines the technical feasibility of the proposed CHANGE REQUEST, leading to a CHANGE TECHNICAL FEASIBILITY.
1029:
1011:
136:, which are discussed in Table 1. The activities (or their sub-activities, if applicable) themselves are described in Table 2.
72:
195:
decides whether a CHANGE REQUEST will be implemented or not. Sometimes this task is performed by the project manager as well.
960:
181:
that the CHANGE REQUEST concerns. In some cases there is a distinct change manager, who in that case takes on this role.
602:“A document that describes the conduct and results of the testing carried out for a system or component ” (IEEE, 1991).
971:
908:
Huang, G.H. & Mak, K.L. (1999). Current practices of engineering change management in UK manufacturing industries.
88:: Through changes, the structure of a system becomes ever more complex, and more resources are required to simplify it.
769:
39:. Its main goals are to support the processing and traceability of changes to an interconnected set of factors.
35:
is the process of requesting, determining attainability, planning, implementing, and evaluating of changes to a
982:
699:
Since complex processes can be very sensitive to even small changes, proper management of change to industrial
1061:
65:
896:
https://web.archive.org/web/20060423164505/http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html
764:
642:
can be viewed as minimalistic change request management (i.e. no real solution to the problem at hand).
1056:
999:
Rajlich, V. (1999). Software Change and
Evolution. In Pavelka, J., Tel, G. & Bartošek, M. (Eds.),
442:
approach as proposed by Weerd, but this has also been left out due to diagram complexity constraints.
654:. Often users report bugs or desire new functionality from their software programs, which leads to a
735:
52:
920:
712:
request management is known as
Management of Change, or MOC. It is just one of many components of
1066:
109:
1030:
https://web.archive.org/web/20060411160145/http://www.321site.com/greg/courses/mis1/glossary.htm
532:
60:
1012:
https://web.archive.org/web/20060412081603/http://sparc.airtime.co.uk/users/wysywig/gloss.htm
952:
779:
700:
1040:
919:. The Institute of Electrical and Electronics Engineers Inc. Retrieved April 13, 2006 from:
704:
651:
113:
878:
Implementing and
Integrating Product Data Management and Software Configuration Management
8:
774:
683:
Another typical area for change request management in the way it is treated here, is the
32:
615:
be digital materials or even training, as long as it relates to (pieces of) the system.
938:
759:
596:
590:
Self-explanatory: an ITEM that already existed, but has been altered; subtype of ITEM.
563:
520:
956:
730:
507:
412:
972:
https://web.archive.org/web/20060307232014/http://mdp.ivv.nasa.gov/mdp_glossary.html
901:
Hinley, D.S. (1996). Software evolution management: a process-oriented perspective.
297:
any activity containing it) as recommended by Remko Helms (personal communication).
993:
326:
650:
A good example of the change request management process in action can be found in
927:
754:
439:
174:
667:. The actual execution of the change leads to the creation and/or alteration of
739:
725:
664:
655:
483:
431:
322:
311:
change builder because of its relationship with the activity
Propagate change.
48:
47:
There is considerable overlap and confusion between change request management,
82:: Systems that are used must change, or else automatically become less useful.
1050:
944:
684:
668:
608:
983:
https://web.archive.org/web/20060615021317/http://www.libraries.psu.edu/tas/
935:
Software change management processes in the development of embedded software
247:
837:"starting points" (i.e. initial states), both pointing to Request change.
460:
427:
387:
A new SYSTEM RELEASE, which reflects the applied change, is made public.
212:
Table 2: Activity descriptions for the change request management process
93:
446:
Table 3: Concept descriptions for the change request management process
1017:
Scott, J.A. & Nisse, D. (2001). Software
Configuration Management,
426:
Besides activities, the process-data diagram (Figure 1) also shows the
1037:
Meta-modeling
Technique: Draft for the course Method Engineering 05/06
968:
NASA IV&V Facility Metrics Data Program - Glossary and Definitions
567:
364:
192:
140:
Table 1: Role descriptions for the change request management process
556:
1028:. Retrieved April 13, 2006 from Uganda Martyrs University website:
910:
International Journal of Operations & Production Management, 19
260:
A customer proposes a change through creation of a CHANGE REQUEST.
236:
A customer desires new functionality and formulates a REQUIREMENT.
159:
885:
System Analysis & Design: An Object-Oriented Approach with UML
108:
For the description of the change request management process, the
744:
178:
937:. PhD dissertation. Espoo: VTT Publications. Available online:
921:
http://www.ee.oulu.fi/research/ouspg/sage/glossary/#reference_6
466:
A required functionality of a component (or item; NASA, 2005).
36:
876:
Crnković I., Asklund, U. & Persson-Dahlqvist, A. (2003).
377:
The DOCUMENTATION is updated to reflect the applied changes.
917:
Standard Glossary of Software Engineering Terminology (ANSI)
870:
329:. This activity could be viewed as a good point to do this.
749:
544:
538:
An assessment of the extent of the change (Rajlich, 1999).
133:
55:. The definition below does not yet integrate these areas.
1041:
https://bscw.cs.uu.nl/bscw/bscw.cgi/d1009019/Instructions
688:
687:
domain. Take for instance the design and production of a
580:
Self-explanatory: a newly created ITEM; subtype of ITEM.
415:
is completed, i.e. the CHANGE LOG ENTRY is wrapped up.
679:
Figure 2: Example change request for the car industry
939:
http://www.vtt.fi/inf/pdf/publications/2000/P416.pdf
367:
process together with the above two sub-activities.
250:) in the system and this leads to a PROBLEM REPORT.
883:Dennis, A., Wixom, B.H. & Tegarden, D. (2002).
103:
1026:Management Information Systems: Glossary of Terms
1001:SOFSEM'99, Lecture Notes in Computer Science 1725
501:earlier (i.e. if the change is not implemented).
1048:
994:http://dictionary.reference.com/search?q=release
977:Pennsylvania State University Libraries (2004).
887:. Hoboken, New York: John Wiley & Sons, Inc.
1019:Guide to Software Engineering Body of Knowledge
949:Lees' Loss Prevention in the Process Industries
68:systems is 15 to 20 percent of overall budget.
71:In the same vein, Hinley describes two of
979:CCL Manual: Glossary of Terms and Acronyms
1021:, Chapter 7, IEEE Computer Society Press.
871:Referenced literature and further reading
797:Crnkovic & Persson-Dahlqvist (2003).
562:“A non-specific term used to denote any
490:the change going to be executed or not?
246:A customer encounters a problem (e.g. a
903:Information and Software Technology, 38
785:
14:
1049:
832:
830:
116:, which is explained in this section.
1008:Managing Standards: Glossary of Terms
321:A CHANGE PLANNING is created for the
806:Dennis, Wixom & Tegarden (2002).
694:
827:
73:Lehman's laws of software evolution
24:
1043:for the process-data diagram.pdf .
674:
25:
1078:
992:. Retrieved April 13, 2006 from:
981:. Retrieved April 13, 2006 from:
894:. Retrieved April 13, 2006 from:
1039:. Retrieved March 1, 2006 from:
1010:. Retrieved April 1, 2006 from:
970:. Retrieved March 4, 2006 from:
770:Application lifecycle management
270:Determine technical feasibility
119:
104:The process and its deliverables
86:The law of increasing complexity
421:
42:
890:Georgetown University (n.d.).
858:
849:
840:
818:
809:
800:
791:
112:is used. Figure 1 depicts the
13:
1:
988:Princeton University (2003).
570:ADDED ITEM and CHANGED ITEM.
280:Determine costs and benefits
126:
985:cataloging/ccl/glossary.htm.
508:CHANGE TECHNICAL FEASIBILITY
80:The law of continuing change
7:
765:Software release life cycle
719:
645:
10:
1083:
233:Require new functionality
1035:Weerd, I. van de (2006).
855:Scott & Nisse (2001).
731:Change request management
716:, section 1910.119(l).1.
714:Process Safety Management
672:entry in the change log.
521:CHANGE COSTS AND BENEFITS
229:Identify potential change
29:change request management
18:Change management process
892:Data Warehouse: Glossary
736:Engineering Change Order
477:(Dennis, et al., 2002).
53:configuration management
933:Mäkäräinen, M. (2000).
880:. London: Artech House.
824:Huang & Mak (1999).
393:Review and close change
110:meta-modeling technique
680:
533:CHANGE IMPACT ANALYSIS
434:and CHANGE LOG ENTRY.
307:Analyze change impact
266:Analyze change request
61:Information Technology
953:Butterworth-Heinemann
780:Issue tracking system
705:Flixborough explosion
678:
374:Update documentation
786:Notes and references
652:software development
177:is the owner of the
114:process-data diagram
1062:Systems engineering
951:(4th ed.). Oxford:
775:Systems engineering
631:CHANGE VERIFICATION
447:
213:
141:
33:systems engineering
1006:Rigby, K. (2003).
926:2009-10-21 at the
760:Release management
681:
445:
243:Encounter problem
211:
139:
1057:Change management
1024:Vogl, G. (2004).
961:978-0-12-397189-0
695:In process plants
639:
638:
496:CHANGE LOG ENTRY*
419:
418:
349:Propagate change
209:
208:
16:(Redirected from
1074:
865:
862:
856:
853:
847:
844:
838:
834:
825:
822:
816:
813:
807:
804:
798:
795:
660:product software
448:
444:
335:Implement change
318:Create planning
214:
210:
187:Change committee
142:
138:
123:
21:
1082:
1081:
1077:
1076:
1075:
1073:
1072:
1071:
1047:
1046:
928:Wayback Machine
873:
868:
863:
859:
854:
850:
845:
841:
835:
828:
823:
819:
814:
810:
805:
801:
796:
792:
788:
722:
697:
665:function points
648:
545:CHANGE PLANNING
424:
384:Release change
339:Execute change
290:Evaluate change
257:Request change
175:project manager
169:Project manager
129:
106:
45:
23:
22:
15:
12:
11:
5:
1080:
1070:
1069:
1067:Process safety
1064:
1059:
1045:
1044:
1033:
1022:
1015:
1004:
997:
986:
975:
964:
942:
931:
913:
906:
899:
888:
881:
872:
869:
867:
866:
864:Mannan (2012).
857:
848:
839:
826:
817:
815:Hinley (1996).
808:
799:
789:
787:
784:
783:
782:
777:
772:
767:
762:
757:
752:
747:
742:
740:Change request
733:
728:
726:Change control
721:
718:
701:process plants
696:
693:
656:change request
647:
644:
637:
636:
633:
627:
626:
623:
621:SYSTEM RELEASE
617:
616:
612:
604:
603:
600:
592:
591:
588:
582:
581:
578:
572:
571:
560:
552:
551:
548:
540:
539:
536:
528:
527:
524:
516:
515:
511:
503:
502:
498:
492:
491:
487:
484:CHANGE REQUEST
479:
478:
474:
472:PROBLEM REPORT
468:
467:
464:
456:
455:
452:
432:CHANGE REQUEST
423:
420:
417:
416:
409:
406:
403:
402:
398:
397:Verify change
395:
389:
388:
385:
382:
379:
378:
375:
372:
369:
368:
361:
358:
355:
354:
350:
347:
344:
343:
340:
337:
331:
330:
323:implementation
319:
316:
313:
312:
308:
305:
299:
298:
294:
292:
286:
285:
281:
278:
275:
274:
271:
268:
262:
261:
258:
255:
252:
251:
244:
241:
238:
237:
234:
231:
225:
224:
221:
218:
207:
206:
203:
201:Change builder
197:
196:
189:
183:
182:
171:
165:
164:
156:
150:
149:
146:
128:
125:
105:
102:
90:
89:
83:
49:change control
44:
41:
9:
6:
4:
3:
2:
1079:
1068:
1065:
1063:
1060:
1058:
1055:
1054:
1052:
1042:
1038:
1034:
1031:
1027:
1023:
1020:
1016:
1013:
1009:
1005:
1002:
998:
995:
991:
987:
984:
980:
976:
973:
969:
966:NASA (2005).
965:
962:
958:
954:
950:
946:
943:
940:
936:
932:
929:
925:
922:
918:
915:IEEE (1991).
914:
911:
907:
904:
900:
897:
893:
889:
886:
882:
879:
875:
874:
861:
852:
846:Weerd (2006).
843:
833:
831:
821:
812:
803:
794:
790:
781:
778:
776:
773:
771:
768:
766:
763:
761:
758:
756:
753:
751:
748:
746:
743:
741:
737:
734:
732:
729:
727:
724:
723:
717:
715:
710:
706:
702:
692:
690:
686:
685:manufacturing
677:
673:
670:
669:software code
666:
661:
657:
653:
643:
634:
632:
629:
628:
624:
622:
619:
618:
613:
611:
610:
609:DOCUMENTATION
606:
605:
601:
599:
598:
594:
593:
589:
587:
586:CHANGED ITEM*
584:
583:
579:
577:
574:
573:
569:
565:
561:
559:
558:
554:
553:
549:
547:
546:
542:
541:
537:
535:
534:
530:
529:
525:
523:
522:
518:
517:
512:
510:
509:
505:
504:
499:
497:
494:
493:
488:
486:
485:
481:
480:
475:
473:
470:
469:
465:
463:
462:
458:
457:
453:
450:
449:
443:
441:
435:
433:
429:
414:
410:
408:Close change
407:
405:
404:
399:
396:
394:
391:
390:
386:
383:
381:
380:
376:
373:
371:
370:
366:
362:
359:
357:
356:
351:
348:
346:
345:
341:
338:
336:
333:
332:
328:
324:
320:
317:
315:
314:
309:
306:
304:
301:
300:
295:
293:
291:
288:
287:
282:
279:
277:
276:
272:
269:
267:
264:
263:
259:
256:
254:
253:
249:
245:
242:
240:
239:
235:
232:
230:
227:
226:
222:
219:
216:
215:
204:
202:
199:
198:
194:
190:
188:
185:
184:
180:
176:
172:
170:
167:
166:
161:
157:
155:
152:
151:
147:
144:
143:
137:
135:
124:
122:
117:
115:
111:
101:
97:
95:
87:
84:
81:
78:
77:
76:
74:
69:
67:
62:
56:
54:
50:
40:
38:
34:
30:
19:
1036:
1025:
1018:
1007:
1000:
989:
978:
967:
948:
934:
916:
909:
902:
891:
884:
877:
860:
851:
842:
820:
811:
802:
793:
698:
682:
649:
640:
630:
620:
607:
595:
585:
575:
555:
543:
531:
519:
506:
495:
482:
471:
459:
454:Description
436:
428:deliverables
425:
422:Deliverables
411:This change
392:
360:Test change
334:
302:
289:
265:
228:
223:Description
220:Sub-activity
200:
186:
168:
153:
148:Description
130:
118:
107:
98:
91:
85:
79:
70:
57:
46:
43:Introduction
28:
26:
990:WordNet 2.0
945:Mannan, Sam
912:(1), 21–37.
597:TEST REPORT
576:ADDED ITEM*
461:REQUIREMENT
303:Plan change
191:The change
94:competition
31:process in
1051:Categories
1003:, 189–202.
905:, 723–730.
755:Versioning
440:versioning
127:Activities
365:iterative
193:committee
947:(2012).
924:Archived
720:See also
646:Examples
568:subtypes
217:Activity
160:customer
154:Customer
745:PRINCE2
564:product
451:Concept
179:project
959:
658:. The
37:system
413:cycle
327:batch
134:roles
957:ISBN
750:ITIL
709:OSHA
557:ITEM
173:The
158:The
145:Role
51:and
27:The
689:car
248:bug
66:ERP
1053::
955:.
829:^
738:,
75::
1032:.
1014:.
996:.
974:.
963:.
941:.
930:.
898:.
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
