.:: ยินดีต้อนรับเข้าสู่เว็บไซต์ ::.

 

 

 

 

 

05530381 Software Engineering
  วิศวกรรมซอฟต์แวร์
  สังกัด บริหารธุรกิจ, บริหารธุรกิจ
  หน่วยกิต 3 (3-0-3)
อาจารย์ จันทิมา เอกวงษ์

เนื้อหาที่เกี่ยวข้อง

 

 

  • ความรู้เบื้องต้นเกี่ยวกับวิศวกรรมซอฟต์แวร์
  • การวางแผนพัฒนาซอฟต์แวร์
  • Software Process  Model
  • Activity Planning
  • Software Effort  Estimate  การประมาณการ
  • Risk Management
  • Resource  Allocation การจัดสรรทรัพยากร
  • Monitoring and Control
  • Outsource  
  • การพัฒนาซอฟต์แวร์

 

Software Process  Model

Process  – เป็นกระบวนการ ลำดับของขั้นตอนต่าง ๆ ในการ                  
                 ดำเนินงานการพัฒนาและบำรุงรักษาซอฟต์แวร์     
    - เป็นพื้นฐานที่ใช้พัฒนาระบบ
Process  Model   เช่น   RAD, JAD  , Waterfall Model ,  V-Process Model , Spiral Model

Waterfall  Model

•เหมาะกับ Project ที่มีขนาดใหญ่
•Waterfall  Model   แบ่งกระบวนการทำงานออกเป็นขั้นตอนต่าง ๆ ขั้นตอนในแต่ละช่วงจะสืบเนื่องกันไปจากขั้นหนึ่งสู่อีกขั้นหนึ่งตามลำดับเหมือนสายน้ำตก  สามารถย้อนกลับไปปรับปรุงขั้นตอนก่อนหน้าได้ตามลำดับ
•ข้อดี Project มีความถูกต้องและตรงตามความต้องการ  การควบคุมเป็นอย่างมีประสิทธิภาพ
•ข้อเสีย  ใช้ระยะเวลานาน

RAD  (Rapid Application Development)

•วิธีการและเครื่องมือที่ทำให้การพัฒนาระบบเร็วขึ้นโดยเฉพาะระบบที่มี user เข้ามาเกี่ยวข้องเป็นส่วนสำคัญ  เช่น การนำโปรแกรมเก่ามาเรียบเรียงใหม่   RAD สามารถทำให้โปรแกรมเสร็จเร็ว  เวลาทำควรอยู่ใน 60-90 วัน  โดยใช้  Tool ต่าง ๆ  เช่น  Case Tool   เน้นที่  Business  Requirement  โดยเร่งทำ Requirement  หลักก่อน

•เป็น Methodology ที่พัฒนาขึ้นในช่วงปี ค.ศ.1990 เพื่อแก้ไขจุดอ่อนของ Methodology แบบ Structured Design ด้วยการปรับระยะในวงจรการพัฒนาระบบ ให้มีขั้นตอนการทำงานที่รวบรัดมากขึ้น มีการเลือกใช้เครื่องมือ (Tools) และเทคนิค (Techniques) ต่าง ๆ เช่น  CASE Tools, JAD และโปรแกรมภาษาที่ช่วยสร้างโค้ดโปรแกรม ช่วยออกแบบหน้าจอ รายงานและแบบฟอร์มต่าง ๆ ได้อย่างรวดเร็ว 
•RAD ได้มีการนำเทคนิคและเครื่องมือชนิดต่าง ๆ เข้ามาสนับสนุนการพัฒนาระบบ ให้สามารถดำเนินการในขั้นตอนต่าง ๆ ใน SDLC ได้ด้วยการใช้ระยะเวลาที่น้อยกว่าแบบ SSADM ตัวอย่างเทคนิคและเครื่องมือดังกล่าว ข้อเสียของ RAD Methodology  คือ การเปลี่ยนแปลงความต้องการของผู้ใช้อยู่ตลอดเวลา เนื่องจากผู้ใช้ได้ทดลองใช้โปรแกรมต้นแบบที่สามารถสร้างและแก้ไขได้ง่าย

Joint Application Development (JAD)

