วิศวกรรมซอฟต์แวร์ - คู่มือฉบับย่อ

ให้เราเข้าใจก่อนว่าวิศวกรรมซอฟต์แวร์หมายถึงอะไร คำนี้ประกอบด้วยสองคำซอฟต์แวร์และวิศวกรรม

Software เป็นมากกว่ารหัสโปรแกรม โปรแกรมคือโค้ดที่เรียกใช้งานได้ซึ่งทำหน้าที่ในการคำนวณ ซอฟต์แวร์ถือเป็นชุดของรหัสโปรแกรมปฏิบัติการไลบรารีและเอกสารที่เกี่ยวข้อง ซอฟต์แวร์เมื่อสร้างขึ้นเพื่อความต้องการเฉพาะจะเรียกว่าsoftware product.

Engineering ในทางกลับกันเป็นเรื่องของการพัฒนาผลิตภัณฑ์โดยใช้หลักการและวิธีการทางวิทยาศาสตร์ที่กำหนดไว้เป็นอย่างดี

Software engineeringเป็นสาขาวิศวกรรมที่เกี่ยวข้องกับการพัฒนาผลิตภัณฑ์ซอฟต์แวร์โดยใช้หลักการวิธีการและขั้นตอนทางวิทยาศาสตร์ที่กำหนดไว้อย่างชัดเจน ผลลัพธ์ของวิศวกรรมซอฟต์แวร์คือผลิตภัณฑ์ซอฟต์แวร์ที่มีประสิทธิภาพและเชื่อถือได้

คำจำกัดความ

IEEE กำหนดวิศวกรรมซอฟต์แวร์ว่า:

(1) การประยุกต์ใช้แนวทางที่เป็นระบบมีวินัยเชิงปริมาณในการพัฒนาการดำเนินการและการบำรุงรักษาซอฟต์แวร์ นั่นคือการประยุกต์ใช้วิศวกรรมกับซอฟต์แวร์

(2) การศึกษาแนวทางตามข้อความข้างต้น

Fritz Bauer นักวิทยาศาสตร์คอมพิวเตอร์ชาวเยอรมันให้คำจำกัดความของวิศวกรรมซอฟต์แวร์ว่า:

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

วิวัฒนาการของซอฟต์แวร์

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

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

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

กฎหมายวิวัฒนาการของซอฟต์แวร์

เลห์แมนได้ให้กฎหมายสำหรับวิวัฒนาการซอฟต์แวร์ เขาแบ่งซอฟต์แวร์ออกเป็นสามประเภท:

  • S-type (static-type) - นี่คือซอฟต์แวร์ซึ่งทำงานตามข้อกำหนดและโซลูชันที่กำหนดไว้อย่างเคร่งครัด วิธีแก้ปัญหาและวิธีการเพื่อให้บรรลุทั้งสองอย่างเข้าใจได้ทันทีก่อนที่จะเขียนโค้ด ซอฟต์แวร์ประเภท s มีการเปลี่ยนแปลงน้อยที่สุดด้วยเหตุนี้จึงเป็นสิ่งที่ง่ายที่สุด ตัวอย่างเช่นโปรแกรมเครื่องคิดเลขสำหรับการคำนวณทางคณิตศาสตร์
  • P-type (practical-type) - นี่คือซอฟต์แวร์ที่มีการรวบรวมขั้นตอนต่างๆ สิ่งนี้ถูกกำหนดโดยขั้นตอนที่สามารถทำได้ ในซอฟต์แวร์นี้สามารถอธิบายข้อมูลจำเพาะได้ แต่วิธีแก้ปัญหาไม่ชัดเจนในทันที ตัวอย่างเช่นซอฟต์แวร์เกม
  • E-type (embedded-type) - ซอฟต์แวร์นี้ทำงานอย่างใกล้ชิดตามความต้องการของสภาพแวดล้อมในโลกแห่งความเป็นจริง ซอฟต์แวร์นี้มีวิวัฒนาการในระดับสูงเนื่องจากมีการเปลี่ยนแปลงด้านกฎหมายภาษี ฯลฯ ในสถานการณ์จริง ตัวอย่างเช่นซอฟต์แวร์การซื้อขายออนไลน์

วิวัฒนาการซอฟต์แวร์ E-Type

เลห์แมนได้ให้กฎหมายแปดประการสำหรับวิวัฒนาการซอฟต์แวร์ E-Type -

  • Continuing change - ระบบซอฟต์แวร์ประเภท E ต้องปรับตัวให้เข้ากับการเปลี่ยนแปลงของโลกแห่งความเป็นจริงต่อไปมิฉะนั้นจะมีประโยชน์น้อยลงเรื่อย ๆ
  • Increasing complexity - ในขณะที่ระบบซอฟต์แวร์ประเภท E มีการพัฒนาความซับซ้อนจึงมีแนวโน้มที่จะเพิ่มขึ้นเว้นแต่จะต้องทำงานเพื่อรักษาหรือลดความซับซ้อนลง
  • Conservation of familiarity - ความคุ้นเคยกับซอฟต์แวร์หรือความรู้เกี่ยวกับวิธีการพัฒนาเหตุใดจึงได้รับการพัฒนาในลักษณะนั้น ฯลฯ จะต้องถูกเก็บรักษาไว้โดยเสียค่าใช้จ่ายใด ๆ เพื่อดำเนินการเปลี่ยนแปลงในระบบ
  • Continuing growth- เพื่อให้ระบบ E-type มีวัตถุประสงค์เพื่อแก้ไขปัญหาทางธุรกิจขนาดของการใช้การเปลี่ยนแปลงจะเติบโตขึ้นตามการเปลี่ยนแปลงวิถีชีวิตของธุรกิจ
  • Reducing quality - ระบบซอฟต์แวร์ประเภท E มีคุณภาพลดลงเว้นแต่จะได้รับการบำรุงรักษาอย่างเข้มงวดและปรับให้เข้ากับสภาพแวดล้อมการทำงานที่เปลี่ยนแปลงไป
  • Feedback systems- ระบบซอฟต์แวร์ประเภท E ประกอบด้วยระบบป้อนกลับแบบหลายลูปหลายระดับและต้องได้รับการปฏิบัติเพื่อให้สามารถแก้ไขหรือปรับปรุงได้สำเร็จ
  • Self-regulation - กระบวนการวิวัฒนาการของระบบ E-type มีการควบคุมตัวเองโดยมีมาตรการกระจายผลิตภัณฑ์และกระบวนการใกล้เคียงกับปกติ
  • Organizational stability - อัตรากิจกรรมทั่วโลกที่มีประสิทธิผลโดยเฉลี่ยในระบบ E-type ที่กำลังพัฒนาจะไม่คงที่ตลอดอายุการใช้งานของผลิตภัณฑ์

กระบวนทัศน์ของซอฟต์แวร์

กระบวนทัศน์ของซอฟต์แวร์หมายถึงวิธีการและขั้นตอนที่ใช้ในการออกแบบซอฟต์แวร์ มีวิธีการมากมายที่เสนอและใช้งานได้ในปัจจุบัน แต่เราจำเป็นต้องดูว่ากระบวนทัศน์เหล่านี้อยู่ที่ใดในวิศวกรรมซอฟต์แวร์ สิ่งเหล่านี้สามารถรวมกันเป็นหมวดหมู่ต่างๆได้แม้ว่าแต่ละประเภทจะรวมกัน:

กระบวนทัศน์การเขียนโปรแกรมเป็นส่วนหนึ่งของกระบวนทัศน์การออกแบบซอฟต์แวร์ซึ่งเป็นส่วนย่อยของกระบวนทัศน์การพัฒนาซอฟต์แวร์

กระบวนทัศน์การพัฒนาซอฟต์แวร์

กระบวนทัศน์นี้เรียกว่ากระบวนทัศน์วิศวกรรมซอฟต์แวร์ซึ่งนำแนวคิดทางวิศวกรรมทั้งหมดที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์มาใช้ รวมถึงการวิจัยและการรวบรวมความต้องการต่างๆซึ่งช่วยให้ผลิตภัณฑ์ซอฟต์แวร์สามารถสร้างได้ มันประกอบด้วย -

  • การรวบรวมความต้องการ
  • การออกแบบซอฟต์แวร์
  • Programming

กระบวนทัศน์การออกแบบซอฟต์แวร์

กระบวนทัศน์นี้เป็นส่วนหนึ่งของการพัฒนาซอฟต์แวร์และรวมถึง -

  • Design
  • Maintenance
  • Programming

กระบวนทัศน์การเขียนโปรแกรม

กระบวนทัศน์นี้เกี่ยวข้องอย่างใกล้ชิดกับด้านการเขียนโปรแกรมของการพัฒนาซอฟต์แวร์ ซึ่งรวมถึง -

  • Coding
  • Testing
  • Integration

ต้องการวิศวกรรมซอฟต์แวร์

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

  • Large software - การสร้างกำแพงนั้นง่ายกว่าบ้านหรืออาคารในทำนองเดียวกันเนื่องจากขนาดของซอฟต์แวร์กลายเป็นวิศวกรรมขนาดใหญ่จึงต้องดำเนินการเพื่อให้เป็นกระบวนการทางวิทยาศาสตร์
  • Scalability- หากกระบวนการซอฟต์แวร์ไม่ได้ใช้แนวคิดทางวิทยาศาสตร์และวิศวกรรมการสร้างซอฟต์แวร์ใหม่ขึ้นมาใหม่จะง่ายกว่าการปรับขนาดซอฟต์แวร์ที่มีอยู่
  • Cost- เนื่องจากอุตสาหกรรมฮาร์ดแวร์ได้แสดงให้เห็นถึงทักษะและการผลิตขนาดใหญ่ทำให้ราคาของคอมพิวเตอร์และฮาร์ดแวร์อิเล็กทรอนิกส์ลดลง แต่ต้นทุนของซอฟต์แวร์ยังคงสูงหากไม่มีการปรับเปลี่ยนกระบวนการที่เหมาะสม
  • Dynamic Nature- ลักษณะการเติบโตและการปรับตัวของซอฟต์แวร์อยู่เสมอขึ้นอยู่กับสภาพแวดล้อมที่ผู้ใช้ทำงาน หากลักษณะของซอฟต์แวร์มีการเปลี่ยนแปลงอยู่เสมอจำเป็นต้องทำการปรับปรุงใหม่ในซอฟต์แวร์ที่มีอยู่ นี่คือจุดที่วิศวกรรมซอฟต์แวร์มีบทบาทที่ดี
  • Quality Management- กระบวนการพัฒนาซอฟต์แวร์ที่ดีกว่าให้ผลิตภัณฑ์ซอฟต์แวร์ที่ดีกว่าและมีคุณภาพ

ลักษณะของซอฟต์แวร์ที่ดี

ผลิตภัณฑ์ซอฟต์แวร์สามารถตัดสินได้จากสิ่งที่นำเสนอและสามารถใช้งานได้ดีเพียงใด ซอฟต์แวร์นี้ต้องเป็นไปตามเหตุผลต่อไปนี้:

  • Operational
  • Transitional
  • Maintenance

ซอฟต์แวร์ที่ได้รับการออกแบบและสร้างขึ้นอย่างดีคาดว่าจะมีคุณสมบัติดังต่อไปนี้:

ปฏิบัติการ

สิ่งนี้บอกให้เราทราบว่าซอฟต์แวร์ทำงานได้ดีเพียงใดในการทำงาน สามารถวัดได้เมื่อ:

  • Budget
  • Usability
  • Efficiency
  • Correctness
  • Functionality
  • Dependability
  • Security
  • Safety

เปลี่ยนผ่าน

สิ่งนี้มีความสำคัญเมื่อมีการย้ายซอฟต์แวร์จากแพลตฟอร์มหนึ่งไปยังอีกแพลตฟอร์มหนึ่ง:

  • Portability
  • Interoperability
  • Reusability
  • Adaptability

ซ่อมบำรุง

ข้อมูลสรุปเกี่ยวกับการที่ซอฟต์แวร์มีความสามารถในการรักษาตัวเองในสภาพแวดล้อมที่เปลี่ยนแปลงตลอดเวลา:

  • Modularity
  • Maintainability
  • Flexibility
  • Scalability

ในระยะสั้นวิศวกรรมซอฟต์แวร์เป็นสาขาหนึ่งของวิทยาการคอมพิวเตอร์ซึ่งใช้แนวคิดทางวิศวกรรมที่กำหนดไว้อย่างดีซึ่งจำเป็นในการผลิตผลิตภัณฑ์ซอฟต์แวร์ที่มีประสิทธิภาพทนทานปรับขนาดได้ในงบประมาณและตรงเวลา

Software Development Life Cycle, SDLC สำหรับระยะสั้นคือลำดับขั้นตอนที่มีโครงสร้างและกำหนดไว้อย่างดีในวิศวกรรมซอฟต์แวร์เพื่อพัฒนาผลิตภัณฑ์ซอฟต์แวร์ที่ต้องการ

กิจกรรม SDLC

SDLC มีขั้นตอนที่ต้องปฏิบัติตามเพื่อออกแบบและพัฒนาผลิตภัณฑ์ซอฟต์แวร์อย่างมีประสิทธิภาพ กรอบงาน SDLC ประกอบด้วยขั้นตอนต่อไปนี้:

การสื่อสาร

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

การรวบรวมความต้องการ

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

  • ศึกษาระบบและซอฟต์แวร์ที่มีอยู่หรือล้าสมัย
  • ทำการสัมภาษณ์ผู้ใช้และนักพัฒนา
  • อ้างถึงฐานข้อมูลหรือ
  • รวบรวมคำตอบจากแบบสอบถาม

การศึกษาความเป็นไปได้

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

การวิเคราะห์ระบบ

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

การออกแบบซอฟต์แวร์

ขั้นตอนต่อไปคือการลดความรู้ทั้งหมดเกี่ยวกับข้อกำหนดและการวิเคราะห์บนโต๊ะทำงานและออกแบบผลิตภัณฑ์ซอฟต์แวร์ อินพุตจากผู้ใช้และข้อมูลที่รวบรวมในขั้นตอนการรวบรวมความต้องการเป็นอินพุตของขั้นตอนนี้ ผลลัพธ์ของขั้นตอนนี้มาในรูปแบบของการออกแบบสองแบบ การออกแบบเชิงตรรกะและการออกแบบทางกายภาพ วิศวกรจัดทำ meta-data และ data dictionaries, logical diagram, data-flow diagram และในบางกรณีรหัสหลอก

การเข้ารหัส

ขั้นตอนนี้เรียกอีกอย่างว่าขั้นตอนการเขียนโปรแกรม การดำเนินการออกแบบซอฟต์แวร์เริ่มต้นในแง่ของการเขียนโค้ดโปรแกรมในภาษาโปรแกรมที่เหมาะสมและการพัฒนาโปรแกรมปฏิบัติการที่ปราศจากข้อผิดพลาดอย่างมีประสิทธิภาพ

การทดสอบ

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

บูรณาการ

ซอฟต์แวร์อาจต้องรวมเข้ากับไลบรารีฐานข้อมูลและโปรแกรมอื่น ๆ ขั้นตอนของ SDLC นี้เกี่ยวข้องกับการรวมซอฟต์แวร์กับหน่วยงานนอกโลก

การนำไปใช้

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

การดำเนินงานและการบำรุงรักษา

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

การจำหน่าย

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

กระบวนทัศน์การพัฒนาซอฟต์แวร์

กระบวนทัศน์การพัฒนาซอฟต์แวร์ช่วยให้นักพัฒนาสามารถเลือกกลยุทธ์ในการพัฒนาซอฟต์แวร์ กระบวนทัศน์การพัฒนาซอฟต์แวร์มีชุดเครื่องมือวิธีการและขั้นตอนของตัวเองซึ่งแสดงออกอย่างชัดเจนและกำหนดวงจรชีวิตการพัฒนาซอฟต์แวร์ กระบวนทัศน์การพัฒนาซอฟต์แวร์หรือแบบจำลองกระบวนการบางส่วนมีการกำหนดไว้ดังนี้:

น้ำตกจำลอง

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

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

รุ่นนี้เหมาะที่สุดเมื่อนักพัฒนาได้ออกแบบและพัฒนาซอฟต์แวร์ที่คล้ายกันมาแล้วในอดีตและตระหนักถึงโดเมนทั้งหมด

แบบจำลองซ้ำ

โมเดลนี้นำไปสู่กระบวนการพัฒนาซอฟต์แวร์ในการทำซ้ำ โครงการนี้แสดงกระบวนการพัฒนาในลักษณะวนซ้ำทุกขั้นตอนหลังจากทุกรอบของกระบวนการ SDLC

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

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

แบบเกลียว

Spiral model เป็นการรวมกันของทั้งสองแบบจำลองซ้ำและหนึ่งในโมเดล SDLC จะเห็นได้ว่าคุณเลือกโมเดล SDLC หนึ่งโมเดลและรวมเข้ากับกระบวนการแบบวนซ้ำ (แบบจำลองซ้ำ)

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

V - แบบจำลอง

ข้อเสียเปรียบที่สำคัญของแบบจำลองน้ำตกคือเราจะย้ายไปยังขั้นตอนถัดไปก็ต่อเมื่อขั้นตอนก่อนหน้าเสร็จสิ้นและไม่มีโอกาสย้อนกลับไปหากพบว่ามีสิ่งผิดปกติในระยะต่อมา V-Model ให้วิธีการทดสอบซอฟต์แวร์ในแต่ละขั้นตอนในลักษณะย้อนกลับ

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

ทำให้ทั้งการตรวจสอบและการตรวจสอบความถูกต้องดำเนินควบคู่กันไป แบบจำลองนี้เรียกอีกอย่างว่ารูปแบบการตรวจสอบและการตรวจสอบความถูกต้อง

บิ๊กแบงโมเดล

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

สำหรับรุ่นนี้จำเป็นต้องมีการวางแผนจำนวนน้อยมาก ไม่เป็นไปตามกระบวนการใด ๆ หรือในบางครั้งลูกค้าก็ไม่แน่ใจเกี่ยวกับข้อกำหนดและความต้องการในอนาคต ดังนั้นข้อกำหนดการป้อนข้อมูลจึงเป็นไปโดยพลการ

รุ่นนี้ไม่เหมาะสำหรับโครงการซอฟต์แวร์ขนาดใหญ่ แต่เหมาะสำหรับการเรียนรู้และทดลอง

หากต้องการอ่านข้อมูลเชิงลึกเกี่ยวกับ SDLC และรุ่นต่างๆคลิกที่นี่

รูปแบบงานของ บริษัท ไอทีที่มีส่วนร่วมในการพัฒนาซอฟต์แวร์สามารถแบ่งออกเป็นสองส่วน:

  • การสร้างซอฟต์แวร์
  • การจัดการโครงการซอฟต์แวร์

โครงการเป็นงานที่กำหนดไว้อย่างชัดเจนซึ่งเป็นการรวบรวมการดำเนินการหลายอย่างเพื่อให้บรรลุเป้าหมาย (เช่นการพัฒนาซอฟต์แวร์และการส่งมอบ) โครงการสามารถมีลักษณะเป็น:

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

โครงการซอฟต์แวร์

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

ต้องการการจัดการโครงการซอฟต์แวร์

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

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

ดังนั้นการจัดการโครงการซอฟต์แวร์จึงจำเป็นอย่างยิ่งที่จะต้องรวมความต้องการของผู้ใช้ควบคู่ไปกับข้อ จำกัด ด้านงบประมาณและเวลา

ผู้จัดการโครงการซอฟต์แวร์

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

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

ให้เราเห็นความรับผิดชอบเล็กน้อยที่ผู้จัดการโครงการต้องรับผิดชอบ -

การจัดการคน

  • ทำหน้าที่เป็นหัวหน้าโครงการ
  • รอยโรคกับผู้มีส่วนได้ส่วนเสีย
  • การจัดการทรัพยากรมนุษย์
  • การตั้งค่าลำดับชั้นการรายงานเป็นต้น

การจัดการโครงการ

  • การกำหนดและตั้งค่าขอบเขตโครงการ
  • การจัดการกิจกรรมการจัดการโครงการ
  • ติดตามความคืบหน้าและประสิทธิภาพ
  • การวิเคราะห์ความเสี่ยงทุกระยะ
  • ทำตามขั้นตอนที่จำเป็นเพื่อหลีกเลี่ยงหรือออกมาจากปัญหา
  • ทำหน้าที่เป็นโฆษกโครงการ

