บทที่ 11 การบ ารุงรักษาซอฟต์แวร์–the...

บทที่ 11 การบ ารุงรักษาซอฟต์แวร์ (Software Maintenance)

วิชา วิศวกรรมซอฟต์แวร์ (04-06-306)

เอกสารประกอบการสอน วิชา วิศวกรรมซอฟต์แวร์ (04-06-306) 1

วัตถุประสงค์การเรียนรู ้

• เพื่อให้ผู้เรียนมีความรู้และความเข้าใจเกี่ยวกับการบ ารุงรักษาซอฟต์แวร์ ตลอดจนกระบวนการบ ารุงรักษาซอฟต์แวร์ในเบื้องต้น

• เพื่อให้ผู้เรียนมีความรู้และความเข้าใจเกี่ยวกับเทคนิคและเครื่องมือในการบ ารุงรักษาซอฟต์แวร ์


หัวข้อ

• บทน า (Overview)

• การบ ารุงรักษาซอฟต์แวร ์

• ปัญหาจากการบ ารุงรักษาซอฟต์แวร์

• กระบวนการบ ารุงรักษาซอฟต์แวร ์

• เทคนิคและเครื่องมือในการบ ารุงรักษาซอฟต์แวร์

• สรุป (Summary)


บทน ำ (Overview)

Delivery

Bug/Error

Maintenance

Software Maintenance

4 เอกสารประกอบการสอน วิชา วิศวกรรมซอฟต์แวร์ (04-06-306)

กำรบ ำรุงรักษำซอฟต์แวร์ (Software Maintenance)

• การเปลี่ยนแปลงซอฟต์แวร์ภายหลังการส่งมอบ เพื่อแก้ไขข้อผิดพลำด ปรับปรุงประสิทธิภำพ หรือ ดัดแปลงซอฟต์แวร์ให้เหมำะสมกับสภำพแวดล้อมที่เปลี่ยนแปลงไป [IEEE1219, 1998]

• กระบวนการปรับปรุงแก้ ไขโค้ดและเอกสำรให้ถูกต้องเมื่อพบข้อผิดพลำด หรือมีกำรร้องขอให้ปรับปรุง เพื่อปรับปรุงให้ซอฟต์แวร์ที่ก าลังใช้งานอยู่ให้คงสมบูรณ์อยู่เสมอ


ควำมส ำคัญของกำรบ ำรุงรักษำ

• เหตุผลส ำคัญของกำรบ ำรุงรกัษำซอฟต์แวร์

– การเปลี่ยนแปลง

– การใช้งานภายใต้สภาพแวดล้อมต่าง ๆ

• กระบวนกำรบ ำรุงรักษำ

– เพื่อให้ซอฟต์แวร์สามารถท างานตรงตามความต้องการผู้ใช้

• วิศวกรซอฟต์แวร์

– ออกแบบให้ซอฟต์แวร์ปรับปรุง/แก้ไขได้ง่าย


ทำงเลือก ระหว่ำงกำรบ ำรุงรักษำซอฟต์แวร์กับพัฒนำขึ้นมำใหม่

• ต้นทุนที่เกิดจากการบ ารุงรักษาสูงเกินไปหรือไม่

• ซอฟต์แวร์หรือระบบไม่น่าเชื่อถืออีกต่อไปใช่หรือไม่

• ซอฟต์แวร์ไม่สามารถดัดแปลงได้อีกใช่หรือไม ่

• ประสิทธิภาพของซอฟต์แวร์ยังคงมีเพียงพอที่จะท างานภายใต้ข้อจ ากัดต่าง ๆ หรือไม ่

• มีซอฟต์แวร์อ่ืนที่สามารถท างานชนิดเดียวกันแต่ท างานได้เร็วกว่า ดีกว่า และต้นทุนต่ ากว่าหรือไม่

7

เอกสารประกอบการสอน วิชา วิศวกรรมซอฟต์แวร์ (04-06-306)

ประเภทกำรบ ำรุงรักษำ

• There are three different types of software maintenance:

• Fault repairs

– Coding errors are usually relatively cheap to correct

– Design errors are more expensive as they may involve rewriting several program components

• Environmental adaptation

– required when some aspect of the system’s environment support software changes

– The application system must be modified to adapt it to cope with these environmental changes

• Functionality addition

– necessary when the system requirements change in response to organizational or business change

– The scale of the changes required to the software is often much greater than for the other types of maintenance


ประเภทกำรบ ำรุงรักษำ (ต่อ)

