-hk- 1

Software MetodologiHendra Komara, ST.

-hk- 2

Objective

• Mampu memahami software development metodologi, teknik dan kakas dari Konvensional sampai Agile

-hk- 3

1. Model Proses konvensional

• Waterfall Model• Top Down Model• Buttom Up Model• Hybrid Model• Prototyping Model• Rapid application development (RAD)

-hk- 4

1.1. Waterfall ModelRequirement

Analysis

Design

Implementation

Testing

Deployment

Maintenance

-hk- 5

Characteristics

• Sequential, proses dilakukan step by step dari requirement gathering sampai maintenance stage.

• model Waterfall cocok untuk Sistem yang memiliki persyaratan yang jelas dan dipahami adalah cocok untuk Waterfall Model.

-hk- 6

Problems• Persyaratan hampir selalu berubah. Tidak ada cara formal untuk mengadopsi

perubahan ini. • Perubahan menyebabkan membingungkan bagi tim proyek, kadang-kadang

persyaratan yang dinyatakan di awal mungkin menjadi usang ketika kode tersebut masuk ke produksi • Proyek-proyek nyata jarang mengikuti aliran sekuensial bahwa model mengusulkan. • Meskipun model linier bisa mengakomodasi iterasi, ia melakukannya secara tidak

langsung. • Model linier sekuensial memerlukan hal ini dan mengalami kesulitan

mengakomodasi ketidakpastian natural yang ada pada awal banyak proyek. • Pelanggan harus memiliki kesabaran. Sebuah versi kerja dari program (s) tidak akan

tersedia sampai akhir proyek rentang waktu. • Ini mungkin bukan model yang baik untuk sistem yang kompleks yang yang

memakan waktu lebih dari beberapa bulan untuk menyelesaikan • Beberapa anggota tim proyek harus menunggu untuk anggota lain dari tim untuk

menyelesaikan tugas-tugas tergantung (blocking state). • Bahkan, waktu yang dihabiskan menunggu bisa melebihi waktu yang dihabiskan

untuk pekerjaan produktif! • Negara memblokir cenderung lebih lazim pada awal dan akhir dari sebuah proses

yang berurutan linear.

-hk- 7

1.2. Top Down modeL

• Dipopulerkan oleh IBM pada tahun 1970 • Gunakan model Waterfall • Prosedur Persyaratan tingkat tinggi didokumentasikan, dan program yang dibangun untuk memenuhi persyaratan ini. Kemudian, tingkat berikutnya dirancang dan dibangun. • Cara yang baik untuk gambar model Top-down adalah untuk memikirkan aplikasi berbasis menu. • Item menu tingkat atas akan dirancang dan kode, dan kemudian setiap sublevel akan ditambahkan setelah tingkat atas selesai. Setiap item menu merupakan subsistem dari aplikasi Total

-hk- 8

Advantages/disadvantages

• Model Top down adalah cocok saat aplikasi yang baru dan tidak ada fungsi yang ada yang dapat dimasukkan ke dalam sistem baru.

• Masalah utama dengan model Top down adalah bahwa: fungsi sistem nyata tidak dapat ditambahkan dan diuji sampai akhir dalam proses pembangunan. Jika masalah tidak terdeteksi di awal proyek, mereka dapat mahal untuk memperbaiki nanti.

-hk- 9

1.3. Bottom Up Model

• karakteristik: • tingkat terendah dari fungsi dirancang dan diprogram pertama, • semua bagian yang terintegrasi bersama-sama ke dalam aplikasi selesai pada

akhirnya.• umumnya, komponen yang paling kompleks dikembangkan dan diuji terlebih

dahulu. • mendorong pengembangan dan penggunaan komponen software reusable

yang dapat digunakan berkali-kali di banyak proyek pengembangan perangkat lunak.

• • Kerugian dari model Bottom-up adalah • jumlah ekstrim koordinasi diperlukan untuk memastikan bahwa komponen

