วันศุกร์ที่ 11 ตุลาคม พ.ศ. 2556

SWE462 การพัฒนา Web Application

     หัวข้อ
        - ความหมาย
        - Thin client and Thick client
        - Advantages (ข้อดี)
 2. HTTP
        - HTTP Request Message
 3. JavaScript
4. Ajax
        - Ajax
        - Communication 



     นิยามของ web application (definition of web Application)
        web application คือ การประยุกต์เว็บ หรือ การใช้เว็บที่เป็น application (ทำงานผ่าน browser โดยไ่ม่มีการ Install)
                web application มีประโยชน์ตรงที่สามารถใช้งานได้หลาย platform และไ่ม่ต้อง install ลงบนเครื่่องคอมพิวเตอร์
        Thin client = application/web browser ที่แค่แสดงผล หรือรับ-ส่ง ข้อมูล ด้วยภาษา HTML จาก Client เท่านั้น (มีความสามารถน้อยมาก)
        Thick Client = Client จะช่วย server ประมวลผล เช่น game-online มีการคำนวณด้วยความสามารถของเครื่องฝั่ง client
    
    ข้อดี
1. ง่ายต่อการส่งมอบแ่ก่ผู้ใช้ (ผู้ใช้เปิด browser เมื่อต้องการใช้เอง)
2. ง่ายต่อการ อัพเกรด (upgrade บน server ทีเดียว)
3. มีความยืดหยุ่นของ end user (เพราะไม่ต้องกังวลว่าจะสามารถใช้ program/app ที่โหลดมาได้หรือไม่)
4. ง่ายต่อการควบคุมข้อมูล (เนื่องจาก ข้อมูลมาจากแหล่งเดียว)

วันอาทิตย์ที่ 29 กันยายน พ.ศ. 2556

SWE323 Software verification and testing

Software verification and testing


      หัวข้อ
  1. Software Development process overview 
        - Software Development Life Cycle
        - Software Development Life Cycle  Approach 
  2. Overview of Testing Techniques
           - Error, Default, Failure
  3. Program Analysis
           - หลักการวิเคราะห์โปรแกรม 
                - Static Analysis Tool
                - Dynamic Analysis Tool  
                       - Integration Testing




Software Development process overview



Software Development Life Cycle
1. Define the problem ระบุปัญหา/กำหนดวัตถุประสงค์
2. Feasibility การกำหนดค่าใช้จ่าย เทคโนโลยีที่ใช้ ทีมพัฒนา ที่เป็นไปได้/สามารถทำงานได้
3. Analysis การจัดเก็บความต้องการและนำมาวิเคราะห์
4. Design ออกแบบ hi level design เช่น use case, data flow
5. Implementation การพัฒนาระบบ และการทดสอบ
6. Maintenance/review การปรับปรุง แก้ไขระบบ

วันเสาร์ที่ 28 กันยายน พ.ศ. 2556

SWE321 Software Analysis and Design

Software Analysis and Design


    หัวข้อ
 1. Software Design & Software Product นิยาม
 3. System Requirement Analysis
        - สิ่งที่ต้องคำนึง
        - สิ่งที่ได้จากการวิเคราะห์ความต้องการ
        - IEEE830
 4. Software Engineering Process and Practice
        - High level design



    Software engineering design สิ่งที่สำคัญ คือ
1. ลูกค้าต้องการอะไร (ความต้องการจริงๆ)
    - มีจุดประสงค์ที่ชัดเจน
2. การเข้าใจที่ตรงกันในกระบวนการการทำงาน และการสื่อสาร
    - มีการประชุม/พูดคุย
    - จัดทำเอกสารให้ชัดเจน ถูกต้อง อัพเดทตลอดเวลา
3. เทคนิควิธีการ/ขั้นตอนที่ใช้
    - แปลงการวิเคราะห์เป็นการเขียนโปรแกรม โดยให้มีการเปลี่ยนแปลงน้อยที่สุด

    Software design เป็นการกำหนด product กำหนด ฟังก์ชั่น, ความสามารถของซอฟต์แวร์ 
และ interface ทั้งจากคอมพิวเตอร์-ผู้ใช้ , คอมพิวเตอร์-คอมพิวเตอร์ เพื่อตอบสนองความต้องการ
ของลูกค้า

    ทักษะที่ต้องใช้
