PEMBAHASAN



A. Perangkat Lunak

Perangkat Lunak (Software) tidak sama dengan program komputer. Perangkat lunak tidak hanya mencakup program, tetapi juga semua dokumentasi dan konfigurasi data yang berhubungan, yang diperlukan untuk membuat agar program beroperasi dengan benar. Software / Perangkat Lunak (PL) adalah instruksi (program komputer) yang ketika dijalankan menyediakan fungsi dan tampilan yang diinginkan, struktur data yang memberi kesempatam program untuk memanipulasi informasi dan dokumen yang mendeskripsikan operasi dan penggunaan program.

PL tidak sama dengan program (komputer), karena PL terdiri dari: program, dokumen dan data. PL merepresentasikan masalah di dunia nyata.


Sistem Perangkat Lunak terdiri dari :

Sejumlah program yg terpisah
File-file konfigurasi
Dokumentasi sistem
Dokumentasi User

Dua tipe produk perangkat lunak :

Produk Generik à Sistem stand-alone standar yg diproduksi oleh organisasi pengembang dan dijual ke pasar terbuka ke siapapun yg membelinya. Biasa disebut sebagai software shrink-wrapped.
Contoh : pengolah kata (word processor).

Pada produk generik, organisasi yang mengembangkan perangkat lunak mengontrol spesifikasi perangkat lunak.

Proses Generik vs Proses RPL

Generik – building any product

- Specification – menentukan requirement dan batasan (constraint)

- Design - Produce a paper model of the system

- Manufacture – membangun sistem (produk)

- Test – menguji apakah sistem sesuai dengan spesifikasi

- Install - deliver system to customer and ensure it is operational

- Maintain – memperbaiki kerusakan jika ditemukan

Produk pesanan (yang disesuaikan) à Sistem yg dipesan oleh pelanggan tertentu. Dikembangkan khusus bagi pelanggan oleh kontraktor perangkat lunak. Contoh : Sistem untuk mendukung proses bisnis tertentu dan sistem kontrol lalu lintas udara.
Pada produk pesanan, spesifikasi biasanya dikembangkan dan dikontrol oleh organisasi yang membeli perangkat lunak tersebut.

Software (permasalahan)

- Umumnya, spesifikasi tidak lengkap / anomalous

- Perbedaan yang kabur antara specification, design dan manufacture

- Tidak ada realisasi secara fisik untuk testing

- Software does not wear out - maintenance bukan berarti mengganti komponen yang rusak.

Model Proses Perangkat Lunak

Merupakan deskripsi yang disederhanakan dari proses perangkat lunak di presentasikan dengan sudut pandang tertentu.
Bisa mencakup kegiatan yang merupakan bagian dari proses perangkat lunak, produk perangkat lunak, dan peran orang yang terlibat pada rekayasa perangkat lunak (Perekayasa PL).

Contoh Jenis Model Proses PL

Model aliran kerja (workflow) à menunjukkan kegiatan pada proses bersama dengan input, output, dan ketergantungannya. Merepresentasikan pekerjaan manusia.
Model aliran data (data flow) à merepresentasikan proses sebagai suatu set kegiatan yang melakukan transformasi data. Menunjukkan bagaimana input ke proses, misalnya spesifikasi ditransformasi menjadi output, misalnya menjadi desain.
Model peran/aksi à merepresentasikan peran orang yang terlibat pada PL dan kegiatan yg menjadi tanggung jawab mereka.

Model atau paradigma umum pada proses PL

Model air terjun (waterfall) à Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.
Pengembangan evolusioner à Pendekatan ini berhimpitan dengan kegiatan spesifikasi, pengembangan, dan validasi. Sistem awal dikembangkan dengan cepat dari spesifikasi abstrak. Sistem ini kemudian di perbaiki dengan masukan dari pelanggan untuk menghasilkan sistem yang memuaskan kebutuhan pelanggan.
Pengembangan Sistem Formal à Pendekatan ini menghasilkan suatu sistem matematis yang formal dan mentransformasikan spesifikasi ini, dengan menggunakan metode matematik menjadi sebuah program.
Pengembangan berdasarkan pemakaian ulang (Reusable) à Teknik ini menganggap bahwa bagian-bagian sistem sudah ada. Proses pengembangan sistem terfokus pada pengintegrasian bagian-bagian sistem dan bukan pengembangannya dari awal.

Karakteristik Perangkat Lunak

PL adalah elemen yang logik, sehingga memiliki karakteristik yang berbeda dengan elemen fisik, yaitu:

PL dikembangkan, tidak dihasilkan
PL tidak pernah usang
Sebagian besar custom-built tidak dapat dirakit dari komponen yg sudah ada.

