Báo cáo bài tập tuần 3: Phân tích yêu cầu phần mềm

Chia sẻ: Cau Be | Ngày: | Loại File: DOCX | Số trang:11

Thêm vào BST

Báo xấu

195
lượt xem 21
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Báo cáo bài tập tuần 3: Phân tích yêu cầu phần mềm có kết cấu nội dung giới thiệu đến các bạn một số nội dung chính về mười đặc tính chất lượng của một bản đặc tả yêu cầu phần mềm tốt, các Tips để viết đặc tả yêu cầu phần mềm, sử dụng tiếng Việt. Mời các bạn cùng tham khảo.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Báo cáo bài tập tuần 3: Phân tích yêu cầu phần mềm

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG ---------- Báo cáo bài tập tuân 3 ̀ Môn học: Phân tich yêu câu phân mêm ́ ̀ ̀ ̀ Giảng viên: PGS.TS. Huynh Quyêt Thăng ̀ ́ ́ Danh sách sinh viên: (nhóm 3 ) ́ Lê Trung Hiêu 20111568 CNTT-TT 2.3 K56 ̀ ̀ Đam Văn Hoai 20111600 CNTT-TT 2.3 K56 Nguyên Đức Cương ̃ 20111203 CNTT-TT 2.3 K56 ̀ ̣ Đoan Văn Đat 20111370 CNTT-TT 2.3 K56 Hà Nội – 4/2014 M ụ c lụ c
Phân tích yêu cầu phần mềm. Page 2
I. Mười đăc tinh chât lượng cua môt ban đăc tả yêu câu phân mêm tôt. ̣ ́ ́ ̉ ̣ ̉ ̣ ̀ ̀ ̀ ́ 1.1. Tính đúng đắn (correct) - Một đặc tả yêu cầu phần mềm tốt là mọi yêu cầu được xác định đều phải được phần mềm đáp ứng. Mỗi yêu cầu cần mô tả chính xác ch ức năng được xây dựng. Sự đảm bảo cho tính đúng đắn đó là tham chiếu đ ến nguồn của yêu cầu, đó có thể là khách hàng hoặc một đ ặc t ả yêu c ầu h ệ thống mức cao hơn. Một yêu cầu phần mềm mà xung đột với một yêu cầu hệ thống tương ứng thì là không đúng đắn. Chỉ sự trình bày của người dùng mới có thể xác định tính đúng đắn của yêu cầu người dùng, điều đó cho biết tại sao khi rà soát yêu cầu ta cần sự có m ặt c ủa chính người dùng hoặc người đại diện của họ. - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đăc tinh nay để đam bao phần mềm đáp ứng đầy ̣ ́ ̀ ̉ ̉ đủ các đặc tả yêu cầu phần mềm. Đây cũng là tiêu chí để đánh giá phần mềm có đáp ứng được các yêu cầu của người dùng hay không. 1.2. Tính hoàn chỉnh (complete) - Mỗi yêu cầu cần mô tả đầy đủ chức năng được chuyển giao. Nó phải chứa tất cả các thông tin cần thiết để nhà phát tri ển thi ết k ế và th ực thi chức năng này. Nếu yêu cầu phần mềm nào đó còn chưa rõ ràng, và ai đó có cảm giác còn thiếu khi nói về yêu cầu đó, họ sẽ đánh dấu yêu cầu đó là "TBD - To Be Determined" - đây là ký hiệu chuẩn trong IEEE 830. Như vậy khi rà soát toàn bộ tài liệu SRS, chúng ta tìm các yêu c ầu b ị đánh dấu TBD để tiếp tục hoàn thiện SRS. - Phải xác định được kết quả của các dữ liệu đầu vào, đặc bi ệt là phải xác định được kết quả của những dữ liệu đầu vào hợp lệ và dữ li ệu đầu vào không hợp lệ. - Phải có đầy đủ nhãn và tài liệu tham khảo cho t ất c ả các s ố li ệu, bảng biểu, sơ đồ trong SRS và định nghĩa của tất cả các điều khoản và đơn vị đo lường. - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đăc tinh nay để đam bao mỗi yêu cầu đã được mô ̣ ́ ̀ ̉ ̉ Phân tích yêu cầu phần mềm. Page 3
tả đầy đủ. 1.3. Tính nhất quán (consistent) -Các yêu cầu phần mềm không xung đột với các yêu cầu ph ần m ềm khác hoặc các yêu cầu cấp cao hơn (hệ thống hoặc kinh doanh). Tất cả các mâu thuẫn trong yêu cầu cần ph ải được phân gi ải tr ước khi quá trình phát triển diễn ra. Bạn có thể không biết một yêu cầu đơn nh ất (single requirement) nào đó là đúng đắn cho đến tận khi bạn ti ến hành m ột s ố nghiên cứu nào đó về yêu cầu này. - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đăc tinh nay để đam bao các yêu cầu của phần ̣ ́ ̀ ̉ ̉ mềm không xung đột lẫn nhau, đảm bảo được tính nh ất quán của các yêu cầu phần mềm. 1.4. Tính khả thi (Feasible) - Khả thi có nghĩa là có thể thực thi mỗi yêu c ầu trong các kh ả năng và giới hạn đã biết của hệ thống và môi trường hoạt động của h ệ th ống. Môt yêu câu không có tinh khả thi nêu nó không thể thực hiên được hoăc có ̣ ̀ ́ ́ ̣ ̣ thể thực hiên nhưng yêu câu chi phí lớn (về nhân lực, về tai chinh, về tai ̣ ̀ ̀ ́ ̀ nguyên phân cứng, phân mêm, hoăc về độ phức tap tinh toan). ̀ ̀ ̀ ̣ ̣ ́ ́ - Để tránh các yêu cầu không khả thi, cần một thành viên c ủa nhóm d ự án làm việc với những nhân viên ban hang hoặc các nhà phân tích yêu c ầu ́ ̀ trong quá trình xử lý yêu cầu (elicitation process). Người này sẽ đánh giá về tính khả thi của các yêu cầu về mặt kỹ thuật hoặc chỉ ra các yêu cầu có thể thực thi nhưng với một chi phí lớn. - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đăc tinh nay để đam bao cac yêu câu được đưa ra ̣ ́ ̀ ̉ ̉ ́ ̀ có thể thực hiên được trong thực tê. Nêu môt yêu câu không thể hoan thanh ̣ ́ ́ ̣ ̀ ̀ ̀ thì nó sẽ anh hưởng tới toan bộ dự an. Yêu câu đó có thể lam lang phi ́ môt ̉ ̀ ́ ̀ ̀ ̃ ̣ lượng lớn công sức, tai nguyên mà đem lai lợi ich quá nhỏ cho dự an. ̀ ̣ ́ ́ Thêm vao đo, viêc không thể hoan thanh yêu câu anh hưởng rât lớn tới uy ̀ ́ ̣ ̀ ̀ ̀ ̉ ́ tin cua người phat triên phân mêm. Vì vây, môt SRS tôt cân đam bao moi ́ ̉ ́ ̉ ̀ ̀ ̣ ̣ ́ ̀ ̉ ̉ ̣ Phân tích yêu cầu phần mềm. Page 4
yêu câu đề có tinh khả thi. ̀ ́ 1.5. Tính có thể thay đổi (Modifiable) - Môt SRS có thể thay đôi cân đam bao môi khi cân bổ sung, sửa đôi hay ̣ ̉ ̀ ̉ ̉ ̃ ̀ ̉ loai bỏ môt yêu câu nao đó thì công viêc nay cân được thực hiên môt cach ̣ ̣ ̀ ̀ ̣ ̀ ̀ ̣ ̣ ́ nhanh chong, chinh xac và vân đam bao tinh nhât quan với cac yêu câu con ́ ́ ́ ̃ ̉ ̉ ́ ́ ́ ́ ̀ ̀ ̣ lai. - Để tăng tính thay đổi được của yêu cầu ph ần m ềm, vi ết các yêu c ầu thật rõ ràng, mạch lạc (fine grain fashion), gán nhãn khác nhau cho m ỗi yêu cầu. Người đoc không thích nhìn thấy các dấu châm đâu hang trong tài ̣ ́ ̀ ̀ liệu, vì khi dò tìm các yêu cầu, phải dò qua từng yêu c ầu c ụ th ể m ột - t ốn thời gian và không rõ ràng (vì không có nhãn). Một trong những cách đ ể loại bỏ các dâu châm, đó là sắp xếp các yêu cầu theo bảng chữ cái - như ́ ́ thế dùng chữ cái để gán nhãn. - SRS có thể được nghiên cứu lai khi cần thiết và cân phai duy trì thông ̣ ̀ ̉ tin diễn biến thay đổi của mỗi yêu cầu. Điều này đòi hỏi mỗi yêu c ầu được dán nhãn duy nhất và được diễn giải riêng rẽ với các yêu cầu khác sao cho mỗi yêu cầu đều được tham chiếu chính xác. M ỗi yêu c ầu ch ỉ được xuất hiện duy nhất 1 lần trong SRS để tránh sự không nh ất quán giữa các thể hiện (instance) của cùng 1 yêu cầu tại những nơi khác nhau. Một bảng nội dung (table of contents), một index, một danh sách tham chiếu chéo (cross – reference listing) sẽ làm SRS dễ sửa chữa hơn. - IEEE 830-1998 hỗ trợ xây dựng SRS với đăc tinh chât lượng nay để có ̣ ́ ́ ̀ thể tiêt kiêm thời gian, chi phí cho quá trinh đam phan và quan lý yêu câu ́ ̣ ̀ ̀ ́ ̉ ̀ phân mêm. Môt SRS có đăc tinh “có thể sửa đôi” sẽ giup viêc sửa đôi chỉ ̀ ̀ ̣ ̣ ́ ̉ ́ ̣ ̉ cân lam ở môt số it nơi cua SRS, đông thời không cân lo lăng về viêc những ̀ ̀ ̣ ́ ̉ ̀ ̀ ́ ̣ thay đôi nay mâu thuân với cac yêu câu trước đo. ̉ ̀ ̃ ́ ̀ ́ 1.6. Tính cần thiết (Necessary) - Mỗi yêu cầu cần phải tài liệu hoá một cái gì đó mà khách hàng th ật Phân tích yêu cầu phần mềm. Page 5
sự cần hoặc một hệ thống khác bên ngoài cần. Một cách khác để xác nhận “tính cần thiết” là yêu cầu đó được đề xuất t ừ một bên mà b ạn bi ết rất rõ rằng người đó có thầm quyền đề ra yêu cầu. - Nêu môt yêu câu phân mêm không đap ứng nguyên vong cua bât kì ́ ̣ ̀ ̀ ̀ ́ ̣ ̣ ̉ ́ khach hang hay hệ thông nao thì nó là yêu câu không cân thiêt, cân phai loai ́ ̀ ́ ̀ ̀ ̀ ́ ̀ ̉ ̣ bo. Viêc thực hiên yêu câu nay không mang lai lợi ich nao cho dự an phân ̉ ̣ ̣ ̀ ̀ ̣ ́ ̀ ́ ̀ mêm, chỉ lam lang phí công sức, tai nguyên. ̀ ̀ ̃ ̀ - IEEE 839-1998 hỗ trợ xây dựng SRS với đăc tinh chât lượng nay để ̣ ́ ́ ̀ đam bao moi yêu câu được đưa ra trong SRS đêu cân thiêt cho dự an phân ̉ ̉ ̣ ̀ ̀ ̀ ́ ́ ̀ mêm. Chỉ cac yêu câu thât sự cân thiêt mới cân đâu tư thời gian, công sức ̀ ́ ̀ ̣ ̀ ́ ̀ ̀ để hoan thanh. ̀ ̀ 1.7. Có độ ưu tiên (Prioritized) - Gán mỗi thứ tự ưu tiên cho mỗi yêu cầu, tính năng (feature), ho ặc use case để có thể hình dung lịch trình phát triển các phiên bản ph ần m ềm. Nếu tất cả các yêu cầu được coi là quan trong như nhau thì qu ản tr ị d ự án sẽ không xác định được cách thức thi công khi một yêu cầu mới phát sinh trong quá trình thi công của dự án, anh ta sẽ không kiểm soát được ngân sách, lịch biểu và nhân lục của sự án. - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đăc tinh nay để đam bao người quản trị dự án đánh ̣ ́ ̀ ̉ ̉ giá được chính xác mức độ quan trong của mỗi yêu cầu. Tù đó có s ự đánh giá, kiểm soát được tất cả các yêu cầu hiện có và các yêu cầu phát sinh thêm. Người quản trị sẽ đầu tư đúng mức với từng yêu cầu tương ứng với mức độ ưu tiên của nó. 1.8. Có thể truy vết (Traceable) - Bạn cần phải liên kết các yêu cầu tới nguồn phát sinh của nó, tới các phần tử thiết kế, mã nguồn, các test cases thực thi và kiểm tra sự đúng đắn trong việc thi công các yêu cầu. Các yêu cầu có thể theo vết được gán Phân tích yêu cầu phần mềm. Page 6
nhãn duy nhất và được viết theo một cách có cấu trúc, chi tiết và được thuyết minh đầy đủ. - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đăc tinh nay để người làm dự án tìm được đường ̣ ́ ̀ đi của mỗi yêu cầu phần mềm từ nguyên nhân phát sinh đến lúc thi ết k ế để đáp ứng được yêu cầu đó trong phần mềm. Mỗi yêu cầu c ần xác đ ịnh một cách rõ ràng nguồn phát sinh, vị trí của nó trong khâu thiết kế. Truy viết được giúp người làm dự án tìm ra lỗi sai hay những thiếu sót của yêu cầu một cách nhanh chóng nhất do đã biết được vết đi của yêu cầu đó. 1.9. Không nhập nhằng (Unambiguous). - Tất cả những ai khi đọc bản báo cáo y êu cầu đều có cùng một cách hiểu, một cách diễn giải nhất quán về nội dung của các yêu cầu. Do ngôn ngữ tự nhiên là có tính nhập nhằng cao nên viết một yêu cầu rõ ràng, cụ thể, đơn nghĩa không phải là dễ. Cách hiệu quả để loại bỏ tính nhập nhằng là mô tả các báo cáo yêu cầu bằng các ngôn ngữ hình thức như use-case chẳng hạn, qua các kịch bản sử dụng cụ thể. - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đăc tinh nay để giúp cho SRS trình bày rõ ràng ̣ ́ ̀ nhất,tường minh nhất. Tất cả các yêu cầu không có sự trùng lặp hay trùng ý nghĩ với nhau vì nếu điều này có trong SRS thì dự án rất d ễ d ẫn đ ến thất bại. Một phần mềm không thể trùng lặp các chức năng với nhau đó là một phần mềm tồi. 1.10. Kiểm tra được (Verifiable) - Hãy kiểm tra mỗi yêu cầu để xem liệu bạn có th ể nghĩ ra một s ố lượng nhỏ các phép tests hoặc sử dụng một cách tiếp cận kiểm tra khác như thanh tra (inspection) hoặc chứng minh (demonstration) để biết liệu yêu cầu đó đã được cài đặt hợp lệ trong sản phẩm hay không. Nếu một yêu cầu không thể kiểm tra thì xác định liệu nó có được cài đ ặt đúng đ ắn hay không sẽ trở thành vấn đề gây tranh cãi. Các yêu cầu không nhất Phân tích yêu cầu phần mềm. Page 7
quán, không khả thi hoặc nhập nhằng thì cũng không thể kiểm tra được. - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đăc tinh nay để người làm dự án kiểm tra cài đặt ̣ ́ ̀ yêu đó đã hợp lí hay chưa, sai hoặc chưa tối ưu nhất. Một SRS kiểm tra được sẽ nhanh phát hiện lỗi của mỗi yêu cầu trong quá trình triển khai dự án giúp giảm chi phí về tiền bạc và nhân lực để sửa chữa. II. Các Tips để viết đặc tả yêu cầu phần mềm 1. Đưa ra các đánh giá dựa trên góc nhìn của nhà phát triển. Bất kể phía đối tác đưa ra yêu cầu nào, quan điểm nào, nên đứng trên quan điểm của nhà phát triển để đánh giá yêu cầu đó. B ản thân phía đối tác khi đưa ra yêu cầu phần mềm nào, đã mang góc nhìn và quan điểm của họ. Thông thường, họ không phải là người trong ngành công nghệ thông tin, và vì thế sẽ không hiểu hết rõ đặc thù của công việc phát triển phần mềm cũng như những khả năng của máy tính. Do đó, luôn phải đánh giá, nhận xét các yêu cầu phần mềm trên góc nhìn của nhà phát triển. 1. Làm nổi bật các yêu cầu bằng cấu trúc phân cấp. Và cũng nên suy nghĩ, đánh giá dựa theo cấu trúc phân cấp này. Bởi bản thân cấu trúc phân cấp đã mang trong nó ít nhiều những thông tin về mối quan h ệ logic giữa yêu cầu: Yêu cầu lớn, yêu cầu nhỏ, yêu cầu cha – con, các yêu cầu cùng mức phân cấp… Chính cấu trúc này giúp việc đánh giá trở nên chính xác, hợp lý, và sát hơn. Đặc biệt đánh giá dựa trên hình ảnh trực quan bao giờ cũng dễ dàng hơn là chỉ suy nghĩ vấn đề trong đầu mà không có hình ảnh hỗ trợ. Và thực tế cũng ch ứng minh, hầu hết mọi người đối mặt với các vấn đề phức tạp bằng cấu trúc phân cấp (nó phân rã vấn đề lớn thành các vấn đề nhỏ - hiểu và có th ể gi ải quyết được). Nếu không biểu diễn theo cấu trúc phân cấp, khó có th ể nhận ra mối quan hệ logic giữa các yêu cầu/mục yêu cầu, khó nh ận ra đâu là yêu cầu lớn, đâu là yêu cầu nhỏ, … 2. Cố gắng viết các câu và đoạn ngắn - đơn giản (write concisely): Phân tích yêu cầu phần mềm. Page 8
o Tránh các đoạn văn nói dài. Bởi đôi khi một đoạn văn dài, với nhiều ý, cuối cùng lại không chốt được yêu cầu mà nó nói tới chính xác là cái gì! o Dùng ngữ pháp, chính tả, và ngắt câu phù hợp (nên đ ể ng ười thông thạo ngôn ngữ được sử dụng để viết SRS) o Dùng từ vựng trong lĩnh vực kinh doanh (đôi khi việc không sử dụng chính xác từ cũng làm thay đổi toàn bộ ý nghĩa mà yêu cầu muốn diễn đạt) Trong một đoạn nói về một yêu cầu phần mềm nào đó, có thể có rất nhiều thông tin quan trọng, nhưng lại không chỉ rõ ra yêu cầu này cần xây dựng cái gì! Thay vì đó, đừng để yêu cầu về một chức năng được viết trong một đoạn quá dài, đưa các mô tả nền tảng (additional descriptive background), context của chức năng ra ngoài, tách bạch với mô tả chức năng. Đừng yêu cầu người khác rà soát lại một tài liệu chưa được kiểm tra ngữ pháp - chính tả. Sẽ tốt hơn nếu có 1 ai đó giỏi ngôn ngữ rà soát lại SRS, tìm ra các vấn đề về dùng từ và câu, để cho ra được 1 tài liệu tốt về mặt diễn đạt yêu cầu phần mềm. 1. Phải có văn bản mô tả cho cả các hành vi được mong muốn lẫn các ngoại lệ - Chúng ta mong đợi hệ thống hoạt động theo đúng nh ững hành vi mà ta mong muốn, tuy nhiên, 1 chương trình đ ược vi ết cùng với rất nhiều những đoạn mã để xử lý lỗi, ngoại lệ. Và nếu chúng ta không xác định các lỗi, ngoại lệ cũng như cách xử lý chúng trong quá trình xây dựng yêu cầu phần mềm, sẽ có 2 vân đề! 1 là developers sẽ chỉ ra ngoại lệ đó và cố gắng thiết kế xử lý ngoại lệ đó theo 1 cách mà kém lý tưởng hơn từ quan điểm của người dùng. 2 là sẽ không ai nghĩ về lỗi/ngoại lệ đó. Và lần đầu tiên chương trình gặp lỗi, ngo ại l ệ đó, nó crash! Công việc chỉ ra các ngoại lệ bị thiếu nên được thực hiện bởi tester, bởi họ sẽ nghĩ về mọi điều tồi tệ có thể xảy ra với chương trình. 2. Tránh các ràng buộc thiết kế (design constraints) không cần thiết. Tránh việc đưa vào SRS quá nhiều ý tưởng giải quyết (solution ideas). Có nghĩa là đừng đưa quá nhiều ràng buộc thiết kế vào tài li ệu SRS bằng cách kết hợp quá nhiều ý tưởng giải pháp trong tài liệu Phân tích yêu cầu phần mềm. Page 9
hướng dẫn, trừ khi có 1 lý do đặc biệt thỏa đáng. 3. Viết các yêu cầu ở mức chi tiết hợp lý Khó để xác định xem tài liệu SRS cần được viết chi tiết đến mức nào, một trong những hướng dẫn, đó là chia các yêu c ầu ph ần m ềm ra thành các bộ phận mà có thể độc lập kiểm tra. Các từ "and" và "or" xác định các yêu cầu phần mềm có được kết hợp với nhau hay không. Ví dụ khi gặp 1 từ "and" trong yêu c ầu ph ần mềm, ta sẽ đặt ra câu hỏi, phải chăng 2 vế c ủa từ "and" là c ủa cùng 1 yêu cầu? Hay chúng về mặt logic là 2 yêu cầu khác nhau và c ần chia ra (split)? 4. Viết các yêu cầu một cách chính xác, cụ thể, không mơ hồ và gây nhầm lẫn. Một số lập trình viên đôi khi thích các yêu cầu phần mềm mơ hồ, gây nhầm lẫn, để khi bắt tay vào xây dựng, họ có thể xây dựng cái gì mà họ muốn ? Và thậm chí người dùng cũng thích các yêu c ầu m ơ h ồ, gây nhầm lẫn, bởi nó cho phép họ định nghĩa lại yêu c ầu đó theo ý mà họ muốn tại thời điểm cụ thể! Điều này không tốt một chút nào cho việc xây dựng một phần mềm chất lượng tốt! Có một số từ nên được sử dụng để viết yêu cầu, và một số từ nên tránh. Nên sử dụng các từ "sẽ", "phải" thay vì nói "nên", "có l ẽ", "có thể",… (should, may, might, could, can, if possible, if you feel like, if you have time, if you get around). Nên chọn 1 s ố thu ật ng ữ và s ử d ụng nó một cách nhất quán từ đầu đến cuối SRS khi nói về các chức năng hệ thống. Một người bạn của tác giả gợi ý là thay thế từ should bằng c ụm t ừ "probably won't (có lẽ sẽ không)", và hỏi ý kiến người dùng có đồng ý với yêu cầu (phần mềm) đó không, và thông thường, người dùng nói không (tức là bản thân cụm từ probably won't cũng đã mơ hồ, không rõ ràng). Một số người viết yêu cầu phần mềm sử dụng should - nói đến chức năng được yêu cầu trong hệ thống, might - chức năng được mong muốn có trong hệ thống, và may - chức năng tùy chọn; điều này th ực sự không tốt, bởi chính bản thân những từ này trong giao tiếp hàng ngày đã ít nhiều được sử dụng thay thế nhau. Chính điều đó sẽ khiến cho việc sử dụng chúng làm văn bản trở nên thiếu tính nhất quán, các Phân tích yêu cầu phần mềm. Page 10
yêu cầu thiếu tính đơn nghĩa! Như vậy cần tránh sử dụng các từ gây nhầm lẫn và mang tính chủ quan. Phân tích yêu cầu phần mềm. Page 11