2. software metodologi 1

8/10/2019 2. Software Metodologi 1

1/57

Software MetodologiHendra Komara, ST.

-hk- 1


2/57

Objective

Mampu memahami software development metodologi, teknik dankakas dari Konvensional sampai Agile

-hk- 2


3/57

1. Model Proses konvensiaonal

Waterfall Model

Top Down Model

Buttom Up Model

Hybrid Model

Prototyping Model

Rapid application development (RAD)

-hk- 3


4/57

1.1. Waterfall Model

-hk- 4

Requirement

Analysis

Design

Implementation

Testing

Deployment

Maintenance


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


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


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


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


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


11/57

1.5. Prototyping Model

-hk- 11


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


13/57


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


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


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


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


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


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


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


21/57

-hk- 21


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


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


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


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


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


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


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


29/57

2.1 Incremental Model

-hk- 29


30/57


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


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


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


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


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


36/57

-hk- 36


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


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


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


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


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


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


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


44/57

2.3 Component Base Development

-hk- 44


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


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


47/57


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


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


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


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


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


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


54/57


55/57

2.5. V Model

-hk- 56


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


57/57

2. software metodologi 1

Documents