perangkat lunak individu bekerja sama dengan benar dalam sistem selesai.

• • Beberapa sistem dikembangkan murni dari model bottom-up.

-hk- 10

1.4. Hybrid Model• Menggabungkan top down / bottom up Model• Tim desain terutama bekerja atas ke bawah, tetapi• Tim pengembangan mengidentifikasi dua jenis komponen tingkat yang lebih rendah untuk

bekerja pada waktu yang sama sebagai komponen tingkat tinggi .• Jenis pertama dari komponen tingkat rendah akan• modul perangkat lunak yang ada dari proyek-proyek lain yang dapat digunakan kembali dalam

proyek baru .• tim desain terutama bekerja atas ke bawah, tetapi tim pengembangan mengidentifikasi dua

jenis komponen tingkat yang lebih rendah untuk bekerja pada waktu yang sama sebagai komponen tingkat tinggi .

• Jenis pertama dari komponen tingkat rendah akan ada modul software dari proyek-proyek lain yang dapat digunakan kembali dalam proyek baru .

• Jenis lain dari komponen tingkat rendah yang akan dikembangkan di awal proyek akan komponen perangkat lunak dengan risiko kegagalan yang tinggi .

• Pendekatan ini memungkinkan tim pengembangan untuk membuat perubahan pada sistem awal proyek jika terjadi masalah dengan komponen berisiko tinggi .

• Sebuah teknik akses data baru tim telah tidak digunakan sebelum atau komponen yang mungkin memerlukan jumlah tinggi waktu proses CPU adalah contoh risiko tinggi komponen tingkat rendah .

• Pada kenyataannya , banyak model SDLC adalah variasi dari Hybrid Model .• The Spiral Model adalah contoh yang telah dibahas sebelumnya .

-hk- 11

1.5. Prototyping Model

-hk- 12

Prototyping Model

• Prototyping adalah proses pembuatan model sederhana software yang mengijinkan pengguna memiliki gambaran dasar tentang program serta melakukan pengujian awal. • Prototyping memberikan fasilitas bagi pengembang dan pemakai

untuk saling berinteraksi selama proses pembuatan, sehingga pengembang dapat dengan mudah memodelkan perangkat lunak yang akan dibuat.

-hk- 13

Klasifikasi Jenis Prototyping Berdasar Tingkat Kerincian

• Low fidelity prototype tidak terlalu rinci menggambarkan sistem. Karakteristik dari low fidelity prototype adalah mempunyai fungsi atau interaksi yang terbatas, lebih menggambarkan kosep perancangan dan layout dibandingkan dengan model interaksi, tidak memperlihatkan secara rinci operasional sistem, mendemostrasikan secara umum feel and look dari antarmuka pengguna dan hanya menggambarkan konsep pendekatan secara umum (Walker et al, 2003).• High fidelity protoype lebih rinci menggambarkan sistem. Prototipe

ini mempunyai interaksi penuh dengan pengguna dimana pengguna dapat memasukkan data dan berinteraksi dengan dengan sistem, mewakili fungsi-fungsi inti sehingga dapat mensimulasikan sebagian besar fungsi dari sistem akhir dan mempunyai penampilan yang sangat mirip dengan produk sebenarnya (Walker et al, 2003).

-hk- 14

Phase Prototyping

1. Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya;

2. Perancangan: perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.

3. Evaluasi prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

-hk- 15

Pendekatan Protyping

1. Throw-Away• Prototype dibuat dan dites. Pengalaman yang diperoleh dari pembuatan

prototype digunakan untuk membuat produk akhir (final), kemudian prototype tersebut dibuang (tak dipakai).

2. Incremental• Produk finalnya dibuat sebagai komponen-komponen yang terpisah.

Desain produk finalnya secara keseluruhan haya ada satu tetapi dibagi dalam komonen-komponen lebih kecil yang terpisah (independent).

3. Evolutionary• Pada metode ini, prototipenya tidak dibuang tetapi digunakan untuk

