Slide 1 Rifki Indra P Software Processes

Slide 2 Software Processes Coherent sets of activities for Specifying, Designing, Implementing and Testing software systems

Slide 3 Bagaimana program di buat? The requirements specification was defined like this The developers understood it in that way This is how the problem was solved before. This is how the problem is solved now That is the program after debugging This is how the program is described by marketing department This, in fact, is what the customer wanted … ;-)

Slide 4 The Software Process l Serangkaian aktifitas yang terstruktur yang dibutuhkan utk develop software Specification Design Validation/testing Evolution/lifecycle l Sebuah model proses software adalah representasi abstrak sebuah proses Ini menyajikan berbagai gambaran dari sebuah proses dari beberapa sudut pandang yang berbeda

Slide 5 Generic Software Process Models l The waterfall model Terpisah dan berbeda tiap spesifikasi kegiatan pengembangan l Evolutionary development Cara pengembangan dengan disisipkan l Formal systems development (example - ASML) Model matematis diperlukan dalam pengembangan dan di transformasikan dalam implementasi l Reuse-based development Menggunakan yang sdh ada, modifikasi lebih

Slide 6 1. THE BASIC WATERFALL MODEL Requirement specification Maintenance Testing Implementation Analysis & Design

Slide 7 A MODIFIED WATERFALL MODEL

Slide 8 Waterfall model problems l Inflexible partitioning membuat tahapan menjadi lama l This makes it difficult to respond to changing customer requirements l Oleh karena itu, model ini digunakan setelah kebutuhan fix di sepakati Waterfall model menggambarkan Perencanaan bertahap  Based on hardware engineering models  banyak digunakan dalam military and aerospace industries

Slide 9 Why Not a Waterfall But software is different :  No fabrication step  Kode program merupakan langkah lain proses desain  Sulit melakukan perubahan permintaan  No body of experience for design analysis (yet)  Analisis dilakukan saat coding  Sehingga masalah sulit terdeteksi dengan baik  Little aware from user/end user  Separation of specification from the design  Doesn’t accommodate prototyping, reuse, etc

Slide Evolutionary development l Evolutionary Develepoment l Tujuan adalah untuk bekerja dengan pelanggan dan untuk mengembangkan sebuah sistem akhir dari spesifikasi awal. l Harus mulai dengan persyaratan dipahami dengan baik. Sistem ini berkembang dengan menambahkan fitur baru seperti yang diusulkan oleh pelanggan.

Slide 11 Evolutionary development

Slide Evolutionary Models: Prototyping communication

Slide 13 Evolutionary development l Problems Lack of process visibility Systems are often poorly structured Special skills (e.g. in languages for rapid prototyping) may be required l Applicability For small or medium-size systems For parts of large systems (e.g. the user interface) For short-lifetime systems

Slide Formal systems development l Based on the transformation of a mathematical specification melalui representasi yang berbeda untuk suatu program dieksekusi l Transformations are ‘correctness-preserving’ sehingga mudah untuk menunjukkan bahwa program ini sesuai dengan spesifikasinya

Slide 15 Formal systems development

Slide 16 Formal transformations

Slide 17 Formal systems development l Problems Need for specialised skills and training to apply the technique Difficult to formally specify some aspects of the system such as the user interface

Slide Reuse-oriented development l Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems l Process stages Component analysis Requirements modification System design with reuse Development and integration This approach is becoming more important but still limited experience with it

Slide 19 Reuse-oriented development

Slide 20 I Software specification l The process of establishing what services are required and the constraints on the system’s operation and development

Slide 21 II. Software design and implementation The process of converting the system specification into an executable system l Software design Design a software structure that realises the specification l Implementation Translate this structure into an executable program

Slide 22 III The testing process

Slide 23 Testing stages l Unit testing Individual components are tested l Module testing Related collections of dependent components are tested l Sub-system testing Modules are integrated into sub-systems and tested. The focus here should be on interface testing l System testing Testing of the system as a whole. Testing of emergent properties l Acceptance testing Testing with customer data to check that it is acceptable

Slide 24 Testing phases

Slide 25 IV Software evolution Software adalah fleksibel, bisa di ubah, tdk lapuk Sebagai persyaratan perubahan melalui kondisi bisnis yang berubah, perangkat lunak yang mendukung bisnis juga harus berkembang dan berubah

Slide 26 System evolution

Slide 27 Automated process support (CASE) l Computer-aided software engineering (CASE) is software to support software development and evolution processes l Activity automation Graphical editors for system model development Data dictionary to manage design entities Graphical UI builder for user interface construction Debuggers to support program fault finding Automated translators to generate new versions of a program

Slide 28 Case technology Case tools telah membawa perbaikan yang signifikan dalam proses perangkat lunak meskipun bukan urutan besarnya perbaikan yang pernah diprediksi Rekayasa perangkat lunak memerlukan pemikiran kreatif, hal ini tidak automatable Rekayasa perangkat lunak adalah kegiatan tim untuk proyek-proyek besar, banyak waktu yang dihabiskan dalam interaksi tim. Case tools tidak benar-benar mendukung

Slide 29 CASE classification Klasifikasi membantu kita memahami berbagai jenis alat CASE dan dukungan mereka untuk kegiatan proses Perspektif fungsional Alat-alat yang diklasifikasikan menurut fungsi tertentu mereka Perspektif proses Alat diklasifikasikan menurut kegiatan proses yang didukung Perspektif integrasi Alat-alat yang diklasifikasikan menurut organisasi mereka menjadi unit-unit yang terintegrasi

Slide 30 Functional tool classification

Activity-based classification

Slide 32 CASE integration l Tools Mendukung tugas-tugas proses individu seperti memeriksa konsistensi desain, mengedit teks, dll l Workbenches Mendukung fase proses seperti spesifikasi atau desain, Biasanya mencakup sejumlah alat yang terintegrasi l Environments Mendukung semua atau sebagian besar dari proses perangkat lunak. Biasanya mencakup beberapa workbenches terintegrasi

Slide 33 Tools, workbenches, environments

Slide 34 Key points l Proses perangkat lunak adalah kegiatan yang terlibat dalam memproduksi dan berkembang sistem perangkat lunak. Mereka direpresentasikan dalam model proses perangkat lunak l Kegiatan umum spesifikasi, desain dan implementasi, validasi dan evolusi l Model proses generik menggambarkan organisasi proses perangkat lunak l Model proses iteratif menggambarkan proses software sebagai siklus kegiatan

Slide 35 Key points l Engineering adalah proses pengembangan spesifikasi perangkat lunak l Desain dan implementasi proses mengubah spesifikasi untuk sebuah program dieksekusi l Validasi melibatkan pemeriksaan bahwa sistem tersebut memenuhi spesifikasi dan kebutuhan pengguna l Evolusi berkaitan dengan memodifikasi sistem setelah digunakan l Teknologi CASE TOOLS mendukung kegiatan proses perangkat lunak