Software Engineering Romi Satria Wahono romi@romisatriawahono.net http://romisatriawahono.net +6281586220090.

Presentasi berjudul: "Software Engineering Romi Satria Wahono romi@romisatriawahono.net http://romisatriawahono.net +6281586220090."— Transcript presentasi:

1 Software Engineering Romi Satria Wahono

2 Romi Satria Wahono SD Sompok Semarang (1987) SMPN 8 Semarang (1990)
Object-Oriented Programming Romi Satria Wahono SD Sompok Semarang (1987) SMPN 8 Semarang (1990) SMA Taruna Nusantara, Magelang (1993) B.Eng, M.Eng and Ph.D in Software Engineering from Saitama University Japan ( ) Universiti Teknikal Malaysia Melaka (2014) Research Interests: Software Engineering, Intelligent Systems Founder dan Koordinator IlmuKomputer.Com Peneliti LIPI ( ) Founder dan CEO PT Brainmatics Cipta Informatika

3 Learning Design Pretest dan Posttest untuk Mengukur Kompetensi Kognifif Penyajian Materi dengan Model Minimalism berbasis Konsep Amati-Tiru-Modifikasi Latihan Secara Iteratif untuk Meningkatkan Kompetensi Kognitif dan Psikomotorik Penugasan berbasis Self-Contained Project dan Literatur Review

4 Textbooks

5 Course Contents -1- Introduction to Software Engineering
What is Software What is Software Engineering Discipline and Curriculum of Software Engineering Software Engineering Profession Profession, Ethics and Certification Software Industry and Market Internet Business Model and Trends

6 Course Contents -2- Software Engineering Process Software Construction
Software Development Life Cycle (SDLC) Software Development Methodologies Software Development Notation (UML) and Tools Object-Oriented Paradigm Software Construction Software Construction Process Estimating the Size of Software Project

7 Course Contents -3- Software Quality Assurance
The Uniqueness of Software Quality Assurance What is Software Quality Software Quality Factor Software Testing Software Engineering Research Computing Research Methodology Research Trends in Software Engineering Case Study: Developing Research Proposal in Software Engineering Field

8 Introduction to Software Engineering

9 Content What is Software What is Software Engineering
Discipline of Software Engineering

10 1. What is Software

11 The Definition of Software

12 Jenis Software (Market)
Software Generik Perangkat lunak standar yang diproduksi oleh perusahaan pengembang dan dijual pada pasar terbuka ke siapapun yang bisa membelinya (Shrink-wrapped) Software Pesanan Perangkat lunak yang dikembangkan khusus dan disesuaikan dengan kebutuhan pelanggan (Ian Sommerville, Software Engineering 9 Ed., 2012)

13 Jenis Software (Platform)
Software Sistem Software Real-Time Software Bisnis Software Teknik dan Ilmu Pengetahuan Software Tertanam (Embedded Software) Software Komputer Personal Software Kecerdasan Buatan Software Mobile (Roger Pressman, Software Engineering,: A Practitioner’s Approach 7Ed., 2009)

14 Jenis Software (Lisensi)
Proprietary Software Open Source Software

15 Open Source Software Software yang source codenya terbuka dan didistribusikan dalam suatu format lisensi yang memungkinkan pihak lain secara bebas memperbanyak dan memodifikasi source code didalamnya Hak cipta tetap ada, tapi lisensi memungkinkan orang lain bebas untuk menggunakan dan memodifikasi software tersebut Jenis lisensi open source software: GNU General Public License (GPL) Apache License BSD license MIT License Mozilla Public License

16 Proprietary Software Software yang source codenya tertutup dan didistribusikan dengan suatu format lisensi yang membatasi pihak lain untuk menggunakan, memperbanyak dan memodifikasi Lisensi proprietary software memungkinkan orang lain menggunakan software yang kita buat dengan diikuti penyerahan royalti (uang) ke pemilik hak ciptanya Shareware dan Freeware adalah proprietary software. Free for use belum tentu free for (redistribute) atau free for modify!

