Công nghệ phần mềm chương 3

Bài giảng 3 - Phát triển phần mềm Agile Phần 1 Chủ đề được bảo vệ Phương pháp Linh hoạt Phát triển theo định hướng và linh hoạt Lập trình cực đoan Quản lý dự án Linh hoạt Nhân rộn

Bài giảng 3 - Phát triển phần mềm Agile

Phần 1

Chủ đề được bảo vệ

Phương pháp Linh hoạt

Phát triển theo định hướng và linh hoạt

Lập trình cực đoan

Quản lý dự án Linh hoạt

Nhân rộng các phương pháp nhanh

Phát triển phần mềm nhanh

Phát triển và phân phối nhanh bây giờ là yêu cầu quan trọng nhất cho các hệ thống phần mềm

Doanh nghiệp hoạt động một cách nhanh chóng - thay đổi yêu cầu và đó là thực tế không thể tạo ra một tập hợp các yêu cầu phần mềm ổn định

Phần mềm phải nhanh chóng phát triển để phản ánh nhu cầu kinh doanh đang thay đổi

Phát triển phần mềm nhanh

Đặc điểm kỹ thuật, thiết kế và thực hiện là giữa các lá

Hệ thống được phát triển như một loạt các phiên bản với các bên liên quan tham gia vào việc đánh giá phiên bản

Giao diện người dùng thường được phát triển bằng cách sử dụng một IDE

và bộ công cụ đồ họa

Phương pháp Linh hoạt

Không hài lòng với các chi phí liên quan đến phương pháp thiết kế phần mềm của những năm 1980 và 1990 dẫn đến việc tạo ra các phương pháp linh hoạt Những phương pháp này:

Tập trung vào các mã chứ không phải là thiết kế

Được dựa trên một phương pháp lặp đi lặp lại để phát triển phần mềm

Nhằm mục đích cung cấp phần mềm làm việc một cách nhanh chóng và

phát triển này một cách nhanh chóng để đáp ứng yêu cầu thay đổi

Mục đích của các phương pháp nhanh là giảm chi phí đầu vào trong quá

trình phần mềm (ví dụ bằng cách hạn chế tài liệu) và để có thể đáp ứng

nhanh chóng với các yêu cầu thay đổi mà không cần phải làm lại quá nhiều

Tuyên ngôn Linh hoạt

Chúng tôi đang khám phá những cách phát triển tốt hơn Phần mềm bằng

cách làm nó và giúp đỡ người khác làm điều đó Thông qua công việc này

chúng tôi đã có giá trị:

Cá nhân và tương tác với các quy trình và công cụ

Phần mềm làm việc thông qua tài liệu hướng dẫn

Sự hợp tác của khách hàng đối với đàm phán hợp đồng

Đáp ứng thay đổi theo kế hoạch

Đó là, mặc dù có giá trị trong các mục trên Bên phải, chúng tôi đánh giá

các mặt hàng bên trái nhiều hơn nữa

Các nguyên tắc của các phương pháp linh hoạt

Nguyên tắc Sự miêu tả

sự tham gia của khách hàng Khách hàng nên tham gia chặt chẽ trong quá trình phát triển

cung cấp và ưu tiên các yêu cầu hệ thống mới và để đánh giá lặp lại của hệ thống

Phân phối gia tăng Phần mềm được phát triển theo từng bước với khách hàng chỉ định các yêu cầu

để được bao gồm trong từng bước tăng

Những người không xử lý Các kỹ năng của nhóm phát triển cần được công nhận và khai thác

viên của nhóm nên được để lại để phát triển cách riêng của họ làm việc mà không có quy trình quy trình

Nắm lấy thay đổi Mong muốn các yêu cầu hệ thống thay đổi và do đó thiết kế hệ thống để thích

ứng với những thay đổi này

Duy trì sự đơn giản Tập trung vào sự đơn giản trong cả phần mềm đang được phát triển và trong

quá trình phát triển Bất cứ nơi nào có thể, tích cực làm việc để loại bỏ sự phức tạp từ hệ thống

Áp dụng phương pháp Linh hoạt

Phát triển sản phẩm, nơi một công ty phần mềm đang phát triển một sản phẩm nhỏ hoặc vừa để bán

