Bài tập lớn về môn:Nhập Môn Công Nghệ Phần MềmChương 2Phân Tích:Đại Học Công Nghiệp Hà NộiTài liệu đã được dịch từ tài liệu tiếng anh.Trong tài liệu đã bao gồm các phần đầy đủ chi tiết được dịch ra.Có thêm câu hỏi trắc nghiệm cuối chương
Trang 1TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
BỘ MÔN CÔNG NGHỆ PHẦN MỀM
Môn học: Nhập môn công nghệ phần mềm
BÁO CÁO CHUYÊN ĐỀ NHÓM SỐ 4 Tên chuyên đề: Chương 2:Phân Tích
Điểm: ……
Giảng viên hướng dẫn: TS Trần Tiến Dũng
Những người thực hiện chuyên đề: (Họ tên và chữ ký)
học Công nghiệp Hà Nội
2 Đinh Hồ Khoa ĐH-KTPM2-K9, Khoa CNTT, Đại học Công nghiệp Hà Nội
3 Đặng Văn Nam ĐH-KTPM2-K9, Khoa CNTT, Đại học Công nghiệp Hà Nội
4 Phùng Minh Tú ĐH-KTPM2-K9, Khoa CNTT, Đại học Công nghiệp Hà Nội
5 Ngô Văn Quyền ĐH-KTPM2-K9, Khoa CNTT, Đại học Công nghiệp Hà Nội
Trang 2Hà Nội – 2016
MỤC LỤC
LỜI NÓI ĐẦU
1.Mục đích tài liệu
● Giới thiệu về môn học công nghệ phần mềm
● Hướng dẫn cách thức phân tích yêu cầu người dùng bằng phương pháp mô hình hóa
● Hướng dẫn cách thức thiết kế phần mềm bằng phương pháp mô hình hóa
● Hướng dẫn các phương thức kiểm chứng một hệ thống phần mềm
● Hướng dẫn các phương thức thẩm định một hệ thống phần mềm
● Hướng dẫn cách xây dựng và kiểm soát kế hoạch của một dự án phần mềm
2.Mô tả tài liệu
Chương II – Phân tích Trình bày cách thức phân tích yêu cầu người dùng bằng
phương pháp mô hình hóa UML
3.Nội Dung Phân Tích
3.1.Các nguyên tắc cốt lõi
3.1.1Hướng dẫn quá trình
Nguyên tắc 1 Hãy nhanh nhẹn cho dù các mô hình quy trình mà bạn chọn là chính kịp thời theo toa hoặc nhanh nhẹn, những nguyên lý cơ bản của phát triển nhanh nên chi phối cách tiếp cận của bạn Mọi khía cạnh của công việc bạn làm nên nhấn mạnh nền kinh tế của hành động giữ cách tiếp cận kỹ thuật của bạn là đơn giản càng tốt, giữ cho các sản phẩm công việc bạn sản xuất càng ngắn gọn càng tốt, và đưa ra quyết định tại địa phương bất cứ khi nào có thể.
❖ Nguyên tắc 2 Tập trung vào chất lượng cho mỗi bước đi Các điều kiện xuất
cảnh cho mỗi tiến trình hoạt động, hành động và nhiệm vụ cần tập trung vào chất lượng của các sản phẩm công việc mà đã được sản xuất
❖ Nguyên tắc 3 Hãy sẵn sàng để thích nghi Quy trình không phải là một kinh
nghiệm tôn giáo và giáo điều không có chỗ trong nó Khi cần thiết, điều chỉnh cách
Trang 3tiếp cận của bạn để hạn chế áp đặt bởi các vấn đề nhân dân, và các dự án riêng của mình
❖ Nguyên tắc 4 Xây dựng một đội ngũ hiệu quả Phần mềm quy trình kỹ thuật và
thực hành là quan trọng, nhưng điểm mấu chốt là con người Xây dựng một đội ngũ
tổ chức tự có tin tưởng lẫn nhau và tôn trọng
❖ Nguyên tắc 5 Thiết lập cơ chế thông tin liên lạc và phối hợp Các dự án thất bại
vì các thông tin quan trọng rơi vào ngõ cụt hoặc các bên liên quan không phối hợp các nỗ lực của họ để tạo ra UCT một kết thúc thành công phẩm Đây là những vấn
đề quản lý và họ phải được giải quyết
❖ Nguyên tắc 6 Quản lý sự thay đổi Cách tiếp cận này có thể là gmail chính thức
hay tin tức, nhưng cơ chế phải được thành lập để quản lý các cách thay đổi được yêu cầu, đánh giá, phê duyệt và triển khai thực hiện
❖ Nguyên tắc 7 Đánh giá rủi ro Rất nhiều điều có thể đi sai như các phần mềm
đang được phát triển Đó là điều cần thiết mà bạn thiết lập kế hoạch dự phòng
❖ Nguyên tắc 8 Tạo các sản phẩm công việc cung cấp giá trị cho những người khác Tạo chỉ những sản phẩm công việc cung cấp giá trị cho các hoạt động khác
quá trình, hành động, hoặc nhiệm vụ Mỗi sản phẩm công việc mà được sản xuất như là một phần của thực hành kỹ thuật phần mềm sẽ được chuyển cho người khác Một danh sách các chức năng và các tính năng cần thiết sẽ được thông qua cùng với những người (người), người sẽ phát triển một thiết kế, thiết kế sẽ được thông qua cùng với những người tạo ra các mã, và như vậy Hãy chắc chắn rằng các sản phẩm công việc truyền đạt các thông tin cần thiết mà không mơ hồ hoặc thiếu sót
3.1.2.Hướng dẫn thực hành
❖ Nguyên tắc 1 Chia và chinh phục.Nói một cách kỹ thuật, phân tích và thiết kế
nên luôn luôn nhấn mạnh tách mối quan ngại một vấn đề lớn là dễ dàng hơn để giải quyết nếu nó được chia thành một bộ sưu tập các phần tử (hoặc quan tâm) Lý tưởng nhất, mỗi mối quan tâm cung cấp chức năng riêng biệt mà có thể được phát triển, và trong một số trường hợp được xác nhận một cách độc lập các mối quan tâm khác
❖ Nguyên tắc 2 Hiểu được sự trừu tượng Trong thực hành kỹ thuật phần mềm, bạn
sử dụng nhiều cấp độ khác nhau của trừu tượng để truyền đạt những ý nghĩa ,ngụ ý của mình Trong phân tích và thiết kế công việc, một nhóm các phần mềm thông thường bắt đầu với mô hình đại diện cho mức độ trừu tượng và từ từ trau chuốt những mô hình thành các mức độ trừu tượng thấp hơn Mục đích của sự trừu tượng
là để loại bỏ sự cần thiết để giao tiếp thông tin chi tiết Nhưng đôi khi, các hiệu ứng
có vấn đề kết tủa bởi những chi tiết "rò rỉ" thông qua Nếu không có sự hiểu biết về các chi tiết, nguyên nhân của một vấn đề có thể không được dễ dàng chẩn đoán
❖ Nguyên tắc 3 Phấn đấu cho nhất quán Cho dù đó là việc tạo ra một mô hình yêu
cầu, phát triển một phần mềm thiết kế, tạo mã nguồn, hoặc tạo ra các trường hợp
Trang 4thử nghiệm, nguyên tắc nhất quán cho thấy một bối cảnh quen thuộc làm cho phần mềm dễ sử dụng hơn.Ví du như:thiết kế một giao diện người dùng cho một
WebApp trí phù hợp các menu tùy chọn, việc sử dụng một bảng màu phù hợp, và
sử dụng phù hợp các biểu tượng dễ nhận biết để tạo được sự nhất quán của sản phẩm
❖ Nguyên tắc 4 Tập trung vào việc chuyển giao thông tin Phần mềm sẽ giúp
chuyển giao thông tin từ một cơ sở dữ liệu để người dùng cuối, từ một hệ thống di sản để một WebApp, từ một người dùng cuối vào một giao diện đồ họa người dùng (GU), từ một hệ điều hành cho một ứng dụng, từ một thành phần phần mềm để khác danh sách gần như vô tận Trong mọi trường hợp, sẽ có nhiều luồng thông tin trên một giao diện, và như một hệ quả, có các lỗi, hay bỏ sót hoặc không chính xác
❖ Nguyên tắc 5 Hãy tìm một mô hình: Mục tiêu của mô hình trong cộng đồng phần
mềm là tạo ra một cơ thể của văn học để giúp các nhà phát triển phần mềm giải quyết các vấn đề định kỳ gặp phải trong suốt tất cả các mẫu phát triển phần mềm giúp tạo ra một ngôn ngữ chung cho cái nhìn sâu sắc về những chương trình và giải pháp của họ Chính thức hệ thống hóa các giải pháp và các mối quan hệ của họ cho phép chúng tôi nắm bắt thành công thân thể của kiến thức trong đó xác định sự hiểu biết của chúng ta về kiến trúc tốt đáp ứng nhu cầu của người sử dụng của họ
❖ Nguyên tắc 6 Khi có thể, đại diện cho các vấn đề và giải pháp của nó từ một số quan điểm khác nhau Khi một vấn đề và giải pháp của nó được kiểm tra từ một
số quan điểm khác nhau, nó có nhiều khả năng là cái nhìn sâu sắc hơn, các lỗi và thiếu sót sẽ được phát hiện
Ví dụ, một mô hình yêu cầu có thể được biểu diễn bằng một quan điểm đĩa dữ liệu theo định hướng, quan điểm chức năng định hướng hoặc một quan điểm hành vi.nó sẽ cung cấp một cái nhìn khác nhau của vấn đề và yêu cầu của nó
❖ Nguyên tắc 7.Cần người duy trì phần mềm Về lâu dài, phần mềm sẽ được sửa
chữa ,những thiếu sót sẽ được phát hiện, thích nghi trong môi trường thay đổi của
nó, và tăng cường như các bên liên quan yêu cầu thêm khả năng Những hoạt động bảo trì có thể được thuận lợi nếu thực hành kỹ thuật phần mềm rắn được áp dụng trong suốt quá trình phần mềm
3.2.Các nguyên tắc hướng dẫn hoạt động khung
3.2.1.Kết nối và giao tiếp
❖ Giao tiếp hiệu quả (vấn đề về kỹ thuật, với khách hàng và các bên liên quan, và với các nhà quản lý dự án) là một trong những hoạt động đầy thử thách nhất rằng bạn sẽ đối đầu Trong bối cảnh này, thảo luận về các nguyên tắc giao tiếp như họ áp dụng cho các giao tiếp khách hàng là cần thiết Tuy nhiên, có nhiều nguyên tắc áp dụng chung cho tất cả các hình thức truyền thông xảy ra trong một dự án phần mềm đó là:
❖ Nguyên tắc 1: Nghe
Cố gắng tập trung vào lời nói của người nói, chứ không phải là xây dựng câu trả lời của bạn cho những từ đó Yêu cầu làm rõ nếu một cái gì đó không rõ ràng, nhưng tránh bị gián đoạn liên tục
Trang 5❖ Nguyên tắc 2: Chuẩn bị trước khi bạn giao tiếp
Hãy dành thời gian để hiểu các vấn đề trước khi bạn gặp gỡ với
những người khác Nếu cần thiết, làm một số nghiên cứu để hiểu thuật ngữ lĩnh vực kinh doanh.Bạn có thể tiến hành một cuộc họp hoặc chuẩn bị một chương trình nghị sự trước cuộc họp
❖ Nguyên tắc 3: Cần có một nhà lãnh đạo.
Mỗi buổi truyền thông cần có một nhà lãnh đạo (một facilitator) để giữ cho cuộc trò chuyện đi theo một hướng , làm trung gian bất kỳ xung đột nào xảy ra và để đảm bảo hơn so với các nguyên tắc khác đang theo sau
❖ Nguyên tắc 4:Nói chuyện trực tiếp là tốt nhất.
Nó thường làm cho mọi việc tốt hơn khi một số đại diện khác của các thông tin có liên quan đều giao tiếp một cách trực quan Ví dụ, một người tham gia có thể tạo ra một bản vẽ hay một tài liệu phục vụ như là một trọng tâm thảo luận
❖ Nguyên tắc 5: Ghi chú và quyết định các tài liệu.
Một người nào đó tham gia vào các giao tiếp nên làm công việc như là ghi âm và viết ra tất cả các điểm và các quyết định quan trọng
❖ Nguyên tắc 6: Phấn đấu cho sự hợp tác.
Sự hợp tác và đồng thuận xảy ra khi những kiến thức tập thể của các thành viên trong nhóm được sử dụng để mô tả chức năng sản phẩm hoặc hệ thống hoặc các tính năng Mỗi hợp tác nhỏ phục vụ để xây dựng lòng tin giữa các thành viên trong nhóm và tạo ra một mục tiêu chung cho đội
❖ Nguyên tắc 7:Tập trung.
Sẽ có nhiều người tham gia vào việc thông tin liên lạc, nhiều khả năng cuộc thảo luận sẽ trả lại từ một chủ đề tiếp theo Người điều hành nên giữ cuộc đàm thoại trả lại từ một chủ đề tiếp theo Người điều hành nên giữ cuộc đàm thoại theo một mô-đun nào đó, để lại một chủ đề duy nhất sau khi nó đã được giải quyết
❖ Nguyên tắc 8: Nếu một cái gì đó không rõ ràng hãy vẽ phác thảo.
Nếu giao tiếp bằng lời nói chỉ đến mức đó Một bức phác thảo thường
có thể cung cấp rõ nét khi nói cách không thực hiện công việc
❖ Nguyên tắc 9: Chuyển sang một chủ đề khác khi cần thiết.
Giao tiếp trong hoạt động công nghệ phần mềm khá mất thời gian Thay
vì lặp vô tận, những người tham gia nên nhận ra rằng nhiều chủ đề cần thảo luận và chuyển sang chủ đề khác đôi khi là cách tốt nhất để đạt được sự nhanh chóng trong giao tiếp
❖ Nguyên tắc 10: Đàm phán không phải là một cuộc thi hay một trò chơi Nó hoạt động tốt nhất khi cả hai bên đều có lợi.
Có rất nhiều trường hợp trong đó bạn và các bên liên quan phải thương lượng chức năng và tính năng, ưu tiên, và ngày giao hàng Nếu đội đã phối
Trang 6hợp tốt, tất cả các bên có một mục tiêu chung Vẫn đàm phán sẽ có nhu cầu thỏa hiệp từ tất cả các bên
3.2.3.Mô hình hóa
❖ Trong phần mềm công việc kỹ thuật, hai lớp của mô hình có thể được tạo ra đó là:các yêu cầu và các mẫu thiết kế.Một số nguyên tắc cần được tuân thủ như sau:
❖ Nguyên tắc 1 Các mục tiêu chính của nhóm phần mềm là để xây dựng phần mềm, không tạo ra các mô hình.
Nhanh nhẹn có nghĩa là nhận được phần mềm cho khách hàng trong thời gian nhanh nhất có thể Mô hình mà làm cho điều này xảy ra là giá trị tạo ra, nhưng các mô hình mà làm chậm quá trình xuống hoặc cung cấp ít hiểu biết mới nên tránh
❖ Nguyên tắc 2 đừng tạo thêm nhiều mẫu mô hình không cần thiết.
Mỗi mô hình được tạo ra phải được giữ đến nay là những thay đổi xảy
ra.Quan trọng hơn, mỗi mô hình mới cần có thời gian, mà nếu không có thể được chi tiêu vào xây dựng (mã hóa và thử nghiệm) Vì vậy, chỉ tạo ra những
mô hình làm cho nó dễ dàng hơn và nhanh hơn để xây dựng phần mềm
❖ Nguyên tắc 3 Phấn đấu để sản xuất các mô hình đơn giản để mô tả vấn đề hoặc các phần mềm.
Mô hình đơn giản thì kết quả phần mềm cũng sẽ được đơn giản
❖ Nguyên tắc 4 Xây dựng mô hình một cách linh hoạt.
Giả sử rằng mô hình của bạn sẽ thay đổi, nhưng không được làm một cách cẩu thả
❖ Nguyên tắc 5 Có thể nêu một mục đích rõ ràng cho mỗi mô hình
được tạo ra.
Mỗi khi bạn tạo ra một mô hình, hãy tự hỏi tại sao bạn đang làm như thế Nếu bạn không thể cung cấp biện pháp vững chắc cho sự tồn tại của mô hình thì
sẽ không dành nhiều thời gian vào nó
❖ Nguyên tắc 6 Điều chỉnh mô hình bạn phát triển với một hệ thống.
Nó có thể cần thiết để thích nghi với ký hiệu mô hình hay quy tắc để áp dụng; Ví dụ, một ứng dụng trò chơi video có thể đòi hỏi một kỹ thuật mô hình khác nhau hơn thời gian thực, nhúng phần mềm điều khiển một động cơ
ô tô
❖ Nguyên tắc 7 Cố gắng để xây dựng mô hình hữu ích, nhưng quên về việc xây dựng mô hình hoàn hảo.
Khi xây dựng các yêu cầu và các mô hình thiết kế, một phần mềm được các
kỹ sư cố gắng để hoàn hảo nhất có thể Đó là, các nỗ lực cần thiết để làm cho các mô hình hoàn toàn đầy đủ và nhất quán là không đáng những lợi ích của các đặc tính này
❖ Nguyên tắc 8 Đừng làm một cách máy móc về mô hình.
Mặc dù tất cả mọi người trong một nhóm phần mềm cố gắng sử dụng ký hiệu phù hợp trong mô hình, các đặc tính quan trọng nhất của mô hình là để
Trang 7truyền đạt thông tin cho phép các nhiệm vụ kỹ thuật phần mềm tiếp theo Nếu một mô hình thực hiện cú pháp thành công thì tốt,ngược lại không chính xác
có thể được chấp nhận
❖ Nguyên tắc 9 Nếu một mô hình của bạn không đúng, mặc dù nó có vẻ ổn trên giấy thì bạn có thể có lý do để lo ngại.
Một mô hình thiết kế phần mềm không thể luôn hoàn hảo,vẫn có nhiều lỗi có thể xảy ra.Vì vậy,bạn có lý do để dành thêm thời gian kiểm tra mô hình hoặc phát triển một mô hình khác
❖ Nguyên tắc 10 Nhận thông tin phản hồi trong thời gian sớm nhất có thể.
Mỗi mô hình cần được xem xét bởi các thành viên của nhóm phần mềm Mục đích của những ý kiến để cung cấp thông tin phản hồi có thể được sử dụng để sửa mô hình sai lầm, thay đổi, hiểu nhầm, và thêm các tính năng hoặc chức năng mà vô tình bị bỏ qua
3.2.4.Xây dựng
❖ Các hoạt động xây dựng bao gồm một bộ mã hóa và thử nghiệm các công việc mà dẫn đến phần mềm hoạt động mà đã sẵn sàng để giao cho khách hàng hoặc người sử dụng cuối Trong công việc kỹ thuật phần mềm hiện đại, mã hóa có thể được tạo ra trực tiếp của mã nguồn ngôn ngữ lập trình (ví dụ, Java), (2) các thế hệ tự động mã nguồn sử dụng một đại diện thiết kế giống như trung gian của các thành phần được xây dựng, hoặc các thế hệ tự động của mã thực thi bằng cách sử dụng "ngôn ngữ lập trình thế hệ thứ tư" (ví dụ, Visual C++) Các thiết lập và nguyên tắc để xây dựng là :
❖ Mã hóa nguyên tắc :Các nguyên tắc hướng dẫn nhiệm vụ mã hóa được liên kết
chặt chẽ với phong cách lập trình, ngôn ngữ lập trình, và các phương pháp lập trình.Tuy nhiên, có một số nguyên tắc cơ bản mà có thể nói như sau :
❖ Nguyên tắc chuẩn bị: Trước khi bạn viết một dòng mã, hãy chắc chắn bạn có thể :
• Hiểu được các vấn đề bạn đang cố gắng để giải quyết
• Hiểu được nguyên tắc thiết kế cơ bản và khái niệm
• Chọn một ngôn ngữ lập trình nào đáp ứng các nhu cầu của phần mềm để có xây dựng và môi trường trong đó nó sẽ hoạt động
• Chọn một môi trường lập trình cung cấp các công cụ mà sẽ làm cho bạn làm việc dễ dàng hơn
• Tạo một tập hợp các bài kiểm tra đơn vị đó sẽ được áp dụng khi các thành phần bạn đang hoàn thành
❖ Lập trình các nguyên tắc: Khi bắt đầu viết mã, hãy chắc chắn rằng :
• Liên kết các thuật toán của bạn bằng cách làm theo lập trình có cấu trúc thực hành
• Xem xét việc sử dụng các cặp lập trình
• Chọn các cấu trúc dữ liệu mà sẽ đáp ứng nhu cầu của thiết kế
Trang 8• Hiểu được các kiến trúc phần mềm và tạo ra các giao diện mà phù hợp với nó
• Giữ logic có điều kiện như đơn giản càng tốt
• Tạo vòng lặp lồng nhau trong một cách mà làm cho chúng dễ dàng kiểm chứng
• Chọn tên biến có ý nghĩa và làm theo tiêu chuẩn mã hóa địa phương khác.Viết mã số đó là tự tài liệu
• Tạo một bố trí trực quan (ví dụ, thụt đầu dòng và dòng trống) nhằm
hỗ trợ sự hiểu biết
❖ Nguyên tắc xác nhận: Sau khi đã hoàn thành vượt qua mã hóa đầu tiên hãy chắc
chắn rằng :
• Tiến hành một hướng mã khi thích hợp
• Thực hiện các bài kiểm tra đơn vị và các lỗi chính xác bạn đã phát hiện ra
• Tái cấu trúc mã
❖ Nguyên tắc kiểm tra :
• Thử nghiệm là một quá trình thực hiện một chương trình với mục đích của việc tìm kiếm một lỗi
• Một trường hợp thử nghiệm tốt là một trong đó có một xác suất cao của việc tìm kiếm một lỗi
• Một thử nghiệm thành công là một trong những phát hiện ra một lỗi nhưng chưa được phát hiện
❖ Một số nguyên tắc thử nghiệm ta cần biết như sau :
Nguyên tắc 1 Tất cả các thử nghiệm nên được theo dõi bởi khách hàng.
Mục tiêu của kiểm thử phần mềm là để phát hiện ra lỗi Nó sau đó nhiều nhất khuyết tật nặng (từ quan điểm của khách hàng của xem) là những người gây ra chương trình không đáp ứng yêu cầu của nó
Nguyên tắc 2 Các xét nghiệm cần được quy hoạch dài trước khi thử
nghiệm bắt đầu
Thử nghiệm quy hoạch có thể bắt đầu ngay sau khi các mô hình yêu cầu hoàn tất định nghĩa chi tiết các trường hợp thử nghiệm có thể bắt đầu ngay sau khi các mô hình thiết kế đã được kiên cố hóa Vì vậy, tất cả các bài kiểm tra có thể được quy hoạch và thiết kế trước bất kỳ mã đã được tạo ra
Nguyên tắc 3 Nguyên tắc Pareto áp dụng để kiểm thử phần mềm.
Nguyên tắc Pareto ngụ ý rằng 80% của tất cả các lỗi phát hiện trong thử nghiệm có khả năng sẽ được theo dõi đến 20% của tất cả các thành phần chương trình Vấn đề là để cô lập các thành phần nghi ngờ và làm để triệt
để chúng
Nguyên tắc 4 Thử nghiệm nên bắt đầu ở nhần nhỏ và cuối cùng là ở phần
lớn
Trang 9Các cuộc thử nghiệm đầu tiên lên kế hoạch và thực hiện thường tập trung
về thành phần riêng lẻ Khi thử nghiệm tiến triển, tập trung chuyển trong một nỗ lực để tìm lỗi trong các cụm tích hợp của các thành phần và cuối cùng trong toàn bộ hệ thống
Nguyên tắc 5 Thử nghiệm đầy đủ là không khả thi.
Các số hoán vị đường dẫn cho ngay cả một chương trình có quy mô vừa là đặc biệt lớn.Vì lý do này, nó là không thể thực hiện mọi sự kết hợp các đường dẫn trong thử nghiệm Đó là có thể, tuy nhiên, để tương xứng với chương trình logic và để đảm bảo rằng tất cả các điều kiện trong việc thiết
kế thành phần cấp đã được thực hiện
3.2.5.Triển khai
Các hoạt động triển khai bao gồm ba hành động: giao hàng, hỗ trợ và thông tin phản hồi Một số nguyên tắc cơ bản đê triển khai phần mềm là :
Nguyên tắc 1 Mong muốn của khách hàng đối với các phần mềm phải
được quản lý
Thông thường, khách hàng muốn nhiều hơn những thứ sẽ cung cấp, và thất vọng xảy ra ngay lập tức Điều này dẫn đến phản hồi mà không phải
là sản xuất và ảnh hưởng đến tinh thần của đội
Nguyên tắc 2 Một gói giao hàng đầy đủ phải được lắp ráp và thử nghiệm.
Một đĩa CD-ROM hoặc phương tiện truyền thông chứa tất cả các phần mềm thực thi, hỗ trợ các file dữ liệu, tài liệu hỗ trợ, và các thông tin khác
có liên quan nên được lắp ráp và triệt để beta thử nghiệm với người sử dụng thực tế Tất cả các kịch bản cài đặt và hoạt động khác tính năng nên được thực hiện kỹ lưỡng trong nhiều tính toán khác nhau cấu hình (ví dụ, phần cứng, hệ điều hành, thiết bị ngoại vi, sắp xếp mạng) càng tốt
Nguyên tắc 3 Một chế độ hỗ trợ phải được thành lập trước khi phần mềm
được giao
Khách hàng mong muốn đáp ứng và thông tin chính xác khi một câu hỏi hoặc vấn đề phát sinh Nếu hỗ trợ không tốt thì khách hàng sẽ không hài lòng ngay lập tức Hỗ trợ nên có kế hoạch, tài liệu hỗ trợ cần được chuẩn
bị, và các cơ chế lưu trữ hồ sơ phù hợp nên được thiết lập để các nhóm phần mềm có thể tiến hành đánh giá phân loại của các loại hỗ trợ yêu cầu
Nguyên tắc 4 :Tài liệu giảng dạy phù hợp phải được cung cấp cho người
dùng
Nhóm nghiên cứu phần mềm cần cung cấp nhiều hơn các phần mềm riên
để hỗ trợ, xử lý sự cố và hướng dẫn cần được cung cấp một cách đầy đủ
Nguyên tắc 5 Buggy (các lỗi) cần được cố định đầu tiên rồi sửa ngay sau
đó
Trang 10Dưới áp lực thời gian, một số tổ chức phần mềm cung cấp gia tăng chất lượng thấp với một cảnh báo với khách hàng rằng lỗi "sẽ được sửa trong phiên bản tiếp theo."
3.3.Hiểu các yêu cầu
3.3.1.Kỹ thuật yêu cầu
Yêu cầu kĩ thuật là hàng loạt các nhiệm vụ và kĩ thuật dẫn đến một sự hiểu biết về
các yêu cầu Từ một quan điểm quá trình của phần mềm,yêu cầu kĩ thuật là một hành động công nghệ phần mềm chính mà bắt đầu trong suốt các hoạt động truyền thông và tiếp tục vào các hoạt động mô hình.Nó phải phù hợp với nhu vầu của quá trình,các dự án,sản phẩm và cả những người đang làm việc
❖ Sự khởi đầu: các dự án phần mềm bắt đầu khi doanh nghiệp xác định được dịch vụ
mới Các đối tượng liên quan( ví dụ: các nhà quản lý kinh doanh,tiếp thị,quản lý sản phẩm…).Tất cả thông tin này có thể thay đổi.Tại khởi động dự án , bạn thiết lập một sự hiểu biết cơ bản của vấn đề, mọi người muốn có một giải pháp , bản chất của giải pháp đó là mong muốn , và hiệu quả của truyền thông sơ kết, hợp tác giữa các bên liên quan khác và các nhóm phần mềm
❖ Sự khám phá: Nó có vẻ đơn giản đủ để yêu cầu khách hàng , người sử dụng và
người khác những gì về mục tiêu của hệ thống hoặc sản phẩm, là những gì được thực hiện , các hệ thống hoặc sản phẩm phù hợp với nhu cầu của doanh nghiệp, và cuối cùng , cách hệ thống hoặc sản phẩm đang được sử dụng trên một cơ sở ngày qua ngày Các vấn đề về sự biến động : Các yêu cầu thay đổi theo thời gian Để khắc phục những vấn đề này , bạn phải tiếp cận yêu cầu thu thập trong một tổ chức
❖ Xây dựng: Các thông tin thu được từ khách hàng trong thời gian khởi động , được
mở rộng và hoàn thiện trong xây dựng Nhiệm vụ này tập trung vào việc phát triển một mô hình yêu cầu tinh tế để xác định các khía cạnh khác nhau các chức năng phần mềm , hành vi, và thông tin Xây dựng được thúc đẩy bởi sự sáng tạo và tinh
tế của ý tưởng người dùng rằng miêu tả cách người dùng sẽ tương tác với hệ thống
❖ Sự đàm phán: khách hàng và người sử dụng yêu cầu nhiều hơn đối với nhà sản
xuất phần mềm, đưa nguồn lực kinh doanh hạn chế Nó cũng tương đối phổ biến cho khách hàng hoặc người sử dụng để đề xuất các mâu thuẫn yêu cầu , cho rằng phiên bản của họ là " Cần thiết cho nhu cầu đặc biệt của chúng tôi "Bạn có để hòa giải những xung đột thông qua một quá trình đàm phán Khách hàng ,người dùng,
và các bên liên quan khác được yêu cầu xếp hạng các yêu cầu và sau đó thảo luận xung đột ưu tiên
❖ Đặc điểm kĩ thuật: Trong bối cảnh các máy tính dựa trên hệ thống (và phần
mềm) , thuật ngữ đặc điểm kỹ thuật có nghĩa khác nhau đối với những người khác nhau Một đặc điểm kỹ thuật có thể là một người viết tài liệu, một tập các mô hình
đồ họa , một mô hình toán học chính thức, một bộ sưu tập các kịch bản sử dụng , một nguyên mẫu , hoặc bất kỳ sự kết hợp giữ chúng
❖ Xác nhận: Các sản phẩm công việc sản xuất như là một hệ quả của yêu cầu kỹ
thuật được đánh giá chất lượng trong bước xác nhận Các cơ chế yêu cầu xác nhận