Kỹ thuật phần mềm - Hướng dẫn nhanh

Đầu tiên chúng ta hãy hiểu kỹ thuật phần mềm là viết tắt của gì. Thuật ngữ này được tạo thành từ hai từ, phần mềm và kỹ thuật.

Software không chỉ là một mã chương trình. Chương trình là một mã thực thi, phục vụ một số mục đích tính toán. Phần mềm được coi là tập hợp các mã lập trình thực thi, các thư viện và tài liệu liên quan. Phần mềm, khi được tạo ra cho một yêu cầu cụ thể được gọi làsoftware product.

Engineering mặt khác, là tất cả về phát triển sản phẩm, sử dụng các nguyên tắc và phương pháp khoa học, được xác định rõ ràng.

Software engineeringlà một nhánh kỹ thuật gắn liền với việc phát triển sản phẩm phần mềm sử dụng các nguyên tắc, phương pháp và quy trình khoa học được xác định rõ ràng. Kết quả của kỹ thuật phần mềm là một sản phẩm phần mềm hiệu quả và đáng tin cậy.

Các định nghĩa

IEEE định nghĩa kỹ thuật phần mềm là:

(1) Việc áp dụng một cách tiếp cận có hệ thống, có kỷ luật, có thể định lượng được để phát triển, vận hành và bảo trì phần mềm; nghĩa là, ứng dụng của kỹ thuật vào phần mềm.

(2) Nghiên cứu các phương pháp tiếp cận như trong tuyên bố trên.

Fritz Bauer, một nhà khoa học máy tính người Đức, định nghĩa kỹ thuật phần mềm là:

Kỹ thuật phần mềm là việc thiết lập và sử dụng các nguyên tắc kỹ thuật hợp lý để có được phần mềm kinh tế đáng tin cậy và hoạt động hiệu quả trên các máy thực.

Tiến hóa phần mềm

Quá trình phát triển một sản phẩm phần mềm sử dụng các nguyên tắc và phương pháp kỹ thuật phần mềm được gọi là software evolution. Điều này bao gồm sự phát triển ban đầu của phần mềm và bảo trì và cập nhật cho đến khi sản phẩm phần mềm mong muốn được phát triển, đáp ứng các yêu cầu mong đợi.

Sự tiến hóa bắt đầu từ quá trình thu thập yêu cầu. Sau đó, các nhà phát triển tạo ra một nguyên mẫu của phần mềm dự định và hiển thị nó cho người dùng để nhận được phản hồi của họ ở giai đoạn đầu của quá trình phát triển sản phẩm phần mềm. Người dùng đề xuất các thay đổi, trên đó một số bản cập nhật liên tục và bảo trì cũng sẽ thay đổi. Quá trình này thay đổi thành phần mềm gốc, cho đến khi hoàn thành phần mềm mong muốn.

Ngay cả khi người dùng đã có phần mềm mong muốn trong tay, công nghệ tiên tiến và các yêu cầu thay đổi buộc sản phẩm phần mềm cũng phải thay đổi theo. Việc tạo lại phần mềm từ đầu và chuyển sang chế độ từng người một với yêu cầu là không khả thi. Giải pháp kinh tế và khả thi duy nhất là cập nhật phần mềm hiện có sao cho phù hợp với yêu cầu mới nhất.

Luật phát triển phần mềm

Lehman đã đưa ra các định luật cho sự phát triển phần mềm. Ông chia phần mềm thành ba loại khác nhau:

• S-type (static-type) - Đây là một phần mềm, hoạt động nghiêm ngặt theo các thông số kỹ thuật và giải pháp đã xác định . Giải pháp và phương pháp để đạt được nó, cả hai đều được hiểu ngay lập tức trước khi viết mã. Phần mềm loại s ít bị thay đổi nhất do đó đây là phần mềm đơn giản nhất. Ví dụ, chương trình máy tính để tính toán toán học.
• P-type (practical-type) - Đây là một phần mềm với một tập hợp các thủ tục. Điều này được xác định bởi chính xác những gì các thủ tục có thể làm. Trong phần mềm này, các thông số kỹ thuật có thể được mô tả nhưng giải pháp không rõ ràng ngay lập tức. Ví dụ, phần mềm chơi game.
• E-type (embedded-type) - Phần mềm này hoạt động chặt chẽ theo yêu cầu của môi trường thế giới thực . Phần mềm này có mức độ phát triển cao vì có nhiều thay đổi khác nhau về luật, thuế, v.v. trong các tình huống thực tế. Ví dụ, phần mềm giao dịch trực tuyến.

Sự phát triển của phần mềm E-Type

Lehman đã đưa ra tám định luật cho sự phát triển của phần mềm E-Type -

• Continuing change - Một hệ thống phần mềm kiểu điện tử phải tiếp tục thích ứng với những thay đổi của thế giới thực, nếu không nó sẽ dần trở nên kém hữu ích hơn.
• Increasing complexity - Khi hệ thống phần mềm kiểu E phát triển, độ phức tạp của nó có xu hướng tăng lên trừ khi công việc được thực hiện để duy trì hoặc giảm bớt nó.
• Conservation of familiarity - Sự quen thuộc với phần mềm hoặc kiến ​​thức về cách nó được phát triển, tại sao nó được phát triển theo cách cụ thể đó, v.v. phải được duy trì bằng mọi giá, để thực hiện các thay đổi trong hệ thống.
• Continuing growth- Để một hệ thống E-type nhằm giải quyết một số vấn đề kinh doanh, quy mô thực hiện các thay đổi của nó sẽ phát triển theo sự thay đổi lối sống của doanh nghiệp.
• Reducing quality - Hệ thống phần mềm loại E giảm chất lượng trừ khi được bảo trì nghiêm ngặt và thích nghi với môi trường hoạt động thay đổi.
• Feedback systems- Hệ thống phần mềm kiểu E tạo thành hệ thống phản hồi đa vòng, đa cấp và phải được xử lý như vậy để được sửa đổi hoặc cải tiến thành công.
• Self-regulation - Quá trình tiến hóa của hệ thống kiểu điện tử tự điều chỉnh với việc phân phối các sản phẩm và các biện pháp quá trình gần với mức bình thường.
• Organizational stability - Tỷ lệ hoạt động toàn cầu hiệu quả trung bình trong một hệ thống kiểu E đang phát triển là bất biến trong thời gian tồn tại của sản phẩm.

Mô hình phần mềm

Mô hình phần mềm đề cập đến các phương pháp và bước được thực hiện trong khi thiết kế phần mềm. Có rất nhiều phương pháp được đề xuất và đang hoạt động hiện nay, nhưng chúng ta cần xem những mô hình này đứng ở vị trí nào trong kỹ thuật phần mềm. Chúng có thể được kết hợp thành nhiều loại khác nhau, mặc dù mỗi loại được chứa trong một loại khác:

Mô hình lập trình là một tập con của Mô hình thiết kế phần mềm, là một tập con của Mô hình phát triển phần mềm.

Mô hình phát triển phần mềm

Mô hình này được gọi là mô hình kỹ thuật phần mềm nơi tất cả các khái niệm kỹ thuật liên quan đến sự phát triển của phần mềm được áp dụng. Nó bao gồm các nghiên cứu khác nhau và thu thập yêu cầu giúp sản phẩm phần mềm được xây dựng. Nó bao gồm -

• Thu thập các yêu cầu
• Thiết kế phần mềm
• Programming

Mô hình thiết kế phần mềm

Mô hình này là một phần của Phát triển phần mềm và bao gồm:

• Design
• Maintenance
• Programming

Mô hình lập trình

Mô hình này liên quan chặt chẽ đến khía cạnh lập trình của phát triển phần mềm. Điêu nay bao gôm -

• Coding
• Testing
• Integration

Cần Kỹ thuật Phần mềm

Nhu cầu của kỹ thuật phần mềm phát sinh do tốc độ thay đổi cao hơn trong các yêu cầu của người dùng và môi trường mà phần mềm đang hoạt động.

• Large software - Tương tự như vậy, việc xây một bức tường còn dễ hơn so với một ngôi nhà hay tòa nhà, vì kích thước của phần mềm trở nên lớn, kỹ thuật phải từng bước để tạo cho nó một quy trình khoa học.
• Scalability- Nếu quy trình phần mềm không dựa trên các khái niệm khoa học và kỹ thuật, thì việc tạo lại phần mềm mới sẽ dễ dàng hơn là mở rộng quy mô một phần mềm hiện có.
• Cost- Khi ngành công nghiệp phần cứng đã thể hiện kỹ năng của mình và sản xuất khổng lồ đã làm giảm giá phần cứng máy tính và điện tử. Nhưng chi phí của phần mềm vẫn cao nếu quy trình không phù hợp không được điều chỉnh.
• Dynamic Nature- Bản chất luôn phát triển và thích ứng của phần mềm phụ thuộc rất nhiều vào môi trường mà người dùng làm việc. Nếu bản chất của phần mềm luôn thay đổi, thì cần phải thực hiện những cải tiến mới cho phần mềm hiện có. Đây là nơi mà kỹ thuật phần mềm đóng một vai trò tốt.
• Quality Management- Quá trình phát triển phần mềm tốt hơn cung cấp sản phẩm phần mềm chất lượng và tốt hơn.

Đặc điểm của phần mềm tốt

Một sản phẩm phần mềm có thể được đánh giá bằng những gì nó cung cấp và nó có thể được sử dụng tốt như thế nào. Phần mềm này phải đáp ứng các cơ sở sau:

• Operational
• Transitional
• Maintenance

Phần mềm được thiết kế và chế tạo tốt dự kiến ​​sẽ có các đặc điểm sau:

Hoạt động

Điều này cho chúng ta biết phần mềm hoạt động tốt như thế nào trong các hoạt động. Nó có thể được đo trên:

• Budget
• Usability
• Efficiency
• Correctness
• Functionality
• Dependability
• Security
• Safety

Chuyển tiếp

Khía cạnh này rất quan trọng khi phần mềm được chuyển từ nền tảng này sang nền tảng khác:

• Portability
• Interoperability
• Reusability
• Adaptability

Bảo trì

Khía cạnh này tóm tắt về cách một phần mềm có khả năng tự duy trì trong môi trường luôn thay đổi:

• Modularity
• Maintainability
• Flexibility
• Scalability

Nói tóm lại, Kỹ thuật phần mềm là một nhánh của khoa học máy tính, sử dụng các khái niệm kỹ thuật được xác định rõ ràng cần thiết để tạo ra các sản phẩm phần mềm hiệu quả, bền, có thể mở rộng, phù hợp với ngân sách và đúng hạn.

Vòng đời phát triển phần mềm, viết tắt là SDLC, là một chuỗi các giai đoạn có cấu trúc, được xác định rõ ràng trong kỹ thuật phần mềm để phát triển sản phẩm phần mềm dự kiến.

Hoạt động SDLC

SDLC cung cấp một loạt các bước cần tuân theo để thiết kế và phát triển một sản phẩm phần mềm một cách hiệu quả. Khung SDLC bao gồm các bước sau:

Giao tiếp

Đây là bước đầu tiên mà người dùng bắt đầu yêu cầu một sản phẩm phần mềm mong muốn. Anh ta liên hệ với nhà cung cấp dịch vụ và cố gắng thương lượng các điều khoản. Anh ta gửi yêu cầu của mình đến tổ chức cung cấp dịch vụ bằng văn bản.

Thu thập các yêu cầu

Bước này trở đi, nhóm phát triển phần mềm làm việc để thực hiện dự án. Nhóm tổ chức các cuộc thảo luận với các bên liên quan khác nhau từ miền có vấn đề và cố gắng cung cấp càng nhiều thông tin càng tốt về các yêu cầu của họ. Các yêu cầu được xem xét và tách biệt thành yêu cầu của người dùng, yêu cầu hệ thống và yêu cầu chức năng. Các yêu cầu được thu thập bằng cách sử dụng một số thực hành như đã cho -

• nghiên cứu hệ thống và phần mềm hiện có hoặc lỗi thời,
• tiến hành phỏng vấn người dùng và nhà phát triển,
• tham chiếu đến cơ sở dữ liệu hoặc
• thu thập câu trả lời từ bảng câu hỏi.

Nghiên cứu khả thi

Sau khi thu thập yêu cầu, nhóm đưa ra một kế hoạch sơ bộ về quy trình phần mềm. Ở bước này, nhóm phân tích xem liệu một phần mềm có thể được tạo ra để đáp ứng tất cả các yêu cầu của người dùng hay không và liệu có khả năng phần mềm không còn hữu ích nữa hay không. Nó được tìm ra, nếu dự án khả thi về mặt tài chính, thực tế và công nghệ để tổ chức tiếp nhận. Có rất nhiều thuật toán có sẵn, giúp các nhà phát triển kết luận về tính khả thi của một dự án phần mềm.

Phân tích hệ thống

Ở bước này, các nhà phát triển quyết định lộ trình kế hoạch của họ và cố gắng đưa ra mô hình phần mềm tốt nhất phù hợp với dự án. Phân tích hệ thống bao gồm Hiểu biết về các giới hạn của sản phẩm phần mềm, các vấn đề liên quan đến hệ thống học hỏi hoặc các thay đổi cần thực hiện trước trong các hệ thống hiện có, xác định và giải quyết tác động của dự án đối với tổ chức và nhân sự, v.v. Nhóm dự án phân tích phạm vi dự án và lập kế hoạch tiến độ và tài nguyên phù hợp.

Thiết kế phần mềm

Bước tiếp theo là mang toàn bộ kiến ​​thức về các yêu cầu và phân tích trên bàn làm việc và thiết kế sản phẩm phần mềm. Đầu vào từ người dùng và thông tin thu thập được trong giai đoạn thu thập yêu cầu là đầu vào của bước này. Đầu ra của bước này có hai dạng; thiết kế logic và thiết kế vật lý. Các kỹ sư tạo ra siêu dữ liệu và từ điển dữ liệu, sơ đồ logic, sơ đồ luồng dữ liệu và trong một số trường hợp là mã giả.

Mã hóa

Bước này còn được gọi là giai đoạn lập trình. Việc thực hiện thiết kế phần mềm bắt đầu từ việc viết mã chương trình bằng ngôn ngữ lập trình phù hợp và phát triển các chương trình thực thi không có lỗi một cách hiệu quả.

Thử nghiệm

Một ước tính nói rằng 50% toàn bộ quy trình phát triển phần mềm nên được kiểm tra. Các lỗi có thể làm hỏng phần mềm từ mức độ nghiêm trọng đến mức độ xóa của chính nó. Kiểm thử phần mềm được thực hiện trong khi mã hóa bởi các nhà phát triển và kiểm tra kỹ lưỡng được thực hiện bởi các chuyên gia kiểm thử ở các cấp độ mã khác nhau như kiểm tra mô-đun, kiểm tra chương trình, kiểm tra sản phẩm, kiểm tra nội bộ và kiểm tra sản phẩm ở cuối người dùng. Phát hiện sớm các lỗi và cách khắc phục chúng là chìa khóa cho phần mềm đáng tin cậy.

Hội nhập

Phần mềm có thể cần được tích hợp với thư viện, cơ sở dữ liệu và (các) chương trình khác. Giai đoạn này của SDLC liên quan đến việc tích hợp phần mềm với các thực thể thế giới bên ngoài.

Thực hiện

Điều này có nghĩa là cài đặt phần mềm trên máy người dùng. Đôi khi, phần mềm cần cấu hình sau cài đặt ở người dùng. Phần mềm được kiểm tra tính di động và khả năng thích ứng và các vấn đề liên quan đến tích hợp được giải quyết trong quá trình thực hiện.

Vận hành và Bảo trì

Giai đoạn này xác nhận phần mềm hoạt động hiệu quả hơn và ít lỗi hơn. Nếu được yêu cầu, người dùng được đào tạo hoặc hỗ trợ tài liệu về cách vận hành phần mềm và cách duy trì hoạt động của phần mềm. Phần mềm được duy trì kịp thời bằng cách cập nhật mã theo những thay đổi diễn ra trong môi trường hoặc công nghệ cuối của người dùng. Giai đoạn này có thể phải đối mặt với những thách thức từ các lỗi ẩn và các vấn đề chưa được xác định trong thế giới thực.

Bố trí

Khi thời gian trôi qua, phần mềm có thể giảm hiệu suất. Nó có thể hoàn toàn lỗi thời hoặc có thể cần nâng cấp mạnh mẽ. Do đó nảy sinh nhu cầu cấp bách để loại bỏ một phần chính của hệ thống. Giai đoạn này bao gồm lưu trữ dữ liệu và các thành phần phần mềm cần thiết, đóng hệ thống, lập kế hoạch hoạt động xử lý và kết thúc hệ thống vào thời điểm thích hợp cuối hệ thống.

Mô hình phát triển phần mềm

Mô hình phát triển phần mềm giúp nhà phát triển lựa chọn chiến lược phát triển phần mềm. Mô hình phát triển phần mềm có bộ công cụ, phương pháp và thủ tục riêng, được thể hiện rõ ràng và xác định vòng đời phát triển phần mềm. Một số mô hình phát triển phần mềm hoặc mô hình quy trình được định nghĩa như sau:

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

Mô hình thác nước là mô hình đơn giản nhất của mô hình phát triển phần mềm. Nó cho biết tất cả các giai đoạn của SDLC sẽ lần lượt hoạt động theo cách tuyến tính. Có nghĩa là, khi giai đoạn đầu tiên kết thúc thì chỉ có giai đoạn thứ hai sẽ bắt đầu và cứ tiếp tục như vậy.

Mô hình này giả định rằng mọi thứ được tiến hành và diễn ra một cách hoàn hảo theo kế hoạch trong giai đoạn trước và không cần phải suy nghĩ về những vấn đề trong quá khứ có thể phát sinh trong giai đoạn tiếp theo. Mô hình này không hoạt động trơn tru nếu còn một số vấn đề ở bước trước. Bản chất tuần tự của mô hình không cho phép chúng ta quay lại và hoàn tác hoặc làm lại các hành động của mình.

Mô hình này phù hợp nhất khi các nhà phát triển đã thiết kế và phát triển phần mềm tương tự trong quá khứ và nhận thức được tất cả các miền của nó.

Mô hình lặp lại

Mô hình này dẫn đầu quá trình phát triển phần mềm trong các lần lặp lại. Nó chiếu quá trình phát triển theo cách tuần hoàn lặp lại mỗi bước sau mỗi chu kỳ của quy trình SDLC.

Phần mềm lần đầu tiên được phát triển trên quy mô rất nhỏ và tất cả các bước được thực hiện sau đó đều được xem xét. Sau đó, vào mỗi lần lặp lại tiếp theo, nhiều tính năng và mô-đun hơn được thiết kế, mã hóa, thử nghiệm và thêm vào phần mềm. Mỗi chu trình tạo ra một phần mềm, tự nó hoàn chỉnh và có nhiều tính năng và khả năng hơn so với chu trình trước đó.

Sau mỗi lần lặp, nhóm quản lý có thể thực hiện công việc quản lý rủi ro và chuẩn bị cho lần lặp tiếp theo. Vì một chu trình bao gồm một phần nhỏ của toàn bộ quy trình phần mềm, nên việc quản lý quy trình phát triển sẽ dễ dàng hơn nhưng lại tiêu tốn nhiều tài nguyên hơn.

Mô hình xoắn ốc

Mô hình xoắn ốc là sự kết hợp của cả hai, mô hình lặp lại và một trong những mô hình SDLC. Nó có thể được xem như nếu bạn chọn một mô hình SDLC và kết hợp nó với quy trình tuần hoàn (mô hình lặp).

Mô hình này xem xét rủi ro, điều này thường không được hầu hết các mô hình khác chú ý. Mô hình bắt đầu với việc xác định các mục tiêu và ràng buộc của phần mềm khi bắt đầu một lần lặp. Giai đoạn tiếp theo là tạo mẫu phần mềm. Điều này bao gồm phân tích rủi ro. Sau đó, một mô hình SDLC tiêu chuẩn được sử dụng để xây dựng phần mềm. Trong giai đoạn thứ tư của kế hoạch lặp lại tiếp theo được chuẩn bị.

V - mô hình

Hạn chế chính của mô hình thác nước là chúng ta chỉ chuyển sang giai đoạn tiếp theo khi giai đoạn trước đã hoàn thành và không có cơ hội quay lại nếu phát hiện có điều gì đó sai trong giai đoạn sau. V-Model cung cấp các phương tiện kiểm tra phần mềm ở từng giai đoạn theo cách ngược lại.

Ở mọi giai đoạn, kế hoạch thử nghiệm và trường hợp thử nghiệm được tạo ra để xác minh và xác thực sản phẩm theo yêu cầu của giai đoạn đó. Ví dụ, trong giai đoạn thu thập yêu cầu, nhóm kiểm thử chuẩn bị tất cả các trường hợp kiểm thử tương ứng với các yêu cầu. Sau đó, khi sản phẩm được phát triển và sẵn sàng để thử nghiệm, các trường hợp kiểm thử của giai đoạn này sẽ xác minh phần mềm về tính hợp lệ của nó đối với các yêu cầu ở giai đoạn này.

Điều này làm cho cả xác minh và xác thực diễn ra song song. Mô hình này còn được gọi là mô hình xác minh và xác nhận.

Mô hình Big Bang

Mô hình này là mô hình đơn giản nhất trong hình thức của nó. Nó đòi hỏi ít kế hoạch, nhiều chương trình và nhiều vốn. Mô hình này được lên ý tưởng xung quanh vụ nổ lớn của vũ trụ. Như các nhà khoa học nói rằng sau vụ nổ lớn của nhiều thiên hà, các hành tinh và ngôi sao đã tiến hóa giống như một sự kiện. Tương tự như vậy, nếu chúng ta tập hợp nhiều lập trình và kinh phí, bạn có thể đạt được sản phẩm phần mềm tốt nhất.

