Pertama, apa risiko kegagalan aplikasi tersebut karena peningkatan "tidak terkendali"?

 Jika tidak
'rendah' maka mungkin aplikasinya tidak tepat.

Jika risikonya dapat ditoleransi, saya sarankan Anda memantau (setiap minggu?) Untuk pemberitahuan
rilis dan, ketika ditemukan, lakukan evaluasi untuk menentukan apakah Anda masih dalam keadaan
tervalidasi atau jika tindakan diperlukan untuk membawa Anda kembali ke keadaan tervalidasi .

Tentu saja, dokumentasikan semuanya.

 Suka:j4zzQ

M.

MC Eistee

Mulai Terlibat

Sep 13, 2019

#3

Apa yang saya alami bahwa itu adalah sesuatu yang sulit untuk melalui semua catatan perubahan dan
mencari tahu apakah itu berdampak atau tidak.

Jika Anda beruntung, perubahan bulanan sudah dikelompokkan ke dalam kategori yang berbeda,
misalnya perbaikan bug, pembaruan keamanan, pembaruan fungsional. Perbaikan bug dan pembaruan
keamanan biasanya tidak dimaksudkan untuk mengubah fungsi yang ada sehingga bagian penting
adalah untuk melihat pembaruan fungsional. Masih juga pembaruan fungsional dapat bagi banyak orang
untuk benar-benar melihat atau sulit dimengerti.
Kemudian kembali ke validasi dasar. Selama validasi Anda harus mengidentifikasi persyaratan yang lebih
tinggi dari risiko rendah. Jadi, Anda perlu melihatnya tepat setelah pembaruan.

 Suka:yodon

Enternasionalis

Terdaftar

Yesterday at 4:10 AM

#4

Kami menggunakan beberapa layanan seperti ini, dan menemukan kesulitan yang sama. Perubahan
didorong kepada kami tanpa kemampuan untuk menunda atau bernegosiasi.

Bagian pertama dari jawaban (bagi kami) adalah untuk memastikan kontrak dan perjanjian dengan
penyedia tersebut memadai (yaitu, lihat apakah Anda bisa mendapatkan syarat dan ketentuan tertentu
yang melindungi Anda dari efek perubahan, serta peringatan awal yang cukup dari rilis
tersebut. ). Bergantung pada kebijakan mereka, Anda mungkin dapat membuat keputusan berbasis
risiko (mis. Rilis perangkat lunak kecil mungkin hanya membutuhkan sedikit usaha, sementara
perubahan versi besar mungkin memerlukan pengujian ulang)

Bagian kedua dari jawabannya adalah meminta penyedia untuk memberikan kepada kami salinan
dokumen validasi internal mereka ketika mereka membuat rilis baru - Anda masih harus melakukan
kegiatan untuk mempertahankan status yang divalidasi, tetapi Anda dapat menurunkan risiko dan upaya
yang diperlukan dengan menerima dokumentasi yang ada jika masuk akal.

Bagian ketiga adalah kegiatan yang sangat berbasis risiko - mengambil penilaian risiko yang jujur dari
aplikasi perangkat lunak, dan menentukan fitur apa (jika ada) yang dapat dimodifikasi dengan risiko yang
dapat diabaikan, dan memungkinkan perubahan itu tidak mengganggu keadaan tervalidasi kecuali
beberapa tertentu masalah diidentifikasi. Kami selanjutnya akan menentukan antarmuka perangkat
lunak mana yang sangat penting. Ketika perubahan terjadi, kami akan menerapkan kontrol risiko
tambahan pada antarmuka tersebut untuk menjaga output tetap valid sementara dokumentasi validasi
terperinci kami menyusul, tanpa harus berhenti menggunakan perangkat lunak. (mis., jika perangkat
lunak secara otomatis menambahkan beberapa tanda pada salah satu dokumen Anda, Anda mungkin
memiliki sementara staf berkualitas secara manual memverifikasi bahwa output pada dokumentasi
sampai validasi ulang selesai).

Saya harap penggunaan Anda cukup berisiko rendah; bahkan dengan metode di atas untuk menjaga
agar pekerjaan tetap masuk akal, dibutuhkan sejumlah sumber daya yang mengejutkan untuk benar-
benar mempertahankan status tervalidasi pada perangkat lunak yang terus diperbarui. Jika aplikasi
berisiko sangat rendah, Anda ingin menjustifikasi tingkat upaya yang rendah kecuali jika ada masalah
yang diamati - jika aplikasi berisiko cukup tinggi, Anda mungkin ingin mempertimbangkan layanan yang
lebih stabil.

Ronen E

Pemecah masalah

Anggota staff

Super Moderator

Yesterday at 7:32 AM

#5

MC Eistee berkata:

Perbaikan bug dan pembaruan keamanan biasanya tidak dimaksudkan untuk mengubah fungsi yang ada

Bukankah seluruh titik dalam memvalidasi sesuatu memastikan bahwa hal-hal itu sebenarnya apa
artinya?

Enternasionalis
Terdaftar

Yesterday at 5:10 PM

#6

Ronen E berkata:

Bukankah seluruh titik dalam memvalidasi sesuatu memastikan bahwa hal-hal itu sebenarnya apa
artinya?

Tentu saja - saya pikir MC tidak menyiratkan bahwa Anda tidak akan melihat pembaruan tersebut, tetapi
bahwa Anda akan menerapkan pengawasan dan prioritas yang lebih besar untuk perubahan fungsional
yang lebih besar (seperti halnya dengan penilaian dampak perubahan), karena risiko yang memengaruhi
aplikasi perangkat lunak Anda pada dasarnya lebih besar. Atau setidaknya itulah yang saya bayangkan
maksud mereka!

Anda harus masuk atau mendaftar untuk membalas di sini.

Bagikan:KericauRedditPinterestTumblrAda apaSurelTautan

Pemula thread Utas serupa Forum

R Validasi perangkat lunak - dari rak X-Ray Jaminan Kualitas Perangka

Y Validasi Perangkat Lunak OTS (Off The Shelf) untuk 510rb Tradisional 21 CFR Bagian 820 - Peratu

T Validasi Perangkat Lunak OTS (Off The Shelf) di Perangkat Medis IEC 62304 - Proses Siklus H

C Validasi Perangkat Lunak Pelatihan OTS (Off-the-Shelf) - Diperlukan? Kualifikasi dan Validasi (te

saya Validasi perangkat lunak komersial - Spreadsheet ISO 13485: 2016 - Sistem M