Quy trình phát triển phần mềm mà BEIT đã sử dụng để xây dựng hơn 200 sản phẩm

Trong phát triển sản phẩm phần mềm, bạn không bao giờ hành động theo linh cảm — ít nhất là trừ khi bạn đang lên kế hoạch kinh doanh tự sát. Luôn có một kế hoạch từng bước mà bạn tuân theo để chuyển từ giai đoạn này sang giai đoạn khác, đảm bảo rằng bạn không trượt khi tiến hành từ một ý tưởng đến một bản giới thiệu. Kế hoạch này làm cơ sở cho quá trình phát triển phần mềm hoàn chỉnh. Mặc dù nó có thể khác nhau giữa các nhà cung cấp, nhưng điều cần thiết là phải sắp xếp mọi thứ theo thứ tự khi bắt đầu một dự án mới.

Bài viết này là một cái nhìn tổng quan sâu sắc về quy trình phát triển phần mềm mà chúng tôi sử dụng tại BEIT  – một công ty phát triển phần mềm với 8 năm kinh nghiệm. Nó bao gồm các bước chúng tôi thực hiện, các nhóm liên quan và mọi thứ bạn phải biết để đạt được hiệu quả với dự án của mình.

Quy trình của chúng tôi bao gồm chín bước phát triển phần mềm, được mài dũa để hoàn thiện bằng cách tuân theo chúng để tạo ra hơn 200 sản phẩm. Vui lòng khai thác chúng như hướng dẫn từ A đến Z của bạn.

Bước 1. Đánh giá mức độ sẵn sàng

Bạn có thể có nhiều câu hỏi hơn là câu trả lời khi lập kế hoạch cho một dự án mới. Sẽ tốt nếu bạn chỉ biết về những thứ kỹ thuật (ví dụ: các mẫu kiến ​​trúc). Bạn có thể nhận được lời khuyên từ chuyên gia về vấn đề đó khi thuê một nhóm phát triển phần mềm từ xa và chuyển sang giai đoạn tiếp theo.

Điều có thể gây ra lo lắng là khi bạn không biết làm thế nào để đạt được sự phù hợp với thị trường sản phẩm hoặc nếu bạn đang bước vào một thị trường ngách không xác định với một chiến lược off-the-cuff. Đây có thể là dấu hiệu bạn chưa sẵn sàng tham gia vào quá trình phát triển sản phẩm phần mềm.

Dưới đây là ba điều quyết định bạn đã sẵn sàng hay chưa:

• Thông số kỹ thuật của sản phẩm . Bạn có một ý tưởng tuyệt vời trong đầu là một khởi đầu tốt, nhưng nó chỉ còn dang dở khi chưa có bảng thông số kỹ thuật sản phẩm hoàn chỉnh. Dành thời gian để xác định các yêu cầu, khái niệm kinh doanh, chức năng sản phẩm và giá trị của bạn. Thông số kỹ thuật của bạn cần càng cụ thể càng tốt để cung cấp cho dự án của bạn một cấu trúc mà không cần phỏng đoán.
• Chuyên môn miền . Kiến thức chuyên môn về miền là chìa khóa để đạt được sự phù hợp của sản phẩm-giải pháp, đó là lý do tại sao nó là một yếu tố không thể thiếu của bất kỳ dự án nào có Liên quan. Bạn dựa trên đó để tạo ra thứ mà đối tượng mục tiêu của bạn cần, không chỉ là một phiên bản phần mềm khác của flotsam và jetsam.
• Kinh nghiệm có liên quan . Biết sâu về vòng đời phát triển sản phẩm phần mềm cho thị trường ngách mà bạn đã tham gia trong nhiều năm sẽ đẩy nhanh quá trình này. Sẽ tốt cho bạn nếu bạn đã xây dựng được mối quan hệ với khách hàng và có một số dự án đang chạy. Điều này có thể giúp các chuyên gia quản lý sản phẩm của bạn lập kế hoạch triển khai dựa trên kinh nghiệm thực tế, giảm tỷ lệ phản tác dụng vì bạn chưa tính đến mọi thứ.

Bạn có phải là một công ty đã thành lập với chuyên môn về lĩnh vực đáng kể và bảng thông số kỹ thuật sản phẩm rõ ràng không? Xin chúc mừng! Bạn đã chọn tất cả các hộp để chuyển sang Bước 2 .

Nhưng nếu chuyên môn của bạn không đủ để tiến hành, bạn có thể muốn chậm lại một chút để thu hẹp khoảng cách.

Đây là cách bạn có thể xây dựng sản phẩm của mình dựa trên kiến ​​thức chuyên môn phù hợp ngay cả khi bạn chưa có:

• Mở rộng thị trường mục tiêu của bạn để tìm các chuyên gia tên miền có thể giúp bạn
• Thực hiện các cuộc phỏng vấn khách hàng để chứng minh tầm nhìn dự án của bạn và xác định các điểm khó khăn mà sản phẩm của bạn sẽ giải quyết
• Hợp tác với các chuyên gia miền để điều hành dự án của bạn cùng nhau

Nếu bạn không biết bắt đầu từ đâu, hãy đọc Running Lean của Ash Maurya để biết các mẹo về phương pháp khởi động hiệu quả. Đối với một khóa học cấp tốc về cách tiếp cận sản phẩm phù hợp với thị trường, hãy xem video này , nơi tác giả chia sẻ mười bước cần thực hiện.

Nuôi dưỡng tư duy “mọi người đều nói dối”, bạn cũng có thể nhúng ngón chân của mình vào bài kiểm tra The Mom Test của Rob Fitzpatrick để học cách thực hiện các cuộc phỏng vấn khách hàng. Quá bận để đọc nó? Bản tóm tắt video dài 3 phút này có thể đưa bạn đến những câu hỏi đáng hỏi cũng như những câu hỏi có thể khiến bạn bối rối khi trò chuyện với khán giả.

Bước 2. Làm quen với nhóm

Bạn không thể một mình dấn thân vào quá trình phát triển. Tạo ra một sản phẩm tuyệt vời từ đầu là có một đội ngũ gắn bó chặt chẽ với nhau, nơi mọi người đều biết rõ về dây.

Trong hầu hết các trường hợp, nhóm của bạn sẽ bao gồm các chuyên gia này.

Giám đốc công nghệ hoặc trưởng nhóm công nghệ

Khi bắt đầu, bạn chia sẻ tầm nhìn và yêu cầu về sản phẩm của mình với giám đốc công nghệ (CTO) hoặc trưởng nhóm kỹ thuật. Nhưng sự hợp tác của bạn với các chuyên gia này không kết thúc ở đó. Họ sẽ đồng hành cùng bạn trong mọi giai đoạn phát triển phần mềm.

Họ làm gì : CTO hoặc trưởng nhóm kỹ thuật quản lý dự án của bạn, đưa ra lộ trình và giúp sản xuất sản phẩm của bạn về mặt kỹ thuật. Họ giám sát cách chiến lược kinh doanh của bạn được đan xen vào các quy trình phát triển phần mềm, xác định các trở ngại và tìm ra các cách để tránh chúng. Họ cũng hoạt động như một liên kết giao tiếp giữa bạn và các bên liên quan khác để giữ cho các quyết định phù hợp.

Quản lý giao hàng

Người quản lý giao hàng giống như một cơ quan giám sát đằng sau dự án của bạn. Họ đảm bảo bạn có hàng đúng hạn mà không phải trả quá nhiều tiền cho chúng trong suốt SDLC.

