Tư vấn CNTT

COCOMO là từ viết tắt của COstructive COst MOdel, đây là phương pháp được sử dụng rộng rãi nhất trong software estimation trên thế giới. Mô hình COCOMO dự báo số effort và duration của một Project dựa vào đầu vào liên quan đến kích thước của kết quả hệ thống và một số "cost drives" ảnh hưởng đến Productivity.

Warning: những ai vướng phải bài toán fixed-price, fixed-cost, fixed-date có thể sẽ không tìm kiếm được lời giải trong bài toán “ước tính chi phí” trong bài viết này. Bài này chỉ ra cách thức tính toán chi phí theo cách của Scrum với giả định bạn đã có sẵn một Scrum Team, có thể không tương thích với cách làm của bạn hiện nay

Như chúng ta đã biết, bất kỳ một sản phẩm nào được thiết kế đều có nghiệp vụ riêng của nó. Đi từ nghiệp vụ đơn giản đến phức tạp, từ nghiệp vụ quen thuộc áp dụng trên toàn các sản phẩm đến các nghiệp vụ được xây dựng thiết kế riêng... Vậy chuyện gì xảy ra nếu chúng ta đi sai nghiệp vụ?

Khi thuê một đơn vị phát triển phần mềm để xây dựng một ứng dụng, có lẽ một trong những mối quan tâm lớn nhất của bạn là giá cả. Đúng vậy - bạn cần một khoản ngân sách khá lớn để thuê một nhóm các nhà phát triển có kinh nghiệm để xây dựng Web hoặc app trên điện thoại thông minh. Nhưng có những mô hình định giá khác nhau mà bạn có thể chọn. Các lựa chọn có thể dựa trên số tiền bạn có và phạm vi các yêu cầu của dự án. Trong bài viết này chúng ta sẽ phân tích ưu và nhược điểm của mô hình nhóm chuyên trách như vậy (Dedicated Team).

Các thuật ngữ đôi khi gây nhầm lẫn do có sự tương đồng về đặt tên viết tắt, mặc dù khác nhau hoàn toàn về bản chất cũng như mục đích. Hãy cùng TIGO tìm hiểu về các sự khác nhau này.

Lịch sử của các phương pháp luận phát triển phần mềm bắt đầu từ những năm 1950. Cho đến lúc đó các thuật ngữ như “framework” và “methodology” không thực sự tồn tại. Những ngày đó, vòng đời phát triển hệ thống được coi là khung phương pháp luận duy nhất được chính thức công nhận.

Chuyện có thật về các tình huống đối mặt giữa team dự án phần mềm và khách hàng - những người tạo ra thay đổi (CR).

Phạm vi của yêu cầu thay đổi là bao nhiêu. Một yêu cầu thay đổi có thể liên quan đến kinh doanh, các bên liên quan hay các yêu cầu chức năng. Bước này khá giống với việc khám phá các yêu cầu mới cho dự án ở giai đoạn đầu. Bạn sẽ muốn tất cả các bên liên quan bị ảnh hưởng tham gia vào việc nêu ra yêu cầu của sự thay đổi, phân tích các yêu cầu đó và xác thực chúng.

Technical Debt (Nợ kĩ thuật) là một món nợ mà hầu như lập trình viên nào cũng phải gánh trong quá trình làm việc. Nhưng để hiểu đúng bản chất và biến chúng thành cơ hội thì không phải ai cũng nhận thức và hành động được.

Phát triển phần mềm có nhiều vấn đề rất khó dự đoán và khó lập kế hoạch một cách rõ ràng. Về bản chất, phát triển phần mềm có nhiều điều mơ hồ và có nhiều bên liên quan. Sự kết hợp của các yếu tố này có thể tạo ra một số rủi ro cần được xem xét và quản lý ngay khi bắt đầu dự án.