Một trong những tri thức cấp thiết của một kỹ sư kiểm thử phần mềm chuyên nghiệp đó là hiểu biết và nắm rõ SDLC (Software Development Life-cycle/chu kỳ luân hồi phát triển phần mềm), bởi vì kiểm thử phần mềm (software testing) là một trong những phần và liên quan chặt chẽ, mật thiết đến SDLC.

Bạn Đang Xem: Tìm hiểu về SDLC – Software Development Life Cycle

Vòng đời phát triển phần mềm (SDLC – Software Development Life Cycle) là một quá trình theo sau cho một dự án phần mềm, trong một tổ chức phần mềm. Nó gồm có một kế hoạch chi tiết cụ thể mô tả làm thế nào để 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ố cực kỳ quan trọng đem lại sự thành công cho những nhà sinh sản phần mềm, nó hỗ trợ cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài đơn vị đều sở hữu thể xử lý đồng bộ công việc tương ứng vị trí của mình thông qua phương pháp chung của đơn vị, hay ít nhất ở Lever dự án.

Trong thực tế các đơn vị xây dựng và phát triển phần mềm tùy theo từng quy mô, hình thức hoạt động mà có thể kiểm soát và điều chỉnh gộp tách các thời đoạn tùy theo nhu cầu thực tế của đơn vị đó. Tuy nhiên để tạo ra một sản phẩm phần mềm sẽ gồm có các thời đoạn sau:

1. Pha yêu cầu

2. Pha đặc tả

3. Pha thiết kế

4. Pha lập trình

5. Pha kiểm thử

6. Pha triển khai và bảo trì

1. Pha yêu cầu

Xem Thêm : Võ cổ truyền Việt Nam

Ở pha này phòng ban phân tích yêu cầu sẽ đi gặp và trao đổi với khách hàng cũng như làm rõ các chức năng, các yêu cầu mà khách hàng mong muốn xây dựng trong phần mềm của mình. Trong thực tế khi ở pha này các đơn vị phần mềm sẽ có được bộ thắc mắc chung dành cho những dự án cũng như thắc mắc riêng cho đặc thù của dự án cần làm.

Đây là pha quan trọng ảnh hưởng tác động đến việc xây dựng và phát triển phần mềm trong thời kì tới do vậy hàng ngũ phân tích yêu cầu thường là những người dân đã có nhiều kinh nghiệm giúp trong quá trình trao đổi với khách hàng sẽ làm rõ và hiểu đúng được những yêu cầu bài toán của khách hàng cũng như thu thập các biểu mẫu thông tin liên quan đến dự án về phục vụ phân tích ở thời đoạn kế tiếp.

2. Pha đặc tả

Đây là pha sẽ tiến hành thực hiện sau lúc đã ghi nhận những yêu cầu của khách hàng về phòng ban phân tích sẽ thực hiện làm rõ các yêu cầu và hiện thực hóa bằng một tài liệu SRS gọi là “Tài liệu đặc tả“. Đây là tài liệu rất quan trọng so với qúa trình phát triển phần mềm vì gồm có tất cả những yêu cầu sản phẩm được thiết kế và phát triển trong suốt vòng đời dự án. Các phòng ban liên quan như lập trình, kiểm thử viên,… sẽ thực hiện công việc dựa trên mô tả các chức năng chi tiết cụ thể trong tài liệu và nó sẽ trả lời thắc mắc “Phần mềm sẽ làm gì ?“.

3. Pha thiết kế

Ở pha này sau lúc địa thế căn cứ vào tài liệu đặc tả, phòng ban thiết kế sẽ thiết kế đưa ra giao diện chung cũng như phòng ban lập trình sẽ thiết kế giao diện mức chi tiết cụ thể theo từng chức năng của phần mềm. Tức là sẽ hiển thực hóa các chức năng trong tài liệu mô tả thành giao diện chức năng phần mềm dạng prototype. Sau đó sử dụng bản sườn phần mềm này để trao đổi và thống nhất với khách hàng về giao diện, bố cục tổng quan. Khi khách hàng đồng ý với thiết kế phần mềm theo prototype này sẽ mới chuyển sang thời đoạn tiếp theo nếu không sẽ ghi nhận ý kiến đóng góp và thực hiện chỉnh sửa cho đến lúc khách hàng đồng thuận với bản prototype phần mềm.

4. Pha lập trình

Trong thời đoạn này SDLC khai mạc phát triển thực tế và sản phẩm được xây dựng. Pha lập trình là pha hiện thực hóa các chức năng của phần mềm sau lúc khách hàng đã thống nhất prototype của phần mềm. Ở pha này các lập trình viên (developer) sẽ lập trình xử lý chức năng, module theo yêu cầu được giao giao sau này sẽ chuyển cho kiểm thử viên thực hiện kiểm tra các chức năng theo testcase được xây dựng dựa trên tài liệu đặc tả.

