แยกการวิเคราะห์ออกจากการออกแบบ
(ตัดสินใจว่าสิ่งที่จำเป็นก่อนที่จะตัดสินใจว่าจะใช้อย่างไร)
โครงการที่ประสบความสำเร็จสามารถแก้ปัญหาทางธุรกิจได้
พิจารณาว่าคุณต้องการบรรลุวัตถุประสงค์ทางธุรกิจใดก่อนที่จะก้าวเข้าสู่เทคโนโลยี ช่วยให้คุณใช้เทคโนโลยีอย่างชาญฉลาด จัดการขอบเขตและลดต้นทุน สร้างระบบที่เหมาะกับลูกค้าของคุณ
เป็นเรื่องง่ายที่จะมีสมาธิกับคุณสมบัติทางเทคนิคของโครงการใด ๆ และมองข้ามเหตุผลของการมีอยู่ของมัน ทุกโครงการมีไว้เพื่อแก้ปัญหา ไม่ว่าสิ่งที่คุณมีจะใช้งานได้ไม่ดีพอและจำเป็นต้องปรับปรุง หรือคุณจำเป็นต้องประดิษฐ์สิ่งใหม่ทั้งหมด ท้ายที่สุด “ถ้ามันไม่พังก็อย่าซ่อม”
บ่อยครั้งที่แรงกดดันจากกำหนดเวลาและงบประมาณทำให้เราข้ามขั้นตอนที่สำคัญในการวิเคราะห์ความต้องการทางธุรกิจ และเราก็กระโดดเข้าสู่เทคโนโลยีโดยตรง แต่บ่อยครั้งที่เราพบว่าระบบไม่ได้ทำสิ่งที่จำเป็น ผู้ใช้จำเป็นต้องใช้วิธีแก้ไขปัญหาชั่วคราว ลดผลประโยชน์บางอย่างที่เราควรจะมอบให้ ซึ่งส่งผลต่อความน่าเชื่อถือของเราด้วย บ่อยเพียงใดที่เราต้องลงทุนเวลาและค่าใช้จ่ายเพิ่มเติมในการให้บริการเวอร์ชัน 2 (และ 3 และ 4 และ …) เมื่อการทำงานอย่างระมัดระวังบางอย่างอาจเปิดเผยความต้องการที่แท้จริงก่อนหน้านี้
วงจรชีวิตของน้ำตกแบบคลาสสิก
มีหลายรูปแบบใน System Development Life Cycle (SDLC) และสิ่งต่อไปนี้อาจไม่ใช่คำศัพท์เฉพาะที่วิธีการของคุณใช้ เนื้อหาของขั้นตอนต่าง ๆ นั้นเรียบง่ายอย่างแน่นอนในตารางนี้ แต่โครงการต่าง ๆ จะปฏิบัติตามขั้นตอนต่อไปนี้:
(ไม่มีภาพที่นี่ – คุณสามารถดาวน์โหลดบทความนี้พร้อมภาพประกอบได้จาก [http://www.irm.com.au/businessanalysispapers.htm]หรือชมภาพได้ที่ [http://www.irm.com.au/images/waterfallcycle.jpg])
เอาต์พุตจากแต่ละเฟสคืออินพุตถัดไป ขยะเข้าขยะออก. หรือจะพูดให้สวยหรูหน่อยก็คือทำกระเป๋าไหมจากหูแม่สุกรไม่ได้ คุณไม่สามารถนำระบบปฏิบัติการที่ดีไปใช้ได้หากไม่มีระบบที่ผ่านการทดสอบที่ดี คุณไม่สามารถสร้างระบบที่ดีได้หากปราศจากข้อกำหนดทางเทคนิคที่ดีและคุณไม่สามารถออกแบบระบบที่ดีได้หากปราศจากข้อกำหนดเฉพาะทางธุรกิจที่ดี
ตรวจสอบให้แน่ใจว่ามีการใช้บุคลากรที่มีความสามารถตั้งแต่เนิ่นๆ ในโครงการของคุณ เพื่อให้แน่ใจว่าคุณจะได้รับผลลัพธ์ที่ดีในตอนท้าย
อย่าหลอกตัวเองให้คิดว่าคุณกำลังช่วยเหลือใครด้วยการข้ามการวิเคราะห์ธุรกิจและมุ่งตรงไปที่การออกแบบ หรือโดยการรวมทั้งสองอย่างเข้าด้วยกัน หากกำหนดเวลากระชั้นชิด ให้เจรจาการดำเนินการเป็นระยะๆ หากงบประมาณจำกัด ให้ลบฟังก์ชันบางอย่างออก
การสำรวจจำนวนมาก รวมถึงงานของ Boehm ได้แสดงให้เห็นอย่างสม่ำเสมอว่าค่าใช้จ่ายในการซ่อมแซมข้อผิดพลาดเพิ่มขึ้นแบบทวีคูณภายหลังการซ่อมแซมเกิดขึ้นใน SDLC ข้อผิดพลาดซึ่งมีค่าใช้จ่าย 1 ดอลลาร์ในการซ่อมแซมในช่วง Initiate จะมีค่าใช้จ่าย 10 ดอลลาร์ในการแก้ไขหากปล่อยไว้จนกว่าจะมีการวิเคราะห์ 100 ดอลลาร์สำหรับการออกแบบ และ 1,000 ดอลลาร์หากไม่มีการดำเนินการใดๆ จนกว่าจะดำเนินการ แต่เรามักจะพูดว่า “เราจะสามารถแก้ไขได้ในรหัส” บ่อยแค่ไหน?
เครื่องมือซอฟต์แวร์ไม่สามารถคิดแทนคุณได้
เชกสเปียร์จะเป็นนักเขียนที่ดีกว่านี้หรือไม่หากเขามีโปรแกรมประมวลผลคำ
เครื่องมือใด ๆ จะเชื่อในสิ่งที่คุณบอก มีเครื่องมือที่ยอดเยี่ยมบางอย่างที่จะทำให้งานแฮ็กไร้เหตุผลของคุณหมดไป เพื่อให้คุณได้มีสมาธิกับการทำสิ่งที่คุณทำได้ดีที่สุด แต่อย่าคิดว่าถ้าคุณมีเครื่องมือที่ดีที่สุดเท่าที่จะเป็นไปได้ ระบบของคุณก็จะดีที่สุดเท่าที่จะเป็นไปได้ ถ้าคุณไม่เชื่อฉัน คว้าโปรแกรมประมวลผลคำที่คุณชอบและเขียนโคลงที่ผู้คนยินดีที่จะใช้อ้างอิงในอีก 400 ปีนับจากนี้
คุณยังต้องคิดเอง นั่นคือสิ่งที่เกี่ยวกับการวิเคราะห์ธุรกิจ
แยกการวิเคราะห์ธุรกิจออกจากการออกแบบทางเทคนิค
การวิเคราะห์ธุรกิจคือการคิดว่าโซลูชันของคุณควรทำอย่างไร ในขณะที่การออกแบบคือวิธีการทำให้เกิดขึ้นโดยใช้เทคโนโลยีที่มีอยู่ การคำนึงถึงสิ่งนี้จะช่วยให้หลีกเลี่ยงการผสมสองขั้นตอนนี้ได้ง่ายขึ้น อะไร และ ยังไง. สิ่งนี้จะช่วยให้คุณสร้างระบบที่แข็งแกร่งยิ่งขึ้น
สิ่งที่ธุรกิจของคุณไม่เปลี่ยนแปลงมากเท่ากับวิธีการทำ เทคโนโลยีเปลี่ยนแปลงเร็วกว่าความต้องการของธุรกิจ การปรับโครงสร้างบริษัท แต่สิ่งที่พวกเขาทำนั้นไม่ได้เปลี่ยนแปลง อยู่ที่ว่าแต่ละคนทำมันอย่างไร การวิเคราะห์ธุรกิจให้มุมมองเชิงตรรกะของความต้องการด้านกระบวนการและข้อมูล และไม่ถูกผูกมัดโดยการใช้งานทางกายภาพ
ผู้เชี่ยวชาญด้านไอทีและผู้ใช้ทางธุรกิจมักจะบ่นเกี่ยวกับความเข้าใจผิดของพวกเขา แน่นอนว่าพวกเขาไม่เข้าใจกัน บุคลากรทางเทคนิคเกี่ยวข้องกับการใช้เทคโนโลยีของตนให้เกิดประโยชน์สูงสุด ผู้ใช้กังวลกับการบรรลุเป้าหมายทางธุรกิจของตน การวิเคราะห์ธุรกิจควรเชื่อมช่องว่างอย่างเรียบร้อย
ข้อกำหนดในการอ้างอิงที่สร้างขึ้นในช่วงเริ่มต้นควรรวมถึงปัญหาที่ต้องแก้ไข วัตถุประสงค์ที่จะบรรลุเพื่อแก้ปัญหานั้น ข้อ จำกัด และขอบเขตอย่างชัดเจน
วัตถุประสงค์ของการวิเคราะห์ธุรกิจคือ:
เทคนิคการวิเคราะห์ธุรกิจ
ในการขุดลึกปัญหาและหาทางออก มีการใช้เทคนิคมากมายซึ่งอยู่นอกเหนือขอบเขตของบทความนี้ ซึ่งรวมถึงการสัมภาษณ์ที่มีโครงสร้างอย่างระมัดระวัง การรวบรวมเอกสาร การระดมสมอง การวิเคราะห์ความเสี่ยง การวิเคราะห์ต้นทุน-ผลประโยชน์ และอื่นๆ อีกมากมาย
เครื่องมือวิเคราะห์ธุรกิจ
เครื่องมือสี่อย่างที่จำเป็นสำหรับการวิเคราะห์: สองเครื่องมือสำหรับกระบวนการและสองเครื่องมือสำหรับข้อมูล
สำหรับกระบวนการ ไดอะแกรมกระแสข้อมูล (DFD) จะแสดงกระบวนการทางธุรกิจในระบบและการเชื่อมต่อระหว่างกัน ในขณะที่ข้อมูลจำเพาะทางธุรกิจจะแสดงกฎทางธุรกิจสำหรับแต่ละกระบวนการ สำหรับข้อมูล ไดอะแกรมความสัมพันธ์ของเอนทิตี (ER Diagram) แสดงสิ่งที่จำเป็นต้องจัดเก็บจากมุมมองทางธุรกิจ และพจนานุกรมข้อมูลให้รายละเอียดเกี่ยวกับรายการเฉพาะ (ฟิลด์) ที่จำเป็นสำหรับแต่ละเอนทิตีและการเชื่อมต่อกับโฟลว์ข้อมูลบน DFD
จุดประสงค์ของเอกสารนี้ไม่ใช่เพื่อแสดงวิธีการสร้างแบบจำลองเหล่านี้ แต่เพื่อแสดงให้เห็นถึงความสำคัญของการใช้งานในรูปแบบธุรกิจมากกว่าแบบจำลองทางเทคนิค
คนโง่ทุกคนสามารถวาดแผนภาพ ER ได้
นี่เป็นเรื่องจริง แต่คุณภาพของโมเดลผลลัพธ์มักไม่เป็นที่ต้องการมากนัก สะท้อนความต้องการทางธุรกิจในรูปแบบและไม่ปล่อยให้โอกาส ระวังสิ่งต่างๆ เช่น ความสัมพันธ์และรายการข้อมูลที่จำเป็นและเป็นทางเลือก เนื่องจากระบบขั้นสุดท้ายของคุณต้องตอบสนองความต้องการทางธุรกิจได้ 100% ไม่ใช่เหตุการณ์ที่เป็นไปได้มากที่สุด อย่าพยายามรวมข้อกำหนดด้านข้อมูลธุรกิจด้านการจัดทำเอกสารเข้ากับการออกแบบฐานข้อมูล
หากรูปแบบธุรกิจถูกต้อง การออกแบบจะง่ายต่อการผลิต และสามารถปรับเปลี่ยนได้ง่ายตามความต้องการทางธุรกิจและเทคโนโลยีใหม่
เหตุใดแผนภาพกระแสข้อมูลจึงดีกว่าลำดับชั้นของฟังก์ชัน
ลำดับชั้นของฟังก์ชันแสดงฟังก์ชันหลักในระบบและเจาะลึกรายละเอียด แต่ไม่แสดงความต้องการข้อมูลสำหรับกระบวนการเหล่านั้น เป็นเรื่องง่ายมากที่จะละเว้นกระบวนการระดับล่างโดยไม่ตั้งใจ ลำดับชั้นของฟังก์ชันจะไม่ชัดเจนในทันทีสำหรับผู้ใช้ที่ต้องการตรวจสอบความถูกต้องของแบบจำลองของคุณอีกครั้ง
ไดอะแกรมโฟลว์ข้อมูลแสดงฟังก์ชันหลักและการเจาะลึกในทำนองเดียวกัน แต่เนื่องจากโฟลว์ข้อมูลทำหน้าที่เป็น “กาว” ซึ่งยึดกระบวนการต่างๆ ไว้ด้วยกัน จึงเป็นเรื่องง่ายที่จะสร้างไดอะแกรมดังกล่าวโดยร่วมมือกับตัวแทนทางธุรกิจ “คุณต้องการข้อมูลอะไรในการดำเนินการนี้? มันมาจากไหน? ผลิตข้อมูลอะไร มันไปอยู่ที่ไหน” ด้วยวิธีนี้ กระบวนการแต่ละอย่างจะค่อยๆ เพิ่มเข้าไปในโมเดลและจะไม่มีอะไรพลาด สามารถเจาะลึกกระบวนการที่ซับซ้อนและสามารถจัดกลุ่มกระบวนการที่เกี่ยวข้องเข้าด้วยกันได้
ไดอะแกรมกระแสข้อมูลขนาดใหญ่อ่านยากและดูแลรักษายาก ดังนั้นจึงสูญเสียประสิทธิภาพในฐานะเครื่องมือสื่อสารกับทั้งผู้ใช้ทางธุรกิจและทีมเทคนิค แทนที่จะมีกระบวนการเจ็ดกระบวนการต่อไดอะแกรมและเจาะลึกไปยังไดอะแกรมที่มีรายละเอียดมากขึ้น ด้วยระบบตัวเลขสำหรับการอ้างอิงโยง ตัวอย่างเช่น รายละเอียดของกระบวนการที่ 3 จะมีหมายเลข 3.1, 3.2, 3.3 เป็นต้น และจะปรากฏในแผนภาพหมายเลข 3 จากนั้นสามารถใช้แผนภาพระดับสูงสำหรับการหารือกับผู้บริหาร และแผนภาพระดับล่างสามารถใช้สำหรับการตรวจสอบซ้ำโดยละเอียด กับผู้ใช้ที่เชี่ยวชาญในด้านนั้น ขณะนี้ลำดับชั้นของฟังก์ชันมีอยู่โดยอัตโนมัติ ไม่จำเป็นต้องวาดแยกต่างหาก
นักวิเคราะห์หลายคนชอบใช้แบบจำลองกระบวนการซึ่งรวมถึง “ช่องทางว่ายน้ำ” เพื่อระบุว่าใครเป็นผู้ดำเนินการแต่ละขั้นตอน นี่เป็นเพียงแผนภาพกระแสข้อมูลในรูปแบบอื่น การเริ่มต้นวิเคราะห์โดยใช้ไดอะแกรมดังกล่าวเป็นเรื่องปกติ แต่เมื่อสิ้นสุดการวิเคราะห์ เส้นทางว่ายน้ำควรจะหายไป เนื่องจากแบบจำลองของคุณควรมีความยืดหยุ่นเพียงพอที่จะอยู่รอดจากการปรับโครงสร้างในธุรกิจ คุณกำลังบันทึกสิ่งที่ต้องทำ ไม่ใช่ใครทำหรืออย่างไร
ควรระบุโฟลว์ข้อมูลด้วยเนื้อหาโดยละเอียดในพจนานุกรมข้อมูล เช่นเดียวกับที่เก็บข้อมูล ไดอะแกรมโฟลว์ข้อมูลจะค่อยๆ ช่วยสร้างโมเดลข้อมูล เพื่อให้คำจำกัดความข้อมูลของคุณสนับสนุนกระบวนการต่างๆ
รวมกระบวนการทั้งหมดในไดอะแกรมกระแสข้อมูล แม้แต่กระบวนการที่ดูไม่สำคัญ ฉันได้ยินเกี่ยวกับโครงการเมื่อเร็วๆ นี้ซึ่งตกหลุมพรางของ “การรายงานเป็นเรื่องง่าย เราจะปล่อยไว้จนกว่าจะสิ้นสุด” ในขณะที่สร้าง ข้อมูลที่จำเป็นสำหรับรายงานไม่สามารถเข้าถึงได้
หลายรุ่นของรุ่น
จัดทำเอกสารระบบที่มีอยู่ก่อน รวมถึงข้อผิดพลาดทั้งหมดโดยไม่มีการปรับปรุงเพิ่มเติม สาเหตุของปัญหาอยู่ในนั้นและคุณไม่ควรด่วนสรุปเกี่ยวกับวิธีที่ดีที่สุดในการแก้ปัญหา
ลบวิธีการออกจากแบบจำลองทางกายภาพปัจจุบัน โดยให้แบบจำลองทางตรรกะปัจจุบัน จากนั้นหาวิธีที่ดีที่สุดในการแก้ปัญหาและรวมถึงข้อกำหนดใหม่ สิ่งนี้ทำให้โมเดลตรรกะใหม่พร้อมสำหรับการออกแบบ
ในบางกรณี ปัญหาสามารถแก้ไขได้โดยเพียงแค่จัดรูปแบบการทำงานใหม่ ประหยัดค่าใช้จ่ายที่ไม่จำเป็นในการออกแบบ สิ่งนี้ทำให้ทีมเทคนิคตกงานหรือไม่? ไม่เลย. พวกเขาสามารถปล่อยให้ใช้ความเชี่ยวชาญของพวกเขาที่จะสร้างความแตกต่างมากที่สุดในโครงการอื่น ๆ
การเขียนข้อมูลจำเพาะ
อย่าเขียนข้อกำหนดเดียวขนาดใหญ่ มันจะผิดเพราะคุณจะพลาดรายละเอียดบางอย่างและจะไม่สามารถแก้ไขได้ง่าย และไม่มีใครจะสามารถจดจำสิ่งทั้งหมดได้ แทนที่จะเขียนข้อมูลจำเพาะเดียวสำหรับแต่ละกระบวนการโดยละเอียด – “mini-spec” แต่ละรายการสามารถตรวจสอบซ้ำกับผู้เชี่ยวชาญทางธุรกิจที่เหมาะสมได้ คอลเลกชันของข้อมูลจำเพาะขนาดเล็กเหล่านี้เป็นข้อมูลจำเพาะของคุณสำหรับระบบทั้งหมด แต่ละตัวง่ายต่อการบำรุงรักษาโดยไม่กระทบกับสเปคที่เหลือ
ข้อมูลจำเพาะไม่ควรรวมถึงข้อมูลทางเทคนิคใด ๆ – เพียงแค่กฎทางธุรกิจจากกระบวนการนั้น ทีมออกแบบสามารถหาวิธีที่ดีที่สุดในการทำให้มันเกิดขึ้น
อะไรที่จะทำให้อัตโนมัติ?
การดูไดอะแกรมโฟลว์ข้อมูลกับตัวแทนธุรกิจและทีมเทคนิคจะช่วยให้คุณสามารถตัดสินใจเลือกการใช้งานที่ดีที่สุดได้ ขึ้นอยู่กับปัจจัยต่างๆ เช่น อะไรเป็นที่ยอมรับของธุรกิจ อะไรที่เป็นไปได้ทางเทคนิค อะไรที่เหมาะกับข้อจำกัดของงบประมาณและเวลา
คุณอาจตัดสินใจเลือกระบบอัตโนมัติทั้งหมด ระบบอัตโนมัติบางส่วน การใช้งานแบบแบ่งช่วง หรือแนวคิดดีๆ อื่นๆ จากนั้นส่งมอบให้กับทีมออกแบบ
ผสมผสานการวิเคราะห์และการออกแบบ
อย่าทำเด็ดขาด คุณกำลังบันทึกอะไร