Phần mềm tương đương với một lệnh thay đổi kỹ thuật là gì?

Chúng tôi có một thiết bị mà chúng tôi đang xem xét thực hiện cập nhật phần mềm trên một vi điều khiển kim loại trần. Hình ảnh mới sẽ được lập trình trên tất cả các sản phẩm trong tương lai.

Nếu tôi thay đổi một thành phần trên thiết bị, tôi sẽ cần phải điền vào một thứ tự thay đổi kỹ thuật.

Có một quy trình công nghiệp tương đương khi thay đổi phần mềm?

Tôi vẫn gọi nó là ECO.

Nếu phần sụn được lập trình vào micro trong nhà máy, thì phần sụn đó và phiên bản cụ thể của nó sẽ là một mục hàng trên BOM.
Thay đổi phần sụn có nghĩa là thay đổi BOM.
Thay đổi BOM yêu cầu ECO.

Tiếp theo đó, một bản cập nhật trường của chương trình cơ sở sẽ tuân theo một quy trình tương tự với quy trình sẽ được tuân theo nếu một mod cho phần cứng được yêu cầu cho một đơn vị trong trường.
Vì vậy, nếu bạn gọi đó là ECO, thì đây cũng là ECO.

Thông thường, một sự thay đổi phần mềm được gọi là Bản vá hoặc (Cập nhật phần mềm). Và theo như tôi biết (tùy thuộc vào công ty), các quy trình được gọi là Quy trình cập nhật bản vá hoặc phần mềm.

Tuy nhiên, trong hầu hết các trường hợp, các bản cập nhật phần mềm không nhiều hơn là chạy một ứng dụng đặc biệt đảm nhiệm việc cài đặt và tất cả các chuyển đổi cần thiết, v.v. là một phần của bản vá.

Vì vậy, không giống như trao đổi bộ phận điện tử, không có phần mềm hiện tại thông thường phải được gỡ cài đặt hoặc thay đổi, bởi vì nó là một phần của chính phần mềm vá lỗi.

Ngoài ra, trong trường hợp có các hạn chế hoặc điều kiện khi cập nhật bản vá / phần mềm có thể hoặc không thể cài đặt, nó sẽ được kiểm tra trong bản vá và sẽ chỉ cài đặt khi cài đặt hợp lệ (hoặc ít nhất, nó sẽ hoạt động theo cách đó ).

Vì vậy, về nguyên tắc, bản cập nhật bản vá / phần mềm thực hiện rất nhiều thứ, như (có thể không hoàn thành):

• Kiểm tra xem bản cập nhật bản vá / phần mềm có thể được cài đặt không (ví dụ: Phiên bản hệ điều hành, phiên bản hiện tại đã cài đặt, v.v.)
• Nếu không, một thông báo sẽ được hiển thị và bản vá / cập nhật dừng lại.
• Nếu có thể cài đặt, các tệp cần chuyển đổi sẽ được thực hiện (đôi khi đây là một phần của ứng dụng chính được vá / cập nhật).
• Các tập tin mới được cập nhật hoặc thêm vào ứng dụng sẽ được cập nhật / vá.
• Ghi chú phát hành được hiển thị (tùy chọn).
• Ứng dụng được bắt đầu (tùy chọn).

Các thuật ngữ tôi thường sử dụng là Yêu cầu thay đổi đối với những thứ cần thay đổi do yêu cầu sửa đổi và Báo cáo sự cố cho những thứ cần thay đổi do lỗi.

Chúng được thu thập, và sau đó lên lịch cho các chu kỳ cập nhật cụ thể. Nếu một chu trình chỉ là nội bộ, nó được gọi là Cột mốc , nếu nó được triển khai cho khách hàng, nó được gọi là Bản phát hành .

Một dòng thời gian điển hình có một vài mốc quan trọng trước khi phát hành, được gọi là Ứng viên phát hành trải qua thử nghiệm rộng rãi và bất kỳ lỗi nào được tìm thấy ở đó sẽ tạo thêm Báo cáo sự cố được lập lại cho cột mốc tiếp theo nếu chúng đủ quan trọng hoặc nếu không phát hành sau.