Phát triển hệ thống tùy chỉnh trong một tổ chức, nơi có sự cam kết rõ ràng của khách hàng để tham gia vào quá trình phát triển và không có nhiều quy tắc và quy định bên ngoài ảnh hưởng đến phần mềm

Do tập trung vào các nhóm tích hợp nhỏ, có nhiều vấn đề trong việc mở rộng các phương pháp nhanh đến các hệ thống lớn

Các vấn đề với các phương pháp linh hoạt

Có thể khó giữ được sự quan tâm của khách hàng tham gia vào quá trình này

Các thành viên trong nhóm có thể không thích hợp với sự tham gia tích cực, đặc trưng cho các phương pháp linh hoạt

Ưu tiên thay đổi có thể khó khăn khi có nhiều bên liên quan

Giữ đơn giản đòi hỏi công việc thêm

Hợp đồng có thể là một vấn đề như với các phương pháp khác để phát triển lặp đi lặp lại

Phương pháp Linh hoạt và bảo trì phần mềm

Hầu hết các tổ chức chi tiêu nhiều hơn cho việc duy trì phần mềm hiện tại so với việc phát triển phần mềm mới Vì vậy, nếu phương pháp linh hoạt để thành công, họ phải hỗ trợ bảo trì cũng như sự phát triển ban đầu

Hai vấn đề chính:

Liệu các hệ thống được phát triển bằng cách sử dụng một cách tiếp cận nhanh có thể duy trì được, với sự nhấn mạnh trong quá trình phát triển để giảm thiểu các tài liệu chính thức?

Có thể sử dụng các phương pháp nhanh để phát triển một hệ thống để đáp ứng yêu cầu thay đổi của khách hàng?

Sự cố có thể xảy ra nếu nhóm phát triển ban đầu không thể duy trì

Phát triển theo định hướng và linh hoạt

Phát triển theo kế hoạch

Cách tiếp cận theo kế hoạch cho công nghệ phần mềm dựa trên các giai đoạn phát triển riêng biệt với các kết quả đầu ra sẽ được sản xuất ở từng giai đoạn này được lên kế hoạch trước

Không nhất thiết thác mô hình - kế hoạch định hướng, phát triển gia tăng có thể

Iteration xảy ra trong các hoạt động

Phát triển nhanh

Đặc điểm kỹ thuật, thiết kế, thực hiện và thử nghiệm được liên leaved và các kết quả từ quá trình phát triển được quyết định thông qua một quá trình đàm phán trong quá trình phát triển phần mềm

Kế hoạch định hướng và đặc điểm kỹ thuật linh hoạt

Các vấn đề kỹ thuật, con người, tổ chức

Hầu hết các dự án bao gồm các yếu tố của quy trình theo định hướng và linh hoạt Quyết định về sự cân bằng phụ thuộc vào:

Điều quan trọng là phải có một đặc tả kỹ thuật và thiết kế rất chi tiết trước khi triển khai? Nếu có, có lẽ bạn cần sử dụng cách tiếp cận theo kế hoạch

Là một chiến lược phân phối gia tăng, nơi bạn cung cấp phần mềm cho khách hàng và nhận phản hồi nhanh từ họ, thực tế? Nếu vậy, hãy xem xét sử dụng các phương pháp nhanh

Hệ thống đang được phát triển bao nhiêu? Các phương pháp linh hoạt hiệu quả nhất khi hệ thống có thể được phát triển với một nhóm đồng bố trí nhỏ

có thể giao tiếp không chính thức Điều này có thể không khả thi đối với các

hệ thống lớn đòi hỏi phải có đội ngũ phát triển lớn hơn để có thể sử dụng cách tiếp cận theo kế hoạch

Các vấn đề kỹ thuật, con người, tổ chức

Loại hệ thống nào đang được phát triển?

Cách tiếp cận theo kế hoạch có thể được yêu cầu cho các hệ thống đòi hỏi nhiều phân tích trước khi thực hiện (ví dụ hệ thống thời gian thực với yêu cầu về thời gian phức tạp)

Tuổi thọ hệ thống dự kiến là bao lâu?

Các hệ thống có tuổi thọ dài có thể yêu cầu nhiều tài liệu thiết kế hơn để truyền đạt ý định ban đầu của các nhà phát triển hệ thống cho nhóm hỗ trợ Công nghệ nào có sẵn để hỗ trợ phát triển hệ thống?