1. User Interface (ออกแบบหน้าจอ) ให้เหมาะสม, เน้นส่วนหลัก ส่วนรอง, ต้องออกแบบขั้นตอน
การดำเนินการให้ชัดเจน
2. Communications (ทักษะการสื่อสาร, พูดคุย) อธิบายให้ลูกค้าเข้าใจได้ง่าย, ทำความเข้าใจ
กับลูกค้า ด้วยมิตรและการแสดงออกที่ดี
3. Industrial design (การออกแบบการผลิต) ว่าจะใช้อะไรเป็นตัวช่วยในการออกแบบ
4. Marketing (การตลาด) กลยุทธ์การตลาดและการโฆษณา



    Software Product 
        ประกอบด้วย 1 หรือมากว่า 1 โปรแกรม, ข้อมูล หรือชุดข้อมูล และ เอกสาร ที่ช่วยสนับสนุน
การใช้งานและการบริการหลังการขาย ซึ่งสิ่งเหล่านี้จะตอบสนองความต้องการของลูกค้าทั้ง
ความจำเป็นของลูกค้า (needs) และความปรารถนาของลูกค้า (desires)

So you want to be a software engineer


So you want to be a software engineer

Software Engineering คำศัพท์




คำศัพท์ที่มักพบบ่อย เกี่ยวกับ Software engineering

1. software  คือ  โปรแกรมคอมพิวเตอร์และเอกสารที่เกี่ยวข้อง, ผลิตภัณฑ์ด้านซอฟต์แวร์สำหรับบุคคล องค์กร หรือตลาดทั่วไป
2. good software ควรมีคุณสมบัติ (attributes) ฟังก์ชั่นที่ลูกค้าต้องการ, สามารถแก้ไขได้ (maintainable), เชื่อถือได้ (dependable), และใช้ได้จริง (usable)
3. software engineering คือ วินัยทางวิศวกรรม ซึ่งต้องเกี่ยวข้องกับการผลิตซอฟต์แวร์ในทุกๆ ขบวนการ
4. Fundamental software activities คือ พฤติกรรมพื้นฐาน ด้าน swe ที่ต้องมี ซึ่งได้แก่
                        1. specification รายละเอียดของซอฟต์แวร์
                        2. development การพัฒนาซอฟต์แวร์
                        3. validation  การตรวจสอบซอฟต์แวร์
                        4. evolution  วิวัฒนาการ, การพัฒนาซอฟต์แวร์เพิ่มเติม
5. Dependability and security ความเชื่อถือได้ ซึ่งจะต้องมีความไว้วางใจได้ (reliability) , มั่นคง (security) , ปลอดภัย (safety) และพร้อมให้บริการ (availability) 
6. Acceptability คือ การยอมรับ ซอฟต์แวร์ที่ดีต้องได้รับการยอมรับจากผู้ใช้ ซึ่งการที่จะได้รับการยอมรับนั้น ซอฟต์แวร์จะต้องตรงกับความต้องการของผู้ใช้
7. Stakeholder คือ ผู้มีส่วนเกี่ยวข้อง หรือผู้มีส่วนได้ส่วนเสียในทุกๆ กระบวนการการผลิตซอฟต์แวร์ตั้งแต่ต้นจนสิ้นสุดโครงการ ซึ่งได้แก่ ลูกค้า (customer), ผู้ใช้ (end user), นักพัฒนา (programmer) , ผู้ควบคุมโครงการ (project manager), ผู้ถือหุ้น เป็นต้น
8. Concurrency คือ การที่สามารถใช้งานพร้อมๆ กันได้
9. Portability คือ ความสามารถในการเคลื่อนย้าย หรือ พกพาได้
10. Modifility คือ สามารถปรับปรุง เปลี่ยนแปลงได้ง่าย

SWE322 Software & UI

swe322 Software & UI


 หัวข้อ
        - เงื่อนไขการให้บริการ
 2. Collaborative Environment
 9. Design Principles




    Computer environment


1. Physical Computing Environment (สภาพแวดล้อมทางกายภาพ)
    - Safety มีความปลอดภัยกับตัวผู้ใช้
    - Efficiency ประสิทธิภาพการใช้งาน
    - User space อุปกรณ์ที่ใช้ทำงานร่วมกัน, พื้นที่ใช้สอย
    - Work space การจัดการ interface บนหน้าจอ
    - Lighting แสงสว่างของอุปกรณ์
    - Noise เสียงของอุปกรณ์
    - Pollution มลพิษที่เกิดจากกการใช้งาน

2. Social Computing Environment 
    - สามารถทำงานเป็นกลุ่มได้
    - ข้อคำนึงในการติดต่อกันของอุปกรณ์ต่างชนิดกัน 

