Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistem
Lisensi
Metodologi Desain SistemKuliah#2 TSK-612 Sistem Embedded Terdistribusi - TA
2011/2012
Eko Didik Widianto
Teknik Sistem Komputer - Universitas Diponegoro
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistem
Lisensi
Review Kuliah
I Pokok bahasan di kuliah #1I Penjelasan tentang sistem embedded terdistribusiI Deskripsi, tujuan, sasaran dan materi kuliah TSK612
Sistem Embedded Terdistribusi
I Umpan balikI Jelaskan tentang sistem embedded!I Jelaskan tentang sistem terdistribusi!I Jelaskan tentang sistem embedded terdistribusi!
I LinkI Website: http://didik.blog.undip.ac.id/2012/03/06/
kuliah-tsk-612-sistem-embedded-terdistribusi-2011/I Email: [email protected]
I Acknowledgement:I Beberapa gambar yang ada di slide ini diambil dari
http://www.ece.cmu.edu/~ece649/[ECE649]
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistem
Lisensi
Tentang Kuliah
I Pokok bahasan di kuliah #2I Metodologi desain sistem: waterflow, v-model, agileI Penerapan metodologi untuk mengembangkan sistem
embedded terdistribusi
I Kompetensi dasarI [C2] mahasiswa akan memahami metodologi desain secara
umum, meliputi waterflow, v-model, spiral dan agileI [C3] mahasiswa akan mampu mengaplikasikan metodologi
tersebut dalam mendesain suatu sistem embeddedterdistribusi
I LinkI Website: http://didik.blog.undip.ac.id/2012/03/06/
kuliah-tsk-612-sistem-embedded-terdistribusi-2011/I Email: [email protected]
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistem
Lisensi
Bahasan
Metodologi Desain SistemMetodologi secara Umum
Lisensi
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
General Quote
I Mengetahui cara untuk mensolder tidak akan membuatseseorang menjadi insinyur elektronika
I Mengetahui cara untuk menuliskan kode tidak akanmembuat seseorang menjadi insinyur software
I Mengetahui cara untuk mensolder dan menulis kode tidakakan membuat seseorang menjadi insinyur sistemembedded
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Bahasan
Metodologi Desain SistemMetodologi secara Umum
Lisensi
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Metodologi Desain secara Umum
I Kebutuhan sistem merupakanbentuk penugasan projek yangperlu ditulis
I Asumsi: sempurnaI Tapi, tidak akan pernah
lengkap dan/atau sempurnasaat memulai projects
I Terdapat banyak langkah antarakebutuhan dan implementasi
I Akankah memulaimenyolder/menyambungkanjalur tanpa skematik?
I Akankah menulis kode atauVHDL tanpa sebuah desain?
I Sebagian besar projek, integrasidapat diselesaikan dalam waktu50% dari jadwalnya
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Metodologi Pengembangan
I Rencana tertulis yang menyatakan bagaimanapengembangan sistem akan dilakukan
I Pendekatan yang diambilI Bagaimana requirement dibuat dan dikelolaI Bagaimana arsitektur didefinisikan dan dikembangkanI Bagaimana perancangan dan implementasi akan dilakukan
dan didokumentasikanI Bagaimana pengujian direncanakan dan dieksekusiI Bagaimana evaluasi dilakukanI Aspek lain: pemeliharaan, manajemen projek, pengelolaan
SDM, dan lain-lainnya
I Tiap langkah mendefinisikan aktivitas, input dan outputI Berupa diagram kotak dan garis panah dengan labelnya
masing-masingI Label garis panah terkait dengan luaran (misalnya
dokumen), yang menjadi tolak ukur untuk melangkah keaktivitas berikutnya
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Siklus Pengembangan Sistem
I Metodologi pengembangan tersebut dapat dilakukandengan pendekatan berikut:
1. Waterfall: berurutan mulai dari spesifikasi sampaipemasangan dan pemeliharaan
2. V-model: versi waterfall yang dimodifikasi untuk mengejarmodularity subsistem
3. Spiral model: mengkombinasikan elemen dalam tahapdesain dan prototyping sebagai upaya memanfaatkankelebihan pendekatan top-down dan bottom-up
4. Agile model: self-organizing dan cross-functional team.Pengembangan iterative dan incremental
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Model Pengembangan Waterfall
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Model Pengembangan Kurva-V
I Merupakan versi modifikasi dari model waterfallI Untuk mengeksploitasi modularitas subsistemI Sisi kiri: definisi projek, sisi kanan: pengujian dan integrasi, bagian
bawah: implementasi
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Perspektif Rekayasa Software
I Mengapa perlu metode rekayasa software?I Pembuatan software telah menjadi komponen biaya utamaI Metode dan pendekatan khusus diperlukan untuk
mengelola kompleksitas softwareI Untuk mengurangi costI Untuk menjadi kesesuaian jadwalnyaI Untuk meningkatkan kualitas sehingga defect software tidak
merugikan perusahaan
I Aplikasi embedded memerlukan standar yang lebih tinggidaripada software desktop
I Perspektif yang perlu diambilI Proses yang baik diperlukan untuk mendapatkan software
yang bagusReview desain merupakan aktivitas penting untuk memulaimengerjakan sesuatu dengan benar (doing right)
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Perlunya Requirement
I Memastikan sistem melakukan fungsinya dengan benar(the right things)
I Memastikan sistem tidak melakukan fungsi yang salahI Menuliskan daftar semua konstrain yang harus dipenuhi
oleh produkI realtime, sumber daya listrik, ukuran, berat, etc
I Memastikan sistem cukup kompleks, namun melebihiyang diperlukan
I Fungsionalitas dipenuhiI Meminimalkan biaya/meminimalkan kompleksitasI Dengan ekstensi, requirement yang sederhana lebih baik
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Sudut Pandang Kebutuhan
I Requirement Sistem/BisnisI Fungsional: lift harus dapat mengangkat semua orang
dengan kecepatan yang memadaiI Lift mungkin harus lebih cepat dari lift kompetitor
I Non-fungsional: lift harus meningkatkan profit kontrakpemeliharaan
I Constraint: produk harus kompetibel dengan jaringanpemeliharaan gedung yang ada
I Requirement Marketing/EngingeeringI Fungsional: lift harus mempunyai kecepatan puncak 11.3
meter/detik (jika kecepatan tercepat kompetitor 11.2 m/dt)I Non-fungsional: lift harus mempunyai antarmuka diagnostikI Contraint: lift harus kompatible dengan jaringan standar
(BACnet)
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Requirement Teknis
I Kebutuhan fungsional (FRS, functional requirement specs)I Pelepasan tombol X sebaiknya menghidupkan lampu Y dalam waktu 200ms
I Kebutuhan non-fungsionalI “Mean time between unsafe operating situations for each rail signal shall be
greater than 250,000 years” (example from a subway system)I “Mean time to repair a single component failure shall be less than 30 minutes
after arrival of mechanic bringing standard tool set.” (typical jet aircraft)I “Elevator shall deliver at least 1000 passenger*floors/minute at up-peak”
I ConstraintsI Specifies a required technical or other approach
I “.NET technology shall be used”I Specifies regulatory or other constraints on solution space/design process
I “System shall conform to requirements of DO-178b” (FAA softwareprocess)
I Assumptions/operating conditionsI “Assume no power outage lasts more than 30 minutes”
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Proses Pengembangan Kebutuhan
I Proses pengembangan kebutuhan di sistem embedded1. Elicitation: Identify business/system requirements (B100)2. Create architecture / allocate functions to subsystems
(B200-OVS)3. Create scenarios / use cases (B200-SWS)4. Create detailed behavioral requirements (B200-FRS)
I Requirements Traceability & Risk Management1. Create traceability matrices to trace:
I System req., behavioral req., implementations, integrationtests, System req., acceptance tests
2. Simulate system to check global/emergent behaviors3. Prototype system to check allocation-based properties
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
1. Requirement ElicitationIdentify business/system requirements
I Customer may provide requirements in request for quote(RFQ)
I Vendor may need to interview customer and extractrequirements
I Requirements phase may precede design phase under aseparate contract
I You might have engineering judgment ( “guessing”)I “I’ll know it when I see it”I “Same as last time except better”
I This is one place where being a good writer + clear thinkerreally helps!
I It can help a lot to have a professional technical writer onthe requirements team
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Keyword
I Behaviors/Constraints:I Shall = system has to do it 100% of the time unless specifically
exceptedI Should = desirable that system does it whenever reasonable to do
soI Can = system can do something, but no particular incentive to
implementI User Actions:
I Must = user has to do this (same as “shall”, except for user, notcomputer)
I May = user can exhibit this behavior, but does not have toI Environment words:
I Will = designer can count on environment being this wayI Might = designer has to accommodate situation, but can’t count on
it
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Contoh: High-Level Requirement
I (What does it do?): All passengers shall be delivered todesired destination floor in a timely manner.
I (Safety): Any unsafe condition shall cause an emergencystop
I An emergency stop should never occur
I (What metrics matter?): Performance should be optimizedto extent possible, including customer-specified weightingsfor:
I Delivery times:I Maximum end-to-end passenger delivery timeI Maximum passenger waiting timeI Average end-to-end passenger delivery timeI Average passenger waiting time
I Note: SHALL = mandatory, SHOULD = desirable
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
2. Membuat Arsitektur
I Class/Component diagram:I Objects and interfacesI However, architecture is both objects AND interfaces, so
there is more to it
I Assume you have a list of objects in the systemI Elevator carI DoorsI Hall call buttonsI Car call buttonsI Directional lanterns
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
3. Membuat Skenario / Use CaseI First: high level flows through the system
I Idea is to create a flow chart of actions experienced by actors /“object lifecycles”
I Elevator passenger from initial entry into system until finaldelivery
I Driver from entering car to leaving carI Each block of flow chart yields one or more use cases
I (Object-oriented/other approaches possible, but flow chartsare usual practice)
I Second: “building-block” use cases catching snippets of functionalityI Multiple scenarios possible for each use case (elevator example):
I Passenger calls carScenario: Presses button onceScenario: Button has already been pressed by someone else
I Passenger enters carScenario: Successful first tryScenario: Gets bumped by door and exits instead of entering,then retries
I Passenger calls destination...
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
4. Membuat Detail Kebutuhan Perilaku
Behavioral Requirement:I 2.3.1 When the first probe temperature exceeds 80
degrees C +/- 1 degree C, the heating element shall turnoff within 100 msec.Rationale: this is a software safety mechanism to avoidactuating safety relief valve....
Constraint:I 5.7.1 Program memory shall be no more than 60% full at
initial product release.Rationale: this leaves room for software expansion andavoids software costs caused by nearly-full memory.
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Membuat Detail Kebutuhan Perilaku
1. List subsystemsI In a fine-grain distributed system, this is sensors+actuators+objects
I “Other objects” are usually compute-nodes such as dispatcherI Actors included to provide environmental model and interface
2. Create a database of behavioral requirements for each subsystemI ReplicationI Instantiation
I Initial conditionsI When are dynamic objects are created?
I Assumptions about how other modules behaveI I/O interface (list of sensor/actuator interfaces)I State (private variables useful for describing behavioral memory)I Constraints
I Non-functional requirements; safety interlocksI Behaviors
I Functional requirements
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistemMetodologi secara Umum
Lisensi
Kebutuhan Perilaku
1. Event-driven system (think “interrupts”):2. Time-triggered system is different (think “polled I/O”):
Metodologi DesainSistem
@2012,Eko DidikWidianto
Metodologi DesainSistem
Lisensi
Lisensi
Creative Common Attribution-ShareAlike 3.0 Unported (CCBY-SA 3.0)
I Anda bebas:I untuk Membagikan — untuk menyalin, mendistribusikan,
dan menyebarkan karya, danI untuk Remix — untuk mengadaptasikan karya
I Di bawah persyaratan berikut:I Atribusi — Anda harus memberikan atribusi karya sesuai
dengan cara-cara yang diminta oleh pembuat karyatersebut atau pihak yang mengeluarkan lisensi.
I Pembagian Serupa — Jika Anda mengubah, menambah,atau membuat karya lain menggunakan karya ini, Andahanya boleh menyebarkan karya tersebut hanya denganlisensi yang sama, serupa, atau kompatibel.
I Lihat: Creative Commons Attribution-ShareAlike 3.0Unported License