Object Oriented Development with UML

งานนำเสนอเรื่อง: "Object Oriented Development with UML"— ใบสำเนางานนำเสนอ:

1 Object Oriented Development with UML
11/13/2018 Object Oriented Development with UML 11-12, November 2006 At Sipa Chiangmai Rational Unified Process โดย รศ. รังสิต ศิริรังษี อ. สายัณห์ อุ่นนันกาศ

2 Software Project Statistics 1979
11/13/2018 Software Project Statistics 1979 47.5% Have things changed?

3 สถิติต่าง ๆ ที่เกี่ยวข้อง
11/13/2018 สถิติต่าง ๆ ที่เกี่ยวข้อง หนึ่งในสี่ของระบบที่พัฒนาขึ้นไม่สามารถส่งมอบได้ การเปลี่ยนงานของ staff จำนวน 20% ถือเป็นเรื่องปกติ อายุเฉลี่ยการเปลี่ยนงานของโปรแกรมเมอร์ไทย 8 เดือน งานหลัก ๆ ใช้เวลาการพัฒนาเกินกว่า 30 เดือน โปรเจคขนาดใหญ่จะใช้เวลาในการดำเนินการ 3 ถึง 5 ปีในการพัฒนา บริษัททั่วไปจะใช้งบลงทุน 20% ของทั้งหมดในการพัฒนาระบบ I T จากการศึกษาโดย Yourdan พบว่า 25% ของโปรเจคขนาดใหญ่ไม่มีทางพัฒนาได้สำเร็จ 100% ของ IT โปรเจคโดยเฉลี่ยจะมีค่าใช้จ่ายเกินงบประมาณทั้งสิ้น

4 Timeline: Initial CHAOS Report
11/13/2018 Timeline: Initial CHAOS Report จากการศึกษาของ Standish Group reports ในปี 1995 จากซอฟต์แวร์จำนวน 175,000 โครงการ 31.1% ของโครงการถูกยกเลิกก่อนที่จะเสร็จสมบูรณ์ 52.7% ของโครงการทั้งหมดจะมีค่าเฉลี่ย 189% overruns มีเพียง 16.2% เท่านั้นที่เสร็จทันเวลาและอยู่ในงบประมาณที่กำหนดไว้ ข้อมูล update ในปี 1998 สถิติทั่วอเมริกามี success rate ที่เพิ่มขึ้นจาก 16% เป็น 28 % แต่ 95% ของโครงการจะต้องเริ่มต้นใหม่อย่างน้อย 1 ครั้ง ค่าใช้จ่ายสำหรับความล้มเหลวและค่าเสียโอกาสมีมากกว่าหมื่นล้านเหรียญต่อปี

5 Software Project Statistics 1979 and 1995
11/13/2018 Software Project Statistics 1979 and 1995 So, here are some statistics produced by the Standish Group based on a survey based on over 8000 software applications across several hunderd organisations. 31% of projects cancelled before actually delivering anything. That is, whatever money had been spent on them before they were closed is money down the drain. A separate report has estimated that project cancellations equates to about $81bn in the USA alone. 53% of projects are "challenged" in some way (i.e. they may be late, over budget, or de-scoped), but at least they deliver something eventually. So, by our definition of quality, around 84% of projects (if you include the cancelled and challenged projects) actually fail in some way. That leaves only 16% successful ones ! Not very good, is it ! Source: The Standish Group, 1995

6 Why Software Projects Fail
11/13/2018 Why Software Projects Fail

7 Project Success Rates Have Improved by 50%
11/13/2018 Project Success Rates Have Improved by 50% Standish Group ได้ประกาศผลการศึกษา CHAOS research ในปี 2003 โดยการศึกษาได้ดำเนินการทุก ๆ สองปีตั้งแต่ปี โดยการสำรวจโครงการทั้งที่ประสบความสำเร็จและล้มเหลว โดยในปี 2003 ได้สำรวจข้อมูลจำนวน 13,522 โครงการโดยมีผลดังต่อไปนี้ อัตราความสำเร็จของโครงการเพิ่มขึ้นกว่าหนึ่งในสามหรือ 34% ของโครงการทั้งหมด ถือเป็นการเพิ่มขึ้น 100% ซึ่งมากกว่าอัตราความสำเร็จในปี 1994 คือ 16% โครงการที่ล้มเหลวลดลง 15% จากโครงการทั้งหมด ซึ่งมากกว่าครึ่งในปี 1994 คือ 31% อัตรา Challenged โครงการยังคงที่ 51%

