Lompat ke isi

Pengembangan perangkat lunak

Dari Wikipedia bahasa Indonesia, ensiklopedia bebas
(Dialihkan dari Programmer)

Bagian dari seri mengenai
Pengembangan perangkat lunak
Aktivitas inti
Paradigma, model
Metodologi, kerangka kerja
Disiplin pendukung
Praktik
Alat
Standar, kumpulan pengetahuan
Glosarium
Garis besar

Pengembangan perangkat lunak adalah proses merancang, membuat, menguji, dan memelihara aplikasi perangkat lunak untuk memenuhi kebutuhan pengguna tertentu atau tujuan bisnis. Proses ini lebih luas daripada pemrograman, yaitu menulis kode, karena mencakup perumusan tujuan, evaluasi kelayakan, analisis persyaratan, perancangan, pengujian, dan rilis. Proses ini merupakan bagian dari rekayasa perangkat lunak yang juga mencakup manajemen organisasi, manajemen proyek perangkat lunak, manajemen konfigurasi dan aspek-aspek lainnya.[1]

Pengembangan perangkat lunak melibatkan banyak keterampilan dan spesialisasi pekerjaan, termasuk pemrograman, pengujian, dokumentasi, desain grafis, dukungan pengguna, pemasaran, dan penggalangan dana. Jenis alat yang umum digunakan adalah kompilator, lingkungan pengembangan terpadu (IDE), dan pengendalian versi.

Rincian proses yang digunakan untuk suatu upaya pengembangan dapat berbeda-beda. Proses tersebut dapat dibatasi pada standar formal yang terdokumentasi, atau dapat disesuaikan dan muncul secara bertahap sesuai dengan upaya pengembangan. Proses dapat bersifat berurutan, yaitu setiap fase utama (misalnya perancangan, implementasi, dan pengujian) diselesaikan sebelum fase berikutnya dimulai, tetapi pendekatan iteratif—di mana aspek-aspek kecil dirancang, diimplementasikan, dan diuji secara terpisah—dapat mengurangi risiko dan biaya serta meningkatkan kualitas.

Metodologi

[sunting | sunting sumber]
Diagram alir model prototipe evolusioner, suatu model pengembangan iteratif[2]

Setiap metodologi yang tersedia paling sesuai untuk jenis proyek tertentu, berdasarkan berbagai pertimbangan teknis, organisasi, proyek, dan tim.[3]

  • Metodologi yang paling sederhana adalah "kode dan perbaiki" (code and fix), yang biasanya digunakan oleh seorang pemrogram yang bekerja pada proyek kecil. Setelah mempertimbangkan secara singkat tujuan program, pemrogram menulis kode dan menjalankannya untuk melihat apakah program tersebut berfungsi. Setelah selesai, produk dirilis. Metodologi ini berguna untuk membuat prototipe, tetapi tidak dapat digunakan untuk program yang lebih rumit.[4]
  • Dalam model air terjun dari atas ke bawah, kelayakan, analisis, perancangan, pengembangan, jaminan kualitas, dan implementasi dilakukan secara berurutan. Model ini mengharuskan satu langkah selesai sebelum langkah berikutnya dimulai, sehingga menyebabkan penundaan dan membuat langkah sebelumnya tidak dapat direvisi jika diperlukan.[5][6][7]
  • Dengan proses iteratif, langkah-langkah tersebut diselingi satu sama lain untuk meningkatkan fleksibilitas, efisiensi, dan penjadwalan yang lebih realistis. Alih-alih menyelesaikan proyek sekaligus, seseorang dapat melalui sebagian besar langkah dengan mengerjakan satu komponen pada satu waktu. Pengembangan iteratif juga memungkinkan pengembang memprioritaskan fitur yang paling penting, sehingga fitur dengan prioritas lebih rendah dapat dihilangkan kemudian jika diperlukan.[6][8] Agile adalah salah satu metode yang populer, yang pada awalnya ditujukan untuk proyek berukuran kecil atau menengah, dan berfokus pada pemberian kendali yang lebih besar kepada pengembang atas fitur yang mereka kerjakan untuk mengurangi risiko pembengkakan waktu atau biaya.[9] Turunan dari Agile mencakup pemrograman ekstrem dan Scrum.[9] Pengembangan perangkat lunak sumber terbuka biasanya menggunakan metodologi Agile dengan perancangan, pengodean, dan pengujian secara bersamaan, karena bergantung pada jaringan kontributor sukarelawan yang terdistribusi.[10]
  • Di luar Agile, beberapa perusahaan mengintegrasikan operasi teknologi informasi (TI) dengan pengembangan perangkat lunak, yang disebut DevOps atau DevSecOps, termasuk keamanan komputer.[11] DevOps mencakup pengembangan berkelanjutan, pengujian, integrasi kode baru ke dalam sistem pengendalian versi, penyebaran kode baru, dan terkadang pengiriman kode kepada klien.[12] Tujuan integrasi ini adalah menyediakan layanan TI dengan lebih cepat dan efisien.[11]

