ผู้จัดการที่ไม่ใช่ฝ่ายไอทีควรรักษาความปลอดภัยในการบำรุงรักษาและการพัฒนาซอฟต์แวร์ระยะยาวที่สำคัญได้อย่างไร


13

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

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

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

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

กล่าวโดยย่อในฐานะผู้จัดการที่ไม่ใช่ฝ่ายไอทีเราจะจัดการการเปลี่ยนแปลงนี้ได้อย่างไร


6
อุ๊ย! พื้นฐานและภาษาโคบอล?! ฉันจะลองบ้านพักคนชรา คุณเคยคิดว่า "ทันสมัย" ซอฟต์แวร์ของคุณหรือไม่
BЈовић

2
เพียงแค่เพิ่ม: อาชีพการผลิตที่คุ้มค่าส่วนหนึ่งในภาษาเก่าที่ไม่เซ็กซี่เช่น BASIC - พื้นฐานและการทำงานที่มีประโยชน์และมีประสิทธิผลไม่ได้รวมอยู่ในประโยคเดียว
BЈовић

3
มีผู้รับเหมาและที่ปรึกษาจำนวนมากที่โอนย้ายซอฟต์แวร์จากระบบดั้งเดิม อย่างไรก็ตามโคบอลและพื้นฐานไม่ใช่มรดกตกทอดมาก่อนประวัติศาสตร์ แม้ว่ามันจะค่อนข้างแปลกที่จะจ้างใครบางคน แต่มันก็เจ๋งในแบบแฮ็กเกอร์ทันสมัย
NimChimpsky

3
ฉันจะเห็นด้วยกับ @ BЈовићในรายการนี้ คุณควรพิจารณาปรับปรุงซอฟต์แวร์ของคุณให้ทันสมัยแทนที่จะพยายามค้นหาสิ่งมีชีวิตที่มีความเก่าแก่อย่าง BASIC และ COBOL เพื่อการพิสูจน์ในอนาคตอย่างน้อย สำหรับตอนนี้คุณอาจพบว่าเนียร์หรือเด็กฮิปสเตอร์ที่สามารถเขียนโค้ดให้คุณได้ แต่เมื่อเวลาผ่านไปและการเปลี่ยนกระบวนทัศน์พรสวรรค์เหล่านี้จะกลายเป็นสัตว์ใกล้สูญพันธุ์ซึ่งจะทำให้ระบบของคุณช้าและมั่นคง ข้อเท็จจริงที่ว่าคุณแทบจะไม่สามารถหาโปรแกรมเมอร์ได้ในขณะนี้ควรเป็นธงสีแดงซึ่งเกี่ยวกับเวลาสำหรับการเปลี่ยนแปลง
Maru

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

คำตอบ:


11

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

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

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

อ่าน "วิธีเอาตัวรอดโดยไม่ต้องสูญเสียสติ"

อย่าทำให้ข้อผิดพลาดของโครงการการโอนย้ายข้อมูลที่ยาวนานโดยไม่มีผลลัพธ์จริงเป็นเวลานาน อ่าน"วิธีเอาตัวรอดโดยไม่ต้องสูญเสียสติ"

ฉันไม่สามารถความเครียดได้มากพอว่าคำแนะนำในบทความนั้นช่วยฉันในการแก้ปัญหา / เข้าถึงปัญหาที่คล้ายกันอย่างไรหลังจากที่เผาไหม้ตัวฉันเองที่ทำโครงการประเภทนั้นในแบบ "เก่า"

ตั้งค่าการทดสอบอัตโนมัติ

หากคุณยังไม่ได้ติดตั้งไว้ (ทำไมไม่ทำอย่างนั้น) ให้โปรแกรมเมอร์ปัจจุบันของคุณสร้างเครื่องทดสอบอัตโนมัติสำหรับแอปพลิเคชันของคุณ

ชุดทดสอบอัตโนมัติควรครอบคลุมทุกหน้าที่การใช้งานของแอปพลิเคชันของคุณ มัน / จะเอกสารข้อกำหนดการทำงานปัจจุบันในกฎ "when_X_then_Y" ของแต่ละกรณีทดสอบ สิ่งนี้จะช่วยทั้งในการเปลี่ยนแปลงรหัสปัจจุบันของคุณจากการทำลายฟังก์ชันการทำงานที่มีอยู่ตลอดจนสนับสนุนการโยกย้ายไปยังสภาพแวดล้อมใหม่