Cũng có thể tạo một Chi nhánh chỉ giải quyết các PR cụ thể để đáp ứng với khiếu nại của khách hàng, với một bản phát hành riêng biệt không có thay đổi gì thêm, với hy vọng rằng sẽ có ít lỗi hơn được giới thiệu ở đây. Điều này thường chỉ được thực hiện nếu nỗ lực cập nhật đủ thấp (ví dụ: vì các bản cập nhật có thể được cài đặt đơn giản bằng cách cắm vào thẻ USB với một tệp có tên nhất định trên đó).

Câu trả lời ngắn: Nó được tích hợp vào hệ thống phiên bản phần mềm.

Câu trả lời dài:

Phần mềm có xu hướng thay đổi nhanh hơn nhiều so với phần cứng. Thông thường phần mềm sử dụng một số loại hệ thống kiểm soát phiên bản (VCS), như Git phổ biến. Hầu hết các công ty phần mềm tôi đã làm việc với việc sử dụng một VCS để theo dõi các thay đổi đối với phần mềm, với mỗi cam kết giải thích lý do đằng sau sự thay đổi. Một số cũng sử dụng trình theo dõi vấn đề, theo dõi các lỗi đã biết, các cải tiến và như vậy. Thông thường có một quá trình tại đó sự phát triển xảy ra trên một nhánh, sau đó sự phát triển đó được kiểm tra trước khi được sáp nhập vào một nhánh "chính" (phát hành). Điều này có xu hướng hiệu quả hơn nhiều đối với tần suất thay đổi cao trong phát triển phần mềm so với nhịp độ chậm hơn trong phần cứng. Việc triển khai và quy trình cụ thể của việc này thay đổi tùy theo từng công ty và thường bị ảnh hưởng bởi một tiêu chuẩn cho các mục đích QA (ISO 9001, AS9100D, v.v.).

Một ví dụ:

1. Bạn quyết định thực hiện một sự thay đổi.

2. Bạn tạo một vấn đề trong trình theo dõi vấn đề.

3. Bạn tạo một chi nhánh để giải quyết vấn đề.
4. Bạn thực hiện một số thay đổi phần mềm.
5. Bạn có các thay đổi được xem xét ngang hàng theo chính sách của công ty
6. Bạn đưa ra một yêu cầu kéo và hợp nhất trở lại vào nhánh dev.
7. Bạn đóng vấn đề.

Trong cài đặt công nghiệp được chạy đúng, phần sụn được flash vào vi mô tự nó là một phần và có một số phần cho tệp thực thi cụ thể đó (tệp hex hoặc bất cứ thứ gì). Nếu bạn muốn thay đổi phần sụn, đó là thay đổi đối với BOM (hóa đơn vật liệu). Và điều đó cần một ECO theo cách tương tự như khi bạn muốn thay thế một con chip.

Nó thực sự đơn giản như vậy.

Có một hệ quả tất yếu. Nếu phần sụn của bạn không có số phần và không được liệt kê trong BOM và do đó không được kiểm soát, thì quy trình chất lượng của bạn có thể cần được cải thiện. Nếu bạn phải đáp ứng ISO-9001 hoặc một cái gì đó tương tự, thì đây là một khoảng cách nhất định trong quy trình của bạn cần sửa chữa.

Cập nhật phần mềm được gọi là bản vá hoặc chúng là "bản cập nhật phần mềm". Tôi luôn hỏi các kỹ sư phần mềm nếu đơn vị được cập nhật "lên phiên bản mới nhất".

Phiên bản lý tưởng được "ký" tắt bởi các bên liên quan và được thử nghiệm trước khi nó được đưa vào sản xuất, nhưng thường xuyên hơn không phải ở hầu hết các nơi, thực tế này chỉ xảy ra hầu hết thời gian.