5.1. Introduction Sebagian besar kebutuhan individu, yang dikembangkan selama rekayasa persyaratan (RE) proses, tidak dapat diperlakukan secara tersendiri.

Slides:



Advertisements
Presentasi serupa
ANALISIS DAN DESAIN SISTEM Mohamad Sidiq Magister Komputer Universitas Dian Nuswantoro 2a2a SYSTEM ANALYSIS P E R T E M U A N.
Advertisements

Sasaran Menjelaskan apa yang dimaksud model proses
PENGENALAN ANALISA SISTEM BERORIENTASI OBYEK
PENGANTAR REKAYASA PERANGKAT LUNAK I
SIKLUS PENGEMBANGAN SISTEM
Aktifitas Pengembangan Sistem
REKAYASA PERANGKAT LUNAK
Selamat Datang Peserta Pra Konferensi
Methods for Software Engineering CHAPTER 5 Software Project Planning Software engineering: a practitioner’s approach / Roger S. Pressman.—5th ed.
1. Pengantar Analisis Bisnis
4. Model Proses Analisis Bisnis
MODEL PROSES REKAYASA PERANGKAT LUNAK
Metode rpl BY: Y. PALOPAK S.Si., MT..
Chapter 4 Requirements Prioritization
EFISIENSI PENGELOLAAN TRANSPORTASI
REKAYASA PERANGKAT LUNAK
APA ITU REKAYASA KEBUTUHAN ??
Spesifikasi Perangkat Lunak
ANALISIS KEBUTUHAN.
Intro TO EA (2).
Impact Analysis.
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
Review Rekayasa Perangkat Lunak
proses PERANGKAT LUNAK
Engineering and Managing Software Requirements
Dokumentasi & Pengelolaan Kebutuhan
Pengenalan Rekayasa Perangkat Lunak
Chapter 7. Requirements Negotiation
Pengantar Analisis Bisnis & Kompetensi Analis Bisnis
Model Proses Analisis Bisnis
Pengumpulan Kebutuhan dan Dokumentasi
Mempersiapkan Proposal Riset
Perancangan Sistem Informasi
Infrastruktur TI dan Teknologi baru
Pemeliharaan Perangkat Lunak
Metode Rekayasa Perangkat Lunak
REKAYASA PERANGKAT LUNAK
4 Managing Software Requirement Analisis Kebutuhan
Arsitektur Enterprise
Pemodelan Tujuan dan Penalaran dengan Mereka
Jaminan Mutu dalam Kebutuhan Rekayasa
Persyaratan Rekayasa Proses
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Management Projeck “Fase Inisialisasi dan Reqiurement Analisys”
Database Change Management source : Database Administration the complete guide to practices and procedures chapter 7 by. Craig S. Mullins.
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Pembangunan Kasus Bisnis & Penentuan Alternatif
Pelaksanaan Solusi Bisnis & Pengelolaan Perubahan
Analisis Kebutuhan.
Arsitektur Enterprise
Enterprise Architecture
Pertemuan-2 PROSES PENELITIAN, PERUMUSAN MASALAH DAN TUJUAN, DAN STUDI LITERATUR
PERTEMUAN 2 Proses Pengembangan Perangkat Lunak
SDLC (System Development Life Cycle)
TESTING DAN IMPLEMENTASI SISTEM (Pertemuan Ke-7)
Metode Rekayasa Perangkat Lunak
Review Rekayasa Perangkat Lunak
Pengembangan Kebutuhan Bisnis
REKAYASA PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
Dokumentasi Rekomendasi Teknologi
Review Rekayasa Perangkat Lunak
Review Rekayasa Perangkat Lunak
Kerangka Kerja IT Balanced Scorecard
Proses Rekayasa Kebutuhan
Transisi Layanan Teknologi Informasi
SISTEM INFORMASI AKUNTANSI
Manajemen Proyek.
Transcript presentasi:

Chapter 5 Requirements Interdependencies: State of the Art and Future Challenges

5.1. Introduction Sebagian besar kebutuhan individu, yang dikembangkan selama rekayasa persyaratan (RE) proses, tidak dapat diperlakukan secara tersendiri selama pengembangan perangkat lunak. Sebaliknya mereka terkait dan saling mempengaruhi dalam perilaku yang kompleks [5, 33]. Sebuah studi terbaru menunjukkan bahwa hanya sekitar seperlima dari persyaratan dalam setiap set persyaratan yang benar-benar tunggal, yaitu, tidak terkait dengan atau mempengaruhi persyaratan lain [5]. Contoh bagaimana persyaratan dapat mempengaruhi satu sama lain ketika salah satu persyaratan: Membatasi bagaimana persyaratan lainnya dapat dirancang atau diimplementasikan Mempengaruhi biaya pelaksanaan persyaratan lain, atau Menambah atau mengurangi kepuasan pelanggan persyaratan lainnya

5.2 Persyaratan traceability: Sebuah Dasar Memahami persyaratan Saling ketergantungan Ada beberapa definisi yang berbeda dari kebutuhan jangka traceability (lihat misalnya [16, 18, 26, 34]). Dalam bab ini, kami telah memilih untuk mendefinisikannya sebagai "kemampuan untuk menggambarkan dan mengikuti kehidupan suatu kebutuhan, baik depan dan arah belakang, idealnya melalui siklus hidup seluruh sistem" ([17], p. 32, berdasarkan [13]). Definisi ini adalah salah satu yang paling sering digunakan dalam lapangan. Persyaratan mampu telusur, secara umum, dicapai melalui bergaul obyek informasi terkait seperti: Persyaratan dan komponen sistem yang terkait memuaskan kebutuhan tersebut Tujuan Sistem dan persyaratan yang berasal dari persyaratan Perubahan proposal dan persyaratan yang mereka berniat untuk mengubah Keputusan dan alasan-alasan dan asumsi yang mereka didasarkan Uji kasus dan persyaratan yang pemenuhannya mereka berniat untuk memastikan, dan Komponen sistem dan sumber daya yang dibutuhkan untuk menerapkan persyaratan

5.2.1 Mengapa Persyaratan traceability? Persyaratan traceability saat ini dianggap sebagai dukungan yang penting untuk mengembangkan sistem perangkat lunak berkualitas tinggi. Untuk menghindari kesalahan yang mahal, informasi traceability diperlukan sebagai dasar untuk keputusan dan tugas-tugas di sebagian besar tahapan proses pengembangan perangkat lunak [12, 26]. Salah satu contoh adalah dalam integrasi perubahan, di mana informasi traceability memungkinkan identifikasi dampak perubahan yang diusulkan [22, 30, 37]. Mengidentifikasi bagaimana persyaratan dan artefak lainnya dipengaruhi oleh usulan perubahan memfasilitasi biaya yang lebih akurat dan analisis jadwal. Persyaratan traceability juga mendukung pemahaman mengapa objek tertentu telah dibuat, dimodifikasi dan berkembang [30].

5.2.2 Berbagai Jenis Persyaratan traceability Gambar 5.1 menyajikan gambaran persyaratan traceability dan menunjukkan apa yang dimaksud dengan maju dan mundur arah yang disebutkan dalam definisi. Namun, itu adalah pandangan yang disederhanakan dari apa jenis informasi yang harus terkait untuk memastikan persyaratan traceability, seperti yang ditunjukkan oleh contoh di atas. Sebagai angka menunjukkan, persyaratan traceability dapat dibagi menjadi dua jenis utama: pretraceability dan post-traceability [13].