ในขณะที่คุณจัดการกับ COBOL และ BASIC ชุดทดสอบน่าจะอยู่ในระดับของการทดสอบการรวม: การทำงานชุด "คงที่" ของไฟล์อินพุต / ฐานข้อมูลและตรวจสอบไฟล์เอาต์พุต / เนื้อหาฐานข้อมูลที่เปลี่ยนแปลงของโปรแกรมเฉพาะ (COBOL) และ / หรือแอปพลิเคชัน สำหรับส่วนพื้นฐานของซอฟต์แวร์ของคุณอาจหมายถึงการเพิ่มพารามิเตอร์บรรทัดคำสั่งเพื่อให้พวกเขาออกกำลังกายบางฟังก์ชั่นโดยไม่ต้องมีการแทรกแซง (G) UI หรือรับเครื่องมือทดสอบอัตโนมัติที่ใช้ (G) UI

แยกการคำนวณและอัลกอริธึมอื่น ๆ

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

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

เริ่มชุดแอปพลิเคชันใหม่ในสภาพแวดล้อม "ปัจจุบัน"

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

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

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

อย่าไปต่อที่การตั้งค่าแอพพลิเคชั่นและอาจตั้งค่าฟังก์ชั่นอินพุต / เอาท์พุตที่สำคัญที่สุดเพียงตัวเดียวที่ใช้การคำนวณจาก "ไลบรารี" COBOL / BASIC ของคุณ

รวม "คลัง" ของ COBOL / BASIC ของคุณ

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

ใช้คลาสในสภาพแวดล้อมใหม่ของคุณที่จะเรียก COBOL / BASIC "ไลบรารี่" และทดสอบ heck โดยใช้การทดสอบเดียวกันที่อยู่ในการทดสอบการใช้งานของสภาพแวดล้อมแบบเก่า แต่ตอนนี้อยู่ในรูปแบบของการทดสอบหน่วยในสภาพแวดล้อมใหม่ .

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

แต่อีกครั้ง: อย่าไปยิ่งกว่าการเพิ่มการทดสอบหน่วยสำหรับการคำนวณที่ใช้โดยสิ่งที่สำคัญที่สุดเพียงอย่างเดียวจากขั้นตอนก่อนหน้า

ค้นหาแอพพลิเคชั่นใหม่ในการวนซ้ำ

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

โอนย้ายไลบรารีหลักในการวนซ้ำ

และในที่สุดโยกย้ายการคำนวณและอัลกอริทึมใน COBOL / BASIC "ไลบรารี่" ของคุณและนำมันไปใช้ในสภาพแวดล้อมใหม่ของคุณ อีกครั้งให้ทำเช่นนี้ซ้ำ ๆ โดยใช้การทดสอบ (หน่วย) เป็นวิธีการรักษาสติของคุณ


1
ในขณะที่คำตอบของคุณดีเมื่อเห็นด้วยตัวเอง แต่น่าเสียดายที่ไม่ได้มุ่งเน้นไปที่คำถาม ผู้ถามเป็นผู้จัดการที่ไม่ใช่ฝ่ายไอทีซึ่งค่อนข้างจะไม่รู้ว่าคุณหมายถึงอะไรกับสิ่งที่คุณเขียน เขาต้องการคำแนะนำในการหาคนที่ทำ
Philipp

1
@ ฟิลิป: เห็นดีแม้ว่าฉันจะบอกว่าฉันไม่ได้ตอบคำถามจริงของเขา ฉันมั่นใจว่า OP รู้วิธีใช้ Google และมีคำค้นหาเพียงพอในคำตอบของฉันสำหรับ OP เพื่อเริ่มการวิจัย - หรือดีกว่า - ให้โปรแกรมเมอร์ปัจจุบันทำเช่นนั้น อย่าลังเลที่จะเพิ่มคำตอบของคุณเองที่อยู่ OP เพราะคุณคิดว่ามันจะต้องทำ Heck แม้อาจ upvote ถ้าคุณไม่ ...
Marjan Venema

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

@MarjanVenema (ฉันไม่ทราบว่าสิ่งที่ฉันคาดหวังเมื่อฉันโพสต์คำถามนี้ แต่สิ่งหนึ่งที่ฉันไม่ได้คาดหวังคือว่าเกือบทุกความคิดเห็นจะมีน้ำใจและมีประโยชน์ - หลายคนคิดว่าทั้งหมด) ฉันอ่านคำแนะนำของคุณ " ทำอย่างไรจึงจะอยู่รอดได้ "โพสต์โดย Milstein และโพสต์สกี้โพสต์ที่เขาตอบสนองและไม่แม้แต่มิลสไตน์ก็ชอบแนวคิดของการเขียนโค้ดซ้ำ จากประสบการณ์ของเราจนถึงขณะนี้ความคิดเห็นของ Spolsky เกี่ยวกับภัยของการย้ายข้อมูลและคุณค่าของรหัสการทำงานที่แท้จริง ฉันเป็นห่วงอย่างแน่นอนว่าฉันจำนนต่อความคิดนึกคิด แต่ฉันต้องการคิดว่า Ramhound ถูกต้องจริง ๆ
user105977