8 From 1995 to 2003 Source: The Standish Group, 1995
11/13/2018 Source: The Standish Group, 1995 So, here are some statistics produced by the Standish Group based on a survey based on over 8000 software applications across several hunderd organisations. 31% of projects cancelled before actually delivering anything. That is, whatever money had been spent on them before they were closed is money down the drain. A separate report has estimated that project cancellations equates to about $81bn in the USA alone. 53% of projects are "challenged" in some way (i.e. they may be late, over budget, or de-scoped), but at least they deliver something eventually. So, by our definition of quality, around 84% of projects (if you include the cancelled and challenged projects) actually fail in some way. That leaves only 16% successful ones ! Not very good, is it ! Source: The Standish Group, 2003

9 11/13/2018

10 11/13/2018 Software Process แนวโน้มในการพัฒนาจึงเปลี่ยนไปเน้นที่คุณภาพของ Product โดยอาศัย Process กิจกรรมต่าง ๆ ที่เกี่ยวข้องกับการผลิตซอฟต์แวร์ Product ลำดับขั้นตอนในการพัฒนาและบำรุงรักษาซอฟต์แวร์ โดยการประยุกต์วิธีการ เครื่องมือ และบุคลากรที่เกี่ยวข้องกับงานพัฒนาซอฟต์แวร์ นิยาม ซอฟต์แวร์โปรเซส : เป็นรายละเอียดของโปรเซสซึ่งจะใช้เป็นแนวทางสำหรับวิศวกรรมซอฟต์แวร์ในการทำงาน โดยการกำหนดปริมาณงานตามกฎเกณฑ์ที่ใช้ หมายเหตุ ขั้นตอนในการโปรเซสต่าง ๆ จะขึ้นอยู่กับการเลือกใช้ขององค์กรหรือหน่วยงานที่พัฒนาระบบเป็นหลัก

11 คุณสมบัติของ process ที่ดี
11/13/2018 คุณสมบัติของ process ที่ดี Understandability - โปรเซสมีการกำหนดรายละเอียดไว้อย่างชัดเจนและสามารถทำความเข้าใจได้กับทุกฝ่าย Visibility - โปรเซสมีความก้าวหน้าอย่างเห็นได้ชัดในแต่ละเฟส Supportability - โปรเซสสามารถใช้เครื่องมือปะเภท CASE tools ช่วย Acceptability - โปรเซสเป็นที่ยอมรับกับทุกฝ่าย Reliability – โปรเซสมีความสามารถของการคงทนต่อความเสียหาย Robustness - โปรเซสสามารถทำงานต่อได้แม้จะเกิดความผิดพลาดขึ้น Maintainability - โปรเซสสามารถปรับปรุงและเปลี่ยนแปลงได้ตามความต้องการของผู้ใช้ Rapidity - ความเร็วในการทำงานที่โปรเซสหรือระบบสามารถตอบสนอง

12 Software Process Model
11/13/2018 Software Process Model เป็นนามธรรมของ software process Model อาจประกอบไปด้วย : กิจกรรมต่าง ๆ อาจมีได้หลายมุมมอง ตัวอย่างเช่น: Waterfall Iterative & Incremental

13 วิธีการแบบ Waterfall Model
11/13/2018 วิธีการแบบ Waterfall Model พัฒนาขึ้นโดย Winston Royce ในปี 1970 และได้รับความนิยมใช้มาจนถึงปัจจุบัน เน้นไปที่การพัฒนาระบบแบบตามลำดับของเฟสที่กำหนดไว้ และทำการตรวจสอบความถูกต้องและทบทวนเมื่อสิ้นสุดในแต่ละเฟส แต่ละเฟสจะไม่มีการ overlap กัน วิธีการนี้จะถูกวิพากวิจารณ์ว่าเป็น "one way street, with no turning back” ดังนั้นการเปลี่ยนแปลงใด ๆ ภายในเฟสปัจจุบันจะก่อให้เกิดผลกระทบต่อความเปลี่ยนแปลงในเฟสก่อนหน้าโดยอัตโนมัติ ค่าใช้จ่ายของการเปลี่ยนแปลงจะมีมากขึ้นตามจำนวนของเฟสที่พัฒนาไปแล้ว

