Kenapa tepatnya rumah sakit?

Kenapa tidak Ini adalah contoh yang bagus. Proyek ada di mana-mana proyek: plus atau minus tahapan yang sama, skema manajemen yang sama, manajemen dokumen, manajemen risiko, kontrol kualitas dan sebagainya. Di mana-mana ada persyaratan untuk peralatan, dan untuk tempat, dan untuk perangkat lunak. Anda bertanya, apa yang mungkin menjadi persyaratan untuk bangunan di Sistem Informasi? Sangat sederhana: lokasi stasiun kerja operator, server - keduanya membutuhkan AC. Berikut persyaratan untuk tempat tersebut. Dan sekarang hampir tidak ada yang meragukan apakah rumah sakit membutuhkan perangkat lunak. Jika Anda ingin tetap up to date, Anda akan dihadapkan dengan tugas untuk menciptakan institusi medis otomatis dengan catatan medis elektronik, di mana dokter melakukan pemeriksaan dengan tablet, dan, misalnya, perawat menandai toilet yang dicuci bukan di atas kertas, tetapi di telepon. Akan ada banyak persyaratan perangkat lunak dalam kasus ini. Dan segera setelah perangkat lunak diperlukan, akan ada kebutuhan untuk menginstal server, menempatkan admin dan operator di suatu tempat. Semuanya saling berhubungan.

Kami memilih proyek konstruksi karena paling mudah menunjukkan bagaimana mendesain IP. Sistem informasi disembunyikan di suatu tempat di dalam, kami tidak melihatnya, dan dinding ada di sini di depan kami: melengkung dan miring, dengan koridor buntu, karena proyek dilakukan pada lutut, dan pelanggan mengubah persyaratannya seratus kali selama bermain.

Kode program di dalam (tetapi tidak ada yang melihat ini)

Apa hubungan rumah sakit dengan itu jika kita mengembangkan perangkat lunak?

Dan ini dia, pengembang, eksekutif, analis, penguji.

Bukan perangkat lunak yang Anda kembangkan ... Ambil Android, ini adalah perangkat lunak. Dan jika, misalnya, Anda memiliki sistem akuntansi, maka Anda sudah berurusan tidak hanya dengan perangkat lunak, tetapi dengan SISTEM INFORMASI.

Perbedaannya jelas. Jika Anda membeli telepon, semuanya sederhana: hidupkan, orang hijau (Android) mulai, gunakan. Dan jika Anda membeli sebuah kotak dengan perangkat lunak akuntansi, maka jelas bahwa sekarang Anda memerlukan server, Anda perlu mengkonfigurasi jaringan, mengkonfigurasi workstation, melatih karyawan, mengintegrasikan sistem dengan IP perusahaan lain, dan menggerakkan sistem dalam mode uji. Ya, dan akuntan perlu dibujuk untuk beralih ke perangkat lunak baru, tidak semuanya siap untuk inovasi. Secara umum, dalam setiap proyek TI, 10-20% adalah TI, dan yang lainnya adalah tindakan organisasi dan administrasi, well, sangat padat, perhiasan, bekerja dengan staf.

Sistem informasi (apakah ini hanya perangkat lunak?)

Dan akhirnya, kita ingat definisi sistem dari tahun 90-an yang jauh, yang tidak ada yang membatalkan:

Sistem otomatis: sistem yang terdiri dari personel dan seperangkat alat otomasi untuk kegiatannya yang mengimplementasikan teknologi informasi untuk melakukan fungsi yang telah ditetapkan.

GOST 34.003-90. Teknologi informasi. Seperangkat standar untuk sistem otomatis. Sistem otomatis. Ketentuan dan definisi.

Artinya, IP di tempat pertama adalah orang, ditambah teknologi yang membantu mengotomatiskan kegiatan mereka, dan bukan sebaliknya.

Cara mendesain rumah sakit

Bayangkan Anda adalah organisasi konstruksi, pelanggan mendatangi Anda dan meminta untuk membangun rumah sakit di tempat seperti itu. Anda segera berlari untuk meletakkan batu bata atau ...? Jika Anda melihat seberapa sering Sistem Informasi dibuat, maka itu adalah: pelaku segera mulai "mengganggu beton dan membeli paket kaca". Seperti, itu tidak akan berjalan seperti itu - kami akan membangun kembali! Kami akan membangun kembali sampai kami mencapai hasil yang diinginkan.