17 Peranan Perangkat Lunak
Menggantikan peran manusia: Dengan otomasi terhadap suatu tugas atau proses Memperkuat peran manusia: Dengan membantu manusia mengerjakan suatu tugas atau proses dengan lebih baik dan tertata

18 Peranan Perangkat Lunak
Restrukturisasi Peran Manusia: Dengan melakukan perubahan-perubahan thd sekumpulan tugas atau proses Hiburan dan Permainan: Dengan menyajikan aplikasi interaktif hiburan yang semakin dekat dengan kenyataan

19

20

21 The Uniqueness of the Software Development

22

23 If(suhu>=3) shutdown()
Bug  failure

24

25 2. What is Software Engineering

26 Definisi Disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi, desain, konstruksi, testing sampai pemeliharaan setelah digunakan

27 Mengapa Software Engineering?
Terminologi rekayasa perangkat lunak (software engineering) pertama kali digunakan pada conference ttg software crisis tahun 1968 Krisis perangkat lunak merupakan akibat langsung dari lahirnya komputer generasi ke 3 yang canggih pada waktu itu Perangkat lunak yang dihasilkan menjadi menjadi beberapa kali lebih besar dan kompleks Pendekatan informal tidak cukup efektif (cost, waktu dan kualitas) dalam pengembangan perangkat lunak Biaya hardware jatuh dan biaya perangkat lunak naik cepat

28 Generasi Komputer Generasi I (1946-1959) Generasi II (1959-1964)
Menggunakan tabung hampa ENIAC, EDSAC Generasi II ( ) Menggunakan transistor PDP-1, PDP-8, UNIVAC, IBM 70xx Generasi III ( ) Menggunakan IC IBM S360, NOVA, UNIVAC 1108 Generasi IV (1980-sekarang) Menggunakan VLSI

29 Object-Oriented Programming

30 Is it Possible? romi@romisatriawahono.net Object-Oriented Programming

31 5 Problems in the Software Development
Poor Requirements - if requirements are unclear, incomplete, too general, and not testable, there may be problems. Unrealistic Schedule - if too much work is crammed in too little time, problems are inevitable. Inadequate Testing - no one will know whether or not the software is any good until customers complain or systems crash. Featuritis - requests to add on new features after development goals are agreed on. Miscommunication - if developers don't know what's needed or customer's have erroneous expectations, problems can be expected.

32 5 Solutions in the Software Development
Solid Requirements - clear, complete, detailed, cohesive, attainable, testable requirements that are agreed to by all players. In 'agile'-type environments, continuous close coordination with customers/end-users is necessary to ensure that changing/emerging requirements are understood.

33 5 Solutions in the Software Development
Realistic Schedules - allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation; personnel should be able to complete the project without burning out.

34 5 Solutions in the Software Development
Adequate Testing - start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing. 'Early' testing could include static code analysis/testing, test-first development, unit testing by developers, built-in testing and diagnostic capabilities, automated post-build testing, etc.

35 5 Solutions in the Software Development
Stick to Initial Requirements where Feasible - be prepared to defend against excessive changes and additions once development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately reflected in related schedule changes. If possible, work closely with customers/end-users to manage expectations. In 'agile'-type environments, initial requirements may be expected to change significantly, requiring that true agile processes be in place and followed.

36 5 Solutions in the Software Development
Communication - require walkthroughs and inspections when appropriate; make extensive use of group communication tools - groupware, wiki's, bug-tracking tools and change management tools, intranet capabilities, etc.; ensure that information/documentation is available and up-to-date - preferably electronic, not paper; promote teamwork and cooperation; use protoypes and/or continuous communication with end-users if possible to clarify expectations.

37 Barriers to Requirements Elicitation
Object-Oriented Programming Barriers to Requirements Elicitation The "Yes, But" Syndrome The "Undiscovered Ruins" Syndrome The "User and the Developer" Syndrome

