MITT

การบ้าน DSS Mintzberg's Ten Management Roles

posted on 15 Jun 2010 17:47 by techinnoreview in MITT

Homework#1

 อรรถพงศ์เมษินทรีย์

 MITTsec 1 5270280026

ตัน ภาสกรนที กูรูกู้วิกฤต

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

 

Styles

 

Figure Head

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

 

Entrepreneur

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

 

Disturbance Handler

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

 

"เฮียฮ้อจุดเปลี่ยนบนโลกเอนเตอร์เทนเมนต์ 

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

Leader and Figure Head

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

 

Liaison

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

 

 วัลยา จิราธิวัฒน์ "ผู้บุกเบิก"

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

 

 

Entrepreneur

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

 

Resource Allocator

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

 

Monitor

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

edit @ 15 Jun 2010 17:49:30 by Auttapong Maesincee

edit @ 15 Jun 2010 17:50:38 by Auttapong Maesincee

Mintzberg's Ten Management Roles

posted on 15 Jun 2010 15:54 by techinnoreview in MITT

Mintzberg's Ten Management Roles

This diagram has been recreated by LMC.

LMC explains Mintzberg's Ten Management Roles

Mintzberg's Ten Management Roles are a complete set of behaviours or roles within a business environment. Each role is different, thus spanning the variety of all identified management behaviours. When collected together as an integrated whole (gestalt), the capabilities and competencies of a manager can be further evaluated in a role-specific way.

The Ten Management Roles

The ten roles explored in this theory have extensive explanations which are briefly
developed here:
 

  • Figurehead: All social, inspiration, legal and ceremonial obligations. In this light, the manager is seen as a symbol of status and authority.
  • Leader: Duties are at the heart of the manager-subordinate relationship and include structuring and motivating subordinates, overseeing their progress, promoting and encouraging their development, and balancing effectiveness.
  • Liaison: Describes the information and communication obligations of a manager. One must network and engage in information exchange to gain access to knowledge bases.
  • Monitor: Duties include assessing internal operations, a department's success and the problems and opportunities which may arise. All the information gained in this capacity must be stored and maintained.
  • Disseminator: Highlights factual or value based external views into the organisation and to subordinates. This requires both filtering and delegation skills.
  • Spokesman: Serves in a PR capacity by informing and lobbying others to keep key stakeholders updated about the operations of the organisation.
  • Entrepreneur: Roles encourage managers to create improvement projects and work to delegate, empower and supervise teams in the development process.
  • Disturbance handler: A generalist role that takes charge when an organisation is unexpectedly upset or transformed and requires calming and support.
  • Resource Allocator: Describes the responsibility of allocating and overseeing financial, material and personnel resources.
  • Negotiator: Is a specific task which is integral for the spokesman, figurehead and resource allocator roles.

As a secondary filtering, Mintzberg distinguishes these roles by their responsibilities towards information. Interpersonal roles, categorised as the figurehead, leader and liason, provide information. Informational roles link all managerial work together by processing information. These roles include the monitor, the disseminator and the spokesperson. All the remaining roles are decisional, in that they use information and make decisions on how information is delivered to secondary parties.

Generalist and specialist management

The core of Mitzberg's Ten Managerial Roles is that managers need to be both organisational generalists and specialists. This is due to three reasons:
 

  • External frustrations including operational imperfections and environmental pressures.
  • Authority disputes which upset even basic routines.
  • The expected fallibility of the individual and human, manager.

Mintzberg's summary statement may be that the role of a manager is quite varied and contradictory in its demands, and that it is therefore not always the lack of managerial prowess, but the complexity of individual situations demanding a variety of roles, which troubles today's manager.

The ten roles, therefore, can be applied to any managerial situation where an examination of the levels to which a manager uses each of the ten 'roles' at his or her disposal is required

 credit http://www.lmcuk.com/management-tool/mintzberg-s-ten-management-roles

 

Development Requirement

posted on 22 Dec 2009 01:52 by techinnoreview in MITT

Credit http://khomkrit.blogspot.com 

 

บันทึกนี้จะกล่าวถึงเรื่องของหลักการสร้างและพัฒนา (หรือเขียน) requirements ขึ้นมา ซึ่งจะบันทึกไว้ทั้งหมด 10 หัวข้อหลักๆที่เราควรทำตอนสร้าง requirement

 

  • การเขียน requirement ถ้าเขียนไม่ครบ ไม่เคลียร์ ระบบไม่เคย success ดังนั้นเรื่องนี้จึงสำคัญมาก

1. Domain Analysis

  • เราจำเป็นที่เราจะต้องเข้าใจ background ของ application และเข้าใจระบบเข้าใจ domain ก่อน
  • ข้อดีก็คือ (”เร็ว ดี”)
    • Faster development เนื่องจากเราได้ขอบเขตจากคนที่รู้จริงเกี่ยวกับระบบ
    • Better System ถ้าดีตั้งแต่เริ่มต้นแล้ว โอกาสผิดพลาดก็จะน้อย การแก้ไขก็น้อยตาม
    • เพิ่มขยายต่อไปทำได้ง่าย เพราะเราเข้าใจระบบได้ดีแล้ว การคิดต่อ ทำต่อก็ง่ายตามไปด้วย

