Tugas Rekayasa Perangkat Lunak

Tweet

Tugas Rekayasa Perangkat Lunak T.5.1 Types of Models ·         Information Modeling Information Modeling dalam rekayasa perangkat lunak merupakan representasi dari konsep dan hubungan, kendala, aturan, dan operasi untuk menentukan semantik data yang dipilih untuk domain wacana. Biasanya hal ini menentukan hubungan antara macam hal, tetapi juga dapat mencakup hubungan dengan hal-hal pribadi. Hal ini dapat menyediakan struktur sharable, stabil, dan persyaratan struktur informasi yang terorganisir atau pengetahuan untuk konteks domain. Contoh dari Information Modeling adalah : -     Entity - Relationship Modeling     Dalam rekayasa perangkat lunak , sebuah Entity - Relationship Modeling adalah cara abstrak untuk menggambarkan basis data . Hal ini biasanya dimulai dengan relasi sebuah database, yang menyimpan data dalam tabel. Beberapa data dalam tabel ini menunjukkan data dalam tabel lain - misalnya, entri anda dalam database bisa menunjukkan beberapa entri untuk setiap nomor telepon anda. Entity - Relationship Modeling akan mengatakan bahwa anda adalah suatu entitas, dan masing-masing nomor telepon adalah suatu entitas, dan hubungan antara Anda dan nomor telepon 'memiliki nomor telepon'. Diagram dibuat untuk merancang entitas dan hubungan yang disebut Entity - Relationship Diagram atauentitas-hubungan diagram. -     Class Diagram Class Diagram dalam Unified Modeling Language (UML) adalah jenis diagram struktur statis yang menggambarkan struktur dari suatu sistem dengan menunjukkan sistem kelas , atribut mereka, operasi (atau metode), dan hubungan antar kelas. Class Diagram juga disebut blok bangunan utama dari pemodelan berorientasi objek. Hal ini digunakan baik untuk pemodelan konseptual umum dari sistematika aplikasi, dan untuk pemodelan rinci dalam menerjemahkan model ke dalam kode pemrograman. Class Diagram juga dapat digunakan untuk pemodelan data. Kelas-kelas dalam Class Diagram mewakili kedua objek utama, yaitu interaksi dalam aplikasi dan kelas yang akan diprogram.             Pada diagram, kelas diwakili dengan kotak yang berisi tiga bagian: ·       Bagian atas memegang nama kelas ·       Bagian tengah berisi atribut dari kelas ·       Bagian bawah memberikan metode atau operasi kelas dapat mengambil atau melakukan    Dalam desain sistem, sejumlah kelas diidentifikasi dan dikelompokkan bersama dalam sebuah diagram kelas yang membantu untuk menentukan hubungan statis antara benda-benda. Dengan pemodelan rinci, kelas dari desain konseptual sering dibagi menjadi beberapa subclass. ·         Behavioral Modeling Ada beberapa ambiguitas dengan Behavioral Modeling. Dalam UML, behavioral modeling mempunyai arti yang sangat luas, hal itu mencakup semua aspek analisis kecuali aspek statis. Namun, sebagai model obyek entitas, perilaku mereka dapat juga diperlakukan dalam arti yang sempit sebagai serangkaian reaksi objek untuk rangsangan eksternal. Reaksi-reaksi ini biasanya berupa tindakan yang diambil oleh suatu benda karena mendapatkan sinyal dari objek lain atau dari lingkungan sistem. Beberapa contoh dari Behavioral Modeling antara lain : -     Structured Analysis Analisis terstruktur dalam rekayasa perangkat lunak dan teknik yang sama yaitu Desain Terstruktur, adalah metode untuk menganalisis dan mengubah bisnis persyaratan menjadi spesifikasi dan akhirnya, program komputer , konfigurasi hardware dan prosedur manual yang terkait. Analisis terstruktur dan desain teknik adalah alat fundamental darianalisis sistem , dan dikembangkan dari analisis sistem klasik tahun 1960-an dan 1970-an. Analisis terstruktur merupakan bagian dari serangkaian metode terstruktur, bahwa merupakan koleksi analisis, desain, dan teknik pemrograman yang dikembangkan untuk menanggapi masalah yang dihadapi dunia perangkat lunak dari tahun 1960-an hingga 1980-an. Dalam rentang waktu ini pemrograman yang paling komersial adalah dilakukan di Cobol dan Fortran , maka C dan BASIC .  -     State Diagrams State Diagram adalah jenis diagram yang digunakan dalam ilmu komputer dan bidang terkait untuk menggambarkan perilaku sistem. State Diagrams mengharuskan sistem yang dijelaskan terdiri dari jumlah state yang terbatas. Banyak bentuk State Diagram yang ada sedikit berbeda dan memiliki semantik yang berbeda. State Diagram digunakan untuk memberikan deskripsi abstrak dari perilaku dari suatu sistem . Perilaku ini dianalisis dan direpresentasikan dalam serangkaian event, yang dapat terjadi dalam satu state atau lebih. Dengan ini setiap diagram biasanya mewakili objek dari satu kelas dan melacak negara bagian yang berbeda dari objek melalui sistem State Diagram dapat digunakan untuk menggambarkan finit-state machines. Hal ini diperkenalkan oleh CE Shannon dan W. Weaver pada tahun 1949 buku mereka "Teori Matematika Komunikasi". Sumber lain adalah Taylor Booth dalam "Mesin Sequential dan Teori Automata" 1967 bukunya. Kemungkinan lain representasi adalah tabel transisi State . -     Use Case Analysis Dalam perangkat lunak dan rekayasa sistem , Use Case adalah daftar langkah-langkah, biasanya mendefinisikan interaksi antara peran (dikenal di UML sebagai " aktor ") dan sistem, untuk mencapai tujuan. Aktor dapat menjadi manusia atau sistem eksternal. Dalam rekayasa sistem, use case digunakan pada tingkat yang lebih tinggi daripada dalam rekayasa perangkat lunak, sering mewakili misi atau tujuan stakeholder. Persyaratan rinci kemudian dapat ditangkap di SysML atau sebagai pernyataan kontrak. Pada tahun 1986 Ivar Jacobson pertama kali dirumuskan tekstual, struktural dan teknik pemodelan visual untuk menentukan use case. Pada tahun 1992 bukunya membantu mempopulerkan teknik untuk menangkap kebutuhan fungsional , khususnya dalam pengembangan perangkat lunak. Awalnya dia menggunakan istilahusage scenario dan usage case, yang terakhir menjadi terjemahan langsung dari användningsfall Swedia, tetapi ditemukan bahwa tak satu pun dari istilah-istilah ini terdengar dalam bahasa Inggris, dan akhirnya ia menetap di use case. Sejak itu, orang lain telah memberikan kontribusi untuk meningkatkan teknik ini, termasuk Alistair Cockburn. Pada tahun 2011, Ivar Jacobson menerbitkan sebuah update untuk use case yang disebut Use Case 2.0. -     Interaction Diagrams Interaction Diagram adalah model yang menggambarkan bagaimana sekelompok benda berkolaborasi dalam beberapa perilaku yang biasanya menggunakan single use case. Diagram menunjukkan sejumlah objek contoh dan pesan yang lewat di antara objek-objek dalam use case. Dalam perilaku ini jendela order entry mengirimkan pesan untuk mempersiapkan perintah. Urutan kemudian mengirimkan mempersiapkan diri untuk setiap baris perintah pada urutan. Pertama Order Line akan memeriksa stock item, dan jika nilainya true maka Order Line akan menghilangkan stock tersebut dari stock item. Jika stock item jatuh di bawah tingkat perintah yang baru maka akan dilakukan permintaan pengiriman baru. Interaction Diagram mempunyai dua bentuk, dan keduanya berada didalam UML. Bentuk pertama adalah sequence diagram. Dalam bentuk ini sebuah objek ditampilkan sebagai garis vertikal dengan pesan sebagai garis horisontal berada di antara keduanya. Bentuk ini pertama kali dipopulerkan oleh Jacobson. Diagram di bawah ini menunjukkan bentuk dalam notasi UML nya. -     Failure Mode and Effects Analysis     Failure Mode and Effects Analysis (FMEA) adalah analisis kegagalan induktif yang  digunakan dalam pengembangan produk, rekayasa sistem, keandalan teknik dan manajemen operasi untuk analisis mode kegagalan dalam klasifikasi sistem dengan tingkat keparahan dan kemungkinan kegagalan. Keberhasilan kegiatan FMEA membantu tim untuk mengidentifikasi mode kegagalan potensial berdasarkan pengalaman masa lalu dengan produk sejenis atau proses atau berdasarkan logika mekanisme kegagalan umum dan memungkinkan tim untuk merancang kegagalan mereka keluar dari sistem dengan usaha dan pengeluaran sumber daya yang minimum, sehingga mengurangi waktu dan biaya pengembangan. Hal ini berfungsi sebagai bentuk review design untuk menghapus kelemahan dari desain atau proses. Hal ini banyak digunakan dalam industri pengembangan dan manufaktur di berbagai tahapan dari siklus hidup produk. Efek analisis mengacu pada mempelajari konsekuensi dari kegagalan pada tingkat sistem yang berbeda. -     Fault Tree Analysis Fault Tree Analysis (FTA) adalah top down sebuah analisis kegagalan deduktif di mana keadaan yang tidak diinginkan dari suatu sistem dianalisis menggunakan logika boolean untuk menggabungkan serangkaian lower-level events. Metode analisis yang digunakan terutama dalam bidang safety engineering dan realibility engineeringuntuk menentukan kemungkinan kecelakaan keselamatan atau tingkat sistem tertentu (fungsional) gagal. Dalam Aerospace istilah umum " Kondisi Kegagalan Sistem" digunakan untuk "keadaan yang tidak diinginkan" / Top Event dari Fault Tree. Kondisi ini diklasifikasikan oleh keparahan efek mereka. Kondisi paling parah memerlukan Fault Tree Analysis paling luas. Ini "Kondisi Kegagalan Sistem" dan klasifikasi mereka sering ditentukan sebelumnya dalam fungsional analisis Hazard. Fault Tree Analysis (FTA) dapat digunakan untuk: ·       Memahami logika menuju Top Event / keadaan yang tidak diinginkan. ·       Menunjukkan kepatuhan dengan (masukan) persyaratan System Safety / Reability Requirement. ·     Memprioritaskan kontributor yang mengarah pada Top Event - Menciptakan Alat Kritis / Suku Cadang / daftar peristiwa untuk langkah-langkah penting yang berbeda. ·    Memantau dan mengontrol kinerja keselamatan sistem yang kompleks (misalnya Apakah masih aman bagi Pesawat untuk terbang jika katup bahan bakar x tidak "bekerja"? Untuk berapa lama hal itu diizinkan untuk terbang dengan katup yang tertutup ?). ·        Meminimalkan dan mengoptimalkan sumber daya. ·   Membantu dalam merancang sebuah sistem. FTA dapat digunakan sebagai alat desain yang membantu untuk membuat persyaratan (output / tingkat yang lebih rendah). Berfungsi sebagai alat diagnostik untuk mengidentifikasi dan memperbaiki penyebab dari sebuah Top Event. Hal ini dapat membantu dengan penciptaan manual diagnostik / proses.      ·         Domain Modeling -     Domain Engineering Domain Engineering, juga disebut rekayasa produk lini, adalah seluruh proses menggunakan kembali pengetahuan domain dalam produksi baru perangkat lunak sistem. Ini adalah konsep kunci dalam sistematis penggunaan kembali perangkat lunak . Ide kunci dalam penggunaan kembali perangkat lunak sistematis adalah domain aplikasi, area software yang berisi kesamaan sistem berbagi. Kebanyakan organisasi bekerja hanya dalam beberapa domain . Mereka berulang kali membangun sistem serupa dalam domain yang diberikan dengan variasi untuk memenuhi kebutuhan pelanggan yang berbeda. Daripada membangun setiap varian sistem baru dari awal, penghematan yang signifikan dapat dicapai dengan menggunakan kembali bagian-bagian dari sistem sebelumnya dalam sebuah domain untuk membangun sistem yang baru. Tujuan : Domain Engineering dirancang untuk meningkatkan kualitas produk perangkat lunak yang dikembangkan melalui penggunaan kembali artefak perangkat lunak. Domain Engineering menunjukkan bahwa sistem perangkat lunak yang paling maju bukanlah sistem baru melainkan varian dari sistem lain dalam bidang yang sama. Akibatnya, melalui penggunaan Domain Engineering, suatu bisnis dapat memaksimalkan keuntungan dan mengurangi waktu-ke-pasar dengan menggunakan konsep dan implementasi dari sistem perangkat lunak sebelumnya dan menerapkannya ke sistem target. Fase Domain Engineering : Domain Engineering, seperti Application Engineering, terdiri dari tiga fase utama yaitu: analisis, desain, dan implementasi. Namun, di mana rekayasa perangkat lunak berfokus pada satu sistem, rekayasa domain berfokus pada keluarga sistem. Sebuah model domain yang baik berfungsi sebagai referensi untuk menyelesaikan ambiguitas dalam suatu proses, sebuah repositori pengetahuan tentang karakteristik domain dan definisi, dan spesifikasi untuk pengembang produk yang merupakan bagian dari domain.  ·         Functional Modeling Functional Modeling atau model fungsional dalam rekayasa sistem dan rekayasa perangkat lunak adalah representasi terstruktur dari fungsi ( kegiatan , tindakan , proses , operasi ). Functional Modeling juga disebut sebagai model kegiatan atau model proses , adalah representasi grafis dari suatu fungsi perusahaan dalam lingkup yang ditetapkan. Tujuan dari Functional Modeling adalah untuk menjelaskan fungsi dan proses, membantu dengan penemuan kebutuhan informasi, membantu mengidentifikasi peluang, dan menetapkan dasar untuk menentukan biaya produk dan jasa.         ·         Enterprise Modeling      Enterprise Modeling adalah representasi abstrak, deskripsi dan definisi struktur, proses, informasi dan sumber daya bisnis yang diidentifikasi, badan pemerintahan, atau organisasi besar lainnya. Hal ini berkaitan dengan proses memahami bisnis perusahaan dan meningkatkan kinerja melalui penciptaan model perusahaan. Hal ini mencakup pemodelan domain bisnis yang relevan (biasanya relatif stabil), proses bisnis, dan teknologi informasi.

