ฉันควรฟังนายจ้างของฉันและใช้เครื่องมือ CASE หรือไม่

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

ฉันคิดว่าถ้าเรายึดหลักความคล่องตัวรูปแบบการออกแบบใช้ TDD และรักษาโค้ดของเราให้สะอาด เราควรจะดี และเท่าที่การวิเคราะห์และการออกแบบฉันคิดว่าไดอะแกรม UML ง่าย ๆ บนไวท์บอร์ดควรทำตามขั้นตอน เอกสารเป็นสิ่งที่ดีและสำคัญ แต่ควรทำให้น้อยที่สุดเท่าที่จะทำได้และเราไม่ควรมุ่งเน้นไปที่เอกสารและลืมรหัส นี่คือสิ่งที่ฉันคิด

ฉันถูกไหม? หรือฉันควรฟังนายจ้างของฉันและเริ่มทำการวิจัยสำหรับ CASE Tool ที่เหมาะสม?

สถานการณ์รับประกันวิธีการวิเคราะห์เพื่อการตัดสินใจ บรรทัดล่างคือ "เครื่องมือ CASE ให้คุณค่ากับธุรกิจหรือไม่" บ่อยครั้งที่ฝ่ายบริหารต้องการให้นักพัฒนาซอฟต์แวร์นำวิธีการหรือเครื่องมือมาใช้เพราะพวกเขาเคยได้ยินสิ่งที่ดีเกี่ยวกับเรื่องนี้ไม่ว่ามันจะเข้ากับกระบวนการและวัฒนธรรมขององค์กรในปัจจุบันได้ดีเพียงใด

หากนายจ้างของคุณขอให้คุณตรวจสอบเครื่องมือของ CASE ดังที่ ChrisF ชี้ให้เห็นคุณควรบังคับ (นี่เป็นปัญหาในที่ทำงานไม่ใช่การเขียนโปรแกรม) ปัจจัยบางอย่างที่จะส่งผลกระทบต่อการใช้เครื่องมือ CASE ได้แก่ :

• กระบวนการใดของคุณที่มีเครื่องมือสำหรับ CASE
• การประเมินจำนวนชั่วโมงบุคคลที่จะต้องใช้เครื่องมือใหม่
• กระบวนการจะเปลี่ยนไปอย่างไรด้วยการนำเครื่องมือใหม่มาใช้
• หรือผลกระทบเชิงบวก (หรือเชิงลบ) ชนิดใดที่สามารถวัดได้จากการใช้เครื่องมือใหม่

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

ใช่คุณควรเริ่มทำการวิจัยเครื่องมือของ CASE

1. เพราะคุณต้องการหลักฐานเพื่อสำรองการยืนยันว่าพวกเขาจะไม่ช่วย คุณไม่มีทางรู้คุณอาจพบว่าพวกเขาจะช่วย
2. เพราะนายจ้างของคุณบอกให้คุณ

ฉันจะไม่ทำซ้ำคะแนนที่วางไว้โดย David Kaczynski ในคำตอบที่ยอดเยี่ยมของเขาเพราะพวกเขาเป็นขั้นตอนที่คุณควรทำตาม

ดูเหมือนว่ากระบวนทัศน์ขนาดใหญ่จะเปลี่ยนจากการพัฒนาแบบ Agile มาเป็นแบบ CASE / MDA โดยใช้การสร้างรหัส ไม่จำเป็นต้องมาจากมุมมองการจัดการโครงการ (วิธี CASE จะไม่ขัดแย้งกับแนวคิดของการทำซ้ำเรื่องราวของผู้ใช้ข้อเสนอแนะอย่างรวดเร็วหรือการปรับปรุงอย่างต่อเนื่อง) แต่แน่นอนจากมุมมอง "ฝีมือซอฟต์แวร์" - หมายถึงการควบคุมรหัสน้อยลง ผลิต, สร้างรหัสที่อาจจะอ่านไม่ได้, แข็ง, ยากที่จะทดสอบ, ต้องการซิงค์กับตัวแบบตลอดเวลา, และอื่น ๆ

จากสิ่งที่คุณอธิบายสิ่งที่นายจ้างของคุณต้องการนั้นสามารถเข้าใจได้ง่าย:

• เอกสารที่ดีกว่าเพื่อหลีกเลี่ยงการสูญเสียความรู้หากนักพัฒนากำลังจะออกจากทีม
• กระบวนการพัฒนาที่เร็วขึ้น

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

นี่คือบทความที่น่าสนใจเกี่ยวกับเครื่องมือของ CASE ในสภาพแวดล้อมแบบ Agile และประโยชน์ / ข้อเสียที่เป็นไปได้: http://www.agilemodeling.com/essays/simpleTools.htm

