วันอังคารที่ 11 มกราคม พ.ศ. 2554

ระบบ E-LEARNING ผ่านเว็บไซต์เรื่องการเขียนเว็บไซต์ด้วยภาษา HTML

 นายพิษณุ สมบูรณ์ ปวส2 เลขที่11 กลุ่มที่1
      วิทยาลัยเทคนิคอุบลราชธานี

วันจันทร์ที่ 22 พฤศจิกายน พ.ศ. 2553

Waterfall Model




          Waterfall Model หรือ ทฤษฎีแบบจำลองน้ำตก เป็นการศึกษาถึงความเหมาะสม
    กำหนดปัญหา หรือการศึกษาความเป็นไปได้ (Feasibility Study)
   เป็นหน้าที่ของนักวิเคราะห์ระบบ ในการพัฒนาซอฟต์แวร์ จะเน้นศึกษาใน 5 ประการ คือ
          
         
           1. ความเหมาะสมทางด้านเทคนิค (Technical Feasibility) - ศึกษาด้านฮาร์ดแวร์ ซอฟต์แวร์ เหมาะสมหรือไม่
           2. ความเหมาะสมทางด้านการปฏิบัติงาน (Operational Feasibility) - การปฏิบัติงานซ้ำซ้อนหรือไม่ ตรงหรือไม่
           3. ความเหมาะสมทางด้านการเงิน (Financial Feasibility) - เปรียบเทียบความคุ้มค่า ผลตอบแทน ค่าใช้จ่าย
           4. ความเหมาะสมทางด้านเวลา (Schedule Feasibility) - พิจารณาเวลาในการสร้างระบบงาน การใช้เวลา
          5. ความเหมาะสมทางด้านบุคลากร (Human Feasibility) - ดูความพร้อมของบุคลากร การพัฒนาบุคลากร
         
         
         คุณลักษณะของ Waterfall Model
  
     •เป็น Seriesของขั้นตอนการทำงาน คล้ายสายงานการผลิต (Product Line)
     •แต่ละขั้น หน้าที่และProduct ถูกกำหนดอย่างชัดเจน
     •Product ส่วนใหญ่เป็นเอกสาร (Document)
     •Productที่ผลิตในแต่ละขั้นจะเป็นพื้นฐานสำหรับงานขั้นต่อไป
     •สามารถตรวจสอบความถูกต้องของงานในแต่ละขั้นได้
         ข้อดีของ Waterfall Mode
  
         แบ่งงานยากให้เป็นงานที่เล็ก ง่ายต่อการจัดการ
        มีการกำหนดProductที่ต้องส่งมอบในแต่ละงาน อย่างชัดเจน


        ข้อจำกัดของ Waterfall Model


       ถ้า ค้นพบข้อผิดพลาดของขั้นที่เสร็จสิ้นแล้ว ไม่สามารถแก้ไขได้ การแก้ไขจำเป็นต้องเริ่ม
       รอบ   (Iteration) ใหม่
      ในความเป็นจริง หลังการทำงานในแต่ละขั้นควรสามารถย้อนไปแก้ไขความผิดพลาดในขั้นใด
      ใดก็ได้ก่อนหน้า

      ดังนั้นในทางปฏิบัติ  ขั้นตอนการทำงานใน Waterfall จึงไม่เป็นเชิงเส้น (Linear)

     ข้อเสียหลักคือ ลูกค้าเห็นและทดลองใช้Software ก็ต่อเมื่อถึงขั้นตอนสุดท้าย  หากมีบางอย่าง
     ที่ไม่ตรงกับความต้องการของลูกค้า การแก้ไขยาก แพง เสียเวลา



ขอขอบคุณข้อมูลจาก     http://th.wikipedia.org/wiki/แบบจำลองน้ำตก
 



วันพุธที่ 3 พฤศจิกายน พ.ศ. 2553

Software Engineering



าทำความรู้จักกับวิศวกรรมซอฟต์แวร์กันดีกว่า

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