Domain Analysis Document

  • มองในเรื่องของ domain name และ motivation (โดย motivation อย่าเขียนลอยๆ ควรมีข้อข้อมูลสนับสนุนด้วย บางครั้งเขียนแค่ว่า อดีตคืออะไร ปัจจุบันคืออะไร และอนาคตจะเป็นยังไง ก็พอ)
  • domain หรือองค์กรอื่นที่เกี่ยวข้องคือที่ไหนบ้าง อย่างน้อยถ้าเราสร้างใหม่ต้องไม่ด้อยกว่าเค้า
  • ดูความต้องการปัจจุบันว่ามีอะไรบ้าง
  • เทคนิค, software, hardware จะใช้อะไรบ้าง
  • คิดว่า data ต้องมีอะไรบ้าง และ data นั้นจะได้จากแหล่งไหน
  • อย่าเขียนมากไป เพราะจะเสียเวลา และห้ามผิดพลาด ถ้าผิดพลาดแล้วต้องปรับแก้อีกยาว นั่นคือ สั้นๆ แต่สื่อความหมาย

2. The Starting Point for Software Projects

picture-3

โดยรวมๆแล้วจุดกำเนิดของ Software จะเป็นไปดังรูป โดย A กับ B (การพัฒนาใหม่ตั้งแต่ต้น) จะเกิดขึ้นน้อยมาก ส่วน C กับ D (การปรับปรุงดูแลรักษา) จะเกิดขึ้นบ่อยๆ

3. Defining the Problem and the Scope

  • ปัญหาก็คือ สิ่งที่เราอยากได้และสิ่งที่เราได้รับมันไม่ตรงกัน
  • อย่าลืมว่า requirement เกิดจากปัญหา เราต้องเขียนปัญหาให้สั้นๆ กระชับ เข้าใจง่าย และสื่อความหมาย

Defining the Scope

  • เมื่อมีปัญหาแล้ว ให้มากำหนด scope ต่อ
  • เวลาเขียนกรอบงานต้อง clear ว่าต้องมีอะไรบ้าง เขียนให้ชัดเจน
  • อะไรก็ตามที่กว้างไปก็ลดให้เล็กลง อะไรก็ตามที่เล็กเกินไป ก็เพิ่มขยายเข้าไป

4. What is a Requirement?

  • statement ที่ไม่ชัดเจน จะไม่มีทางทำได้สำเร็จเลย
  • ถ้ากำหนดกรอบได้ควรกำหนดกรอบด้วย (กำหนด constraint) ว่างตรงไหนเราทำได้หรือทำไม่ได้ บางอย่างมันอยู่ในกรอบ ต้องอยู่ในกรอบเท่านั้นถึงจะทำได้ เช่นให้มองว่าถ้ามันเป็บแบบนี้เราจะทำได้ เป็บแบบนี้เราจะไม่ทำ เราจะทำไม่ได้ ดังนั้นต้องเขียนconstraint ให้ชัด ว่างานใหม่นี้เกิดขึ้นได้แต่ว่าต้องมีข้อกำหนดแบบนี้นะ งานนี้ถึงจะทำได้จริง
  • ต้องเข้าใจตรงกันทุกๆ partner สั้น และกระชับ

Requirement Engineering

  • สิ่งที่เราต้องรู้ก็คือ ทำอย่างไร requirement ถึงจะทำออกมาได้กระชับ และตรงตามความต้องการของ user?
  • เมื่อเขียน requirement เสร็จแล้ว ท้ายสุดเราต้อง validate เพื่อให้มั่นใจว่า requirement นั้นๆตรงตามที่ user ต้องการจริงๆ

5. Type of Requirement

  • Function บอกว่าระบบจะทำอะไรบ้าง
  • Non-Function จะอ้างอิงจาก PIECES (Performance, Information, Economic, Control/Security, Efficiency, Security)

Functional Requirement
ให้แยกออกเป็น 2 ส่วน คือ Data กับ Transformations

  1. Data โดยให้พิจารณาว่าข้อมูลจะเข้ามาในระบบได้อย่างไร จะเก็บไว้ที่ไหน แล้วข้อมูลนั้นจะออกไปไหน เช่นระบบต้องสามารถรับข้อมูล xxx ได้ และระบบต้องออก report xxx ได้ เป็นต้น
  2. Transformations ระบบนี้จะประมวลผลอะไรบ้าง เช่นระบบนี้ต้องประมวลผลดอกเบี้ยได้ ต้องทำแบบนั้นแบบนี้ได้ ซึ่งก็คือกระบวนการทั้งหมดเลย ซึ่งก็คือการ transform ให้ได้สิ่งที่ต้องการนั่นเอง และถ้าเป็นไปได้ให้มองในเรื่องของการ consequence, parallelism ระบบนี้ทำงานพร้อมๆกันได้กี่งาน กี่คนด้วย
  3. exception handling ถ้ามีข้อผิดพลาดเกิดขึ้นแล้ว ให้ทำอะไรต่อ? มองหาว่าอะไรผิดปกติแล้วมีอะไรบ้าง แล้วเราจะแก้ไขอย่างไร?