Atribut-atribut PL yang baik

Perangkat Lunak seharusnya memberikan user kebutuhan fungsionalitas dan kinerja yang:

1. Dapat dipelihara (Maintanability) à PL harus dapat memenuhi perubahan kebutuhan user.

2. Dapat diandalkan (Dependability) à PL harus dapat dipercaya dan tidak menyebabkan kerusakan fisik atau ekonomi jika terjadi kegagalan sistem.

3. Efisien à PL harus efisien dalam penggunaan sumber daya sistem.

4. Kemampupakaian (Usability) à PL harus dapat dipakai sesuai dengan yang direncanakan.

Evolusi Perangkat Lunak

1950

1960

1970

1980

1990

2000

The early years

•batch oriented

•limited distribution

•custom software

The second era

•multi-user

•real-time

•databases

•product software

The third era

•distributed systems

•embedded intelligence

•low-cost hardware

•consumer impact

The fourth era

•powerful desktop systems

•object technologies

•expert systems

•artificial neural networks

•parallel computing




Kategori PL

Secara umum PL dapat dikategorikan:

Software System: OS, Compiler, Driver, utilities, interaksi langsung dg h/w
Real-time Software : program yang memantau / menganalisa / mengawasi peristiwa nyata secara langsung, PL telekomunikasi
Business Software : payroll, inventory, accounting, dll
Engineering dan Scientific Software: simulasi sistem, aplikasi interaktif, CAD, dll
Embedded Software : program yang di-embedded pada peralatan dg fungsi tertentu. Kontrol pada AC, Microwave; sistem automobil digital, program pd Handphone, dll
Personal Computer Software : Pengolah kata, aplikasi grafis, multimedia, manajemen database, dll
Web-based Software : aplikasi dengan antarmuka browser
Artificial Intelligence Software : program pd robot, dll

Communications Software

a. Communications software provides

· message formatting

· error checking

· communications logs

· data security and privacy

· translation capabilities for networks

Misalnya: protokol jaringan, network operating system, mobile OS, encoder/decoder, software komunikasi, embedded software

Tahapan Pengembangan PL

Survey
Analisis
Desain
Testing
Implementasi
Dokumentasi
Pemeliharaan
B. Rekayasa Perangkat Lunak (RPL)

Paradigma RPL

Paradigma Software Engineering / Rekayasa Perangkat Lunak (RPL), muncul sejak adanya Software Crisis.
Pembangunan perangkat lunak (PL) selalu terlambat, over budget dan tidak berkualitas
Diperlukan suatu metoda yang sistematis untuk mengembangkan PL yang baik
Penggunaan PL semakin luas dan dalam berbagai bidang kehidupan, sehingga muncul paradigma yang bervariasi

Why Do Project Fails?

A 1994 Survey Found:

– 31% of Projects Canceled Before Completion

– 53% Delivered Behind Schedule or Over Cost



Sejarah RPL

Rekayasa perangkat lunak (RPL, atau dalam bahasa Inggris: Software Engineering atau SE) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat lunak dan sebagainya.

Istilah software engineering, pertama kali digunakan pada akhir tahun 1950-an dan sekitar awal 1960-an. Pada tahun 1968, NATO menyelenggarakan konferensi tentang software engineering di Jerman dan kemudian dilanjutkan pada tahun 1969. Meski penggunaan kata software engineering dalam konferensi tersebut menimbulkan debat tajam tentang aspek engineering dari pengembangan perangkat lunak, banyak pihak yang menganggap konferensi tersebutlah yang menjadi awal tumbuhnya profesi rekayasa perangkat lunak.

Rekayasa perangkat lunak telah berkembang sejak pertama kali diciptakan pada tahun 1940-an hingga kini. Fokus utama pengembangannya adalah untuk mengembangkan praktek dan teknologi untuk meningkatkan produktivitas para praktisi pengembang perangkat lunak dan kualitas aplikasi yang dapat digunakan oleh pemakai.


1965 – 1985 Krisis Perangkat Lunak

Sejarah Krisis Perangkat Lunak (Software Crisis)

Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat lunak. Banyak projek yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari projek yang melebihi anggaran, hingga kasus yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak.