Tugas Rekayasa Perangkat Lunak T.5.1

Types of Models

·         Information Modeling

Information Modeling dalam rekayasa perangkat lunak merupakan representasi dari konsep dan hubungan, kendala, aturan, dan operasi untuk menentukan semantik data yang dipilih untuk domain wacana. Biasanya hal ini menentukan hubungan antara macam hal, tetapi juga dapat mencakup hubungan dengan hal-hal pribadi. Hal ini dapat menyediakan struktur sharable, stabil, dan persyaratan struktur informasi yang terorganisir atau pengetahuan untuk konteks domain. Contoh dari Information Modeling adalah :

-     Entity - Relationship Modeling

    Dalam rekayasa perangkat lunak , sebuah Entity - Relationship Modeling adalah cara abstrak untuk menggambarkan basis data . Hal ini biasanya dimulai dengan relasi sebuah database, yang menyimpan data dalam tabel. Beberapa data dalam tabel ini menunjukkan data dalam tabel lain - misalnya, entri anda dalam database bisa menunjukkan beberapa entri untuk setiap nomor telepon anda. Entity - Relationship Modeling akan mengatakan bahwa anda adalah suatu entitas, dan masing-masing nomor telepon adalah suatu entitas, dan hubungan antara Anda dan nomor telepon 'memiliki nomor telepon'. Diagram dibuat untuk merancang entitas dan hubungan yang disebut Entity - Relationship Diagram atauentitas-hubungan diagram.