Đối với mô hình này, cần phải lập kế hoạch rất nhỏ. Nó không tuân theo bất kỳ quy trình nào, hoặc đôi khi khách hàng không chắc chắn về yêu cầu và nhu cầu trong tương lai. Vì vậy các yêu cầu đầu vào là tùy ý.

Mô hình này không phù hợp với các dự án phần mềm lớn nhưng là mô hình tốt để học hỏi và thử nghiệm.

Để đọc chuyên sâu về SDLC và các mô hình khác nhau của nó, hãy nhấp vào đây.

Mô hình công việc của một công ty CNTT tham gia vào phát triển phần mềm có thể được chia thành hai phần:

• Tạo phần mềm
• Quản lý dự án phần mềm

Một dự án là nhiệm vụ được xác định rõ ràng, là tập hợp một số hoạt động được thực hiện để đạt được mục tiêu (ví dụ: phát triển và phân phối phần mềm). Một Dự án có thể được mô tả như sau:

• Mỗi dự án có thể có một mục tiêu duy nhất và khác biệt.
• Dự án không phải là hoạt động thường ngày hoặc hoạt động hàng ngày.
• Dự án có thời gian bắt đầu và thời gian kết thúc.
• Dự án kết thúc khi mục tiêu của nó đạt được do đó nó là một giai đoạn tạm thời trong vòng đời của một tổ chức.
• Dự án cần có đủ nguồn lực về thời gian, nhân lực, tài chính, vật lực và ngân hàng tri thức.

Dự án phần mềm

Dự án Phần mềm là toàn bộ quy trình phát triển phần mềm từ thu thập yêu cầu đến kiểm tra và bảo trì, được thực hiện theo phương pháp thực thi, trong một khoảng thời gian xác định để đạt được sản phẩm phần mềm dự kiến.

Cần quản lý dự án phần mềm

Phần mềm được cho là một sản phẩm vô hình. Phát triển phần mềm là một loại hình hoàn toàn mới trong kinh doanh thế giới và có rất ít kinh nghiệm trong việc xây dựng các sản phẩm phần mềm. Hầu hết các sản phẩm phần mềm được thiết kế riêng để phù hợp với yêu cầu của khách hàng. Điều quan trọng nhất là công nghệ cơ bản thay đổi và tiến bộ thường xuyên và nhanh chóng đến mức trải nghiệm của một sản phẩm có thể không được áp dụng cho sản phẩm kia. Tất cả những hạn chế về kinh doanh và môi trường như vậy đều mang lại rủi ro trong quá trình phát triển phần mềm, do đó điều cần thiết là phải quản lý các dự án phần mềm một cách hiệu quả.

Hình ảnh trên cho thấy ba hạn chế đối với các dự án phần mềm. Nó là một phần thiết yếu của tổ chức phần mềm để cung cấp sản phẩm chất lượng, giữ chi phí trong giới hạn ngân sách của khách hàng và thực hiện dự án theo đúng lịch trình. Có một số yếu tố, cả bên trong và bên ngoài, có thể tác động đến tam giác ràng buộc ba này. Bất kỳ yếu tố nào trong ba yếu tố đều có thể ảnh hưởng nghiêm trọng đến hai yếu tố kia.

Do đó, quản lý dự án phần mềm là điều cần thiết để kết hợp các yêu cầu của người dùng cùng với các hạn chế về ngân sách và thời gian.

Quản lý dự án phần mềm

Người quản lý dự án phần mềm là người đảm nhận trách nhiệm thực hiện dự án phần mềm. Người quản lý dự án phần mềm hiểu rõ tất cả các giai đoạn của SDLC mà phần mềm sẽ trải qua. Người quản lý dự án có thể không bao giờ trực tiếp tham gia sản xuất sản phẩm cuối cùng nhưng anh ta kiểm soát và quản lý các hoạt động liên quan đến sản xuất.

Người quản lý dự án giám sát chặt chẽ quá trình phát triển, chuẩn bị và thực hiện các kế hoạch khác nhau, sắp xếp các nguồn lực cần thiết và đầy đủ, duy trì liên lạc giữa tất cả các thành viên trong nhóm để giải quyết các vấn đề về chi phí, ngân sách, nguồn lực, thời gian, chất lượng và sự hài lòng của khách hàng.

Hãy để chúng tôi thấy một số trách nhiệm mà người quản lý dự án phải gánh vác -

Quản lý con người

• Hoạt động như trưởng dự án
• Tổn thương với các bên liên quan
• Quản lý nguồn nhân lực
• Thiết lập phân cấp báo cáo, v.v.

Quản lý dự án

• Xác định và thiết lập phạm vi dự án
• Quản lý các hoạt động quản lý dự án
• Giám sát tiến độ và hiệu suất
• Phân tích rủi ro ở mọi giai đoạn
• Thực hiện các bước cần thiết để tránh hoặc thoát khỏi vấn đề
• Làm người phát ngôn của dự án

Hoạt động quản lý phần mềm

Quản lý dự án phần mềm bao gồm một số hoạt động, bao gồm lập kế hoạch dự án, quyết định phạm vi sản phẩm phần mềm, ước tính chi phí theo các điều khoản khác nhau, lập lịch trình các nhiệm vụ và sự kiện, và quản lý tài nguyên. Các hoạt động quản lý dự án có thể bao gồm:

• Project Planning
• Scope Management
• Project Estimation

Lập kế hoạch dự án

Lập kế hoạch dự án phần mềm là nhiệm vụ, được thực hiện trước khi quá trình sản xuất phần mềm thực sự bắt đầu. Nó ở đó để sản xuất phần mềm nhưng không liên quan đến hoạt động cụ thể nào có liên quan đến hướng sản xuất phần mềm; đúng hơn nó là một tập hợp nhiều quy trình, tạo điều kiện cho việc sản xuất phần mềm. Lập kế hoạch dự án có thể bao gồm những điều sau:

Phạm vi quản lí

Nó xác định phạm vi của dự án; điều này bao gồm tất cả các hoạt động, quá trình cần được thực hiện để tạo ra một sản phẩm phần mềm có thể phân phối. Quản lý phạm vi là điều cần thiết vì nó tạo ra ranh giới của dự án bằng cách xác định rõ ràng những gì sẽ được thực hiện trong dự án và những gì sẽ không được thực hiện. Điều này làm cho dự án chứa các nhiệm vụ có giới hạn và có thể định lượng được, có thể dễ dàng được lập thành tài liệu và do đó tránh được chi phí và thời gian chạy quá nhiều.

Trong quá trình quản lý Phạm vi dự án, cần phải -

• Xác định phạm vi
• Quyết định xác minh và kiểm soát nó
• Chia dự án thành nhiều phần nhỏ khác nhau để dễ quản lý.
• Xác minh phạm vi
• Kiểm soát phạm vi bằng cách kết hợp các thay đổi đối với phạm vi

Dự toán dự án

Để quản lý hiệu quả, cần phải ước tính chính xác các biện pháp khác nhau. Với việc lập dự toán chính xác, các nhà quản lý có thể quản lý và kiểm soát dự án hiệu quả và hiệu quả hơn.

Dự toán dự án có thể bao gồm những điều sau:

• Software size estimation

  Kích thước phần mềm có thể được ước tính theo KLOC (Dòng mã Kilo) hoặc bằng cách tính toán số điểm chức năng trong phần mềm. Các dòng mã phụ thuộc vào thực tiễn mã hóa và các điểm Chức năng thay đổi tùy theo yêu cầu của người dùng hoặc phần mềm.

• Effort estimation

  Các nhà quản lý ước tính những nỗ lực về yêu cầu nhân sự và giờ công cần thiết để sản xuất phần mềm. Đối với nỗ lực ước tính kích thước phần mềm nên được biết. Điều này có thể được rút ra từ kinh nghiệm của người quản lý, dữ liệu lịch sử của tổ chức hoặc quy mô phần mềm có thể được chuyển đổi thành nỗ lực bằng cách sử dụng một số công thức tiêu chuẩn.

• Time estimation

  Khi kích thước và nỗ lực được ước tính, thời gian cần thiết để sản xuất phần mềm có thể được ước tính. Các nỗ lực cần thiết được phân tách thành các danh mục phụ theo yêu cầu kỹ thuật và sự phụ thuộc lẫn nhau của các thành phần khác nhau của phần mềm. Các nhiệm vụ phần mềm được chia thành các nhiệm vụ, hoạt động hoặc sự kiện nhỏ hơn theo Cấu trúc Đột phá Công việc (WBS). Các nhiệm vụ được lên lịch hàng ngày hoặc theo tháng dương lịch.

  Tổng thời gian cần thiết để hoàn thành tất cả các công việc tính bằng giờ hoặc ngày là tổng thời gian đã đầu tư để hoàn thành dự án.

• Cost estimation

  Đây có thể coi là khó khăn nhất vì nó phụ thuộc vào nhiều yếu tố hơn bất kỳ yếu tố nào trước đó. Để ước tính chi phí dự án, cần phải xem xét -

• Kích thước của phần mềm
• Chất lượng phần mềm
• Hardware
• Phần mềm hoặc công cụ bổ sung, giấy phép, v.v.
• Nhân viên lành nghề với các kỹ năng cụ thể cho nhiệm vụ
• Du lịch liên quan
• Communication
• Đào tạo và hỗ trợ

Kỹ thuật ước tính dự án

Chúng tôi đã thảo luận về các thông số khác nhau liên quan đến ước tính dự án như quy mô, nỗ lực, thời gian và chi phí.

Người quản lý dự án có thể ước tính các yếu tố được liệt kê bằng cách sử dụng hai kỹ thuật được công nhận rộng rãi:

Kỹ thuật phân hủy

Kỹ thuật này giả định phần mềm là sản phẩm của nhiều thành phần khác nhau.

Có hai mô hình chính -

• Line of Code Việc ước tính được thực hiện thay mặt cho số dòng mã trong sản phẩm phần mềm.
• Function Points Ước tính được thực hiện thay mặt cho số điểm chức năng trong sản phẩm phần mềm.

Kỹ thuật ước tính thực nghiệm

Kỹ thuật này sử dụng các công thức có nguồn gốc thực nghiệm để ước tính. Các công thức này dựa trên LOC hoặc FP.

• Putnam Model

  Mô hình này do Lawrence H. Putnam thực hiện, dựa trên phân bố tần số của Norden (đường cong Rayleigh). Mô hình Putnam ánh xạ thời gian và nỗ lực cần thiết với kích thước phần mềm.

• COCOMO

  COCOMO là viết tắt của COnstructive COst MOdel, được phát triển bởi Barry W. Boehm. Nó chia sản phẩm phần mềm thành ba loại phần mềm: phần mềm hữu cơ, phần tách rời và phần mềm nhúng.

Lập kế hoạch dự án

Lập kế hoạch dự án trong một dự án đề cập đến lộ trình của tất cả các hoạt động được thực hiện theo thứ tự cụ thể và trong khoảng thời gian được phân bổ cho từng hoạt động. Các nhà quản lý dự án có xu hướng xác định các nhiệm vụ khác nhau và các mốc quan trọng của dự án và sắp xếp chúng theo các yếu tố khác nhau. Họ tìm kiếm các nhiệm vụ nằm trong lộ trình quan trọng trong lịch trình, cần thiết để hoàn thành theo cách cụ thể (vì nhiệm vụ phụ thuộc lẫn nhau) và nghiêm ngặt trong thời gian được phân bổ. Việc sắp xếp các nhiệm vụ nằm ngoài lộ trình quan trọng ít có khả năng ảnh hưởng đến toàn bộ tiến độ của dự án.

Để lên lịch cho một dự án, cần phải -

• Chia các nhiệm vụ dự án thành dạng nhỏ hơn, dễ quản lý
• Tìm ra các nhiệm vụ khác nhau và tương quan chúng
• Ước tính khung thời gian cần thiết cho mỗi nhiệm vụ
• Chia thời gian thành các đơn vị công việc
• Chỉ định đủ số lượng đơn vị công việc cho mỗi nhiệm vụ
• Tính tổng thời gian cần thiết cho dự án từ đầu đến cuối

Quản lý tài nguyên

Tất cả các yếu tố được sử dụng để phát triển một sản phẩm phần mềm có thể được coi là tài nguyên cho dự án đó. Điều này có thể bao gồm nguồn nhân lực, công cụ sản xuất và thư viện phần mềm.

Các tài nguyên có sẵn với số lượng hạn chế và ở trong tổ chức dưới dạng một nhóm tài sản. Sự thiếu hụt nguồn lực cản trở sự phát triển của dự án và có thể bị chậm tiến độ. Cuối cùng, phân bổ các nguồn lực bổ sung sẽ làm tăng chi phí phát triển. Do đó cần phải ước tính và phân bổ nguồn lực đầy đủ cho dự án.

Quản lý tài nguyên bao gồm -

• Xác định tổ chức dự án phù hợp bằng cách tạo một nhóm dự án và phân bổ trách nhiệm cho từng thành viên trong nhóm
• Xác định các nguồn lực cần thiết ở một giai đoạn cụ thể và tính khả dụng của chúng
• Quản lý Tài nguyên bằng cách tạo yêu cầu tài nguyên khi chúng được yêu cầu và hủy phân bổ chúng khi không cần nữa.

Quản lý rủi ro dự án

Quản lý rủi ro bao gồm tất cả các hoạt động liên quan đến xác định, phân tích và lập dự phòng cho các rủi ro có thể dự đoán được và không thể dự đoán được trong dự án. Rủi ro có thể bao gồm những điều sau:

• Nhân viên có kinh nghiệm rời dự án và nhân viên mới đến.
• Thay đổi trong quản lý tổ chức.
• Yêu cầu thay đổi hoặc hiểu sai yêu cầu.
• Ước tính thấp thời gian và nguồn lực cần thiết.
• Thay đổi công nghệ, thay đổi môi trường, cạnh tranh kinh doanh.

Quy trình quản lý rủi ro

Có các hoạt động sau liên quan đến quá trình quản lý rủi ro:

• Identification - Lưu ý tất cả các rủi ro có thể xảy ra, có thể xảy ra trong dự án.
• Categorize - Phân loại rủi ro đã biết thành cường độ rủi ro cao, trung bình và thấp tùy theo tác động có thể có của chúng đối với dự án.
• Manage - Phân tích xác suất xảy ra rủi ro ở các giai đoạn khác nhau. Lập kế hoạch để tránh hoặc đối mặt với rủi ro. Cố gắng giảm thiểu tác dụng phụ của chúng.
• Monitor - Theo dõi chặt chẽ các nguy cơ tiềm ẩn và các triệu chứng ban đầu của chúng. Đồng thời theo dõi ảnh hưởng của các bước được thực hiện để giảm thiểu hoặc tránh chúng.

Thực hiện & Giám sát Dự án

Trong giai đoạn này, các nhiệm vụ được mô tả trong kế hoạch dự án được thực hiện theo lịch trình của chúng.

Việc thực hiện cần được giám sát để kiểm tra xem mọi thứ có diễn ra theo đúng kế hoạch hay không. Giám sát là quan sát để kiểm tra xác suất rủi ro và thực hiện các biện pháp để giải quyết rủi ro hoặc báo cáo tình trạng của các nhiệm vụ khác nhau.

Các biện pháp này bao gồm -

• Activity Monitoring - Tất cả các hoạt động được lên lịch trong một số nhiệm vụ có thể được giám sát hàng ngày. Khi tất cả các hoạt động trong một nhiệm vụ được hoàn thành, nó được coi là hoàn thành.
• Status Reports - Các báo cáo chứa tình trạng của các hoạt động và nhiệm vụ đã hoàn thành trong một khung thời gian nhất định, thường là một tuần. Trạng thái có thể được đánh dấu là đã hoàn thành, đang chờ xử lý hoặc đang tiến hành, v.v.
• Milestones Checklist - Mỗi dự án được chia thành nhiều giai đoạn trong đó các nhiệm vụ chính được thực hiện (các mốc quan trọng) dựa trên các giai đoạn của SDLC. Danh sách kiểm tra cột mốc này được chuẩn bị vài tuần một lần và báo cáo trạng thái của các cột mốc quan trọng.

Quản lý truyền thông dự án

Giao tiếp hiệu quả đóng vai trò quan trọng trong sự thành công của một dự án. Nó thu hẹp khoảng cách giữa khách hàng và tổ chức, giữa các thành viên trong nhóm cũng như các bên liên quan khác trong dự án như nhà cung cấp phần cứng.

Giao tiếp có thể bằng miệng hoặc bằng văn bản. Quy trình quản lý thông tin liên lạc có thể có các bước sau:

• Planning - Bước này bao gồm danh tính của tất cả các bên liên quan trong dự án và phương thức giao tiếp giữa họ. Nó cũng xem xét nếu cần bất kỳ phương tiện liên lạc bổ sung nào.
• Sharing - Sau khi xác định các khía cạnh khác nhau của kế hoạch, người quản lý tập trung vào việc chia sẻ thông tin chính xác với đúng người vào đúng thời gian. Điều này giúp mọi người tham gia dự án được cập nhật về tiến độ dự án và tình trạng của nó.
• Feedback - Người quản lý dự án sử dụng các biện pháp và cơ chế phản hồi khác nhau và tạo báo cáo trạng thái và hiệu suất. Cơ chế này đảm bảo rằng đầu vào từ các bên liên quan khác nhau sẽ đến với người quản lý dự án dưới dạng phản hồi của họ.
• Closure - Vào cuối mỗi sự kiện lớn, kết thúc giai đoạn SDLC hoặc kết thúc dự án, việc đóng quản trị được thông báo chính thức để cập nhật cho mọi bên liên quan bằng cách gửi email, bằng cách phân phối bản cứng của tài liệu hoặc bằng các phương tiện liên lạc hiệu quả khác.

Sau khi kết thúc, nhóm chuyển sang giai đoạn hoặc dự án tiếp theo.

Quản lý cấu hình

Quản lý cấu hình là một quá trình theo dõi và kiểm soát những thay đổi trong phần mềm về các yêu cầu, thiết kế, chức năng và sự phát triển của sản phẩm.

IEEE định nghĩa nó là “quá trình xác định và xác định các mục trong hệ thống, kiểm soát sự thay đổi của các mục này trong suốt vòng đời của chúng, ghi lại và báo cáo trạng thái của các mục và yêu cầu thay đổi, đồng thời xác minh tính đầy đủ và đúng đắn của các mục”.

Nói chung, khi SRS được hoàn thiện, sẽ có ít khả năng yêu cầu thay đổi từ người dùng hơn. Nếu chúng xảy ra, các thay đổi chỉ được giải quyết khi có sự chấp thuận trước của cấp quản lý cao hơn, vì có khả năng chi phí và thời gian bị vượt quá.

Đường cơ sở

Một giai đoạn của SDLC được giả định hơn nếu nó được xác định cơ sở, tức là đường cơ sở là phép đo xác định mức độ hoàn chỉnh của một giai đoạn. Một giai đoạn được xác định cơ sở khi tất cả các hoạt động liên quan đến nó được kết thúc và được ghi lại đầy đủ. Nếu nó không phải là giai đoạn cuối cùng, đầu ra của nó sẽ được sử dụng trong giai đoạn tiếp theo.

Quản lý cấu hình là một kỷ luật của quản trị tổ chức, quản lý sự xuất hiện của bất kỳ thay đổi nào (quy trình, yêu cầu, công nghệ, chiến lược, v.v.) sau khi một giai đoạn được xác định. CM luôn kiểm tra mọi thay đổi được thực hiện trong phần mềm.

Kiểm soát thay đổi

Kiểm soát thay đổi là chức năng của quản lý cấu hình, đảm bảo rằng tất cả các thay đổi được thực hiện đối với hệ thống phần mềm là nhất quán và được thực hiện theo các quy tắc và quy định của tổ chức.

Việc thay đổi cấu hình của sản phẩm thực hiện theo các bước sau:

• Identification- Yêu cầu thay đổi đến từ nguồn bên trong hoặc bên ngoài. Khi yêu cầu thay đổi được xác định chính thức, nó sẽ được ghi lại một cách chính xác.

• Validation - Tính hợp lệ của yêu cầu thay đổi được kiểm tra và quy trình xử lý của nó được xác nhận.

• Analysis- Tác động của yêu cầu thay đổi được phân tích về lịch trình, chi phí và các nỗ lực cần thiết. Tác động tổng thể của sự thay đổi trong tương lai đối với hệ thống được phân tích.

• Control- Nếu sự thay đổi tiềm năng tác động đến quá nhiều thực thể trong hệ thống hoặc không thể tránh khỏi, thì bắt buộc phải có sự chấp thuận của các cơ quan có thẩm quyền cấp cao trước khi sự thay đổi được đưa vào hệ thống. Nó được quyết định nếu thay đổi có giá trị kết hợp hay không. Nếu không, yêu cầu thay đổi chính thức bị từ chối.

• Execution - Nếu giai đoạn trước xác định thực hiện yêu cầu thay đổi, giai đoạn này thực hiện các hành động thích hợp để thực hiện thay đổi, thực hiện sửa đổi kỹ lưỡng nếu cần thiết.

• Close request- Thay đổi được xác minh để thực hiện đúng và hợp nhất với phần còn lại của hệ thống. Thay đổi mới được kết hợp này trong phần mềm được ghi lại đúng cách và yêu cầu được chính thức đóng lại.

Công cụ quản lý dự án

Rủi ro và sự không chắc chắn tăng lên gấp bội so với quy mô của dự án, ngay cả khi dự án được phát triển theo các phương pháp luận đã định.

Có sẵn các công cụ hỗ trợ quản lý dự án hiệu quả. Một số được mô tả -

Biểu đồ Gantt

Biểu đồ Gantt do Henry Gantt (1917) nghĩ ra. Nó đại diện cho lịch trình của dự án đối với các khoảng thời gian. Nó là một biểu đồ thanh ngang với các thanh thể hiện các hoạt động và thời gian được lên lịch cho các hoạt động của dự án.

