Cong Nghe Phan Mem

Mở cơ hội học tập cho mọi người Trung tâm đào tạo E-Learning
NHẬP MÔN
CÔNG NGHỆ PHẦN MỀM
VCLASS 01
TỔNG QUAN CÔNG NGHỆ PHẦN MỀM

043.623.0853
anhtt@ehou.edu.vn
Giảng viên chuyên môn: ThS. Lê Hữu Dũng

Trường Đại học Mở Hà Nội Trung tâm Đào tạo E-Learning
Học phần: NHẬP MÔN CÔNG NGHỆ PHẦN MỀM
1
Tóm lược môn học/chủ đề
Hướng
3 dẫn chi tiết
Thảo luận,giải đáp thắc mắc
Learning Opportunity for All NHẬP MÔN CÔNG NGHỆ PHẦN MỀM (IT40) – Gv: ThS. Lê Hữu Dũng
1.1 Phần mềm là gì?
Khái niệm:
[3] “Computer programs and associated documentation. Software products may
be developed for a particular customer or may be developed for a general
market”
[IEEE] “Computer programs, procedures, and possibly associated
documentation and data pertaining to the operation of a computer system.”
Phần cứng và hạ
tầng công nghệ
càng phát triển
thì các bài toán mà
phần mềm phải giải
quyết càng phức
tạp
31/12/2020
Learning Opportunity for All NHẬP MÔN CÔNG NGHỆ PHẦN MỀM (IT40) – Gv: ThS. Lê Hữu Dũng4/24
• Các đặc trưng của phần mềm
McCall’s software quality factors [2.pg509]
Đặc tính hoạt động (Operation)
1. Tính đúng đắn (Correctness)

2. Tính tin cậy(Reliability)
3. Tính khả dụng(Usability)
4. Tính toàn vẹn(Integrity)
5. Tính hiệu quả(Efficiency)
Đặc tính Chuyển đổi (Transition)
6. Tính liên tác(Interoperability)

7. Tính khả chuyển(Portability)
8. Tính tái dụng(Reusability)
Đặc tính Sửa đổi (Revision)
9. Tính bảo trì(Maintainability)

10. Tính linh hoạt(Flexibility)
11. Tính kiểm thử được(Testability)
1.2 Công nghệ phần mềm là gì?
 1.2.1. Software crisis (khủng hoảng về phần

mềm):
là khái niệm được sử dụng từ những ngày đầu của
khoa học máy tính để chỉ sự khó khăn khi tạo ra
những chương trình máy tính hữu dụng và hiệu quả
trong thời gian cần thiết
Nguyên nhân:
Dự án vượt dự toán
Dự án Quá thời hạn
Phần mềm Không hiệu quả
Phần mềm chất lượng thấp
Phần mềm không đáp ứng yêu cầu
Dự án không thể quản lý và code không thể bảo trì
Phần mềm không thể bàn giao
1.2.2 Định nghĩa:

“The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of
engineering to software” (IEEE)
 CNPM là giải pháp cho Software Crisis
31/12/2020
Learning Opportunity for All
12/24
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM (IT40) – Gv: ThS. Lê Hữu Dũng
1.3 Các giai đoạn phát triển phần

mềm
31/12/2020
13/24
1.4 Các quá trình bổ trợ

cho phát triển phần mềm
Project Management
Quality Assurance
31/12/2020
14/24
NHẬP MÔN
CÔNG NGHỆ PHẦN MỀM
VCLASS 02
QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

043.623.0853
anhtt@ehou.edu.vn

Học phần: NHẬP MÔN CÔNG NGHỆ PHẦN MỀM
1
Tóm lược môn học/chủ đề
Hướng
3 dẫn chi tiết
Thảo luận,giải đáp thắc mắc
Nội dung
➢ Một số quy trình cơ bản