Các phương pháp linh hoạt dựa vào các công cụ tốt để theo dõi thiết kế phát triển

Nhóm phát triển được tổ chức như thế nào?

Nếu nhóm phát triển được phân phối hoặc nếu một phần của sự phát triển đang được thuê ngoài, sau đó bạn có thể cần phải phát triển tài liệu thiết kế

để giao tiếp qua các nhóm phát triển

Các vấn đề kỹ thuật, con người, tổ chức

Có những vấn đề văn hoá hoặc tổ chức có thể ảnh hưởng đến sự phát triển của hệ thống?

Các tổ chức kỹ thuật truyền thống có nền văn hoá phát triển theo kế hoạch,

vì đây là tiêu chuẩn trong kỹ thuật

Làm thế nào tốt là các nhà thiết kế và lập trình trong nhóm phát triển?

Đôi khi người ta cho rằng các phương pháp linh hoạt đòi hỏi trình độ kỹ năng cao hơn các phương pháp tiếp cận theo kế hoạch, trong đó các lập trình viên đơn giản chỉ dịch một thiết kế chi tiết thành mã

Hệ thống có phải tuân thủ các quy định bên ngoài không?

Nếu một hệ thống phải được chấp thuận bởi một cơ quan quản lý bên ngoài (ví dụ như FAA phê duyệt phần mềm quan trọng đối với hoạt động của một chiếc máy bay) thì có thể bạn sẽ phải xuất trình các tài liệu chi tiết như là một phần của trường hợp an toàn hệ thống

Lập trình cực đại

Có lẽ phương pháp nhanh nhất được sử dụng rộng rãi và được sử dụng rộng rãi nhất

Extreme Programming (XP) có một cách tiếp cận cực đại để phát triển lặp đi lặp lại

Các phiên bản mới có thể được xây dựng vài lần mỗi ngày;

Số lượng được phân phối cho khách hàng mỗi 2 tuần một lần;

Tất cả các thử nghiệm phải được chạy cho mỗi xây dựng và xây dựng chỉ

được chấp nhận nếu các bài kiểm tra chạy thành công

XP và nguyên tắc linh hoạt

- Sự phát triển gia tăng được hỗ trợ thông qua việc phát hành hệ thống nhỏ

và thường xuyên

- Sự tham gia của khách hàng có nghĩa là cam kết với khách hàng toàn thời

gian với nhóm

- Mọi người không qua quá trình lập trình cặp, quyền sở hữu tập thể và quy

trình tránh thời gian làm việc dài

- Hỗ trợ được thay đổi thông qua các bản phát hành hệ thống thông thường

Giữ đơn giản thông qua việc tái cấu trúc mã

Chu kỳ phát hành lập trình cực đoan

Các hoạt động lập trình cực đoan (a)

Nguyên tắc

hoặc thực hành

Sự miêu tả

Lập kế hoạch gia

tăng

Các yêu cầu được ghi trên thẻ câu chuyện và những câu chuyện được đưa vào trong bản phát hành được xác định bởi thời gian sẵn có và mức độ ưu tiên tương đối của chúng Các nhà phát triển phá vỡ những câu chuyện này vào phát triển

'Nhiệm vụ' Xem hình 3.5 và 3.6

Phiên bản nhỏ Bộ chức năng hữu ích tối thiểu cung cấp giá trị kinh doanh

được phát triển trước tiên Các bản phát hành của hệ thống thường xuyên và từng bước bổ sung chức năng cho bản phát hành đầu tiên

Thiết kế đơn

giản

Thiết kế đầy đủ được thực hiện để đáp ứng các yêu cầu hiện tại và không còn nữa

Phát triển thử

nghiệm đầu tiên

Khung kiểm tra đơn vị tự động được sử dụng để viết bài kiểm tra cho một phần chức năng mới trước khi chức năng đó được thực hiện

Tái cấu trúc lại Tất cả các nhà phát triển dự kiến sẽ cấu trúc lại mã liên tục

càng sớm càng cải tiến mã có thể được tìm thấy Điều này giữ cho mã đơn giản và duy trì

Thực tiễn lập trình cực đoan (b)

Lập trình cặp Các nhà phát triển làm việc theo cặp, kiểm tra công việc của