นายจ้างของฉัน (ไม่ใช่นักพัฒนาซอฟต์แวร์) คิดว่าเครื่องมือของ CASE จะช่วยเราปรับปรุงกระบวนการพัฒนาและเอกสารของเรา "

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

สาเหตุที่เป็นไปได้มากที่สุดที่การแนะนำแบบนี้โดยผู้บริหารที่ไม่ใช่ด้านเทคนิคก็คือมีคนพยายามขายของบางอย่าง บริษัท ยักษ์ใหญ่แห่งหนึ่งที่ขายสิ่งเหล่านี้มีรายได้ที่ตกต่ำเหมือนเรือเหาะนำในอากาศที่หายาก พนักงานขาย (หรือที่รู้จักกันอีกครั้งคือผู้ขาย, ที่ปรึกษา) ที่ไม่ได้ย้ายไปหาสิ่งอื่นใดกำลังพยายามหาคะแนนใหม่เอ่อ ... ลูกค้า หนึ่งในเหตุผลหลักที่ บริษัท เหล่านี้กำลังดิ้นรนคือไม่มีความต้องการเครื่องมือประเภทนี้อีกต่อไป โดย 'เครื่องมือประเภทนี้' ฉันหมายถึงเครื่องมือที่สัญญาว่าจะ 'กำจัดการเขียนโค้ด' ไม่มีอะไรผิดปกติกับรหัสขึ้นอยู่กับภาษา โค้ดที่เขียนนั้นมี abstractions ที่ทรงพลังกว่าสิ่งที่เครื่องมือเหล่านี้มีให้

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

ด้วยเครื่องมือของ CASE ฉันได้ทำงานในสถานที่ต่าง ๆ สามแห่งที่เป็นเจ้าของแพ็คเกจเหล่านี้ ในทุก ๆ คนมันเป็นแบบนี้:

1. ตัวแบบถูกออกแบบมาอย่างพิถีพิถันในเครื่องมือ ใช้เวลานานกว่าปกติมากและไม่มีการส่งมอบที่ใช้งานได้จนกว่าจะถึงเวลาที่กำหนด
2. รูปแบบที่จำเป็นต้องมีการเสริมด้วยตรรกะทางธุรกิจ ตัวแบบผิดและต้องถูกปรับแต่งด้วยตนเองในช่วงระยะเวลาโครงการล่าช้าเนื่องจากความพยายามเกินกำหนด
3. การซิงค์โมเดลอีกครั้งและรหัสเป็นเครื่องมือที่ห้ามการเสียค่าใช้จ่ายดังนั้นเครื่องมือ CASE จึงถูกนำไปวางไว้ซึ่งจะไม่ถูกใช้อีกครั้ง

สรุปมันเป็นความล้มเหลวทั้งหมด 100% และเสียเงินในแต่ละกรณี เมื่อฉันพูดกับคนอื่น ๆ ที่ใช้เครื่องมือ CASE ในองค์กรอื่น ๆ เรื่องราวก็เหมือนกันเสมอ ฉันไม่ได้ใช้เครื่องมือเหล่านี้ทั้งหมดและเป็นไปได้ว่าบางคนใช้ประโยชน์ได้ดี แต่ฉันค่อนข้างแน่ใจว่าทีมส่วนใหญ่ที่ใช้พวกเขาหยุดใช้พวกเขามานานแล้ว

หนึ่งในผลประโยชน์ที่คุณจะได้รับจากการตรวจสอบ / ใช้งานเครื่องมือของ CASE คือคุณจะได้รับทักษะที่เป็นที่ต้องการของตลาดสำหรับการจ้างงานในอนาคต ฉันคิดว่าข้อกังวลของคุณมากมายเป็นสิ่งสำคัญ แต่ตามที่ David Kaczynski ชี้ว่านี่ไม่ใช่คำถามเกี่ยวกับการเขียนโปรแกรมมากเท่ากับคำถามนายจ้าง / พนักงานสัมพันธ์ ประโยชน์อีกอย่างหนึ่งของเครื่องมือ CASE คือเมื่อเรียนรู้แล้ว บริษัท ของคุณจะสามารถเข้าร่วมโครงการที่มีความซับซ้อนมากขึ้น อาจเป็นไปได้ว่าสัญญาที่นายจ้างของคุณต้องการได้รับหรือต้องการการใช้เครื่องมือ CASE