-     Class Diagram

Class Diagram dalam Unified Modeling Language (UML) adalah jenis diagram struktur statis yang menggambarkan struktur dari suatu sistem dengan menunjukkan sistem kelas , atribut mereka, operasi (atau metode), dan hubungan antar kelas. Class Diagram juga disebut blok bangunan utama dari pemodelan berorientasi objek. Hal ini digunakan baik untuk pemodelan konseptual umum dari sistematika aplikasi, dan untuk pemodelan rinci dalam menerjemahkan model ke dalam kode pemrograman. Class Diagram juga dapat digunakan untuk pemodelan data. Kelas-kelas dalam Class Diagram mewakili kedua objek utama, yaitu interaksi dalam aplikasi dan kelas yang akan diprogram.

            Pada diagram, kelas diwakili dengan kotak yang berisi tiga bagian:

·       Bagian atas memegang nama kelas

·       Bagian tengah berisi atribut dari kelas

·       Bagian bawah memberikan metode atau operasi kelas dapat mengambil atau melakukan

   Dalam desain sistem, sejumlah kelas diidentifikasi dan dikelompokkan bersama dalam sebuah diagram kelas yang membantu untuk menentukan hubungan statis antara benda-benda. Dengan pemodelan rinci, kelas dari desain konseptual sering dibagi menjadi beberapa subclass.

