ตอบคำถามบทที่ 3 - 4

ตอบคำถามบทที่ 3 - 4

โจทย์

1. จงสร้างปฐมภูมิแกนต์ (Gantt Chart)
ตอบ

2. จงสร้างเครือข่าย PERT
ตอบ

3. โครงการนี้ใช้เวลาในการดำเนินงานกี่วัน
ตอบ จากการพิจารณเครือข่าย PERT ในข้อที่ 2 สามารถนำมาคำนวณเป็นสายงานได้ 3 สายดังนี้
        สายงานที่ 1 คือ P-Q-R-S = 31 วัน
        สายงานที่ 2 คือ P-T-Z-S = 32 วัน
        สายงานที่ 3 คือ X-Y-Z-S = 34 วัน
เนื่องจากโจทย์ไม่ได้กำหนดการเร่งระยะเวลาการดำเนินโครงการ ทำให้โครงการนี้มีระยะเวลา
การดำเนินงาน 34 วัน


4. จงหาเส้นทางวิกฤตพร้อมระบุกิจกรรมวิกฤต
ตอบ จากข้อที่ 3 สายงานวิกฤตคือ สายงานที่ 3 ซึ่งใช้ระยะเวลาดำเนินงานสูงสุด 34 วัน

ตอบคำถามบทที่ 2

1. จงเปรียบเทียบจุดเด่นจุดด้อยของระเบียบวิธีปฎิบัติของวิศวกรรมซอฟต์แวร์ ระหว่างวิธีเชิงโครงสร้าง (Structured Approach) และวิธีเชิงวัตถุ (Object-Oriented Approach)
    ตอบ วิธีเชิงโครงสร้าง
              จุดเด่น  1. เป็นวิธีการวิเคราะห์ออกแบบเชิงโครงสร้าง
                             2. มีการแบ่งระบบออกเป็นส่วนย่อยๆ
                             3. มีลักษณะเป็นลำดับชั้น
              จุดด่อย 1. การวิเคราะห์และรวบรวมข้อมูลมีการแยกออกเป็นส่วนๆ ทำให้ใช้เวลานาน
                             2. ต้นทุนสูง
                             3. เนื่องจากใช้เวลานาน ทำให้เสี่ยงต่อการเปลี่ยนแปลงความต้องการของผู้ใช้
            วิธีเชิงวัตถุ
              จุดเด่น  1. การวิเคราะห์และออกแบบทำได้อย่างรวดเร็ว
                             2. รองรับระบบงานที่มีความซับซ้อนสูง
                             3. ทันต่อการเปลี่ยนแปลงความต้องการของผู้ใช้
              จุดด่อย 1. ต้องใช้ผู้ที่มีความสามารถความเชี่ยวชาญในการเขียนโปรแกรมสูง
 2. Waterfall model แตกต่างจาก Spiral model อย่างไร จงอธิบายตามความเข้าใจของนักศึกษา
    ตอบ  Waterfall model แตกต่างจาก Spiral model 2 อย่างด้วยกัน คือ

          1. ขั้นตอนในการพัฒนาระบบ
         2. การวนกลับไปแก้ไขในขั้นตอนก่อนหน้า Waterfall model จะย้อนกลับไปแก้ไขในขั้นตอนก่อนหรือขั้นตอนที่ผ่านมาแล้ว ก็ต่อเมื่อเกิดปัญหาในการพัฒนา หรือต้องการเพิ่มความต้องการในด้านต่างๆ ให้กับระบบ ซึ่ง Spiral model จะต่างกันคือเป็นการวนซ้ำตั้งแต่ต้นจนจบแล้ววนซ้ำไปเรื่อยๆ
3.ในฐานะที่นักศึกษาเป็นนักวิศวกรรมซอฟต์แวร์ ควรจะเลือกพิจารณาใช้แบบจำลองกระบวนการผลิตซอฟต์แวร์ (Software Process Model) แบบใด เพราะเหตูใด จงให้เหตุผลประกอบการเลือก

    ตอบ  Increment delivery ซึ่งเป็นแบบจำลองการผลิตซอฟต์แวร์ที่มีการพัฒนาโดยแบ่งโปรแกรมออกเป็นส่วนย่อยๆ หลายๆ ส่วน ซึ่งจะทำการพัฒนาเพิ่มเติมไปเรื่อยๆ ที่ละชุด เมื่อพัฒนาจนเสร็จแล้ว จึงนำมารวมกันเป็นระบบใหญ่ แล้วทำการทดสอบระบบทั้งระบบ สาเหตุที่เลือกแบบจำลองนี้ เพราะเป็นแบบจำลองที่มีการวางแผนโครงสร้างและกำหนดความต้องการทั้งหมด จนเสร็จสิ้นก่อนแล้วจึงเริ่มพัฒนาที่ละฟังชังก์ชั่นของระบบ แล้วค่อยนำมารวมกัน

ตอบคำถามบทที่ 1

ตอบคำถามบทที่ 1

ตอบคำถามบทที่ 1
1. จงยกตัวอย่างของผลกระทบของซอฟต์แวร์ ทั้งทางด้านบวกและลบที่มีต่อสังคม
ตอบ  ด้านบวก                                                                                                                              
ช่วยส่งเสริมความสะดวกสบายของมนุษย์ เทคโนโลยีสารสนเทศช่วยให้ความเป็นอยู่ของมนุษย์ดีขึ้น ช่วยส่งเสริมให้มี ประสิทธิภาพในการทำงาน ทำให้มนุษย์มีเวลาว่างเพื่อใช้ ในทางที่เกิดประโยชน์ทางด้านอื่นมากขึ้น
ช่วยส่งเสริมสติปัญญาของมนุษย์ให้ดีขึ้น เพราะจะช่วยให้มนุษย์ทำงานได้เร็ว ถูกต้องแม่นยำ และสามารถเก็บข้อมูลได้มากอีกด้วย
ช่วยส่งเสริมงานทางด้านเศรษฐกิจ ทำให้กระแส เงินหมุนเวียนได้อย่างกว้างขวาง ผู้ผลิตในสายอุตสาหกรรม จะผลิตสินค้าได้มาก และลดต้นทุนในการทำ
ช่วยให้มนุษย์มีความคิดใหม่ๆในการพัฒนาซอฟต์แวร์ให้มีการเจริญเติบโตมากยิ่งขึ้น
ช่วยให้มนุษย์สะดวกสบายในการติดต่อสื่อสารต่างๆได้ดียิ่งขึ้น

      ด้านลบ