iterasi desain berikutnya. Dalam hal ini, sistem atau produk yang sebenarnya dipandang sebagai evolusi dari versi awal yang sangat terbatas menuju produk final atau produk akhir.

-hk- 16

Keunggulan Protyping

1. Adanya komunikasi yang baik antara pengembang dan pelanggan.2. Pengembang dapat bekerja lebih baik dalam menentukan

kebutuhan pelanggan.3. Pelanggan berperan aktif dalam pengembangan system.4. Lebih menghemat waktu dalam pengembangan system.5. Penerapan menjadi lebih mudah karena pemakai mengetahui apa

yang diharapkannya

-hk- 17

Kelemahan Protyping

1. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu lama.

2. Pengembang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan blue print dari sistem .

3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik.

4. Sulitnya menentukan berapa kali harus bertemu dengan customer5. Proyek bisa dijalankan tanpa batasan waktu yang jelas6. Harus mengatasi konflik antara developer dan customer7. Mengukur tahapan pembuatan software tanpa batasan yang jelas8. Permintaan yang berlebihan dari customer bisa muncul9. Customer tidak peduli terhadap proyek software

-hk- 18

1. 6. Rapid Application Development (RAD)

• Rapid application development (RAD) adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). • RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. • Waktu yang singkat adalah batasan yang penting untuk model ini. • Rapid application development menggunakan metode iteratif (berulang)

dalam mengembangkan sistem dimana working model (model bekerja). Sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. • Working model digunakan kadang-kadang saja sebagai basis desain dan

implementasi sistem final.• Model RAD mengadopsi model waterfall dan pembangunan dalam waktu

singkat (versi “High Speed” dari model Waterfall)

-hk- 19

Rapid application development (RAD)

• RAD dapat diterapkan jika kebutuhan telah lengkap dan jelas serta dipahami dengan baik, • Waktu yang dibutuhkan untuk menyelesaikan secara lengkap

perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. • Model RAD hampir sama dengan model waterfall, bedanya siklus

pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.

-hk- 20

Untuk mendapat kecepatan, RAD Menerapkan Prinsip-prinsip berikut:• Component based construction ( pemrograman berbasis komponen

bukan prosedural).• Penekanan pada penggunaan ulang (reuse) komponen perangkat

lunak yang telah ada.• Pembangkitan kode program otomatis/semi otomatis.• Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa

tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan • Model ini melibatkan multiple team (banyak tim), tiap tim

menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.

-hk- 21

-hk- 22

Phases in RAD (1)

1. Business modeling• Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk

menjawab pertanyaan-pertanyaan berikut : • Informasi apa yang mengendalikan proses bisnis ? • Informasi apa yang di munculkan? • Siapa yang memunculkanya? • Kemana informasi itu pergi? • Siapa yang memprosesnya ?

2. Data modeling.• Aliran informasi yang didefinisikan sebagai bagian dari fase pemodelan bisnis disaring ke dalam

serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik/attribut dari masing-masing objek diidentifikasi dan hubungan antara objek-objek tersebut didefinisikan.

3. Process modeling.• Aliran informasi yang didefinisikan dalam fase pemodelan data ditransformasikan untuk

mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali sebuah objek data.

-hk- 23

Phases in RAD (2)

4. Application generation.• Menciptakan perangkat lunak dengan menggunakan bahasa pemrograman

generasi ketiga yang konvensional, • Metode pengembangan perangkat lunak RAD lebih banyak memproses kerja

untuk memakai lagi komponen program yang telah ada atau menciptakan komponen yang bisa reuse. • Pada semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasi

kontruksi PL.

5. Testing and turnover.• proses metode pengembangan perangkat lunak RAD menekankan pada

reuse, banyak komponen yang telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji

-hk- 24

Kelemahan RAD

1. Untuk proyek dengan skala besar, metode pengembangan perangkat lunak RAD membutuhkan sumber daya manusia yang cukup untuk membentuk sejumlah tim RAD yang baik.

