



















Preview text:
lOMoAR cPSD| 58815430
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG KHOA
CÔNG NGHỆ THÔNG TIN 1
BÁO CÁO KẾT THÚC MÔN HỌC
PHÂN TÍCH & THIẾT KẾ HỆ THỐNG THÔNG TIN
Họ và tên: Tạ Tô Chí Cương
Mã sinh viên:B20DCCN097 Nhóm lớp học: 02
Giảng viên giảng dạy:Trần Đình Qué
Số điện thoại: 0967110559 lOMoAR cPSD| 58815430
1.4 pha trong Framework bao gồm :
1. Xác định Yêu cầu (Requirements Identification):
Mục tiêu: Pha này nhằm xác định các bên liên quan quan trọng trong dự án
và xác định cách tiếp cận họ để thu thập yêu cầu. Hoạt động:
-Xác định và liệt kê các bên liên quan, bao gồm khách hàng, người dùng
cuối và các nhóm quản lý.
-Lập kế hoạch và lên lịch gặp gỡ, cuộc họp và cuộc trò chuyện với các bên liên quan.
-Xây dựng danh sách liên hệ và thiết lập cơ chế giao tiếp với họ.
-Kết quả: Danh sách các bên liên quan và lịch trình gặp gỡ được thiết lập.
2. Thu Thập Yêu cầu (Requirements Elicitation):
Mục tiêu: Pha này tập trung vào việc thu thập yêu cầu từ các bên liên quan đã xác định. Hoạt động:
-Sử dụng các kỹ thuật thu thập thông tin như cuộc phỏng vấn, xem xét tài
liệu, thực hiện cuộc thảo luận và quan sát để tìm hiểu về nhu cầu và mong muốn của các bên liên quan.
-Ghi chép chi tiết và cẩn thận các yêu cầu thu thập được. -Kết
quả: Tập hợp yêu cầu sơ bộ từ các bên liên quan.
3. Phân tích Yêu cầu (Requirements Analysis):
Mục tiêu: Trong pha này, chúng ta phân tích và đánh giá các yêu cầu đã thu
thập để hiểu chúng rõ hơn và xác định tính khả thi và tính nhất quán của chúng. Hoạt động:
-Phân loại và đánh dấu ưu tiên cho các yêu cầu.
-Kiểm tra tính khả thi và tính nhất quán của các yêu cầu.
-Xác định rõ phạm vi của dự án và xác định các ràng buộc.
-Đánh giá mối ảnh hưởng của các yêu cầu đối với dự án.
-Kết quả: Tập hợp yêu cầu đã được phân tích và hiểu rõ hơn.
4. Quản lý Yêu cầu (Requirements Management): lOMoAR cPSD| 58815430
Mục tiêu: Pha này nhằm quản lý và duy trì các yêu cầu trong suốt thời gian dự án. Hoạt động:
-Quản lý phiên bản của các yêu cầu để theo dõi thay đổi và phiên bản.
-Theo dõi và kiểm soát các thay đổi trong yêu cầu.
-Duy trì cơ sở dữ liệu yêu cầu và cập nhật nó khi cần thiết để đảm bảo tính nhất quán.
-Kết quả: Cơ sở dữ liệu yêu cầu được duy trì và quản lý cẩn thận.
Những pha này không chỉ giúp xây dựng cơ sở yêu cầu mạnh mẽ cho dự án
phần mềm mà còn đảm bảo tính nhất quán và theo kịp sự thay đổi trong dự án. Các
pha này thường được thực hiện theo chu kỳ lặp đi lặp lại để đảm bảo rằng yêu cầu
luôn được cập nhật và phản ánh đúng nhu cầu của dự án. lOMoAR cPSD| 58815430
2.Giải thích Figue 4.1
Biểu đồ 4.1 thể hiện vai trò của Chuyên viên Phân tích Kinh doanh
(Business Analyst - BA) trong một dự án, vị trí quan trọng của họ trong việc nối
kết giữa khách hàng và bộ phận phát triển doanh nghiệp. BA đóng vai trò chính
trong việc suy luận, phân tích, ghi chép, và xác nhận nhu cầu của các bên liên quan
đến dự án. Họ là người đóng vai trò trung gian quan trọng qua đó các yêu cầu được
truyền đạt giữa cộng đồng khách hàng và nhóm phát triển phần mềm, như thể hiện
trong Biểu đồ 4-1. Tuy nhiên, cần lưu ý rằng có nhiều hình thức giao tiếp khác
được sử dụng trong dự án, vì vậy BA không phải lúc nào cũng chịu trách nhiệm
hoàn toàn về việc truyền đạt thông tin về dự án. BA đóng vai trò trung tâm trong
việc thu thập và phân phối thông tin sản phẩm, trong khi người quản lý dự án có
vai trò chủ trì trong việc truyền đạt thông tin về dự án.
Chức danh "Chuyên viên Phân tích Kinh doanh" có thể được biểu đạt bằng
nhiều cách khác nhau trong các tổ chức và dự án khác nhau. Các tên gọi đồng
nghĩa với chức danh này bao gồm Phân tích Yêu cầu, Phân tích Hệ thống, Kỹ sư
Yêu cầu, Quản lý Yêu cầu, Phân tích Ứng dụng, Chuyên viên Phân tích Hệ thống
Kinh doanh, Chuyên viên Phân tích Kinh doanh IT, và nhiều tên gọi khác. Các tên
gọi này có thể thay đổi từ tổ chức này sang tổ chức khác. Một hoặc nhiều chuyên
gia có thể thực hiện vai trò này trong một dự án cụ thể, hoặc nhiệm vụ này có thể
được phân phối cho các thành viên khác trong nhóm thực hiện các vai trò dự án
khác. Những thành viên trong nhóm này có thể bao gồm Quản lý Dự án, Quản lý
Sản phẩm, Chủ sở hữu Sản phẩm, Chuyên gia về Chủ đề (SME), Nhà phát triển, và
đôi khi cả người dùng. lOMoAR cPSD| 58815430
Cần lưu ý rằng khi một người giữ một vai trò dự án khác, nhưng cũng làm
công việc của Chuyên viên Phân tích Kinh doanh, họ đang thực hiện hai công việc
khác nhau. Ví dụ, một Quản lý Dự án có thể đôi khi đảm nhận vai trò của một BA
trong một dự án cụ thể. Trong trường hợp này, Quản lý Dự án phải tạo và quản lý
kế hoạch dự án, bao gồm lịch trình và nguồn lực dựa trên công việc mà các BA đã
xác định. Quản lý Dự án phải giúp đỡ trong việc quản lý phạm vi và xử lý thay đổi
lịch trình khi phạm vi thay đổi. Họ có thể thực hiện vai trò Quản lý Dự án trong
một khoảnh khắc và sau đó chuyển sang việc thực hiện các công việc của Chuyên
viên Phân tích. Tuy nhiên, đây là hai vai trò khác nhau, đòi hỏi các kỹ năng và kiến thức hơi khác nhau.
Trong các tổ chức phát triển sản phẩm tiêu dùng, vai trò Chuyên viên Phân
tích thường thuộc về người Quản lý Sản phẩm hoặc các nhân viên tiếp thị. Thực tế,
người Quản lý Sản phẩm thường thực hiện vai trò giống như một BA, nhưng
thường tập trung vào việc hiểu thị trường và dự đoán nhu cầu của người dùng bên
ngoài. Nếu một dự án có cả người Quản lý Sản phẩm và một BA, thường người
Quản lý Sản phẩm sẽ tập trung vào thị trường bên ngoài và nhu cầu của người
dùng, trong khi BA chuyển đổi chúng thành yêu cầu chức năng.
Dự án Agile cũng đòi hỏi kỹ năng phân tích kinh doanh. Có thể có một vai
trò dự án, chẳng hạn như Chủ sở hữu Sản phẩm, thực hiện một số công việc phân
tích truyền thống. Một số nhóm thấy hữu ích khi có ai đó giữ vai trò của một
Chuyên viên Phân tích bổ sung (Cohn 2010). BA có thể giúp đại diện cho người
dùng và hiểu rõ nhu cầu của họ, đồng thời thực hiện các hoạt động phân tích bổ
sung được mô tả trong chương sau. Bất kể tên gọi chức danh công việc, người thực
hiện nhiệm vụ của Chuyên viên Phân tích phải có kỹ năng, kiến thức và tính cách
để thực hiện vai trò một cách xuất sắc
3.Công việc của người làm BA
Người làm BA cần phải hiểu rõ trước các mục tiêu kinh doanh cho dự án và
sau đó định rõ các yêu cầu người dùng, chức năng và chất lượng, cho phép các
nhóm ước tính và lập kế hoạch cho dự án, và thiết kế, xây dựng và xác minh sản
phẩm. BA cũng là một người lãnh đạo và người truyền thông, biến những ý tưởng
mơ hồ từ khách hàng thành các đặc tả rõ ràng hướng dẫn công việc của đội phát triển phần mềm.
1.Nhiệm vụ của BA lOMoAR cPSD| 58815430
Xác định rõ yêu cầu kinh doanh: Nhiệm vụ của BA bắt đầu bằng việc giúp
doanh nghiệp hoặc người tài trợ dự án, người quản lý sản phẩm hoặc quản lý tiếp
thị xác định yêu cầu kinh doanh của dự án. Họ có thể đề xuất một mẫu tài liệu tầm
nhìn (vision) và phạm vi (scope) và làm việc cùng với những người nắm giữ tầm
nhìn để giúp họ diễn đạt nó một cách rõ ràng.
Lập kế hoạch tiếp cận yêu cầu: Nhà phân tích cần phát triển kế hoạch để
thu thập, phân tích, ghi chép, xác nhận và quản lý yêu cầu trong suốt dự án. Họ
làm việc chặt chẽ với quản lý dự án để đảm bảo rằng các kế hoạch này phù hợp với
kế hoạch tổng thể của dự án và sẽ giúp đạt được các mục tiêu của dự án.
Xác định các bên liên quan và lớp người dùng: BA làm việc với những
người tài trợ kinh doanh để chọn ra các đại diện phù hợp cho từng lớp người dùng,
kêu gọi sự tham gia của họ và thương lượng về trách nhiệm của họ. Họ giải thích
những gì bạn muốn từ đối tác khách hàng của bạn và thỏa thuận về mức độ tham
gia phù hợp từ mỗi người.
Thu thập yêu cầu: Một nhà phân tích phải tích cực giúp người dùng diễn
đạt những khả năng của hệ thống mà họ cần để đáp ứng mục tiêu kinh doanh bằng
cách sử dụng nhiều kỹ thuật thu thập thông tin khác nhau.
Phân tích yêu cầu: BA tìm kiếm những yêu cầu phát sinh (derived
requirements) từ những gì khách hàng đã yêu cầu và tìm kiếm yêu cầu ngụ ý
(implicit requirements) mà khách hàng có vẻ mong đợi mà không nói ra. Họ sử
dụng các mô hình yêu cầu (requirements model) để nhận biết các khuôn mẫu, xác
định khoảng trống trong yêu cầu, tiết lộ những yêu cầu xung đột và xác nhận rằng
tất cả các yêu cầu đã được chỉ định nằm trong phạm vi. Họ làm việc với các bên
liên quan để xác định mức độ chi tiết cần thiết cho việc chỉ định yêu cầu của người dùng và chức năng.
Ghi chép tài liệu yêu cầu: Nhà phân tích chịu trách nhiệm viết tài liệu yêu
cầu một cách có cấu trúc và rõ ràng, mô tả giải pháp để giải quyết vấn đề của
khách hàng. Họ sử dụng các mẫu tiêu chuẩn giúp gia tăng quá trình phát triển yêu
cầu bằng cách nhắc nhở nhà phân tích về các chủ đề cần thảo luận với đại diện người dùng.
Truyền đạt yêu cầu: BA phải truyền đạt yêu cầu một cách hiệu quả đến tất
cả các bên liên quan. Nhà phân tích nên xác định khi nào thì việc thể hiện các yêu
cầu phải cần thiết sử dụng các phương pháp khác ngoài văn bản, bao gồm các loại lOMoAR cPSD| 58815430
mô hình phân tích hình ảnh, bảng, phương trình toán học và nguyên mẫu. Truyền
đạt không chỉ đơn giản là việc viết yêu cầu lên giấy, nó liên quan đến việc hợp tác
liên tục với nhóm để đảm bảo họ hiểu thông tin bạn đang truyền đạt.
Xác nhận các yêu cầu chính: Nhà phân tích phải đảm bảo rằng các tuyên
bố về yêu cầu đã đáp ứng được những mong muốn được thảo luận và rằng giải
pháp dựa trên yêu cầu sẽ đáp ứng nhu cầu của các bên liên quan. Những người
phân tích đóng vai trò trung tâm trong việc xem xét yêu cầu. Bạn cũng nên xem xét
các thiết kế và thử nghiệm được tạo ra từ yêu cầu để đảm bảo rằng yêu cầu đã
được hiểu đúng cách. Nếu bạn đang tạo các bài kiểm tra chấp nhận thay vì yêu cầu
chi tiết trong dự án Agile, thì những bài kiểm tra đó cũng nên được xem xét.
Hỗ trợ ưu tiên hóa yêu cầu: Nhà phân tích đảm bảo sự hợp tác và thương
thảo giữa các bên liên quan khác nhau và các nhà phát triển để đảm bảo họ đưa ra
quyết định ưu tiên hợp lý, phù hợp với việc đạt được mục tiêu kinh doanh.
Quản lý yêu cầu: BA tham gia vào toàn bộ vòng đời phát triển phần mềm,
vì vậy họ nên giúp tạo lập, xem xét và thực hiện kế hoạch quản lý yêu cầu của dự
án. Sau khi thiết lập cơ sở yêu cầu cho một phiên bản sản phẩm hoặc vòng lặp phát
triển cụ thể, nhà phân tích chuyển sang tập trung vào việc theo dõi tình trạng của
những yêu cầu đó, xác minh sự hài lòng của họ trong sản phẩm và quản lý các thay
đổi đối với cơ sở yêu cầu. Với sự đóng góp từ các đồng nghiệp khác nhau, nhà
phân tích thu thập thông tin về tính truy vết (traceability information) giúp kết nối
các yêu cầu riêng lẻ đến các yếu tố hệ thống khác.
2.Kỹ năng của Business Analyst (BA)
Người đảm nhận vai trò nhà phân tích cần có đào tạo, hướng dẫn, và kinh
nghiệm đầy đủ. Công việc này bao gồm nhiều "kỹ năng mềm" hướng đến khả năng
tương tác với con người hơn là kỹ thuật cứng. Những người phân tích cần biết cách
sử dụng nhiều kỹ thuật thu thập thông tin và cách biểu diễn thông tin dưới các hình
thức khác nhau ngoài văn bản tự nhiên.
Một BA hiệu quả kết hợp sự kỹ năng giao tiếp mạnh mẽ, tạo điều kiện và kỹ
năng giao tiếp giữa con người với kiến thức về kỹ thuật và lĩnh vực kinh doanh,
cùng với tính cách phù hợp với công việc. Kiên nhẫn và sự mong muốn chân thành
là các yếu tố quan trọng để đạt được thành công. Dưới đây là một số kỹ năng quan trọng: lOMoAR cPSD| 58815430
Kỹ năng Lắng Nghe: Để trở thành một người giao tiếp hai chiều thành thạo,
học cách lắng nghe một cách hiệu quả là quan trọng. Lắng nghe tích cực bao gồm
loại bỏ các yếu tố gây xao lẫn, duy trì tư thế chú ý và tiếp xúc bằng mắt; nhắc lại
để xác nhận mức độ hiểu biết của bạn. Bạn cần nắm bắt những gì mọi người đang
nói và chú ý để phát hiện những điều họ có thể do dự trong việc nói ra. Học cách
đồng thuận với cách mà người kia muốn giao tiếp và hiểu một cách khách quan
những gì bạn nghe từ khách hàng. Lưu ý đối với những giả định chưa được nêu ra
từ những gì bạn nghe hoặc hiểu được.
Kỹ năng Phỏng vấn và Đặt câu hỏi: Hầu hết thông tin về yêu cầu đến từ
các cuộc trò chuyện, vì vậy một BA phải thành thạo trong việc tương tác với nhiều
cá nhân và nhóm. Đôi khi, làm việc với các quản lý cấp cao và với những người có
ý kiến mạnh mẽ hoặc quyết liệt có thể làm bạn cảm thấy e dè. Bạn cần đặt ra các
câu hỏi thích hợp để nắm bắt thông tin yêu cầu quan trọng. Ví dụ, người dùng
thường tập trung vào các hành vi hoạt động thông thường của hệ thống. Tuy nhiên,
có rất nhiều mã code được viết để xử lý các trường hợp ngoại lệ. Do đó, bạn cũng
cần trao đổi để xác định các tình huống lỗi và xác định cách hệ thống nên phản ứng.
Kỹ năng Suy Nghĩ Nhanh: Người BA luôn phải ý thức về thông tin hiện có
và tiến hành xử lý thông tin mới dựa trên nó. Họ cần phát hiện ra sự mâu thuẫn, sự
không chắc chắn, sự mơ hồ và các giả định để có thể thảo luận về chúng ngay lập
tức nếu cần. Bạn có thể cố gắng viết kịch bản một bộ câu hỏi hoàn hảo, tuy nhiên,
bạn sẽ cần phải đặt một câu hỏi mà bạn không thể dự đoán được. Bạn cần viết ra
các câu hỏi hay, lắng nghe rõ ràng vào các câu trả lời và nhanh chóng nghiên cứu
điều tiếp theo để nói hoặc hỏi. Đôi khi bạn sẽ không đặt ra một câu hỏi mà thay
vào đó sẽ đưa ra một ví dụ phù hợp trong ngữ cảnh để giúp các bên liên quan hình
thành câu trả lời tiếp theo.
Kỹ năng Phân Tích: Một BA hiệu quả có thể suy nghĩ ở cả hai mức trừu
tượng cao và thấp và biết khi nào nên chuyển từ một mức này sang mức khác. Đôi
khi, bạn phải đi sâu vào từ thông tin ở mức cao xuống chi tiết. Trong các tình
huống khác, bạn sẽ cần tổng hợp từ một nhu cầu cụ thể mà một người dùng đã mô
tả thành một bộ yêu cầu để đáp ứng nhiều bên liên quan. Nhà phân tích cần hiểu
thông tin phức tạp từ nhiều nguồn và giải quyết các vấn đề khó khăn liên quan đến
thông tin đó. Họ cần đánh giá thông tin để điều hòa sự xung đột, phân biệt yêu cầu
thực sự từ các "mong muốn" của người dùng và phân biệt ý tưởng giải pháp từ yêu cầu. lOMoAR cPSD| 58815430
Kỹ năng Tư Duy Hệ Thống: Mặc dù một BA cần tập trung vào chi tiết,
nhưng họ cũng cần phải nhìn vào toàn cảnh. Nhà phân tích phải kiểm tra yêu cầu
dựa trên những gì anh ta biết về toàn bộ doanh nghiệp, môi trường kinh doanh và
ứng dụng để tìm sự không nhất quán và ảnh hưởng. Nhà phân tích cần hiểu về sự
tương tác và mối quan hệ giữa con người, quy trình và công nghệ liên quan đến hệ thống.
Kỹ năng Học Tập: Nhà phân tích phải nhanh chóng nắm bắt kiến thức mới,
cho dù đó là về phương pháp yêu cầu mới hoặc lĩnh vực ứng dụng. Họ cần có khả
năng đưa kiến thức đó vào thực hành một cách hiệu quả. Nhà phân tích phải xem
xét nhiều tài liệu và nắm bắt bản chất một cách nhanh chóng.
Kỹ năng Hỗ Trợ: Khả năng hỗ trợ các cuộc thảo luận về yêu cầu và các
buổi làm việc thu thập yêu cầu là một khả năng quan trọng của nhà phân tích. Hỗ
trợ là việc dẫn dắt một nhóm đến thành công. Hỗ trợ là vô cùng cần thiết khi hợp
tác định nghĩa yêu cầu, ưu tiên nhu cầu và giải quyết xung đột.
Kỹ năng Lãnh Đạo: Một nhà phân tích mạnh mẽ có thể ảnh hưởng đến một
nhóm các bên liên quan để họ hướng đến một mục tiêu chung. Lãnh đạo đòi hỏi
hiểu biết về nhiều kỹ thuật để đàm phán thỏa thuận giữa các bên liên quan của dự
án, giải quyết xung đột và đưa ra quyết định.
Kỹ năng Quan Sát: Một nhà phân tích quan sát sẽ phát hiện ra các ý kiến
được đưa ra trong cuộc trò chuyện mà có thể trở thành điều quan trọng. Bằng cách
theo dõi người dùng thực hiện công việc của họ hoặc sử dụng ứng dụng hiện tại,
một người quan sát giỏi có thể phát hiện ra các chi tiết mà người dùng có thể
không nghĩ đến để đề cập.
Kỹ năng Giao Tiếp: Sản phẩm chính từ quá trình phát triển yêu cầu là một
bộ yêu cầu mô tả thông tin một cách hiệu quả giữa khách hàng, marketing, quản lý
và nhân viên kỹ thuật. Nhà phân tích cần phải có kiểm soát vững chắc về ngôn ngữ
và khả năng diễn đạt ý tưởng phức tạp một cách rõ ràng, cả bằng văn bản và lời nói.
Kỹ năng Tổ Chức: Nhà phân tích phải đối mặt với một loạt các tài liệu,
thông tin và tác vụ. Khả năng tổ chức tốt là quan trọng để theo dõi và duyệt thông tin một cách hiệu quả. lOMoAR cPSD| 58815430
Kỹ năng Xây Dựng Mối Quan Hệ: Mối quan hệ giữa nhà phân tích và các
bên liên quan, bao gồm người dùng cuối, là quan trọng. Xây dựng mối quan hệ là
việc làm liên tục và đòi hỏi sự tôn trọng và lắng nghe chân thành đối với ý kiến và
cảm xúc của mọi người.
Nhìn chung, Business Analyst là một vai trò đòi hỏi nhiều kỹ năng khác
nhau, từ kỹ năng mềm như giao tiếp và tư duy hệ thống đến kiến thức kỹ thuật và
hiểu biết sâu về lĩnh vực kinh doanh. Với những kỹ năng này, họ có thể giúp định
hình và triển khai các dự án và ứng dụng một cách hiệu quả để đáp ứng nhu cầu
của khách hàng và doanh nghiệp.
3.Kiến thức của BA
Kiến thức của một Business Analyst (BA) trong các dự án phần mềm có thể
được phân chia thành các khía cạnh quan trọng sau:
Kiến thức kỹ thuật: BA cần phải hiểu về các phương pháp kỹ thuật và công
nghệ liên quan đến phát triển phần mềm. Điều này bao gồm kiến thức về phương
pháp Agile, Waterfall, và các quy trình phát triển phần mềm khác. BA cũng cần
biết cách áp dụng chúng trong bối cảnh của các dự án cụ thể.
Quản lý dự án: Một BA hiệu quả cần phải hiểu về quản lý dự án và quản lý
yêu cầu. Điều này bao gồm khả năng lập kế hoạch, theo dõi tiến độ, quản lý rủi ro,
và đảm bảo chất lượng trong toàn bộ vòng đời dự án.
Kiến thức về doanh nghiệp và ngành công nghiệp: BA cần phải hiểu rõ về
mô hình kinh doanh, ngành công nghiệp và tổ chức mà họ đang làm việc. Điều này
giúp họ giảm thiểu sự hiểu nhầm với người dùng, đề xuất cách cải thiện quy trình
kinh doanh, và nêu ra các yêu cầu có giá trị.
Kiến thức về quản lý sản phẩm: Trong môi trường phát triển thương mại,
BA cần phải hiểu về các khái niệm quản lý sản phẩm, bao gồm quản lý sản phẩm
theo chu kỳ, đặc điểm sản phẩm và quản lý yêu cầu thay đổi.
Kiến thức về kiến trúc và môi trường hoạt động: Để tham gia vào các cuộc
trò chuyện kỹ thuật và đánh giá ưu tiên và yêu cầu ngoài chức năng, BA cần phải
có kiến thức cơ bản về kiến trúc phần mềm và môi trường hoạt động. lOMoAR cPSD| 58815430
Kỹ năng giao tiếp và lãnh đạo: BA cần phải có khả năng giao tiếp hiệu
quả và lãnh đạo trong việc thuyết phục các bên liên quan về yêu cầu và quản lý
sự thay đổi trong dự án. 4.Agile & Waterfall
Mô hình Agile là một phương pháp xây dựng và phát triển các dự án phần
mềm. Nó tập trung vào sự linh hoạt và tương tác liên tục giữa các thành viên trong
nhóm phát triển và khách hàng hoặc người sử dụng cuối. Các đặc điểm quan trọng
của mô hình Agile bao gồm:
Phát triển linh hoạt: Agile rút ngắn đáng kể thời gian phát triển bằng cách
lặp đi lặp lại các giai đoạn phát triển trong một khoảng thời gian ngắn. Điều này
cho phép phát triển sản phẩm nhanh chóng và phản hồi linh hoạt đối với yêu cầu
thay đổi từ khách hàng. lOMoAR cPSD| 58815430
Phân chia thành giai đoạn nhỏ: Mỗi dự án Agile được chia thành nhiều
giai đoạn nhỏ hơn, gọi là "sprints" hoặc "iterations," trong đó mỗi giai đoạn tập
trung vào phát triển một phần cụ thể của sản phẩm.
Phản hồi thường xuyên từ khách hàng: Sản phẩm được cập nhật và bàn
giao cho khách hàng sau mỗi giai đoạn, cho phép họ đưa ra ý kiến và yêu cầu thay
đổi. Điều này giúp đảm bảo rằng sản phẩm cuối cùng phù hợp với nhu cầu của khách hàng.
Quyết định dựa trên dữ liệu thực tế: Agile thúc đẩy việc ra quyết định dựa
trên dữ liệu thực tế và phản hồi từ người dùng cuối. Thay vì dự đoán tất cả từ đầu,
dự án tiến hành điều chỉnh dựa trên hiện trạng thực tế.
Quy trình thực hiện của Agile bao gồm các giai đoạn sau:
a) Lập kế hoạch: Kế hoạch tổng thể của dự án được xác định trong những
tuần đầu tiên, sau đó mỗi giai đoạn phát triển nhỏ được kế hoạch cụ thể. Họp hàng
ngày để cập nhật tình hình công việc.
b) Phân tích: Phân tích yêu cầu diễn ra trong suốt quá trình phát triển, với
sự hợp tác giữa khách hàng và nhóm phát triển để đưa ra cách làm tốt nhất trước
khi bàn giao cho đội phát triển.
c) Thiết kế và lập trình: Thiết kế và lập trình diễn ra song song với việc
cải tiến liên tục. Mã nguồn là sở hữu tập thể và các thành viên phải sửa lỗi không
phân biệt người gây ra.
d) Kiểm thử: Tất cả các thành viên đảm bảo chất lượng sản phẩm và khi
có lỗi, đội cùng nhau phân tích và xử lý.
e) Bàn giao sản phẩm: Sản phẩm được demo hàng tuần và đưa cho khách hàng xem xét và góp ý.
Mô hình Waterfall:
Mô hình Waterfall là một phương pháp phát triển phần mềm theo tuần tự và
tập trung vào việc hoàn thành từng giai đoạn trước khi chuyển sang giai đoạn tiếp
theo. Các đặc điểm quan trọng của mô hình Waterfall bao gồm:
Phát triển theo bước đơn: Waterfall yêu cầu hoàn thành từng giai đoạn,
chẳng hạn như thu thập yêu cầu, phân tích hệ thống, thiết kế, lập trình, kiểm thử và
triển khai, theo một thứ tự cụ thể và không thể tiến hành song song. lOMoAR cPSD| 58815430
Yêu cầu cố định từ đầu: Yêu cầu được xác định một cách cụ thể ở giai đoạn
đầu và không thay đổi trong suốt quá trình phát triển. Các thay đổi yêu cầu thường
rất khó khăn và đắt đỏ trong mô hình Waterfall.
Kiểm thử cuối cùng: Kiểm thử thường diễn ra ở giai đoạn cuối cùng của dự
án sau khi phát triển hoàn thành. Điều này có thể tạo ra áp lực lớn và gây ra sự trễ
trên lịch trình nếu có lỗi phát sinh.
Thiết kế hoàn chỉnh trước khi lập trình: Mô hình Waterfall đòi hỏi việc
hoàn thành thiết kế trước khi bắt đầu lập trình. Điều này có thể dẫn đến việc phải
chờ đợi lâu trước khi bắt đầu phát triển.
Quy trình thực hiện của Waterfall bao gồm các giai đoạn sau:
a) Thu thập yêu cầu: Xác định yêu cầu chức năng và phi chức năng của
hệ thống, sau đó tạo bản tài liệu đặc tả yêu cầu.
b) Phân tích hệ thống: Định rõ cách thức hệ thống sẽ đáp ứng yêu cầu.
c) Lập trình: Lập trình sản phẩm dựa trên thiết kế và yêu cầu đã xác định.
d) Kiểm thử: Kiểm thử từng phần của sản phẩm và sau đó kiểm thử chấp nhận cuối cùng.
e) Triển khai: Đưa sản phẩm vào môi trường thực tế.
f) Bảo trì: Sửa lỗi và triển khai các thay đổi mới khi cần thiết.
5.Vai trò của Business Analyst (BA) trong các dự án Agile:
BA trong dự án Agile phải xác định và quản lý yêu cầu một cách linh hoạt,
tuân theo triều đạo phát triển linh hoạt và điều chỉnh theo yêu cầu của dự án.
Họ phải đảm bảo rằng tài liệu yêu cầu được duyệt xét ở mức độ phù hợp,
không quá thừa hoặc quá ít.
BA giúp xác định cách ghi chép backlog một cách hiệu quả, bao gồm việc sử
dụng thẻ hoặc các công cụ chính thức nếu cần.
Họ áp dụng kỹ năng hướng dẫn và lãnh đạo để đảm bảo sự tương tác liên tục
và trao đổi thông tin giữa các bên tham gia dự án.
BA hỗ trợ xác minh rằng nhu cầu của khách hàng được đại diện một cách
chính xác trong backlog sản phẩm và hỗ trợ việc ưu tiên các yêu cầu trong backlog.
Họ làm việc cùng với khách hàng để xử lý các thay đổi và điều chỉnh ưu tiên yêu cầu theo thời gian.
BA đóng vai trò quan trọng trong việc đánh giá tác động của các thay đổi lên
nội dung và lịch trình phát hành của dự án Agile. lOMoAR cPSD| 58815430
6.Mô hình yêu cầu phần mềm
Các nhà phân tích kinh doanh thường mong muốn tìm ra một phương pháp
kết hợp tất cả các yếu tố lại với nhau để tạo thành một mô hình tổng thể mô tả toàn
bộ yêu cầu của hệ thống. Tuy nhiên, thực tế cho thấy không có sơ đồ nào có thể
bao gồm tất cả mọi thứ.
Trong thực tế, nếu bạn có thể mô hình hóa toàn bộ hệ thống trong một sơ đồ
duy nhất, thì sơ đồ đó sẽ không thể sử dụng được như một danh sách chi tiết của
các yêu cầu riêng lẻ. Ban đầu, phân tích hệ thống có cấu trúc đã được thiết kế để
thay thế việc viết đặc tả chức năng truyền thống bằng ngôn ngữ tự nhiên thông qua
việc sử dụng các biểu đồ và ký hiệu có tính hình thức. Tuy nhiên, từ kinh nghiệm,
ta nhận thấy rằng các mô hình phân tích nên bổ sung - chứ không phải thay thế -
đặc tả yêu cầu viết bằng ngôn ngữ tự nhiên.
Mô hình hóa yêu cầu phần mềm (Software Requirement Modeling) là quá
trình tạo ra các biểu đồ để tăng cường sự hiểu biết, giao tiếp và tài liệu hóa về
những gì hệ thống phần mềm cần thực hiện. Mô hình hóa yêu cầu hiệu quả giúp
đảm bảo rằng các dự án phát triển phần mềm được định rõ, được tài liệu hóa đúng
cách và đáp ứng nhu cầu của các bên liên quan. Nó cũng hỗ trợ quản lý thay đổi và
giao tiếp liên tục trong toàn bộ quá trình phát triển phần mềm.
Các mô hình yêu cầu phần mềm có khả năng giúp bạn xác định các yêu cầu
bị thiếu, không liên quan và không nhất quán. Do bị hạn chế về khả năng nhớ của
con người, việc phân tích danh sách các yêu cầu không nhất quán, trùng lặp, và
không liên quan gần như không thể thực hiện được. Việc tìm kiếm tất cả các lỗi
này chỉ bằng cách xem xét lại các yêu cầu văn bản là một công việc khó khăn. Các
ký hiệu và biểu đồ được trình bày ở đây cung cấp một ngôn ngữ chung, tiêu chuẩn
trong ngành dành cho những người tham gia dự án để sử dụng. Các mô hình này
rất hữu ích cho việc xây dựng và khám phá các yêu cầu cũng như thiết kế phần
mềm. Các biểu đồ này cho phép tạo các biểu đồ khái niệm về hệ thống mới. Chúng
mô tả các khía cạnh logic của các thành phần dữ liệu, các đối tượng trong thế giới
thực và các thay đổi về trạng thái của hệ thống. Bạn có thể xem xét các mô hình từ
các góc độ khác nhau hoặc rút ra các yêu cầu chức năng từ các mô hình cao cấp
dựa trên đầu vào của người dùng.
Hầu hết thời gian, bạn sẽ không thể tạo ra một mô hình hoàn chỉnh từ lần
đầu tiên, do đó việc lặp lại là quan trọng để thành công trong việc mô hình hóa.
Các công cụ cũng có thể thực thi các quy tắc cho từng phương pháp mô hình hóa lOMoAR cPSD| 58815430
họ hỗ trợ, xác định các lỗi cú pháp và sự không nhất quán mà người kiểm tra biểu
đồ có thể không thể nhận thấy. Các công cụ quản lý yêu cầu hỗ trợ mô hình hóa
cho phép bạn theo dõi các yêu cầu đối với biểu đồ.
Các biểu đồ có thể được sử dụng cho mô hình yêu cầu phần mềm bao gồm:
Biểu đồ luồng dữ liệu (Data Flow Diagram): Được sử dụng để biểu diễn
quá trình xử lý dữ liệu trong hệ thống.
Biểu đồ Swimlane: Sử dụng để biểu diễn các bước trong quy trình kinh
doanh hoặc hoạt động của hệ thống phần mềm.
Biểu đồ trạng thái (State Diagram): Sử dụng để mô hình hóa các trạng thái
mà hệ thống hoặc đối tượng có thể thay đổi và các chuyển đổi giữa chúng.
Bảng quyết định và cây quyết định: Sử dụng để mô hình hóa các quyết định
và hành vi của hệ thống dựa trên các điều kiện khác nhau.
Bảng phản hồi sự kiện: Sử dụng để liệt kê các sự kiện và hành vi mà hệ
thống phản ứng khi nhận được các sự kiện cụ thể từ môi trường của nó.
Biểu đồ Use case: Sử dụng để biểu diễn các tình huống sử dụng cụ thể của hệ thống.
Biểu đồ hoạt động: Sử dụng để mô hình hóa các luồng khác nhau trong quá
trình hoạt động của hệ thống.
Biểu đồ mối quan hệ thực thể (ERD): Sử dụng để biểu diễn mối quan hệ
giữa các thực thể và thuộc tính của chúng.
Các từ khóa trong yêu cầu có thể đóng vai trò như các thực thể, quy trình,
tác nhân, chuyển tiếp, hoạt động, sự kiện, quyết định trong các biểu đồ này.
Thường thì không cần phải tạo một mô hình phân tích hoàn chỉnh cho toàn
bộ hệ thống. Thay vào đó, tập trung vào việc mô hình hóa các phần phức tạp và rủi
ro nhất của hệ thống, cũng như các phần mơ hồ hoặc không chắc chắn. Chọn các
phần tử của hệ thống mà tác động của các khiếm khuyết trong đó là lớn và nghiêm
trọng là một chiến lược tốt. Hãy chọn các mô hình để sử dụng cùng nhau để đảm lOMoAR cPSD| 58815430
bảo tất cả các mô hình đều hoàn chỉnh và liên quan đến nhau. Ví dụ, kiểm tra các
đối tượng dữ liệu trong DFD có thể giúp phát hiện các thực thể bị thiếu trong ERD.
Cụ thể, một số biểu đồ quan trọng bao gồm:
Biểu đồ luồng dữ liệu: Dùng để biểu diễn quá trình xử lý dữ liệu và các
luồng dữ liệu trong hệ thống.
Biểu đồ Swimlane: Sử dụng để hiển thị các bước trong quy trình kinh doanh
hoặc tương tác giữa hệ thống và người dùng.
Biểu đồ trạng thái: Dùng để biểu diễn các trạng thái mà hệ thống hoặc đối
tượng có thể thay đổi và các chuyển đổi giữa chúng.
Biểu đồ giao diện: Sử dụng để mô hình hóa thiết kế giao diện người dùng.
Bảng quyết định và cây quyết định: Sử dụng để biểu diễn các quyết định và
hành vi của hệ thống dựa trên các điều kiện khác nhau.
Bảng phản ứng sự kiện: Liệt kê các sự kiện và hành vi mà hệ thống phản
ứng khi nhận được các sự kiện cụ thể từ môi trường của nó.
Biểu đồ Use case: Sử dụng để biểu diễn các tình huống sử dụng cụ thể của hệ thống.
Biểu đồ hoạt động: Dùng để mô hình hóa các luồng khác nhau trong quá
trình hoạt động của hệ thống.
Biểu đồ mối quan hệ thực thể (ERD): Sử dụng để biểu diễn mối quan hệ
giữa các thực thể và thuộc tính của chúng.
Các từ khóa trong yêu cầu có thể đóng vai trò như các thực thể, quy trình,
tác nhân, chuyển tiếp, hoạt động, sự kiện, quyết định trong các biểu đồ này.
Thường thì không cần phải tạo một mô hình phân tích hoàn chỉnh cho toàn
bộ hệ thống. Thay vào đó, tập trung vào việc mô hình hóa các phần phức tạp và rủi
ro nhất của hệ thống, cũng như các phần mơ hồ hoặc không chắc chắn. Chọn các
phần tử của hệ thống mà tác động của các khiếm khuyết trong đó là lớn và nghiêm
trọng là một chiến lược tốt. Hãy chọn các mô hình để sử dụng cùng nhau để đảm lOMoAR cPSD| 58815430
bảo tất cả các mô hình đều hoàn chỉnh và liên quan đến nhau. Ví dụ, kiểm tra các
đối tượng dữ liệu trong DFD có thể giúp phát hiện các thực thể bị thiếu trong ERD.
Biểu đồ lớp (Class diagrams): Sử dụng để biểu thị các lớp đối tượng liên
quan đến lĩnh vực ứng dụng, bao gồm các thuộc tính, hành vi và tính chất của
chúng, cũng như các mối quan hệ giữa các lớp.
Biểu đồ trường hợp sử dụng (Use case diagrams): Dùng để hiển thị các
mối quan hệ giữa các tác nhân bên ngoài hệ thống và các trường hợp sử dụng mà họ tương tác với.
Biểu đồ hoạt động (Activity diagrams): Sử dụng để mô hình hóa các luồng
khác nhau trong quá trình hoạt động của hệ thống.
Biểu đồ trạng thái (State diagrams): Sử dụng để biểu diễn các trạng thái
khác nhau mà hệ thống hoặc đối tượng có thể thay đổi và các chuyển đổi cho phép
giữa các trạng thái này.
Biểu đồ giao diện (Interface diagrams): Dùng để mô hình hóa thiết kế giao diện người dùng.
Các biểu đồ này giúp tạo ra một tổng thể mô tả các yêu cầu của hệ thống và
cách chúng tương tác với nhau. Đồng thời, chúng hỗ trợ quản lý thay đổi và giao
tiếp liên tục trong quá trình phát triển phần mềm.
Tóm lại, mô hình yêu cầu phần mềm là một phần quan trọng của quá trình
phát triển phần mềm, giúp đảm bảo rằng các yêu cầu được định rõ, được tài liệu
hóa đúng cách và đáp ứng nhu cầu của các bên liên quan. Các biểu đồ và mô hình
yêu cầu giúp tạo ra một cái nhìn toàn diện về hệ thống và giúp xác định các yêu
cầu còn thiếu, không liên quan và không nhất quán. lOMoAR cPSD| 58815430
7. Các giai đoạn thiết kế phần mềm: Thiết kế kiến trúc, Thiết kế chi tiết
Giai đoạn thiết kế phần mềm thường được chia thành nhiều phần, trong đó
có hai giai đoạn quan trọng là Thiết kế Kiến trúc (Architectural Design) và Thiết
kế Chi tiết (Detailed Design). Dưới đây là mô tả ngắn về hai giai đoạn này:
Thiết kế Kiến trúc (Architectural Design):
Mục tiêu chính: Xác định cấu trúc chung của hệ thống, đảm bảo rằng nó
đáp ứng được yêu cầu của khách hàng và đáp ứng các tiêu chí hiệu suất, bảo mật, và khả năng mở rộng.
Các bước cụ thể:
-Phân tích yêu cầu: Hiểu rõ yêu cầu của khách hàng và các hệ thống liên quan.
-Xác định kiến trúc hệ thống: Chọn mô hình kiến trúc, xác định các thành
phần chính và cách chúng tương tác.
-Xác định giao diện: Định rõ giao diện giữa các thành phần và hệ thống bên ngoài.
-Kiểm soát và quản lý dữ liệu: Xác định cách dữ liệu sẽ được lưu trữ, truy
xuất, và quản lý trong hệ thống.
Thiết kế Chi tiết (Detailed Design):
Mục tiêu chính: Xác định cụ thể cách mỗi thành phần của hệ thống sẽ được
triển khai, bao gồm các cấu trúc dữ liệu, thuật toán, và các đặc tả chi tiết khác.
Các bước cụ thể:
-Xác định các module: Phân chia hệ thống thành các module nhỏ hơn để dễ quản lý và triển khai.
-Thiết kế cấu trúc dữ liệu: Xác định cách dữ liệu sẽ được tổ chức và lưu trữ.
-Thiết kế thuật toán: Xác định các thuật toán và quy trình để thực hiện chức năng mong muốn.
-Xác định giao diện hàm: Mô tả cách các module sẽ tương tác với nhau thông qua giao diện hàm.
-Xác định bảo mật: Bảo vệ hệ thống trước các mối đe dọa bảo mật thông qua các biện pháp an ninh.
Cả hai giai đoạn này đều rất quan trọng để đảm bảo rằng phần mềm được
thiết kế không chỉ đáp ứng các yêu cầu chức năng mà còn đảm bảo hiệu suất, bảo
mật và khả năng bảo trì. lOMoAR cPSD| 58815430
8. Phương pháp Agile trong phát triển phần mềm Phương pháp Agile là một
phương pháp quản lý dự án và phát triển sản phẩm linh hoạt, tập trung vào sự linh
hoạt và tương tác liên tục giữa các thành viên trong nhóm phát triển. Agile được
thiết kế để làm giảm thiểu rủi ro, tối ưu hóa sự linh hoạt và tăng cường sự hài lòng
của khách hàng thông qua việc cung cấp sản phẩm có giá trị cao sớm và thường
xuyên. Dưới đây là một số đặc điểm và phương pháp chính của Agile: Scrum:
Scrum Master: Người quản lý quy trình và đảm bảo nhóm áp dụng Scrum đúng cách.
Product Owner: Người đại diện cho khách hàng và quyết định về những tính năng cần ưu tiên.
Development Team: Nhóm các nhà phát triển thực hiện công việc và tự tổ chức. Sprint:
Thời gian cố định: Phát triển sản phẩm trong các chu kỳ ngắn gọi là Sprint,
thường kéo dài từ 2 đến 4 tuần.
Sprint Planning: Quyết định nhiệm vụ cần thực hiện trong Sprint và ước lượng thời gian. Backlog và Prioritization:
Product Backlog: Danh sách tất cả các tính năng, yêu cầu và công việc cần thực hiện.
Sprint Backlog: Tập trung vào các công việc cần hoàn thành trong một Sprint.
Prioritization: Xác định ưu tiên để đảm bảo các tính năng quan trọng nhất
được phát triển trước.
Demo và Retrospective:
Demo: Cuối mỗi Sprint, nhóm thực hiện một buổi demo để giới thiệu sản
phẩm cho khách hàng hoặc người sử dụng.
Retrospective: Cuộc họp để đánh giá Sprint vừa qua và cải thiện quy trình làm việc.
Continuous Integration và Testing:
Continuous Integration: Tự động hóa quá trình tích hợp mã nguồn từ các
nhóm phát triển khác nhau hàng ngày. lOMoAR cPSD| 58815430
Continuous Testing: Thực hiện kiểm thử liên tục để đảm bảo chất lượng sản phẩm. Tương tác Liên tục:
Daily Standup Meeting: Cuộc họp hàng ngày ngắn gọn để các thành viên
báo cáo tiến độ và cùng nhau giải quyết vấn đề.
Open Communication: Khuyến khích sự tương tác và giao tiếp mở giữa các thành viên trong nhóm.
Phương pháp Agile giúp nhóm phát triển phản hồi nhanh chóng từ khách
hàng, giảm thiểu rủi ro và tăng cường khả năng thích ứng của dự án đối với thay
đổi. Điều này thường dẫn đến việc tạo ra sản phẩm có giá trị cao và đáp ứng được
nhanh chóng cho nhu cầu thay đổi của khách hàng.