ทำให้เกิดอาชญากรรม เทคโนโลยีสารสนเทศสามารถนำมาใช้ในการก่อให้เกิดอาชญากรรมได้ เช่น การลับลอกนำข้อมูลสำคัญไปใช้ การวางแผนการโจรกรรมทางธนาคาร เป็นต้น
ทำให้เกิดการแพร่วัฒนธรรมและกระจายข่าวสารที่ไม่เหมาะสมอย่างรวดเร็ว
ทำให้สังคมออนไลน์เกิดความวุ่นวาย เพราะใช้ในการสื่อสารที่ผิด และไม่เหมาะสม
ในการใช้ซอฟต์แวร์ที่มีลิขสิทธิ์ จะต้การองเสียค่าใช้จ่ายสูง จึงเกิดการละเมิดลิขสิทธิ์เกิดขึ้น
ในการใช้ซอฟต์แวร์ในการควบคุมเครื่องจักร ถ้าเกิดความบกพร่องของระบบก็จะทำให้การทำงานหยุดทั้งระบบ และไม่สามารถทำงานต่อได้ จึงต้องทำการแก้ไขจนเสร็จถึงจะสามารถปฏิบัติงานต่อได้ จนบางครั้งอาจทำให้การทำงานล่าช้าได้
2. จงอธิบายเกี่ยวกับ Software Crisis ตามความเข้าใจของนักศึกษา
     ตอบ Software Crisis หรือที่เรียกว่า วิกฤตทางด้านซอฟต์แวร์ ซึ่งเปรียบเสมือนการทำงานที่ไม่บรรลุตามวัตถุประสงค์ทำใหเกิดปัญหา เช่น เกิดข้อผิดพลาดขึ้นบ่อย ไม่สามารถสร้างความพึงพอใจให้กับลูกค้าได้ งานไม่เสร็จตามที่ำหนด งบบานปลาย เป็นต้น

3. จงยกตัวอย่างศอฟต์แวร์ที่นักศึกษาคิดว่าเป็นซอฟต์แวรืที่มีคุณภาพ แล้วนำมาวิเคราะห์หาคุณลักษณะของซอฟต์แวร์ที่ดี ว่าตรงตามคุณลักษณะใดบ้าง
ตอบ ยกตัวอย่าง Microsoft office  โคยคุณสมบัติที่ดีของซอฟต์แวร์ทางด้าน Software Engineering คือ
การใช้งานที่ง่ายที่คุณต้องการ
ในปัจจุบันการใช้งาน Microsoft office ผู้ใช้จะไม่ต้องกังวลในเรื่องของการใช้งาน เพราะสามารถจะเรียนรู้การใช้งานได้ด้วยตัวเอง เนื่องจากมีรูปแบบที่เรียบง่ายในการใช้งาน และไม่ยุ่งยากถึงแม้จะเป็นรุ่นใหม่ก็
เข้าถึงเครื่องมือที่เหมาะกับงานที่กำลังทำอยู่ได้ง่ายขึ้น ค้นหาคำสั่งที่จำเป็นต้องใช้ได้ทุกเมื่่อและทุกตำแหน่งที่คุณต้องการเรียกใช้
ความสามารถด้านประสิทธิภาพ Microsoft Office  เป็นโปรแกรมที่ได้รับการยอมรับในประสิทธิภาพการทำงาน เนื่องจาก ส่วนติต่อกับผู้ใช้ที่ (User Interface) ใช้งานง่าย ตรงตามความต้องการของผู้ใช้ และการใช้งานทรัพยากรทางด้าน Hardware ไม่สูงมากทำให้ประหยัดทรัพยากรการทำงานมากขึ้น
สร้างฐานข้อมูลได้รวดเร็ว ไม่ต้องเสียเวลาเรียนรู้และสามารถนำคอมโพเนนต์กลับมาใช้ใหม่ได้
4. นักศึกษาคิดว่า "นักวิศวกรรมซอฟต์แวร์" ควรมีทักษะความรู้ ความเชี่ยวชาญในด้านใดบ้าง จงอธิบาย
ตอบ        1. ในการเป็นวิศวกรรมที่ดีจะต้องเรียนรู้และคำนึงถึงความต้องการของผู้ใช้ และทำการออกแบบให้ผู้ใช้สามารถเข้าใจได้ง่ายยิ่งขึ้น

                2. ควรจะมีทักษะการใช้โปรแกรม ให้มีความชำนาญหลายๆโปรแกรม เพื่อลดเวลา และต้นทุนในการทำงาน                                                                                                                                            
                3. จะต้องมีความรับผิดชอบต่องานที่ได้รับมอบหมาย
                4. จะต้องตรงตามความต้องการของลูกค้า ตรงต่อเวลา และตรงกับงานที่ได้รับหมอบหมาย

Chapter 6

 Requirements Engineering Processes

Objectives
1.      เพื่ออธิบายถึงกิจกรรมที่สำคัญของการทำ Requirements และความสัมพันธ์ต่างๆ
2.      แนะนำเทคนิคการค้นหาและวิเคราะห์ Requirements
3.      อธิบายการยืนยัน Requirements และหน้าที่ของผู้ตรวจทาน
4.      อธิบายหน้าที่ของการจัดการ Requirements ในการสนับสนุนกระบวนการทางวิศวกรรมของ Requirements อื่น

Topics Covered
1.      การศึกษาความเป็นไปได้
2.      การค้นหาและการวิเคราะห์
3.      การตรวจทานยืนยันความเที่ยงตรง
4.      การบริหารจัดการ



Requirements engineering processes
1.      กระบวนการที่ใช้สำหรับ Requirements มีหลากหลายขึ้นอยู่กับโดเมนของระบบงาน ,ผู้เกี่ยวข้องและองค์กรที่ทำ Requirements
2.      อย่างไรก็ตามกิจกรรมที่เหมือนกันก็คือ
3.      การค้นหา (ล้วงความลับ)
4.      การยืนยันความเที่ยงตรง
5.      การบริหารจัดการ

Requirements engineering

Feasibility studies
1.      การศึกษาความเป็นไปได้ ช่วยตัดสินใจว่าคุ้มค่าหรือไม่
2.      การศึกษาแบบใกล้ชิด ตรวจเช็คว่า
3.      ว่าระบบจะส่งผลตอบแทนตามเป้าหมาย
4.      ว่าระบบสามารถทำได้ด้วยเทคโนโลยีปัจจุบัน และไม่เกินงบประมาณ
5. ว่าระบบสามารถนำไปใช้ร่วมกับระบบอื่นๆ ที่ใช้อยู่ปัจจุบัน
Feasibility study implementation
1.      ขึ้นอยู่กับการประเมินข้อมูล (ว่าต้องการอะไร) การเก็บข้อมูล การเขียนรายงาน
2.      คำถามของคนในองค์กร
3.      อะไรจะเกิดขึ้นถ้าไม่ได้นำไปใช้?
4.      ปัญหาในกระบวนการปัจจุบันมีอะไรบ้าง?
5.      ระบบใหม่จะช่วยได้อย่างไร?
6.      จะมีปัญหาในการรวบรวมหรือไม่?
7. สิ่งอำนวยความสะดวกที่จะรองรับระบบที่เสนอขึ้นมามีอะไรบ้าง?

Elicitation and analysis
1.      บางครั้งเรียกว่า การค้นหาความต้องการ
2.      ประกอบด้วยเจ้าหน้าที่เทคนิคทำงานร่วมกับลูกค้า เพื่อหาโดเมนของแอปพลิเคชั่น , บริการที่ระบบจะมีให้รวมถึงข้อจำกัดในการใช้งาน
3. อาจประกอบด้วย ผู้ใช้ , ผู้บริหาร , วิศวกรที่ซ่อมบำรุง , ผู้เชี่ยวชาญโดเมน , สหภาพ ฯลฯ เหล่านี้เรียกว่า ผู้มีส่วนได้-ส่วนเสีย (Stakeholders)