Namun, jika Anda adalah organisasi yang serius, maka pertama menawarkan kepada pelanggan DESIGN untuk konstruksi. Apakah kamu setuju? Dan mengapa salah dengan Sistem Informasi? Mungkin itu bukan perbedaan antara konstruksi dan pengembangan perangkat lunak, tetapi bahwa dalam kasus rumah sakit yang sama, mereka banyak berpikir, merencanakan, lalu membangun, dan mereka pertama kali mengembangkan dan kemudian berpikir perangkat lunak? Bukankah itu sebabnya Anda mendengar banyak tentang programmer krivoruky, tetapi tidak ada tentang pekerja migran yang sama di lokasi konstruksi? Pembangun bekerja di proyek, tidak seperti pengembang.

Selalu seperti itu tanpa proyek, walaupun itu tidak terlihat

Kami sekarang mempertimbangkan proses desain secara lebih rinci. Ada beberapa tahapan. Mengapa kita perlu melewati beberapa tahap, mengapa tidak melakukannya sekaligus? Untuk kejelasan, saya akan memberikan contoh sekolah ... Berapa tahun di sekolah telah mempelajari operasi perkalian? Anda mengatakan satu atau dua bulan, dan Anda pada dasarnya salah. Ya, bagaimana mengalikan 5 dengan 6, lulus dalam seminggu. Waktu tertentu diajarkan tabel perkalian. Dan penggandaan fraksi, angka dengan gelar, logaritma, ekspresi dalam tanda kurung, angka kompleks, naik ke tingkat berapa banyak orang belajar? Hampir sepanjang tahun sekolah! Ternyata kami mempelajari perkalian yang sama setiap tahun dari sudut yang berbeda.

Dan mengapa ini tidak dipelajari di kelas satu?

Jadi, setiap proses belajar dan mendesain adalah siklus. Pertama, kami mendapat konsep umum tentang angka, kemudian kami belajar bagaimana melakukan tindakan sederhana dengannya, kemudian kami belajar tentang pecahan dan belajar cara bekerja dengannya, dan seterusnya.

Pertama, kami menyadari masalah apa yang harus diselesaikan dengan bantuan Sistem Informasi. Kemudian kami menentukan lingkaran tugas yang harus diselesaikan, memahami apa yang harus dilakukan sistem, tindakan apa yang harus dilakukan personel. Kemudian mereka memikirkan BAGAIMANA sistem harus memenuhi tugas-tugas yang didefinisikan sebelumnya. Anda dapat melewati langkah-langkah ini, Anda hanya perlu kembali dan mengulang semuanya: mengukur tujuh kali dan memotong sekali lebih cepat daripada sebaliknya, dan lebih sedikit material yang tersisa.

Kami berikan contoh lain. Anda berada di puncak gunung yang melihat ke bawah dengan teropong yang kuat dan mencoba membuat rute turunan yang terperinci. Di eyepieces, Anda dapat melihat setiap kerikil di jalan, setiap genangan air. Tapi di sini ada jalan ini dan apakah mengarah ke puncak dengan teropong tidak terlihat: tidak ada rencana umum. Pendaki yang masuk akal pertama-tama akan menguraikan jalur keturunan dengan mata telanjang, dan kemudian mereka akan diperiksa di bawah pembesaran yang kuat. Segera setelah Anda terjun ke detail, Anda kehilangan pandangan umum tentang proyek. Mengambil spyglass segera, Anda idealnya menggambarkan 10 fungsi, sementara melupakan 40 fungsi lainnya, dan umumnya tidak menyebutkannya.

Itu bisa dilihat dengan baik, tetapi hanya sebagian kecil

Kompleksitas desain bertahap adalah bahwa pada awal proses Anda harus beroperasi dengan konsep abstrak. Jadi saya ingin "merasakan" sesuatu yang siap, dan tidak berbicara tentang persyaratan, fungsi, tugas, proses tertentu. Menggambar antarmuka pengguna segera lebih sederhana, tetapi juga lebih mudah untuk melewatkan setidaknya setengah dari persyaratan. Jika pada awalnya kita membuat daftar operasi yang harus dilakukan pengguna ketika bekerja dengan satu atau beberapa bentuk layar, maka perancang hanya perlu menggambar, dan tidak berfantasi, seperti yang sering terjadi.

Sekarang akhirnya beralih ke tahap desain.

1. Menyusun persyaratan umum

Jadi, katakanlah Anda seorang desainer. Seorang pelanggan mendatangi Anda, “dikirim” oleh pembangun yang bertanggung jawab. Pelanggan secara alami meminta Anda untuk mengembangkan proyek rumah sakit. Anda lari ke Kuhlmann dan ... Ya, ini adalah barang antik - luncurkan ArchiCAD dan gambar.