Fokus lain dalam banyak metodologi pemrograman adalah gagasan untuk mencoba menemukan masalah seperti kerentanan keamanan dan bug sedini mungkin (pengujian shift-left) guna mengurangi biaya pelacakan dan perbaikannya.[13]

Pada tahun 2009, diperkirakan bahwa 32% proyek perangkat lunak diselesaikan tepat waktu dan sesuai anggaran, serta dengan fungsionalitas yang lengkap. Sebanyak 44% lainnya berhasil diserahkan, tetapi kehilangan setidaknya salah satu fiturnya. Sementara itu, 24% sisanya dibatalkan sebelum dirilis.[14]

Siklus hidup

[sunting | sunting sumber]

Siklus hidup pengembangan perangkat lunak menjelaskan fase-fase umum dalam proses pengembangan perangkat lunak.[15]

Kelayakan

[sunting | sunting sumber]

Sumber gagasan untuk produk perangkat lunak sangat beragam. Gagasan tersebut dapat berasal dari riset pasar, termasuk demografi calon pelanggan baru, pelanggan yang sudah ada, calon pelanggan yang menolak produk, staf pengembangan perangkat lunak internal lainnya, atau pihak ketiga yang kreatif. Gagasan untuk produk perangkat lunak biasanya pertama kali dievaluasi oleh staf pemasaran berdasarkan kelayakan ekonomi, kesesuaian dengan saluran distribusi yang ada, kemungkinan dampaknya terhadap lini produk yang sudah ada, fitur yang diperlukan, dan kesesuaiannya dengan tujuan pemasaran perusahaan. Pada tahap evaluasi pemasaran, asumsi biaya dan waktu dievaluasi.[16] Analisis kelayakan memperkirakan pengembalian investasi proyek, biaya pengembangannya, dan jangka waktunya. Berdasarkan analisis ini, perusahaan dapat mengambil keputusan bisnis untuk berinvestasi dalam pengembangan lebih lanjut.[17] Setelah memutuskan untuk mengembangkan perangkat lunak, perusahaan berfokus untuk menyerahkan produk dengan biaya dan waktu yang sama atau lebih rendah daripada perkiraan, serta dengan standar kualitas yang tinggi (yaitu minimnya bug) dan fungsionalitas yang diinginkan. Namun demikian, sebagian besar proyek perangkat lunak mengalami keterlambatan, dan terkadang dilakukan kompromi pada fitur atau kualitas untuk memenuhi tenggat waktu.[18]

Analisis

[sunting | sunting sumber]

Analisis perangkat lunak dimulai dengan analisis persyaratan untuk menangkap kebutuhan bisnis perangkat lunak.[19] Tantangan dalam mengidentifikasi kebutuhan adalah bahwa pengguna saat ini atau calon pengguna mungkin memiliki kebutuhan yang berbeda dan tidak kompatibel, mungkin tidak memahami kebutuhan mereka sendiri, dan dapat mengubah kebutuhan mereka selama proses pengembangan perangkat lunak.[20] Pada akhirnya, hasil analisis adalah spesifikasi produk yang terperinci yang dapat digunakan oleh pengembang. Analis perangkat lunak sering kali melakukan dekomposisi proyek menjadi objek-objek yang lebih kecil, yaitu komponen yang dapat digunakan kembali untuk meningkatkan efektivitas biaya, efisiensi, dan keandalan.[19] Dekomposisi proyek dapat memungkinkan implementasi multithreading yang berjalan jauh lebih cepat pada komputer multiprosesor.[21]