14 Waterfall Development
11/13/2018 Waterfall Development Subsystem Testing System Testing Code & Unit Design Requirements Analysis T I M E

15 วิธีการแบบ Waterfall Model
11/13/2018 วิธีการแบบ Waterfall Model ได้รับความนิยมในการใช้อย่างแพร่หลาย แต่ละขั้นตอนจะแสดงผลลัพธ์ออกมาในรูปของเอกสารประกอบ เหมาะสมอย่างยิ่งที่จะใช้การพัฒนางานที่มีความเข้าใจอย่างดีอยู่แล้ว โดยใช้เทคโนโลยีที่เคยทำอยู่เป็นประจำ เมื่อโครงการเริ่มต้นไปแล้ว การเปลี่ยนแปลงที่เกิดขึ้นจะก่อให้เกิดความยุ่งยากต่อขั้นตอนที่ได้ดำเนินการไปแล้ว เกิด blocking states ขึ้นในกรณีที่มีการแก้ไขขั้นตอนใดขั้นตอนหนึ่ง ความก้าวหน้าของโปรเจคจะมองเห็นได้ชัดเจนในขั้นตอนท้าย ๆ การทดสอบระบบไม่สามารถทำได้จนกว่าจะถึงขั้นตอนท้าย ๆ เกิดความเสี่ยงต่าง ๆ ในระหว่างขั้นตอนการดำเนินการ

16 Relative Costs of Fixing Software Faults
11/13/2018 Relative Costs of Fixing Software Faults 200 30 10 4 3 2 1 Requirements Specification Planning Design Implementation Integration Maintenance

17 11/13/2018 Iterative Process แบ่งหน้าที่ของระบบออกเป็นส่วน ๆ และทำการพัฒนาเพิ่มขึ้นทีละส่วนตามลำดับ แต่ละส่วนที่เพิ่มขึ้นจะมีวงจรชีวิตที่สมบูรณ์เป็นของตัวเอง และสามารถทำงานตามลำดับหรือขนานกันได้ ทั้งนี้ขึ้นอยู่งานแต่ละชนิด แต่ละส่วนที่เพิ่มขึ้นจะมีผลทำให้ระบบสมบูรณ์ขึ้นตามลำดับ ส่วนที่ทำการพัฒนาก่อนจะถือเป็นส่วนหลักของระบบ เช่นการทำงานพื้นฐานของระบบ แก้ไขเพิ่มเติมแต่ละส่วนเพื่อหาผลกระทบต่อการออกแบบส่วนที่เพิ่มขึ้นในลำดับถัดมา

18 The Iteration Life Cycle: A Mini-Waterfall
11/13/2018 The Iteration Life Cycle: A Mini-Waterfall ผลลัพธ์จาก iterations ก่อนหน้า กำหนด risk ให้ทันต่อเหตุการณ์ Iteration Planning Scenarios Requirements Capture Analysis & Design Implementation Test Prepare Release Release รายละเอียด ของ risk ต่าง ๆ

19 Apply the Waterfall Iteratively to System Increments
11/13/2018 Apply the Waterfall Iteratively to System Increments In the iterative approach, the waterfall is applied to a single increment of the system at a time. Each iteration produces an executable. Animation note: The graphic automatically wipes right T C D R T I M E Iteration 1 Iteration 2 Iteration 3 iterations ในช่วงต้น ๆ จะเป็นการจัดการกับปัจจัยที่มีความเสี่ยงมากที่สุด แต่ละ iteration จะถูกสร้างออกมาเป็น release และเพิ่มขึ้น ๆ จนกระทั่งได้ระบบที่สมบูรณ์ แต่ละ iteration จะรวมไปถึงการ integration และการ test R: Requirements Analysis D: Design C: Coding, Unit Testing T: Subsystem and System Test Iterative processes were developed in response to these waterfall characteristics. With an iterative process, the waterfall steps are applied iteratively. Instead of developing the whole system in lockstep, an increment (that is, a subset of system functionality) is selected and developed, then another increment, etc. The selection of the increment to be developed first is based on risk, the highest priority risks first. To address the select risk(s), a subset of use-cases are chosen. The minimal set of use-cases that will allow objective verification (i.e., through a set of executable tests) that this risk has been addressed, is developed. Then the next increment is selected to address the next highest risk, and so on. The waterfall is thus applied at the increment level and the system evolves incrementally.

