Persyaratan Rekayasa Proses

Slides:



Advertisements
Presentasi serupa
Overview Komponen Sistem SQA
Advertisements

Proses-proses Perangkat Lunak
Rekayasa Perangkat Lunak dan Proses Software
Software Requirement Specification
Sasaran Menjelaskan apa yang dimaksud model proses
PROSES-PROSES PERANGKAT LUNAK
AUDIT SISTEM INFORMASI MANAJEMEN ASET BERDASARKAN PERSPEKTIF PROSES BISNIS INTERNAL BALANCED SCORECARD DAN STANDAR COBIT 4.1 (Studi Kasus: PT. Pertamina.
SIKLUS HIDUP SISTEM Pertemuan Ke-7.
REKAYASA SISTEM SESI : 2 BY ARISM,SKOM,MMSI. MANPRO-M2 : REKAYASA SI.
REKAYASA PERANGKAT LUNAK
Requirement.
Pengembangan perangkat lunak
Konsep & Prinsip Analisis
4. Model Proses Analisis Bisnis
Perancangan Perangkat Lunak
4. Model Proses Analisis Bisnis
Methods for Software Engineering CHAPTER 5 Software Project Planning Software engineering: a practitioner’s approach / Roger S. Pressman.—5th ed.
Diadopsi dari presentasi Ian Sommeriville, Pengantar Rekayasa Perangkat Lunak.
4. Model Proses Analisis Bisnis
Pusat Pusat Tanggung Tanggung Jawab Pendapatan dan Beban Jawab Pendapatan dan Beban KELOMPOK 6: TAUFIANI ISTI IDAYANTI( ) NABILAH MAULIDIYAH( )
APA ITU REKAYASA KEBUTUHAN ??
Manajemen Proyek Web.
Perspektif Pemangku Kepentingan
Spesifikasi Perangkat Lunak
ANALISIS DAN PERANCANGAN SISTEM (APS)
ANALISIS KEBUTUHAN.
METODOLOGI MANAJEMEN PROYEK
REKAYASA PERANGKAT LUNAK
Dokumentasi & Pengelolaan Kebutuhan
Chapter 7. Requirements Negotiation
BAB IV STRATEGI.
Pengantar Analisis Bisnis & Kompetensi Analis Bisnis
FASE DELIVERY MPSI Sesi 11.
Pengumpulan Kebutuhan dan Dokumentasi
PO2 define the information architecture Plan and organise
Nur fisabilillah, S.Kom, MMSI | UNIVERSITAS GUNADARMA
Pendahuluan Muhammad Rachmadi, S.T., M.T.I..
4 Managing Software Requirement Analisis Kebutuhan
PROSES REKAYASA PERSYARATAN
Materi #04 Manajemen Integrasi Proyek Pariwisata
Pemodelan Tujuan dan Penalaran dengan Mereka
Jaminan Mutu dalam Kebutuhan Rekayasa
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Management Projeck “Fase Inisialisasi dan Reqiurement Analisys”
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
PERTEMUAN – 2 MEMULAI PROYEK. PERTEMUAN – 2 MEMULAI PROYEK.
MANAJEMEN PROYEK PERANGKAT LUNAK
TIM PROYEK.
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Pembangunan Kasus Bisnis & Penentuan Alternatif
Pelaksanaan Solusi Bisnis & Pengelolaan Perubahan
Analisis Kebutuhan.
Pemodelan Proses Bisnis by : Sol’s
REKAYASA PERANGKAT LUNAK
Manajemen Proyek Sistem Informasi DAY-2
Pengembangan Kebutuhan Bisnis
Rekayasa Kebutuhan.
Pertemuan 8 Rekayasa Kebutuhan
Rancangan Infrastruktur Business-Driven (1)
INTERAKSI MANUSIA DAN KOMPUTER
5 Kebutuhan Software By : Andi Latifa Nabone.
ANALISA KEBUTUHAN PERANGKAT LUNAK
PERANCANGAN BASIS DATA
Penyusunan Anggaran.
Kerangka Kerja IT Balanced Scorecard
Proses Rekayasa Kebutuhan
Aplikasi dan Rekayasa E-Bisnis
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
Strategi Implementasi ITIL
Framework TOGAF SI402 Arsitektur Enterprise Pertemuan #9
Transcript presentasi:

Persyaratan Rekayasa Proses 6 Persyaratan Rekayasa Proses By : Andi Latifa Nabone

Topik yang dibahas Studi kelayakan Persyaratan elisitasi dan analisis Persyaratan validasi Persyaratan manajemen

Persyaratan proses rekayasa Proses yang digunakan untuk RE sangat bervariasi tergantung pada domain aplikasi, orang yang terlibat dan organisasi mengembangkan persyaratan. Namun, ada sejumlah aktivitas generik umum untuk semua proses Persyaratan elisitasi; Persyaratan analisis; Persyaratan validasi; Persyaratan manajemen.

Studi kelayakan Sebuah studi kelayakan memutuskan apakah sistem yang diusulkan adalah berharga. Sebuah studi difokuskan singkat yang memeriksa Jika sistem memberikan kontribusi kepada tujuan organisasi; Jika sistem tersebut dapat direkayasa dengan menggunakan teknologi saat ini dan sesuai dengan anggaran; Jika sistem dapat diintegrasikan dengan sistem lain yang digunakan.

Studi kelayakan pelaksanaan Berdasarkan penilaian informasi (apa yang diperlukan), pengumpulan informasi dan penulisan laporan. Pertanyaan untuk orang-orang dalam organisasi Bagaimana jika sistem tidak diimplementasikan? Apa masalah proses saat ini? Bagaimana bantuan sistem yang diusulkan? Apa yang akan menjadi masalah integrasi? Adalah teknologi baru yang dibutuhkan? Keterampilan apa? Fasilitas apa harus didukung oleh sistem yang diusulkan?

Elisitasi dan analisis Kadang-kadang disebut elisitasi persyaratan atau penemuan persyaratan. Melibatkan staf teknis bekerja dengan pelanggan untuk mencari tahu tentang domain aplikasi, layanan bahwa sistem harus menyediakan dan kendala operasional sistem. Mungkin melibatkan pengguna akhir, manajer, insinyur yang terlibat dalam perawatan, ahli domain, serikat buruh, dll disebut stakeholder.

Masalah persyaratan analisis Stakeholder tidak tahu apa yang mereka inginkan. Pemangku kepentingan menyatakan persyaratan dalam istilah mereka sendiri. Pemangku kepentingan yang berbeda mungkin memiliki kebutuhan yang saling bertentangan. Organisasi dan faktor-faktor politik dapat mempengaruhi persyaratan sistem. Persyaratan berubah selama proses analisis. Stakeholder baru mungkin muncul dan perubahan lingkungan bisnis.

Proses kegiatan Persyaratan penemuan Berinteraksi dengan pemangku kepentingan untuk menemukan kebutuhan mereka. Persyaratan Domain juga ditemukan pada tahap ini. Persyaratan klasifikasi dan organisasi Groups persyaratan yang berkaitan dan mengatur mereka ke dalam cluster yang koheren. Prioritas dan negosiasi Memprioritaskan persyaratan dan menyelesaikan konflik persyaratan. Persyaratan dokumentasi Persyaratan didokumentasikan dan masukan ke putaran berikutnya spiral.

Persyaratan penemuan Proses pengumpulan informasi tentang sistem yang diusulkan dan penyulingan ada dan kebutuhan pengguna dan sistem dari informasi ini. Sumber informasi termasuk dokumentasi, stakeholder sistem dan spesifikasi sistem yang sama.

ATM stakeholder Nasabah bank Perwakilan dari bank lain Manajer bank Counter staf Database administrator Keamanan manajer Pemasaran departemen Perangkat keras dan perangkat lunak insinyur pemeliharaan Perbankan regulator

Jenis sudut pandang Interactor sudut pandang Orang atau sistem lain yang berinteraksi langsung dengan sistem. Dalam ATM, pelanggan dan database rekening adalah VP interactor. Langsung sudut pandang Stakeholders yang tidak menggunakan sistem sendiri, tetapi yang mempengaruhi persyaratan. Dalam ATM, manajemen dan staf keamanan pandangan langsung. Domain sudut pandang Domain karakteristik dan kendala yang mempengaruhi persyaratan. Dalam ATM, sebuah contoh akan standar untuk komunikasi antar-bank.

Persyaratan validasi Prihatin dengan menunjukkan bahwa persyaratan sistem menentukan bahwa pelanggan benar-benar ingin. Biaya kesalahan Persyaratan yang tinggi sehingga validasi sangat penting Memperbaiki kesalahan persyaratan setelah melahirkan mungkin biaya hingga 100 kali biaya memperbaiki kesalahan implementasi.

Persyaratan memeriksa Validitas. Apakah sistem menyediakan fungsi yang paling mendukung kebutuhan pelanggan? Konsistensi. Apakah ada konflik persyaratan? Kelengkapan. Apakah semua fungsi yang dibutuhkan oleh pelanggan disertakan? Realisme. Dapatkah persyaratan diterapkan diberikan anggaran yang tersedia dan teknologi Verifiability. Dapatkah persyaratan diperiksa?

Persyaratan teknik validasi Persyaratan tinjauan Sistematis manual analisis persyaratan. Prototyping Dengan menggunakan model eksekusi dari sistem untuk memeriksa persyaratan. Dibahas di Bab 17. Uji kasus generasi Mengembangkan tes untuk persyaratan untuk memeriksa testability.

Persyaratan tinjauan Tinjauan rutin harus dilakukan sementara definisi persyaratan sedang dirumuskan. Kedua staf klien dan kontraktor harus dilibatkan dalam tinjauan. Tinjauan mungkin formal (dengan dokumen lengkap) atau informal. Komunikasi yang baik antara pengembang, pelanggan dan pengguna dapat menyelesaikan masalah-masalah pada tahap awal.

Review cek Verifiability. Apakah persyaratan realistis diuji? Komprehensibilitas. Apakah persyaratan dengan benar dipahami? Ketertelusuran. Apakah asal persyaratan dinyatakan dengan jelas? Adaptasi. Persyaratan dapat berubah tanpa dampak besar pada persyaratan lain?

Persyaratan manajemen Persyaratan manajemen adalah proses pengelolaan perubahan kebutuhan selama proses rekayasa persyaratan dan pengembangan sistem. Persyaratan yang pasti tidak lengkap dan tidak konsisten Persyaratan baru muncul selama proses tersebut sebagai kebutuhan bisnis perubahan dan pemahaman yang lebih baik dari sistem dikembangkan; Sudut pandang yang berbeda memiliki kebutuhan yang berbeda dan ini sering bertentangan.

Persyaratan perubahan Prioritas kebutuhan dari perubahan sudut pandang yang berbeda selama proses pembangunan. Pelanggan Sistem dapat menentukan persyaratan dari perspektif bisnis yang bertentangan dengan kebutuhan pengguna akhir. Lingkungan bisnis dan teknis dari perubahan sistem selama perkembangannya.

Persyaratan manajemen perencanaan Selama proses rekayasa persyaratan, Anda harus merencanakan: Persyaratan identifikasi Bagaimana kebutuhan secara individual diidentifikasi; Sebuah proses perubahan manajemen Proses diikuti ketika menganalisis perubahan persyaratan; Ketertelusuran kebijakan Jumlah informasi tentang hubungan persyaratan yang dipelihara; KASUS alat dukungan Dukungan alat yang dibutuhkan untuk membantu mengelola perubahan persyaratan;

Persyaratan manajemen perubahan Harus berlaku untuk semua perubahan yang diajukan dengan kebutuhan. Pokok tahap Analisis masalah. Diskusikan masalah persyaratan dan mengusulkan perubahan; Ubah analisis dan biaya. Menilai dampak perubahan persyaratan lain; Perubahan implementasi. Modifikasi persyaratan dokumen dan dokumen lain untuk mencerminkan perubahan.

terima kasih