Problems of requirements analysis
1.      Stakeholders ไม่ทราบความต้องการที่แท้จริงของตัวเอง
2.      Stakeholders แจ้งความต้องการด้วยภาษาที่เข้าใจเองฝ่ายเดียว
3.      Stakeholders มีความต้องการขัดแย้งกันเอง
4.      องค์กรและปัจจัยการเมือง อาจส่งผลถึงความต้องการ
5. ความต้องการเปลี่ยนไปในระหว่างการทำวิเคราะห์ Stakeholders คนใหม่ เข้ามามีส่วนร่วมทำให้ภาวะทางธุรกิจเปลี่ยนไป






Process activities
1.      การค้นหาความต้องการ
2.      พูดคุยสอบถามผู้มีส่วนได้เสีย เพื่อค้นหาว่าเขาต้องการอะไรบ้าง ความต้องการหลักๆ ก็จะพบได้จากการพูดคุยนี้
3.      การจัดชั้นลำดับความสำคัญ
4.      จัดกลุ่มความต้องการที่เกี่ยวข้องกันไว้ ในกลุ่มเดียวกัน
5.      จัดลำดับความสำคัญก่อนหลัง
6.      อะไรมีความสำคัญต้องการทำก่อน อะไรที่ขัดแย้งกันต้องขจัดออกไป
7.      ทำเอกสาร
8. สิ่งที่จำเป็นต้องทำต้องบันทึกไว้เป็นลายลักษณ์อักษร และเป็นข้อมูลป้อนใส่ในการทำโปรแกรมครั้งต่อไป

Requirements discovery
1.      คือกระบวนการรวบรวมข้อมูลที่เกี่ยวกับระบบที่นำเสนอ และระบบปัจจุบัน แล้วกลั่นกรองหาความต้องการของผู้ใช้ และสิ่งที่จำเป็นสำหรับระบบ จากข้อมูลเหล่านั้น
2. แหล่งของข้อมูลรวมถึงเอกสาร , ระบบที่เป็นเจ้าของและรายละเอียดของระบบที่คล้ายคลึงกัน

ATM stakeholders
1.      ลูกค้าของธนาคาร
2.      ตัวแทนจากต่างธนาคาร
3.      ผู้จัดการธนาคาร
4.      เจ้าหน้าที่ที่เคาน์เตอร์
5.      ผู้บริหารอ่านข้อมูล
6.      ผู้จัดการด้านความปลอดภัย
7.      ฝ่ายการตลาด
8.      วิศวกรผู้ดูแลฮาร์ดแวร์และซอฟแวร์
9.               ผู้ออกกฎหมายควบคุมธนาคาร

Viewpoints
1.      วิวพอยต์ คือ การจัดวางโครงสร้างความต้องการ เพื่อแสดงมุมมองของผู้มีส่วนได้เสียที่มีความคิดเห็นแตกต่างกัน
2.                การวิเคราะห์มุมมองหลายๆ ด้านนั้นสำคัญ เนื่องจากวิธีที่คุณต้องการที่จะวิเคราะห์ความต้องการ มิได้มีเพียงทางเดียว

Types of viewpoint
1.      ผู้ที่ติดต่อด้วย
2.      คือคนหรือระบบที่ติดต่อกับระบบ เช่น ATM ลูกค้า และอ่านข้อมูลบัญชีเงินฝาก ก็คือ ทัศนะของผู้ติดต่อ
3.      ผู้ได้รับผลประโยชน์ทางอ้อม
4.      คือผู้ได้รับผลประโยชน์ มิได้เป็นผู้ใช้ระบบ แต่มีอิทธิพลต่อความต้องการ เช่นใน ATM ผู้จัดการ , เจ้าหน้าที่รักษาความปลอดภัย ก็จะมีทัศนะทางอ้อม
5.      โดเมน
6. คุณสมบัติและข้อจำกัดของโดเมน ซึ่งมีผลต่อความต้องการ ใน ATMก็คือมาตรฐานการสื่อสารระหว่างธนาคาร

Viewpoint identification
1.      การจำแนกทัศนะ โดยใช้
2.      ผู้ให้และผู้รับบริการจากระบบ
3.      ระบบที่ติดต่อโดยตรงกับระบบที่กำลังทำใหม่
4.      กฎระเบียบและมาตรฐาน
5.      แหล่งของธุรกิจและความต้องการในหน้าที่รอง
6.      วิศวกรผู้พัฒนาระบบและยังคงรักษาระบบนั้นไว้
7. มุมมองของนักการตลาดและนักธุรกิจอื่นๆ


Interviewing
1.      การสัมภาษณ์อย่างเป็นทางการหรือส่วนตัว ทีม Requirements จะถามคำถามเกี่ยวกับระบบปัจจุบันและระบบที่ต้องการใหม่
2.      การสัมภาษณ์แบ่งเป็น 2 ชนิด
3.      แบบปิด คือ เตรียมคำถามมาให้ตอบ
4. แบบเปิด คือ ไม่มีการกำหนดวาระ และคำถามจะเป็นการถามสด โดยตรงจากผู้เป็นเจ้าของระบบ

Interviews in practice
1.      โดยทั่วไปจะผสมระหว่างการสัมภาษณ์แบบเปิดและปิด
2.      การสัมภาษณ์เหมาะสำหรับทำความเข้าใจโดยรวมว่าเจ้าของระบบต้องการติดต่อกับระบบอย่างไร
3.      การสัมภาษณ์ไม่เหมาะสำหรับหาความต้องการในโดเมน
4.      วิศวกรไม่สามารถเข้าใจศัพท์เฉพาะของโดเมน
5. ความรู้ในโดเมนบางครั้งก็คุ้นจนเราคิดว่ายากที่จะปะติดปะต่อหรือไม่คุ้มค่า

Effective interviewers
1.      ต้องมีใจเปิดกว้าง , ยินดีรับฟังเจ้าของระบบ ไม่ควรคิดล่วงหน้าว่าความต้องการควรเป็นอะไร
2. ควรตั้งใจถามหรือนำเสนอ แต่ไม่ควรถามแบบตอบไม่ได้ เช่น        “ What do you want? ”

Scenarios
1.      บทละครเป็นตัวอย่างจริงที่แสดงให้เห็นว่าระบบใช้งานได้อย่างไร
2.      ควรจะมีสิ่งต่างๆ ดังนี้
3.      บอกสถานการณ์ตอนเริ่มเรื่อง
4.      บอกการดำเนินเรื่อง
5.      บอกสาเหตุของความผิดพลาดที่อาจจะเกิดขึ้น
6.      ข้อมูลเกี่ยวกับกิจกรรมที่เกิดพร้อมๆกัน
7. บอกสถานะของเรื่องตอนจบ




Use cases
1.      Use-cases เป็นเทคนิคแบบบทละคร ที่มีอยู่ใน UML ซึ่งจะอธิบายการติดต่อโต้ตอบของตัวแสดงในเรื่อง
2.      ชุดของ Use-cases จะอธิบายการติดต่อโต้ตอบทั้งหมดของระบบ
3.      ผังเรียงลำดับสามารถช่วยเพิ่มเติมรายละเอียดให้ Use-cases ด้วยการแสดงลำดับชั้นของเหตุการณ์ในระบบ
Social and organisational factors
1.      ระบบซอฟแวร์ที่ใช้ในสังคมและองค์กรจะส่งผลกระทบหรือควบคุมSystem Requirements
2.      ปัจจัยทางด้านสังคมและองค์กรไม่ได้เป็นวิวพอยท์เดียว แต่ส่งผลกระทบต่อวิวพอยท์ทั้งหมด
3.      นักวิเคราะห์ที่ดีต้องสำนึกถึงปัจจัยต่างๆเหล่านี้ แต่ปัจจุบันยังไม่มีหนทางที่จะมาช่วยการวิเคราะห์ได้