Biểu đồ PERT

Biểu đồ PERT (Kỹ thuật Đánh giá & Đánh giá Chương trình) là một công cụ mô tả dự án dưới dạng sơ đồ mạng. Nó có khả năng biểu diễn đồ họa các sự kiện chính của dự án theo cách song song và liên tiếp. Các sự kiện xảy ra nối tiếp nhau, cho thấy sự phụ thuộc của sự kiện sau so với sự kiện trước.

Các sự kiện được hiển thị dưới dạng các nút được đánh số. Chúng được kết nối với nhau bằng các mũi tên có nhãn mô tả trình tự các nhiệm vụ trong dự án.

Biểu đồ tài nguyên

Đây là một công cụ đồ họa có chứa thanh hoặc biểu đồ đại diện cho số lượng tài nguyên (thường là nhân viên lành nghề) cần thiết theo thời gian cho một sự kiện (hoặc giai đoạn) của dự án. Biểu đồ nguồn lực là một công cụ hiệu quả để lập kế hoạch và điều phối nhân viên.

Phân tích đường dẫn quan trọng

Công cụ này hữu ích trong việc nhận ra các nhiệm vụ phụ thuộc lẫn nhau trong dự án. Nó cũng giúp tìm ra con đường ngắn nhất hoặc con đường quan trọng để hoàn thành dự án thành công. Giống như biểu đồ PERT, mỗi sự kiện được phân bổ cho một khung thời gian cụ thể. Công cụ này hiển thị sự phụ thuộc của sự kiện giả sử một sự kiện chỉ có thể tiếp tục nếu sự kiện trước đó được hoàn thành.

Các sự kiện được sắp xếp theo thời gian bắt đầu sớm nhất có thể. Đường dẫn giữa nút đầu và nút cuối là đường dẫn quan trọng không thể giảm hơn nữa và tất cả các sự kiện yêu cầu phải được thực hiện theo cùng một thứ tự.

Các yêu cầu phần mềm là mô tả các tính năng và chức năng của hệ thống đích. Các yêu cầu chuyển tải những mong đợi của người dùng từ sản phẩm phần mềm. Các yêu cầu có thể rõ ràng hoặc ẩn, đã biết hoặc chưa biết, mong đợi hoặc bất ngờ theo quan điểm của khách hàng.

Kỹ thuật yêu cầu

Quá trình thu thập các yêu cầu phần mềm từ khách hàng, phân tích và ghi lại chúng được gọi là kỹ thuật yêu cầu.

Mục tiêu của kỹ thuật yêu cầu là phát triển và duy trì tài liệu 'Đặc tả yêu cầu hệ thống' phức tạp và mang tính mô tả.

Quy trình kỹ thuật yêu cầu

Đây là một quy trình bốn bước, bao gồm:

• Nghiên cứu khả thi
• Thu thập các yêu cầu
• những yêu cầu chi tiết của phần mềm
• Xác thực yêu cầu phần mềm

Hãy để chúng tôi xem quy trình ngắn gọn -

Nghiên cứu khả thi

Khi khách hàng tiếp cận tổ chức để phát triển sản phẩm mong muốn, họ nảy ra ý tưởng sơ bộ về những gì mà tất cả các chức năng phần mềm phải thực hiện và tất cả các tính năng được mong đợi từ phần mềm.

Tham khảo thông tin này, các nhà phân tích thực hiện một nghiên cứu chi tiết về việc liệu hệ thống mong muốn và chức năng của nó có khả thi để phát triển hay không.

Nghiên cứu khả thi này tập trung vào mục tiêu của tổ chức. Nghiên cứu này phân tích liệu sản phẩm phần mềm có thể được hiện thực hóa trên thực tế về mặt thực hiện, đóng góp của dự án cho tổ chức, các ràng buộc chi phí và theo các giá trị và mục tiêu của tổ chức. Nó khám phá các khía cạnh kỹ thuật của dự án và sản phẩm như khả năng sử dụng, khả năng bảo trì, năng suất và khả năng tích hợp.

Đầu ra của giai đoạn này là một báo cáo nghiên cứu khả thi cần có các nhận xét và khuyến nghị đầy đủ cho ban quản lý về việc có nên thực hiện dự án hay không.

Thu thập các yêu cầu

Nếu báo cáo khả thi là tích cực đối với việc thực hiện dự án, giai đoạn tiếp theo bắt đầu với việc thu thập các yêu cầu từ người sử dụng. Các nhà phân tích và kỹ sư giao tiếp với khách hàng và người dùng cuối để biết ý tưởng của họ về những gì phần mềm nên cung cấp và những tính năng nào họ muốn phần mềm bao gồm.

những yêu cầu chi tiết của phần mềm

SRS là một tài liệu được tạo bởi nhà phân tích hệ thống sau khi các yêu cầu được thu thập từ các bên liên quan khác nhau.

SRS xác định cách phần mềm dự định sẽ tương tác với phần cứng, giao diện bên ngoài, tốc độ hoạt động, thời gian phản hồi của hệ thống, tính di động của phần mềm trên các nền tảng khác nhau, khả năng bảo trì, tốc độ phục hồi sau khi gặp sự cố, Bảo mật, Chất lượng, Hạn chế, v.v.

Các yêu cầu nhận được từ khách hàng được viết bằng ngôn ngữ tự nhiên. Người phân tích hệ thống có trách nhiệm ghi lại các yêu cầu bằng ngôn ngữ kỹ thuật để nhóm phát triển phần mềm có thể hiểu được và hữu ích.

SRS sẽ đưa ra các tính năng sau:

• Yêu cầu của người dùng được thể hiện bằng ngôn ngữ tự nhiên.
• Các yêu cầu kỹ thuật được thể hiện bằng ngôn ngữ có cấu trúc, được sử dụng bên trong tổ chức.
• Mô tả thiết kế nên được viết bằng mã Pseudo.
• Định dạng biểu mẫu và bản in màn hình GUI.
• Các ký hiệu điều kiện và toán học cho DFD, v.v.

Xác thực yêu cầu phần mềm

Sau khi các thông số kỹ thuật yêu cầu được phát triển, các yêu cầu được đề cập trong tài liệu này sẽ được xác nhận. Người dùng có thể yêu cầu giải pháp bất hợp pháp, không thực tế hoặc các chuyên gia có thể giải thích các yêu cầu không chính xác. Điều này dẫn đến việc tăng chi phí rất lớn nếu không được khai thác từ trong trứng nước. Các yêu cầu có thể được kiểm tra dựa trên các điều kiện sau:

• Nếu chúng có thể được triển khai trên thực tế
• Nếu chúng hợp lệ và theo chức năng và miền của phần mềm
• Nếu có bất kỳ sự mơ hồ nào
• Nếu chúng hoàn thành
• Nếu chúng có thể được chứng minh

Quy trình kích thích yêu cầu

Quá trình kích thích yêu cầu có thể được mô tả bằng cách sử dụng sơ đồ folloiwng:

• Requirements gathering - Các nhà phát triển thảo luận với khách hàng và người dùng cuối và biết mong đợi của họ từ phần mềm.
• Organizing Requirements - Các nhà phát triển ưu tiên và sắp xếp các yêu cầu theo thứ tự quan trọng, khẩn cấp và thuận tiện.

• Negotiation & discussion - Nếu các yêu cầu không rõ ràng hoặc có một số xung đột trong các yêu cầu của các bên liên quan khác nhau, nếu có, thì nó sẽ được thương lượng và thảo luận với các bên liên quan. Các yêu cầu sau đó có thể được ưu tiên và thỏa hiệp hợp lý.

  Các yêu cầu đến từ các bên liên quan khác nhau. Để loại bỏ sự mơ hồ và xung đột, chúng được thảo luận để rõ ràng và đúng đắn. Các yêu cầu phi thực tế được thỏa hiệp một cách hợp lý.

• Documentation - Tất cả các yêu cầu chính thức và không chính thức, chức năng và phi chức năng đều được lập thành văn bản và sẵn sàng cho quá trình xử lý giai đoạn tiếp theo.

Kỹ thuật kích thích yêu cầu

Yêu cầu Kích thích là quá trình để tìm ra các yêu cầu đối với một hệ thống phần mềm dự kiến ​​bằng cách giao tiếp với khách hàng, người dùng cuối, người dùng hệ thống và những người khác có cổ phần trong việc phát triển hệ thống phần mềm.

Có nhiều cách khác nhau để khám phá các yêu cầu

Phỏng vấn

Phỏng vấn là phương tiện mạnh mẽ để thu thập các yêu cầu. Tổ chức có thể tiến hành một số hình thức phỏng vấn như:

• Phỏng vấn có cấu trúc (kín), trong đó mọi thông tin thu thập đều được quyết định trước, họ tuân theo khuôn mẫu và vấn đề thảo luận một cách chắc chắn.
• Phỏng vấn không cấu trúc (mở), nơi thông tin thu thập không được quyết định trước, linh hoạt hơn và ít thiên vị hơn.
• Phỏng vấn miệng
• Phỏng vấn viết
• Phỏng vấn 1-1 được tổ chức giữa hai người trên bàn.
• Phỏng vấn nhóm được tổ chức giữa các nhóm người tham gia. Họ giúp phát hiện ra bất kỳ yêu cầu còn thiếu nào khi có nhiều người tham gia.

Khảo sát

Tổ chức có thể tiến hành khảo sát giữa các bên liên quan khác nhau bằng cách truy vấn về kỳ vọng và yêu cầu của họ từ hệ thống sắp tới.

Bảng câu hỏi

Một tài liệu với bộ câu hỏi khách quan được xác định trước và các phương án tương ứng được giao cho tất cả các bên liên quan trả lời, được thu thập và biên soạn.

Một thiếu sót của kỹ thuật này là, nếu một tùy chọn cho một số vấn đề không được đề cập trong bảng câu hỏi, vấn đề có thể bị bỏ qua.

Phân tích công việc

Nhóm kỹ sư và nhà phát triển có thể phân tích hoạt động mà hệ thống mới được yêu cầu. Nếu khách hàng đã có một số phần mềm để thực hiện một số hoạt động nhất định, nó sẽ được nghiên cứu và thu thập các yêu cầu của hệ thống đề xuất.

Phân tích tên miền

Mọi phần mềm đều thuộc một số danh mục miền. Những người có chuyên môn trong lĩnh vực này có thể trợ giúp đắc lực để phân tích các yêu cầu chung và cụ thể.

Động não

Một cuộc tranh luận không chính thức được tổ chức giữa các bên liên quan khác nhau và tất cả đầu vào của họ được ghi lại để phân tích các yêu cầu thêm.

Tạo mẫu

Prototyping là xây dựng giao diện người dùng mà không thêm chức năng chi tiết để người dùng diễn giải các tính năng của sản phẩm phần mềm dự định. Nó giúp đưa ra ý tưởng tốt hơn về các yêu cầu. Nếu không có phần mềm nào được cài đặt ở cuối ứng dụng khách để nhà phát triển tham khảo và khách hàng không nhận thức được các yêu cầu của riêng mình, nhà phát triển sẽ tạo một nguyên mẫu dựa trên các yêu cầu được đề cập ban đầu. Nguyên mẫu được hiển thị cho khách hàng và phản hồi được ghi nhận. Phản hồi của khách hàng đóng vai trò là đầu vào để thu thập yêu cầu.

Quan sát

Nhóm chuyên gia đến thăm tổ chức hoặc nơi làm việc của khách hàng. Họ quan sát hoạt động thực tế của các hệ thống đã được cài đặt hiện có. Họ quan sát quy trình làm việc ở cuối khách hàng và cách xử lý các vấn đề thực thi. Nhóm tự rút ra một số kết luận hỗ trợ hình thành các yêu cầu mong đợi từ phần mềm.

Đặc điểm yêu cầu phần mềm

Thu thập các yêu cầu phần mềm là nền tảng của toàn bộ dự án phát triển phần mềm. Do đó chúng phải rõ ràng, chính xác và được xác định rõ ràng.

Thông số kỹ thuật yêu cầu phần mềm hoàn chỉnh phải là:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Nguồn đáng tin cậy

Yêu cầu phần mềm

Chúng ta nên cố gắng hiểu những loại yêu cầu nào có thể phát sinh trong giai đoạn kích thích yêu cầu và những loại yêu cầu nào được mong đợi từ hệ thống phần mềm.

Nhìn chung, các yêu cầu phần mềm nên được phân loại thành hai loại:

Yêu cầu chức năng

Các yêu cầu liên quan đến khía cạnh chức năng của phần mềm thuộc loại này.

Chúng xác định các chức năng và chức năng bên trong và từ hệ thống phần mềm.

Ví dụ -

• Tùy chọn tìm kiếm được cung cấp cho người dùng để tìm kiếm từ các hóa đơn khác nhau.
• Người dùng có thể gửi bất kỳ báo cáo nào đến ban quản lý.
• Người dùng có thể được chia thành các nhóm và các nhóm có thể được cấp các quyền riêng biệt.
• Nên tuân thủ các quy tắc kinh doanh và chức năng quản trị.
• Phần mềm được phát triển để giữ nguyên khả năng tương thích xuống.

Những yêu cầu phi lý

Các yêu cầu, không liên quan đến khía cạnh chức năng của phần mềm, thuộc loại này. Chúng là những đặc điểm tiềm ẩn hoặc được mong đợi của phần mềm mà người dùng đưa ra giả định.

Các yêu cầu phi chức năng bao gồm:

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Khôi phục thảm họa
• Accessibility

Các yêu cầu được phân loại hợp lý như

• Must Have : Không thể nói phần mềm hoạt động nếu không có chúng.
• Should have : Nâng cao chức năng của phần mềm.
• Could have : Phần mềm vẫn có thể hoạt động bình thường với các yêu cầu này.
• Wish list : Các yêu cầu này không liên quan đến bất kỳ mục tiêu nào của phần mềm.

Trong khi phát triển phần mềm, "Phải có" phải được thực hiện, "Nên có" là một vấn đề tranh luận với các bên liên quan và phủ định, trong khi "có thể có" và "danh sách mong muốn" có thể được giữ để cập nhật phần mềm.

Yêu cầu về giao diện người dùng

Giao diện người dùng là một phần quan trọng của bất kỳ phần mềm hoặc phần cứng hoặc hệ thống kết hợp nào. Một phần mềm được chấp nhận rộng rãi nếu nó -

• dễ dàng hoạt động
• phản hồi nhanh chóng
• xử lý hiệu quả các lỗi vận hành
• cung cấp giao diện người dùng đơn giản nhưng nhất quán

Sự chấp nhận của người dùng chủ yếu phụ thuộc vào cách người dùng có thể sử dụng phần mềm. Giao diện người dùng là cách duy nhất để người dùng cảm nhận hệ thống. Một hệ thống phần mềm hoạt động tốt cũng phải được trang bị giao diện người dùng hấp dẫn, rõ ràng, nhất quán và đáp ứng. Nếu không, các chức năng của hệ thống phần mềm không thể được sử dụng một cách thuận tiện. Một hệ thống được cho là tốt nếu nó cung cấp các phương tiện để sử dụng nó một cách hiệu quả. Các yêu cầu về giao diện người dùng được đề cập ngắn gọn bên dưới:

• Nội dung trình bày
• Điều hướng dễ dàng
• Giao diện đơn giản
• Responsive
• Các phần tử giao diện người dùng nhất quán
• Cơ chế phản hồi
• Thiết lập mặc định
• Bố cục có mục đích
• Sử dụng màu sắc và kết cấu có chiến lược.
• Cung cấp thông tin trợ giúp
• Phương pháp lấy người dùng làm trung tâm
• Cài đặt chế độ xem dựa trên nhóm.

Nhà phân tích hệ thống phần mềm

Nhà phân tích hệ thống trong một tổ chức CNTT là người phân tích yêu cầu của hệ thống được đề xuất và đảm bảo rằng các yêu cầu được hình thành và lập thành văn bản một cách hợp lý & chính xác. Vai trò của một nhà phân tích bắt đầu trong Giai đoạn Phân tích Phần mềm của SDLC. Người phân tích có trách nhiệm đảm bảo rằng phần mềm được phát triển đáp ứng các yêu cầu của khách hàng.

Nhà phân tích hệ thống có các trách nhiệm sau:

• Phân tích và hiểu các yêu cầu của phần mềm dự định
• Hiểu dự án sẽ đóng góp như thế nào trong các mục tiêu của tổ chức
• Xác định các nguồn yêu cầu
• Xác thực yêu cầu
• Xây dựng và thực hiện kế hoạch quản lý yêu cầu
• Tài liệu về yêu cầu kinh doanh, kỹ thuật, quy trình và sản phẩm
• Phối hợp với khách hàng để ưu tiên các yêu cầu và loại bỏ và sự mơ hồ
• Hoàn thiện các tiêu chí chấp nhận với khách hàng và các bên liên quan khác

Các thước đo và số liệu phần mềm

Các biện pháp phần mềm có thể được hiểu là một quá trình định lượng và ký hiệu các thuộc tính và khía cạnh khác nhau của phần mềm.

Số liệu phần mềm cung cấp các thước đo cho các khía cạnh khác nhau của quy trình phần mềm và sản phẩm phần mềm.

Các biện pháp phần mềm là yêu cầu cơ bản của kỹ thuật phần mềm. Chúng không chỉ giúp kiểm soát quá trình phát triển phần mềm mà còn giúp giữ cho chất lượng của sản phẩm cuối cùng xuất sắc.

Theo Tom DeMarco, một (Kỹ sư phần mềm), "Bạn không thể kiểm soát những gì bạn không thể đo lường." Qua câu nói của ông, có thể thấy rất rõ rằng các biện pháp phần mềm quan trọng như thế nào.

Hãy cho chúng tôi xem một số chỉ số phần mềm:

• Size Metrics - LOC (Dòng mã), hầu hết được tính bằng hàng nghìn dòng mã nguồn được phân phối, được ký hiệu là KLOC.

  Chức năng Đếm điểm là thước đo chức năng được cung cấp bởi phần mềm. Chức năng Số điểm xác định kích thước của khía cạnh chức năng của phần mềm.

• Complexity Metrics - Độ phức tạp Cyclomatic của McCabe định lượng giới hạn trên của số lượng đường dẫn độc lập trong một chương trình, được coi là độ phức tạp của chương trình hoặc các mô-đun của nó. Nó được biểu diễn dưới dạng các khái niệm lý thuyết đồ thị bằng cách sử dụng đồ thị luồng điều khiển.

• Quality Metrics - Các khuyết tật, dạng và nguyên nhân của chúng, hậu quả, mức độ nghiêm trọng và tác động của chúng xác định chất lượng sản phẩm.

  Số lượng khuyết tật được tìm thấy trong quá trình phát triển và số lượng lỗi được khách hàng báo cáo sau khi sản phẩm được lắp đặt hoặc giao hàng tại khách hàng, xác định chất lượng của sản phẩm.

• Process Metrics - Trong các giai đoạn khác nhau của SDLC, các phương pháp và công cụ được sử dụng, các tiêu chuẩn của công ty và hiệu suất phát triển là các thước đo quy trình phần mềm.
• Resource Metrics - Nỗ lực, thời gian và các nguồn lực khác nhau được sử dụng, đại diện cho các số liệu để đo lường nguồn lực.

Thiết kế phần mềm là một quá trình chuyển đổi các yêu cầu của người dùng thành một số dạng phù hợp, giúp người lập trình viết mã và thực hiện phần mềm.

Để đánh giá các yêu cầu của người dùng, một tài liệu SRS (Đặc tả yêu cầu phần mềm) được tạo trong khi để mã hóa và triển khai, cần có các yêu cầu cụ thể và chi tiết hơn trong điều khoản phần mềm. Đầu ra của quá trình này có thể được sử dụng trực tiếp để thực hiện trong các ngôn ngữ lập trình.

Thiết kế phần mềm là bước đầu tiên trong SDLC (Vòng đời thiết kế phần mềm), nó chuyển nồng độ từ miền vấn đề sang miền giải pháp. Nó cố gắng chỉ định cách thực hiện các yêu cầu được đề cập trong SRS.

Cấp độ thiết kế phần mềm

Thiết kế phần mềm mang lại ba cấp độ kết quả:

• Architectural Design - Thiết kế kiến ​​trúc là phiên bản trừu tượng cao nhất của hệ thống. Nó xác định phần mềm là một hệ thống có nhiều thành phần tương tác với nhau. Ở cấp độ này, các nhà thiết kế có được ý tưởng về miền giải pháp được đề xuất.
• High-level Design- Thiết kế cấp cao phá vỡ khái niệm 'một thực thể nhiều thành phần' của thiết kế kiến ​​trúc thành một cái nhìn ít trừu tượng hơn về các hệ thống con và mô-đun và mô tả sự tương tác của chúng với nhau. Thiết kế cấp cao tập trung vào cách hệ thống cùng với tất cả các thành phần của nó có thể được thực hiện dưới dạng mô-đun. Nó nhận biết cấu trúc mô-đun của từng hệ thống con và mối quan hệ và tác động qua lại giữa chúng.
• Detailed Design- Thiết kế chi tiết đề cập đến phần thực hiện của những gì được coi là một hệ thống và các hệ thống con của nó trong hai thiết kế trước. Nó chi tiết hơn về các mô-đun và việc triển khai chúng. Nó xác định cấu trúc logic của từng mô-đun và các giao diện của chúng để giao tiếp với các mô-đun khác.

Mô-đun hóa

Mô-đun hóa là một kỹ thuật để chia một hệ thống phần mềm thành nhiều mô-đun rời rạc và độc lập, được mong đợi có khả năng thực hiện (các) nhiệm vụ một cách độc lập. Các mô-đun này có thể hoạt động như các cấu trúc cơ bản cho toàn bộ phần mềm. Các nhà thiết kế có xu hướng thiết kế các mô-đun sao cho chúng có thể được thực thi và / hoặc được biên dịch riêng biệt và độc lập.

