คำถามติดแท็ก sdlc

ฉันหวังว่านี่ไม่ใช่คำถามทั่วไปเกินไป ฉันสามารถใช้คำแนะนำที่ปรุงรสได้จริงๆ ฉันเพิ่งได้รับการว่าจ้างให้เป็น "SW Engineer" แต่เพียงผู้เดียวในร้านค้าเล็ก ๆ ของนักวิทยาศาสตร์ที่ใช้เวลา 10-20 ปีที่ผ่านมาในการปูก้อนกรวดด้วยกันเป็นฐานรหัสที่กว้างใหญ่ (มันถูกเขียนในภาษาที่ล้าสมัยจริง: G2 - คิดว่า Pascal ด้วยกราฟิก) ตัวโปรแกรมเองเป็นแบบจำลองทางกายภาพของโรงงานแปรรูปสารเคมีที่ซับซ้อน ทีมที่เขียนมันมีความรู้เกี่ยวกับโดเมนอย่างไม่น่าเชื่อ แต่มีการฝึกอบรมอย่างเป็นทางการเพียงเล็กน้อยในการเขียนโปรแกรมพื้นฐาน พวกเขาเพิ่งเรียนรู้บทเรียนที่ยากลำบากเกี่ยวกับผลที่ตามมาของการจัดการการกำหนดค่าที่ไม่มีอยู่จริง ความพยายามในการบำรุงรักษาของพวกเขายังถูกขัดขวางอย่างมากจากการสะสม "ตะกอน" ที่ไม่มีเอกสารในรหัสด้วย ฉันจะให้คุณ "การเมือง" ของสถานการณ์ (มีเสมอ การเมือง!) แต่ก็เพียงพอที่จะบอกว่าไม่มีความเห็นเป็นเอกฉันท์เกี่ยวกับสิ่งที่จำเป็นสำหรับเส้นทางข้างหน้า พวกเขาขอให้ฉันเริ่มนำเสนอหลักการบางประการของการพัฒนาซอฟต์แวร์ที่ทันสมัยให้กับทีม พวกเขาต้องการให้ฉันแนะนำวิธีปฏิบัติและกลยุทธ์มาตรฐานอุตสาหกรรมบางประการเกี่ยวกับข้อกำหนดการเข้ารหัสการจัดการวงจรชีวิตรูปแบบการออกแบบระดับสูงและการควบคุมแหล่งที่มา ตรงไปตรงมามันเป็นงานที่ค่อนข้างน่ากลัวและฉันไม่แน่ใจว่าจะเริ่มต้นที่ไหน ในตอนแรกฉันมีแนวโน้มที่จะสอนพวกเขาในบางแนวคิดหลักของThe Pragmatic ProgrammerหรือRefactoringของ Fowler ("Code Smells" ฯลฯ ) ฉันหวังว่าจะแนะนำวิธีการแบบ Agile จำนวนมาก แต่ท้ายที่สุดเพื่อให้มีประสิทธิภาพฉันคิดว่าฉันจะต้องฝึกฝนพื้นฐาน 5-7 หลัก กล่าวอีกนัยหนึ่งอะไรคือหลักการหรือวิธีปฏิบัติที่สำคัญที่สุดที่พวกเขาสามารถเริ่มใช้งานได้อย่างแนบเนียน นั่นคือคำถามของฉัน: สิ่งที่คุณจะรวมไว้ในรายการกลยุทธ์ที่มีประสิทธิภาพที่สุดเพื่อช่วยยืดเส้นสปาเก็ตตี้ออกไป (และป้องกันไม่ให้เกิดขึ้นในอนาคต)

470 project-management  agile  development-process  maintenance  sdlc 

