tugas pertemuan i metode-metode rekayasa perangkat lunak · tugas pertemuan i metode-metode...

Tugas I RPL Heriyanto

1

Tugas Pertemuan I Metode-Metode Rekayasa Perangkat Lunak

Perangkat Lunak dipandang Perlu ? Perangkat lunak dipandang sangat perlu karena ia mempengaruhi hampir setiap aspek di dalam kehidupan kita dalam bisnis, dan kegiatan sehari-hari [11].

perangkat lunak diperlukan untuk memudahkan kehidupan manusia, sebagai alat bantu, tools, sehingga lebih comfortable/nyaman dalam melaksanakan kegiatan bisnis maupun non bisnis.

dan diperlukan rekayasa perangkat lunak dengan metode-metode karena untuk menghasilkan suatu perangkat lunak yang berkualitas.

Karakteristik Perangkat Lunak : 1. Merupakan suatu produk [11] 2. Merupakan pengendali komputer, komunikasi, mengatur informasi [11] 3. Perangkat lunak dikembangkan atau direkayasa bukan diproduksi seperti manufaktur [11] 4. Perangkat lunak tidak mengenal suku cadang [11] 5. Perangkat lunak tidak mengalami kelelahan/kerusakan/aus [11]. 6. Membantu Dasar Pengambilan Keputusan.

Definisi Perangkat Lunak

Software is: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to ad equately manipulate information, and (3) descriptive information in both hard copy and virtual forms that describes the operation and use of the programs [1].

Perangkat lunak adalah (1) instruksi-instruksi (program komputer) yang ketika dijalankan menyediakan fitur-fitur, fungsi-fungsi, dan kinerja-kinerja yang dikehendaki;(2) struktur data yang memungkinkan program-program memanipulasi informasi, dan (3) informasi deskriptif pada salinan tercetak dan bentuk-bentuk maya yang menggambarkan pengoperasian dan penggunaan program-program.[11]

Definisi tentang perangkat lunak oleh Fritz Bauer [Nau69] pada konferensi seminar dengan topik perangkat lunak. [software engineering is] the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines [1]. [Perangkat lunak adalah ] pembuatan dan penggunaan prinsip-prinsip penting rekayasa supaya pengguna bisa memperoleh perangkat lunak secara murah yang dapat diandalkan dan bekerja secara efisien pada mesin-mesin yang sesungguhnya [11].


2

Definisi Rekayasa Perangkat Lunak.klasik 1969

“The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.”[1]

Penerapan prinsip engineering untuk memperoleh software yang ekonomis, reliable dan bekerja efisien pada komputer

Definisi Rekayasa Perangkat Lunak 1993

“Software Engineering: (1) The application of a systematic, disciplines, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1).”[1]

RPL : (1) Penerapan secara sistematis, disiplin, pendekatan terukur pada pengembangan, pengoperasian dan pemeliharaan software. (2) Studi terhadap (1)

Definisi Rekayasa Perangkat Lunak menurut IEEE [IEE93a] telah mengembangkan suatu definisi yang lebih komprehensif

