1 / 52

Software Engineering

Software Engineering. Romi Satria Wahon o romi@romisatriawahono.net http://romisatriawahono.net +6281586220090. Romi Satria Wahono. SD Sompok Semarang (1987) SMPN 8 Semarang (1990) SMA Taruna Nusantara , Magelang (1993)

lee-snider
Download Presentation

Software Engineering

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. Software Engineering Romi Satria Wahonoromi@romisatriawahono.nethttp://romisatriawahono.net+6281586220090

  2. Romi Satria Wahono • SD Sompok Semarang (1987) • SMPN 8 Semarang (1990) • SMA Taruna Nusantara, Magelang (1993) • B.Eng, M.Eng and Ph.Din Software Engineering fromSaitama University Japan (1994-2004)Universiti Teknikal Malaysia Melaka (2014) • Research Interests: Software Engineering,Intelligent Systems • Founder danKoordinatorIlmuKomputer.Com • Peneliti LIPI (2004-2007) • Founder dan CEO PT Brainmatics Cipta Informatika

  3. Textbooks

  4. Course Contents-1- • Introduction to Software Engineering • WhatisSoftware • WhatisSoftware Engineering • Discipline andCurriculumof Software Engineering • Software Engineering Profession • Profession, Ethics and Certification • Software Industry and Market • Internet Business Model and Trends

  5. Course Contents-2- • Software Engineering Process • 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

  6. Course Contents-3- • Software Quality Assurance • The Uniqueness of SoftwareQualityAssurance • What is Software Quality • Software Quality Factor • Software Testing • Software Engineering Research • ComputingResearch Methodology • Research Trendsin Software Engineering • Case Study: Developing Research Proposal in Software Engineering Field

  7. Introduction to Software Engineering

  8. Content • WhatisSoftware • WhatisSoftware Engineering • Discipline of Software Engineering

  9. 1. What is Software

  10. The Definition of Software

  11. JenisSoftware (Market) • Software Generik Perangkatlunakstandar yang diproduksiolehperusahaanpengembangdandijualpadapasarterbukakesiapapun yang bisamembelinya (Shrink-wrapped) • Software Pesanan Perangkatlunak yang dikembangkankhususdandisesuaikandengankebutuhanpelanggan (Ian Sommerville, Software Engineering 9 Ed., 2012)

  12. JenisSoftware (Platform) • Software Sistem • Software Real-Time • Software Bisnis • Software TeknikdanIlmuPengetahuan • Software Tertanam (Embedded Software) • Software Komputer Personal • Software KecerdasanBuatan • Software Mobile (Roger Pressman, Software Engineering,: A Practitioner’s Approach 7Ed., 2009)

  13. JenisSoftware (Lisensi) • Proprietary Software • Open Source Software

  14. Open Source Software • Software yang source codenyaterbukadandidistribusikandalam suatu format lisensi yangmemungkinkanpihak lain secarabebasmemperbanyakdanmemodifikasi source code didalamnya • Hakciptatetapada, tapilisensimemungkinkanorang lain bebasuntukmenggunakandanmemodifikasi software tersebut • Jenislisensi open source software: • GNU General Public License (GPL) • Apache License • BSD license • MIT License • Mozilla Public License

  15. Proprietary Software • Software yang source codenyatertutupdandidistribusikandengansuatu format lisensi yang membatasi pihak lain untuk menggunakan, memperbanyakdanmemodifikasi • Lisensi proprietary software memungkinkanorang lain menggunakan software yang kitabuatdengandiikutipenyerahanroyalti (uang) kepemilikhakciptanya • SharewaredanFreewareadalah proprietary software. Free for use belumtentu free for (redistribute) atau free for modify!

  16. PerananPerangkatLunak • Menggantikanperanmanusia: Denganotomasiterhadapsuatutugasatauproses • Memperkuatperanmanusia: Denganmembantumanusiamengerjakansuatutugasatauprosesdenganlebihbaikdantertata

  17. PerananPerangkatLunak • RestrukturisasiPeranManusia: Denganmelakukanperubahan-perubahanthdsekumpulantugasatauproses • HiburandanPermainan:Denganmenyajikanaplikasiinteraktifhiburan yang semakindekatdengankenyataan

  18. The Uniqueness of theSoftware Development

  19. If(suhu>=3) shutdown() • Bug  failure

  20. 2. What is Software Engineering

  21. Disiplinilmu yang membahassemuaaspekproduksiperangkatlunak, mulaidaritahapawalspesifikasi, desain, konstruksi, testingsampaipemeliharaansetelahdigunakan Definisi

  22. Mengapa Software Engineering? • Terminologirekayasaperangkatlunak (software engineering) pertama kali digunakanpadaconference ttg software crisistahun 1968 • Krisisperangkatlunakmerupakanakibatlangsungdarilahirnyakomputergenerasike 3 yang canggih pada waktu itu • Perangkatlunak yang dihasilkanmenjadimenjadibeberapa kali lebihbesardankompleks • Pendekatan informal tidakcukupefektif (cost, waktudankualitas) dalampengembanganperangkatlunak • Biaya hardware jatuhdanbiayaperangkatlunaknaikcepat

  23. Generasi I (1946-1959) Menggunakantabunghampa ENIAC, EDSAC Generasi II (1959-1964) Menggunakantransistor PDP-1, PDP-8, UNIVAC, IBM 70xx Generasi III (1964-1979) MenggunakanIC IBM S360, NOVA, UNIVAC 1108 Generasi IV (1980-sekarang) MenggunakanVLSI GenerasiKomputer

  24. IsitPossible?

  25. 5 Problems in the SoftwareDevelopment • PoorRequirements- if requirements are unclear, incomplete, too general, and not testable, there may be problems. • UnrealisticSchedule- if too much work is crammed in too little time, problems are inevitable. • InadequateTesting- 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.

  26. 5 Solutions in the SoftwareDevelopment • SolidRequirements- 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.

  27. 5 Solutions in the SoftwareDevelopment • RealisticSchedules- 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.

  28. 5 Solutions in the SoftwareDevelopment • AdequateTesting- 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.

  29. 5 Solutions in the SoftwareDevelopment • Stick to InitialRequirementswhere 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.

  30. 5 Solutions in the SoftwareDevelopment • 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.

  31. Barriers to Requirements Elicitation • The "Yes, But" Syndrome • The "Undiscovered Ruins" Syndrome • The "User and the Developer" Syndrome

  32. 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 . . . ?“

  33. 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

  34. 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?

  35. 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.

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

  37. 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.

  38. 3. Discipline and Curriculum of Software Engineering

  39. PerjalananDisiplinIlmu SoftwareEngineering • Peter J Dennings yang memimpin task force disiplin ilmu computing memasukkan software engineering sebagai satu disiplin ilmu (Dennings, 1999) • IEEE Computer Society membentuktimkhususuntuk menyusun pohon ilmu Software Engineering (Software Engineering Body of Knowledge, SWEBOK) http://swebok.org • Software Engineering termasuknamajurusanataufakultas yang diakuimenurut IEEE Computing Curricula 2005

  40. Matriks Dennings 1999 • AlgoritmadanStruktur Data • BahasaPemrograman • ArsitekturKomputer • SistemOperasidanJaringan • Software Engineering • Database danSistim Retrieval Informasi • Artificial Intelligence danRobotik • Grafik • Human Computer Interaction • IlmuKomputasi • Organizational Informatics • BioInformatik (Peter J. Dennings,1999 )

  41. SWEBOK 2004

  42. IEEE Computing Curricula 2005 • Computer Engineering (CE, TeknikKomputer) • Computer Science (CS, IlmuKomputer) • Information Systems (IS, SistemInformasi) • Information Technology (IT, TeknologiInformasi) • Software Engineering (SE, RekayasaPerangkatLunak)

  43. IEEE Computing Curricula 2005 ComputerEngineering (CE) pengembangan sistemterintegrasi(software danhardware) Computer Engineer ComputerScience (CS) konsep computing dan pengembangan software Computer Scientist Information System (IS) analisa kebutuhan danproses bisnisserta desain sistem System Analyst Information Technology (IT) pengembangandan maintenanceinfrastruktur IT Network Engineer SoftwareEngineering (SE) pengembangan software dan pengelolaan tahapan SDLC Software Engineer

  44. Referensi (Foundation) • Roger S. Pressman, Software Engineering: A Practitioner’s Approach SeventEdition, McGraw-Hill, 2009 • Ian Sommerville, Software Engineering 9th Edition, Addison-Wesley, 2010 • Albert Endresdan 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, http://www.swebok.org, 2004

More Related