ยินดีด้วยคุณคือ นักพัฒนาอิสระที่มีความสามารถ . จากจุดเริ่มต้นที่ต่ำต้อยของคุณบางทีอาจทำงานเป็นผู้ทดสอบคุณได้พัฒนาไปสู่นักพัฒนาทีมจากนั้นเป็นนักพัฒนาอาวุโสและตอนนี้คุณได้ก้าวกระโดดไปอีกขั้นหนึ่งที่ใหญ่ที่สุดในบรรดาพวกเขาทั้งหมดไปจนถึงการทำงานโดยตรงกับลูกค้า
แต่ในกรณีที่การเปลี่ยนอื่น ๆ เป็นแบบเชิงเส้นค่าสุดท้ายนี้เป็นเลขชี้กำลัง แม้ว่าในอดีตคุณจะได้รับคำสั่งเดินขบวนจากนายจ้างที่ทำงานกับลูกค้าหรือเป็นตัวของตัวเองในธุรกิจซอฟต์แวร์ แต่ตอนนี้ความรับผิดชอบทั้งหมดที่เคยกระจายระหว่างการทดสอบผู้เชี่ยวชาญการจัดการโปรแกรม ฯลฯ เป็นของคุณทั้งหมด และตอนนี้คุณกำลังทำงานกับลูกค้าที่ไม่ได้อยู่ในธุรกิจซอฟต์แวร์ พวกเขาอยู่ในธุรกิจอื่นที่ต้องการซอฟต์แวร์สักชิ้นและไม่มีวิสัยทัศน์ที่ชัดเจนและแม่นยำว่าต้องการอะไรจากคุณ นี่เป็นความท้าทายที่ยิ่งใหญ่กว่าที่ปรากฏ
* หมายเหตุ: * ที่นี่ฉันกำลังอธิบายถึงลูกค้ารายย่อยที่ต้องการกองทัพแบบคนเดียวจากนักพัฒนาของพวกเขา ไม่ใช่เส้นทางเดียวที่นักแปลอิสระสามารถใช้และไม่ใช่ลูกค้ารายเดียวที่เราทำงานด้วยที่ ApeeScape แต่เป็นเส้นทางที่ฉันชอบมากที่สุด แน่นอนว่าหากคุณทำงานเป็นทีมไม่ใช่ ด้วยตัวคุณเอง บางส่วนด้านล่างนี้ใช้ไม่ได้ ตัวอย่างเช่นหากคุณใช้ วิธีการแบบ Agile หรือ การต่อสู้ คุณอาจต้องการจัดโครงสร้างเป้าหมายให้แตกต่างกันเล็กน้อย
จากจุดเริ่มต้นที่ต่ำต้อยของคุณบางทีอาจทำงานเป็นผู้ทดสอบคุณได้พัฒนาไปสู่การเป็นนักพัฒนาทีมจากนั้นเป็นนักพัฒนาอาวุโสและตอนนี้คุณได้ก้าวกระโดดไปอีกขั้นหนึ่งที่ใหญ่ที่สุดในบรรดาพวกเขาทั้งหมดไปจนถึงการทำงานโดยตรงกับลูกค้า
คุณเคยได้ยินเกี่ยวกับความสำคัญสูงสุดของการสื่อสาร คุณไม่สามารถทำงานได้โดยใช้คำอธิบายสั้น ๆ สองสามประโยคผ่าน Skype และพูดว่า “ เจอกันใหม่อีกสามเดือนเมื่อฉันเสร็จ” คุณต้องติดต่อสื่อสารกับลูกค้าของคุณและในทุกขั้นตอนของการทำงานโปรดตรวจสอบให้แน่ใจว่าคุณมีแนวคิดที่สอดคล้องกันเกี่ยวกับวัตถุประสงค์เนื่องจากเป็นเรื่องยากที่ลูกค้าจะส่ง Wireframes และข้อกำหนดการทำงานโดยละเอียดให้คุณ คุณจะได้รับแนวคิดทั่วไปเกี่ยวกับสิ่งที่ซอฟต์แวร์ควรทำมีลักษณะและความลื่นไหล หากคุณเขียนแอปพลิเคชันตามคำอธิบายคร่าวๆที่คุณมักจะเริ่มต้นแทบไม่มีโอกาสที่ลูกค้าของคุณจะพอใจกับผลลัพธ์ ในแต่ละขั้นตอนคุณต้องทบทวนวิธีการที่ใกล้เคียงกับข้อตกลงมากขึ้น
คุณไม่สามารถทำงานได้โดยรับคำอธิบายสั้น ๆ สองสามประโยคผ่าน Skype และพูดว่า 'เจอกันอีกสามเดือนเมื่อฉันทำเสร็จ'
จากการทำงานมาหลายปีใน บริษัท ที่เป็นธุรกิจซอฟต์แวร์ซึ่งทุกคนในทีมล้วนมาจากวัฒนธรรมเดียวกันพูดภาษาแม่เดียวกันทำงานในห้องโถงเดียวกันพบกันทุกวัน ฯลฯ เป็นที่น่าสังเกตว่า บริษัท ยัง ไม่ได้รับสิ่งที่ต้องการเพียงครึ่งเดียว อย่าพลาด: ความท้าทายที่นี่มีมาก
ทำไมเอกสารการออกแบบซอฟต์แวร์จึงมีความสำคัญ
ดังนั้นเมื่อคุณทำโครงการใหม่ ก่อนที่คุณจะเปิด Xcode หรือ Visual Studio คุณจำเป็นต้องมีเป้าหมายการออกแบบที่ชัดเจนและตกลงกัน . และควรกำหนดเป้าหมายเหล่านี้ในเอกสารข้อกำหนด หากลูกค้ายังไม่ได้เขียนคุณควรเขียนและส่งให้ลูกค้าตรวจสอบก่อนที่คุณจะเปิด IDE ของคุณด้วยซ้ำ และ หากคุณพบลูกค้าที่พูดว่า“ เราไม่มีเวลาสำหรับเอกสารการออกแบบ” โดยตรงไปตรงมาคุณควรเดินออกไปจากโครงการ เพราะคุณมีปัญหาอยู่ข้างหน้า ข้อกำหนดไม่จำเป็นต้องมีความยาวเป็นพิเศษ อาจเป็นได้เพียงไม่กี่หน้า แต่อย่างน้อยที่สุดควรจัดวางอินเทอร์เฟซผู้ใช้รวมโครงร่าง (หากมีองค์ประกอบ UI) และกำหนดเป้าหมายที่สำเร็จ
ไม่มี เอกสารนี้คุณจะต้องตกอยู่ในวงล้อมของการเทียบเคียงที่รุนแรงลูกค้าโต้แย้งในสิ่งที่พวกเขาบอกคุณหรือสิ่งที่คุณบอกพวกเขาส่งข้อความตัดบทและวางการสื่อสารก่อนหน้านี้ด้วยความโกรธการตีความและการโต้เถียงจนกว่าจะถึงเวลาที่ลูกค้าต้องการ คุณทำการเปลี่ยนแปลงเพื่อให้แอปพลิเคชันสอดคล้องกับ“ สิ่งที่พวกเขาต้องการจริงๆ” และคาดว่าคุณจะทำการเปลี่ยนแปลงเหล่านั้นโดยไม่ต้องจ่ายเงิน
ด้วย เอกสารการออกแบบซอฟต์แวร์นี้คุณจะมีคำตอบสำหรับการเล่นลิ้นดังกล่าว: เมื่อมีความขัดแย้งเกิดขึ้นคุณสามารถอ้างถึงข้อกำหนดที่ลูกค้าตกลงและลงชื่อออกโดยชี้ให้เห็นว่าคุณได้ปฏิบัติตามจดหมายแล้ว แทนที่จะโต้แย้งที่โกรธเคืองคุณจะต้องแก้ไขและชี้แจงเอกสาร หากมีสิ่งใดเกิดขึ้นลูกค้าจะขออภัยที่ปล่อยให้ความไม่ถูกต้องผ่านไปตั้งแต่แรก
เราทุกคนต้องการให้ลูกค้าพึงพอใจ เราทุกคนต้องการความสัมพันธ์ในการทำงานที่เป็นมิตร และเราทุกคนต่างต้องการความภาคภูมิใจในงานที่ทำได้ดี แต่สิ่งเหล่านี้จะเกิดขึ้นไม่ได้หากมีความคลุมเครือไม่ว่างานนั้นจริงจะเป็นอย่างไร คือ . หากลูกค้าของคุณบอกว่าเอกสารการออกแบบเป็นงานพิเศษมากเกินไปคุณต้องอธิบายให้พวกเขาเข้าใจว่า จริง งานพิเศษจะปรากฏขึ้นเมื่อจำเป็นต้องมีการแก้ไขเนื่องจากความเข้าใจผิดบางประการ ถ้าลูกค้า ยัง ยืนยันว่าคุณก้าวหน้าโดยไม่มีเอกสารดังกล่าวคุณควรยอมรับความจริงที่ว่าคุณมีความสัมพันธ์ที่ไม่สามารถทำงานได้และเดินจากไป
ข้อกำหนดการออกแบบซอฟต์แวร์ควรระบุอะไรบ้าง?
อย่างน้อยที่สุดควรเป็นคำอธิบายของแอปพลิเคชันที่ต้องการเกณฑ์ความสำเร็จและเหตุการณ์สำคัญ โปรดจำไว้ว่าคุณกำลังแบ่งปันสิ่งที่อธิบายได้ดีที่สุดว่าเป็นเอกสารข้อกำหนดและฟังก์ชันไม่ใช่ข้อกำหนดการนำไปใช้งาน และเว้นแต่การใช้งานเฉพาะจะเป็นวัตถุประสงค์ของลูกค้าที่ระบุไว้วิธีที่คุณจะทำให้การใช้งานนั้นขึ้นอยู่กับคุณ
หน้าจอผู้ใช้
โครงการส่วนใหญ่เป็นแอปพลิเคชันไม่ใช่ไลบรารีหรือเฟรมเวิร์ก แต่ถ้าคุณมีหนึ่งในสิ่งเหล่านี้เป็นสิ่งที่ส่งมอบได้ก็นับว่าคุณโชคดีเพราะ อินเทอร์เฟซผู้ใช้อยู่ห่างไกลจากองค์ประกอบที่เป็นปัญหาที่สุดของเทมเพลตเอกสารการออกแบบของคุณ และมักนำไปสู่ความเข้าใจผิด ลูกค้าจำนวนมากจะส่งภาพประกอบที่สมบูรณ์แบบที่สร้างขึ้นในโปรแกรมแก้ไขกราฟิกโดยนักออกแบบกราฟิกที่ไม่ใช่โปรแกรมเมอร์ แต่ปัญหาคือภาพประกอบเหล่านี้ไม่ได้บอกอะไรเกี่ยวกับภาพเคลื่อนไหวสถานะการควบคุม (เช่นปุ่มนี้ถูกปิดใช้งานหรือไม่ปุ่มนี้จะหายไปเมื่อใช้ไม่ได้หรือไม่) หรือแม้กระทั่งการดำเนินการใดที่ต้องดำเนินการเมื่อกดปุ่ม
ลูกค้าจำนวนมากจะส่งภาพประกอบที่สมบูรณ์แบบซึ่งสร้างขึ้นในโปรแกรมแก้ไขกราฟิกโดยนักออกแบบกราฟิกที่ไม่ใช่โปรแกรมเมอร์ แต่ภาพประกอบเหล่านี้ไม่ได้บอกอะไรเกี่ยวกับภาพเคลื่อนไหวสถานะการควบคุมหรือแม้แต่สิ่งที่ต้องดำเนินการเมื่อกดปุ่ม
ก่อนที่คุณจะเริ่มเขียนโค้ดหลังภาพประกอบเหล่านี้คุณควรจะตอบคำถามเหล่านั้นได้ทั้งหมด โดยเฉพาะคุณควรรู้:
- การควบคุมสามารถมองเห็นและ / หรือเปิดใช้งานอยู่เสมอหรือไม่ รัฐของพวกเขาเปลี่ยนแปลงภายใต้เงื่อนไขใด
- ดูเหมือนบิตแมปเป็นปุ่มหรือเปล่า
- การเปลี่ยนแปลงใดเกิดขึ้นระหว่างสถานะและมุมมองเหล่านี้ และควรเป็นภาพเคลื่อนไหวอย่างไร?
หากคุณต้องการสร้าง UI สำหรับการทำงานร่วมกันของไคลเอ็นต์ให้ทำแบบเดียวกันในทางกลับกัน: ใช้เครื่องมือโครงร่างและสร้างชุดรูปแบบหน้าจอที่สมบูรณ์รวมถึงตัวแปรที่มุมมองแสดงในสถานะแอปพลิเคชันต่างๆ อาจเป็นงานที่ละเอียดถี่ถ้วนและน่าเบื่อ แต่คุณจะไม่เสียใจเพราะมันช่วยให้คุณไม่ต้องเขียนโค้ดจำนวนมากซ้ำและสร้างอินเทอร์เฟซใหม่เนื่องจากความเข้าใจผิดเล็กน้อยที่มีผลกระทบหลัก ๆ หากคุณกำลังสร้างแอปพลิเคชันคู่ (เช่นสำหรับทั้งคู่ iPhone และ iPad) สร้างโครงลวดแยกกันสำหรับทั้งสอง
ขนาดหน้าจอก็สำคัญเช่นกัน มี (ตามที่เขียน) หน้าจอ iPhone สามขนาด โครงลวดแยกสำหรับหน้าจอ 3.5 'และ 4' อาจมากเกินไป แต่คุณอาจต้องสร้างขึ้น ในกรณีส่วนใหญ่คุณสามารถเปลี่ยนสัดส่วนได้
หากลูกค้าของคุณจัดหากราฟิกให้คุณตรวจสอบให้แน่ใจว่ามีขนาดที่ถูกต้องและมีอัตราส่วนภาพที่เหมาะสม การปรับบิตแมปใด ๆ ที่มีข้อความหรือวัตถุ (เช่นวงกลม) จะทำให้เกิดการบิดเบือน หากไม่ตรงกันโปรดแจ้งให้ลูกค้าสร้างใหม่โดยใช้ขนาดที่ตรงกัน อย่าคิดว่าคุณสามารถยืดหน้าจอขนาด 3.5 นิ้วให้เป็นสแปลชขนาด 4 นิ้วแล้วหมุนไปด้วย
ฟังก์ชันการทำงาน
คำถามสำคัญที่ต้องถามในเอกสารการออกแบบแอปพลิเคชัน:
- แอปพลิเคชันทำอะไรและทำงานได้เร็วแค่ไหน?
- เงื่อนไขความล้มเหลวที่เป็นไปได้คืออะไรและได้รับการจัดการอย่างไร?
- การดำเนินการแบบครั้งเดียวใดที่ดำเนินการในการดำเนินการครั้งแรก (เช่นหลังการติดตั้ง)
- หากผู้ใช้สร้างรายการประเภทใดก็ได้ (เช่นบุ๊กมาร์ก) มีข้อ จำกัด อย่างไร
สรุปแนวคิดเหล่านี้ให้ละเอียดและละเอียดถี่ถ้วนที่สุดเท่าที่จะทำได้เนื่องจากข้อผิดพลาดหรือความเข้าใจผิดในที่นี้จะหมายถึงการเขียนโค้ดใหม่
เหตุการณ์สำคัญ
เทมเพลตข้อกำหนดของคุณควรจัดวางเหตุการณ์สำคัญที่ชัดเจน หากลูกค้าของคุณเขียนการออกแบบส่วนติดต่อผู้ใช้และฟังก์ชันการทำงานคุณควรเห็นด้วยกับเหตุการณ์สำคัญชุดหนึ่งในภายหลัง บางครั้งเกณฑ์เหล่านี้เป็นเกณฑ์การเรียกเก็บเงินเช่นกัน แต่อย่างน้อยที่สุดเกณฑ์เหล่านี้ก็ให้ตัวชี้วัดที่ชัดเจนในการดำเนินการให้เสร็จสิ้น เหตุการณ์สำคัญอาจอยู่ในแง่ของการทำงานและ / หรือส่วนประกอบ พวกเขาอาจเป็นแอปพลิเคชันแยกต่างหากหากกิ๊กเกี่ยวข้องกับชุดของสิ่งที่ส่งมอบ หากเป็นไปได้เหตุการณ์สำคัญควรมีระยะเวลาเท่ากันโดยประมาณ
ตัวอย่างข้อกำหนดการออกแบบซอฟต์แวร์
ในที่นี้ฉันจะจัดวางโครงสร้างตัวอย่างของเอกสารการออกแบบที่เหมาะสม แน่นอนแม่แบบนี้ควรปรับเปลี่ยนตามความจำเป็น สำหรับตัวอย่างอื่นดู ข้อมูลจำเพาะตัวอย่างของ Joel Spolsky ขึ้นอยู่กับ บทความนี้ . เขาเข้าใกล้เอกสารแตกต่างกันเล็กน้อย แต่มีความรู้สึกคล้ายกัน
c-corp หรือ s-corp
คำแถลงเป้าหมาย
รวมย่อหน้าสั้น ๆ ที่อธิบายโครงการและกลุ่มเป้าหมาย
รายละเอียดการทำงาน
แอปพลิเคชันคืออะไร ทำ เหรอ? สถานะแอปพลิเคชันใด (คำอธิบายระดับสูงของสถานการณ์ผู้ใช้หลัก) ที่ผู้ใช้จะพบ
ตัวอย่างเช่นคำอธิบายการทำงานของคุณอาจมีลักษณะดังนี้:
- การเรียกใช้ครั้งแรก
- การสร้าง _____ ใหม่ (เกมการค้นหา ฯลฯ )
- การดำเนินงาน
- ความเป็นมาและพฤติกรรมเบื้องหน้า
หน้าจอผู้ใช้
รวมโครงร่างสำหรับแต่ละหน้าพร้อมคำอธิบายโดยละเอียดของ:
- การควบคุมแต่ละรายการรวมถึงสถานะ (เปิดใช้งาน / ปิดใช้งาน / ไฮไลต์) และการดำเนินการ
- การวางแนวที่รองรับและการเปลี่ยนระหว่างพวกเขา
- แสดงฟังก์ชันการทำงาน
- การจัดการข้อผิดพลาด
- ขนาดและข้อ จำกัด
นี่คือ wireframes ที่เกี่ยวข้องกับแอพ iOS ล่าสุดของฉัน NotifEye:
หากคุณสนใจฉันสร้างภาพจำลองเหล่านี้โดยใช้ เครื่องมือ Wireframing ของ Balsamiq .
ตัวอย่างเช่นไฟล์ คำอธิบาย UI อาจมีลักษณะดังนี้:
- แถบนำทาง
- การควบคุมการนำทางด้านซ้าย: กลับไปที่โฮมเพจ
- แถบชื่อเรื่อง: หน้าจอปัจจุบันหรือชื่อการดำเนินการ
- ปุ่มใหม่: สร้างสิ่งใหม่
- มุมมองตาราง
- ส่วนที่ 0: ชื่อส่วน
- ส่วน 0 แถว:
- การควบคุมแถว 0 (เช่นรูปภาพ)
- บรรทัดข้อความ 0
- บรรทัดข้อความ 2
เหตุการณ์สำคัญ
ตามที่อธิบายไว้ข้างต้นกำหนดเวลาในการดำเนินการแล้วเสร็จและคาดว่าจะส่งมอบ
ตัวอย่างเช่นส่วนเหตุการณ์สำคัญในเทมเพลตเอกสารการออกแบบของคุณอาจมีลักษณะดังนี้
- แอปพลิเคชั่น Facade แสดงหน้าจอและการเปลี่ยนชั่วคราวและภาพ / ข้อความตัวอย่าง
- โปรโตคอลการสื่อสาร: แอปพลิเคชันเชื่อมต่อกับเครือข่าย / เซิร์ฟเวอร์
- เหตุการณ์สำคัญในหน้าที่ 1: …
- แอปพลิเคชันอัลฟ่า (พร้อมฟังก์ชันการทำงานเต็มรูปแบบ)
- เสถียรภาพ
- ปล่อย
การตรวจสอบเอกสารซอฟต์แวร์ยังคงมีความเกี่ยวข้อง
ฉันไม่ได้หมายความว่าจะบอกเป็นนัยว่าขั้นตอนการออกแบบสิ้นสุดลงเมื่อคุณและลูกค้าของคุณได้ตกลงกันในเอกสารข้อกำหนด จะมีรายละเอียดที่คุณทั้งคู่ไม่เคยพิจารณาและทั้งคุณและลูกค้าจะมองไปที่ผลลัพธ์ระดับกลางพบกับแนวคิดใหม่ ๆ การเปลี่ยนแปลงการออกแบบข้อบกพร่องในการออกแบบที่ไม่คาดคิดและข้อเสนอแนะที่ไม่สามารถใช้งานได้
การออกแบบจะพัฒนาขึ้นและควรบันทึกการเปลี่ยนแปลงไว้ในเอกสารของคุณ จากประสบการณ์ 25 ปีของฉันฉันไม่เคยทำงานในโครงการที่สิ่งนี้ไม่เกิดขึ้นเลยสักครั้งและรวมถึงแอปพลิเคชันของฉันเองด้วย (นั่นคือฉันเป็นลูกค้าของฉันเองที่ไหน) ถึงกระนั้นฉันก็สร้างเอกสารการออกแบบที่มีข้อกำหนดโดยละเอียดและปรับเปลี่ยนตามความจำเป็น
เหนือสิ่งอื่นใดติดต่อกัน อย่างน้อยสัปดาห์ละหลายครั้งติดต่อลูกค้าของคุณรายงานความคืบหน้าของคุณขอคำชี้แจงและตรวจสอบให้แน่ใจว่าคุณแบ่งปันวิสัยทัศน์ที่เหมือนกัน ในการทดสอบกระดาษลิตมัสสำหรับการสื่อสารของคุณพยายามตรวจสอบให้แน่ใจว่าคุณและลูกค้าของคุณให้ เหมือนกัน คำตอบสำหรับคำถามสามข้อนี้:
- นักพัฒนากำลังทำอะไรอยู่
- ขณะนี้นักพัฒนากำลังทำอะไรอยู่
- นักพัฒนาจะทำงานอะไรต่อไป?
ทำความเข้าใจพื้นฐาน
คำย่อ SDD ย่อมาจากอะไร?
SDD ย่อมาจากเอกสารการออกแบบซอฟต์แวร์หรือคำอธิบายการออกแบบซอฟต์แวร์
เอกสารการออกแบบการทำงานคืออะไร?
เอกสารการออกแบบการใช้งานจะอธิบายถึงความสามารถลักษณะและฟังก์ชันของผลิตภัณฑ์ซอฟต์แวร์ที่จำเป็นในการดำเนินการในท้ายที่สุด เอกสารการออกแบบเรียกอีกอย่างว่าข้อกำหนดการใช้งานหรือเอกสารข้อกำหนดการใช้งาน (FSD) หรือข้อกำหนดข้อกำหนดการทำงาน
เอกสารการออกแบบระดับสูงคืออะไร?
เอกสารการออกแบบระดับสูง (HLDD) อธิบายถึงสถาปัตยกรรมที่ใช้ในการพัฒนาผลิตภัณฑ์ซอฟต์แวร์เฉพาะ โดยปกติจะมีแผนภาพที่แสดงถึงโครงสร้างที่จินตนาการไว้ของระบบซอฟต์แวร์ เนื่องจากเอกสารนี้เป็นเอกสารระดับสูงจึงมักใช้ภาษาที่ไม่ใช่ทางเทคนิค
เอกสารการออกแบบซอฟต์แวร์มีอะไรบ้าง?
เอกสารการออกแบบซอฟต์แวร์ (SDD) โดยทั่วไปจะอธิบายถึงการออกแบบข้อมูลของผลิตภัณฑ์ซอฟต์แวร์การออกแบบสถาปัตยกรรมการออกแบบส่วนต่อประสานและการออกแบบขั้นตอน เนื้อหาและการจัดระเบียบของ SDD ระบุโดยมาตรฐาน IEEE 1016