Selama fase analisis dan perancangan pengembangan perangkat lunak, analisis terstruktur sering digunakan untuk memecah persyaratan pelanggan menjadi bagian-bagian yang dapat diimplementasikan oleh pemrogram perangkat lunak.[22] Logika yang mendasari program dapat direpresentasikan dalam diagram aliran data, kamus data, pseudocode, diagram transisi keadaan, dan/atau diagram hubungan entitas.[23] Jika proyek mencakup bagian dari perangkat lunak warisan yang belum dimodelkan, perangkat lunak tersebut dapat dimodelkan untuk membantu memastikan bahwa perangkat lunak tersebut diintegrasikan dengan benar ke dalam perangkat lunak yang lebih baru.[24]

Perancangan

[sunting | sunting sumber]

Perancangan mencakup pilihan mengenai implementasi perangkat lunak, seperti bahasa pemrograman dan perangkat lunak basis data yang akan digunakan, atau bagaimana perangkat keras dan komunikasi jaringan akan diatur. Perancangan dapat bersifat iteratif dengan melibatkan pengguna untuk berkonsultasi mengenai kebutuhan mereka melalui proses coba-coba. Perancangan sering kali melibatkan orang-orang yang ahli dalam aspek seperti perancangan basis data, arsitektur layar, serta kinerja server dan perangkat keras lainnya.[19] Perancang sering berusaha menemukan pola dalam fungsionalitas perangkat lunak untuk memisahkan modul-modul yang berbeda yang dapat digunakan kembali dengan pemrograman berorientasi objek. Contohnya adalah model–view–controller, yaitu antarmuka antara antarmuka pengguna grafis dan backend.[25]

Pemrograman

[sunting | sunting sumber]

Fitur utama pengembangan perangkat lunak adalah membuat dan memahami perangkat lunak yang mengimplementasikan fungsionalitas yang diinginkan.[26] Terdapat berbagai strategi untuk menulis kode. Perangkat lunak yang kohesif memiliki berbagai komponen yang independen satu sama lain.[19] Kopling adalah keterkaitan antarkomponen perangkat lunak, yang dipandang tidak diinginkan karena meningkatkan kesulitan dalam pemeliharaan.[27] Sering kali, pemrogram perangkat lunak tidak mengikuti praktik terbaik industri, sehingga menghasilkan kode yang tidak efisien, sulit dipahami, atau tidak memiliki dokumentasi mengenai fungsinya.[28] Standar-standar ini terutama cenderung tidak dipatuhi ketika terdapat tenggat waktu.[29] Akibatnya, pengujian, debugging, dan revisi kode menjadi jauh lebih sulit. Refaktor kode adalah teknik untuk menyusun ulang kode yang sudah ada tanpa mengubah perilaku eksternalnya, biasanya untuk meningkatkan perancangannya, keterbacaan, atau kemudahan pemeliharaannya.[30]

Sejak memopulerkan model bahasa besar, pengembangan perangkat lunak berbantuan AI telah digunakan untuk membantu pemrograman manusia dengan membuat AI menangani sintaks dan menulis kode.[31]

Pengujian

[sunting | sunting sumber]
Laporan cakupan pengujian dalam Clover

Pengujian adalah proses memastikan bahwa kode dieksekusi dengan benar dan tanpa kesalahan. Debugging dilakukan oleh setiap pengembang perangkat lunak terhadap kode mereka sendiri untuk memastikan bahwa kode tersebut melakukan apa yang dimaksudkan. Secara khusus, sangat penting bahwa perangkat lunak dapat dijalankan pada semua masukan, bahkan jika hasilnya tidak benar.[32] Peninjauan kode oleh pengembang lain sering digunakan untuk meneliti kode baru yang ditambahkan ke proyek, dan menurut beberapa perkiraan secara drastis mengurangi jumlah bug yang masih ada setelah pengujian selesai.[33] Setelah kode diserahkan, jaminan kualitas—yang pada sebagian besar perusahaan besar merupakan departemen tersendiri yang terdiri dari orang-orang yang bukan pemrogram—menguji ketepatan seluruh produk perangkat lunak. Aktivitas pengujian juga dapat dilakukan sepanjang siklus hidup pengembangan perangkat lunak, bergantung pada metodologi yang digunakan.[34] Pengujian penerimaan yang diturunkan dari persyaratan perangkat lunak asli merupakan salah satu alat yang populer untuk hal ini.[32] Pengujian kualitas juga sering mencakup pemeriksaan tekanan dan beban (apakah perangkat lunak tangguh terhadap tingkat masukan atau penggunaan yang tinggi), pengujian integrasi (untuk memastikan perangkat lunak terintegrasi dengan baik dengan perangkat lunak lain), dan pengujian kompatibilitas (mengukur kinerja perangkat lunak pada berbagai sistem operasi atau peramban).[32] Ketika pengujian ditulis sebelum kode, hal ini disebut pengembangan berbasis pengujian.[35]