Tapi tentu saja ini bukan tentang kamu. Anda seorang profesional dan mulai mengajukan banyak pertanyaan "bodoh". Dan yang paling penting dari mereka - mengapa Anda perlu membangun rumah sakit? Apa tujuan pembangunan? Jika tujuannya tidak jelas, maka Anda tidak akan dapat menjawab pertanyaan, apakah itu rumah sakit besar atau kecil, dari profil apa, daripada dilengkapi. Sayangnya, pelanggan sering mengatakan banyak hal menarik, kecuali hal utama - apa tujuan mereka. Di sini perlu untuk "menarik" keluar dari mereka di tempat pertama. Dan Anda harus mengajukan pertanyaan. Pelanggan sendiri bukan spesialis, ia punya ide, dan dalam hal ini ia melihat perannya terpenuhi. Dia tidak mengerti jalan apa yang diperlukan untuk mewujudkan idenya. Sebagai aturan, pelanggan mengharapkan keajaiban tua yang baik - untuk datang ke pantai, melempar jaring (membayar uang), menangkap ikan, dan dia akan memenuhi keinginannya ... Tapi itu terjadi seperti lelucon tentang seorang pria kaya yang, setelah menangkap ikan mas, diminta memenuhi satu keinginan: " Saya ingin semuanya menyertai saya! " "Tidak masalah," jawab ikan itu, "kamu memiliki segalanya ..."

Untuk memahami tujuan proyek, tidaklah cukup untuk membuat beberapa kalimat dengan seperangkat frase standar. Tujuan suatu proyek biasanya ditentukan atas dasar oposisi: mereka menggambarkan model informasi yang ada (misalnya, orang duduk di arsip dan memilah-milah kertas), kemudian kekurangannya (karena kurangnya otomatisasi, 10 orang terlibat dalam arsip, yang jelas berlebihan, departemen lain tidak dapat menerima selama berminggu-minggu) dari arsip informasi yang mereka butuhkan, dll.) dan menawarkan solusi (untuk memperkenalkan perangkat lunak yang akan memungkinkan sejumlah operasi dilakukan dalam mode otomatis, operasi harus terdaftar). Jika jenis layanan yang sama sekali baru diperkenalkan ke pasar, maka perlu untuk mempelajari pasar yang ada dan "mengkritik" alat yang tersedia di sana, kemudian mengusulkan solusi.

Selain itu, pada tahap ini perlu untuk menentukan persyaratan legislatif apa yang harus diperhitungkan, bagaimana menjalankan operasi tertentu secara hukum, bagaimana layanan baru akan dimonetisasi, bagaimana direncanakan memasuki pasar, bagaimana menarik minat peserta eksternal dari sistem baru.

Dengan kata lain, model bisnis harus dibuat. Di satu sisi, ini bukan tugas pengembang, tetapi, di sisi lain, tanpa definisi tujuan yang jelas dan cara mengimplementasikannya, tidak jelas tugas apa yang harus diselesaikan sistem. Dan jika pelanggan sendiri belum merumuskan dengan jelas apa yang dia butuhkan, dia tidak mungkin puas dengan setidaknya beberapa hasil.

2. Memilih konsep sistem

Pada tahap ini, perlu untuk memilih solusi teknis umum yang dengannya persyaratan yang dibuat pada tahap sebelumnya dapat dipenuhi. Apakah itu aplikasi web atau asli, klien tebal atau database tipis, terpusat atau terdistribusi, DBMS relasional atau noSQL, monolith atau layanan mikro, Java atau Python. Seringkali masalah ini dilupakan untuk dibahas tepat waktu, dan kemudian ternyata salah satu programmer secara mandiri memilih alat tertentu, dan pada akhirnya solusi ini tidak memungkinkan untuk mencapai tujuan.

3. Pengembangan Kerangka Acuan

Persyaratan umum dibuat untuk rumah sakit, memilih konsep. "Yah," pelanggan akan berkata, "sekarang semuanya jelas, Anda bisa menggambar." Apakah mungkin? Persyaratannya bersifat umum, persyaratannya harus rinci. Misalnya, pada langkah pertama, Anda menentukan bahwa harus ada laboratorium tes darah. Tapi apa jenis peralatan yang akan ada, berapa banyak mengkonsumsi listrik, udara terkompresi (bagaimana jika?), Apakah Anda memerlukan lampu kuarsa untuk desinfeksi, meja laboratorium, ventilasi? Tanpa ini, akan sulit untuk dirancang. Ini yang pertama. Dan kedua, perlu untuk meresepkan rencana untuk membangun rumah sakit, mempersiapkan dan menjalankannya.