Sejarah munculnya Rekayasa Perangkat Lunak sebenarnya dilatarbelakangi oleh adanya krisis perangkat lunak (software crisis) di era tahun 1960-an. Krisis perangkat lunak merupakan akibat langsung dari lahirnya komputer generasi ke 3 yang canggih, ditandai dengan penggunaan Integrated Circuit (IC) untuk komputer. Performansi hardware yang meningkat, membuat adanya kebutuhan untuk memproduksi perangkat lunak yang lebih baik. Akibatnya perangkat lunak yang dihasilkan menjadi menjadi beberapa kali lebih besar dan kompleks. Pendekatan informal yang digunakan pada waktu itu dalam pengembangan perangkat lunak, menjadi tidak cukup efektif (secara cost, waktu dan kualitas). Biaya hardware mulai jatuh dan biaya perangkat lunak menjadi naik cepat. Karena itulah muncul pemikiran untuk menggunakan pendekatan engineering yang lebih pasti, efektif, standard dan terukur dalam pengembangan perangkat lunak.


1985 - kini: Tidak Ada Senjata Pamungkas

Selama bertahun-tahun, para peneliti memfokuskan usahanya untuk menemukan teknik jitu untuk memecahkan masalah krisis perangkat lunak.

Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi object, perangkat pembantu pengembangan perangkat lunak (CASE tools), berbagai standar, UML hingga metode formal diagung-agungkan sebagai senjata pamungkas untuk menghasilkan software yang benar, sesuai anggaran dan tepat waktu.

Pada tahun 1987, Fred Brooks menulis artikel No Silver Bullet, yang berproposisi bahwa tidak ada satu teknologi atau praktek yang sanggup mencapai 10 kali lipat perbaikan dalam produktivitas pengembangan perangkat lunak dalam tempo 10 tahun.

Sebagian berpendapat, no silver bullet berarti profesi rekayasa perangkat lunak dianggap telah gagal. Namun sebagian yang lain justru beranggapan, hal ini menandakan bahwa bidang profesi rekayasa perangkat lunak telah cukup matang, karena dalam bidang profesi lainnya pun, tidak ada teknik pamungkas yang dapat digunakan dalam berbagai kondisi.

Deskripsi RPL

Stephen R. Schach:

RPL adalah sebuah disiplin dimana dalam menghasilkan PL bebas dari kesalahan dan menggunakan anggaran secara tepat dan tepat waktu serta memuaskan keinginan pemakai

Fritz Bauer:

RPL adalah penetapan dan penggunaan prinsip rekayasa dalam rangka memperoleh PL yang dapat dipercaya dan dapat bekerja secara efisien pada mesin nyata.

IEEE 610.12

RPL adalah sebuah studi pendekatan dan aplikasi secara sistematis, disiplin pengembangan operasi dan pemeliharaan PL yang kesemuanya itu merupakan aplikasi rekayasa yang berkaitan dengan PL.

Anonim

RPL atau Software Engineering (SE) à Disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Ada 2 istilah kunci disini :

· “disiplin rekayasa” à Perekayasa membuat suatu alat bekerja. Menerapkan teori, metode, dan alat bantu yang sesuai, selain itu mereka menggunakannya dengan selektif dan selalu mencoba mencari solusi terhadap permasalahan.

· “semua aspek produksi perangkat lunak” à RPL tidak hanya berhubungan dengan proses teknis dari pengembangan perangkat lunak tetapi juga dengan kegiatan seperti Manajemen proyek PL dan pengembangan alat bantu, metode, dan teori untuk mendukung produksi PL.

Kemudian tidak boleh dilupakan bahwa secara definisi perangkat lunak tidak hanya untuk program komputer, tetapi juga termasuk dokumentasi dan konfigurasi data yang berhubungan yang diperlukan untuk membuat program beroperasi dengan benar. Dengan definisi ini otomatis keluaran (output) produksi perangkat lunak disamping program komputer juga dokumentasi lengkap berhubungan dengannya. Ini yang kadang kurang dipahami oleh pengembang, sehingga menganggap cukup memberikan program yang jalan (running program) ke pengguna (customer).

Rekayasa Perangkat Lunak bukan merupakan cabang ilmu Computer Science yang mempelajari tentang technical coding. Ini yang sering salah kaprah dipahami, sehingga pelajar, mahasiswa atau bahkan calon dosen shock ketika dihadapkan dengan buku-buku textbook Rekayasa Perangkat Lunak yang selalu tebal dengan penjelasan sangat luas tentang bagaimana perangkat lunak diproduksi, dari aspek requirement capturing, desain, arsitektur, testing, kualitas software, sampai people/cost management. Dan ini adalah suatu kesepakatan yang sudah diterima umum tentang Rekayasa Perangkat Lunak, sejak jaman Roger S Pressman menulis buku “Software Engineering: A Practitioner’s Approach”, sampai Ian Sommerville yang kemudian datang dengan buku “Software Engineering” yang sudah sampai edisi ke 7, maupun pendatang baru semacam Hans Van Vliet, Shari Lawrence Pfleeger maupun James F Peters.