nhau và hỗ trợ luôn làm tốt công việc

Sở hữu tập thể Các cặp nhà phát triển làm việc trên tất cả các khu vực của hệ

thống, do đó không có hòn đảo chuyên môn phát triển và tất cả các nhà phát triển chịu trách nhiệm về tất cả các mã Bất cứ ai cũng có thể thay đổi bất cứ điều gì

Hội nhập liên tục Ngay khi công việc của một công việc hoàn thành, nó được

tích hợp vào toàn bộ hệ thống Sau khi tích hợp như vậy, tất cả các bài kiểm tra đơn vị trong hệ thống phải vượt qua

Tốc độ phát triển

bền vững

Số lượng lớn làm thêm giờ không được coi là chấp nhận được

vì hiệu quả ròng thường làm giảm chất lượng mã và năng suất trung bình

Khách hàng tại

chỗ

Một đại diện của người dùng cuối của hệ thống (khách hàng) nên có sẵn toàn thời gian cho việc sử dụng của đội XP Trong một quá trình lập trình cực đoan, khách hàng là một thành viên của nhóm phát triển và chịu trách nhiệm đưa các yêu cầu hệ thống vào đội để thực hiện

Các kịch bản yêu cầu

Trong XP, một khách hàng hoặc người sử dụng là một phần của đội XP và

có trách nhiệm đưa ra quyết định về các yêu cầu

Yêu cầu người dùng được thể hiện dưới dạng kịch bản hay những câu chuyện người dùng

Chúng được viết trên phiếu và nhóm phát triển chia chúng thành các nhiệm

vụ thực hiện Những nhiệm vụ này là cơ sở của dự toán và dự toán chi phí Khách hàng chọn các câu chuyện để đưa vào bản phát hành kế tiếp dựa trên các ưu tiên của họ và dự toán ước tính

XP và thay đổi

Sự khôn ngoan thông thường trong kỹ thuật phần mềm là để thiết kế cho sự thay đổi Cần phải tốn nhiều thời gian và công sức để dự đoán những thay đổi vì điều này làm giảm chi phí sau này trong vòng đời

XP, tuy nhiên, duy trì rằng điều này là không đáng giá như thay đổi không thể được dự đoán đáng tin cậy

Thay vào đó, nó đề xuất cải tiến mã không đổi (tái cấu trúc) để thay đổi dễ dàng hơn khi chúng được triển khai

Tái cấu trúc lại

Lập trình đội tìm kiếm các cải tiến phần mềm có thể và thực hiện những cải tiến ngay cả khi không có nhu cầu cấp thiết cho họ

Điều này cải thiện sự hiểu biết của phần mềm và do đó làm giảm nhu cầu về tài liệu

Thay đổi dễ dàng hơn vì mã được cấu trúc và rõ ràng

Tuy nhiên, một số thay đổi đòi hỏi phải có kiến trúc tái cấu trúc và điều này tốn kém hơn nhiều

Ví dụ về sắp xếp lại

Tổ chức lại một hệ thống cấp bậc để loại bỏ mã trùng lặp

Thanh toán và đổi tên các thuộc tính và phương pháp để giúp họ dễ hiểu hơn

Việc thay thế mã nội tuyến bằng các cuộc gọi đến các phương thức đã được bao gồm trong một thư viện chương trình

Những điểm chính

Các phương pháp Linh hoạt là các phương pháp phát triển gia tăng tập trung vào sự phát triển nhanh chóng, thường xuyên phát hành phần mềm, giảm chi phí quá trình và tạo ra mã chất lượng cao Họ liên quan đến khách hàng trực tiếp trong quá trình phát triển

Quyết định sử dụng cách tiếp cận nhanh hoặc theo một kế hoạch dựa trên sự phát triển cần phụ thuộc vào loại phần mềm đang được phát triển, khả năng của nhóm phát triển và văn hóa của công ty phát triển hệ thống

Lập trình cực đoan là một phương pháp linh hoạt nổi tiếng tích hợp một loạt các thực tiễn lập trình tốt như bản phát hành thường xuyên của phần mềm, cải tiến phần mềm liên tục và sự tham gia của khách hàng vào nhóm phát triển

Bài giảng 3 - Phát triển phần mềm Linh hoạt

Phần 2

Thử nghiệm trong XP