Họ làm gì : Người quản lý phân phối hợp tác với CTO hoặc trưởng nhóm kỹ thuật để tạo ra một lộ trình dự án và giám sát tất cả các giai đoạn phát triển phần mềm về thời hạn và phân bổ nguồn lực. Họ ưu tiên các nhu cầu kinh doanh của bạn từ bước này sang bước khác và báo cáo kết quả khi đạt được. Trong mô hình Agile, người quản lý phân phối tiến lên để tối đa hóa giá trị trong sản phẩm của bạn thông qua các lần lặp lại.

Phân tích kinh doanh

Bạn muốn có một nhà phân tích kinh doanh (BA) trong nhóm của mình để đảm bảo sản phẩm của bạn phù hợp với thị trường một cách hiệu quả nhất có thể.

Họ làm gì : Một BA mang đến sự rõ ràng về nơi bạn đặt mục tiêu và cách sản phẩm của bạn có thể đạt được điều đó. Ở giai đoạn đầu, họ tổng hợp các con số và thu thập thông tin chi tiết để phân tích đối tượng mục tiêu của bạn muốn gì. Sau đó, họ đạt được điểm hợp lý giữa các vấn đề và giải pháp, tìm ra cách lý tưởng để tạo ra sản phẩm của bạn và ước tính bạn sẽ tốn bao nhiêu chi phí để làm điều đó. Cuối cùng, họ viết ra các yêu cầu kinh doanh và đảm bảo rằng chúng được đáp ứng mà không cần bỏ sót gì.

Nhóm phát triển

Một nhóm phát triển phần mềm chuyên dụng bao gồm tất cả những người chuyên nghiệp, những người đã kết hợp sản phẩm của bạn lại với nhau. Hãy nghĩ đến các nhà thiết kế UX / UI, các nhà phát triển frontend / backend và các kỹ sư đảm bảo chất lượng (QA).

Họ làm gì : Như bạn có thể thấy từ chức danh của họ, những chuyên gia này thiết kế, phát triển và theo dõi chặt chẽ chất lượng phần mềm của bạn. Họ biến bản tóm tắt của bạn thành một sản phẩm đầy đủ tính năng và đưa nó đến người dùng cuối. Khi nó ở đó, họ sẽ duy trì nó để bạn có thể cung cấp giá trị liên tục cho đối tượng mục tiêu của mình.

Bước 3. Xác nhận và ước tính ý tưởng

Vì vậy, bạn đang ngồi trên đống kiến ​​thức chuyên môn về lĩnh vực và đã kết nối với CTO, trưởng nhóm kỹ thuật, BA hoặc giám đốc phân phối để nói về ý tưởng dự án của bạn. Tiếp theo là gì? Xác nhận ý tưởng và ước tính dự án.

Xác thực ý tưởng

Xác thực ý tưởng là một bước quan trọng. Là một phần của quá trình khám phá sản phẩm , tất cả đều nhằm kết nối các dấu chấm giữa thứ bạn định tạo và liệu có ai muốn bạn sử dụng nó hay không. Đó là khi bạn xác thực các giả định, giả thuyết và phỏng đoán để tìm kiếm câu trả lời cho nhu cầu sản phẩm thực tế. Đo lường nó giúp bạn lập kế hoạch ngân sách và thời hạn cho dự án của mình.

Xác thực ý tưởng bao gồm nhiều quy trình (phỏng vấn khách hàng, khảo sát, v.v.) và các câu hỏi cần đặt ra. Ở giai đoạn này, bạn chuyển từ xác định vấn đề sang tìm ra giải pháp sang xác định các tính năng của sản phẩm đang được săn lùng.

Để bạn hiểu rõ hơn, việc xác định tai ương có nghĩa là:

• Thu hẹp đối tượng mà sản phẩm của bạn có thể giúp đỡ
• Tìm hiểu các vấn đề của họ và cách họ giải quyết chúng
• Xác định cách sản phẩm của bạn có thể giải quyết những vấn đề đó
• Tìm hiểu xem liệu trò chơi đó có đủ thay đổi để đáng trả tiền hay không để giải quyết các tai ương của đối tượng mục tiêu của bạn

Đối với vấn đề thứ hai, nhóm của bạn nghiên cứu các cách và giải pháp mà đối tượng mục tiêu của bạn hiện đang sử dụng để giải quyết các vấn đề của họ. Nếu điều này nghe giống như phân tích cạnh tranh, đó là bởi vì nó thực sự là như vậy.

Phân tích cạnh tranh không chỉ để biết bạn sẽ đối đầu với ai để thu hút khán giả mục tiêu của bạn. Đó là để làm thế nào để có lợi thế bằng cách cung cấp một giải pháp tốt hơn những giải pháp hiện có.

Đó là khi nhóm của bạn xác định điều gì làm cho sản phẩm của bạn khác biệt và những tính năng mà sản phẩm cần có. Quá trình phát triển phần mềm này cũng giúp xác định xem bạn nên sử dụng ứng dụng web tiến bộ (PWA), ứng dụng di động gốc hay tùy chọn kết hợp / đa nền tảng. Chúng tôi có toàn bộ bài viết dành riêng cho ứng dụng PWS so với ứng dụng gốc , vì vậy hãy xem nếu bạn cần thêm thông tin về chủ đề này.

Biết những tính năng nào sẽ được phát triển cũng sẽ giúp bạn quyết định giữa phát triển truyền thống hay dựa trên đám mây . Nhóm phát triển của bạn có thể hướng dẫn bạn thực hiện điều này.

Để hình dung giải pháp của bạn sẽ hoạt động như thế nào trong đời thực, nhóm của bạn sẽ phân tích các yêu cầu, tập hợp các câu chuyện của người dùng và phác thảo phần mềm mong muốn của bạn. Nhưng đừng mong đợi những tác phẩm nghệ thuật cấp Claude Monet ở giai đoạn này. Họ chỉ cung cấp cho bạn một sự hiểu biết cơ bản, đủ để tiến hành ước tính.

Dự toán dự án

Tại sao chúng ta không bắt đầu ước tính chi phí phát triển phần mềm sớm hơn? Không thể thực hiện được nếu không xác thực ý tưởng của bạn và khám phá dự án của bạn là gì.

Ước tính sơ

Vì vậy, một khi chúng tôi có các yếu tố đầu vào quan trọng, bạn có thể ước tính sơ bộ về phần mềm của bạn sẽ khiến bạn phải trả giá như thế nào. Nó cung cấp cho bạn số liệu về sân bóng dựa trên:

• Xác thực ý tưởng
• Các tính năng bắt buộc của sản phẩm
• Kinh nghiệm của người có liên quan với các dự án tương tự

Dưới đây là sơ lược về quy trình: đôi khi, chúng tôi sử dụng công cụ Ước tính ứng dụng của tôi . Bạn cũng có thể kiểm tra nó để có ước tính gần đúng.

Một ước tính sơ bộ đóng vai trò như một sổ cái chung cho BA để tạo cấu trúc phân tích công việc (WBS). Đó là một hình ảnh trực quan chia tách toàn bộ quy trình phát triển ứng dụng thành các bước và nhiệm vụ nhỏ bé để xem những gì sẽ được thực hiện. Nó bao gồm phạm vi công việc và các sản phẩm có thể phân phối sơ bộ và được sử dụng trong cả hai mô hình Agile và Waterfall của SDLC.

Nếu bạn giỏi với một ước tính sơ bộ, bạn có thể yêu cầu một ước tính chi tiết.

Ước tính chi tiết