มีตัวอย่างที่ดีของรหัสที่มีเอกสารที่ดีเช่น java api แต่รหัสจำนวนมากในโครงการสาธารณะเช่นโครงการคอมไพล์และโครงการภายในของ บริษัท นั้นได้รับการบันทึกไว้ไม่ดีและไม่เป็นมิตรกับผู้มาใหม่ ในการ จำกัด การพัฒนาซอฟต์แวร์ทั้งหมดของฉันฉันต้องจัดการกับรหัสที่มีเอกสารไม่ดี ฉันสังเกตเห็นสิ่งต่าง ๆ ต่อไปนี้ - ความคิดเห็นน้อยหรือไม่มีเลยในรหัส ชื่อเมธอดและตัวแปรไม่ได้อธิบายตัวเอง มีเอกสารเพียงเล็กน้อยหรือไม่มีเลยว่าโค้ดเข้ากับระบบหรือกระบวนการทางธุรกิจได้อย่างไร จ้างนักพัฒนาที่ไม่ดีหรือไม่ให้คำปรึกษากับคนที่ดี พวกเขาไม่สามารถเขียนโค้ดที่ง่ายและสะอาดได้ ดังนั้นจึงเป็นเรื่องยากหรือเป็นไปไม่ได้สำหรับทุกคนรวมถึงผู้พัฒนาที่จะจัดทำเอกสารรหัส เป็นผลให้ฉันต้องผ่านรหัสจำนวนมากและพูดคุยกับคนจำนวนมากเพื่อเรียนรู้สิ่งต่าง ๆ ฉันรู้สึกว่านี่เป็นการเสียเวลาของทุกคน นอกจากนี้ยังสร้างความต้องการเซสชันการถ่ายโอน KT / ความรู้สำหรับผู้มาใหม่ไปยังโครงการ ฉันได้เรียนรู้ว่าเอกสารไม่ได้รับความสนใจเนื่องจากมีเหตุผลดังต่อไปนี้: ความเกียจคร้าน นักพัฒนาไม่ต้องการทำอะไรนอกจากรหัส งานรักษาความปลอดภัย. (หากไม่มีใครสามารถเข้าใจรหัสของคุณได้อย่างง่ายดายคุณอาจไม่สามารถเปลี่ยนได้อย่างง่ายดาย) กำหนดเวลาที่ยากลำบากทำให้เสียเวลาเล็กน้อยในการจัดทำเอกสาร ดังนั้นฉันสงสัยว่าจะมีวิธีการส่งเสริมและบังคับใช้แนวทางปฏิบัติด้านเอกสารที่ดีใน บริษัท หรือโครงการหรือไม่ กลยุทธ์ที่จะใช้ในการสร้างเอกสารที่เหมาะสมสำหรับระบบและรหัสของโครงการใด ๆ โดยไม่คำนึงถึงความซับซ้อนของมันคืออะไร? มีตัวอย่างที่ดีหรือไม่เมื่อจำเป็นต้องใช้เอกสารน้อยที่สุดหรือไม่ IMHO ฉันรู้สึกว่าเราควรมีการตรวจสอบเอกสารหลังจากส่งมอบโครงการแล้ว หากไม่ใช่เรื่องง่ายกระชับเป็นตัวอย่างและเป็นมิตรต่อผู้ใช้วิศวกรหรือนักพัฒนาเอกสารด้านเทคนิคจะเป็นผู้รับผิดชอบและทำการแก้ไข ฉันไม่คาดหวังว่าผู้คนจะทำเอกสารรีมไม่หวังว่ามันจะเป็นมิตรกับผู้ใช้เหมือนกับหนังสือเล่มแรก แต่ฉันหวังว่ามันจะช่วยลดความจำเป็นในการวิเคราะห์ชั่วโมงและช่วงเวลา KT ที่สิ้นเปลือง มีวิธีที่จะจบหรือบรรเทาความบ้าคลั่งนี้หรือไม่? "การพัฒนาเอกสารขับเคลื่อน" อาจจะ?

26 programming-practices  development-process  documentation  source-code  sdlc 

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

26 project-management  development-process  time  estimation  sdlc 

