ซอฟแวร์การพัฒนาเป็นกระบวนการของการตั้งครรภ์การระบุการออกแบบการเขียนโปรแกรม ,การจัดเก็บเอกสาร ,การทดสอบและข้อผิดพลาดเครื่องประกอบเกี่ยวข้องในการสร้างและการบำรุงรักษาการใช้งาน ,กรอบ , หรือส่วนประกอบซอฟต์แวร์อื่น ๆ การพัฒนาซอฟต์แวร์เป็นกระบวนการของการเขียนและการรักษารหัสที่มาแต่ในความหมายกว้างมันรวมถึงทุกสิ่งที่มีส่วนเกี่ยวข้องระหว่างความคิดของซอฟแวร์ที่ต้องการผ่านไปสำแดงสุดท้ายของซอฟแวร์ที่บางครั้งในการวางแผนและโครงสร้างกระบวนการ [1]ดังนั้นการพัฒนาซอฟต์แวร์อาจรวมถึงการวิจัยการพัฒนาใหม่การสร้างต้นแบบการดัดแปลงการนำกลับมาใช้ใหม่การวิศวกรรมซ้ำการบำรุงรักษาหรือกิจกรรมอื่นใดที่ส่งผลให้เกิดผลิตภัณฑ์ซอฟต์แวร์ [2] ซอฟต์แวร์สามารถพัฒนาเพื่อวัตถุประสงค์ที่หลากหลายโดยทั่วไปสามประการคือเพื่อตอบสนองความต้องการเฉพาะของลูกค้า / ธุรกิจเฉพาะ (กรณีที่มีซอฟต์แวร์ที่กำหนดเอง ) เพื่อตอบสนองความต้องการที่รับรู้ของผู้ใช้ที่มีศักยภาพบางกลุ่ม(กรณีที่มีการค้าและซอฟต์แวร์โอเพนซอร์ส ) หรือเพื่อการใช้งานส่วนตัว (เช่นนักวิทยาศาสตร์อาจเขียนซอฟต์แวร์เพื่อทำงานทางโลกโดยอัตโนมัติ) การพัฒนาซอฟต์แวร์แบบฝังกล่าวคือการพัฒนาซอฟต์แวร์ฝังตัวเช่นใช้สำหรับควบคุมผลิตภัณฑ์สำหรับผู้บริโภคจำเป็นต้องใช้กระบวนการพัฒนาที่รวมเข้ากับการพัฒนาผลิตภัณฑ์ทางกายภาพที่ควบคุมได้ ซอฟต์แวร์ระบบรองรับแอพพลิเคชั่นและกระบวนการเขียนโปรแกรมเองและมักจะพัฒนาแยกกัน ความจำเป็นในการควบคุมคุณภาพที่ดีขึ้นของกระบวนการพัฒนาซอฟต์แวร์ทำให้เกิดระเบียบวินัยของวิศวกรรมซอฟต์แวร์ซึ่งมีจุดมุ่งหมายเพื่อใช้วิธีการที่เป็นระบบซึ่งเป็นตัวอย่างในกระบวนทัศน์ทางวิศวกรรม กับกระบวนการพัฒนาซอฟต์แวร์ มีหลายวิธีในการจัดการโครงการซอฟต์แวร์ซึ่งเรียกว่าแบบจำลองวงจรชีวิตการพัฒนาซอฟต์แวร์วิธีการกระบวนการหรือแบบจำลอง น้ำตกจำลองเป็นรุ่นดั้งเดิมเทียบกับนวัตกรรมล่าสุดมากขึ้นของการพัฒนาซอฟต์แวร์เปรียว