38 The "Yes, But" Syndrome For whatever reason, we always see two immediate, distinct, and separate reactions when the users see the system implementation for the first time. "Wow, this is so cool; we can really use this, what a neat job" and so on. "Yes, but, hmmmmm, now that I see it, what about this ... ? Wouldn't it be nice if ? Whatever happened to ?“

39 The "Yes, But" Syndrome The "Yes, But" syndrome is human nature and is an integral part of application development We should plan to avoid or significantly reduce this syndrome by applying techniques that get the "Buts" out early In so doing, we elicit the "Yes, But" response early, and we then can begin to invest the majority of our development efforts in software that has already passed the "Yes, But" test

40 The "Undiscovered Ruins" Syndrome
In many ways, the search for requirements is like a search for undiscovered ruins The more you find, the more you know remain You never really feel that you have found them all, and perhaps you never will Indeed, software development teams always struggle to determine when they are done with requirements elicitation. When have they found all the requirements or at least enough requirements?

41 The "User and the Developer" Syndrome
Communication gap between the user and the developer Users and developers are typically from different worlds, may even speak different languages, and have different backgrounds, motivations, and objectives.

42 The "User and the Developer" Syndrome
Reasons for this problem and some suggested solutions

43 Key Points Requirements elicitation is complicated by three endemic syndromes. The "Yes, But" syndrome stems from human nature and the users' inability to experience the software as they might a physical device Searching for requirements is like searching for "Undiscovered Ruins"; the more you find, the more you know remain The "User and the Developer" syndrome reflects the profound differences between these two, making communication difficult.

44 3. Discipline and Curriculum of Software Engineering

45 Perjalanan Disiplin Ilmu Software Engineering
Peter J Dennings yang memimpin task force disiplin ilmu computing memasukkan software engineering sebagai satu disiplin ilmu (Dennings, 1999) IEEE Computer Society membentuk tim khusus untuk menyusun pohon ilmu Software Engineering (Software Engineering Body of Knowledge, SWEBOK) Software Engineering termasuk nama jurusan atau fakultas yang diakui menurut IEEE Computing Curricula 2005

46 Matriks Dennings 1999 Algoritma dan Struktur Data Bahasa Pemrograman
Arsitektur Komputer Sistem Operasi dan Jaringan Software Engineering Database dan Sistim Retrieval Informasi Artificial Intelligence dan Robotik Grafik Human Computer Interaction Ilmu Komputasi Organizational Informatics BioInformatik ( Peter J. Dennings, 1999 )

47 SWEBOK 2004

48

49 IEEE Computing Curricula 2005
Computer Engineering (CE, Teknik Komputer) Computer Science (CS, Ilmu Komputer) Information Systems (IS, Sistem Informasi) Information Technology (IT, Teknologi Informasi) Software Engineering (SE, Rekayasa Perangkat Lunak)

50 IEEE Computing Curricula 2005
Computer Engineering (CE) pengembangan sistem terintegrasi(software dan hardware) Computer Engineer Computer Science (CS) konsep computing dan pengembangan software Computer Scientist Information System (IS) analisa kebutuhan dan proses bisnis serta desain sistem System Analyst Information Technology (IT) pengembangan dan maintenance infrastruktur IT Network Engineer Software Engineering (SE) pengembangan software dan pengelolaan tahapan SDLC Software Engineer

51 Target Profesi IEEE CC 2005 -1-
Computer Engineering (CE) Indonesia: Jurusan Sistem Komputer atau Teknik Komputer Target: Lulusan mampu mendesain dan mengimplementasikan sistem yang terintegrasi baik software maupun hardware Computer Science (CS) Indonesia: Jurusan Ilmu Komputer Target: Lulusan memiliki kemampuan yang cukup luas dimulai dari penguasaan teori (konsep) dan pengembangan software

52 Target Profesi IEEE CC 2005 -2-
Information System (IS) Indonesia: Jurusan Sistem Informasi  Target: Lulusan mampu menganalisa kebutuhan (requirement) dan proses bisnis (business process), serta mendesain sistem berdasarkan tujuan dari organisasi Information Technology (IT) Indonesia: Tidak ada (masuk ke jurusan teknik informatika) Target: Lulusan mampu merencanakan, mengimplementasikan, mengkonfigurasi dan memaintain infrastruktur teknologi informasi dalam organisasi