Ước tính chi tiết đi sâu hơn vào việc lập kế hoạch cho từng bước, tính năng phần mềm, mô hình SDLC và những người liên quan đến việc tạo ra sản phẩm của bạn. Nó cũng tính đến số giờ cần thiết để phát triển phần mềm của bạn bằng cách phân bổ chúng cho mọi chuyên gia trong nhóm của bạn.

Tất nhiên, một ước tính chi tiết sẽ chính xác hơn một ước tính sơ bộ. Có thể mất đến hai tuần để kiểm đếm mọi thứ và hiển thị cho bạn tổng chi phí sản phẩm của bạn.

Để đảm bảo tính chính xác, chúng tôi cũng xem xét loại cơ sở hạ tầng và kiến ​​trúc phần mềm khi lập ước tính chi tiết. 

Nếu bạn muốn triển khai đám mây, nền tảng bạn đang xây dựng sản phẩm của mình có thể ảnh hưởng đến chi phí của nó. Chúng tôi có thể tiếp tục với dự án của bạn, cho dù bạn muốn đưa dự án đó lên AWS, Google Cloud Platform hay Azure, mặc dù AWS chứng tỏ là người chiến thắng chung cuộc đối với hầu hết các giải pháp được tạo có liên quan.

Sau đó, bạn sẽ cần phải quyết định một mẫu kiến ​​trúc phần mềm để có được một ước tính chi tiết.

Nhiều lớp	Một mẫu có cấu trúc, được kết hợp chặt chẽ được xây dựng trên các lớp trình bày, nghiệp vụ, tính bền bỉ và cơ sở dữ liệu.
Theo hướng sự kiện	Một mẫu không đồng bộ đặt sự nhanh nhẹn lên hàng đầu khi kích hoạt các sự kiện thời gian thực để các thành phần phần mềm hoạt động.
microkernel	Mẫu nhiều thành phần sử dụng các trình cắm thêm độc lập để bổ sung vào chức năng cốt lõi và cho phép phát triển sản phẩm phần mềm tùy chỉnh .
Microservices	Một mô hình kết hợp lỏng lẻo trong đó các mô-đun phần mềm khác nhau được xây dựng, triển khai và duy trì dưới dạng các dịch vụ nhỏ.
Dựa trên không gian	Một mẫu phức tạp cao sử dụng các đơn vị xử lý và công nghệ ảo hóa trên cấu trúc lưới để xử lý và lưu trữ dữ liệu.
Máy khách-máy chủ	Một mẫu đơn giản để thiết lập giao tiếp giữa một máy khách yêu cầu dữ liệu từ máy chủ.
Chủ nô	Một cách để phân phối các yêu cầu lặp lại đến nhiều thành phần phụ để xử lý đồng thời.
Bộ lọc đường ống	Một dạng trong đó các luồng dữ liệu sử dụng các đường ống làm trình kết nối để đi đến các bộ lọc khác nhau được xử lý xung quanh một chức năng cụ thể.

Khi bạn chọn một mẫu kiến ​​trúc, bạn sẽ tiến hành làm rõ ràng tất cả các yêu cầu chức năng và phi chức năng. Chúng tôi thu thập chúng để chuẩn bị tài liệu đặc tả yêu cầu phần mềm (SRS) và tập hợp lại thành một ngăn xếp công nghệ.

Yêu cầu và phân tích tính khả thi

Các yêu cầu và phân tích tính khả thi giúp cho việc lập dự toán và lập kế hoạch chi tiết trở nên hoàn chỉnh. Nó xem xét liệu phần mềm bạn muốn xây dựng có khả thi với các yêu cầu của bạn hay không hoặc yêu cầu thay đổi trước khi thiết kế và phát triển hoàn thành.

Khi đánh giá tính khả thi của phần mềm , các yêu cầu của bạn có thể được thay đổi. Nếu phân tích cho thấy một số trong số chúng không tốt nhất cho doanh nghiệp của bạn hoặc đối tượng mục tiêu về mặt kỹ thuật, hoạt động hoặc pháp lý, chúng tôi có thể đưa ra một vài gợi ý về các điều chỉnh. Những điều này có thể giúp bạn có được một sản phẩm khả thi hơn và tiết kiệm chi phí hơn về lâu dài.

Cùng với đó, phân tích tính khả thi và yêu cầu tập trung vào các vấn đề kỹ thuật, vận hành và pháp lý.

Tính khả thi về kỹ thuật

Nghiên cứu này được sử dụng để kiểm tra xem dự án của bạn có khả thi về mặt tài nguyên và công nghệ hay không. Nó phân tích cơ sở hạ tầng bạn đang sử dụng, khả năng nhóm của bạn, loại phần mềm và công nghệ ở giữa. Kết quả của nó cho bạn biết nếu có bất kỳ cải tiến kỹ thuật nào là cần thiết để đạt được kết quả tốt nhất.

Khả năng hoạt động

Bạn có thể vẫn chưa biết liệu sản phẩm cuối cùng của mình có dễ sử dụng, có thể bảo trì và sẵn sàng tích hợp hay không. Phân tích tính khả thi về hoạt động sẽ xem xét tất cả những điều đó để đảm bảo bạn có chiến lược phù hợp để đáp ứng các yêu cầu và nhu cầu kinh doanh của mình.

Tính khả thi về mặt pháp lý

Phân tích này kiểm tra các yêu cầu pháp lý mà sản phẩm của bạn phải đáp ứng và liệu bạn đã lên kế hoạch cho mọi thứ để tuân thủ hay chưa. Thông thường, tính khả thi về mặt pháp lý bao gồm các luật bảo mật và quyền riêng tư của dữ liệu, như GDPR hoặc CCPA, quyền sở hữu trí tuệ và các quy định của địa phương.

Khi nói đến khía cạnh pháp lý của dự án của bạn, kết quả của các yêu cầu và phân tích tính khả thi sẽ được tìm thấy trong các tài liệu phát triển phần mềm . Đó là những gì bạn ký như một phần của quy trình giới thiệu khách hàng để viết ra một cách rõ ràng những gì cần phải làm để tuân thủ.

Chỉ cần ký hợp đồng phát triển phần mềm và thỏa thuận chi phí và thời hạn? Đã đến lúc đi sâu vào mọi thứ.

Bước 4. Nguyên mẫu hoặc MVP

Với một nguyên mẫu hoặc sản phẩm khả thi tối thiểu (MVP), bạn có thể đưa nghiên cứu sơ bộ của mình vào thực tế và xem liệu ý tưởng của bạn có hoạt động trong đời thực hay không. Cả hai tùy chọn đều để thử nghiệm để bạn có thể nhanh chóng điều chỉnh dự án của mình và sử dụng tài nguyên một cách tiết kiệm.

Tiết kiệm thời gian một chút : Nếu bạn đã xác thực ý tưởng của mình và biết sản phẩm của mình trông như thế nào và nó sẽ hoạt động như thế nào, hãy chuyển sang Bước 5 . Tạo một nguyên mẫu hoặc MVP là một trong những bước phát triển phần mềm mà bạn có thể bỏ qua nếu kế hoạch của bạn chưa có cơ sở.

Tuy nhiên, nếu bạn vẫn đang thử nghiệm vùng nước, hãy xem xét việc xây dựng một nguyên mẫu có thể nhấp, MVP trợ giúp đặc biệt hoặc MVP chính thức. 

Nguyên mẫu có thể nhấp 

Kiểm tra giao diện người dùng của sản phẩm mong muốn của bạn? Một nguyên mẫu có thể nhấp có thể được phát triển cho các ứng dụng web và di động như một phiên bản thiết kế rút gọn để đánh giá khả năng sử dụng của nó.

