Tìm hiểu về SDLC – Software Development Life Cycle

Một trong những kiến ​​thức cần thiết đối với một kỹ sư kiểm thử phần mềm chuyên nghiệp là hiểu và nắm rõ sdlc (vòng đời phát triển phần mềm / chu kỳ phát triển phần mềm), vì kiểm thử phần mềm (kiểm thử phần mềm) là một phần và có liên quan mật thiết đến sdlc.

Vòng đời phát triển phần mềm (sdlc – Vòng đời phát triển phần mềm) là quá trình được theo sau bởi các dự án phần mềm trong một tổ chức phần mềm. Nó bao gồm các bản thiết kế mô tả cách phát triển, duy trì, thay đổi hoặc nâng cấp phần mềm cụ thể.

Quy trình là một trong những yếu tố quan trọng nhất trong sự thành công của các nhà sản xuất phần mềm, nó giúp mọi thành viên của dự án, cũ và mới, bên trong hoặc bên ngoài công ty, đồng bộ hóa công việc của họ theo cách toàn công ty, hoặc ít nhất là ở cấp độ dự án.

Trên thực tế, các công ty xây dựng và phát triển phần mềm, theo quy mô và hình thức kinh doanh riêng, có thể được điều chỉnh, hợp nhất và tổ chức theo nhu cầu thực tế của công ty. Tuy nhiên, việc tạo ra một sản phẩm phần mềm sẽ bao gồm các giai đoạn sau:

1. Giai đoạn Yêu cầu

2. Giai đoạn Đặc điểm kỹ thuật

3. Giai đoạn Thiết kế

4. Giai đoạn Lập trình

5. Bản beta