Non-functional Requirements: Quality
คือ business framework ซึ่งก็คือเงื่อนไขบังคับนั่นเอง

  • ปกติ non-function จะไม่ต่างกันเท่าไหร่ในแต่ละโปรเจ็ค จะต่างกันก็ตรงการ tune-up นิดหน่อยในเรื่องของตัวเลข
  • เชิง SE จะมอง usability, efficiency, reliability, maintainability, reusability
  • ให้มองที่ PIECES เป็นหลัก
  • โดยทั่วๆไปก็หนีไม่พ้นเรื่องเกี่ยวกับ response time ดี throughput ดี เชื่อถือได้ พร้อมใช้เสมอ ระบบล้มแล้วต้องกลับมาใช้ใหม่ได้ maintain ง่าย reuse ง่าย ใช้ resource น้อย ใช้กับ user ได้พร้อมๆกันกี่คน รับโหลดได้มากแค่ไหน
  • ในเรื่องของ capacity เราจะมองว่าระบบให้บริการ user ได้พร้อมๆกันกี่คน
  • Security & Safety
  • Training
  • Interface เราจะมอง 3 ด้านคือ
    1. User Interface สำหรับ user
    2. Hardware
    3. Software

ความต่างระหว่าง requirement กับ scope งาน ต่างกันอย่างไร?
Scope งานจะบอกเป็น eye bird view ภาพกว้างว่าจะทำอะไรบ้าง แล้วเอาภาพกว้างมาเจาะลึก ซึ่งก็คือ requirement นั่นเอง ส่วน requirement จะบอกว่าต้องการอะไรเท่านั้น ไม่ได้บอกว่าเราจะทำมันอย่างไร

6. Some Techniques for Gathering and Analyzing Requirements
  • observation สิ่งที่ได้มาคือ requirement ปัจจุบัน เห็นยังไงก็เอามาทำแบบนั้น
  • interviewing เราจะได้ requirement เพิ่มเติมจาก need ใหม่ๆของ user ได้

แต่อย่างไรก็ตามไม่จำเป็นต้องใช้วิธีการเดียวใช้ทั้งสองแบบก็ได้

Gathering and Analyzing Requirement

  • Brainstorming(meeting) แบบนี้ใช้กันมาก เอาคนที่เกี่ยวข้องโดยตรงมาคุย โดยอ้อมไม่เอา และ conflict ที่เกิดขึ้น ณ ตอนนั้นจะได้แก้ไขได้ในตอนนั้นเลย คำที่ใช้อย่างเป็นทางการสำหรับ brainstorming ก็คือ JAD
  • Prototyping กรณีที่ requirement ไม่เคลียร์ หรือ user ไม่เข้าใจระบบเท่าไหร่ เราก็จะทำ model นั่นเอง ที่ basic ที่สุดก็จะใช้ กระดาษ+ดินสอวาดให้ดูเลย และสิ่งที่เกี่ยวข้องส่วนมาก(ที่ทำเป็น prototype) ก็คือ ทำ User Interface นั่นเอง การเก็บข้อมูลทางเทคนิคปกติ user ไม่ค่อยสนใจเท่าไรนัก
  • Informal use case analysis ใช้ use-case ช่วยในการเก็บ requirement ด้วย
    • case ที่ว่านี้ให้เรามองประเด็นที่เราสนใจ หรือจะมองเป็น task หรือ function งานหลักๆก็ได้
    • ใช้ use case แทน context diagram
    • use case เป็น informal technique (จะมีหรือไม่มีในเอกสารก็ได้)
    • use case จะเริ่มจากเราต้องหาให้ได้ว่าใครเป็น user, actor และระบุให้ได้ว่า actor แต่ละคนเกี่ยวข้องกับระบบในมุมมองไหนบ้าง
      • เช่นระบบห้องสมุดก็จะมี case หลักๆคือ คืน ยืม ต่ออายุ และทำ catalog หนังสือ ส่วน actor ก็จะมีแค่ นักศึกษากับบรรณารักษ์เท่านั้น และบรรณารักจะยุ่งอยู่กับแค่ case ของการทำ catalog หนังสือเท่านั้น เนื่องจาก case อื่นๆแม้บรรณารักษ์จะมีส่วนเกี่ยวข้องก็จริง แต่ก็ไม่ได้เกี่ยวโดยตรง (ไม่ใช่คนกระทำเองตรงๆ เป็นแค่ helper เท่านั้น)

Documenting Requirements

  • ถ้าเป็นไปได้ ควรใช้มาตรฐานขององค์กร อะไรที่องค์กรมีให้ใช้ตามองค์กร
  • บันทึกกการเก็บ requirement เอกสารต่างๆ รายงารการประชุม details และของ requirement ต่างๆที่เรามี ก็เอามาเก็บไว้ในภาคผนวกด้วย


ตัวอย่าง. Interview Note (ตัวอย่าง ไม่จำเป็นต้องเหมือนกันทีเดียว)