Produksi

[sunting | sunting sumber]

Produksi adalah fase ketika perangkat lunak disebarkan kepada pengguna akhir.[36] Selama produksi, pengembang dapat membuat sumber daya dukungan teknis untuk pengguna[37][36] atau suatu proses untuk memperbaiki bug dan kesalahan yang tidak terdeteksi sebelumnya. Mungkin juga dilakukan kembali ke fase pengembangan sebelumnya jika kebutuhan pengguna berubah atau disalahpahami.[36]

Pekerja

[sunting | sunting sumber]
Pemrogram sedang bekerja

Pengembangan perangkat lunak dilakukan oleh pengembang perangkat lunak, yang biasanya bekerja dalam sebuah tim. Komunikasi yang efisien antaranggota tim sangat penting bagi keberhasilan. Hal ini lebih mudah dicapai jika tim berukuran kecil, terbiasa bekerja sama, dan berada di lokasi yang berdekatan.[38] Komunikasi juga membantu mengidentifikasi masalah pada tahap awal pengembangan dan menghindari pekerjaan yang berulang. Banyak proyek pengembangan menghindari risiko kehilangan pengetahuan penting yang hanya dimiliki oleh satu karyawan dengan memastikan bahwa beberapa pekerja memahami setiap komponen.[39] Pengembangan perangkat lunak melibatkan profesional dari berbagai bidang, bukan hanya pemrogram perangkat lunak, tetapi juga manajer produk yang menetapkan strategi dan peta jalan untuk produk,[40] individu yang berspesialisasi dalam pengujian, penulisan dokumentasi, desain grafis, dukungan pengguna, pemasaran, dan penggalangan dana. Meskipun pekerja untuk perangkat lunak proprietari menerima bayaran, sebagian besar kontributor perangkat lunak sumber terbuka adalah sukarelawan.[41] Sebagai alternatif, mereka dapat dibayar oleh perusahaan yang model bisnisnya tidak melibatkan penjualan perangkat lunak, tetapi hal lain—seperti layanan dan modifikasi terhadap perangkat lunak sumber terbuka.[42]

Model dan alat

[sunting | sunting sumber]

Rekayasa perangkat lunak berbantuan komputer

[sunting | sunting sumber]

Rekayasa perangkat lunak berbantuan komputer (CASE) adalah alat untuk melakukan otomatisasi sebagian dari pengembangan perangkat lunak.[43] CASE memungkinkan perancang membuat sketsa logika suatu program, baik program yang akan ditulis maupun program yang sudah ada untuk membantu mengintegrasikannya dengan kode baru atau melakukan rekayasa balik terhadapnya (misalnya untuk mengubah bahasa pemrograman).[44]

Dokumentasi

[sunting | sunting sumber]

Dokumentasi hadir dalam dua bentuk yang biasanya dipisahkan—satu ditujukan untuk pengembang perangkat lunak dan satu lagi disediakan bagi pengguna akhir untuk membantu mereka menggunakan perangkat lunak.[45][46] Sebagian besar dokumentasi pengembang berbentuk komentar kode untuk setiap berkas, kelas, dan metode yang mencakup antarmuka pemrograman aplikasi (API)—cara bagian perangkat lunak tersebut dapat diakses oleh bagian lain—dan sering kali mencakup rincian implementasi.[47] Dokumentasi ini membantu pengembang baru memahami proyek ketika mereka mulai mengerjakannya.[48] Dalam pengembangan Agile, dokumentasi sering ditulis bersamaan dengan kode.[49] Dokumentasi pengguna lebih sering ditulis oleh penulis teknis.[50]