Nguyên mẫu này đóng vai trò như một khung dây đơn giản với khả năng tương tác cơ bản để kiểm tra mức độ thân thiện với người dùng của bố cục, nút hoặc trang của bạn. Nó không phải là để giúp đối tượng mục tiêu của bạn đối phó với tai ương của họ hoặc tham gia quá nhiều vào chức năng của sản phẩm cuối cùng của bạn.

Concierge MVP

Xác minh một bằng chứng về khái niệm? Một cách tốt để kiểm tra xem có nhu cầu về sản phẩm của bạn hay không là sử dụng MVP của nhân viên hướng dẫn. 

MVP trợ giúp đặc biệt dựa trên một giải pháp được tạo sẵn để tập trung vào các vấn đề của khán giả mà không phát triển bất kỳ chức năng nào. Với MVP này, bạn giúp người dùng tiềm năng có được thứ họ cần theo cách thủ công và xem liệu một sản phẩm tự động có thể mang lại cho họ giá trị tương tự hay không. Tuy nhiên, nó không dành cho bạn nếu bạn định yêu cầu họ cung cấp thông tin nhận dạng cá nhân, số thẻ tín dụng hoặc dữ liệu nhạy cảm khác.

MVP chính thức

Đang kiểm tra các tính năng? MVP chính thức có thiết kế và chức năng chi tiết hơn so với mẫu thử nghiệm, cho phép bạn đặt nó trước khán giả mục tiêu của mình để kiểm tra xem điều gì phù hợp nhất với điểm đau của họ.

Hãy nhớ rằng bạn không bán bất cứ thứ gì với MVP này. Nó cũng không có tất cả các tính năng bạn sẽ thêm vào. Bạn chỉ sử dụng nó như một đầu mối liên hệ với đối tượng mục tiêu của mình để thu thập phản hồi với một giải pháp hữu dụng như một phần của quy trình phát triển sản phẩm Agile.

Nhưng làm thế nào để bạn biết bạn nên đầu tư vào những tính năng nào cho MVP chính thức của mình? Ôm mô hình Kano.

Mô hình Kano là một khung phân tích để tìm ra cách tốt nhất để đảm bảo sự hài lòng của khách hàng với sản phẩm của bạn. Trong phát triển web hoặc ứng dụng di động, nó có thể giúp bạn đưa ra danh sách chọn lọc các tính năng MVP đáng thử nghiệm ngay từ đầu.

Nói một cách đơn giản, mô hình Kano cho phép bạn phân biệt giữa các yếu tố cần thiết và chuông và còi trong một sản phẩm chưa được tạo ra. Vì vậy, khi xây dựng một MVP theo khuôn khổ này, bạn sẽ nói có với:

• Các tính năng cơ bản mà sản phẩm của bạn không thể thiếu . Chúng là các tính năng ưu tiên cao nhất để thêm vào MVP của bạn, vì khán giả mục tiêu của bạn chắc chắn mong đợi có chúng. Ví dụ: nếu bạn đang xây dựng nền tảng thị trường trực tuyến , thì trang tổng quan về người bán và điều hướng dễ dàng sẽ ở đó theo mặc định.
• Các tính năng hiệu suất làm cho sản phẩm của bạn khác biệt . Đây là những tính năng giúp đối tượng mục tiêu của bạn vượt qua vấn đề của họ đồng thời mang lại lợi thế cạnh tranh cho bạn. Hãy nghĩ về một khu chợ một lần nữa. Nếu bạn dự định giành được khách hàng bằng các báo cáo chi tiết hơn những nơi khác, hãy thêm chúng vào MVP của bạn.
• Các tính năng thú vị cung cấp giá trị bổ sung . Chúng không nhất thiết phải có trong MVP của bạn, nhưng bạn muốn có ít nhất một tính năng thú vị để xem liệu nó có ảnh hưởng đến sự hài lòng của khách hàng hay không. Ví dụ: bạn có thể thử nghiệm tìm kiếm bằng giọng nói trong MVP trên thị trường của mình để giúp người dùng cuối điều hướng nền tảng của bạn.

Và bạn sẽ nói không với mọi thứ mà người dùng không quan tâm. Bạn có thể từ bỏ bất kỳ tính năng nào trong MVP của mình để làm cho sản phẩm cuối cùng trở nên hoàn chỉnh nhưng không có tác động hữu hình đến sự hài lòng hoặc không hài lòng của người dùng.

Bước 5. Thiết kế

Giai đoạn thiết kế là khi các yêu cầu và phản hồi thu thập được trong bước trước đó được sử dụng để sắp xếp sản phẩm của bạn nhằm phát triển thêm. Bên cạnh đó, đó cũng là lúc sản phẩm của bạn đạt được một mốc quan trọng về mặt hình ảnh.

Nếu bạn đang đấu tranh để giành được sự ủng hộ của các bên liên quan hoặc nhà đầu tư khác, thiết kế phần mềm tùy chỉnh có thể giúp bạn đưa chúng vào danh sách đầu tiên. Sản phẩm của bạn trở nên hữu hình ở giai đoạn này, giúp đạt được tổng lượt mua dễ dàng hơn. Và bởi vì nó có thể sử dụng được — ít nhất là ở một mức độ nào đó — bạn có thể tiếp tục thử nghiệm để nhận phản hồi lặp đi lặp lại.

Quá trình thiết kế phần mềm bắt đầu với việc nhìn lại nghiên cứu người dùng.

Nghiên cứu người dùng và kiến ​​trúc thông tin

Đến đây, bạn đã biết đủ về lý do tại sao bạn đang tạo ra một sản phẩm và người dùng cuối của nó là ai. Nhưng bạn cần một chiến lược phù hợp hơn để bắt đầu quá trình thiết kế với nhóm của mình. Chiến lược này nên được xây dựng dựa trên:

1. Tóm tắt thiết kế . Bạn soạn thảo tài liệu này với nhóm của mình để loại bỏ sự mơ hồ khỏi bảng thiết kế. Nó phải kết hợp các khía cạnh chính của dự án của bạn, bao gồm các yêu cầu và sản phẩm phân phối, đồng thời các bên liên quan có thể hiểu được. Các nhà thiết kế và kỹ sư gắn bó với một bản tóm tắt trong tất cả các bước của quy trình phát triển phần mềm.
2. Tính cách người dùng . Những điều này xuất hiện từ kết quả nghiên cứu người dùng của bạn. Với tính cách người dùng được ghi chép đầy đủ, các nhà thiết kế UX / UI có thể gặp gỡ những người mà họ đang thiết kế sản phẩm của bạn, mặc dù họ chỉ là hư cấu. Nhóm của bạn biết khách hàng lý tưởng của bạn là ai, họ bao nhiêu tuổi, họ làm nghề gì để kiếm sống và các thông tin chi tiết khác giúp họ đưa ra quyết định thiết kế phù hợp.
3. Hành trình của người dùng và luồng người dùng . Đây là những hình ảnh minh họa cách khán giả mục tiêu có thể sử dụng sản phẩm của bạn để đáp ứng nhu cầu của họ. Ngoài ra, hành trình của người dùng còn vượt xa hơn thế bằng cách hình dung trải nghiệm của họ ngay cả sau khi đạt được mục tiêu. Cả hai hình ảnh đều cần thiết để thiết kế một giải pháp mang lại cảm giác cá nhân hóa hơn.

Ba yếu tố này là tối quan trọng đối với kiến ​​trúc thông tin (IA). Nhóm thiết kế của bạn xây dựng nó để kết hợp điều hướng, tính năng, hình ảnh và nội dung khác của sản phẩm của bạn trong một biểu đồ để cấu trúc các bước cần thực hiện. Sau đó, IA được sử dụng để ưu tiên UX khi tạo khung dây. Điều này giúp giữ cho các bên liên quan được liên kết, đặc biệt là khi kết hợp với các cuộc hội thảo thường xuyên để gắn kết các nhóm với nhau.