Ethnography
1.      นักสังคมวิทยาทุ่มเทเวลาอย่างมาก เพื่อสังเกตและวิเคราะห์พฤติกรรมการทำงานของคน
2.      คนธรรมดาไม่ต้องอธิบายหรือปะติดปะต่อเรื่องการทำงานของคน
3.      ปัจจัยความสำคัญของสังคมและองค์กรจะสังเกตเห็นได้เอง
4.      การศึกษาโปรแกรมที่มาจากระบบต่างๆ ทำให้ทราบถึงผลงานที่ละเอียดซับซ้อนได้มากกว่าการศึกษาระบบงานธรรมดา


Focused ethnography
1.      พัฒนามาจากโครงการศึกษากระบวนการควบคุมการจราจรทางอากาศ
2.      ผสมผสาน ethnography กับ prototyping
3.      ปัญหาที่ตอบไม่ได้จากการทำ Prototype ก็ต้องมาดูที่การวิเคราะห์ethnographic
4.      ปัญหาเกี่ยวกับ ethnographic ก็คือ เมื่อศึกษาการปฏิบัติงานที่มีอยู่ในปัจจุบันอาจต้องอาศัยพื้นฐานทางประวัติการทำงานของระบบนั้น ซึ่งอาจเป็นข้อมูลที่ไม่ได้ใช้แล้ว


Scope of ethnography
Ethnography เหมาะสำหรับการหาความต้องการ 2 ชนิด คือ
1.      ความต้องการที่มาจากการทำงานจริงมากกว่าที่เขียนไว้ในระเบียบปฏิบัติงาน
2.      ความต้องการที่มาจาก การร่วมมือกัน และความเข้าใจในหน้าที่รับผิดชอบของผู้อื่น

Requirements validation
1.      เกี่ยวข้องกับการสาธิตให้เห็นว่าความต้องการที่เป็นนิยามของระบบนั้นเป็นสิ่งที่ลูกค้าต้องการจริงๆ
2.      ข้อผิดพลาดที่พบในความต้องการนั้นมีราคาสูง ดังนั้นการยืนยันจึงสำคัญ
3. การแก้ข้อผิดพลาดจาก Requirements หลังจากส่งมอบงานจะแพงเป็น 100 เท่าของการแก้ข้อผิดพลาดจากการใช้งาน

Requirements checking
1.      ยืนยัน – ฟังก์ชั่นของระบบได้ตามความต้องการหรือไม่?
2.      สม่ำเสมอ – ขัดแย้งกันเองหรือไม่?
3.      ครบถ้วน – ฟังก์ชั่นที่ลูกค้าต้องการครบหรือไม่?
4.      เป็นจริงได้ – ความต้องการสามารถทำให้เป็นจริงได้ ภายใต้งบประมาณที่และเทคโนโลยีที่มีอยู่หรือไม่?
5. ตรวจทานได้ - ความต้องการสามารถตรวจทานได้

Requirements validation techniques
1. Requirements reviews
2. ทำการวิเคราะห์ด้วยตัวเองอย่างมีระบบ
3. Prototyping
4. ใช้ตัวต้นแบบตรวจเช็ค – อ่าน Text บทที่ 17
5. Test-case generation
6. ใช้ข้อทดสอบตรวจเช็คความต้องการ

Requirements reviews
1.      ทำการรีวิวสม่ำเสมอในช่วงที่ทำ Requirements
2.      ทั้งลูกค้าและคู่สัญญา ต้องร่วมมือกันตรวจสอบ
3. รีวิว (เอกสารทั้งหมด) อย่างเป็นทางการ หรือไม่เป็นทางการ       การติดต่อสื่อสารที่ดีระหว่างผู้ที่พัฒนาโปรแกรม , ลูกค้า และผู้ใช้ สามารถลดปัญหาได้ในตอนต้น

Review checks
1. ตรวจทานได้ – ความต้องการนั้นนำไปใช้ทดสอบได้หรือไม่
2. เข้าใจได้ – ความต้องการนั้นเข้าใจได้
3. ติดตามได้ – สามารถติดตามต้นตอของความต้องการได้
4. ปรับตัวได้ - สามารถปรับปรุงได้โดยไม่กระทบต่อความต้องการอื่นๆ

Requirements management
1.      เป็นกระบวนการบริหารการแก้ไขปรับปรุงความต้องการ ในขณะที่พัฒนาระบบ
2.      ความต้องการส่วนใหญ่จะไม่ครบถ้วนและไม่สอดคล้องต่อเนื่องกัน
3.      ความต้องการที่เพิ่มขึ้นเนื่องจากภาวะธุรกิจเปลี่ยนไป ทำให้ต้องทำความเข้าใจในระบบใหม่ให้ดีขึ้น
4. มุมมองที่ต่างกันบ่อยครั้งจะขัดแย้งกันเอง

Requirements change
1.      ลำดับความสำคัญเปลี่ยนแปลงไประหว่างการพัฒนาระบบ
2.      ลูกค้าระบุความต้องการขัดแย้งกับผู้ใช้ระบบ
3. ธุรกิจและสภาพแวดล้อมของระบบเปลี่ยนไปในช่วงพัฒนาระบบ


Enduring and volatile requirements
1.      ความต้องการที่ยั่งยืน คือ ความต้องการที่มั่นคงได้มาจากกิจกรรมหลักของลูกค้า เช่น โรงพยาบาลจะมีหมอ และพยาบาล
2.      ความต้องการที่เปลี่ยนง่าย คือ ความต้องการที่เปลี่ยนในช่วงพัฒนาหรือช่วงที่ใช้งานแล้ว เช่น ในโรงพยาบาลความต้องการมาจากนโยบายการดูแลสุขภาพ
 
Requirements management planning
1. ในระหว่างกระบวนการทำความต้องการต้องมีแผน ;
2. วางแผนที่จะระบุความต้องกาออกมา
3. วางแผนบริหารการเปลี่ยนแปลง
4. นโยบายสืบสวนย้อนรอย
5. ใช้เครื่องมือช่วย เช่น CASE

Traceability
1.      คือความสามารถที่จะสืบหาแหล่งที่มาของความต้องการและรูปแบบของระบบ
2.      สืบหาแหล่งที่มา – เชื่อมโยงความต้องการไปยังผู้ลงทุนที่เสนอความต้องการ
3.      สืบหาความต้องการ – เชื่อมโยงระหว่างความต้องการที่พึ่งพากัน
4. สืบหารูปแบบ - เชื่อมโยงระหว่างความต้องการและการออกแบบ


CASE tool support
1.      ที่จัดเก็บ
2.      ควรบริหารการจัดเก็บความต้องการในที่ที่ปลอดภัย
3.      บริหารการเปลี่ยนแปลง
4.      กระบวนการบริหารการเปลี่ยนแปลงเป็นกระบวนการ Workflow ซึ่งสามารถแสดงสถานภาพได้ และมีข้อมูลวิ่งไป-มาระหว่างสถานภาพเหล่านั้นเป็นแบบกึ่งอัตโนมัติ
5.      การบริหารการสืบย้อนรอย
6. ควรจัดให้มีการเชื่อมโยงระหว่างความต้องการเดิมและความต้องการที่เพิ่มขึ้นใหม่โดยอัตโนมัติ