53 Target Profesi IEEE CC 2005 -3-
Software Engineering (SE) Indonesia: Tidak ada (masuk ke Jurusan Teknik Informatika) Lulusan mampu mengelola aktifitas pengembangan software berskala besar dalam tiap tahapannya (software development life cycle)

54

55

56

57

58

59 Strategi Penerapan Kurikulum Computing

60 Desain Umum Kurikulum -1-
Gunakan standard IEEE Computing Curriculla 2005 dan kurikulum inti informatika dan komputer yang diterbitkan APTIKOM (terjemahan dari IEEE Computing Curricula) Desain kurikulum supaya tidak terlalu padat. Orientasikan ke bidang minat (konsentrasi, peminatan or research group) yang peluang kerja dan pasar masih terbuka lebar (besar)

61 Desain Umum Kurikulum -2-
Ajarkan satu bahasa pemrograman utama dan gunakan untuk penugasan di setiap mata kuliah. Ajarkan bahasa pemrograman dengan paradigma lain setelah mahasiswa benar-benar mahir dengan bahasa utama tadi Desain kurikulum supaya mahasiswa bisa menyelesaikan mata kuliah pada semester ke 6. Setelah itu masuk ke research group masing-masing untuk penelitian tugas akhir

62 Desain Umum Kurikulum -3-
Arahkan mahasiswa untuk memiliki kemampuan verbal dan tulis Fasilitasi dan wajibkan mahasiswa memiliki situs blog, tempat mereka menuliskan aktifitas, aktualisasi diri dan mengupload laporan kajian (tugas mandiri) Laporan kajian harus dipresentasikan di depan kelas baik tim maupun individu Libatkan mahasiswa dalam berbagai project riil milik dosen untuk melatih dan mendekatkan ilmu yang dipelajari ke dunia industri

63 Desain Umum Kurikulum -4-
Temukan uniqueness dari kurikulum yang kita miliki atau target lulusan yang kita harapkan Uniqueness inilah yang nantinya membentuk image branding yang terekam dengan baik oleh masyarakat Tampilkan uniqueness dalam bentuk slogan, logo atau mark tertentu dari universitas

64 Referensi (Foundation)
Roger S. Pressman, Software Engineering: A Practitioner’s Approach Sevent Edition, McGraw-Hill, 2009 Ian Sommerville, Software Engineering 9th Edition, Addison-Wesley, 2010 Albert Endres dan Dieter Rombach, A Handbook of Software and Systems Engineering, Pearson Education Limited, 2003 Yingxu Wang, Software Engineering Foundations: A Software Science Perspective, Auerbach Publications, Taylor & Francis Group, 2008 Guide to the Software Engineering Body of Knowledge 2004 Version (SWEBOK), IEEE Computer Society,

65 Referensi (Process) Alan Dennis et al, Systems Analysis and Design with UML – 3rd Edition, John Wiley and Sons, 2010 Dan Pilone and Russ Miles, Head First Software Development, O’Reilly Media, 2008 Barclay and Savage, Object-Oriented Design with UML and Java, Elsevier, 2004 Paul Kimmel, UML Demystified, McGraw-Hill, 2005 Kim Hamilton and Russell Miles, Learning UML 2.0, O'Reilly, 2006 Howard Podeswa, UML for the IT Business Analyst, Course Technology, 2009 Deloitte, Business Process Modeling – Basic Guideline and Tips, 2008

66 Referensi (Quality Assurance)
Daniel Galin, Software Quality Assurance, Addison-Wesley, 2004 Jeff Tian, Software Quality Engineering, John Wiley & Sons, Inc., 2005 G. Gordon Schulmeyer, Handbook of Software Quality Assurance Fourth Edition, Artech House, 2008 Kshirasagar Naik and Priyadarshi Tripathy, Software Testing and Quality Assurance, John Wiley & Sons, Inc., 2008