Bài giảng Công nghệ phần mềm - Phần mềm và công nghệ phần mềm - Lê Nguyễn Tuấn Thành
Kỹ thuật tạo yêu cầu là một quá trình của việc phát triển đặc
tả phần mềm
Quá trình thiết kế và cài đặt chuyển đổi đặc tả thành một
chương trình có thể chạy được
Xác thực (validation) liên quan đến đảm bảo rằng hệ thống
đáp ứng đặc tả của nó và yêu cầu người dùng
Tiến hóa liên quan đến thay đổi hệ thống sau khi nó đã đi vào
hoạt động
RUP là một mô hình quy trình chung để phân chia các hành
động theo các giai đoạn
Công cụ CASE là những hệ thống phần mềm được thiết kế để
hỗ trợ những hoạt động thông thường trong quy trình phần
mềm như: soạn thảo sơ đồ thiết kế, kiểm tra tính nhất quán của
sơ đồ, lưu vết những thử nghiệm chương trình được chạy
142 trang |
Chia sẻ: dntpro1256 | Lượt xem: 712 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Bài giảng Công nghệ phần mềm - Phần mềm và công nghệ phần mềm - Lê Nguyễn Tuấn Thành, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Công nghệ Phần mềm
Phần mềm và
Công nghệ phần mềm
Bộ Môn Công Nghệ Phần Mềm – Khoa CNTT
Trường Đại Học Thủy Lợi
Giảng viên: Lê Nguyễn Tuấn Thành
Email: thanhlnt@tlu.edu.vn
Nội dung
2
1. Phần mềm
2. Công nghệ phần mềm
3. Quản lý dự án phần mềm
4. Quy trình phần mềm
Bài giảng có sử dụng hình vẽ trong cuốn sách “Software Engineering, Ian Sommerville, 8th Edition, 2007”
Câu hỏi?
3
1. Phần mềm là gì?
2. Những thuộc tính của một phần mềm tốt là gì?
3. Công nghệ Phần mềm là gì?
4. Những thách thức chính mà Công nghệ Phần mềm phải đối
mặt là gì?
5. Sự khác nhau giữa Công nghệ Phần mềm và Khoa học Máy
tính là gì?
6. Sự khác nhau giữa Công nghệ Phần mềm và Kỹ thuật Hệ
thống (System Engineering) là gì?
7. Tiến trình phần mềm là gì?
8. Mô hình tiến trình phần mềm là gì?
9. Các chi phí của Công nghệ Phần mềm là gì?
10. Các phương thức Công nghệ Phần mềm là gì?
11. CASE (Computer-Aided Software Engineering) là gì?
1. Phần mềm là gì?
What is the Software?
4
5
Tầm quan trọng
6
Nền kinh tế của TẤT CẢ các quốc gia phát triển phụ
thuộc vào phần mềm,
Ngày càng có nhiều hệ thống được kiểm soát bởi
phần mềm,
Chi tiêu cho phần mềm thể hiện một phần đáng kể của
GNP1 ở tất cả các nước phát triển.
[1] GNP (Gross National Product): Tổng sản lượng quốc gia
Định nghĩa
7
Phần mềm là các chương trình máy tính và những tài liệu
liên quan (đặc tả yêu cầu, mô hình thiết kế, tài liệu hướng
dẫn sử dụng,)
Sản phẩm phần mềm được chia thành 2 loại:
1. Đại trà (Generic Product): được phát triển để bán cho một loạt
các đối tượng khách hàng khác nhau. Ví dụ: các phần mềm PC như
Excel hoặc Word
2. Chuyên biệt (Bespoke/Customised Product): được phát triển cho
một khách hàng duy nhất theo yêu cầu của họ. Ví dụ: các phần mềm
cho ngành thuế, ngân hàng, điện lực
Một phần mềm mới có thể được tạo ra bằng cách:
Phát triển những chương trình mới,
Cấu hình những hệ thống phần mềm chung,
Sử dụng lại phần mềm có sẵn
Chi phí phần mềm
(Software Costs)
8
Chi phí cho phần mềm thường chi phối chi phí
cho hệ thống máy tính,
Chi phí của phần mềm trên PC thường lớn hơn chi
phí phần cứng,
Chi phí cho phần mềm tập trung chủ yếu vào khâu
bảo trì (maintain) hơn là khâu phát triển (develop).
Với những hệ thống có vòng đời dài, chi phí bảo trì có thể
gấp nhiều lần chi phí phát triển
Thuộc tính của Phần mềm TỐT
9
Khả năng bảo trì
Phần mềm phải phát triển để đáp ứng nhu cầu thay đổi
Đáng tin cậy
Phần mềm phải thực sự đáng tin cậy
Hiệu quả
Phần mềm không nên tạo ra việc sử dụng lãng phí tài nguyên
hệ thống
Chấp nhận được
Phần mềm phải được chấp nhận bởi người dùng mà nó được
thiết kế. Điều này có nghĩa là nó có thể được hiểu, sử dụng và
tương thích với những hệ thống khác.
2. Công nghệ Phần mềm là gì?
What is the Software Engineering?
10
Công nghệ Xây dựng
11
Những bước nào cần
phải làm?
Quyết định cần xây những gì
Quyết định công trình sẽ
trông như thế nào
Cần xây bao nhiêu tầng, mỗi
tầng bao nhiêu phòng, mỗi
phòng rộng bao nhiêu,
Quyết định vật liệu xây
dựng
Lên kế hoạch dự án, lập lịch,
làm việc nhóm
Mô phỏng và kiểm tra
Tiến hành xây dựng
Hoạt động và bảo trì
Thành phần trong phát triển phần mềm
12
Không chỉ là kỹ năng công nghệ
13
Các trường đại học có xu hướng tập trung
vào công nghệ, bỏ qua yếu tố con người
và quá trình thực hiện.
Việc thực hiện theo quy trình có thể làm giảm tỷ lệ
lỗi lên tới 75%
Trong thực tế, lập trình thường chiếm ít thời
gian làm nhất trong toàn bộ quá trình thực
hiện dự án!
Khía cạnh của CNPM
14
Những quy trình cần thiết để chuyển một khái niệm
thành một sản phẩm (deliverable) có thể tiến hóa theo
thời gian
Làm việc với tài nguyên và thời gian bị giới hạn
Phải thỏa mãn một khách hàng
Quản lý rủi ro
Làm việc nhóm và giao tiếp
Định nghĩa
15
Công nghệ phần mềm là một quy trình kỹ thuật
(engineering discipline) liên quan đến tất cả khía
cạnh của sản xuất phần mềm
CNPM liên quan tới các lý thuyết, phương pháp và công cụ
cho việc phát triển phần mềm chuyên nghiệp
CNPM liên quan đến việc phát triển phần mềm hiệu
quả về chi phí.
Liên quan đến nhiều lĩnh vực
16
computer science (algorithms,data structures, languages,tools)
business/management (project mgmt,scheduling)
economics/marketing (selling,niche markets,monopolies)
communication (managing relations with stakeholders: customers,
management,developers,testers, sales)
law (patents, licenses, copyrights,reverse engineering)
sociology (modern trends in societies, localization,ethics)
political science (negotiations; topics at the intersection of law,
economics,and global societal trends; public safety)
psychology (personalities,styles, usability,what is fun)
art (GUI design,what is appealing to users)
necessarily "softer"; fewer clearly right/wrong answers
Các vai trò
17
Khách hàng (customer / client)
Muốn xây dựng phần mềm
Thường không biết rõ họ muốn những gì
Quản lý (managers)
Tạo kế hoạch, phối hợp thành viên trong nhóm
Khó dự đoán tất cả những vấn đề có thể phát sinh
Người phát triển (developers)
Thiết kế và viết mã nguồn
Khó có thể viết mã nguồn phức tạp cho những hệ thống lớn
Người kiểm thử (testers)
Thực hiện đảm bảo chất lượng (QA – Quality Assurance)
Không thể kiểm thử tất cả các trường hợp
Người dùng (Users)
Mua và sử dụng sản phẩm phần mềm
Hay thay đổi và có thể hiểu sai sản phẩm
Làm ra Phần mềm là việc khó
18
Historically, ~ 85% of software projects "fail”.Why?
management sets unrealistic expectations; devs don't correct them
overestimating the positive impact of shiny new tools and hardware
hired developers based on availability despite warning signs
personality conflicts between developers
changes in rate structure requirements in middle of work
one delay causes another (dev delay leads to test delay, etc.)
hacks and shortcuts
developers end up working "death marches" (6-day, 10-hour weeks)
overestimating how nearly done you are ("I'm 90% there!")
software written doesn't match the spec
developer time taken away by other tasks
tons of bugs come out in testing
developers don't listen to testers; ignore severity of bugs reported
management breaking promises (bonuses, time off, etc.)
Công nghệ Phần mềm vs. Khoa học Máy tính
19
Công nghệ Phần mềm Khoa học máy tính
Liên quan đến việc thực hành để phát
triển và phân phối phần mềm hữu ích
Liên quan tới học thuyết và những nguyên
lý cơ bản
Các học thuyết khoa học máy tính vẫn chưa đủ để đóng vai trò là cơ sở hoàn
chỉnh cho công nghệ phần mềm (không giống như các ngành Vật lý hay Kỹ thuật
điện)
Công nghệ Phần mềm vs. Kỹ thuật Hệ thống
20
Công nghệ Phần mềm Kỹ thuật Hệ thống
Là một phần của Kỹ thuật Hệ thống liên
quan tới phát triển hạ tầng phần mềm,
điều khiển, ứng dụng và cơ sở dữ liệu
trong hệ thống
Liên quan đến tất cả khía cạnh của phát
triển hệ thống dựa trên máy tính bao gồm
phần cứng, phần mềm và quy trình kỹ
thuật
Kỹ sư hệ thống liên quan đến đặc tả hệ thống (system specification), thiết kế
kiến trúc (architectural design), tích hợp (integration) và triển khai
(deployment)
Hoạt động trong CNPM
21
Vòng đời phát triển phần mềm (Software Development
Lifecycle - SDLC)
Chi phí của Công nghệ Phần mềm
22
Gần 60% chi phí dành cho việc phát triển (development),
khoảng 40% cho việc kiểm thử (test).
Chi phí tiến hóa (evolution costs) thường vượt quá chi
phí phát triển (development costs)
Phân phối chi phí phụ thuộc vào mô hình phát
triển được sử dụng
Phân phối Chi phí theo hoạt động
(Activity cost distribution)
23
Các phương pháp CNPM
(Software Engineering Methods)
24
Những cách tiếp cận có cấu trúc để phát triển PM:
Mô hình hệ thống (system models)
Hệ thống ký hiệu (notations)
Quy tắc (rules)
Tư vấn thiết kế (design advice)
Hướng dẫn quá trình (process guidance)
Miêu tả mô hình
Những miêu tả của mô hình đồ họa nên được tạo ra
Quy tắc
Những rằng buộc áp dụng cho mô hình hệ thống
Khuyến cáo
Những tư vấn cho thực hành thiết kế tốt
Hướng dẫn quá trình
Những hành động phải tuân theo
Thách thức chính đối với CNPM
25
Tính không đồng nhất
Phát triển những kỹ thuật để xây dựng phần mềm đáp ứng
những nền tảng và môi trường thực thi không đồng nhất
Sự phân phối
Phát triển những kỹ thuật để dẫn đến phân phối phần mềm
nhanh hơn
Độ tin cậy
Phát triển những kỹ thuật để chứng minh phần mềm có thể
được sự tin tưởng bởi người dùng
Trách nhiệm chuyên môn và đạo đức
26
CNPM liên quan đến những trách nhiệm hơn là đơn giản
chỉ áp dụng những kỹ năng kỹ thuật.
Kỹ sư phần mềm phải cư xử theo một cách trung thực và
có trách nhiệm đạo đức nếu họ muốn được tôn trọng
như các chuyên gia.
Hành vi đạo đức không chỉ đơn giản là tuân theo pháp
luật
Trách nhiệm chuyên môn
27
Tính bảo mật (confidentiality)
Các kỹ sư thường phải tôn trọng sự bảo mật của người sử dụng lao
động hoặc khách hàng của họ bất kể một hợp đồng bảo mật chính thức
có được ký kết hay không.
Năng lực (competence)
Các kỹ sư không nên làm sai lệch trình độ của mình. Họ không nên cố
chấp nhận công việc vượt quá khả năng của mình.
Quyền sở hữu trí tuệ (intellectual property rights)
Các kỹ sư nên biết về luật pháp địa phương quy định việc sử dụng sở
hữu trí tuệ như bằng sáng chế, bản quyền, Họ nên cẩn thận để đảm
bảo rằng sở hữu trí tuệ của người sử dụng lao động và khách hàng được
bảo vệ.
Lạm dụng máy tính (computer misuse)
KSPM không nên sử dụng kỹ năng của mình để lạm dụng máy tính của
người khác.
Lạm dụng máy tính bao gồm từ những việc tương đối tầm thường (như
chơi game trên máy tính của người sử dụng lao động) đến những việc
nghiêm trọng (như phát tán virus).
Bộ Quy tắc Đạo đức ACM/IEEE
28
Các hiệp hội chuyên nghiệp ở Hoa Kỳ đã hợp tác để đưa
ra một bộ quy tắc đạo đức (Code of Ethics)
Thành viên của những tổ chức này đăng ký vào bộ quy
tắc hành động khi họ gia nhập
Bộ quy tắc bao gồm 8 nguyên tắc liên quan đến hành vi
và quyết định tạo bởi những kỹ sư phần mềm chuyên
nghiệp
Bộ quy tắc đạo đức – 8 Nguyên tắc
29
1. CỘNG ĐỒNG (PUBLIC)
Kỹ sư phần mềm (KSPM) phải hành động phù hợp với lợi ích cộng đồng
2. KHÁCH HÀNG VÀ NGƯỜI SỬ DỤNG LAO ĐỘNG (CLIENT & EMPLOYER)
KSPM phải hành động cho lợi ích tốt nhất của khách hàng và người sử dụng lao động phù hợp với lợi
ích cộng đồng
3. SẢN PHẨM (PRODUCT)
KSPM phải đảm bảo rằng sản phẩm của họ và những thay đổi liên quan đáp ứng những chuẩn
chuyên môn cao nhất có thể
4. ĐÁNH GIÁ (JUDGMENT)
KSPM phải duy trì tính toàn vẹn và độc lập trong sự đánh giá chuyên nghiệp của mình
5. QUẢN LÝ (MANAGEMENT)
Nhà quản lý và lãnh đạo CNPM phải đăng ký và thúc đẩy cách tiếp cận đạo đức đối với việc quản lý
phát triển và bảo trì phần mềm
6. CHUYÊN NGHIỆP (PROFESSION)
KSPM phải nâng cao tính toàn vẹn và uy tín nghề nghiệp phù hợp với lợi ích cộng đồng
7. ĐỒNG NGHIỆP (COLLEAGUES)
KSPM phải công bằng và hỗ trợ đồng nghiệp của mình
8. BẢN THÂN (SELF)
KSPM phải tham gia học tập suốt đời liên quan đến thực hành nghề nghiệp và thúc đẩy tiếp cận đạo
đức đối với việc thực hành này
Tình huống khó xử về đạo đức
(Ethical dilemmas)
30
Sự không đồng thuận về nguyên tắc với chính sách quản
lý cấp cao
Người sử dụng lao động hành xử theo cách phi đạo đức
và phát hành một hệ thống thiếu an toàn mà không hoàn
thành việc thử nghiệm (testing)
Tham gia phát triển những hệ thống vũ khí quân sự hoặc
hệ thống hạt nhân
Tóm tắt Công nghệ Phần mềm (1/2)
31
CNPM là một ngành kỹ thuật liên quan đến tất cả khía cạnh
của sản phẩm phần mềm
Sản phẩm phần mềm bao gồm các chương trình được phát
triển và tài liệu liên quan.
Những thuộc tính thiết yếu của sản phẩm là:
tính bảo trì (maintainability),
tính tin cậy (dependability),
tính hiệu quả (efficiency) và
tính sử dụng (usability)
Các phương pháp là những cách tổ chức để sản xuất phần
mềm. Chúng bao gồm:
những đề xuất cho quá trình phải tuân theo,
bộ ký hiệu sử dụng,
những quy tắc chi phối việc miêu tả hệ thống được sản xuất và
những hướng dẫn thiết kế
Tóm tắt Công nghệ Phần mềm (2/2)
32
KSPM có những trách nhiệm đối với nghề nghiệp và cộng
đồng. Họ không nên chỉ đơn giản liên quan với những vấn
đề kỹ thuật
Các hiệp hội chuyên nghiệp công bố bộ quy tắc ứng xử
nhằm xác định những tiêu chuẩn hành vi mong muốn của
những thành viên
3. Quản lý dự án Phần mềm
Software Project Management
33
Mục tiêu
34
Giới thiệu quản lý dự án phần mềm và miêu tả những đặc
điểm riêng biệt của nó
Giải thích những tác vụ chính được thực hiện bởi những
người quản trị dự án (project managers)
Thảo luận về lập kế hoạch dự án và quá trình lập kế
hoạch
Chỉ ra bằng cách nào những biểu diễn lịch trình đồ họa
(graphial schedule) được sử dụng để quản lý dự án
Thảo luận những khái niệm về rủi ro (risk) và quá trình
quản lý rủi ro
Chủ đề được đề cập
(Topics covered)
35
Những hoạt động quản lý (Management activities)
Lập kế hoạch dự án (project planning)
Lập lịch trình dự án (project scheduling)
Quản lý rủi ro (risk management)
Quản lý Dự án Phần mềm
(Software project management)
36
Liên quan đến những hoạt động để đảm bảo rằng:
phần mềm được phân phối đúng hạn (on time),
theo đúng lịch trình (on schedule) và
phù hợp với những yêu cầu của công ty phát triển cũng như
công ty đặt hàng phần mềm
Quản lý dự án là cần thiết do quá trình phát triển phần
mềm luôn luôn phụ thuộc vào ngân sách và những rằng
buộc lịch trình được đặt ra bởi công ty phát triển phần
mềm
Những Hoạt động Quản lý
(Management activities)
37
Viết đề xuất (proposal writing)
Lập kế hoạch và lịch trình dự án (project planning &
scheduling)
Lập chi phí dự án (project costing)
Giám sát dự án và duyệt lại (project monitoring &
reviews)
Lựa chọn và đánh giá nhân sự (personnel selection &
evaluation)
Viết báo cáo và trình bày (report writing &
presentations)
Tính chất chung của Quản lý
(Management commonalities)
38
Những hoạt động này không phải là đặc thù (peculiar)
của quản lý phần mềm
Nhiều kỹ thuật trong các ngành quản lý dự án khác đều
có thể áp dụng cho quản lý dự án phần mềm
Lập nhân dự dự án
(Project staffing)
39
Có thể không thể bổ nhiệm những người lý tưởng để làm
việc trong một dự án, do:
Ngân sách dự án không cho phép sử dụng những nhân viên
được trả lương cao
Nhân sự với kinh nghiệm thích hợp có thể không sẵn có
Công ty có thể mong muốn phát triển những kỹ năng cho nhân
viên trong dự án phần mềm
Nhà quản lý phải làm việc với những rằng buộc này, đặc
biệt khi có tình trạng thiếu nhân sự được huấn luyện
Lập kế hoạch dự án
(Project planning)
40
Có thể là hoạt động quản lý dự án tốn nhiều thời gian
nhất
Là hoạt động liên tục từ lúc hình thành khái niệm ban đầu
đến khi phân phối hệ thống.
Những kế hoạch phải thường xuyên được sửa lại khi có
thông tin mới
Nhiều loại khác nhau của kế hoạch phải được phát triển
để hỗ trợ kế hoạch dự án phần mềm chính, cái mà liên
quan đến lịch trình và ngân sách dự án
Các kiểu kế hoạch dự án
41
Kế hoạch Miêu tả
Kế hoạch chất lượng
(Quality plan)
Miêu tả những thủ tục và tiêu chuẩn chất lượng được sử
dụng trong một dự án
Kế hoạch xác nhận
(Validation plan)
Miêu tả cách tiếp cận, tài nguyên và lịch trình được sử dụng
cho xác nhận hệ thống
Kế hoạch quản lý và
cấu hình
Miêu tả những thủ tục và cấu trúc quản lý cấu hình được sử
dụng
Kế hoạch bảo trì
(Maintenance plan)
Dự đoán những yêu cầu bảo trì của hệ thống, chi phí bảo trì
và công sức được yêu cầu
Kế hoạch phát triển
nhân sự
Miêu tả cách phát triển kỹ năng và kinh nghiệm cho những
thành viên nhóm dự án
Quá trình lập Kế hoạch Dự án
(Project planning process)
42
Thiết lập những rằng buộc của dự án
Đánh giá ban đầu về những thông số dự án
Định nghĩa những cột mốc của dự án và sản phẩm tương ứng với từng mốc
Chừng nào dự án còn chưa được hoàn thành hoặc bị hủy bỏ, lặp các bước sau:
Xây dựng lịch trình dự án
Khởi đầu những hoạt động theo lịch trình
Chờ (một lúc)
Xét lại tiến độ dự án (project progress)
Xem lại ước lượng của những thông số dự án
Cập nhật lịch trình dự án
Tái thương lượng những rằng buộc dự án và sản phẩm đi kèm
Nếu (gia tăng vấn đề) thì:
Khởi đầu xét lại kỹ thuật và sử đổi có thể
Kết thúc điều kiện nếu
Kết thúc lặp
Kế hoạch dự án
(Project plan)
43
Kế hoạch dự án đề cập đến:
Các nguồn lực có sẵn cho dự án
Phân chia công việc (work breakdown)
Lịch trình cho công việc
Cấu trúc kế hoạch dự án
(Project plan structure)
44
Giới thiệu (introduction)
Tổ chức dự án (project organization)
Phân tích rủi ro (risk analysis)
Những yêu cầu tài nguyên phần cứng và phần
mềm
Phân chia công việc (work breakdown)
Lịch trình dự án (project schedule)
Những cơ chế báo cáo và giám sát
Lập lịch trình Dự án
(Project scheduling)
45
Chia dự án thành các tác vụ và ước lượng thời gian & tài
nguyên được yêu cầu để hoàn thành mỗi tác vụ
Tổ chức những tác vụ đồng thời để tối ưu hóa việc sử
dụng nhân lực (workforce)
Tối giản hóa những phụ thuộc giữa các tác vụ để giảm độ
trễ do một tác vụ phải đợi tác vụ khác hoàn thành
Việc lập lịch trình phụ thuộc vào trực giác và kinh
nghiệm của những nhà quản trị dự án
Quá trình lập Lịch trình Dự án
(Project scheduling process)
46
Vấn đề trong việc lập Lịch trình
(Scheduling problems)
47
Ước lượng độ khó của những vấn đề và từ đó chi phí để
phát triển một giải pháp là khó
Năng suất (productivity) không tỷ lệ với số lượng người
làm việc trên một tác vụ
Thêm nhân lực vào một dự án quá hạn khiến nó càng bị
trễ hơn do các chi phí giao tiếp
Việc không mong đợi luôn luôn xảy ra. Do đó phải luôn
có dự phòng (contingency) trong việc lập kế hoạch
Biểu đồ hình cột và Mạng hoạt động
(Bar charts and activity networks)
48
Những ký hiệu đồ họa được sử dụng để minh họa lịch
trình dự án
Hiển thị sự phân nhỏ dự án thành các tác vụ. Những tác
vụ không nên quá nhỏ
Nên kéo dài trong khoảng 1 hay 2 tuần
Biểu đồ hoạt động hiển thị sự phụ thuộc giữa các tác vụ
và đường găng (critical path)
Biểu đồ hình cột hiển thị lịch trình theo thời gian biểu
Thời lượng Tác vụ và Những phụ thuộc
(Task durations and dependencies)
49
Chỉ ra tên hoạt động, ai có trách nhiệm với mỗi hoạt động và khi nào hoạt
động đó được lên lịch bắt đầu hoặc kết thúc.
Biểu đồ thanh (Sơ đồ Gantt) (1/2)
50
Stt Task
Start on
Day
Task
Duration
Start
Date
End
Date
1
Đồng bộ DB giữa 2 hệ thống backup VN (114)
và backup Sing (230) 0 8 30-09-16 07-10-16
2
Test KT đồng bộ giữa 2 hệ thống backup
VN và backup Sing 10 2 10-10-16 11-10-16
5 Test đồng bộ với khách hàng lần 1 12 6 12-10-16 17-10-16
6 Xây dựng Testcases 18 5 18-10-16 22-10-16
7
KT xây dựng mô hình đồng bộ mới (db
phân tán) gồm 4 servers 23 3 23-10-16 25-10-16
9 Test KT 26 2 26-10-16 27-10-16
10 Test đồng bộ với khách hàng lần 2 28 7 28-10-16 03-11-16
11 Các bộ phận nghiệm thu pha 2 35 1 04-11-16 04-11-16
Biểu đồ thanh (Sơ đồ Gantt)
(2/2)
51
0 5 10 15 20 25 30
Đồng bộ DB giữa 2 hệ thống backup VN (114) và
backup Sing (230)
Test KT đồng bộ giữa 2 hệ thống backup VN và
backup Sing
Test đồng bộ với khách hàng lần 1
Xây dựng Testcases
KT xây dựng mô hình đồng bộ mới (db phân tán)
gồm 4 servers
Test KT
Test đồng bộ với khách hàng lần 2
Các bộ phận nghiệm thu pha 2
Kết thúc pha 2
Time & Task Duration
T
a
sk
s
Biểu đồ Grantt của Pha 2 [20/09 - 18/10]
• Microsoft Excel, Microsoft Project.
Công cụ vẽ Sơ đồ Gantt
52
Đường thời gian của hoạt động
(Activity timeline)
53
Biểu đồ Phân bổ Nhân viên
(Staff allocation)
54
Biểu đồ Mạng lưới Hoạt động
Các sơ đồ mạng lưới hoạt động chỉ ra các lệ thuộc
giữa các hoạt động khác nhau tạo thành dự án:
Công việc: các việc cần làm
Sự kiện: Kết quả công việc
Mối liên hệ giữa các công việc (CV)
Có CV trước không có CV sau
Có CV sau không có CV trước
Có cả CV trước và sau
Biểu đồ Mạng lưới
56
Có 2 dạng biểu diễn
AOA: các mũi tên chỉ
các công việc còn các
nút chỉ các sự kiện
AON: Các công việc
được biểu diễn trên
các nút
Biểu đồ Mạng lưới (Sơ đồ AOA)
Đường găng
Công việc găng (critical task) là các công việc có trữ lượng
thời gian (thời gian tự do) bằng 0. Tức là các công việc đã bị
fix cứng thời gian.
Đường găng (critical path) là đường dài nhất đi xuyên mạng đi
từ thời điểm bắt đầu tới thời điểm kết thúc đi qua các công việc
găng (critical task)
Ý nghĩa: Độ dài của đường găng trên trục thời gian, chính là
thời lượng nhỏ nhất có thể để dự án hoàn thành theo kế hoạch,
tức là thời gian hoàn thành dự án
Phương pháp Đường găng CPM (1/3)
59
ES (Early Start):Thời gian bắt đầu sớm
EF (Early Finish):Thời gian kết thúc sớm
LS (Late Start):Thời gian bắt đầu muộn
LF (Late Finish):Thời gian kết thúc muộn
Tg là thời gian hoàn thành
ES của các công việc ngay khi bắt đầu quy
định là 1
ES = max (EF của các công việc trước đó) + 1
EF = ES + Tg – 1
LF = LS + Tg – 1
Tg tự do = LS – ES
Phương pháp Đường găng CPM (2/3)
60
Phương pháp Đường găng CPM (3/3)
61
Đường găng là đường chứa toàn các công việc có thời gian tự do là 0.
Trong sơ đồ trên, đường B → E là đường găng.
Bài tập: Tìm Đường găng của Dự án sau
Công việc Thời gian (ngày) Công việc trước
A 5
B 6
C 10 A,B
D 7 B
E 3 C
F 4 C,D
G 9 E,F
Quản trị Rủi ro
(Risk management)
63
Một rủi ro là xác suất xảy ra một số tình huống bất lợi
Những rủi ro dự án tác động đến lịch trình hoặc tài nguyên
Những rủi ro sản phẩm tác động đến chất lượng hoặc hiệu
suất của phần mềm được phát triển
Những rủi ro kinh doanh tác động đến công ty phát triển hoặc
đặt hàng (procure) phần mềm
Quản trị rủi ro liên quan đến xác định những rủi ro và
thiết lập những kế hoạch để tối giản hóa ảnh hưởng
của chúng đối với dự án
64
Các rủi ro phần mềm (1/2)
(Software risks)
65
Rủi ro Mức
ảnh hưởng
Miêu tả
Nhân sự biến động
(Staff turnober)
Dự án Nhân viên có kinh nghiệm rời khỏi dự
án trước khi nó hoàn thành
Sự quản lý thay đổi
(Management change)
Dự án Có một sự thay đổi trong cách quản lý
công ty với những ưu tiên khác
Phần cứng không có sẵn
(Hardward unavailability)
Dự án Phần cứng cần thiết cho dự án không
được phân phối theo như lịch trình
Yêu cầu thay đổi
(Requirements change)
Dự án và
Sản phẩm
Có một số lượng lớn sự thay đổi trong
yêu cầu hơn dự kiến
Đặc tả bị trễ
(Specification delays)
Dự án và
Sản phẩm
Đặc tả của những giao diện cần thiết
không sẵn có trên lịch trình
Ước tính thấp kích thước
(Size underestimate)
Dự án và
Sản phẩm
Kích thước của hệ thống đã bị ước tính
thấp
Các rủi ro phần mềm (2/2)
(Software risks)
66
Rủi ro Mức
ảnh hưởng
Miêu tả
Công cụ CASE kém hiệu
quả
Sản phẩm Những công cụ CASE hỗ trợ dự án
không thực thi như dự kiến
Công nghệ thay đổi
(Technology changes)
Kinh doanh Công nghệ nền tảng mà hệ thống được
xây dựng trên đó bị thay thế bởi công
nghệ mới
Sự cạnh tranh sản phẩm
(Product competition)
Kinh doanh Một sản phẩm cạnh tranh đã được đưa
ra thị trường trước khi sản phẩm hoàn
thiện
Quá trình quản trị rủi ro (1/2)
(The risk management process)
67
Xác định rủi ro (risk identification)
Xác định những rủi ro dự án, sản phẩm và kinh doanh
Phân tích rủi ro (risk analysis)
Đánh giá khả năng và hậu quả của những rủi ro này
Lập kế hoạch rủi ro (risk planning)
Xây dựng những kế hoạch để tránh hoặc tối giản hóa ảnh
hưởng của rủi ro
Giám sát rủi ro (risk monitoring)
Giám sát rủi ro xuyên suốt dự án
Quá trình quản trị rủi ro (2/2)
(The risk management process)
68
Xác định Rủi ro
(Risk identification)
69
Rủi ro công nghệ (technology risks)
Rủi ro con người (people risks)
Rủi ro tổ chức công ty (organizational risks)
Rủi ro yêu cầu (requirement risks)
Rủi ro ước lượng (estimation risks)
Rủi ro và Những loại rủi ro (1/2)
(Risks and risk types)
70
Loại rủi ro Những rủi ro có thể
Công nghệ
• Cơ sở dữ liệu được sử dụng trong hệ thống không thể xử lý
nhiều giao dịch (transactions) trong một giây như mong đợi
• Những thành phần hệ thống nên được sử dụng chứa những khiếm
khuyết dẫn đến hạn chế chức năng của chúng
Con người
• Không thể tuyển dụng nhân sự có những kỹ năng được yêu cầu
• Nhân sự chủ chốt ốm và không sẵn sàng trong những thời điểm
quan trọng
• Khóa huấn luyện yêu cầu cho nhân sự không sẵn có
Tổ chức công ty
• Công ty phải tái cấu trúc và quản lý khác chịu trách nhiệm dự án
• Những vấn đề tài chính công ty buộc ngân sách dự án giảm
Công cụ
• Mã được sinh ra bởi những công cụ CASE không hiệu quả
• Công cụ CASE không thể được tích hợp
Rủi ro và Những loại rủi ro (2/2)
(Risks and risk types)
71
Loại rủi ro Những rủi ro có thể
Yêu cầu
• Thay đổi yêu cầu dẫn đến việc thiết kế lại phần lớn được đề xuất
• Khách hàng không hiểu được ảnh hưởng của việc yêu cầu thay đổi
Ước lượng
• Thời gian yêu cầu để phát triển phần mềm bị ước lượng quá thấp
• Tỷ lệ khuyết khiếm phải sửa bị ước lượng quá thấp
• Kích thước của phần mềm bị ước lượng quá thấp
Phân tích rủi ro (1/4)
(Risk analysis)
72
Đánh giá xác suất và tầm quan trọng của từng rủi ro
Xác suất có thể là: rất thấp, thấp, trung bình, cao hoặc rất
cao
Những tác động rủi ro có thể là: thảm khốc (catastrophic),
nghiêm trọng (serious), chấp nhận được (tolerable) hoặc
không đáng kể (insignificant)
Phân tích rủi ro (2/4)
(Risk analysis)
73
Rủi ro (Risk) Xác suất
(Probability)
Tác động
(Effects)
Những vấn đề tài chính công ty buộc ngân sách dự
án giảm
Thấp Thảm khốc
Không thể tuyển dụng nhân sự có những kỹ năng
được yêu cầu
Cao Thảm khốc
Nhân sự chủ chốt ốm và không sẵn sàng trong
những thời điểm quan trọng
Trung bình Nghiêm trọng
Những thành phần hệ thống nên được sử dụng
chứa những khiếm khuyết dẫn đến hạn chế chức
năng của chúng
Trung bình Nghiêm trọng
Thay đổi yêu cầu dẫn đến việc thiết kế lại phần lớn
được đề xuất
Trung bình Nghiêm trọng
Công ty phải tái cấu trúc và quản lý khác chịu trách
nhiệm dự án
Cao Nghiêm trọng
Phân tích rủi ro (3/4)
(Risk analysis)
74
Rủi ro (Risk) Xác suất
(Probability)
Tác động
(Effects)
Cơ sở dữ liệu được sử dụng trong hệ thống không
thể xử lý nhiều giao dịch trong một giây như mong
đợi
Trung bình Nghiêm trọng
Thời gian yêu cầu để phát triển phần mềm bị ước
lượng quá thấp
Cao Nghiêm trọng
Công cụ CASE không thể được tích hợp Cao Chấp nhận
được
Khách hàng không hiểu được ảnh hưởng của việc
yêu cầu thay đổi
Trung bình Chấp nhận
được
Khóa huấn luyện yêu cầu cho nhân sự không sẵn
có
Trung bình Chấp nhận
được
Tỷ lệ khuyết khiếm phải sửa bị ước lượng quá thấp Trung bình Chấp nhận
được
Phân tích rủi ro (4/4)
(Risk analysis)
75
Rủi ro (Risk) Xác suất
(Probability)
Tác động
(Effects)
Kích thước của phần mềm bị ước lượng quá thấp Cao Chấp nhận
được
Mã được sinh ra bởi những công cụ CASE không
hiệu quả
Trung bình Không đáng kể
Lập kế hoạch rủi ro
(Risk planning)
76
Chiến thuậtTránh (Avoidance strategies)
Xác suất phát sinh rủi ro bị giảm đi
Chiến thuậtTối giản (Minimization strategies)
Ảnh hưởng của rủi ro với dự án hoặc sản phẩm sẽ bị giảm đi
Kế hoạch Dự phòng (Contingency plans)
Nếu phát sinh rủi ro, những kế hoạch dự phòng sẽ được sử
dụng để ứng phó với rủi ro đó
Những chiến thuật quản trị rủi ro (1/2)
(Risk management strategies)
77
Rủi ro Chiến thuật
Vấn đề tài chính
công ty
Chuẩn bị một tài liệu tóm lược cho quản lý cấp cao để chỉ ra
rằng dự án đang có đóng góp rất quan trọng như thế nào cho
các mục tiêu kinh doanh
Vấn đề tuyển dụng Cảnh báo khách hàng về những khó khăn tiềm ẩn và khả năng bị
chậm trễ, tiến hành điều tra những thành phần mua vào
Nhân viên ốm Tổ chức lại nhóm sao cho có thêm nhiều chồng lặp (overlap)
trong công việc và con người do đó các thành viên hiểu được
công việc của nhau
Thành phần kiếm
khuyết
Thay thế những thành phần khiếm khuyết tiềm ẩn bằng cách
mua vào những thành phần có độ tin cậy cao
Những chiến thuật quản trị rủi ro (2/2)
(Risk management strategies)
78
Rủi ro Chiến thuật
Thay đổi yêu cầu Lấy được thông tin truy xuất để đánh giá tác động của việc thay
đổi yêu cầu, tối đa hóa thông tin ẩn trong thiết kế
Tái cấu trúc công
ty
Chuẩn bị một tài liệu tóm lược cho quản lý cấp cao để chỉ ra
rằng dự án đang có đóng góp rất quan trọng như thế nào cho
các mục tiêu kinh doanh
Hiệu suất cơ sở dữ
liệu
Xem xét khả năng mua một cơ sở dữ liệu hiệu suất cao hơn
Thời gian phát triển
bị ước lượng quá
thấp
Xem xét mua thêm thành phần, xem xét sửa dụng một trình
tạo mã chương trình tự động
Giám sát rủi ro
(Risk monitoring)
79
Đánh giá thường xuyên từng rủi ro để quyết định liệu nó
đang trở nên ít xảy ra hơn hay ngược lại
Đánh giá liệu ảnh hưởng của rủi ro có thay đổi không
Mỗi rủi ro chính nên được thảo luận tại các buổi họp
quản lý tiến trình
Tóm tắt Quản lý dự án phần mềm (1/2)
80
Quản lý dự án tốt là cần thiết cho sự thành công của dự
án
Bản chất phi vật thể của phần mềm gây khó khăn cho
việc quản lý
Những nhà quản lý có vai trò đa dạng nhưng những hoạt
động quan trọng nhất của họ là:
lập kế hoạch (planning),
ước lượng (estimating) và
lập lịch trình (scheduling)
Lập kế hoạch và ước lượng là những quá trình lặp lại
được tiếp tục trong suốt quá trình thực hiện dự án
Tóm tắt Quản lý dự án phần mềm (2/2)
81
Một cột mốc (milestone) dự án là một trạng thái có thể
dự đoán được, tại đó một báo cáo chính thức về tiến độ
được trình bày cho ban quản lý
Lập lịch trình dự án liên quan đến chuẩn bị những biểu
diễn đồ họa khác nhau để hiển thị những hoạt động của
dự án, khoảng thời gian và nhân sự
Quản lý rủi ro liên quan đến xác định những rủi ro có thể
ảnh hưởng đến dự án và lập kế hoạch để đảm bảo rằng
những rủi ro này không trở thành những các mối đe dọa
lớn
4. Quy trình Phần mềm
Software Processes
82
Mục tiêu
83
Giới thiệu những mô hình quy trình phát triển phần mềm
Mô tả những mô hình quy trình chung và khi nào chúng
có thể được sử dụng
Mô tả phác thảo những mô hình quy trình cho yêu cầu kỹ
thuật (requirement engineering), phát triển phần mềm
(software development), kiểm thử (testing) và tiến hóa
(evolution)
Giải thích mô hình RUP (Rational Unified Process)
Giới thiệu công nghệ CASE để hỗ trợ những hoạt động
tiến trình phần mềm
Chủ đề được đề cập
(Topics covered)
84
Những mô hình quy trình phần mềm (Software Process
Models)
Quy trình lặp (Process Iteration)
Những hoạt động trong quy trình (Process Activities)
RUP (Rational Unified Process)
CASE (Computer-aided Software Engineering)
Quy trình phần mềm là gì?
85
Một tập các hành động có cấu trúc mà mục
đích của chúng là sự phát triển hoặc tiến hóa
của phần mềm.
Mô hình Quy trình Phần mềm
(Software Process Model)
86
Một mô hình quy trình phần mềm là một biểu diễn
trừu tượng được đơn giản hóa của quy trình phần
mềm.
Trình bày miêu tả về một vài khía cạnh cụ thể của quy trình.
Khía cạnh luồng công việc (workflow perspective): chuỗi
những hành động trong quy trình;
Khía cạnh luồng dữ liệu (data-flow perspective): luồng
thông tin trong quy trình
Khía cạnh vai trò (role/action perspective): ai làm việc gì
trong quy trình
Những Mô hình Quy trình Phần mềm
87
Mô hình thác nước (waterfall)
Tuần tự, tách biệt và làm rõ những giai đoạn của đặc tả và phát
triển
Phát triển tiến hóa (evolutionary development)
Các giai đoạn đặc tả, phát triển và kiểm chứng được xen kẽ
nhau
Mô hình dựa trên thành phần (component-based)
Hệ thống được lắp ráp từ những thành phần sẵn có
Mô hình phát triển lặp (iterative development)
Mô hình Thác nước
(Waterfall)
88
Mô hình Thác nước
(Waterfall)
89
Mô hình thác nước:
Các giai đoạn
90
1. Phân tích và định nghĩa yêu cầu (Requirement analysis &
definition)
2. Thiết kế hệ thống và phần mềm (System & software
design)
3. Cài đặt và kiểm thử đơn vị (Implementation & unit
testing)
4. Tích hợp và kiểm thử hệ thống (Integration & system
testing)
5. Vận hành và kiểm thử (Operation & maintenance)
Mô hình thác nước:
Phân tích
91
Yếu điểm chính: khó khăn trong việc thích ứng với thay
đổi sau khi tiến trình đã được tiến hành.
Một giai đoạn phải được hoàn thành trước khi chuyển sang giai
đoạn tiếp theo
Phải chờ đợi lâu trước khi có sản phẩm cuối
Chỉ thích hợp khi những yêu cầu được hiểu rõ và
những thay đổi sẽ bị giới hạn trong tiến trình thiết kế
Tuy nhiên, trong thực tế có rất ít những hệ thống nghiệp
vụ có các yêu cầu ổn định.
Mô hình này hầu như được sử dụng cho những dự án kỹ
thuật hệ thống lớn
Mô hình chữ V
(V Model)
92
Mô hình Phát triển Tiến hóa
(Evolutionary Development)
93
Ý tưởng:
Xây dựng một mẫu thử ban đầu và đưa cho người sử dụng xem xét,
Sau đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thỏa
mãn yêu cầu của người sử dụng thì dừng lại
2 phương pháp:
Phát triển thăm dò: mục đích là để làm việc với khách hàng và
đưa ra hệ thống cuối cùng từ những đặc tả sơ bộ ban đầu
Thường bắt đầu thực hiện với những yêu cầu được tìm hiểu rõ ràng
và sau đó, bổ sung những đặc điểm mới được đề xuất bởi KH
Loại bỏ mẫu thử: mục đích là để tìm hiểu các yêu cầu của hệ thống
Thường bắt đầu với những yêu cầu không rõ ràng và ít thông tin.
Các mẫu thử sẽ được xây dựng và chuyển giao tới cho người sử
dụng
Từ đó có thể phân loại những yêu cầu nào là thực sự cần thiết và lúc này
mẫu thử không còn cần thiết nữa
Mô hình Phát triển Tiến hóa
Minh họa
94
Mô hình Phát triển Tiến hóa
Phân tích
95
Vấn đề
Thiếu tầm nhìn của cả quy trình
Hệ thống thường hướng cấu trúc nghèo nàn
Yêu cầu những kỹ năng đặc biệt (ví dụ: về mặt ngôn ngữ để
tạo nguyên mẫu nhanh)
Tính ứng dụng:
Cho những hệ thống tương tác vừa và nhỏ
Cho những phần (module) của hệ thống lớn (ví dụ: giao diện
người dùng)
Cho những hệ thống có vòng đời ngắn
Mô hình dựa trên thành phần
(Component-based Software Engineering)
96
Dựa trên việc tái sử dụng có hệ thống,
Hệ thống được tích hợp từ những thành phần sẵn có hoặc từ
những hệ thống COTS (Commercial-off-the-shelf)
Những giai đoạn:
Phân tích thành phần
Thay đổi yêu cầu
Thiết kế hệ thống với việc sử dụng lại
Phát triển và tích hợp
Cách tiếp cận này đang ngày càng được sử dụng nhiều khi
các tiêu chuẩn thành phần được đưa vào sử dụng
Phát triển hướng Tái sử dụng
(Reuse-oriented development)
97
Quy trình lặp
(Process iteration)
98
Các yêu cầu hệ thống LUÔN LUÔN tiến hóa trong quá
trình thực hiện dự án
vì thế lặp quy trình luôn là một phần của quy trình cho những
hệ thống lớn
Quá trình lặp có thể được áp dụng với bất kỳ mô hình
quy trình chung nào
Hai cách tiếp cận liên quan
Phân phối gia tăng (incremental delivery)
Phát triển xoắn ốc (spiral development)
Mô hình Bản mẫu
(Prototyping Model)
99
Phân phối gia tăng
(Incremental delivery)
100
Thay vì phát triển và phân phối hệ thống một lần, sự
phát triển và phân phối được chia ra thành nhiều
vòng, tăng dần, gọi là các gia số (increment)
Mỗi gia số phân phối một tập con các chức năng được yêu
cầu
Những yêu cầu người dùng được sắp ưu tiên và yêu cầu ưu
tiên cao nhất được bao gồm trong những gia số đầu tiên
Phát triển gia tăng
(Incremental development)
101
Phát triển gia tăng
(Incremental development)
102
Phát triển gia tăng
Ưu điểm
103
Khách hàng không phải đợi cho đến khi toàn bộ hệ
thống được phân phối trước khi có thể thu được giá
trị từ nó.
Những gia số bước đầu giống như một nguyên mẫu để
giúp phát hiện những yêu cầu cho những gia số bước sau
Bản phát hành đầu tiên sẽ thỏa mãn hầu hết những
yêu cầu quan trọng nhất của KH
KH có thể sử dụng phần mềm ngay lập tức
Những dịch vụ hệ thống có độ ưu tiên cao nhất được
phân phối trước tiên, và có xu hướng nhận được kiểm
thử nhiều nhất
Nguy cơ thất bại toàn bộ dự án thấp hơn
Mô hình phát triển xoắn ốc
(Spiral development)
104
Được biểu diễn theo một hình xoắn ốc thay vì một
chuỗi tuần tự những hành động với cơ chế truy vết
ngược
Mỗi vòng lặp trong sơ đồ xoắn ốc biểu diễn một pha của
quy trình
Không có những pha cố định như đặc tả hay thiết kế -
những vòng lặp trong sơ đồ xoắn ốc được chọn dựa vào
điều gì được yêu cầu
Rủi ro được đánh giá và giải quyết trong suốt quy trình
Những Hoạt động của Mô hình xoắn ốc
(Spiral model sectors)
105
Thiết lập mục tiêu (objective setting)
Các mục tiêu cụ thể của từng pha được xác định
Đánh giá và giảm thiểu rủi ro
Rủi ro được đánh giá và những hành động được đưa ra để
giảm thiểu những rủi ro chính
Phát triển và đánh giá
Một mô hình phát triển cho hệ thống được chọn
Lập kế hoạch
Dự án được đánh giá và giai đoạn tiếp theo của vòng xoắn
được lên kế hoạch
Mô hình Xoắn ốc
(Boehm – IEEE 1988)
106
Phát triển Phần mềm Linh hoạt
(Agile Development)
107
SCRUM (1/2)
SCRUM (2/2)
Nhắc lại:
Những Hoạt động chung trong Quy trình PM
110
Đặc tả phần mềm (software specification)
Thiết kế và cài đặt phần mềm (software design and
implementation)
Xác thực phần mềm (software validation)
Tiến hóa phần mềm (software evolution)
Đặc tả Phần mềm
(Software specification)
111
Quá trình thiết lập những dịch vụ gì được yêu cầu và
những rằng buộc với thao tác và phát triển hệ thống
Quy trình kỹ thuật tạo yêu cầu (requirements
engineering process)
Nghiên cứu khả thi (feasibility study)
Đưa ra và Phân tích yêu cầu (requirements elicitation &
analysis)
Đặc tả yêu cầu (requirements specification)
Xác thực yêu cầu (requirements validation)
Yêu cầu kỹ thuật
(Requirements engineering process)
112
Thiết kế và Cài đặt Phần mềm
(Software design and implementation)
113
Là quá trình của việc chuyển những đặc tả hệ thống thành
một hệ thống có thể chạy được
Thiết kế phần mềm
Thiết kế một cấu trúc phần mềm phù hợp với đặc tả
Cài đặt phần mềm
Chuyển cấu trúc này thành một chương trình có thể chạy
được
Những hoạt động thiết kế và cài đặt có liên hệ gần gũi
với nhau và có thể đan xen
Những Hoạt động trong Quá trình Thiết kế
(Design process activities)
114
Thiết kế kiến trúc (architectural design)
Đặc tả trừu tượng (abstract specification)
Thiết kế giao diện (interface design)
Thiết kế thành phần (component design)
Thiết kế cấu trúc dữ liệu (data structure design)
Thiết kế thuật toán (algorithm design)
Quá trình Thiết kế Phần mềm
(Software design process)
115
Những Phương pháp có cấu trúc
(Structured methods)
116
Là những cách tiếp cận có hệ thống để phát triển một
thiết kế phần mềm
Thiết kế thường được tài liệu hóa như một tập các mô
hình đồ họa
Các mô hình có thể là:
Mô hình đối tượng (object model)
Mô hình trình tự (sequence model)
Mô hình chuyển trạng thái (state transition model)
Mô hình cấu trúc (structural model)
Mô hình luồng dữ liệu (data-flow model)
Lập trình và Gỡ rối
(Programing and Debugging)
117
Là quá trình chuyển từ thiết kế thành chương trình và
loại bỏ lỗi (errors) từ chương trình đó
Lập trình là một hoạt động cá nhân – không có tiến trình
lập trình chung
Lập trình viên thực hiện một vài kiểm thử chương trình
để phát hiện lỗi (faults) trong chương trình và loại bỏ
những lỗi này trong quá trình gỡ rối (debugging)
Quá trình Gỡ rối
(Debugging process)
118
Xác thực Phần mềm
(Software validation)
119
Xác minh và xác thực (verification & validation – V & V)
được dự định để chỉ ra rằng một hệ thống phù hợp với
đặc tả của nó và tuân theo những yêu cầu của khách hàng
Liên quan đến việc kiểm tra và xem xét lại những quá
trình và kiểm thử hệ thống
Kiểm thử hệ thống liên quan đến chạy hệ thống với
những trường hợp thử nghiệm (test cases), được bắt
nguồn từ đặc tả của dữ liệu thật được xử lý bởi hệ thống
Quy trình Kiểm thử
(Testing process)
120
Những Giai đoạn Kiểm thử
(Testing stages)
121
Kiểm thử thành phần hay kiểm thử đơn vị (Component
or unit testing)
Những thành phần cá nhân được kiểm thử độc lập
Thành phần có thể là những hàm hoặc những đối tượng hoặc
những nhóm kết hợp (coherent groups) của những thực thể
này
Kiểm thử hệ thống (System testing)
Kiểm thử cả hệ thống như một toàn thể. Kiểm thử những đặc
tính khẩn cấp (emergent properties) là cực kỳ quan trọng
Kiểm thử chấp nhận (Acceptance testing)
Kiểm thử với dữ liệu khách hàng để kiểm tra xem hệ thống có
tuân theo những nhu cầu của khách hàng không
Các pha Kiểm thử
(Testing phases)
122
Giới thiệu về
Mô hình RUP và công cụ CASE
123
RUP (1/2)
(Rational Unified Process)
124
Một mô hình quy trình hiện đại xuất phát từ công việc
trên UML và quá trình liên quan
Thông thường RUP được miêu tả với 3 khía cạnh
(perspectives)
1. Khía cạnh động (dynamic perspective): hiển thị những giai
đoạn theo thời gian
2. Khía cạnh tĩnh (static perspective): hiển thị những hành động
của quy trình
3. Khía cạnh thực hành (pratice perspective): gợi ý thực hành
tốt
RUP (2/2)
125
Mô hình giai đoạn của RUP
126
Cái giai đoạn của RUP
127
Khởi đầu (Inception)
Thiết lập các trường hợp nghiệp vụ (business case) cho hệ
thống
Nghiên cứu (Elaboration)
Phát triển hiểu biết về miền vấn đề (problem domain) và kiến
trúc hệ thống
Xây dựng (Construction)
Thiết kế hệ thống, lập trình và kiểm thử
Chuyển đổi (Transition)
Triển khai (deploy) hệ thống trong môi trường vận hành của
nó
Thực hành với mô hình RUP
(RUP good practice)
128
Phát triển phần mềm lặp nhiều lần
Quản lý yêu cầu
Sử dụng kiến trúc dựa trên thành phần
Trực quan hóa mô hình phần mềm
Xác thực chất lượng phần mềm
Kiểm soát sự thay đổi với phần mềm
Quy trình công việc tĩnh (1/2)
(Static workflows)
129
Luồng công việc Miêu tả
Mô hình hóa nghiệp vụ
(Business modelling)
Quy trình nghiệp vụ được mô hình hóa sử dụng các trường hợp
nghiệp vụ (business use cases)
Yêu cầu (requirements) Các tác nhân tương tác với hệ thống được xác định và các trường
hợp (use cases) được phát triển để mô hình hóa yêu cầu hệ thống
Phân tích và thiết kế
(Analysis and design)
Một mô hình thiết kế được tạo ra và tài liệu hóa sử dụng những mô
hình kiến trúc, mô hình thành phần, mô hình đối tượng và mô hình
tuần tự (sequence models)
Cài đặt (Implementation) Những thành phần trong hệ thống được cài đặt và cấu trúc vào
những hệ thống con. Quá trình sinh mã tự động từ những mô hình
thiết kế giúp đẩy nhanh quá trình này
Kiểm thử (Testing) Kiểm thử là một quá trình lặp lại, được tiến hành kết hợp với quá
trình cài đặt. Kiểm thử hệ thống theo thực hiện sau khi hoàn thành
việc cài đặt
Triển khai (Deployment) Một bản phát hành của sản phẩm được tạo ra, phân phối tới người
dùng và cài đặt vào nơi làm việc của họ
Quy trình công việc tĩnh (2/2)
(Static workflows)
130
Luồng công việc Miêu tả
Quản lý cấu hình và sự
thay đổi (Configuration
and change management)
Luồng công việc phụ trợ này quản lý những thay đổi của hệ thống
Quản lý dự án (Project
management)
Luồng công việc phụ trợ này quản lý phát triển hệ thống
Môi trường (Environment) Luồng công việc này liên quan đến việc tạo những công cụ phần
mềm thích hợp sẵn sàng cho nhóm phát triển sử dụng
CASE là gì? (1/2)
(Computer-Aided Software Engineering)
131
CASE là những hệ thống phần mềm hỗ trợ cho quá trình
phát triển và tiến hóa phần mềm
Tự động hóa hoạt động (activity automation)
Trình soạn thảo bằng đồ họa (graphical editors) cho quá trình
phát triển mô hình hệ thống
Từ điển dữ liệu (data dictionary) để quản lý những thực thể
trong thiết kế (design entities)
Trình tạo giao diện đồ họa (graphical UI builder) cho việc xây
dựng giao diện người dùng
Trình gỡ rối (debuggers) để hỗ trợ việc tìm lỗi chương trình
(program fault)
Trình dịch tự động (automated translators) để tạo những phiên
bản mới cho chương trình
CASE là gì? (2/2)
(Computer-Aided Software Engineering)
132
CASE thường được dùng cho hỗ trợ phương pháp
Upper-CASE:
Những công cụ hỗ trợ những hành động tiến trình ở giai đoạn
đầu: xác định yêu cầu (requirements) và thiết kế (design)
Lower-CASE:
Những công cụ hỗ trợ những hành động ở giai đoạn sau như:
lập trình (programming), debugging và testing
Công nghệ CASE
133
Công nghệ CASE dẫn tới những cải tiến đáng kể trong
tiến trình phần mềm. Tuy nhiên đây không phải là những
cải tiến lớn như đã từng được dự đoán
Công nghệ phần mềm đòi hỏi phải có tư duy sáng tạo – điều
này không dễ dàng có thể được tự động hóa
Công nghệ phần mềm là một hoạt động nhóm và với những dự
án lớn, phải sử dụng nhiều thời gian trong việc tương tác nhóm.
Công nghệ CASE không thực sự hỗ trợ điều này
Phân loại CASE
(CASE classification)
134
Sự phân loại giúp chúng ta hiểu những kiểu khác nhau của
công cụ CASE và những hỗ trợ của chúng cho hoạt động
tiến trình
Khía cạnh chức năng (functional perspective)
Phân loại dựa theo chức năng cụ thể của chúng
Khía cạnh quy trình (process perspective)
Phân loại dựa theo những hoạt động quy trình được hỗ trợ
Khía cạnh tích hợp (integration perspective)
Phân loại dựa theo tổ chức của chúng trong những đơn vị
được tích hợp
Phân loại công cụ chức năng (1/2)
(Functional tool classification)
135
Kiểu công cụ Ví dụ
Công cụ lập kế hoạch Công cụ PERT, công cụ ước lượng, bảng tính (spreadsheet)
Công cụ soạn thảo Trình soạn thảo văn bản, biểu đồ, bộ xử lý từ ngữ
Công cụ quản lý sự
thay đổi
Công cụ truy xuất yêu cầu, hệ thống kiểm soát sự thay đổi
Công cụ quản lý cấu
hình
Hệ thống quản lý phiên bản, công cụ xây dựng hệ thống
Công cụ tạo nguyên
mẫu
Ngôn ngữ ở mức rất cao, bộ tạo giao diện người dùng
Ngôn ngữ hỗ trợ
phương thức
Trình thiết kế, từ điển dữ liệu, bộ sinh mã
Công cụ xử lý ngôn
ngữ
Trình biên dịch (compilers), trình thông dịch (interpreters)
Công cụ phân tích
chương trình
Bộ tạo tham chiếu chéo, trình phân tích tĩnh, trình phân tích
động
Phân loại công cụ chức năng (2/2)
(Functional tool classification)
136
Kiểu công cụ Ví dụ
Công cụ kiểm thử Bộ tạo dữ liệu kiểm thử, trình so sánh tệp tin
Công cụ gỡ rối Hệ thống gỡ rối tương tác
Công cụ tài liệu hóa Chương trình bố trí trang, trình xử lý hình ảnh
Công cụ tái kỹ thuật Hệ thống tham chiếu chéo, hệ thống tái cấu trúc chương
trình
Phân loại công cụ dựa trên hành động
(Activity-based tool classification)
137
Tích hợp CASE
(CASE integration)
138
Công cụ
Hỗ trợ những tác vụ quy trình cá nhân như kiểm tra tính nhất
quán của thiết kế, soạn thảo văn bản,
Workbench
Hỗ trợ một giai đoạn quy trình như đặc tả, thiết kế. Thường
bao gồm một số lượng công cụ được tích hợp
Môi trường
Hỗ trợ tất cả hoặc phần lớn của toàn bộ quy trình phần mềm.
Thường bao gồm nhiều workbench được tích hợp
Công cụ, Workbench, Môi trường
139
Tóm tắt Quy trình Phần mềm (1/2)
(Key points)
140
Quy trình phần mềm là những hoạt động liên quan đến
việc tạo ra và tiến hóa một hệ thống phần mềm
Mô hình quy trình phần mềm là những biểu diễn trừu
tượng của những quy trình này
Những hoạt động chung là: đặc tả, thiết kế và cài đặt,
xác thực và tiến hóa
Những mô hình quy trình chung miêu tả tổ chức của
những quy trình phần mềm. Ví dụ: mô hình thác nước,
mô hình phát triển tiến hóa và mô hình kỹ thuật
phần mềm dựa trên thành phần
Những mô hình quy trình lặp miêu tả tiến trình phần
mềm như một vòng tròn của những hành động
Tóm tắt Quy trình Phần mềm (2/2)
(Key points)
141
Kỹ thuật tạo yêu cầu là một quá trình của việc phát triển đặc
tả phần mềm
Quá trình thiết kế và cài đặt chuyển đổi đặc tả thành một
chương trình có thể chạy được
Xác thực (validation) liên quan đến đảm bảo rằng hệ thống
đáp ứng đặc tả của nó và yêu cầu người dùng
Tiến hóa liên quan đến thay đổi hệ thống sau khi nó đã đi vào
hoạt động
RUP là một mô hình quy trình chung để phân chia các hành
động theo các giai đoạn
Công cụ CASE là những hệ thống phần mềm được thiết kế để
hỗ trợ những hoạt động thông thường trong quy trình phần
mềm như: soạn thảo sơ đồ thiết kế, kiểm tra tính nhất quán của
sơ đồ, lưu vết những thử nghiệm chương trình được chạy
Tài liệu Tham khảo
142
Giáo trình chính: Software Engineering, Ian
Sommerville, 8th Edition, 2007
Tham khảo:
Object-Oriented Software Engineering Practical Software
Development using UML and Java, Lloseng.com,
Lethbridge/Laganièr,2001
Bài giảng & Tài liệu của môn Nhập Môn Công Nghệ Phần Mềm,
PhạmThị Quỳnh
Các file đính kèm theo tài liệu này:
- bai_1_ph_n_m_m_va_cong_ngh_ph_n_m_m_0391_2017023.pdf