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

ฉันกำลังทำงานกับผลิตภัณฑ์สำหรับลูกค้าที่ต้องถูกต้องและเหมาะสมกับวัตถุประสงค์ มันสร้างขึ้นบนกอง LAMP (PHP / Cake) ดังนั้นจึงมี GPL, MIT, PHP, APACHE สิทธิ์การใช้งาน: "ตามสภาพ" โดยไม่มีการรับประกันหรือเงื่อนไขใด ๆ ไม่ว่าโดยชัดแจ้งหรือโดยนัยรวมถึง แต่ไม่ จำกัด เพียงการรับประกันหรือเงื่อนไขใด ๆ ของ TITLE การไม่ละเมิดสิทธิมนุษยชนหรือความเหมาะสมสำหรับวัตถุประสงค์เฉพาะ คุณเป็นผู้รับผิดชอบ แต่เพียงผู้เดียวในการพิจารณาความเหมาะสมในการใช้หรือแจกจ่ายงานและความเสี่ยงที่เกี่ยวข้องกับการใช้สิทธิ์ของคุณภายใต้ใบอนุญาตนี้ เหตุผลของฉันที่ผลิตภัณฑ์ของฉันถูกต้องและเหมาะสมกับวัตถุประสงค์: เอกสาร UAT ที่ลงนามแล้วนั้นพิสูจน์ความถูกต้องและความเหมาะสมสำหรับวัตถุประสงค์ สแต็คมีการใช้อย่างกว้างขวางโดยนักพัฒนาอุตสาหกรรมและผู้ใช้ (netcraft, gartner ฯลฯ สถิติ) ว่ามีฉันทามติว่ามันเหมาะสำหรับวัตถุประสงค์ (เช่นเราสามารถเพิกเฉยต่อความเหมาะสมของข้อความเพื่อวัตถุประสงค์ในการปฏิเสธความรับผิดชอบตามขอบเขตการรับประกัน) นี่เป็นจุดที่ถูกต้องหรือไม่? ฉันสามารถทำการอ้างสิทธิ์ได้ว่าซอฟต์แวร์ของฉันนั้นเหมาะสมกับวัตถุประสงค์หรือไม่

15 licensing  documentation  specifications 

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

15 client-relations  specifications 

ตามที่ฉันได้เขียนในคำถามอื่น ๆ ที่นี่โครงการที่ฉันกำลังดำเนินการอยู่ในขณะนี้ไม่มีกระบวนการซอฟต์แวร์ นั่นหมายความว่าไม่มีเอกสาร (รวมทั้งความต้องการคัดลอกยากหรือสเปค)ไม่มีการควบคุมแหล่ง , ไม่มีฐานข้อมูลข้อผิดพลาดข้อบกพร่องเป็น "คงที่" (หวังว่า) และรหัสใหม่จะถูกเพิ่มในเวลาเดียวกันและไม่มีการทดสอบอย่างเป็นทางการ - เราจะล้มเหลวการทดสอบโจเอลแย่มากมันไม่ตลกเลย เมื่อวานนี้ผู้จัดการของฉันขอให้ฉันเขียนเอกสารเกี่ยวกับวิธีเริ่มแก้ไขข้อบกพร่องเหล่านี้ โปรดทราบว่าฉันแค่ฝึกงานที่นี่เป็นเวลา 6 เดือน ฉันจะออกไปในช่วงวันขอบคุณพระเจ้าในเดือนพฤศจิกายนเพื่อกลับไปโรงเรียน อย่างไรก็ตามฉันคิดว่าฉันอาจทำให้โครงการนี้เคลื่อนไหวไปในทิศทางที่ถูกต้อง แต่ฉันไม่แน่ใจว่าจะเริ่มต้นอย่างไร ขณะนี้ฉันกำลังใช้CiteSeerและWikipediaเพื่อพยายามค้นหาเอกสารและอธิบายกระบวนการซอฟต์แวร์และนำไปใช้ แต่คำแนะนำประสบการณ์ส่วนตัวหรือลิงก์ไปยังบล็อกเอกสารบทความ wiki หรืออื่น ๆ จะได้รับการชื่นชมอย่างมาก

13 development-process  specifications 

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

12 design  specifications 

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

12 prototyping  specifications 

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

12 design  agile  specifications 

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

11 c#  specifications 

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

11 version-control  specifications 

ฉันต้องการอธิบายว่าเพราะเหตุใดจึงไม่มีการเปลี่ยนแปลงข้อกำหนดในระหว่างช่วงเวลาการพัฒนากับพนักงานฝ่ายวางแผนใหม่

11 requirements  specifications  requirements-management 

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

10 documentation  specifications 