Perbedaan antara RPL dengan Computer Science

· computer science berhubungan dengan teori dan metode yang mendasari sistem komputer dan perangkat lunak, sedangkan RPL berhubungan dengan praktek dalam memproduksi perangkat lunak.

Perbedaan RPL dengan Rekayasa Sistem

· Rekayasa sistem berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa sistem yang meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database pada sistem.


Tujuan RPL

Untuk membangun PL yang benar dan benar sebuah PL (Right Software andSoftware Right)
Untuk membangun PL yang tepat (correct)
Dikelola dengan baik untuk pemeliharaan kebenarannya (correctnes)

Metode-metode RPL

Pendekatan-pendekatan terstruktur terhadap pengembangan perangkat lunak mencakup model, notasi, aturan, saran pengembangan sistem (rekomendasi), dan panduan proses.

Deskripsi model sistem à Deskripsi model yang harus dikembangkan dan notasi yang digunakan untuk mendefinisikan model-model ini. Ex : model aliran data.
Aturan à Batasan yang berlaku bagi model sistem. Ex : Setiap entitas pada model sistem harus memiliki nama yang unik.
Rekomendasi à Saran dalam membentuk perancangan yang baik. Ex : Tidak ada objek yang memiliki lebih dari tujuh sub-objek yang berhubungan dengannya.
Panduan Proses à Aktifitas yang bisa diikuti untuk mengembangkan model sistem. Ex : Atribut objek harus didokumentasi sebelum mendefinisikan operasi yang berhubungan dengan objek.


Pemodelan dalam RPL

a. Definisi Software Process

Sejumlah aktivitas yang dilakukan pada tahapan awal dalam mengembangkan produk PL.

b. Definisi Software Process Model

Abstraksi ideal dari suatu proses PL


Karakteristik Proses

Understandability
Visibility
Supportability
Acceptability
Reliability
Maintainability
Rapidity


Pemodelan dalam RPL

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat proses.

Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:

Pendekatan Waterfall
Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak, uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya.

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata.

Langkah-langkah yang penting dalam model ini adalah

· Penentuan dan analisis spesifikasi

Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.

· Desain sistem dan perangkat lunak

Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan.

· Implementasi dan ujicoba unit

Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.

· Integrasi dan ujicoba sistem

Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan ke kastamer

· Operasi dan pemeliharaan

Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan.

Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan.



Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering. Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

Pengembangan secara Evolusioner
Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan maintable.

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak Terdapat 2 tipe pada model ini

a. Pemprograman evolusioner. Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.

b. Pemodelan. Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti.

Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun, pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia. Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka. Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:

· Proses tidak visibel.. Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem.

· Sistem-sistem biasanya kurang terstruktur. Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Evolusi perangkat lunak terlihat sulit dan mahal.

· Ketrampilan khusus jarang dimiliki. Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.

Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas. ( seperti model waterfall ). Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk Pengembangan sistem yang relatif kecil. Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan, tidak terlalu mahal. Pengembangan sistem yang memiliki masa hidup yang relatif singkat. Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru. Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.


Transformasi Formal
Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi.


Penggabungan sistem dengan menggunakan komponen yang dapat digunakan kembali
Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian.

The Software Life Cycle

The Cycle as a whole (try and error)

The traditional development phase





Waterfall model


Prototyping Model


Requirements

Gathering

Design

Implementation

Testing

Design

Implementation

Testing

Maintenance










Proses RPL: Analisis

Survey: wawancara, kuisoner, old-system
Requirement analysis: identifikasi kebutuhan customer/user, pengguna (operator)
Spesifikasi: membuat spesifikasi program
– Kebutuhan Sistem

– Spesifikasi Teknis Sistem -> What

– Dokumen spesifikasi sebagai basis dari kontrak




Proses RPL: Design

Concentrate on how the system will accomplish the goals.
– NB Analysis concentrates on what the proposed system should do.

Modular design
Object-oriented design

Implementation

Actual writing of programs
creation of data files, and
development of database

Testing

Eliminate errors from the software.
– Component testing

– Overall system testing

Difficult and a lot of research remains to be done.

Tantangan Kunci yang dihadapi RPL

Tantangan Warisan (Legacy) à Tantangan memelihara dan meng-update PL sedemikian sehingga biaya yg berlebihan dapat dihindari dan layanan bisnis yg penting tetap dilakukan.
Tantangan Heterogenitas à Tantangan teknik pengembangan untuk membangun perangkat lunak yang dapat diandalkan dan cukup flexibel untuk menghadapi heterogenitas yang ada.
Tantangan Pengiriman à Tantangan mempersingkat waktu kirim sistem besar dan kompleks, tanpa mengurangi kualitas sistem.