➢ Quy trình RUP
➢ Quy trình phát triển linh hoạt
2.1 Một số quy trình cơ bản
◼Waterfall
◼Prototyping
◼Incremental
◼Spiral
◼V-Model
INITIAL 2.1.1.Waterfall
2.1.2. Prototyping
2.1.3. Incremental
2.1.4. Spiral
2.1.5 Mô hình chữ V (V-Model)
2.2 Rational Unified Process (RUP)
◼Là 1 qui trình công nghệ cho phát triển phần mềm
(Software Engineering Process).
◼Cung cấp cách tiếp cận có kỷ luật để phân công
nhiệm vụ và trách nhiệm trong một tổ chức.
◼Mục tiêu: đảm bảo sản xuất phần mềm chất
lượng cao đáp ứng nhu cầu của người dùng cuối,
trong thời gian và ngân sách dự đoán được.
◼Là hướng dẫn để sử dụng UML một cách hiệu quả
RUP hỗ trợ đáp ứng 6 vấn đề thực tiễn
➢Phát triển lặp

➢Quản lý yêu cầu
➢Sử dụng các thành phần trong phát triển
➢Mô hình hóa trực quan
➢Kiểm định chất lượng
➢Kiểm soát sự thay đổi
Qui trình RUP được tổ chức theo 2 chiều:

Công việc (Workflows)
và thời gian (Phases)
RUP: Các pha và các lần lặp [*:p4-7]

◼Các pha:
Inception: Khởi đầu
Elaboration: Phác thảo
Contruction: Xây dựng
Transition: Chuyển giao
◼Mỗi pha trong RUP có thể được chia nhỏ thành các lần lặp mà
mỗi lần đó sẽ tạo ra 1 sản phẩm (bản nội bộ hoặc phát hành)
theo cơ chế tăng tiến
[*]Rational Unified Process Best Practices for Software

Development Team. Rational Software White Paper, 2005.
RUP: Các công việc [*: p10-14]
1. Mô hình hóa nghiệp vụ 7. Quản lý dự án (Project

(Business Modeling) Management)
2. Xác định yêu cầu 8. Quản lý cấu hình và
(Requiments) sự thay đổi
3. Phân tích & Thiết kế (Configuration &
(Analysis & Design) Change Management)
4. Thi hành 9. (Thiết lập) Môi trường
(Implementation)
5. Kiểm thử (Test)
6. Phân phối
(Deployment)
RUP: Sản phẩm RUP
◼Được cung cấp gồm:

Tài nguyên trên Web (hướng dẫn, mẫu biểu, …)
Microsoft Project Plan
Công cụ phát triển (để tùy biến RUP)
Sách viết về RUP ("Rational Unified Process — An
Introduction", by Philippe Kruchten, published by
AddisonWesley)
◼http://sce.uhcl.edu/helm/rationalunifiedprocess/process/templat
es.htm
Thảo luận chung

043.623.0853
Chúc Anh/chị học tập tốt

anhtt@ehou.edu.vn
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM
VCLASS 03
Đặc tả yêu cầu phần mềm

043.623.0853
anhtt@ehou.edu.vn
Nội dung
1. Khái niệm
2. Nghiên cứu khả thi
3. Mục đích sử dụng SRS
4. Sự cần thiết của SRS
5. Phân loại yêu cầu
6. Thế nào là 1 SRS tốt
7. Thành phần của 1 SRS
3.1 Khái niệm
Yêu cầu (Requirement) là gì:

Một yêu cầu là một tuyên bố về những gì hệ thống phải làm hoặc những đặc
tính cần thiết mà nó phải có.
LÊ HỮU DŨNG
02/03/2021
3/245
[5], [IEEE]:
A requirement is:
 A condition or capability needed by a stakeholder to solve a problem or achieve
an 1 objective.
 A condition or capability that must be met or possessed by a solution or solution
component to satisfy a contract, standard, specifcation, or other formally
imposed documents.
 A documented representation of a condition or capability as in (1) or (2).
LÊ HỮU DŨNG
02/03/2021
4/245
◼ Sản phẩm của pha Xác định yêu cầu: Văn bản đặc tả yêu cầu phần mềm (SRS,
Software Requirement Specification)
◼ SRS: một bản đặc tả đầy đủ về những gì mà hệ thống dự kiến cần làm (WHAT, not
HOW)
3.2. Nghiên cứu khả thi
◼ Thực hiện trước khi phân tích, xác định yêu cầu.
◼ Nhằm trả lời:
 Có nên phát triển hệ thống này không?
 Cần nguồn lực như thế nào?
 Phải liên tác với những hệ thống nào?