• กำรบ ำรุงรักษำมีลักษณะส ำคัญ 4 ประกำร ดังนี ้– ควบคุมการท างานแต่ละฟังก์ชันของ

ซอฟต์แวร์ให้ยังคงถูกต้องเป็นประจ า

– ควบคุมการปรับปรุงซอฟต์แวร์

– คงสภาพความสมบูรณ์ของฟังก์ชันงานของซอฟต์แวร ์

– ป้องกันไม่ให้ประสิทธิภาพของซอฟต์แวร์ลดลงเกินระดับที่น่าพอใจ

Corrective Maintenance

Adaptive Maintenance

Perfective Maintenance

Preventive Maintenance

ประเภทการบ ารุงรักษาซอฟต์แวร์


An approximate distribution of maintenance costs/ Overall lifetime costs

Maintenance effort distribution Development and maintenance costs


ที่มา: Lan Sommerville, Software Engineering Ninth Edition, 2011.

ปัญหำจำกกำรบ ำรุงรักษำซอฟต์แวร ์

• ข้อจ ากัดด้านการท างานความเข้าใจ • ขวัญและก าลังใจ • การตัดสินใจด้านบริหารส าคัญที่สุดเสมอ

ด้ำนทีมงำน

• สถาปัตยกรรมและแนวทางเก่า • ความยากของการทดสอบ ด้ำนเทคนิค

• ท าตามหลักปฏิบัติ / ไม่ชัดเจน / ซ่อมบ ารุงยาก กำรประนีประนอม

• ประเภทของ และความใหม่ของแอปพลิเคชัน • การโยกย้ายและจ านวนแรงงานที่มีอยู่ • ช่วงชีวิตของซอฟต์แวร์ สภาพแวดล้อมที่อาจเปลี่ยนแปลงได้เสมอ • คุณภาพของฮาร์ดแวร์ งานออกแบบ โปรแกรม เอกสารและการทดสอบ

ด้ำนงบประมำณ


Maintenance prediction

เอกสารประกอบการสอน วิชา วิศวกรรมซอฟต์แวร์ (04-06-306) 12 ที่มา: Lan Sommerville, Software Engineering Ninth Edition, 2011.

Maintenance prediction (ต่อ)

• To evaluate the relationships between a system and its environment, you should assess:

– The number and complexity of system interfaces • The larger the number of interfaces and the more complex these

interfaces, the more likely it is that interface changes will be required as new requirements are proposed.

– The number of inherently volatile system requirements • requirements that reflect organizational policies and procedures are likely

to be more volatile than requirements that are based on stable domain characteristics.

– The business processes in which the system is used • As business processes evolve, they generate system change requests. The

more business processes that use a system, the more the demands for system change.


Maintenance prediction (ต่อ)

• Examples of process metrics that can be used for assessing maintainability are as follows:

– Number of requests for corrective maintenance

– Average time required for impact analysis

– Average time taken to implement a change request

– Number of outstanding change requests


Software reengineering

• There are two important benefits from reengineering rather than replacement:

• Reduced risk There is a high risk in redeveloping business-critical software. Errors may be made in the system specification or there may be development problems. Delays in introducing the new software may mean that business is lost and extra costs are incurred.

• Reduced cost The cost of reengineering may be significantly less than the cost of developing new software. Ulrich (1990) quotes an example of a commercial system for which the reimplementation costs were estimated at $50 million. The system was successfully reengineered for $12 million. I suspect that, with modern software technology, the relative cost of reimplementation is probably less than this but will still considerably exceed the costs of reengineering.


The reengineering process

16 เอกสารประกอบการสอน วิชา วิศวกรรมซอฟต์แวร์ (04-06-306) ที่มา: Lan Sommerville, Software Engineering Ninth Edition, 2011.

Reengineering approaches

17 เอกสารประกอบการสอน วิชา วิศวกรรมซอฟต์แวร์ (04-06-306) ที่มา: Lan Sommerville, Software Engineering Ninth Edition, 2011.

Costs increase from left to right so that source code translation is the cheapest option. Reengineering as part of architectural migration is the most expensive.

The reengineering process (ต่อ)

• The activities in this reengineering process are as follows: 1. Source code translation Using a translation tool, the

program is converted from an old programming language to a more modern version of the same language or to a different language.

2. Reverse engineering The program is analyzed and information extracted from it. This helps to document its organization and functionality. Again, this process is usually completely automated.

3. Program structure improvement The control structure of the program is analyzed and modified to make it easier to read and understand. This can be partially automated but some manual intervention is usually required.


The reengineering process (ต่อ)

4. Program modularization Related parts of the program are grouped together and, where appropriate, redundancy is removed. In some cases, this stage may involve architectural refactoring (e.g., a system that uses several different data stores may be refactored to use a single repository). This is a manual process.

5. Data reengineering The data processed by the program is changed to reflect program changes. This may mean redefining database schemas and converting existing databases to the new structure. You should usually also clean up the data. This involves finding and correcting mistakes, removing duplicate records, etc. Tools are available to support data reengineering.


Preventative maintenance by refactoring

• Refactoring is the process of making improvements to a program to slow down degradation through change [Opdyke and

Johnson, 1990]

– improve its structure

– reduce its complexity

– easier to understand

• Refactoring is sometimes considered to be limited to object-oriented development but the principles can be applied to any development approach – not add functionality but should concentrate on program

improvement

– refactoring as ‘preventative maintenance’ that reduces the problems of future change


Preventative maintenance by refactoring (ต่อ)

• Reengineering takes place after a system has been maintained for some time and maintenance costs are increasing, use automated tools to process and reengineer a legacy system to create a new system that is more maintainable

• Refactoring is a continuous process of improvement throughout the development and evolution process. It is intended to avoid the structure and code degradation that increases the costs and difficulties of maintaining a system

• Refactoring is an inherent part of agile methods – Program quality is therefore liable to degrade quickly so agile

developers frequently refactor their programs to avoid this degradation

– The emphasis on regression testing in agile methods lowers the risk of introducing new errors through refactoring


Bad smells

• Fowler et al. (1999) suggest that there are stereotypical situations (he calls them ‘bad smells’) in which the code of a program can be improved. Examples of bad smells that can be improved through refactoring include:

1. Duplicate code The same of very similar code may be included at different places in a program. This can be removed and implemented as a single method or function that is called as required.

2. Long methods If a method is too long, it should be redesigned as a number of shorter methods.


Bad smells (ต่อ)

3. Switch (case) statements These often involve duplication, where the switch depends on the type of some value. The switch statements may be scattered around a program. In object-oriented languages, you can often use polymorphism to achieve the same thing.

4. Data clumping Data clumps occur when the same group of data items (fields in classes, parameters in methods) reoccur in several places in a program. These can often be replaced with an object encapsulating all of the data.

5. Speculative generality This occurs when developers include generality in a program in case it is required in future. This can often simply be removed.


กระบวนกำรบ ำรุงรักษำซอฟต์แวร์

Classification & Identification

Analysis

Design

Implementation System test

Acceptance Test

Delivery

24

Modification Request

เอกสารประกอบการสอน วิชา วิศวกรรมซอฟต์แวร์ (04-06-306)

กระบวนกำรบ ำรุงรักษำซอฟต์แวร์ (ต่อ)

• เสนอให้เปลี่ยนแปลง (Modification Request)

– ยื่นข้อเสนอหรือค าร้องขอให้เปลี่ยนแปลงซอฟต์แวร์จากผู้ใช้งาน

• จ ำแนกและระบุประเภทของกำรบ ำรุงรักษำ (Classification & Identification)

– ก าหนดหมายเลข/รหัสให้ค าร้อง พร้อมจ าแนกประเภทการบ ารุงรักษา และพิจารณาอนุมัติ

– ประมาณขนาด จัดล าดับความส าคัญ และก าหนดระยะเวลา (ถ้าอนุมัต)ิ



• วิเครำะห์ข้อเสนอ (Analysis)

– วิเคราะห์ความเป็นไปได้ของการเปลี่ยนแปลง • ขอบเขต / เทคนิค / วางแผน

– (เอกสารจาก Classification & Identification)

– ถ้าเอกสารไม่สมบูรณ์ต้องใช้การวิศวกรรมแบบย้อนกลบั (Reverse Engineering)

– Impact analysis, Human factors, Cost-benefit Effective



• กำรออกแบบ (Design)

– ออกแบบโมดูลที่ได้รับการเปลี่ยนแปลง และที่ได้รับผลกระทบ

– แก้ไขเอกสารที่เกี่ยวข้องทั้งหมดกับโมดูลที่กระทบ

– ออกแบบกรณีทดสอบส าหรับโมดูลใหม่ที่ผ่านการแก้ไข

– พิจารณาเอกสารข้อก าหนดความต้องการ เพื่อปรับปรุงให้ตรงกับรุ่นของซอฟต์แวร์ และปรับปรุงรายการซ่อมบ ารุง



• ด ำเนินงำนบ ำรุงรักษำ (Implementation)

– ด าเนินการแก้ไขโปรแกรมในส่วนที่ได้รับผลกระบบทีละส่วน แล้วน ามาประสานกัน

– ทดสอบการท างานตามเทคนิคที่ก าหนดในขั้นตอนการวิเคราะห์

– Risk analysis



• กำรทดสอบระบบ (System Test)

– ทดสอบซอฟต์แวร์ตามกรณีทดสอบที่ได้ออกแบบ

– Unit test, Integration และ System test ตามล าดับ

• ทดสอบกำรยอมรับ (Acceptance Test)

– เพื่อรับประกันในระบบ/ซอฟต์แวร์ที่ผ่านการแก้ไขเป็นที่ยอมรับของลูกค้า



• ส่งมอบ (Delivery)

– วางแผนการส่งมอบ

– แจ้งผู้ใช้งานเกี่ยวกับการติดตั้งระบบ

– จัดการฝึกอบรม

– ส ารองระบบ

– เตรียมระบบสนับสนุนระหว่างการใช้งานของผู้ใช้


เทคนิคในกำรบ ำรุงรักษำซอฟต์แวร์

• กำรท ำควำมเข้ำใจโปรแกรม (Program Comprehension) – Code Browser ระบุต าแหน่งนิยามคลาส – คลาสที่ Derived จาก Base Class – รายการคลาส ชนิดของคลาส เมธอด อินเตอร์เฟส และการเข้าถึงคลาส

• กำรฟื้นฟูสภำพของซอฟต์แวร์ (Software Rejuvenation) – Redocumentation – Restructuring – Reverse Engineering – Reengineering


เครื่องมือในกำรบ ำรุงรักษำซอฟต์แวร์

• Text Editor

• File Comparators

• Compiler and Linkers

• Debugging Tools

• Code Reference Generators

• Static Code Analyzers

• Configuration Management Repositories


33

Bugzilla What is Bugzilla? Bugzilla is a "Defect Tracking System" or "Bug-Tracking System". Defect Tracking Systems allow individual or groups of developers to keep track of outstanding bugs in their product effectively. Most commercial defect-tracking software vendors charge enormous licensing fees. Despite being "free", Bugzilla has many features its expensive counterparts lack. Consequently, Bugzilla has quickly become a favorite of thousands of organizations across the globe.

ที่มา: https://www.bugzilla.org/ เอกสารประกอบการสอน วิชา วิศวกรรมซอฟต์แวร์ (04-06-306)

สรุป (Summary)

• ศึกษาเรียนรู้เกี่ยวกับ • การบ ารุงรักษาซอฟต์แวร์ (Software Maintenance)

• การเปลี่ยนแปลงหรือแก้ไขซอฟต์แวร์หลังจากส่งมอบให้แก่ลูกค้าเพื่อติดตั้งใช้งาน เพื่อให้ซอฟต์แวร์ท างานได้เหมาะสมกับสภาพแวดล้อมที่เปลี่ยนแปลงไป

• สามารถจ าแนกประเภทการบ ารุงรักษาซอฟต์แวร์เป็น 4 ประเภท ดังนี้ Corrective Maintenance, Adaptive Maintenance, Perfective Maintenance และ Preventive Maintenance


กิจกรรมท้ำยบท

• จงอธิบายเกี่ยวกับประเภทของการบ ารงุรักษาซอฟต์แวร์ 3 ประเภทหลัก และบอกถึงความแตกต่างในการจ าแนกแต่ละประเภท

• จงให้ค าจ ากัดความและบอกความส าคัญของการบ ารุงรักษาซอฟต์แวร์ (Software Maintenance) พอสังเขป

• กระบวนการบ ารุงรักษาซอฟต์แวร์มีกี่ประบวนการ และประกอบด้วยอะไรบ้าง จงอธิบาย

• อะไรเป็นปัจจัยหลักที่อาจจะส่งผลกระทบต่องบประมาณในการ reengineering ระบบ

• จงอธิบายความหมายของค าส าคัญดังนี้ Reengineering, Refactoring และ Bad smells


เอกสำรอ้ำงอิง

• กิตติ ภักดัวัฒนะกุล, วิศวกรรมซอฟต์แวร์ (Software Engineering), กรุงเทพฯ: เคทีพี คอมพ์ แอนด์ คอนซัลท์, 2552

• Lan Sommerville, Software Engineering Ninth Edition, Pearson Education, Inc., publishing as Addison-Wesley, 2011.


บทที่ 11 การบ ารุงรักษาซอฟต์แวร์–the...

Documents