Estimasi upaya

[sunting | sunting sumber]

Estimasi yang akurat sangat penting pada tahap kelayakan dan dalam menyerahkan produk tepat waktu serta sesuai anggaran. Proses menghasilkan estimasi sering kali didelegasikan oleh manajer proyek.[51] Karena estimasi upaya berkaitan langsung dengan ukuran keseluruhan aplikasi, estimasi tersebut sangat dipengaruhi oleh penambahan fitur dalam persyaratan—semakin banyak persyaratan, semakin tinggi biaya pengembangan. Aspek yang tidak berkaitan dengan fungsionalitas, seperti pengalaman pengembang perangkat lunak dan penggunaan kembali kode, juga penting untuk dipertimbangkan dalam estimasi.[52] Hingga 2019, sebagian besar alat untuk memperkirakan jumlah waktu dan sumber daya untuk pengembangan perangkat lunak dirancang untuk aplikasi konvensional dan tidak berlaku untuk aplikasi web atau aplikasi seluler.[53]

Lingkungan pengembangan terpadu

[sunting | sunting sumber]
Anjuta, IDE C dan C++ untuk lingkungan GNOME

Lingkungan pengembangan terpadu (IDE) mendukung pengembangan perangkat lunak dengan fitur yang lebih lengkap dibandingkan penyunting teks sederhana.[54] IDE sering mencakup kompilasi otomatis, penyorotan sintaks kesalahan,[55] bantuan debugging,[56] integrasi dengan pengendalian versi, dan semi-otomatisasi pengujian.[54]

Pengendalian versi

[sunting | sunting sumber]

Pengendalian versi adalah cara populer untuk mengelola perubahan yang dilakukan terhadap perangkat lunak. Setiap kali versi baru diperiksa masuk (checked in), perangkat lunak menyimpan cadangan semua berkas yang dimodifikasi. Jika beberapa pemrogram mengerjakan perangkat lunak secara bersamaan, sistem ini mengelola penggabungan perubahan kode mereka. Perangkat lunak menyoroti kasus ketika terdapat konflik antara dua kumpulan perubahan dan memungkinkan pemrogram memperbaiki konflik tersebut.[57]

Model tampilan

[sunting | sunting sumber]
Matriks Tampilan dan Perspektif TEAF

Model tampilan adalah kerangka kerja yang menyediakan sudut pandang terhadap sistem dan lingkungannya, untuk digunakan dalam proses pengembangan perangkat lunak. Model ini merupakan representasi grafis dari semantik yang mendasari suatu tampilan.

Tujuan sudut pandang dan tampilan adalah memungkinkan insinyur manusia memahami sistem kompleks dan mengatur unsur-unsur masalah berdasarkan bidang keahlian. Dalam rekayasa sistem yang intensif secara fisik, sudut pandang sering kali sesuai dengan kemampuan dan tanggung jawab dalam organisasi rekayasa.[58]

Fungsi kebugaran

[sunting | sunting sumber]

Fungsi kebugaran adalah pengujian otomatis dan objektif untuk memastikan bahwa pengembangan baru tidak menyimpang dari batasan, pemeriksaan, dan pengendalian kepatuhan yang telah ditetapkan.[59]

Kekayaan intelektual

[sunting | sunting sumber]

Kekayaan intelektual dapat menjadi masalah ketika pengembang mengintegrasikan kode atau pustaka sumber terbuka ke dalam produk proprietari, karena sebagian besar lisensi sumber terbuka yang digunakan untuk perangkat lunak mengharuskan modifikasi dirilis berdasarkan lisensi yang sama. Sebagai alternatif, pengembang dapat memilih alternatif proprietari atau menulis modul perangkat lunak mereka sendiri.[60]

Lihat pula

[sunting | sunting sumber]

Referensi