3.3. Mục đích sử dụng SRS
◼ SRS thể hiện sự thống nhất cơ bản giữa người dùng và người cung cấp (phần mềm)
◼ SRS là
 Trung gian kết nối hiểu biết, đặc tả nhu cầu của người dùng mà các bên liên
quan đều có thể hiểu được (một cách thống nhất)
3.4. Sự cần thiết của SRS
◼ Giúp người dùng hiểu được những gì họ cần

◼ SRS cung cấp căn cứ cho việc xác nhận sản phẩm cuối cùng:
 Hiểu rõ về những gì được trông đợi
 Xác nhận “phần mềm đáp ứng đúng SRS”
◼ Chất lượng SRS ảnh hưởng tới chất lượng phần mềm
◼ SRS tốt giúp giảm chi phí phát triển phần mềm
3.5. Phân loại yêu cầu
LÊ HỮU DŨNG
02/03/2021
9/245
 Yêu cầu chức năng  Yêu cầu phi chức năng:

 Hệ thống/từng thành phần, là những đặc điểm mà hệ
cá nhân thuộc hệ thống thống nên có
phải/cần làm gì?  Tin cậy (Reliability)
 Hiệu năng (Performance)
 Hữu dụng (Usability)
 Bảo mật (Security)
 Tương thích
(Compatibility/ inter-
operability)
 Khả năng bảo trì
(Maintainability)
 Khả chuyển (Portability)
 Văn hóa
 Đáp ứng Pháp luật/Qui
định
LÊ HỮU DŨNG
02/03/2021
Learning Opportunity for All NHẬP MÔN CÔNG NGHỆ PHẦN MỀM (IT40) – Gv: ThS. Lê Hữu Dũng 10
3.6. Thế nào là 1 SRS tốt?[*]
◼ Chính xác (Correct) ◼ Có thứ tự (Ranked)

◼ Không mập mờ ◼ Xác minh được
(Unambiguos) (Verifiable)
◼ Đầy đủ (Complete) ◼ Chỉnh sửa được
◼ Nhất quán (Modifiable)
(Consistent) ◼ Truy vết được
(Traceable)
[*] IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1998 – 4.3
3.7. Thành phần của SRS
◼ Cấu trúc SRS được chia làm 3 phần:
 Introduction (Giới thiệu)
 Overall description (mô tả tổng thể)
 Specific requirement (đặc tả yêu cầu)
3.7. Thành phần của SRS (tiếp)
Giới thiệu Mô tả tổng thể
Mục đích Quan điểm về sản

phẩm
Phạm vi
Các chức năng
ĐỊnh nghĩa, từ & chữ
Đặc điểm người dùng
viết tắt
Ràng buộc
Tài liệu tham khảo ảnh: IEEE Recommended Practice for
Các giả định và phụ Software Requirements Specifications
Tổng quan thuộc
3.7. Thành phần của SRS (tiếp)

◼ Đặc tả yêu cầu:
 Giao diện bên ngoài
 Yêu cầu chức năng
 Yêu cầu hiệu năng
 Ràng buộc thiết kế
 Thuộc tính hệ thống
phần mềm
 Yêu cầu khác
043.623.0853
Chúc Anh/chị học tập tốt

anhtt@hou.edu.vn
VCLASS 04
Thiết kế phần mềm

043.623.0853
anhtt@ehou.edu.vn
Nội dung
1. Thiết kế phần mềm là gì?

2. Các phương pháp thiết kế
3. Thiết kế kiến trúc phần mềm
4. Thiết kế giao diện người dùng
1. Thiết kế phần mềm là gì?
◼ Thiết kế phần mềm là 1 tiến trình nhằm chuyển đổi yêu cầu của người dùng sang
một số dạng phù hợp giúp người lập trình thực hiện được công việc (lập trình) của
mình để tạo ra phần mềm.
◼ Các mức độ thiết kế phần mềm:
 Thiết kế kiến trúc (Architechtural Design)
 Thiết kế mức cao (High-level Design)
 Thiết kế chi tiết (Detailed Design)
