Ulasan Buku tentang Pengembangan Perangkat Lunak oleh Karl Wigers dan Joy Beatty

Pada tahun 2018, buku "Pengembangan persyaratan perangkat lunak" dicetak ulang. Kolega mengirimi saya tautan ke publikasi. Para penulis menambahkan teknik untuk bekerja dalam proyek gesit, menentukan peran analis dan rekomendasi untuk otomatisasi. Ada ulasan yang sangat bertentangan di Web. Saya memesan buku dan mencari tahu pertanyaannya.



Pro


Semuanya dicat


Pemula akan mendapatkan pemahaman lengkap tentang pekerjaan analis. Pro akan mengingat apa yang mereka hadapi sendiri. Semua tahapan pembuatan spesifikasi dianalisis. Lampiran B berisi manual yang disusun berdasarkan prinsip pemecahan masalah. Daftar isi itu sendiri bertindak sebagai petunjuk. Daftar periksa terperinci ada di hampir setiap bab. Misalnya, templat spesifikasi mencakup 8 klausa, 24 subclauses dan dua lampiran. Panduan komprehensif.

Mudah untuk menemukan informasi


Informasi terstruktur dengan jelas, dan ini membuatnya mudah untuk mencari buku. Daftar isi ditulis lebih dari 9 halaman. Dengan cepat menemukan tahap dan penjelasan yang tepat. Di setiap bab ada referensi ke bab lain, jika ada pertanyaan yang dijelaskan di sana lebih detail. Pada akhir manual adalah daftar istilah, sehingga Anda tidak perlu takut frasa seperti "UML", "siklus hidup proyek air terjun" atau "matriks CRUD". Dalam beberapa menit ada versi PDF dari edisi sebelumnya, Anda dapat menggunakan pencarian dokumen jika Anda memerlukan data tertentu.

Untuk semua orang di IT


Analis melakukan kontak dengan semua orang yang terlibat dalam proyek: pelanggan, desainer, pengembang, penguji, tenaga penjualan, dukungan dan pengguna produk. Dan masing-masing kelompok harus tahu bagaimana cara mengkorelasikan kerangka acuan dengan apa yang mereka lakukan. Seorang karyawan yang tidak berpengalaman mungkin bertanya sesuatu seperti: "Dan di mana ada tertulis untuk kami bahwa ketika Anda mengklik item ini tidak ada yang harus terjadi?" Jika dia membaca buku itu, dia akan menjawab pertanyaan ini dan memberikan komentar yang masuk akal pada dokumen itu.

Penjelasan Ketentuan


Sulit untuk membaca manual karena kebiasaan, tetapi setelah halaman ke-700 menjadi lebih mudah :) Selama presentasi, setiap konsep diberikan dalam tanda kurung aslinya dalam bahasa Inggris. Ini nyaman karena penerjemahnya tidak selalu akurat dan Anda dapat membuka Wikipedia dalam bahasa Inggris. Di akhir buku ada daftar istilah dengan penjelasan. Benar, tidak semua konsep yang ditemukan dalam manual. Untuk melengkapi daftar, saya harus menambahkan 50 frasa dan nomor halaman baru dengan tangan.

Cons


Verbositas


Penulis menyalahgunakan kalimat yang panjang dan informasi yang tidak perlu. Karena itu, artinya lebih sulit ditangkap.

"Alat manajemen persyaratan membantu Anda melacak persyaratan, sehingga memungkinkan untuk mengidentifikasi hubungan antara berbagai jenis persyaratan, antara persyaratan dalam berbagai subsistem, dan antara persyaratan individu dan komponen sistem terkait (seperti desain, modul kode, tes, dan dokumentasi pengguna)."

Leo Tolstoy, kan?

"... metode komunikasi dapat memberikan sinkronisasi waktu dan ruang yang efektif dalam tim."

Dan di atas kertas tertulis bahwa ini adalah manual, bukan risalah filosofis.