กระบวนการพัฒนาซอฟต์แวร์ (ยังเป็นที่รู้จักกันว่าเป็นวิธีการพัฒนาซอฟแวร์รุ่นหรือวงจรชีวิต) เป็นกรอบที่ถูกนำมาใช้กับโครงสร้าง , แผนและควบคุมกระบวนการของการพัฒนาระบบสารสนเทศ กรอบการทำงานที่หลากหลายมีการพัฒนาในช่วงหลายปีที่ผ่านมาแต่ละกรอบมีจุดแข็งและจุดอ่อนที่เป็นที่ยอมรับของตนเอง มีหลายวิธีในการพัฒนาซอฟต์แวร์: บางวิธีใช้วิธีการที่มีโครงสร้างและอิงตามวิศวกรรมในการพัฒนาซอฟต์แวร์มากกว่าในขณะที่คนอื่น ๆ อาจใช้วิธีการที่เพิ่มมากขึ้นซึ่งซอฟต์แวร์จะพัฒนาไปตามการพัฒนาทีละชิ้น วิธีการพัฒนาระบบเดียวไม่จำเป็นต้องเหมาะกับทุกโครงการ วิธีการที่มีอยู่แต่ละวิธีเหมาะสมที่สุดกับโครงการเฉพาะประเภทโดยพิจารณาจากการพิจารณาด้านเทคนิคองค์กรโครงการและทีมต่างๆ [3] ขั้นตอนเหล่านี้มักเรียกรวมกันว่าวงจรชีวิตของการพัฒนาซอฟต์แวร์หรือ SDLC แนวทางที่แตกต่างกันในการพัฒนาซอฟต์แวร์อาจดำเนินการตามขั้นตอนเหล่านี้ตามลำดับที่ต่างกันหรืออุทิศเวลามากหรือน้อยในขั้นตอนต่างๆ ระดับรายละเอียดของเอกสารประกอบที่จัดทำขึ้นในแต่ละขั้นตอนของการพัฒนาซอฟต์แวร์อาจแตกต่างกันไป ขั้นตอนเหล่านี้อาจดำเนินการในทางกลับกัน (วิธีการตาม "น้ำตก") หรืออาจทำซ้ำในรอบต่างๆหรือการวนซ้ำ (วิธีที่ "สุดโต่ง" มากขึ้น) แนวทางที่รุนแรงกว่ามักจะใช้เวลาในการวางแผนและเอกสารน้อยลงและใช้เวลาในการเขียนโค้ดและพัฒนาแบบทดสอบอัตโนมัติมากขึ้น วิธีการที่ "สุดโต่ง" มากขึ้นยังส่งเสริมการทดสอบอย่างต่อเนื่องตลอดวงจรชีวิตของการพัฒนาเช่นเดียวกับการมีผลิตภัณฑ์ที่ใช้งานได้ (หรือปราศจากข้อบกพร่อง) ตลอดเวลา แนวทางที่มีโครงสร้างหรือ“ น้ำตก ” มากขึ้นพยายามที่จะประเมินความเสี่ยงส่วนใหญ่และพัฒนาแผนโดยละเอียดสำหรับซอฟต์แวร์ก่อนที่จะเริ่มการใช้งาน (การเข้ารหัส) และหลีกเลี่ยงการเปลี่ยนแปลงการออกแบบที่สำคัญและการเข้ารหัสซ้ำในขั้นตอนต่อ ๆ ไปของการวางแผนวงจรชีวิตของการพัฒนาซอฟต์แวร์ . มีข้อดีและข้อเสียที่สำคัญสำหรับวิธีการต่างๆและแนวทางที่ดีที่สุดในการแก้ปัญหาโดยใช้ซอฟต์แวร์มักจะขึ้นอยู่กับประเภทของปัญหา หากเข้าใจปัญหาเป็นอย่างดีและสามารถวางแผนการทำงานล่วงหน้าได้อย่างมีประสิทธิภาพยิ่งวิธีการตาม "น้ำตก" มากขึ้นอาจได้ผลดีที่สุด ในทางกลับกันหากปัญหานั้นไม่เหมือนใคร (อย่างน้อยก็สำหรับทีมพัฒนา) และโครงสร้างของซอฟต์แวร์นั้นไม่สามารถจินตนาการได้อย่างง่ายดายดังนั้นแนวทางที่เพิ่มขึ้นอย่าง "สุดโต่ง" อาจได้ผลดีที่สุด