◼ Đầu ra của thiết kế phần mềm sẽ được sử dụng cho quá trình xây dựng và kiểm thử
nên việc đánh giá một thiết kế có phù hợp hay không rất quan trọng, nếu một thiết kế
sai sẽ dẫn đến tất cả các quá trình sau đó cũng sai và cần phải chỉnh sửa nếu thiết
kế được chỉnh sửa
2. Các phương pháp thiết kế
◼ Thiết kế hướng chức năng

◼ Thiết kế hướng dữ liệu
◼ Thiết kế hướng đối tượng
2.1. Thiết kế Hướng chức năng
◼ Thiết kế hướng chức năng là một cách tiếp cận thiết kế phần mềm trong đó bản thiết
kế được phân rã thành một bộ các mô-đun được tác động lẫn nhau, mà mỗi mô-đun
đáp ứng một chức năng xác định.
◼ Thiết kế hướng chức năng: thông tin trạng thái của hệ thống không được che dấu. →
dễ xảy ra xung đột khi dữ liệu bị thay đổi ngoài ý muốn.
◼ Thiết kế hướng chức năng thích hợp cho những hệ thống cỡ nhỏ và đơn giản.
2.2. Thiết kế Hướng dữ liệu
◼ Là phương pháp thiết kế tập trung trên dữ liệu của hệ thống

◼ Các xử lý cần thiết được xác định theo các đối tượng dữ liệu đã được định danh.
◼ Khi cấu trúc dữ liệu thay đổi, các xử lý và thuật toán liên quan cũng phải thay đổi
theo
2.3. Thiết kế Hướng đối tượng
◼ Hệ thống được tiếp cận như một bộ các đối tượng, phân tán, mỗi đối tượng có
những thông tin trạng thái riêng của nó. Các đối tượng là độc lập, sẵn sàng thay đổi
mà không ảnh hưởng tới các đối tượng khác. Các đối tượng tương tác với nhau
bằng cách truyền các thông điệp
◼ Các tính chất

 Tính bao gói, che giấu dữ liệu
 Tính kế thừa
 Tính trừu tượng
 Tính đa hình
3. Thiết kế kiến trúc phần mềm
◼ Bản thiết kế kiến trúc là phiên bản trừu tượng nhất về hệ thống. Nó xác định phần
mềm như là một hệ thống với nhiều thành phần (components) tương tác với nhau.
◼ Một kiến trúc phần mềm là tập hợp các cấu trúc cần thiết để suy luận về hệ thống,
trong đó bao gồm các yếu tố phần mềm, mối quan hệ giữa chúng và đặc tính của cả
hai
◼ Một số Kiểu kiến trúc

 Kiến trúc thường (VD: phân tầng, pipes and filter, blackboard)
 Các hệ thống phân tán (VD: client- server, three- tiers, broker)
 Các hệ thống tương tác (VD: MVC, Presentation- Abstraction- Control, WPF)
 Các hệ thống mô phỏng (VD: microkernel, reflection)
 Các kiểu khác (VD: batch, interperters, process control, rule- based)
◼ Lựa chọn kiến trúc:

 Thiết kế kiến trúc là một quá trình sáng tạo nhằm đáp ứng các yêu cầu trên cơ
sở kết hợp các hiểu biết về các kiểu kiến trúc đã biết.
 Các yêu cầu phi chức năng có thể là cơ sở cho sự lựa chọn kiến trúc:
◼ Tính Hiêu năng
◼ Tính Bảo mật
◼ Tính khả dụng
◼ Tính bảo trì
3.1. Kiến trúc phân lớp
◼ Mẫu phân lớp xác định các lớp (nhóm các mô-đun cung cấp một tập hợp dịch vụ gắn
kết) và mối quan hệ được phép sử dụng một chiều giữa các lớp.
 Ưu điểm: tận dụng được các đặc điểm của phương pháp hướng đối tượng, có
