bài giảng nhập môn công nghệ phần mềm - phan phương lan

Các giai đoạn phát triển phần mềm Định nghĩa & Phân tích yêu cầu Thiết kế Cài đặt Kiểm thử Bảo trì Phát hành Các giai đoạn phát triển phần mềm z Định nghĩa & Phân tích yêu cầu: thu thập

Trang 1

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

GIỚI THIỆU

Phan Phương Lan

Nội dung

z Phần I: Tổng quan về Công nghệ phần mềm

Trang 2

Tài liệu tham khảo

z Sách tham khảo chính:

z Shari Lawrence Pleeger, Joanne M.Atlee, Software

Engineering theory and practice, 3th edition, 2006

z Ian Sommerville, Software Engineering, 8th edition, 2006

z Sách đọc thêm:

z Hans Van Vliet, Software Engineering principles and

practice, John Wiley, 2000.

z Pressman, Roger S., Software Engineering: A Practitioner’s Approach, McGraw-Hill, 5th edition, 2003.

Trang 3

CHƯƠNG 1 – GIỚI THIỆU VỀ

CÔNG NGHỆ PHẦN MỀM

Nội dung

z Các giai đoạn trong phát triển phần mềm

z Những người tham gia trong dự án phát triển

phần mềm

z Các yếu tố chính làm thay đổi sự phát triển phần mềm

Trang 4

(2) Nghiên cứu các phương pháp tiếp cận được dùng trong (1)

công nghệ đúng đắn để thu được phần mềm một cách kinh tế nhất và chạy hiệu quả trên các máy thật

z Đúng kế hoạch thời gian

z Trong phạm vi ngân sách dự kiến

Trang 5

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

Định nghĩa & Phân tích yêu cầu

Thiết kế

Cài đặt

Kiểm thử

Bảo trì Phát hành

z Định nghĩa & Phân tích yêu cầu: thu thập mô tả

đầy đủ của bài toán

z Chức năng/tính năng của PM

z Khả năng mở rộng

z Các loại tài liệu đòi hỏi

z Thời gian đáp ứng hoặc các yêu cầu về chất lượng của

hệ thống

z Nghiên cứu khả thi

z Thiết kế: thiết kế hệ thống và thiết kế chi tiết

Trang 6

z Cài đặt: tập trung vào từng module riêng lẻ:

z Chuyển tiếp giữa các giai đoạn

z Bảo trì

z Sửa lỗi sau khi phần mềm đã được triển khai

z Đáp ứng sự thay đổi yêu cầu, sự thay đổi về môi trường, v.v

Trang 7

z Công sức của từng giai đoạn: 40 – 20 – 40

z Công sức của từng giai đoạn – Giai đoạn bảo trì

z Hoạt động bảo trì chiếm khoảng 50 – 70% toàn bộ

Trang 8

z Các thành viên trong đội phát triển phần mềm :

z Nhà phân tích yêu cầu: làm việc với khách hàng để xác định và

tư liệu hóa các yêu câu

z Nhà thiết kế: tạo ra bản mô tả mức hệ thống về cái mà hệ thống

phải thực hiện

z Lập trình viên: viết mã lệnh cài đặt sự thiết kế

z Nhà kiểm thử: bắt các lỗi

z Người hướng dẫn: chỉ dẫn người dùng cách sử dụng hệ thống

z Bảo trì viên: chỉnh sửa các lỗi khi hệ thống đã được phát hành và

đáp ứng các thay đổi

Trang 10

z Mô hình phát triển ứng dụng nhanh

z Mô hình gia tăng

Trang 11

Tiến trình (Process)

z Tiến trình: một chuỗi các bước bao gồm các hoạt

động, các ràng buộc và các tài nguyên mà chúng tạo ra kết quả được mong đợi

z Tiến trình: bao gồm một bộ các công cụ và các

kỹ thuật

Tiến trình

z Các đặc trưng của tiến trình

z Quy định tất cả các hoạt động chính của tiến trình

z Sử dụng các nguồn tài nguyên, phụ thuộc vào tập các ràng buộc (chẳng hạn như kế hoạch làm việc)

z Tạo ra các sản phẩm cuối cùng hoặc trung gian