2. Metode pengembangan perangkat lunak RAD membutuhkan pengembang dan pemakai yang mempunyai komitmen dalam aktivitas rapid-fire untuk melaksanakan aktivitas melengkapi sistem dalam kerangka waktu yang singkat. Jika komitmen tersebut tidak ada, proyek RAD gagal.

3. Tidak semua aplikasi sesuai untuk metode pengembangan perangkat lunak RAD bila sistem tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematic. RAD menjadi tidak sesuai jika risiko teknisnya tinggi.

-hk- 25

Kelebihan RAD

1. Hasil pengembangan bisa lebih cepat dibandingkan SDLC lainnya2. Memerlukan biaya yang lebih sedikit3. Mementingkan dari segi bisnis dan teknik4. Berkonsentrasi pada sudut pandang user5. Menyediakan kemungkinan perubahan secara cepat sesuai

permintaan user6. Menghasilkan jarak kesesuaian yang kecil antara kebutuhan user

dan spesifikasi sistem7. Waktu, biaya, dan effort minimal

-hk- 26

Kondisi sesuai yang dapat diterapkan model  RAD1. Proyek dengan skala kecil sampai medium dengan waktu pendek.2. Fokus pada lingkup tertentu, misalnya pada objek bisnis yang

telah didefinisikan dengan baik3. Bukan aplikasi dengan komputasi yang kompleks4. User tahu pasti area yang harus dimiliki aplikasi5. Manajemen memiliki komitmen terhadap keterlibatan user6. Spesifikasi kebutuhan sudah benar-benar diketahui7. Pendefinisian spesifikasi yang tidak perlu waktu lama8. Anggota tim memiliki keahlian yang baik9. Komposisi tim stabil10. Ada kontrol proyek yang efektif

-hk- 27

Kondisi tidak sesuai saat diterapkan model  RAD

1. Proyek yang terlalu besar dan kompleks 2. Proyek yang bersifat aplikasi real-time atau menangani hal-hal

yang kritis3. Sistem dengan komputasi tinggi4. Lingkup dan objek bisnis proyek belum jelas5. Pengumpulan spesifikasi kebutuhan membutuhkan waktu lama6. Banyak orang yang harus terlibat dalam proyek7. Membutuhkan lingkup daerah yang luas8. Tim proyek besar dengan koordinasi tinggi9. Komiten pihak manajemen dengan user rendah10. Banyak teknologi baru digunakan untuk membangun aplikasi

-hk- 28

2. Evolutionary software Model Prosess

• Software evolves over a period of time• Changes of requirements drive the evolution• Prototype is introduced to gain more understanding between a customer and

a developer, thus it only assists both parties

• The evolutionary nature is not considered in classic development paradigms.• Evolutionary models are iterative. They are characterized in a manner

that enables software engineers to develop increasingly more complete versions of the software.• Incremental model• Spiral model• Component Based Development (CBD) Model• Formal Methods Model• V Model

-hk- 29

2.1 Incremental Model

-hk- 30

Characteristics (1)

• Pengembangan dengan model ini cocok untuk core produk• Delivery langsung ke user sudah berupa prototipe lengkap (bukan

mock-up)

-hk- 31

Characteristics (1)

• The incremental model combines elements of the linear sequential model (applied repetitively) with the iterative philosophy of prototyping.• The incremental model applies linear sequences in a staggered fashion as

time progresses.• Each linear sequence produces a deliverable “increment” of the software

• For example, word processing software developed using the incremental paradigm ‐might deliver basic file management, editing, and document production functions in the first increment; more sophisticated editing and document production capabilities in the second increment; spelling and grammar checking in the third increment; and advanced page layout capability in the fourth increment.

• It should be noted that the process flow for any increment can incorporate the prototyping paradigm.

-hk- 32

Characteristics (2)

• When an incremental model is used, the first increment is often a core product.• basic requirements are addressed, but many supplementary features (some

known, others unknown) remain undelivered.

