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.
Mục lục
Mục lục
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:
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ó:
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ạ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.
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.
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.
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ì.
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.
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 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à:
Đố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.
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ì.
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:
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 đ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ệ.
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ý.
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.
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.
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ứ.
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.
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.
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.
Đ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:
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.
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.
Đế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:
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.
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ế 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 để:
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 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 để:
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.
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.
Để đ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:
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.
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 để:
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.
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.
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:
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.
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:
Đó 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:
Đó 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.
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:
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.
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.
Đ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ả.
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.
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.
Đ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.
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ì:
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:
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:
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ì.
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:
Đâ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 .
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.
Nguồn: https://relevant.software/blog/software-development-process/
Những tiến bộ nhanh chóng trong công nghệ đã tác động đáng kể đến xu… Đọc thêm
Trong thế giới thương mại điện tử không ngừng phát triển, việc đi trước đón… Đọc thêm
Công ty công nghệ BEIT là một trong những doanh nghiệp tiên phong trong lĩnh… Đọc thêm
Đối với người dùng không chuyên, việc tạo hình ảnh bắt mắt từng là một… Đọc thêm
Cách cải thiện SEO cho trang web của bạn, tăng thứ hạng tìm kiếm và… Đọc thêm
1. Khám phá các tùy chọn Elementor Chúng ta sẽ sớm xem xét việc xây… Đọc thêm
This website uses cookies.