Pre-traceability mengacu pada aspek-aspek kehidupan persyaratan sebelum hal ini termasuk dalam persyaratan spesifikasi [13] dan berfokus pada memungkinkan pemahaman yang lebih baik dari persyaratan. Pre-traceability termasuk menelusuri elisitasi dan definisi persyaratan, serta evolusi mereka [26]. Persyaratan harus berkaitan dengan asal-usul mereka misalnya stakeholder yang (S), business rule (BR), atau dokumentasi sebelumnya (Doc), tetapi juga untuk persyaratan terkait lainnya misalnya melalui persyaratan dekomposisi. Persyaratan pre-traceability adalah dasar untuk mengelola evolusi sistem, karena memungkinkan elisitasi bagian dari spesifikasi yang dipengaruhi oleh permintaan perubahan tertentu yang diangkat, misalnya oleh kebijakan organisasi, proses bisnis, atau penggunaan sistem.

Post-traceability mengacu pada aspek-aspek kehidupan persyaratan itu dari titik waktu ketika telah dimasukkan dalam persyaratan spesifikasi dan maju [13] dan berfokus pada memungkinkan pemahaman yang lebih baik dan penerimaan sistem saat ini / software. Post-traceability berkaitan dengan memastikan bahwa semua persyaratan dipenuhi oleh sistem, melalui desain dan implementasi sistem, dengan mengaitkan persyaratan untuk komponen (C), yang membantu memuaskan bahwa persyaratan tertentu. Tidak ada persyaratan harus hilang dan tidak ada tambahan [26]. Hal ini juga melibatkan berkaitan persyaratan untuk menguji kasus, yang harus digunakan untuk memastikan bahwa komponen memenuhi kebutuhan tersebut. Persyaratan post-traceability juga penting untuk integrasi perubahan dengan memungkinkan identifikasi dampak perubahan terhadap desain dan implementasi [22].

5.2.3 A Meta-Model of Requirements Traceability The meta-model disajikan pada Gambar. 5.2 menunjukkan perspektif utama persyaratan traceability [32] dan juga menunjukkan bahwa ada beberapa dimensi informasi traceability. Sumber itu adalah artefak fisik di mana informasi tersebut dipertahankan, misalnya dokumen persyaratan spesifikasi, dokumen desain, memorandum, dan telepon. Perspektif ini menekankan manajemen dokumen bagian dari traceability, yang penting karena jejak benda yang tersedia dalam sumber-sumber persisten merupakan traceability jangka panjang. Stakeholder adalah agen yang terlibat dalam pengelolaan traceability, misalnya pelanggan, analis sistem, dan manajer proyek.

5.2.4 Beberapa Catatan Penutup tentang Persyaratan traceability Dalam bab ini, kita fokus pada aspek obyek persyaratan traceability dan dimensi mengenai informasi yang harus diwakili apa. Lebih khusus lagi, kita fokus pada objek dari satu jenis tertentu - persyaratan - dan mampu telusur antara kebutuhan. Ini didefinisikan di atas sebagai terutama masalah pre-traceability (lihat Gambar. 5.1) termasuk dalam kategori traceability horisontal, karena kita berhubungan objek informasi dari jenis yang sama.

5.3 Gambaran Umum Tipe Ketergantungan Dalam Sect. 5.2 Persyaratan saling ketergantungan digambarkan sebagai isu spesifik dalam persyaratan traceability. Adapun traceability secara umum, ada beberapa cara di mana persyaratan dapat berhubungan satu sama lain. Bagian ini memberikan gambaran tentang jenis saling ketergantungan saat ini dikenal, yang dapat digunakan untuk menggambarkan hubungan antara kebutuhan.

5.3.1 Structural Interdependencies Saling ketergantungan struktural yang bersangkutan dengan fakta bahwa diberi satu set spesifik persyaratan, mereka dapat diatur dalam struktur di mana hubungan yang hirarkis dari sebuah serta bersifat lintas-struktur. Kebutuhan bisnis tingkat tinggi secara bertahap didekomposisi menjadi persyaratan perangkat lunak yang lebih rinci, membentuk sebuah hirarki. Juga, bisa ada hubungan struktural antara persyaratan dalam bagian yang berbeda dari hirarki secara keseluruhan.