·         Behavioral Modeling

Ada beberapa ambiguitas dengan Behavioral Modeling. Dalam UML, behavioral modeling mempunyai arti yang sangat luas, hal itu mencakup semua aspek analisis kecuali aspek statis. Namun, sebagai model obyek entitas, perilaku mereka dapat juga diperlakukan dalam arti yang sempit sebagai serangkaian reaksi objek untuk rangsangan eksternal. Reaksi-reaksi ini biasanya berupa tindakan yang diambil oleh suatu benda karena mendapatkan sinyal dari objek lain atau dari lingkungan sistem. Beberapa contoh dari Behavioral Modeling antara lain :

-     Structured Analysis

Analisis terstruktur dalam rekayasa perangkat lunak dan teknik yang sama yaitu Desain Terstruktur, adalah metode untuk menganalisis dan mengubah bisnis persyaratan menjadi spesifikasi dan akhirnya, program komputer , konfigurasi hardware dan prosedur manual yang terkait. Analisis terstruktur dan desain teknik adalah alat fundamental darianalisis sistem , dan dikembangkan dari analisis sistem klasik tahun 1960-an dan 1970-an.

Analisis terstruktur merupakan bagian dari serangkaian metode terstruktur, bahwa merupakan koleksi analisis, desain, dan teknik pemrograman yang dikembangkan untuk menanggapi masalah yang dihadapi dunia perangkat lunak dari tahun 1960-an hingga 1980-an. Dalam rentang waktu ini pemrograman yang paling komersial adalah dilakukan di Cobol dan Fortran , maka C dan BASIC . 