ศาสตร์แขนงหนึ่งที่นำมาใช้คือ “วิศวกรรม (Engineer)” เรียกว่า “วิศวกรรมซอฟต์แวร์ (Software Engineering)”
ที่นับวันจะทวีความสำคัญต่ออุตสาหกรรมการผลิตซอฟต์แวร์มากขึ้นอย่างหลีก เลี่ยงไม่ได้

เราก็ได้รู้แล้วนะครับว่า วิศวกรรมซอฟต์แวร์มีความสำคัญเช่นไรต่อไปมารู้เรื่องเกี่ยวกับ Agile Modeling-AM ว่าคืออะไรกันน๊ะ
เป็นญาติทางไหนของวิศวกรรมซอฟต์แวร์ 


Agile Modeling-AM


 เป็นหลักการในการพัฒนา software แบบใหม่ที่เน้น 
    - Rapid and flexible response to change  
    - ทำให้การพัฒนาว่องไว  
    - มีการทำเรื่อยๆไม่ต้องหยุด แม้มีอะไรมากระทบก็ไม่เป็นไร  
    - เมื่อมีการเปลี่ยนแปลง เราสามารถรองรับความเปลี่ยนแปลงนั้นได้อย่างรวดเร็ว ไม่ตายตัว

 

วัตถุประสงค์ของ Agile

  1. เน้นว่าใครถนัดอะไร และการพูดคุยสื่อสารกัน มากกว่า การยึดติดที่เครื่องมือและกระบวนการ เช่นเปลี่ยนให้โปรแกรมเมอร์ไปคุยกับลูกค้าแทน ลูกค้าบอกอะไรมาก็ทำตามนั้นได้เลย
  2. ให้ทำงานโดยยึดที่ผลผลิตหรือ software เป็นหลัก เช่น เดิมเน้นเอกสารแต่ Agile ไม่สนมากนัก แต่สนที่ว่าเรามี sw หรือของส่งให้ลูกค้าหรือยัง
  3. ให้ความสำคัญเรื่องของการติดต่อสื่อสาร เช่น เดิมมีสัญญาหรือ contact กันแต่ Agile ไม่สนใจ ให้มองที่ความสัมพันธ์ระหว่างผู้พัฒนาและลูกค้า
  4. ยอมรับความเปลี่ยนแปลง เช่น เดิมต้องวางแผนให้ครบเป็นอย่างดี และทำตามแผน(gantt chart) ให้ได้ แต่ Agile ไม่ต้องทำตามแผนแต่เน้นการสนองความเปลี่ยนแปลงที่เกิดขึ้นได้

 

หลักการ Agile 

เน้นความพอใจให้ลูกค้า ลูกค้าชอบ มีการส่งมอบ sw อย่างต่อเนื่อง  

ยอมรับ requirement ที่เปลี่ยนแปลง  

มีการส่งมอบงานบ่อยๆ (ทุกๆ 2 สัปดาห์)

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

 

  โมเดลของ Agile

เลือกบางหลักการมาทำ
เป็นวิธีนึงที่จะเอาหลักการของ Agile มาจัดการกับเอกสารและระบบเดิมที่มีอยู่ได้
  1. value ผลลัพธ์
  2. principle หลักการ
  3. practices วิธีปฏิบัติ
ทั้งสามอย่างนี้เป็นส่วนหนึ่งในโมเดล Agile ที่สามารถนำมาพัฒนา SW ให้มีประสิทธิภาพและเกิด overhead น้อย
    -ให้มอง Agile เป็นส่วนขยายของกระบวนการพัฒนา SW แบบเดิมได้
    -ให้ Agile เข้าไปกำกับ ดูว่าของเดิมที่มีอยู่อันไหนสำคัญก็ทำอันนั้นก่อน
    -นำ Agile มาจัดลำดับความสำคัญ ดูว่ากิจกรรมไหน ควรทำ ไม่ควรทำ


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