Apa itu Isu Hukum yang Berkaitan dengan Server dan Infrastruktur Pembangunan Sistem?

Sistem IT yang digunakan dalam syarikat pada hakikatnya dibina dengan membuat spesifikasi dan dokumen reka bentuk, dan menulis kod sumber yang sepadan dengan kandungan tersebut. Namun, bukan hanya aspek lunak sahaja, sistem hanya akan berfungsi sebenarnya apabila ada komputer fizikal, iaitu infrastruktur. Dalam artikel ini, kami akan menerangkan tentang isu-isu undang-undang yang berkaitan erat dengan bidang infrastruktur dalam projek pembangunan sistem.

Apa Itu Infrastruktur dalam Sistem IT

Pakar teknologi yang menjalankan pembangunan sistem dikenali sebagai Jurutera Sistem (SE). Projek pembangunan biasanya bermula dengan proses hulu seperti pembuatan spesifikasi dan dokumen reka bentuk, diikuti oleh pelaksanaan program dan ujian. Secara umum, Jurutera Sistem (SE) dalam erti kata yang luas boleh dijelaskan sebagai pakar teknologi yang bertanggungjawab atas semua tugas yang diperlukan untuk ini. Walau bagaimanapun, bergantung kepada syarikat atau tempat kerja, tugas dan bidang yang dipegang mungkin dibezakan dengan lebih lanjut. Istilah ‘Jurutera Infrastruktur’ merujuk kepada pakar teknologi yang bertanggungjawab untuk mempersiapkan persekitaran operasi fizikal komputer, khususnya dalam konteks tugas yang berkaitan dengan pembangunan dan operasi sistem IT. Sistem IT yang digunakan dalam syarikat atau tempat kerja adalah struktur abstrak yang dibina daripada kombinasi kod sumber. Namun, untuk sistem ini berfungsi seperti yang diharapkan, pembinaan persekitaran infrastruktur seperti pelayan dan rangkaian adalah penting. Praktik pembangunan sistem bergerak maju dengan dua roda, iaitu pelaksanaan kod sumber program dan persiapan persekitaran infrastruktur yang menyokong persekitaran operasi. Perspektif ini dianggap penting untuk mencegah kejadian masalah yang tidak dijangka.

Apakah situasi spesifik di mana masalah infrastruktur menyebabkan projek terbakar?

Dalam projek pembangunan sistem, mungkin terjadi situasi di mana fokus hanya diberikan kepada reka bentuk program abstrak dan kod sumber, dan perspektif penyiapan infrastruktur diabaikan. Walau bagaimanapun, keadaan di mana kedua-dua elemen ini tidak sejajar boleh menjadi risiko projek terbakar.

Bagaimanakah kesalahan penentuan saiz server boleh menyebabkan konflik?

Sebagai contoh, selepas semua pelaksanaan dan ujian program selesai, mungkin ditemui bahawa prestasi pemprosesan server tidak mencukupi dan sistem tidak dapat digunakan secara praktikal. Penentuan saiz infrastruktur yang sesuai dengan skala sistem berdasarkan beban yang dijangka pada tahap operasi sistem dikenali sebagai ‘penentuan saiz’. Kes di mana konflik berkembang disebabkan oleh kesalahan dalam penentuan saiz server telah berlaku di masa lalu. (Walaupun akhirnya diselesaikan melalui penyelesaian, anda boleh merujuk kepada kes ini sebagai contoh terkenal.) Untuk penyelesaian konflik antara kedua-dua pihak melalui proses ‘penyelesaian’, sila rujuk kepada artikel berikut untuk penjelasan terperinci.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

Penyelesaian konflik melalui penyelesaian bermakna, dengan mudahnya, konflik telah diselesaikan melalui ‘perbincangan’ antara kedua-dua pihak. Oleh itu, berbeza dengan kes di mana keputusan diberikan oleh mahkamah, isi penyelesaian ini biasanya tidak dikumpulkan sebagai preseden dan biasanya mempunyai sifat individu yang kuat.

Inti pati kes adalah lingkungan kewajipan penjual untuk menangani spesifikasi yang tidak jelas

Walau bagaimanapun, inti pati konflik seperti ini boleh dianggap sebagai ‘sejauh mana penjual harus bertanggungjawab terhadap perkara yang tidak dinyatakan secara spesifik dalam spesifikasi’. Dengan mempertimbangkan perkara ini, anda boleh mendapatkan banyak petunjuk dari kandungan artikel berikut.

https://monolith.law/corporate/system-development-specs-function[ja]