[sunting | sunting sumber]
  1. ↑ Dooley 2017, hlm. 1.
  2. ↑ Dooley 2017, hlm. 12.
  3. ↑ System Development Methodologies for Web-Enabled E-Business: A Customization Framework Linda V. Knight (DePaul University, USA), Theresa A. Steinbach (DePaul University, USA), dan Vince Kellen (Blue Wolf, USA)
  4. ↑ Dooley 2017, hlm. 8–9.
  5. ↑ Dooley 2017, hlm. 9.
  6. 1 2 Langer 2016, hlm. 2–3, 5–6.
  7. ↑ Tucker, Morelli & de Silva 2011, hlm. 8.
  8. ↑ Dooley 2017, hlm. 11.
  9. 1 2 Dooley 2017, hlm. 13.
  10. ↑ Tucker, Morelli & de Silva 2011, hlm. 41–42.
  11. 1 2 Vishnu 2019, hlm. 1–2.
  12. ↑ Laukkanen, Eero; Itkonen, Juha; Lassenius, Casper (2017). "Problems, causes and solutions when adopting continuous delivery—A systematic literature review". Information and Software Technology. 82: 55–79. doi:10.1016/j.infsof.2016.10.001.
  13. ↑ Winters, Manshreck & Wright 2020, hlm. 17.
  14. ↑ Tucker, Morelli & de Silva 2011, hlm. 6.
  15. ↑ Saif 2019, hlm. 46–47.
  16. ↑ Morris 2001, hlm. 1.10.
  17. ↑ Langer 2016, hlm. 7.
  18. ↑ Dooley 2017, hlm. 3, 8.
  19. 1 2 3 4 Langer 2016, hlm. 8.
  20. ↑ Langer 2016, hlm. 2–3.
  21. ↑ Dooley 2017, hlm. 193–194.
  22. ↑ Langer 2016, hlm. 103–104.
  23. ↑ Langer 2016, hlm. 117, 127, 131, 137, 141.
  24. ↑ Langer 2016, hlm. 106.
  25. ↑ Dooley 2017, hlm. 142.
  26. ↑ Tucker, Morelli & de Silva 2011, hlm. 31.
  27. ↑ Langer 2016, hlm. 8–9.
  28. ↑ Tucker, Morelli & de Silva 2011, hlm. 31–32.
  29. ↑ Tucker, Morelli & de Silva 2011, hlm. 34–35.
  30. ↑ "Refactoring Home Page". refactoring.com. Diakses tanggal 11 Mei 2026.
  31. ↑ Cass, Stephen (23 September 2025). "The Top Programming Languages 2025". IEEE Spectrum. Diakses tanggal 6 Mei 2026.{{cite web}}: Pemeliharaan CS1: Tanggal diterjemahkan otomatis (link)
  32. 1 2 3 Langer 2016, hlm. 9.
  33. ↑ Dooley 2017, hlm. 272.
  34. ↑ "IEEE Standards Association". IEEE Standards Association (dalam bahasa Inggris). Diakses tanggal 11 Mei 2026.
  35. ↑ Tucker, Morelli & de Silva 2011, hlm. 9.
  36. 1 2 3 Langer 2016, hlm. 10.
  37. ↑ Tucker, Morelli & de Silva 2011, hlm. 37.
  38. ↑ Dooley 2017, hlm. 2.
  39. ↑ Winters, Manshreck & Wright 2020, hlm. 30–31.
  40. ↑ "What Does a Product Manager Do? And How to Become One". Coursera (dalam bahasa Inggris). 21 Januari 2025. Diakses tanggal 5 Mei 2025.
  41. ↑ Tucker, Morelli & de Silva 2011, hlm. 7.
  42. ↑ Tucker, Morelli & de Silva 2011, hlm. 14–15.
  43. ↑ Langer 2016, hlm. 22.
  44. ↑ Langer 2016, hlm. 108–110, 206.
  45. ↑ Tucker, Morelli & de Silva 2011, hlm. 243.
  46. ↑ Winters, Manshreck & Wright 2020, hlm. 192.
  47. ↑ Winters, Manshreck & Wright 2020, hlm. 193–195.
  48. ↑ Tucker, Morelli & de Silva 2011, hlm. 143.
  49. ↑ Tucker, Morelli & de Silva 2011, hlm. 144.
  50. ↑ Winters, Manshreck & Wright 2020, hlm. 204.
  51. ↑ Saif 2019, hlm. 50–51.
  52. ↑ Saif 2019, hlm. 52–53.
  53. ↑ Saif 2019, hlm. 45.
  54. 1 2 Tucker, Morelli & de Silva 2011, hlm. 68.
  55. ↑ Dooley 2017, hlm. 236.
  56. ↑ Dooley 2017, hlm. 239.
  57. ↑ Dooley 2017, hlm. 246–247.
  58. ↑ Edward J. Barkmeyer (Februari 2003). "INSTIR 6928 - Concepts for Automating Systems Integration" (PDF). NIST. Diarsipkan dari asli (PDF) tanggal 25 Januari 2017. Diakses tanggal 21 Mei 2026.
  59. ↑ Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media. 2020. ISBN 978-1492043454.
  60. ↑ Langer 2016, hlm. 44–45.