-     State Diagrams

State Diagram adalah jenis diagram yang digunakan dalam ilmu komputer dan bidang terkait untuk menggambarkan perilaku sistem. State Diagrams mengharuskan sistem yang dijelaskan terdiri dari jumlah state yang terbatas. Banyak bentuk State Diagram yang ada sedikit berbeda dan memiliki semantik yang berbeda.

State Diagram digunakan untuk memberikan deskripsi abstrak dari perilaku dari suatu sistem . Perilaku ini dianalisis dan direpresentasikan dalam serangkaian event, yang dapat terjadi dalam satu state atau lebih. Dengan ini setiap diagram biasanya mewakili objek dari satu kelas dan melacak negara bagian yang berbeda dari objek melalui sistem

State Diagram dapat digunakan untuk menggambarkan finit-state machines. Hal ini diperkenalkan oleh CE Shannon dan W. Weaver pada tahun 1949 buku mereka "Teori Matematika Komunikasi". Sumber lain adalah Taylor Booth dalam "Mesin Sequential dan Teori Automata" 1967 bukunya. Kemungkinan lain representasi adalah tabel transisi State .

-     Use Case Analysis

Dalam perangkat lunak dan rekayasa sistem , Use Case adalah daftar langkah-langkah, biasanya mendefinisikan interaksi antara peran (dikenal di UML sebagai " aktor ") dan sistem, untuk mencapai tujuan. Aktor dapat menjadi manusia atau sistem eksternal. Dalam rekayasa sistem, use case digunakan pada tingkat yang lebih tinggi daripada dalam rekayasa perangkat lunak, sering mewakili misi atau tujuan stakeholder. Persyaratan rinci kemudian dapat ditangkap di SysML atau sebagai pernyataan kontrak.