5.3.2 Membatasi Saling ketergantungan Beberapa literatur memperkenalkan jenis saling ketergantungan yang cukup luas dan umum sehingga ada beberapa persyaratan yang bergantung pada atau yang membatasi orang lain [26, 38]. Hipotesis kami adalah bahwa saling ketergantungan yang lebih rinci dapat diidentifikasi di sini untuk menggambarkan bagaimana persyaratan dapat membatasi satu sama lain atau tergantung pada satu sama lain, terutama jika klasifikasi ini dijabarkan lebih lanjut sehubungan dengan kegiatan pembangunan yang berbeda atau keputusan. Namun, pada tahap ini kita memilih untuk menyertakan kategori interdependensi umum ini, menyadari kebutuhan untuk penelitian lebih lanjut. Kami telah, sejauh ini, mengidentifikasi dua jenis dalam kategori ini. Requires dan Conflicts with.

5.3.3 Cost/ Nilai Saling Ketergantungan Biaya / nilai interdependensi berkepentingan dengan biaya yang terlibat dalam pelaksanaan persyaratan dalam kaitannya dengan nilai bahwa pemenuhan persyaratan yang akan memberikan kepada pelanggan / pengguna dirasakan. Jenis saling ketergantungan berikut termasuk dalam kategori ini (baik ini juga disebutkan dalam kaitannya dengan negosiasi di Bab 4.):

5.4 Bagaimana Pengetahuan tentang Persyaratan Saling Ketergantungan Memfasilitasi Rekayasa Perangkat Lunak? Kami berpendapat bahwa persyaratan yang saling tergantung dan bahwa dependensi ini mempengaruhi aktivitas yang berbeda dalam proses rekayasa perangkat lunak. Bagian ini menyajikan gambaran situasi selama rekayasa perangkat lunak di mana saling ketergantungan dapat mempengaruhi tugas-tugas yang dilakukan. Hal ini bertujuan untuk memberikan wawasan tentang bagaimana persyaratan saling ketergantungan mempengaruhi kegiatan dalam rekayasa perangkat lunak dan bagaimana pengetahuan tentang dependensi dapat memfasilitasi pengembangan perangkat lunak. Untuk setiap kegiatan yang dijelaskan, jenis keterkaitan yang relevan dengan kegiatan yang dibahas.

Requirements Management Change Management and Impact Analysis Release Planning Reuse of Components Reuse of Requirements Design and Implementation Testing

5.5 Masalah Penelitian Topik kebutuhan interdependensi terbilang belum dieksplorasi dan beragam. Ada beberapa bagian di mana lebih banyak penelitian telah dilakukan, misalnya dalam persyaratan manajemen manajemen interaksi dan persyaratan konflik, tapi secara keseluruhan sejumlah besar penelitian tambahan diperlukan untuk memberikan pandangan yang komprehensif dari daerah seperti itu. Penelitian lebih lanjut juga diperlukan masalah-interdependensi terkait dan solusi mereka. Bagian ini memperkenalkan penelitian agenda yang terdiri dari empat bidang utama.

Quick overview of what this meeting is all about Agenda What to expect

Brainstorming Objectives Describe the objective(s) of the exercise New product or service ideas? New feature ideas? Feature/product naming? Promotion ideas? New process for doing something? Define top requirements or restrictions

Rules No idea is a bad idea Be creative Take risks No criticism allowed

Brainstorming Activity Generate ideas Use games and exercises to “warm up” your creative thinking When ideas slow down, try another exercise to generate fresh ideas Breaking into smaller groups may be helpful Use a computer to capture every comment/idea

Summarize Review ideas Vote on top candidates and consolidate Check requirements and restrictions Trim list to top 5-10 ideas

Describe what happens next: Next Steps Describe what happens next: Research the ideas generated? Follow up with larger group? Generate action items for follow-up: Start turning ideas into reality