เวลาไปสัมภาษณ์เราจะต้องทำ และบันทึกสิ่งต่างๆ เช่น

  • เราไปสัมภาษณ์ใคร, contact person คือใคร
  • ใส่ version ที่สัมภาษณ์ด้วย (บ่อยครั้งเราจะสัมภาษณ์มากกว่า 1 ครั้ง)
  • หน่วยงานที่ไปสัมภาษณ์ทำอะไร
  • มองระบบปัจจุบันที่เป็นอยู่ รายละเอียดย่อๆให้เข้าใจก่อน ทั้งทางด้าน hardware, software, network สถานภาพปัจจุบันต่างๆ
  • อย่าไปกระดาษเปล่า ค้นหาจากเว็บ หาข้อมูลก่อนไป รู้เขา รู้เรา
  • ปัญหาที่มีคืออะไร
  • เค้าอยากเห็นอะไรในระบบงานใหม่เพิ่มเติมจากระบบงานเก่าที่มีอยู่
  • เอกสารต่างๆที่มีที่เราได้มาจาก user


7. Types of Requirement Document

มี 2 ประเภท หลักๆ คือ

  1. Requirement Definition เขียนแค่ 1-2 บรรทัด สั้นๆเป็น eye bird view สำหรับผู้บริหารระดับสูง มอง requirement หลักของ user คืออะไรบอก user อยากได้อะไรบ้าง ไม่ได้ลงรายละเอียดอะไรมากนัก
  2. Requirement Specification อันนี้คือ requirement ที่เราต้องการในระดับที่เอาไปใช้ปฏิบัติงานได้

The Content of Requirement Documents - เนื้อหาใน requirement มีอะไร

  • ปัญหามีอะไรบ้าง
  • background เป็นอย่างไร?
  • สภาพงาน และระบบเป็นอย่างไร?
  • Functional Requirement
  • Non-functional Requirement
  • เวลาเขียน requirement จะต้องเขียนให้ชัดเจน ไม่อย่างนั้นเอามาวัดผลยาก (พยายามเขียนแต่ในสิ่งที่วัดผลได้เท่านั้น)
  • requirement ถือว่าเป็นสัญญาที่เรารับปากว่าจะทำให้ user และเอาไว้ประเมินตอนหลังด้วย
  • พยายามอย่าใส่เทคนิคลงไปใน requirement เพราะมันเป็นสัญญา user ต้องอ่านได้เข้าใจด้วย


8. Reviewing Requirement

หลังจากเก็บ requirement เสร็จแล้ว เราควรที่จะต้องมา review อีกครั้ง โดยดูจากเรื่องหลักๆต่อไปนี้

  • ลงทุนพัฒนาคุ้มค่าหรือเปล่า
  • ความสำคัญของปัญหา
  • ใน requirement จะต้องเคลียร์ ใช้สัญลักษณ์ที่สอดคล้องกันตลอดทั้งเล่ม
  • ไม่กำกวม อ่านแล้วชัดเจน เข้าใจง่าย วัดผลได้ตรงๆ
  • logically - บอกแค่ logic ห้ามบอกว่าจะ implement อย่างไร ให้มองแต่ what เท่านั้น
  • details ต้องเพียงพอ
  • requirement ที่ได้จะต้อง implement ได้ด้วยทรัพยากร และ technology ที่มีอยู่ในมือ คือสามารถหาได้ ณ ตอนนั้น
  • ไม่ over constraints ไม่มีเงื่อนไขบังคับเยอะ เพราะมันจะทำให้ยืดหยุ่นน้อย
  • จัดเรียงดี และ user ทุกคนต้องเห็นชอบด้วย

ปกติแล้วเราจะ validate โดยดูว่าตรง need จริงของ user หรือเปล่า และ verify โดยดูว่าตรงตาม spec ที่กำหนดไว้หรือเปล่า

Poor Requirement Document
requirement แย่ๆเป็นอย่างไร?

  • Unstructured Specifications - เขียนเป็บพรรณาโวหาร ดูยาก แก้ยาก ควรที่จะเขียนเป็นข้อๆแทนจะเข้าใจและอ่านได้ง่ายกว่า
  • Noise - อะไรไม่ต้องการ ให้เอาออก อย่าให้มีมากเกินไป requirement ที่เกินความจำเป็นไม่ได้ช่วยแก้ปัญหาอะไรเลย
  • Silence - สิ่งที่เราต้องการมันหายไป
  • Over-Specification - เอา design (หรือ how) มาใส่
  • Contradictions - มีอะไรที่ขัดแย้งกันเองในเอกสาร
  • Ambiguity - กำกวม
  • Forward References reference - ควรอ้างอิงจาก source เป็นหลัก
  • Wishful Thinking - requirement ที่เป็นไปไม่ได้


9. Managing Changing Requirement

ถ้าทำ requirement เสร็จสิ้นแล้วภายหลัง user ต้องการเปลี่ยน requirement เราจะต้องคิดก่อน ว่าควรเปลี่ยนหรือไม่ ซึ่งถ้าหากว่าจะเปลี่ยน ก็อาจจะต้องต่อรองกับ user ด้วย โดยมองที่ cost เป็นหลัก (cost หลักๆก็คือ เวลา)
ปกติแล้ว Requirement จะเปลี่ยนก็เพราะ 3 อย่างหลักๆนี้

  1. Business process เปลี่ยน
  2. Technology เปลี่ยน
  3. เรา (ทั้งคนเก็บ requirement และ user ที่ให้ requirement) ไม่เข้าใจงานดีพอตอนที่เราทำ requirement

อย่างไรก็ตามเราจะหลีกเลี่ยง requirement กระดื๊บ (creep) ห้ามเพิ่ม requirement เกินความจำเป็น ห้ามเพิ่มทีละนิดๆ วิธีการแก้ไขก็คือเขียน scope งานให้กระชับ และเสร็จสิ้นตั้งแต่ตอนแรก