z Có thể được tạo thành từ các tiến trình con

bằng hệ thống phân cấp hay các liên kết

Trang 12

Tiến trình

z Các đặc trưng của tiến trình

z Mỗi hoạt động của tiến trình có tiêu chuẩn vào

và ra

z Các hoạt động được tổ chức theo trình tự vì thế

sự tính toán về thời gian là rõ ràng

z Mỗi tiến trình có các nguyên tắc hướng dẫn, bao gồm các mục tiêu của từng hoạt động

z Các ràng buộc có thể áp dụng vào một hoạt

động, tài nguyên hay sản phẩm

Tiến trình

z Tầm quan trọng của tiến trình

z Áp đặt cấu trúc và tính bền vững lên một tập các hoạt động

z Hướng dẫn ta hiểu, điều khiển, kiểm tra và cải thiện các hoạt động

z Cho phép ta có được các kinh nghiệm

Trang 13

z Cụ thể hóa một tiến trình chung cho một hoàn cảnh

Trang 14

z Mô hình phát triển ứng dụng nhanh

z Mô hình gia tăng

Trang 15

Mô hình thác nước

Phân tích yêu cầu

Thiết kế chi tiết Thiết kế hệ thống

Lập trình

Kiểm thử đơn vị & tích hợp Kiểm thử hệ thống Kiểm thử chấp nhận Vận hành & bảo trì

z Không có sự lặp lại trong mô hình thác nước

z Thực tế, các dự án ít khi tuân theo dòng tuần tự của mô

hình, mà thường có lặp lại

Trang 16

z Hạn chế của mô hình thác nước

z Không có các hướng dẫn về cách thức xử lý những thay đổi về sản phẩm và hoạt động trong suốt sự phát triển

z Xem sự phát triển phần mềm như một tiến trình sản xuất hơn là tiến trình sáng tạo

z Không có các hoạt động lặp để tạo ra sản phẩm

cuối

z Phải chờ đợi lâu trước khi có sản phẩm cuối

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

z Một sự biến đổi của mô hình thác nước

z Sử dụng kiểm thử đơn vị để xác minh (verify) thiết kế chi tiết

z Sử dụng kiểm thử tích hợp để xác minh thiết kế hệ thống

z Sử dụng kiểm thử chấp nhận để thẩm định (validate) các yêu cầu

z Nếu các vấn đề được tìm thấy trong suốt sự xác minh và

Trang 18

Mô hình bản mẫu

Mô hình phát triển ứng dụng nhanh

(Rapid Application Development: RAD)

z Là tiến trình phát triển phần mềm gia tăng

z Thời gian phát triển phần mềm rất ngắn

Trang 19

Business Modeling

Data Modeling

Process Modeling

Application Generation

Business Modeling

Data Modeling

Process Modeling

Business Modeling

Data Modeling

Process Modeling

Testing & Turnover

Team #3

Mô hình phát triển ứng dụng nhanh

z Cần nguồn nhân lực dồi dào để tạo các nhóm cho các chức năng chính

z Yêu cầu hai bên cam kết trong thời gian ngắn phải có phần mềm hoàn chỉnh, thiếu trách nhiệm của một bên

dễ làm dự án đổ vỡ

z RAD không phải tốt cho mọi ứng dụng, nhất là với ứng dụng không thể module hóa hoặc đòi hỏi tính năng cao

z RAD không phù hợp khi các rủi ro kỹ thuật cao

Trang 20

z Lặp lại quy trình để hoàn thiện dần

Mô hình gia tăng

Phát hành lần 1

Phát hành lần 2

…

Trang 21

Mô hình xoắn ốc (Spiral Model)

z Được đề nghị bởi Boehm (1988)

z Kết hợp các hoạt động phát triển với sự quản lý rủi ro đểgiảm đến mức tối thiểu và kiểm soát các rủi ro

z Thích hợp với các hệ lớn

z Mô hình được trình bày ở dạng xoắn ốc trong đó mỗi lần lặp được biểu diễn bởi một đường vòng gồm bốn hoạt động chính

z Xác định các mục tiêu, các lựa chọn và các ràng buộc

z Đánh giá các lựa chọn và các rủi ro

