ScenIC: Perbedaan antara revisi
Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 28471124; atribusi sumber disertakan. |
Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi |
||
| Baris 1: | Baris 1: | ||
'''ScenIC''' adalah metode [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan perangkat lunak]] untuk [[sistem]] yang berkembang. Berasal dari model ''Inquiry Cycle'' pada penyempurnaan kebutuhan, metode ini menggunakan penyempurnaan ''goal'' dan analisis skenario sebagai strategi metodologis utamanya. ScenIC bersandar pada analogi memori manusia: ''semantic memory'' terdiri dari generalisasi tentang sifat-sifat sistem; ''episodic memory'' terdiri atas episode dan skenario tertentu; dan ''working memory'' terdiri dari pengingat tentang penyempurnaan yang tidak lengkap. Metode khusus dari pedoman pengingat dan resolusi diaktifkan oleh keadaan dari ''episodic memory'' atau ''semantic memory''. ScenIC merupakan representatif dari ''Inquiry Cycle'', yang merupakan aplikasi siklus dari langkah-langkah berikut: ekspresi ide semantik atau episodik, mengangkat dan menyelesaikan masalah (kritik), dan penyempurnaan memori jangka panjang. Ekspresi didukung dengan mengadopsi skema ''semantic memory'' dan ''episodic memory'', kemudian kritik oleh pedoman pengungkapan masalah yang dapat mengarahkan perhatian, sedangkan penyempurnaan didukung oleh pedoman resolusi yang menyarankan penyempurnaan. | '''ScenIC''' adalah metode [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan perangkat lunak]] untuk [[sistem]] yang berkembang. Berasal dari model ''Inquiry Cycle'' pada penyempurnaan kebutuhan, metode ini menggunakan penyempurnaan ''goal'' dan analisis skenario sebagai strategi metodologis utamanya. ScenIC bersandar pada analogi memori manusia: ''semantic memory'' terdiri dari generalisasi tentang sifat-sifat sistem; ''episodic memory'' terdiri atas episode dan skenario tertentu; dan ''working memory'' terdiri dari pengingat tentang penyempurnaan yang tidak lengkap. Metode khusus dari pedoman pengingat dan resolusi diaktifkan oleh keadaan dari ''episodic memory'' atau ''semantic memory''. ScenIC merupakan representatif dari ''Inquiry Cycle'',<ref name=":0">C. Potts. [http://dx.doi.org/10.1109/52.268952 Inquiry-based requirements analysis]. ''IEEE Software''. 1994-03. Vol. 11 (2). hlm. 21–32. doi:10.1109/52.268952.</ref><ref>C. Potts. [http://dx.doi.org/10.1109/isre.1995.512559 An evaluation of inquiry-based requirements analysis for an Internet service]. ''Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)''. IEEE Comput. Soc. Press. doi:10.1109/isre.1995.512559. ISBN 0818670177.</ref> yang merupakan aplikasi siklus dari langkah-langkah berikut: ekspresi ide semantik atau episodik, mengangkat dan menyelesaikan masalah (kritik), dan penyempurnaan memori jangka panjang. Ekspresi didukung dengan mengadopsi skema ''semantic memory'' dan ''episodic memory'', kemudian kritik oleh pedoman pengungkapan masalah yang dapat mengarahkan perhatian, sedangkan penyempurnaan didukung oleh pedoman resolusi yang menyarankan penyempurnaan.<ref name=":1">C. Potts. [http://dx.doi.org/10.1109/isre.1999.777985 ScenIC: a strategy for inquiry-driven requirements determination]. ''Proceedings IEEE International Symposium on Requirements Engineering (Cat. No.PR00188)''. IEEE Comput. Soc. doi:10.1109/isre.1999.777985. ISBN 0769501885.</ref> | ||
== Skema Memori ScenIC == | == Skema Memori ScenIC == | ||
Masing-masing dari tiga memori ScenIC memiliki skema ''entity-relationship''. Spesifikasi detail elemen skema dibiarkan tidak terdefinisi sehingga ScenIC dapat diterapkan pada berbagai tingkat formalitas. | Masing-masing dari tiga memori ScenIC memiliki skema ''entity-relationship''. Spesifikasi detail elemen skema dibiarkan tidak terdefinisi sehingga ScenIC dapat diterapkan pada berbagai tingkat formalitas.<ref name=":1" /> | ||
'''Skema ''Semantic Memory''''' | '''Skema ''Semantic Memory''''' | ||
''Semantic memory'' ScenIC mencerminkan informasi tentang sistem. Karena ''semantic memory'' berubah selama penyempurnaan, "sistem" dapat mencakup "lingkungan" dan "mesin". Entitas semantik dalam ScenIC meliputi aktor (''actor)'', tujuan ''(goal)'', dan hambatan ''(obstacle)''. Aktor adalah entitas yang berpartisipasi dalam perubahan keadaan . Aktor eksternal termasuk peran pengguna, organisasi, perangkat fisik, sistem eksternal, dan alam. Aktor internal adalah yang diduga sebagai komponen arsitektur, atau keseluruhan sistem yang dipandang sebagai kotak hitam ''(black box).'' Ada dua macam tujuan: objektif dan tugas. Objektif diekspresikan oleh lintasan perbaikan (mis. "Mengurangi keluhan pelanggan") atau pelestarian atau pencegahan keadaan (mis. "Lift tidak boleh bergerak saat pintunya terbuka").Tugas adalah tujuan yang dinyatakan dalam hal pencapaian suatu keadaan atau kinerja suatu tindakan (mis. "Begitu permintaan rapat dimasukkan ke dalam sistem, waktu dan tempat akan langsung dijadwalkan.) Objektif tidak dapat dicapai secara langsung oleh mesin, tetapi secara tidak langsung diwujudkan melalui kombinasi tugas. Misalnya, untuk mengurangi keluhan pelanggan, pengguna dan mesin melakukan tindakan terkoordinasi yang terperinci. Tugas, sebaliknya, dapat direalisasikan langsung oleh aktor, meskipun beberapa mungkin memerlukan ekspansi lebih lanjut. Spesifikasi sistem adalah sekumpulan spesifikasi tugas yang dialokasikan untuk aktor internal. | ''Semantic memory'' ScenIC mencerminkan informasi tentang sistem. Karena ''semantic memory'' berubah selama penyempurnaan, "sistem" dapat mencakup "lingkungan" dan "mesin".<ref>Pamela Zave. [http://dx.doi.org/10.1145/237432.237434 Four dark corners of requirements engineering]. ''ACM Transactions on Software Engineering and Methodology''. 1997-01-01. Vol. 6 (1). hlm. 1–30. doi:10.1145/237432.237434.</ref> Entitas semantik dalam ScenIC meliputi aktor (''actor)'', tujuan ''(goal)'', dan hambatan ''(obstacle)''. Aktor adalah entitas yang berpartisipasi dalam perubahan keadaan . Aktor eksternal termasuk peran pengguna, organisasi, perangkat fisik, sistem eksternal, dan alam. Aktor internal adalah yang diduga sebagai komponen arsitektur, atau keseluruhan sistem yang dipandang sebagai kotak hitam ''(black box).'' Ada dua macam tujuan: objektif dan tugas. Objektif diekspresikan oleh lintasan perbaikan (mis. "Mengurangi keluhan pelanggan") atau pelestarian atau pencegahan keadaan (mis. "Lift tidak boleh bergerak saat pintunya terbuka").Tugas adalah tujuan yang dinyatakan dalam hal pencapaian suatu keadaan atau kinerja suatu tindakan (mis. "Begitu permintaan rapat dimasukkan ke dalam sistem, waktu dan tempat akan langsung dijadwalkan.) Objektif tidak dapat dicapai secara langsung oleh mesin, tetapi secara tidak langsung diwujudkan melalui kombinasi tugas. Misalnya, untuk mengurangi keluhan pelanggan, pengguna dan mesin melakukan tindakan terkoordinasi yang terperinci. Tugas, sebaliknya, dapat direalisasikan langsung oleh aktor, meskipun beberapa mungkin memerlukan ekspansi lebih lanjut. Spesifikasi sistem adalah sekumpulan spesifikasi tugas yang dialokasikan untuk aktor internal.<ref name=":1" /> | ||
Tujuan dapat digagalkan oleh hambatan, kebanyakan melekat pada tujuan itu sendiri (mis. Ketidakpuasan terhadap batasan yang ada), tetapi adapula yang muncul karena mode kegagalan para aktor yang dialokasikan tugas. Hambatan termasuk perilaku non-normatif secara umum, bukan hanya kegagalan. Aktor non-mekanis dapat berperilaku dengan cara yang tidak diantisipasi yang melanggar asumsi yang diperlukan untuk pencapaian tujuan. Hambatan yang sering atau berat harus diselesaikan dengan tugas defensif atau mitigasi. | Tujuan dapat digagalkan oleh hambatan, kebanyakan melekat pada tujuan itu sendiri (mis. Ketidakpuasan terhadap batasan yang ada), tetapi adapula yang muncul karena mode kegagalan para aktor yang dialokasikan tugas. Hambatan termasuk perilaku non-normatif secara umum, bukan hanya kegagalan. Aktor non-mekanis dapat berperilaku dengan cara yang tidak diantisipasi yang melanggar asumsi yang diperlukan untuk pencapaian tujuan. Hambatan yang sering atau berat harus diselesaikan dengan tugas defensif atau mitigasi.<ref name=":1" /> | ||
'''Skema ''Episodic Memory''''' | '''Skema ''Episodic Memory''''' | ||
Perwakilan pengguna dan pelanggan tidak selalu dapat menghasilkan dan membayangkan konsekuensi dari spesifikasi, sehingga sistem tertentu mungkin tampak lebih diinginkan daripada implementasinya. Argumen-argumen ini telah disuarakan untuk membenarkan [[Purwarupa|prototipe]], spesifikasi dan model yang dapat dieksekusi, [[maket]] dan ''[[Papan cerita|storyboard]]'', penelusuran data praktik kerja, dan skenario. ''Episodic memory'' ScenIC terdiri dari episode, urutan contoh tugas yang memiliki tujuan. ''Episodic memory'' ScenIC terdiri dari episode yang diarahkan pada tujuan dan yang menggambarkan hambatan yang digabung sebagai skenario pada berbagai tingkat detail. Skenario digunakan untuk mengeksplorasi kemungkinan seperti alokasi tugas alternatif untuk aktor, metode penyelesaian kendala alternatif, dan misi masa depan alternatif. Struktur narasi skenario adalah tata bahasa cerita yang disederhanakan. | Perwakilan pengguna dan pelanggan tidak selalu dapat menghasilkan dan membayangkan konsekuensi dari spesifikasi, sehingga sistem tertentu mungkin tampak lebih diinginkan daripada implementasinya. Argumen-argumen ini telah disuarakan untuk membenarkan [[Purwarupa|prototipe]],<ref>Vonk, R., ''Prototyping: The effective use of CASE technology.'' 1990, Prentice Hall.</ref> spesifikasi dan model yang dapat dieksekusi, [[maket]] dan ''[[Papan cerita|storyboard]]'',<ref>Muller, M., et al., Bifocal tools for scenarios and representations in participatory activities with users, in ''Scenario-Based Design: Envisioning Work and Technology in System Development,'' J.M. Carroll, (Ed.). 1995, Wiley.</ref><ref>Ehn, P., The Art and Science of Designing Computer Artifacts, in ''Scand. J. Inf. Sys.'' 1989 21-42.</ref> penelusuran data praktik kerja,<ref>Hugh R. Beyer. [http://dx.doi.org/10.1145/203356.203365 Apprenticing with the customer]. ''Communications of the ACM''. 1995-05-01. Vol. 38 (5). hlm. 45–52. doi:10.1145/203356.203365.</ref><ref>Francoise Brun-Cottan. [http://dx.doi.org/10.1145/203356.203368 Using video to re-present the user]. ''Communications of the ACM''. 1995-05-01. Vol. 38 (5). hlm. 61–71. doi:10.1145/203356.203368.</ref><ref>Karen Holtzblatt. [http://dx.doi.org/10.1145/163430.164050 Making customer-centered design work for teams]. ''Communications of the ACM''. 1993-10-01. Vol. 36 (10). hlm. 92–103. doi:10.1145/163430.164050.</ref> dan skenario.<ref name=":0" /><ref>J.S. Anderson. [http://dx.doi.org/10.1109/isre.1993.324824 Using scenarios in deficiency-driven requirements engineering]. ''[1993] Proceedings of the IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/isre.1993.324824. ISBN 0818631201.</ref><ref>John M. Carroll. [http://dx.doi.org/10.1145/146802.146834 Getting around the task-artifact cycle: how to make claims and design by scenario]. ''ACM Transactions on Information Systems''. 1992-04-01. Vol. 10 (2). hlm. 181–212. doi:10.1145/146802.146834.</ref><ref>Rubin, Kenneth H. [http://worldcat.org/oclc/926690727 Object behavior analysis]. Association for Computing Machinery. 1992.</ref><ref>Alistair Sutcliffe. [http://dx.doi.org/10.1007/bf02802920 Scenario-based requirements analysis]. ''Requirements Engineering''. 1998-03. Vol. 3 (1). hlm. 48–65. doi:10.1007/bf02802920.</ref><ref>Jacobson, I. [http://worldcat.org/oclc/693444408 Object-oriented software engineering a use case driven approach]. ACM Press: Addison Wesley. 1998. ISBN 0201544350.</ref> ''Episodic memory'' ScenIC terdiri dari episode, urutan contoh tugas yang memiliki tujuan. ''Episodic memory'' ScenIC terdiri dari episode yang diarahkan pada tujuan dan yang menggambarkan hambatan yang digabung sebagai skenario pada berbagai tingkat detail. Skenario digunakan untuk mengeksplorasi kemungkinan seperti alokasi tugas alternatif untuk aktor, metode penyelesaian kendala alternatif, dan misi masa depan alternatif. Struktur narasi skenario adalah tata bahasa cerita yang disederhanakan.<ref>Cline, Patsy, 1932-1963. [http://worldcat.org/oclc/19869279 Remembering]. 1988, 1982.</ref><ref>Rumelhart, D., Notes on a Schema for Stories, in ''Representation and Understanding,'' D. Bobrow & A.Collins, (Eds.) 1975, Academic Press.</ref><ref>Perry W. Thorndyke. [http://dx.doi.org/10.1016/0010-0285(77)90005-6 Cognitive structures in comprehension and memory of narrative discourse]. ''Cognitive Psychology''. 1977-01. Vol. 9 (1). hlm. 77–110. doi:10.1016/0010-0285(77)90005-6.</ref><ref name=":2">Jeff Conklin. [http://dx.doi.org/10.1002/(sici)1097-4571(198905)40:3 3.0.co;2-u gIBIS: A tool for all reasons]. ''Journal of the American Society for Information Science''. 1989-05. Vol. 40 (3). hlm. 200–213. doi:10.1002/(sici)1097-4571(198905)40:3 3.0.co;2-u.</ref> | ||
'''Skema ''Working Memory''''' | '''Skema ''Working Memory''''' | ||
''Working memory'' berorientasi pada tindakan. Isinya mengingatkan dan mengarahkan ''Inquiry''. Proyek ''Working memory'' di ScenIC adalah catatan masalah yang tertunda atau keputusan perbaikan yang belum ditindaklanjuti. Skema ''working memory'' yang berfungsi dapat diperluas ke IBIS atau skema yang lebih kompleks, dan ''working memory'' dapat ditangkap atau diarsipkan sebagai ''rationale''. Pedoman metodologis disediakan dengan mengajukan masalah standar tentang informasi jangka panjang. Pedoman ScenIC dikodekan sebagai templat pengingat dengan konteks pemicu. | ''Working memory'' berorientasi pada tindakan. Isinya mengingatkan dan mengarahkan ''Inquiry''. Proyek ''Working memory'' di ScenIC adalah catatan masalah yang tertunda atau keputusan perbaikan yang belum ditindaklanjuti. Skema ''working memory'' yang berfungsi dapat diperluas ke IBIS atau skema yang lebih kompleks,<ref>C. Potts. [http://dx.doi.org/10.1109/icse.1988.93722 Recording the reasons for design decisions]. ''Proceedings. [1989] 11th International Conference on Software Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icse.1988.93722. ISBN 0897912586.</ref><ref>C. Potts. [http://dx.doi.org/10.1109/icse.1989.714422 A Generic Model For Representing Design Methods]. ''11th International Conference on Software Engineering''. IEEE. doi:10.1109/icse.1989.714422. ISBN 0818689412.</ref> dan ''working memory'' dapat ditangkap atau diarsipkan sebagai ''rationale''.<ref name=":2" /><ref>Kunz, W. & H. Rittel, ''Issues as Elements of Information Systems,'' 1970, Inst. Urban and Regional Development, Univ.Calif.: Berkeley, California.</ref><ref>J. Lee. [http://dx.doi.org/10.1109/icse.1991.130629 Extending the Potts and Bruns model for recording design rationale]. ''[1991 Proceedings] 13th International Conference on Software Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icse.1991.130629. ISBN 0818621400.</ref><ref>K. C. Burgess Yakemovic. [http://dx.doi.org/10.1145/99332.99347 Report on a development project use of an issue-based information system]. ''Proceedings of the 1990 ACM conference on Computer-supported cooperative work - CSCW '90''. ACM Press. 1990. doi:10.1145/99332.99347. ISBN 0897914023.</ref> Pedoman metodologis disediakan dengan mengajukan masalah standar tentang informasi jangka panjang. Pedoman ScenIC dikodekan sebagai templat pengingat dengan konteks pemicu.<ref name=":1" /> | ||
== Strategi dan Panduan ScenIC == | == Strategi dan Panduan ScenIC == | ||
ScenIC membuat fase ekspresi ''Inquiry Cycle'' dengan menyediakan skema ''episodic memory'' dan ''semantic memory'' untuk informasi tentang sistem yang diusulkan. Kritik didukung oleh masalah standar yang dipicu oleh keadaan ingatan jangka panjang. Penyempurnaan didukung oleh pedoman resolusi. Kerangka kerja tersebut diuraikan dalam Tabel 1. | ScenIC membuat fase ekspresi ''Inquiry Cycle'' dengan menyediakan skema ''episodic memory'' dan ''semantic memory'' untuk informasi tentang sistem yang diusulkan. Kritik didukung oleh masalah standar yang dipicu oleh keadaan ingatan jangka panjang. Penyempurnaan didukung oleh pedoman resolusi. Kerangka kerja tersebut diuraikan dalam Tabel 1.<ref name=":1" /> | ||
{| class="wikitable" | |||
|+Tabel 1: Strategi dan Panduan ScenIC<ref name=":1" /> | |||
!Kondisi Pemicu | |||
!Masalah | |||
!Pedoman Resolusi | |||
!Perubahan Hasil | |||
|- | |||
|Kondisi ''semantic memory'' atau ''episodic memory'' | |||
|Masalah yang diangkat mengenai kebutuhan sistem | |||
|Saran ScenIC | |||
|Kondisi ''semantic memory'' atau ''episodic memory'' | |||
|- | |||
|Contohnya, aktor menjalankan tugas pada sebuah episode | |||
|Contohnya, bisakah aktor gagal? | |||
|Contohnya, analisis risiko kegagalan | |||
|Contohnya, hambatan baru dan skenario yang mengilustrasikannya | |||
|} | |||
Aktor eksternal ada di luar kendali [[Perancang|desainer]]. Aktor eksternal dimasukkan jika melakukan tindakan signifikan dalam ruang lingkup sistem. ''Goal'' dapat diidentifikasi dengan merefleksikan tujuan sistem, mewawancarai [[pemangku kepentingan]], atau menyimpulkan tujuan dari [[dokumentasi]] latar belakang. ''Goal'' juga dapat diidentifikasi dari konten memori jangka panjang. Skenario, misalnya, dapat menerangi tujuan yang sebelumnya diabaikan atau kurang ditekankan. Hambatan mungkin akan menyarankan tugas tambahan. ''Goal'' kemudian diperluas dengan [[:en:Means-ends analysis|analisis ''means-end'']]<ref name=":1" />''.'' | |||
Terdapat pedoman umum untuk memperluas objektif dan tugas pemeliharaan, tetapi objektif peningkatan cenderung spesifik ke domain tertentu. Tugas sering kali harus dilakukan secara berurutan, karena tergantung pada kondisi awal. Pengaturan waktu ini tersirat dalam ketergantungan antar tugas. Tugas pada tingkatan yang lebih tinggi secara bertahap mengonsumsi [[informasi]] atau bergantung pada penyelesaian sebagian tugas dependen. Untuk alasan ini, yang terbaik adalah menunda analisis dependensi tugas sampai tugas dirinci dan dapat dialokasikan untuk aktor. Terkadang tugas tergantung pada ketersediaan informasi tanpa menjelaskan bagaimana informasi tersebut diperoleh. Tugas mana yang harus dilakukan oleh sistem dan yang harus dilakukan oleh aktor eksternal jarang ditentukan sebelumnya. Misalnya, suatu sistem dapat memutuskan waktu dan tempat terbaik untuk rapat secara otomatis. Atau, sistem bisa menyusun informasi dan menyajikannya kepada pengguna untuk meminta keputusan akhir. Kedua sistem tersebut mendukung tujuan penjadwalan pertemuan tetapi memiliki batasan yang berbeda. Alokasi tugas dibantu oleh analisis skenario. Alokasi alternatif dapat didiskusikan dalam skenario alternatif, dan masalah yang diangkat digunakan dalam mengevaluasinya. Kemungkinan alokasi ditentukan sebagian oleh arsitektur saat ini dan sebagian oleh praktik saat ini.<ref name=":1" /> | |||
Hambatan dapat diidentifikasi dengan sejumlah proses yang berkisar dari praktik rekayasa yang paling informal hingga sistematis. Secara umum, hambatan diidentifikasi dengan pendekatan ''top-down'' atau ''bottom-up''.<ref name=":1" /> | |||
Hambatan | * Identifikasi ''top-down'' dari kombinasi hambatan yang menghalangi objektif. Hambatan tunggal jarang memiliki tanggung jawab atas tujuan yang tidak tercapai. Strategi ''top-down'' minimal adalah ''generate-and-test'': bertanya secara sistematis apakah setiap keputusan alokasi merusak tujuan. Cara lain adalah membangun anti-skenario dari insiden kritikal.<ref name=":1" /> | ||
* Identifikasi ''bottom-up'' dari hambatan yang menghalangi tugas. Beberapa kendala melekat dalam domain masalah. Misalnya, tempat terbaik untuk rapat tidak dapat dipilih jika tidak ada ruang yang tersedia. Di sisi lain, banyak muncul dari kegagalan aktor.<ref name=":1" /> | |||
Ada tiga cara untuk mengatasi hambatan, antara lain abaikan saja, mempertahankannya, idealnya mencegahnya sama sekali, dan mengurangi dampaknya, idealnya pulih sama sekali. Dalam banyak kasus, pertahanan lebih efektif dan lebih murah daripada mitigasi, tetapi ketika konsekuensi hambatannya ringan dan biaya pertahanan tinggi, lebih masuk akal untuk mengandalkan mitigasi. Mitigasi hanya layak dipertimbangkan ketika pertahanan cenderung gagal dan risiko hambatan residual masih perlu dikhawatirkan.<ref name=":1" /> | |||
Ada tiga cara untuk mengatasi hambatan, antara lain abaikan saja, mempertahankannya, idealnya mencegahnya sama sekali, dan mengurangi dampaknya, idealnya pulih sama sekali. Dalam banyak kasus, pertahanan lebih efektif dan lebih murah daripada mitigasi, tetapi ketika konsekuensi hambatannya ringan dan biaya pertahanan tinggi, lebih masuk akal untuk mengandalkan mitigasi. Mitigasi hanya layak dipertimbangkan ketika pertahanan cenderung gagal dan risiko hambatan residual masih perlu dikhawatirkan. | |||
== ''Inquiry Cycle'' dan Skenario == | == ''Inquiry Cycle'' dan Skenario == | ||
Inti dari mengeksplorasi skenario adalah untuk mengangkat dan menyelesaikan masalah tentang kebutuhan. Salah satu manfaat dari analisis skenario adalah wawasan yang tidak sengaja ditemukan yang dihasilkan dari skenario. Ketika masalah yang diangkat dari skenario diselesaikan, perubahan yang dihasilkan dapat terjadi di mana saja dalam ''episodic memory'' atau ''semantic memory.'' Episode mengikuti struktur tugas. Skenario disusun dari episode sehingga kasus-kasus normal dan anti-skenario diuraikan. | Inti dari mengeksplorasi skenario adalah untuk mengangkat dan menyelesaikan masalah tentang kebutuhan. Salah satu manfaat dari analisis skenario adalah wawasan yang tidak sengaja ditemukan yang dihasilkan dari skenario. Ketika masalah yang diangkat dari skenario diselesaikan, perubahan yang dihasilkan dapat terjadi di mana saja dalam ''episodic memory'' atau ''semantic memory.'' Episode mengikuti struktur tugas. Skenario disusun dari episode sehingga kasus-kasus normal dan anti-skenario diuraikan.<ref name=":1" /> | ||
Setelah mengidentifikasi hambatan, dimungkinkan untuk menyusun sejumlah skenario yang berisi episode normatif (kepuasan tujuan) dan eksepsi (kemunculan hambatan), yang sebagian besar adalah redundan atau tidak menarik. Karena itu, komposisi skenario merupakan bentuk pengambilan sampel, seperti pembuatan kasus uji. Namun, skenario berbeda dari kasus uji dalam dua hal penting. Pertama, skenario digunakan untuk menemukan dan menguraikan kebutuhan, sehingga setiap ukuran arti penting atau cakupan skenario adalah target yang bergerak. Kedua, kita dapat menilai kecukupan kasus uji terhadap paduk yang objektif, sedangkan paduk kebutuhan apa pun bersifat subjektif. Solusi ScenIC bersifat [[Pragmatisme|pragmatis]], yang artinya kumpulan tujuan dan hambatan diambil sebagai dasar untuk menilai cakupan skenario. | Setelah mengidentifikasi hambatan, dimungkinkan untuk menyusun sejumlah skenario yang berisi episode normatif (kepuasan tujuan) dan eksepsi (kemunculan hambatan), yang sebagian besar adalah redundan atau tidak menarik. Karena itu, komposisi skenario merupakan bentuk pengambilan sampel, seperti pembuatan kasus uji. Namun, skenario berbeda dari kasus uji dalam dua hal penting. Pertama, skenario digunakan untuk menemukan dan menguraikan kebutuhan, sehingga setiap ukuran arti penting atau cakupan skenario adalah target yang bergerak. Kedua, kita dapat menilai kecukupan kasus uji terhadap paduk yang objektif, sedangkan paduk kebutuhan apa pun bersifat subjektif. Solusi ScenIC bersifat [[Pragmatisme|pragmatis]], yang artinya kumpulan tujuan dan hambatan diambil sebagai dasar untuk menilai cakupan skenario.<ref name=":1" /> | ||
* Cakupan kasus normal. Harus ada setidaknya satu skenario untuk setiap kasus normal. Biasanya ada kasus normal alternatif, beberapa di antaranya mencakup tujuan inisiasi atau pemeliharaan sistem. | * Cakupan kasus normal. Harus ada setidaknya satu skenario untuk setiap kasus normal. Biasanya ada kasus normal alternatif, beberapa di antaranya mencakup tujuan inisiasi atau pemeliharaan sistem.<ref name=":1" /> | ||
* Cakupan hambatan tunggal. Setiap rintangan harus terjadi dalam setidaknya satu skenario. | * Cakupan hambatan tunggal. Setiap rintangan harus terjadi dalam setidaknya satu skenario.<ref name=":1" /> | ||
* Cakupan objektif. Idealnya, setiap skenario harus dinilai terhadap setiap tujuan. Untuk efisiensi yang lebih besar, disarankan untuk membagi tujuan menjadi dua: tujuan yang mutlak harus dicapai, dan tujuan yang kuat tetapi bisa dilanggar. Tujuan dari tipe pertama harus diperiksa ketika mengelaborasi setiap skenario, sedangkan yang dari tipe kedua dapat disampel secara acak. | * Cakupan objektif. Idealnya, setiap skenario harus dinilai terhadap setiap tujuan. Untuk efisiensi yang lebih besar, disarankan untuk membagi tujuan menjadi dua: tujuan yang mutlak harus dicapai, dan tujuan yang kuat tetapi bisa dilanggar. Tujuan dari tipe pertama harus diperiksa ketika mengelaborasi setiap skenario, sedangkan yang dari tipe kedua dapat disampel secara acak.<ref name=":1" /> | ||
== Referensi == | == Referensi == | ||
<references /> | |||
== Sumber dan atribusi == | == Sumber dan atribusi == | ||
Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=ScenIC&oldid=28471124 Wikipedia bahasa Indonesia], revisi 28471124 (2025-11-14T02:34:03Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku. | |||
[https://id.wikipedia.org/w/index.php?title=ScenIC&oldid=28471124 Wikipedia bahasa Indonesia], | |||
revisi 28471124 (2025-11-14T02:34:03Z) | <!-- WIKI_UNISSULA_PRESENTATION_V4 --> | ||
Atribusi-BerbagiSerupa (CC BY-SA) | |||
Revisi terkini sejak 23 Agustus 2026 03.05
ScenIC adalah metode rekayasa kebutuhan perangkat lunak untuk sistem yang berkembang. Berasal dari model Inquiry Cycle pada penyempurnaan kebutuhan, metode ini menggunakan penyempurnaan goal dan analisis skenario sebagai strategi metodologis utamanya. ScenIC bersandar pada analogi memori manusia: semantic memory terdiri dari generalisasi tentang sifat-sifat sistem; episodic memory terdiri atas episode dan skenario tertentu; dan working memory terdiri dari pengingat tentang penyempurnaan yang tidak lengkap. Metode khusus dari pedoman pengingat dan resolusi diaktifkan oleh keadaan dari episodic memory atau semantic memory. ScenIC merupakan representatif dari Inquiry Cycle,[1][2] yang merupakan aplikasi siklus dari langkah-langkah berikut: ekspresi ide semantik atau episodik, mengangkat dan menyelesaikan masalah (kritik), dan penyempurnaan memori jangka panjang. Ekspresi didukung dengan mengadopsi skema semantic memory dan episodic memory, kemudian kritik oleh pedoman pengungkapan masalah yang dapat mengarahkan perhatian, sedangkan penyempurnaan didukung oleh pedoman resolusi yang menyarankan penyempurnaan.[3]
Skema Memori ScenIC
Masing-masing dari tiga memori ScenIC memiliki skema entity-relationship. Spesifikasi detail elemen skema dibiarkan tidak terdefinisi sehingga ScenIC dapat diterapkan pada berbagai tingkat formalitas.[3]
Skema Semantic Memory
Semantic memory ScenIC mencerminkan informasi tentang sistem. Karena semantic memory berubah selama penyempurnaan, "sistem" dapat mencakup "lingkungan" dan "mesin".[4] Entitas semantik dalam ScenIC meliputi aktor (actor), tujuan (goal), dan hambatan (obstacle). Aktor adalah entitas yang berpartisipasi dalam perubahan keadaan . Aktor eksternal termasuk peran pengguna, organisasi, perangkat fisik, sistem eksternal, dan alam. Aktor internal adalah yang diduga sebagai komponen arsitektur, atau keseluruhan sistem yang dipandang sebagai kotak hitam (black box). Ada dua macam tujuan: objektif dan tugas. Objektif diekspresikan oleh lintasan perbaikan (mis. "Mengurangi keluhan pelanggan") atau pelestarian atau pencegahan keadaan (mis. "Lift tidak boleh bergerak saat pintunya terbuka").Tugas adalah tujuan yang dinyatakan dalam hal pencapaian suatu keadaan atau kinerja suatu tindakan (mis. "Begitu permintaan rapat dimasukkan ke dalam sistem, waktu dan tempat akan langsung dijadwalkan.) Objektif tidak dapat dicapai secara langsung oleh mesin, tetapi secara tidak langsung diwujudkan melalui kombinasi tugas. Misalnya, untuk mengurangi keluhan pelanggan, pengguna dan mesin melakukan tindakan terkoordinasi yang terperinci. Tugas, sebaliknya, dapat direalisasikan langsung oleh aktor, meskipun beberapa mungkin memerlukan ekspansi lebih lanjut. Spesifikasi sistem adalah sekumpulan spesifikasi tugas yang dialokasikan untuk aktor internal.[3]
Tujuan dapat digagalkan oleh hambatan, kebanyakan melekat pada tujuan itu sendiri (mis. Ketidakpuasan terhadap batasan yang ada), tetapi adapula yang muncul karena mode kegagalan para aktor yang dialokasikan tugas. Hambatan termasuk perilaku non-normatif secara umum, bukan hanya kegagalan. Aktor non-mekanis dapat berperilaku dengan cara yang tidak diantisipasi yang melanggar asumsi yang diperlukan untuk pencapaian tujuan. Hambatan yang sering atau berat harus diselesaikan dengan tugas defensif atau mitigasi.[3]
Skema Episodic Memory
Perwakilan pengguna dan pelanggan tidak selalu dapat menghasilkan dan membayangkan konsekuensi dari spesifikasi, sehingga sistem tertentu mungkin tampak lebih diinginkan daripada implementasinya. Argumen-argumen ini telah disuarakan untuk membenarkan prototipe,[5] spesifikasi dan model yang dapat dieksekusi, maket dan storyboard,[6][7] penelusuran data praktik kerja,[8][9][10] dan skenario.[1][11][12][13][14][15] Episodic memory ScenIC terdiri dari episode, urutan contoh tugas yang memiliki tujuan. Episodic memory ScenIC terdiri dari episode yang diarahkan pada tujuan dan yang menggambarkan hambatan yang digabung sebagai skenario pada berbagai tingkat detail. Skenario digunakan untuk mengeksplorasi kemungkinan seperti alokasi tugas alternatif untuk aktor, metode penyelesaian kendala alternatif, dan misi masa depan alternatif. Struktur narasi skenario adalah tata bahasa cerita yang disederhanakan.[16][17][18][19]
Skema Working Memory
Working memory berorientasi pada tindakan. Isinya mengingatkan dan mengarahkan Inquiry. Proyek Working memory di ScenIC adalah catatan masalah yang tertunda atau keputusan perbaikan yang belum ditindaklanjuti. Skema working memory yang berfungsi dapat diperluas ke IBIS atau skema yang lebih kompleks,[20][21] dan working memory dapat ditangkap atau diarsipkan sebagai rationale.[19][22][23][24] Pedoman metodologis disediakan dengan mengajukan masalah standar tentang informasi jangka panjang. Pedoman ScenIC dikodekan sebagai templat pengingat dengan konteks pemicu.[3]
Strategi dan Panduan ScenIC
ScenIC membuat fase ekspresi Inquiry Cycle dengan menyediakan skema episodic memory dan semantic memory untuk informasi tentang sistem yang diusulkan. Kritik didukung oleh masalah standar yang dipicu oleh keadaan ingatan jangka panjang. Penyempurnaan didukung oleh pedoman resolusi. Kerangka kerja tersebut diuraikan dalam Tabel 1.[3]
| Kondisi Pemicu | Masalah | Pedoman Resolusi | Perubahan Hasil |
|---|---|---|---|
| Kondisi semantic memory atau episodic memory | Masalah yang diangkat mengenai kebutuhan sistem | Saran ScenIC | Kondisi semantic memory atau episodic memory |
| Contohnya, aktor menjalankan tugas pada sebuah episode | Contohnya, bisakah aktor gagal? | Contohnya, analisis risiko kegagalan | Contohnya, hambatan baru dan skenario yang mengilustrasikannya |
Aktor eksternal ada di luar kendali desainer. Aktor eksternal dimasukkan jika melakukan tindakan signifikan dalam ruang lingkup sistem. Goal dapat diidentifikasi dengan merefleksikan tujuan sistem, mewawancarai pemangku kepentingan, atau menyimpulkan tujuan dari dokumentasi latar belakang. Goal juga dapat diidentifikasi dari konten memori jangka panjang. Skenario, misalnya, dapat menerangi tujuan yang sebelumnya diabaikan atau kurang ditekankan. Hambatan mungkin akan menyarankan tugas tambahan. Goal kemudian diperluas dengan analisis means-end[3].
Terdapat pedoman umum untuk memperluas objektif dan tugas pemeliharaan, tetapi objektif peningkatan cenderung spesifik ke domain tertentu. Tugas sering kali harus dilakukan secara berurutan, karena tergantung pada kondisi awal. Pengaturan waktu ini tersirat dalam ketergantungan antar tugas. Tugas pada tingkatan yang lebih tinggi secara bertahap mengonsumsi informasi atau bergantung pada penyelesaian sebagian tugas dependen. Untuk alasan ini, yang terbaik adalah menunda analisis dependensi tugas sampai tugas dirinci dan dapat dialokasikan untuk aktor. Terkadang tugas tergantung pada ketersediaan informasi tanpa menjelaskan bagaimana informasi tersebut diperoleh. Tugas mana yang harus dilakukan oleh sistem dan yang harus dilakukan oleh aktor eksternal jarang ditentukan sebelumnya. Misalnya, suatu sistem dapat memutuskan waktu dan tempat terbaik untuk rapat secara otomatis. Atau, sistem bisa menyusun informasi dan menyajikannya kepada pengguna untuk meminta keputusan akhir. Kedua sistem tersebut mendukung tujuan penjadwalan pertemuan tetapi memiliki batasan yang berbeda. Alokasi tugas dibantu oleh analisis skenario. Alokasi alternatif dapat didiskusikan dalam skenario alternatif, dan masalah yang diangkat digunakan dalam mengevaluasinya. Kemungkinan alokasi ditentukan sebagian oleh arsitektur saat ini dan sebagian oleh praktik saat ini.[3]
Hambatan dapat diidentifikasi dengan sejumlah proses yang berkisar dari praktik rekayasa yang paling informal hingga sistematis. Secara umum, hambatan diidentifikasi dengan pendekatan top-down atau bottom-up.[3]
- Identifikasi top-down dari kombinasi hambatan yang menghalangi objektif. Hambatan tunggal jarang memiliki tanggung jawab atas tujuan yang tidak tercapai. Strategi top-down minimal adalah generate-and-test: bertanya secara sistematis apakah setiap keputusan alokasi merusak tujuan. Cara lain adalah membangun anti-skenario dari insiden kritikal.[3]
- Identifikasi bottom-up dari hambatan yang menghalangi tugas. Beberapa kendala melekat dalam domain masalah. Misalnya, tempat terbaik untuk rapat tidak dapat dipilih jika tidak ada ruang yang tersedia. Di sisi lain, banyak muncul dari kegagalan aktor.[3]
Ada tiga cara untuk mengatasi hambatan, antara lain abaikan saja, mempertahankannya, idealnya mencegahnya sama sekali, dan mengurangi dampaknya, idealnya pulih sama sekali. Dalam banyak kasus, pertahanan lebih efektif dan lebih murah daripada mitigasi, tetapi ketika konsekuensi hambatannya ringan dan biaya pertahanan tinggi, lebih masuk akal untuk mengandalkan mitigasi. Mitigasi hanya layak dipertimbangkan ketika pertahanan cenderung gagal dan risiko hambatan residual masih perlu dikhawatirkan.[3]
Inquiry Cycle dan Skenario
Inti dari mengeksplorasi skenario adalah untuk mengangkat dan menyelesaikan masalah tentang kebutuhan. Salah satu manfaat dari analisis skenario adalah wawasan yang tidak sengaja ditemukan yang dihasilkan dari skenario. Ketika masalah yang diangkat dari skenario diselesaikan, perubahan yang dihasilkan dapat terjadi di mana saja dalam episodic memory atau semantic memory. Episode mengikuti struktur tugas. Skenario disusun dari episode sehingga kasus-kasus normal dan anti-skenario diuraikan.[3]
Setelah mengidentifikasi hambatan, dimungkinkan untuk menyusun sejumlah skenario yang berisi episode normatif (kepuasan tujuan) dan eksepsi (kemunculan hambatan), yang sebagian besar adalah redundan atau tidak menarik. Karena itu, komposisi skenario merupakan bentuk pengambilan sampel, seperti pembuatan kasus uji. Namun, skenario berbeda dari kasus uji dalam dua hal penting. Pertama, skenario digunakan untuk menemukan dan menguraikan kebutuhan, sehingga setiap ukuran arti penting atau cakupan skenario adalah target yang bergerak. Kedua, kita dapat menilai kecukupan kasus uji terhadap paduk yang objektif, sedangkan paduk kebutuhan apa pun bersifat subjektif. Solusi ScenIC bersifat pragmatis, yang artinya kumpulan tujuan dan hambatan diambil sebagai dasar untuk menilai cakupan skenario.[3]
- Cakupan kasus normal. Harus ada setidaknya satu skenario untuk setiap kasus normal. Biasanya ada kasus normal alternatif, beberapa di antaranya mencakup tujuan inisiasi atau pemeliharaan sistem.[3]
- Cakupan hambatan tunggal. Setiap rintangan harus terjadi dalam setidaknya satu skenario.[3]
- Cakupan objektif. Idealnya, setiap skenario harus dinilai terhadap setiap tujuan. Untuk efisiensi yang lebih besar, disarankan untuk membagi tujuan menjadi dua: tujuan yang mutlak harus dicapai, dan tujuan yang kuat tetapi bisa dilanggar. Tujuan dari tipe pertama harus diperiksa ketika mengelaborasi setiap skenario, sedangkan yang dari tipe kedua dapat disampel secara acak.[3]
Referensi
- ↑ 1,0 1,1 C. Potts. Inquiry-based requirements analysis. IEEE Software. 1994-03. Vol. 11 (2). hlm. 21–32. doi:10.1109/52.268952.
- ↑ C. Potts. An evaluation of inquiry-based requirements analysis for an Internet service. Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95). IEEE Comput. Soc. Press. doi:10.1109/isre.1995.512559. ISBN 0818670177.
- ↑ 3,00 3,01 3,02 3,03 3,04 3,05 3,06 3,07 3,08 3,09 3,10 3,11 3,12 3,13 3,14 3,15 3,16 3,17 C. Potts. ScenIC: a strategy for inquiry-driven requirements determination. Proceedings IEEE International Symposium on Requirements Engineering (Cat. No.PR00188). IEEE Comput. Soc. doi:10.1109/isre.1999.777985. ISBN 0769501885.
- ↑ Pamela Zave. Four dark corners of requirements engineering. ACM Transactions on Software Engineering and Methodology. 1997-01-01. Vol. 6 (1). hlm. 1–30. doi:10.1145/237432.237434.
- ↑ Vonk, R., Prototyping: The effective use of CASE technology. 1990, Prentice Hall.
- ↑ Muller, M., et al., Bifocal tools for scenarios and representations in participatory activities with users, in Scenario-Based Design: Envisioning Work and Technology in System Development, J.M. Carroll, (Ed.). 1995, Wiley.
- ↑ Ehn, P., The Art and Science of Designing Computer Artifacts, in Scand. J. Inf. Sys. 1989 21-42.
- ↑ Hugh R. Beyer. Apprenticing with the customer. Communications of the ACM. 1995-05-01. Vol. 38 (5). hlm. 45–52. doi:10.1145/203356.203365.
- ↑ Francoise Brun-Cottan. Using video to re-present the user. Communications of the ACM. 1995-05-01. Vol. 38 (5). hlm. 61–71. doi:10.1145/203356.203368.
- ↑ Karen Holtzblatt. Making customer-centered design work for teams. Communications of the ACM. 1993-10-01. Vol. 36 (10). hlm. 92–103. doi:10.1145/163430.164050.
- ↑ J.S. Anderson. Using scenarios in deficiency-driven requirements engineering. [1993] Proceedings of the IEEE International Symposium on Requirements Engineering. IEEE Comput. Soc. Press. doi:10.1109/isre.1993.324824. ISBN 0818631201.
- ↑ John M. Carroll. Getting around the task-artifact cycle: how to make claims and design by scenario. ACM Transactions on Information Systems. 1992-04-01. Vol. 10 (2). hlm. 181–212. doi:10.1145/146802.146834.
- ↑ Rubin, Kenneth H. Object behavior analysis. Association for Computing Machinery. 1992.
- ↑ Alistair Sutcliffe. Scenario-based requirements analysis. Requirements Engineering. 1998-03. Vol. 3 (1). hlm. 48–65. doi:10.1007/bf02802920.
- ↑ Jacobson, I. Object-oriented software engineering a use case driven approach. ACM Press: Addison Wesley. 1998. ISBN 0201544350.
- ↑ Cline, Patsy, 1932-1963. Remembering. 1988, 1982.
- ↑ Rumelhart, D., Notes on a Schema for Stories, in Representation and Understanding, D. Bobrow & A.Collins, (Eds.) 1975, Academic Press.
- ↑ Perry W. Thorndyke. Cognitive structures in comprehension and memory of narrative discourse. Cognitive Psychology. 1977-01. Vol. 9 (1). hlm. 77–110. doi:10.1016/0010-0285(77)90005-6.
- ↑ 19,0 19,1 Jeff Conklin. 3.0.co;2-u gIBIS: A tool for all reasons. Journal of the American Society for Information Science. 1989-05. Vol. 40 (3). hlm. 200–213. doi:10.1002/(sici)1097-4571(198905)40:3 3.0.co;2-u.
- ↑ C. Potts. Recording the reasons for design decisions. Proceedings. [1989] 11th International Conference on Software Engineering. IEEE Comput. Soc. Press. doi:10.1109/icse.1988.93722. ISBN 0897912586.
- ↑ C. Potts. A Generic Model For Representing Design Methods. 11th International Conference on Software Engineering. IEEE. doi:10.1109/icse.1989.714422. ISBN 0818689412.
- ↑ Kunz, W. & H. Rittel, Issues as Elements of Information Systems, 1970, Inst. Urban and Regional Development, Univ.Calif.: Berkeley, California.
- ↑ J. Lee. Extending the Potts and Bruns model for recording design rationale. [1991 Proceedings] 13th International Conference on Software Engineering. IEEE Comput. Soc. Press. doi:10.1109/icse.1991.130629. ISBN 0818621400.
- ↑ K. C. Burgess Yakemovic. Report on a development project use of an issue-based information system. Proceedings of the 1990 ACM conference on Computer-supported cooperative work - CSCW '90. ACM Press. 1990. doi:10.1145/99332.99347. ISBN 0897914023.
Sumber dan atribusi
Konten artikel ini diadaptasi dari Wikipedia bahasa Indonesia, revisi 28471124 (2025-11-14T02:34:03Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.