กิจกรรมการจัดการซอฟต์แวร์

การจัดการโครงการซอฟต์แวร์ประกอบด้วยกิจกรรมหลายอย่างซึ่งประกอบด้วยการวางแผนโครงการขอบเขตการตัดสินใจของผลิตภัณฑ์ซอฟต์แวร์การประมาณต้นทุนในแง่ต่างๆการจัดกำหนดการงานและเหตุการณ์และการจัดการทรัพยากร กิจกรรมการบริหารโครงการอาจรวมถึง:

  • Project Planning
  • Scope Management
  • Project Estimation

การวางแผนโครงการ

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

การจัดการขอบเขต

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

ในระหว่างการจัดการ Project Scope จำเป็นต้อง -

  • กำหนดขอบเขต
  • ตัดสินใจตรวจสอบและควบคุม
  • แบ่งโครงการออกเป็นส่วนย่อย ๆ เพื่อความสะดวกในการจัดการ
  • ตรวจสอบขอบเขต
  • ควบคุมขอบเขตโดยรวมการเปลี่ยนแปลงเข้ากับขอบเขต

การประมาณโครงการ

สำหรับการจัดการที่มีประสิทธิภาพการประมาณค่าที่ถูกต้องของมาตรการต่างๆเป็นสิ่งจำเป็น ด้วยผู้จัดการการประเมินที่ถูกต้องสามารถจัดการและควบคุมโครงการได้อย่างมีประสิทธิภาพและประสิทธิผลมากขึ้น

การประมาณโครงการอาจเกี่ยวข้องกับสิ่งต่อไปนี้:

  • Software size estimation

    ขนาดของซอฟต์แวร์อาจประมาณได้ทั้งในรูปแบบของ KLOC (Kilo Line of Code) หรือโดยการคำนวณจำนวนจุดฟังก์ชันในซอฟต์แวร์ บรรทัดของโค้ดขึ้นอยู่กับแนวทางการเข้ารหัสและจุดฟังก์ชันแตกต่างกันไปตามความต้องการของผู้ใช้หรือซอฟต์แวร์

  • Effort estimation

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

  • Time estimation

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

    ผลรวมของเวลาที่ต้องใช้ในการทำงานทั้งหมดในชั่วโมงหรือวันคือเวลาทั้งหมดที่ลงทุนเพื่อทำโครงการให้เสร็จ

  • Cost estimation

    สิ่งนี้อาจถือได้ว่าเป็นสิ่งที่ยากที่สุดเนื่องจากขึ้นอยู่กับองค์ประกอบมากกว่าองค์ประกอบก่อนหน้านี้ สำหรับการประมาณต้นทุนโครงการจำเป็นต้องพิจารณา -

    • ขนาดของซอฟต์แวร์
    • คุณภาพซอฟต์แวร์
    • Hardware
    • ซอฟต์แวร์หรือเครื่องมือเพิ่มเติมใบอนุญาต ฯลฯ
    • บุคลากรที่มีทักษะและทักษะเฉพาะงาน
    • การเดินทางเกี่ยวข้อง
    • Communication
    • การฝึกอบรมและการสนับสนุน

เทคนิคการประมาณโครงการ

เราได้กล่าวถึงพารามิเตอร์ต่างๆที่เกี่ยวข้องกับการประมาณโครงการเช่นขนาดความพยายามเวลาและต้นทุน

ผู้จัดการโครงการสามารถประมาณปัจจัยที่ระบุไว้โดยใช้เทคนิคที่ได้รับการยอมรับอย่างกว้างขวางสองประการ -

เทคนิคการสลายตัว

เทคนิคนี้ถือว่าซอฟต์แวร์เป็นผลิตภัณฑ์จากองค์ประกอบต่างๆ

มีสองรุ่นหลัก -

  • Line of Code การประมาณจะกระทำในนามของจำนวนบรรทัดของรหัสในผลิตภัณฑ์ซอฟต์แวร์
  • Function Points การประมาณจะกระทำในนามของจำนวนฟังก์ชันพอยต์ในผลิตภัณฑ์ซอฟต์แวร์

เทคนิคการประมาณค่าเชิงประจักษ์

เทคนิคนี้ใช้สูตรที่ได้จากเชิงประจักษ์เพื่อทำการประมาณค่าสูตรเหล่านี้อ้างอิงจาก LOC หรือ FPs

  • Putnam Model

    แบบจำลองนี้จัดทำโดย Lawrence H. Putnam ซึ่งอ้างอิงจากการแจกแจงความถี่ของ Norden (เส้นโค้ง Rayleigh) พัทโมเดลแมปเวลาและความพยายามที่จำเป็นกับขนาดซอฟต์แวร์

  • COCOMO

    COCOMO ย่อมาจาก COnstructive COst MOdel ซึ่งพัฒนาโดย Barry W. Boehm มันแบ่งผลิตภัณฑ์ซอฟต์แวร์ออกเป็นสามประเภทของซอฟต์แวร์: ออร์แกนิกกึ่งแยกเดี่ยวและแบบฝัง

การจัดกำหนดการโครงการ

การจัดกำหนดการโครงการในโครงการหมายถึงแผนงานของกิจกรรมทั้งหมดที่ต้องทำตามลำดับที่ระบุและภายในช่วงเวลาที่กำหนดให้กับแต่ละกิจกรรม ผู้จัดการโครงการมีแนวโน้มที่จะกำหนดงานต่างๆและเหตุการณ์สำคัญของโครงการและจัดเตรียมโดยคำนึงถึงปัจจัยต่างๆ พวกเขามองหางานที่อยู่ในเส้นทางที่สำคัญในตารางเวลาซึ่งจำเป็นต้องทำให้เสร็จในลักษณะเฉพาะ (เนื่องจากการพึ่งพาซึ่งกันและกันของงาน) และอย่างเคร่งครัดภายในเวลาที่จัดสรร การจัดเตรียมงานที่อยู่นอกเส้นทางวิกฤตมีโอกาสน้อยที่จะส่งผลกระทบต่อกำหนดการทั้งหมดของโครงการ

สำหรับการจัดกำหนดการโครงการจำเป็นต้อง -

  • แบ่งงานโครงการออกเป็นรูปแบบที่เล็กลงและจัดการได้
  • ค้นหางานต่างๆและเชื่อมโยงกัน
  • ประมาณกรอบเวลาที่จำเป็นสำหรับแต่ละงาน
  • แบ่งเวลาออกเป็นหน่วยงาน
  • กำหนดจำนวนหน่วยงานที่เพียงพอสำหรับแต่ละงาน
  • คำนวณเวลาทั้งหมดที่ต้องใช้สำหรับโครงการตั้งแต่ต้นจนจบ

การจัดการทรัพยากร

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

ทรัพยากรมีอยู่ในปริมาณที่ จำกัด และอยู่ในองค์กรเป็นแหล่งรวมของทรัพย์สิน การขาดแคลนทรัพยากรเป็นอุปสรรคต่อการพัฒนาโครงการและอาจล้าหลังกว่ากำหนดการ การจัดสรรทรัพยากรพิเศษเพิ่มต้นทุนการพัฒนาในที่สุด ดังนั้นจึงจำเป็นต้องประมาณการและจัดสรรทรัพยากรให้เพียงพอสำหรับโครงการ

การจัดการทรัพยากรประกอบด้วย -

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

การบริหารความเสี่ยงโครงการ

การบริหารความเสี่ยงเกี่ยวข้องกับกิจกรรมทั้งหมดที่เกี่ยวข้องกับการระบุวิเคราะห์และจัดเตรียมข้อกำหนดสำหรับความเสี่ยงที่คาดการณ์ได้และไม่สามารถคาดเดาได้ในโครงการ ความเสี่ยงอาจรวมถึงสิ่งต่อไปนี้:

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

กระบวนการบริหารความเสี่ยง

กิจกรรมที่เกี่ยวข้องในกระบวนการบริหารความเสี่ยงมีดังต่อไปนี้:

  • Identification - จดบันทึกความเสี่ยงทั้งหมดที่อาจเกิดขึ้นในโครงการ
  • Categorize - จัดหมวดหมู่ความเสี่ยงที่ทราบเป็นระดับความเสี่ยงสูงปานกลางและต่ำตามผลกระทบที่เป็นไปได้ต่อโครงการ
  • Manage - วิเคราะห์ความน่าจะเป็นของการเกิดความเสี่ยงในระยะต่างๆ วางแผนเพื่อหลีกเลี่ยงหรือเผชิญกับความเสี่ยง พยายามลดผลข้างเคียงให้น้อยที่สุด
  • Monitor - ติดตามความเสี่ยงที่อาจเกิดขึ้นและอาการเริ่มแรกของพวกเขาอย่างใกล้ชิด ตรวจสอบผลกระทบของขั้นตอนที่ดำเนินการเพื่อลดหรือหลีกเลี่ยง

การดำเนินการและการตรวจสอบโครงการ

ในขั้นตอนนี้งานที่อธิบายไว้ในแผนโครงการจะดำเนินการตามกำหนดเวลา

การดำเนินการต้องมีการตรวจสอบเพื่อตรวจสอบว่าทุกอย่างเป็นไปตามแผนหรือไม่ การเฝ้าติดตามคือการสังเกตเพื่อตรวจสอบความน่าจะเป็นของความเสี่ยงและใช้มาตรการเพื่อจัดการกับความเสี่ยงหรือรายงานสถานะของงานต่างๆ

มาตรการเหล่านี้ ได้แก่ -

  • Activity Monitoring - กิจกรรมทั้งหมดที่กำหนดไว้ในบางงานสามารถตรวจสอบได้แบบวันต่อวัน เมื่อกิจกรรมทั้งหมดในงานเสร็จสิ้นจะถือว่าเสร็จสมบูรณ์
  • Status Reports - รายงานประกอบด้วยสถานะของกิจกรรมและงานที่เสร็จสิ้นภายในกรอบเวลาที่กำหนดโดยทั่วไปหนึ่งสัปดาห์ สถานะสามารถทำเครื่องหมายว่าเสร็จสิ้นรอดำเนินการหรืองานระหว่างดำเนินการเป็นต้น
  • Milestones Checklist - ทุกโครงการแบ่งออกเป็นหลายขั้นตอนซึ่งมีการดำเนินงานหลัก (เหตุการณ์สำคัญ) ตามขั้นตอนของ SDLC รายการตรวจสอบความสำเร็จนี้จัดทำขึ้นทุกๆสองสามสัปดาห์และรายงานสถานะของเหตุการณ์สำคัญ

การจัดการการสื่อสารโครงการ

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

การสื่อสารสามารถพูดหรือเขียนได้ กระบวนการจัดการการสื่อสารอาจมีขั้นตอนดังต่อไปนี้:

  • Planning - ขั้นตอนนี้รวมถึงการระบุผู้มีส่วนได้ส่วนเสียทั้งหมดในโครงการและโหมดการสื่อสารระหว่างกัน นอกจากนี้ยังพิจารณาว่าจำเป็นต้องมีสิ่งอำนวยความสะดวกด้านการสื่อสารเพิ่มเติมหรือไม่
  • Sharing - หลังจากกำหนดแง่มุมต่างๆของการวางแผนแล้วผู้จัดการจะเน้นที่การแบ่งปันข้อมูลที่ถูกต้องกับบุคคลที่ถูกต้องในเวลาที่ถูกต้อง ซึ่งจะช่วยให้ทุกคนที่เกี่ยวข้องกับโครงการมีความคืบหน้าและสถานะของโครงการอยู่เสมอ
  • Feedback - ผู้จัดการโครงการใช้มาตรการต่างๆและกลไกการตอบกลับและสร้างรายงานสถานะและประสิทธิภาพ กลไกนี้ช่วยให้มั่นใจได้ว่าข้อมูลจากผู้มีส่วนได้ส่วนเสียต่างๆจะมาถึงผู้จัดการโครงการตามข้อเสนอแนะของพวกเขา
  • Closure - ในตอนท้ายของเหตุการณ์สำคัญแต่ละครั้งการสิ้นสุดขั้นตอนของ SDLC หรือการสิ้นสุดของโครงการจะมีการประกาศการปิดการดูแลระบบอย่างเป็นทางการเพื่ออัปเดตผู้มีส่วนได้ส่วนเสียทุกคนโดยการส่งอีเมลโดยแจกจ่ายสำเนาเอกสารหรือด้วยวิธีการสื่อสารที่มีประสิทธิภาพอื่น ๆ

หลังจากปิดแล้วทีมจะย้ายไปยังเฟสหรือโครงการถัดไป

การจัดการการตั้งค่า

การจัดการการกำหนดค่าเป็นกระบวนการติดตามและควบคุมการเปลี่ยนแปลงของซอฟต์แวร์ในแง่ของข้อกำหนดการออกแบบฟังก์ชันและการพัฒนาผลิตภัณฑ์

IEEE กำหนดให้เป็น“ กระบวนการในการระบุและกำหนดรายการในระบบการควบคุมการเปลี่ยนแปลงของรายการเหล่านี้ตลอดวงจรชีวิตการบันทึกและรายงานสถานะของรายการและการร้องขอการเปลี่ยนแปลงและการตรวจสอบความสมบูรณ์และความถูกต้องของรายการ”

โดยทั่วไปเมื่อสรุป SRS แล้วจะมีโอกาสน้อยกว่าที่จะมีการเปลี่ยนแปลงข้อกำหนดจากผู้ใช้ หากเกิดขึ้นการเปลี่ยนแปลงจะได้รับการแก้ไขโดยได้รับการอนุมัติล่วงหน้าจากฝ่ายบริหารที่สูงขึ้นเท่านั้นเนื่องจากมีความเป็นไปได้ที่จะมีค่าใช้จ่ายและเวลามากเกินไป

พื้นฐาน

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

การจัดการการกำหนดค่าเป็นระเบียบวินัยของการบริหารองค์กรซึ่งดูแลการเปลี่ยนแปลงใด ๆ (กระบวนการความต้องการเทคโนโลยีกลยุทธ์ ฯลฯ ) หลังจากเฟสถูกกำหนดพื้นฐาน CM คอยตรวจสอบการเปลี่ยนแปลงที่เกิดขึ้นในซอฟต์แวร์

การเปลี่ยนแปลงการควบคุม

การควบคุมการเปลี่ยนแปลงเป็นหน้าที่ของการจัดการการกำหนดค่าซึ่งทำให้มั่นใจได้ว่าการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับระบบซอฟต์แวร์นั้นสอดคล้องและเป็นไปตามกฎและข้อบังคับขององค์กร

การเปลี่ยนแปลงการกำหนดค่าของผลิตภัณฑ์ต้องทำตามขั้นตอนต่อไปนี้ -

  • Identification- คำขอเปลี่ยนแปลงมาจากแหล่งภายในหรือภายนอก เมื่อมีการระบุคำขอเปลี่ยนแปลงอย่างเป็นทางการจะมีการจัดทำเป็นเอกสารอย่างถูกต้อง

  • Validation - ตรวจสอบความถูกต้องของคำขอเปลี่ยนแปลงและขั้นตอนการจัดการได้รับการยืนยัน

  • Analysis- ผลกระทบของการร้องขอการเปลี่ยนแปลงได้รับการวิเคราะห์ในแง่ของกำหนดเวลาต้นทุนและความพยายามที่จำเป็น วิเคราะห์ผลกระทบโดยรวมของการเปลี่ยนแปลงที่คาดหวังในระบบ

  • Control- หากการเปลี่ยนแปลงในอนาคตส่งผลกระทบต่อเอนทิตีจำนวนมากเกินไปในระบบหรือหลีกเลี่ยงไม่ได้จำเป็นต้องได้รับการอนุมัติจากหน่วยงานระดับสูงก่อนที่การเปลี่ยนแปลงจะรวมเข้ากับระบบ มีการตัดสินใจว่าการเปลี่ยนแปลงนั้นคุ้มค่าหรือไม่ หากไม่เป็นเช่นนั้นคำขอเปลี่ยนแปลงจะถูกปฏิเสธอย่างเป็นทางการ

  • Execution - หากเฟสก่อนหน้ากำหนดให้ดำเนินการร้องขอการเปลี่ยนแปลงเฟสนี้จะดำเนินการที่เหมาะสมเพื่อดำเนินการเปลี่ยนแปลงทำการแก้ไขอย่างละเอียดหากจำเป็น

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

เครื่องมือการจัดการโครงการ

ความเสี่ยงและความไม่แน่นอนเพิ่มขึ้นหลายเท่าเมื่อเทียบกับขนาดของโครงการแม้ว่าโครงการจะได้รับการพัฒนาตามวิธีการที่กำหนด

มีเครื่องมือที่ช่วยในการจัดการโครงการอย่างมีประสิทธิภาพ มีการอธิบายไว้เล็กน้อย -

แผนภูมิแกนต์

แผนภูมิแกนต์ถูกคิดค้นโดย Henry Gantt (1917) แสดงถึงกำหนดการโครงการตามช่วงเวลา เป็นแผนภูมิแท่งแนวนอนที่มีแถบแสดงกิจกรรมและเวลาที่กำหนดไว้สำหรับกิจกรรมโครงการ

แผนภูมิ PERT

แผนภูมิ PERT (Program Evaluation & Review Technique) เป็นเครื่องมือที่แสดงโครงการเป็นแผนภาพเครือข่าย สามารถแสดงภาพเหตุการณ์หลักของโครงการได้ทั้งแบบคู่ขนานและต่อเนื่องกัน เหตุการณ์ที่เกิดขึ้นทีละเหตุการณ์จะแสดงการพึ่งพาของเหตุการณ์ในภายหลังมากกว่าเหตุการณ์ก่อนหน้า

เหตุการณ์จะแสดงเป็นโหนดที่มีหมายเลข เชื่อมต่อกันด้วยลูกศรที่มีป้ายกำกับซึ่งแสดงลำดับของงานในโครงการ

ฮิสโตแกรมทรัพยากร

นี่คือเครื่องมือกราฟิกที่มีแถบหรือแผนภูมิที่แสดงถึงจำนวนทรัพยากร (โดยปกติจะเป็นพนักงานที่มีทักษะ) ซึ่งต้องใช้ในช่วงเวลาหนึ่งสำหรับกิจกรรมโครงการ (หรือเฟส) ฮิสโตแกรมทรัพยากรเป็นเครื่องมือที่มีประสิทธิภาพสำหรับการวางแผนและการประสานงานของพนักงาน

การวิเคราะห์เส้นทางที่สำคัญ

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

กิจกรรมต่างๆจะจัดเรียงตามเวลาเริ่มต้นที่เร็วที่สุด เส้นทางระหว่างโหนดเริ่มต้นและโหนดปลายทางเป็นเส้นทางวิกฤตซึ่งไม่สามารถลดได้อีกและเหตุการณ์ทั้งหมดจำเป็นต้องดำเนินการตามลำดับเดียวกัน

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

วิศวกรรมความต้องการ

กระบวนการรวบรวมข้อกำหนดซอฟต์แวร์จากไคลเอนต์วิเคราะห์และจัดทำเป็นเอกสารเรียกว่าวิศวกรรมความต้องการ

เป้าหมายของวิศวกรรมความต้องการคือการพัฒนาและรักษาเอกสาร 'ข้อกำหนดข้อกำหนดของระบบ' ที่ซับซ้อนและมีความหมาย

กระบวนการวิศวกรรมความต้องการ

เป็นกระบวนการสี่ขั้นตอนซึ่งประกอบด้วย -

  • การศึกษาความเป็นไปได้
  • การรวบรวมความต้องการ
  • ข้อกำหนดข้อกำหนดของซอฟต์แวร์
  • การตรวจสอบความต้องการซอฟต์แวร์

ให้เราดูกระบวนการโดยย่อ -

การศึกษาความเป็นไปได้

เมื่อลูกค้าเข้าใกล้องค์กรเพื่อรับผลิตภัณฑ์ที่ต้องการได้รับการพัฒนาจะมีแนวคิดคร่าวๆเกี่ยวกับฟังก์ชันทั้งหมดที่ซอฟต์แวร์ต้องดำเนินการและคุณลักษณะทั้งหมดที่คาดหวังจากซอฟต์แวร์

