Bài giảng Công nghệ phần mềm

à ảB i Gi ng Công Nghệ Phần Mềm Software Engineering Giới thiệu môn học † Nội dung môn học „ Giới thiệu các khái niệm cơ bản về công nghệ phần mềm „ Mục tiêu của sản xuất phần mềm và công nghệ phần mềm „ Các mô hình sản xuất phần mềm „ Quy trình sản xuất và quản lý dự án phần mềm † Tài liệu tham khảo „ Introduction to Software Engineering – Ronald J. Leach – CRC Press (Thư viện A2 MS: 9075802004) „ Software Engineering – Ian Sommerville – Fifth edition (Thư viện A3 MS: 200032) „ Software Engineering – A Practitioner’s Approach – Roger S. Pressman – Fifth Edition † Hình thức kiểm tra „ Giữa kỳ (20%) + Cuối kỳ (60%) + Bài tập (20%) „ Hình thức kiểm tra: trắc nghiệm khách quan – open book „ Đánh giá kêt quả: tương đối - phi tuyến Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 2 ???????? & !!!!!!!! † Công Nghiệp & Công Nghệ ầ ề† Công Nghiệp Ph n M m (CNpPM) † Công Nghệ Phần Mềm (CNPM) † Công nghiệp phần mềm & các công nghiệp khác „ Giống „ Khác † Có hay không (những) công nghệ cho sản xuất phần mềm? † Có cần thiết phải có công nghệ cho sản xuất phần ề ấ ầ ềm m không, khi sản xu t ph n m m là hoạt động sản xuất “đặc biệt” vì không thể nói làm một phần mềm như sản xuất một lon coca. Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 3 Đặc tính của sản phẩm phần mềm † Software = Program † Software product = Program + Document + Support † Loại sản phẩm phần mềm „ Generic Product: là sản phẩm đóng gói và bán rộng rãi trên thị trường. „ B k P d t là ả hẩ đ hát t iể th ê ầ đặ thù ủespo e ro uc : s n p m ược p r n eo y u c u c c a từng khách hàng. † Các đặc tính quan trọng của sản phẩm phần mềm „ M i i bili hầ ề ó hể h đổi h ậ iệ h ê ầ ủa nta na ty: p n m m c t t ay t u n t n t eo y u c u c a người dùng „ Dependability: tính ổn định, bảo mật và an toàn của phần mềm. Không gây tổn hại về vật chất hay kinh tế cho hệ thống. „ Efficiency: Sử dụng hiệu quả tài nguyên của hệ thống cho công việc „ Usability: giao diện và phương thức phải phù hợp với người dùng đồng thời đáp ứng đúng yêu cầu của người dùng Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 4 Software - Đủ hay Thiếu? † Phần mềm được viết ngay từ khi có những máy tính ầ ềprogramable đ u tiên. Được quan tâm và phát tri n từ rất sớm † Có rất nhiều phần mềm đã được viết Î Không thiếu phần mềm † Thực tế việc sản xuất phần mềm không đáp ứng kịp yêu cầu của người sử dụng: „ Không đủ về số lượng „ Thiếu về chất lượng „ Không kịp về thời gian Î Phần mềm không đáp ứng đủ cho người dùng Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 5 Nguyên nhân khách quan † Số lượng phần mềm phải được hiểu là số đầu/loại phần mềm được sử dụng cho từng mục tiêu ứng dụng. † Nhu cầu sử dụng phần mềm là rất lớn „ Nhiều ngành nghề cần dùng phần mềm máy tính „ Mỗi ngành nghề cần nhiều loại phần mềm khác nhau „ Mội loại phần mềm cần nhiều cấp độ khác nhau theo trình độ người dùng † Chất lượng phần mềm cũng chưa đáp ứng tốt hoàn toàn người sử dụng: „ Tính customize rất cao của sản phẩm phần mềm. „ Trình độ sử dụng khác nhau và điều kiện hạ tầng ứng dụng khác nhau † Nhu cầu phần mềm thường rất cấp bách „ Tầm nhìn và chiến lược chưa đầy đủ của người sử dụng „ Không có kế hoạch lâu dài „ Phải thay đổi theo từng đối tượng người dùng Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 6 Nguyên nhân chủ quan † Tính chuyên nghiệp trong sản xuất phần mềm chưa cao Các dữ liệu quan sát được „ Cứ 6 đề án triển khai thì có 2 bị huỷ bỏ „ Trung bình thời gian thực hiện thực tế bị kéo dài 50 % (cá biệt 200- 300%) „ Các đề án lớn dễ thất bại „ 3/4 các hệ thống lớn có lỗi khi thực thi „ Quá trình phân tích yêu cầu (5 % công sức): để lại 55 % lỗi, có 18 % phát hiện được ế ế ể ỗ„ Quá trình thi t k (25 % công sức): đ lại 30 % l i, có 10 % phát hiện được „ Quá trình mã hoá, kiểm tra và bảo trì: để lại 15 % lỗi, có 72 % phát hiện được Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 7 Nguyên nhân chủ quan (tt) Lý do của những hệ quả trên ể ầ ề ố„ Phát tri n ph n m m gi ng như một “nghệ thuật”, chưa được xem như một ngành khoa học „ Quy trình phát triển phần mềm chưa được thống nhất „ Phải iết l i / ỗi khi ó th đổi ề ô ữ h/ h ặ /v ạ s w m c sự ay v ng n ng , w o c o s „ Chưa đạt được 1 chuẩn cho việc đo lường hiệu suất và sản phẩm „ Độ phức tạp của phần mềm quá cao đối với 1 “kiến trúc sư” h ậ đ ả để l i hậ hằ á ê ầ hầ ề„ Kỹ t u t ặc t ạ sự n p n ng trong c c y u c u p n m m „ Làm việc nhóm không đúng kỷ luật gây ra các lỗi Ầ Ả Ó Ộ Ề Ẩ Ì ẢÎ C N PH I C M T/NHI U CHU N QUY TR NH TRONG S N XUẤT PHẦN MỀM ĐỂ NÂNG CAO TÍNH CHUYÊN NGHIỆP CỦA NỀN SẢN XUẤT ĐẶC BIỆT NÀY Î CẦN CÔNG NGHỆ CHO CÔNG NGHIỆP PHẦN MỀM Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 8 Định nghĩa “Công nghệ phần mềm” † Công Nghệ Phần Mềm là sự thiết lập và sử dụng các ng ên tắc khoa học nhằm m c đích tạo ra các phầnuy ụ mềm một cách kinh tế mà các phần mềm đó hoạt động hiệu quả và tin cậy trên các máy tính. † Công nghệ phần mềm là một quy trình có hệ thống được sử dụng trong quá trình phân tích, thiết kế, hiện thực, kiểm tra và bảo trì để bảo đảm các sản phẩm phần mềm được sản xuất và hoạt động: hiệu quả, tin cậy, hữu dụng, nâng cấp dễ dàng (modificable), khả chuyển (portable), khả kiểm tra (testable), cộng tác được với các hệ thống khác (interoperable) và vận hành đúng (correct). Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 9 Cụ thể † Efficiency: Phần mềm được sản xuất trong thời gian và điều kiện vừa phải. Phần mềm vận hành đúng mức độ yêu cầu về công việc và thời gian. † Reliablity: Phần mềm vận hành ổn định và tương tác được với các hệ thống ứng dụng † Usability: Phần mềm có thể dùng được bởi người sử dụng và với môi trường mà người sử dụng đang có. Chú ý tới giao diện, điều kiện hệ thống,… † Modifiability: Phần mềm có thể được thay đổi dể dàng, nhanh chóng khi yêu cầu của người sử dụng thay đổi. † Portability: Phần mềm có thể chuyển đổi dễ dàng sang các hệ thống khác mà không cần phải điều chỉnh lớn. Chỉ cần recompile nều cần thiết là tốt nhất. † Testability: Phầ ề ó thể đ kiể t dễ dà Tốt hất là đ d l hón m m c ược m ra ng. n ược mo u a. † Reusability: Phần mềm hay một phần có thể được tái sử dụng cho các ứng dụng khác. Các modul có thiết kế tốt, độc lập và giao tiến đơn giản, cả về tình tương thích công nghệ phát triển Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 10 Cụ thể (tt) † Maintainability: thiết kế của phần mềm có thể được hiểu dễ dàng cũng như h ể i th ậ tiệ h ời khá t á t ì h điề hỉ h â ấ hc uy n g ao u n n c o ngư c rong qu r n u c n , n ng c p ay thay đổi theo yêu cầu. † Interoperability: Phần mềm vận hành ổn định và đúng như mong đợi. Trên hệ thống nhiều người dùng (multi users) phần mềm vẫn hoạt động được với các vận hành khác của hệ thống. † Correctness: Phần mềm phải tính toán đúng và tạo ra kết quả đúng và đúng với mục tiêu ứng dụng của người dùng. † Các yêu cầu khác: „ Đúng tiến độ „ Sử dụng hợp lý nguồn nhân lực phát triển „ Chi phí phát triển thấp nhất Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 11 What is “Engineering”? † The profession in which k l d f h h l d l i d b d„ a now e ge o t e mat ematica an natura sciences ga ne y stu y, experience, and practice „ is applied with judgment „ t d l t tili i ll th t i l d f f to eve op ways o u ze, econom ca y, e ma er a s an orces o na ure for the benefit of mankind -- Accreditation Board for Engineering and Technology S i Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 1212 c ence Engineers in Society † ACM Code of Ethics and Professional Conduct „ 1.1 Contribute to society and human well-being. „ 1.2 Avoid harm to others. „ 1.3 Be honest and trustworthy. „ 1.4 Be fair and take action not to discriminate. „ 1.5 Honor property rights including copyrights and patent. „ 1 6 Gi dit f i t ll t l t. ve proper cre or n e ec ua proper y. „ 1.7 Respect the privacy of others. „ 1.8 Honor confidentiality. Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 1313 Nội dung công việc của Software Engineering Công việc của software engineering bao gồm: † Phân tích hệ thống/vấn đề † Xác định các yêu cầu † Quản lý chất lượng † Huấn luyện † Thiết kế phần mềm † Viết phần mềm (coding) ể † Dự đoán tài nguyên † Quản trị dự án † Ki m tra và tích hợp hệ thống † Cài đặt và chuyển giao hầ ềp n m m † Lập tài liệu † Bảo trì Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 14 Một định nghĩa khác của CNPM † CNPM là các quy trình đúng kỷ luật và có định lượng ểđược áp dụng cho sự phát tri n, thực thi và bảo trì các hệ thống thiên về phần mềm † Tập trung vào quy trình sự đo lường sản phẩm tính, , , đúng thời gian và chất lượng Qui trình Đo lường Tiê h ẩ Thời gian Quản lý Chất lượng Dịch vụ Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 15 u c u n Mô hình phát triển phần mềm Các công đoạn chính tổng quát bao gồm 4 giai đoạn † Giai đoạn đặc tả: xác định các tính năng và điều kiện hoạt động của hệ thống. (thu thập yêu cầu và phân tích) † Giai đoạn phát triển: Thiết kế phần mềm (software design) viết code (code generation, † Giai đoạn kiểm tra: kiểm tra phần mềm (software testing), kiểm tra tính hợp lý của phần mềm. ả ử ỗ ổ† Giai đoạn b o trì: S a l i (correction), thay đ i môi trường thực thi (adaptation), tăng cường (enhancement) Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 16 Các mô hình sản xuất phần mềm Tùy theo quy mô và công nghệ phát triển, có các mô hình ấsản xu t khác nhau. † Mô hình tuần tự tuyến tính- waterfall † Mô hình Prototyping Evolutionary Development- † Mô hình xoắn ốc – Boehm’s Spiral Model † Mô hình RAD – Rapid Application Development MÔ HÌNH NÀO TỐT HƠN Mỗi mô hình phù hợp với trình độ phát triển, quy mô sản phẩm và yêu cầu ràng buộc cụ thể về thời gian và tính chất của hệ thống Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 17 . Mô hình WaterFall – Sequency model † Mô hình phát triển phần mềm đầu tiên ế ố ầ† Các công việc ti p n i nhau một cách tu n tự † Đặt nền móng cho các phương pháp phân tích, thiết kế, kiểm tra… Phân tích yêu cầu Thiết kế hệ thống & phần mềm Hiện thức và kiểm tra moduls Tí h hợ à kiểc p v m tra tổng thể Chuyển giao và Bảo trì Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 18 Mô hình WaterFall – Sequency model (tt) Bộc lộ một số khuyết điểm ấ ể ầ ề† Bản ch t của phát tri n ph n m m là quá trình lặp đi lặp lại chứ không phải tuần tự † Các bước thực chất không tách biệt hoàn toàn mà có chồng lấn và tham khảo lại † Bắt buộc khách hàng đặc tả tất cả yêu cầu một cách chính xác và đầy đủ ngay từ ban đầu † Khách hàng thường phải chờ đợi rất lâu để thấy được phiên bản đầu tiên của sản phẩm ồ† T n tại “delay” tích lũy trong nhóm làm việc -> dự án thường bị trể. † Chỉ phù hợp cho dự án nhỏ, đơn giản. Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 19 Mô Hình Prototype Hoạt động sản xuất Bản prototype Đặc tả Mô tả sơ lược ủ khá h hà Các bản trung gianPhát triểnc a c ng Bản cuối cùng Kiểm thử Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 20 Mô Hình Prototype – ưu & khuyết † Prototype như là một cơ chế để nhận diện chính xác yêu cầu của khách hàng „ Bản thân khách hàng chưa hiểu rõ yêu cầu của mình, cũng như các quy trình chưa được xác lập rõ ràng. „ Khách hàng chưa hiểu rõ khả năng hổ trợ của hệ thống máy tính † Kích thích sự thích thú của người dùng với dự án ể† Prototype có th bị “throw-away” -> Lãng phí † Các process không được phân định rõ ràng † Hệ thống thông thường có cấu trúc lỏng lẻo † Cần có những kỹ năng đăc biệt trong quản lý và phát triển † Khách hàng hối thúc nhà phát triển hoàn thành sản phẩm một khi thấy được các prototype đầu tiên Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 21 Mô Hình Prototype – Ứng dụng † Dùng cho các hệ thống nhỏ. Các chi phí khi thay đổi hệ thống là không quá lớn khi cần phải thay đổi sau khi thực hiện prototype † Cần sự cấp bách về thời gian triển khai ngắn. Hệ thống cần được đưa vào ứng dụng từng phần trong khoảng thời gian nhất định. † Trong trường hợp những hệ thống mà việc đặc tả các yêu cầu là rất khó và không rõ ràng ngay từ đầu. Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 22 Mô hình Xoắn Ốc - Boehm’s Spiral Model Đánh giá rủi roá ô ệ Phát triển sản phẩmHoạch định đề tài X c định c ng vi c † Được thực hiện theo một chuỗi lặp kiểu xoắn ốc, mỗi lần lặp cải thiện sản phẩm † Có phương pháp đánh giá rủi ro † Có thể áp dụng prototype † Mỗi lần lặp được cải thiện cho thích nghi với bản chất Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 23 của đề án Mô hình RAD Business modeling Data modeling Process modeling Application generation Testing & Turnover † Rapid Application Development là mô hình tuần tự tuyến tính có thời gian phát triển rất ngắn † Sử dụng các thành phần có sẵn càng nhiều càng tốt † Sử dụng công cụ lập trình ở dạng tự động sinh mã chứ không phải các ngôn ngữ truyền thống † Ph th ộ à ô hệ hát t iể ó tí h blụ u c v o c ng ng p r n c n reusa e cao. † Pattern system development Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 24 Software Process Model Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 25 Các tiêu chuẩn dùng trong CNpPM † The Capability Maturity Model (CMM) của Software Engineering Institue (SEI) Đại học Carnegie Mellon- . „ Chú trọng đến tính hệ thống và khả năng quản trị của các công ty phần mềm hơn là một quy trình (process) cụ thể. † The Process Improvement Paradigm (PIP) của Software Engineering Laboratory (SEL) – NASA’s Goddard Space Flight Center „ Tương tự như CMM, chú trọng đến tính hệ thống và những hướng dẫn để tăng cường tính năng của các quá trình quản lý. Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 26 Các tiêu chuẩn dùng trong CNpPM (tt) † Các chuẩn khác của Department of Defense S 216 A S 1 4A S 882C„ MIL – TD 7 ; MIL- TD 57 ; MIL- TD † The electronic Industries Association (EIA) chuẩn SEB-6-A † The European ESPRIT project † International Standards Organisation - ISO 9001 † United Kingdom MOD 0055 Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 27 Software Process Management To Achieve Improvement The Capability Maturity Model for Software (CMM) is a five-level roadmap for improving the software process and achieving improved quality results. Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 28 Software Process Management O ti i i P Capability Maturity Model Overview Increasing P Managed Process p m z ng - rocess refined constantly rocess Maturity Defined Process - measured/controlled Repeatable - Costs - institutionalized Initial - Ad hoc; , Schedules managed Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 29 unpredictable The Capability Maturity Model The CMM StructureMaturity Levels Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 30 The Capability Maturity Model The CMM StructureMaturity Levels Process indicate Capability Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 31 The Capability Maturity Model Maturity Levels A maturity level is a well-defined evolutionary plateau on the path toward becoming a mature software organization. • each level is a layer in the foundation for continuous process improvement • there are five maturity levels in the CMM Process capability describes the range of expected results from following a process. Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 32 The Capability Maturity Model The Five Maturity Levels Continuously Managed Optimizing (5) improving process Defined (4) Standard, Predictable process Di i li d Repeatable (3) consistent process sc p ne process Initial (2) Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 33 (1) The Capability Maturity Model The CMM StructureMaturity Levels K P AProcess are composed of indicate ey rocess reas Capability Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 34 The Capability Maturity Model Key Process Areas Key process areas are the major building blocks in festablishing the process capability o an organization. They are a cluster of related activities performed collectively to achieve a set of goals Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 35 The Capability Maturity Model Focus of the Key Process Areas Level Focus Key Process Area Defect Prevention Technology Change Management Process Change Management Quantitative process management Optimizing (5) Continuous Process improvement Software quality management Organization process focus Organization process definition Training program Managed (4) Product & process quality Defined (3) Engineering process Integrated software management Software product engineering Intergroup coordination Peer Reviews Requirements management Software project planning Software project tracking & oversight Software subcontract management Software quality assurance Repeatable (2) Project management Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 36 Software configuration management Initial (1) The Initial Maturity Level Understanding the Initial Maturity Level Performance driven by the competence and heroics of the people doing the work. Consistency and compliance to standards driven by management priorities - usually schedule is the top priority. High quality and exceptional performance possible so long as the best people can be hired Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 37 . The Initial Maturity Level The Management View of the Software Process at Level 1 In Out Requirements flow in. A software product is (usually) produced by some amorphous process. Th d t fl t d (h f ll ) k Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Ti