ใน บริษัท ของฉันเราประสบความสำเร็จในการปฏิบัติงานด้วยความคล่องตัว - แต่ไม่ต้องใช้การทำซ้ำ เหตุผลหลักคือเราไม่สามารถหาวิธีที่สะอาดเพื่อให้เหมาะสมใน QA ในรอบการวนซ้ำ เราเข้าใจว่า QA เป็นบิตของการตรวจสอบเพิ่มเติมสำหรับบิวด์บางตัว (รีลีสผู้สมัคร) ก่อนที่บิลด์นี้จะนำไปใช้กับลูกค้า จุดประสงค์คือเพื่อหลีกเลี่ยงการกระทำที่มุ่งร้ายเพียงอย่างเดียวที่สร้างความเสียหายต่อการเปิดตัวทั้งหมด เนื่องจากคุณไม่เคยรู้ว่าที่หนึ่งมันเป็น QA ต้องรอจนกว่าทุกคุณลักษณะ / กระทำสำหรับการเปิดตัวอยู่ในการสร้าง (ไม่มีคำพูดสุดท้ายที่มีชื่อเสียง "อนุญาตให้เปลี่ยนแปลงเพียงเล็กน้อย") หาก QA พบข้อบกพร่องในตัวเลือกการเปิดตัวนักพัฒนาแก้ไขข้อบกพร่องเหล่านี้ในสาขาการเปิดตัวที่เกี่ยวข้อง (และผสานเข้ากับลำตัว) เมื่อแก้ไขบั๊กทั้งหมดแล้วบิลด์ใหม่จะถูกปรับใช้เพื่อให้ QA ทำการทดสอบอีกครั้ง เฉพาะเมื่อไม่พบข้อบกพร่องในตัวเลือกการเปิดตัวบางอย่างมันจะถูกเสนอให้กับลูกค้าเพื่อการตรวจสอบ โดยปกติจะใช้เวลาประมาณสองถึงสามผู้สมัครประมาณหนึ่งสัปดาห์ต่อการเปิดตัว เวลาในการเขียนการแก้ไขนั้นปกติแล้วจะต่ำกว่าความพยายามในการทดสอบ ดังนั้นเพื่อให้นักพัฒนาไม่ว่างพวกเขาทำงานในการเปิดตัว N + 1 ในขณะที่ QA ทำงานบน N หากไม่มีการใช้การวนซ้ำนี่จะไม่มีปัญหาเพราะเราสามารถซ้อนทับงานสำหรับการปล่อย N และ N + 1 อย่างไรก็ตามจากสิ่งที่ฉันเข้าใจว่าสิ่งนี้ไม่เข้ากันกับวิธีการทำซ้ำเช่น Scrum หรือ XP พวกเขาต้องการให้ทำซ้ำได้ในตอนท้ายด้วยความพยายามในการทดสอบทั้งหมดเพื่อรวมไว้ในการทำซ้ำ …

17 agile  teamwork  qa  sdlc 