5. Pha kiểm thử

Ở pha này, các kiểm thử viên sẽ nhận được những chuyển giao chức năng thực hiện từ lập trình viên. Sau đó các kiểm thử viên sẽ thực hiện kiểm tra các chức năng này theo những testcase được xây dựng. Trong quá trình kiểm thử theo testcase nếu có phát sinh lỗi, kiểm thử viên sẽ thực hiện báo bug lỗi để lập trình viên xử lý chức năng đó fix lỗi.

Quá trình kiểm thử chức năng, kiểm tra lại, báo bug lỗi, báo cáo giải trình sẽ thực hiện đi thực hiện lại cho đến lúc các chức năng lập trình đã thực hiện đúng theo tài liệu đặc tả hay yêu cầu của khách hàng.

Sau lúc hoàn thiện các chức năng cũng như đạt yêu cầu về kiểm thử, phần mềm sẽ tiến hành triển khai thử nghiệm trên môi trường thiên nhiên của khách hàng. Nếu có yêu cầu chỉnh sửa hàng ngũ phát triển phần mềm sẽ thực hiện bổ sung, sửa lỗi để sở hữu thể sát hoạch phần mềm.

6. Pha triển khai bảo trì

Một khi sản phẩm sau lúc được kiểm thử và sẵn sàng triển khai, sản phẩm được phát hành chính thức trên thị trường thích hợp. Thỉnh thoảng việc triển khai sản phẩm xẩy ra theo từng thời đoạn theo chiến lược kinh doanh của tổ chức đó. Trong quá trình sử dụng phần mềm của khách hàng, đơn vị phát triển phần mềm sẽ phải tương trợ, xử lý lỗi nếu có phát sinh trong quá trình sử dụng. Ở đây có 2 khái niệm cần lưu ý đó là:

– Software repair (bảo trì sửa lỗi): Thực hiện chỉnh sửa các lỗi phát sinh trong quá trình sử dụng phần mềm của khách hàng.

– Software update (bảo trì update)

• Bảo trì hoàn thiện: Sửa đổi phần mềm theo ý 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 thiên nhiên mới

Có nhiều mô hình vòng đời phát triển phần mềm được xác định và thiết kế theo sau trong quá trình phát triển phần mềm. Các mô hình này được gọi là các mô hình quá trình phát triển phần mềm. Mỗi mô hình quy trình tuân theo những bước cho kiểu của nó để đảm bảo thành công trong quá trình phát triển phần mềm. Sau đây là các mô hình SDLC quan trọng và phổ thông nhất:

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

Xem Thêm : Cơ quan hành pháp là gì? Các cơ quan hành pháp bao gồm?

Mô hình này gồm có các thời đoạn xử lý tiếp nối nhau như sau:

• Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là thời đoạn xác định những Yêu cầu liên quan đến chức năng và phi chức năng mà mạng lưới hệ thống phần mềm cần có. Thời đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification). Tài liệu Đặc tả yêu cầu đây chính là nền tảng cho các hoạt động sinh hoạt tiếp theo cho tới cuối dự án.
• Phân tích mạng lưới hệ thống và thiết kế (System Analysis and Design): là thời đoạn định ra làm thế nào để mạng lưới hệ thống phần mềm đáp ứng những yêu cầu mà khách hàng yêu cầu trong tài liệu SRS.
• Lập trình (Coding and Unit Test): là thời đoạn hiện thực làm thế nào được chỉ ra trong thời đoạn “Phân tích mạng lưới hệ thống và thiết kế”
• Kiểm thử (Test): gồm có kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn mạng lưới hệ thống (system test). Một khâu kiểm thử cuối cùng thường được thực hiện là sát hoạch (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định mạng lưới hệ thống phần mềm có đáp ứng yêu cầu của họ hay là không.
• Cấu hình thiết lập và bảo trì (Deployment and Maintenance): đây là thời đoạn setup, cấu hình và tập huấn cho khách hàng. Thời đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của mạng lưới hệ thống).

2. Mô hình chữ V – V model

• Trong mô hình Waterfall, kiểm thử được thực hiện trong một thời đoạn riêng biệt. Còn với mô hình chữ V, toàn bộ qui trình được chia thành hai nhóm thời đoạn tương ứng nhau: phát triển và kiểm thử. Mỗi thời đoạn phát triển sẽ kết phù hợp với một thời đoạn kiểm thử tương ứng
• Ý thức chủ đạo của V-model là các hoạt động sinh hoạt kiểm thử phải được tiến hành song song (theo khả năng có thể) ngay từ trên đầu chu trình cùng với các hoạt động sinh hoạt phát triển. Ví dụ, các hoạt động sinh hoạt cho việc lập kế hoạch kiểm thử toàn mạng lưới hệ thống có thể được thực hiện song song với các hoạt động sinh hoạt phân tích và thiết kế mạng lưới hệ thống