คุณกำลังผสมปญหาและวิธีแก้ปัญหาและเจ้านายของคุณกำลังพยายามช่วยเหลือด้วยความสำเร็จไม่มากก็น้อย ในการท้าทายเจ้านายของคุณคุณต้องมีบทบาทอย่างชัดเจนในองค์กรของคุณ หากเขาเป็นซีอีโอและคุณเป็น CTO การตัดสินใจก็เป็นของคุณและซีอีโอควรชี้ให้เห็นว่าประเด็นทางธุรกิจที่ได้รับผลกระทบจากการขาดเอกสารประกอบ ภาระหน้าที่ของคุณคือการแก้ไขปัญหาทางธุรกิจด้วยเครื่องมือ CASE หรือโซลูชันอื่น ๆ ที่คุณออกมา

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

เครื่องมือทางเลือกของ CASE สามารถช่วยได้เช่นกัน การวัดสิ่งต่าง ๆ เช่นวัฏจักรหรือการวัดความซับซ้อนอื่น ๆ จะทำให้การออกแบบของคุณมีโครงสร้างที่ดีและนักพัฒนาให้ความสำคัญกับรหัส ความคิดเห็นที่ดีขึ้นเกี่ยวกับโค้ดของคุณคล้ายกับ Javacode สามารถช่วยปรับปรุงเอกสารได้

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

ฉันพยายามทำให้นายจ้างของคุณตระหนักว่าเขา / เธอได้รับสิ่งต่าง ๆ ไปข้างหลัง หากมีที่ว่างสำหรับการลงทุนสำหรับทีมซอฟต์แวร์คุณควรระบุว่าปัญหาคอขวดหรือปัญหาคุณภาพของคุณคืออะไร หากปรากฎว่าคุณมีพื้นที่มากที่สุดในการปรับปรุงด้านเอกสารและกระบวนการพัฒนาคุณควรระบุว่าการเปลี่ยนแปลงใดมีผลตอบแทนการลงทุนที่ใหญ่ที่สุดในแง่ของการปรับปรุงพื้นที่เหล่านี้ นั่นอาจเป็นหรือไม่ก็ได้ที่จะเริ่มใช้เครื่องมือของ CASE

ช่วยบอสของคุณช่วยตัวเอง

คุณสามารถตอบสนองหรือดำเนินการตามคำขอนี้

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

Reframing คำถาม

หากคุณต้องการเปลี่ยนกรอบคำถามเป็นสิ่งที่ชอบ

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

การมอบหมายนี้เป็นที่พอใจมากขึ้น ช่วยเจ้านายของคุณ (และตัวคุณเอง) โดยให้ทางเลือกแก่เขาในการตรวจสอบย้อนกลับอย่างชัดเจนถึง CASE และตัวเลือกที่ใช้ Agile / open source / cloud

เยี่ยมชม CASE

ใน '90s, CASE tools อาจอยู่ในรูปของชุดเครื่องมือจาก Rational ซึ่งอาจรวมถึง Requisite Pro, Rational Rose, Clear Case, Rational Robot (นักทดสอบ), Purify, Pure Coverage และ Quantify และเครื่องมืออื่น ๆ ที่รวมเข้าด้วยกัน หากคุณเป็นร้านค้า MAD (ทางการแพทย์, Avionics, Defense) คุณอาจใช้เครื่องมือเหล่านี้รุ่นที่ปรับปรุงเพื่อผลิตเอกสารและสิ่งประดิษฐ์ที่สามารถตรวจสอบย้อนกลับได้และครอบคลุมซึ่งลูกค้ามักต้องการในตลาดเหล่านั้น

ติดต่อ IBM และรับพนักงานขายเพื่อเสนอราคาใบอนุญาตห้าใบ (หรือใบอนุญาตลอยเดียว) เพิ่มในการฝึกอบรมบางอย่างเช่นกัน การแบ่งปันคำพูดนี้กับผู้จัดการของคุณอาจสิ้นสุดการพูดคุยเกี่ยวกับเครื่องมือของ CASE แต่อย่าเข้าใจฉันผิด ฉันชอบ Rational หัวหน้านักวิทยาศาสตร์และผลิตภัณฑ์ของพวกเขา แต่ส่วนใหญ่เข้าถึงพวกเขาผ่านทางใบอนุญาตมหาวิทยาลัยเนื่องจากราคาของพวกเขาสูงเกินไปสำหรับ บริษัท ที่ฉันทำงาน หากคุณได้รับการอนุมัติอย่างน้อยจากประสบการณ์ของฉันพวกเขาจะปฏิบัติต่อสิทธิ์ของคุณด้วยการสนับสนุนที่ดีการฝึกอบรมที่มีคุณภาพ

เครื่องมือสำหรับการขาย