• The core product is used by the customer (or undergoes detailed review).• As a result of use and/or evaluation, a plan is developed for the next

increment.• The plan addresses the modification of the core product to better meet the

needs of the customer and the delivery of additional features and functionality.

• This process is repeated following the delivery of each increment, until the complete product is produced.

-hk- 33

Characteristics (3)

• The incremental process model is iterative in nature.• But unlike prototyping, the incremental model focuses on the delivery of an

operational product with each increment.• Early increments are stripped down versions of the final product, but they do

provide capability that serves the user and also provide a platform for evaluation by the user.

• Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the project.• Early increments can be implemented with fewer people. If the core product is well

received, then additional staff (if required) can be added to implement the next increment.

• Increments can be planned to manage technical risks.• For example, a major system might require the availability of new hardware that is under

development and whose delivery date is uncertain.

• It might be possible to plan early increments in a way that avoids the use of this hardware, thereby enabling partial functionality to be delivered to end users without ‐inordinate delay.

-hk- 34

2.2 Spiral Model

• Model spiral dikembangan berdasarkan dari penyempurnaan waterfall model dan merangkai sifat iteratif dari model prototipe dimana cara kontrol dan aspek sistematis berasal dari model sekuensial linear.• Model spiral memungkinkan untuk melakukan perubahan, tambahan

serta perbaikan setiap rilis produk yang baru. • Model spiral umumnya banyak digunakan untuk data yang besar, dan

model yang rumit, model ini juga membantu mengelola resiko dan ketidakpastian dengan memungkinkan beberapa poin keputusan dan secara eksplisit menjelaskan bahwa tidak semua aktivitas dapat diketahui sebelum aktivitas berikutnya dimulai

-hk- 35

Spiral Model

• Model spiral juga secara eksplisit termasuk dalam manajemen resiko dalam pengembangan perangkat lunak. Dengan mengidentifikasi resiko utama baik secara teknis dan manajerial, dan dapat menentukan bagaimana mengurangi resiko dalam menjaga proses pengembangan perangkat lunak dibawah kontrol.• Model spiral mengacu pada konsep perbaikan terus menerus

terhadap produk inti dengan menggunakan banyak fase didasarkan pada urutan yang sama, dipisahkan oleh perencanaan, penilaian resiko, dan pembangunan prototipe dan simulasi.• Model spiral konsisten untuk membuat transisi yang tertib untuk

kegiatan pemeliharaan.• Model spiral memungkinkan keterlibatan pengguna awal (pimpinan

proyek yang lama) dalam upaya pengembangan sistem, sehingga diharapkan menghasilkan sistem baru yang lebih baik.

-hk- 36

-hk- 37

Activities

• The project starts with• a small set of requirements and• Develop these requirements and produce a prototype of the application

• For each iteration a risk analysis process is performed• At the next development iteration,

• More requirements are gathered and more functionalities are added until the product is ready production (installation and maintenance)

• The model is divided into a number of framework activities called task regions• Typically there are 3 6 regions‐• Each of the regions is populated by a set of work tasks, called a task set, that

are adapted to the characteristics of the project to be undertaken.

-hk- 38

Task Regions

• Customer communication• tasks required to establish effective communication between developer and

customer.• Planning

• tasks required to define resources, timelines, and other project related information.

• Risk analysis• tasks required to assess both technical and management risks.

• Engineering• tasks required to build one or more representations of the application.

• Construction and release• tasks required to construct, test, install, and provide user support (e.g.,

documentation and training).• Customer evaluation

• tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.

-hk- 39

Characteristics (1)

• The spiral model is• an evolutionary software process model• Combine the iterative nature of prototyping with the controlled and

systematic aspects of the linear sequential model.• It provides the potential for rapid development of incremental versions of the

software.

• Using the spiral model, software is developed in a series of incremental releases.• During early iterations, the incremental release might be a paper model or