3. Cognitive Computer Environment (สภาพการเรียนรู้) : อยู่ในส่วนของผู้ใช้
    - อายุ
    - disability (พิการ)
    - ความรู้/ความสามารถทางด้านเทคนิคที่ใช้
    - ความสนใจของผู้ใช้
    - สภาวะของผู้ใช้ เมื่อใช้งานอุปกรณ์


    เงื่อนไขการใช้บริการ (terms)
1. Information Space : ลักษณะการเก็บข้อมูลและข้อมูล 
2. Intoraction Architecture : การติดต่อสื่อสารหรือโครงสร้างของ Hw/Sw
3. Intoraction Mode : โหมดการสื่อสาร เช่น ภาพ เสียง ภาพเคลื่อนไหว
4. Intoraction Paradigm : Model/pattern ระหว่างผู้ใช้กับคอมพิวเตอร์
5. Intoraction Space :  ตัวต่ออุปกรณ์ เช่น censor
6. Intoraction Style : ประเภทตัวสื่อสารกับผู้ใช้ เช่น GUI, SPEECH
7. Work Space : การเข้าถึงข้อมูลจากหน้าจอ, การทำงานกับ icon

SWE200 Software Processes


Software Processes

  Software processes 
1. กลุ่มของกิจกรรมที่ถูกต้อง ใช้ในการพัฒนาซอฟต์แวร์
2. ในกระบวนการมีหลายรูปแบบ แต่ในทุกๆ รูปแบบ จะประกอบด้วย 4 ขั้นตอนหลัก คือ
    - specification รายละเอียดที่ต้องการ



    วิธีการพัฒนาซอฟต์แวร์  แบ่งเป็น
1. Plan-driven มีการวัด/ประเมิน มีการวางแผนงาน
2. Agile processes เป็นการวางแผนแบบค่อยๆ ทำ มีการลำดับความสำคัญ เป็นการวางแผนเฉพาะ และการประเมินที่รวดเร็ว
3. ในทางปฏิบัติอาจเป็นการผสมผสานกันระหว่าง plan-driven & agile  (practice)

SWE200&SWE208 Requirement Engineering



Requirement Engineering

 เนื้อหา
        4.1 การเลือกเทคนิคมาใช้จากปัจจัยที่เกี่ยวข้อง
        4.2 การเลือกเทคนิคมาใช้จากประสบการณ์

โพสต์ใหม่
  สมัครรับบทความ

Requirement Engineering (วิศวกรรมความต้องการ)

โพสต์25 ก.ย. 2556, 00:22โดยChonrada Krasaeseub   [ อัปเดต 25 ก.ย. 2556, 01:41 ]
    Requirement เป็นการอธิบายบริการหรือข้อจำกัดต่างๆ ของระบบ ซึ่งจะถูกสร้างขึ้นระหว่าง
ขบวนการการหาความต้องการ ซึ่งเป็นการอธิบายด้วยภาษาพูดหรือ diagram โดยผู้ใช้
 เรียกว่า user requirement ซึ่งผู้ที่เก็บความต้องการจะมีการจัดเรียงความต้องการ
 เพื่อให้ผู้ใช้สามารถตรวจสอบและแก้ไขได้
    System requirement จะอยู่ในเอกสาร มีโครงสร้างและรูปแบบที่มีการอธิบายโดยละเอียด
เช่น บอกขั้นตอนการทำงานของระบบ, ข้อจำกัดการให้บริการ และยังถือเป็นเอกสารที่ใช้อ้างอิง
และเป็นสัญญา ระหว่าง ลูกค้ากับหน่วยงานที่พัฒนาระบบ

        ประเภทของความต้องการ
1. Functional Requirement  คือ การทำงานของระบบ ว่าจะมี input อย่างไร และต้องได้ output
 ที่ถูกต้องอย่างไร, ระบบมีพฤติกรรมการทำงานอย่างไร, รวมถึงเมื่อพบกับสถานการณ์พิเศษ
 หรือการรับค่าข้อมูลที่แปลกๆ ไป จะมีการแจ้ง error หรือไม่
    - เป็นข้อมูลที่ลูกค้าหรือผู้ใช้บอำ
    - ขึ้นอยู่กับประเภทของ ซอฟต์แวร์ว่าทำได้หรือทำไม่ได้
    - ถือเป็นการอธิบายระดับสูงของการให้บริการ

