Đề Cương Tự Luận Nhập môn Công nghệ phần mềm KHTN 2017

Đề Cương Tự Luận Nhập môn Công nghệ phần mềm trường đại học khoa học tự nhiên 2017 , Đề Cương Tự Luận Nhập môn Công nghệ phần mềm trường đại học khoa học tự nhiên 2017, Đề Cương Tự Luận Nhập môn Công nghệ phần mềm trường đại học khoa học tự nhiên 2017

Tuần 1: Tổng quan Phần mềm Định nghĩa: - Chương trình + tài liệu - Ln gắn với hệ thống cụ thể - Các sản phẩm phần mềm phát triển cho khách hàng cụ thể cho thị trường chung Phân loại : - Generic products (Sản phẩm dùng chung): Những hệ thống độc lập chào bán thị trường mua chúng VD: Microsoft Office, Photoshop - Customized products (Sản phẩm đặt hàng): Phần mềm phát triển cho khách hàng cụ thể để đáp ứng nhu cầu họ VD: Phần mềm điều khiển không lưu - Sự khác biệt: Sản phẩm dùng chung người phát triển hệ thống đặc tả họ định thực thay đổi Còn Sản phẩm đặt hàng khách hàng Tiêu chí: Maintanability (Tính bảo trì được): Có thể cải tiến phù hợp nhu cầu Dependability & Security (Tính tin cậy được): Độ tin cậy, an tồn & bảo mật Efficiency (Tính hiệu quả): khơng lãng phí tài nguyên Acceptability (Tính chấp nhận được): Ng sử dụng chấp nhận CNPM Định nghĩa: Là lĩnh vực liên quan đến khía cạnh sản xuất phần mềm Chi phí: - Chi phí phát triển: 60% - Chi phí kiểm thử : 40% Quy trình PM ĐN: Một chuỗi hoạt động để tạo sản phẩm phần mềm Đặc tả  Phát triển  Thẩm định  Cải tiến Thử thách chính: - Tính khơng đồng (hệ thống yêu cầu hệ phân tán qua mạng bao gồm nhiều loại thiết bị) - Sự thay đổi xã hội thương mại (Xã hội thương mại khơng ngừng thay đổi kinh tế phát triển công nghệ đời.) - Bảo mật & tin cậy (Vì phần mềm liên quan đến tất mặt đời sống) Các loại ứng dụng (8) : - Ứng dụng độc lập - Ứng dụng dựa vào giao dịch tương tác - Ứng dụng điều khiển nhúng - Hệ thống xử lý khối - Hệ thống giải trí - Hệ thống mơ & mơ hình hóa - Hệ thống thu thập liệu - Hệ thống hệ thống Nguyên tắc: - Tái sử dụng - Sử dụng quy trình - Hiệu - Yêu cầu đặc tả CNPM & Web Xu hướng tương lai Cloud computing Phụ thuộc: Trình duyệt Đạo đức nghề nghiệp Pháp luật Trung thực Trách nhiệm: - Bảo mật - Năng lực - Quyền sở hữu trí tuệ - Lạm dụng máy tính Một số câu hỏi thường gặp Công nghệ phần mềm gì? Cơng nghệ phần mềm lĩnh vực cơng nghệ liên quan đến tất khía cạnh việc sản xuất phần mềm từ giai đoạn đặc tả hệ thống đến giai đoạn bảo trì hệ thống sau đưa vào sử dụng Những hoạt động (activities) CNPM? Sự khác CNPM khoa học máy tính (computer science)? Khoa học máy tính (computer science) tập trung vào lý thuyết tảng CNPM liên quan đến thực tiễn việc phát triển phân phối sản phẩm phần mềm Sự khác CNPM công nghệ hệ thống (system engineering)? Công nghệ hệ thống (system engineering) gồm tất khía cạnh việc phát triển hệ thống máy tính bao gồm phần cứng, phần mềm quy trình CNPM phần quy trình chung Những thử thách mà công nghệ phần mềm phải đối mặt? Chi phí CNPM? Khoảng 60% chi phí phần mềm chi phí phát triển phần mềm, 40% chi phí dành cho kiểm thử phần mềm Đối với phần mềm đặt hàng, chi phí để cải tiến phần mềm lớn chi phí sản xuất phần mềm Kỹ thuật phương pháp CNPM tốt nhất? Tất dự án phần mềm phải quản lý phát triển cách chuyên nghiệp Các kỹ thuật phương pháp khác phù hợp với loại hệ thống khác Khơng có phương pháp tốt nhất! Quy trình phần mềm (software process) gì? Một chuỗi hoạt động để tạo sản phẩm phần mềm Có hoạt động chung cho tất quy trình phần mềm Tổng kết Công nghệ phần mềm lĩnh vực công nghệ liên quan đến tất khía cạnh việc sản xuất phần mềm Tiêu chí sản phẩm phần mềm tính bảo trì được, tính tin cậy được, tính hiệu tính chấp nhận Những hoạt động quy trình phần mềm đặc tả, phát triển, thẩm định cải tiến phần mềm Những khái niệm CNPM hồn tồn áp dụng cho tất loại phát triển hệ thống Có nhiều loại hệ thống khác loại cần công cụ kỹ thuật CNPM phù hợp để phát triển Bài 2: Quy trình phần mềm Khái niệm : tập có cấu trúc hoạt động cần thiết để phát triển hệ thống phần mềm Mơ hình Quy trình hoạch định sẵn quy trình linh hoạt - Các quy trình hoạch định sẵn (plan-driven process) quy trình mà tất hoạt động lên kế hoạch trước tiến độ thực đánh giá dựa vào kế hoạch -Trong quy trình linh hoạt (agile process), kế hoạch phát triển dễ dàng thay đổi quy trình để đáp ứng thay đổi yêu cầu khách hàng Thác nước (waterfall model) - Mơ hình hoạch định sẵn Các pha đặc tả phát triển phân biệt tách rời - Ưu điểm: • • • Dễ quản lý tiến độ Được sử dụng hệ thống lớn mà phát triển nhiều địa điểm khác Phối hợp cơng việc dễ dàng - Nhược điểm: • • Khó thích nghi thay đổi Khó khăn đáp ứng thay đổi yêu cầu người dùng Phát triển (incremental development) - Các pha đặc tả, phát triển thẩm định đan xen Có thể mơ hình hoạch định sẵn, mơ hình linh hoạt - Ưu điểm: • Giảm chi phí đáp ứng thay đổi yêu cầu khách hàng • • Dễ dàng lấy phản hồi từ khách hàng Phân phối triển khai phần mềm đến khách hàng nhanh - Nhược điểm • • Quy trình khơng rõ ràng Cấu trúc hệ thống có xu hướng bị giảm phần hệ thống thêm vào Tái sử dụng (reuse-oriented software engineering) - Hệ thống xây dựng từ component có sẵn Có thể hoạch định sẵn, linh hoạt - Các giai đoạn quy trình • • • • Phân tích component Bổ sung yêu cầu Thiết kế hệ thống với việc tái sử dụng Phát triển tích hợp - Các loại component: Web service, Package, COTS Xoắn ốc Boehm Quy trình biểu diễn đường xoắn ốc chuỗi hoạt động với bước quay lui Mỗi vòng lặp đường xoắn ốc biểu diễn pha quy trình Khơng có pha cố định đặt tả hay thiết kế, vòng lặp đường xoắn ốc chọn theo nhu cầu Rủi ro đánh giá rõ ràng giải suốt quy trình - Ưu điểm: • • • • Là phương pháp thực tế để phát triển hệ thống phần mềm lớn Giúp kỹ sư hiểu rõ tương tác tốt với nguy mức tiến hóa Cho phép áp dụng nguyên giai đoạn tiến hóa Giảm nguy trước trở thành vấn đề hệ thống - Nhược điểm: • • • Khơng phải “thuốc chữa bách bệnh” Khó khăn việc thuyết phục khách hàng phương pháp điều khiển Cần chuyên gia đánh giá nguy dựa vào chuyên gia để thành công Nếu nguy lớn không tìm quản lý được, vấn đề hệ thống xảy Các hoạt động Đặc tả: ĐN hệ thống làm - Quy trình cơng nghệ u cầu (requirements engineering process) • • • • Nghiên cứu khả thi (Feasibility study) Thu thập phân tích yêu cầu (Requirements elicitation and analysis) Đặc tả yêu cầu (Requirements specification) Thẩm định yêu cầu (Requirements validation) Thiết kế & cài đặt: ĐN tổ chức hệ thống & cài đặt hệ thống - Thiết kế Kiến trúc - Thiết kế Giao diện - Thiết kế Component - Thiết kế CSDL Kiểm định: Kiểm tra hệ thống đáp ứng mong muốn người dùng - Các giai đoạn kiểm thử phần mềm: • • • Kiểm thử phát triể n(Development or component testing) Kiểm thử hệ thống Kiểm thử người dùng Cải tiến: thay đổi hệ thống để đáp ứng thay đổi yêu cầu người dùng Thích nghi thay đổi Thay đổi yêu cầu - Là điều hiển nhiên dự án lớn - Thay đổi  Làm lại Giảm thiểu chi phí làm lại - Tránh thay đổi: dự đốn trước thay đổi xảy (VD: phát triển prototype) - Chấp nhận thay đổi: • • Chi phí thay đổi thấp Thường dùng mơ hình phân phối Nguyên PM - Là phiên hệ thống dùng để demo khái niệm thử tùy chọn thiết kế, tìm giải pháp cho vấn đề - Dùng trường hợp: • • • Thu thập yêu cầu thẩm định yêu cầu Tìm giải pháp phát triển thiết kế giao diện người dùng Chạy kiểm thử back-to-back - Lợi ích: • • • • • Cải thiện khả sử dụng hệ thống Thoả mãn tốt nhu cầu thực người dùng Cải thiện chất lượng thiết kế Cải thiện khả bảo trì hệ thống Giảm bớt nỗ lực phát triển Nguyên có phải để phát triển hệ thống hay không? Nguyên để phát triển hệ thống  cần loại bỏ Do: • • • • Khó điều chỉnh hệ thống để đáp ứng yêu cầu phi chức Nguyên thường không viết tài liệu Cấu trúc nguyên thường bị phá vỡ bị thay đổi nhanh Nguyên khơng đáp ứng tiêu chuẩn chất lượng mặt tổ chức So sánh Chuyển giao Phát triển dần dần? Phát triển • • • Phát triển phần hệ thống đánh giá phần trước tiến hành phát triển phần Được sử dụng phương pháp linh hoạt Đánh giá thực đại diện người sử dụng/khách hàng Chuyển giao • • Triển khai phần để sử dụng cho người dùng cuối Đánh giá thực tế Quy trình RUP (The Rational Unified Process) Khái niệm - Là quy trình tổng quát bắt nguồn từ UML Unified Software Development Process - Kết hợp khía cạnh ba mơ hình quy trình tổng qt - Thường mơ tả ba góc độ: Góc độ động, Góc độ tĩnh, Góc độ thực tiễn Các pha RUP: - Khởi động, Phát triển, Xây dựng, Chuyển tiếp Vòng lặp RUP - Lặp pha, Lặp qua pha Ưu điểm: - Phát triển phần mềm theo vòng lặp - Quản lý yêu cầu VD: Kiến trúc phân tầng hệ thống thông tin Tuần 10: Thiết kế & cài đặt Thiết kế hướng đối tượng sử dụng UML Phát triển hướng đối tượng - Phân tích hướng đối tượng: phát triển mơ hình đối tượng miền ứng dụng - Thiết kế hướng đối tượng: phát triển mơ hình hệ thống hướng đối tượng để cài đặt yêu cầu - Lập trình hướng đối tượng: thực hóa thiết kế hướng đối tượng sử dụng ngơn ngữ lập trình hướng đối tượng Đối tượng & Lớp đối tượng - Đối tượng thực thể có trạng thái tập thao tác hoạt động trạng thái - Lớp đối tượng sử dụng template cho đối tượng Các giai đoạn quy trình thiết kế - Định nghĩa ngữ cảnh tương tác ngồi hệ thống • • Mơ hình ngữ cảnh hệ thống (chỉ hệ thống khác môi trường hệ thống phát triển.) Mơ hình tương tác hệ thống (mô tả cách hệ thống tương tác với mơi trường Sử dụng use case để tương tác.) • • - Thiết kế kiến trúc hệ thống • • Sử dụng thông tin tương tác hệ thống môi trường để thiết kế kiến trúc hệ thống Kiến trúc mức cao weather Station • • Kiến trúc hệ thống thu thập liệu • - Nhận diện đối tượng • • • Các phương pháp nhận diện: phân tích ngữ pháp, kịch & nhận diện đối tượng hữu hình có miền ứng dụng Các lớp đối tượng • - Phát triển mơ hình thiết kế • • Mơ hình tĩnh: mô tả cấu trúc tĩnh hệ thống lớp đối tượng quan hệ VD: Hệ thống ( Mơ hình tĩnh) • • Mơ hình động: mơ tả tương tác động đối tượng - Đặc tả giao diện đối tượng Thiết kế mẫu (Mẫu Observe) Mô tả: tách rời biểu diễn khỏi đối tượng Mơ tả vấn đề: Sử dụng tình nhiều dạng hiển thị Mô tả giải pháp: Các đối tượng trừu tượng chứa thao tác sử dụng tình Hệ quả: Khó tối ưu Các vấn đề cài đặt Tái sử dụng - Các mức tái sử dụng • • • • Trừu tượng: Tái sử dụng kiến thức thiết kế mức trừu tượng Đối tượng: Sử dụng trực tiếp đối tượng từ thư viện có sẵn Component: tập hợp đối tượng lớp đối tượng mà ta tái sử dụng hệ thống ứng dụng Hệ thống: Tái sử dụng toàn hệ thống ứng dụng - Chi phí • • • Tìm kiếm & đánh giá phần mềm Chỉnh sửa & cấu hình lại component Tích hợp component vào hệ thống Quản lý cấu hình - Mục tiêu: Hỗ trợ quy trình tích hợp hệ thống cho • • • Tất ng phát triển Truy cập tài liệu & mã nguồn dự án Tìm thay đổi thực Biên dịch & liên kết component - Hoạt động • • • Quản lý phiên bản: theo dõi phiên khác component Tích hợp hệ thống: giúp người phát triển định nghĩa phiên component sử dụng Theo dõi vấn đề: cho phép người dùng report bugs vấn đề khác Phát triển host-target - Hầu hết phần mềm phát triển máy tính (host) chạy máy tính khác (target)  Ta đề cập đến tảng (platform) phát triển tảng thực thi - Bộ công cụ tảng phát triển - IDEs - Nhân tố triển khai Component/ Hệ thống Tuần 11: Thiết kế giao diện người dùng Các vấn đề thiết kế giao diện người dùng Nhân tố người (hạn chế ghi nhớ ngắn hạn, ng mong muốn kiểu tương tác ) Nguyên tắc (xem xét nhu cầu, kinh nghiệm & khả ng dùng ) Nguyên lý thiết kế • • • • • • Thân thiện với người dùng Nhất quán Ít bất ngờ Có thể khơi phục Hướng dẫn người dùng Đa dạng người dùng Hai vấn đề cần quan tâm thiết kế hệ thống tương tác • • Người dùng cung cấp thông tin cho hệ thống cách nào? Hệ thống biểu diễn thông tin đến người dùng nào? Các kiểu tương tác Biểu diễn thông tin: trực tiếp đồ họa, tĩnh động Hiển thị màu Thơng báo lỗi Quy trình thiết kế giao diện người dùng Phân tích người dùng : Hiểu người dùng làm với hệ thống - Kịch tương tác  Yêu cầu • • • Phân tích tác vụ: Mơ hình hóa bước để hồn thành tác vụ Phỏng vấn: Hỏi người sử dụng công việc họ làm Ethnography: Quan sát người sử dụng nơi làm việc Xây dựng prototype : Xây dựng chuỗi prototype để thử nghiệm - Mục tiêu: cho phép người dùng có trải nghiệm trực tiếp với giao diện - Trên giấy (qua phản hồi người dùng tạo phần mềm) - Trên phần mềm • • • Xây dựng kịch Lập trình trực quan Xây dựng dựa vào Internet Đánh giá giao diện: Thử nghiệm prototype với người dùng - Các kỹ thuật • • • • Câu hỏi lấy phản hồi Quay video Cài mã thu thập thông tin Cung cấp chức phản hồi - Các thuộc tính • • • • • Tính học Tốc độ thao tác Tính chịu lỗi Khả khơi phục Tính tương thích Tuần 12 + 13: Kiểm thử Khái niệm Là phần trình thẩm định (phần mềm phải thỏa mãn yêu cầu người dùng) & kiểm định (phần mềm phải tương thích với đặc tả) Có thể có mặt lỗi, khơng chương trình khơng có lỗi !!! Mục tiêu: - Đảm bảo chương trình chạy yêu cầu - Tìm tình phát sinh lỗi Một mơ hình quy trình kiểm thử phần mềm Cách thực hiện: - (1) Chạy phần mềm vs liệu nhân tạo  dựa vào kết  (2) - (2) Tìm lỗi, bất thường thơng tin thuộc tính Hỗ trợ tra - Phân tích biểu diễn tĩnh Các giai đoạn Kiểm thử phát triển phần mềm -Kiểm thử đơn vị (unit testing) : Là quy trình kiểm thử component riêng lẻ • Kiểm thử lớp đối tượng • • Kiểm thử tự động Kiểm thử phân vùng -Kiểm thử component (component testing) : nhằm giao diện component thỏa mãn đặc tả • Kiểm thử giao diện • -Kiểm thử hệ thống (system testing): Kiểm tra component tương thích với nhau, tương tác chuyển liệu, thời điểm thông qua giao diện chúng • Kiểm thử dựa vào use-case Phát triển theo hướng kiểm thử - Là phương pháp việc phát triển mã nguồn kiểm thử đan xen - Kiểm thử hồi quy : Là việc kiểm thử hệ thống để kiểm tra thay đổi không phá vỡ việc cài đặt mã nguồn trước Kiểm thử release - Là quy trình kiểm thử release hệ thống, sử dụng bên đội ngũ phát triển hệ thống - So sánh Kiểm thử release kiểm thử hệ thống Kiểm thử release hình thức kiểm thử hệ thống Điểm khác quan trọng: • • Một nhóm tách biệt khơng tham gia vào việc phát triển chịu trách nhiệm kiểm thử release Kiểm thử hệ thống nhóm phát triển nên tập trung vào việc tìm lỗi hệ thống (defect testing) • Mục tiêu kiểm thử release để chứng tỏ hệ thống đáp ứng yêu cầu đủ tốt để đưa sử dụng bên (validation testing) - Kiểm thử dựa vào yêu cầu: Gồm việc kiểm tra yêu cầu phát triển test cho u cầu Ví dụ: yêu cầu hệ thống MHC-PMS: • • Giả sử bệnh nhân dị ứng với loại thuốc đó, kê đơn loại thuốc đó, hệ thống phải đưa cảnh báo đến người dùng hệ thống Nếu người kê đơn chọn thuốc mà bỏ qua cảnh báo dị ứng, họ phải đưa lý lại bỏ qua cảnh báo - Performance testing: Stress testing hình thức performance testing hệ thống cố tình bị q tải để kiểm tra hành vi lỗi Kiểm thử người dùng - Là giai đoạn người dùng cung cấp đầu vào đưa lời khuyên cho việc kiểm thử hệ thống - Kiểm thử người dùng cần thiết, chí hệ thống rõ ràng kiểm thử release tiến hành - Các loại kiểm thử người dùng • • • • Alpha testing: Người dùng phần mềm làm việc với nhóm phát triển để kiểm thử phần mềm Beta testing: Một release có sẵn cho phép người dùng sử dụng chúng lấy kinh nghiệm tìm lỗi Acceptance testing: Khách hàng kiểm thử hệ thống để định xem hệ thống có chấp nhận để triển khai đến môi trường làm việc khách hàng hay khơng Quy trình Acceptance testing: • Tuần 14: Phát triển phần mềm linh hoạt Các phương pháp linh hoạt Đặc điểm việc phát triển phần mềm nhanh - Đặc tả, thiết kế cài đặt đan xen - Hệ thống phát triển chuỗi phiên stakeholder tham gia vào việc đánh giá phiên - Giao diện người dùng thường phát triển sử dụng IDE công cụ đồ họa Phạm vi ứng dụng: sản phẩm nhỏ vừa, sản phẩm đặt hàng khơng có nhiều quy tắc bị ảnh hưởng quy định bên ngồi Hai câu hỏi cần xem xét: • • Các hệ thống phát triển phương pháp linh hoạt có bảo trì khơng, nhấn mạnh quy trình phát triển ta giảm thiểu tài liệu mang tính hình thức? Các phương pháp linh hoạt có hiệu cho việc cải tiến hệ thống để trả lời yêu cầu thay đổi khách hàng không? Phát triển hoạch định sẵn linh hoạt Phát triển hoạch định sẵn • • • • Dựa vào giai đoạn phát triển tách biệt Đầu giai đoạn lên kế hoạch trước Không thiết phải mơ hình thác nước, phương pháp phát triển Vòng lặp xảy bên hoạt động Phát triển linh hoạt • • Đặc tả, thiết kế, cài đặt kiểm thử đan xen Đầu từ quy trình phát triển định thông qua việc thương lượng suốt trình phát triển phần mềm Câu hỏi: Có cần đặc tả thiết kế chi tiết trước chuyển sang cài đặt hay khơng? Nếu có, ta cần sử dụng phương pháp hoạch định sẵn Chiến lược chuyển giao có thực tế khơng? Nếu có, xem xét việc sử dụng phương pháp linh hoạt Hệ thống phát triển lớn đến mức nào? Phương pháp linh hoạt hiệu hệ thống phát triển với đội ngũ nhỏ làm việc nơi giao tiếp thân mật với Hệ thống lớn đòi hỏi đội ngũ phát triển lớn  sử dụng phương pháp hoạch định sẵn Loại hệ thống phát triển? Phương pháp hoạch định sẵn thích hợp với hệ thống đòi hỏi lượng phân tích lớn trước cài đặt Thời gian sử dụng hệ thống? Các hệ thống mong đợi sử dụng lâu  cần nhiều tài liệu thiết kế để truyền đạt ý định ban đầu người phát triển hệ thống cho nhóm hỗ trợ Cơng nghệ sẵn có để hỗ trợ phát triển hệ thống? Phương pháp linh hoạt dựa vào công cụ tốt để ghi lại dấu vết việc thiết kế liên tục thay đổi Đội ngũ phát triển tổ chức nào? Đội ngũ phát triển phân tán phần việc phát triển gia cơng bên ngồi  cần phát triển tài liệu thiết kế để giao tiếp nhóm với Các vấn đề văn hóa tổ chức có ảnh hưởng đến phát triển hệ thống hay không? Các tổ chức cơng nghệ truyền thống có văn hóa việc phát triển hoạch định sẵn, chuẩn công nghệ Trình độ người thiết kế người lập trình nhóm phát triển tốt đến đâu? Phương pháp linh hoạt đòi hỏi kỹ cao phương pháp hoạch định sẵn Trong phương pháp hoạch định sẵn: người lập trình việc chuyển thiết kế chi tiết thành mã nguồn 10.Hệ thống có chịu chi phối quy định từ bên ngồi khơng? Nếu hệ thống phải duyệt nhân tố bên è cần tài liệu chi tiết Extreme programming Được xem phương pháp linh hoạt tiếng sử dụng rộng rãi Có cách tiếp cận “cực đoan” việc phát triển vòng lặp • • • Các phiên xây dựng vài lần ngày; Các phần phân phối đến khách hàng hai tuần lần; Tất test phải chạy phiên phiên chấp nhận test thành cơng Vòng lặp tạo release XP Khó khăn kiểm thử XP - Người lập trình thích lập trình kiểm thử • Thường tắt việc viết test - Một số test khó viết theo kiểu tăng dần • Ví dụ: giao diện người dùng phức tạp, thường khó viết unit test cho đoạn mã cài đặt việc hiển thị luồng chuyển tiếp hình - Khó đánh giá tính đầy đủ test • Bộ test khơng thể bao phủ hết tất Quản trị dự án linh hoạt Scrum : Là phương pháp tổng quát - Tập trung vào quản lý việc phát triển vòng lặp nguyên lý phương pháp linh hoạt - Lợi ích Scrum • • • • • Sản phẩm chia thành phần nhỏ dễ hiểu dễ quản lý Các yêu cầu không ổn định khơng làm chậm trễ tiến độ Tồn đội thấy thứ è giao tiếp nhóm cải thiện Khách hàng nhận phần hạn gởi phản hồi sản phẩm Niềm tin khách hàng đội phát triển tăng lên văn hóa tích cực tạo người mong muốn dự án thành công Mở rộng quy mô phương pháp linh hoạt Việc mở rộng quy mô phương pháp linh hoạt gồm: • • điều chỉnh phương pháp để phù hợp với dự án lớn tổ chức lớn sử dụng phương pháp để phát triển ứng dụng Scaling out scaling up • • ‘Scaling up’ :sử dụng phương pháp linh hoạt để phát triển hệ thống lớn ‘Scaling out’: cách phương pháp linh hoạt giới thiệu đến tổ chức có nhiều năm kinh nghiệm sản xuất phần mềm ... nhắc - VD: Đặc tả dùng bảng (dùng hỗ trợ ngôn ngữ tự nhiên) - VD: Các quy trình cơng nghệ u cầu ĐN: Tập hợp tác vụ kỹ thuật để hiểu rõ yêu cầu gọi công nghệ yêu cầu Hoạt động: - Nghiên cứu khả... phát triển hệ thống Có nhiều loại hệ thống khác loại cần công cụ kỹ thuật CNPM phù hợp để phát triển Bài 2: Quy trình phần mềm Khái niệm : tập có cấu trúc hoạt động cần thiết để phát triển hệ thống... Rational Unified Process) Khái niệm - Là quy trình tổng quát bắt nguồn từ UML Unified Software Development Process - Kết hợp khía cạnh ba mơ hình quy trình tổng qt - Thường mơ tả ba góc độ: Góc độ động,