เมื่ออ้างอิงถึงข้อมูลนี้นักวิเคราะห์จะทำการศึกษาโดยละเอียดว่าระบบและฟังก์ชันการทำงานที่ต้องการนั้นมีความเป็นไปได้ที่จะพัฒนาหรือไม่

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

ผลลัพธ์ของระยะนี้ควรเป็นรายงานการศึกษาความเป็นไปได้ที่ควรมีข้อคิดเห็นและข้อเสนอแนะที่เพียงพอสำหรับการจัดการว่าควรดำเนินโครงการหรือไม่

การรวบรวมความต้องการ

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

ข้อกำหนดข้อกำหนดของซอฟต์แวร์

SRS เป็นเอกสารที่สร้างขึ้นโดยนักวิเคราะห์ระบบหลังจากรวบรวมข้อกำหนดจากผู้มีส่วนได้ส่วนเสียต่างๆ

SRS กำหนดวิธีที่ซอฟต์แวร์ที่ต้องการจะโต้ตอบกับฮาร์ดแวร์อินเทอร์เฟซภายนอกความเร็วในการทำงานเวลาตอบสนองของระบบความสามารถในการพกพาซอฟต์แวร์ข้ามแพลตฟอร์มต่างๆการบำรุงรักษาความเร็วในการกู้คืนหลังจากเกิดปัญหาความปลอดภัยคุณภาพข้อ จำกัด ฯลฯ

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

SRS ควรมาพร้อมกับคุณสมบัติดังต่อไปนี้:

  • ข้อกำหนดของผู้ใช้จะแสดงเป็นภาษาธรรมชาติ
  • ข้อกำหนดทางเทคนิคจะแสดงเป็นภาษาที่มีโครงสร้างซึ่งใช้ภายในองค์กร
  • คำอธิบายการออกแบบควรเขียนด้วยรหัส Pseudo
  • รูปแบบของการพิมพ์หน้าจอแบบฟอร์มและ GUI
  • สัญกรณ์เชิงเงื่อนไขและคณิตศาสตร์สำหรับ DFD เป็นต้น

การตรวจสอบความต้องการซอฟต์แวร์

หลังจากมีการพัฒนาข้อกำหนดข้อกำหนดข้อกำหนดที่ระบุไว้ในเอกสารนี้จะได้รับการตรวจสอบความถูกต้อง ผู้ใช้อาจขอวิธีแก้ปัญหาที่ผิดกฎหมายไม่สามารถใช้งานได้จริงหรือผู้เชี่ยวชาญอาจตีความข้อกำหนดไม่ถูกต้อง ส่งผลให้ต้นทุนเพิ่มขึ้นอย่างมากหากไม่ได้แทงหน่อ ข้อกำหนดสามารถตรวจสอบได้ตามเงื่อนไขต่อไปนี้ -

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

ขั้นตอนการลบความต้องการ

กระบวนการกระตุ้นความต้องการสามารถแสดงได้โดยใช้แผนภาพ folloiwng:

  • Requirements gathering - นักพัฒนาจะพูดคุยกับลูกค้าและผู้ใช้ปลายทางและรู้ความคาดหวังของพวกเขาจากซอฟต์แวร์
  • Organizing Requirements - ผู้พัฒนาจัดลำดับความสำคัญและจัดเรียงข้อกำหนดตามลำดับความสำคัญความเร่งด่วนและความสะดวก

  • Negotiation & discussion - หากข้อกำหนดมีความคลุมเครือหรือมีข้อขัดแย้งบางประการในข้อกำหนดของผู้มีส่วนได้ส่วนเสียต่างๆหากเป็นเช่นนั้นจะมีการเจรจาและหารือกับผู้มีส่วนได้เสีย จากนั้นข้อกำหนดอาจได้รับการจัดลำดับความสำคัญและลดทอนอย่างสมเหตุสมผล

    ข้อกำหนดมาจากผู้มีส่วนได้ส่วนเสียต่างๆ เพื่อขจัดความคลุมเครือและความขัดแย้งจะมีการหารือเพื่อความชัดเจนและถูกต้อง ข้อกำหนดที่ไม่สมจริงถูกบุกรุกอย่างมีเหตุผล

  • Documentation - ข้อกำหนดที่เป็นทางการและไม่เป็นทางการใช้งานได้และไม่ใช้งานได้ทั้งหมดได้รับการจัดทำเป็นเอกสารและพร้อมใช้งานสำหรับการประมวลผลขั้นต่อไป

เทคนิคการปลดปล่อยความต้องการ

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

มีหลายวิธีในการค้นหาข้อกำหนด

บทสัมภาษณ์

การสัมภาษณ์เป็นสื่อที่แข็งแกร่งในการรวบรวมข้อกำหนด องค์กรอาจทำการสัมภาษณ์หลายประเภทเช่น:

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

แบบสำรวจ

องค์กรอาจทำการสำรวจในกลุ่มผู้มีส่วนได้ส่วนเสียต่างๆโดยสอบถามเกี่ยวกับความคาดหวังและความต้องการของพวกเขาจากระบบที่กำลังจะเกิดขึ้น

แบบสอบถาม

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

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

การวิเคราะห์งาน

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

การวิเคราะห์โดเมน

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

การระดมความคิด

การอภิปรายอย่างไม่เป็นทางการจัดขึ้นระหว่างผู้มีส่วนได้ส่วนเสียต่างๆและข้อมูลทั้งหมดของพวกเขาจะถูกบันทึกไว้เพื่อการวิเคราะห์ข้อกำหนดเพิ่มเติม

การสร้างต้นแบบ

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

การสังเกต

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

ลักษณะข้อกำหนดของซอฟต์แวร์

การรวบรวมข้อกำหนดซอฟต์แวร์เป็นรากฐานของโครงการพัฒนาซอฟต์แวร์ทั้งหมด ดังนั้นจึงต้องมีความชัดเจนถูกต้องและชัดเจน

ข้อกำหนดข้อกำหนดซอฟต์แวร์ที่สมบูรณ์ต้องเป็น:

  • Clear
  • Correct
  • Consistent
  • Coherent
  • Comprehensible
  • Modifiable
  • Verifiable
  • Prioritized
  • Unambiguous
  • Traceable
  • แหล่งที่มาที่น่าเชื่อถือ

ข้อกำหนดของซอฟต์แวร์

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

ความต้องการซอฟต์แวร์โดยกว้างควรแบ่งออกเป็นสองประเภท:

ความต้องการการทำงาน

ข้อกำหนดซึ่งเกี่ยวข้องกับลักษณะการทำงานของซอฟต์แวร์จัดอยู่ในหมวดหมู่นี้

พวกเขากำหนดฟังก์ชันและฟังก์ชันการทำงานภายในและจากระบบซอฟต์แวร์

ตัวอย่าง -

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

ข้อกำหนดที่ไม่ใช่หน้าที่

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

ข้อกำหนดที่ไม่ใช้งาน ได้แก่ -

  • Security
  • Logging
  • Storage
  • Configuration
  • Performance
  • Cost
  • Interoperability
  • Flexibility
  • การกู้คืนระบบ
  • Accessibility

ข้อกำหนดถูกจัดประเภทตามเหตุผลเป็น

  • Must Have : ซอฟต์แวร์ไม่สามารถพูดได้ว่าใช้งานได้หากไม่มีพวกเขา
  • Should have : การปรับปรุงการทำงานของซอฟต์แวร์
  • Could have : ซอฟต์แวร์ยังคงสามารถทำงานได้อย่างถูกต้องตามข้อกำหนดเหล่านี้
  • Wish list : ข้อกำหนดเหล่านี้ไม่ได้จับคู่กับวัตถุประสงค์ใด ๆ ของซอฟต์แวร์

ในขณะที่พัฒนาซอฟต์แวร์ต้องใช้ "สิ่งที่ต้องมี" "สิ่งที่ควรมี" เป็นประเด็นของการถกเถียงกับผู้มีส่วนได้ส่วนเสียและการปฏิเสธในขณะที่ "สามารถมี" และ "รายการที่ต้องการ" สามารถเก็บไว้เพื่ออัปเดตซอฟต์แวร์ได้

ข้อกำหนดส่วนติดต่อผู้ใช้

UI เป็นส่วนสำคัญของซอฟต์แวร์หรือฮาร์ดแวร์หรือระบบไฮบริด ซอฟต์แวร์ได้รับการยอมรับอย่างกว้างขวางหากเป็น -

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

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

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

นักวิเคราะห์ระบบซอฟต์แวร์

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

นักวิเคราะห์ระบบมีหน้าที่รับผิดชอบดังต่อไปนี้:

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

เมตริกและมาตรการของซอฟต์แวร์

การวัดซอฟต์แวร์สามารถเข้าใจได้ว่าเป็นกระบวนการในการหาปริมาณและเป็นสัญลักษณ์ของคุณลักษณะและลักษณะต่างๆของซอฟต์แวร์

Software Metrics ให้มาตรการสำหรับด้านต่างๆของกระบวนการซอฟต์แวร์และผลิตภัณฑ์ซอฟต์แวร์

มาตรการด้านซอฟต์แวร์เป็นข้อกำหนดพื้นฐานของวิศวกรรมซอฟต์แวร์ พวกเขาไม่เพียง แต่ช่วยควบคุมกระบวนการพัฒนาซอฟต์แวร์ แต่ยังช่วยรักษาคุณภาพของผลิตภัณฑ์ขั้นสูงสุดให้ดีเยี่ยม

ตามที่ Tom DeMarco (วิศวกรซอฟต์แวร์) กล่าวว่า“ คุณไม่สามารถควบคุมสิ่งที่คุณไม่สามารถวัดผลได้” จากคำพูดของเขาเป็นที่ชัดเจนมากว่ามาตรการซอฟต์แวร์มีความสำคัญอย่างไร

ให้เราดูเมตริกซอฟต์แวร์:

  • Size Metrics - LOC (Lines of Code) ซึ่งส่วนใหญ่คำนวณจากซอร์สโค้ดที่จัดส่งหลายพันบรรทัดแสดงเป็น KLOC

    Function Point Count คือการวัดฟังก์ชันการทำงานที่ซอฟต์แวร์มีให้ การนับคะแนนฟังก์ชันกำหนดขนาดของลักษณะการทำงานของซอฟต์แวร์

  • Complexity Metrics - ความซับซ้อนของ Cyclomatic ของ McCabe จะวัดขอบเขตบนของจำนวนเส้นทางอิสระในโปรแกรมซึ่งถูกมองว่าเป็นความซับซ้อนของโปรแกรมหรือโมดูลของโปรแกรม มันแสดงในแง่ของแนวคิดทฤษฎีกราฟโดยใช้กราฟการไหลของการควบคุม

  • Quality Metrics - ข้อบกพร่องประเภทและสาเหตุผลที่ตามมาความรุนแรงของความรุนแรงและผลกระทบเป็นตัวกำหนดคุณภาพของผลิตภัณฑ์

    จำนวนข้อบกพร่องที่พบในกระบวนการพัฒนาและจำนวนข้อบกพร่องที่ลูกค้ารายงานหลังจากติดตั้งหรือส่งมอบผลิตภัณฑ์ที่ลูกค้าปลายทางกำหนดคุณภาพของผลิตภัณฑ์

  • Process Metrics - ในขั้นตอนต่างๆของ SDLC วิธีการและเครื่องมือที่ใช้มาตรฐานของ บริษัท และประสิทธิภาพของการพัฒนาคือเมตริกกระบวนการซอฟต์แวร์
  • Resource Metrics - ความพยายามเวลาและทรัพยากรต่างๆที่ใช้แสดงถึงเมตริกสำหรับการวัดทรัพยากร

การออกแบบซอฟต์แวร์เป็นกระบวนการในการเปลี่ยนความต้องการของผู้ใช้ให้อยู่ในรูปแบบที่เหมาะสมซึ่งช่วยโปรแกรมเมอร์ในการเข้ารหัสและการนำไปใช้งานซอฟต์แวร์

สำหรับการประเมินความต้องการของผู้ใช้เอกสาร SRS (ข้อกำหนดข้อกำหนดของซอฟต์แวร์) จะถูกสร้างขึ้นในขณะที่สำหรับการเข้ารหัสและการนำไปใช้งานจำเป็นต้องมีข้อกำหนดที่เฉพาะเจาะจงและมีรายละเอียดมากขึ้นในแง่ของซอฟต์แวร์ ผลลัพธ์ของกระบวนการนี้สามารถนำไปใช้ในการใช้งานภาษาโปรแกรมได้โดยตรง

การออกแบบซอฟต์แวร์เป็นขั้นตอนแรกใน SDLC (Software Design Life Cycle) ซึ่งย้ายความเข้มข้นจากโดเมนปัญหาไปยังโดเมนโซลูชัน พยายามระบุวิธีปฏิบัติตามข้อกำหนดที่กล่าวถึงใน SRS

ระดับการออกแบบซอฟต์แวร์

การออกแบบซอฟต์แวร์ให้ผลลัพธ์สามระดับ:

  • Architectural Design - การออกแบบสถาปัตยกรรมเป็นระบบนามธรรมรุ่นสูงสุด ระบุซอฟต์แวร์เป็นระบบที่มีส่วนประกอบหลายอย่างที่โต้ตอบกัน ในระดับนี้นักออกแบบจะได้รับแนวคิดเกี่ยวกับโดเมนโซลูชันที่เสนอ
  • High-level Design- การออกแบบระดับสูงแบ่งแนวคิด 'องค์ประกอบเดียว - หลายองค์ประกอบ' ของการออกแบบสถาปัตยกรรมออกเป็นมุมมองที่เป็นนามธรรมน้อยลงของระบบย่อยและโมดูลและแสดงให้เห็นถึงปฏิสัมพันธ์ระหว่างกัน การออกแบบระดับสูงมุ่งเน้นไปที่วิธีการนำระบบพร้อมกับส่วนประกอบทั้งหมดไปใช้งานในรูปแบบของโมดูล รับรู้โครงสร้างโมดูลาร์ของแต่ละระบบย่อยและความสัมพันธ์และปฏิสัมพันธ์ระหว่างกัน
  • Detailed Design- การออกแบบโดยละเอียดเกี่ยวข้องกับส่วนการนำไปใช้งานของสิ่งที่เห็นว่าเป็นระบบและระบบย่อยในสองการออกแบบก่อนหน้านี้ มีรายละเอียดเพิ่มเติมเกี่ยวกับโมดูลและการนำไปใช้งาน เป็นการกำหนดโครงสร้างเชิงตรรกะของแต่ละโมดูลและอินเทอร์เฟซเพื่อสื่อสารกับโมดูลอื่น ๆ

Modularization

Modularization เป็นเทคนิคในการแบ่งระบบซอฟต์แวร์ออกเป็นโมดูลที่แยกจากกันและแยกกันหลาย ๆ โมดูลซึ่งคาดว่าจะสามารถทำงานได้อย่างอิสระ โมดูลเหล่านี้อาจทำงานเป็นโครงสร้างพื้นฐานสำหรับซอฟต์แวร์ทั้งหมด นักออกแบบมักจะออกแบบโมดูลเพื่อให้สามารถใช้งานและ / หรือคอมไพล์แยกกันและเป็นอิสระ

การออกแบบโมดูลาร์เป็นไปตามกฎของกลยุทธ์การแก้ปัญหาแบบ 'แบ่งและพิชิต' โดยไม่ได้ตั้งใจเนื่องจากมีประโยชน์อื่น ๆ อีกมากมายที่มาพร้อมกับการออกแบบโมดูลของซอฟต์แวร์

ข้อดีของการแยกส่วน:

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

ภาวะพร้อมกัน

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

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

จำเป็นสำหรับโปรแกรมเมอร์และนักออกแบบที่จะต้องจดจำโมดูลเหล่านั้นซึ่งสามารถดำเนินการแบบขนานได้

ตัวอย่าง

คุณลักษณะการตรวจสอบการสะกดในโปรแกรมประมวลผลคำเป็นโมดูลของซอฟต์แวร์ซึ่งทำงานควบคู่ไปกับโปรแกรมประมวลผลคำ

การเชื่อมต่อและการทำงานร่วมกัน

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

การติดต่อกัน

การทำงานร่วมกันเป็นมาตรการที่กำหนดระดับของความสามารถในการพึ่งพาภายในองค์ประกอบของโมดูล การทำงานร่วมกันที่ดีกว่าคือการออกแบบโปรแกรม

การทำงานร่วมกันมี 7 ประเภท ได้แก่ -

  • Co-incidental cohesion -เป็นการทำงานร่วมกันโดยไม่ได้วางแผนและสุ่มซึ่งอาจเป็นผลมาจากการแบ่งโปรแกรมออกเป็นโมดูลขนาดเล็กเพื่อประโยชน์ในการแยกส่วน เนื่องจากไม่ได้วางแผนไว้จึงอาจสร้างความสับสนให้กับโปรแกรมเมอร์และโดยทั่วไปไม่ได้รับการยอมรับ
  • Logical cohesion - เมื่อองค์ประกอบที่จัดหมวดหมู่อย่างมีเหตุผลถูกรวมเข้าด้วยกันในโมดูลจะเรียกว่าการทำงานร่วมกันทางตรรกะ
  • emporal Cohesion - เมื่อองค์ประกอบของโมดูลได้รับการจัดระเบียบเพื่อให้ได้รับการประมวลผลในช่วงเวลาใกล้เคียงกันจะเรียกว่าการทำงานร่วมกันชั่วคราว
  • Procedural cohesion - เมื่อองค์ประกอบของโมดูลถูกจัดกลุ่มเข้าด้วยกันซึ่งจะดำเนินการตามลำดับเพื่อดำเนินงานเรียกว่าการทำงานร่วมกันตามขั้นตอน
  • Communicational cohesion - เมื่อองค์ประกอบของโมดูลถูกจัดกลุ่มเข้าด้วยกันซึ่งดำเนินการตามลำดับและทำงานกับข้อมูลเดียวกัน (ข้อมูล) จะเรียกว่าการทำงานร่วมกันของการสื่อสาร
  • Sequential cohesion - เมื่อองค์ประกอบของโมดูลถูกจัดกลุ่มเนื่องจากเอาต์พุตขององค์ประกอบหนึ่งทำหน้าที่เป็นอินพุตไปยังอีกองค์ประกอบหนึ่งจึงเรียกว่าการเชื่อมต่อกันตามลำดับ
  • Functional cohesion - ถือเป็นการร่วมแรงร่วมใจกันในระดับสูงสุดและเป็นที่คาดหวังอย่างมาก องค์ประกอบของโมดูลในการทำงานร่วมกันของฟังก์ชันถูกจัดกลุ่มเนื่องจากทั้งหมดมีส่วนทำให้เกิดฟังก์ชันที่กำหนดไว้อย่างดีเพียงฟังก์ชันเดียว นอกจากนี้ยังสามารถใช้ซ้ำได้

การมีเพศสัมพันธ์

การเชื่อมต่อเป็นมาตรการที่กำหนดระดับของการพึ่งพาระหว่างโมดูลของโปรแกรม จะบอกว่าโมดูลรบกวนและโต้ตอบกันในระดับใด ยิ่ง coupling ต่ำโปรแกรมก็จะยิ่งดีขึ้น

การมีเพศสัมพันธ์มีห้าระดับ ได้แก่ -

  • Content coupling - เมื่อโมดูลสามารถเข้าถึงหรือแก้ไขหรืออ้างถึงเนื้อหาของโมดูลอื่นได้โดยตรงจะเรียกว่าการเชื่อมต่อระดับเนื้อหา
  • Common coupling- เมื่อโมดูลหลายโมดูลมีสิทธิ์อ่านและเขียนข้อมูลส่วนกลางบางส่วนจะเรียกว่าการมีเพศสัมพันธ์ร่วมหรือส่วนกลาง
  • Control coupling- โมดูลสองโมดูลเรียกว่าการควบคุมควบคู่กันหากหนึ่งในนั้นตัดสินใจการทำงานของโมดูลอื่นหรือเปลี่ยนขั้นตอนการดำเนินการ
  • Stamp coupling- เมื่อหลายโมดูลใช้โครงสร้างข้อมูลร่วมกันและทำงานในส่วนต่างๆกันจะเรียกว่าการเชื่อมต่อแบบประทับ
  • Data coupling- การเชื่อมต่อข้อมูลคือการที่โมดูลสองโมดูลโต้ตอบกันโดยการส่งผ่านข้อมูล (เป็นพารามิเตอร์) หากโมดูลส่งผ่านโครงสร้างข้อมูลเป็นพารามิเตอร์โมดูลรับควรใช้ส่วนประกอบทั้งหมด

