1 / 81

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

KOM 331 3(2-3 ) – Rekayasa Perangkat Lunak. Sony Hartono Wijaya – sony@ipb.ac.id Departemen Ilmu Komputer IPB 2009. updated : 25 Februari 2009. Referensi. Sommerville I . 2004 & 2006. Software Engineering . 7 th or 8 th Edition, Addison-Wesley, Harlow, Essex,UK

alima
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related