แหล่งที่มาของแนวคิดสำหรับผลิตภัณฑ์ซอฟต์แวร์มีมากมาย แนวคิดเหล่านี้อาจมาจากการวิจัยตลาดซึ่งรวมถึงข้อมูลประชากรของผู้มีโอกาสเป็นลูกค้าใหม่ลูกค้าปัจจุบันกลุ่มเป้าหมายการขายที่ปฏิเสธผลิตภัณฑ์พนักงานพัฒนาซอฟต์แวร์ภายในคนอื่น ๆ หรือบุคคลที่สามที่สร้างสรรค์ แนวคิดสำหรับผลิตภัณฑ์ซอฟต์แวร์มักจะได้รับการประเมินก่อนโดยบุคลากรทางการตลาดสำหรับความเป็นไปได้ทางเศรษฐกิจเพื่อให้เหมาะสมกับการกระจายช่องทางที่มีอยู่เพื่อผลกระทบที่เป็นไปได้ต่อสายผลิตภัณฑ์ที่มีอยู่คุณสมบัติที่ต้องการและเพื่อให้เหมาะสมกับวัตถุประสงค์ทางการตลาดของ บริษัท ในขั้นตอนการประเมินทางการตลาดจะมีการประเมินสมมติฐานด้านต้นทุนและเวลา ในช่วงแรกจะมีการตัดสินใจว่าจากข้อมูลรายละเอียดเพิ่มเติมที่สร้างโดยเจ้าหน้าที่การตลาดและการพัฒนาหรือไม่ควรติดตามโครงการต่อไป [4] ในหนังสือ"Great ซอฟแวร์การอภิปราย" , อลันเมตรเดวิสระบุในบท"ข้อกำหนด"ย่อยบท"ชิ้นส่วนที่หายของการพัฒนาซอฟต์แวร์" นักศึกษาวิศวกรรมศาสตร์เรียนวิศวกรรมและไม่ค่อยมีความรู้ด้านการเงินหรือการตลาด นักศึกษาสาขาการตลาดเรียนรู้การตลาดและไม่ค่อยมีความรู้ด้านการเงินหรือวิศวกรรม พวกเราส่วนใหญ่กลายเป็นผู้เชี่ยวชาญในด้านเดียว เพื่อให้เรื่องซับซ้อนมีไม่กี่คนที่ต้องพบปะผู้คนแบบสหวิทยาการในทีมงานดังนั้นจึงมีบทบาทน้อยที่จะเลียนแบบ อย่างไรก็ตามการวางแผนผลิตภัณฑ์ซอฟต์แวร์มีความสำคัญอย่างยิ่งต่อความสำเร็จในการพัฒนาและจำเป็นต้องมีความรู้ในหลายสาขาวิชา [5] เพราะการพัฒนาซอฟต์แวร์ที่อาจเกี่ยวข้องกับการสูญเสียหรือจะเกินกว่าสิ่งที่เป็นสิ่งจำเป็นโดยลูกค้าโครงการพัฒนาซอฟแวร์อาจหลงทางเข้าไปกังวลทางด้านเทคนิคน้อยเช่นทรัพยากรมนุษย์ , การบริหารความเสี่ยง , ทรัพย์สินทางปัญญา , การจัดทำงบประมาณ , การจัดการวิกฤตฯลฯ กระบวนการเหล่านี้อาจก่อให้เกิด บทบาทของการพัฒนาธุรกิจที่ทับซ้อนกับการพัฒนาซอฟต์แวร์ การวางแผนเป็นวัตถุประสงค์ของแต่ละกิจกรรมที่เราต้องการค้นพบสิ่งต่างๆที่เป็นของโครงการ เป็นงานที่สำคัญในการสร้างโปรแกรมซอฟแวร์ที่มีการสกัดความต้องการหรือการวิเคราะห์ความต้องการ [6]ลูกค้ามักมีความคิดเชิงนามธรรมว่าต้องการอะไรเป็นผลลัพธ์สุดท้าย แต่ไม่รู้ว่าซอฟต์แวร์ควรทำอย่างไร วิศวกรซอฟต์แวร์ที่มีทักษะและประสบการณ์จะรับรู้ถึงความต้องการที่ไม่สมบูรณ์คลุมเครือหรือแม้กระทั่งที่ขัดแย้งกัน ณ จุดนี้ การแสดงโค้ดสดบ่อยๆอาจช่วยลดความเสี่ยงที่ข้อกำหนดไม่ถูกต้อง "แม้ว่าจะมีการใช้ความพยายามอย่างมากในขั้นตอนข้อกำหนดเพื่อให้แน่ใจว่าความต้องการนั้นสมบูรณ์และสอดคล้องกัน แต่ก็ไม่ค่อยเป็นเช่นนั้นการปล่อยให้ขั้นตอนการออกแบบซอฟต์แวร์เป็นขั้นตอนที่มีอิทธิพลมากที่สุดในการลดผลกระทบของข้อกำหนดใหม่หรือที่เปลี่ยนแปลงไปความผันผวนของข้อกำหนด เป็นสิ่งที่ท้าทายเพราะส่งผลต่ออนาคตหรือกำลังดำเนินการพัฒนาอยู่” [7] เมื่อรวบรวมข้อกำหนดทั่วไปจากลูกค้าแล้วการวิเคราะห์ขอบเขตของการพัฒนาควรได้รับการกำหนดและระบุไว้อย่างชัดเจน สิ่งนี้มักเรียกว่าเอกสารขอบเขต เมื่อความต้องการมีการจัดตั้งการออกแบบซอฟแวร์ที่สามารถจัดตั้งในเอกสารการออกแบบซอฟแวร์ สิ่งนี้เกี่ยวข้องกับการออกแบบเบื้องต้นหรือระดับสูงของโมดูลหลักโดยมีภาพรวม (เช่นแผนภาพบล็อก ) ว่าชิ้นส่วนประกอบเข้าด้วยกันอย่างไร ในขณะนี้ควรทราบภาษาระบบปฏิบัติการและส่วนประกอบฮาร์ดแวร์ทั้งหมด จากนั้นจึงมีการสร้างการออกแบบที่มีรายละเอียดหรือระดับต่ำโดยอาจใช้การสร้างต้นแบบเพื่อพิสูจน์แนวคิดหรือเพื่อกำหนดความต้องการ การดำเนินการเป็นส่วนหนึ่งของกระบวนการที่วิศวกรซอฟต์แวร์จริงโปรแกรมรหัสสำหรับโครงการ การทดสอบซอฟต์แวร์เป็นขั้นตอนที่สำคัญและสำคัญของกระบวนการพัฒนาซอฟต์แวร์ ส่วนนี้ของกระบวนการนี้ช่วยให้มั่นใจได้ว่าข้อบกพร่องได้รับการยอมรับโดยเร็วที่สุด ในบางกระบวนการโดยทั่วไปเรียกว่าการพัฒนาที่ขับเคลื่อนด้วยการทดสอบการทดสอบอาจได้รับการพัฒนาก่อนการใช้งานและใช้เป็นแนวทางสำหรับความถูกต้องของการนำไปใช้งาน การจัดทำเอกสารการออกแบบภายในของซอฟต์แวร์เพื่อวัตถุประสงค์ในการบำรุงรักษาและการปรับปรุงในอนาคตจะดำเนินการตลอดการพัฒนา นอกจากนี้ยังอาจรวมถึงการเขียนAPIไม่ว่าจะเป็นภายนอกหรือภายใน กระบวนการทางวิศวกรรมซอฟต์แวร์ที่ทีมพัฒนาเลือกจะเป็นตัวกำหนดว่าจำเป็นต้องใช้เอกสารภายใน (ถ้ามี) มากน้อยเพียงใด โมเดลที่ขับเคลื่อนด้วยแผน (เช่นWaterfall ) โดยทั่วไปจะจัดทำเอกสารมากกว่ารุ่นAgile การปรับใช้จะเริ่มต้นโดยตรงหลังจากที่โค้ดได้รับการทดสอบอย่างเหมาะสมได้รับการอนุมัติสำหรับการวางจำหน่ายและจำหน่ายหรือแจกจ่ายในสภาพแวดล้อมการผลิต ซึ่งอาจเกี่ยวข้องกับการติดตั้งการปรับแต่ง (เช่นการตั้งค่าพารามิเตอร์ตามค่าของลูกค้า) การทดสอบและอาจมีการขยายระยะเวลาการประเมินผล [ ] การบำรุงรักษาและปรับปรุงซอฟต์แวร์เพื่อรับมือกับข้อบกพร่องหรือข้อกำหนดที่เพิ่งค้นพบอาจใช้เวลาและความพยายามอย่างมากเนื่องจากข้อกำหนดที่ไม่ได้รับอาจบังคับให้ออกแบบซอฟต์แวร์ใหม่ [ ] ในกรณีส่วนใหญ่จำเป็นต้องมีการบำรุงรักษาเป็นประจำเพื่อแก้ไขปัญหาที่ได้รับรายงานและทำให้ซอฟต์แวร์ทำงานต่อไป

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

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