prototype.• During later iterations, increasingly more complete versions of the

engineered system are produced.

• It is a realistic approach to develop a large scale systems and software

-hk- 40

Characteristics (2)• The positive side compare to Waterfall model

• The development can be started without completerequirements• Risk analysis provides

• a formal method to ensure the project runs well even if the requirements are changed.• Unnecessary technology/tools can be avoided before resources are wasted

• The team understands the domain better at each iteration

• Spiral model is divided into a number of framework activities, also called task regions.• Typically, there are between three and six task regions • For small projects, the number of work tasks and their formality is low. For

larger, more critical projects, each task region contains more work tasks that are defined to achieve a higher level formality.

-hk- 41

Spiral activities

• The first circuit around the spiral might result in the development ofa product specification;• Subsequent passes around the spiral might be used to develop a prototype

• Progressively more sophisticated versions of the software.

• Each pass through the planning region results in adjustments to theproject plan.• Cost and schedule are adjusted based on feedback derived from customer

evaluation.• The project manager adjusts the planned number of iterations required to complete

the software.

• The spiral model can be adapted to apply throughout the life of the computer software. An alternative view of the spiral model can be considered by examining the project entry point axis• Each cube placed along the axis can be used to represent the starting point for

different types of projects.

-hk- 42

Project entry point axis

• Starting point for different types of projects• E.g.

• Concept development project• New development project• Product enhancement project

• The new product will evolve through a number of iterations around the spiral, following the path that bounds the region that has somewhat lighter shading than the core.• In essence, the spiral, when characterized in this way, remains operative until

the software is retired.

-hk- 43

Problems

• It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable.• It demands considerable risk assessment expertise and relies on this

expertise for success.• If a major risk is not uncovered and managed, problems will undoubtedly

occur.

• The model has not been used as widely as the linear sequential or prototyping paradigms.• It will take a number of years before efficacy of this important paradigm can

be determined with absolute certainty.

-hk- 44

2.3 Component Base Development

-hk- 45

Characteristics

• Component-based Software Engineering (CBSE) merupakan pendekatan dalam mengembangan perangkat lunak yang menonjolkan sisi kegunaan-ulang (reusability) dari sebuah komponen perangkat lunak.• Fase perancangan dan implementasi pada pengembangan perangkat lunak,

diusahakan semaksimal mungkin menggunakan komponen-komponen yang sudah ada. • Salah satu slogan yang disebutkan dalam CBSE adalah “buy, do not build”

yakni sesedikit mungkin membangun dan sebanyak mungkin menggunakan komponen atau modul yang sudah ada dari hasil pengembangan sebelumnya atau dari vendor penjual.• Paradigma yang dibawa dalam CBSE adalah menyusun (composing) sistem

perangkat lunak, sebagai ganti dari memprogram (programming) perangkat lunak. • Pekerjaan utama dalam pengembangan perangkat lunak menggunakan

pendekatan CBSE adalah integrasi komponen perangkat lunak.

-hk- 46

Characteristics

• Incorporates many characteristics of Spiral model• However it composes applications using components• Components are stored in components library or repository

• The model leads to software reuse, and reusability• Reduction of 70% development cycle time• Reduction of 84% project cost• Increased productivity index of 26.2 compared to industry norm of 16.9

-hk- 48

Aktivitas pada CBSE

• Secara garis besar, pendekatan CBSE terdiri atas dua proses utama, yakni • Domain Engineering dan • Component-based Development.

-hk- 49

Domain Engineering

Domain Engineering merupakan proses dalam CBSE yang berfokus untuk menghasilkan model atau komponen yang dapat diguna-ulang (reusable). Terdapat tiga aktivitas dalam Domain Engineering, yakni:

1. Domain Analysis, bertujuan untuk menentukan fungsi dan objek, mendefinisikan taksonomi, mengidentifikasi fitur umum dan keterhubungannya, dan mendefinisikan model fungsional dan bahasa domain. Aktivitas ini akan menghasilan model domain.