ฉันต้องการส่งคำถามนี้ออกไปเพื่อดูว่าสื่ออยู่ที่ไหนอย่างน่าสนใจ ฉันจะยอมรับว่าในช่วง 12 เดือนที่ผ่านมาฉันเลือก TDD และค่า Agile จำนวนมากในการพัฒนาซอฟต์แวร์ ฉันรู้สึกสับสนมากกับการพัฒนาซอฟต์แวร์ที่ดีขึ้นเรื่อย ๆ จนฉันไม่เคยละทิ้งพวกเขาออกจากหลักการ จนกระทั่ง ... ฉันได้รับการเสนอบทบาทการทำสัญญาที่สองเท่าของฉันกลับบ้านจ่ายสำหรับปี บริษัท ที่ฉันเข้าร่วมไม่ได้ทำตามวิธีการเฉพาะใด ๆ ทีมไม่เคยได้ยินอะไรเลยเช่นกลิ่นรหัส SOLID ฯลฯ และแน่นอนว่าฉันจะไม่ใช้เวลากับการทำ TDD หากทีมไม่เคยแม้แต่จะทำ เห็นการทดสอบหน่วยในทางปฏิบัติ ฉันขายของหมดแล้วหรือยัง ไม่ไม่สมบูรณ์ ... รหัสจะถูกเขียนว่า "หมดจด" เสมอ (ตามคำสอนของลุงบ็อบ) และหลักการของ SOLID จะถูกนำไปใช้กับรหัสที่ฉันเขียนตามที่พวกเขาต้องการเสมอ การทดสอบลดลงสำหรับฉัน แต่ บริษัท ไม่สามารถที่จะส่งทีมที่ไม่รู้จักเช่นคนที่ค่อนข้างตรงไปตรงมาแม้ว่าฉันจะสร้างกรอบการทดสอบพวกเขาจะไม่ใช้ / บำรุงรักษากรอบการทดสอบอย่างถูกต้อง การใช้สิ่งนั้นเป็นตัวอย่างคุณจะบอกว่านักพัฒนาไม่ควรทิ้งหลักการฝีมือของเขาเพื่อเงิน / ผลประโยชน์อื่น ๆ ฉันเข้าใจว่านี่อาจเป็นความเห็นส่วนตัวเกี่ยวกับความกังวลของพวกเขาต่อความต้องการทางธุรกิจและประโยชน์ของงานฝีมือ ฯลฯ แต่เราสามารถพิจารณาได้ว่าตัวอย่างเช่นการทดสอบอาจตกถ้า บริษัท ตัดสินใจว่าพวกเขาต้องการ ทีมทดสอบแทนที่จะเข้าใจการทดสอบหน่วยในการเขียนโปรแกรมนั่นเป็นสิ่งที่คุณสามารถยกโทษให้ตัวเองได้หรือไม่? …

16 agile  testing  unit-testing  tdd  sdlc 

พิจารณา บริษัท ที่ได้รับการรับรองอย่างภาคภูมิใจสำหรับวิธีการที่ไม่ใช่แบบ Agile ใช้เป็นจุดขายให้กับลูกค้าเพื่อแสดงความรับผิดชอบ คุณจะไปเกี่ยวกับวิธีการแนะนำ Kanban หรือการแย่งชิงกันมีความก้าวหน้าโดยไม่ทำลายทั้งระบบของพวกเขาและยังคงทำให้พวกเขามีความมั่นใจว่ามันยังคงสามารถเช่นเดียวกับความรับผิดชอบ / ตรวจสอบ ? ฉันรู้ว่าสิ่งนี้อาจเกี่ยวข้องกับ " คุณจะแนะนำวิธีการแบบเปรียวเช่น Scrum " ได้อย่างไร แต่ที่นี่ฉันสงสัยว่าจะหลีกเลี่ยง / หลีกเลี่ยงความจริงที่ว่า บริษัท กำหนดวิธีการจัดการ SDLC ภายใต้ข้ออ้างที่ผิด ๆ วิธีเดียวที่จะมีหลักฐานการตรวจสอบ

16 project-management  agile  development-process  sdlc 

ในกระบวนการ Agile ของเราเรามี Sprints 2 สัปดาห์ งานจะถูกส่งเป็นรายวัน (งานสร้างรายวัน) และทีมทดสอบจะทำการทดสอบเสร็จในวันถัดไปหรือในวันเดียวกัน นอกจากนี้เรายังมีบทวิจารณ์รหัส Dev ซึ่งต้องใช้เวลา (1-2 ชั่วโมง) ดังนั้นจึงมีกำหนด 3 ครั้งต่อสัปดาห์: จันทร์ - ศุกร์ นักพัฒนามารวมกันและแนะนำวิธีปรับปรุง / สร้างรหัสใหม่ ปัญหาของเราคือเมื่อรายการการดำเนินการเกิดขึ้นหลังจากการตรวจสอบโค้ดงานส่วนใหญ่ได้รับการทดสอบแล้ว ผู้ทดสอบไม่ต้องการทดสอบสิ่งที่ผ่านการทดสอบแล้ว พวกเขาไม่สนใจเกี่ยวกับการเปลี่ยนแปลง dev ภายใน เราเข้าใจผิดเกี่ยวกับกระบวนการเปรียวหรือไม่? การตรวจสอบโค้ดไม่เข้ากันกับรอบการเปิดตัว / ทดสอบรายวันหรือไม่ เราไม่สามารถตรวจสอบโค้ดได้ทุกวันเนื่องจากใช้เวลาของทุกคน