2. Non-Functional requirement คือ ข้อจำกัดหรืองานที่ถูกเสนอโดยระบบ โดยมักเป็นทั้งระบบ
ไม่ใช่สำหรับงานใดงานหนึ่ง เช่น security, usability, safety เป็นต้น
    - เป็นคุณสมบัติและข้อจำกัดต่างๆ ของระบบ เช่น ข้อจำกัดของความจุอุปกรณ์
    - อาจจะสำคัญมากว่า functional requirement ซึ่ง จะเป็นตัวบ่งบอกการทำงานของระบบ
ว่าดีหรือไม่
    - มีความทนทานต่อปัญหาหรือการถูกบุกรุกจากภายนอก (Robustness) 
         ประเภทของ non-functional requirement
    1. product requirement    จะต้องมีประสิทธิภาพ เช่น การทำงานที่รวดเร็ว , เชื่อถือได้
    2. organizational requirement มาตรฐานต่างๆ ในการทำงาน อย่างชัดเจน เพื่อหน้าตา
ขององค์กร
    3. external requirement ปัจจัยภายนอกของกระบวนการพัฒนา เช่น การทำงานร่วมกันภายใน
หน่วยงาน และกระบวนการในการพัฒนาระบบ

3. Performance requirement  เป็นคุณสมบัติส่วนหนึ่งของ non-functional requirement เช่น
    - speed requirement การวัดการทำงาน ที่มีข้อมูลขนาดใหญ่ โดยไม่ผ่านการ interrupt
และการแทรกจากผู้ใช้ 
    - capacity requirement ปริมาณข้อมูล ที่สามารถรอบรับกับระบบ, การจำกัดตัวเลขในการเก็บ
ข้อมูล
    - Reliability requirement  ซอฟต์แวร์มีความมั่นคง และไม่เกิดข้อผิดพลาดระหว่างการทำงาน,
 มีการหาข้อล้มเหลวและแก้ไข, นอกจากนี้ยังควรที่จะสามารถใช้งานได้เสมอโดยไม่ติดขัดด้วย


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

SWE320 Software Architecture



     Architecture สถาปัตยกรรม คือ ผลลัพธ์ของการตัดสินใจทางธุรกิจ (เงิน, ต้นทุน, ฟังก์ชั่นการใช้งานที่ต้องการ) , การตัดสินใจทางเทคนิค (เทคนิคการสร้าง, รูปแบบ) และอิทธิพลหรือผลกระทบที่อาจจะเกิดขึ้น

    Software Architecture คือ รูปแบบที่มีการเชื่อมโยงกัน หรือ โครงสร้างของระบบหรือซอฟต์แวร์ ซึ่งประกอบด้วย
1. Software element หน่วยย่อยของซอฟต์แวร์
2. Externally visible คุณสมบัติภายนอก หรือ ฟังก์ชั่น
3. Relation ความสัมพันธ์ระหว่าง element เหล่านั้น



  


  อิทธิพลในการสร้างสถาปัตยกรรม ที่ส่งผลต่อ Architect (นักออกแบบสถาปัตยกรรม)

loop ABC (Architecture Business Cycle)
Loop ABC (Architecture Business Cycle)


1. Stakeholder ผู้มีส่วนได้ส่วนเสีย ซึ่งจะเป็นคน หรือ หน่วยงานก็ได้
        - Customer ลูกค้า
        - End user ผู้ใช้
        - Developer นักพัฒนา
        - Project manager  ผู้ควบคุมโครงการ
        - Maintainer นักดูแลระบบ

2.  Developing Organization หน่วยงานที่ทำการพัฒนาซอฟต์แวร์
        - ทักษะความสามารถในการพัฒนาซอฟต์แวร์ เช่น ความถนัดด้านภาษาคอมพิวเตอร์ เช่น Java , C ซึ่งบางครั้งอาจเกิดข้อจำกัดด้านทักษะภาษาที่ใช้พัฒนาได้
        - การลงทุน เช่น มีการเพิ่มจำนวนคนในการเขียนโปรแกรม หรือ การ training 
        - โครงสร้างภายในองค์กรที่พัฒนาซอฟต์แวร์ เช่น การจัดทีมการทำงาน, วัฒนธรรมองค์กร

3. Technical Environment  สภาพแวดล้อมทางเทคนิค
        - วิธีการที่เป็นมาตรฐานในปัจจุบัน เช่น CMMI, เงื่อนไขฟังก์ชั่นต่างๆ เช่น web service(WSI) ซึ่งมาตรฐานจะเป็นตัวบังคับในกระบวนการพัฒนา
        - เทคนิคทาง software engineering หรือเทคนิคการพัฒนา/การเขียนโปรแกรม เช่น object oriented (oo)

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