Baru-baru ini, seorang teman saya mengeluh tentang dominasi bahasa gaul bahasa Inggris di beberapa komunitas profesional. Saya menjawabnya bahwa itu buruk, tetapi dipaksakan. Sama seperti ini, proses pinjaman alami terjadi, di mana yang perlu disesuaikan dan yang tidak perlu terhanyut. Dan dalam bahasa Inggris sendiri ada jauh lebih banyak Latinisme daripada di Anglicisme Rusia. Lagi pula, dulu mereka yang terlibat dalam sains dikomunikasikan secara eksklusif dalam bahasa Latin.
Dalam bahasa Rusia, masih ada area kecil di mana ia diperlukan untuk membawanya ke realitas modern. Ini berlaku untuk praktik Barat di bidang pengelolaan orang dan tim. Mereka dipelajari dengan buruk oleh sains Soviet, sementara di tahun 90-an pengenalan mereka yang dipercepat dimulai oleh orang-orang yang baru-baru ini menganggap mereka secara ideologis salah. Begitu pula dengan ekonomi dan di area yang lebih spesifik, seperti yang terkait dengan produksi perangkat lunak.
Kami selalu tahu cara menulis kode program yang bagus. Tetapi bisnis perangkat lunak lebih luas daripada pemrograman sederhana yang disewa - ini adalah perdagangan pengetahuan. Dan jika demikian, maka produksi dan organisasinya diperlukan. Di sini, peran kunci dimainkan oleh sistem manajemen pengumpulan persyaratan, di mana proses produksi harus dibangun berdasarkan pengalaman Barat.
Lebih lanjut dalam artikel ini, kesalahan pinjaman tipikal dianalisis menggunakan contoh-contoh dari terjemahan buku Karl I. Wigers 'Pengembangan Perangkat Lunak Persyaratan'. Pada akhirnya, materi yang dibahas dirangkum menggunakan model-V dari siklus hidup persyaratan desain untuk perangkat lunak.
Tidak diragukan lagi, buku penasaran oleh Karl I. Wigers "Pengembangan persyaratan perangkat lunak" (selanjutnya disebut RTkPO) menjadi standar tertentu dalam komunitas informasi Rusia. Tetapi penggunaan ketentuan dari buku ini (dipinjam, asli, diterjemahkan) di luar konsep penulis menimbulkan pertanyaan yang ingin saya pahami.
Ini adalah ilustrasi pengembangan persyaratan ketika proyek berkembang dari atas ke bawah, melalui tiga dokumen: "
Dokumen pada gambar dan batas-batas proyek ", "
Dokumen tentang kasus penggunaan ", "
Spesifikasi persyaratan perangkat lunak ". Dalam edisi ke-3, dua dokumen pertama disajikan sebagai "
Dokumen konsep dan batas " dan "
Dokumen persyaratan pengguna "
Untuk membuat dokumen yang tepat, Anda harus terlebih dahulu memahami esensinya. Tampaknya kuncinya adalah untuk mengungkap "
citra dan batas-batas proyek " yang misterius: menyelesaikannya, dan Anda dapat menggunakan praktik siap pakai tanpa batasan dan dengan manfaat besar. Sayangnya, ini hanya bekerja dengan teknologi sederhana yang dibeli dari pihak ketiga. Aspek
manajemen tim terkait langsung dengan karakteristik budaya asing, dan semuanya tidak mudah di sana. Perbedaan budaya adalah bagian yang terlihat dari gunung es dari seluruh sistem stereotip etnik perilaku
bawah sadar . Tetapi kita sama sekali tidak mengendalikan alam bawah sadar, atau kita hanya mengendalikannya sebagian.
Namun, tidak semuanya sia-sia. Kita perlu menemukan asosiasi terminologi mereka dengan praktik kita. Kami akan menganalisis "
Dokumen pada gambar dan batas-batas proyek ." Batas-batas proyek adalah
ruang lingkup proyek . Ini harus diterjemahkan sebagai "
beban kerja ". Tidak ada dalam kamus? Sayang Anda dapat melihat manual bahasa Inggris:
ruang lingkup proyek - bagian dari perencanaan proyek, termasuk proses penentuan dan kemudian mendokumentasikan tujuan spesifik proyek, hasil, tugas, biaya, dan tenggat waktu . Ada prosedur khusus, mengapa tidak menyebutnya "
batas proyek "? Dalam hal ini, masalah akan muncul dengan integrasi pengalaman masa lalu kita sendiri: setelah semua, kita telah merencanakan dan, khususnya, menentukan ruang lingkup pekerjaan sebelumnya.
Ketika terjemahan kamus gagal, Anda perlu mencari model konseptual sederhana yang menggambarkan penggunaan istilah kontroversial dalam bidang studi terkait. Transfer lebih lanjut dari model pengungkapan sederhana seperti itu ke tanah asalnya memungkinkan kita menemukan kecocokan bahasa. Model triple constrains adalah pengantar manajemen proyek.
Model ini mengungkapkan hubungan antara istilah "
waktu eksekusi ", "
biaya ", "
jumlah pekerjaan " (waktu, biaya, ruang lingkup), yang ditempatkan dalam bentuk segitiga sama sisi, yang menyiratkan bahwa mengubah satu sisi segitiga ini menyebabkan perubahan dalam semua.
Visi Proyek kadang
- kadang diterjemahkan bukan sebagai "
gambar proyek ", tetapi sebagai "
konsep proyek ", tetapi ini tidak menambah kejelasan.
Pernyataan Visi Proyek dalam buku pegangan didefinisikan sebagai "
pandangan idealistis dari hasil bisnis yang diinginkan yang akan diperoleh setelah berhasil menyelesaikan proyek ." Kami biasanya menggunakan istilah "
tujuan proyek " dan merumuskan tugas-tugas ini dengan pesimisme domestik. Jika kita menyebutnya "
gambar proyek ", kecil kemungkinan hal ini akan membantu mewujudkan optimisme Barat di tanahnya sendiri. Total, dokumen pertama dapat disebut "
Tujuan Proyek dan Lingkup Pekerjaan ". Dan tidak ada yang misterius.
Dipercayai bahwa istilah-istilah tersebut tidak boleh diterjemahkan, tetapi gunakan bahasa Inggris dalam proyek tersebut. Ini hanya berfungsi sebagian, sangat membatasi lingkaran orang yang ahli dalam berbagai hal. Keterampilan bahasa dasar tidak cukup ketika masalah teknologi berhubungan dengan perbedaan etnis-budaya.
Berikut ini adalah contoh khas dari RTkPO: "
Persyaratan harus dinyatakan secara berurutan, misalnya," sistem akan menjadi ... "atau" pengguna akan menjadi ... ", lalu kata kerja aktif, dan kemudian hasil yang diamati ... Anda dapat menggunakan" harus "sebagai sinonim untuk" akan ", tetapi menghindari "harus", "mungkin", "bisa" dan kata-kata serupa, yang tidak jelas apakah tindakan itu perlu . "
Anda mungkin berpikir bahwa ini adalah panduan untuk bertindak. Sebenarnya, terjemahan ini tidak membantu untuk mengetahuinya, tetapi lebih membingungkan segalanya. Selain itu, bahasa Inggris asli bukan kebenaran akhir, tetapi ekspresi pandangan tertentu tentang modalitas bahasa Inggris. Tampilan diabadikan dalam standar RFC2119 **, yang mengklarifikasi aturan untuk menggunakan kata kunci bahasa Inggris di bidang manajemen persyaratan (
misalnya harus, harus, harus, boleh ). Misalnya, dalam standar ini,
harus berarti "
bahwa definisi adalah persyaratan mutlak dari spesifikasi ." Namun, penulis bertemu template dokumen dengan larangan langsung pada penggunaan
harus (penjelasan posisi ini tersedia di Internet ***).
Rincian tingkat selanjutnya untuk persyaratan adalah "
Use Case Document ". Di RTkPO, ditunjukkan bahwa ia mendefinisikan kasus penggunaan, skenario, dan tabel
respons peristiwa . Terjemahan dari "
kasus penggunaan " sebagai "
kasus penggunaan " tidak perlu menyederhanakan pandangan hal-hal (karena itu, dalam praktiknya, Anglicism dari
kasus penggunaan telah menjadi lebih mapan) Perangkat lunak modern harus memiliki perlindungan terhadap peretasan dan perlindungan dari orang bodoh, tetapi menganggap ini sebagai opsi untuk digunakan - kekerasan terhadap bahasa Rusia. Untuk terjemahan, "skenario interaksi" diusulkan.
Faktanya, model
event-response diketahui oleh kita. Di sekolah menengah, ini dipelajari sebagai "
dampak - fluktuasi -> respons ." Di bawah pengaruh yang sama, respons sistem dapat bervariasi karena fluktuasi acak. Dalam perangkat lunak pengguna, ini biasanya berbagai situasi kesalahan. Selain itu, pada tingkat konsep, efek lingkungan harus dibedakan dari efek pengguna. Nama yang kurang lebih cocok untuk tingkat persyaratan ini adalah "
Persyaratan Sistem " atau sudah "
Persyaratan Produk Perangkat Lunak ", meskipun terminologinya belum ditetapkan dan pilihan yang sangat berbeda ditemukan (misalnya, dalam edisi terbaru nama "
Dokumen Kebutuhan Pengguna " digunakan, yang secara otomatis tidak termasuk sistem tertanam dari pertimbangan).
Inti dari pengembangan persyaratan tingkat ini adalah penciptaan model spekulatif terperinci dari perangkat lunak yang berfungsi dalam dunia eksternal yang ideal. Oleh karena itu, poin penting adalah menetapkan batasan dan membuat asumsi. "
Warna mobil bisa apa saja, asalkan hitam, " - jadi Henry Ford mendesain ulang persyaratan bisnis untuk warna mobil menjadi asumsi. Namun, di lain waktu, untuk memenuhi persyaratan bisnis untuk kebersihan mobil, ternyata diperlukan untuk membuat kaca streamline non-planar. Insinyur Ford mengatakan itu secara teknis tidak mungkin. Ford menemukan penemu muda di samping.
Level yang lebih rendah diwakili oleh "
Spesifikasi Kebutuhan Perangkat Lunak ", yang meliputi "
batasan ", "
antarmuka eksternal ", "
atribut kualitas " dan sebenarnya "
persyaratan fungsional ". Ini adalah dokumen terakhir dalam gambar, sayangnya, pertanyaan-pertanyaan pengujian berikutnya tidak dibahas. Oleh karena itu, untuk merumuskan definisi, RTkPO terpaksa menggunakan konsep persyaratan bisnis: "
persyaratan fungsional menentukan fungsionalitas perangkat lunak yang harus dibangun pengembang sehingga pengguna dapat menyelesaikan tugas mereka dalam kerangka persyaratan bisnis "
Di sisi pengujian, definisi lebih sederhana untuk dibangun: "
Persyaratan fungsional adalah persyaratan yang sedang diuji ." Ini harus dipahami sebagai kemampuan untuk menguji setiap persyaratan fungsional dengan tes dalam arti klasik (dengan putusan - lulus atau gagal). Kebalikannya, sebenarnya, tidak benar: beberapa tes mungkin ada pada mereka sendiri. Tetapi kehadiran tes tersebut merupakan indikator kelalaian dalam pekerjaan pada persyaratan. Setelah semua, tes memeriksa bagian kode yang tidak muncul sendiri, tetapi sebagai hasil dari pelaksanaan persyaratan fungsional tertentu.
Proses pengembangan perangkat lunak dewasa modern mencoba untuk membawa komponen pengukuran ke dalam tahap awal pembuatan produk perangkat lunak. Tanpa merinci - sebagian besar ini adalah semua jenis metrik cakupan. Salah satu indikator kualitas produk masa depan adalah persentase cakupan dengan tes persyaratan fungsional, yang dihitung menggunakan tabel (matriks) cakupan (matrix traceability). Dimungkinkan untuk memasukkan persyaratan non-fungsional dalam matriks, tetapi di masa depan pekerjaan itu akan ditandai sebagai tidak dapat diuji, dan, yang paling penting, penguji akan mengevaluasinya sebagai tidak berguna. Tampaknya "
spesifikasi persyaratan perangkat lunak " yang lengkap dengan daftar persyaratan non-fungsional sangat berguna bagi programmer. Dan ini, mungkin, akan jadi jika, setelah kompilasi, mereka melihat ke sana, setidaknya dari waktu ke waktu.
Sebagian besar persyaratan non-fungsional dapat ditulis dengan cara fungsional. Untuk parafrase, hampir semua persyaratan non-fungsional untuk suatu sistem atau produk perangkat lunak dapat diproses menjadi satu atau lebih persyaratan fungsional.
Atribut kualitas dalam RTkPO sebagian jatuh ke persyaratan fungsional, yang benar-benar benar. Namun, keterbatasan dan antarmuka eksternal RTkPO didefinisikan sebagai berikut: “
persyaratan non-fungsional lainnya menggambarkan interaksi eksternal antara sistem dan dunia luar, batasan desain dan implementasi. "Kendala (kendala) terkait dengan pilihan kemungkinan mengembangkan penampilan dan struktur produk ." Subsistem komunikasi dengan dunia luar selalu memiliki antarmuka yang fungsional dan dapat diuji.
Bisakah pembatasan menjadi persyaratan fungsional? Jelas ya, jika Anda menuliskannya dalam bentuk terbalik sebagai peluang. Misalnya, produk harus lebih cepat daripada pesaing (jika tidak tidak diperlukan - pembatasan yang sangat parah). Pertama-tama, kita berbicara tentang kebaruan keputusan yang dibuat, didokumentasikan, termasuk dalam bentuk persyaratan. Tetapi jelas bahwa sistem harus memiliki modul untuk mengukur parameter yang terdeteksi dari kecepatan ini, dan pada tahap awal.
Jadi, "
Spesifikasi Fungsional " adalah nama yang ditetapkan untuk spesifikasi tingkat yang lebih rendah dalam bentuk dokumen yang diformat atau sebagai basis data di bawah kendali perangkat lunak khusus.
Apa yang terjadi dengan persyaratan selanjutnya? Selain pengembang (programmer), insinyur pengujian dan insinyur QA (Jaminan Kualitas) akan bekerja dengan persyaratan. "Pengujian" dapat diterjemahkan sebagai "verifikasi", tetapi "pengujian" pinjaman tampaknya terjadi. Menerjemahkan QA lagi membutuhkan model pengungkapan - di sini, prinsip mana yang mendukungnya. Pertama, "
Cocok untuk tujuan " (produk harus sesuai dengan tujuan yang dimaksudkan), kedua, "
benar pertama kali " ("pertama kali" - kesalahan harus dihilangkan) dan ketiga, kemandirian proyek. Ini adalah "
Penerimaan ", prinsip-prinsip yang mendasari penerimaan militer yang terkenal dan penerimaan negara yang legendaris.
Spesifikasi persyaratan akan menjadi dasar dokumen desain lebih lanjut. Minimal, persyaratan akan digunakan dalam pengembangan
dokumentasi pengguna . Secara umum diterima bahwa pengujian dimulai dengan
rencana pengujian dan diakhiri dengan
laporan pengujian - dokumen yang berkaitan langsung dengan spesifikasi. Seseorang dapat melihat angka dalam RTkPO secara berbeda - sebagai model umum dari proses pengembangan perangkat lunak (atau model siklus hidup perangkat lunak). Dalam model ini, dokumen jadi adalah titik masuk / keluar antara fase proses.
Dalam urutan kronologis, dokumen akan disajikan sebagai berikut: persyaratan bisnis (sebagai bagian dari lingkup proyek), persyaratan sistem (PO), persyaratan fungsional, rencana pengujian, laporan pengujian, dokumentasi pengguna. Garis antara dua dokumen adalah fase proses. Model sering digambarkan dalam bentuk siklus berulang atau spiral, namun, sumbu kronologis sederhana lebih terlihat. Kemudian fase pertama dan terakhir dari proses ditunjukkan bukan oleh segmen, tetapi oleh ray. Dalam presentasi modern, sumbu waktu ditekuk di tengah fase pengkodean dalam bentuk huruf "
V ", sehingga disebut
model-V .
Garis putus-putus menunjukkan koneksi melewati sumbu kronologis, menunjukkan kemampuan untuk memulai beberapa pekerjaan di muka. Misalnya, dengan persyaratan bisnis yang dirumuskan, Anda sudah dapat mengatakan sesuatu tentang dokumentasi pengguna produk, dan persyaratan yang dibentuk untuk sistem akan memberikan model perangkat lunak masa depan, yang kualitasnya sudah dapat dinilai.
Tetapi fungsi utama dari garis-garis ini adalah untuk menunjukkan skalabilitas (penyederhanaan) dari model-V.
Mendukung semua fase dan dokumen selalu merupakan kesenangan yang mahal, dan alasan yang sangat umum untuk kalah dari lebih banyak pesaing seluler . Misalnya, seorang individu bekerja seperti ini: persyaratan bisnis -> pengembangan (pengkodean) -> dokumentasi pengguna. Ini adalah garis patah atas. Perusahaan outsourcing, sebagai aturan, melewatkan fase yang lebih rendah tanpa mengeluarkan uang untuk spesifikasi fungsional dan dibatasi oleh satu atau lain jenis persyaratan sistem (misalnya,
skenario interaksi ). Untuk produk dengan tipe yang sama, biasanya ada standar perusahaan, dan dari fase pengkodean, laporan tertentu pengujian internal pengembang dikeluarkan untuk memulai fase QA / penerimaan.
Model-V dasar membantu memperjelas bidang tanggung jawab. Misalnya, seorang karyawan memainkan peran sebagai Acceptance Engineer (QA) atau Test Engineer, tergantung pada fase di mana ia bekerja. Tidak masalah jika dia ditugaskan ke proyek atau departemen tertentu. Hal yang sama berlaku untuk analis, perancang, pengembang - kemampuan untuk memenuhi semua peran ini oleh satu orang tidak menyangkal model-V. Untuk Acceptance Engineer (QA) dan analis dasarnya adalah "Persyaratan Sistem", mereka bekerja dengan perangkat lunak yang dikembangkan sebagai kotak hitam. Bagi mereka yang terlibat dalam fase, desain, pengembangan, dan pengujian adalah kotak putih, meskipun pada tingkat yang berbeda.
Sebagai kesimpulan, perlu dicatat bahwa model-V masih presentasi (dalam hal ini, menggambarkan evolusi desain persyaratan). Ini bukan panduan langsung untuk bertindak, proses pengembangan perangkat lunak nyata lebih rumit. Tetapi potensinya yang terbuka sulit diremehkan.
* Karl I. Wigers "Pengembangan Persyaratan Perangkat Lunak."
** Kata-kata kunci untuk digunakan dalam RFC untuk Menunjukkan Tingkat Kebutuhan (https://tools.ietf.org/html/rfc2119)
*** Harus - Jangan gunakan harus karena tidak ada yang mendefinisikan bagaimana harus berbeda dari yang seharusnya. Juga, harus diadakan di pengadilan, tidak harus. Memang, haruskah terdengar lebih kuat, bukan? Maksud saya, jika bos Anda memberi tahu Anda bahwa Anda "harus" melakukan sesuatu, Anda akan melakukannya. Tetapi, ketika menulis persyaratan, buat hal-hal sederhana dan gunakan saja (http://www.reqexperts.com/blog/2012/10/using-the-correct-terms-shall-will-should)