2. Software Metodologi 1
-
Upload
albaragista -
Category
Documents
-
view
214 -
download
0
Transcript of 2. Software Metodologi 1
-
8/10/2019 2. Software Metodologi 1
1/57
Software MetodologiHendra Komara, ST.
-hk- 1
-
8/10/2019 2. Software Metodologi 1
2/57
Objective
Mampu memahami software development metodologi, teknik dankakas dari Konvensional sampai Agile
-hk- 2
-
8/10/2019 2. Software Metodologi 1
3/57
1. Model Proses konvensiaonal
Waterfall Model
Top Down Model
Buttom Up Model
Hybrid Model
Prototyping Model
Rapid application development (RAD)
-hk- 3
-
8/10/2019 2. Software Metodologi 1
4/57
1.1. Waterfall Model
-hk- 4
Requirement
Analysis
Design
Implementation
Testing
Deployment
Maintenance
-
8/10/2019 2. Software Metodologi 1
5/57
Characteristics
Sequential, proses dilakukan step by step dari requirement gatheringsampai maintenance stage.
Waterfall model is suitable for
Systems that have welldefined and understood requirements are a good fitfor the Waterfall Model.
-hk- 5
-
8/10/2019 2. Software Metodologi 1
6/57
Problems Requirements are almost always changed. There is no formal way to adopt these
changes.
Changes cause confusing to the project teams, sometimes the requirement thatis stated in the beginning may become obsolete when the code goes toproduction
Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so indirectly.
The linear sequential model requires this and has difficulty accommodating the
natural uncertainty that exists at the beginning of many projects. The customer must have patience. A working version of the program(s) will not be
available until late in the project timespan.
It might not be a good model for a complex system which that takes more than fewmonths to complete
Some project team members must wait for other members of the team to completedependent tasks (blocking state).
In fact, the time spent waiting can exceed the time spent on productive work!
The blocking state tends to be more prevalent at the beginning and end of a linearsequential process.
-hk- 6
-
8/10/2019 2. Software Metodologi 1
7/57
1.2. Top Down modeL
Popularized by IBM in the 1970s
Use the Waterfall model
Procedures
Highlevel requirements are documented, and programs are built to meetthese requirements.
Then, the next level is designed and built.
A good way to picture the Topdown model is to think of amenudriven application.
The top level menu items would be designed and coded, and theneach sublevel would be added after the top level was finished. Eachmenu item represents a subsystem of the total application
-hk- 7
-
8/10/2019 2. Software Metodologi 1
8/57
Advantages/disadvantages
The Top down model is a good fit
when the application is a new one and
there is no existing functionality that can be incorporated into the newsystem.
A major problem with the Top down model is that:
real system functionality cannot be added and tested until late in thedevelopment process.
If problems are not detected early in the project, they can be costly to
remedy later.
-hk- 8
-
8/10/2019 2. Software Metodologi 1
9/57
1.3. Bottom Up Model
Characteristics:
the lowest level of functionality is designed and programmed first,
all the pieces are integrated together into the finished application in the end.
generally, the most complex components are developed and tested first.
encourages the development and use of reusable software components that can
be used multiple times across many software development projects.
The disadvantage of the Bottomup model is
an extreme amount of coordination is required to be sure that the individualsoftware components work together correctly in the finished system.
Few systems are developed purely from the Bottomup model.
-hk- 9
-
8/10/2019 2. Software Metodologi 1
10/57
1.4. Hybrid Model Combines top down/bottom up model
The design team primarily works top down, but
The development team identifies two types of lower level components to workon at the same time as the highlevel components.
The first type of lowlevel component would be existing software modules from other projects that can be reused in the new project.
the design team primarily works top down, but the development team identifies two typesof lower level components to work on at the same time as the high level components.
The first type of lowlevel component would be existing software modules from other
projects that can be reused in the new project. The other type of lowlevel component that would be developed early in the project would
be software components with a high risk of failure.
This approach allows the development team to make changes to thesystem early in the project if problems occur with the high riskcomponents.
A new data access technique the team has not used before or acomponent that might require high amounts of CPU processing time isan example of a high risk lowlevel component.
In reality, many of the SDLC models are a variation of the Hybrid Model.
The Spiral Model is an example discussed previously.
-hk- 10
-
8/10/2019 2. Software Metodologi 1
11/57
1.5. Prototyping Model
-hk- 11
-
8/10/2019 2. Software Metodologi 1
12/57
Prototyping Model
Prototyping adalah proses pembuatan model sederhana softwareyang mengijinkan pengguna memiliki gambaran dasar tentangprogram serta melakukan pengujian awal.
Prototyping memberikan fasilitas bagi pengembang dan pemakai
untuk saling berinteraksi selama proses pembuatan, sehinggapengembang dapat dengan mudah memodelkan perangkat lunakyang akan dibuat.
-hk- 12
-
8/10/2019 2. Software Metodologi 1
13/57
-
8/10/2019 2. Software Metodologi 1
14/57
Phase Prototyping
1. Pengumpulan kebutuhan: developerdan klien bertemu danmenentukan tujuan umum, kebutuhan yang diketahui dangambaran bagian-bagian yang akan dibutuhkan berikutnya;
2. Perancangan: perancangan dilakukan cepat dan rancangan
mewakili semua aspek software yang diketahui, dan rancangan inimenjadi dasar pembuatanprototype.
3. Evaluasiprototype: klien mengevaluasi prototype yang dibuat dandigunakan untuk memperjelas kebutuhan software.
-hk- 14
-
8/10/2019 2. Software Metodologi 1
15/57
Pendekatan Protyping
1. Throw-Away
Prototype dibuat dan dites. Pengalaman yang diperoleh dari pembuatanprototype digunakan untuk membuat produk akhir (final), kemudianprototype tersebut dibuang (tak dipakai).
2. Incremental Produk finalnya dibuat sebagai komponen-komponen yang terpisah.
Desain produk finalnya secara keseluruhan haya ada satu tetapi dibagidalam komonen-komponen lebih kecil yang terpisah (independent).
3. Evolutionary
Pada metode ini, prototipenya tidak dibuang tetapi digunakan untukiterasi desain berikutnya. Dalam hal ini, sistem atau produk yangsebenarnya dipandang sebagai evolusi dari versi awal yang sangatterbatas menuju produk final atau produk akhir.
-hk- 15
-
8/10/2019 2. Software Metodologi 1
16/57
Keunggulan Protyping
1. Adanya komunikasi yang baik antara pengembang dan pelanggan.
2. Pengembang dapat bekerja lebih baik dalam menentukankebutuhan pelanggan.
3. Pelanggan berperan aktif dalam pengembangan system.
4. Lebih menghemat waktu dalam pengembangan system.
5. Penerapan menjadi lebih mudah karena pemakai mengetahui apayang diharapkannya
-hk- 16
-
8/10/2019 2. Software Metodologi 1
17/57
Kelemahan Protyping
1. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunakyang ada belum mencantumkan kualitas perangkat lunak secarakeseluruhan dan juga belum memikirkan kemampuan pemeliharaanuntuk jangka waktu lama.
2. Pengembang biasanya ingin cepat menyelesaikan proyek. Sehinggamenggunakan algoritma dan bahasa pemrograman yang sederhana
untuk membuatprototyping lebih cepat selesai tanpa memikirkan lebihlanjut bahwa program tersebut hanya merupakan blue printdari sistem .
3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidakmencerminkan teknik perancangan yang baik.
4. Sulitnya menentukan berapa kali harus bertemu dengan customer
5. Proyek bisa dijalankan tanpa batasan waktu yang jelas
6. Harus mengatasi konflik antara developerdan customer7. Mengukur tahapan pembuatan software tanpa batasan yang jelas
8. Permintaan yang berlebihan dari customerbisa muncul
9. Customer tidak peduli terhadap proyek software
-hk- 17
-
8/10/2019 2. Software Metodologi 1
18/57
1. 6. Rapid Application Development(RAD)
Rapid application development(RAD) adalah model proses pembangunanperangkat 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 tujuanmenetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan.
Working modeldigunakan kadang-kadang saja sebagai basis desain dan
implementasi sistem final. Model RAD mengadopsi model waterfalldan pembangunan dalam waktu
singkat (versi High Speed dari model Waterfall)
-hk- 18
-
8/10/2019 2. Software Metodologi 1
19/57
Rapid application development (RAD)
RAD dapat diterapkan jika kebutuhan telah lengkap dan jelas sertadipahami dengan baik,
Waktu yang dibutuhkan untuk menyelesaikan secara lengkapperangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari.
Model RAD hampir sama dengan model waterfall, bedanya sikluspengembangan yang ditempuh model ini sangat pendek denganpenerapan teknik yang cepat.
-hk- 19
-
8/10/2019 2. Software Metodologi 1
20/57
Untuk mendapat kecepatan, RADMenerapkan Prinsip-prinsip berikut:
Component based construction ( pemrograman berbasis komponenbukan prosedural).
Penekanan pada penggunaan ulang (reuse) komponen perangkatlunak yang telah ada.
Pembangkitan kode program otomatis/semi otomatis.
Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapatim dalam waktu yang hampir bersamaan dalam waktu yang sudahditentukan
Model ini melibatkan multiple team (banyak tim), tiap timmenyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknyatim tergantung dari area dan kompleksitasnya sistem yang dibangun.
-hk- 20
-
8/10/2019 2. Software Metodologi 1
21/57
-hk- 21
-
8/10/2019 2. Software Metodologi 1
22/57
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. Gambaranpemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkankembali sebuah objek data.
-hk- 22
-
8/10/2019 2. Software Metodologi 1
23/57
Phases in RAD (2)
4. Application generation.
Menciptakan perangkat lunak dengan menggunakan bahasa pemrogramangenerasi ketiga yang konvensional,
Metode pengembangan perangkat lunak RAD lebih banyak memproses kerjauntuk memakai lagi komponen program yang telah ada atau menciptakankomponen yang bisa reuse.
Pada semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasikontruksi PL.
5. Testing and turnover.
proses metode pengembangan perangkat lunak RAD menekankan pada
reuse, banyak komponen yang telah diuji. Hal ini mengurangi keseluruhanwaktu pengujian. Tapi komponen baru harus diuji
-hk- 23
-
8/10/2019 2. Software Metodologi 1
24/57
Kelemahan RAD
1. Untuk proyek dengan skala besar, metode pengembanganperangkat lunak RAD membutuhkan sumber daya manusia yangcukup untuk membentuk sejumlah tim RAD yang baik.
2. Metode pengembangan perangkat lunak RAD membutuhkan
pengembang dan pemakai yang mempunyai komitmen dalamaktivitas rapid-fire untuk melaksanakan aktivitas melengkapisistem dalam kerangka waktu yang singkat. Jika komitmentersebut tidak ada, proyek RAD gagal.
3. Tidak semua aplikasi sesuai untuk metode pengembangan
perangkat lunak RAD bila sistem tidak dapat dimodulkan denganteratur, pembangunan komponen penting pada RAD akan menjadisangat problematic. RAD menjadi tidak sesuai jika risiko teknisnyatinggi.
-hk- 24
-
8/10/2019 2. Software Metodologi 1
25/57
Kelebihan RAD
1. Hasil pengembangan bisa lebih cepat dibandingkan SDLC lainnya
2. Memerlukan biaya yang lebih sedikit
3. Mementingkan dari segi bisnis dan teknik
4. Berkonsentrasi pada sudut pandang user5. Menyediakan kemungkinan perubahan secara cepat sesuai
permintaan user
6. Menghasilkan jarak kesesuaian yang kecil antara kebutuhan userdan spesifikasi sistem
7. Waktu, biaya, dan effort minimal
-hk- 25
-
8/10/2019 2. Software Metodologi 1
26/57
Kondisi sesuai yang dapatditerapkan model RAD
1. Proyek dengan skala kecil sampai medium dengan waktu pendek.
2. Fokus pada lingkup tertentu, misalnya pada objek bisnis yangtelah didefinisikan dengan baik
3. Bukan aplikasi dengan komputasi yang kompleks
4. User tahu pasti area yang harus dimiliki aplikasi
5. Manajemen memiliki komitmen terhadap keterlibatan user
6. Spesifikasi kebutuhan sudah benar-benar diketahui
7. Pendefinisian spesifikasi yang tidak perlu waktu lama
8. Anggota tim memiliki keahlian yang baik
9. Komposisi tim stabil
10. Ada kontrol proyek yang efektif
-hk- 26
-
8/10/2019 2. Software Metodologi 1
27/57
Kondisi tidak sesuai saat diterapkanmodel RAD
1. Proyek yang terlalu besar dan kompleks
2. Proyek yang bersifat aplikasi real-time atau menangani hal-halyang kritis
3. Sistem dengan komputasi tinggi
4. Lingkup dan objek bisnis proyek belum jelas
5. Pengumpulan spesifikasi kebutuhan membutuhkan waktu lama
6. Banyak orang yang harus terlibat dalam proyek
7. Membutuhkan lingkup daerah yang luas
8. Tim proyek besar dengan koordinasi tinggi
9. Komiten pihak manajemen dengan user rendah
10. Banyak teknologi baru digunakan untuk membangun aplikasi
-hk- 27
-
8/10/2019 2. Software Metodologi 1
28/57
2. Evolutionary software ModelProsess
Software evolves over a period of time Changes of requirements drive the evolution
Prototype is introduced to gain more understanding between a customer anda developer, thus it only assists both parties
The evolutionary nature is not considered in classic developmentparadigms.
Evolutionary models are iterative. They are characterized in a mannerthat enables software engineers to develop increasingly morecomplete versions of the software.
Incremental model
Spiral model Component Based Development (CBD) Model
Formal Methods Model
V Model
-hk- 28
-
8/10/2019 2. Software Metodologi 1
29/57
2.1 Incremental Model
-hk- 29
-
8/10/2019 2. Software Metodologi 1
30/57
-
8/10/2019 2. Software Metodologi 1
31/57
Characteristics (1)
The incremental model combines elements of the linear sequentialmodel (applied repetitively) with the iterative philosophy ofprototyping.
The incremental model applies linear sequences in a staggered fashion astime progresses.
Each linear sequence produces a deliverable increment of the software
For example, wordprocessing software developed using the incremental paradigmmight 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 advancedpage layout capability in the fourth increment.
It should be noted that the process flow for any increment can incorporatethe prototyping paradigm.
-hk- 31
-
8/10/2019 2. Software Metodologi 1
32/57
Characteristics (2)
When an incremental model is used, the first increment is often acore product.
basic requirements are addressed, but many supplementary features (someknown, others unknown) remain undelivered.
The core product is used by the customer (or undergoes detailedreview).
As a result of use and/or evaluation, a plan is developed for the nextincrement.
The plan addresses the modification of the core product to better meet theneeds 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- 32
-
8/10/2019 2. Software Metodologi 1
33/57
Characteristics (3)
The incremental process model is iterative in nature.
But unlike prototyping, the incremental model focuses on the delivery of anoperational product with each increment.
Early increments are stripped down versions of the final product, but they doprovide capability that serves the user and also provide a platform for evaluationby the user.
Incremental development is particularly useful when staffing is
unavailable for a complete implementation by the business deadlinethat 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 thenext 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 enablingpartial functionality to be delivered to endusers withoutinordinate delay.
-hk- 33
-
8/10/2019 2. Software Metodologi 1
34/57
2.2 Spiral Model
Model spiral dikembangan berdasarkan dari penyempurnaanwaterfall model dan merangkai sifat iteratif dari model prototipedimana cara kontrol dan aspek sistematis berasal dari modelsekuensial linear.
Model spiral memungkinkan untuk melakukan perubahan, tambahanserta perbaikan setiap rilis produk yang baru.
Model spiral umumnya banyak digunakan untuk data yang besar, danmodel yang rumit, model ini juga membantu mengelola resiko danketidakpastian dengan memungkinkan beberapa poin keputusan dan
secara eksplisit menjelaskan bahwa tidak semua aktivitas dapatdiketahui sebelum aktivitas berikutnya dimulai
-hk- 34
-
8/10/2019 2. Software Metodologi 1
35/57
Spiral Model
Model spiral juga secara eksplisit termasuk dalam manajemen resikodalam pengembangan perangkat lunak. Dengan mengidentifikasiresiko utama baik secara teknis dan manajerial, dan dapatmenentukan bagaimana mengurangi resiko dalam menjaga prosespengembangan perangkat lunak dibawah kontrol.
Model spiral mengacu pada konsep perbaikan terus menerusterhadap produk inti dengan menggunakan banyak fase didasarkanpada urutan yang sama, dipisahkan oleh perencanaan, penilaianresiko, dan pembangunan prototipe dan simulasi.
Model spiral konsisten untuk membuat transisi yang tertib untukkegiatan pemeliharaan.
Model spiral memungkinkan keterlibatan pengguna awal (pimpinanproyek yang lama) dalam upaya pengembangan sistem, sehinggadiharapkan menghasilkan sistem baru yang lebih baik.
-hk- 35
-
8/10/2019 2. Software Metodologi 1
36/57
-hk- 36
-
8/10/2019 2. Software Metodologi 1
37/57
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 untilthe product is ready production (installation and maintenance)
The model is divided into a number of framework activities calledtask regions
Typically there are 36 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- 37
-
8/10/2019 2. Software Metodologi 1
38/57
Task Regions
Customer communication
tasks required to establish effective communication between developer andcustomer.
Planning
tasks required to define resources, timelines, and other project relatedinformation.
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 softwarerepresentations created during the engineering stage and implemented duringthe installation stage.
-hk- 38
-
8/10/2019 2. Software Metodologi 1
39/57
Characteristics(1)
The spiral model is
an evolutionary software process model
Combine the iterative nature of prototyping with the controlled andsystematic aspects of the linear sequential model.
It provides the potential for rapid development of incremental versions ofthe software.
Using the spiral model, software is developed in a series ofincremental releases.
During early iterations, the incremental release might be a paper model orprototype.
During later iterations, increasingly more complete versions of theengineered system are produced.
It is a realistic approach to develop a large scale systems andsoftware
-hk- 39
-
8/10/2019 2. Software Metodologi 1
40/57
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. Forlarger, more critical projects, each task region contains more work tasks thatare defined to achieve a higher level formality.
-hk- 40
-
8/10/2019 2. Software Metodologi 1
41/57
Spiral activities
The first circuit around the spiral might result in the development ofaproduct 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 theprojectplan.
Cost and schedule are adjusted based on feedback derived from customerevaluation.
The project manager adjusts the planned number of iterations required tocomplete the software.
The spiral model can be adapted to apply throughout the life of thecomputer software. An alternative view of the spiral model can beconsidered by examining theproject entry point axis
Each cube placed along the axis can be used to represent the starting point fordifferent types of projects.
-hk- 41
-
8/10/2019 2. Software Metodologi 1
42/57
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 aroundthe spiral, following the path that bounds the region that hassomewhat lighter shading than the core.
In essence, the spiral, when characterized in this way, remains operative untilthe software is retired.
-hk- 42
-
8/10/2019 2. Software Metodologi 1
43/57
Problems
It may be difficult to convince customers (particularly in contractsituations) that the evolutionary approach is controllable.
It demands considerable risk assessment expertise and relies on thisexpertise for success.
If a major risk is not uncovered and managed, problems will undoubtedlyoccur.
The model has not been used as widely as the linear sequential orprototyping paradigms.
It will take a number of years before efficacy of this important paradigm canbe determined with absolute certainty.
-hk- 43
-
8/10/2019 2. Software Metodologi 1
44/57
2.3 Component Base Development
-hk- 44
-
8/10/2019 2. Software Metodologi 1
45/57
Characteristics
Component-based Software Engineering (CBSE) merupakan pendekatandalam 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 menggunakankomponen atau modul yang sudah ada dari hasil pengembangansebelumnya atau dari vendorpenjual.
Paradigma yang dibawa dalam CBSE adalah menyusun (composing) sistem
perangkat lunak, sebagai ganti dari memprogram (programming) perangkatlunak.
Pekerjaan utama dalam pengembangan perangkat lunak menggunakanpendekatan CBSE adalah integrasi komponen perangkat lunak.
-hk- 45
-
8/10/2019 2. Software Metodologi 1
46/57
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- 46
-
8/10/2019 2. Software Metodologi 1
47/57
-
8/10/2019 2. Software Metodologi 1
48/57
Domain Engineering
Domain Engineering merupakan proses dalam CBSE yang berfokusuntuk 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 danketerhubungannya, dan mendefinisikan model fungsional dan bahasadomain. Aktivitas ini akan menghasilan model domain.
2. Software Architecture Development, bertujuan untuk membangunarsitektur perangkat lunak yang dapat diguna ulang berdasarkankebutuhan-kebutuhan pada domain tertentu. Aktivitas ini akanmenghasilkan model struktural perangkat lunak.
3. Reusable Component Development, bertujuan untuk mengidentifikasidan mengembangkan komponen-komponen pada arsitektur yang dapatdiguna ulang. Aktivitas ini akan mengisi repositori komponen atauartifak yang dapat diguna ulang.
-hk- 49
-
8/10/2019 2. Software Metodologi 1
49/57
Component-based
Development CBSD merupakan proses dalam CBSE yang menggunakan hasil (model
dan komponen) dari Domain Engineering untuk membangunperangkat 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- 50
-
8/10/2019 2. Software Metodologi 1
50/57
Aktivitas pada Component-basedDevelopment(1)
1. Software Analysis, bertujuan untuk menganalisis kebutuhanperangkat lunak yang akan dibangun.
2. Architectural Design, bertujuan untuk merancang struktur highlevel design dari kebutuhan yang telah dianalisis sebelumnya.
3. Component Engineering, yang terdiri atas:a. Component Development, bertujuan untuk mengembangkan komponenyang tidak terdapat pada repositori.
b. Component Qualification, bertujuan untuk memilih komponen yangsudah terdapat pada repositori untuk digunakan.
c. Component Adaptation, bertujuan untuk melakukan modifikasiterhadap 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, menjadisatu perangkat lunak utuh yang sesuai dengan kebutuhan.
-hk- 51
-
8/10/2019 2. Software Metodologi 1
51/57
Aktivitas pada Component-basedDevelopment(2)
4. Test ing, bertujuan untuk menguji perangkat lunak yangsudah dibangun. Namun, pengujian yang dilakukandifokuskan pada integrasi komponen-komponen.
5. Component Update, bertujuan untuk memelihara perangkat
lunak dengan memperbaharui komponen-komponen yangterdapat pada perangkat lunak.
-hk- 52
-
8/10/2019 2. Software Metodologi 1
52/57
2.4. Formal Methods Model
The model encompasses a set of activities that leads to formalmathematical specification of computer software.
Formal methods enable a software engineer to specify, develop, and verify acomputerbased system by applying a rigorous, mathematical notation.
A variation on this approach, called cleanroom software engineering iscurrently applied by some software development organizations.
-hk- 53
-
8/10/2019 2. Software Metodologi 1
53/57
Advantages
During development, they provide a mechanism for eliminating manyof the problems that are difficult to overcome using other softwareengineering paradigms.
Ambiguity, incompleteness, and inconsistency can be discovered andcorrected more easily, not through ad hoc review but through the applicationof mathematical analysis.
During design, they serve as a basis for program verification
enable the software engineer to discover and correct errors that might goundetected.
Thus it offers the promise of defectfree software
Safety critical software application developers or
people who suffer severe economic hardship should software errors occurare in favor of this model
-hk- 54
-
8/10/2019 2. Software Metodologi 1
54/57
-
8/10/2019 2. Software Metodologi 1
55/57
2.5. V Model
-hk- 56
-
8/10/2019 2. Software Metodologi 1
56/57
Characteristics
The phase of development is modeled by associating developmentphase to testing phase
Each phase of development is associated with specific verification orvalidation
Horizontal view represent the completeness of a softwaredevelopment project
Vertical view represent the level of abstraction (from high level viewtowards 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 tobuild stable software products
-hk- 57
-
8/10/2019 2. Software Metodologi 1
57/57