• รูปแบบข้อมูลให้รายละเอียดของข้อมูลที่จะถูกจัดเก็บและเป็นของใช้หลักเมื่อผลิตภัณฑ์สุดท้ายคือรุ่นของคอมพิวเตอร์รหัสซอฟต์แวร์สำหรับโปรแกรมหรือการจัดทำข้อกำหนดการทำงานที่จะช่วยให้ซอฟแวร์คอมพิวเตอร์ตัดสินใจทำให้หรือซื้อ ดูรูปทางด้านขวาสำหรับตัวอย่างการโต้ตอบระหว่างกระบวนการทางธุรกิจและโมเดลข้อมูล [9] โดยปกติรูปแบบที่ถูกสร้างขึ้นหลังจากการดำเนินการให้สัมภาษณ์เรียกว่าการวิเคราะห์ธุรกิจ การสัมภาษณ์ประกอบด้วยวิทยากรที่ถามคำถามหลายชุดที่ออกแบบมาเพื่อดึงข้อมูลที่จำเป็นซึ่งอธิบายกระบวนการ ผู้สัมภาษณ์เรียกว่าผู้อำนวยความสะดวกเพื่อเน้นว่าเป็นผู้เข้าร่วมที่ให้ข้อมูล วิทยากรควรมีความรู้เกี่ยวกับกระบวนการที่สนใจ แต่สิ่งนี้ไม่สำคัญเท่ากับการมีระเบียบวิธีการที่มีโครงสร้างซึ่งจะถามคำถามจากผู้เชี่ยวชาญด้านกระบวนการ วิธีการนี้มีความสำคัญเนื่องจากโดยปกติแล้วทีมงานของผู้อำนวยความสะดวกจะรวบรวมข้อมูลทั่วทั้งสถานที่และผลลัพธ์ของข้อมูลจากผู้สัมภาษณ์ทั้งหมดจะต้องประกอบเข้าด้วยกันเมื่อเสร็จสิ้น [9] แบบจำลองได้รับการพัฒนาขึ้นเพื่อกำหนดสถานะปัจจุบันของกระบวนการซึ่งในกรณีนี้ผลิตภัณฑ์ขั้นสุดท้ายเรียกว่าโมเดลสแนปช็อต "ตามสภาพ" หรือชุดของแนวคิดเกี่ยวกับสิ่งที่กระบวนการควรมีซึ่งส่งผลให้เกิด "สิ่งที่สามารถทำได้ -be "แบบ. การสร้างแบบจำลองกระบวนการและข้อมูลสามารถใช้เพื่อตรวจสอบว่ากระบวนการและระบบข้อมูลที่มีอยู่นั้นถูกต้องหรือไม่และต้องการเพียงการปรับเปลี่ยนหรือการปรับปรุงเล็กน้อยหรือหากจำเป็นต้องทำการวิศวกรรมซ้ำเพื่อเป็นการดำเนินการแก้ไข การสร้างแบบจำลองทางธุรกิจเป็นมากกว่าวิธีการดูหรือทำให้กระบวนการข้อมูลของคุณเป็นไปโดยอัตโนมัติ การวิเคราะห์สามารถใช้เพื่อปรับรูปแบบพื้นฐานของธุรกิจหรือองค์กรของคุณในการดำเนินงาน [9] Computer-aided Software Engineering (CASE) ในสาขาวิศวกรรมซอฟต์แวร์ภาคสนามคือการประยุกต์ใช้ชุดเครื่องมือและวิธีการซอฟต์แวร์เพื่อพัฒนาซอฟต์แวร์ซึ่งส่งผลให้ผลิตภัณฑ์ซอฟต์แวร์มีคุณภาพสูงปราศจากข้อบกพร่องและบำรุงรักษาได้ [10]นอกจากนี้ยังหมายถึงวิธีการในการพัฒนาระบบสารสนเทศร่วมกับเครื่องมืออัตโนมัติที่สามารถใช้ในกระบวนการพัฒนาซอฟต์แวร์ [11]คำว่า "Computer-aided Software Engineering" (CASE) สามารถอ้างถึงซอฟต์แวร์ที่ใช้สำหรับการพัฒนาซอฟต์แวร์ระบบอัตโนมัติเช่นรหัสคอมพิวเตอร์ ฟังก์ชัน CASE ประกอบด้วยการวิเคราะห์การออกแบบและการเขียนโปรแกรม กล่องเครื่องมือวิธีการแบบอัตโนมัติสำหรับการออกแบบ, การจัดเก็บเอกสารและการผลิตรหัสคอมพิวเตอร์ในโครงสร้างที่ต้องการการเขียนโปรแกรมภาษา [12]

