kom 331 3 2 3 rekayasa perangkat lunak n.
Skip this Video
Loading SlideShow in 5 Seconds..
KOM 331 3(2-3 ) – Rekayasa Perangkat Lunak PowerPoint Presentation
Download Presentation
KOM 331 3(2-3 ) – Rekayasa Perangkat Lunak

Loading in 2 Seconds...

  share
play fullscreen
1 / 81
Download Presentation

KOM 331 3(2-3 ) – Rekayasa Perangkat Lunak - PowerPoint PPT Presentation

alima
117 Views
Download Presentation

KOM 331 3(2-3 ) – Rekayasa Perangkat Lunak

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. KOM 331 3(2-3) – Rekayasa Perangkat Lunak Sony Hartono Wijaya – sony@ipb.ac.id Departemen Ilmu Komputer IPB 2009 updated : 25 Februari 2009

  2. Referensi Sommerville I. 2004 & 2006. Software Engineering. 7thor 8thEdition, Addison-Wesley, Harlow, Essex,UK Pressman RS. 2005. Software Engineering. 6th Edition. McGraw-Hill Bennett S. et al. 2002. Object Oriented System Analysis and Design Using UML. McGraw-Hill

  3. Materi Kuliah dan Diskusi • www.ilkom.fmipa.ipb.ac.id/kulon • Enrollment key : rpl0809 • Username dan First Name diisi dengan nomor NRP. • Mahasiswa yang tidak memenuhi ketentuan tersebut tidak akan diterima menjadi anggota kuliah online RPL

  4. Penilaian dan Kontrak Perkuliahan • Semester Genap 2008/2009 • Kuliah : Rabu, 15.00-16.40 - RK. 14 FAC 401 A • Praktikum : Senin, 07.00-10.00 - Lab. • Penilaian : • UTS: 30% • UAS : 30% • Project, Praktikum dan Tugas: 40% (Progress 10%, Presentasi 20%) • Ujian perbaikan menyusul , maksimal 2 minggu setelah jadwal ujian yang telah ditetapkan • Toleransi keterlambatan maksimal 15menit

  5. RekayasaPerangkat Lunak (Software Engineering) Software Engineer

  6. PerbedaanRekayasaPerangkatLunakdanRekayasaSistem ? • RekayasaPerangkatLunakadalahbagiandariRekayasaSistem • Rekayasa Sistem (mis: SistemInformasi) terkaitdengansemuaaspekpengembangansistemberbasiskomputer yang meliputi : • Perangkatkeras (Hardware), • Jaringan (Netware) • Perangkatlunak (Software) • Data (dataware) • Manusia(brainware) • System engineers melibatkankegiatan Spesifikasisistem, perancanganarsitektur, integrasidan deployment

  7. Apakah Perangkat Lunak itu ? • Perangkat Lunak adalah suatu kumpulan objek-objek yang membentuk sebuah konfigurasi yang terdiri dari : • program • dokumen • data ...

  8. Apakah perangkat lunak itu ? • Perangkat lunak adalah hasil rekayasa • perangkat lunak tidak pernah usang • perangkat lunak adalah suatu yang kompleks

  9. Waktu penggunaan vs. Tingkat kegagalan

  10. Biaya perubahan

  11. Aplikasi Perangkat Lunak • Perangkat Lunak Sistem • Perangkat Lunak Real time • Perangkat Lunak Bisnis • Perangkat Lunak Teknik atau Sains • Embedded Software • Perangkat Lunak PC • Perangkat Lunak AI • Aplikasi Web

  12. Perangkat Lunak Sistem • Sistem Operasi • Kompilator • Perangkat Lunak Utilitas • Anti Virus

  13. Perangkat Lunak Real Time • Perangkat Lunak Pengendali Reaktor Kimia • Perangkat Lunak Pengendali Pesawat Terbang • Perangkat Lunak untuk Vehicle Tracking System • dll

  14. Perangkat Lunak Bisnis • Cash Register • Sistem Inventory • Sistem Informasi Akuntansi • Sistem Informasi Eksekutif • dll

  15. Embedded Software • Smart Card • Microwave • dll

  16. Perangkat Lunak PC • Pengolah Kata • Pengolah Data • Pesentasi • dll

  17. Perangkat Lunak AI • Sistem Pakar • Optimasi • Game • Robot

  18. Tantangan Proses PengembanganPerangkat Lunak • Bagaimana kita bisa menjamin kualitas perangkat lunak yang kita bangun ? • Bagaimana kita tetap dapat memenuhi permintaan yang meningkat tapi tetap mampu mengontrol budget ? • Bagaimana dapat menghindari keterlambatan waktu pengembangan ? • Bagaimana kita dapat dengan sukses memperkenalkan teknologi baru ?

  19. Jawabannya ???

  20. PROSES !

  21. Sekitar Proses Pengembangan Perangkat Lunak • Diperlukan untukmenjadiacuandalampengembanganperangkatlunak yang berkualitas • Diperlukan untukmempertemukankebutuhan developer dan customer • Menjadi framework untukmengelolasuatuproyekpengembanganperangkatlunak

  22. A Layered Technology Software Engineering Software Engineering tools methods process model a “quality” focus

  23. Layer 1: High Quality Remember: High quality = project timeliness Why? Less rework!

  24. What are the attributes of good quality of software? • Maintainability • Software must evolve to meet changing needs • Dependability • Software must be trustworthy • Efficiency • Software should not make wasteful use of system resources • Usability • Software must be usable by the users for which it was designed The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable

  25. How Programs Are Usually Written … This is how the problem is solved now The developers understood it in that way The requirements specification was defined like this This is how the problem was solved before. This is how the program is described by marketing department This, in fact, is what the customer wanted … ;-) That is the program after debugging

  26. The Software Process • A structured set of activities required to develop a software system • Specification • Design • Validation • Evolution • A software process model is an abstract representation of a process • It presents a description of a process from some particular perspective

  27. Model ProsesPerangkatLunak yang UmumModels • Model waterfall • tahap-tahappenentuanspesifikasiperangkatlunakbenar-benarberbedadanterpisahdengantahappengembanganperangkatlunak • Evolutionary development • Adainterleave antaratahapSpesifikasidanPengembangan • Formal systems development (example - ASML) • Model sistemberbasismatematis yang secara formal ditransformasikankedalamkode program saatimplementasi • Reuse-based development • Sistemdibangundarikomponen yang sudahada

  28. 1. Waterfall Model

  29. Tahap-tahap model Waterfall • PendefinisiandanAnalisisKebutuhan (Requirements) • PerancanganSistemdanPerangkatLunak • ImplementasidanPengujian Unit • IntegrasidanPengujianSistem • PengoperasiandanPerawatan Model inisulituntukmengakomodasiadanyaperubahanpadasaatprosessedangberlangsung

  30. Masalahpada model proses Waterfall • Inflexible partitioning of the project into distinct stages • This makes it difficult to respond to changing customer requirements • Therefore, this model is only appropriate when the requirements are well-understood Waterfall model describes a process of stepwise refinement • Based on hardware engineering models • Widely used in military and aerospace industries

  31. Why Not a Waterfall But software is different : • No fabrication step • Program code is another design level • Hence, no “commit” step – software can always be changed…! • No body of experience for design analysis (yet) • Most analysis (testing) is done on program code • Hence, problems not detected until late in the process • Waterfall model takes a static view of requirements • Ignore changing needs • Lack of user involvement once specification is written • Unrealistic separation of specification from the design • Doesn’t accommodate prototyping, reuse, etc

  32. 2. Evolutionary development • Exploratory development • Objective is to work with customers and to evolve a final system from an initial outline specification. • Should start with well-understood requirements. • The system evolves by adding new features as they are proposed by customer. • Throw-away prototyping • Objective is to understand the system requirements. Should start with poorly understood requirements • Develop “quick and dirty” system quickly; • Expose to user comment; • Refine; Until adequate system developed. • Particularly suitable where: • detailed requirements not possible; • powerful development tools (e.g. GUI) available

  33. Evolutionary development

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

  35. 3. Formal systems development • Based on the transformation of a mathematical specification through different representations to an executable program • Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification Embodied in the ‘Cleanroom’ approach (which was originally developed by IBM)to software development

  36. Formal systems development

  37. Formal transformations

  38. Formal systems development • 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 • Applicability • Critical systems especially those where a safety or security case must be made before the system is put into operation

  39. 4. Reuse-oriented development • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems • 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