Requirements change management
1.      ควรจะนำไปใช้กับทุกกระบวนการที่ทำให้ความต้องการเปลี่ยนไป
2.      หลักการ
3.      วิเคราะห์ปัญหาให้พิจารณาระหว่างปัญหาและคำขอเปลี่ยนแปลง
4.      วิเคราะห์การเปลี่ยนแปลง และค่าใช้จ่ายประเมินผลกระทบของการเปลี่ยนแปลงนั้น
5. ดำเนินการเปลี่ยน แก้ไขเอกสารความต้องการและเอกสารอื่นๆ ตามที่เปลี่ยนแปลง



Key points
1.      กระบวนการสร้างความต้องการรวมถึงการศึกษาความเป็นไปได้ ,การค้นหาและวิเคราะห์ , การระบุรายละเอียด และการบริหารการจัดการ
2.      การค้นหาและวิเคราะห์ เกี่ยวพันกับการทำความเข้าใจที่โดเมน ,การรวบรวม , จัดชั้น , โครงสร้าง , จัดระดับความสำคัญ , การยืนยันความถูกต้อง
3. มีผู้ลงทุนหลายฝ่าย ซึ่งมีความต้องการต่างกัน
4. Key points
5. องค์ประกอบทางสังคมและองค์กร ส่งผลกระทบต่อความต้องการ
6. การยืนยันความต้องการเกี่ยวข้องกับการตรวจเช็ค เพื่อความถูกต้อง,สม่ำเสมอ , ครบถ้วน , เป็นไปได้ และตรวจทานได้
7. การเปลี่ยนแปลงทางธุรกิจ ทำให้ความต้องการเปลี่ยนแปลงตาม
8. การบริหารความต้องการ รวมถึงการวางแผนและบริหารการเปลี่ยนแปลง

Chapter 5

การวิเคราะห์ความต้องการ