14 project-management  agile  teamwork  code-reviews  sdlc 

เมื่อผู้ขายประกาศว่าพวกเขาไม่ต้องการให้การสนับสนุนหรือบริการใด ๆ กับซอฟต์แวร์อีกต่อไป (และระบุความตั้งใจที่จะออกจากธุรกิจโดยไม่เสนอเส้นทางการอัปเกรด) ลูกค้าประเภทใดที่สามารถขอความช่วยเหลือได้ โปรดพิจารณาสิ่งนี้จากมุมมองของลูกค้า พนักงานไอทีของลูกค้ามีแนวโน้มที่จะพิจารณาทางเลือกด้านเทคนิคเท่านั้น แต่มีตัวเลือกที่ไม่ใช่ด้านเทคนิคที่ลูกค้าสามารถติดตามได้เช่นกัน นอกจากนี้ลูกค้ายังสามารถดำเนินการขั้นตอนที่เหมาะสมได้ล่วงหน้าเพื่อลดการหยุดชะงักเช่นในแง่ของสัญญา สิ่งที่ฉันคิดได้: จำเป็นต้องซื้อฮาร์ดแวร์สำรองและตั้งค่าสภาพแวดล้อมสำรองที่ซอฟต์แวร์สามารถทำงานได้ต่อไป วิธีการส่งออกข้อมูลที่หลากหลายซึ่งไม่ต้องการการมีส่วนร่วมของผู้ขาย (ซึ่งอาจรวมถึงเทคนิคที่ไม่สำคัญเช่นการตรวจสอบข้อมูลที่เก็บไว้ในแบ็กเอนด์ฐานข้อมูลสินค้าสำหรับเทคนิคที่เกี่ยวข้องเช่นการขูดหน้าจอการพิมพ์ไปยังภาพตามด้วยการสแกนซ้ำเป็นต้น) ระบบคู่ขนานที่พนักงานจะทำซ้ำข้อมูลเก่าลงในระบบใหม่ด้วยตนเองหรือกึ่งอัตโนมัติ วิธีการทางกฎหมายในกรณีที่ผู้ขายมีปัญหาทางการเงิน (เช่นในกรณีของสัญญารหัสต้นทาง ) ความคิดอื่น ๆ ? สมมติว่าไม่มี "การหลบเลี่ยง" ที่เกี่ยวข้อง (ไม่มี DRM หรือ DMCA) ไม่มีการกู้คืนข้อมูลหรือวิศวกรรมย้อนกลับทางกฎหมาย / ยอมรับได้หรือไม่? หมายเหตุการแก้ไข: มันเป็นการผสมผสานของเรื่องราวเล็ก ๆ น้อย ๆ แต่เป็นเรื่องจริง ฉันไม่ได้เกี่ยวข้องโดยตรงกับสิ่งเหล่านี้ มันเป็นเพียงความปรารถนาของฉันที่จะเรียนรู้เกี่ยวกับวิธีการจัดการสถานการณ์ "จุดสิ้นสุดของชีวิต" โดยทั่วไป มันไม่ใช่ความตั้งใจของฉันที่จะทำให้เนื้อเรื่องดั้งเดิมฟังเหมือน "ยาก" ที่ต้องแก้ไข