Pada tahun 1986 Ivar Jacobson pertama kali dirumuskan tekstual, struktural dan teknik pemodelan visual untuk menentukan use case. Pada tahun 1992 bukunya membantu mempopulerkan teknik untuk menangkap kebutuhan fungsional , khususnya dalam pengembangan perangkat lunak. Awalnya dia menggunakan istilahusage scenario dan usage case, yang terakhir menjadi terjemahan langsung dari användningsfall Swedia, tetapi ditemukan bahwa tak satu pun dari istilah-istilah ini terdengar dalam bahasa Inggris, dan akhirnya ia menetap di use case. Sejak itu, orang lain telah memberikan kontribusi untuk meningkatkan teknik ini, termasuk Alistair Cockburn. Pada tahun 2011, Ivar Jacobson menerbitkan sebuah update untuk use case yang disebut Use Case 2.0.

-     Interaction Diagrams

Interaction Diagram adalah model yang menggambarkan bagaimana sekelompok benda berkolaborasi dalam beberapa perilaku yang biasanya menggunakan single use case. Diagram menunjukkan sejumlah objek contoh dan pesan yang lewat di antara objek-objek dalam use case. Dalam perilaku ini jendela order entry mengirimkan pesan untuk mempersiapkan perintah. Urutan kemudian mengirimkan mempersiapkan diri untuk setiap baris perintah pada urutan. Pertama Order Line akan memeriksa stock item, dan jika nilainya true maka Order Line akan menghilangkan stock tersebut dari stock item. Jika stock item jatuh di bawah tingkat perintah yang baru maka akan dilakukan permintaan pengiriman baru. Interaction Diagram mempunyai dua bentuk, dan keduanya berada didalam UML. Bentuk pertama adalah sequence diagram. Dalam bentuk ini sebuah objek ditampilkan sebagai garis vertikal dengan pesan sebagai garis horisontal berada di antara keduanya. Bentuk ini pertama kali dipopulerkan oleh Jacobson. Diagram di bawah ini menunjukkan bentuk dalam notasi UML nya.

-     Failure Mode and Effects Analysis

    Failure Mode and Effects Analysis (FMEA) adalah analisis kegagalan induktif yang  digunakan dalam pengembangan produk, rekayasa sistem, keandalan teknik dan manajemen operasi untuk analisis mode kegagalan dalam klasifikasi sistem dengan tingkat keparahan dan kemungkinan kegagalan. Keberhasilan kegiatan FMEA membantu tim untuk mengidentifikasi mode kegagalan potensial berdasarkan pengalaman masa lalu dengan produk sejenis atau proses atau berdasarkan logika mekanisme kegagalan umum dan memungkinkan tim untuk merancang kegagalan mereka keluar dari sistem dengan usaha dan pengeluaran sumber daya yang minimum, sehingga mengurangi waktu dan biaya pengembangan. Hal ini berfungsi sebagai bentuk review design untuk menghapus kelemahan dari desain atau proses. Hal ini banyak digunakan dalam industri pengembangan dan manufaktur di berbagai tahapan dari siklus hidup produk. Efek analisis mengacu pada mempelajari konsekuensi dari kegagalan pada tingkat sistem yang berbeda.

-     Fault Tree Analysis

Fault Tree Analysis (FTA) adalah top down sebuah analisis kegagalan deduktif di mana keadaan yang tidak diinginkan dari suatu sistem dianalisis menggunakan logika boolean untuk menggabungkan serangkaian lower-level events. Metode analisis yang digunakan terutama dalam bidang safety engineering dan realibility engineeringuntuk menentukan kemungkinan kecelakaan keselamatan atau tingkat sistem tertentu (fungsional) gagal.

Dalam Aerospace istilah umum " Kondisi Kegagalan Sistem" digunakan untuk "keadaan yang tidak diinginkan" / Top Event dari Fault Tree. Kondisi ini diklasifikasikan oleh keparahan efek mereka. Kondisi paling parah memerlukan Fault Tree Analysis paling luas. Ini "Kondisi Kegagalan Sistem" dan klasifikasi mereka sering ditentukan sebelumnya dalam fungsional analisis Hazard.

Fault Tree Analysis (FTA) dapat digunakan untuk:

·       Memahami logika menuju Top Event / keadaan yang tidak diinginkan.

·       Menunjukkan kepatuhan dengan (masukan) persyaratan System Safety / Reability Requirement.