1
@ user105977: ฉันเข้าใจ ใช่การเขียนใหม่นั้นมีความเสี่ยง แต่ไม่สามารถหลีกเลี่ยงได้เสมอไปและบางครั้งก็เป็นวิธีที่ดีที่สุดแม้ว่าจะมีความเสี่ยงก็ตาม สำหรับฉันการรักษาระบบเดิมโดยอาศัยชุดทักษะที่แม้ตอนนี้ยังไม่พร้อมใช้งานอย่างแน่นอนเป็นความเสี่ยงทางธุรกิจที่อาจสูงกว่าความเสี่ยงของการเขียนซ้ำและเพิ่มขึ้นตามเวลาเนื่องจากกลุ่มนักพัฒนาที่มีอยู่ลดลง แต่ฉันไม่ได้อยู่ในตำแหน่งของคุณและไม่สามารถตัดสินความเสี่ยงของญาติ
Marjan Venema

2

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

คุณพูดถึงเรื่องนี้ น่าเสียดายที่คุณได้ใช้เวลานานในการอัปเดตเทคโนโลยีของคุณนี่เป็นงานที่ยากมาก

ฉันอยากจะแนะนำหนึ่งในสองเส้นทาง

  1. เจ้าหน้าที่กลุ่มนักพัฒนา / ผู้จัดการโครงการ / QE / การดำเนินงานด้านไอทีและสร้างระบบของคุณเพิ่มขึ้นตามที่ระบุไว้ในคำตอบทางเทคนิคด้านบน อย่างไรก็ตามสิ่งนี้จะมีราคาแพงเป็นพิเศษ
  2. แทนที่จะเป็นผู้ให้บริการชั้นวางของให้มองหาที่ปรึกษาด้านการพัฒนาที่กำหนดเองที่มีคุณสมบัติเหมาะสม กลุ่มนี้จะจัดการทรัพยากรทั้งหมดเพื่อสร้างระบบใหม่ของคุณจากนั้นคุณสามารถนำมันมาไว้ในบ้านพร้อมกับพนักงานตัวเล็กกว่าตัวเลือก 1 เพื่อดำเนินการต่อ ตัวเลือกนี้มีความเสี่ยงที่แตกต่างกันอย่างไรก็ตามการเลือกผู้ให้บริการที่ดีอาจเป็นเรื่องยากสำหรับผู้ที่ไม่ใช่ด้านเทคนิค พวกเขายังมีความเสี่ยงสูงมากด้วยค่าใช้จ่ายที่มากเกินความจำเป็น ฯลฯ เพื่อลดเส้นทางนี้ใช้พนักงานที่มีอยู่ของคุณเพื่อสร้างชุดข้อกำหนดที่ละเอียดมาก (จากมุมมองของผู้ใช้) สำหรับการเสนอราคาของคุณ จากนั้นขอเสนอราคาคงที่เช่นกัน

ขอให้โชคดีคุณมีมรดกที่จะเอาชนะได้ประมาณ 20 ปี มันจะไม่ถูกง่ายหรือสะอาด


1
FYI: 20 ปีในโลกของซอฟต์แวร์เทียบเท่ากับมนุษย์ 2 หรือ 3 คน มันเป็นเวลานานมาก จากมุมมองทางเทคโนโลยี BASIC และ COBOL นั้นแก่พอที่จะใส่ในพิพิธภัณฑ์ ...
Radu Murzea

ตอนนี้ฉันได้เขียนโปรแกรมมา 20 ปีแล้วและ COBOL ถือกำเนิดประสบการณ์ของฉันไม่น้อย
Bill Leeper

-2

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

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


1
ย่อหน้าที่สองระบุว่าพวกเขาได้ทำสิ่งที่คุณแนะนำแล้ว: พวกเขาได้ระบุทั้งสาม บริษัท ที่จัดหาซอฟต์แวร์การจัดการผลประโยชน์ พวกเขาไม่มีคุณสมบัติ
MSalters

ผมไม่แนะนำให้พวกเขาได้พบกับ บริษัท เพื่อให้ซอฟต์แวร์ค่อนข้างบริการของระบบผลประโยชน์อย่างต่อเนื่องการบริหาร
เครื่องหมายประสิทธิภาพสูง
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.