คุณยังมีโอกาสที่ดีในการไปช็อปปิ้งเครื่องมือ นักพัฒนา Agile ต้องการเครื่องมือเช่นกัน คุณสามารถซื้อชุดโปรแกรมที่ให้การสนับสนุนเอกสารประกอบสำหรับการ์ดเรื่องราวออนไลน์ใช้เคสกรณีใช้เคสและประเภทไดอะแกรม UML อื่น ๆ Atlassian มีสิ่งที่ฉันคิดว่าเป็นชุดเครื่องมือที่ดี - จิราสำหรับงานและการติดตามข้อผิดพลาด, Green Hopper สำหรับสิ่งที่พวกเขาอธิบายว่าเป็นการจัดการโครงการ Agile, การรวมกลุ่มสำหรับวิกิอินทราเน็ต, Crucible สำหรับการตรวจสอบรหัสออนไลน์ มีซอฟต์แวร์เป็นใบอนุญาตให้บริการสำหรับชุดเครื่องมือเหล่านี้และชุดเครื่องมืออื่น ๆ ที่ตรงกับความต้องการของคุณหากคุณเป็น Agile

การรวม IDE เป็นหนทางอื่นในการรับกรณีเทียบเท่าปี 2555 ถ้าคุณเป็นบ้านพัฒนาของ Microsoft Visual Team Studio มีเครื่องมือที่มีขอบเขตคล้ายกับสิ่งที่ Rational สร้างขึ้น พวกเขามีวิศวกรรมซอฟต์แวร์แบบไปกลับบางส่วนการสร้างส่วนทดสอบหน่วยจากคลาสการรวมเข้ากับระบบควบคุมซอร์สและเครื่องมือมากมายสำหรับการทำงานร่วมกันของทีม

เครื่องมือโอเพนซอร์ซ

ในด้านโอเพ่นซอร์ส Eclipse และปลั๊กอินจำนวนมากพยายามรวมเครื่องมือโอเพนซอร์สจำนวนมาก ฉันไม่แน่ใจว่า Eclipse Modeling Framework นั้นพัฒนาแล้วหรือมีเครื่องมืออื่น ๆ ที่ให้วิศวกรซอฟต์แวร์ไปกลับได้อย่างมีประสิทธิภาพ แต่ครั้งสุดท้ายที่ฉันดูมันก็ดูไม่สำเร็จ สภาพแวดล้อม Qt Creator ทำงานร่วมกับการควบคุมแหล่งข้อมูลและมีความสามารถบางอย่างเพื่อช่วยตรวจสอบเฉพาะจุดจากการครอบคลุมรหัสของการเปลี่ยนแปลงในขณะที่คุณอยู่ในโปรแกรมแก้ไข

การยอมรับเครื่องมือที่เพิ่มขึ้นซ้ำแล้วซ้ำอีก

วิธีการวนซ้ำ / การเพิ่มขึ้นของการเลือกเครื่องมือก็มีประสิทธิภาพมากเช่นกัน โครงการโอเพนซอร์สมักจะสนับสนุนสภาพแวดล้อมเดียวหรือหลาย ตัวเลือกเครื่องมือของคุณอาจได้รับอิทธิพลจากสแต็คที่คุณใช้ ไม่เคยมีเวลาที่ดีในการปิดการพัฒนาอย่างสมบูรณ์ดังนั้นการเพิ่มและฝึกอบรมทีมในเครื่องมือขนาดเล็กไม่กี่ต่อไตรมาสอาจจะดีกว่าวิธีการที่ยิ่งใหญ่ที่เปลี่ยนแปลงทุกอย่างในครั้งเดียว

โซลูชั่นเครื่องมือคลาวด์

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

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

สิ่งหนึ่งที่ฉันจะเพิ่มในคำตอบที่ยอดเยี่ยมที่นี่คือคุณอาจได้รับประโยชน์จากการทำความเข้าใจว่าคุณต้องการ "ปรับปรุงกระบวนการพัฒนาของคุณ" อย่างไร

แนวโน้มที่ท่วมท้นในช่วง 20 ปีที่ผ่านมาคือการพัฒนาซอฟท์แวร์ให้เหมาะสมกับเวลาในการทำตลาด "Agile", "lean", DevOps, TDD, BDD - พวกเขาทั้งหมดเกี่ยวกับการนำซอฟต์แวร์ที่มีคุณภาพออกจากประตูให้เร็วที่สุด

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

ดังนั้นอาจถามเจ้านายของคุณว่าสิ่งที่เขาพยายามเพิ่มประสิทธิภาพ

จากประสบการณ์การทำงานกับเครื่องมือ CASE อย่างรวดเร็วกลายเป็นเรื่องยากกว่าการทำงานกับรหัส - โดยเฉพาะอย่างยิ่งเมื่อทำงานกับโดเมนปัญหาที่ซับซ้อนกว่าค่าเฉลี่ย โครงการหยุดเป็นโครงการ "ธนาคาร" และกลายเป็นโครงการ "insert-name-of-CASE-tool-here" แทน