6. Giai đoạn Triển khai và Bảo trì

   

   1. Giai đoạn Yêu cầu

   Trong giai đoạn này, bộ phận phân tích yêu cầu sẽ gặp và thảo luận với khách hàng và làm rõ các tính năng và yêu cầu mà khách hàng muốn xây dựng vào phần mềm của họ. Trên thực tế, ở giai đoạn này, đơn vị phần mềm sẽ có một tập hợp các câu hỏi chung cho từng dự án cụ thể cũng như các câu hỏi dành riêng cho dự án cần thực hiện.

   Đây là giai đoạn quan trọng ảnh hưởng đến việc xây dựng và phát triển phần mềm trong tương lai gần nên đội phân tích yêu cầu thường là những người có nhiều kinh nghiệm giúp làm rõ và hiểu đúng các yêu cầu vấn đề của khách hàng trong quá trình giao tiếp với khách hàng , và thu thập các yêu cầu liên quan đến dự án. Bảng thông tin cho giai đoạn phân tích tiếp theo.

   2. Giai đoạn đặc điểm kỹ thuật

   Đây là giai đoạn sẽ được thực hiện sau khi các yêu cầu của khách hàng được lập thành văn bản và bộ phận phân tích sẽ trình bày rõ các yêu cầu và thực hiện chúng thông qua một tài liệu srs được gọi là “tài liệu đặc tả”. Tài liệu này rất quan trọng đối với quá trình phát triển phần mềm vì nó bao gồm tất cả các yêu cầu về sản phẩm được thiết kế và phát triển trong suốt vòng đời của dự án. Lập trình viên, người kiểm thử và các bộ phận khác có liên quan sẽ làm việc theo mô tả chức năng chi tiết trong tài liệu và trả lời câu hỏi “Phần mềm sẽ làm gì?”

   3. Giai đoạn thiết kế

   Ở giai đoạn này, theo tài liệu đặc tả, bộ phận thiết kế sẽ thiết kế giao diện chung, bộ phận lập trình sẽ thiết kế giao diện chi tiết theo từng chức năng của phần mềm. Các chức năng trong tài liệu mô tả được thực hiện dưới dạng giao diện chức năng phần mềm nguyên mẫu. Giao diện và bố cục sau đó được thảo luận và thống nhất với khách hàng bằng cách sử dụng khung phần mềm này. Khi khách hàng đồng ý với thiết kế phần mềm dựa trên nguyên mẫu này, giai đoạn tiếp theo sẽ đạt được. Trong trường hợp không đồng ý, các ý kiến ​​sẽ được ghi nhận và chỉnh sửa cho đến khi khách hàng đồng ý với nguyên mẫu phần mềm.

   4. Giai đoạn lập trình

   Ở giai đoạn này, sdlc bắt đầu thực sự phát triển và xây dựng sản phẩm. Giai đoạn lập trình là giai đoạn trong đó các chức năng phần mềm được thực hiện sau khi khách hàng đồng ý với nguyên mẫu phần mềm. Ở giai đoạn này, người lập trình (nhà phát triển) lập trình xử lý chức năng, gán các mô-đun cần thiết, sau đó chuyển các trường hợp kiểm thử được xây dựng theo tài liệu đặc tả cho người kiểm thử để kiểm tra chức năng.

   5. Giai đoạn thử nghiệm

   Ở giai đoạn này, người kiểm tra sẽ nhận được bàn giao chức năng từ người lập trình. Người kiểm thử sau đó sẽ kiểm tra các chức năng này dựa trên các trường hợp kiểm thử đã xây dựng. Trong quá trình kiểm thử đối với test case nếu có lỗi thì tester sẽ báo lỗi và cho lập trình viên thao tác trên chức năng đó để sửa lỗi.

   Quá trình kiểm tra chức năng, kiểm tra lại, báo cáo lỗi và báo cáo sẽ được thực hiện lặp đi lặp lại cho đến khi chức năng lập trình được triển khai theo tài liệu đặc tả hoặc yêu cầu của khách hàng. .

   Sau khi chức năng hoàn tất và các yêu cầu thử nghiệm được đáp ứng, phần mềm sẽ được thử nghiệm trong môi trường của khách hàng. Nếu có yêu cầu biên tập đối với phần mềm, nhóm phát triển phần mềm bổ sung và sửa lỗi để phần mềm được chấp nhận.

   6. Giai đoạn Triển khai Bảo trì

   Sau khi sản phẩm được thử nghiệm và sẵn sàng triển khai, sản phẩm sẽ chính thức được phát hành tại thị trường thích hợp. Đôi khi việc giới thiệu sản phẩm được tổ chức theo chiến lược kinh doanh của tổ chức. Trong quá trình sử dụng phần mềm khách hàng, nếu có bất kỳ lỗi nào xảy ra trong quá trình sử dụng, công ty phát triển phần mềm phải hỗ trợ và xử lý. Có hai khái niệm cần lưu ý ở đây:

   – Sửa chữa phần mềm: Sửa chữa các lỗi xảy ra trong quá trình sử dụng phần mềm máy khách.

   – Cập nhật Phần mềm (Bảo trì Cập nhật)

   • Hoàn thành bảo trì: sửa đổi phần mềm theo mong muốn của khách hàng
   • Bảo trì thích ứng: Sửa đổi phần mềm để thích ứng với môi trường mới

   Nhiều mô hình vòng đời phát triển phần mềm được xác định và thiết kế trong quá trình phát triển phần mềm. Các mô hình này được gọi là mô hình quy trình phát triển phần mềm. Mỗi mô hình quy trình tuân theo loại bước của nó để đảm bảo sự thành công của phát triển phần mềm. Dưới đây là các mô hình sdlc quan trọng và phổ biến nhất:

   1. Mô hình thác nước – Waterfall

   

   Mô hình này bao gồm các giai đoạn xử lý tuần tự sau:

   • Yêu cầu và Đặc điểm kỹ thuật : là giai đoạn xác định các yêu cầu chức năng và phi chức năng mà hệ thống phần mềm yêu cầu. Giai đoạn này yêu cầu sự tham gia tích cực của khách hàng và kết thúc bằng tài liệu được gọi là “Đặc tả yêu cầu phần mềm” hoặc srs (Đặc tả yêu cầu phần mềm). Tài liệu đặc tả yêu cầu là cơ sở cho các hoạt động tiếp theo cho đến khi kết thúc dự án.
   • Phân tích và Thiết kế Hệ thống : là giai đoạn xác định cách hệ thống phần mềm sẽ đáp ứng các yêu cầu do khách hàng chỉ định trong tài liệu. srs.
   • Mã hóa và Kiểm tra đơn vị : là giai đoạn thực tế được chỉ ra bởi giai đoạn Thiết kế và Phân tích Hệ thống
   • Kiểm tra : Bao gồm kiểm tra tích hợp và kiểm tra hệ thống cho các nhóm thành phần. Giai đoạn cuối cùng của kiểm thử thường được thực hiện là kiểm thử chấp nhận, trong đó khách hàng tham gia với vai trò quan trọng trong việc xác định xem hệ thống phần mềm có đáp ứng các yêu cầu của họ hay không.
   • Cài đặt và Bảo trì : Đây là giai đoạn cài đặt, cấu hình và đào tạo của khách hàng. Giai đoạn này sửa chữa các lỗi phần mềm (nếu có) và phát triển các thay đổi mới do khách hàng yêu cầu (như sửa đổi, thêm bớt các chức năng / tính năng của hệ thống).

   2. v-model – v-model

   

   • Trong mô hình thác nước, thử nghiệm được thực hiện trong một giai đoạn riêng biệt. Với mô hình v, toàn bộ quy trình được chia thành hai giai đoạn tương ứng: phát triển và thử nghiệm. Mỗi giai đoạn phát triển sẽ gắn liền với một giai đoạn thử nghiệm tương ứng
   • Đặc điểm chính của mô hình v là các hoạt động kiểm thử phải bắt đầu từ đầu chu kỳ (càng xa càng tốt) đồng thời với các hoạt động phát triển. Ví dụ: các hoạt động lập kế hoạch kiểm tra trên toàn hệ thống có thể được thực hiện đồng thời với các hoạt động phân tích và thiết kế hệ thống

   3. Mô hình xoắn ốc

   

   • Trong mô hình xoắn ốc, quá trình phát triển phần mềm được thực hiện giống như một đường xoắn ốc. Mỗi vòng xoắn đại diện cho một hoạt động trong quá trình phát triển phần mềm
   • Nó dựa trên ý tưởng giảm thiểu rủi ro bằng cách phân tích các yếu tố rủi ro trong mỗi lần lặp lại và sử dụng phương pháp tạo mẫu. Quá trình phát triển được chia thành nhiều bước lặp đi lặp lại, mỗi bước bắt đầu bằng việc lập kế hoạch, phân tích rủi ro, tạo mẫu, hoàn thiện và phát triển hệ thống, sửa đổi, v.v. Nội dung gồm 4 hoạt động chính:

   Lập kế hoạch: xác định mục tiêu, giải pháp và ràng buộc

   Phân tích rủi ro: Phân tích các lựa chọn, xác định và giải quyết rủi ro

   Phát triển và thử nghiệm: phát triển sản phẩm “cấp độ tiếp theo”. Xây dựng một hoặc nhiều bản trình bày của ứng dụng

   Lập kế hoạch cho chu kỳ lặp tiếp theo: Xem lại tất cả kết quả của các giai đoạn con đã xảy ra trước đó và lập kế hoạch cho lần lặp tiếp theo.

   • Phiên bản được cải tiến dần dần với mỗi lần lặp lại của hình xoắn ốc (bắt đầu từ trung tâm). Theo một vòng xoáy, phân tích rủi ro phải đưa ra quyết định “đi hay dừng”. Nếu rủi ro quá lớn, dự án có thể bị tạm dừng hoặc các yêu cầu thay đổi cho phù hợp. Mô hình này phù hợp để phát triển các hệ thống lớn.

   4. Mô hình Agile: Quy trình Scrum

   

   Sprint là một chu kỳ phát triển sản phẩm nhỏ. Trong một sprint, nhóm dự án sẽ tập trung vào việc phát triển một tính năng cụ thể và tinh chỉnh nó vào cuối mỗi sprint. Mỗi sprint có thời hạn thống nhất, thường là 1 hoặc 2 tuần, thường không quá 4 tuần.

   • Trước khi toàn bộ nhóm trải qua sprint, nhóm sản xuất họp với chủ sở hữu sản phẩm để lập kế hoạch cho mỗi sprint (được gọi là cuộc họp scrum). Kết quả của cuộc họp lập kế hoạch (theo kiểu scrum) là một cuộc họp sprint tồn đọng với công việc tồn đọng trong sprint
   • Trong quá trình phát triển, nhóm phải cập nhật sprint backlog và có các cuộc họp hàng ngày để chia sẻ tiến độ và các vấn đề trong khi cộng tác. Các đội có quyền tự quản lý và tổ chức công việc của họ để hoàn thành trong nước rút
   • Đánh giá sprint vào cuối sprint sẽ giúp khách hàng hiểu những gì nhóm có thể cung cấp, những gì còn phải làm hoặc những gì cần phải thay đổi hoặc cải thiện. Sau khi đánh giá sprint kết thúc, scrum master và nhóm tổ chức hồi cứu sprint để tìm kiếm các cải tiến trước khi sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm học hỏi và phát triển trong mỗi sprint.
   • Sprint được lặp lại cho đến khi hoàn thành dự án trong product backlog hoặc chủ sở hữu sản phẩm quyết định rằng có thể dừng dự án dựa trên tình hình thực tế. Bởi vì quy trình luôn được cải tiến, các nhóm scrum thường rất hiệu quả. Đây là hai trong số những lợi ích mà scrum mang lại cho một tổ chức.
   • Scrum xác định các quy tắc của bốn sự kiện chính (cuộc họp) để tạo môi trường và cách thức cho các thành viên dự án làm việc và cộng tác. Những buổi lễ này được tổ chức trước khi bắt đầu chạy nước rút (lập kế hoạch chạy nước rút), trong thời gian chạy nước rút (cuộc chạy nước rút hàng ngày) và sau khi chạy nước rút (đánh giá sprint và hồi tưởng sprint)
   • Trong scrum, nhóm phát triển phần mềm được chia thành ba vai trò với các trách nhiệm được xác định rõ ràng để đảm bảo rằng các nhiệm vụ cụ thể được tối ưu hóa. Ba vai trò này bao gồm: Product Owner (Chủ sở hữu sản phẩm), bậc thầy scrum và Nhóm phát triển (Nhóm sản xuất hoặc phát triển).

   Product Owner: là người chịu trách nhiệm về sự thành công của dự án, người xác định các yêu cầu và cuối cùng đánh giá kết quả đầu ra của nhà phát triển phần mềm

   scrum master: Họ phải đảm bảo hoàn thành nước rút đúng mục đích, bảo vệ đội và loại bỏ chướng ngại vật

   Nhóm phát triển: Thường từ 5-9 người, tùy theo quy mô của dự án, có thể có nhiều nhóm và nhiều người tham gia.