metodologi desain sistem @2012,eko didik widianto...

Metodologi DesainSistem

@2012,Eko DidikWidianto


Lisensi

Metodologi Desain SistemKuliah#2 TSK-612 Sistem Embedded Terdistribusi - TA

2011/2012

Eko Didik Widianto

Teknik Sistem Komputer - Universitas Diponegoro




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]

http://didik.blog.undip.ac.id/2012/03/06/kuliah-tsk-612-sistem-embedded-terdistribusi-2011/


mailto:[email protected]

http://www.ece.cmu.edu/~ece649/




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]



mailto:[email protected]




Lisensi

Bahasan

Metodologi Desain SistemMetodologi secara Umum

Lisensi



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




Lisensi

Bahasan

Metodologi Desain SistemMetodologi secara Umum

Lisensi




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




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




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




Lisensi

Model Pengembangan Waterfall




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




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)




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




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)




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”




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




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




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




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




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




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...




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.




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




Lisensi

Kebutuhan Perilaku

1. Event-driven system (think “interrupts”):2. Time-triggered system is different (think “polled I/O”):




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

http://creativecommons.org/licenses/by-sa/3.0/

http://creativecommons.org/licenses/by-sa/3.0/

metodologi desain sistem @2012,eko didik widianto...

Documents