Software Engineering; (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software (2) the study of approaches as in (1) [1].

Rekayasa perangkat lunak pada dasarnya merupakan (1) aplikasi dari suatu pendekatan yang sistematik, disiplin, dan dapat diukur pada pengembangan, operasi, dan perawatan perangkat lunak; yaitu penerapan rekayasa pada perangkat lunak. (2) studi pendekatan-pendekatan seperti pada (1) [11].

Metode-Metode yang ada pada Perangkat Lunak yang berbeda-beda diikuti seiring dengan berkembangnya pengembangan kualitas dari software dengan tingginya kebutuhan akan perangkat lunak itu sendiri sehingga juga berdampak pada mahalnya harga perangkat lunak dengan kualitas yang berbeda-beda. Kebutuhan yang ada di pasaran dengan produk yang dihasilkan sulit untuk distandarkan antara satu produk dengan produk yang lain dengan variasi kebutuhan dan penggunaan yang tentunya berbeda-beda, variasi harga dan diiringi dengan variasi kualitas. Pentingnya metode pengembangan tersebut dibutuhkan karena perangkat lunak perlu di dokumentsi dengan baik meliputi sistem, program, algoritma maupun data secara baik dan teratur. Selain itu dari sisi lain perkembangan hardware pun selalu berkembang sehingga perlu banyak metode untuk memecahkan sistem dan dokumentasi perangkat lunak tersebut.

Pentingnya Rekayasa perangkat Lunak

1. Semua bisnis memerlukan alat bantu software 2. Banyak system yang dikendalikan oleh Perangkat lunak 3. Harga Perangkat Lunak lebih mahal dari hardware


3

4. Biaya perawatan perangkat lunak lebih mahal dibandingkan dengan pembuatannya 5. Rekayasa Perangkat Lunak harus dikelola secara efektif baik pembuatannya maupun

perawatannya.

Alasan pengembangan sistem. what? Why?

1. pengembang software dalam mengembangkan software tertentu, dengan tujuan menghindarkan adanya masalah-masalah yang muncul dalam pengerjaan dari project tersebut Adanya permasalahan : ketidakberesan dan pertumbuhan organisasi sehingga mengurangi resiko dan kesalahan system (recycle solve problem)

2. Meraih kesempatan-kesempatan diterapkan berbagai jenis proyek/oportunity 3. Adanya instruksi pimpinan dan pemerintah./demain 4. Menuntut adanya dokumentasi dan pengembangan system serta pemerliharaan

(development and maintenance). 5. kualitas

Gambar 1. Alasan pengembangan sistem

Adapun Lapisan-lapisan/layer yang ada pada teknologi rekayasa perangkat lunak :

Gambar 2. Lapisan rekayas perangkat lunak [1][11][3][8]

1. Adanya masalah/kesalahan Memecahkan Problem

2. Efektif(mudah,nyaman/convertable 3. Permintaan/demain 4. Opportunity 5. Pengembangan dan pemeliharaan 6. Tututan kualitas software

Method‐method Lingkungan

Bisnis dll


4

Beberapa metode rekayasa perangkat lunak diantaranya :

1. Waterfall (air terjun) Model air terjun sering dikenal dengan SDLC (System Development Life Cycle), pendekatan yang sistimatis dan berurutan (sekuensial). [11].Model air terjun yang asli diperkenalkan oleh Winston Royce[Roy70].[1][11][3][8] Model air terjun merupakan paradigma yang tertua untuk rekayasa perangkat lunak[11]. The early SDLC is also referred to as the waterfall model as each phase produces an artifact that leads into the next phase [20]. The waterfall model is the oldest paradigm for software engineering. [1].

A variation in the representation of the waterfall model is called the v-model[1][11] Waterfall model is the sequential development model.[2] The waterfall model, sometimes called the classic life cycle, suggest a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction and deployment, culminating in ongoning support of completed software. [1]

Metode waterfall merupakan metode yang sering digunakan oleh penganalisa sistem pada umumnya. Inti dari metode waterfall adalah pengerjaan dari suatu sistem dilakukan secara berurutan atau secara linear. Jadi jika langkah ke-1 belum dikerjakan, maka langkah 2 tidak dapat dikerjakan. Jika langkah ke-2 belum dikerjakan maka langkah ke-3 juga tidak dapat dikerjakan, begitu seterusnya. Secara otomatis langkah ke-3 akan bisa dilakukan jika langkah ke-1 dan ke-2 sudah dilakukan.

Gambar 3.model waterfall [1][3][8][11]

Beberapa permasalah yang sering dijumpai saat model air terjun diterapkan[11][1] :

1. Proyek Perangkat Lunak yang nyata jarang mengikuti aliran sekuensial seperti yang diusulkan oleh model air terjun.


5

2. Seringkali sulit bagi para pelanggan untuk menetapkan semua spesifikasi kebutuhan secara eksplisit. Model air terjun menghendaki hal seperti ini dan model ini sulit mengakomodasi ketidakpastian alamiah pada awal kebanyakan proyek.

3. Pelanggan harus memiliki kesabaran. Suatu kesalahan fatal jika tidak terdeteksi hingga program berjalan berakibat fatal.

Dalam suatu analisa yang menarik tentang proyek-proyek perangkat lunak yang nyata, Bradac [Bra94] menemukan bahwa tahapan-tahapan dalam siklus hidup klasik cenderung ‘terkunci’ sehingga banyak anggota tim proyek perangkat lunak harus menghabiskan waktu untuk menunggu anggota tim proyek lainnya bekerja.[11]

Organizational value/development methodology value alignment using waterfall consistency, bureaucratic, hierarchy, markets, normative values[5]

It is limited to the by-then popular methodologies such as the waterfall [6]

The waterfall model is quite rigid under changing requirements[7]. Model waterfall cukup kaku kalau ingin melakukan perubahan.

Waterfall is used largely because that’s what most people learned either in college or on the job over many years.[9]. Waterfall digunakan untuk pengguna besar.

The popular SDLC in some form of contemporary use are: 1) Waterfall [12]

This model later became known as the ‘traditional’ or waterfall model and has been viewed as a foundational standart for software process.[17].Waterfall is typically described as a unidirectional top down and non iterative activity sequence [17]

Because the waterfall model requires the early steps to be especially free of mistakes while it is well known that early in the project is just when ignorance makes mistakes most likely, some authors have objected to its use[21]

Waktu

Waterfall sulit untuk sesuatu yang waktunya uncertainty dan banyak projek sehingga waktunya lama..

It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many project. [1] The time spent waiting can exceed the time spent on productive work! The blocking states tend to be more prevalent at the beginning and end of a linear sequential process. [1] The waterfall models is a poor choice for software development project where requirements are not well-known or understood by the development team. It might not a


6

good model for complex project or projects that make more than a few months to complete [4]

Cost/biaya

Kesalahan kecil akan menjadi masalah besar jika tidak ketahuai sejak dini oleh pengembang sehingga biaya bisa sangat mahal. If undetected until the working program is reviewed can be disastrous[1]

Risk / Resiko

Program yang mempunyai banyak versi akan sulit tersedia resiko program waktu lama untuk berganti-ganti versi. The customer must have patience. A working version of the programs will not be available until late in the project time span.[1] Requirement is clear before development starts [2] The problems with one phase are never solved completely during that phase and in fact many problems regarding a particular phase arise after the phase is signed off, this result in badly structured system[2]. The funding for project stable [4]. However, experience has shown that the strict controls inherent in the waterfall process inhibit developers ability to react to changing conditions [14]. Namun Pengalaman menunjukan control kaku pada waterfall sehingga menolak pengembangan yang kondisinya berubah-ubah. Kesulitan didalam mereview.

Jumlah SDM

In which some project team members must wait for other members of the team to complete dependent task [1] The amount of resources required to implement this model are minimal [2] If client want the requirement to be changed, it will not implemented in the current development process [2]. Project team members comfortable with structure [4]. Anggota Team nyaman dengan struktur. This 50 person team produced the same number of features as a typical 350 person waterfall team[10].team berjumlah 50 dan standarnya 350 orang untuk team waterfall

Tools

As its linear model, it’s easy to implement [2].Linier model mudah diimplementasikan If requirement is clear, larger project then we choose waterfall model[2]. Waterfall model untuk proyek yang besar.DAD, ERD,


7

Kualitas.

Each phase proper documentation is followed for the quality of the development [2].

In organizationally stable periods when waterfall methods were used release duration increased [13].Organisasi yang stable menggunakan metode waterfall digunakan akan meningkat.

Waterfall Model, a high precision model for English noun phrase identification is presented [15], The waterfall model combined the rule method and the statistical method so as to make them complements each other [15].

That the performance in the waterfall region can be improved by using irregular LDPC Codes.[16]. PEG algorithm that shows a better performance in the error floor region as well as in the waterfall region compared to randomly construced LDPC Codes[16].

Therefore, a Dynamic Resource (computing nodes) scaling algoritm based on th waterfall model is proposed[18]

RUP (Rational Unified Process) emerged when the ability of the waterfall model to deal effectively with common and serious problems in software projects was questioned[19].

Keunggulan dan Kelemahan Metode Waterfall

Metode pengembangan waterfall mempunyai keunggulan dalam membangun dan mengembangkan suatu sistem, antara lain:

1. Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.

2. Dokumen pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi setiap fase atau tahapan akan mempunyai dokumen tertentu.

Dalam proses membangun dan mengembangkan suatu sistem, metode waterfall mempunyai beberapa kelemahan, antara lain:

1. Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk..

2. Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan.

3. Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidakpastian pada saat awal pengembangan.


8

Karakteristik Waterfall :

a. Waterfall merupakan metode Sequential secara berurutan atau secara linear b. Perencanaan analisis awal harus kuat diketahui sejak dini agar tidak menjadi masalah

besar c. Proses Pengembangan tidak dapat dilakukan secara berulang sebelum produk jadi.

2. Prototype

Prototype dilakukan apabila tidak bisa mengidentifikasikan spesifikasi kebutuhan yang rinci untuk fungis-fungsi dan fitur-fitur yang nantinya akan dimiliki perangkat lunak yang akan dikembangkan [11]. The Prototype is deployed and evaluated by stackeholders, who provide feedback that is used to further refine requirements. Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the same time enabling you to better understand what needs to be done.[1]

Prototype yang memilki kegunaan menurut Brooks[Bro95] dalam kebanyakan proyek perangkat lunak sistem yang dibentuk pertama kali biasanya bukan merupakan sistem yang dapat langsung digunakan oleh pengguna.[11]

Metode ini sering digunakan pada dunia riil. Karena metode ini secara keseluruhan akan mengacu kepada kepuasan user. Bisa dikatakan bahwa metode ini merupakan metode waterfall yang dilakukan secara berulang-ulang. The design process of the framework and the prototype is iterative [23]

Gambar 4.model prototyping [1][3][8][11]

Meskipun demikian pembuatan prototype bisa saja menimbulkan masalah sebagai berikut [11] 1. Para stakeholder dapat melihat tampilan perangkat lunak yang akan dipakai kemudian,

tidak perduli sesungguhnya prototype pada umumnya tidak dirancang secara seksama.


9

2. Prototype jadi dengan cepat. Algoritma-algoritma yang tidak efisien mungkin diimplementasikan hanya untuk memperlihatkan kemampuan sistem secara cepat.

Waktu Prototype menghemat waktu dalam pengembangannya. The quick design leads to the construction of a prototype[1]

Cost/biaya

The development may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human machine interaction should take[1]

This means the required human resources were twice as high as the forecasted but our CMFS prototype shows that the actual service costs are lower.[22]

Risk / Resiko

Stakeholders cry foul and demand that “a few fixes’ be applied to make the prototype a working product. Too ofter software development management relents.[1]

Prototype bisa jadi tidak sama dengan product yang akan jadi.

Jumlah SDM

Although prototyping can be used as a stand-alone process model, it is more commonly used as a technique that can be implemented within the context of any one of the process models [1]

Paradigma pembuatan prototype seringkali membantu tim pengembang perangkat lunak dan para stakeholder untuk memahami lebih baik apa yang akan dikembangkan saaat spesifikasi kebutuhan belum jelas [11]

Tools

An inappropriate operating system or programming language may be used simply because it is available and known.[1]

If a working prototype is to be built, you can make use of exiting program fragments or apply tools. (e.g. report generators and windows managers)[11].

Jika suatu prototype yang dapat digunakan akan dikembangkan, kita bisa menggunakan program yang sudah ada sebelumnya atau dengan menerapkan penggunaan perkakas yang sudah ada (misalnya perkakas pembentukan laporan [report generators] atau aplikasi untuk melakukan perancangan antarmuka [windows manager] yang


10

memungkinkan program yang dapat digunakan dapat dibuat dengan mudah dan cepat [11]

Four Generation Technology (4GT) Method

Kualitas.

Kualitas sistem kurang baik karena hanya mengedepankan aspek kenyamanan user. Tidak mencerminkan proses perancangan yang baik. Stakeholder see what appears to be a working version of the software, unaware that the prototype is held together haphazardly, unaware that in the rush to get it working you haven’t considered overall software quality or long-term maintainability.[1]

Keunggulan metode Prototyping

• Adanya komunikasi baik antara pengembang dengan pelanggan. • Pengembang dapat bekerja lebih baik untuk memenuhi kebutuhan pelanggan. • Pelanggan berperan aktif dalam pengembangan sistem. • Menghemat waktu dalam pengembangannya. • Penerapan lebih mudah karena pemakai akan mengetahui apa yang diharapkan.

Kelemahan metode Prototyping

• Kualitas sistem kurang baik karena hanya mengedepankan aspek kenyamanan user.

• Pengembang kadang-kadang menggunakan implementasi yang sembarangan. • Tidak mencerminkan proses perancangan yang baik.

Karakteristik Protopying

1. Berupa Sampling yang implementasinya belum tentu mewakili system 2. Menghemat waktu karena sudah ada produk sejak dini


11

DAFTAR PUSTAKA

[1] Pressman Roger S, (Software Engineering A Practitioner’s Approach) Seventh, 2010 [2] Balaji, S, Waterfall vs V-Model Vs Agile: A Comparative Study on SDLC, International Journal of Informationa Technology and Business Management 29 June 2012 vol 2 no.1 [3] Pressman Roger S , Softwre Engineering A Practitioner’s Approach) Fifth Edition 2001. [4] Sharma Manish, A Survey of Project Scenario Impact in SDLC Models Selection Process, Internaional Journal of Scientific & Engineering Research Volume2 July 2011 [5] Cram, Alec, W, Aligning Organizational Values in System Development Project:An Empirical Study, Proceedings of The 44th Hawaii International Conference on System Science, 2011 [6] Dyck Sebastian, Identifying Common Characteristics in Fundamental, Integrated and Agile Software Development Methodologies [7] Thakurta Rahul, Understanding Requirements Volatility in Software Projects-An Empirical Investigation of Volatility Awareness, Management Approaches and their Applicability, Proceedings of the 43rd Hawaii International Conference on System Sciences 2010. [8] Pressman Roger S, Software Engineering A Practitioner’s Approach) Fifth, 2001 [9] Edberg, Dana, Embracing or Constraining Change:An Exploration of Methodologies for Maintaining Software, Proceedings of the 44th Hawaii International Conference on System Science 2011 [10] Sutherland Jeff, Fully Distributed Scrum: Replicating Local Productivity and Quality with Offshore Teams, Proceedings of the 42nd Hawaii International Conference on System Science 2009 [11] Pressman,Ph.D Rekayasa Perangkat Lunak Pendekatan Praktis Edisi 7, Edisi Bahasa Indonesia 2012 [12] Aitken Ashley, A Comparative Analysis of Traditional Software Engineering and Agile Software Development, Proceeding of the 46th Hawaaii International Conference on System Sciences 2013 [13] Greening Daniel R, Release Duration and Enterprised Agility, Proceeding of the 46th Hawaii International Conference on System Sciences 2013 [14] Harris Michael, Controls in Flexible Software Development, Proceeding of the 39th Hawaii International Conference on System Sciences 2006 [15] Liang Ying Hong, High Precision English Base Noun Phrase Identification Based on “Waterfall” Model, Procedings of the Fourth International Conference on Machine Learning and Cybernetics, Guangzhou, 18-21 August 2005 [16] Richter G, An Improvement of the PEG Algorithm for LDPC Codes in the Waterfall Region,Eurocon Servia & Montenegro Belgrade November 22-24, 2005 [17] Thummadi B Veeresh, Enacted Routines in Agile and Waterfall Processes, Agile Conference 2011


12

[18] Liu Wenjie, A Waterfall Model to Achieve Energy Efficient Task Maping for Large Scale GPU Clusters, IEEE International Parallel & Distributed Processing Symposium 2011 [19] Osorio Jorge A, Moving from Waterfall to Iterative Development An Empirical Evalution of Advantages, Disadvantages and Risks of RUP, EUROMICRO Conferences on Software Engineering and Advanced Applications 37th 2011 [20] Nasution M.Faisal Fariduddin Attar, Documentation in Systems Development : A Significant Criterion for Project Success, Proceedings of the 42nd Hawaii International Conference on System Sciences 2009 [21] Keeman William M, MC, Experience with a Software Engineering Project Course, IEEE Transactions on Software Engineering Vol SE-13 NO.11 November 1987 [22] Dorn Jurgen, A Prototype for Service Based Costing, Proceeding Hawaii International Conference on System Sciences 46th 2013 [23] Dalmolen Simon, Transportation Performances measures and metrics : Overall Transportation Effectiveness (OTE) A Framework Prototype and Case Study, Proceeding Hawaii International Conference on System Sciences 46th 2013

tugas pertemuan i metode-metode rekayasa perangkat lunak · tugas pertemuan i metode-metode...

Documents