14 contract  legacy  sdlc  software-obsolescence 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา ในอุตสาหกรรมมีความแตกต่างระหว่างสภาพแวดล้อม 'ในบ้าน' ที่นักพัฒนาซอฟต์แวร์กำลังเขียนรหัสซึ่ง บริษัท จะใช้และสภาพแวดล้อม 'การพัฒนาซอฟต์แวร์' ที่เหมาะสมซึ่งเป็นซอฟต์แวร์ที่สร้างขึ้นเพื่อจำหน่าย / จำหน่าย สู่สาธารณะ ความแตกต่างที่เห็นได้ชัดระหว่างสองคือ บริษัท ที่มุ่งเน้นการพัฒนาซอฟต์แวร์โดยทั่วไปจะยึดติดกับวงจรชีวิตการพัฒนาซอฟต์แวร์บางอย่างเช่นการเขียนข้อมูลจำเพาะการทดสอบการสร้าง ฯลฯ ในขณะที่ร้านค้าภายใน บริษัท ทำสิ่งต่าง ๆ ในแบบสบาย ๆ มากกว่าเพราะพวกเขาเป็นผู้ใช้งานและสามารถแก้ไขสิ่งที่ไม่ถูกต้องได้เสมอ ในฐานะนักเรียน (เช่นนักเรียนคนอื่น ๆ ) ฉันคาดหวังว่าตัวเองจะจบลงด้วยการทำงานในสภาพแวดล้อมการพัฒนาซอฟต์แวร์ แต่ฉันก็จบลงด้วยการได้ตำแหน่งแรกของ บริษัท ที่ดำเนินธุรกิจแฟชั่นในบ้านมากกว่า บางครั้งฉันสงสัยว่าฉันพลาดประสบการณ์การพัฒนาซอฟต์แวร์ที่สมบูรณ์แบบหรือไม่ มีพื้นฐานสำหรับความรู้สึกนี้หรือไม่? ฉันควรพยายามเข้าร่วมสภาพแวดล้อมการพัฒนาซอฟต์แวร์ที่เหมาะสมหรือไม่

13 programming-practices  skills  sdlc 

ที่มหาวิทยาลัยในท้องถิ่นของฉันมีสโมสรคอมพิวเตอร์ขนาดเล็กสำหรับนักเรียนประมาณ 20 คน สโมสรมีทีมเล็ก ๆ หลายแห่งที่มุ่งเน้นเฉพาะด้านเช่นการพัฒนาอุปกรณ์เคลื่อนที่หุ่นยนต์การพัฒนาเกมและการแฮ็ค / การรักษาความปลอดภัย ฉันแนะนำแนวคิดการพัฒนาแบบเปรียวเบื้องต้นให้กับทีมสองกลุ่มเช่นเรื่องราวของผู้ใช้การประเมินความซับซ้อนของงานและการรวมอย่างต่อเนื่องสำหรับการควบคุมเวอร์ชันและการสร้าง / ทดสอบอัตโนมัติ ฉันคุ้นเคยกับวงจรชีวิตการพัฒนาขั้นพื้นฐานบางอย่างเช่น Waterfall, Spiral, RUP, เปรียว ฯลฯ แต่ฉันสงสัยว่ามีสิ่งใดที่เป็นวงจรการพัฒนาซอฟต์แวร์สำหรับการแฮ็ค / การเจาะระบบรักษาความปลอดภัย แน่นอนแฮกเกอร์กำลังเขียนรหัสคอมพิวเตอร์ แต่วงจรชีวิตของรหัสนั้นคืออะไร ฉันไม่คิดว่าพวกเขาจะกังวลเกี่ยวกับการบำรุงรักษามากเกินไปเมื่อพบการละเมิดและแก้ไขแล้วรหัสที่ใช้ประโยชน์จากการละเมิดนั้นไม่ได้ผล ฉันคิดว่าวงจรชีวิตจะเป็นเช่น: ค้นหาช่องว่างในความปลอดภัย ใช้ประโยชน์จากช่องว่างในการรักษาความปลอดภัย จัดหา payload ใช้ประโยชน์จากส่วนของข้อมูล มีความแตกต่างอะไรบ้าง (ถ้ามี) สำหรับวงจรการพัฒนาของซอฟต์แวร์เมื่อจุดประสงค์ของผลิตภัณฑ์คือการละเมิดความปลอดภัย?

10 development-process  security  hacking  sdlc 

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

10 code-quality  sdlc  product-management 

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

9 terminology  sdlc