"Sebutkan diagram untuk status pesanan makanan."

Penulis tidak mengulangi dua kali, jangan ulangi.

"Stephen Withall (2007) menjelaskan banyak skema untuk mendokumentasikan data secara akurat (juga disebut informasi)."

Data = Informasi. Dan ada sesuatu untuk itu!

Dan suara semantik seperti itu di seluruh buku. Ada kecurigaan bahwa penulis dibayar untuk kalimat tersebut.

Kesalahan tata bahasa


Dalam proses membaca, saya menghitungnya lebih dari 160. Semua kesalahan dalam kurikulum sekolah. Sebagai contoh: kata-kata dilewati, "-tsya" digunakan sebagai ganti "-tat", kalimat diulang dalam satu paragraf, kesalahan ketik biasa ditemui, koma dilewati, konsep yang ditulis dengan cara yang sama membingungkan.

Kesalahan pertama terjadi segera setelah Anda membuka buku. Chris tidak punya megalomania, mereka hanya membingungkannya dengan Karl, yang mendedikasikan buku untuknya. Mereka adalah pasangan.



Bagaimana Anda menyukai ungkapan itu?
"Mendesain ulang sistem untuk pemrosesan yang lebih baik dari aturan bisnis volatile yang merupakan dukungan proyek yang kompleks."


Penempatan produk


Dalam perjalanan presentasi, penulis berulang kali menyebutkan produk Microsoft. Mereka sangat terkenal sehingga tidak masuk akal untuk menulis tentang mereka. Dan ketika perlu untuk menyebutkan persyaratan sistem manajemen (SUT), penulis tidak menghiraukannya. Saya hanya membaca bab ini demi mereka. Buku itu baru saja dirilis oleh Microsoft Press, sedangkan "yang lunak" tidak memiliki SUT lengkap. Loyalitas perusahaan melebihi hutang profesional.

Meremehkan


Misalnya, dalam Lampiran B, penulis memberikan contoh dokumentasi persyaratan. Mereka menulis bahwa pelanggan harus dapat mengubah langganan. Tetapi tidak dikatakan tentang penciptaan langganan. Bagaimana saya bisa mengubah sesuatu yang belum dibuat? Melewati fase awal.

Atau ditunjukkan bahwa sistem harus memungkinkan pelanggan menentukan metode pembayaran. Tetapi tidak tertulis tentang konfirmasi pembayaran. Apa gunanya menunjukkan bagaimana Anda ingin membayar jika pembayaran tidak dapat dikonfirmasi? Ketinggalan tahap akhir.

Langkah-langkah yang tersisa dijabarkan dalam aplikasi secara rinci. Terhadap latar belakang ini, tautan yang hilang dalam rantai opsi meninggalkan perasaan diremehkan. Jelas bahwa aplikasi diberikan sebagai contoh, tetapi tetap saja.

Apa yang relevan untuk Rusia?


Sebelum membaca, saya memikirkan sesuatu seperti ini: “Apa yang bisa disarankan orang Amerika kepada kita? Mereka memiliki semuanya dalam jumlah, dan tidak ada masalah. " Ternyata masalahnya hampir sama.

Tidak ada budaya menghormati persyaratan


Seperti yang dikatakan pengembang, "Saya tidak membaca TK, tetapi segera menulis kode." Ini bukan pendekatan yang seimbang. Implementasinya tidak dikoordinasikan dengan pihak-pihak yang berkepentingan, opsi tambahan tidak sedang dipelajari, dan komunikasi dengan elemen lain diabaikan. Risiko kesalahan dan kenaikan harganya. Jika pengguna menemukan kesalahan setelah rilis, maka harganya naik 21 kali. Pada tahap TK, menghilangkannya jauh lebih murah. Tetapi sementara perusahaan tidak serius tentang spesifikasi, itu akan "menginginkan yang terbaik, tetapi ternyata seperti biasa."

Tidak ada persyaratan bisnis


