Pengembangan perangkat lunak: Perbedaan antara revisi
Konten dihapus Konten ditambahkan
k Perubahan kosmetik tanda baca |
k Mengembalikan suntingan oleh 114.79.3.115 (bicara) ke revisi terakhir oleh Etewe Tag: Pengembalian |
||
| (16 revisi perantara oleh 9 pengguna tidak ditampilkan) | |||
Baris 6:
Perlunya [[pengawasan kualitas]] yang lebih baik pada proses pengembangan perangkat lunak menciptakan disiplin [[teknik perangkat lunak]], yang bertujuan menerapkan pendekatan sistematis yang tercantum dalam paradigma [[teknik]] hingga proses pengembangan perangkat lunak.
== Proses bisnis dan pemodelan data ==
[[Visualisasi data|Representasi grafik]] dari keadaan informasi saat ini memberikan sarana yang sangat efektif untuk menyajikan informasi kepada pengguna dan pengembang sistem.
[[Berkas:Process_and_data_modeling.svg|jmpl|200x200px|Contoh interaksi antara proses bisnis dan model data.<ref name="SS93">Paul R. Smith & Richard Sarfaty (1993). [http://www.osti.gov/energycitations/servlets/purl/10160331-YhIRrY/ Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools.] Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group.</ref>]]
* Sebuah [[model bisnis]] mengilustrasikan fungsi yang saling berkaitan dengan dengan proses bisnis yang sedang dimodelkan pengorganisasian yang melaksanakan fungsi-fungsi ini. Dengan menggambarkan aktivitas dan arus informasi, sebuah fondasi dibuat untuk memvisualisasikan, menentukan, memahami, dan memvalidasi sifat suatu proses.
* Sebuah [[model data]] menyediakan detail dari informasi yang ingin disimpan dan penggunaan utama ketika produk akhir adalah pembuatan kode perangkat lunak komputer untuk aplikasi atau persiapan spesifikasi fungsional untuk membantu keputusan membuat atau membeli perangkat lunak komputer. Lihat gambar di sebelah kanan untuk contoh interaksi antara proses bisnis dan model data.<ref name="SS93" />
Biasanya, sebuah model dibuat setelah melakukan sebuah wawancara, disebut sebagai analisis bisnis. Wawancara terdiri dari fasilitator yang mengajukan serangkaian pertanyaan yang dirancang untuk mengekstraksi informasi yang diperlukan yang menggambarkan suatu proses. Pewawancara disebut sebagai fasilitator untuk menekankan bahwa partisipan yang memberikan informasi. Fasilitator harus memiliki pengetahuan tentang proses yang diinginkan, tetapi hal ini tidak sepenting memiliki metodologi terstruktur yang digunakan untuk mengajukan pertanyaan kepada pakar proses. Metodologinya sangat penting karena biasanya sebuah tim dari fasilitator sedang mengumpulkan informasi di sepanjang bangunan dan hasil dari informasi dari semua pewawancara harus cocok dengan satu sama lain setelah selesai.<ref name="SS932" />
== Metodologi ==
Satu proses pengembangan perangkat lunak tidak selalu cocok untuk digunakan untuk semua projek. Masing-masing metodologi yang tersedia paling cocok untuk jenis proyek tertentu, berdasarkan berbagai pertimbangan teknis, organisasi, proyek, dan tim.<ref>System Development Methodologies for Web-Enabled E-Business: A Customization Framework Linda V. Knight (DePaul University, USA), Theresa A. Steinbach (DePaul University, USA) and Vince Kellen (Blue Wolf, USA)</ref>
== Aktivitas ==
=== Proses perencanaan ===
Sebuah tugas penting dalam membuat perangkat lunak adalah meng[[analisis kebutuhan]]. Pelanggan pada umumnya mempunyai ide abstrak dari apa yang mereka inginkan tetapi mereka tidak tahu apa kegunaan perangkat lunaknya. Insinyur perangkat lunak yang terampil dan berpengalaman mengenali persyaratan yang tidak lengkap, ambigu, atau bahkan bertentangan pada saat ini. Sering mendemonstrasikan kode langsung dapat membantu mengurangi risiko kesalahan persyaratan.
"Walaupun banyak usaha yang diperlukan untuk memenuhi dalam fase persyaratan untuk memastikan bahwa persyaratan lengkap dan konsisten, jarang sekali hal ini terjadi; meninggalkan fase desain perangkat lunak sebagai fase yang paling berpengaruh dalam meminimalkan dampak persyaratan baru atau perubahan. Volatilitas persyaratan merupakan hal yang menantang karena berdampak pada upaya pembangunan di masa depan atau yang sudah berjalan."<ref>{{cite web|last1=Otero|first1=Carlos|title=Software Design Challenges|url=http://www.ittoday.info/ITPerformanceImprovement/Articles/2012-06Otero.html|website=IT Performance Improvement|publisher=Taylor & Francis LLC|archive-url=https://web.archive.org/web/20171028111402/http://www.ittoday.info/ITPerformanceImprovement/Articles/2012-06Otero.html|archive-date=28 October 2017|access-date=19 October 2017|url-status=live}}</ref>
== CASE ==
[[Computer-aided software engineering]] (CASE) adalah aplikasi ilmiah dari sebuah seperangkat alat dan metode perangkat lunak untuk pengembangan perangkat lunak untuk membantu mencapai kualitas tinggi, produk perangkat lunak bebas cacat dan dapat dipelihara.<ref>Kuhn, D.L (1989). "Selecting and effectively using a computer-aided software engineering tool". Annual Westinghouse computer symposium; 6–7 Nov 1989; Pittsburgh, PA (USA); DOE Project.</ref> Ini juga merujuk pada metode pengembangan dari [[sistem informasi]] bersama dengan alat otomatis yang dapat digunakan dalam proses pengembangan perangkat lunak.<ref>P. Loucopoulos and V. Karakostas (1995). ''System Requirements Engineering''. McGraw-Hill.</ref> Istilah "computer-aided software engineering" (CASE) dapat merujuk pada perangkat lunak yang digunakan untuk pengembangan secara otomatis dari [[perangkat lunak sistem]], yaitu, kode komputer. Fungsi CASE meliputi analisis, desain, dan pemrograman. Alat CASE mengotomatiskan metode untuk merancang, mendokumentasikan, dan membuat kode komputer terstruktur dalam bahasa pemrograman yang diinginkan.<ref>[http://www.its.bldrdoc.gov/projects/devglossary/_case.html CASE] {{webarchive|url=https://web.archive.org/web/20120218104409/http://www.its.bldrdoc.gov/projects/devglossary/_case.html|date=2012-02-18}} definition In: ''[http://www.its.bldrdoc.gov/projects/devglossary/ Telecom Glossary 2000] {{webarchive|url=https://web.archive.org/web/20051122063850/http://www.its.bldrdoc.gov/projects/devglossary/|date=2005-11-22}}. Retrieved 26 Oct 2008.''</ref>
Dua kunci ide dari Computer-aided Software System Engineering (CASE) adalah:<ref>K. Robinson (1992). ''Putting the Software Engineering into CASE''. New York : John Wiley and Sons Inc.</ref>
* Mendorong bantuan komputer dalam pengembangan perangkat lunak dan proses [[pemeliharaan perangkat lunak]], dan
* Pendekatan rekayasa untuk pengembangan dan pemeliharaan perangkat lunak.
Alat CASE yang umum ada untuk [[manajemen konfigurasi]], [[pemodelan data]], [[transformasi model]], [[Refaktorisasi kode|pemfaktoran ulang]], [[Pemrograman otomatis# Pembuatan kode sumber|pembuatan kode sumber]].
[[Berkas:Anjuta-2.0.0-2.png|jmpl|[[Anjuta]], sebuah IDE C dan C++ untuk lingkungan GNOME.]]
== Bahasa pemodelan ==
Sebuah [[bahasa pemodelan]] adalah [[bahasa artifisial]] yang dapat digunakan untuk mengekspresikan informasi atau pengetahuan atau sistem di dalam sebuah struktur yang ditentukan oleh seperangkat aturan yang konsisten. Aturan ini digunakan untuk interpretasi makna komponen-komponen dalam struktur. Bahasa pemodelan dapat berupa grafis atau tekstual.<ref>Xiao He (2007). "[ftp://antvision.cn/pub/%E5%8C%97%E4%BA%AC%E7%A7%91%E6%8A%80%E5%A4%A7%E5%AD%A6/%E8%AE%BA%E6%96%87/%E4%BD%95%E5%95%B8%E8%80%81%E5%B8%88%E8%AE%BA%E6%96%87/A%20metamodel%20for%20the%20notation%20of%20graphical%20modeling%20languages.pdf A metamodel for the notation of graphical modeling languages]". In: ''Computer Software and Applications Conference, 2007. COMPSAC 2007 – Vol. 1. 31st Annual International'', Volume 1, Issue, 24–27 July 2007, pp 219–224.</ref>
== Model Pandangan ==
[[Berkas:TEAF_Matrix_of_Views_and_Perspectives.svg|jmpl|200x200px|Matriks Pandangan dan Perspektif [[TEAF]].]]
Sebuah [[model pandangan]] adalah sebuah kerangka kerja yang menyediakan sudut pandang dalam [[sistem]] dan [[Lingkungan (sistem)|lingkungannya]], untuk digunakan dalam [[proses pengembangan perangkat lunak]]. Ini adalah representasi grafis dari semantik yang mendasari suatu pandangan.
Kegunaan dari sudut pandang dan pandangan untuk memungkinkan insinyur manusia memahami sistem yang sangat kompleks dan mengorganisir elemen dari suatu permasalahan di sekitar lingkup [[pakar]]. Dalam rekayasa sistem intensif fisik, sudut pandang sering kali sesuai dengan kemampuan dan tanggung jawab dalam organisasi teknik.<ref name="NIST2003">Edward J. Barkmeyer ea (2003). [http://www.mel.nist.gov/msidlibrary/doc/AMIS-Concepts.pdf ''Concepts for Automating Systems Integration''] {{Webarchive|url=https://web.archive.org/web/20170125115826/http://www.mel.nist.gov/msidlibrary/doc/AMIS-Concepts.pdf|date=25 January 2017}} NIST 2003.</ref>
== Paradigma pemrograman ==
Sebuah [[paradigma pemrograman]] adalah sebuah gaya dasar [[pemrograman komputer]], yang umumnya tidak ditentukan oleh metodologi manajemen proyek (seperti waterfall atau agile). Paradigma berbeda dalam konsep dan abstraksi yang digunakan untuk mewakili elemen suatu program (seperti objek, fungsi, variabel, ''constraint'') dan langkah-langkah yang meliputi sebuah komputasi (seperti penugasan, evaluasi, kelanjutan, aliran data). Terkadang konsep yang dinyatakan oleh paradigma digunakan secara kooperatif dalam desain arsitektur sistem tingkat tinggi; dalam kasus lainnya, ruang lingkup paradigma pemrograman terbatas pada struktur internal program atau modul tertentu. Contohnya: [[object-oriented design]] (OOD) [[Grady Booch]], juga dikenal sebagai object-oriented analysis and design (OOAD). Model Booch model termasuk enam diagram: ''class'', objek, transisi keadaan, interaksi, modul, dan proses.<ref>{{cite book|last1=Merx|first1=Georges G.|last2=Norman|first2=Ronald J.|year=2006|url=https://archive.org/details/unifiedsoftwaree0000merx/page/201|title=Unified Software Engineering with Java|publisher=[[Prentice-Hall, Inc.]]|isbn=0130473766|page=[https://archive.org/details/unifiedsoftwaree0000merx/page/201 201]}}</ref>
==Angkatan kerja==
[[Berkas:African software developer at work, Nigeria.jpg|jmpl|Karyawan sedang mengembangkan perangkat lunak]]
Pengembang perangkat lunak adalah orang atau perusahaan yang terlibat dalam [[proses pengembangan perangkat lunak]], termasuk penelitian, desain, [[pemrograman]], pengujian, dan aspek-aspek lain dalam menciptakan [[perangkat lunak]]. Gelar pekerjaan lain untuk orang yang memiliki arti yang sama termasuk [[pemrogram]], [[analis perangkat lunak]], atau [[Rekayasa perangkat lunak|insinyur perangkat lunak]]. Perusahaan yang berspesialisasi dalam perangkat lunak dapat disebut rumah perangkat lunak. Di perusahaan besar, mungkin ada karyawan yang tanggung jawabnya hanya terdiri dari salah satu disiplin ilmu. Dalam lingkungan pengembangan yang lebih kecil, beberapa orang atau satu orang mungkin menangani seluruh proses. Lingkungan kolaboratif, seperti [[perangkat lunak sumber terbuka]], dapat menyatukan banyak pengembang.
== Referensi ==
Baris 11 ⟶ 58:
== Bacaan lanjutan ==
{{refbegin|30em}}
* {{cite book |first=Edward |last=Kit |year=1992 |title=Software Testing in The Real World |isbn=0201877562 |publisher=Addison-Wesley Professional |url=https://archive.org/details/softwaretestingi00kite }}
* Dan Conde (2002). ''Software Product Management: Managing Software Development from Idea to Product to Marketing to Sales''.▼
* {{cite book |first=Jim |last=McCarthy |year=1995 |title=Dynamics of Software Development |isbn=1556158238 |publisher=Microsoft Press |url=https://archive.org/details/dynamicsofsoftwa00mcca }}
* A.M. Davis (2005). ''Just enough requirements management: where software development meets marketing''.▼
▲* {{cite book |first=Dan |last=Conde
* Edward Hasted. (2005). ''Software That Sells: A Practical Guide to Developing and Marketing Your Software Project''.▼
▲* {{cite book |first=A. M. |last=Davis
▲* {{cite book |first=Edward |last=Hasted
* {{cite book |first=Luke |last=Hohmann |year=2003 |title=Beyond Software Architecture: Creating and Sustaining Winning Solutions |url=https://archive.org/details/beyondsoftwarear0000hohm |isbn=0201775948 |publisher=Addison-Wesley Professional}}
* John W. Horch (2005). "Two Orientations On How To Work With Objects." In: ''IEEE Software''. vol. 12, no. 2, pp. 117–118, Mar., 1995.
* {{cite book |first=John |last=Rittinghouse
* {{cite book |first=Karl E. |last=Wiegers
* {{cite book |first=Robert K. |last=Wysocki
{{refend}}
== Pranala luar ==
▲{{DEFAULTSORT:Pengembangan perangkat lunak}}
{{Ilmu komputer}}{{Authority control}}{{DEFAULTSORT:Pengembangan perangkat lunak}}
[[Kategori:Pengembangan perangkat lunak| ]]
[[Kategori:Pemasaran]]
[[Kategori:Manajemen proyek perangkat lunak]]
[[Kategori:Manajemen proyek]]
[[Kategori:Pengembangan produk]]
▲[[en:Software development]]
| |||