·     Memprioritaskan kontributor yang mengarah pada Top Event - Menciptakan Alat Kritis / Suku Cadang / daftar peristiwa untuk langkah-langkah penting yang berbeda.

·    Memantau dan mengontrol kinerja keselamatan sistem yang kompleks (misalnya Apakah masih aman bagi Pesawat untuk terbang jika katup bahan bakar x tidak "bekerja"? Untuk berapa lama hal itu diizinkan untuk terbang dengan katup yang tertutup ?).

·        Meminimalkan dan mengoptimalkan sumber daya.

·   Membantu dalam merancang sebuah sistem. FTA dapat digunakan sebagai alat desain yang membantu untuk membuat persyaratan (output / tingkat yang lebih rendah). Berfungsi sebagai alat diagnostik untuk mengidentifikasi dan memperbaiki penyebab dari sebuah Top Event. Hal ini dapat membantu dengan penciptaan manual diagnostik / proses. 

  

 ·         Domain Modeling

-     Domain Engineering

Domain Engineering, juga disebut rekayasa produk lini, adalah seluruh proses menggunakan kembali pengetahuan domain dalam produksi baru perangkat lunak sistem. Ini adalah konsep kunci dalam sistematis penggunaan kembali perangkat lunak . Ide kunci dalam penggunaan kembali perangkat lunak sistematis adalah domain aplikasi, area software yang berisi kesamaan sistem berbagi. Kebanyakan organisasi bekerja hanya dalam beberapa domain . Mereka berulang kali membangun sistem serupa dalam domain yang diberikan dengan variasi untuk memenuhi kebutuhan pelanggan yang berbeda. Daripada membangun setiap varian sistem baru dari awal, penghematan yang signifikan dapat dicapai dengan menggunakan kembali bagian-bagian dari sistem sebelumnya dalam sebuah domain untuk membangun sistem yang baru.

Tujuan :

Domain Engineering dirancang untuk meningkatkan kualitas produk perangkat lunak yang dikembangkan melalui penggunaan kembali artefak perangkat lunak. Domain Engineering menunjukkan bahwa sistem perangkat lunak yang paling maju bukanlah sistem baru melainkan varian dari sistem lain dalam bidang yang sama. Akibatnya, melalui penggunaan Domain Engineering, suatu bisnis dapat memaksimalkan keuntungan dan mengurangi waktu-ke-pasar dengan menggunakan konsep dan implementasi dari sistem perangkat lunak sebelumnya dan menerapkannya ke sistem target.

Fase Domain Engineering :

Domain Engineering, seperti Application Engineering, terdiri dari tiga fase utama yaitu: analisis, desain, dan implementasi. Namun, di mana rekayasa perangkat lunak berfokus pada satu sistem, rekayasa domain berfokus pada keluarga sistem. Sebuah model domain yang baik berfungsi sebagai referensi untuk menyelesaikan ambiguitas dalam suatu proses, sebuah repositori pengetahuan tentang karakteristik domain dan definisi, dan spesifikasi untuk pengembang produk yang merupakan bagian dari domain. 

·         Functional Modeling

Functional Modeling atau model fungsional dalam rekayasa sistem dan rekayasa perangkat lunak adalah representasi terstruktur dari fungsi ( kegiatan , tindakan , proses , operasi ).

Functional Modeling juga disebut sebagai model kegiatan atau model proses , adalah representasi grafis dari suatu fungsi perusahaan dalam lingkup yang ditetapkan. Tujuan dari Functional Modeling adalah untuk menjelaskan fungsi dan proses, membantu dengan penemuan kebutuhan informasi, membantu mengidentifikasi peluang, dan menetapkan dasar untuk menentukan biaya produk dan jasa.

       

·         Enterprise Modeling

     Enterprise Modeling adalah representasi abstrak, deskripsi dan definisi struktur, proses, informasi dan sumber daya bisnis yang diidentifikasi, badan pemerintahan, atau organisasi besar lainnya. Hal ini berkaitan dengan proses memahami bisnis perusahaan dan meningkatkan kinerja melalui penciptaan model perusahaan. Hal ini mencakup pemodelan domain bisnis yang relevan (biasanya relatif stabil), proses bisnis, dan teknologi informasi.