Artikel di atas menjelaskan sejauh mana penjual harus menggunakan budi bicara dan memikul tanggungjawab pelaksanaan untuk perkara yang tidak dinyatakan dalam spesifikasi. Di sini, penulis menjelaskan bahawa cerita berbeza antara perkara ‘sisi skrin’ yang dapat dengan mudah divisualisasikan dalam dokumen definisi keperluan dan reka bentuk asas (bidang yang dikenali sebagai ‘front end’), dan ‘sisi logik’ seperti migrasi data (bidang yang dikenali sebagai ‘back end’ atau ‘database’). Dengan kata lain, dianggap bahawa ada kecenderungan untuk pihak pemberi perintah/pengguna (yang biasanya tidak mempunyai pengetahuan pakar tentang projek pembangunan sistem) untuk dipertanggungjawabkan lebih mudah untuk masalah spesifikasi yang dapat dikenal pasti dengan mudah di ‘sisi skrin’. Sebaliknya, dianggap bahawa ada kecenderungan untuk masalah ‘sisi logik’ dipertanggungjawabkan kepada penerima perintah/penjual. Dengan mempertimbangkan perkara ini, masalah penentuan saiz server dianggap sebagai bidang yang sukar untuk mengenali masalah kecuali jika anda adalah pakar teknologi, dan oleh itu, dianggap sebagai bidang yang cenderung dipertanggungjawabkan kepada penerima perintah/penjual. Oleh itu, jika anda benar-benar perlu berperang di mahkamah mengenai perkara ini, dijangka bahawa keputusan yang tidak menguntungkan pihak penerima perintah/penjual akan diberikan kecuali jika ada sebab yang kuat untuk membebaskan tanggungjawab pihak penerima perintah/penjual.

Langkah-langkah untuk Mengelakkan Masalah Akibat Kesilapan dalam Penyelarasan Saiz Pelayan

Untuk mencegah masalah seperti yang disebutkan sebelum ini, adalah penting untuk menyelaraskan langkah-langkah seperti pelaksanaan program dan penulisan kod sumber dengan persiapan persekitaran infrastruktur. Langkah-langkah khusus yang boleh dipertimbangkan adalah seperti berikut:

Menjelaskan tanggungjawab berkaitan dengan penyelarasan saiz pelayan dalam kontrak

Bukan hanya dalam kes-kes seperti ini, tetapi dalam banyak pertikaian berkaitan dengan projek pembangunan sistem, seringkali terdapat banyak kes di mana peranan dan tanggungjawab antara vendor yang merupakan pakar dalam pembangunan sistem dan pengguna yang memahami situasi dalam syarikat tidak jelas. Walaupun kerjasama rapat antara kedua-dua pihak adalah penting untuk kelancaran projek, adalah diharapkan agar peranan dan tanggungjawab masing-masing dapat diperjelaskan sebanyak mungkin dalam kontrak dan sebagainya.

Melakukan pengurusan perubahan dan penjelasan keperluan pembangunan dengan sempurna

Selain itu, jika keperluan fungsi yang sepatutnya direalisasikan adalah kabur, risiko pertikaian menjadi lebih tinggi. Ini melibatkan dua aspek: penjelasan spesifikasi dalam fasa definisi keperluan awal dan pengurusan perubahan di tengah-tengah projek. Bagaimana untuk menangani perubahan spesifikasi di tengah-tengah projek dijelaskan secara terperinci dalam artikel berikut.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Memilih model pembangunan yang sesuai dengan sifat projek

Selain itu, berkaitan dengan kedua-dua langkah-langkah di atas, adalah penting untuk memilih model pembangunan yang sesuai berdasarkan sifat dan skala projek pembangunan sistem. Secara umum, jika pembangunan sistem dengan skala tertentu di mana penyelarasan saiz pelayan mungkin penting, manfaat penggunaan model air terjun, yang sesuai untuk penjelasan spesifikasi dan lingkup tanggungjawab, dianggap meningkat. Mengenai pemilihan model pembangunan yang sesuai berdasarkan sifat projek, penjelasan terperinci diberikan dalam artikel berikut.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Rumusan

Masalah yang bermula dari persiapan persekitaran sekitar infrastruktur untuk kelancaran projek pembangunan sistem adalah titik yang mudah diabaikan. Dianggap bahawa memberi perhatian kepada masalah sekitar infrastruktur bukanlah beban yang kecil bagi orang lain selain pakar teknologi. Walau bagaimanapun, langkah-langkah pencegahan untuk masalah seperti ini boleh dikatakan sebagai lanjutan daripada langkah-langkah asas seperti ‘penjelasan spesifikasi / pengurusan perubahan yang teliti’, ‘penjelasan peranan / skop tanggungjawab’, dan ‘pemilihan model pembangunan yang sesuai dengan skala dan bajet projek’. Apa yang perlu difahami oleh mereka yang terlibat dalam undang-undang perniagaan adalah bahawa asas undang-undang pencegahan cukup untuk menangani masalah infrastruktur. Selain itu, bagi jurutera teknologi IT, memahami bahawa masalah infrastruktur boleh menjadi risiko serius yang boleh membakar projek dan penting untuk mengurus kerja dengan lancar dianggap penting.