khả năng mở rộng
 Nhược điểm: tăng kích cỡ của phần mềm
3.2. Kiến trúc kiểu đường ống
◼ Dữ liệu được chuyển đổi từ đầu vào bên ngoài của hệ thống thành đầu ra thông qua
một loạt các phép biến đổi được thực hiện bởi các bộ lọc (Filter) của hệ thống được
kết nối bằng đường ống (Pipe).
◼ Đường ống nối các cổng đầu ra của bộ lọc với các cổng đầu vào của bộ lọc. Các bộ
lọc được kết nối phải thống nhất về loại dữ liệu được truyền dọc theo đường ống kết
nối.
3.3. Kiến trúc kiểu hướng sự kiện
◼ Các yêu cầu dịch vụ do khách hàng tạo sẽ đến dưới dạng các sự kiện. Chúng được
xếp hàng đợi, và sau đó được chuyển hướng đến một trình xử lý sự kiện thích hợp
theo một số chính sách ứng dụng.
◼ Ưu điểm: khả năng mở rộng cao
◼ Nhược điểm: hiệu suất và khả năng phục hồi thấp
3.3. Kiến trúc kiểu tương tác (MVC)
◼ Mẫu MVC chia chức năng hệ thống thành ba thành phần: mô hình, chế độ xem và bộ
điều khiển làm trung gian giữa mô hình và chế độ xem.
◼ Ưu điểm: tách biệt nhiệm vụ giữa các thành phần
◼ Nhược điểm: sự phức tạp không đáng có với phần mềm đơn giản
4. Thiết kế giao diện người dùng

◼ Thiết kế giao diện người dùng là một phần quan trọng quá trình thiết kế phần mềm.
Thiết kế giao diện và xử lý tương tác với người sử dụng là một yếu tố quan trọng ảnh
hưởng đến việc sử dụng phần mềm.
◼ Sản phẩm thiết kế giao diện phải làm sao để phù hợp với kĩ năng, kinh nghiệm và
mong đợi từ phía người sử dụng phần mềm.
4.1. Nguyên tắc cơ bản

trong thiết kế giao diện
1. Dễ học
2. Quen thuộc
3. Nhất quán
4. Không gây bất ngờ
5. Khôi phục được
6. Phản hồi tốt, kịp thời
7. Đa dạng (trong khả năng tiếp cận)
4.2. Quy trình thiết kế giao diện
1. Đặc tả yêu cầu giao

diện
2. Nghiên cứu, phân
tích người dùng
3. Phân tích nhiệm vụ
4. Thiết kế
5. Kiểm thử (Đo lường,
đánh giá)
VCLASS 05
Lập trình và kiểm thử phần mềm

043.623.0853
anhtt@ehou.edu.vn
Nội dung
1. Lập trình
1. Khái niệm
2. Các phương pháp lập trình
3. Quản lý phiên bản mã nguồn
2. Kiểm thử phần mềm
1. LẬP TRÌNH
1.1 Khái niệm
◼ Lập trình là việc lập trình viên sử dụng các ngôn ngữ lập trình và phần mềm hỗ trợ
để viết ra những đoạn code theo thuật toán để tạo ra những phần mềm/ứng dụng
chạy trên các thiết bị (máy tính, điện thoại,.. ) nhằm đáp ứng một nhu cầu nào đó của
con người
◼ VD:
 Lập trình ứng dụng
 Lập trình Game
 Lập trình nhúng
 …
1.2. Các phương pháp lập trình
◼ Lập trình tuần tự

◼ Lập trình hướng cấu trúc
◼ Lập trình hướng đối tượng
◼ Lập trình hướng dịch vụ
1.2.1. Lập trình tuần tự
◼ Giải quyết các bài toán đơn giản với số ít dòng lệnh thực hiện tuần tự.
◼ Nhược điểm:
 Gặp khó khăn với bài toán phức tạp
 Không tái sử dụng được