10. Difficulties and Risks in Domain and Requirements Analysis

อุปสรรคของ requirement ที่ทำมา มักจะเกิดจากสิ่งต่อไปนี้

  • ไม่เข้าใจเนื้องาน ทั้ง user และคนเก็บ
  • requirement เปลี่ยนบ่อย (ถ้าเป็นแบบนี้ควรทำระบบแบบ incremental) ทำให้งานไม่เสร็จสักที
  • เก็บ requirement ไม่ครบ (แบบนี้เจอบ่อยมาก)
  • พยายามทำบางอย่างมากเกิน แม้มันจะไม่จำเป็นต้องทำ
  • requirement ขัดแย้งกันเอง (หลายครั้งเราเก็บ requirement มาจากคนมากกว่า 1 คน ซึ่งแต่ละคนอาจให้ requirement ที่ขัดแย้งกันได้)
  • ยากที่จะเข้าใจ requirement ที่ยาวๆ เป็นพรรณาโวหารได้ แก้โดยการเขียนประโยคสั้นๆก็พอ ให้เข้าใจได้ง่ายๆ

ตัวอย่าง Use CASE Diagram และ State Diagram

posted on 22 Dec 2009 01:33 by techinnoreview in MITT

 

 จะเห็นได้ว่ามี ผู้ใช้ระบบ ที่เป็นคน แบ่งแยกออกมาอย่างชัดเจนในระบบ

 ในระบบก็จะมี sub system แยกออกมาตามกรณีการใช้งานระบบอย่างชัดเจน

 

ระบบนี้ มี process หลักคือ place order หรือการสั่งสินค้า

และจัดให้มี sub system หรือระบบรอง 3 ส่วน

 

1. supply Customer Data ซึ่งคือการเรียกดูหรืออัพเดทประวัติลูกค้า *รวมถึงเรื่องสมาชิกด้วย

2. Order Product ซึ่งแตกออกมาจาก process หลักโดยตรง

3. Arrange Payment คือการกระทำธุรกรรม โดยอาจแยกได้เป็นเงินสด กับเครดิต

 

ทั้งนี้อาจจะมาในส่วนของ extend ในที่นี้ ยกตัวอย่างการ ขอข้อมูล Catalog เพื่อ ประกอบการตัดสินใจ

 

หรือเพื่อแสดงข้อมูลให้กับพนักงานขายในการบริการลูกค้า

 

State Diagram 

 

 

 State Diagram นั้นเขียนได้หลายแบบ แต่ทั้งสิ้นล้วนเกิดจาก จุดเริ่มต้นไปจนจบกระบวนการ

 

ต่างจาก DFD ที่เป็นการใหลข้อข้อมูล

 State Diagram จะมุ่งเน้นไปที่การแบ่งแยกการทำงานของแต่ละ process 

 

1. หัวของช่องสี่เหลี่ยมคือชื่อของ state

2. กรอบด้านล่างนั้น บ่งบอกการกระทำใน state นั้นๆ ว่าต้องทำอะไร

3. ลูกศรลากออกนั้น หมายถึงเมื่อทำโปรเสสนั้นๆเสร็จแล้ว จะก้าวไปสู่ state ถัดไปด้วยข้อแม้ใด 

Distributed system บน Object Orient Software Engineering (OOSE)

posted on 22 Dec 2009 01:12 by techinnoreview in MITT
 
 
ระบบคอมพิวเตอร์กระจายเชิงวัตถุ (Distributed Object Computing)
 
ความหมายอย่างสั้น
 
Distributed Object Computing คืออะไร?
 
ระบบคอมพิวเตอร์กระจายเชิงวัตถุ (Distributed Object Computing)
 
เป็นแนวคิดสำหรับการพัฒนาซอฟท์แวร์ที่รวมเอาเทคโนโลยีทาง Object Oriented
 
ร่วมกับ Distributed System เพื่อให้การระบบมีประสิทธิภาพขึ้น
 
โดยการนำข้อดีของการพัฒนาโปรแกรมแบบ Object Oriented
 
และระบบที่เป็น Distributed System เข้าด้วยกัน
 
 

ปัญหาที่เกิดขึ้นในการพัฒนาระบบ
 
เนื่องจากโลกของคอมพิวเตอร์เกิดการเปลี่ยนแปลงในส่วนของฮาร์ดแวร์
 
และซอฟต์แวร์อยู่ตลอดเวลา ไม่ว่าจะเกิดจากผู้พัฒนาเอง, ผู้ขายหรือแม้แต่ผู้ใช้
 
 
ปัจจุบันแอพลิเคชันมีขนาดใหญ่และซับซ้อน
 
นับตั้งแต่เวลาที่หมดไปกับการพัฒนา ความยากและค่าใช้จ่ายที่เกิดขึ้นในการปรับปรุงดูแลรักษา
 
รวมไปถึงความต้องการการทำงานที่ เพิ่มขึ้นอยู่เรื่อยๆ
 
ปัญหาของการพัฒนาซอฟท์แวร์นั้นมีเกิดขึ้นเยอะแยะมากมาย
 