Untuk Sistem Informasi, pengembangan TOR ( Kerangka Acuan ) adalah bagian utama dari proyek. Kerangka acuan menggambarkan:

1. APA yang harus dilakukan sistem.
2. Apa yang seharusnya menjadi keseluruhan struktur sistem.
3. Cara membuat sistem.

Artinya, TOR berisi persyaratan fungsional dan non-fungsional, serta persyaratan untuk tahap pengembangan, pengiriman, penerimaan, dokumentasi. Juga dalam Kerangka Acuan harus dijelaskan secara singkat proses yang benar-benar kita otomatisasi.

Ketika menggambarkan fungsi sistem (dan ini adalah bagian utama dari TOR) itu harus dipahami - kami memberikan persyaratan untuk APA yang harus dilakukan sistem, dan bukan BAGAIMANA. Bagi Anda, luasnya cakupan harus lebih penting daripada mendalam. Misalnya, pada tahap pertama (persiapan persyaratan umum), kami mengidentifikasi kebutuhan akan fungsi pemblokiran login pengguna. Pernyataan kerja menunjukkan bahwa akun diblokir jika tidak digunakan selama 90 hari atau setelah 6 upaya login gagal, akses dapat dibatasi oleh administrator untuk jangka waktu tertentu, ketika mencoba memasukkan pengguna yang diblokir, pesan harus ditampilkan, dll. Dan dalam proyek teknis (mari kita maju dari diri kita sendiri), kita akan menggambar maket kartu pengguna dengan bendera kunci dan tanggal buka kunci, menulis skrip untuk masuk ke sistem, yang akan memeriksa pemblokiran, secara otomatis membuka setelah periode tertentu, memblokir jika ada upaya login yang gagal; mari kita tentukan apa yang dilakukan di sisi klien dan apa yang dilakukan di sisi server.

Saya ingin menyanggah beberapa mitos yang terkait dengan pengembangan spesifikasi teknis .

Mitos satu: TK hanya memuat persyaratan untuk kontraktor.

Tidak, TK adalah cara membuat sistem, dan ada bagian dalam kerangka acuan di mana pembagian tanggung jawab dapat dijelaskan.

Mitos kedua: Dalam Kerangka Acuan sering ada banyak "air".

Memang, sering TK berisi informasi umum tentang sistem, tetapi mereka diperlukan. Sebagai contoh, kami membahas dan membahas persyaratan untuk sistem, sebagai hasilnya, satu tim menyadari bahwa perlu untuk mengembangkan aplikasi untuk Windows, dan yang lainnya untuk browser. Satu mengira sistem itu disebut itu, dan yang lainnya nama yang berbeda. Tampaknya hal-hal yang jelas, tetapi mereka harus dipahami sama oleh semua anggota tim dan semua spesialis yang terlibat.

Mitos tiga: Persyaratan untuk staf, server, saluran komunikasi, mode operasi administrator berlebihan, karena mereka berada di bidang tanggung jawab pelanggan.

Pertama, seperti yang telah kita bahas, TK ditulis untuk semua orang sekaligus, dan kedua, TK menjelaskan cara membuat sistem bekerja, dan tidak hanya perangkat lunak yang ditulis. Kalau tidak, akan ada kotak lain tergeletak di rak dengan disk dan instruksi tebal. Dengan demikian, bagian organisasi TK, persyaratan non-fungsional, tidak kalah penting daripada persyaratan fungsional.

Kami mempertimbangkan persiapan TK secara lebih rinci dalam artikel terpisah. Pengembangan Kerangka Acuan sesuai dengan GOST 34 sederhana dan mudah .

4. Pengembangan proyek teknis

Jadi, lanjutkan. Di sini di depan Anda (kami mengakui bahwa Anda seorang desainer). Kerangka Acuan untuk pembangunan rumah sakit dengan daftar persyaratan yang sangat besar. Anda duduk, lihat dengan sedih 100 halaman TK, dan tidak tahu harus mulai dari mana. Kemudian gambar itu secara bertahap mulai cerah. Anda berpikir: ya, kita membutuhkan begitu banyak meter di bawah bangsal, begitu banyak di bawah dapur, begitu banyak di tempat istirahat, laboratorium, ruang perawatan dan sebagainya dan seterusnya. Kemudian banyak sketsa, sketsa, opsi lahir, Anda membuat ulang, bertukar kamar, singkatnya, mencari rasio terbaik. Lalu pergi ke detail - gambar, gambar, cetak biru: dinding, pintu, jendela, saluran kabel, kabel, pipa, ventilasi, lantai, bahan dinding, selesai ... dan seterusnya dan seterusnya dan seterusnya. Secara umum, sedetail mungkin, garis besar bagaimana rumah sakit harus terlihat dan berfungsi setelah konstruksi selesai.