z Phát triển và kiểm thử

Mô hình xoắn ốc

Trang 22

RUP – Rational Unified Process

z Bổ sung cho UML

z Cách tiếp cận lặp cho các hệ thống hướng đối tượng, bao gồm các use case để mô hình hóa các yêu cầu

z Các giai đoạn của RUP

z Inception: thiết lập phạm vi, giới hạn, các use case quan trọng, các

kiến trúc ứng viên, các dự đoán về chi phí và kế hoạch làm việc

z Elaboration: đạt được kiến trúc hoàn chỉnh, thiết lập sự hỗ trợ công

cụ, có tất cả các use case, giải quyết tất cả các rủi ro chính

z Construction: xây dựng tiến trình, một hay nhiều sự phát hành

z Transition: phát hành ra cộng đồng người dùng, thường là một số

phát hành

RUP

Trang 23

Trang 24

z Nhân sự lμ thμnh phần quan trọng nhất của tổ chức

z Việc quản lý nhân sự kém sẽ dẫn đến sự thất bại của

Trang 25

Chọn nhân sự

z Một công việc quản lý dự án quan trọng lμ chọn nhóm lμm việc

z Các thông tin cần cho sự lựa chọn nhân sự gồm:

z Thông tin được cung cấp bởi ứng viên

z Thông tin do phỏng vấn vμ nói chuyện với ứng viên

z Thông tin từ thư tiến cử hay sự giới thiệu của những người biết hay những người lμm việc với ứng viên

Chọn nhân sự

z Một số lưu ý trong việc chọn nhân sự

z Các nhμ quản lý trong công ty không muốn mất người cho các dự án mới Vì vậy, ta phải chấp nhận những người chỉ có thể lμm việc bán thời gian trong dự án

z Các kỹ năng cần thiết cho dự án lμ khan hiếm =>

không có được nhiều ứng viên để chọn

z Những sinh viên mới ra trường không có nhiều kinh nghiệm cụ thể nhưng họ thường nhiệt tình vμ dễ học công nghệ mới

z Sự thμnh thạo về kỹ thuật có thể ít quan trọng hơn các

kỹ năng xã hội

Trang 26

z Một vai trò quan trọng của nhμ quản lý lμ thúc

đẩy nhân sự lμm việc trong dự án

z Động cơ thúc đẩy lμ một vấn đề phức tạp

z Các loại động cơ thúc đẩy được dựa trên:

z Các nhu cầu cơ bản (lương thực, thời gian ngủ, v.v);

z Các nhu cầu cá nhân (sự tôn trọng, lòng tự trọng, v.v);