ตัวอย่างเช่น
 
 
- แอพลิเคชันเปรียบเสมือนหินก้อนใหญ่ก้อนเดียว
มีลักษณะเป็น Packaged ซึ่งรวมคุณสมบัติหลากหลายเข้าไว้เป็นอันหนึ่งอันเดียว
ไม่สามารถที่จะลบ ปรับปรุง แก้ไขอย่างอิสระ หรือแทนที่ด้วยทางเลือกอื่น
 
- แอพลิเคชันไม่ง่ายต่อการนำมารวมกัน
ข้อมูลและฟังก์ชันการทำงานของ
แอพลิเคชันหนึ่งจะไม่มีประโยชน์ต่อแอพลิเคชันอื่น
แม้ว่าแอพลิเคชันนั้นๆ จะถูกพัฒนามาจากภาษาเดียวกัน
หรือทำงานบนเครื่องแบบเดียวกันก็ตาม
 
- ระบบปฏิบัติการก็มีส่วนสัมพันธ์กับปัญหาที่เกิดขึ้นเนื่องจาก
ความสามารถที่จะรองรับมีไม่เพียงพอ
และยากในการนำส่วนอื่นมาแทนที่หรือทำการปรับปรุงให้ทันตามสมัย
 
- การพัฒนาแอพลิเคชันยังไม่มีแบบแผนที่คงที่แน่นอน
แม้ว่าแอพลิเคชันจะมี คุณสมบัติการทำงานร่วมกัน
แต่การให้บริการกับแอพลิเคชันอื่นในแต่ละระบบก็แตกต่างกัน
ตามแต่ที่ระบบปฏิบัติการหรือเครือข่ายจะมีให้
ดังนั้นรูปแบบการพัฒนาส่วนใหญ่จึงมีความ
แตกต่างกันออกไปบางทีเป็นการใช้บริการที่มีอยู่ภายในเครื่องตัวเอง,
บริการที่มีอยู่ใน ระบบปฏิบัติหรือเครื่องที่แยกกันโดยใช้ข้ามเครือข่าย
 
 
ในปัจจุบันแนวโน้มของฮาร์ดแวร์มีการปรับตัวลดลงจากที่ต้องทำงานบนเครื่องเมนเฟรม
 
และมินิคอมพิวเตอร์ แต่หันมาเพิ่มขีดความสามารถที่ตัวซอฟต์แวร์
 
และมาทำงานบนเครื่องคอมพิวเตอร์พีซีธรรมดา
 
จากปัญหาในการพัฒนาซอฟท์แวร์ข้างต้น และแนวโน้มการปรับเปลี่ยนต่างๆที่เกิดขึ้น
 
จึงเกิดการพัฒนาเทคโนโลยีใหม่ที่รวมเอาข้อดีของระบบการทำงานแบบกระจายหรือ
 
Distributed System กับการพัฒนาโปรแกรมในเชิงวัตถุหรือ
 
Object Oriented เข้าด้วยกัน
 
 
หากคุณมีพื้นฐานทางด้าน Distributed System และ Object Oriented มาบ้าง
 
ก็คงจะทราบว่าทั้งสองแนวคิดนี้ในปัจจุบันกำลังเป็นที่นิยมมากสำหรับการพัฒนาระบบขององค์กร
 
เนื่องจาก Distributed System เป็นการทำงานในระบบกระจาย
 
ดังนั้นการทำงานจึงไม่หนักไปอยู่ที่เครื่องคอมพิวเตอร์เพียงเครื่องเดียว
 
จะกระจายการทำงานไปในคอมพิวเตอร์หลายๆ เครื่อง ผลที่ได้คือจะช่วยให้การทำงานนั้นสะดวก
 
รวดเร็ว ง่ายในการพัฒนา และยังเป็นลดต้นทุนอีกด้วย
 
ส่วนการพัฒนาระบบแบบ Object Oriented นั้น
 
เป็นการพัฒนาระบบในเชิงของวัตถุ ที่จะมองสิ่งต่างๆของระบบเป็นวัตถุ
 
เหมือนกับการมองของมนุษย์ทั่วไป ทำให้การพัฒนาโปรแกรมง่ายๆ ขึ้น
 
 
ความหมายอย่างละเอียด
Distributed System หรือระบบการทำงานแบบกระจาย
 
Distributed System หรือระบบที่ทำงานอย่างกระจาย หมายถึง
 
ระบบที่มีการทำงานไม่ว่าจะเป็นคอมพิวเตอร์
 
โปรแกรมหรือข้อมูลกระจายอยู่ตามเครื่องคอมพิวเตอร์หลายๆ เครื่อง
 
ไม่จำเป็นต้องอยู่บนเครื่องเดียว ซึ่งปกติเครื่องเหล่านี้จะมีการเชื่อมต่อกันด้วยระบบเครือข่าย
 
โดยทำไมต้องมีการกระจาย ก็เพื่อ
 
 
1. ให้เหมาะสมกับการงานขององค์กรซึ่งปกติจะประกอบด้วยหน่วยงานต่างๆ หลาย หน่วยงาน
 
 
2. การใช้เครื่องคอมพิวเตอร์ขนาดเล็กหลายๆเครื่องจะมีต้นทุนที่ถูกกว่า การใช้เครื่องขนาดใหญ่
 
 
3. เครื่อง workstations/PCs มีการติดต่อกับผู้ใช้ที่ง่ายกว่า
 
 
4. เครื่องสามารถใช้ประโยชน์ได้มากกว่า โดยที่ไม่จำเป็นต้องเป็นเครื่องประเภทเดียวกัน
 
 
5. ในงานบางประเภทจำเป็นต้องใช้เครื่องในการทำงานมากกว่า 1 เครื่อง
 