ทีมของฉันและฉันพัฒนาซอฟต์แวร์ที่ลูกค้าของเราจะใช้เพื่อโต้ตอบกับลูกค้าของพวกเขา นอกจากนี้เรายังกิน dogfood ของเราเองและใช้ซอฟต์แวร์ของเราเองเพื่อโต้ตอบกับลูกค้าของเรา ดังนั้นบางครั้งมันอาจเป็นเรื่องยากที่จะอธิบายกรณีและสถานการณ์การใช้งานเนื่องจากพนักงานของเราสามารถเป็นผู้ประกอบการลูกค้าของเราสามารถเป็นผู้ประกอบการและลูกค้าของลูกค้าของเราสามารถเป็นผู้เยี่ยมชมได้ อย่างไรก็ตามลูกค้าของเราสามารถเป็นผู้เยี่ยมชมที่มีปฏิสัมพันธ์กับพนักงานผู้ให้บริการของเราลูกค้าของลูกค้าของเราสามารถเป็นผู้เยี่ยมชมที่โต้ตอบกับลูกค้าหรือพนักงานของเรา นี่คือรูปแบบที่: A is an employee B is a customer C is our customers' customer X interacts with Y Operator --> Visitor A --> B A --> C B --> C เนื่องจากบางครั้งลูกค้าของเราสามารถมีบทบาทที่แตกต่างกันได้บางครั้งก็จำเป็นต้องอ้างถึงบทบาทเฉพาะผู้ดำเนินการหรือผู้เข้าชมแทนที่จะเป็นพนักงานและลูกค้า นอกจากนี้ยังเป็นการกล่าวคำว่า "ลูกค้าของลูกค้า" ตลอดเวลา ฉันสงสัยว่าร้านค้าพัฒนารายอื่นจัดการรายละเอียดความหมายเหล่านี้อย่างไรเมื่อเขียนกรณีการใช้งานและสถานการณ์จำลอง มีคำศัพท์ทั่วไปหนึ่งคำที่ใช้กับผลิตภัณฑ์ใด ๆ ที่เกี่ยวข้องกับนักแสดงระดับที่สามหรือไม่? นอกเหนือจากการใช้บทบาทเฉพาะผู้ดำเนินการและผู้เข้าชมคำใดที่สามารถใช้เพื่อระบุลูกค้าของลูกค้า คำจะต้องสั้นพอที่จะนำมาใช้ภายในองค์กร หากมีความยาวเกินกว่าสองพยางค์รูปแบบที่สั้นลงจะต้องแยกความแตกต่างจากนักแสดงคนอื่น ๆ

10 communication  naming  specifications 

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

9 issue-tracking  specifications  methodology 

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

9 specifications  wiki 

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

9 testing  qa  specifications 

ฉันไม่สามารถจินตนาการการเขียนซอฟต์แวร์โดยไม่มีสเป็ค ไม่ว่าร่างนั้นจะอยู่ในระดับสูงหรือสูง spec เป็นสิ่งสำคัญที่จะต้องอธิบายให้โปรแกรมเมอร์ที่ไม่รู้เรื่องเกี่ยวกับฟังก์ชันการทำงานของโปรแกรม แต่ปัญหาของสเป็คก็คือมันค่อนข้างเป็นพลเมืองชั้นสองในวงจรการพัฒนาซอฟต์แวร์ เมื่อการพัฒนาหยิบไอน้ำออกมามันก็จะถูกทอดทิ้ง แต่เมื่อมีข้อพิพาทเกิดขึ้นผู้พัฒนาและผู้ทดสอบและฝ่ายขายจะแย่งกันหาข้อมูลจำเพาะเพื่อให้เหตุผลของพวกเขา สถานการณ์อย่างน้อยหนึ่งเหตุการณ์จะเกิดขึ้น: ไม่สามารถกู้คืน spec ได้ไม่มีใครรู้ว่า spec อยู่ที่ไหน ข้อมูลจำเพาะรุ่นต่าง ๆ เกิดขึ้นจากแหล่งต่าง ๆ มันต้องใช้ความยากลำบากมากที่จะหารุ่นที่เป็นรุ่นล่าสุดหรือไม่ว่าจะมีเป็นรุ่นล่าสุดที่มีอยู่ ข้อมูลจำเพาะไม่สมบูรณ์บางส่วนของเอกสารที่อ้างถึงหายไป ดังนั้นการจัดการข้อมูลจำเพาะจึงเป็นสิ่งสำคัญและทุกคนมีแหล่งข้อมูลจำเพาะเพียงแหล่งเดียว คุณจัดการข้อมูลจำเพาะของคุณอย่างไร ฉันพยายามให้ทุกคนใช้ Google เอกสาร แต่ทุกคนคัดค้าน ทุกคนแนบมาและหลงใหลใน Microsoft Word มากเกินไปซึ่งก็คือ - ในความเห็นของพวกเขา - ใช้งานง่ายมากง่ายมากที่จะแทรกภาพ, ง่ายมากที่จะพิมพ์สมการและอะไรก็ตาม จะโน้มน้าวพวกเขาได้อย่างไรว่า MS Word นั้นยอดเยี่ยมสำหรับการแบ่งปัน?

9 specifications