20 Examples of Software Risk Items
11/13/2018 Examples of Software Risk Items ปัญหาส่วนตัวของบุคลากร ตารางเวลาและงบประมาณไม่ตรงกับความเป็นจริง พัฒนาการทำงานในส่วนที่เป็นหัวใจของระบบผิด พัฒนาระบบ user interface ไม่ถูกต้อง มีการเปลี่ยนแปลงความต้องการของระบบอย่างต่อเนื่อง เกิดปัญหาจาก Components ที่นำมาจากภายนอก

21 Adv : Iterative Process
11/13/2018 Adv : Iterative Process ช่วยจัดการกับความเปลี่ยนแปลงที่เกิดขึ้นในกรณีที่มีการเปลี่ยนแปลงความต้องการของระบบ ซึ่งเป็นสาเหตุหลักที่มีผลต่อการส่งมอบงานไม่เป็นไปตามกำหนด ความเสี่ยงที่เกิดขึ้นจะถูกค้นพบหรือจัดการแก้ไขได้ในขั้นตอนของการรวบรวมส่วนประกอบของระบบด้วยวิธีการพัฒนาแบบนี้สามารถจัดการกับความเสี่ยงได้ในช่วงต้น ๆ ของการพัฒนา การพัฒนาแบบนี้จะช่วยให้การจัดการระบบงานได้ง่ายขึ้น โดยยอมให้มีการส่งมอบระบบงานเป็นส่วน ๆ ก่อนได้ การพัฒนาแบบนี้ช่วยสนับสนุนการนำกลับมาใช้ใหม่ได้ ซึ่งจะง่ายต่อการกำหนดองค์ประกอบที่ต้องการในขั้นตอนของการออกแบบ การแก้ไขความผิดพลาดในหลาย ๆ รอบการทำงานแบบนี้ จะทำให้ผลลัพธ์ที่ได้จากการทำงานของระบบมีความสมบูรณ์มากขึ้น

22 An Iterative Development Process...
11/13/2018 An Iterative Development Process... In the iterative approach, the waterfall is applied to a single increment of the system at a time. Each iteration produces an executable. Animation note: The graphic automatically wipes right T C D R T I M E Iteration 1 Iteration 2 Iteration 3 Iteration 1 R: Requirements Analysis D: Design C: Coding, Unit Testing T: Subsystem and System Test Iterative processes were developed in response to these waterfall characteristics. With an iterative process, the waterfall steps are applied iteratively. Instead of developing the whole system in lockstep, an increment (that is, a subset of system functionality) is selected and developed, then another increment, etc. The selection of the increment to be developed first is based on risk, the highest priority risks first. To address the select risk(s), a subset of use-cases are chosen. The minimal set of use-cases that will allow objective verification (i.e., through a set of executable tests) that this risk has been addressed, is developed. Then the next increment is selected to address the next highest risk, and so on. The waterfall is thus applied at the increment level and the system evolves incrementally. Iteration 2 Iteration 3

23 Waterfall Development Delays Reduction of Risk
11/13/2018 Waterfall Development Delays Reduction of Risk To continue the example. At the end of two years, since we have not actually executed any thing yet, we have just as much risk remaining in the project as we had when we started. Animation note: the green line is drawn automatically. Requirements Analysis R I S K Design Code & Unit Testing The fundamental problem of this approach is that it pushes risk forward in time, where it’s costly to undo mistakes from earlier phases. An initial design will likely be flawed with respect to its key requirements, and furthermore, the late discovery of design defects tends to result in costly over runs and/or project cancellation. The waterfall approach tends to mask the real risks to a project until it is too late to do anything meaningful about them. Subsystem Testing System Testing T I M E