ตามหลักการแล้วการไม่มีการมีเพศสัมพันธ์ถือเป็นสิ่งที่ดีที่สุด

การตรวจสอบการออกแบบ

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

ขั้นตอนต่อไปซึ่งเป็นการนำซอฟต์แวร์ขึ้นอยู่กับผลลัพธ์ทั้งหมดที่กล่าวมาข้างต้น

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

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

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

การวิเคราะห์และออกแบบซอฟต์แวร์เป็นขั้นตอนกลางซึ่งช่วยให้ข้อกำหนดที่มนุษย์อ่านได้เปลี่ยนเป็นรหัสจริง

ให้เราดูเครื่องมือวิเคราะห์และออกแบบบางส่วนที่นักออกแบบซอฟต์แวร์ใช้:

แผนภาพกระแสข้อมูล

แผนภาพกระแสข้อมูลคือการแสดงภาพกราฟิกของการไหลของข้อมูลในระบบสารสนเทศ สามารถแสดงการไหลของข้อมูลขาเข้ากระแสข้อมูลขาออกและข้อมูลที่จัดเก็บ DFD ไม่ได้กล่าวถึงอะไรเกี่ยวกับวิธีที่ข้อมูลไหลผ่านระบบ

มีความแตกต่างที่ชัดเจนระหว่าง DFD และผังงาน ผังงานแสดงถึงขั้นตอนการควบคุมในโมดูลโปรแกรม DFD แสดงการไหลของข้อมูลในระบบในระดับต่างๆ DFD ไม่มีองค์ประกอบควบคุมหรือสาขาใด ๆ

ประเภทของ DFD

แผนภาพการไหลของข้อมูลเป็นแบบตรรกะหรือทางกายภาพ

  • Logical DFD - DFD ประเภทนี้มุ่งเน้นไปที่กระบวนการของระบบและการไหลของข้อมูลในระบบตัวอย่างเช่นในระบบซอฟต์แวร์การธนาคารข้อมูลจะถูกย้ายระหว่างหน่วยงานต่างๆอย่างไร
  • Physical DFD- DFD ประเภทนี้แสดงให้เห็นว่าการไหลของข้อมูลถูกนำไปใช้จริงในระบบอย่างไร มีความเฉพาะเจาะจงและใกล้เคียงกับการนำไปใช้งานมากขึ้น

ส่วนประกอบ DFD

DFD สามารถแสดงต้นทางปลายทางการจัดเก็บและการไหลของข้อมูลโดยใช้ชุดส่วนประกอบต่อไปนี้ -

  • Entities- เอนทิตีเป็นแหล่งที่มาและปลายทางของข้อมูลสารสนเทศ เอนทิตีแสดงด้วยรูปสี่เหลี่ยมพร้อมชื่อตามลำดับ
  • Process - กิจกรรมและการดำเนินการกับข้อมูลจะแสดงด้วยวงกลมหรือสี่เหลี่ยมขอบมน
  • Data Storage - การจัดเก็บข้อมูลมีสองรูปแบบ - สามารถแสดงเป็นรูปสี่เหลี่ยมผืนผ้าโดยไม่มีทั้งสองด้านที่เล็กกว่าหรือเป็นรูปสี่เหลี่ยมผืนผ้าแบบเปิดที่ขาดเพียงด้านเดียว
  • Data Flow- การเคลื่อนไหวของข้อมูลแสดงด้วยลูกศรชี้ การเคลื่อนไหวของข้อมูลจะแสดงจากฐานของลูกศรเป็นต้นทางไปทางหัวของลูกศรเป็นปลายทาง

ระดับของ DFD

  • Level 0- DFD ระดับนามธรรมสูงสุดเรียกว่าระดับ 0 DFD ซึ่งแสดงให้เห็นระบบข้อมูลทั้งหมดเป็นแผนภาพเดียวที่ปกปิดรายละเอียดพื้นฐานทั้งหมด DFD ระดับ 0 เรียกอีกอย่างว่า DFD ระดับบริบท
  • Level 1- DFD ระดับ 0 แบ่งออกเป็น DFD ระดับ 1 ที่เฉพาะเจาะจงมากขึ้น DFD ระดับ 1 แสดงถึงโมดูลพื้นฐานในระบบและการไหลของข้อมูลระหว่างโมดูลต่างๆ DFD ระดับ 1 ยังกล่าวถึงกระบวนการพื้นฐานและแหล่งที่มาของข้อมูล

  • Level 2 - ในระดับนี้ DFD จะแสดงวิธีการไหลของข้อมูลภายในโมดูลที่กล่าวถึงในระดับ 1

    DFD ระดับที่สูงขึ้นสามารถเปลี่ยนเป็น DFD ระดับล่างที่เฉพาะเจาะจงมากขึ้นพร้อมกับความเข้าใจที่ลึกซึ้งยิ่งขึ้นเว้นแต่จะได้คุณสมบัติในระดับที่ต้องการ

แผนภูมิโครงสร้าง

แผนภูมิโครงสร้างเป็นแผนภูมิที่ได้มาจาก Data Flow Diagram แสดงรายละเอียดของระบบมากกว่า DFD แบ่งระบบทั้งหมดออกเป็นโมดูลที่มีฟังก์ชันต่ำสุดอธิบายฟังก์ชันและฟังก์ชันย่อยของแต่ละโมดูลของระบบให้มีรายละเอียดมากกว่า DFD

แผนภูมิโครงสร้างแสดงถึงโครงสร้างลำดับชั้นของโมดูล ในแต่ละชั้นจะมีการดำเนินการเฉพาะ

นี่คือสัญลักษณ์ที่ใช้ในการสร้างแผนภูมิโครงสร้าง -

  • Module- แสดงถึงกระบวนการหรือรูทีนย่อยหรืองาน โมดูลควบคุมแตกแขนงไปยังโมดูลย่อยมากกว่าหนึ่งโมดูล โมดูลไลบรารีสามารถใช้ซ้ำได้และเรียกใช้จากโมดูลใดก็ได้
  • Condition- แสดงด้วยเพชรเม็ดเล็กที่ฐานของโมดูล แสดงให้เห็นว่าโมดูลควบคุมสามารถเลือกรูทีนย่อยใดก็ได้ตามเงื่อนไขบางประการ
  • Jump - ลูกศรจะแสดงขึ้นชี้ภายในโมดูลเพื่อแสดงให้เห็นว่าตัวควบคุมจะกระโดดไปตรงกลางของโมดูลย่อย
  • Loop- ลูกศรโค้งแสดงถึงการวนซ้ำในโมดูล โมดูลย่อยทั้งหมดที่ครอบคลุมโดยการดำเนินการซ้ำแบบวนซ้ำของโมดูล
  • Data flow - ลูกศรกำกับที่มีวงกลมว่างที่ท้ายหมายถึงการไหลของข้อมูล
  • Control flow - ลูกศรกำกับที่มีวงกลมเต็มที่ท้ายหมายถึงการควบคุม

แผนภาพ HIPO

แผนภาพ HIPO (Hierarchical Input Process Output) เป็นการรวมกันของวิธีการจัดระเบียบสองวิธีเพื่อวิเคราะห์ระบบและจัดเตรียมเอกสาร โมเดล HIPO ได้รับการพัฒนาโดย IBM ในปี 1970

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

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

ตรงกันข้ามกับแผนภาพ IPO (Input Process Output) ซึ่งแสดงถึงการไหลของการควบคุมและข้อมูลในโมดูล HIPO ไม่ได้ให้ข้อมูลใด ๆ เกี่ยวกับกระแสข้อมูลหรือกระแสการควบคุม

ตัวอย่าง

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

ภาษาอังกฤษที่มีโครงสร้าง

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

วิธีการในรูปแบบอื่นซึ่งใช้กราฟหรือแผนภาพบางครั้งอาจตีความแตกต่างกันไป

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

วิธีการในรูปแบบอื่นซึ่งใช้กราฟหรือแผนภาพบางครั้งอาจตีความแตกต่างกันไป ที่นี่ทั้ง Structured English และ Pseudo-Code จะพยายามลดช่องว่างความเข้าใจดังกล่าว

Structured English คือการใช้คำภาษาอังกฤษธรรมดาในกระบวนทัศน์การเขียนโปรแกรมเชิงโครงสร้าง ไม่ใช่รหัสขั้นสูงสุด แต่เป็นคำอธิบายประเภทที่จำเป็นในการเขียนโค้ดและวิธีการเขียนโค้ด ต่อไปนี้เป็นโทเค็นบางส่วนของการเขียนโปรแกรมเชิงโครงสร้าง

IF-THEN-ELSE,  
DO-WHILE-UNTIL

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

ตัวอย่าง

เราใช้ตัวอย่างเดียวกันของการรับรองความถูกต้องของลูกค้าในสภาพแวดล้อมการช็อปปิ้งออนไลน์ ขั้นตอนนี้ในการรับรองความถูกต้องของลูกค้าสามารถเขียนเป็น Structured English เป็น:

Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
   Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
   PRINT error message
   Call procedure NEW_CUSTOMER_REQUEST()
ENDIF

โค้ดที่เขียนด้วย Structured English เหมือนกับภาษาอังกฤษแบบวันต่อวันมากกว่า ไม่สามารถนำไปใช้เป็นรหัสของซอฟต์แวร์ได้โดยตรง ภาษาอังกฤษที่มีโครงสร้างไม่ขึ้นอยู่กับภาษาโปรแกรม

รหัสหลอก

รหัสเทียมถูกเขียนใกล้เคียงกับภาษาโปรแกรมมากขึ้น อาจถือได้ว่าเป็นภาษาโปรแกรมเสริมซึ่งเต็มไปด้วยความคิดเห็นและคำอธิบาย

รหัส Pseudo หลีกเลี่ยงการประกาศตัวแปร แต่ถูกเขียนโดยใช้โครงสร้างของภาษาโปรแกรมจริงเช่น C, Fortran, Pascal เป็นต้น

รหัสเทียมมีรายละเอียดการเขียนโปรแกรมมากกว่าภาษาอังกฤษที่มีโครงสร้าง มีวิธีการดำเนินการเช่นถ้าคอมพิวเตอร์เรียกใช้รหัส

ตัวอย่าง

โปรแกรมพิมพ์ Fibonacci ได้สูงสุด n ตัวเลข

void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
   if a greater than b 
   {
      Increase b by a;
      Print b;
   } 
   else if b greater than a
   {
      increase a by b;
      print a;
   }
}

ตารางการตัดสินใจ

ตารางการตัดสินใจแสดงถึงเงื่อนไขและการดำเนินการตามลำดับที่จะดำเนินการเพื่อแก้ไขปัญหาในรูปแบบตารางที่มีโครงสร้าง

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

การสร้างตารางการตัดสินใจ

ในการสร้างตารางการตัดสินใจนักพัฒนาต้องทำตามขั้นตอนพื้นฐานสี่ขั้นตอน:

  • ระบุเงื่อนไขที่เป็นไปได้ทั้งหมดที่จะแก้ไข
  • กำหนดการดำเนินการสำหรับเงื่อนไขที่ระบุทั้งหมด
  • สร้างกฎสูงสุดที่เป็นไปได้
  • กำหนดการดำเนินการสำหรับแต่ละกฎ

ตารางการตัดสินใจควรได้รับการตรวจสอบโดยผู้ใช้ปลายทางและเมื่อเร็ว ๆ นี้สามารถทำให้ง่ายขึ้นโดยการกำจัดกฎและการกระทำที่ซ้ำกัน

ตัวอย่าง

ให้เรายกตัวอย่างง่ายๆของปัญหาประจำวันเกี่ยวกับการเชื่อมต่ออินเทอร์เน็ตของเรา เราเริ่มต้นด้วยการระบุปัญหาทั้งหมดที่อาจเกิดขึ้นขณะเริ่มอินเทอร์เน็ตและแนวทางแก้ไขที่เป็นไปได้

เราแสดงรายการปัญหาที่เป็นไปได้ทั้งหมดภายใต้เงื่อนไขของคอลัมน์และการดำเนินการในอนาคตภายใต้การดำเนินการของคอลัมน์

เงื่อนไข / การดำเนินการ กฎ
เงื่อนไข แสดงว่าเชื่อมต่อแล้ว น น น น ย ย ย ย
Ping กำลังทำงาน น น ย ย น น ย ย
เปิดเว็บไซต์ ย น ย น ย น ย น
การดำเนินการ ตรวจสอบสายเคเบิลเครือข่าย X
ตรวจสอบเราเตอร์อินเทอร์เน็ต X X X X
รีสตาร์ทเว็บเบราว์เซอร์ X
ติดต่อผู้ให้บริการ X X X X X X
ไม่ต้องดำเนินการใด ๆ
ตาราง: ตารางการตัดสินใจ - การแก้ไขปัญหาอินเทอร์เน็ตภายในองค์กร

แบบจำลองเอนทิตี - ความสัมพันธ์

แบบจำลองเอนทิตี - ความสัมพันธ์เป็นรูปแบบฐานข้อมูลประเภทหนึ่งตามแนวคิดของเอนทิตีในโลกแห่งความเป็นจริงและความสัมพันธ์ระหว่างกัน เราสามารถแมปสถานการณ์จริงบนแบบจำลองฐานข้อมูล ER ER Model สร้างชุดของเอนทิตีที่มีแอตทริบิวต์ชุดของข้อ จำกัด และความสัมพันธ์ระหว่างกัน

ER Model เหมาะที่สุดสำหรับการออกแบบฐานข้อมูลตามแนวคิด ER Model สามารถแสดงได้ดังนี้:

  • Entity - เอนทิตีใน ER Model คือสิ่งมีชีวิตในโลกแห่งความเป็นจริงซึ่งมีคุณสมบัติบางอย่างที่เรียกว่า attributes. ทุกแอตทริบิวต์ถูกกำหนดโดยชุดค่าที่เกี่ยวข้องเรียกว่าdomain.

    ตัวอย่างเช่นพิจารณาฐานข้อมูลโรงเรียน ที่นี่นักเรียนเป็นนิติบุคคล นักเรียนมีคุณสมบัติที่หลากหลายเช่นชื่อรหัสอายุและชั้นเรียนเป็นต้น

  • Relationship - เรียกการเชื่อมโยงทางตรรกะระหว่างเอนทิตี relationship. ความสัมพันธ์ถูกแมปกับเอนทิตีในรูปแบบต่างๆ การแมปคาร์ดินัลลิตีกำหนดจำนวนการเชื่อมโยงระหว่างสองเอนทิตี

    การทำแผนที่คาร์ดินัลลิตี:

    • หนึ่งต่อหนึ่ง
    • หนึ่งต่อหลายคน
    • หลายต่อหนึ่ง
    • หลายต่อหลายคน

พจนานุกรมข้อมูล

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

พจนานุกรมข้อมูลมักอ้างถึงเป็นที่เก็บข้อมูลเมตาดาต้า (ข้อมูลเกี่ยวกับข้อมูล) ถูกสร้างขึ้นพร้อมกับโมเดลซอฟต์แวร์ DFD (Data Flow Diagram) และคาดว่าจะได้รับการอัปเดตเมื่อใดก็ตามที่ DFD มีการเปลี่ยนแปลงหรืออัปเดต

ข้อกำหนดของพจนานุกรมข้อมูล

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

พจนานุกรมข้อมูลมีวิธีการจัดทำเอกสารสำหรับระบบฐานข้อมูลที่สมบูรณ์ในที่เดียว การตรวจสอบความถูกต้องของ DFD ดำเนินการโดยใช้พจนานุกรมข้อมูล

สารบัญ

พจนานุกรมข้อมูลควรมีข้อมูลเกี่ยวกับสิ่งต่อไปนี้

  • กระแสข้อมูล
  • โครงสร้างข้อมูล
  • องค์ประกอบข้อมูล
  • ที่เก็บข้อมูล
  • การประมวลผลข้อมูล

โฟลว์ข้อมูลอธิบายโดยใช้ DFD ตามที่ศึกษาก่อนหน้านี้และแสดงในรูปแบบพีชคณิตตามที่อธิบายไว้

= ประกอบด้วย
{} การทำซ้ำ
() ไม่จำเป็น
+ และ
[/] หรือ

ตัวอย่าง

ที่อยู่ = บ้านเลขที่ + (ถนน / พื้นที่) + เมือง + รัฐ

รหัสหลักสูตร = หมายเลขหลักสูตร + ชื่อหลักสูตร + ระดับหลักสูตร + เกรดหลักสูตร

องค์ประกอบข้อมูล

องค์ประกอบข้อมูลประกอบด้วยชื่อและคำอธิบายของข้อมูลและรายการควบคุมที่เก็บข้อมูลภายในหรือภายนอกเป็นต้นโดยมีรายละเอียดดังต่อไปนี้:

  • ชื่อหลัก
  • ชื่อรอง (นามแฝง)
  • กรณีการใช้งาน (ใช้อย่างไรและที่ไหน)
  • คำอธิบายเนื้อหา (สัญกรณ์ ฯลฯ )
  • ข้อมูลเสริม (ค่าที่ตั้งไว้ล่วงหน้าข้อ จำกัด ฯลฯ )

ที่เก็บข้อมูล

จัดเก็บข้อมูลจากจุดที่ข้อมูลเข้าสู่ระบบและมีอยู่นอกระบบ ที่เก็บข้อมูลอาจรวมถึง -

  • Files
    • ภายในซอฟต์แวร์
    • ภายนอกกับซอฟต์แวร์ แต่อยู่ในเครื่องเดียวกัน
    • ภายนอกกับซอฟต์แวร์และระบบที่อยู่ในเครื่องอื่น
  • Tables
    • หลักการตั้งชื่อ
    • การจัดทำดัชนีคุณสมบัติ

การประมวลผลข้อมูล

การประมวลผลข้อมูลมีสองประเภท:

  • Logical: ตามที่ผู้ใช้เห็น
  • Physical: ตามที่ซอฟต์แวร์เห็น

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

การออกแบบซอฟต์แวร์มีหลายรูปแบบ ให้เราศึกษาสั้น ๆ :

การออกแบบที่มีโครงสร้าง

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

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

ปัญหาเล็ก ๆ น้อย ๆ ได้รับการแก้ไขโดยใช้โมดูลโซลูชัน การออกแบบที่มีโครงสร้างเน้นว่าโมดูลเหล่านี้ได้รับการจัดระเบียบอย่างดีเพื่อให้ได้โซลูชันที่แม่นยำ

โมดูลเหล่านี้จัดเรียงตามลำดับชั้น พวกเขาสื่อสารกัน การออกแบบโครงสร้างที่ดีมักจะปฏิบัติตามกฎบางประการสำหรับการสื่อสารระหว่างโมดูลต่างๆกล่าวคือ -

Cohesion - การจัดกลุ่มองค์ประกอบที่เกี่ยวข้องกับหน้าที่ทั้งหมด

Coupling - การสื่อสารระหว่างโมดูลต่างๆ

การออกแบบที่มีโครงสร้างที่ดีมีการเชื่อมต่อกันสูงและการจัดเตรียมการเชื่อมต่อที่ต่ำ

การออกแบบเชิงฟังก์ชัน

ในการออกแบบที่เน้นฟังก์ชันระบบประกอบด้วยระบบย่อยขนาดเล็กจำนวนมากที่เรียกว่าฟังก์ชัน ฟังก์ชันเหล่านี้สามารถทำงานที่สำคัญในระบบได้ ระบบถือเป็นมุมมองด้านบนของฟังก์ชันทั้งหมด

การออกแบบที่เน้นฟังก์ชันสืบทอดคุณสมบัติบางประการของการออกแบบโครงสร้างโดยใช้วิธีการแบ่งแยกและพิชิต