Bacaan lebih lanjut

[sunting | sunting sumber]
  • Conde, Dan (2002). Software Product Management: Managing Software Development from Idea to Product to Marketing to Sales. Aspatore Books. ISBN 1587622025.
  • Davis, A. M. (2005). Just enough requirements management: Where software development meets marketing. Dorset House Publishing Company, Incorporated. ISBN 0932633641.
  • Dooley, John F. (2017). Software Development, Design and Coding: With Patterns, Debugging, Unit Testing, and Refactoring (dalam bahasa Inggris). Apress. ISBN 978-1-4842-3153-1.
  • Kit, Edward (1992). Software Testing in The Real World. Addison-Wesley Professional. ISBN 0201877562.
  • Hasted, Edward (2005). Software That Sells: A Practical Guide to Developing and Marketing Your Software Project. Wiley Publishing. ISBN 0764597833.
  • Hohmann, Luke (2003). Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley Professional. ISBN 0201775948.
  • Horch, John W. (Maret 1995). "Two Orientations On How To Work With Objects". IEEE Software. 12 (2): 117–118. ProQuest 215832531.
  • Langer, Arthur M. (2016). Guide to Software Development: Designing and Managing the Life Cycle (dalam bahasa Inggris). Springer. ISBN 978-1-4471-6799-0.
  • McCarthy, Jim (1995). Dynamics of Software Development. Microsoft Press. ISBN 1556158238.
  • Morris, Joseph M. (2001). Software industry accounting (Edisi 2nd). John Wiley & Sons. OCLC 53863959.
  • Rittinghouse, John (2003). Managing Software Deliverables: A Software Development Management Methodology. Digital Press. ISBN 155558313X.
  • Saif, Syed Mohsin (2019). "Software Effort Estimation for Successful Software Application Development". Dalam Vishnu, Pendyala (ed.). Tools and Techniques for Software Development in Large Organizations: Emerging Research and Opportunities: Emerging Research and Opportunities (dalam bahasa Inggris). IGI Global. hlm. 45–97. ISBN 978-1-7998-1865-6.
  • Tucker, Allen; Morelli, Ralph; de Silva, Chamindra (2011). Software Development: An Open Source Approach (dalam bahasa Inggris). CRC Press. ISBN 978-1-4398-8460-7.
  • Vishnu, Pendyala (2019). "Evolution of Integration, Build, Test, and Release Engineering Into DevOps and to DevSecOps". Dalam Vishnu, Pendyala (ed.). Tools and Techniques for Software Development in Large Organizations: Emerging Research and Opportunities: Emerging Research and Opportunities (dalam bahasa Inggris). IGI Global. hlm. 1–20. ISBN 978-1-7998-1865-6.
  • Wiegers, Karl E. (2005). More About Software Requirements: Thorny Issues and Practical Advice. Microsoft Press. ISBN 0735622671.
  • Winters, Titus; Manshreck, Tom; Wright, Hyrum (2020). Software Engineering at Google: Lessons Learned from Programming Over Time (dalam bahasa Inggris). O'Reilly Media, Inc. ISBN 978-1-4920-8276-7.
  • Wysocki, Robert K. (2006). Effective Software Project Management. Wiley. ISBN 0764596365.

Pranala luar

[sunting | sunting sumber]

Templat:Software engineering Templat:Computer science

Diperoleh dari "https://id.wikipedia.org/w/index.php?title=Pengembangan_perangkat_lunak&oldid=30073669#Angkatan_kerja"