Ketika mengembangkan proyek teknis Sistem Informasi, diperlukan dokumen yang berisi hal-hal berikut: skenario terperinci yang menggambarkan operasi dan interaksi sistem yang dikembangkan, pengguna dan sistem terkait; tata letak terperinci antarmuka pengguna yang berisi deskripsi tipe data dan perilaku setiap elemen antarmuka (nilai default, kondisi di mana Anda dapat mengubah nilai bidang, visibilitas, tindakan yang dilakukan oleh sistem saat elemen berubah, dll.); deskripsi protokol untuk integrasi dengan sistem dan peralatan terkait, formulir laporan dan deskripsi algoritma untuk pembentukannya, struktur server dan database, jika ada beberapa.

Biasanya ini lebih dari cukup untuk dapat memberikan dokumen kepada pengembang dan mendapatkan hasil yang waras. Maket dan skrip terperinci menyediakan informasi yang cukup tentang perilaku sistem dan antarmuka, serta struktur data. Pengembang akan ditempatkan dalam kerangka kerja yang ketat di mana Anda dapat berfantasi, tetapi kemudian tidak akan keluar.

Saya harap dalam artikel-artikel berikut kita akan memeriksa secara lebih rinci bagaimana melakukan desain teknis dengan cara yang berkualitas tinggi, bagaimana mengembangkan mock-up, skenario, dan dokumen mana yang perlu disusun.

5. Pengembangan dokumentasi kerja

Pertanyaan logisnya adalah apa dokumentasi kerja untuk rumah sakit? Benarkah instruksi untuk membersihkan koridor ?! Bercanda sebagai lelucon, apakah Anda perlu memelihara sistem kebakaran? Itu perlu. Dan liftnya? Bagaimana dengan jaringan komputer? Dan persediaan air? "Yah, itu tidak berlaku untuk proyek rumah sakit!" - katamu. Ya, ini sebagian benar. Namun, rumah sakit dikirim ke pelanggan secara keseluruhan, dan semua sistem harus memiliki dokumentasi operasional yang sesuai. Dan agar perubahannya cepat, sukses, Anda akan menyusun daftar persyaratan, yang dapat Anda periksa apakah semuanya beres.

Kehadiran panduan pengguna dan administrator untuk IP adalah standar, dengan ini semuanya jelas. Tetapi pelanggan sering berpikir tentang proses penerimaan sistem pada saat terakhir. Dan sia-sia. Untuk ini, ada dokumen yang sangat bagus, "Program dan Metodologi Uji," juga biasanya terkait dengan dokumen kerja. Ini adalah semacam daftar periksa yang berisi deskripsi prosedur verifikasi. Jika dokumen ini dipersiapkan sebelumnya (dan naskahnya, sebagai dasar, dapat dipinjam dari proyek teknis), maka pengembang akan memiliki kriteria yang jelas untuk menerima pekerjaan mereka. Anda tidak perlu programmer Anda sendiri atau outsourcing untuk membuktikan kasus mereka - ada skenario, itu harus dikerjakan. Dan tidak akan ada masalah dengan pelanggan - fantasi sudah dibatasi oleh dokumen.

Dan di mana tempat Agile?

Beberapa orang dengan dua tangan di belakang Agile (atau metode pengembangan "fleksibel" lainnya), yang lain sangat menentangnya. Penulis artikel memiliki pendapatnya sendiri: Agile sangat baik, tetapi to the point. Dan mereka biasanya menggunakannya untuk keperluan lain.

, Agile, , , , ? Tidak , , ? , Agile? , Agile , . . — (, , , ).

: ?

-, Agile , , , , . , - . — - - . , , , . , , . , . ? -. — .

-, , , Agile . . , : . — , — . !

, , «» Agile, ( , ). : . , . () , - , , . .

?

. . — . , . — . , , , , -. ? , . , , . -, , . , , () , . .

, 34- . , . ( ) . .

, . .

: .

:

• 34 .
• .
• .