z Các nhu cầu xã hội (được chấp nhận lμ một thμnh viên

Trang 27

z Cung cÊp c¸c ph−¬ng tiÖn giao tiÕp

z Cho phÐp c¸c giao tiÕp kh«ng h×nh thøc

Trang 29

z Con người lμm việc vì họ được thúc đẩy bởi những

người mμ họ lμm cùng

Quản lý nhúm

z Hầu hết hoạt động phần mềm lμ hoạt động nhóm vì một dự án phần mềm không thể hoμn thμnh bởi duy nhất một người

z Sự tương tác nhóm lμ yếu tố quyết định then chốt

sự thực hiện của nhóm

z Tính linh động trong kết cấu nhóm bị hạn chế do các nhμ quản lý phải lμm cái tốt nhất mμ họ có thể với nhân sự hiện có

Trang 30

z Hướng công việc – mỗi người muốn lμm công việc của chính họ

z Hướng bản thân – mỗi người đều muốn lãnh

đạo

Trang 31

z Trách nhiệm của lãnh đạo nhóm lμ:

Cung cấp các chỉ dẫn kỹ thuật vμ các quản lý dự án

Phải nắm được công việc hμng ngμy của nhóm để

đảm bảo mọi người lμm việc hiệu quả vμ lμm việc với nhμ quản lý dự án theo kế hoạch của dự án

z Trong một nhóm, có thể có cả 1 lãnh đạo kỹ thuật vμ 1 lãnh đạo quản lý

z Sự lãnh đạo nhóm dựa trên sự tôn trọng, sự lãnh đạo

Quản lý nhúm

Trang 32

Sự gắn kết nhúm

z Trong một nhóm gắn kết, các thμnh viên xem

nhóm lμ quan trọng hơn bất cứ cá nhân nμo trong nhóm

z Thuận lợi của nhóm gắn kết:

z Chuẩn về chất l−ợng nhóm đ−ợc phát triển

z Các thμnh viên trong nhóm lμm việc cùng với nhau vìthế các hạn chế về sự không hiểu biết giảm

z Các thμnh viên trong nhóm học lẫn nhau vμ biết đ−ợc công việc của nhau

z Phát triển một tên riêng vμ một lĩnh vực của nhóm

z Thực hiện các hoạt động xây dựng nhóm

Trang 33

z Những vấn đề có thể xảy ra trong các nhóm gắn kết:

z Chống lại người lãnh đạo mới được chỉ định từ bên ngoμi nhóm

z Giải quyết: chọn lãnh đạo mới lμ người trong nhóm

z Suy nghĩ nhóm => các khả năng phê bình bị xói mòn

z Giải quyết: tổ chức các buổi họp chính thức vμ mời chuyên gia từ bên ngoμi phê bình các quyết

z Các giao tiếp tốt còn lμm gia tăng tính gắn kết nhóm vì nó thúc đẩy sự hiểu biết

Trang 34

z M«i tr−êng lμm viÖc tù nhiªn

z ViÖc tæ chøc n¬i lμm viÖc tèt cã thÓ khuyÕn khÝch sù giao tiÕp

Trang 35

z Các nhóm bộ phận có chuyên môn sâu

z Tham gia bán thời gian vào các dự án khác nhau

z Người quản lí dự án chịu trách nhiệm cho sự thành công toàn bộ dự án và nâng cao kiến thức chuyên môn của nhóm

Trang 36

Tổ chức nhóm

z Nhóm lập trình viên chính

z Hạt nhân của mỗi nhóm gồm 3 người:

z Trưởng nhóm: thiết kế và cài đặt phần chính của hệ thống

z Trợ lý: giúp việc cho trưởng nhóm

z Người quản lí tài liệu

z Cần có một trưởng nhóm giỏi kỹ thuật và năng lực quản lí tốt

z Lưu ý: công việc không có cấu trúc, không có người phân tích, người thiết kế, lập trình viên…

Tổ chức nhóm

z Nhóm nhỏ: 4-5 người

z Thường áp dụng trong tiến trình theo mô hình gia tăng

z Dùng ngôn ngữ cấp cao, các gói dùng lại, các phần mềm sinh mã

z Nhóm trưởng là người giỏi

Trang 38

và thủ tục này được tuân theo

z Hướng tới phát triển một ‘văn hóa chất lượng’ nơi chất lượng được xem là trách nhiệm của mọi người

Quản lý chất lượng phần mềm

z Phạm vi của quản lý chất lượng

z Quản lý chất lượng là đặc biệt quan trọng đối với các

hệ thống phức tạp và lớn Tài liệu chất lượng là hồ sơ

về tiến trình và hỗ trợ tính liên tục phát triển khi nhóm phát triển thay đổi

z Đối với các hệ thống nhỏ hơn, quản lý chất lượng cần

ít tài liệu hơn và nên tập trung vào việc củng cố văn hóa chất lượng

Trang 39

z Kiểm soát chất lượng

z Đảm bảo rằng nhóm phát triển phần mềm tuân theo các thủ tục và chuẩn

z Quản lý chất lượng nên tách biệt khỏi quản lý dự án để đảm bảo sự độc lập

Trang 40

z Chất lượng của sản phẩm và quy trình

z Trong phát triển phần mềm, mối quan hệ giữa chất lượng sản phẩm và chất lượng quy trình là phức tạp vì

z Việc áp dụng các kinh nghiệm và các kỹ năng cá nhân là đặc biệt quan trọng trong phát triển phần mềm

z Các yếu tố bên ngoài như tính mới lạ của ứng dụng hay

kế hoạch phát triển gấp có thể làm suy giảm chất lượng sản phẩm

z Một số thuộc tính chất lượng phần mềm khó đo lường

=> khó đánh giá được cách mà các đặc điểm của quy trình tác động đến các thuộc tính đó

z Quản lý chất lượng quy trình liên quan tới:

z Định nghĩa các chuẩn quy trình như khi nào và bằng cách nào các xem lại (review) được quản lý, quản lý cấu hình, v.v

z Giám sát quy trình phát triển để đảm bảo các chuẩn được tuân theo

z Báo cáo quy trình phần mềm với quản lý dự án và

Trang 41

Đảm bảo chất lượng và các chuẩn

z Các chuẩn

z Là chìa khóa của sự quản lý chất lượng hiệu quả

z Có thể là các chuẩn của tổ chức, của quốc gia hay của quốc tế

Trang 42

z Các chuẩn quy trình và sản phẩm

z Tầm quan trọng của các chuẩn

Trang 43

z Các vấn đề về chuẩn

z Chúng có thể được xem là không liên quan

và không được cập nhật bởi các kỹ sư phần mềm

z Chúng thường đòi hỏi quá nhiều thực hiện rườm rà và có thể buồn tẻ

z Để tránh các vấn đề về chuẩn, nhà quản lý chất lượng nên thực hiện:

z Mời các kỹ sư phần mềm tham gia vào việc chọn các chuẩn sản phẩm

z Xem lại và hiệu chỉnh các chuẩn để phản ánh các công nghệ đang thay đổi

z Cung cấp các công cụ phần mềm để hỗ trợ các chuẩn nếu có thể

Trang 44

z ISO 9000

z Một tập chuẩn quốc tế cho quản lý chất lượng

z Phù hợp với nhiều tổ chức từ công nghiệp sản xuất tới kinh doanh dịch vụ

z ISO 9000 và quản lý chất lượng

Trang 45

mà công ty nên định nghĩa

z ISO 9001 bao phủ các phạm vi sau

Trang 46

z Các chuẩn tư liệu

z Đặc biệt quan trọng vì tài liệu là cách hữu hình duy nhất để biểu diễn phần mềm và quy trình phần mềm

z Ba loại chuẩn tư liệu

z Chuẩn quy trình tư liệu: liên quan tới cách các tài liệu nên được phát triển, thẩm định và duy trì

z Chuẩn tài liệu: chi phối nội dung, cấu trúc và sự trình bày của các tài liệu

z Chuẩn trao đổi tài liệu: đảm bảo rằng tất cả các bản sao điện tử của các tài liệu là tương thích

z Một mô hình về quy trình tư liệu

Trang 47

z Chuẩn tài liệu

z Các chuẩn nhận dạng tài liệu: cách các tài liệu được nhận biết là duy nhất

z Các chuẩn cấu trúc tài liệu: cấu trúc chuẩn cho các tài liệu của dự án

z Các chuẩn trình bày tài liệu: định nghĩa các font chữ, kiểu chữ, sử dụng các logo, v.v

z Chuẩn cập nhật tài liệu: định nghĩa cách các thay đổi

so các phiên bản trước được phản ánh trong tài liệu

z Chuẩn trao đổi tài liệu

z Các chuẩn trao đổi cho phép các tài liệu điện tử được nhận, được gửi, v.v

z Các tài liệu được tạo ra bằng cách sử dụng các hệ

thống khác nhau và trên các máy tính khác nhau Thậm chí khi các công cụ chuẩn được sử dụng, các chuẩn được cần đến để định nghĩa các quy tắc sử dụng chúng

Trang 48

Lập kế hoạch chất lượng

z Kế hoạch chất lượng trình bày các chất lượng sản phẩm được mong đợi và mô tả cách mà chúng được đánh giá cũng như định nghĩa các thuộc tính chất

z Rủi ro và quản lý rủi ro

z Kế hoạch chất lượng nên là tài liệu ngắn gọn và

Trang 49

Lập kế hoạch chất lượng

z Các thuộc tính chất lượng phần mềm

Kiểm soát chất lượng

z Kiểm soát chất lượng đòi hỏi việc giám sát quy trình phát triển phần mềm để đảm bảo các thủ tục

và các chuẩn đang được tuân theo

z Hai cách tiếp cận kiểm soát quy trình