กลไกการออกแบบนี้แบ่งทั้งระบบออกเป็นฟังก์ชันย่อย ๆ ซึ่งให้วิธีการที่เป็นนามธรรมโดยการปกปิดข้อมูลและการทำงานของมัน .. โมดูลการทำงานเหล่านี้สามารถแบ่งปันข้อมูลระหว่างกันโดยการส่งผ่านข้อมูลและใช้ข้อมูลที่มีอยู่ทั่วโลก

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

กระบวนการออกแบบ

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

การออกแบบเชิงวัตถุ

การออกแบบเชิงวัตถุทำงานรอบ ๆ เอนทิตีและลักษณะเฉพาะแทนที่จะเป็นฟังก์ชันที่เกี่ยวข้องกับระบบซอฟต์แวร์ กลยุทธ์การออกแบบนี้มุ่งเน้นไปที่เอนทิตีและลักษณะของมัน แนวคิดทั้งหมดของโซลูชันซอฟต์แวร์เกี่ยวข้องกับหน่วยงานที่มีส่วนร่วม

ให้เราดูแนวคิดที่สำคัญของ Object Oriented Design:

  • Objects - เอนทิตีทั้งหมดที่เกี่ยวข้องกับการออกแบบโซลูชันเรียกว่าอ็อบเจ็กต์ ตัวอย่างเช่นบุคคลธนาคาร บริษัท และลูกค้าถือเป็นวัตถุ ทุกเอนทิตีมีแอตทริบิวต์บางอย่างที่เกี่ยวข้องและมีวิธีการบางอย่างในการดำเนินการกับแอตทริบิวต์

  • Classes - คลาสคือคำอธิบายทั่วไปของออบเจ็กต์ วัตถุคือตัวอย่างของการเรียน. คลาสกำหนดแอตทริบิวต์ทั้งหมดซึ่งอ็อบเจ็กต์สามารถมีและเมธอดซึ่งกำหนดการทำงานของอ็อบเจ็กต์

    ในการออกแบบโซลูชันแอตทริบิวต์จะถูกจัดเก็บเป็นตัวแปรและฟังก์ชันต่างๆจะถูกกำหนดโดยวิธีการหรือขั้นตอน

  • Encapsulation - ใน OOD แอตทริบิวต์ (ตัวแปรข้อมูล) และวิธีการ (การดำเนินการกับข้อมูล) รวมเข้าด้วยกันเรียกว่าการห่อหุ้ม การห่อหุ้มไม่เพียง แต่รวมข้อมูลสำคัญของวัตถุเข้าด้วยกันเท่านั้น แต่ยัง จำกัด การเข้าถึงข้อมูลและวิธีการจากโลกภายนอกด้วย สิ่งนี้เรียกว่าการซ่อนข้อมูล
  • Inheritance - OOD ช่วยให้คลาสที่คล้ายกันสามารถสแต็กอัพตามลำดับชั้นโดยที่คลาสต่ำกว่าหรือคลาสย่อยสามารถอิมพอร์ตใช้งานและใช้ซ้ำตัวแปรและวิธีการที่อนุญาตจากซุปเปอร์คลาสทันที คุณสมบัติของ OOD นี้เรียกว่ามรดก สิ่งนี้ทำให้ง่ายต่อการกำหนดคลาสเฉพาะและสร้างคลาสทั่วไปจากคลาสเฉพาะ
  • Polymorphism - ภาษา OOD จัดให้มีกลไกที่วิธีการทำงานที่คล้ายกัน แต่แตกต่างกันในอาร์กิวเมนต์สามารถกำหนดชื่อเดียวกันได้ สิ่งนี้เรียกว่า polymorphism ซึ่งทำให้อินเทอร์เฟซเดียวดำเนินงานสำหรับประเภทต่างๆ ขึ้นอยู่กับวิธีการเรียกใช้ฟังก์ชันส่วนต่างๆของโค้ดจะถูกเรียกใช้งาน

กระบวนการออกแบบ