24 Iterative Development Accelerates Risk Reduction
11/13/2018 Iterative Development Accelerates Risk Reduction Going back to our 2- year project that actually takes 3 years: It may still take 3 years, but at the end of 2 years, we have removed most of the risk and have something that executes, although in a limited way. We are in a much stronger position. Animation notes: The risk lines are automatically drawn after the axes are drawn. R I S K T I M E Iteration Iterative Waterfall The most critical characteristic of iterative development is that project risk is driven down in early iterations before significant implementation investments are made.

25 What is the RUP? RUP = Rational Unified Process
11/13/2018 What is the RUP? RUP = Rational Unified Process เป็นกระบวนการพัฒนาซอฟต์แวร์ที่ถูกพัฒนาขึ้นโดย Rational Software Corporation ปัจจุบันอยู่ภายใน IBM RUP ถือเป็นกระบวนการทางด้านวิศวกรรมซอฟต์แวร์ RUP มีการกำหนดโครงสร้างไว้เป็นอย่างดี โดยใช้แนวคิดเชิงวัตถุในการกำหนดรายละเอียดของการทำงาน RUP รวบรวมวิธีการพัฒนาต่าง ๆ ที่เคยใช้ได้ผลดีไว้ด้วยกัน การออกแบบและจัดทำเอกสารในกระบวนการแบบ RUP จะใช้ UML ส่วนสำคัญที่สุดของ Unified Process คือการพัฒนาระบบด้วยวิธีการแบบ iterative development

26 Development Life Cycles
11/13/2018 Development Life Cycles SDLC (Waterfall) Project initiation Analysis Logical Design Physical Design Implementation Maintenance Unified Process Inception Elaboration Construction Transition

27 11/13/2018 Phases in the Process Major Milestones Inception Elaboration Construction Transition time วงจรชีวิตที่ใช้ในการพัฒนาระบบแบบ RUP ประกอบไปด้วย 4 เฟส ได้แก่: Inception - Requirement Elaboration - Analysis & Design, Implementation Construction – Implementation, Test Transition - Deploy

28 Phases in the Process Inception Phase ค้นหาความต้องการของระบบเบื้องต้น
11/13/2018 Phases in the Process Inception Phase ค้นหาความต้องการของระบบเบื้องต้น วิเคราะห์ Cost Benefit และวิเคราะห์ความเสี่ยงเบื้องต้น กำหนดขอบเขตของโครงการและทางเลือกของสถาปัตยกรรมที่ใช้ ผลลัพธ์ที่ได้ Use Case Model (10% - 20% complete) Elaboration phase วิเคราะห์และออกแบบระบบ กำหนดรายละเอียดสถาปัตยกรรมของระบบ กำหนดแผนพัฒนาระบบทั้งหมด ผลลัพธ์ที่ได้ Use Case Model (80% complete)

29 Phases in the Process Construction Phase
11/13/2018 Phases in the Process Construction Phase พัฒนาส่วนที่เป็นองค์ประกอบต่าง ๆ ที่ถูกออกแบบไว้ ทดสอบตามคุณสมบัติที่กำหนดไว้ จัดการทรัพยากร ควบคุมกระบวนการ optimization Transition phase ประกอบไปด้วยการ transfer ของระบบไปยังผู้ใช้ ขั้นตอนนี้รวมไปถึงการติดตั้ง การฝึกอบรม การสนับสนุนทางเทคนิคและการบำรุงรักษา รวมทั้ง "Beta testing" เพื่อตรวจสอบระบบตามความคาดหวังของผู้ใช้

30 RUP : Iteration Process
11/13/2018 RUP : Iteration Process Inception Elaboration Construction Transition Iteration 1 Iteration 2 Iteration 3 “Mini-Waterfall” Process Iteration Planning Rqmts Capture Analysis & Design Implementation Test Prepare Release

31 Rational Unified Process (RUP)
11/13/2018 Rational Unified Process (RUP) time content Preliminary Iteration(s) Iter. #1 Phases Iterations Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Elaboration Transition Inception Construction Business Modeling Implementation Test Analysis & Design Process Workflows Deployment Requirements Inception Defines the scope of the project. A business plan is often created to determine whether resources should be committed or not. The model is 20% complete. Elaboration Plan project, specify features, baseline architecture. Requirements are firmed up, we’re now 80% complete. A detailed cost/resource estimation can be drawn up. Construction Build the product. Several iterations. Transition Move the product into and end user environment. Training, installation and support. An iteration is a distinct sequence of activities based on an established plan and evaluation criteria, resulting in an executable release (internal or external) A workflow shows all the activities you might go through to produce a particular set of artifacts – more later. Supporting Workflows Configuration & Change Mgmt Project Management Environment

32 The Architecure of RUP กระบวนการประกอบไปด้วย:
11/13/2018 The Architecure of RUP กระบวนการประกอบไปด้วย: “dynamic aspect” แกนแนวนอนเป็นการนำเสนอช่วงเวลาและแสดงให้เห็นถึงวงจรชีวิตของกระบวนการที่เกิดขึ้น การทำงานแบบไดนามิคของกระบวนการที่แสดงในรูปของเฟส และในแต่ละรอบการทำงาน cycles, phases และ iterations “static aspect” แกนแนวตั้งจะเป็นการนำเสนอกระบวนการหลัก ๆ ซึ่งมีการจัดกลุ่มกิจกรรมทางด้านวิศวกรรมซอฟต์แวร์ต่าง ๆ ไว้ เป็นการนำเสนอการทำงานแบบสแตติคของกระบวนการที่อยู่ในรูปของกิจกรรมต่าง ๆ activities, artefacts และ roles

33 11/13/2018 Major Models Business Model เพื่อทำความเข้าใจกับโครงสร้างและการทำงานทางธุรกิจขององค์กรที่ต้องการพัฒนาระบบ โดยเริ่มต้นจากการทำความเข้าใจกับปัญหาที่เกิดขึ้นและการกำหนดวิธีการแก้ไข จัดทำเอกสารที่แสดงถึงกระบวนการทางธุรกิจผ่านยูสเคสไดอาแกรม เพื่อให้เกิดความเข้าใจที่ถูกต้องระหว่างผู้ที่มีส่วนเกี่ยวข้อง Requirements เป็นการระบุว่าอะไรที่ระบบต้องทำในรูปของ Use Case ไดอาแกรมและเอกสารประกอบ ฟังก์ชันการทำงาน และกฎเกณฑ์ควบคุมต่าง ๆ ที่จำเป็นต่อการ ตัดสินใจในการพัฒนาระบบ

34 11/13/2018 Major Models Analysis and Design เป็นการทำงานที่ได้มาจาก Use case โดยตรง ทำหน้าที่เป็น abstraction ของแบบจำลองในการพัฒนาและซอร์สโค้ด แปลงความต้องการของระบบให้อยู่ในรูปของการออกแบบระบบ สร้าง classes, interaction diagrams รวมไปถึงสถาปัตยกรรมของระบบ Implementation ใน RUP จะเน้นไปที่การพัฒนาแบบองค์ประกอบร่วมในการนำเสนอการทำงานของระบบ กำหนดรายละเอียด ไว้อย่างชัดเจน ไม่ว่าจะเป็นการนำองค์ประกอบนั้น ๆ กลับมาใช้ใหม่ หรือพัฒนาองค์ประกอบใหม่ ๆ ขึ้นมาใหม่ ซึ่งจะช่วยให้การบำรุงรักษาสามารถทำได้ง่ายขึ้น ทดสอบองค์ประกอบร่วมในรูปของ Unit Test Integrated องค์ประกอบร่วมเข้าด้วยกัน

35 11/13/2018 Major Models Test เป็นกระบวนการที่เกิดขึ้นเพื่อให้แน่ใจได้ว่าความผิดพลาดได้ถูกตรวจสอบพบก่อนที่จะถึงขั้นตอนของการนำระบบไปติดตั้งใช้งาน ทดสอบการติดต่อกันระหว่างออปเจค เพื่อตรวจสอบความถูกต้องของการทำงานในขั้นตอนของการรวบรวมองค์ประกอบต่าง ๆ ของซอฟต์แวร์ เพื่อตรวจสอบว่าความต้องการของระบบได้ถูกนำไปพัฒนาให้เป็นระบบอย่างถูกต้อง Deployment เป็นขั้นตอนในการนำระบบไปใช้งาน ติดตั้งซอฟต์แวร์ หลาย ๆ กรณีอาจรวมไปถึงการวางแผนทดสอบแบบเบตา การย้ายข้อมูลจากระบบเก่าสู่ระบบใหม่ เป็นต้น

36 Major Process Workflows
11/13/2018 Major Process Workflows You can relate this back to previous slides that describe the system model and the many diagrams needed to fully communicate its content. One can consider all of the models listed here, taken together, to be “the system model.” The only model that is a little different is the business model. It describes the business at large, not just the automated part. The other models describe the information system that supports the business model. It is a good idea to point out that each of these models is incrementally developed across many iterations. Business Modeling Business Use-Case Model Business Object Model Requirements realized by Use-Case Model Analysis & Design implemented by Design Model Implementation verified by Implementation Model Test Test Model

37 Brief summary of supporting workflows
11/13/2018 Brief summary of supporting workflows Configuration & Change Management การอธิบายถึงวิธีการควบคุมผลลัพธ์ต่าง ๆ ที่ถูกสร้างขึ้นโดยผู้มีส่วนเกี่ยวข้องภายในโครงการ การอัพเดทพร้อมกัน การจำกัดการแจ้งผล และหลากหลายเวอร์ชัน Project Management ใช้เป็นแนวทางในการปฏิบัติสำหรับการวางแผน จัดการบุคลากร ประมวลผล และตรวจสอบความก้าวหน้าของโครงการ ใช้เป็นกรอบงานสำหรับการจัดการความเสี่ยง Environment เป็นการจัดสภาพแวดล้อมในการพัฒนาซอฟต์แวร์ ทั้งทางด้านกระบวนการและเครื่องมือที่ใช้ในการสนับสนุนการทำงานของทีมพัฒนา

38 Bringing It All Together...
11/13/2018 Bringing It All Together... In an iteration, you walk through all workflows Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration & Change Mgmt Project Management Environment Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Iterations

39 11/13/2018 What does RUP offer? RUP มีคำแนะนำในการพัฒนาซอฟต์แวร์สมัยใหม่ในรูปของ Best Practices ดังต่อไปนี้ Develop software iteratively Manage requirements Use component based architectures Visually model software Verify software quality Control changes to software

40 1. Manage Your Requirements
11/13/2018 1. Manage Your Requirements เป็นวิธีการค้นหา การจัดรูปแบบ และและการจัดทำเอกสารสำหรับฟังก์ชันการทำงานและกฎเกณฑ์ต่าง ๆ ของระบบ การจัดการความต้องการของระบบจะเน้นไปที่การจัดการต่อความเปลี่ยนแปลงความต้องการของระบบ โดยใช้ทรัพยากรในการพัฒนาน้อยที่สุด ในขั้นตอนนี้ใช้ Use cases เป็นเครื่องมือสำคัญในการจัดการความต้องการของระบบ Use-Case Model Implementation Model Test Model verifies realization influenced by Design Model

41 Adv : Manage Your Requirements
11/13/2018 Adv : Manage Your Requirements สามารถควบคุมระบบงานที่มีความซับซ้อนได้ดี ช่วยป้องกันไม่ให้เกิดความสับสนกับความต้องการของระบบ ปรับปรุงคุณภาพของระบบงาน โดยกระบวนการแบบเอกภาพได้จัดเตรียมเครื่องมือและวิธีการในการวัดคุณภาพที่สามารถประเมินได้ ช่วยลดเวลาและค่าใช้จ่ายในการแก้ไขความผิดพลาดจากความต้องการของระบบ ซึ่งโดยปกติจะมีค่าใช้จ่ายสูงมาก การจัดการความต้องการของระบบจะช่วยลดความผิดพลาดในการพัฒนาช่วงแรก ๆ ได้ ซึ่งจะเป็นการลดเวลาและค่าใช้จ่ายโดยอัตโนมัติ ช่วยปรับปรุงประสิทธิภาพการสื่อสารภายในทีม การจัดการความต้องการของระบบจะเกี่ยวข้องกับผู้ใช้ในช่วงต้น ๆ ของกระบวนการ ซึ่งจะช่วยให้แน่ใจได้ว่าระบบงานเป็นไปตามความต้องการของผู้ใช้