Thiết kế mô-đun vô tình tuân theo các quy tắc của chiến lược giải quyết vấn đề 'chia để trị', điều này là do có nhiều lợi ích khác đi kèm với thiết kế mô-đun của một phần mềm.

Lợi thế của mô-đun hóa:

• Các thành phần nhỏ hơn dễ bảo trì hơn
• Chương trình có thể được phân chia dựa trên các khía cạnh chức năng
• Mức độ trừu tượng mong muốn có thể được đưa vào chương trình
• Các thành phần có độ gắn kết cao có thể được sử dụng lại
• Có thể thực hiện đồng thời
• Mong muốn từ khía cạnh bảo mật

Đồng tiền

Ngược dòng thời gian, tất cả các phần mềm đều được thực thi tuần tự. Bằng cách thực thi tuần tự, chúng tôi có nghĩa là lệnh được mã hóa sẽ được thực hiện lần lượt với ngụ ý chỉ một phần của chương trình được kích hoạt tại bất kỳ thời điểm nào. Giả sử, một phần mềm có nhiều mô-đun, thì chỉ một trong số tất cả các mô-đun có thể được tìm thấy hoạt động tại bất kỳ thời điểm thực thi nào.

Trong thiết kế phần mềm, đồng thời được thực hiện bằng cách chia phần mềm thành nhiều đơn vị thực thi độc lập, giống như các mô-đun và thực thi chúng song song. Nói cách khác, đồng thời cung cấp khả năng để phần mềm thực thi nhiều phần mã song song với nhau.

Các lập trình viên và nhà thiết kế cần phải nhận ra các mô-đun đó, chúng có thể được thực hiện song song.

Thí dụ

Tính năng kiểm tra chính tả trong trình xử lý văn bản là một mô-đun của phần mềm, chạy dọc theo chính trình xử lý văn bản.

Khớp nối và liên kết

Khi một chương trình phần mềm được mô-đun hóa, các nhiệm vụ của nó được chia thành nhiều mô-đun dựa trên một số đặc điểm. Như chúng ta đã biết, các mô-đun là tập hợp các hướng dẫn được ghép lại với nhau để đạt được một số nhiệm vụ. Mặc dù chúng được coi là một thực thể đơn lẻ nhưng có thể tham chiếu lẫn nhau để làm việc cùng nhau. Có những thước đo để đo lường chất lượng của thiết kế các mô-đun và sự tương tác giữa chúng với nhau. Các biện pháp này được gọi là ghép nối và gắn kết.

Sự gắn kết

Sự gắn kết là một thước đo xác định mức độ tin cậy nội bộ trong các phần tử của một mô-đun. Tính liên kết càng lớn thì thiết kế chương trình càng tốt.

Có bảy loại liên kết, cụ thể là -

• Co-incidental cohesion -Đó là sự gắn kết ngẫu nhiên và không có kế hoạch, có thể là kết quả của việc chia nhỏ chương trình thành các mô-đun nhỏ hơn nhằm mục đích mô-đun hóa. Bởi vì nó không có kế hoạch, nó có thể gây nhầm lẫn cho các lập trình viên và thường không được chấp nhận.
• Logical cohesion - Khi các phần tử được phân loại một cách hợp lý được ghép lại với nhau thành một mô-đun, nó được gọi là sự gắn kết hợp lý.
• emporal Cohesion - Khi các phần tử của mô-đun được tổ chức sao cho chúng được xử lý tại một thời điểm tương tự, nó được gọi là sự gắn kết thời gian.
• Procedural cohesion - Khi các phần tử của mô-đun được nhóm lại với nhau, được thực thi tuần tự để thực hiện một tác vụ, nó được gọi là liên kết thủ tục.
• Communicational cohesion - Khi các phần tử của mô-đun được nhóm lại với nhau, được thực thi tuần tự và hoạt động trên cùng một dữ liệu (thông tin), nó được gọi là gắn kết giao tiếp.
• Sequential cohesion - Khi các phần tử của mô-đun được nhóm lại vì đầu ra của một phần tử này đóng vai trò là đầu vào cho phần tử khác, v.v., nó được gọi là liên kết tuần tự.
• Functional cohesion - Nó được coi là mức độ gắn kết cao nhất và rất được kỳ vọng. Các phần tử của mô-đun trong liên kết chức năng được nhóm lại vì chúng đều đóng góp vào một chức năng được xác định rõ ràng. Nó cũng có thể được tái sử dụng.

Khớp nối

Khớp nối là một thước đo xác định mức độ tin cậy lẫn nhau giữa các mô-đun của chương trình. Nó cho biết các mô-đun giao thoa và tương tác với nhau ở cấp độ nào. Khớp nối càng thấp thì chương trình càng tốt.

Có năm cấp độ khớp nối, cụ thể là -

• Content coupling - Khi một mô-đun có thể truy cập trực tiếp hoặc sửa đổi hoặc tham chiếu đến nội dung của mô-đun khác, nó được gọi là ghép mức nội dung.
• Common coupling- Khi nhiều mô-đun có quyền truy cập đọc và ghi vào một số dữ liệu chung, nó được gọi là khớp nối chung hoặc khớp nối toàn cầu.
• Control coupling- Hai mô-đun được gọi là kết hợp điều khiển nếu một trong số chúng quyết định chức năng của mô-đun kia hoặc thay đổi luồng thực thi của nó.
• Stamp coupling- Khi nhiều mô-đun chia sẻ cấu trúc dữ liệu chung và làm việc trên một phần khác nhau của nó, nó được gọi là ghép tem.
• Data coupling- Ghép nối dữ liệu là khi hai mô-đun tương tác với nhau bằng cách truyền dữ liệu (dưới dạng tham số). Nếu một mô-đun chuyển cấu trúc dữ liệu dưới dạng tham số, thì mô-đun nhận sẽ sử dụng tất cả các thành phần của nó.

Lý tưởng nhất là không có khớp nối nào được coi là tốt nhất.

Xác minh thiết kế

Đầu ra của quy trình thiết kế phần mềm là tài liệu thiết kế, mã giả, sơ đồ logic chi tiết, sơ đồ quy trình và mô tả chi tiết về tất cả các yêu cầu chức năng hoặc phi chức năng.

Giai đoạn tiếp theo, là triển khai phần mềm, phụ thuộc vào tất cả các kết quả đầu ra được đề cập ở trên.

Sau đó, nó trở nên cần thiết để xác minh đầu ra trước khi tiếp tục giai đoạn tiếp theo. Bất kỳ sai sót nào được phát hiện sớm càng tốt hoặc nó có thể không được phát hiện cho đến khi kiểm tra sản phẩm. Nếu kết quả đầu ra của giai đoạn thiết kế ở dạng ký hiệu chính thức, thì các công cụ liên quan của chúng để xác minh nên được sử dụng, nếu không thì có thể sử dụng đánh giá thiết kế kỹ lưỡng để xác minh và xác nhận.

Bằng cách tiếp cận xác minh có cấu trúc, người đánh giá có thể phát hiện ra các khiếm khuyết có thể do bỏ qua một số điều kiện. Đánh giá thiết kế tốt là rất quan trọng để thiết kế phần mềm tốt, chính xác và chất lượng.

Phân tích và thiết kế phần mềm bao gồm tất cả các hoạt động, giúp chuyển đổi đặc tả yêu cầu thành việc thực hiện. Đặc tả yêu cầu xác định tất cả các mong đợi chức năng và phi chức năng từ phần mềm. Các thông số kỹ thuật yêu cầu này ở dạng các tài liệu con người có thể đọc và hiểu được, mà máy tính không phải làm gì.

Phân tích và thiết kế phần mềm là giai đoạn trung gian, giúp các yêu cầu có thể đọc được của con người được chuyển thành mã thực tế.

Hãy cho chúng tôi xem một số công cụ phân tích và thiết kế được các nhà thiết kế phần mềm sử dụng:

Sơ đồ luồng dữ liệu

Sơ đồ luồng dữ liệu là biểu diễn đồ họa của luồng dữ liệu trong hệ thống thông tin. Nó có khả năng mô tả luồng dữ liệu đến, luồng dữ liệu đi và dữ liệu được lưu trữ. DFD không đề cập bất cứ điều gì về cách dữ liệu chảy qua hệ thống.

Có một sự khác biệt nổi bật giữa DFD và Lưu đồ. Lưu đồ mô tả luồng điều khiển trong các mô-đun chương trình. DFD mô tả luồng dữ liệu trong hệ thống ở nhiều cấp độ khác nhau. DFD không chứa bất kỳ phần tử điều khiển hoặc nhánh nào.

Các loại DFD

Sơ đồ Luồng Dữ liệu là Lôgic hoặc Vật lý.

• Logical DFD - Loại DFD này tập trung vào quy trình hệ thống và luồng dữ liệu trong hệ thống, ví dụ trong hệ thống phần mềm Ngân hàng, dữ liệu được di chuyển như thế nào giữa các thực thể khác nhau.
• Physical DFD- Loại DFD này cho thấy luồng dữ liệu thực sự được thực hiện như thế nào trong hệ thống. Nó cụ thể hơn và gần với việc thực hiện.

Thành phần DFD

DFD có thể đại diện cho Nguồn, đích, lưu trữ và luồng dữ liệu bằng cách sử dụng tập hợp các thành phần sau:

• Entities- Các thực thể là nguồn và đích của dữ liệu thông tin. Các thực thể được biểu diễn bằng một hình chữ nhật với tên tương ứng của chúng.
• Process - Các hoạt động và hành động được thực hiện trên dữ liệu được thể hiện bằng Hình tròn hoặc Hình chữ nhật có cạnh tròn.
• Data Storage - Có hai biến thể lưu trữ dữ liệu - nó có thể được biểu diễn dưới dạng hình chữ nhật không có cả hai cạnh nhỏ hơn hoặc dưới dạng hình chữ nhật có mặt mở chỉ thiếu một cạnh.
• Data Flow- Chuyển động của dữ liệu được thể hiện bằng các mũi tên nhọn. Di chuyển dữ liệu được hiển thị từ gốc của mũi tên là nguồn của nó đến đầu của mũi tên là đích.

Các cấp độ của DFD

• Level 0- DFD mức trừu tượng cao nhất được gọi là DFD mức 0, mô tả toàn bộ hệ thống thông tin như một sơ đồ che giấu tất cả các chi tiết bên dưới. DFD mức 0 còn được gọi là DFD mức ngữ cảnh.

• Level 1- DFD Cấp 0 được chia thành DFD Cấp 1 cụ thể hơn. DFD mức 1 mô tả các mô-đun cơ bản trong hệ thống và luồng dữ liệu giữa các mô-đun khác nhau. DFD cấp độ 1 cũng đề cập đến các quy trình và nguồn thông tin cơ bản.


• Level 2 - Ở cấp độ này, DFD hiển thị cách dữ liệu chảy bên trong các mô-đun được đề cập ở Cấp độ 1.

  DFD cấp cao hơn có thể được chuyển thành DFD cấp thấp hơn với mức độ hiểu biết sâu hơn trừ khi đạt được mức đặc tả mong muốn.

Biểu đồ cấu trúc

Biểu đồ cấu trúc là biểu đồ bắt nguồn từ Sơ đồ luồng dữ liệu. Nó đại diện cho hệ thống chi tiết hơn DFD. Nó chia nhỏ toàn bộ hệ thống thành các mô-đun chức năng thấp nhất, mô tả các chức năng và chức năng con của từng mô-đun của hệ thống chi tiết hơn DFD.

Biểu đồ cấu trúc thể hiện cấu trúc phân cấp của các mô-đun. Tại mỗi lớp, một nhiệm vụ cụ thể được thực hiện.

Dưới đây là các ký hiệu được sử dụng trong xây dựng biểu đồ kết cấu -

• Module- Nó đại diện cho quá trình hoặc chương trình con hoặc nhiệm vụ. Một mô-đun điều khiển phân nhánh thành nhiều mô-đun con. Mô-đun Thư viện có thể sử dụng lại và không thể sử dụng từ bất kỳ mô-đun nào.
  
• Condition- Nó được thể hiện bằng viên kim cương nhỏ ở cơ sở của mô-đun. Nó mô tả rằng mô-đun điều khiển có thể chọn bất kỳ quy trình phụ nào dựa trên một số điều kiện.
  
• Jump - Một mũi tên được hiển thị trỏ vào bên trong mô-đun để mô tả rằng điều khiển sẽ nhảy vào giữa mô-đun phụ.
  
• Loop- Một mũi tên cong thể hiện vòng lặp trong mô-đun. Tất cả các mô-đun con được bao phủ bởi thực thi lặp lại vòng lặp của mô-đun.
  
• Data flow - Một mũi tên có hướng với vòng tròn trống ở cuối thể hiện luồng dữ liệu.
  
• Control flow - Một mũi tên có hướng với vòng tròn đầy ở cuối thể hiện luồng điều khiển.
  

Sơ đồ HIPO

Sơ đồ HIPO (Hierarchical Input Process Output) là sự kết hợp của hai phương pháp có tổ chức để phân tích hệ thống và cung cấp các phương tiện tài liệu. Mô hình HIPO được IBM phát triển vào năm 1970.

Biểu đồ HIPO thể hiện sự phân cấp của các mô-đun trong hệ thống phần mềm. Nhà phân tích sử dụng sơ đồ HIPO để có được cái nhìn cấp cao về các chức năng của hệ thống. Nó phân rã các chức năng thành các chức năng con theo cách phân cấp. Nó mô tả các chức năng được thực hiện bởi hệ thống.

Sơ đồ HIPO rất tốt cho mục đích tài liệu. Biểu diễn đồ họa của chúng giúp các nhà thiết kế và quản lý dễ dàng có được ý tưởng hình ảnh về cấu trúc hệ thống.

Ngược lại với sơ đồ IPO (Đầu vào quy trình đầu ra), mô tả luồng điều khiển và dữ liệu trong một mô-đun, HIPO không cung cấp bất kỳ thông tin nào về luồng dữ liệu hoặc luồng điều khiển.

Thí dụ

Cả hai phần của sơ đồ HIPO, bản trình bày phân cấp và biểu đồ IPO đều được sử dụng để thiết kế cấu trúc của chương trình phần mềm cũng như tài liệu giống nhau.

Tiếng Anh có cấu trúc

Hầu hết các lập trình viên không biết về bức tranh toàn cảnh của phần mềm nên họ chỉ dựa vào những gì người quản lý yêu cầu họ làm. Ban quản lý phần mềm cấp cao hơn có trách nhiệm cung cấp thông tin chính xác cho các lập trình viên để phát triển mã chính xác nhưng nhanh chóng.

Các dạng phương pháp khác, sử dụng đồ thị hoặc sơ đồ, đôi khi có thể được những người khác nhau giải thích theo cách khác nhau.

Do đó, các nhà phân tích và thiết kế phần mềm đã đưa ra các công cụ như Tiếng Anh có cấu trúc. Nó không có gì khác ngoài mô tả về những gì được yêu cầu để mã và cách mã nó. Tiếng Anh có cấu trúc giúp lập trình viên viết mã không bị lỗi.

Các dạng phương pháp khác, sử dụng đồ thị hoặc sơ đồ, đôi khi có thể được những người khác nhau giải thích theo cách khác nhau. Ở đây, cả tiếng Anh có cấu trúc và Pseudo-Code đều cố gắng giảm thiểu khoảng cách hiểu biết đó.

Structured English is the Nó sử dụng các từ tiếng Anh thuần túy trong mô hình lập trình có cấu trúc. Nó không phải là mã cuối cùng mà là một loại mô tả những gì cần thiết để viết mã và cách viết mã nó. Sau đây là một số mã thông báo của lập trình có cấu trúc.

IF-THEN-ELSE,  
DO-WHILE-UNTIL

Analyst sử dụng cùng một biến và tên dữ liệu, được lưu trữ trong Từ điển dữ liệu, giúp việc viết và hiểu mã trở nên đơn giản hơn nhiều.

Thí dụ

Chúng tôi lấy ví dụ tương tự về Xác thực khách hàng trong môi trường mua sắm trực tuyến. Quy trình xác thực khách hàng này có thể được viết bằng tiếng Anh có cấu trúc như sau:

Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
   Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
   PRINT error message
   Call procedure NEW_CUSTOMER_REQUEST()
ENDIF

Mã được viết bằng tiếng Anh có cấu trúc giống như tiếng Anh nói hàng ngày. Nó không thể được thực hiện trực tiếp như một mã của phần mềm. Tiếng Anh có cấu trúc độc lập với ngôn ngữ lập trình.

Mã giả

Mã giả được viết gần với ngôn ngữ lập trình hơn. Nó có thể được coi là ngôn ngữ lập trình tăng cường, có đầy đủ các nhận xét và mô tả.

Mã giả tránh khai báo biến nhưng chúng được viết bằng một số cấu trúc của ngôn ngữ lập trình thực tế, như C, Fortran, Pascal, v.v.

Mã giả chứa nhiều chi tiết lập trình hơn so với tiếng Anh có cấu trúc. Nó cung cấp một phương pháp để thực hiện tác vụ, như thể một máy tính đang thực thi mã.

Thí dụ

Chương trình in Fibonacci lên đến n số.

void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
   if a greater than b 
   {
      Increase b by a;
      Print b;
   } 
   else if b greater than a
   {
      increase a by b;
      print a;
   }
}

Bảng Quyết định

Bảng Quyết định thể hiện các điều kiện và các hành động tương ứng cần thực hiện để giải quyết chúng, ở định dạng bảng có cấu trúc.

Nó là một công cụ mạnh mẽ để gỡ lỗi và ngăn chặn lỗi. Nó giúp nhóm các thông tin tương tự thành một bảng duy nhất và sau đó bằng cách kết hợp các bảng, nó giúp đưa ra quyết định dễ dàng và thuận tiện.

Tạo bảng quyết định

Để tạo bảng quyết định, nhà phát triển phải làm theo bốn bước cơ bản:

• Xác định tất cả các điều kiện có thể được giải quyết
• Xác định hành động cho tất cả các điều kiện đã xác định
• Tạo các quy tắc tối đa có thể
• Xác định hành động cho từng quy tắc

Bảng Quyết định nên được xác nhận bởi người dùng cuối và gần đây có thể được đơn giản hóa bằng cách loại bỏ các quy tắc và hành động trùng lặp.

Thí dụ

Hãy để chúng tôi lấy một ví dụ đơn giản về vấn đề hàng ngày với kết nối Internet của chúng tôi. Chúng tôi bắt đầu bằng cách xác định tất cả các vấn đề có thể phát sinh khi khởi động internet và các giải pháp khả thi tương ứng của chúng.

Chúng tôi liệt kê tất cả các vấn đề có thể xảy ra trong điều kiện cột và các hành động tiềm năng trong cột Hành động.

	Điều kiện / Hành động	Quy tắc
Điều kiện	Hiển thị đã kết nối	N	N	N	N	Y	Y	Y	Y
	Ping đang hoạt động	N	N	Y	Y	N	N	Y	Y
	Mở trang web	Y	N	Y	N	Y	N	Y	N
Hành động	Kiểm tra cáp mạng	X
	Kiểm tra bộ định tuyến internet	X				X	X	X
	Khởi động lại trình duyệt web							X
	Liên hệ với nhà cung cấp dịch vụ		X	X	X	X	X	X
	Không hành động

Bảng: Bảng Quyết định - Khắc phục sự cố Internet nội bộ

Mô hình mối quan hệ-thực thể

Mô hình Thực thể-Mối quan hệ là một loại mô hình cơ sở dữ liệu dựa trên khái niệm về các thực thể trong thế giới thực và mối quan hệ giữa chúng. Chúng ta có thể ánh xạ kịch bản thế giới thực vào mô hình cơ sở dữ liệu ER. Mô hình ER tạo ra một tập hợp các thực thể với các thuộc tính của chúng, một tập hợp các ràng buộc và mối quan hệ giữa chúng.

Mô hình ER được sử dụng tốt nhất cho thiết kế khái niệm của cơ sở dữ liệu. Mô hình ER có thể được biểu diễn như sau:

• Entity - Một thực thể trong Mô hình ER là một thế giới thực, có một số thuộc tính được gọi là attributes. Mọi thuộc tính được xác định bởi tập giá trị tương ứng của nó, được gọi làdomain.

  Ví dụ, Hãy xem xét một cơ sở dữ liệu trường học. Ở đây, học sinh là một thực thể. Sinh viên có các thuộc tính khác nhau như tên, id, tuổi và lớp, v.v.

• Relationship - Sự liên kết logic giữa các thực thể được gọi là relationship. Các mối quan hệ được ánh xạ với các thực thể theo nhiều cách khác nhau. Các bản đồ ánh xạ xác định số lượng liên kết giữa hai thực thể.

  Ánh xạ các bản đồ:

  • một đối một
  • một đến nhiều
  • nhiều đến một
  • nhiều nhiều

Từ điển dữ liệu

Từ điển dữ liệu là tập hợp thông tin tập trung về dữ liệu. Nó lưu trữ ý nghĩa và nguồn gốc của dữ liệu, mối quan hệ của nó với dữ liệu khác, định dạng dữ liệu để sử dụng, v.v. Từ điển dữ liệu có định nghĩa chặt chẽ về tất cả các tên để tạo điều kiện thuận lợi cho người dùng và nhà thiết kế phần mềm.

Từ điển dữ liệu thường được tham chiếu như kho lưu trữ siêu dữ liệu (dữ liệu về dữ liệu). Nó được tạo ra cùng với mô hình DFD (Data Flow Diagram) của chương trình phần mềm và dự kiến ​​sẽ được cập nhật bất cứ khi nào DFD được thay đổi hoặc cập nhật.

Yêu cầu của Từ điển Dữ liệu