เช่นงานรับฝากถอนเงินของธนาคาร
 
 
 
แต่ปัญหาของ Distributed System
 
คือความยุ่งยากตั้งแต่การออกแบบ การพัฒนา
 
จนถึงการจัดการ และดูแลรักษา มีแนวคิดต่างๆ มากมาย
 
ในการพัฒนาระบบ Distributed System ไม่ว่า

จะเป็นเรื่องของการพัฒนาระบบเครือข่าย โปรโตคอลต่างๆ
 
เช่น TCP/IP, การพัฒนาภาษาเช่น JAVA เรื่องของ Web Technology
 
ตลอดถึงการนำแนวคิดของ Object มาใช้ด้วย
 
 
Object Oriented Programming หรือการพัฒนาโปรแกรมเชิงวัตถุ
 
แนวคิดของ Object Oriented ก่อนการพัฒนาโปรแกรมเชิงวัตถุจะได้รับความนิยมมาก
 
เราพบว่าการพัฒนาโปรแกรมเชิงวัตถุมีแนวคิดมาจากการพัฒนาสิ่งต่างๆ
 
ในโลกของความเป็นจริง การเขียนโปรแกรมแบบ Object Oriented
 
ทำให้เราสามารถจินตนาการถึงโปรแกรมในลักษณะเป็นรูปร่าง
 
เป็นตัวตนทำให้จัดการได้ง่ายกว่า การเขียนโปรแกรมในแบบเดิม
 
ทำให้เราสามารถนำโปรแกรมหรือวัตถุที่เราเคยสร้างไว้นำกลับมาใช้ได้อีก
 
ทำให้ง่ายในการพัฒนาระบบและพัฒนาระบบได้รวดเร็วยิ่งขึ้น
 
 
เครื่องมือในการพัฒนาโปรแกรมในปัจจุบันไม่ว่าจะเป็น C++,VB, Powerbuilder, JAVA, Delphi
 
ต่างมีความสามารถในการพัฒนาทางด้าน Object ทั้งสิ้น
 
ซึ่งอาจจะต่างกันในรายละเอียดบางอย่าง
 
 
Distributed Object Computing หรือการคอมพิวเตอร์แบบกระจายเชิงวัตถุ
 
  เป็นแนวคิดที่รวมเอาเทคโนโลยีทาง Object oriented ร่วมกับ Distributed computing
 
เพื่อสร้าง Distributed System ที่มีประสิทธิภาพขึ้น
 
โดยการนำข้อดีของการพัฒนาโปรแกรมแบบ Object Orientd
 
และระบบที่เป็น Distributed System เข้าด้วยกัน
 
ดังนั้นจะทำให้การพัฒนาระบบที่มีอยู่อยู่เป็นไปได้ง่าย รวดเร็ว
 
และมีประสิทธิภาพตามหลักการของ Distributed System อีกด้วย
 
 
แต่การที่จะสามารถสร้างโปรแกรมประยุกต์ในแนวคิดของ
 
Distributed Object Computing ได้นั้นต้องอาศัยวิธีการที่ยุ่งยากซับซ้อน
 
ไม่ว่าจะเป็นเรื่องของการจัดการ Object ที่ต้องมีประสิทธิภาพ
 
รวมถึงการจัดการในเรื่องของการติดต่อสื่อสารบนระบบเครือข่าย
 
แต่ทั้งนี้ไม่ต้อง ตกใจตอนนี้เราไม่จำเป็นต้องคิดค้นวิธีการเอง
 
เนื่องจากมีเครื่องมือที่จัดเตรียมสิ่งต่างๆ ไว้ให้เราแล้ว
 
ซึ่งเครื่องมือที่นิยมในกันมากคือ CORBA และ DCOM
 
 
ข้อพิจารณาในการนำความรู้ไปประยุกต์ใช้
 
 
การพัฒนาซอฟท์แวร์ ในระดับ Enterprise
 
การพัฒนาซอฟท์แวร์ เป็นงานที่ยุ่งยากและเสียค่าใช้จ่ายสูงโดย
 
เฉพาะระบบที่มีลักษณะเป็นแบบกระจายและมีขนาดใหญ่
 
ซึ่งปกติการพัฒนาซอฟท์แวร์แบบนี้จะเป็นการพัฒนาร่วมกันเป็นทีม
 
และคงจะเกิดปัญหาต่างๆ มากมาย ในการที่จะทำอย่างไรเพื่อ
 
1. สร้างระบบที่สามารถทำงานบนระบบเครือข่ายได้
 
ระบบนี้สามารถทำงานอยู่บนระบบปฏิบัติการที่ต่างกัน
 
เช่น Application ส่วนหนึ่งทำงานบน Unix ส่วนที่ติดต่อกับผู้ใช้ทำงานบน Windows
 
 
2. มีความสามารถในการนำเอาส่วนประกอบที่มีอยู่แล้วกลับมาใช้ใหม่ได้ (Re-Use Existing Component)
 
