Persyaratan pengembangan dan pengelolaan proyek perangkat lunak adalah pekerjaan yang sangat penting, menurut survei proyek-proyek perangkat lunak banyak gagal, karena permintaan menyebabkan sekitar 45%, karena itu, perlu bekerja akan menghasilkan proyek software dapat dicapai dampak penting. Namun demikian, pembangunan proyek, pemahaman banyak orang tentang kebutuhan masih jauh dari cukup, dari partisipasi saya di atau akses ke beberapa item, yang seratus ribu kecil untuk beberapa dolar pada permintaan juta besar untuk proyek-proyek perangkat lunak atau berapa banyak masalah, beberapa pengembang tidak mementingkan alasan mereka sendiri, beberapa alasan teknis, staf beberapa alasan organisasi, beberapa alasan komunikasi, beberapa mekanisme untuk menyebabkan semua alasan ini menunjukkan bahwa permintaan untuk pengembangan perangkat lunak yang baik adalah sistem kerja, tidak pekerjaan teknis yang sederhana, hanya sistem kebutuhan untuk memahami dan menyerap konsep dasar, metode, berarti, kriteria evaluasi, risiko, pengetahuan, dan menerapkannya dalam praktek, hanya cara untuk melakukan pengembangan dan kebutuhan manajemen.
Artikel ini memperkenalkan pengetahuan dasar tentang persyaratan perangkat lunak dan pelajaran individu dalam sejumlah pengalaman kerja praktis untuk membantu pembaca memahami kebutuhan perangkat lunak, kebutuhan belajar beberapa metode dasar dikembangkan untuk menghindari permintaan alasan yang menyebabkan kegagalan proyek.
1 Apakah kebutuhan perangkat lunak dan rekayasa persyaratan
Definisi 1,1 persyaratan perangkat lunak
Dalam Kamus Standar IEEE Rekayasa Perangkat Lunak (1997) menetapkan persyaratan perangkat lunak adalah:
(1) pengguna untuk memecahkan masalah atau mencapai kondisi tujuan atau kemampuan yang diperlukan.
(2) sistem atau komponen sistem untuk memenuhi kontrak, standar, spesifikasi atau dokumen resmi lainnya yang diberikan dengan kondisi atau kemampuan yang dibutuhkan.
(3) refleksi di atas (1) atau (2) kondisi yang dijelaskan dalam deskripsi dokumen atau kekuasaan.
Benar-benar populer, permintaan "" adalah kebutuhan pengguna, yang meliputi pengguna untuk memecahkan masalah, mencapai tujuan dan sasaran yang diperlukan untuk mencapai kondisi tersebut, itu adalah proses atau pekerjaan pengembangan sistem menunjukkan bahwa bentuk umum dari dokumen formulir.
1,2 Definisi rekayasa kebutuhan
Proses analisis kebutuhan, juga dikenal sebagai rekayasa persyaratan dan tahap persyaratan, yang meliputi kebutuhan pembangunan dan manajemen permintaan dalam dua bagian. Persyaratan pembangunan adalah bahwa dari pengumpulan informasi, analisis dan evaluasi terhadap persiapan dokumen, menghasilkan serangkaian kegiatan penilaian kebutuhan, dibagi menjadi empat fase: situasi akuisisi, analisis, penyusunan spesifikasi dan evaluasi. Empat tahap yang tidak harus mengikuti urutan linier, kegiatan mereka adalah independen dan diulang. Permintaan manajemen adalah pengendalian proses pengembangan perangkat lunak dan kebutuhan pemeliharaan kegiatan yang disepakati, yang meliputi: pengendalian perubahan, kontrol versi, persyaratan pelacakan, pelacakan persyaratan status dan sebagainya.
2, risiko analisis permintaan
Sebagai kebutuhan peserta, model bisnis, investasi, waktu dan faktor obyektif lainnya, dan permintaan subjektif dan dapat menggambarkan karakteristik miskin, karena itu, analisis permintaan sering dihadapkan pada sejumlah risiko potensial. Risiko ini terutama dalam:
(1) user tidak bisa benar mengungkapkan kebutuhan mereka sendiri.
Dalam proses pembangunan sebenarnya, sering bertemu dengan kebutuhan nyata pengguna mereka tidak terlalu jelas, mereka adalah bahwa komputer yang mahakuasa dengan hanya mengungkapkan keinginannya untuk melakukan Jiu Shi Yue memahami kebutuhan, sementara aturan 业务alur kerja tetapi tidak ingin membicarakannya, mereka juga tidak jelas. Analisis ini sering sulit untuk meningkatkan permintaan, analis harus menghabiskan lebih banyak waktu dan energi untuk berinteraksi dengan pengguna, untuk membantu mereka menyortir ide-ide, mengetahui kebutuhan nyata pengguna.
(2) usaha personil dengan kekuatan yang cukup.
Beberapa pengguna dengan pekerjaan sehari-hari berat, mereka tidak ingin membayar lebih banyak waktu dan energi untuk menjelaskan bisnis untuk analis, ini akan meningkatkan kesulitan staf dan beban kerja, juga bisa menyebabkan kekurangan pada sistem karena kebutuhan bisnis tidak dapat digunakan.
(3) Persyaratan pengguna yang senantiasa berubah.
Sebagai permintaan kegagalan pengakuan, perubahan bisnis, permintaan salah, permintaan itu tidak jelas dan alasan lain, permintaan untuk siklus hidup seluruh proyek dapat berubah, karena itu, kita harus menyadari 到, perangkat lunak proses pembangunan sebenarnya untuk bertarung dengan perubahan proses, perubahan menuntut setiap pengembang, masalah manajemen proyek juga merupakan masalah yang paling sulit, dalam hal perubahan permintaan, harus memodifikasi desain, penulisan ulang kode, memodifikasi kasus uji, menyesuaikan rencana proyek, dll , perubahan permintaan sebagai akar segala kejahatan, kemajuan normal dari proyek yang disebabkan masalah tak ada habisnya.
(4) besarnya permintaan penuh. Perlu tidak hilang?
Ini adalah masalah besar, permintaan agar sistem yang besar untuk kelelahan hampir mustahil, bahkan jika sistem kecil, permintaan baru selalu muncul. Sebuah sistem sulit untuk menentukan ruang lingkup dan jelas dari semua tuntutan yang diajukan, ini akan menyebabkan kemajuan dalam pengembang proyek untuk terus menerus meningkatkan permintaan, pertama membentuk arsitektur sistem dan kemudian melengkapi persyaratan spesifikasi, sehingga kemungkinan pengerjaan ulang besar, akan mengembangkan personil untuk membawa frustrasi, mengurangi kepercayaan diri mereka untuk menyelesaikan proyek.
(5) kebutuhan perbaikan.
Untuk penjelasan lebih rinci tentang permintaan pada akhirnya, adalah makna akhir? Meskipun permintaan standar nasional digambarkan dalam penyusunan spesifikasi, tetapi khusus untuk permintaan tertentu, sulit untuk memberikan target tertentu, dapat digambarkan sebagai kebajikan melihat kebajikan dan kebijaksanaan melihat bijaksana, dan tidak ada kesimpulan. Permintaan yang lebih rinci, semakin lama periode kemungkinan perubahan, pembatasan lebih pada desain persyaratan yang lebih ketat pada kebutuhan ekstraksi umum semakin tinggi, sebaliknya, permintaan lebih untuk minyak mentah, pengembang dalam desain teknis tidak jelas mana yang lebih mempengaruhi desain teknis.
(6) menggambarkan ambiguitas permintaan.
Persyaratan yang dijelaskan dalam ambiguitas di satu pihak mengacu pada kebutuhan yang berbeda dari para pembaca memiliki pemahaman yang berbeda dari petunjuk; sisi lain, mengacu pada pembaca yang sama dapat digunakan untuk menjelaskan cara sebuah catatan permintaan. Ambiguitas membuat pengguna dan pengembang dan peserta proyek lainnya memiliki harapan yang berbeda, ini akan mengembangkan, personil ujian bagi interpretasi yang berbeda mengenai buang-buang waktu, sebuah konsekuensi yang tak terhindarkan lagi dilakukan.
(7) mengabaikan karakteristik pengguna.
Analis sering terabaikan fitur dari pengguna sistem, sistem terdiri dari orang yang berbeda untuk menggunakan karakteristik mereka yang berbeda, menggunakan perbedaan frekuensi, tingkat pendidikan dan pengguna tingkat pengalaman bervariasi. Jika Anda mengabaikan, hal itu akan menyebabkan beberapa pengguna produk kecewa.
(8) membutuhkan perlindungan perkembangan waktu.
Untuk memastikan ketepatan dan kelengkapan persyaratan, pemimpin proyek perlu memaksa untuk menghabiskan waktu lebih banyak, tetapi user dan pengembangan kepemimpinan departemen lambat karena proyek untuk melihat Cheng Guo beton dan kecemasan, mereka cenderung untuk memaksa proyek ke depan secepat mungkin untuk meningkatkan permintaan kebutuhan akan pengembang kompleks dan berubah frustasi kelelahan, mereka ingin mengakhiri dini untuk tahap permintaan.
3 Bagaimana melakukan pekerjaan tuntutan
Analisis kebutuhan pengembangan perangkat lunak adalah salah satu pekerjaan yang paling sulit, tidak hanya memerlukan analisis kebutuhan staf dengan pengalaman yang kaya dan kualitas profesional yang baik, juga memerlukan analis memiliki kemampuan yang baik untuk belajar, hubungan masyarakat, bahasa dan keterampilan organisasi. Dalam kerja praktek staf harus menghadapi unit yang berbeda, departemen yang berbeda, orang yang berbeda, budaya yang berbeda, hubungan yang berbeda, tingkat manajemen yang berbeda dan pada kondisi yang berbeda, wajah sebuah lingkungan kompleks, bagaimana persyaratan analisis kerja? Pertama perlu membentuk mekanisme kerja yang efektif, hanya membentuk mekanisme kerja untuk memastikan implementasi program sesuai dengan persyaratan kerja yang ditetapkan, pengembangan dan pengelolaan persyaratan peserta akan berada dalam keadaan kerja teratur. Diikuti dengan penuh penggunaan mekanisme kerja dan kemampuan individu untuk memperoleh dan menganalisa masalah, menulis dokumen persyaratan dan manajemen permintaan.
3.1 analisis kebutuhan untuk membentuk mekanisme kerja dari sejumlah faktor untuk dipertimbangkan
(1) untuk merebut para pembuat kebijakan yang paling mendesak dan paling prihatin, perhatikan.
Pengguna, pembuat kebijakan prihatin dengan penekanan pada proyek ini adalah proyek untuk mengembangkan lancar, maksud sebenarnya dari para pembuat kebijakan adalah kebutuhan utama dari sisi pengguna, oleh karena itu, dalam proses pembangunan, kita harus menggunakan setiap kesempatan untuk memahami keputusan-keputusan berkaitan dengan masalah, tetapi juga biarkan mereka mengerti proyek. Seperti laporan negosiasi, khusus, rapat koordinasi, inspeksi terkemuka, hasil awal jelas menunjukkan seperti kursus singkat penggunaan bahasa atau teks untuk merebut kepemimpinan yang paling perhatian untuk memandu pemahaman mereka dan perhatian terhadap pengembangan proyek, ketika para pembuat kebijakan untuk proyek pentingnya analisis permintaan pada manusia, material, waktu di tempat yang aman.
(2) pembentukan perlindungan jaringan, pembagian tanggung jawab yang jelas.
pengembangan Proyek biasanya akan mengatur tim proyek yang sesuai atau kelompok proyek, saat ini, bentuk umum dari organisasi adalah: produk pengelolaan kelompok, kualitas dan kelompok pengujian, tim program pembangunan, pengguna kelompok perwakilan dan kelompok dukungan logistik, divisi utama kelompok ini adalah: produk Manajemen Grup bertanggung jawab untuk mengidentifikasi dan menetapkan tujuan-tujuan proyek, sesuai dengan prioritas kebutuhan yang teridentifikasi spesifikasi fungsional, untuk personil yang relevan informasi dari kemajuan proyek. Manajer Program bertanggung jawab untuk analisis sistem, standar pengembangan perangkat lunak di bawah koordinasi dari hari ke hari pembangunan untuk menjamin pengiriman tepat waktu tugas pembangunan, kontrol kemajuan proyek. Program Pengembangan Bagian bertanggung jawab untuk spesifikasi fungsional sesuai dengan pengiriman sistem perangkat lunak. Kualitas dan tim pengujian yang bertanggung jawab untuk memastikan bahwa sistem memenuhi spesifikasi fungsional, pengujian dan pengembangan tidak tergantung pada paralel. Perwakilan Pengguna bertanggung jawab atas nama sisi pengguna untuk permintaan pengujian samping untuk pengguna perangkat lunak. kelompok dukungan logistik bertanggung jawab untuk memastikan kelancaran pekerjaan proyek dukungan logistik.
(3) untuk menciptakan lingkungan komunikasi yang baik dan suasana.
Analisis tingkat komunikasi antara staf dan kebutuhan pengguna analisis yang berkaitan dengan kualitas, sehingga menciptakan lingkungan komunikasi yang baik, penanganan hubungan antara staf dan pengguna sangat penting, secara umum, pengguna, karena investor akan memiliki beberapa keuntungan psikologis, Xi Wang pandangan mereka diberikan perhatian yang cukup, analis harus sepenuhnya menyadari hal ini, untuk mempersiapkan diri untuk menghindari perselisihan dengan mereka, karena tujuan kami adalah untuk membantu pengguna mengungkapkan kebutuhan utama mereka. Analis pada saat komunikasi harus diperhatikan aspek-aspek berikut: 1) sikap saling menghormati, tapi tidak kerendahan hati. Kerendahan hati dapat memungkinkan pengguna untuk sementara puas, tetapi tidak kerjasama jangka panjang yang bagus, terutama di saat konflik, pengguna tanah adat akan menemukan keuntungan mereka sendiri, tetapi untuk mengabaikan pandangan analis. 2) analis harus berusaha untuk beradaptasi dengan bahasa pengguna dengan cara-cara yang berbeda. Setiap orang memiliki cara mereka sendiri ekspresi, analis begitu baik harus menjadi pendengar yang "baik", mereka dapat dengan cepat beradaptasi dengan gaya bahasa pengguna, mengerti artinya. 3) mengungkapkan, pertanyaan yang bagus. Staf harus membiarkan pihak lain sebelum membuka ekspresi penuh makna itu, pemahaman yang terakhir, bicara nya, cobalah untuk tidak terburu-buru. 4) Pekerjaan pertukaran akan membantu meningkatkan pemahaman, meningkatkan komunikasi.
(4) persyaratan kualitas kontrol perlu dilembagakan perubahan tidak dapat dihindarkan bahwa proyek-proyek perangkat lunak.
Jadi persyaratan pengendalian kualitas adalah kerja keras, untuk menjamin kelancaran pelaksanaan pekerjaan, Anda harus memiliki sistem untuk memastikan bahwa sistem dapat dikembangkan dalam program pengendalian kualitas proyek, program ini terutama beton, deskripsi kuantitatif persyaratan pengguna untuk membentuk, analisis spesifikasi perangkat lunak komprehensif yang konsisten dan standar persyaratan, persyaratan spesifikasi analisis prosedur kerja yang jelas dan unsur-unsur, kegiatan pengembangan standar, untuk desain perangkat lunak tindak lanjut, implementasi, pengujian, penilaian dan memberikan dasar bagi penerimaan. Dalam program untuk menjelaskan tim membutuhkan kontrol kualitas semua departemen tentang tanggung jawab, kerja analisis kebutuhan untuk mengembangkan prosedur, termasuk penyusunan analisis kebutuhan rencana kerja, penyusunan "analisis kebutuhan" pernyataan, "kebutuhan spesifikasi analisis," penelaahan dan konfirmasi, "permintaan analisis spesifikasi, "perubahan kontrol, kontrol kualitas untuk menentukan kualitas rekaman permintaan standardisasi isi dokumen.
3,2 Persyaratan Pengembangan dan Pengelolaan beberapa cara
Persyaratan pembangunan merupakan tugas yang kompleks, metode yang digunakan banyak metode pengembangan yang berbeda adalah cara yang berbeda, berikut adalah beberapa metode sederhana terkait:
(1) Grey sistem: korelasi Gambar diagram sistem digunakan untuk menentukan sistem dan batasan sistem entitas eksternal dan antarmuka antara model sederhana.
(2) studi kelayakan: dalam biaya diizinkan, persyaratan kinerja, analisis kelayakan pelaksanaan setiap permintaan yang diajukan tuntutan untuk mencapai risiko yang relevan, termasuk konflik dengan persyaratan lain, ketergantungan pada faktor-faktor eksternal dan hambatan teknis.
(3) prioritas kebutuhan: identifikasi kasus penggunaan, fitur produk atau untuk mencapai prioritas kebutuhan individu. Prioritas dasar untuk menentukan versi produk yang akan menyertakan fitur atau jenis kebutuhan.
(4) prototipe sistem: bila pengguna itu sendiri tidak begitu jelas pada beberapa permintaan, kami dapat membangun sebuah prototipe sistem, evaluasi pengguna prototipe dengan pemahaman yang lebih baik dari masalah yang harus ditangani. .
(5) Graphic model: persyaratan perangkat lunak grafis menggambar model analisis adalah untuk menghasilkan sebuah cara penting dalam spesifikasi. Mereka dapat membantu analis memilah data, model bisnis, alur kerja, dan hubungan di antara mereka, untuk mencari yang hilang, persyaratan berlebihan dan tidak konsisten. Model ini meliputi diagram aliran data, diagram relasi entitas, negara transformasi diagram, diagram kotak dialog, kelas objek dan diagram interaksi.
(6) Data dictionary: kamus data yang digunakan pada sistem dan struktur dari semua definisi dari item data untuk memastikan bahwa pengembang menggunakan definisi data terpadu. Pada tahap permintaan, definisi kamus data item data nasabah setidaknya, untuk memastikan bahwa pelanggan dengan tim pembangunan adalah dengan menggunakan definisi dan terminologi yang sama.
(7) Kualitas fungsi penyebaran: penyebaran fungsi mutu merupakan teknologi sistem yang canggih, akan karakteristik produk, atribut dan pentingnya link pelanggan. Teknologi yang menyediakan metode untuk jelas yang paling prihatin dengan karakteristik pelanggan. Perlu terbagi menjadi tiga kategori: permintaan diharapkan, permintaan umum, kebutuhan kegembiraan.
Permintaan manajemen untuk mengontrol dan menjaga permintaan persetujuan sebelumnya, untuk memastikan konsistensi dari proses pembangunan proyek, yang memungkinkan pengguna untuk mendapatkan apa yang mereka ingin mendapatkan produk akhir. Permintaan manajemen termasuk aspek-aspek berikut:
1) menentukan persyaratan proses perubahan kontrol.
Pengembangan pilihan, analisa dan proses pengambilan keputusan perlu berubah, semua perubahan untuk semua kebutuhan proses yang harus diikuti.
2) untuk analisis dampak perubahan persyaratan.
Penilaian setiap perubahan yang diminta, untuk menentukan jadwal proyek dan tuntutan lainnya, hubungan yang jelas dengan perubahan dan untuk menilai tugas beban kerja yang diperlukan untuk menyelesaikan tugas ini. Melalui analisis ini akan membantu mengubah departemen pengawasan perlu membuat keputusan yang lebih baik.
3) menetapkan persyaratan dan kebutuhan kontrol versi versi dasar dari dokumen.
Tentukan dasar permintaan, ini project kebutuhan untuk mencapai kesepakatan tentang pemahaman para pihak untuk sebuah snapshot waktu, maka permintaan perubahan dapat mengikuti proses kontrol perubahan. Spesifikasi untuk setiap versi dari catatan permintaan harus independen untuk menghindari yang lama dan versi baru dari kertas dan benchmark atau bingung.
4) persyaratan pemeliharaan sejarah perubahan.
Situasi ini akan menuntut perubahan pada dokumen-dokumen tertulis, catatan perubahan tanggal, alasan, orang yang bertanggung jawab, nomor versi, dll, pemberitahuan tepat waktu kepada staf yang terlibat dalam pengembangan proyek. Untuk meminimalkan kebingungan, konflik, yg keliru, harus menunjuk orang yang bertanggung jawab untuk memperbarui permintaan.
5) pelacakan status kebutuhan masing-masing.
Dapat permintaan negara masing-masing properti (jika ia telah merekomendasikan telah diadopsi, telah dilaksanakan, atau telah memverifikasi) disimpan dalam database, ini bisa mendapatkan setiap orang dalam kelas negara Renhe ketika kuantitas yang diminta.
6) untuk mengukur stabilitas permintaan. Sebuah secara teratur jumlah dan perlu menuntut perubahan (menambah, mengubah, menghapus) jumlah perbandingan.
Kebutuhan untuk mengubah terlalu banyak "adalah sinyal peringatan", yang berarti masalah belum benar-benar jelas.
4 Persyaratan Standar Analisis dan Evaluasi
Bagaimana menentukan spesifikasi persyaratan yang baik atau buruk, berbagai perangkat lunak spesifikasi teknik telah menetapkan sendiri standar, di sini untuk memberitahu Anda NASA lebih umum SEL dianjurkan metode, yang didanai oleh National Aeronautics dan Administrasi Ruang Angkasa dikembangkan di laboratorium Rekayasa Perangkat Lunak Lima standar internasional yang umum digunakan rekayasa perangkat lunak, perangkat lunak proses persyaratan, kriteria evaluasi adalah: jelas, lengkap, konsisten, bisa diuji.
(1) jelas: Sebagian besar analisis kebutuhan masih digunakan dalam bahasa alam, bahasa alam analisis kebutuhan dari kekurangan terbesar adalah ambiguitas, sehingga pengembang perlu permintaan bahasa yang digunakan untuk melakukan beberapa pembatasan.
Seperti penggunaan ekspresi + tindakan sederhana subjek. Analisis kebutuhan harus dijelaskan dalam sederhana, tidak menggunakan pertanyaan, modifikasi dari ekspresi kompleks. Selain ambiguitas bahasa, perhatikan untuk tidak menggunakan jargon, adalah istilah komputer. Analisis kebutuhan yang paling penting dan komunikasi pengguna, namun sebagian besar pengguna komputer tidak profesional, jika permintaan jargon yang digunakan dalam analisis, itu akan menyebabkan pengguna untuk memahami kesulitan.
(2) integritas: integritas permintaan sangat penting, jika ada kelalaian apapun kebutuhan, kemudian harus menulis ulang semua proses pengembangan perangkat lunak, hal terburuk adalah penyelesaian dekat dalam pengembangan perangkat lunak, menuntut ditemukan hilang.
Tetapi kenyataannya adalah bahwa permintaan sering ditinggalkan apa yang terjadi, pengembang tidak hanya dari masalah, lebih banyak pengguna di sana. Untuk mencapai integritas permintaan adalah hal yang sangat sulit, ia melibatkan semua aspek dari proses analisis kebutuhan, seluruh proses, dari awal pembangunan untuk perencanaan kebutuhan permintaan akhir penilaian.
(3) Konsistensi konsisten berarti: bahwa kebutuhan pengguna dan kebutuhan bisnis harus konsisten, persyaratan fungsional dan user harus konsisten.
Dalam proses persyaratan, pengembang perlu untuk memperbaiki hubungan konsistensi, seperti permintaan pengguna tidak melebihi rentang pra-pra-ditentukan. kepatuhan ketat dengan konsistensi hubungan antara tingkat yang berbeda, kami dapat memastikan bahwa sistem perangkat lunak akhir ini dikembangkan tidak akan menyimpang dari tujuan aslinya.
(4) untuk menguji: uji proyek dari jam berapa?
Beberapa orang mengatakan bahwa mulai dari coding selesai, itu dikatakan saat pengkodean unit testing, implementasi, pengujian sistem selesai, kesimpulan ini tidak sepenuhnya benar. Bahkan, tes dimulai dari proses analisis kebutuhan, karena permintaan yang merupakan masukan dan rencana uji referensi. Ini membutuhkan analisis kebutuhan adalah untuk menguji hanya persyaratan sistem semua yang dapat diuji, untuk memastikan perangkat lunak selalu di sekitar kebutuhan pengguna untuk memastikan sistem perangkat lunak ini sukses.
Tidak ada komentar:
Posting Komentar