Persyaratan bisnis menggambarkan mengapa organisasi membutuhkan sistem, yaitu tujuan yang ingin dicapai oleh perusahaan. Tetapi jika Anda melihat perusahaan Rusia berukuran sedang, Anda mendapat kesan aneh. Beberapa tidak mengerti mengapa mereka berproduksi, sementara yang lain tidak mengerti mengapa mereka membeli. Tetapi ambisi meningkat dan bertaruh pada segel di Instagram. Kebetulan Anda berkomunikasi dengan jenius lain dari Skolkovo, dan dia dengan penuh semangat memaksakan kebutuhan imajiner pada kliennya. Akibatnya, perusahaan terlihat seperti sayuran, dan anggarannya tampak seperti ember berlubang.

"Pasang" ke desain


Ini tidak mungkin, karena setelah mendesain ulang, Anda harus mengedit TK. Ini adalah buang-buang waktu yang tidak perlu. Spesifikasi tidak perlu tergantung pada desain. Biarkan para desainer memiliki pilihan bagaimana menerapkan persyaratan ini atau itu. Misalnya, elemen kontrol "Hapus" dapat direpresentasikan sebagai tombol, ikon, tautan, gesek, atau item menu konteks. Lebih baik untuk menggambarkan ini melalui fungsi dan sirkuit, daripada antarmuka. Bukan "sistem menampilkan daftar drop-down", tetapi "sistem memberikan pilihan".

Tidak ada pemahaman tentang spesifik analis


Misalnya, di satu perusahaan, analis telah memperluas tanggung jawab. Mereka diinstruksikan untuk memberi tahu pihak berwenang tentang kapan persyaratan ini atau itu sedang dilaksanakan dan oleh siapa. Jika ada penundaan, mereka tahu sebabnya. Tugas dipindahkan secara bertahap dan orang-orang yang bertanggung jawab dari departemen lain ditunjuk. Akibatnya, bagian konten menderita. Semua yang dijelaskan adalah tanggung jawab manajer proyek. Manajer bertanggung jawab atas pertukaran informasi tentang proyek, analis bertanggung jawab atas pertukaran informasi tentang produk. Ini adalah dua lini bisnis yang berbeda.

Tidak ada alat yang digunakan


Satu bos ingin mereka yang bekerja dengan TK untuk mengenal mereka dekat dengan teks. Ini tidak realistis. Perusahaan memiliki beberapa puluh TK, dan jumlahnya meningkat. Jika Anda sendiri selesai menyusun TK sebulan lalu, Anda masih melupakannya, karena dengan begitu Anda membenamkan diri dalam 2-3 yang baru. Masalahnya dipecahkan bukan karena memori, tetapi karena penerapan sistem manajemen persyaratan (SUT). Mereka mendukung identifikasi, manajemen, pelacakan, dan penarikan persyaratan. Tetapi Anda harus membayar untuk mereka, dan majikan lebih suka bekerja dengan cara lama, seperti yang dikatakan:

Dua tentara dari batalyon konstruksi menggantikan excavator.
Dan salah satu pasukan udara menggantikan mereka dua kali lipat.


Posting scriptum
Saya menulis kepada penerbit versi buku dalam bahasa Rusia tentang kesalahan dan menyarankan untuk memperbaikinya bersama. Permintaan dibaca, tetapi staf tidak menanggapi. Jadi mereka menganggap buta huruf sebagai norma. Ini menyedihkan karena aslinya bagus.

Kesimpulan


Buku ini meninggalkan kesan kontroversial karena kekotorannya. Kontennya tinggi, tetapi bentuknya tidak. Ini menakutkan. Tetapi jika seorang spesialis ingin menjadi analis, ia harus memahami apa yang ingin dikatakan oleh penulis. Itu tidak mudah, tetapi waktu yang dihabiskan sepadan, dan Anda akan lebih menghargai diri sendiri.

Source: https://habr.com/ru/post/id419235/


All Articles