Thử nghiệm là trung tâm của XP và XP đã phát triển một cách tiếp cận mà chương trình được kiểm tra sau khi mọi thay đổi đã được thực hiện

Các tính năng thử nghiệm XP:

+ Kiểm tra phát triển - đầu tiên

+ Phát triển thử nghiệm gia tăng từ các kịch bản

+ Có sự tham gia của người dùng trong việc phát triển và kiểm tra tính hợp

lệ

+ Các ca kiểm thử tự động được sử dụng để chạy tất cả các thử nghiệm thành phần mỗi lần phát hành bản phát hành mới

Phát triển thử nghiệm đầu tiên

- Viết bài kiểm tra trước khi mã làm rõ các yêu cầu được thực hiện

- Các bài kiểm tra được viết bằng các chương trình thay vì dữ liệu để chúng

có thể được thực hiện tự động Xét nghiệm này bao gồm một tấm séc rằng

nó đã được thực hiện một cách chính xác

Thường dựa vào một khuôn khổ kiểm tra như Junit

- Tất cả các xét nghiệm trước và mới được chạy tự động khi chức năng mới được thêm vào, do đó kiểm tra xem các chức năng mới đã không giới thiệu lỗi

Sự quan tâm của khách hàng

- Vai trò của khách hàng trong quá trình kiểm tra là giúp phát triển các bài kiểm tra chấp nhận được cho những câu chuyện sẽ được thực hiện trong lần phát hành kế tiếp của hệ thống

- Khách hàng là thành viên của nhóm viết bài kiểm tra khi tiến độ phát triển Tất cả các mã mới do đó được xác nhận để đảm bảo rằng đó là những gì khách hàng cần

- Tuy nhiên, người nhận vai trò khách hàng có thời gian hạn chế nên không thể làm việc toàn thời gian với nhóm phát triển Họ có thể cảm thấy rằng việc cung cấp các yêu cầu là đủ của một đóng góp và do đó có thể không muốn tham gia vào quá trình thử nghiệm

Mô tả trường hợp thử nghiệm để kiểm tra liều lượng

Kiểm tra tự động hóa

Tự động kiểm tra có nghĩa là các bài kiểm tra được viết như các thành phần thực thi trước khi thực hiện nhiệm vụ

Các thành phần thử nghiệm này nên độc lập, nên mô phỏng việc nhập dữ liệu đầu vào để kiểm tra và nên kiểm tra xem kết quả có đáp ứng các đặc điểm đầu ra không Một khuôn khổ kiểm tra tự động (ví dụ Junit) là một hệ thống mà làm cho nó dễ dàng để viết bài kiểm tra thực thi và nộp một bộ kiểm tra để thực hiện

Khi thử nghiệm được tự động, luôn luôn có một bộ kiểm tra có thể được thực hiện nhanh chóng và dễ dàng

Bất cứ khi nào bất kỳ chức năng nào được thêm vào hệ thống, các bài kiểm tra có thể được chạy và những vấn đề mà mã mới đã được giới thiệu có thể

bị bắt ngay lập tức

Khó khăn thử nghiệm XP

Các lập trình viên thích lập trình để kiểm tra và đôi khi họ mất đoạn ngắn khi viết bài kiểm tra Ví dụ: họ có thể viết các bài kiểm tra không đầy đủ mà không kiểm tra tất cả các trường hợp ngoại lệ có thể xảy ra

Một số bài kiểm tra có thể rất khó viết từng bước Ví dụ, trong một giao diện người dùng phức tạp, nó thường rất khó để viết các unit test cho mã mà thực hiện những 'logic hiển thị và quy trình làm việc giữa các màn hình Rất khó để đánh giá tính đầy đủ của một bộ bài kiểm tra Mặc dù bạn có thể

có rất nhiều bài kiểm tra hệ thống, bộ thử nghiệm của bạn có thể không cung cấp phạm vi bảo hiểm hoàn chỉnh

Lập trình cặp

Trong XP, các lập trình viên làm việc theo cặp, ngồi với nhau

để phát triển mã

Điều này giúp phát triển quyền sở hữu chung của mã và phổ biến kiến thức trong nhóm

Nó phục vụ như là một quá trình xem xét không chính thức khi mỗi dòng mã được xem nhiều hơn 1 người