ข้อกำหนดความต้องการ (requirement specification) เป็น[ข้อกำหนดที่กำหนดขึ้นในกระบวนการพัฒนาระบบ โดยก่อนจะลงมือพัฒนาจะมีการวิเคราะห์ความต้องการ หลังจากเราวิเคราะห์เสร็จก็จะมากำหนดความต้องการว่ามีอะไรบ้าง โดยความต้องการที่เรากำหนดขึ้นมานั้นนำมาใช้ประโยชน์ได้ 2 อย่าง คือ
มองในมุมมองของเจ้าของงาน จะใช้เป็นตัวอ้างอิงการเปิดประมูลให้กับผู้ที่จะทำการพัฒนา
เป็นส่วนหนึ่งในสัญญาเพื่อใช้ในการชำระค่าจ้าง กล่าวคือ ถ้าทำไม่ได้ตามข้อกำหนดความต้องการก็อาจจะไม่ชำระค่าจ้าง เป็นต้น
ประเภทของความต้องการ
User Requirement - เป็นความต้องการที่รวบรวมจากผู้ใช้ระบบโดยตรง เช่น ลำดับของช่องที่จะให้กรอกข้อมูล, จะกรอกอย่างไร, เรียงลำดับอย่างไร, ขนาดตัวอักษร, สีอะไร เป็นต้น
System Requirement – ความต้องการของระบบ เช่น ระบบต้องสามารถส่งข้อมูลผ่านระบบเครือข่ายได้, ข้อมูลต้องเก็บได้ทั้งที่ Server และ Work Station เป็นต้น
Software Specification – รายละเอียดทางด้านเทคนิคของซอฟต์แวร์ว่าต้องทำอะไรได้บ้าง
ความต้องการแบ่งออกได้เป็น 3 กลุ่มใหญ่ ๆ
Functional Requirement คือ Requirement หรือสิ่งที่ระบบควรจะทำ , หน้าที่หลักของระบบที่จะต้องทำ เช่น
ผู้ใช้ต้องสามารถค้นหาจากฐานข้อมูลทั้งหมด ก็ได้หรือ ค้นหาจากส่วนหนึ่งส่วนใดของฐานข้อมูลก็ได้
ระบบจะต้องมีโปรแกรมที่ช่วยให้อ่านเอกสารได้
Non-functional Requirement คือ Requirement อื่นๆที่ไม่ใช่หน้าที่หลักๆที่ต้องทำ แต่เป็นคุณสมบัติอื่นๆที่เราอยากได้จากระบบ เช่น ความปลอดภัยของระบบ, ความเชื่อถือได้ของระบบ, เวลาตอบสนอง, มีความสามารถทางด้าน I/O, ความสามารถในการเชื่อมต่อกับระบบอื่นๆ ตัวอย่างเช่น ระบบบัญชี โดยที่หน้าที่หลักของระบบบัญชีคือ บันทึกข้อมูล Transaction รายวัน, จะต้องมีการทำสรุปยอดบัญชีได้ สิ่งเหล่านี้คือสิ่งที่ระบบบัญชีควรทำคือ Functional Requirement แต่ถ้าบอกว่าต้องมีการใส่รหัสผ่าน สามารถเชื่อมโยงอินเทอร์เน็ตได้ , เชื่อมโยงกับระบบบัญชีของบริษัทอื่นได้ อันนี้ไม่ใช่หน้าที่หลัก ของระบบบัญชี แต่มันคือ Non-functional Requirement
Domain Requirement คือ เป็นเงื่อนไขอื่นจากสภาวะแวดล้อมที่ทำให้ระบบทำงานได้ หรือ เป็นการมองที่ว่าระบบที่พัฒนามานี้จะไปทำงานร่วมกับระบบอื่นๆหรือสภาวะแวดล้อมอื่นๆในองค์กร มันจะต้องมีความต้องการอื่นๆภายนอกมากระทบบ้างหรือไม่ เช่น เราออกแบบระบบบัญชี เมื่อนำไปใช้ จะไปทำงานร่วมกับระบบอื่นๆเช่นไปทำงานร่วมกับระบบการสมัครสมาชิกของ ชมรมคอมพิวเตอร์ ของ ม.นเรศวร โดยนำระบบบัญชีไปใช้ในส่วนการรับสมัคร เป็นต้น

Chapter 4

Project หมายถึง การดำเนินกิจกรรมตามแผนงานที่ได้จัดทำขึ้น โดยแต่ละกิจกรรมจะมีวันเริ่มต้นและสิ้นสุด เพื่อบรรลุเป้าหมายหรือวัตถุประสงค์ที่กำหนดไว้ ภายใต้ระยะเวลา แหล่งทรัพยากร และงบประมาณที่กำหนดไว้
Project Management หมายถึง กระบวนการในการกำหนด วางแผน ชี้แนะ ติดตาม และควบคุมโครงการพัฒนาระบบให้สามารถดำเนินการได้ตามระยะเวลาและงบประมาณที่กำหนดไว้ได้
Project Manager
เป็นผู้ที่คอยดูแล ให้คำแนะนำ ควบคุม และติดตามผลการดำเนินงานของโครงการ ให้เป็นไปตามแผนงานที่กำหนดขึ้น เพื่อบรรลุวัตถุประสงค์ในการพัฒนาระบบร่วมกัน
หน้าที่ของ Project Manager
•          กำหนดขอบเขตของโครงการ
•          วางแผนและจัดตั้งทีมงาน
•          จัดตารางการดำเนินงาน
•          กำกับและควบคุมโครงการ
ทักษะของ Project Manager
•          ความเป็นผู้นำ
•          การจัดการ
•          แก้ปัญหาต่าง ๆ ที่เกิดขึ้น
•          บริหารทีมงาน
•          การบริหารงานเมื่อเกิดการเปลี่ยนแปลงหรือในสภาวะที่มีความเสี่ยง
Project Management Process
แบ่งออกเป็น 4 ระยะ
•          ระยะการเริ่มต้นโครงการ
•          ระยะการวางแผนโครงการ
•          ระยะดำเนินโครงการ
•          ระยะปิดโครงการ

ระยะที่ 1: การเริ่มต้นโครงการ
•          จัดตั้งทีมงานจัดทำโครงการ
•          จัดทำแผนการในการเริ่มต้นโครงการ
•          จัดทำกระบวนการบริหารโครงการ
•          จัดทำสมุดโครงการ
ระยะที่ 2: การวางแผนโครงการ
•          แสดงรายละเอียดขอบเขตของโครงการและความเป็นไปได้
•          แบ่งกิจกรรมทั้งหมดของโครงการ
•          ประมาณการใช้แหล่งทรัพยากรและวางแผนการใช้ทรัพยากรนั้น
•          จัดตารางระยะเวลาดำเนินการในเบื้องต้น
•          วางแผนการติดต่อสื่อสารกับผู้ที่เกี่ยวข้องในระหว่างการพัฒนาระบบ
•          จัดทำมาตรฐานในการดำเนินงาน
•          ระบุและประเมินความเสี่ยง
•          ประมาณการใช้งบประมาณ
•          จัดทำรายงานแสดงสถานะของงาน (Statement of Work : SOW)
•          จัดทำ Baseline Project Plan
ระยะที่ 4: ดำเนินโครงการ
•          ดำเนินงานในแต่ละกิจกรรมที่วางแผนไว้
•          ติดตามผลการปฏิบัติงานของทีมงาน
•          คอยติดตามการเปลี่ยนแปลง
•          บำรุงรักษาชุดเอกสารของโครงการ
•          แจ้งความคืบหน้าในการดำเนินงาน

ระยะที่ 4: ปิดโครงการ
•          ปิดโครงการ
•          ทบทวนการดำเนินงานหลังปิดโครงการ
•          สิ้นสุดสัญญาในโครงการพัฒนาระบบ
เทคนิคการบริหารโครงการ
•          Gantt Chart
•          PERT/CPM Chart
Gantt Chart
•          พัฒนาขึ้นโดย Henry L. Gantt ในปี 1917
•          เป็นกราฟแท่งในแนวนอนซึ่งแสดงขอบเขตของระยะเวลาของกิจกรรมแต่ละขั้นตอน
•          โดยรายชื่อกิจกรรมจะถูกแสดงไว้ในแนวตั้งทางด้านซ้ายมือ
•          ระยะเวลาการทำงานจะแสดงในแนวนอนของแผนภาพ
กิจกรรม
•          1. รวบรวมความต้องการ
•          2. ออกแบบรายงาน
•          3. ออกแบบหน้าจอ
•          4. ออกแบบฐานข้อมูล
•          5. จัดทำเอกสาร
•          6. เขียนโปรแกรม
•          7. ทดสอบโปรแกรม
•          8. ติดตั้งโปรแกรม
PERT/CPM Chart
•          PERT Chart : Project Evaluation and Review Technique Chart
•          CPM Chart : Critical Path Method
PERT Chart
•          เป็นแผนภาพแสดงกิจกรรมของโครงการที่เชื่อมโยงกันในลักษณะของเครือข่าย (ข่ายงาน) ทำให้ทราบว่าจะต้องดำเนินกิจกรรมใดให้เสร็จสิ้นก่อนกิจกรรมถัดไป
•          โดยแต่ละกิจกรรมจะแทนด้วยเส้นลูกศร และเชื่อมโยงกันด้วยวงกลม (เรียกว่า โหนด) เพื่อบอกให้ทราบถึงจุดเริ่มต้นและจุดสิ้นสุดของแต่ละกิจกรรม
•          เหมาะสำหรับโครงการใหม่ที่ไม่เคยเกิดขึ้นเลย
•          การกำหนดเวลากิจกรรมของ PERT Chart จึงเป็นการกำหนดในรูปของความน่าจะเป็น (Probabilistic)

CPM Chart
•          เป็นแผนภาพแสดงกิจกรรมของโครงการที่เชื่อมโยงกันในลักษณะเครือข่าย (ข่ายงาน) ทำให้ทราบว่าต้องดำเนินกิจกรรมใดให้เสร็จสิ้นก่อนกิจกรรมถัดไป เช่นเดียวกับ PERT Chart
•          เหมาะสำหรับโครงการที่เคยเกิดขึ้นแล้วในอดีต ทำให้มีข้อมูลเพื่อกำหนดระยะเวลาของกิจกรรมได้เป็นที่แน่นอน (Deterministic)

Critical Path : เส้นทางวิกฤต
•          หมายถึง เส้นทางที่ใช้เวลาในการดำเนินกิจกรรมรวมของโครงการนานที่สุด และกิจกรรมที่อยู่บนเส้นทางวิกฤตจะเรียกว่า กิจกรรมวิกฤต Critical Activity
การหาเส้นทางวิกฤต
•          เป็นการหาเส้นทางที่ใช้เวลานานที่สุดและเหลือเวลาน้อยที่สุด
•          ต้องทราบระยะเวลาโดยประมาณของแต่ละกิจกรรม กำหนดได้ 2 วิธี
–        Deterministic
–        Statistic
การกำหนดระยะเวลาด้วย Statistic
•          แยกแยะกิจกรมของโครงการ
•          กำหนดกิจกรรมที่ต้องดำเนินให้เสร็จสิ้นก่อนดำเนินกิจกรรมต่อไป
•          กำหนดระยะเวลาทั้งหมด 3 ค่า
–        เวลาทำกิจกรรมให้เสร็จสิ้นเร็วสุด Optimistic
–        เวลาทำกิจกรรมให้เสร็จสิ้นช้าสุด Pessimistic
–        เวลาทำกิจกรรมให้เสร็จสิ้นที่เป็นไปได้มากที่สุด Realistic
นำค่าทั้ง 3 มาคำนวณหาค่าใช้จริงเพียงค่าเดียว เรียกว่า ค่า ระยะเวลาคาดหวัง Expected Time โดยใช้สูตร
                ET = o + 4r + p
                           6

Chapter 3

วิศวกรรมระบบ(System Engineering)
วิศวกรรมระบบ
        ระบบ
        ระบบ ( System) หมายถึง กลุ่มขององค์ประกอบต่างๆ ที่สัมพันธ์กัน พึ่งพาอาศัยกัน และต้องปฏิสัมพันธ์กันเพื่อให้บรรลุวัตถุประสงค์ร่วมกัน
        ระบบในแวดวงพัฒนาสสารสนเทศเป็นระบบที่ประกอบไปด้วยฮาร์ดแวร์ ซอฟต์แวร์ และบุคลากร เพื่อประมวลผลข้อมูลให้ได้เป็นสารสนเทศที่ต้องการ ซึ่งก็คือ ระบบที่นำคอมพิวเตอร์มาสนับสนุนการทำงาน หรือ Computer-base System มีส่วนประกอบหลักๆ ดังนี้
1. ซอฟต์แวร์ (Software) คือโปรแกรมคอมพิวเตอร์
2. ฮาร์ดแวร์ (Hardware) ได้แก่ อุปกรณ์อิเล็กทรอนิกส์ที่ใช้ประมวลผล อุปกรณ์เชื่อมต่อ
3. บุคลากร (People) ได้แก่ ผู้ใช้ และผู้ควบคุมการทดงาน ของฮาร์ดแวร์และซอฟต์แวร์
4. ฐานข้อมูล (Database) คือส่วนจัดเก็บข้อมูลและสารสมเทศของระบบ
5. เอกสาร (Documentation) คือ เอกสารรายละเอียดทั้งหมดของระบบ
6. กระบวนการ (Procedure) ได้แก่ขั้นตอนการทำงานของระบบ
นอกจากองค์ประกอบข้างต้นและวัตถุประสงค์หลักขององค์กรแล้ว Computer-base System ยังต้องใช้องค์ความรู้อีกหลายด้านเพิ่มเติม เพื่อกำหนดวิธีการทำงานของระบบให้สามารถบรรลุวัตถุประสงค์อื่นๆ อีกด้วย บางครั้งจึงเรียกระบบลักษณะดังกล่าวว่า Socio-technical System ซึ่งมีคุณสมบัติ 3 ประการได้แก่
1. เป็นระบบที่มีคุณลักษณะ Emergent Properties คือ คุณลักษณะที่ไม่สามารถวัดได้จากระบบย่อยใดระบบหนึ่ง แต่จะต้องวัดจากการทำงานโดยรวมของระบบ
2. พฤติกรรมของระบบไม่แน่นอน บางครั้งระบบอาจแสดงผลลัพธ์ที่แตกต่างออกไปจากเดิม เนื่องจากข้อมูลนำเข้าที่มีลักษณะเฉพาะ หรือบางครั้งระบบอาจมีการตอบสนองในลักษณะอื่นขึ้นอยู่กับผู้ใช้ระบบ
3. เป็นระบบที่ถูกเพิ่มความสามารถให้บรรลุวัตถุประสงค์อื่นๆ นอกเหนือจากวัตถุประสงค์หลัก ทำให้ต้องมีการปรับปรุงระบบให้เข้ากับวัตถุประสงค์อื่นๆ เหล่านั้น ซึ่งอาจส่งผลให้การทำงานของระบบเกิดล้มเหลวได้
3.2 วิศวกรรมระบบ
        โดยส่วนใหญ่ เมื่อระบบทำงานผิดพลาดและไม่สามารถแก้ไขที่กระบวนการของระบบได้โดยตรง จึงต้องแก้ไขที่ซอฟต์แวร์ด้วยการเพิ่มประสิทธิภาพ หรือดัดแปลงการทำงานให้เข้ากับสภาพแวดล้อมที่เป็นสาเหตุในขณะนั้น บางครั้งอาจทำให้ประสิทธิภาพของซอฟต์แวร์ลดลง และส่งผลให้ลูกค้าไม่พอใจในที่สุด ในสถานการณ์ดังกล่าวอาจมองว่าปัญหาเกิดจากซอฟต์แวร์ไม่มีประสิทธิภาพ แต่แท้จริงแล้ว ปัญหาเกิดจากการออกแบบระบบ ที่ไม่ได้คำนึงถึงส่วนประกอบอื่นของระบบโดยเฉพาะสภาพแวดล้อมที่มีอิทธิพลต่อ ระบบ
        วิศวกรมระบบ (System Engineering) หมายถึง กระบวนการศึกษาและวิเคราะห์ของระบบที่มีความสลับซับซ้อน เพื่อสนับสนุนการทำงานในส่วนของวิศวกรรซอฟต์แวร์ กิจกรรมของวิศวกรรมระบบ จะถูกดำเนินไปพร้อมๆ กัน มีดังนี้
        1. กำหนดวัตถุประสงค์ของระบบ
        2. กำหนดขอบเขตระบบ
        3. แบ่งระบบออกเป็นส่วนๆ ตามฟังก์ชันการทำงานหรือคุณสมบัติของระบบ
        4. พิจารณาความสัมพันธ์ของส่วนประกอบต่างๆ ที่เกี่ยวข้องทั้งหมด
        5. กำหนดความสัมพันธ์ของปัจจัยนำเข้า ประมวลผล และผลลัพธ์
        6. พิจารณาปัจจัยที่มีส่วนเกี่ยวข้องในระบบ ไม่ว่าจะเป็นฮาร์ดแวร์ ซอฟต์แวร์ ฐานข้อมูล หรือแม้แต่ผลิตภัณฑ์ซอฟต์แวร์อื่นๆ เป็นต้อ
        7. กำหนดความต้องการในส่วนของการดำเนินการและฟังก์ชันทั้งระบบ
        8. สร้างแบบจำลองระบบ เพื่อใช้วิเคราะห์และพัฒนาให้สอดคล้องกับแบบจำลองซอฟต์แวร์ที่สร้างขึ้น
        9. นำเสนอและแลกเปลี่ยนข้อคิดเห็นกับผู้ที่เกี่ยวข้องกับระบบ ไม่ว่าจะเป็นผู้ใช้ระบบ เจ้าของระบบ หรือแม้แต่ผู้ที่เกี่ยวข้องกับผลประโยชน์ที่มีต่อระบบ



3.3 กระบวนการวิศวกรรมระบบ
        กระบวนการวิศวกรรมระบบ ประกอบไปด้วยขั้นตอนการทำงานทั้งหมด 7 เฟส ได้แก่

รูปที่ 3.1 แสดงกระบวนการวิศวกรรมระบบ (System Engineering Process)
        1. การกำหนดความต้องการ (Requirement Definition)
กระบวนการของวิศวกรรมระบบ เริ่มต้นด้วยการวิเคราะห์ภาพรวมของทั้งองค์กร เพื่อกำหนดนิยามความต้องการของระบบให้ชัดเจน ด้วยการกำหนดหน้าที่ว่าระบบควรทำอะไรได้บ้าง
2. การออกแบบระบบ (System Design)
เป็นการกำหนดรายละเอียดของฟังก์ชั่นในแต่ละส่วนประกอบของระบบ โดยมีกระบวนการย่อยดังนี้
1. แบ่งส่วนความต้องการ (Partition Requirement) วิเคราะห์ความต้องการและจัดโครงสร้างด้วยการแบ่งกลุ่มความต้องการด้วยวิธีที่เหมาะสม
2. กำหนดระบบย่อย (Identify Sub-System) นำระบบใหญ่มาแบ่งส่วนออกเป็นระบบย่อย ด้วยวิธีการหรือแนวทางที่เหมาะสม
3. กำหนดความต้องการในแต่ละระบบย่อย (Assign Requirement) กำหนดความต้องการของแต่ละระบบย่อย ซึ่งต้องสอดคล้องกับความต้องการทั้งหมดของระบบ และจะซับซ้อนขึ้นเมื่อความต้องการมีการเปลี่ยนแปลง
4. กำหนดฟังก์ชันของแต่ละระบบย่อย (Specify Sub-system Functionality) ซึ่งต้องสอดคล้องกับความต้องการของแต่ละระบบย่อยด้วย
5. กำหนดส่วนประสานของระบบย่อย แต่ละระบบย่อยจะต้องเตรียมส่วนประสานไว้บริการระบบย่อยอื่นๆ เพื่อการผนวกรวมระบบ


รูป 3.2 แสดงกระบวนการออกแบบระบบ
        3. การพัฒนาระบบย่อย (Sub-system Development)
เป็นการนำระบบย่อยที่ถูกกำหนดรายละเอียดไว้แล้วในระยะการออกแบบ มาสร้างตามรายละเอียดที่กำหนดไว้ ตามกระบวนการที่เหมาะสม การพัฒนาระบบย่อยโดยทั่วไปจะดำเนินการแบบขนาน เมื่อพบปัญหาจะต้องย้อนกลับไปแก้ไขทันที เนื่องจากการแก้ไขระบบหลังจากการผลิตเสร็จเรียบร้อยแล้วนั้น จะทำให้เกิดต้นทุนที่สูงมาก จึงต้องหันมาแก้ไขที่ซอฟต์แวร์เอง ซึ่งความซับซ้อนของซอฟต์แวร์นั้นมีลักษณะเป็นลูกโซ่ คือ ต้องเริ่มแก้ตั้งแต่ข้อกำหนดความต้องการ งานออกแบบ มาจนถึงโค้ดโปรแกรม จึงทำให้การแก้ไขซอฟต์แวร์นั้นเป็นเรื่องยาก
        4. การผนวกรวมระบบ (System Integration)
ระบบย่อยใดที่พัฒนาเสร็จสิ้นแล้ว จะถูกผนวกรวมเข้าด้วยกันจนกลายเป็นระบบที่เสร็จสิ้นสมบูรณ์ โดยใช้แนวทางที่เรียกว่า Big Bang ซึ่งเป็นการผนวกรวมระบบย่อยทั้งหมดในคราวเดียวกัน ซึ่งมองเห็นข้อผิดพลาดได้ยาก Incremental Integration Process เป็นการผนวกรวมระบบย่อยที่ละระบบ ทำให้มองเห็นความผิดพลาดของระบบได้ง่าย เมื่อผนวกรวมระบบแล้วต้องมีการทดสอบระบบอีกครั้ง
        5. การติดตั้งระบบ (System Installation)
เมื่อตรวจสอบประสิทธิภาพของระบบจนมั่นใจว่าระบบสมารถติดตั้งได้แล้ว ก็ทำการติดตั้งระบบให้ผู้ใช้ ใช้งาน และต้องทำการติดตามประสิทธิภาพการทำงานของระบบหลังการติดตั้งด้วย เมื่อพบข้อผิดพลาดก็ดำเนินการแก้ไขให้ถูกต้อง
        6. การเปลี่ยนแปลงระบบ (System Evolution)
ในช่วงระยะเวลาของการใช้งานระบบ  อาจเกิดการเปลี่ยนแปลงของสิ่งต่างๆ ทั้งในส่วนของระบบเองและสิ่งแวดล้อมระบบ โดยเจ้าระบบอาจต้องการแก้ไขข้อผิดพลาด รวมทั้งแก้ไขความต้องการของระบบเดิมให้เป็นไปตามความต้องการใหม่ เมื่อทุกฝ่ายที่เกี่ยวข้องกันตัดสินใจเปลี่ยนแปลงระบบ จะต้องวางแผนอย่างรอบคอบ เนื่องจาการเปลี่ยนแปลงระบบต้องใช้ต้นทุนค่อนข้างสูง
        7. การปลดระวางระบบ (System Decommission)
การปลดระวางระวางระบบ หมายถึง การเลิกใช้ระบบหลังพบว่าระบบไม่สามารถใช้งานได้อีกต่อไป
ข้อแตกต่างและความสัมพันธ์ระหว่างกระบวนการวิศวกรรมระบบกับกระบวนการวิศวกรรมซอฟต์แวร์ มีดังนี้
        1. ขอบเขตของการแก้ไขงานในระหว่างการพัฒนาระบบ
        เมื่อทีมงานสามารถกำหนดระบบที่จะพัฒนาได้แล้วหากในระหว่างการดำเนินงานอยู่ นั้นมีการเปลี่ยนแปลงความต้องการบางอย่างละการเปลี่ยนแปลงได้รับการอนุมัติ การแก้ไขจึงเป็นเรื่องยาก จึงต้องแก้ไขที่ตัวซอฟต์แวร์ของระบบซึ่งง่ายกว่า
        2. ความสัมพันธ์ของงานด้านวิศวกรรม
        ระบบหนึ่งระบบอาจต้องประยุกต์ใช้งานวิศวกรรมลายด้าน ทั้งนี้เพื่อให้ส่วนประกอบต่างๆของระบบ ทั้งฮาร์ดแวร์ ซอฟต์แวร์ บุคลากร และข้อมูลส่วนอื่นๆ มีความสัมพันธ์สอดคล้องกันเป็นอย่างดี เพื่อป้องกันการเกิดข้อผิดพลาดที่ไม่อาจคาดการณ์ได้ จึงต้องอาศัยวิศวกรหลายคนเพื่อรับผิดชอบงานแต่ละด้าน
3.4 ระบบกับองค์กร
        หากต้องการพัฒนาระบบงานใดระบบงานหนึ่งให้มีประสิทธิภาพและประสิทธิผล ทีมงานจะต้องทำความเข้าใจในองค์กรที่เป็นเจ้าของระบบนั้นด้วย
        วิธีที่จะทราบว่า เทคโนโลยีที่จะนำมาใช้ในองค์กรจะส่งผลกระทบต่อส่วนอื่นขององค์กรอย่างไร ทำได้โดยการศึกษาถึงความสัมพันธ์ระว่างองค์ประกอบทั้ง 5 ส่วนได้แก่

รูป 3.3 แบบจำลองของ H.J. Leavitt แสดงความสัมพันธ์เมื่อนำเทคโนโลยีไปใช้ในองค์กร
        1. บุคลากร (People) ศึกษาคุณสมบัติด้านกำลังความสามารถ และวุฒิภาวะ
        2. วัฒนธรรม (Culture) ศึกษาคุณสมบัติด้านทัศนคติ พฤติกรรม ทักษะการปรับตัว และการเรียนรู้
        3. เทคโนโลยี (Technology) ศึกษาเทคโนโลยีปัจจุบันและผลกระทบที่เกี่ยวข้องกับเทคโนโลยีใหม่ ระดับการใช้งานเครื่องมือ มาตรฐาน และระเบียบวิธีปฏิบัติ
        4. โครงสร้าง (Structure) ศึกษาโครงสร้างบุคลากร โครงสร้างองค์กร
        5. ภาระหน้าที่ (Task) ศึกษาด้านภาระหน้าที่ปัจจุบัน ความซับซ้อนของงานที่ได้รับมอบหมาย และวิธีการทำงาน