• ส่งเสริมความช่วยเหลือด้านคอมพิวเตอร์ในการพัฒนาซอฟต์แวร์และกระบวนการบำรุงรักษาซอฟต์แวร์และ เครื่องมือกรณีทั่วไปที่มีอยู่สำหรับการจัดการการกำหนดค่า , การสร้างแบบจำลองข้อมูล , การเปลี่ยนแปลงรูปแบบ , refactoring , แหล่งที่มาของการสร้างรหัส สภาพแวดล้อมการพัฒนาแบบบูรณาการ (IDE) ที่เรียกว่าเป็นสภาพแวดล้อมการออกแบบบูรณาการหรือบูรณาการการแก้จุดบกพร่องสภาพแวดล้อมที่เป็นโปรแกรมซอฟต์แวร์ที่ให้บริการสิ่งอำนวยความสะดวกที่ครบวงจรเพื่อการเขียนโปรแกรมคอมพิวเตอร์สำหรับการพัฒนาซอฟต์แวร์ โดยปกติ IDE ประกอบด้วย: IDEs ได้รับการออกแบบเพื่อเพิ่มผลผลิตโดยการให้โปรแกรมเมอร์ส่วนประกอบแน่นถักคล้ายกับส่วนติดต่อผู้ใช้ โดยทั่วไปแล้ว IDE จะมีไว้สำหรับภาษาการเขียนโปรแกรมเฉพาะเพื่อจัดเตรียมชุดคุณลักษณะที่ตรงกับกระบวนทัศน์การเขียนโปรแกรมของภาษามากที่สุด แบบภาษาใดภาษาเทียมที่สามารถใช้ในการแสดงข้อมูลหรือความรู้หรือระบบในโครงสร้างที่ถูกกำหนดโดยชุดสอดคล้องของกฎ กฎใช้สำหรับการตีความความหมายของส่วนประกอบในโครงสร้าง ภาษาการสร้างแบบจำลองอาจเป็นแบบกราฟิกหรือข้อความ [14]ภาษาการสร้างแบบจำลองกราฟิกใช้เทคนิคแผนภาพที่มีสัญลักษณ์ที่มีชื่อซึ่งแสดงถึงแนวคิดและเส้นที่เชื่อมต่อสัญลักษณ์และแสดงถึงความสัมพันธ์และคำอธิบายประกอบกราฟิกอื่น ๆ เพื่อแสดงข้อ จำกัด โดยทั่วไปภาษาการสร้างแบบจำลองข้อความจะใช้คำหลักที่เป็นมาตรฐานพร้อมด้วยพารามิเตอร์เพื่อสร้างนิพจน์ที่คอมพิวเตอร์ตีความได้