3. Mô hình Xoắn ốc – Spiral model

• Trong mô hình xoắn ốc, quy trình phát triển phần mềm được thực hiện như một vòng xoáy ốc. Mỗi vòng xoắn ốc trình diễn một hoạt động trong tiến trình phát triển phần mềm
• Nó dựa trên ý tưởng là tối thiểu hóa rủi ro, bằng viêc phân tích yếu tố rủi ro ở từng bước một lặp và sử dụng phương pháp làm bản mẫu. Quá trình phát triển được chia thành nhiều bước tái diễn, từng bước một khai mạc bằng việc lập kế hoạch, phân tích rủi ro, rồi tạo bản mẫu, hoàn thiện và phát triển mạng lưới hệ thống, duyệt lại, và cứ thế tiếp tục. 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 phương án, xác định và xử lý rủi ro

Phát triển và kiểm định: phát triển sản phẩm “mức tiếp theo”. Xây dựng một hay một số trình diễn của ứng dụng

Lên kế hoạch cho chu kỳ luân hồi lặp tiếp theo: kiểm duyệt tất cả những kết quả của tương đối nhiều thời đoạn con xẩy ra trước đó và lập kế hoạch cho chu kỳ luân hồi lặp tiếp theo.

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

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

Sprint là chu trình nhỏ để phát triển sản phẩm. Trong Sprint, nhóm dự án sẽ tập trung phát triển những chức năng cụ thể nào đó và hoàn thiện nó vào mỗi cuối sprint. Mỗi Sprint có thời kì thống nhất, thường là một hoặc 2 tuần và thường không thực sự 4 tuần.

• Trước lúc cả nhóm thực hiện làm các sprint, đội sinh sản cùng họp với Product Owner để lập kế hoạch cho từng Sprint (gọi là Scrum Meeting). Kết quả của buổi lập kế hoạch (Theo phong cách làm của Scrum) là Sprint Backlog chứa các công việc cần làm trong suốt một Sprint
• Trong suốt quá trình phát triển, nhóm sẽ phải update Sprint Backlog và thực hiện công việc họp hằng ngày (Daily Scrum) để san sớt tiến độ công việc cũng như các vướng mắc trong quá trình thao tác cùng nhau. Nhóm được trao quyền để tự quản lí và tổ chức lấy công việc của mình để hoàn thành công việc trong Sprint
• Cuộc họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giao những gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến. Sau lúc kết thúc việc thẩm định Sprint, Scrum Master và nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective) để tìm kiếm các cải tiến trước lúc Sprint tiếp theo khai mạc, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint.
• Các Sprint sẽ tiến hành lặp đi tái diễn cho tới khi nào các hạng mục trong Product Backlog đều được hoàn thành hoặc khi Product Owner quyết định có thể dừng dự án địa thế căn cứ tình hình thực tế. Do quy trình luôn luôn luôn được cải tiến, nhóm Scrum thường có năng suất lao động rất cao. Đây là hai lợi ích to lớn mà Scrum mang lại cho tổ chức.
• Scrum khái niệm quy tắc cho bốn sự kiện then chốt (các cuộc họp) nhằm tạo môi trường thiên nhiên và quy cách hoạt động và hợp tác cho những thành viên trong dự án. Các lễ thức này diễn ra trước lúc Sprint khai mạc (Sprint Planning), trong những khi Sprint diễn ra (Daily Scrum) và sau lúc Sprint kết thúc (Sprint Review và Sprint Retrospective)
• Trong Scrum, hàng ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù. Ba vai trò này gồm có: Product Owner (chủ sản phẩm), Scrum Master và Development Team (Đội sinh sản hay Nhóm Phát triển).

Product Owner: Là người chịu trách nhiệm về sự việc thành công của dự án, người khái niệm các yêu cầu và thẩm định cuối cùng đầu ra của tương đối nhiều nhà phát triển phần mềm

Scrum Master: họ phải đảm bảo các sprint được hoàn thành đúng mục tiêu, bảo vệ đội thao tác và loại bỏ các trở ngại

Development Team: thường từ 5-9 người, tùy theo quy mô dự án nó có thể có rất nhiều đội, nhiều người tham gia.

https://www.tutorialspoint.com/sdlc/sdlc_overview.htm

http://istqbexamcertification.com/what-are-the-software-development-life-cycle-sdlc-phases/