1.2.2. Lập trình hướng cấu trúc
◼ Bài toán phức tạp được phân rã thành các bài toán đơn giản hơn. Việc phân rã được
lặp lại cho đến khi thu được bài toán đủ nhỏ để lập trình.
◼ Mỗi bài toán nhỏ được giải quyết bởi 1 đơn vị chương trình (chương trình con) dạng
hàm hay thủ tục. Các chương trình con được kết hợp lại để giải quyết bài toán ban
đầu.
◼ Chương trình con có thể nhận vào các tham số (tham biến, tham trị), có thể trả lại
các giá trị.
◼ Ưu điểm:
 Tiếp cận đơn giản hóa
 Có thể tái sử dụng các chương trình con
 Không bảo vệ được dữ liệu khỏi các thay đổi ngoài ý muốn trong các chương
trình con.
 Thay đổi các chương trình con có thể làm ảnh hưởng đến toàn bộ chương trình
1.2.3. Lập trình Hướng đối tượng
◼ Bài toán được tiếp cận như là mối quan hệ của các đối tượng
◼ Các đối tượng có thông tin (thuộc tính) và hành động (phương thức), có cơ chế bao
gói, che giấu dữ liệu.
◼ Các đối tượng tương tác với nhau thông qua cơ chế truyền thông điệp.
◼ Có khả năng:
 Bao gói, che giấu dữ liệu
 Kế thừa
 Trừu tượng hóa
 Đa hình
◼ Ưu điểm:
 Bảo vệ được dữ liệu
 Có khả năng tái sử dụng
 Có khả năng nâng cấp với ít ảnh hưởng
 Số lượng mã tăng ở những bài toán đơn giản
 Có sự trùng lặp, nhập nhằng (nếu thiết kế không tốt)
1.2.4. Lập trình Hướng dịch vụ
◼ Các nghiệp vụ đã được giải quyết được các hệ thống cung cấp dưới dạng các dịch
vụ (service/API) để hệ thống khác sử dụng (mà không phải làm lại)
◼ Phục vụ giải quyết bài toán lớn, phát triển hệ sinh thái phần mềm
◼ Ưu điểm:
 Hỗ trợ phát triển hệ thống lớn
 Tiết kiệm nguồn lực
 Phức tạp
 Độ phụ thuộc cao (về mạng, giữa các hệ thống)
 Gia tăng rủi ro
2. KIỂM THỬ PHẦN MỀM
2.1. Khái niệm
◼ Kiểm thử là tiến trình vận hành hệ thống hoặc thành phần dưới những điều kiện xác
định, quan sát, ghi nhận kết quả và đưa ra đánh giá về hệ thống hoặc thành phần đó.
(IEEE Standard Glossary of Software Engineering Terminology)
2.2. Tại sao cần kiểm thử phần mềm
◼ Nhằm giúp sản phẩm

phần mềm đạt chất
lượng mong muốn.
◼ Giúp giảm chi phí sửa
lỗi, góp phần vào
Nguồn: Software Testing (Ron Patton) thành công của dự án
phần mềm
2.3. Chất lượng của việc kiểm thử [1]
◼ Có xác xuất phát hiện lỗi cao

◼ Không trùng lặp
◼ Phải là lựa chọn kiểm thử tốt nhất
◼ Không quá đơn giản hay quá phức tạp
2.4. Các mức độ kiểm thử
◼ Kiểm thử đơn vị (Unit testing)

◼ Kiểm thử tích hợp (Integration Testing)
◼ Kiểm thử hệ thống (System Testing)
◼ Kiểm thử chấp nhận (Acceptance Testing)
2.5. Quy trình kiểm thử phần

mềm
▪ Gồm 6 giai đoạn:
1) Phân tích yêu cầu/thiết kế
2) Lập kế hoạch kiểm thử
3) Thiết kế kiểm thử
4) Cài đặt môi trường kiểm thử
5) Thực hiện kiểm thử
6) Báo cáo kiểm thử
03/12/2021
18/30
2.6. Kỹ thuật kiểm thử
◼ Kiểm thử hộp đen (Black Box Testing)