กระบวนการออกแบบซอฟต์แวร์สามารถรับรู้ได้ว่าเป็นชุดของขั้นตอนที่กำหนดไว้อย่างดี แม้ว่าจะแตกต่างกันไปตามแนวทางการออกแบบ (เชิงฟังก์ชันหรือเชิงวัตถุ แต่อาจมีขั้นตอนต่อไปนี้ที่เกี่ยวข้อง:

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

แนวทางการออกแบบซอฟต์แวร์

วิธีการทั่วไปสองวิธีในการออกแบบซอฟต์แวร์มีดังนี้

การออกแบบจากบนลงล่าง

เราทราบดีว่าระบบประกอบด้วยระบบย่อยมากกว่าหนึ่งระบบและประกอบด้วยส่วนประกอบหลายอย่าง นอกจากนี้ระบบย่อยและส่วนประกอบเหล่านี้อาจมีชุดของระบบย่อยและส่วนประกอบและสร้างโครงสร้างลำดับชั้นในระบบ

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

การออกแบบจากบนลงล่างเริ่มต้นด้วยแบบจำลองทั่วไปของระบบและกำหนดส่วนที่เฉพาะเจาะจงมากขึ้น เมื่อส่วนประกอบทั้งหมดประกอบด้วยระบบทั้งระบบ

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

การออกแบบด้านล่าง

รูปแบบการออกแบบจากล่างขึ้นบนเริ่มต้นด้วยส่วนประกอบที่เฉพาะเจาะจงและพื้นฐานที่สุด ดำเนินการกับการแต่งส่วนประกอบในระดับที่สูงขึ้นโดยใช้ส่วนประกอบระดับพื้นฐานหรือต่ำกว่า มันสร้างส่วนประกอบระดับที่สูงขึ้นไปเรื่อย ๆ จนกว่าระบบที่ต้องการจะไม่ถูกพัฒนาเป็นส่วนประกอบเดียว ในแต่ละระดับที่สูงขึ้นปริมาณของนามธรรมจะเพิ่มขึ้น

กลยุทธ์ด้านล่างเหมาะกว่าเมื่อระบบจำเป็นต้องสร้างขึ้นจากระบบที่มีอยู่บางส่วนซึ่งสามารถใช้ไพรมารีพื้นฐานในระบบที่ใหม่กว่าได้

วิธีการทั้งสองวิธีจากบนลงล่างและจากล่างขึ้นบนไม่สามารถใช้งานได้ทีละวิธี แต่จะใช้ทั้งสองอย่างร่วมกัน

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

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

UI อาจเป็นแบบกราฟิกข้อความตามวิดีโอโดยขึ้นอยู่กับการผสมผสานระหว่างฮาร์ดแวร์และซอฟต์แวร์ UI อาจเป็นฮาร์ดแวร์หรือซอฟต์แวร์หรือทั้งสองอย่างผสมกันก็ได้

ซอฟต์แวร์ได้รับความนิยมมากขึ้นหากอินเทอร์เฟซผู้ใช้คือ:

  • Attractive
  • ใช้งานง่าย
  • ตอบสนองในเวลาอันสั้น
  • ชัดเจนเพื่อทำความเข้าใจ
  • สอดคล้องกับหน้าจอเชื่อมต่อทั้งหมด

UI แบ่งออกเป็นสองประเภทอย่างกว้าง ๆ :

  • อินเตอร์เฟซบรรทัดคำสั่ง
  • อินเทอร์เฟซผู้ใช้แบบกราฟิก

อินเทอร์เฟซบรรทัดคำสั่ง (CLI)

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

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

คำสั่งคือการอ้างอิงตามข้อความไปยังชุดคำสั่งซึ่งคาดว่าระบบจะดำเนินการ มีวิธีการเช่นมาโครสคริปต์ที่ทำให้ผู้ใช้ดำเนินการได้ง่าย

CLI ใช้ทรัพยากรคอมพิวเตอร์น้อยกว่าเมื่อเทียบกับ GUI

องค์ประกอบ CLI

อินเทอร์เฟซบรรทัดคำสั่งแบบข้อความสามารถมีองค์ประกอบต่อไปนี้:

  • Command Prompt- เป็นการแจ้งเตือนแบบข้อความซึ่งส่วนใหญ่จะแสดงบริบทที่ผู้ใช้กำลังทำงานอยู่ มันถูกสร้างขึ้นโดยระบบซอฟต์แวร์

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

  • Command- คำสั่งคือคำสั่งปฏิบัติการ อาจมีพารามิเตอร์อย่างน้อยหนึ่งพารามิเตอร์ เอาต์พุตเมื่อดำเนินการคำสั่งจะแสดงแบบอินไลน์บนหน้าจอ เมื่อเอาต์พุตถูกสร้างขึ้นพร้อมท์คำสั่งจะแสดงในบรรทัดถัดไป

อินเทอร์เฟซผู้ใช้แบบกราฟิก

อินเทอร์เฟซผู้ใช้แบบกราฟิกให้วิธีกราฟิกกับผู้ใช้ในการโต้ตอบกับระบบ GUI สามารถใช้ร่วมกันได้ทั้งฮาร์ดแวร์และซอฟต์แวร์ การใช้ GUI ผู้ใช้ตีความซอฟต์แวร์

โดยปกติ GUI จะใช้ทรัพยากรมากกว่า CLI ด้วยเทคโนโลยีที่ก้าวหน้าโปรแกรมเมอร์และนักออกแบบจึงสร้างการออกแบบ GUI ที่ซับซ้อนซึ่งทำงานได้อย่างมีประสิทธิภาพแม่นยำและรวดเร็วยิ่งขึ้น

องค์ประกอบ GUI

GUI จัดเตรียมชุดส่วนประกอบสำหรับโต้ตอบกับซอฟต์แวร์หรือฮาร์ดแวร์

ส่วนประกอบกราฟิกทุกชิ้นมีวิธีการทำงานกับระบบ ระบบ GUI มีองค์ประกอบต่อไปนี้เช่น:

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

  • Tabs - หากแอปพลิเคชันอนุญาตให้เรียกใช้อินสแตนซ์หลาย ๆ อินสแตนซ์แอปพลิเคชันจะปรากฏบนหน้าจอเป็นหน้าต่างแยก Tabbed Document Interfaceขึ้นมาเพื่อเปิดเอกสารหลายชุดในหน้าต่างเดียวกัน อินเทอร์เฟซนี้ยังช่วยในการดูแผงค่ากำหนดในแอปพลิเคชัน เว็บเบราว์เซอร์สมัยใหม่ทั้งหมดใช้คุณสมบัตินี้

  • Menu- เมนูคืออาร์เรย์ของคำสั่งมาตรฐานจัดกลุ่มเข้าด้วยกันและวางไว้ในตำแหน่งที่มองเห็นได้ (โดยปกติจะอยู่บนสุด) ภายในหน้าต่างแอปพลิเคชัน เมนูนี้สามารถตั้งโปรแกรมให้ปรากฏหรือซ่อนเมื่อคลิกเมาส์

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

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

ส่วนประกอบ GUI เฉพาะของแอปพลิเคชัน

GUI ของแอปพลิเคชันประกอบด้วยองค์ประกอบ GUI ที่แสดงรายการอย่างน้อยหนึ่งรายการ:

  • Application Window - หน้าต่างแอปพลิเคชันส่วนใหญ่ใช้โครงสร้างที่จัดทำโดยระบบปฏิบัติการ แต่ส่วนใหญ่ใช้หน้าต่างที่ลูกค้าสร้างขึ้นเองเพื่อบรรจุเนื้อหาของแอปพลิเคชัน

  • Dialogue Box - เป็นหน้าต่างย่อยที่มีข้อความสำหรับผู้ใช้และขอให้ดำเนินการบางอย่าง ตัวอย่างเช่น: แอปพลิเคชันสร้างกล่องโต้ตอบเพื่อรับการยืนยันจากผู้ใช้ในการลบไฟล์

  • Text-Box - จัดเตรียมพื้นที่สำหรับผู้ใช้ในการพิมพ์และป้อนข้อมูลแบบข้อความ

  • Buttons - เลียนแบบปุ่มในชีวิตจริงและใช้ในการส่งอินพุตไปยังซอฟต์แวร์

  • Radio-button- แสดงตัวเลือกที่มีให้เลือก สามารถเลือกได้เพียงหนึ่งรายการจากข้อเสนอทั้งหมด

  • Check-box- ฟังก์ชั่นคล้ายกับ list-box เมื่อเลือกตัวเลือกกล่องจะถูกทำเครื่องหมายว่าเลือกไว้ สามารถเลือกหลายตัวเลือกที่แสดงโดยกล่องกาเครื่องหมาย

  • List-box - แสดงรายการสิ่งของที่มีให้เลือก สามารถเลือกได้มากกว่าหนึ่งรายการ

ส่วนประกอบ GUI ที่น่าประทับใจอื่น ๆ ได้แก่ :

  • Sliders
  • Combo-box
  • Data-grid
  • รายการแบบหล่นลง

กิจกรรมการออกแบบส่วนต่อประสานผู้ใช้

มีกิจกรรมมากมายสำหรับการออกแบบส่วนต่อประสานผู้ใช้ กระบวนการออกแบบและใช้งาน GUI นั้นเหมือนกับ SDLC สามารถใช้โมเดลใดก็ได้สำหรับการใช้งาน GUI ระหว่าง Waterfall, Iterative หรือ Spiral Model

โมเดลที่ใช้สำหรับการออกแบบและพัฒนา GUI ควรเป็นไปตามขั้นตอนเฉพาะของ GUI เหล่านี้

  • GUI Requirement Gathering- นักออกแบบอาจต้องการรายชื่อข้อกำหนดด้านการใช้งานและไม่ใช้งานได้ทั้งหมดของ GUI สิ่งนี้สามารถนำมาจากผู้ใช้และโซลูชันซอฟต์แวร์ที่มีอยู่

  • User Analysis- นักออกแบบศึกษาว่าใครจะใช้ซอฟต์แวร์ GUI กลุ่มเป้าหมายมีความสำคัญเนื่องจากรายละเอียดการออกแบบเปลี่ยนแปลงไปตามระดับความรู้ความสามารถของผู้ใช้ หากผู้ใช้มีความเชี่ยวชาญด้านเทคนิคสามารถรวม GUI ขั้นสูงและซับซ้อนได้ สำหรับผู้ใช้มือใหม่ข้อมูลเพิ่มเติมเกี่ยวกับวิธีใช้ซอฟต์แวร์จะรวมอยู่ด้วย

  • Task Analysis- นักออกแบบต้องวิเคราะห์ว่าซอฟต์แวร์จะต้องทำภารกิจอะไร ที่นี่ใน GUI ไม่สำคัญว่าจะทำอย่างไร งานสามารถแสดงตามลำดับชั้นโดยใช้ภารกิจหลักหนึ่งงานและแบ่งออกเป็นงานย่อยย่อย ๆ งานให้เป้าหมายสำหรับการนำเสนอ GUI การไหลของข้อมูลระหว่างงานย่อยเป็นตัวกำหนดการไหลของเนื้อหา GUI ในซอฟต์แวร์

  • GUI Design & implementation- นักออกแบบหลังจากมีข้อมูลเกี่ยวกับข้อกำหนดงานและสภาพแวดล้อมของผู้ใช้แล้วให้ออกแบบ GUI และนำไปใช้ในโค้ดและฝัง GUI กับซอฟต์แวร์ที่ใช้งานได้หรือจำลองไว้เบื้องหลัง จากนั้นนักพัฒนาจะทดสอบตัวเอง

  • Testing- การทดสอบ GUI สามารถทำได้หลายวิธี องค์กรสามารถมีการตรวจสอบภายในองค์กรการมีส่วนร่วมโดยตรงของผู้ใช้และการเปิดตัวเวอร์ชันเบต้าเป็นเพียงส่วนน้อยเท่านั้น การทดสอบอาจรวมถึงการใช้งานความเข้ากันได้การยอมรับของผู้ใช้เป็นต้น

เครื่องมือติดตั้ง GUI

มีเครื่องมือมากมายที่นักออกแบบสามารถสร้าง GUI ทั้งหมดได้ด้วยการคลิกเมาส์ เครื่องมือบางอย่างสามารถฝังอยู่ในสภาพแวดล้อมซอฟต์แวร์ (IDE)

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

เครื่องมือ GUI มีหลายกลุ่มตามการใช้งานและแพลตฟอร์มที่แตกต่างกัน

ตัวอย่าง

Mobile GUI, Computer GUI, Touch-Screen GUI เป็นต้นนี่คือรายการเครื่องมือบางอย่างที่มีประโยชน์ในการสร้าง GUI:

  • FLUID
  • AppInventor (แอนดรอยด์)
  • LucidChart
  • Wavemaker
  • Visual Studio

กฎทองของอินเทอร์เฟซผู้ใช้

กฎต่อไปนี้กล่าวถึงเป็นกฎทองสำหรับการออกแบบ GUI ที่ Shneiderman และ Plaisant อธิบายไว้ในหนังสือของพวกเขา (การออกแบบส่วนต่อประสานผู้ใช้)

  • Strive for consistency- ควรมีลำดับการกระทำที่สอดคล้องกันในสถานการณ์ที่คล้ายคลึงกัน ควรใช้คำศัพท์ที่เหมือนกันในการแจ้งเมนูและหน้าจอวิธีใช้ ควรใช้คำสั่งที่สอดคล้องกันตลอด

  • Enable frequent users to use short-cuts- ความต้องการของผู้ใช้ในการลดจำนวนการโต้ตอบเพิ่มขึ้นตามความถี่ในการใช้งาน คำย่อปุ่มฟังก์ชันคำสั่งที่ซ่อนอยู่และสิ่งอำนวยความสะดวกมาโครมีประโยชน์มากสำหรับผู้ใช้ที่เชี่ยวชาญ

  • Offer informative feedback- สำหรับทุกการดำเนินการของผู้ปฏิบัติงานควรมีข้อเสนอแนะของระบบ สำหรับการกระทำที่เกิดขึ้นบ่อยและเล็กน้อยการตอบสนองจะต้องมีความสุภาพ แต่สำหรับการกระทำที่ไม่บ่อยและสำคัญการตอบสนองจะต้องมีความสำคัญ

  • Design dialog to yield closure- ควรจัดลำดับการกระทำเป็นกลุ่มโดยมีจุดเริ่มต้นกลางและตอนท้าย ข้อเสนอแนะที่ให้ข้อมูลเมื่อเสร็จสิ้นการดำเนินการกลุ่มหนึ่งทำให้ผู้ปฏิบัติงานพึงพอใจในความสำเร็จความรู้สึกโล่งใจสัญญาณที่จะละทิ้งแผนฉุกเฉินและทางเลือกออกจากใจของพวกเขาและสิ่งนี้บ่งชี้ว่าหนทางข้างหน้ามีความชัดเจนในการเตรียมรับมือต่อไป กลุ่มของการกระทำ

  • Offer simple error handling- ออกแบบระบบให้มากที่สุดเพื่อให้ผู้ใช้ไม่เกิดข้อผิดพลาดร้ายแรง หากเกิดข้อผิดพลาดระบบควรจะตรวจจับได้และเสนอกลไกที่ง่ายและเข้าใจได้สำหรับจัดการข้อผิดพลาด

  • Permit easy reversal of actions- คุณลักษณะนี้ช่วยลดความกังวลเนื่องจากผู้ใช้ทราบว่าข้อผิดพลาดสามารถยกเลิกได้ การย้อนกลับของการกระทำที่ง่ายช่วยกระตุ้นการสำรวจตัวเลือกที่ไม่คุ้นเคย หน่วยของการย้อนกลับอาจเป็นการกระทำเดียวการป้อนข้อมูลหรือกลุ่มการดำเนินการทั้งหมด

  • Support internal locus of control- ผู้ปฏิบัติงานที่มีประสบการณ์ต้องการอย่างยิ่งให้รู้สึกว่าพวกเขาเป็นผู้รับผิดชอบระบบและระบบตอบสนองต่อการกระทำของพวกเขา ออกแบบระบบเพื่อให้ผู้ใช้เป็นผู้ริเริ่มการกระทำแทนที่จะเป็นผู้ตอบสนอง

  • Reduce short-term memory load - ข้อ จำกัด ของการประมวลผลข้อมูลของมนุษย์ในหน่วยความจำระยะสั้นกำหนดให้ต้องเก็บการแสดงผลที่เรียบง่ายการแสดงหลายหน้ารวมเข้าด้วยกันความถี่ในการเคลื่อนที่ของหน้าต่างจะลดลงและจัดสรรเวลาในการฝึกอบรมที่เพียงพอสำหรับรหัสการจำและลำดับของการกระทำ

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

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

มาตรการความซับซ้อนของ Halstead

ในปีพ. ศ. 2520 Mr. Maurice Howard Halstead ได้นำเสนอเมตริกเพื่อวัดความซับซ้อนของซอฟต์แวร์ เมตริกของ Halstead ขึ้นอยู่กับการนำไปใช้งานจริงของโปรแกรมและมาตรการซึ่งคำนวณโดยตรงจากตัวดำเนินการและตัวถูกดำเนินการจากซอร์สโค้ดในลักษณะคงที่ ช่วยให้สามารถประเมินเวลาในการทดสอบคำศัพท์ขนาดความยากข้อผิดพลาดและความพยายามสำหรับซอร์สโค้ด C / C ++ / Java

จากข้อมูลของ Halstead“ โปรแกรมคอมพิวเตอร์คือการนำอัลกอริทึมมาใช้ซึ่งถือว่าเป็นชุดของโทเค็นซึ่งสามารถจำแนกเป็นตัวดำเนินการหรือตัวถูกดำเนินการ” เมตริก Halstead คิดว่าโปรแกรมเป็นลำดับของตัวดำเนินการและตัวถูกดำเนินการที่เกี่ยวข้อง

เขากำหนดตัวบ่งชี้ต่างๆเพื่อตรวจสอบความซับซ้อนของโมดูล

พารามิเตอร์ ความหมาย
n1 จำนวนตัวดำเนินการที่ไม่ซ้ำกัน
\ n2 จำนวนตัวถูกดำเนินการที่ไม่ซ้ำกัน
N1 จำนวนการเกิดทั้งหมดของตัวดำเนินการ
N2 จำนวนการเกิดขึ้นทั้งหมดของตัวถูกดำเนินการ

เมื่อเราเลือกไฟล์ต้นฉบับเพื่อดูรายละเอียดความซับซ้อนในตัวแสดงเมตริกผลลัพธ์ต่อไปนี้จะปรากฏในรายงานเมตริก:

เมตริก ความหมาย การเป็นตัวแทนทางคณิตศาสตร์
n คำศัพท์ n1 + n2
น ขนาด N1 + N2
วี ปริมาณ ความยาว * คำศัพท์ Log2
ง ความยาก (n1 / 2) * (N1 / n2)
จ ความพยายาม ความยาก * ปริมาณ
ข ข้อผิดพลาด ปริมาณ / 3000
ที เวลาทดสอบ เวลา = ความพยายาม / S โดยที่ S = 18 วินาที

มาตรการความซับซ้อนของไซโคลมาติก

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

หากเราเปรียบเทียบสองโปรแกรมที่มีขนาดเท่ากันโปรแกรมที่มีข้อความในการตัดสินใจมากกว่าจะซับซ้อนกว่าเนื่องจากการควบคุมการกระโดดของโปรแกรมบ่อยๆ

McCabe ในปี 1976 เสนอ Cyclomatic Complexity Measure เพื่อหาปริมาณความซับซ้อนของซอฟต์แวร์ที่กำหนด เป็นแบบจำลองการขับเคลื่อนด้วยกราฟที่ขึ้นอยู่กับโครงสร้างการตัดสินใจของโปรแกรมเช่น if-else, do-while, repeat-until, switch-case และ goto

กระบวนการสร้างกราฟควบคุมการไหล:

  • แบ่งโปรแกรมเป็นบล็อกเล็ก ๆ คั่นด้วยโครงสร้างการตัดสินใจ
  • สร้างโหนดที่เป็นตัวแทนของแต่ละโหนดเหล่านี้
  • เชื่อมต่อโหนดดังนี้:

    • หากการควบคุมสามารถแตกแขนงจากบล็อก i ไปยังบล็อก j

      วาดส่วนโค้ง

    • จากโหนดออกไปยังโหนดรายการ

      วาดส่วนโค้ง

ในการคำนวณความซับซ้อนของวงจรของโมดูลโปรแกรมเราใช้สูตร -

V(G) = e – n + 2

Where
e is total number of edges
n is total number of nodes

ความซับซ้อนของวงจรของโมดูลข้างต้นคือ

e = 10
n = 8
Cyclomatic Complexity = 10 - 8 + 2
                      = 4

ตามที่ P. Jorgensen Cyclomatic Complexity ของโมดูลไม่ควรเกิน 10

จุดฟังก์ชัน

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

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

ให้เราดูพารามิเตอร์ของจุดฟังก์ชัน:

อินพุตภายนอก

ทุกอินพุตที่ไม่ซ้ำกันไปยังระบบจากภายนอกถือเป็นอินพุตภายนอก วัดความเป็นเอกลักษณ์ของอินพุตเนื่องจากไม่มีอินพุตสองตัวที่ควรมีรูปแบบเดียวกัน อินพุตเหล่านี้อาจเป็นข้อมูลหรือพารามิเตอร์ควบคุมก็ได้

  • Simple - หากจำนวนอินพุตต่ำและมีผลต่อไฟล์ภายในน้อยลง

  • Complex - หากจำนวนอินพุตสูงและมีผลต่อไฟล์ภายในมากขึ้น

  • Average - ระหว่างง่ายและซับซ้อน

เอาต์พุตภายนอก

ประเภทเอาต์พุตทั้งหมดที่ระบบมีให้จะนับอยู่ในประเภทนี้ เอาต์พุตจะถือว่าไม่ซ้ำกันหากรูปแบบเอาต์พุตและ / หรือการประมวลผลไม่ซ้ำกัน

  • Simple - หากจำนวนเอาต์พุตต่ำ

  • Complex - หากจำนวนเอาต์พุตสูง

  • Average - อยู่ระหว่างง่ายและซับซ้อน

ไฟล์ภายในแบบลอจิคัล

ระบบซอฟต์แวร์ทุกระบบจะเก็บรักษาไฟล์ภายในเพื่อรักษาข้อมูลที่ใช้งานได้และทำงานได้อย่างถูกต้อง ไฟล์เหล่านี้เก็บข้อมูลตรรกะของระบบ ข้อมูลตรรกะนี้อาจมีทั้งข้อมูลการทำงานและข้อมูลควบคุม

  • Simple - หากจำนวนประเภทการบันทึกต่ำ

  • Complex - หากจำนวนประเภทการบันทึกสูง

  • Average - อยู่ระหว่างง่ายและซับซ้อน

ไฟล์อินเทอร์เฟซภายนอก

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

  • Simple - หากจำนวนประเภทบันทึกในไฟล์ที่แชร์มีน้อย

  • Complex - หากจำนวนประเภทบันทึกในไฟล์ที่แชร์มีมาก

  • Average - อยู่ระหว่างง่ายและซับซ้อน

คำถามภายนอก

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

  • Simple - หากแบบสอบถามต้องการการประมวลผลต่ำและให้ข้อมูลผลลัพธ์จำนวนเล็กน้อย

  • Complex - หากแบบสอบถามต้องการกระบวนการที่สูงและให้ข้อมูลผลลัพธ์จำนวนมาก

  • Average - อยู่ระหว่างง่ายและซับซ้อน

พารามิเตอร์เหล่านี้แต่ละตัวในระบบจะได้รับน้ำหนักตามคลาสและความซับซ้อน ตารางด้านล่างกล่าวถึงน้ำหนักที่กำหนดให้กับแต่ละพารามิเตอร์:

พารามิเตอร์ เรียบง่าย เฉลี่ย ซับซ้อน
อินพุต 3 4 6
เอาท์พุต 4 5 7
สอบถาม 3 4 6
ไฟล์ 7 10 15
อินเทอร์เฟซ 5 7 10

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

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

จากนั้นปัจจัยลักษณะเหล่านี้จะถูกจัดอันดับจาก 0 ถึง 5 ดังที่กล่าวไว้ด้านล่าง:

  • ไม่มีอิทธิพล
  • Incidental
  • Moderate
  • Average
  • Significant
  • Essential

จากนั้นการให้คะแนนทั้งหมดจะรวมเป็น N ค่าของ N อยู่ในช่วง 0 ถึง 70 (คุณลักษณะ 14 ประเภท x 5 ประเภทของการให้คะแนน) ใช้ในการคำนวณ Complexity Adjustment Factors (CAF) โดยใช้สูตรต่อไปนี้:

CAF = 0.65 + 0.01N

จากนั้น

Delivered Function Points (FP)= CAF x Raw FP

จากนั้น FP นี้สามารถใช้ในเมตริกต่างๆเช่น:

    Cost = $ / FP

    Quality = ข้อผิดพลาด / FP

    Productivity = FP / คน - เดือน

ในบทนี้เราจะศึกษาเกี่ยวกับวิธีการเขียนโปรแกรมเอกสารและความท้าทายในการใช้งานซอฟต์แวร์

การเขียนโปรแกรมที่มีโครงสร้าง

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

การเขียนโปรแกรมแบบมีโครงสร้างระบุว่าจะต้องเขียนโปรแกรมอย่างไร การเขียนโปรแกรมเชิงโครงสร้างใช้แนวคิดหลักสามประการ:

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

  • Modular Programming- ในขณะที่เขียนโปรแกรมโค้ดจะแบ่งออกเป็นกลุ่มคำสั่งย่อย ๆ กลุ่มเหล่านี้เรียกว่าโมดูลโปรแกรมย่อยหรือรูทีนย่อย การเขียนโปรแกรมแบบโมดูลโดยอาศัยความเข้าใจในการวิเคราะห์จากบนลงล่าง มันไม่สนับสนุนการกระโดดโดยใช้คำสั่ง 'goto' ในโปรแกรมซึ่งมักทำให้โฟลว์ของโปรแกรมไม่สามารถตรวจสอบย้อนกลับได้ ห้ามกระโดดและสนับสนุนให้ใช้รูปแบบโมดูลาร์ในการเขียนโปรแกรมแบบมีโครงสร้าง

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

การเขียนโปรแกรมฟังก์ชั่น

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

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

การเขียนโปรแกรมเชิงฟังก์ชันให้วิธีการคำนวณเป็นฟังก์ชันทางคณิตศาสตร์ซึ่งให้ผลลัพธ์โดยไม่คำนึงถึงสถานะของโปรแกรม สิ่งนี้ทำให้สามารถคาดเดาพฤติกรรมของโปรแกรมได้

การเขียนโปรแกรมเชิงฟังก์ชันใช้แนวคิดต่อไปนี้:

  • First class and High-order functions - ฟังก์ชันเหล่านี้มีความสามารถในการยอมรับฟังก์ชันอื่นเป็นอาร์กิวเมนต์หรือส่งคืนฟังก์ชันอื่นเป็นผลลัพธ์

  • Pure functions - ฟังก์ชั่นเหล่านี้ไม่รวมถึงการอัปเดตที่ทำลายล้างกล่าวคือไม่มีผลต่อ I / O หรือหน่วยความจำใด ๆ และหากไม่ได้ใช้งานก็สามารถลบออกได้อย่างง่ายดายโดยไม่ขัดขวางส่วนที่เหลือของโปรแกรม

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

  • Strict evaluation- เป็นวิธีการประเมินนิพจน์ที่ส่งผ่านไปยังฟังก์ชันเป็นอาร์กิวเมนต์ การเขียนโปรแกรมเชิงฟังก์ชันมีวิธีการประเมินผลสองประเภทคือเข้มงวด (กระตือรือร้น) หรือไม่เข้มงวด (ขี้เกียจ) การประเมินอย่างเข้มงวดจะประเมินนิพจน์ก่อนเรียกใช้ฟังก์ชันเสมอ การประเมินที่ไม่เข้มงวดจะไม่ประเมินการแสดงออกเว้นแต่ว่าจำเป็น

  • λ-calculus- ภาษาโปรแกรมที่ใช้งานได้ส่วนใหญ่ใช้แคลคูลัสเป็นระบบประเภท λนิพจน์ถูกดำเนินการโดยการประเมินเมื่อเกิดขึ้น

Common Lisp, Scala, Haskell, Erlang และ F # เป็นตัวอย่างของภาษาโปรแกรมที่ใช้งานได้

รูปแบบการเขียนโปรแกรม

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

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

แนวทางการเข้ารหัส

รูปแบบการเข้ารหัสจะแตกต่างกันไปตามองค์กรระบบปฏิบัติการและภาษาของการเข้ารหัส

องค์ประกอบการเข้ารหัสต่อไปนี้อาจถูกกำหนดภายใต้แนวทางการเข้ารหัสขององค์กร:

  • Naming conventions - ส่วนนี้กำหนดวิธีการตั้งชื่อฟังก์ชันตัวแปรค่าคงที่และตัวแปรส่วนกลาง

  • Indenting - นี่คือช่องว่างที่เหลือที่จุดเริ่มต้นของบรรทัดโดยปกติจะเว้นวรรค 2-8 หรือแท็บเดียว

  • Whitespace - โดยทั่วไปจะถูกละไว้ที่ส่วนท้ายของบรรทัด

  • Operators- กำหนดกฎของการเขียนตัวดำเนินการทางคณิตศาสตร์การกำหนดและตรรกะ ตัวอย่างเช่นตัวดำเนินการกำหนด '=' ควรมีช่องว่างก่อนและหลังเช่นเดียวกับใน“ x = 2”

  • Control Structures - กฎของการเขียน if-then-else, case-switch, while-until และสำหรับข้อความควบคุมโฟลว์เพียงอย่างเดียวและแบบซ้อนกัน

  • Line length and wrapping- กำหนดจำนวนอักขระที่ควรมีในหนึ่งบรรทัดโดยส่วนใหญ่จะมีความยาว 80 อักขระ การห่อเป็นตัวกำหนดว่าควรพันเส้นอย่างไรหากยาวเกินไป

  • Functions - สิ่งนี้กำหนดวิธีการประกาศและเรียกใช้ฟังก์ชันโดยมีและไม่มีพารามิเตอร์

  • Variables - สิ่งนี้กล่าวถึงวิธีการประกาศและกำหนดตัวแปรของข้อมูลประเภทต่างๆ

  • Comments- นี่เป็นหนึ่งในองค์ประกอบการเข้ารหัสที่สำคัญเนื่องจากความคิดเห็นที่รวมอยู่ในโค้ดจะอธิบายถึงสิ่งที่โค้ดทำจริงและคำอธิบายอื่น ๆ ที่เกี่ยวข้องทั้งหมด ส่วนนี้ยังช่วยสร้างเอกสารวิธีใช้สำหรับนักพัฒนาคนอื่น ๆ

เอกสารซอฟต์แวร์

เอกสารประกอบซอฟต์แวร์เป็นส่วนสำคัญของกระบวนการซอฟต์แวร์ เอกสารที่เป็นลายลักษณ์อักษรเป็นเครื่องมือที่ยอดเยี่ยมและวิธีการจัดเก็บข้อมูลที่จำเป็นในการทราบเกี่ยวกับกระบวนการซอฟต์แวร์ เอกสารซอฟต์แวร์ยังให้ข้อมูลเกี่ยวกับวิธีการใช้ผลิตภัณฑ์

เอกสารที่ได้รับการดูแลอย่างดีควรเกี่ยวข้องกับเอกสารต่อไปนี้:

  • Requirement documentation - เอกสารนี้ใช้เป็นเครื่องมือหลักสำหรับนักออกแบบซอฟต์แวร์นักพัฒนาและทีมทดสอบเพื่อดำเนินงานตามลำดับ เอกสารนี้ประกอบด้วยคำอธิบายเกี่ยวกับการทำงานไม่ใช้งานและพฤติกรรมทั้งหมดของซอฟต์แวร์ที่ต้องการ

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

    เอกสารนี้ใช้เป็นรากฐานสำหรับซอฟต์แวร์ที่จะพัฒนาและส่วนใหญ่ใช้ในขั้นตอนการตรวจสอบและการตรวจสอบความถูกต้อง กรณีทดสอบส่วนใหญ่สร้างขึ้นโดยตรงจากเอกสารข้อกำหนด

  • Software Design documentation - เอกสารเหล่านี้มีข้อมูลที่จำเป็นทั้งหมดซึ่งจำเป็นในการสร้างซอฟต์แวร์ ประกอบด้วย:(a) สถาปัตยกรรมซอฟต์แวร์ระดับสูง (b) รายละเอียดการออกแบบซอฟต์แวร์ (c) แผนภาพกระแสข้อมูล (d) การออกแบบฐานข้อมูล

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

  • Technical documentation- เอกสารเหล่านี้ได้รับการดูแลโดยนักพัฒนาและผู้เขียนโค้ดจริง เอกสารเหล่านี้โดยรวมแสดงถึงข้อมูลเกี่ยวกับรหัส ในขณะที่เขียนโค้ดโปรแกรมเมอร์ยังกล่าวถึงวัตถุประสงค์ของโค้ดว่าใครเป็นคนเขียนโค้ดจะต้องใช้ที่ไหนทำอะไรและทำอย่างไรทรัพยากรอื่น ๆ ที่โค้ดใช้ ฯลฯ

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

    มีเครื่องมืออัตโนมัติมากมายและบางส่วนมาพร้อมกับภาษาโปรแกรมเอง ตัวอย่างเช่น java มาพร้อมกับเครื่องมือ JavaDoc เพื่อสร้างเอกสารทางเทคนิคของโค้ด

  • User documentation- เอกสารนี้แตกต่างจากที่อธิบายข้างต้นทั้งหมด เอกสารก่อนหน้านี้ทั้งหมดได้รับการดูแลเพื่อให้ข้อมูลเกี่ยวกับซอฟต์แวร์และขั้นตอนการพัฒนา แต่เอกสารสำหรับผู้ใช้จะอธิบายว่าผลิตภัณฑ์ซอฟต์แวร์ควรทำงานอย่างไรและควรใช้อย่างไรเพื่อให้ได้ผลลัพธ์ที่ต้องการ

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

ความท้าทายในการติดตั้งซอฟต์แวร์

มีความท้าทายบางอย่างที่ทีมพัฒนาต้องเผชิญในขณะที่ใช้ซอฟต์แวร์ บางส่วนมีการกล่าวถึงด้านล่าง:

  • Code-reuse- อินเทอร์เฟซการเขียนโปรแกรมของภาษาในปัจจุบันมีความซับซ้อนมากและมีฟังก์ชั่นห้องสมุดขนาดใหญ่ อย่างไรก็ตามเพื่อลดต้นทุนของผลิตภัณฑ์ขั้นสุดท้ายผู้บริหารองค์กรต้องการที่จะใช้รหัสซ้ำซึ่งสร้างขึ้นก่อนหน้านี้สำหรับซอฟต์แวร์อื่น ๆ มีปัญหาใหญ่ที่โปรแกรมเมอร์ต้องเผชิญสำหรับการตรวจสอบความเข้ากันได้และการตัดสินใจว่าจะใช้โค้ดซ้ำมากน้อยเพียงใด

  • Version Management- ทุกครั้งที่ออกซอฟต์แวร์ใหม่ให้กับลูกค้านักพัฒนาจะต้องดูแลเวอร์ชันและเอกสารที่เกี่ยวข้องกับการกำหนดค่า เอกสารนี้ต้องมีความแม่นยำสูงและพร้อมใช้งานตรงเวลา

  • Target-Host- โปรแกรมซอฟต์แวร์ที่กำลังพัฒนาในองค์กรจำเป็นต้องได้รับการออกแบบสำหรับเครื่องโฮสต์ที่ลูกค้าสิ้นสุด แต่ในบางครั้งก็ไม่สามารถออกแบบซอฟต์แวร์ที่ทำงานบนเครื่องเป้าหมายได้

การทดสอบซอฟต์แวร์คือการประเมินซอฟต์แวร์กับข้อกำหนดที่รวบรวมจากผู้ใช้และข้อกำหนดของระบบ การทดสอบจะดำเนินการที่ระดับเฟสในวงจรชีวิตการพัฒนาซอฟต์แวร์หรือที่ระดับโมดูลในโค้ดโปรแกรม การทดสอบซอฟต์แวร์ประกอบด้วย Validation and Verification

การตรวจสอบซอฟต์แวร์

การตรวจสอบความถูกต้องเป็นกระบวนการตรวจสอบว่าซอฟต์แวร์ตรงตามความต้องการของผู้ใช้หรือไม่ ดำเนินการในตอนท้ายของ SDLC หากซอฟต์แวร์ตรงกับข้อกำหนดที่สร้างขึ้นจะมีการตรวจสอบความถูกต้อง

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

การตรวจสอบซอฟต์แวร์

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

  • การตรวจสอบรับรองว่าผลิตภัณฑ์ที่พัฒนาเป็นไปตามข้อกำหนดการออกแบบ
  • การยืนยันตอบคำถาม - "เรากำลังพัฒนาผลิตภัณฑ์นี้โดยปฏิบัติตามข้อกำหนดการออกแบบทั้งหมดอย่างมั่นคงหรือไม่"
  • การตรวจสอบจะเน้นที่การออกแบบและข้อกำหนดของระบบ

เป้าหมายของการทดสอบคือ -

  • Errors- นี่เป็นข้อผิดพลาดในการเข้ารหัสที่เกิดขึ้นโดยนักพัฒนา นอกจากนี้ยังมีความแตกต่างในผลลัพธ์ของซอฟต์แวร์และเอาต์พุตที่ต้องการถือเป็นข้อผิดพลาด

  • Fault- เมื่อมีข้อผิดพลาดเกิดข้อผิดพลาด ข้อผิดพลาดหรือที่เรียกว่าข้อผิดพลาดเป็นผลมาจากข้อผิดพลาดที่อาจทำให้ระบบล้มเหลว

  • Failure - ความล้มเหลวกล่าวว่าเป็นความไม่สามารถของระบบในการทำงานที่ต้องการ ความล้มเหลวเกิดขึ้นเมื่อมีข้อบกพร่องในระบบ

คู่มือ Vs การทดสอบอัตโนมัติ

การทดสอบสามารถทำได้ด้วยตนเองหรือใช้เครื่องมือทดสอบอัตโนมัติ:

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

    การทดสอบด้วยตนเองใช้เวลาและทรัพยากรอย่างสิ้นเปลือง ผู้ทดสอบจำเป็นต้องยืนยันว่าใช้กรณีทดสอบที่ถูกต้องหรือไม่ การทดสอบส่วนใหญ่เกี่ยวข้องกับการทดสอบด้วยตนเอง

  • Automatedการทดสอบนี้เป็นขั้นตอนการทดสอบที่ทำโดยใช้เครื่องมือทดสอบอัตโนมัติ ข้อ จำกัด ของการทดสอบด้วยตนเองสามารถเอาชนะได้โดยใช้เครื่องมือทดสอบอัตโนมัติ

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

มีเครื่องมือซอฟต์แวร์และฮาร์ดแวร์ที่ช่วยผู้ทดสอบในการทดสอบโหลดการทดสอบความเครียดการทดสอบการถดถอย

แนวทางการทดสอบ

การทดสอบสามารถทำได้โดยใช้สองวิธี -

  • การทดสอบการทำงาน
  • การทดสอบการใช้งาน

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

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

การทดสอบกล่องดำ

ดำเนินการเพื่อทดสอบการทำงานของโปรแกรม เรียกอีกอย่างว่าการทดสอบ "พฤติกรรม" ผู้ทดสอบในกรณีนี้มีชุดของค่าอินพุตและผลลัพธ์ที่ต้องการตามลำดับ ในการป้อนข้อมูลหากเอาต์พุตตรงกับผลลัพธ์ที่ต้องการโปรแกรมจะได้รับการทดสอบ 'ok' และมีปัญหา

ในวิธีการทดสอบนี้ผู้ทดสอบไม่ทราบการออกแบบและโครงสร้างของโค้ดและวิศวกรทดสอบและผู้ใช้จะทำการทดสอบซอฟต์แวร์นี้

เทคนิคการทดสอบกล่องดำ:

  • Equivalence class- อินพุตแบ่งออกเป็นคลาสที่คล้ายกัน หากองค์ประกอบหนึ่งของคลาสผ่านการทดสอบจะถือว่าคลาสทั้งหมดผ่านการทดสอบ

  • Boundary values- อินพุตแบ่งออกเป็นค่าที่สูงกว่าและต่ำสุด หากค่าเหล่านี้ผ่านการทดสอบจะถือว่าค่าทั้งหมดที่อยู่ระหว่างนั้นอาจผ่านไปด้วย

  • Cause-effect graphing- ในทั้งสองวิธีก่อนหน้านี้จะมีการทดสอบค่าอินพุตครั้งละหนึ่งค่าเท่านั้น สาเหตุ (อินพุต) - เอฟเฟกต์ (เอาท์พุต) เป็นเทคนิคการทดสอบที่การรวมกันของค่าอินพุตจะถูกทดสอบอย่างเป็นระบบ

  • Pair-wise Testing- ลักษณะการทำงานของซอฟต์แวร์ขึ้นอยู่กับพารามิเตอร์หลายตัว ในการทดสอบแบบคู่พารามิเตอร์หลายตัวจะถูกทดสอบแบบคู่กันสำหรับค่าที่แตกต่างกัน

  • State-based testing- ระบบเปลี่ยนสถานะในการจัดเตรียมอินพุต ระบบเหล่านี้ได้รับการทดสอบตามสถานะและอินพุต

การทดสอบกล่องขาว

ดำเนินการเพื่อทดสอบโปรแกรมและการนำไปใช้งานเพื่อปรับปรุงประสิทธิภาพหรือโครงสร้างของโค้ด เรียกอีกอย่างว่าการทดสอบ 'โครงสร้าง'

ในวิธีการทดสอบนี้ผู้ทดสอบจะทราบการออกแบบและโครงสร้างของโค้ด โปรแกรมเมอร์ของจรรยาบรรณดำเนินการทดสอบโค้ดนี้

ด้านล่างนี้เป็นเทคนิคการทดสอบ White-box:

  • Control-flow testing- วัตถุประสงค์ของการทดสอบโฟลว์การควบคุมเพื่อตั้งค่ากรณีทดสอบซึ่งครอบคลุมข้อความและเงื่อนไขสาขาทั้งหมด เงื่อนไขสาขาได้รับการทดสอบว่าเป็นจริงและเท็จเพื่อให้ครอบคลุมข้อความทั้งหมดได้

  • Data-flow testing- เทคนิคการทดสอบนี้เน้นให้ครอบคลุมตัวแปรข้อมูลทั้งหมดที่รวมอยู่ในโปรแกรม จะทดสอบว่าตัวแปรถูกประกาศและกำหนดไว้ที่ใดและมีการใช้หรือเปลี่ยนแปลงตัวแปรที่ใด

ระดับการทดสอบ

การทดสอบตัวเองอาจกำหนดไว้ในระดับต่างๆของ SDLC กระบวนการทดสอบทำงานควบคู่ไปกับการพัฒนาซอฟต์แวร์ ก่อนที่จะก้าวไปสู่ขั้นต่อไปจะมีการทดสอบขั้นตอนการตรวจสอบและตรวจสอบ

ทำการทดสอบแยกกันเพื่อให้แน่ใจว่าไม่มีจุดบกพร่องหรือปัญหาที่ซ่อนอยู่ในซอฟต์แวร์ ซอฟต์แวร์ได้รับการทดสอบในระดับต่างๆ -

การทดสอบหน่วย

ในขณะที่เขียนโปรแกรมโปรแกรมเมอร์จะทำการทดสอบบางอย่างในหน่วยของโปรแกรมนั้นเพื่อให้ทราบว่าไม่มีข้อผิดพลาดหรือไม่ การทดสอบดำเนินการภายใต้วิธีการทดสอบกล่องขาว การทดสอบหน่วยช่วยให้นักพัฒนาตัดสินใจว่าแต่ละหน่วยของโปรแกรมทำงานตามข้อกำหนดและปราศจากข้อผิดพลาด

การทดสอบการผสานรวม

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

การทดสอบระบบ

ซอฟต์แวร์ได้รับการรวบรวมเป็นผลิตภัณฑ์จากนั้นจึงทดสอบโดยรวม สามารถทำได้โดยใช้การทดสอบอย่างน้อยหนึ่งอย่างต่อไปนี้:

  • Functionality testing - ทดสอบการทำงานทั้งหมดของซอฟต์แวร์ตามข้อกำหนด

  • Performance testing- การทดสอบนี้พิสูจน์ให้เห็นว่าซอฟต์แวร์มีประสิทธิภาพเพียงใด เป็นการทดสอบประสิทธิภาพและเวลาเฉลี่ยที่ซอฟต์แวร์ใช้ในการทำงานที่ต้องการ การทดสอบประสิทธิภาพทำได้โดยการทดสอบโหลดและการทดสอบความเครียดโดยที่ซอฟต์แวร์อยู่ภายใต้การใช้งานของผู้ใช้และโหลดข้อมูลสูงภายใต้สภาวะแวดล้อมต่างๆ

  • Security & Portability - การทดสอบเหล่านี้จะทำเมื่อซอฟต์แวร์มีขึ้นเพื่อทำงานบนแพลตฟอร์มต่างๆและเข้าถึงได้โดยบุคคลจำนวนมาก

การทดสอบการยอมรับ

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

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

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

การทดสอบการถดถอย

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

เอกสารการทดสอบ

เอกสารการทดสอบจัดทำขึ้นในแต่ละขั้นตอน -

ก่อนการทดสอบ

การทดสอบเริ่มต้นด้วยการสร้างกรณีทดสอบ เอกสารต่อไปนี้จำเป็นสำหรับการอ้างอิง -

  • SRS document - เอกสารข้อกำหนดการใช้งาน

  • Test Policy document - ข้อมูลนี้จะอธิบายว่าควรทำการทดสอบไปไกลแค่ไหนก่อนที่จะปล่อยผลิตภัณฑ์

  • Test Strategy document - ข้อมูลนี้กล่าวถึงรายละเอียดของทีมทดสอบเมทริกซ์ความรับผิดชอบและสิทธิ / ความรับผิดชอบของผู้จัดการทดสอบและวิศวกรทดสอบ

  • Traceability Matrix document- เป็นเอกสาร SDLC ซึ่งเกี่ยวข้องกับกระบวนการรวบรวมความต้องการ เมื่อข้อกำหนดใหม่มาถึงข้อกำหนดเหล่านี้จะถูกเพิ่มเข้าไปในเมทริกซ์นี้ เมทริกซ์เหล่านี้ช่วยให้ผู้ทดสอบทราบแหล่งที่มาของข้อกำหนด สามารถติดตามไปข้างหน้าและข้างหลังได้

ในขณะที่กำลังทดสอบ

อาจจำเป็นต้องใช้เอกสารต่อไปนี้ขณะเริ่มการทดสอบและกำลังดำเนินการ:

  • Test Case document- เอกสารนี้ประกอบด้วยรายการการทดสอบที่ต้องดำเนินการ ซึ่งรวมถึงแผนการทดสอบหน่วยแผนการทดสอบการบูรณาการแผนการทดสอบระบบและแผนการทดสอบการยอมรับ

  • Test description - เอกสารนี้เป็นคำอธิบายโดยละเอียดของกรณีทดสอบและขั้นตอนการดำเนินการทั้งหมด

  • Test case report - เอกสารนี้ประกอบด้วยรายงานกรณีทดสอบอันเป็นผลมาจากการทดสอบ

  • Test logs - เอกสารนี้ประกอบด้วยบันทึกการทดสอบสำหรับรายงานกรณีทดสอบทุกฉบับ

หลังจากการทดสอบ

เอกสารต่อไปนี้อาจสร้างขึ้นหลังจากการทดสอบ:

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

การทดสอบเทียบกับการควบคุมคุณภาพการประกันคุณภาพและการตรวจสอบ

เราจำเป็นต้องเข้าใจว่าการทดสอบซอฟต์แวร์แตกต่างจากการประกันคุณภาพซอฟต์แวร์การควบคุมคุณภาพซอฟต์แวร์และการตรวจสอบซอฟต์แวร์

  • Software quality assurance- นี่คือวิธีการตรวจสอบกระบวนการพัฒนาซอฟต์แวร์ซึ่งมั่นใจได้ว่ามาตรการทั้งหมดได้รับการดำเนินการตามมาตรฐานขององค์กร การตรวจสอบนี้ทำขึ้นเพื่อให้แน่ใจว่ามีการปฏิบัติตามวิธีการพัฒนาซอฟต์แวร์ที่เหมาะสม

  • Software quality control- เป็นระบบรักษาคุณภาพของผลิตภัณฑ์ซอฟต์แวร์ อาจรวมถึงแง่มุมที่ใช้งานได้และไม่ใช้งานได้ของผลิตภัณฑ์ซอฟต์แวร์ซึ่งช่วยเพิ่มความปรารถนาดีขององค์กร ระบบนี้ทำให้แน่ใจว่าลูกค้าได้รับผลิตภัณฑ์ที่มีคุณภาพตามความต้องการและผลิตภัณฑ์ที่ได้รับการรับรองว่า 'เหมาะสำหรับการใช้งาน'

  • Software audit- เป็นการทบทวนขั้นตอนที่องค์กรใช้ในการพัฒนาซอฟต์แวร์ ทีมผู้ตรวจสอบซึ่งเป็นอิสระจากทีมพัฒนาจะตรวจสอบกระบวนการซอฟต์แวร์ขั้นตอนข้อกำหนดและด้านอื่น ๆ ของ SDLC วัตถุประสงค์ของการตรวจสอบซอฟต์แวร์คือการตรวจสอบซอฟต์แวร์และกระบวนการพัฒนาทั้งที่เป็นไปตามมาตรฐานกฎและข้อบังคับ

การบำรุงรักษาซอฟต์แวร์เป็นส่วนหนึ่งของ SDLC ที่ได้รับการยอมรับอย่างกว้างขวางในปัจจุบัน ย่อมาจากการปรับเปลี่ยนและการอัปเดตทั้งหมดที่ทำหลังจากส่งมอบผลิตภัณฑ์ซอฟต์แวร์ มีสาเหตุหลายประการเหตุใดจึงต้องมีการปรับเปลี่ยนบางส่วนมีการกล่าวถึงสั้น ๆ ด้านล่าง:

  • Market Conditions - นโยบายที่เปลี่ยนแปลงอยู่ตลอดเวลาเช่นการจัดเก็บภาษีและข้อ จำกัด ที่เพิ่งนำมาใช้เช่นวิธีดูแลรักษาการทำบัญชีอาจทำให้ต้องมีการปรับเปลี่ยน

  • Client Requirements - ในช่วงเวลาหนึ่งลูกค้าอาจขอคุณสมบัติหรือฟังก์ชันใหม่ ๆ ในซอฟต์แวร์

  • Host Modifications - หากฮาร์ดแวร์และ / หรือแพลตฟอร์มใด ๆ (เช่นระบบปฏิบัติการ) ของโฮสต์เป้าหมายเปลี่ยนแปลงจำเป็นต้องมีการเปลี่ยนแปลงซอฟต์แวร์เพื่อให้สามารถปรับตัวได้

  • Organization Changes - หากมีการเปลี่ยนแปลงระดับธุรกิจในตอนท้ายของลูกค้าเช่นการลดความแข็งแกร่งขององค์กรการหา บริษัท อื่นการลงทุนในองค์กรในธุรกิจใหม่อาจเกิดความจำเป็นในการแก้ไขซอฟต์แวร์เดิม

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

ในช่วงอายุการใช้งานซอฟต์แวร์ประเภทของการบำรุงรักษาอาจแตกต่างกันไปตามลักษณะของซอฟต์แวร์ อาจเป็นเพียงงานบำรุงรักษาตามปกติเนื่องจากข้อบกพร่องบางอย่างที่พบโดยผู้ใช้บางรายหรืออาจเป็นเหตุการณ์ใหญ่ในตัวเองตามขนาดการบำรุงรักษาหรือลักษณะ ต่อไปนี้เป็นประเภทของการบำรุงรักษาตามลักษณะ:

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

  • Adaptive Maintenance - ซึ่งรวมถึงการปรับเปลี่ยนและการอัปเดตที่ใช้เพื่อให้ผลิตภัณฑ์ซอฟต์แวร์เป็นปัจจุบันและปรับให้เข้ากับโลกของเทคโนโลยีและสภาพแวดล้อมทางธุรกิจที่เปลี่ยนแปลงตลอดเวลา

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

  • Preventive Maintenance- ซึ่งรวมถึงการปรับเปลี่ยนและการอัปเดตเพื่อป้องกันปัญหาในอนาคตของซอฟต์แวร์ มีจุดมุ่งหมายเพื่อแก้ไขปัญหาซึ่งไม่สำคัญในขณะนี้ แต่อาจทำให้เกิดปัญหาร้ายแรงในอนาคต

ค่าใช้จ่ายในการบำรุงรักษา

รายงานชี้ให้เห็นว่าค่าใช้จ่ายในการบำรุงรักษาสูง การศึกษาเกี่ยวกับการประมาณค่าบำรุงรักษาซอฟต์แวร์พบว่าค่าใช้จ่ายในการบำรุงรักษาสูงถึง 67% ของต้นทุนของวงจรกระบวนการซอฟต์แวร์ทั้งหมด

โดยเฉลี่ยแล้วค่าใช้จ่ายในการบำรุงรักษาซอฟต์แวร์มากกว่า 50% ของขั้นตอน SDLC ทั้งหมด มีหลายปัจจัยที่ทำให้ต้นทุนการบำรุงรักษาสูงขึ้นเช่น:

ปัจจัยในโลกแห่งความเป็นจริงที่มีผลต่อต้นทุนการบำรุงรักษา

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

ปัจจัยด้านซอฟต์แวร์ที่มีผลต่อต้นทุนการบำรุงรักษา

  • โครงสร้างของโปรแกรมซอฟต์แวร์
  • ภาษาโปรแกรม
  • การพึ่งพาสภาพแวดล้อมภายนอก
  • ความน่าเชื่อถือและความพร้อมของพนักงาน

กิจกรรมการบำรุงรักษา

IEEE จัดเตรียมกรอบสำหรับกิจกรรมกระบวนการบำรุงรักษาตามลำดับ สามารถใช้ในลักษณะซ้ำและสามารถขยายเพื่อให้สามารถรวมรายการและกระบวนการที่กำหนดเองได้

กิจกรรมเหล่านี้ไปพร้อมกันในแต่ละขั้นตอนต่อไปนี้:

  • Identification & Tracing- เกี่ยวข้องกับกิจกรรมที่เกี่ยวข้องกับการระบุข้อกำหนดของการปรับเปลี่ยนหรือการบำรุงรักษา สร้างขึ้นโดยผู้ใช้หรือระบบเองอาจรายงานผ่านบันทึกหรือข้อความแสดงข้อผิดพลาดที่นี่ประเภทการบำรุงรักษายังถูกจัดประเภทด้วย

  • Analysis- การปรับเปลี่ยนจะได้รับการวิเคราะห์ถึงผลกระทบต่อระบบรวมถึงผลกระทบด้านความปลอดภัยและความปลอดภัย หากผลกระทบที่น่าจะเกิดขึ้นรุนแรงก็ควรมองหาทางเลือกอื่น จากนั้นชุดการปรับเปลี่ยนที่จำเป็นจะปรากฏเป็นข้อกำหนดข้อกำหนด วิเคราะห์ค่าใช้จ่ายในการดัดแปลง / บำรุงรักษาและสรุปการประมาณค่า

  • Design- โมดูลใหม่ซึ่งจำเป็นต้องเปลี่ยนหรือแก้ไขได้รับการออกแบบตามข้อกำหนดข้อกำหนดที่กำหนดไว้ในขั้นตอนก่อนหน้า กรณีทดสอบถูกสร้างขึ้นเพื่อการตรวจสอบและยืนยัน

  • Implementation - โมดูลใหม่ได้รับการเข้ารหัสด้วยความช่วยเหลือของการออกแบบโครงสร้างที่สร้างขึ้นในขั้นตอนการออกแบบโปรแกรมเมอร์ทุกคนคาดว่าจะทำการทดสอบหน่วยควบคู่กันไป

  • System Testing- การทดสอบการรวมจะกระทำระหว่างโมดูลที่สร้างขึ้นใหม่ การทดสอบการรวมจะดำเนินการระหว่างโมดูลใหม่และระบบด้วย ในที่สุดระบบจะได้รับการทดสอบโดยรวมตามขั้นตอนการทดสอบแบบถอยหลัง

  • Acceptance Testing- หลังจากทดสอบระบบภายในแล้วระบบจะทดสอบการยอมรับด้วยความช่วยเหลือของผู้ใช้ หากอยู่ในสถานะนี้ผู้ใช้ร้องเรียนปัญหาบางอย่างที่ได้รับการแก้ไขหรือระบุไว้เพื่อแก้ไขในการทำซ้ำครั้งต่อไป

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

    สิ่งอำนวยความสะดวกในการฝึกอบรมมีให้หากจำเป็นนอกเหนือจากสำเนาคู่มือผู้ใช้

  • Maintenance management- การจัดการการกำหนดค่าเป็นส่วนสำคัญของการบำรุงรักษาระบบ ได้รับความช่วยเหลือเกี่ยวกับเครื่องมือควบคุมเวอร์ชันเพื่อควบคุมเวอร์ชันกึ่งเวอร์ชันหรือการจัดการแพตช์

วิศวกรรมใหม่ของซอฟต์แวร์

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

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

ตัวอย่างเช่นในตอนแรก Unix ได้รับการพัฒนาในภาษาแอสเซมบลี เมื่อมีภาษา C Unix ได้รับการออกแบบใหม่ในภาษา C เนื่องจากการทำงานในภาษาแอสเซมบลีเป็นเรื่องยาก

นอกเหนือจากนี้บางครั้งโปรแกรมเมอร์สังเกตเห็นว่าบางส่วนของซอฟต์แวร์ต้องการการบำรุงรักษามากกว่าส่วนอื่น ๆ และต้องทำการวิศวกรรมซ้ำด้วย

กระบวนการ Re-Engineering

  • Decideจะวิศวกรอะไรใหม่ เป็นซอฟต์แวร์ทั้งหมดหรือบางส่วน?
  • Perform Reverse Engineering เพื่อให้ได้ข้อมูลจำเพาะของซอฟต์แวร์ที่มีอยู่
  • Restructure Programถ้าจำเป็น ตัวอย่างเช่นการเปลี่ยนโปรแกรมเชิงฟังก์ชันเป็นโปรแกรมเชิงวัตถุ
  • Re-structure data ตามความจำเป็น.
  • Apply Forward engineering แนวคิดเพื่อให้ได้ซอฟต์แวร์ที่ออกแบบใหม่

มีคำศัพท์สำคัญบางคำที่ใช้ในการรีเอ็นจิเนียริ่งซอฟต์แวร์

วิศวกรรมย้อนกลับ

เป็นกระบวนการเพื่อให้บรรลุข้อกำหนดของระบบโดยการวิเคราะห์ทำความเข้าใจระบบที่มีอยู่อย่างละเอียดถี่ถ้วน กระบวนการนี้สามารถมองได้ว่าเป็นแบบจำลอง SDLC แบบย้อนกลับกล่าวคือเราพยายามทำให้ระดับนามธรรมสูงขึ้นโดยการวิเคราะห์ระดับนามธรรมที่ต่ำกว่า

ระบบที่มีอยู่ถูกนำไปใช้ก่อนหน้านี้ซึ่งเราไม่รู้อะไรเลย จากนั้นนักออกแบบจะทำวิศวกรรมย้อนกลับโดยดูที่รหัสและพยายามออกแบบ ด้วยการออกแบบในมือพวกเขาพยายามสรุปข้อกำหนด ดังนั้นการย้อนกลับจากรหัสเป็นข้อกำหนดของระบบ

การปรับโครงสร้างโปรแกรม

เป็นกระบวนการในการจัดโครงสร้างใหม่และสร้างซอฟต์แวร์ที่มีอยู่ใหม่ ทั้งหมดนี้เกี่ยวกับการจัดเรียงซอร์สโค้ดใหม่ทั้งในภาษาโปรแกรมเดียวกันหรือจากภาษาโปรแกรมหนึ่งไปยังอีกภาษาหนึ่ง การปรับโครงสร้างสามารถมีได้ทั้งการปรับโครงสร้างซอร์สโค้ดและการปรับโครงสร้างข้อมูลหรือทั้งสองอย่าง

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

ความน่าเชื่อถือของซอฟต์แวร์บนแพลตฟอร์มฮาร์ดแวร์ที่ล้าสมัยสามารถลบออกได้ด้วยการจัดโครงสร้างใหม่

ส่งต่อวิศวกรรม

วิศวกรรมไปข้างหน้าเป็นกระบวนการในการจัดหาซอฟต์แวร์ที่ต้องการจากข้อกำหนดที่มีอยู่ในมือซึ่งนำมาลงโดยวิธีวิศวกรรมย้อนกลับ สันนิษฐานว่าในอดีตมีวิศวกรรมซอฟต์แวร์บางส่วนได้ทำไปแล้ว

วิศวกรรมไปข้างหน้าเหมือนกับกระบวนการวิศวกรรมซอฟต์แวร์ที่มีข้อแตกต่างเพียงประการเดียว - จะดำเนินการหลังการทำวิศวกรรมย้อนกลับเสมอ

การใช้ซ้ำของส่วนประกอบ

ส่วนประกอบเป็นส่วนหนึ่งของโค้ดโปรแกรมซอฟต์แวร์ซึ่งดำเนินการงานอิสระในระบบ อาจเป็นโมดูลขนาดเล็กหรือระบบย่อยก็ได้

ตัวอย่าง

ขั้นตอนการเข้าสู่ระบบที่ใช้บนเว็บถือได้ว่าเป็นส่วนประกอบระบบการพิมพ์ในซอฟต์แวร์ถือได้ว่าเป็นส่วนประกอบของซอฟต์แวร์

ส่วนประกอบมีการทำงานร่วมกันสูงและอัตราการเชื่อมต่อที่ต่ำกว่ากล่าวคือทำงานได้อย่างอิสระและสามารถทำงานได้โดยไม่ต้องขึ้นอยู่กับโมดูลอื่น ๆ

ใน OOP อ็อบเจ็กต์ได้รับการออกแบบเฉพาะสำหรับข้อกังวลของพวกเขาและมีโอกาสน้อยที่จะใช้ในซอฟต์แวร์อื่น ๆ

ในการเขียนโปรแกรมแบบแยกส่วนโมดูลจะถูกเข้ารหัสเพื่อทำงานเฉพาะซึ่งสามารถใช้กับโปรแกรมซอฟต์แวร์อื่น ๆ ได้หลายโปรแกรม

มีแนวดิ่งใหม่ทั้งหมดซึ่งขึ้นอยู่กับการนำส่วนประกอบซอฟต์แวร์กลับมาใช้ใหม่และเรียกว่าวิศวกรรมซอฟต์แวร์คอมโพเนนต์ (CBSE)

การใช้ซ้ำสามารถทำได้ในระดับต่างๆ

  • Application level - เมื่อใช้แอปพลิเคชันทั้งหมดเป็นระบบย่อยของซอฟต์แวร์ใหม่

  • Component level - ที่ใช้ระบบย่อยของแอปพลิเคชัน

  • Modules level - เมื่อมีการใช้โมดูลการทำงานซ้ำ

    ส่วนประกอบซอฟต์แวร์มีอินเทอร์เฟซซึ่งสามารถใช้เพื่อสร้างการสื่อสารระหว่างส่วนประกอบต่างๆ

กระบวนการใช้ซ้ำ

สามารถใช้วิธีการได้สองแบบ: โดยการรักษาข้อกำหนดให้เหมือนกันและปรับส่วนประกอบหรือโดยการรักษาส่วนประกอบให้เหมือนกันและปรับเปลี่ยนข้อกำหนด

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

  • Design- นี่เป็นขั้นตอนกระบวนการ SDLC มาตรฐานซึ่งมีการกำหนดข้อกำหนดในแง่ของคำพูดของซอฟต์แวร์ สถาปัตยกรรมพื้นฐานของระบบโดยรวมและระบบย่อยถูกสร้างขึ้น

  • Specify Components - จากการศึกษาการออกแบบซอฟต์แวร์นักออกแบบจะแยกระบบทั้งหมดออกเป็นส่วนประกอบขนาดเล็กหรือระบบย่อย การออกแบบซอฟต์แวร์ที่สมบูรณ์เพียงชุดเดียวกลายเป็นชุดส่วนประกอบขนาดใหญ่ที่ทำงานร่วมกัน

  • Search Suitable Components - ที่เก็บส่วนประกอบซอฟต์แวร์ถูกอ้างถึงโดยนักออกแบบเพื่อค้นหาส่วนประกอบที่ตรงกันบนพื้นฐานของฟังก์ชันการทำงานและข้อกำหนดซอฟต์แวร์ที่ต้องการ ..

  • Incorporate Components - ส่วนประกอบที่ตรงกันทั้งหมดถูกรวมเข้าด้วยกันเพื่อสร้างเป็นซอฟต์แวร์ที่สมบูรณ์

CASE ย่อมาจาก Cคอมพิวเตอร์ Aided Software Eวิศวกรรม หมายถึงการพัฒนาและบำรุงรักษาโครงการซอฟต์แวร์ด้วยความช่วยเหลือของเครื่องมือซอฟต์แวร์อัตโนมัติต่างๆ

เครื่องมือเคส

เครื่องมือ CASE คือชุดของโปรแกรมแอปพลิเคชันซอฟต์แวร์ซึ่งใช้ในการทำกิจกรรม SDLC โดยอัตโนมัติ ผู้จัดการโครงการซอฟต์แวร์นักวิเคราะห์และวิศวกรใช้เครื่องมือ CASE เพื่อพัฒนาระบบซอฟต์แวร์

มีเครื่องมือ CASE จำนวนมากเพื่อลดความซับซ้อนของขั้นตอนต่างๆของวัฏจักรการพัฒนาซอฟต์แวร์เช่นเครื่องมือวิเคราะห์เครื่องมือออกแบบเครื่องมือการจัดการโครงการเครื่องมือจัดการฐานข้อมูลเครื่องมือจัดทำเอกสาร

การใช้เครื่องมือ CASE ช่วยเร่งการพัฒนาโครงการเพื่อให้ได้ผลลัพธ์ที่ต้องการและช่วยในการค้นพบข้อบกพร่องก่อนที่จะก้าวไปข้างหน้าในขั้นตอนต่อไปในการพัฒนาซอฟต์แวร์

ส่วนประกอบของ CASE Tools

เครื่องมือ CASE สามารถแบ่งออกเป็นส่วนต่างๆได้อย่างกว้าง ๆ ตามการใช้งานในขั้นตอน SDLC เฉพาะ:

  • Central Repository- เครื่องมือ CASE ต้องการที่เก็บส่วนกลางซึ่งสามารถใช้เป็นแหล่งข้อมูลทั่วไปแบบบูรณาการและสอดคล้องกัน ที่เก็บกลางเป็นที่เก็บข้อมูลส่วนกลางซึ่งมีการจัดเก็บข้อมูลจำเพาะของผลิตภัณฑ์เอกสารข้อกำหนดรายงานและแผนผังที่เกี่ยวข้องข้อมูลที่เป็นประโยชน์อื่น ๆ เกี่ยวกับการจัดการ ที่เก็บกลางยังทำหน้าที่เป็นพจนานุกรมข้อมูล

  • Upper Case Tools - เครื่องมือ Upper CASE ใช้ในการวางแผนวิเคราะห์และออกแบบขั้นตอนของ SDLC

  • Lower Case Tools - เครื่องมือ CASE ส่วนล่างใช้ในการใช้งานการทดสอบและการบำรุงรักษา

  • Integrated Case Tools - เครื่องมือ CASE ในตัวมีประโยชน์ในทุกขั้นตอนของ SDLC ตั้งแต่การรวบรวมความต้องการไปจนถึงการทดสอบและการจัดทำเอกสาร

เครื่องมือ CASE สามารถจัดกลุ่มเข้าด้วยกันได้หากมีฟังก์ชันการทำงานกิจกรรมกระบวนการและความสามารถในการรวมเข้ากับเครื่องมืออื่น ๆ ที่คล้ายกัน

ขอบเขตของเครื่องมือเคส

ขอบเขตของเครื่องมือ CASE มีอยู่ทั่วทั้ง SDLC

ประเภทเครื่องมือเคส

ตอนนี้เราสั้น ๆ เกี่ยวกับเครื่องมือ CASE ต่างๆ

เครื่องมือแผนภาพ

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

เครื่องมือการสร้างแบบจำลองกระบวนการ

การสร้างแบบจำลองกระบวนการเป็นวิธีการสร้างแบบจำลองกระบวนการซอฟต์แวร์ซึ่งใช้ในการพัฒนาซอฟต์แวร์ เครื่องมือการสร้างแบบจำลองกระบวนการช่วยให้ผู้จัดการสามารถเลือกรูปแบบกระบวนการหรือปรับเปลี่ยนตามความต้องการของผลิตภัณฑ์ซอฟต์แวร์ ตัวอย่างเช่น EPF Composer

เครื่องมือการจัดการโครงการ

เครื่องมือเหล่านี้ใช้สำหรับการวางแผนโครงการการประมาณต้นทุนและความพยายามการจัดกำหนดการโครงการและการวางแผนทรัพยากร ผู้จัดการต้องปฏิบัติตามการดำเนินโครงการอย่างเคร่งครัดกับทุกขั้นตอนที่กล่าวถึงในการจัดการโครงการซอฟต์แวร์ เครื่องมือการจัดการโครงการช่วยในการจัดเก็บและแบ่งปันข้อมูลโครงการแบบเรียลไทม์ทั่วทั้งองค์กร ตัวอย่างเช่น Creative Pro Office, Trac Project, Basecamp

เครื่องมือจัดทำเอกสาร

เอกสารในโครงการซอฟต์แวร์เริ่มต้นก่อนกระบวนการซอฟต์แวร์ดำเนินไปตลอดทุกขั้นตอนของ SDLC และหลังจากเสร็จสิ้นโครงการ

เครื่องมือจัดทำเอกสารสร้างเอกสารสำหรับผู้ใช้ทางเทคนิคและผู้ใช้ปลายทาง ผู้ใช้ทางเทคนิคส่วนใหญ่เป็นผู้เชี่ยวชาญภายในของทีมพัฒนาซึ่งอ้างถึงคู่มือระบบคู่มืออ้างอิงคู่มือการฝึกอบรมคู่มือการติดตั้งเป็นต้นเอกสารสำหรับผู้ใช้จะอธิบายถึงการทำงานและวิธีการใช้งานของระบบเช่นคู่มือการใช้งาน ตัวอย่างเช่น Doxygen, DrExplain, Adobe RoboHelp สำหรับเอกสารประกอบ

เครื่องมือวิเคราะห์

เครื่องมือเหล่านี้ช่วยในการรวบรวมข้อกำหนดตรวจสอบความไม่สอดคล้องความไม่ถูกต้องโดยอัตโนมัติในแผนภาพความซ้ำซ้อนของข้อมูลหรือการละเว้นที่ผิดพลาด ตัวอย่างเช่น Accept 360, Accompa, CaseComplete สำหรับการวิเคราะห์ความต้องการ, Visible Analyst สำหรับการวิเคราะห์ทั้งหมด

เครื่องมือออกแบบ

เครื่องมือเหล่านี้ช่วยนักออกแบบซอฟต์แวร์ในการออกแบบโครงสร้างบล็อกของซอฟต์แวร์ซึ่งอาจแบ่งย่อยออกเป็นโมดูลขนาดเล็กโดยใช้เทคนิคการปรับแต่ง เครื่องมือเหล่านี้ให้รายละเอียดของแต่ละโมดูลและการเชื่อมต่อระหว่างโมดูล ตัวอย่างเช่น Animated Software Design

เครื่องมือจัดการการกำหนดค่า

อินสแตนซ์ของซอฟต์แวร์ถูกเผยแพร่ภายใต้เวอร์ชันเดียว เครื่องมือจัดการการกำหนดค่าจัดการกับ -

  • การจัดการเวอร์ชันและการแก้ไข
  • การจัดการการกำหนดค่าพื้นฐาน
  • เปลี่ยนการจัดการการควบคุม

เครื่องมือ CASE ช่วยในเรื่องนี้โดยการติดตามอัตโนมัติการจัดการเวอร์ชันและการจัดการรุ่น ตัวอย่างเช่น Fossil, Git, Accu REV

เปลี่ยนเครื่องมือควบคุม

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

เครื่องมือการเขียนโปรแกรม

เครื่องมือเหล่านี้ประกอบด้วยสภาพแวดล้อมการเขียนโปรแกรมเช่น IDE (Integrated Development Environment) ไลบรารีโมดูลในตัวและเครื่องมือจำลอง เครื่องมือเหล่านี้ให้ความช่วยเหลือที่ครอบคลุมในการสร้างผลิตภัณฑ์ซอฟต์แวร์และรวมถึงคุณสมบัติสำหรับการจำลองและการทดสอบ ตัวอย่างเช่น Cscope เพื่อค้นหาโค้ดใน C, Eclipse

เครื่องมือสร้างต้นแบบ

ต้นแบบซอฟต์แวร์เป็นเวอร์ชันจำลองของผลิตภัณฑ์ซอฟต์แวร์ที่ต้องการ Prototype ให้รูปลักษณ์เริ่มต้นของผลิตภัณฑ์และจำลองลักษณะของผลิตภัณฑ์จริงเพียงเล็กน้อย

การสร้างต้นแบบเครื่องมือ CASE มาพร้อมกับไลบรารีกราฟิกเป็นหลัก พวกเขาสามารถสร้างส่วนต่อประสานผู้ใช้และการออกแบบที่เป็นอิสระจากฮาร์ดแวร์ เครื่องมือเหล่านี้ช่วยให้เราสร้างต้นแบบอย่างรวดเร็วจากข้อมูลที่มีอยู่ นอกจากนี้ยังมีการจำลองซอฟต์แวร์ต้นแบบ ตัวอย่างเช่นนักแต่งเพลงต้นแบบของ Serena, Mockup Builder

เครื่องมือพัฒนาเว็บ

เครื่องมือเหล่านี้ช่วยในการออกแบบหน้าเว็บที่มีองค์ประกอบที่เกี่ยวข้องทั้งหมดเช่นแบบฟอร์มข้อความสคริปต์กราฟิกและอื่น ๆ เครื่องมือบนเว็บยังแสดงตัวอย่างแบบสดของสิ่งที่กำลังพัฒนาและจะดูแลอย่างไรหลังจากเสร็จสิ้น ตัวอย่างเช่น Fontello, Adobe Edge Inspect, Foundation 3, Brackets

เครื่องมือประกันคุณภาพ

การประกันคุณภาพในองค์กรซอฟต์แวร์กำลังตรวจสอบกระบวนการและวิธีการทางวิศวกรรมที่นำมาใช้ในการพัฒนาผลิตภัณฑ์ซอฟต์แวร์เพื่อให้มั่นใจว่ามีคุณภาพตามมาตรฐานขององค์กร เครื่องมือ QA ประกอบด้วยเครื่องมือควบคุมการกำหนดค่าและการเปลี่ยนแปลงและเครื่องมือทดสอบซอฟต์แวร์ ตัวอย่างเช่น SoapTest, AppsWatch, JMeter

เครื่องมือบำรุงรักษา

การบำรุงรักษาซอฟต์แวร์รวมถึงการปรับเปลี่ยนในผลิตภัณฑ์ซอฟต์แวร์หลังจากส่งมอบแล้ว เทคนิคการบันทึกอัตโนมัติและการรายงานข้อผิดพลาดการสร้างตั๋วข้อผิดพลาดอัตโนมัติและการวิเคราะห์สาเหตุที่แท้จริงเป็นเครื่องมือ CASE เพียงไม่กี่อย่างซึ่งช่วยองค์กรซอฟต์แวร์ในขั้นตอนการบำรุงรักษา SDLC ตัวอย่างเช่น Bugzilla สำหรับการติดตามข้อบกพร่อง HP Quality Center

ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved