สำหรับเนื้อหาในตอนนี้ก็ต่อมาจากตอนที่ 1 ซึ่งเราจะสร้างโรงงานกัน สำหรับโรงงานผลิตซอฟต์แวร์ (Software Factory) จะประกอบด้วยองค์ประกอบดังนี้

1.       สถานที่ อาจจะไม่พูดถึงมากนัก ตอนนี้เราใช้ชุมชนของ Great Friends เป็นสถานที่ไปก่อน (คิดว่า อ.สุเทพให้ใช้นะครับ) แต่ในอนาคต ถ้าเราจะพัฒนาซอฟต์แวร์ต้นแบบ ก็อาจจะต้องมีเรื่อง Software Development Environment เข้ามาเกี่ยวข้อง ซึ่งต่อไปจะสร้างเป็นรูปแบบใดค่อยว่ากันไป (ถ้ามันเกิดขึ้นได้) และผู้ที่ทำงานก็สามารถทำงานอยู่ที่ใดก็ได้โดยผ่านอินเตอร์เน็ต เพื่อใช้เวลาว่างให้เป็นประโยชน์ (สำหรับท่านที่ยังมีภาระทำงานประจำอยู่)

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

2.1    Project Sponsor หรือผู้ให้การสนับสนุน สำหรับตรงนี้ผมว่านอกจาก อ.สุเทพ ซึ่งเป็นผู้ก่อตั้งชุมชนนี้ ทุกท่านที่ร่วมในโครงการเป็น Project Sponsor ได้ครับ เพราะว่าอะไร ก็เพราะว่าเราทำงานโดยไม่ต้องใช้เงินทุนจากคนอื่น เราทำงานโดยใช้เงินทุนของพวกเรากันเอง นั่นคือเวลาที่มาร่วมทำงาน หลายคนอาจจะงงว่า เราจะทำอะไร ในตอนเริ่มต้นคงยังไม่มีอะไรมากก็คงเป็นสนามฝึกให้คนในชุมชนเข้าใจการทำแอพพลิเคชั่นแบบซอฟต์แวร์โรงงานนั่นเอง (ถ้าพวกเราเห็นด้วยนะครับ ผมแค่เสนอแนวคิดเข้าไป) แล้วต่อไปค่อยว่ากันว่าพวกเราจะทำอะไรต่อสำหรับชุมชนเรา เนื่องจากการทำซอฟต์แวร์โรงงาน ต้องใช้ทีมงานที่มีความรู้ความสามารถเฉพาะด้านในเรื่องต่างๆ มาทำงานร่วมกัน ภายใต้จุดมุ่งหมายเดียวกัน และทุกคนก็เป็นเจ้าของร่วมกัน (ดีไหมครับ)  เอ ฟังดูจะทำได้อย่างไร ก็มาร่วมออกความคิดกันก้ได้ครับ นอกจากนั้นผมอยากให้ทาง บริษัทไมโครซอฟต์เข้ามาสนับสนุนด้วย เพราะว่าเขาเป็นเจ้าของเทคโนโลยี และเราก็เอาเทคโนโลยีเขามาใช้ร่วมกันเป็น Total Solution จะให้เป็นตังค์ หรือให้เป็นเครื่องมือก็ได้ครับ หรือท่านสมาชิกท่านใดที่มีเงินเหลือเยอะและไม่รู้จะเอาไปทำอะไรก็บริจากก็ได้ครับ (อ.สุเทพรับหรือเปล่าผมไม่ทราบ แต่ อ.อาจจะบอกว่าให้มาลงทะเบียนเรียนก็แล้วกัน ไม่อยากได้เงินเปล่าๆ)

2.2    ทีมพัฒนา สำหรับทีมงานนั้นจะมีบทบาทและความรับผิดชอบดังรูปดังนี้ครับ

  รูปแสดงโครงสร้างของทีมงาน

2.1.1           Project Manager (PM) ทำหน้าที่บริหารจัดการโครงการ เพื่อให้งานสำเร็จอยู่ภายในเวลาและค่าใช้จ่ายที่กำหนด

2.1.2           Business Analyst ทำหน้าที่วิเคราะห์ความต้องการของระบบงาน ซึ่ง BA จะต้องมีความรู้ดีในเรื่อง Business Process ของงานที่กำลังทำอยู่ ซึ่งที่จริงแล้วจะต้องรู้ดีมากว่าผู้ใช้เพราะว่าผ่านงานมาหลายหลากและจะต้องแนะนำผู้ใช้และปรับปรุงกระบวนการทำงานของผู้ใช้ได้ ไม่ใช่ไปรับฟังผู้ใช้งาน และทำกระบวนการตามผู้ใช้กำหนดอย่างเดียว ถ้าเป็นอย่างนี้เราจะเรียกว่า System Analyst มือใหม่หัดขับครับ

2.1.3           Software Architect ทำหน้าที่ออกแบบโครงสร้างของระบบงาน (Framework) และจัดทำรูปแบบการพัฒนามาตรฐาน (Patterns and Standard Guideline) และเครื่องมืออื่นๆ ให้ Developer ไว้ใช้งาน ซึ่ง Software Architect นั้นจะต้องมีความรู้ดีในเรื่อง OOAD/OOP และ Development Patterns รักเทคนิคเป็นชีวิตจิตใจ Software Architect จะไม่ชอบไปวิเคราะห์ระบบมากนัก ทำได้ครับแต่ให้เลือกไม่เอาดีกว่า พูดแล้วเหมือนทำนายดวงคนราศี Software Architect เลยครับ เพราะว่าผมก็คนราศีนี้เหมือนกัน (ผู้เขียนเคยเรียนวิชาโหราศาสตร์มาแต่ไม่มีเวลาศึกษาเพิ่มเติม แค่ติดตามเทคโนโลยีให้ทันไมโครซอฟต์ก็แย่แล้ว) นอกจากนั้นสำหรับการออกแบบที่เป็น Software Factory นั้น Software Architect จะคอยทำหน้าที่สร้างชิ้นงานที่เป็น Simi-Part และกำหนดสเปกเพื่อให้สามารถนำมาประกอบกัน (Assembly) ให้ได้เป็นชิ้นงานสำเร็จ รวมถึงจัดทำคู่มือการทำงานของไลน์ผลิตต่าง ๆ ฝึกอบรมการใช้งาน แก้ไขปัญหาที่เกิดขึ้นที่เกี่ยวกับงานนั้น รวมถึงปรับปรุงกระบวนการให้ดีขึ้น

2.1.4           ต่อไปเป็น System Analyst (SA) ซึ่งทำหน้าที่เป็นนักวิเคราะห์ระบบ  เก็บรวบรวมความต้องการลูกค้า จัดทำ Requirement Specification และควบคุมการเปลี่ยนแปลงความต้องการเพื่อไม่ให้กระทบกับแผนงานหลักมากนัก สำหรับ Software Architect นั้น (ผู้เขียนไม่รู้จะใช้ตัวย่ออะไรเนื่องจากเหมือนกับ SA ถ้าใครอยากตั้งตัวย่อก็เชิญครับ) และนอกจากนั้น SA ก็จะต้องเข้ามาออกแบบระบบโดยจะต้องทำงานร่วมกันกับ Software Architect ซึ่งในส่วนตัวผมมองว่า SA จะออกแบบในเชิง High Level Design เพื่อให้ครอบคลุมความต้องการของลูกค้าเพราะว่ารู้ความต้องการของลูกค้าได้ดีกว่า ส่วน Software Architect นั้นจะออกแบบในเชิงรายละเอียด โดยรับอินพุตมาจาก SA (SA และ Software Architect อาจเป็นคนเดียวกันได้ครับเพราะผมพูดถึงบทบาท (Role) คนหนึ่งคนทำได้หลาย Role ครับ) และจะต้องให้ SA คอยทบทวน (Review) ว่าสิ่งที่ได้ออกแบบตอบสนองต่อความต้องการลูกค้าได้ทั้งหมดหรือไม่ ดังนั้น SA, Software Architect และ PM จะคอยตรวจสอบการออกแบบระบบงานก่อนที่จะเข้าไปสู่กระบวนการผลิตจริง เพราะว่าถ้าเข้าสู่กระบวนการผลิตแล้ว มีการเปลี่ยนแปลงการออกแบบนั่นคือหายนะครับ เพราะว่าจะทำให้ต้นทุนสูงขึ้นอย่างมหาศาล

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

2.1.6           สำหรับ Developer นั้นจะทำหน้าที่พัฒนางานตามสเปกที่ได้ออกแบบมาจาก SA โดยโครงสร้างแล้วกลุ่ม Developer จะถูกแบ่งออกเป็นกลุ่มย่อย ๆ ซึ่งในภาษาโรงงานจะเรียกว่าไลน์การผลิตนั่นเอง อ้อลืมไป ในส่วน Software Architect นั้นก็จะแบ่งออกเป็นกลุ่มๆ เหมือนๆ กันคือหัวหน้าทีมดูแลทั้งหมด และทีมต่าง ๆ ที่ทำหน้าที่ออกแบบส่วนต่าง ๆ (โดยธรรมชาติแล้ว Software Architect ในกลุ่มต่าง ๆ ก็เติมโตมาจาก Developer นั่นเอง) และการแบ่งออกเป็นกลุ่มๆ นี้ในทางปฏิบัติเป็นเรื่องที่ทำได้ไม่ยากแล้วครับมีเครื่องมือสนับสนุน (ไม่ใช่ว่าผมจะเอาแนวคิดสวยหรูมาแสดงให้ดูเท่ แต่มันปฏิบ้ติได้จริงซึ่งผมจะได้อธิบายต่อไป) โดยจะแบ่งเป็นกลุ่มๆ ดังนี้

-        นักพัฒนาวิศวกรรมหน้าจอ (Screen Engineer) ซึ่งการพัฒนาหน้าจอนี้ในปัจจุบันนับว่าเป็นงานที่มีความซับซ้อนมาก และผู้ใช้จะยอมรับระบบหรือไม่ก็อยู่ที่หน้าจอนี้

-       นักพัฒนาบิซิเนสโลจิก (Business Logic Engineer) สำหรับนักพัฒนาส่วนนี้ผมเคยคิดว่าจะให้ SA เป็นคนทำ เนื่องจากว่า SA จะรู้ดี และสามารถเขียนได้ดีโดยที่ไม่ต้องถ่ายทอดสเปกไปให้ Developer ซึ่งแน่นอน Developer ก็จะไม่สามารถรับได้ 100% ขึ้นอยู่กับ Developer ว่ามีประสบการณ์มากน้อยเท่าไร สมมุติว่ารับได้ 70% อีก 30% ก็เป็นบักครับ ซึ่งการพัฒนาตรงนี้ผมมองว่าเราควรเอาเทคนิคของ Windows Workflow Foundation (WF) หรือเครื่องมือที่ใช้พัฒนา Workflow หรือ Business Process Management (BPM) มาใช้ เพราะว่า SA ก็ต้องเขียนสเปกเป็นโฟลอยู่แล้ว ทำไมไม่เขียนโดยใช้  Workflow เลย สำหรับส่วนที่เป็นโปรเซสย่อยของการทำงานในโฟลนั้น (จะเรียกว่า Activity Code) ก็ให้ Developer ทำ อย่างน้อยโฟลก็ไม่ผิด ตรงนี้เราสามารถออกแบบการทำงานให้ดีได้ นอกจากนั้นแล้ว ถ้าเป็นงานที่เป็นเซอร์วิส ก็พัฒนาให้เป็น SOA ได้ซึ่งก็มีเครื่องมือ Web Services Software Factory หรือเครื่องมืออื่นๆ ช่วยอยู่แล้ว ดังนั้นเรื่อง SOA ก็เป็นเรื่องที่มีความซับซ้อนอยู่แล้วก็อาจจะแยกเป็นเรื่องหนึ่งซึ่งจะเอาไปต่อกับ Workflow ได้ (WF 4.0 สามารถ integrated กับ WCF ได้แล้วครับ ตรงนี้นับว่าเป็นข่าวดีสำหรับผู้ที่จะทำ Workflow ให้เป็น SOA) โครสนใจก็มาศึกษาตรงนี้ได้

-       สำหรับฐานข้อมูลนั้นเป็นหน้าที่ของ Data Administrator (เป็นคนเดียวกับ SA ก็ได้ครับ) ดูแลข้อมูล ความสัมพันธ์ข้อมูลเพื่อสร้างฐานข้อมูล และจัดทำ Data Model สำหรับ Data Model นี้ผู้เขียนได้ใช้ ADO.NET Entity Framework (EF) สำหรับทำ Data Model ซึ่งก็จะทำให้นักพัฒนาสามารถเรียกใช้ Business Entity ที่ถูกสร้างมาจากโมเดลได้ โดยที่ Develop ไม่ต้องไปสร้างเอง ซึ่งการสร้าง Data Model และ Entity Class ส่วนกลางเป็นหน้าที่ของ Data Administrator ที่สร้างไว้ให้ Developer ใช้งานเพื่อให้สามารถพัฒนางานส่วนนี้ได้ง่ายที่สุด

3          เทคโนโลยีและเครื่องมือที่นำมาใช้

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

3.1     เทคโนโลยี่ที่นำมาใช้

สำหรับแนวคิดที่จะนำมาใช้ผมก็ขอเสนอแนวคิดที่มาจากหนังสือ“Software Factories Assembling Application with Patterns, Models, Frameworks, and Tools” ซึ่งแนวคิดที่ใช้พัฒนา Software Factory ได้อย่างดี แต่ไม่ใช่ว่าเราจะไปนั่งอ่านหนังสือทั้งเล่มก่อนแล้วถึงจะมาทำ เพียงแต่เราเข้าไปดูแนวคิดเบื้องต้นเพื่อนำมาปรับใช้งาน หลังจากนั้นเราจึงจะเข้าไปปรับใช้ในรายละเอียดมากขึ้น สำหรับแนวคิดในด้านอื่นๆ นั้นก็จะมีดังนี้ครับ

1.    แนวคิดในการออกแบบโรงงานพัฒนาซอฟต์แวร์ (Software Factory) โดยใช้ Guidance และชุดเครื่องมือพัฒนา Composite Application Guidance สำหรับ WPF และ Silverlight ซึ่งเป็น Guidance และชุดเครื่องมือที่ใช้ช่วยพัฒนา (มาพร้อมกับ .DLL สำหรับควบคุมการทำงานของ WPF และ Silverlight) และควบคุมการพัฒนาหน้าจอให้เป็นชิ้นส่วนที่ต้องการและนำมาประกอบกันให้เองโดยอัตโนมัติ (Composite UI Guidance Asset) ใช้สำหรับพัฒนาแอพพลิเคชันที่เป็น Windows Presentation Foundation (WPF) และ Silverlight โดยใช้เฟรมเวิร์คร่วมกัน รวมถึงมี Guideline ที่จะบอกว่า ถ้าเราจะเปลี่ยน Code ของหน้าจอที่เป็น WPF ให้เป็น Silverlight จะต้องระวังอะไรบ้างโดยแก้ไข Code ไม่มาก ในอดีตลองนึกภาพว่าถ้าเราจะเปลี่ยนหน้าจอที่เป็น Windows Form ให้เป็น Web Form  คุณจะต้องพัฒนาทั้งหมด แต่ในเฟรมเวิร์คใหม่นี้คุณสามารถเปลี่ยน Code ไม่มาก แต่ผมว่าเราจะต้องวางรูปแบบก่อนล่วงหน้าเพื่อให้ง่ายต่อการเปลี่ยนหน้าจอจาก WPF ไปเป็น Silverlight ให้ได้ง่ายมากขึ้นและสามารถควบคุมได้ ตรงนี้คงฝากผู้เชี่ยวชาญทางด้านนี้ช่วยเหลือครับ

Composite Application Library Package

จากรูปเป็น Composite Application Library Package นั้นในส่วนด้านบนสุดจะเป็น Application ที่เราพัฒนาอยู่รวมถึงเฟรมเวิร์คและ         Infrastructure พื้นฐานรวมถึงโมดูลต่าง ๆ ที่เราพัฒนาซึ่งจะใช้เฟรมเวิร์คร่วมกัน ส่วน Library ที่อยู่ใน Patterns & Practices นั้นก็จะมี Library ต่าง ๆ ให้เราใช้งาน ส่วนการใช้งานอย่างไรนั้น ใน Guidance จะบอกรายละเอียดรวมถึงตัวอย่างการใช้งาน ซึ่งเป็นหน้าที่เราที่จะเข้าไปศึกษาและนำมาใช้หลังจากนั้นมันก็จะเป็นมาตรฐานการทำงานและการพัฒนาของเราโดยอัตโนมัติ ถ้าเราใช้ Library เหล่านี้ร่วมกันในชุมชน Great Friend มันก็จะเป็นมาตรฐานการใช้งานร่วมกัน ซึ่งจะทำให้เราสามารถเขียนโปรแกรมด้วยสไตล์เดียวกัน ผมว่าทำได้แค่นี้ก็ได้ประโยชน์มาหาศาลแล้วครับ ท่านลองคิดเล่นๆ ต่อไปว่ามันจะเกิดประโยชน์ต่อเนื่องอะไรอีกครับ ตรงนี้ผมขอยังไม่ขอพูดครับ

Patterns ที่อยู่ใน Composite Application Library

สำหรับรูปนี้เป็น Patterns ที่อยู่ใน Composite Application Library ซึ่งมี Patterns ต่าง ๆ ที่ถูกสร้างขึ้นใน Composite Application Library ซึ่งมีมาทั้ง Source Code ให้เราได้ศึกษาวิธีการเขียนโปรแกรมได้ด้วย

1.    สำหรับเครื่องมือต่อไปเป็นเครื่องมือที่ใช้บริหารจัดการ Automation Lifecycle Management (ALM) เป็นการควบคุมขั้นตอนการพัฒนาซอฟต์แวร์โดยใช้เครื่องมือช่วยเพื่อให้กระบวนการพัฒนาซอฟต์แวร์มีประสิทธิภาพมากขึ้นซึ่งก็จะใช้  Visual Studio Team System 2008 หรือ 2010 ซึ่งจะใช้ฟังก์ชั่นของ Project Management, Source Control, Build Server, Testing, Bug Tracking, Deployment ส่วนการบำรุงรักษาระบบงานก็น่าจะใช้ Build Server เพื่อทำ Branching ในกรณีที่ Build ระบบงานให้กับลูกค้าแต่ละรายที่มีความต้องการเฉพาะ ซึ่งตรงนี้อาจจะต้องพึ่งพาผู้เชี่ยวชาญ   

2.    Application Architecture Guide 2.0 Designing Application on .NET Platform เป็น Best Practice ที่ช่วยแนะนำวิธีการพัฒนาระบบงานขนาดใหญ่

3.    Standard Pattern Development เป็นรูปแบบมาตรฐานที่ทั่วโลกยอมรับแล้วว่าสามารถนำมาใช้แก้ไขปัญหาการพัฒนาซอฟต์แวร์ได้เป็นอย่างดี ซึ่ง Composite Application Guidance สำหรับ WPF และ Silverlight ก็ถูกพัฒนาอยู่บน Standard Pattern Development ต่างๆ เช่น Dependency Injection, Inversion of Control, Service Locator, Presentation Model เป็นต้น ซึ่งทำให้ทีมงานพัฒนาโครงสร้างได้เรียนรู้รูปแบบการพัฒนามาตรฐานดังกล่าวในขณะที่ศึกษาเครื่องมือนี้ และทำให้ทีมงานสามารถพัฒนาความรู้ทางด้าน Software Architecture ได้ในเลาเดียวกัน

2.1     เครื่องมือที่ใช้ออกแบบและพัฒนา (Design and Development Tools)

1.    Visual Studio Team System 2008 หรือ Visual Studio Team System 2010 สำหรับเป็น Integrate Development Environment และ Testing Tools

2.    Windows 2008 Server Standard Edition หรือ Enterprise Edition ใช้เป็นเฟรตฟอร์มที่เราพัฒนา

3.    Microsoft SQL Server 2008 Express Edition, Standard Edition หรือ Enterprise Edition เป็นระบบจัดการฐานข้อมูล

4.    Windows SharePoint Service 3.0 หรือ MOSS 2007 สำหรับพัฒนางานที่เป็น Document หรือ Content Management รวมถึงใช้เป็นเครื่องมือที่ช่วยจัดการ Configuration Management

5.    Windows Workflow Foundation สำหรับพัฒนางานที่เป็น Workflow

6.    WPF และ  Silverlight เทคโนโลยีสำหรับพัฒนาหน้าจอ

7.    สำหรับ Client Platforms นั้นเพื่อความทันสมัยเราก็อาจจะใช้บน Windows 7 เลย ส่วนอื่นๆ จะเป็น Mobile Application และอื่นๆ ก็เชิญคนที่เชี่ยวชาญด้านนั้นเข้ามาร่วมได้เลยครับ

3          สภาพแวดล้อมของการพัฒนา (Development Environment)

  รูปแสดงสภาพแวดล้อมของการพัฒนา

สำหรับสภาพแวดล้อมของการพัฒนานั้นก็จะเป็นในลักษณะดังในรูปด้านบน ซึ่งผมได้ทำเป็น Environment Development ที่ใช้พัฒนางานอยู่ในขณะนี้ โดยเฉพาะ Project Server 2007 ที่ใช้บริหารจัดการโครงการขนาดใหญ่ ในกรณีที่เรามีโครงการมาก ๆ ทำให้การบริหารจัดการทรัพยากรทำได้ดี การบริหารจัดการโครงการทำผ่าน Project Web Access โดยไม่จำเป็นต้องใช้กระดาษเลย สำหรับเรื่อง Development Environment นั้นประกอบด้วยส่วนต่างๆ ดังต่อไปนี้

1.     เครื่องที่เป็นโดเมนคอนโทรลเลอร์ ทำหน้าที่เก็บ Active Directory ของผู้ใช้งานระบบ

2.     เครื่องที่เป็น Database Server และ SharePoint Server จะติดตั้ง Microsoft SQL Server 2008 และ Windows SharePoint Service 3.0 (WSS 3.0) และ Microsoft Search Server 2008 Express Edition ถ้าเราจะใช้ SharePoint เป็นส่วนหนึ่งของการพัฒนาระบบ ซึ่ง WSS 3.0 และ Microsoft Search Server 2008 Express Edition นั้นไม่เสียตังค์ หรือจะใช้ MOSS 2007 ก็ได้ครับ

3.     เครื่องที่เป็น Project Management Server จะถูกติดตั้ง Windows 2008 Server Enterprise Edition, Microsoft SQL Server 2008 Enterprise Edition, WSS 3.0 หรือ MOSS 2007 , Microsoft Project Server 2007 เป็นเครื่องมือที่ใช้บริหารจัดการโครงการในระดับ High Level สำหรับทำ Enterprise Project Management

2          การบริหารจัดการโครงการ

วิธีและกระบวนการทำงาน (Methodology and Project Management Process)

สำหรับการบริหารโครงการนั้น นอกจากเราจะใช้วิธีบริหารโครงการในรูปแบบ MSF for Agile Software Development เป็นแนวทางในการทำงาน รวมทั้ง Project Planning, Project Monitoring and Control ที่อยู่ใน CMMI มาช่วยกระบวนการทำงาน โดยเป้าหมายหลักคือให้ซอฟต์แวร์ออกมาสู่ตลาดให้เร็วที่สุด แต่จะต้องมีคุณภาพที่ดี

3          Software Process Improvement นอกจากนั้น เราควรจะมี Software Process Improvement กระบวนการพัฒนาซอฟต์แวร์ที่ดี และพัฒนาให้ดีขึ้นเรื่อยๆ (ไม่มีคำว่าดีที่สุด มีแต่คำว่าดีกว่า และดีกว่า) ในด้านต่างๆ ตามกระบวนการของ CMMI หรือเราจะใช้ Agile ก็ได้ขึ้นอยู่กับทีมงาน เพื่อรับประกันว่าซอฟต์แวร์ที่เราพัฒนานั้นมีคุณภาพ ตรงนี้เป็นเรื่องใหญ่ครับ ส่วนผมตอนนี้ทำงานอยู่ใน Committee ของ Thailand SPIN ในส่วน Project Management ซึ่งกำลังเผยแพร่ความรู้ในเรื่อง Process Improvement ให้กับ Community อยู่เหมือนกันครับ

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

สำหรับตอนต่อไปนั้นผมก็จะพูดเรื่องเครื่องมือต่าง ๆ ที่ช่วยสนับสนุนโรงงานผลิตซอฟต์แวร์โดยจะเริ่มด้วย Composite Application Guidance for WPF and Silverlight ซึ่งเป็นตัวที่ผมชอบ และสามารถเห็นแนวคิด Software Factory ได้ชัดเจนทีเดียว ก็คอยติดตามในตอนต่อไปครับ