Dữ liệu được tham chiếu qua từ điển dữ liệu trong khi thiết kế và triển khai phần mềm. Từ điển dữ liệu loại bỏ bất kỳ khả năng mơ hồ nào. Nó giúp giữ cho công việc của các lập trình viên và nhà thiết kế được đồng bộ hóa trong khi sử dụng cùng một tham chiếu đối tượng ở mọi nơi trong chương trình.

Từ điển dữ liệu cung cấp một cách tài liệu cho hệ thống cơ sở dữ liệu hoàn chỉnh ở một nơi. Việc xác nhận DFD được thực hiện bằng từ điển dữ liệu.

Nội dung

Từ điển dữ liệu phải chứa thông tin về những điều sau

• Dòng dữ liệu
• Cấu trúc dữ liệu
• Yếu tố dữ liệu
• Kho dữ liệu
• Xử lí dữ liệu

Luồng dữ liệu được mô tả bằng các DFD như đã nghiên cứu trước đó và được biểu diễn dưới dạng đại số như đã mô tả.

=	Gồm
{}	Sự lặp lại
()	Không bắt buộc
+	Và
[/]	Hoặc là

Thí dụ

Địa chỉ = Số nhà + (Đường / Khu vực) + Thành phố + Tiểu bang

ID khóa học = Số khóa học + Tên khóa học + Cấp độ khóa học + Điểm khóa học

Yếu tố dữ liệu

Các phần tử dữ liệu bao gồm Tên và mô tả các Mục Dữ liệu và Kiểm soát, Kho dữ liệu Nội bộ hoặc Bên ngoài, v.v. với các chi tiết sau:

• Tên chính
• Tên phụ (Bí danh)
• Ca sử dụng (Sử dụng như thế nào và ở đâu)
• Mô tả nội dung (Ký hiệu, v.v.)
• Thông tin bổ sung (giá trị đặt trước, ràng buộc, v.v.)

Kho dữ liệu

Nó lưu trữ thông tin từ nơi dữ liệu đi vào hệ thống và tồn tại ngoài hệ thống. Kho dữ liệu có thể bao gồm -

• Files
  • Nội bộ của phần mềm.
  • Bên ngoài phần mềm nhưng trên cùng một máy.
  • Bên ngoài phần mềm và hệ thống, nằm trên các máy khác nhau.
• Tables
  • Quy ước đặt tên
  • Lập chỉ mục tài sản

Xử lí dữ liệu

Có hai loại Xử lý Dữ liệu:

• Logical: Như người dùng thấy nó
• Physical: Như phần mềm thấy nó

Thiết kế phần mềm là một quá trình để khái niệm hóa các yêu cầu phần mềm thành việc triển khai phần mềm. Thiết kế phần mềm lấy các yêu cầu của người dùng làm thách thức và cố gắng tìm ra giải pháp tối ưu. Trong khi phần mềm đang được lên ý tưởng, một kế hoạch được đưa ra nhằm tìm ra thiết kế tốt nhất có thể để thực hiện giải pháp dự định.

Có nhiều biến thể của thiết kế phần mềm. Hãy để chúng tôi nghiên cứu chúng một cách ngắn gọn:

Thiết kế có cấu trúc

Thiết kế có cấu trúc là một khái niệm hóa vấn đề thành một số yếu tố được tổ chức tốt của giải pháp. Về cơ bản nó liên quan đến thiết kế giải pháp. Lợi ích của thiết kế có cấu trúc là, nó giúp hiểu rõ hơn về cách vấn đề đang được giải quyết. Thiết kế có cấu trúc cũng giúp người thiết kế dễ dàng tập trung vào vấn đề một cách chính xác hơn.

Thiết kế có cấu trúc chủ yếu dựa trên chiến lược 'chia để trị' trong đó một vấn đề được chia thành nhiều vấn đề nhỏ và từng vấn đề nhỏ được giải quyết riêng lẻ cho đến khi toàn bộ vấn đề được giải quyết.

Các phần nhỏ của vấn đề được giải quyết bằng các mô-đun giải pháp. Thiết kế có cấu trúc nhấn mạnh rằng các mô-đun này được tổ chức tốt để đạt được giải pháp chính xác.

Các mô-đun này được sắp xếp theo thứ bậc. Họ giao tiếp với nhau. Một thiết kế có cấu trúc tốt luôn tuân theo một số quy tắc để giao tiếp giữa nhiều mô-đun, cụ thể là -

Cohesion - nhóm tất cả các yếu tố liên quan đến chức năng.

Coupling - giao tiếp giữa các mô-đun khác nhau.

Một thiết kế có cấu trúc tốt có sự gắn kết cao và sắp xếp khớp nối thấp.

Thiết kế hướng chức năng

Trong thiết kế hướng chức năng, hệ thống bao gồm nhiều hệ thống con nhỏ hơn được gọi là chức năng. Các chức năng này có khả năng thực hiện nhiệm vụ quan trọng trong hệ thống. Hệ thống được coi là cái nhìn từ trên xuống của tất cả các chức năng.

Thiết kế hướng chức năng kế thừa một số thuộc tính của thiết kế có cấu trúc trong đó phương pháp phân chia và chinh phục được sử dụng.

Cơ chế thiết kế này chia toàn bộ hệ thống thành các chức năng nhỏ hơn, cung cấp các phương tiện trừu tượng hóa bằng cách che giấu thông tin và hoạt động của chúng .. Các mô-đun chức năng này có thể chia sẻ thông tin với nhau bằng cách truyền thông tin và sử dụng thông tin có sẵn trên toàn cầu.

Một đặc điểm khác của các hàm là khi một chương trình gọi một hàm, hàm đó sẽ thay đổi trạng thái của chương trình, điều này đôi khi không được các mô-đun khác chấp nhận. Thiết kế hướng chức năng hoạt động tốt khi trạng thái hệ thống không quan trọng và chương trình / chức năng hoạt động trên đầu vào thay vì trạng thái.

Quá trình thiết kế

• Toàn bộ hệ thống được xem như cách dữ liệu chảy trong hệ thống bằng biểu đồ luồng dữ liệu.
• DFD mô tả cách các chức năng thay đổi dữ liệu và trạng thái của toàn bộ hệ thống.
• Toàn bộ hệ thống được chia nhỏ một cách hợp lý thành các đơn vị nhỏ hơn được gọi là các chức năng trên cơ sở hoạt động của chúng trong hệ thống.
• Mỗi chức năng sau đó được mô tả lớn.

Thiết kế hướng đối tượng

Thiết kế hướng đối tượng hoạt động xung quanh các thực thể và đặc điểm của chúng thay vì các chức năng liên quan đến hệ thống phần mềm. Chiến lược thiết kế này tập trung vào các thực thể và đặc điểm của nó. Toàn bộ khái niệm về giải pháp phần mềm xoay quanh các thực thể tham gia.

Hãy để chúng tôi xem các khái niệm quan trọng của Thiết kế hướng đối tượng:

• Objects - Tất cả các thực thể tham gia vào thiết kế giải pháp được gọi là các đối tượng. Ví dụ, con người, ngân hàng, công ty và khách hàng được coi là đối tượng. Mỗi thực thể đều có một số thuộc tính được liên kết với nó và có một số phương pháp để thực hiện trên các thuộc tính.

• Classes - Một lớp là một mô tả tổng quát của một đối tượng. Một đối tượng là một thể hiện của một lớp. Lớp định nghĩa tất cả các thuộc tính mà một đối tượng có thể có và các phương thức, xác định chức năng của đối tượng.

  Trong thiết kế giải pháp, các thuộc tính được lưu trữ dưới dạng các biến và các chức năng được xác định bằng các phương pháp hoặc thủ tục.

• Encapsulation - Trong OOD, các thuộc tính (biến dữ liệu) và phương thức (hoạt động trên dữ liệu) được gói lại với nhau được gọi là đóng gói. Đóng gói không chỉ gói thông tin quan trọng của một đối tượng lại với nhau mà còn hạn chế quyền truy cập dữ liệu và phương thức từ thế giới bên ngoài. Đây được gọi là ẩn thông tin.
• Inheritance - OOD cho phép các lớp tương tự xếp chồng lên nhau theo cách phân cấp trong đó các lớp thấp hơn hoặc lớp con có thể nhập, triển khai và sử dụng lại các biến và phương thức được phép từ các siêu lớp trực tiếp của chúng. Thuộc tính này của OOD được gọi là tài sản thừa kế. Điều này giúp dễ dàng xác định lớp cụ thể và tạo lớp tổng quát từ những lớp cụ thể.
• Polymorphism - Các ngôn ngữ OOD cung cấp một cơ chế trong đó các phương thức thực hiện các tác vụ tương tự nhưng khác nhau về đối số, có thể được gán cùng một tên. Đây được gọi là tính đa hình, cho phép một giao diện duy nhất thực hiện các tác vụ cho các kiểu khác nhau. Tùy thuộc vào cách hàm được gọi, phần tương ứng của mã sẽ được thực thi.

Quá trình thiết kế