เพื่อไม่ต้องเขียนใหม่ ทำให้ประหยัดค่าใช้จ่ายได้มาก
 
 
3. ระบบควรจะสามารถพัฒนาจากภาษาคอมพิวเตอร์หลายๆ ภาษาได้
 
ทำให้นักเขียนโปรแกรมพัฒนาโปรแกรมได้สะดวกขึ้น
 
เพราะสามารถเขียนได้เองด้วยภาษาที่ถนัด อาจมองเห็นภาพว่าจะดีเพียงใด
 
เช่น ในทีมงานของเรามีความสามารถในการใช้ Visual Basic
 
อีกคนหนึ่งมีความสามารถในการใช้ C++
 
ส่วนอีกคนมีความสามารถในการใช้ Delphi
 
และอีกคนมีความสามารถในการใช้ JAVA แล้ว
 
ทุกคนสามารถเขียนโปรแกรมด้วยภาษาที่แต่ละคนถนัด และสามารถนำมาประกอบใช้รวมกันได้
 
 
 
4. สามารถใช้งานระบบที่มีอยู่เดิมได้
 
เช่น ในบริษัทอาจจะมีระบบเดิมที่ใช้งานก่อนแล้ว
 
ซึ่งอาจจะพัฒนาด้วยภาษา COBOL บนเครื่อง VAX
 
แต่หากต้องการพัฒนาระบบให้มีประสิทธิภาพมากขึ้น หรือต้องการแก้ไขบางส่วนของระบบ
 
คงเป็นเรื่องยากในการเข้าไปแก้ไข Source Code เดิม
 
(ซึ่งบางครั้ง Sode Code เดิมอาจจะหายไปแล้ว)
 
แต่ไม่อยากจะเขียนใหม่จะทำอย่างไร
 
หากมีเครื่องมือที่สามารถทำได้ดังที่กล่าวมานี้
 
คงจะรู้ว่ามันจะทำให้การพัฒนา Software ง่ายขึ้นและเสียค่าใช้จ่ายน้อยลง
 
และจะไม่ทำให้ผิดหวังหากศึกษาเรื่อง Distributed Object Computing ต่อไป
 
เพราะระบบดังกล่าวจะสนับสนุนทุกอย่างที่กล่าวมา
 
 
แหล่งข้อมูล :
จรณิต แก้วกังวาล. การออกแบบและจัดการฐานข้อมูล. กรุงเทพฯ: ซีเอ็ดยูเคชั่น.
เกี่ยวกับผู้จัดทำ :
ชื่อ-นามสกุล นายชนิตว์สรณ์ ตรีวิทยาภูมิ
การศึกษา ปริญญาโทเศรษฐศาสตร์ธุรกิจมหาบัณฑิต (English Program)
จุฬาลงกรณ์มหาวิทยาลัย ปี 2001
โครงการจัดทำข้อมูลองค์ความรู้ งวดที่ 1 : นิยามธุรกิจ: เทคโนโลยีสารสนเทศ (งวด2) 4/5
ประสบการณ์ ปัจจุบันทำงานตำแหน่ง Planning Officer ให้กับ
Thai Petrochemical Industry Public Company Limited (TPI)
โครงการจัดทำข้อมูลองค์ความรู้ งวดที่ 1 : นิยามธุรกิจ: เทคโนโลยีสารสนเทศ (งวด2) 5/5

Information Security Access Control Metrix

posted on 16 Dec 2009 10:10 by techinnoreview in MITT
Access Control Matrix

 

Split the matrix into its columns
 
แบ่งตาม columns เรียกว่า ACLs 
 
Store each column with its corresponding object
 
Whenever an object is accessed, its column of the access
 
control matrix could be consulted to see if the operation is allowed
 
These columns are known as access control lists or ACLs
 
 
Store the access control matrix by row, each with its
corresponding subject
 
แบ่งตามแถว เรียกว่า C-lists
 
Whenever a subject tries to perform an operation, we can
consult its row to see if the operation is allowed
This is known as capabilities or C-lists 
 
 
เมื่อเอามารวมกันจะได้ตารางการเข้าถึงข้อมูลที่เป็นรูปแบบ metric 2 มิติ
 
ปัญหาที่พบบ่อยคือ คนที่ไม่มีสิทธิ์ในไฟล์หนึ่ง อาจใช้อีกโปรแกรมที่มีสิทธ์ ไปทำการจัดการได้
 
*ถ้านึกภาพไม่ออกให้นึกถึง access control center ใน vista และ seven
 
 
 
 

public class Main {
public static void main(String[] args) {
Cubic Mycubic = new Cubic();
int w = 3;
int l = 10;
int h = 26;
System.out.println("Volume of this cubic is equal to " + Mycubic.Volume(w,l,h));
System.out.println("Surface Area of this cubic is equal to " + Mycubic.surfaceArea(w,l));
}
}
class Cubic {
public int Volume (int wid, int lon, int hgt)
{
if (wid < 0||lon <0||hgt<0) return -1;
else return wid*lon*hgt;
}
public int surfaceArea (int wid, int lon)
{
if (wid < 0||lon <0) return -1;
else return wid*lon;

}
}

Tags