Một cách khác để duy trì sự liên kết của nhóm trong giai đoạn thiết kế là vẽ sơ đồ ký hiệu mô hình hóa quy trình kinh doanh (BPMN) . Nó phải dựa trên WBS để sắp xếp các quyết định, tạo tác, yêu cầu và luồng thông tin liên quan đến thiết kế. Sơ đồ BPMN giúp kết nối các ý tưởng và quy trình để thiết kế một sản phẩm lấy người dùng làm trung tâm.

Wireframe và mô hình

Bước wireframing được thực hiện sau khi bạn có kết quả nghiên cứu người dùng và IA. Đó là khi bạn nhận được thứ gì đó hữu hình như bản nháp bố cục đầu tiên. Khung dây cho thấy các khối cấu trúc chính của thứ mà sau này sẽ trở thành sản phẩm của bạn. Chúng thường chứa đầy lorem ipsum mà không có bất kỳ tính năng hấp dẫn trực quan nào. Tuy nhiên, thiết kế đơn giản như vậy có thể cung cấp cho bạn ý tưởng sơ bộ về các vị trí nút, điều hướng, độ sâu của trang, v.v.

Tiếp theo, bạn chạm tay vào một mô hình . Đó là một thiết kế tinh tế hơn về mặt hình ảnh cho phép bạn có được cảm nhận tổng thể về sản phẩm của mình. Một mô hình có thể chứa đầy các biểu tượng, thanh trượt và các hình ảnh trực quan khác được tạo trong một bảng màu đã thống nhất và trên một bố cục khung dây. Khi nó được giao, bạn có thể yêu cầu thay đổi những gì bạn thấy không cần thiết hoặc tiếp tục.

Cả wireframe và mockup đều không sử dụng được. Bạn chỉ có thể kiểm tra sản phẩm của mình bằng một số thao tác khi có mẫu thử nghiệm có thể nhấp.

Thiết kế UI / UX

Thiết kế trải nghiệm người dùng loại trực tiếp là thiết kế mà đối tượng mục tiêu của bạn thấy trực quan. Nó phải nhất quán, đơn giản và phù hợp với cá tính và hành trình của người dùng của bạn. Một thiết kế UX tuyệt vời giúp loại bỏ thời gian để khán giả mục tiêu của bạn làm quen với nó. Thay vào đó, nó được tạo ra theo cách tự giải thích để họ có thể giải quyết tai ương với sản phẩm của bạn ngay lập tức.

Ở giai đoạn này, bạn sẽ nhận được phiên bản cuối cùng của thiết kế giao diện người dùng của sản phẩm. Phản hồi giả lập của bạn được xem xét để:

• Hoàn thiện các yếu tố cấu trúc và hình ảnh
• Thêm các tính năng thiết kế bổ sung mà bạn nghĩ có thể mang lại lợi ích cho đối tượng mục tiêu của mình
• Tối ưu hóa các tương tác vi mô
• Làm nổi bật đặc điểm nhận dạng thương hiệu của bạn trong giao diện người dùng của sản phẩm

Với phiên bản thiết kế cuối cùng, điều quan trọng là phải kiểm tra xem đối tượng mục tiêu của bạn cảm thấy như thế nào về nó.

Kiểm tra khả năng sử dụng

Kiểm tra khả năng sử dụng là kiểm tra cuối cùng trước khi bắt đầu phát triển sản phẩm phần mềm. Nó liên quan đến việc giới thiệu thiết kế sản phẩm của bạn cho một nhóm người dùng cuối để đánh giá tính trực quan, độ chính xác và hiệu quả của nó.

Kiểm tra khả năng sử dụng là một cách sâu sắc để:

• Kiểm tra hành vi của người dùng trong các tình huống tương tác với sản phẩm ngoài đời thực
• Đảm bảo rằng các quyết định thiết kế của bạn là đúng hoặc cần được xem xét lại
• Đánh giá sự hấp dẫn trực quan của thiết kế của bạn
• Phát hiện các sai sót và các yếu tố thiết kế liên quan đến sự không hài lòng của người dùng

Bằng cách thử nghiệm sản phẩm theo cách này, bạn có thể xem xét kỹ hơn cách những người thực sử dụng sản phẩm của bạn. Điều này giúp tiết kiệm rất nhiều thời gian và công sức vì bạn có thể thiết kế lại bất kỳ tính năng nào dựa trên thông tin chi tiết và chỉ chuyển sang giai đoạn viết mã khi mọi thứ đã được đánh bóng.

Bước 6. Phát triển

Giờ đây, vòng đời phát triển sản phẩm đã đưa bạn đến với khía cạnh kỹ thuật của dự án của bạn. Bạn có thể gọi nó là bước mã hóa, trong đó mọi thứ được thiết lập để tạo ứng dụng hoặc trang web của bạn. Nói cách khác, đây là lúc nhóm phát triển phần mềm Agile của bạn bắt tay vào làm việc với cơ sở hạ tầng, giao diện người dùng và công việc phụ trợ.

Đối với bạn, giai đoạn phát triển bắt đầu với việc cung cấp một bản tuyên bố về công việc (SOW) khi bạn được giới thiệu. Được viết bởi một người quản lý dự án, tài liệu này mô tả lý do, khi nào, như thế nào và những gì cần phải thực hiện một cách chi tiết. Nó đi sâu vào mọi thứ từ lịch trình, tiêu chuẩn và thanh toán đến các dịch vụ phát triển được cung cấp trong vòng đời dự án của bạn.

Với một SOW được viết tốt, bạn luôn biết sản phẩm của mình đang ở đâu. Nó nâng cao trải nghiệm quản lý dự án bằng cách đặt ra một cách tiêu chuẩn hóa để xử lý mọi việc và đảm bảo tất cả các nhóm đi theo cùng một con đường hướng tới một sự ra mắt thành công.

Đồ tạo tác dự án

Để đi sâu hơn vào thủ tục giấy tờ, SOW của bạn đi kèm với tám hiện vật dự án. Những điều này là cần thiết để bao quát các quy trình trong các bước kỹ thuật phần mềm một cách rõ ràng tuyệt đối:

1. Lịch trình liên lạc . Đây là kế hoạch của bạn để nhận cập nhật trạng thái và thông tin khác liên quan đến dự án sau khi bắt đầu phát triển. Lịch trình giao tiếp giúp bạn biết những cuộc họp nào bạn có thể tham gia với tư cách là khách hàng, tần suất của họ và các kênh liên lạc.
2. Điều lệ dự án . Tương tự như một lộ trình, điều lệ dự án đóng vai trò như một hướng dẫn cho bạn và nhóm phát triển của bạn. Nó tập hợp lý do của phần mềm, mục tiêu, các bên liên quan và tài nguyên của bạn. Bên cạnh đó, nó mô tả các vai trò và trách nhiệm, bao gồm các cấp quyền hạn của người quản lý dự án.
3. Ma trận RACI . Tạo tác này chỉ định các giai đoạn và nhiệm vụ phát triển phần mềm cho những người trong nhóm của bạn. Nó sử dụng các thẻ Chịu trách nhiệm, Chịu trách nhiệm, Được tư vấn và Thông báo để xác định các vai trò cụ thể trong suốt vòng đời dự án của bạn.
4. Thay đổi đăng ký yêu cầu . Với tạo tác này, bạn có thể kiểm tra các chỉnh sửa trong dự án của mình và yêu cầu họ với tư cách là một bên liên quan. Ngay cả một điều chỉnh nhỏ cần một phút để thực hiện cũng được ghi lại ở đây để theo dõi.
5. Biểu đồ Gantt . Khi nói đến các nhiệm vụ lập kế hoạch, biểu đồ Gantt cung cấp cho bạn cái nhìn tổng quan dựa trên thời hạn về mọi thứ sẽ được thực hiện. Nó hiển thị các hoạt động và mất bao lâu để hoàn thành từng hoạt động đó, giúp bạn cập nhật nhanh nhất về trạng thái hoàn thành dự án.
6. Lộ trình dự án . Còn được gọi là kế hoạch phát hành, một lộ trình công nghệ hiển thị các yếu tố WBS cấp cao nhất qua các lần chạy nước rút lặp lại. Tạo tác này làm cho dự án của bạn dễ dự đoán hơn và hiệu quả hơn trong dài hạn. Bạn có thể có được lộ trình CNTT, ứng dụng hoặc nhà phát triển để điều phối các đợt triển khai và nâng cấp mới trong doanh nghiệp của mình trong khi vẫn đặt tầm nhìn về các mục tiêu chiến lược. Với một kế hoạch phát hành, bạn có thể thực hiện một cái gì đó mới và kiểm soát nó, không chỉ đi theo dòng chảy.
7. Sổ đăng ký rủi ro . Tạo tác này liệt kê các rủi ro tiêu cực và tích cực gắn liền với quá trình phát triển phần mềm sau phiên xác định rủi ro. Nó cho phép bạn và nhóm dự án của bạn nhận thức được các mối đe dọa, tác động và các hành động giảm thiểu để bảo vệ sản phẩm và doanh nghiệp của bạn không đi chệch hướng.
8. Câu chuyện của người dùng . Được viết bởi một BA, những câu chuyện của người dùng chuyển khỏi những nội dung phát triển phức tạp để chuyển sang mô tả ngắn gọn, dễ hiểu về cách sản phẩm của bạn sẽ được sử dụng. Họ đặt đối tượng mục tiêu của bạn lên hàng đầu và cung cấp tài liệu tham khảo để xây dựng chức năng giúp đáp ứng nhu cầu của họ.

Bây giờ bạn có nghĩ rằng bạn có thể ký SOW của mình, nhận tất cả tám hiện vật và gọi nó là một ngày không? Nó không hoạt động theo cách đó. Là chủ sở hữu sản phẩm, vai trò của bạn là trung tâm trong quá trình phát triển và sự tham gia của bạn cũng vậy.

Họp dự án

Sự hợp tác của chúng tôi bắt đầu bằng một cuộc họp khởi động, nhưng nó không giới hạn ở một cuộc họp. Để theo kịp các tiêu chuẩn cao tại BEIT  , chúng tôi sử dụng các quy trình quản lý dự án Agile và mong bạn tham gia với chúng tôi để:

• Đứng lên hàng ngày để sắp xếp các công việc cho ngày sắp tới và vượt qua những trở ngại thông qua nỗ lực tổng hợp
• Các cuộc họp lập kế hoạch Sprint để thiết lập mục tiêu và lập kế hoạch hoạt động cho sprint tiếp theo
• Các cuộc họp ước tính tồn đọng để tìm hiểu sâu về công việc tồn đọng của sprint, ưu tiên các tính năng, đánh giá khối lượng công việc và lập kế hoạch cách thực hiện chúng
• Các bài thuyết trình cuối sprint để đánh giá và thảo luận về các kết quả đã đạt được trong sprint
• Hồi tưởng về Sprint để nhìn lại các quy trình trong sprint trước và tối ưu hóa chúng cho sp tiếp theo

Bạn cũng sẽ cần dành một chút thời gian để xem qua các báo cáo trong lịch trình của mình. Chúng đi kèm với tất cả các giai đoạn phát triển phần mềm để cung cấp kết quả đầu ra cho mỗi bước chúng tôi hoàn thành. 

Bước 7. Kiểm tra

Thực hành làm cho hoàn hảo, phải không? Cào đó.

Trong phát triển phần mềm, thử nghiệm tạo nên sự hoàn hảo. Quá trình này bắt đầu ngay sau khi dòng mã đầu tiên được viết và tiếp tục diễn ra trước khi sản phẩm của bạn xuất hiện trực tuyến.

Chúng tôi kiểm tra những gì ở BEIT  ?

Khi phần mềm của bạn được phát triển với BEIT  , bạn sẽ nhận được các dịch vụ đảm bảo chất lượng trong quá trình này. Chúng dựa trên một kế hoạch QA được xác định trước cho dự án của bạn mà cả nhóm QA đều tuân theo.

Kế hoạch QA mô tả phạm vi thử nghiệm và các hành động cần thực hiện để cung cấp một sản phẩm hoàn mỹ. Chúng tôi thực hiện nó trong giai đoạn phát triển để chuyển trọng tâm sang:

• Phân tích yêu cầu: Phần mềm của bạn được kiểm tra sự phù hợp với các yêu cầu được xác định ở giai đoạn xác nhận.
• Lập kế hoạch và thực hiện kiểm thử: Các trường hợp và chiến lược kiểm thử được phát triển cho các mô-đun phần mềm của bạn.
• Theo dõi lỗi : Một hệ thống chuyên biệt được tạo ra để theo dõi tất cả các lỗi làm hỏng phần mềm của bạn, cộng với cách thức và thời điểm chúng phải được giảm thiểu.
• Kiểm tra hồi quy trước khi khởi chạy : Các mô-đun phần mềm hiện tại của bạn được kiểm tra lặp đi lặp lại các sai sót khi có một chút thay đổi đối với mã. 

Chúng tôi thực hiện các bài kiểm tra thủ công và tự động để tìm ra nguyên nhân gốc rễ của lỗi một cách hiệu quả khi chúng được phát hiện. Nhưng bạn có luôn cần thực hiện cả hai điều đó không? Nó phụ thuộc.

Kiểm tra thủ công so với kiểm tra tự động

Không có cách nào hoàn hảo để kiểm tra tất cả các trường hợp sử dụng, mặc dù tất cả chúng ta đều ước mình có một cách hoàn hảo. Cả kiểm thử thủ công và tự động đều có thể mang lại lợi ích cho quá trình phát triển sản phẩm phần mềm, nhưng khác. 

Sự khác biệt giữa chúng là bạn phải thực hành kiểm tra trong thử nghiệm thủ công. Điều đó có nghĩa là các chuyên gia QA chỉ sử dụng kiến ​​thức và kỹ năng của họ trong khi giữ các tab trên phần mềm, tính năng hoặc mô-đun cụ thể của bạn.

Tự động hóa không yêu cầu bạn phải thực hành, ít nhất một khi các tập lệnh thử nghiệm đã có sẵn. Chúng chạy tự động để kiểm tra lỗi phần mềm của bạn.

Vậy tại sao bạn lại làm một việc thủ công trong khi bạn có thể tự động hóa nó? Mặc dù tẻ nhạt và dễ xảy ra lỗi do con người, nhưng các bài kiểm tra thủ công sẽ tốt hơn so với các đoạn script khi:

• Kiểm tra sản phẩm của bạn để biết người dùng cuối, không phải máy móc, cảm nhận như thế nào
• Bạn cần sự kiểm soát của con người đối với quá trình QA
• Dự án của bạn nhỏ và viết kịch bản có vẻ không phải là một ý tưởng hay về mặt tài chính
• Bạn cần điều chỉnh động các quy trình QA của mình và không thể lập kế hoạch trước cho chúng