Quá trình thiết kế phần mềm có thể được coi là một loạt các bước được xác định rõ ràng. Mặc dù nó thay đổi theo cách tiếp cận thiết kế (hướng chức năng hoặc hướng đối tượng, nhưng nó có thể có các bước sau:

• Một thiết kế giải pháp được tạo ra từ yêu cầu hoặc sơ đồ trình tự hệ thống và / hoặc hệ thống đã sử dụng trước đó.
• Các đối tượng được xác định và nhóm thành các lớp nhân danh sự giống nhau về đặc điểm thuộc tính.
• Hệ thống phân cấp lớp và mối quan hệ giữa chúng được xác định.
• Khung ứng dụng được xác định.

Phương pháp tiếp cận thiết kế phần mềm

Dưới đây là hai cách tiếp cận chung cho thiết kế phần mềm:

Thiết kế từ trên xuống

Chúng ta biết rằng một hệ thống bao gồm nhiều hơn một hệ thống con và nó chứa một số thành phần. Hơn nữa, các hệ thống con và thành phần này có thể có trên tập hợp các hệ thống con và thành phần và tạo ra cấu trúc phân cấp trong hệ thống.

Thiết kế từ trên xuống lấy toàn bộ hệ thống phần mềm như một thực thể và sau đó phân tách nó để đạt được nhiều hơn một hệ thống con hoặc thành phần dựa trên một số đặc điểm. Mỗi hệ thống con hoặc thành phần sau đó được coi như một hệ thống và được phân rã thêm. Quá trình này tiếp tục chạy cho đến khi đạt được mức thấp nhất của hệ thống trong phân cấp từ trên xuống.

Thiết kế từ trên xuống bắt đầu với một mô hình hệ thống tổng quát và tiếp tục xác định phần cụ thể hơn của nó. Khi tất cả các thành phần được cấu thành, toàn bộ hệ thống sẽ tồn tại.

Thiết kế từ trên xuống phù hợp hơn khi giải pháp phần mềm cần được thiết kế từ đầu và các chi tiết cụ thể chưa được biết đến.

Thiết kế từ dưới lên

Mô hình thiết kế từ dưới lên bắt đầu với hầu hết các thành phần cụ thể và cơ bản. Nó tiến hành soạn các thành phần cấp cao hơn bằng cách sử dụng các thành phần cấp cơ bản hoặc thấp hơn. Nó tiếp tục tạo ra các thành phần cấp cao hơn cho đến khi hệ thống mong muốn không được phát triển thành một thành phần duy nhất. Với mỗi cấp độ cao hơn, số lượng trừu tượng được tăng lên.

Chiến lược từ dưới lên phù hợp hơn khi một hệ thống cần được tạo ra từ một số hệ thống hiện có, nơi các nguyên thủy cơ bản có thể được sử dụng trong hệ thống mới hơn.

Cả hai cách tiếp cận từ trên xuống và từ dưới lên đều không thực tế riêng lẻ. Thay vào đó, sự kết hợp tốt của cả hai được sử dụng.

Giao diện người dùng là giao diện ứng dụng đầu cuối mà người dùng tương tác để sử dụng phần mềm. Người dùng có thể thao tác và điều khiển phần mềm cũng như phần cứng bằng giao diện người dùng. Ngày nay, giao diện người dùng được tìm thấy ở hầu hết mọi nơi có công nghệ kỹ thuật số, ngay từ máy tính, điện thoại di động, ô tô, máy nghe nhạc, máy bay, tàu thủy, v.v.

Giao diện người dùng là một phần của phần mềm và được thiết kế theo cách mà nó dự kiến ​​sẽ cung cấp cho người dùng cái nhìn sâu sắc về phần mềm. Giao diện người dùng cung cấp nền tảng cơ bản cho tương tác giữa người và máy tính.

Giao diện người dùng có thể là đồ họa, dựa trên văn bản, dựa trên âm thanh-video, tùy thuộc vào sự kết hợp phần cứng và phần mềm cơ bản. Giao diện người dùng có thể là phần cứng hoặc phần mềm hoặc kết hợp cả hai.

Phần mềm trở nên phổ biến hơn nếu giao diện người dùng của nó là:

• Attractive
• Đơn giản để sử dụng
• Đáp ứng trong thời gian ngắn
• Rõ ràng để hiểu
• Nhất quán trên tất cả các màn hình giao diện

Giao diện người dùng được chia thành hai loại:

• Giao diện dòng lệnh
• Giao diện đồ họa người dùng

Giao diện dòng lệnh (CLI)

CLI đã là một công cụ tương tác tuyệt vời với máy tính cho đến khi màn hình hiển thị video ra đời. CLI là lựa chọn hàng đầu của nhiều người dùng kỹ thuật và lập trình viên. CLI là giao diện tối thiểu mà một phần mềm có thể cung cấp cho người dùng.

CLI cung cấp một dấu nhắc lệnh, nơi người dùng gõ lệnh và đưa vào hệ thống. Người dùng cần nhớ cú pháp của lệnh và cách sử dụng nó. CLI trước đó không được lập trình để xử lý các lỗi người dùng một cách hiệu quả.

Một lệnh là một tham chiếu dựa trên văn bản cho tập hợp các lệnh, được mong đợi sẽ được thực thi bởi hệ thống. Có những phương thức như macro, script giúp người dùng dễ dàng thao tác.

CLI sử dụng ít tài nguyên máy tính hơn so với GUI.

Yếu tố CLI

Giao diện dòng lệnh dựa trên văn bản có thể có các yếu tố sau:

• Command Prompt- Nó là trình thông báo dựa trên văn bản, hầu hết hiển thị ngữ cảnh mà người dùng đang làm việc. Nó được tạo ra bởi hệ thống phần mềm.

• Cursor- Là một đường ngang nhỏ hoặc một thanh dọc có chiều cao của dòng, để thể hiện vị trí của ký tự trong khi nhập. Con trỏ chủ yếu được tìm thấy ở trạng thái nhấp nháy. Nó di chuyển khi người dùng viết hoặc xóa nội dung nào đó.

• Command- Một lệnh là một lệnh thực thi. Nó có thể có một hoặc nhiều tham số. Đầu ra khi thực hiện lệnh được hiển thị nội tuyến trên màn hình. Khi đầu ra được tạo ra, dấu nhắc lệnh được hiển thị trên dòng tiếp theo.

Giao diện đồ họa người dùng

Giao diện người dùng đồ họa cung cấp phương tiện đồ họa người dùng để tương tác với hệ thống. GUI có thể là sự kết hợp của cả phần cứng và phần mềm. Sử dụng GUI, người dùng diễn giải phần mềm.

Thông thường, GUI tiêu tốn nhiều tài nguyên hơn so với CLI. Với công nghệ tiên tiến, các lập trình viên và nhà thiết kế tạo ra các thiết kế GUI phức tạp hoạt động với hiệu quả, độ chính xác và tốc độ cao hơn.

Phần tử GUI

GUI cung cấp một tập hợp các thành phần để tương tác với phần mềm hoặc phần cứng.

Mỗi thành phần đồ họa cung cấp một cách để làm việc với hệ thống. Hệ thống GUI có các yếu tố sau như:

• Window- Khu vực hiển thị nội dung ứng dụng. Nội dung trong cửa sổ có thể được hiển thị dưới dạng biểu tượng hoặc danh sách, nếu cửa sổ đại diện cho cấu trúc tệp. Người dùng dễ dàng điều hướng trong hệ thống tệp trong cửa sổ khám phá hơn. Windows có thể được thu nhỏ, thay đổi kích thước hoặc tối đa hóa kích thước của màn hình. Chúng có thể được di chuyển đến bất cứ đâu trên màn hình. Một cửa sổ có thể chứa một cửa sổ khác của cùng một ứng dụng, được gọi là cửa sổ con.

• Tabs - Nếu một ứng dụng cho phép thực thi nhiều thể hiện của chính nó, chúng sẽ xuất hiện trên màn hình dưới dạng các cửa sổ riêng biệt. Tabbed Document Interfaceđã mở nhiều tài liệu trong cùng một cửa sổ. Giao diện này cũng giúp xem bảng tùy chọn trong ứng dụng. Tất cả các trình duyệt web hiện đại đều sử dụng tính năng này.

• Menu- Menu là một dãy các lệnh chuẩn, được nhóm lại với nhau và đặt ở vị trí dễ nhìn thấy (thường là trên cùng) bên trong cửa sổ ứng dụng. Menu có thể được lập trình để xuất hiện hoặc ẩn khi nhấp chuột.

• Icon- Một biểu tượng là hình ảnh nhỏ đại diện cho một ứng dụng được liên kết. Khi các biểu tượng này được nhấp hoặc nhấp đúp, cửa sổ ứng dụng sẽ được mở ra. Biểu tượng hiển thị ứng dụng và chương trình được cài đặt trên hệ thống dưới dạng hình ảnh nhỏ.

• Cursor- Các thiết bị tương tác như chuột, touch pad, bút kỹ thuật số được thể hiện trong GUI dưới dạng con trỏ. Con trỏ trên màn hình làm theo hướng dẫn từ phần cứng trong thời gian gần như thực. Con trỏ cũng được đặt tên là con trỏ trong hệ thống GUI. Chúng được sử dụng để chọn menu, cửa sổ và các tính năng ứng dụng khác.

Các thành phần GUI cụ thể của ứng dụng

GUI của một ứng dụng chứa một hoặc nhiều phần tử GUI được liệt kê:

• Application Window - Hầu hết các cửa sổ ứng dụng sử dụng các cấu trúc do hệ điều hành cung cấp nhưng nhiều cửa sổ sử dụng các cửa sổ do khách hàng tự tạo để chứa nội dung của ứng dụng.

• Dialogue Box - Đây là một cửa sổ con chứa thông báo cho người dùng và yêu cầu một số hành động được thực hiện. Ví dụ: Ứng dụng tạo một hộp thoại để nhận được xác nhận từ người dùng để xóa một tệp.

  

• Text-Box - Cung cấp khu vực để người dùng gõ và nhập dữ liệu dạng văn bản.

• Buttons - Chúng bắt chước các nút trong cuộc sống thực và được sử dụng để gửi đầu vào cho phần mềm.

  

• Radio-button- Hiển thị các tùy chọn có sẵn để lựa chọn. Chỉ một trong số tất cả được cung cấp có thể được chọn.

• Check-box- Các chức năng tương tự như list-box. Khi một tùy chọn được chọn, hộp được đánh dấu là đã chọn. Có thể chọn nhiều tùy chọn được biểu thị bằng hộp kiểm.

• List-box - Cung cấp danh sách các mặt hàng có sẵn để lựa chọn. Nhiều hơn một mục có thể được chọn.

  

Các thành phần GUI ấn tượng khác là:

• Sliders
• Combo-box
• Data-grid
• Danh sách thả xuống

Hoạt động thiết kế giao diện người dùng

Có một số hoạt động được thực hiện để thiết kế giao diện người dùng. Quá trình thiết kế và thực hiện GUI giống như SDLC. Bất kỳ mô hình nào cũng có thể được sử dụng để triển khai GUI giữa Mô hình Thác nước, Mô hình lặp lại hoặc Mô hình xoắn ốc.

Một mô hình được sử dụng để thiết kế và phát triển GUI phải đáp ứng các bước cụ thể của GUI.

• GUI Requirement Gathering- Các nhà thiết kế có thể muốn có danh sách tất cả các yêu cầu chức năng và phi chức năng của GUI. Điều này có thể được lấy từ người dùng và giải pháp phần mềm hiện có của họ.

• User Analysis- Nhà thiết kế nghiên cứu xem ai sẽ sử dụng GUI phần mềm. Đối tượng mục tiêu quan trọng khi các chi tiết thiết kế thay đổi theo trình độ kiến ​​thức và năng lực của người dùng. Nếu người dùng hiểu biết về kỹ thuật, GUI nâng cao và phức tạp có thể được kết hợp. Đối với người dùng mới làm quen, có thêm thông tin về cách sử dụng phần mềm.

• Task Analysis- Người thiết kế phải phân tích nhiệm vụ phải thực hiện của giải pháp phần mềm. Ở đây trong GUI, không quan trọng nó sẽ được thực hiện như thế nào. Các nhiệm vụ có thể được trình bày theo cách phân cấp lấy một nhiệm vụ chính và chia nó thành các nhiệm vụ phụ nhỏ hơn. Nhiệm vụ cung cấp các mục tiêu cho bản trình bày GUI. Luồng thông tin giữa các nhiệm vụ con xác định luồng nội dung GUI trong phần mềm.

• GUI Design & implementation- Nhà thiết kế sau khi có thông tin về yêu cầu, nhiệm vụ và môi trường người dùng, thiết kế GUI và thực hiện vào mã và nhúng GUI với phần mềm làm việc hoặc giả trong nền. Sau đó, nó được các nhà phát triển tự kiểm tra.

• Testing- Kiểm tra GUI có thể được thực hiện theo nhiều cách khác nhau. Tổ chức có thể kiểm tra nội bộ, sự tham gia trực tiếp của người dùng và phát hành phiên bản beta là rất ít trong số đó. Thử nghiệm có thể bao gồm khả năng sử dụng, khả năng tương thích, sự chấp nhận của người dùng, v.v.

Công cụ triển khai GUI

Có một số công cụ có sẵn bằng cách sử dụng mà các nhà thiết kế có thể tạo toàn bộ GUI chỉ bằng một cú nhấp chuột. Một số công cụ có thể được nhúng vào môi trường phần mềm (IDE).

Các công cụ triển khai GUI cung cấp một loạt các điều khiển GUI mạnh mẽ. Để tùy chỉnh phần mềm, các nhà thiết kế có thể thay đổi mã cho phù hợp.

Có các phân đoạn khác nhau của các công cụ GUI tùy theo mục đích sử dụng và nền tảng khác nhau của chúng.

Thí dụ

GUI di động, GUI máy tính, GUI màn hình cảm ứng, v.v. Dưới đây là danh sách một số công cụ hữu ích để xây dựng GUI:

• FLUID
• AppInventor (Android)
• LucidChart
• Wavemaker
• Visual Studio

Giao diện người dùng Quy tắc vàng

Các quy tắc sau được đề cập là các quy tắc vàng cho thiết kế GUI, được Shneiderman và Plaisant mô tả trong cuốn sách của họ (Thiết kế giao diện người dùng).

• Strive for consistency- Cần phải có các chuỗi hành động nhất quán trong các tình huống tương tự. Thuật ngữ giống hệt nhau nên được sử dụng trong lời nhắc, menu và màn hình trợ giúp. Các lệnh nhất quán nên được sử dụng xuyên suốt.

• Enable frequent users to use short-cuts- Mong muốn của người dùng giảm số lượng tương tác tăng lên theo tần suất sử dụng. Các từ viết tắt, phím chức năng, lệnh ẩn và các phương tiện macro rất hữu ích đối với người dùng thành thạo.

• Offer informative feedback- Đối với mọi hành động của người vận hành, cần có một số phản hồi của hệ thống. Đối với các hành động thường xuyên và nhỏ, phản ứng phải khiêm tốn, trong khi đối với các hành động không thường xuyên và lớn, phản ứng phải thực chất hơn.

• Design dialog to yield closure- Các chuỗi hành động nên được tổ chức thành các nhóm có phần đầu, phần giữa và phần cuối. Phản hồi mang tính thông tin khi hoàn thành một nhóm hành động mang lại cho người điều hành sự hài lòng về thành tích, cảm giác nhẹ nhõm, tín hiệu để loại bỏ các kế hoạch và lựa chọn dự phòng khỏi tâm trí của họ, và điều này cho thấy rằng con đường phía trước là rõ ràng để chuẩn bị cho việc tiếp theo nhóm hành động.

• Offer simple error handling- Thiết kế hệ thống càng nhiều càng tốt để người dùng không mắc lỗi nghiêm trọng. Nếu một lỗi được tạo ra, hệ thống sẽ có thể phát hiện ra nó và đưa ra các cơ chế đơn giản, dễ hiểu để xử lý lỗi.

• Permit easy reversal of actions- Tính năng này giúp giảm bớt sự lo lắng, vì người dùng biết rằng các lỗi có thể được hoàn tác. Đảo ngược hành động dễ dàng khuyến khích việc khám phá các lựa chọn không quen thuộc. Các đơn vị của khả năng đảo ngược có thể là một hành động đơn lẻ, một mục nhập dữ liệu hoặc một nhóm hành động hoàn chỉnh.

• Support internal locus of control- Người vận hành có kinh nghiệm rất mong muốn cảm giác rằng họ chịu trách nhiệm về hệ thống và rằng hệ thống phản hồi lại các hành động của họ. Thiết kế hệ thống để biến người dùng trở thành người khởi xướng hành động hơn là người phản hồi.

• Reduce short-term memory load - Hạn chế của việc xử lý thông tin của con người trong bộ nhớ ngắn hạn đòi hỏi các màn hình phải được giữ đơn giản, nhiều trang hiển thị được hợp nhất, giảm tần số chuyển động cửa sổ và dành đủ thời gian đào tạo cho các mã, ghi nhớ và chuỗi hành động.

Thuật ngữ phức tạp là viết tắt của trạng thái sự kiện hoặc sự vật, có nhiều liên kết liên kết với nhau và cấu trúc phức tạp cao. Trong lập trình phần mềm, khi thiết kế phần mềm được hiện thực hóa, số lượng các phần tử và mối liên hệ giữa chúng dần dần xuất hiện rất lớn, điều này trở nên quá khó hiểu ngay lập tức.

Khó đánh giá độ phức tạp của thiết kế phần mềm nếu không sử dụng các thước đo và thước đo độ phức tạp. Chúng ta hãy xem ba thước đo độ phức tạp quan trọng của phần mềm.

Các biện pháp phức tạp của Halstead

Năm 1977, ông Maurice Howard Halstead đưa ra các thước đo để đo lường độ phức tạp của phần mềm. Các số liệu của Halstead phụ thuộc vào việc triển khai chương trình thực tế và các phép đo của nó, được tính toán trực tiếp từ các toán tử và toán hạng từ mã nguồn, theo cách tĩnh. Nó cho phép đánh giá thời gian kiểm tra, từ vựng, kích thước, độ khó, lỗi và nỗ lực đối với mã nguồn C / C ++ / Java.

Theo Halstead, “Một chương trình máy tính là sự triển khai của một thuật toán được coi là một tập hợp các mã thông báo có thể được phân loại thành toán tử hoặc toán hạng”. Các chỉ số Halstead cho rằng một chương trình là một chuỗi các toán tử và các toán hạng liên quan của chúng.

Ông xác định các chỉ số khác nhau để kiểm tra độ phức tạp của mô-đun.

Tham số	Ý nghĩa
n1	Số lượng toán tử duy nhất
n2	Số toán hạng duy nhất
N1	Tổng số lần xuất hiện của toán tử
N2	Tổng số lần xuất hiện của các toán hạng

Khi chúng tôi chọn tệp nguồn để xem chi tiết độ phức tạp của nó trong Trình xem số liệu, kết quả sau được nhìn thấy trong Báo cáo chỉ số:

Hệ mét	Ý nghĩa	Biểu diễn toán học
n	Từ vựng	n1 + n2
N	Kích thước	N1 + N2
V	Âm lượng	Độ dài * Từ vựng Log2
D	Khó khăn	(n1 / 2) * (N1 / n2)
E	Nỗ lực	Độ khó * Khối lượng
B	Lỗi	Khối lượng / 3000
T	Thời gian kiểm tra	Thời gian = Nỗ lực / S, trong đó S = 18 giây.

Các phép đo độ phức tạp chu kỳ

Mọi chương trình đều bao gồm các câu lệnh cần thực thi để thực hiện một số nhiệm vụ và các câu lệnh ra quyết định khác quyết định, câu lệnh nào cần được thực hiện. Các cấu trúc ra quyết định này thay đổi dòng chảy của chương trình.

Nếu chúng ta so sánh hai chương trình có cùng kích thước, chương trình nào có nhiều câu lệnh ra quyết định hơn sẽ phức tạp hơn vì việc kiểm soát chương trình nhảy thường xuyên.

McCabe, năm 1976, đề xuất Phép đo độ phức tạp Cyclomatic để định lượng độ phức tạp của một phần mềm nhất định. Đây là mô hình hướng đồ thị dựa trên các cấu trúc ra quyết định của chương trình như if-else, do-while, repeat-Until, switch-case và câu lệnh goto.

Quy trình lập đồ thị điều khiển luồng:

• Phá vỡ chương trình trong các khối nhỏ hơn, được phân định bằng các cấu trúc ra quyết định.
• Tạo các nút đại diện cho mỗi nút này.
• Kết nối các nút như sau:

• Nếu điều khiển có thể phân nhánh từ khối i sang khối j

  Vẽ một vòng cung

• Từ nút thoát đến nút vào

  Vẽ một vòng cung.

Để tính toán độ phức tạp Cyclomatic của một mô-đun chương trình, chúng tôi sử dụng công thức:

V(G) = e – n + 2

Where
e is total number of edges
n is total number of nodes

Độ phức tạp Cyclomatic của mô-đun trên là

e = 10
n = 8
Cyclomatic Complexity = 10 - 8 + 2
                      = 4

Theo P. Jorgensen, Độ phức tạp Cyclomatic của một mô-đun không được vượt quá 10.

Điểm chức năng

Nó được sử dụng rộng rãi để đo kích thước của phần mềm. Điểm chức năng tập trung vào chức năng được cung cấp bởi hệ thống. Các tính năng và chức năng của hệ thống được sử dụng để đo độ phức tạp của phần mềm.

Điểm chức năng tính trên năm tham số, được đặt tên là Đầu vào bên ngoài, Đầu ra bên ngoài, Tệp nội bộ logic, Tệp giao diện bên ngoài và Truy vấn bên ngoài. Để xem xét độ phức tạp của phần mềm, mỗi tham số được phân loại thêm là đơn giản, trung bình hoặc phức tạp.

Hãy cho chúng tôi xem các thông số của hàm điểm:

Đầu vào bên ngoài

Mọi đầu vào duy nhất vào hệ thống, từ bên ngoài, được coi là đầu vào bên ngoài. Tính duy nhất của đầu vào được đo lường, vì không có hai đầu vào nào có định dạng giống nhau. Các đầu vào này có thể là dữ liệu hoặc tham số điều khiển.

• Simple - nếu số lượng đầu vào thấp và ít ảnh hưởng đến các tệp nội bộ hơn

• Complex - nếu số lượng đầu vào cao và ảnh hưởng đến nhiều tệp nội bộ hơn

• Average - ở giữa đơn giản và phức tạp.

Đầu ra bên ngoài

Tất cả các loại đầu ra do hệ thống cung cấp đều được tính vào danh mục này. Đầu ra được coi là duy nhất nếu định dạng đầu ra và / hoặc quá trình xử lý của chúng là duy nhất.

• Simple - nếu số lượng đầu ra thấp

• Complex - nếu số lượng đầu ra cao

• Average - ở giữa đơn giản và phức tạp.

Tệp nội bộ logic

Mọi hệ thống phần mềm đều duy trì các tệp nội bộ để duy trì thông tin chức năng của nó và hoạt động bình thường. Các tệp này chứa dữ liệu logic của hệ thống. Dữ liệu lôgic này có thể chứa cả dữ liệu chức năng và dữ liệu điều khiển.

• Simple - nếu số lượng loại bản ghi thấp

• Complex - nếu số loại bản ghi nhiều

• Average - ở giữa đơn giản và phức tạp.

Tệp giao diện bên ngoài

Hệ thống phần mềm có thể cần chia sẻ tệp của nó với một số phần mềm bên ngoài hoặc nó có thể cần chuyển tệp để xử lý hoặc dưới dạng tham số cho một số chức năng. Tất cả các tệp này được tính là tệp giao diện bên ngoài.

• Simple - nếu số loại bản ghi trong tệp chia sẻ thấp

• Complex - nếu số loại bản ghi trong tệp được chia sẻ nhiều

• Average - ở giữa đơn giản và phức tạp.

Yêu cầu bên ngoài

Yêu cầu là sự kết hợp của đầu vào và đầu ra, trong đó người dùng gửi một số dữ liệu để hỏi về khi đầu vào và hệ thống trả lời người dùng với đầu ra của câu hỏi được xử lý. Độ phức tạp của một truy vấn nhiều hơn Đầu vào Bên ngoài và Đầu ra Bên ngoài. Truy vấn được cho là duy nhất nếu đầu vào và đầu ra của nó là duy nhất về định dạng và dữ liệu.

• Simple - nếu truy vấn cần xử lý thấp và tạo ra một lượng nhỏ dữ liệu đầu ra

• Complex - nếu truy vấn cần quy trình cao và thu được lượng lớn dữ liệu đầu ra

• Average - ở giữa đơn giản và phức tạp.

Mỗi tham số này trong hệ thống được cho trọng số tùy theo lớp và độ phức tạp của chúng. Bảng dưới đây đề cập đến trọng số được cung cấp cho mỗi tham số:

Tham số	Đơn giản	Trung bình cộng	Phức tạp
Đầu vào	3	4	6
Kết quả đầu ra	4	5	7
Yêu cầu	3	4	6
Các tập tin	7	10	15
Giao diện	5	7	10

Bảng trên mang lại các Điểm Chức năng thô. Các điểm chức năng này được điều chỉnh theo độ phức tạp của môi trường. Hệ thống được mô tả bằng cách sử dụng mười bốn đặc điểm khác nhau:

• Truyền thông dữ liệu
• Quá trình đóng góp
• Mục tiêu hoạt động
• Tải cấu hình hoạt động
• Tỷ lệ giao dịch
• Nhập dữ liệu trực tuyến,
• Hiệu quả người dùng cuối
• Cập nhật trực tuyến
• Logic xử lý phức tạp
• Re-usability
• Cài đặt dễ dàng
• Hoạt động dễ dàng
• Nhiều trang web
• Mong muốn tạo điều kiện thay đổi

Các yếu tố đặc điểm này sau đó được xếp hạng từ 0 đến 5, như được đề cập bên dưới:

• Không ảnh hưởng
• Incidental
• Moderate
• Average
• Significant
• Essential

Tất cả các xếp hạng sau đó được tổng hợp là N. Giá trị của N nằm trong khoảng từ 0 đến 70 (14 loại đặc điểm x 5 loại xếp hạng). Nó được sử dụng để tính toán các yếu tố điều chỉnh độ phức tạp (CAF), sử dụng các công thức sau:

CAF = 0.65 + 0.01N

Sau đó,

Delivered Function Points (FP)= CAF x Raw FP

FP này sau đó có thể được sử dụng trong các số liệu khác nhau, chẳng hạn như:

Cost = $ / FP

Quality = Lỗi / FP

Productivity = FP / người-tháng

Trong chương này, chúng ta sẽ nghiên cứu về các phương pháp lập trình, tài liệu và những thách thức trong việc triển khai phần mềm.

Lập trình có cấu trúc

Trong quá trình mã hóa, các dòng mã tiếp tục nhân lên, do đó, kích thước của phần mềm tăng lên. Dần dần, nó trở nên không thể nhớ dòng chương trình. Nếu một người quên cách phần mềm và các chương trình, tệp, thủ tục cơ bản của nó được xây dựng thì sẽ rất khó chia sẻ, gỡ lỗi và sửa đổi chương trình. Giải pháp cho điều này là lập trình có cấu trúc. Nó khuyến khích nhà phát triển sử dụng các chương trình con và vòng lặp thay vì sử dụng các bước nhảy đơn giản trong mã, do đó mang lại sự rõ ràng trong mã và cải thiện hiệu quả của nó. Lập trình có cấu trúc cũng giúp lập trình viên giảm thời gian viết mã và tổ chức mã hợp lý.

Lập trình có cấu trúc cho biết chương trình sẽ được mã hóa như thế nào. Lập trình có cấu trúc sử dụng ba khái niệm chính:

• Top-down analysis- Một phần mềm luôn được tạo ra để thực hiện một số công việc hợp lý. Công việc hợp lý này được gọi là vấn đề trong cách nói của phần mềm. Vì vậy, điều rất quan trọng là chúng ta phải hiểu cách giải quyết vấn đề. Theo phân tích từ trên xuống, vấn đề được chia thành nhiều phần nhỏ mà mỗi phần đều có ý nghĩa nhất định. Mỗi vấn đề được giải quyết riêng lẻ và các bước được nêu rõ ràng về cách giải quyết vấn đề.

• Modular Programming- Trong khi lập trình, mã được chia thành các nhóm lệnh nhỏ hơn. Các nhóm này được gọi là mô-đun, chương trình con hoặc chương trình con. Lập trình mô-đun dựa trên sự hiểu biết về phân tích từ trên xuống. Nó không khuyến khích các bước nhảy bằng cách sử dụng các câu lệnh 'goto' trong chương trình, điều này thường làm cho dòng chương trình không thể theo dõi. Nhảy bị cấm và định dạng mô-đun được khuyến khích trong lập trình có cấu trúc.

• Structured Coding - Tham chiếu với phân tích từ trên xuống, mã hóa có cấu trúc chia các mô-đun thành các đơn vị mã nhỏ hơn theo thứ tự thực thi của chúng. Lập trình có cấu trúc sử dụng cấu trúc điều khiển, điều khiển luồng chương trình, trong khi mã hóa có cấu trúc sử dụng cấu trúc điều khiển để tổ chức các lệnh của nó theo các mẫu có thể xác định được.

Lập trình chức năng

Lập trình hàm là phong cách của ngôn ngữ lập trình, sử dụng các khái niệm về hàm toán học. Một hàm trong toán học phải luôn tạo ra cùng một kết quả khi nhận cùng một đối số. Trong các ngôn ngữ thủ tục, luồng chương trình chạy qua các thủ tục, tức là quyền điều khiển chương trình được chuyển sang thủ tục được gọi. Trong khi luồng điều khiển đang chuyển từ thủ tục này sang thủ tục khác, chương trình sẽ thay đổi trạng thái của nó.

Trong lập trình thủ tục, một thủ tục có thể tạo ra các kết quả khác nhau khi nó được gọi với cùng một đối số, vì bản thân chương trình có thể ở trạng thái khác khi gọi nó. Đây là một thuộc tính cũng như một nhược điểm của lập trình thủ tục, trong đó trình tự hoặc thời gian thực hiện thủ tục trở nên quan trọng.

Lập trình hàm cung cấp các phương tiện tính toán như các hàm toán học, tạo ra kết quả bất kể trạng thái chương trình. Điều này làm cho nó có thể dự đoán hành vi của chương trình.

Lập trình hàm sử dụng các khái niệm sau:

• First class and High-order functions - Các hàm này có khả năng chấp nhận một hàm khác làm đối số hoặc chúng trả về các hàm khác dưới dạng kết quả.

• Pure functions - Các chức năng này không bao gồm các cập nhật phá hoại, nghĩa là chúng không ảnh hưởng đến bất kỳ I / O hoặc bộ nhớ nào và nếu chúng không được sử dụng, chúng có thể dễ dàng được gỡ bỏ mà không cản trở phần còn lại của chương trình.

• Recursion- Đệ quy là một kỹ thuật lập trình trong đó một hàm gọi chính nó và lặp lại mã chương trình trong đó trừ khi một số điều kiện xác định trước phù hợp. Đệ quy là cách tạo vòng lặp trong lập trình hàm.

• Strict evaluation- Là một phương pháp đánh giá biểu thức được truyền cho một hàm như một đối số. Lập trình chức năng có hai loại phương pháp đánh giá, nghiêm ngặt (háo hức) hoặc không nghiêm ngặt (lười biếng). Đánh giá nghiêm ngặt luôn đánh giá biểu thức trước khi gọi hàm. Đánh giá không chặt chẽ không đánh giá biểu hiện trừ khi nó là cần thiết.

• λ-calculus- Hầu hết các ngôn ngữ lập trình hàm sử dụng λ-tích làm hệ thống kiểu của chúng. Các biểu thức λ được thực thi bằng cách đánh giá chúng khi chúng xuất hiện.

Lisp, Scala, Haskell, Erlang và F # là một số ví dụ về ngôn ngữ lập trình chức năng.

Phong cách lập trình

Phong cách lập trình là tập hợp các quy tắc mã hóa được tuân theo bởi tất cả các lập trình viên để viết mã. Khi nhiều lập trình viên làm việc trên cùng một dự án phần mềm, họ thường xuyên phải làm việc với mã chương trình do một số nhà phát triển khác viết. Điều này trở nên tẻ nhạt hoặc đôi khi là không thể, nếu tất cả các nhà phát triển không tuân theo một số phong cách lập trình tiêu chuẩn để viết mã chương trình.

Một phong cách lập trình thích hợp bao gồm sử dụng hàm và tên biến có liên quan đến nhiệm vụ dự định, sử dụng thụt lề được đặt đúng vị trí, mã chú thích để thuận tiện cho người đọc và trình bày tổng thể mã. Điều này làm cho tất cả mọi người đều có thể đọc và hiểu được mã chương trình, do đó giúp gỡ lỗi và giải quyết lỗi dễ dàng hơn. Ngoài ra, phong cách mã hóa phù hợp giúp dễ dàng lập tài liệu và cập nhật.

Nguyên tắc mã hóa

Thực hành về phong cách viết mã khác nhau tùy theo tổ chức, hệ điều hành và ngôn ngữ viết mã.

Các yếu tố mã hóa sau có thể được xác định theo hướng dẫn mã hóa của một tổ chức:

• Naming conventions - Phần này định nghĩa cách đặt tên cho hàm, biến, hằng và biến toàn cục.

• Indenting - Đây là khoảng trống ở đầu dòng, thường là 2-8 khoảng trắng hoặc tab đơn.

• Whitespace - Nó thường bị bỏ qua ở cuối dòng.

• Operators- Nêu các quy tắc viết toán tử, phép gán và toán tử logic. Ví dụ, toán tử gán '=' phải có khoảng trắng trước và sau nó, như trong “x = 2”.

• Control Structures - Các quy tắc viết if-then-else, case-switch, while-Until và cho các câu lệnh luồng điều khiển duy nhất và theo kiểu lồng nhau.

• Line length and wrapping- Xác định bao nhiêu ký tự nên có trong một dòng, chủ yếu là một dòng dài 80 ký tự. Gói xác định cách một dòng nên được quấn, nếu quá dài.

• Functions - Điều này xác định cách các hàm nên được khai báo và gọi, có và không có tham số.

• Variables - Điều này đề cập đến cách các biến của các kiểu dữ liệu khác nhau được khai báo và định nghĩa.

• Comments- Đây là một trong những thành phần mã hóa quan trọng, vì các chú thích trong mã mô tả những gì mã thực sự làm và tất cả các mô tả liên quan khác. Phần này cũng giúp tạo tài liệu trợ giúp cho các nhà phát triển khác.

Tài liệu phần mềm

Tài liệu phần mềm là một phần quan trọng của quy trình phần mềm. Một tài liệu được viết tốt cung cấp một công cụ tuyệt vời và phương tiện lưu trữ thông tin cần thiết để biết về quy trình phần mềm. Tài liệu phần mềm cũng cung cấp thông tin về cách sử dụng sản phẩm.

Một tài liệu được duy trì tốt phải bao gồm các tài liệu sau:

• Requirement documentation - Tài liệu này hoạt động như một công cụ chính cho nhà thiết kế phần mềm, nhà phát triển và nhóm thử nghiệm để thực hiện các nhiệm vụ tương ứng của họ. Tài liệu này chứa tất cả các mô tả chức năng, phi chức năng và hành vi của phần mềm dự định.

  Nguồn của tài liệu này có thể được lưu trữ trước đó dữ liệu về phần mềm, phần mềm đã chạy ở cuối khách hàng, cuộc phỏng vấn của khách hàng, bảng câu hỏi và nghiên cứu. Nói chung, nó được lưu trữ dưới dạng bảng tính hoặc tài liệu xử lý văn bản với nhóm quản lý phần mềm cao cấp.

  Tài liệu này làm nền tảng cho phần mềm được phát triển và chủ yếu được sử dụng trong các giai đoạn xác minh và xác nhận. Hầu hết các trường hợp thử nghiệm được xây dựng trực tiếp từ tài liệu yêu cầu.

• Software Design documentation - Các tài liệu này chứa tất cả các thông tin cần thiết, cần thiết để xây dựng phần mềm. Nó chứa:(a) Kiến trúc phần mềm cấp cao, (b) Chi tiết thiết kế phần mềm, (c) Sơ đồ luồng dữ liệu, (d) Thiết kế cơ sở dữ liệu

  Các tài liệu này hoạt động như một kho lưu trữ cho các nhà phát triển để triển khai phần mềm. Mặc dù các tài liệu này không cung cấp bất kỳ chi tiết nào về cách viết mã chương trình, nhưng chúng cung cấp tất cả các thông tin cần thiết cần thiết cho việc viết mã và triển khai.

• Technical documentation- Các tài liệu này được duy trì bởi các nhà phát triển và lập trình viên thực tế. Nhìn chung, những tài liệu này đại diện cho thông tin về mã. Trong khi viết mã, các lập trình viên cũng đề cập đến mục tiêu của mã, ai đã viết nó, nó sẽ được yêu cầu ở đâu, nó làm gì và nó hoạt động như thế nào, những tài nguyên nào khác mà mã sử dụng, v.v.

  Tài liệu kỹ thuật làm tăng sự hiểu biết giữa các lập trình viên khác nhau làm việc trên cùng một mã. Nó nâng cao khả năng tái sử dụng của mã. Nó giúp cho việc gỡ lỗi trở nên dễ dàng và có thể theo dõi.

  Có nhiều công cụ tự động khác nhau có sẵn và một số đi kèm với ngôn ngữ lập trình. Ví dụ, java có công cụ JavaDoc để tạo tài liệu kỹ thuật về mã.

• User documentation- Tài liệu này khác với tất cả những gì đã giải thích ở trên. Tất cả các tài liệu trước đó được duy trì để cung cấp thông tin về phần mềm và quá trình phát triển của nó. Nhưng tài liệu hướng dẫn sử dụng giải thích cách sản phẩm phần mềm hoạt động và cách sử dụng nó để có được kết quả mong muốn.

  Các tài liệu này có thể bao gồm, quy trình cài đặt phần mềm, hướng dẫn cách thực hiện, hướng dẫn sử dụng, phương pháp gỡ cài đặt và các tài liệu tham khảo đặc biệt để có thêm thông tin như cập nhật giấy phép, v.v.

Thách thức triển khai phần mềm

Có một số thách thức mà nhóm phát triển phải đối mặt trong khi triển khai phần mềm. Một số trong số chúng được đề cập dưới đây:

• Code-reuse- Giao diện lập trình của các ngôn ngữ ngày nay rất phức tạp và được trang bị các chức năng thư viện khổng lồ. Tuy nhiên, để giảm giá thành của sản phẩm cuối cùng, ban quản lý tổ chức muốn sử dụng lại mã, mã đã được tạo trước đó cho một số phần mềm khác. Có những vấn đề lớn mà các lập trình viên phải đối mặt để kiểm tra tính tương thích và quyết định sử dụng lại bao nhiêu mã.

• Version Management- Mỗi khi một phần mềm mới được phát hành cho khách hàng, các nhà phát triển phải duy trì phiên bản và tài liệu liên quan đến cấu hình. Tài liệu này cần phải có độ chính xác cao và có sẵn đúng hạn.

• Target-Host- Chương trình phần mềm đang được phát triển trong tổ chức cần được thiết kế cho các máy chủ ở cuối khách hàng. Nhưng đôi khi, không thể thiết kế một phần mềm hoạt động trên các máy mục tiêu.

Kiểm thử phần mềm là đánh giá phần mềm dựa trên các yêu cầu thu thập từ người dùng và các thông số kỹ thuật của hệ thống. Kiểm thử được tiến hành ở cấp độ pha trong vòng đời phát triển phần mềm hoặc ở cấp độ mô-đun trong mã chương trình. Kiểm thử phần mềm bao gồm Xác thực và Xác minh.

Xác thực phần mềm

Xác thực là quá trình kiểm tra xem phần mềm có đáp ứng các yêu cầu của người dùng hay không. Nó được thực hiện ở cuối SDLC. Nếu phần mềm phù hợp với các yêu cầu mà nó được tạo ra, nó sẽ được xác nhận.

• Việc xác nhận đảm bảo sản phẩm đang được phát triển theo yêu cầu của người dùng.
• Xác thực trả lời câu hỏi - "Chúng tôi có đang phát triển sản phẩm thử tất cả những gì người dùng cần từ phần mềm này không?".
• Xác thực nhấn mạnh vào các yêu cầu của người dùng.

Xác minh phần mềm

Xác minh là quá trình xác nhận xem phần mềm có đáp ứng các yêu cầu kinh doanh hay không và được phát triển tuân theo các đặc điểm kỹ thuật và phương pháp luận phù hợp.

• Việc xác minh đảm bảo sản phẩm đang được phát triển là theo thông số kỹ thuật của thiết kế.
• Việc xác minh trả lời câu hỏi– "Chúng tôi có đang phát triển sản phẩm này bằng cách tuân thủ chặt chẽ tất cả các thông số kỹ thuật của thiết kế không?"
• Xác minh tập trung vào thiết kế và thông số kỹ thuật của hệ thống.

Mục tiêu của bài kiểm tra là -

• Errors- Đây là những sai lầm mã hóa thực tế của các nhà phát triển. Ngoài ra, có sự khác biệt trong đầu ra của phần mềm và đầu ra mong muốn, được coi là một lỗi.

• Fault- Khi lỗi tồn tại lỗi xảy ra. Lỗi, còn được gọi là lỗi, là kết quả của một lỗi có thể khiến hệ thống bị lỗi.

• Failure - thất bại được cho là hệ thống không có khả năng thực hiện nhiệm vụ mong muốn. Lỗi xảy ra khi có lỗi trong hệ thống.

Kiểm tra tự động bằng tay Vs

Kiểm tra có thể được thực hiện thủ công hoặc sử dụng công cụ kiểm tra tự động:

• Manual- Việc kiểm tra này được thực hiện mà không cần sự trợ giúp của các công cụ kiểm tra tự động. Người kiểm thử phần mềm chuẩn bị các trường hợp kiểm thử cho các phần và cấp độ khác nhau của mã, thực hiện các bài kiểm tra và báo cáo kết quả cho người quản lý.

  Kiểm tra thủ công tốn thời gian và tài nguyên. Người kiểm thử cần xác nhận xem có sử dụng đúng các trường hợp kiểm thử hay không. Phần chính của thử nghiệm liên quan đến thử nghiệm thủ công.

• AutomatedThử nghiệm này là một quy trình thử nghiệm được thực hiện với sự hỗ trợ của các công cụ thử nghiệm tự động. Những hạn chế với kiểm tra thủ công có thể được khắc phục bằng cách sử dụng các công cụ kiểm tra tự động.

Một bài kiểm tra cần phải kiểm tra xem một trang web có thể được mở trong Internet Explorer hay không. Điều này có thể dễ dàng thực hiện với thử nghiệm thủ công. Nhưng để kiểm tra xem máy chủ web có thể chịu tải 1 triệu người dùng hay không, thì không thể kiểm tra bằng tay.

Có các công cụ phần mềm và phần cứng giúp người kiểm tra tiến hành kiểm tra tải, kiểm tra căng thẳng, kiểm tra hồi quy.

Thử nghiệm các phương pháp

Thử nghiệm có thể được tiến hành dựa trên hai cách tiếp cận:

• Kiểm tra chức năng
• Thử nghiệm triển khai

Khi chức năng đang được thử nghiệm mà không quan tâm đến việc triển khai thực tế, nó được gọi là thử nghiệm hộp đen. Mặt còn lại được gọi là kiểm thử hộp trắng, nơi không chỉ kiểm tra chức năng mà còn phân tích cách nó được thực hiện.

Các bài kiểm tra hết sức là phương pháp mong muốn tốt nhất để có một bài kiểm tra hoàn hảo. Mọi giá trị có thể có trong phạm vi giá trị đầu vào và đầu ra đều được kiểm tra. Không thể kiểm tra từng giá trị trong kịch bản thế giới thực nếu phạm vi giá trị lớn.

Kiểm tra hộp đen

Nó được thực hiện để kiểm tra chức năng của chương trình. Nó còn được gọi là kiểm tra 'Hành vi'. Người thử nghiệm trong trường hợp này, có một bộ giá trị đầu vào và kết quả mong muốn tương ứng. Khi cung cấp đầu vào, nếu đầu ra khớp với kết quả mong muốn, chương trình được kiểm tra 'ok' và có vấn đề khác.

Trong phương pháp thử nghiệm này, người thử nghiệm không biết thiết kế và cấu trúc của mã, và các kỹ sư thử nghiệm và người dùng cuối tiến hành thử nghiệm này trên phần mềm.

Các kỹ thuật kiểm tra hộp đen:

• Equivalence class- Đầu vào được chia thành các lớp tương tự nhau. Nếu một phần tử của lớp vượt qua bài kiểm tra, thì giả sử rằng tất cả lớp đó đều vượt qua.

• Boundary values- Đầu vào được chia thành các giá trị cuối cao hơn và thấp hơn. Nếu các giá trị này vượt qua bài kiểm tra, thì giả định rằng tất cả các giá trị ở giữa cũng có thể vượt qua.

• Cause-effect graphing- Trong cả hai phương pháp trước, chỉ một giá trị đầu vào tại một thời điểm được kiểm tra. Nguyên nhân (đầu vào) - Hiệu ứng (đầu ra) là một kỹ thuật kiểm tra trong đó sự kết hợp của các giá trị đầu vào được kiểm tra một cách có hệ thống.

• Pair-wise Testing- Hành vi của phần mềm phụ thuộc vào nhiều tham số. Trong thử nghiệm theo cặp, nhiều tham số được thử nghiệm theo cặp cho các giá trị khác nhau của chúng.

• State-based testing- Hệ thống thay đổi trạng thái cung cấp đầu vào. Các hệ thống này được kiểm tra dựa trên trạng thái và đầu vào của chúng.

Thử nghiệm hộp trắng

Nó được tiến hành để kiểm tra chương trình và việc triển khai nó, nhằm cải thiện hiệu quả hoặc cấu trúc mã. Nó còn được gọi là thử nghiệm 'Cấu trúc'.

Trong phương pháp thử nghiệm này, người thử nghiệm đã biết thiết kế và cấu trúc của mã. Lập trình viên của mã tiến hành kiểm tra này trên mã.

Dưới đây là một số kỹ thuật kiểm tra Hộp trắng:

• Control-flow testing- Mục đích của thử nghiệm luồng điều khiển để thiết lập các trường hợp thử nghiệm bao gồm tất cả các câu lệnh và điều kiện nhánh. Các điều kiện rẽ nhánh được kiểm tra cả đúng và sai, để có thể bao quát tất cả các câu lệnh.

• Data-flow testing- Kỹ thuật kiểm tra này nhấn mạnh để bao hàm tất cả các biến dữ liệu có trong chương trình. Nó kiểm tra nơi các biến được khai báo và xác định và nơi chúng được sử dụng hoặc thay đổi.

Kiểm tra mức độ

Bản thân kiểm tra có thể được xác định ở nhiều cấp độ SDLC khác nhau. Quá trình kiểm thử chạy song song với phát triển phần mềm. Trước khi chuyển sang giai đoạn tiếp theo, một giai đoạn được kiểm tra, xác nhận và xác minh.

Kiểm tra riêng được thực hiện chỉ để đảm bảo rằng không có lỗi hoặc vấn đề ẩn nào còn sót lại trong phần mềm. Phần mềm được kiểm tra ở nhiều cấp độ khác nhau -

Kiểm tra đơn vị

Trong khi viết mã, lập trình viên thực hiện một số kiểm tra trên đơn vị chương trình đó để biết nó có lỗi hay không. Thử nghiệm được thực hiện theo phương pháp thử nghiệm hộp trắng. Kiểm thử đơn vị giúp các nhà phát triển quyết định rằng các đơn vị riêng lẻ của chương trình đang hoạt động theo yêu cầu và không có lỗi.

Thử nghiệm hội nhập

Ngay cả khi các đơn vị phần mềm hoạt động tốt riêng lẻ, thì cần phải tìm hiểu xem các đơn vị nếu được tích hợp với nhau cũng sẽ hoạt động mà không có lỗi. Ví dụ, truyền đối số và cập nhật dữ liệu, v.v.

Thử nghiệm hệ thống

Phần mềm được biên dịch dưới dạng sản phẩm và sau đó nó được kiểm tra tổng thể. Điều này có thể được thực hiện bằng cách sử dụng một hoặc nhiều thử nghiệm sau:

• Functionality testing - Kiểm tra tất cả các chức năng của phần mềm theo yêu cầu.

• Performance testing- Thử nghiệm này chứng minh hiệu quả của phần mềm. Nó kiểm tra hiệu quả và thời gian trung bình mà phần mềm thực hiện để thực hiện công việc mong muốn. Kiểm tra hiệu suất được thực hiện bằng phương pháp kiểm tra tải và kiểm tra căng thẳng trong đó phần mềm được đặt dưới mức người dùng và tải dữ liệu cao trong các điều kiện môi trường khác nhau.

• Security & Portability - Các bài kiểm tra này được thực hiện khi phần mềm hoạt động trên nhiều nền tảng khác nhau và được nhiều người truy cập.

Kiểm tra chấp nhận

Khi phần mềm đã sẵn sàng để bàn giao cho khách hàng, nó phải trải qua giai đoạn thử nghiệm cuối cùng, nơi nó được kiểm tra về sự tương tác và phản hồi của người dùng. Điều này rất quan trọng vì ngay cả khi phần mềm phù hợp với tất cả các yêu cầu của người dùng và nếu người dùng không thích cách nó xuất hiện hoặc hoạt động, nó có thể bị từ chối.

• Alpha testing- Đội ngũ lập trình viên tự thực hiện kiểm thử alpha bằng cách sử dụng hệ thống như thể nó đang được sử dụng trong môi trường làm việc. Họ cố gắng tìm hiểu xem người dùng sẽ phản ứng như thế nào với một số hành động trong phần mềm và cách hệ thống sẽ phản ứng với các đầu vào.

• Beta testing- Sau khi phần mềm được kiểm tra nội bộ, phần mềm được bàn giao cho người sử dụng để sử dụng nó trong môi trường sản xuất của họ chỉ nhằm mục đích thử nghiệm. Đây vẫn chưa phải là sản phẩm được giao. Các nhà phát triển hy vọng rằng người dùng ở giai đoạn này sẽ gặp phải các vấn đề nhỏ, đã được bỏ qua để tham dự.

Kiểm tra hồi quy

Bất cứ khi nào một sản phẩm phần mềm được cập nhật với mã, tính năng hoặc chức năng mới, nó sẽ được kiểm tra kỹ lưỡng để phát hiện xem có bất kỳ tác động tiêu cực nào của mã được thêm vào hay không. Đây được gọi là kiểm tra hồi quy.

Tài liệu Kiểm tra

Tài liệu kiểm tra được chuẩn bị ở các giai đoạn khác nhau -

Trước khi thử nghiệm

Thử nghiệm bắt đầu với việc tạo các trường hợp thử nghiệm. Tài liệu sau đây là cần thiết để tham khảo -

• SRS document - Tài liệu Yêu cầu Chức năng

• Test Policy document - Điều này mô tả việc kiểm tra sẽ diễn ra trong bao lâu trước khi phát hành sản phẩm.

• Test Strategy document - Điều này đề cập đến các khía cạnh chi tiết của nhóm kiểm thử, ma trận trách nhiệm và quyền / trách nhiệm của người quản lý kiểm tra và kỹ sư kiểm tra.

• Traceability Matrix document- Đây là tài liệu SDLC, có liên quan đến quy trình thu thập yêu cầu. Khi các yêu cầu mới đến, chúng được thêm vào ma trận này. Các ma trận này giúp người kiểm tra biết được nguồn yêu cầu. Chúng có thể được truy tìm về phía trước và phía sau.

Trong khi được kiểm tra

Các tài liệu sau có thể được yêu cầu khi bắt đầu thử nghiệm và đang được thực hiện:

• Test Case document- Tài liệu này chứa danh sách các thử nghiệm cần phải tiến hành. Nó bao gồm kế hoạch kiểm thử Đơn vị, kế hoạch kiểm tra tích hợp, kế hoạch kiểm tra hệ thống và kế hoạch kiểm tra chấp nhận.

• Test description - Tài liệu này là một mô tả chi tiết về tất cả các trường hợp kiểm thử và các thủ tục để thực thi chúng.

• Test case report - Tài liệu này chứa báo cáo trường hợp thử nghiệm là kết quả của thử nghiệm.

• Test logs - Tài liệu này chứa các bản ghi thử nghiệm cho mọi báo cáo trường hợp thử nghiệm.

Sau khi kiểm tra

Các tài liệu sau có thể được tạo sau khi thử nghiệm:

• Test summary- Bản tóm tắt kiểm tra này là phân tích tập thể của tất cả các báo cáo và nhật ký kiểm tra. Nó tóm tắt và kết luận nếu phần mềm đã sẵn sàng để khởi chạy. Phần mềm được phát hành dưới hệ thống kiểm soát phiên bản nếu nó đã sẵn sàng để khởi chạy.

Kiểm tra so với Kiểm soát Chất lượng, Đảm bảo Chất lượng và Kiểm toán

Chúng ta cần hiểu rằng kiểm thử phần mềm khác với đảm bảo chất lượng phần mềm, kiểm soát chất lượng phần mềm và kiểm toán phần mềm.

• Software quality assurance- Đây là các phương tiện giám sát quá trình phát triển phần mềm, qua đó đảm bảo rằng tất cả các biện pháp được thực hiện theo các tiêu chuẩn của tổ chức. Việc giám sát này được thực hiện để đảm bảo rằng các phương pháp phát triển phần mềm phù hợp đã được tuân thủ.

• Software quality control- Đây là hệ thống duy trì chất lượng của sản phẩm phần mềm. Nó có thể bao gồm các khía cạnh chức năng và phi chức năng của sản phẩm phần mềm, nhằm nâng cao thiện chí của tổ chức. Hệ thống này đảm bảo rằng khách hàng đang nhận được sản phẩm chất lượng theo yêu cầu của họ và sản phẩm được chứng nhận là 'phù hợp để sử dụng'.

• Software audit- Đây là đánh giá về thủ tục được tổ chức sử dụng để phát triển phần mềm. Một nhóm kiểm toán viên, độc lập với nhóm phát triển kiểm tra quy trình phần mềm, thủ tục, các yêu cầu và các khía cạnh khác của SDLC. Mục đích của kiểm toán phần mềm là kiểm tra phần mềm đó và quá trình phát triển của nó, cả hai đều tuân theo các tiêu chuẩn, quy tắc và quy định.

Bảo trì phần mềm được chấp nhận rộng rãi một phần của SDLC bây giờ một ngày. Nó là viết tắt của tất cả các sửa đổi và cập nhật được thực hiện sau khi phân phối sản phẩm phần mềm. Có một số lý do, tại sao cần phải sửa đổi, một số trong số đó được đề cập ngắn gọn dưới đây:

• Market Conditions - Các chính sách thay đổi theo thời gian, chẳng hạn như thuế và các ràng buộc mới được áp dụng như, cách duy trì sổ sách kế toán, có thể kích hoạt nhu cầu sửa đổi.

• Client Requirements - Theo thời gian, khách hàng có thể yêu cầu các tính năng hoặc chức năng mới trong phần mềm.

• Host Modifications - Nếu bất kỳ phần cứng và / hoặc nền tảng nào (chẳng hạn như hệ điều hành) của máy chủ đích thay đổi, thì cần thay đổi phần mềm để giữ khả năng thích ứng.

• Organization Changes - Nếu có bất kỳ sự thay đổi cấp độ nghiệp vụ nào ở phía khách hàng, chẳng hạn như giảm sức mạnh tổ chức, mua lại công ty khác, tổ chức mạo hiểm kinh doanh mới, có thể phát sinh nhu cầu sửa đổi trong phần mềm gốc.

Các loại bảo trì

Trong vòng đời phần mềm, loại bảo trì có thể khác nhau tùy theo bản chất của nó. Nó có thể chỉ là một nhiệm vụ bảo trì định kỳ khi một số lỗi được phát hiện bởi một số người dùng hoặc bản thân nó có thể là một sự kiện lớn dựa trên quy mô hoặc tính chất bảo trì. Sau đây là một số loại bảo trì dựa trên đặc điểm của chúng:

• Corrective Maintenance - Điều này bao gồm các sửa đổi và cập nhật được thực hiện để sửa chữa hoặc khắc phục sự cố do người dùng phát hiện hoặc kết luận bởi báo cáo lỗi của người dùng.

• Adaptive Maintenance - Điều này bao gồm các sửa đổi và cập nhật được áp dụng để giữ cho sản phẩm phần mềm luôn cập nhật và phù hợp với thế giới công nghệ và môi trường kinh doanh luôn thay đổi.

• Perfective Maintenance- Điều này bao gồm các sửa đổi và cập nhật được thực hiện để giữ cho phần mềm có thể sử dụng được trong thời gian dài. Nó bao gồm các tính năng mới, các yêu cầu mới của người dùng để tinh chỉnh phần mềm và cải thiện độ tin cậy và hiệu suất của nó.

• Preventive Maintenance- Điều này bao gồm các sửa đổi và cập nhật để ngăn ngừa các sự cố trong tương lai của phần mềm. Nó nhằm mục đích giải quyết các vấn đề, hiện không đáng kể nhưng có thể gây ra các vấn đề nghiêm trọng trong tương lai.

Chi phí bảo trì

Các báo cáo cho thấy chi phí bảo trì cao. Một nghiên cứu về ước tính bảo trì phần mềm cho thấy chi phí bảo trì cao tới 67% chi phí của toàn bộ chu trình quy trình phần mềm.

Trung bình, chi phí bảo trì phần mềm là hơn 50% của tất cả các giai đoạn SDLC. Có nhiều yếu tố khác nhau khiến chi phí bảo trì tăng cao, chẳng hạn như:

Các yếu tố trong thế giới thực ảnh hưởng đến Chi phí bảo trì

• Tuổi tiêu chuẩn của bất kỳ phần mềm nào được coi là tối đa từ 10 đến 15 năm.
• Các phần mềm cũ hơn, vốn có nghĩa là hoạt động trên các máy chậm với ít bộ nhớ và dung lượng lưu trữ hơn không thể tự thách thức các phần mềm nâng cao mới ra mắt trên phần cứng hiện đại.
• Khi công nghệ tiến bộ, việc duy trì phần mềm cũ trở nên tốn kém.
• Hầu hết các kỹ sư bảo trì là người mới và sử dụng phương pháp thử và sai để khắc phục sự cố.
• Thông thường, những thay đổi được thực hiện có thể dễ dàng làm hỏng cấu trúc ban đầu của phần mềm, gây khó khăn cho bất kỳ thay đổi nào sau đó.
• Các thay đổi thường không được ghi lại có thể gây ra nhiều xung đột hơn trong tương lai.

Các yếu tố cuối phần mềm ảnh hưởng đến Chi phí bảo trì

• Cấu trúc của chương trình phần mềm
• Ngôn ngữ lập trình
• Phụ thuộc vào môi trường bên ngoài
• Độ tin cậy và tính sẵn sàng của nhân viên

Hoạt động bảo trì

IEEE cung cấp một khuôn khổ cho các hoạt động quy trình bảo trì tuần tự. Nó có thể được sử dụng theo cách lặp đi lặp lại và có thể được mở rộng để có thể bao gồm các mục và quy trình tùy chỉnh.

Các hoạt động này song hành với từng giai đoạn sau:

• Identification & Tracing- Nó liên quan đến các hoạt động liên quan đến việc xác định yêu cầu sửa đổi hoặc bảo trì. Nó được tạo ra bởi người dùng hoặc hệ thống có thể tự báo cáo thông qua nhật ký hoặc thông báo lỗi. Ở đây, kiểu bảo trì cũng được phân loại.

• Analysis- Việc sửa đổi được phân tích về tác động của nó đối với hệ thống bao gồm các tác động về an toàn và bảo mật. Nếu tác động có thể xảy ra là nghiêm trọng, giải pháp thay thế sẽ được tìm kiếm. Một tập hợp các sửa đổi cần thiết sau đó được cụ thể hóa thành các thông số kỹ thuật yêu cầu. Chi phí sửa đổi / bảo trì được phân tích và kết luận ước tính.

• Design- Các mô-đun mới, cần được thay thế hoặc sửa đổi, được thiết kế dựa trên các thông số kỹ thuật yêu cầu đã đặt ra ở giai đoạn trước. Các trường hợp thử nghiệm được tạo để xác nhận và xác minh.

• Implementation - Các mô-đun mới được mã hóa với sự trợ giúp của thiết kế có cấu trúc được tạo ra trong bước thiết kế. Mỗi lập trình viên phải thực hiện kiểm thử đơn vị song song.

• System Testing- Kiểm thử tích hợp được thực hiện giữa các mô-đun mới được tạo. Thử nghiệm tích hợp cũng được thực hiện giữa các mô-đun mới và hệ thống. Cuối cùng hệ thống được kiểm tra tổng thể, tuân theo các quy trình kiểm tra hồi quy.

• Acceptance Testing- Sau khi chạy thử nội bộ hệ thống được nghiệm thu với sự trợ giúp của người dùng. Nếu ở trạng thái này, người dùng khiếu nại một số vấn đề mà họ được giải quyết hoặc lưu ý để giải quyết trong lần lặp tiếp theo.

• Delivery- Sau khi kiểm tra nghiệm thu, hệ thống được triển khai trên toàn tổ chức bằng gói cập nhật nhỏ hoặc cài đặt mới hệ thống. Thử nghiệm cuối cùng diễn ra ở cuối máy khách sau khi phần mềm được giao.

  Cơ sở đào tạo được cung cấp nếu cần thiết, ngoài bản cứng của hướng dẫn sử dụng.

• Maintenance management- Quản lý cấu hình là một phần thiết yếu của bảo trì hệ thống. Nó được hỗ trợ với các công cụ kiểm soát phiên bản để kiểm soát các phiên bản, quản lý bán phiên bản hoặc vá lỗi.

Tái thiết kế phần mềm

Khi chúng ta cần cập nhật phần mềm để phù hợp với thị trường hiện tại, mà không ảnh hưởng đến chức năng của nó, nó được gọi là tái thiết kế phần mềm. Đó là một quá trình kỹ lưỡng trong đó thiết kế của phần mềm được thay đổi và các chương trình được viết lại.

Phần mềm cũ không thể tiếp tục điều chỉnh với công nghệ mới nhất hiện có trên thị trường. Khi phần cứng trở nên lỗi thời, việc cập nhật phần mềm trở thành một vấn đề đau đầu. Ngay cả khi phần mềm cũ đi theo thời gian, chức năng của nó vẫn không.

Ví dụ, ban đầu Unix được phát triển bằng hợp ngữ. Khi ngôn ngữ C ra đời, Unix đã được thiết kế lại bằng C, vì làm việc trong hợp ngữ rất khó.

Ngoài điều này, đôi khi các lập trình viên nhận thấy rằng một số phần mềm cần được bảo trì nhiều hơn những phần khác và chúng cũng cần được tái thiết kế.

Tái thiết kế quy trình

• Decidenhững gì để thiết kế lại. Nó là toàn bộ phần mềm hay một phần của nó?
• Perform Reverse Engineering, để có được thông số kỹ thuật của phần mềm hiện có.
• Restructure Programnếu được yêu cầu. Ví dụ, thay đổi chương trình hướng chức năng thành chương trình hướng đối tượng.
• Re-structure data theo yêu cầu.
• Apply Forward engineering khái niệm để có được phần mềm được thiết kế lại.

Có một số thuật ngữ quan trọng được sử dụng trong kỹ thuật lại phần mềm

Kỹ thuật đảo ngược

Nó là một quá trình để đạt được đặc tả hệ thống bằng cách phân tích kỹ lưỡng, hiểu rõ hệ thống hiện có. Quá trình này có thể được xem là mô hình SDLC đảo ngược, tức là chúng ta cố gắng đạt được mức trừu tượng cao hơn bằng cách phân tích các mức trừu tượng thấp hơn.

Một hệ thống hiện có là thiết kế đã được triển khai trước đó, mà chúng ta không biết gì về nó. Sau đó, các nhà thiết kế thực hiện kỹ thuật đảo ngược bằng cách xem mã và cố gắng lấy thiết kế. Với thiết kế trong tay, họ cố gắng kết luận các thông số kỹ thuật. Do đó, đi ngược lại từ mã đến đặc tả hệ thống.

Tái cấu trúc chương trình

Nó là một quá trình tái cấu trúc và xây dựng lại phần mềm hiện có. Tất cả chỉ là sắp xếp lại mã nguồn, trong cùng một ngôn ngữ lập trình hoặc từ một ngôn ngữ lập trình này sang một ngôn ngữ lập trình khác. Tái cấu trúc có thể có tái cấu trúc mã nguồn và tái cấu trúc dữ liệu hoặc cả hai.

Việc tái cấu trúc không ảnh hưởng đến chức năng của phần mềm nhưng nâng cao độ tin cậy và khả năng bảo trì. Các thành phần chương trình thường gây ra lỗi có thể được thay đổi hoặc cập nhật bằng cách cấu trúc lại.

Sự tin cậy của phần mềm trên nền tảng phần cứng lỗi thời có thể được loại bỏ thông qua tái cấu trúc.

Kỹ thuật chuyển tiếp

Kỹ thuật chuyển tiếp là một quá trình thu được phần mềm mong muốn từ các thông số kỹ thuật trong tay đã được đưa xuống bằng kỹ thuật đảo ngược. Nó giả định rằng đã có một số kỹ thuật phần mềm đã được thực hiện trong quá khứ.

Kỹ thuật chuyển tiếp cũng giống như quy trình kỹ thuật phần mềm chỉ có một điểm khác biệt - nó luôn được thực hiện sau quá trình thiết kế ngược.

Khả năng tái sử dụng thành phần

Thành phần là một phần của mã chương trình phần mềm, thực thi một nhiệm vụ độc lập trong hệ thống. Nó có thể là một mô-đun nhỏ hoặc chính hệ thống con.

Thí dụ

Các thủ tục đăng nhập được sử dụng trên web có thể được coi là thành phần, hệ thống in trong phần mềm có thể được xem như một thành phần của phần mềm.

Các thành phần có tính gắn kết cao về chức năng và tỷ lệ ghép nối thấp hơn, tức là chúng hoạt động độc lập và có thể thực hiện các nhiệm vụ mà không phụ thuộc vào các mô-đun khác.

Trong OOP, các đối tượng được thiết kế rất cụ thể để họ quan tâm và có ít cơ hội được sử dụng trong một số phần mềm khác.

Trong lập trình mô-đun, các mô-đun được mã hóa để thực hiện các tác vụ cụ thể có thể được sử dụng trên nhiều chương trình phần mềm khác.

Có một ngành dọc hoàn toàn mới, dựa trên việc tái sử dụng thành phần phần mềm và được gọi là Kỹ thuật phần mềm dựa trên thành phần (CBSE).

Tái sử dụng có thể được thực hiện ở nhiều cấp độ khác nhau

• Application level - Nơi toàn bộ ứng dụng được sử dụng như hệ thống con của phần mềm mới.

• Component level - Hệ thống con của một ứng dụng được sử dụng ở đâu.

• Modules level - Nơi các mô-đun chức năng được sử dụng lại.

  Các thành phần phần mềm cung cấp các giao diện, có thể được sử dụng để thiết lập giao tiếp giữa các thành phần khác nhau.

Quy trình tái sử dụng

Có thể áp dụng hai loại phương pháp: hoặc bằng cách giữ nguyên các yêu cầu và điều chỉnh các thành phần hoặc bằng cách giữ cho các thành phần giống nhau và sửa đổi các yêu cầu.

• Requirement Specification - Các yêu cầu chức năng và phi chức năng được chỉ định, mà sản phẩm phần mềm phải tuân theo, với sự trợ giúp của hệ thống hiện có, đầu vào của người dùng hoặc cả hai.

• Design- Đây cũng là một bước quy trình SDLC tiêu chuẩn, trong đó các yêu cầu được xác định theo cách nói của phần mềm. Kiến trúc cơ bản của toàn bộ hệ thống và các hệ thống con của nó được tạo ra.

• Specify Components - Bằng cách nghiên cứu thiết kế phần mềm, các nhà thiết kế tách toàn bộ hệ thống thành các thành phần nhỏ hơn hoặc hệ thống con. Một thiết kế phần mềm hoàn chỉnh biến thành một tập hợp các thành phần khổng lồ hoạt động cùng nhau.

• Search Suitable Components - Kho lưu trữ thành phần phần mềm được các nhà thiết kế tham khảo để tìm kiếm thành phần phù hợp, trên cơ sở chức năng và các yêu cầu phần mềm dự kiến.

• Incorporate Components - Tất cả các thành phần phù hợp được đóng gói với nhau để định hình chúng như một phần mềm hoàn chỉnh.

CASE là viết tắt của Cbên ngoài Aided Software Engineering. Nó có nghĩa là phát triển và bảo trì các dự án phần mềm với sự trợ giúp của các công cụ phần mềm tự động khác nhau.

Công cụ CASE

Các công cụ CASE là một tập hợp các chương trình ứng dụng phần mềm, được sử dụng để tự động hóa các hoạt động SDLC. Các công cụ CASE được sử dụng bởi các nhà quản lý dự án phần mềm, nhà phân tích và kỹ sư để phát triển hệ thống phần mềm.

Có một số công cụ CASE có sẵn để đơn giản hóa các giai đoạn khác nhau của Vòng đời phát triển phần mềm như công cụ phân tích, công cụ thiết kế, công cụ quản lý dự án, công cụ quản lý cơ sở dữ liệu, công cụ tài liệu.

Việc sử dụng các công cụ CASE đẩy nhanh quá trình phát triển dự án để tạo ra kết quả mong muốn và giúp phát hiện ra các sai sót trước khi chuyển sang giai đoạn tiếp theo trong phát triển phần mềm.

Các thành phần của CASE Tools

Các công cụ CASE có thể được chia thành các phần sau dựa trên việc sử dụng chúng ở một giai đoạn SDLC cụ thể:

• Central Repository- Các công cụ CASE yêu cầu một kho lưu trữ trung tâm, có thể dùng như một nguồn thông tin chung, tích hợp và nhất quán. Kho lưu trữ trung tâm là nơi lưu trữ tập trung, nơi lưu trữ thông số kỹ thuật sản phẩm, tài liệu yêu cầu, báo cáo và sơ đồ liên quan, thông tin hữu ích khác về quản lý. Kho lưu trữ trung tâm cũng đóng vai trò như từ điển dữ liệu.

  

• Upper Case Tools - Các công cụ CASE trên được sử dụng trong các giai đoạn lập kế hoạch, phân tích và thiết kế SDLC.

• Lower Case Tools - Các công cụ CASE thấp hơn được sử dụng trong việc thực hiện, thử nghiệm và bảo trì.

• Integrated Case Tools - Các công cụ CASE tích hợp rất hữu ích trong tất cả các giai đoạn của SDLC, từ thu thập Yêu cầu đến Kiểm tra và lập tài liệu.

Các công cụ CASE có thể được nhóm lại với nhau nếu chúng có chức năng, hoạt động quy trình tương tự và khả năng tích hợp với các công cụ khác.

Phạm vi của Công cụ tình huống

Phạm vi của các công cụ CASE xuyên suốt SDLC.

Các loại công cụ trường hợp

Bây giờ chúng ta đi sơ qua các công cụ CASE khác nhau

Công cụ sơ đồ

Các công cụ này được sử dụng để biểu diễn các thành phần hệ thống, dữ liệu và luồng điều khiển giữa các thành phần phần mềm khác nhau và cấu trúc hệ thống dưới dạng đồ họa. Ví dụ: công cụ Flow Chart Maker để tạo các lưu đồ hiện đại.

Công cụ tạo mô hình quy trình

Mô hình hóa quy trình là phương pháp tạo mô hình quy trình phần mềm, được sử dụng để phát triển phần mềm. Các công cụ mô hình hóa quy trình giúp người quản lý chọn một mô hình quy trình hoặc sửa đổi mô hình đó theo yêu cầu của sản phẩm phần mềm. Ví dụ, EPF Composer

Công cụ quản lý dự án

Những công cụ này được sử dụng để lập kế hoạch dự án, ước tính chi phí và nỗ lực, lập kế hoạch dự án và lập kế hoạch nguồn lực. Người quản lý phải tuân thủ nghiêm ngặt việc thực hiện dự án với mọi bước được đề cập trong quản lý dự án phần mềm. Các công cụ quản lý dự án giúp lưu trữ và chia sẻ thông tin dự án trong thời gian thực trong toàn bộ tổ chức. Ví dụ, Creative Pro Office, Trac Project, Basecamp.

Công cụ tài liệu

Tài liệu trong một dự án phần mềm bắt đầu trước quá trình phần mềm, xuyên suốt tất cả các giai đoạn của SDLC và sau khi hoàn thành dự án.

Công cụ tài liệu tạo tài liệu cho người dùng kỹ thuật và người dùng cuối. Người dùng kỹ thuật chủ yếu là các chuyên gia nội bộ của nhóm phát triển, những người tham khảo hướng dẫn sử dụng hệ thống, hướng dẫn tham khảo, hướng dẫn đào tạo, hướng dẫn cài đặt, v.v. Ví dụ: Doxygen, DrExplain, Adobe RoboHelp để làm tài liệu.

Công cụ phân tích

Các công cụ này giúp thu thập các yêu cầu, tự động kiểm tra xem có bất kỳ sự không nhất quán, không chính xác nào trong sơ đồ, sự dư thừa dữ liệu hoặc thiếu sót sai sót hay không. Ví dụ: Chấp nhận 360, Đồng hành, Hoàn thành trường hợp để phân tích yêu cầu, Nhà phân tích hiển thị để phân tích tổng thể.

Công cụ thiết kế

Các công cụ này giúp các nhà thiết kế phần mềm thiết kế cấu trúc khối của phần mềm, cấu trúc này có thể được chia nhỏ hơn nữa trong các mô-đun nhỏ hơn bằng cách sử dụng các kỹ thuật sàng lọc. Các công cụ này cung cấp thông tin chi tiết về từng mô-đun và kết nối giữa các mô-đun. Ví dụ: Thiết kế phần mềm hoạt hình

Công cụ quản lý cấu hình

Một phiên bản phần mềm được phát hành dưới một phiên bản. Công cụ quản lý cấu hình xử lý -

• Quản lý phiên bản và sửa đổi
• Quản lý cấu hình cơ sở
• Thay đổi quản lý kiểm soát

Các công cụ CASE trợ giúp trong việc này bằng cách tự động theo dõi, quản lý phiên bản và quản lý phát hành. Ví dụ, Fossil, Git, Accu REV.

Thay đổi công cụ kiểm soát

Các công cụ này được coi là một phần của các công cụ quản lý cấu hình. Họ xử lý các thay đổi được thực hiện đối với phần mềm sau khi đường cơ sở của nó được sửa hoặc khi phần mềm được phát hành lần đầu tiên. Các công cụ CASE tự động hóa theo dõi thay đổi, quản lý tệp, quản lý mã và hơn thế nữa. Nó cũng giúp thực thi chính sách thay đổi của tổ chức.

Công cụ lập trình

Các công cụ này bao gồm các môi trường lập trình như IDE (Môi trường phát triển tích hợp), thư viện mô-đun tích hợp sẵn và các công cụ mô phỏng. Những công cụ này hỗ trợ toàn diện trong việc xây dựng sản phẩm phần mềm và bao gồm các tính năng để mô phỏng và thử nghiệm. Ví dụ, Cscope để tìm kiếm mã trong C, Eclipse.

Công cụ tạo mẫu

Nguyên mẫu phần mềm là phiên bản mô phỏng của sản phẩm phần mềm dự định. Nguyên mẫu cung cấp cái nhìn và cảm nhận ban đầu về sản phẩm và mô phỏng một số khía cạnh của sản phẩm thực tế.

Các công cụ tạo mẫu CASE về cơ bản đi kèm với các thư viện đồ họa. Họ có thể tạo thiết kế và giao diện người dùng độc lập với phần cứng. Những công cụ này giúp chúng tôi xây dựng các nguyên mẫu nhanh chóng dựa trên thông tin hiện có. Ngoài ra, họ cung cấp mô phỏng nguyên mẫu phần mềm. Ví dụ, nhà soạn nhạc nguyên mẫu của Serena, Mockup Builder.

Công cụ phát triển web

Những công cụ này hỗ trợ thiết kế các trang web với tất cả các yếu tố liên minh như biểu mẫu, văn bản, tập lệnh, đồ họa, v.v. Các công cụ web cũng cung cấp bản xem trước trực tiếp về những gì đang được phát triển và nó sẽ trông như thế nào sau khi hoàn thành. Ví dụ, Fontello, Adobe Edge Kiểm tra, Foundation 3, Dấu ngoặc.

Công cụ đảm bảo chất lượng

Đảm bảo chất lượng trong một tổ chức phần mềm là giám sát quá trình kỹ thuật và các phương pháp được áp dụng để phát triển sản phẩm phần mềm nhằm đảm bảo sự phù hợp của chất lượng theo các tiêu chuẩn của tổ chức. Các công cụ QA bao gồm các công cụ kiểm soát cấu hình và thay đổi và các công cụ kiểm tra phần mềm. Ví dụ: SoapTest, AppsWatch, JMeter.

Công cụ bảo trì

Bảo trì phần mềm bao gồm các sửa đổi trong sản phẩm phần mềm sau khi nó được chuyển giao. Kỹ thuật ghi nhật ký và báo cáo lỗi tự động, tạo phiếu lỗi tự động và nguyên nhân gốc rễ Phân tích là một vài công cụ CASE, giúp tổ chức phần mềm trong giai đoạn bảo trì SDLC. Ví dụ: Bugzilla để theo dõi lỗi, Trung tâm Chất lượng HP.