• IDEFเป็นครอบครัวของภาษาการสร้างแบบจำลองที่โดดเด่นที่สุดของซึ่งรวมถึงIDEF 0สำหรับการสร้างแบบจำลองการทำงานIDEF1Xสำหรับข้อมูลการสร้างแบบจำลองและIDEF5สำหรับการสร้างแบบจำลองจีส์

• LePUS3เป็นภาษาคำอธิบายการออกแบบเชิงวัตถุและภาษาข้อกำหนดที่เป็นทางการซึ่งเหมาะสำหรับการสร้างแบบจำลองโปรแกรมเชิงวัตถุขนาดใหญ่ ( Java , C ++ , C # ) และรูปแบบการออกแบบเป็นหลัก

• Specification and Description Language (SDL) เป็นภาษาข้อมูลจำเพาะที่กำหนดเป้าหมายตามข้อกำหนดที่ไม่คลุมเครือและคำอธิบายลักษณะการทำงานของระบบที่มีปฏิกิริยาและระบบกระจาย

• Unified Modeling Language (UML) เป็นภาษาโมเดลสำหรับวัตถุประสงค์ทั่วไปซึ่งเป็นมาตรฐานอุตสาหกรรมสำหรับการระบุระบบที่ต้องใช้ซอฟต์แวร์มาก UML 2.0 เวอร์ชันปัจจุบันรองรับเทคนิคไดอะแกรมที่แตกต่างกันสิบสามแบบและมีการสนับสนุนเครื่องมืออย่างกว้างขวาง ภาษาการสร้างแบบจำลองบางภาษาไม่สามารถใช้งานได้และสำหรับภาษาที่ใช้ภาษาเหล่านี้ไม่จำเป็นต้องหมายความว่าโปรแกรมเมอร์ไม่จำเป็นอีกต่อไป ในทางตรงกันข้ามแบบภาษาที่ปฏิบัติการมีวัตถุประสงค์เพื่อขยายการผลิตของโปรแกรมเมอร์ที่มีทักษะเพื่อให้พวกเขาสามารถแก้ไขปัญหายากขึ้นเช่นการคำนวณแบบขนานและระบบกระจาย กระบวนทัศน์การเขียนโปรแกรมเป็นรูปแบบพื้นฐานของการเขียนโปรแกรมคอมพิวเตอร์ซึ่งไม่ได้กำหนดโดยวิธีการจัดการโครงการโดยทั่วไป (เช่นน้ำตกหรือเปรียว) กระบวนทัศน์แตกต่างกันในแนวคิดและนามธรรมที่ใช้ในการแสดงองค์ประกอบของโปรแกรม (เช่นวัตถุฟังก์ชันตัวแปรข้อ จำกัด ) และขั้นตอนที่ประกอบด้วยการคำนวณ (เช่นการกำหนดการประเมินความต่อเนื่องการไหลของข้อมูล) บางครั้งแนวคิดที่ยืนยันโดยกระบวนทัศน์จะถูกนำไปใช้ร่วมกันในการออกแบบสถาปัตยกรรมระบบระดับสูง ในกรณีอื่น ๆ ขอบเขตของกระบวนทัศน์การเขียนโปรแกรม จำกัด อยู่ที่โครงสร้างภายในของโปรแกรมหรือโมดูลเฉพาะ ภาษาการเขียนโปรแกรมสามารถรองรับกระบวนทัศน์หลาย ตัวอย่างเช่นโปรแกรมที่เขียนด้วยC ++หรือObject Pascalอาจเป็นขั้นตอนทั้งหมดหรือเชิงวัตถุล้วนๆหรือมีองค์ประกอบของทั้งสองกระบวนทัศน์ นักออกแบบซอฟต์แวร์และโปรแกรมเมอร์ตัดสินใจว่าจะใช้องค์ประกอบกระบวนทัศน์เหล่านั้นอย่างไร ในการเขียนโปรแกรมเชิงวัตถุโปรแกรมเมอร์สามารถคิดว่าโปรแกรมเป็นชุดของวัตถุโต้ตอบในขณะที่ในการเขียนโปรแกรมเชิงฟังก์ชันโปรแกรมสามารถคิดว่าเป็นลำดับของการประเมินฟังก์ชันไร้สถานะ เมื่อการเขียนโปรแกรมคอมพิวเตอร์หรือระบบที่มีโปรเซสเซอร์หลายการเขียนโปรแกรมที่มุ่งเน้นกระบวนการช่วยให้โปรแกรมเมอร์จะคิดเกี่ยวกับการใช้งานเป็นชุดของกระบวนการพร้อมกันที่ใช้ร่วมกันปฏิบัติตามเหตุผลโครงสร้างข้อมูล เช่นเดียวกับกลุ่มที่แตกต่างกันในวิศวกรรมซอฟต์แวร์ที่แตกต่างกันสนับสนุนวิธีการที่แตกต่างกันการเขียนโปรแกรมภาษาสนับสนุนที่แตกต่างกันกระบวนทัศน์การเขียนโปรแกรม บางภาษาได้รับการออกแบบมาเพื่อรองรับกระบวนทัศน์เดียว ( SmalltalkรองรับการเขียนโปรแกรมเชิงวัตถุHaskellรองรับการเขียนโปรแกรมเชิงฟังก์ชัน) ในขณะที่ภาษาโปรแกรมอื่น ๆ รองรับกระบวนทัศน์หลายแบบ (เช่นObject Pascal , C ++ , C # , Visual Basic , Common Lisp , Scheme , Python , Rubyและออนซ์ ) กระบวนทัศน์ในการเขียนโปรแกรมหลายคนเป็นที่รู้จักกันดีว่าพวกเขาห้ามใช้วิธีอะไร ยกตัวอย่างเช่นโปรแกรมการทำงานบริสุทธิ์ห้ามใช้ผลข้างเคียง ; การเขียนโปรแกรมเชิงโครงสร้างห้ามใช้คำสั่งgoto ส่วนหนึ่งด้วยเหตุนี้กระบวนทัศน์ใหม่มักถูกมองว่าเป็นหลักคำสอนหรือเข้มงวดเกินไปสำหรับผู้ที่คุ้นเคยกับรูปแบบก่อนหน้านี้ [ ] การหลีกเลี่ยงวิธีการบางอย่างสามารถทำให้ง่ายต่อการพิสูจน์ทฤษฎีบทเกี่ยวกับความถูกต้องของโปรแกรมหรือเพียงแค่ทำความเข้าใจพฤติกรรมของโปรแกรม

• วิธีการ เขียนโปรแกรมเชิงวัตถุ

• Grady Booch 's ออกแบบเชิงวัตถุ (อู๊ด) หรือที่เรียกว่าการวิเคราะห์เชิงวัตถุและการออกแบบ (OOAD) โมเดล Booch ประกอบด้วยไดอะแกรมหกแบบ ได้แก่ คลาสอ็อบเจ็กต์การเปลี่ยนสถานะการโต้ตอบโมดูลและกระบวนการ [15]

• การออกแบบจากบนลงล่างและล่างขึ้นบน

• การเขียนโปรแกรมจากบนลงล่าง : พัฒนาขึ้นในปี 1970 โดยนักวิจัยของ IBM Harlan Mills (และNiklaus Wirth ) ในการเขียนโปรแกรมเชิงโครงสร้างที่พัฒนาขึ้น คำจำกัดความของการใช้ซอฟต์แวร์ซ้ำคือกระบวนการสร้างซอฟต์แวร์จากส่วนประกอบซอฟต์แวร์ที่กำหนดไว้ล่วงหน้า วิธีการที่นำมาใช้ซอฟแวร์พยายามที่จะเพิ่มหรือเพิ่มการใช้สิ่งของซอฟต์แวร์ที่มีอยู่ในวงจรการพัฒนาซอฟแวร์

ต่อไปนี้เป็นวิธีการใช้ซอฟต์แวร์ซ้ำโดยทั่วไป:

• เฟรมเวิร์กซอฟต์แวร์คือการออกแบบหรือการนำไปใช้งานซ้ำสำหรับระบบซอฟต์แวร์หรือระบบย่อย

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

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

• กลุ่มผลิตภัณฑ์ซอฟต์แวร์พยายามที่จะพัฒนาซอฟต์แวร์ตามชุดของสินทรัพย์และกระบวนการ 'หลัก' ทั่วไปเพื่อผลิตผลิตภัณฑ์ (หรือ 'แอปพลิเคชัน') ที่หลากหลายสำหรับตลาดเฉพาะ

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

• เอกสารโอเพนซอร์สผ่านไลบรารีเช่นGitHubให้โค้ดฟรีสำหรับนักพัฒนาซอฟต์แวร์เพื่อใช้ซ้ำและนำไปใช้ในแอพพลิเคชั่นหรือการออกแบบใหม่