42 2. Develop Software Iteratively
11/13/2018 2. Develop Software Iteratively การพัฒนาระบบงานแบบนี้จะแบ่งงานออกเป็นหลาย ๆ รอบการทำงาน ซึ่งในแต่ละรอบการทำงานหนึ่ง ๆ ประกอบด้วยขั้นตอนของการกำหนดความต้องการของระบบ การวิเคราะห์ การออกแบบ การพัฒนาระบบ และการทดสอบระบบตามความต้องการของผู้ใช้ Initial Planning Requirements Analysis & Design Implementation Test Deployment Evaluation Management Environment

43 3. Component-based Architecture
11/13/2018 3. Component-based Architecture เป็นการกำหนดหรือออกแบบสถาปัตยกรรมที่เหมาะสมกับระบบไว้ก่อน เพื่อช่วยในการตัดสินใจว่าองค์ประกอบใดต้องการพัฒนา และองค์ประกอบใดที่ต้องการนำกลับมาใช้ใหม่ มีความยืดหยุ่นและง่ายต่อการเปลี่ยนแปลงโดยใช้ interfaces ที่มีการออกแบบไว้เป็นอย่างดี System- software Middleware Business- specific Application- Component-based Architecture with layers

44 4. Model Software Visually
11/13/2018 4. Model Software Visually เป็นแบบจำลองเชิงภาพที่แสดงให้เห็นถึงวิธีการกำหนดโครงสร้างและการทำงานของสถาปัตยกรรมและองค์ประกอบของระบบ ช่วยในการทำความเข้าใจกับระบบที่มีความซับซ้อน ปกปิดรายละเอียดและยอมให้การใช้สัญลักษณ์รูปกราฟิกแทนการเขียนโค้ด ใช้เป็นพื้นฐานในการพัฒนาโปรแกรม ค้นหาความต้องการของระบบอย่างละเอียด Code Classes Sub Systems Visual Modeling raises the level of abstraction

45 5. Verify Software Quality
11/13/2018 5. Verify Software Quality สร้าง Test Case เพื่อใช้สำหรับการทดสอบ scenario เพื่อให้แน่ใจได้ว่าความต้องการของระบบทั้งหมดได้ถูกนำไปพัฒนาอย่างถูกต้อง การตรวจสอบความสอดคล้องกับความต้องการที่ถูกระบุอยู่ในความต้องการของผู้ใช้งาน ใน RUP การทดสอบเกิดขึ้นตลอดช่วงวงจรชีวิตของการพัฒนาระบบ ซึ่งช่วยให้การค้นพบความผิดพลาดเกิดขึ้นในช่วงต้น ๆ และช่วยลดค่าใช้จ่ายในการแก้ไข Development Deployment Cost Software problems are 100 to 1000 times more costly to find and repair after deployment

46 6. Control Changes to Software
11/13/2018 6. Control Changes to Software การควบคุม การตรวจสอบติดตามความเปลี่ยนแปลงที่เกิดขึ้นสามารถทำได้โดยใช้วิธีการพัฒนาแบบ iterative การสร้าง workspaces ที่ปลอดภัยสำหรับนักพัฒนาแต่ละคน ป้องกันผลกระทบจากการเปลี่ยนแปลงแก้ไขไปยัง workspaces อื่น แสดงรายละเอียดของการ integration แบบอัตโนมัติ ALERT REPORT Parallel Development Workspace Management Process Integration Build Management

47 J2EE Roadmap System Models
11/13/2018 J2EE Roadmap System Models realized by refined into defined in Implementation Model Deployment Model Use Case Model Design Model refined into realized by refined into refined into Data Model User-Experience Model

48 Team-Unifying Approach
11/13/2018 Team-Unifying Approach Designer / Developer Analyst Tester Architect Tool Specialist Release Engineer Project Management The RUP offers: A Team-Unifying Approach The Rational Unified Process unifies the entire software development team and enhances team communication by providing each team member with one knowledge base, one modeling language and one view of how to develop software. Everybody is involved; their roles and activities are well documented and are publishable over an intranet… Re-iterate the HHGTTG and the Tower of Babel...

49 11/13/2018

50 11/13/2018

51 11/13/2018

52 11/13/2018