•เป็นแนวคิดของของบริษัท IBM  คือทำอย่างไรให้คนที่เกี่ยวข้องกับ Requirement มาตัดสินใจร่วมกัน  โดยทำแบบ Workshop ร่วมกัน
•คนที่จะมาร่วมปรึกษาหารือกันตัดสินใจร่วมกัน ได้แก่
–Euceutive Sponsor - ผู้บริหารระดับสูง  เชิญมาเพื่อมีอำนาจในการตัดสินใจ
–Project Manager หรือ Project Leader
–Facilitator  เช่น  Consultant  หรือ  ผู้ที่เคยทำ , คนในองค์กรที่มีประสบการณ์
–Recorder / Clerk / Secretary  เช่น  คนจดรายงาน
–Participants คนที่เกี่ยวข้อง เช่น user ที่เกี่ยวข้อง
–IT  Development  เช่น โปรแกรมเมอร์ Observers ผู้สังเกตการณ์
•ข้อดี  เพื่อให้ Project เสร็จเร็วและตรงตามความต้องการของผู้ใช้และองค์กร
•ข้อเสีย 
–รวมคนยาก
–เสียเวลาในการทำงานประจำ
–ใช้เวลามาก
Prototyping Model
การทำ Prototypes  มี 2 แบบ
1.Throw – away prototypes ได้แก่ prototypes ที่ทำให้ user มองเห็นภาพของระบบ เช่น หน้าจอ  ไม่จำเป็นต้องใช้เครื่องที่ Implement จริง ๆ ทำเสร็จยกเลิกไป  โดยส่วนใหญ่ใช้ Desktop ทำ Prototypes
2.Evalutionary Prototypes  เป็น Prototypes ใช้ทำงานกับSoftware และเครื่องที่ใช้งานจริง  ส่วนมากใช้กับ user ที่อยู่ในหน่วยงานเดียวกัน  โปรแกรมอาจเสร็จทีละส่วน แล้วให้ user ทดสอบโดยไม่ต้องรอให้เสร็จทั้งหมด
ข้อดีของการทำ Prototypes
•เรียนรู้จาก Software จริง
•ช่วยสื่อสารระหว่าง  user กับ Developer  เพื่อทำให้ทราบว่างานก้าวหน้าไปถึงไหน
•user  มีส่วนร่วมในการทำ
•ทำให้ Requirement ชัดเจน (ใช่หรือไม่ ที่ต้องการ)
•การ Test Prototypes ทำให้ Project สมบูรณ์
•ลดความต้องการ  Document-user เห็นแล้วเข้าใจ
•ลดต้นทุนในการ Maintenance - user เคยเห็นแล้ว   จะทำให้ลดต้นทุน , ค่าใช้จ่าย ในการ Maintenance   ลงเหลือ 10-20 % ส่วนใหญ่ Maintenance ในส่วนของ Error
•ลดข้อจำกัดของ Feature ต่างๆ ในการทำงาน
•ทำให้เห็นผลลัพธ์ว่าเป็นอย่างไร
ข้อเสียของ Prototypes
  • user เห็น Prototypes  เข้าใจว่าเสร็จแล้ว  มักต้องการรู้ว่าจะใช้ได้เมื่อไหร่
  • ไม่มี Security , Response Time
  • ควบคุมยาก เมื่อเห็นแล้ว user มักจะมีการเปลี่ยนแปลง Requirement
  • เสียเวลาและค่าใช้จ่ายในการทำ Prototypes
  • ประสิทธิภาพของจริงกับ Prototype ต่างกันได้ เช่น Prototypes เร็ว ของจริง ช้า , Prototypes ช้าของจริงเร็ว
  • user กับ Developer ไม่ได้อยู่ที่เดียวกันทำให้ไม่สะดวกในการทำPrototype
รูปแบบของการทำ Prototypes
•Mock – ups  ทำหน้าจอให้เห็น  แต่ใช้จริงไม่ได้ (ใช้อธิบาย)
•Simulated  Interaction  จำลองการใช้งานจริง เช่น การกรอกข้อมูล การเรียกใช้ข้อมูล แต่ใช้งานจริงไม่ได้ (วิธีนี้นิยมมาก)
•Partial  working Model แบ่งเป็น
–Vertical (ลึก)  สามารถใช้งาน Feature บางส่วนได้จริง (ไม่ทั้งหมด) ใช้กับ Simulate
–Horizontal (กว้าง) มี Feature ครบ ทำให้ทราบว่ามี Feature อะไรบ้าง แต่ใช้งานไม่ได้ทั้งหมด (ไม่ลึก) ใช้กับ Mock – up
ข้อเสนอแนะในการทำ Prototypes
•การทำ  Prototypes ควรเป็นแบบได้
•ให้ user สามารถ Interface กับระบบได้
•ฟังก์ชั่นต่าง ๆ ของระบบ  ควรทำให้ชัดเจน เพื่อให้ได้ Feature ครบ
ปัญหาของการทำ Prototypes  คือ ควบคุมการเปลี่ยนแปลงยาก เช่น เปลี่ยน Process ประมาณ 60% เปลี่ยนหน้าจอ 35%