Đó là lý do tại sao kiểm tra thủ công có ý nghĩa hơn trong việc kiểm tra mọi thứ liên quan đến trải nghiệm và khám phá của người dùng. Họ giúp khám phá những gì chỉ một con người có thể nhận thấy. Bên cạnh đó, bạn không thể triển khai các tập lệnh cho thử nghiệm đặc biệt.

Các bài kiểm tra tự động cũng có ưu và nhược điểm. Bạn sẽ tốn nhiều tiền hơn để bắt đầu với chúng vì bạn sẽ cần viết và triển khai các tập lệnh cho tất cả các trường hợp sử dụng của mình. Và họ vẫn yêu cầu một chuyên gia QA để giám sát các vấn đề phức tạp. 

Điều đó nói rằng, các bài kiểm tra tự động tốt hơn các bài kiểm tra thủ công khi:

• Thử nghiệm nhiều và lặp đi lặp lại
• Chạy các bài kiểm tra mà không người kiểm tra con người nào có thể thực hiện được
• Dự án của bạn lớn và bạn sẽ cần quá nhiều kỹ sư QA mà không cần tự động hóa
• Bạn muốn mô phỏng các mối đe dọa mạng để kiểm tra sự thâm nhập của ứng dụng web

Đó là lý do tại sao tự động hóa hoạt động tốt nhất cho các trường hợp thử nghiệm quy mô lớn cần được thực hiện nhiều lần, như hồi quy, đơn vị và tải.

Phát triển theo hướng thử nghiệm (TDD)

Có nhiều cách để viết mã và tiến hành kiểm tra, nhưng phát triển theo hướng kiểm tra (TDD) là cách chúng tôi yêu thích nhất. Ý tưởng chủ đạo của TDD là các quy trình phát triển phần mềm tuân theo kết quả của các bài kiểm tra. Nói một cách đơn giản, bạn viết mã sau khi kiểm tra không thành công báo hiệu điều gì đó cần được thay đổi để xác thực các hành vi. Sau đó, bạn đặt mã tối thiểu để vượt qua bài kiểm tra đó, loại bỏ các phần trùng lặp và lặp lại chu trình.

Trong TDD, sự phát triển thực tế xảy ra sau khi thử nghiệm, hoặc cụ thể hơn là trong khi thử nghiệm. Đây là điều làm cho nó khác với thử nghiệm truyền thống được thực hiện khi tất cả mã đã ở đó. Việc phát triển theo cách này cũng giúp đảm bảo mức độ bao phủ cao hơn với các bài kiểm tra vì cả hai quá trình đều đan xen nhau.

Khi các bài kiểm tra thúc đẩy sự phát triển sản phẩm phần mềm, hệ thống của bạn kết thúc với:

• Mã dọn dẹp
• Ít sự kém hiệu quả hơn
• Không có phần trùng lặp
• Thời gian thử nghiệm tiết kiệm được hàng giờ ở giai đoạn cuối cùng

TDD thường sử dụng các bài kiểm tra đơn vị, nhưng nó không bằng chúng. Kiểm thử đơn vị cũng phổ biến trong kiểm thử truyền thống để kiểm tra một hành vi ở mức thấp nhất. Tuy nhiên, trong TDD, chúng là một phần không thể thiếu của quá trình tái cấu trúc đồng thời thúc đẩy sự phát triển.

Bước 8. Thực hiện và triển khai

Khi thử nghiệm trước khi ra mắt chứng tỏ phần mềm của bạn đã sẵn sàng để tiến xa hơn, nó sẽ được chuyển sang giai đoạn sản xuất. Tại BEIT  , bước này liên quan đến việc điều phối phát hành sản phẩm phần mềm để đưa giải pháp của bạn đến người dùng cuối một cách đồng bộ.

Hãy xem những gì liên quan đến việc điều phối phát hành.

Thiết lập máy chủ

Điều đầu tiên cần làm để phần mềm của bạn hoạt động là thiết lập một nơi để chứa nó. Cho dù bạn chọn máy chủ tại chỗ hay nền tảng đám mây, bạn sẽ giao việc đó cho nhóm phát triển của mình. Bước này cần được thực hiện hết sức cẩn thận để thiết lập các quy trình phụ trợ trơn tru và triển khai các phương pháp DevSecOps . Đồng thời, nhóm của bạn nên định cấu hình phân bổ tài nguyên phía máy chủ để phần mềm mới phát hành của bạn có thể được sử dụng hiệu quả.

Xây dựng đường ống CI / CD

Bất cứ điều gì bạn đang phát triển, bạn muốn kết hợp phần mềm của mình với đường dẫn Tích hợp liên tục (CI) và Phân phối liên tục (CD). Sau khi được triển khai, nó sẽ đẩy nhanh quá trình phát hành cho tất cả các bản dựng mà bạn có và giúp việc áp dụng các thay đổi sau khi ra mắt dễ dàng hơn. Ngoài ra, các phương pháp hay nhất về đường ống CI / CD bổ sung vào khả năng bảo trì sản phẩm của bạn bằng cách gói nó thành một gói thống nhất.

Bảo vệ phần mềm của bạn khỏi lỗi của bên thứ ba

Không có phần mềm nào miễn nhiễm với mọi rủi ro ngoài kia. Tích hợp của bên thứ ba — và thậm chí cả nhà cung cấp dịch vụ đám mây của bạn — đôi khi có thể gặp phải một bản vá lỗi khó khăn, khiến hệ thống của bạn gặp lỗi. Đó là lý do tại sao nhóm phát triển của bạn nên định cấu hình sao lưu máy chủ ở giai đoạn triển khai. Với các bản sao lưu, bạn có thể quay trở lại hoạt động bình thường, mặc dù không có sẵn các hệ thống của bên thứ ba mà bạn dựa vào.

Chuẩn bị và thực hiện kế hoạch triển khai

Điều phối phát hành cũng xoay quanh một kế hoạch triển khai. Nó được đưa vào phần cuối của quá trình phát triển để xác định cách phần mềm của bạn hoạt động, ai chịu trách nhiệm đưa nó đến đó và cách nó được duy trì sau đó. Theo cùng một kế hoạch, nhóm của bạn sau đó sẽ phân phối sản phẩm của bạn cho bất kỳ ai được cho là sử dụng nó và đảm bảo rằng nó không gặp trở ngại trong suốt chặng đường.

Bước 9. Vận hành và bảo trì

Vì vậy, sản phẩm của bạn được tung ra. Điều này đánh dấu sự khởi đầu của các hoạt động và định kỳ bảo trì.

Mặc dù nó đến sau cùng, bảo trì là một trong những giai đoạn phát triển phần mềm quan trọng nhất. Bạn nên duy trì — hoặc nhờ ai đó bảo trì — sản phẩm của bạn để cải tiến, cập nhật và duy trì hoạt động mà không cần thời gian ngừng hoạt động.

Đây là lúc bạn thường ký thỏa thuận bảo trì phần mềm với nhóm phát triển của mình hoặc bên thứ ba. Theo thỏa thuận này, bạn quy định những bộ phận nào của sản phẩm cần được bảo trì, các hoạt động bảo trì, các khoản nợ phải trả và hơn thế nữa.

Theo tiêu chuẩn IEEE / ISO / IEC 14764-2006 , có bốn loại hoạt động bảo trì:

1. Bảo trì phần mềm sửa chữa . Nếu ai đó đã nhận thấy một lỗi trong sản phẩm của bạn, việc sửa lỗi đó là một phần của quá trình bảo trì khắc phục. Nó đề cập đến các hành động được thực hiện để đối phó với các lỗi được báo cáo trong phần mềm của bạn.
2. Bảo trì phần mềm dự phòng . Cũng giống như bạn thay dầu động cơ của ô tô để ngăn chặn các vấn đề xảy ra với bộ bánh xe của mình, loại bảo dưỡng này bao gồm việc kiểm tra và sửa chữa kịp thời để ngăn chặn các lỗi phần mềm.
3. Bảo trì phần mềm hoàn hảo . Sau khi ra mắt, phần mềm của bạn sẽ phát triển. Bảo trì hoàn hảo có nghĩa là tối ưu hóa, tinh chỉnh và thêm các tính năng mới để cung cấp phiên bản tốt nhất của sản phẩm cho người dùng cuối.
4. Bảo trì phần mềm thích ứng . Chuyển sang đám mây? Đáp ứng các chính sách cập nhật trong tiện ích bổ sung của bên thứ ba mà phần mềm của bạn sử dụng? Loại bảo trì này đòi hỏi mọi thứ cần được thực hiện để điều chỉnh sản phẩm của bạn theo những thay đổi mà không ảnh hưởng đến giá trị của sản phẩm đối với đối tượng mục tiêu của bạn.

IEEE / ISO / IEC 14764-2006 cũng nên là hướng dẫn của bạn để lập kế hoạch bảo trì và phân tích tài nguyên. Với kế hoạch bảo trì, bạn sẽ ở trên cùng một trang với bất kỳ ai chăm sóc sản phẩm của bạn sau khi ra mắt. Nó đưa ra các hướng dẫn chi tiết về cách thức, thời gian và những gì sẽ được thực hiện để duy trì. Nó giống như một chiến lược bạn phát triển để không bị xáo trộn trong việc xác định:

• Phạm vi các hoạt động phòng ngừa, khắc phục, thích ứng và các hoạt động khác
• Trách nhiệm của mọi người trong nhóm bảo trì
• Tài liệu
• Thay đổi quy trình yêu cầu
• Lịch trình và chi phí
• Thực hành phương pháp luận về kỹ thuật độ tin cậy của trang web (SRE)
• Phương pháp kiểm soát chất lượng
• Báo cáo

Bạn nên bắt đầu xây dựng kế hoạch bảo trì trong các bước kỹ thuật phần mềm nếu cùng một nhóm xử lý việc phát triển và bảo trì. Chuẩn bị sớm như vậy đảm bảo rằng nó bao gồm tất cả các cơ sở ngay khi sản phẩm của bạn có sẵn cho người dùng cuối.

Phân tích nguồn lực là một điều quan trọng khác cần xem xét ở giai đoạn vận hành và bảo trì. Nó nên được thực hiện để đính kèm một thẻ giá cho:

• Nguồn nhân lực hoặc những người sẽ tham gia vào việc duy trì sản phẩm của bạn
• Tài nguyên môi trường hoặc nơi bảo trì và thử nghiệm sẽ được thực hiện
• Nguồn lực tài chính hoặc bao nhiêu hoạt động bảo trì sẽ khiến bạn tiêu tốn

Bạn không nên xem xét kỹ lưỡng các tài nguyên của riêng mình. Nếu bạn để các hoạt động và bảo trì cho Có liên quan, chúng tôi sẽ làm điều đó cùng nhau để xác định nguồn nhân lực, môi trường và tài chính sẵn có. Chúng tôi sử dụng kết quả nghiên cứu và các phương pháp dựa trên số liệu thống kê để kiểm đếm chi phí và giúp bạn lập ngân sách cho việc duy trì.

Tiêu chuẩn bảo mật của chúng tôi

Trong một thế giới mà kiểm soát truy cập bị hỏng, phần mềm gián điệp và vi phạm dữ liệu tràn lan, việc đảm bảo an ninh là nhiệm vụ ưu tiên hàng đầu. Nó có phải là một đơn đặt hàng cao? Chắc chắn rồi. Nó là bất khả thi? Câu trả lời của chúng tôi là không.

Cam kết của BEIT  đối với các thực hành an toàn và bảo mật được kiên định trong tất cả các bước phát triển phần mềm. Từ xác nhận ý tưởng đến bảo trì, chúng tôi tuân theo các tiêu chuẩn ISO / IEC 27001 . Chúng tôi cũng đầu tư vào đào tạo nhân viên toàn diện về cách kiểm tra bảo mật ứng dụng dành cho thiết bị di động , bảo mật ứng dụng web và các loại phần mềm khác để nâng cao kỹ năng trong việc tạo ra các sản phẩm không có sơ hở.

Đó là cách bạn biết sản phẩm của mình được bảo mật từ góc độ kỹ thuật khi sản phẩm đã sẵn sàng. Nó sẽ đi kèm với nhiều tạo tác, kế hoạch và chính sách để bạn có thể theo kịp các tiêu chuẩn bảo mật cao ở cấp tổ chức:

• Kế hoạch kinh doanh liên tục để mô tả các hành động tức thì bạn sẽ cần thực hiện trong thời gian gián đoạn nhỏ hoặc lớn để giảm thiểu thời gian ngừng hoạt động.
• Kế hoạch khôi phục để xác định phản ứng và các hành động khắc phục bạn sẽ cần thực hiện để thoát khỏi sự cố liên quan đến bảo mật.
• Chính sách bảo mật thông tin nhằm thiết lập các quy tắc và hướng dẫn về quản lý dữ liệu trong tổ chức của bạn và các bên thứ ba để tuân thủ.
• Chính sách đánh giá rủi ro để đánh giá các mối nguy về mức độ ảnh hưởng của chúng đối với doanh nghiệp của bạn và khả năng xảy ra của chúng.

Đây chỉ là một số tài liệu đi kèm với sản phẩm của bạn để đáp ứng các tiêu chuẩn bảo mật. Bạn có thể nhận được danh sách đầy đủ các hiện vật, kế hoạch và chính sách sau khi ký NDA để phát triển phần mềm với BEIT .

Thực tiễn bảo mật của chúng tôi cũng liên quan đến các hội thảo đánh giá rủi ro và mô hình mối đe dọa thường xuyên. Họ tập hợp các nhóm lại với nhau để nâng cao hiểu biết về các mối nguy tiềm ẩn và trao quyền cho họ thực hiện công việc của mình với các biện pháp bảo vệ. Các hội thảo được thực hiện xuyên suốt SDLC của bạn. Bạn có thể tìm thấy một số chủ đề và thực tiễn được thảo luận tại các hội thảo trong hướng dẫn của chúng tôi về bảo mật của các ứng dụng web và di động .

Kết thúc

Vòng đời phát triển sản phẩm phần mềm là một quá trình bao gồm nhiều bước, mở rộng, bắt đầu khi ý tưởng của bạn được sinh ra và tiếp tục khi nó được thực hiện thành một giải pháp toàn diện. Cần rất nhiều nỗ lực để hoàn thành tất cả các bước đó. Nhưng sẽ dễ dàng hơn để làm điều đó nếu chúng được đặt trong đá, như trong hướng dẫn này. Chúng tôi theo dõi nó hàng ngày tại BEIT  , và bạn cũng vậy.

Chín bước phát triển phần mềm của BEIT  đưa sản phẩm của bạn từ nghiên cứu sơ bộ đến triển khai và bảo trì. Hãy bám sát chúng để luôn đi đúng hướng, cho dù bạn đang tạo web hay ứng dụng di động.

Hướng dẫn biến cửa hàng Shopify trở thành ứng dụng di động

Nguồn: https://relevant.software/blog/software-development-process/