2. Software Architecture Development, bertujuan untuk membangun arsitektur perangkat lunak yang dapat diguna ulang berdasarkan kebutuhan-kebutuhan pada domain tertentu. Aktivitas ini akan menghasilkan model struktural perangkat lunak.

3. Reusable Component Development, bertujuan untuk mengidentifikasi dan mengembangkan komponen-komponen pada arsitektur yang dapat diguna ulang. Aktivitas ini akan mengisi repositori komponen atau artifak yang dapat diguna ulang.

-hk- 50

Component-based Development

• CBSD merupakan proses dalam CBSE yang menggunakan hasil (model dan komponen) dari Domain Engineering untuk membangun perangkat lunak tertentu. • Dalam hal ini, pengembangan perangkat lunak akan sebisa mungkin

menggunakan komponen yang telah dihasilkan. • Apabila tidak memungkinkan untuk menggunakan komponen yang

ada, maka akan dilakukan pengembangan komponen sendiri.

-hk- 51

Aktivitas pada Component-based Development(1)

1. Software Analysis, bertujuan untuk menganalisis kebutuhan perangkat lunak yang akan dibangun.

2. Architectural Design, bertujuan untuk merancang struktur high level design dari kebutuhan yang telah dianalisis sebelumnya.

3. Component Engineering, yang terdiri atas:a. Component Development, bertujuan untuk mengembangkan komponen

yang tidak terdapat pada repositori.b. Component Qualification, bertujuan untuk memilih komponen yang

sudah terdapat pada repositori untuk digunakan.c. Component Adaptation, bertujuan untuk melakukan modifikasi

terhadap komponen yang sudah dipilih pada tahap sebelumnya agar dapat beradaptasi dengan kebutuhan perangkat lunak.

d. Component Composition, bertujaun untuk mengintegrasikan seluruh komponen, baik yang baru maupun yag dipilih dari repositori, menjadi satu perangkat lunak utuh yang sesuai dengan kebutuhan.

-hk- 52

Aktivitas pada Component-based Development(2)

4. Testing, bertujuan untuk menguji perangkat lunak yang sudah dibangun. Namun, pengujian yang dilakukan difokuskan pada integrasi komponen-komponen.

5. Component Update, bertujuan untuk memelihara perangkat lunak dengan memperbaharui komponen-komponen yang terdapat pada perangkat lunak.

-hk- 53

2.4. Formal Methods Model

• The model encompasses a set of activities that leads to formal mathematical specification of computer software.• Formal methods enable a software engineer to specify, develop, and verify a

computer based system by applying a rigorous, mathematical ‐ notation.• A variation on this approach, called cleanroom software engineering is

currently applied by some software development organizations.

-hk- 54

Advantages

• During development, they provide a mechanism for eliminating many of the problems that are difficult to overcome using other software engineering paradigms.• Ambiguity, incompleteness, and inconsistency can be discovered and

corrected more easily, not through ad hoc review but through the application of mathematical analysis.

• During design, they serve as a basis for program verification• enable the software engineer to discover and correct errors that might go

undetected.

• Thus it offers the promise of defect free software‐• Safety critical software application developers or• people who suffer severe economic hardship should software errors occur

are in favor of this model

-hk- 55

Some problems

• The development of formal models is currently quite time consuming and expensive.• Because few software developers have the necessary background to

apply formal methods, extensive training is required.• It is difficult to use the models as a communication mechanism for

technically unsophisticated customers.

-hk- 56

2.5. V Model

-hk- 57

Characteristics

• The phase of development is modeled by associating development phase to testing phase• Each phase of development is associated with specific verification or

validation

• Horizontal view represent the completeness of a software development project• Vertical view represent the level of abstraction (from high level view

towards low level view)• From actual system specification to actual code implementation• From unit testing to user acceptance test

• It is considered to be a highly discipline approach• Promotes meticulous design, development and documentation necessary to

build stable software products

-hk- 58

End.