◼ Kiểm thử hộp trắng (White Box Testing)
◼ Kiểm thử hộp xám (Gray Box Testing)
2.7. Một số kỹ thuật thiết kế Test Case
◼ Với Blackbox Testing

 Equivalence partitioning (phân vùng tương đương)
 Boundary value analysis (phân tích giá trị biên)
 Decision table testing (kiểm thử bảng quyết định)
 State transition testing (kiểm thử chuyển đổi trạng thái)
 Use case testing (kiểm thử trường hợp sử dụng)
◼ Với Whitebox Testing
 Statement testing (kiểm thử câu lệnh)
 Decision testing (kiểm thử quyết định)
 Condition testing (kiểm thử điều kiện)
 Multiple condition testing (kiểm thử đa điều kiện)
 Path testing (kiểm thử đường hoạt động của chương trình)
2.8. Cách thực hiện kiểm thử
◼ Manual Testing (thủ công)

◼ Automation Testing (tự động hóa)

Cong Nghe Phan Mem

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cong Nghe Phan Mem

Uploaded by

Copyright:

Available Formats

Mở cơ hội học tập cho mọi người Trung tâm đào tạo E-Learning

TỔNG QUAN CÔNG NGHỆ PHẦN MỀM

Giảng viên chuyên môn: ThS. Lê Hữu Dũng

Học phần: NHẬP MÔN CÔNG NGHỆ PHẦN MỀM

Thảo luận,giải đáp thắc mắc

1.1 Phần mềm là gì?

• Các đặc trưng của phần mềm

McCall’s software quality factors [2.pg509]

Đặc tính hoạt động (Operation)

1. Tính đúng đắn (Correctness)

Đặc tính Chuyển đổi (Transition)

6. Tính liên tác(Interoperability)

Đặc tính Sửa đổi (Revision)

9. Tính bảo trì(Maintainability)

1.2 Công nghệ phần mềm là gì?

 1.2.1. Software crisis (khủng hoảng về phần

1.2.2 Định nghĩa:

1.3 Các giai đoạn phát triển phần

1.4 Các quá trình bổ trợ

QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

Giảng viên chuyên môn: ThS. Lê Hữu Dũng

Học phần: NHẬP MÔN CÔNG NGHỆ PHẦN MỀM

Thảo luận,giải đáp thắc mắc

➢ Một số quy trình cơ bản

2.1 Một số quy trình cơ bản

2.1.5 Mô hình chữ V (V-Model)

2.2 Rational Unified Process (RUP)

RUP hỗ trợ đáp ứng 6 vấn đề thực tiễn

➢Phát triển lặp

Qui trình RUP được tổ chức theo 2 chiều:

RUP: Các pha và các lần lặp [*:p4-7]

[*]Rational Unified Process Best Practices for Software

RUP: Các công việc [*: p10-14]

1. Mô hình hóa nghiệp vụ 7. Quản lý dự án (Project

RUP: Sản phẩm RUP

◼Được cung cấp gồm:

Thảo luận chung

Chúc Anh/chị học tập tốt

NHẬP MÔN CÔNG NGHỆ PHẦN MỀM

Đặc tả yêu cầu phần mềm

3.1 Khái niệm

Yêu cầu (Requirement) là gì:

3.2. Nghiên cứu khả thi

3.3. Mục đích sử dụng SRS

3.4. Sự cần thiết của SRS

◼ Giúp người dùng hiểu được những gì họ cần

3.5. Phân loại yêu cầu

 Yêu cầu chức năng  Yêu cầu phi chức năng:

3.6. Thế nào là 1 SRS tốt?[*]

◼ Chính xác (Correct) ◼ Có thứ tự (Ranked)

3.7. Thành phần của SRS

◼ Cấu trúc SRS được chia làm 3 phần:

 Introduction (Giới thiệu)

 Overall description (mô tả tổng thể)

 Specific requirement (đặc tả yêu cầu)

3.7. Thành phần của SRS (tiếp)

Giới thiệu Mô tả tổng thể

Mục đích Quan điểm về sản

3.7. Thành phần của SRS (tiếp)

Chúc Anh/chị học tập tốt

NHẬP MÔN CÔNG NGHỆ PHẦN MỀM

Thiết kế phần mềm

1. Thiết kế phần mềm là gì?