Nezalavigne's Blog

Important Trends In Software Engineering

(Pentingnya Tren Dalam Rekayasa Perangkat Lunak)

I. Apa itu Software Engineering?
Apakah:
- Pemrograman?
- Ilmu komputer?
- Rekayasa?
- Disiplin nyata?
- Sebuah aktivitas profesional?
- Beberapa Definisi Dasar
Perangkat Lunak – Program komputer, prosedur, dan dokumentasi kemungkinan terkait dan data yang berkaitan dengan pengoperasian sistem komputer. Teknik – Aplikasi sistematis, pendekatan disiplin, diukur untuk beberapa proses. Proses Perangkat Lunak(Siklus Hidup)

• Pembangunan
• Operasi
• Pemeliharaan :
  - Korektif
  - Peningkatan

Definisi Hasil
Rekayasa Perangkat Lunak
Definisi – Penerapan sistematis, disiplin, pendekatan kuantitatif untuk pengembangan perangkat lunak, operasi dan pemeliharaan .*
* – Standar IEEE 610,12-1.990, Standar IEEE Istilah Rekayasa Perangkat Lunak Terminologi, IEEE Standar Koleksi Rekayasa Perangkat Lunak, IEEE (1997).
Mengapa kita membutuhkannya?

“Krisis Perangkat Lunak”
- Pertama kali diidentifikasi di NATO Konferensi, Garmisch, Jerman, 1968
- Ditandai oleh perangkat lunak yang
• kualitas yang buruk
• lebih dari anggaran
• terlambat
• Naur & Randell (1969)

II. Dimana Rekayasa Perangkat Lunak Hari ini?
Meskipun perbaikan yang signifikan telah dibuat dalam bidang tertentu, sifat berkembang pesat dari industri perangkat lunak telah menghasilkan peningkatan kecil dalam keseluruhan situasi keseluruhan – sebenarnya … ..

Krisis Menetap
Lebih dari 30 tahun kemudian, perangkat lunak “krisis” masih bersama kami
masalah utama adalah masih sama:
- Miskin kualitas (kebenaran, bug, kegunaan, pemeliharaan, dll)
- Lebih dari anggaran
- Terlambat dikirimkan, atau tidak sama sekali
Kualitas Perangkat Lunak Masalah
Kebenaran, bug, kegunaan, dll
- Contoh -
• Udara Komando Strategis AS alert (Nov 9, 1979) – berebut waspada dalam menanggapi laporan bahwa Uni Soviet telah meluncurkan serangan rudal
• Therac 25 akselerator linier perawatan perangkat medis – dua pasien meninggal akibat overdosis berat radiasi (1985-1987)
• Perang Teluk (1991) – US Patriot pertahanan rudal gagal mendeteksi rudal SCUD karena time error – 28 Amerika tewas sebagai akibatnya.

Jadwal / Masalah Biaya
Sebuah contoh – U. S. Internal Revenue Service
- Dipekerjakan Sperry Corporation untuk membangun pajak penghasilan bentuk sistem otomatis pengolahan (1980-1985) – sistem yang dihasilkan tidak bisa menangani beban kerja, biaya hampir dua kali lipat apa yang diharapkan, dan harus segera diganti setelah instalasi awal. Pada tahun 1996, situasi tidak membaik.

Tidak Krisis A -
Tapi A kronis Kondisi
Perangkat Lunak “Krisis” telah berlangsung terlalu panjang untuk krisis – bukan, itu kondisi, gigih kronis bisnis perangkat lunak
Rekayasa Perangkat Lunak adalah solusi yang diusulkan untuk masalah ini. Tujuannya adalah:
- Produksi perangkat lunak bebas kesalahan, dikirimkan tepat waktu dan sesuai anggaran, yang memenuhi kebutuhan pengguna, dan mudah untuk mempertahankan.
Sebuah Closer Look At The
Siklus Hidup Perangkat Lunak

• Pembangunan
• Operasi
• Pemeliharaan

Sebagian besar masalah dapat ditelusuri ke tahap Pengembangan dari siklus kehidupan, sehingga sebagian besar upaya untuk meningkatkan kinerja perangkat lunak telah difokuskan pada aspek ini.

Pengembangan Perangkat Lunak (1)
Pada hari-hari awal komputasi, pengembangan perangkat lunak dipandang sebagai hanya terdiri dari “coding”, atau pemrograman komputer
Ini adalah seni hitam, dipraktekkan oleh terampil individu, biasanya bekerja sendirian
Pendekatan ini bekerja relatif baik ketika program masih kecil & sederhana

Pengembangan Perangkat Lunak (2)
Sebagaimana sistem komputer (baik hardware dan software) telah menjadi lebih besar dan lebih kompleks, proses pengembangan perangkat lunak juga telah menjadi lebih dan lebih kompleks – dan seni sederhana “pemrograman dalam kecil” tidak lagi mampu mengatasi dengan tugas .

Pengembangan Perangkat Lunak (3)
Perubahan dalam perangkat lunak dari waktu ke waktu:
- Tumbuh dalam ukuran dari 10 atau 100 dari baris ke 1000 untuk s 1.000.000 ‘baris kode
- Lingkungan operasi berubah dari yang sederhana operasi “batch” untuk sistem multiprogramming kompleks, untuk time-sharing dan didistribusikan komputasi untuk lingkungan jaringan Internet saat ini komputasi.

Pengembangan Perangkat Lunak (4)
Hari ini, proses pengembangan perangkat lunak umumnya dianggap terdiri dari sejumlah kegiatan penting:
- Persyaratan pengumpulan dan analyis
- Desain
- Pelaksanaan (yaitu pemrograman)
- Pengujian, verifikasi, validasi
- Instalasi
- (Diikuti dengan operasi dan pemeliharaan)

Pengembangan Perangkat Lunak (5)
Penting kesimpulan –

- Proyek software pada umumnya saat ini melibatkan besar, program yang kompleks yang terlalu sulit bagi satu orang untuk menangani

- Sejumlah orang harus bekerja dalam tim dalam rangka untuk menyelesaikan setiap proyek tersebut dalam waktu yang wajar

- Keterampilan manajemen adalah sebagai penting sebagai keterampilan teknis

Pengembangan Perangkat Lunak (6)
Rekayasa Perangkat Lunak hari ini

- Mengakui bahwa proses teknis dari pengembangan perangkat lunak tidak dapat berhasil tanpa penerapan prinsip-prinsip manajemen yang baik

- Proyek perangkat lunak dapat gagal untuk alasan baik teknis atau manajerial – tapi paling sering kegagalan proyek akibat dari praktek pengelolaan yang buruk atau tidak ada.

Pengembangan Perangkat Lunak (7)
Mayoritas upaya untuk meningkatkan hasil perangkat lunak

- Rekayasa Perangkat Lunak Institute (SEI) – didirikan oleh Departemen Pertahanan AS, bersama dengan Universitas Carnegie Mellon, Pittsburgh, PA

- SEI Capability Maturity Model dikembangkan (CMM) untuk menilai kemampuan perangkat lunak

- SEI Capability Maturity Model
Kematangan Tingkat 1
Kematangan Tingkat 2
Kematangan Tingkat 3
Tingkat Kematangan 4
Tingkat Kematangan 5
Bandingkan ISO 9000 dan SPICE (Perangkat Lunak Proses Peningkatan Kemampuan dan tekad).
Terendah tingkat, ad hoc
Proses Repeatable
Ditetapkan proses
Dikelola proses

- Mengoptimalkan proses, dengan umpan balik dan perbaikan terus-menerus
CMM

Perubahan Diperlukan Untuk Pindah dari tingkat ke tingkat
Tingkat 1 Tingkat 2
Tingkat 2 Tingkat 3
Tingkat 3 Tingkat 4
Tingkat 4 sampai Tingkat 5
Proses disiplin, telp Proyek.
Proses definisi, Teknik Manajemen telp.
Proses kontrol, telp Kuantitatif.
perbaikan proses terus-menerus, telp Ubah.

- Lain Upaya Untuk Meningkatkan Kualitas Perangkat Lunak
ISO 9000 – (International Standard Organization) – 9000 standar seri, berkaitan dengan perbaikan desain, kegiatan pengembangan, produksi, tidak hanya untuk perangkat lunak
SPICE (Perangkat Lunak Perbaikan Proses penentuan Kemampuan) – sebuah inisiatif perbaikan proses internasional, lebih dari 40 negara yang terlibat
CMM, ISO 9000, SPICE – semua bertujuan untuk meningkatkan proses pengembangan perangkat lunak
- Hasil Dari Proses Perbaikan Raytheon Corp * – 1987-1992
Peningkatan upaya:
Diinvestasikan sekitar $ 1 Juta setiap tahun selama lima tahun dalam kegiatan perbaikan proses
* – IEEE Software, Juli 1993
Hasil:
- Kembali $ 7,70 pada setiap dolar yang diinvestasikan
- 130% peningkatan produktivitas
- Evolusi dari CMM Tingkat 1 sampai Tingkat 3

- – Aplikasi Dari CMM *
Penerapan CMM perangkat lunak tidak memfasilitasi perbaikan proses, biaya lebih rendah dan meningkatkan produktivitas
Kemajuan melalui tingkat kematangan CMM adalah memakan waktu dan sulit
Pencapaian Level 3 memerlukan empat tahun rata-rata
* – IEEE Software, Mei / Juni 1999

- Hari Industri Perangkat Lunak *
Sebuah laporan 1999 menunjukkan bahwa, pada tahun 1997:
- Hanya 2% dari organisasi perangkat lunak telah mencapai CMM level 4 atau 5
- Hampir 62% masih di Level 1
- Karena memerlukan sekitar 4 tahun untuk mencapai level 3, jumlah organisasi di Tingkat atas (4 & 5) masih belum besar (di 2003)
* – IEEE Software, Mei / Juni 1999

- Karakteristik Industri Perangkat Lunak Hari ini
Didorong oleh kekuatan pasar yang kuat, termasuk tekanan terus-menerus untuk memberikan perangkat lunak pada jadwal waktu yang tidak realistis
Melanjutkan Evolusi yang cepat dari metodologi perangkat lunak dan sistem
Tidak dapat mengadopsi dan memanfaatkan metodologi terbukti dalam tepat waktu
- Hari Industri Perangkat Lunak (1)
Meskipun banyak yang sekarang dikenal tentang bagaimana untuk meningkatkan produksi perangkat lunak, negara secara keseluruhan tidak jauh lebih baik dari sebelumnya *, karena urgensi pertemuan jadwal pengiriman yang tidak realistis dan evolusi secara cepat industri perangkat lunak
* – Yaitu berkualitas buruk, pengiriman yang terlambat, lebih dari anggaran
- Hari Perangkat Lunak Industri (2)
“Perangkat Lunak biaya Glitches ekonomi AS $ 59500000000 setiap tahun …”, menurut US Department Perdagangan studi baru-baru ini – sekitar 50 persen akibat pengguna, dan 50 persen karena vendor dan pengembang …. *
* – ACM TECHNews, 1 Juli 2002

- III. Kemana Software Engineering ?
Faktor penting.
Pasar tekanan
- Siklus produksi pendek, tidak realistis tanggal pengiriman
- Kekurangan personil terampil
Baru metodologi / teknologi
transfer teknologi keterbatasan
- Pasar Tekanan (1) – Pertimbangan Penjadwalan
Manajemen personel sering setuju untuk jadwal yang tidak realistis, karena tekanan pasar dan keinginan untuk “mengalahkan kompetisi”
Hasil:
- Realistis jadwal
- Belum teruji, produk cacat
- Ketidakpuasan pelanggan

- Tekanan Pasar (2) – Biaya Proyek Memperkirakan Perangkat Lunak
organisasi perangkat lunak Tercerahkan membuat peningkatan penggunaan terbukti, teknik kuantitatif untuk memperkirakan ukuran proyek, dan persyaratan yang sesuai untuk usaha dan jadwal.
Peningkatan (kuantitatif) memperkirakan membantu menghindari komitmen awal untuk tidak mungkin tanggal pengiriman yang dijadwalkan.

- Pasar Tekanan (3) – Biaya Perangkat Lunak Alat Estimasi
Banyak pendekatan, termasuk:
- Estimasi dengan analogi
- Baris kode teknik (LOC)
- Poin Fungsi metode (IFPUG)
- COCOMO model, Boehm (COCOMO II)
- Walston / Felix Model
- Pada tahun 2002, lebih dari 50 alat-alat estimasi biaya dipasarkan di AS, & 25 di Eropa
* – “Software Estimasi Biaya pada tahun 2002″, crosstalk, Juni 2002

- Tekanan Pasar (4) – Kekurangan Dari Personil Terampil
Akhir 90-an hingga 2000 – di AS, kegilaan dot.com menyebabkan kekurangan utama dari personil terampil
Solusi = lebih out-sourcing dan impor pekerja terampil
Dot.com patung 2001 + – kekurangan dihilangkan – persaingan yang meningkat di pasar dunia pengembangan perangkat lunak

- Baru Metodologi (1)
metodologi baru terus muncul, lebih cepat daripada mereka dapat secara efektif dimasukkan ke dalam penggunaan
Mayor Masalah: Bagaimana seseorang mengetahui apakah sebuah metodologi baru layak menempatkan ke dalam penggunaan? (Beberapa mungkin tidak.)
Adopsi membutuhkan investasi besar – akan ada ROI yang positif?

- baru Metodologi (2)
Pemrograman paradigma
ad hoc
fungsional
prosedural
terstruktur
berorientasi objek
pasangan pemrograman
XP (eXtreme Programming)
selanjutnya??
baru Metodologi (3)
KASUS Alat
(Computer Aided Software Engineering)
lingkungan yang kompleks Hari pemrograman memerlukan kompleks, perangkat lunak yang canggih – yang, sekali lagi, meningkatkan pertanyaan tentang biaya adopsi dan ROI (biasanya positif dalam jangka panjang, tetapi negatif dalam jangka pendek).
- baru Metodologi (4)
KASUS Alat Paradoks:
CASE tools, seperti Lingkungan Pengembangan Terpadu (IDE), seperti Visual Basic, dll, membuatnya mudah untuk mengembangkan komponen perangkat lunak – bahkan jika pengguna alat tidak memiliki pemahaman tentang konsep perangkat lunak yang mendasari => alat tersebut dapat berbahaya!

- Baru Metodologi (5)
KASUS Alat Paradox (2)
Meskipun alat-alat KASUS mengurangi jumlah usaha yang diperlukan untuk memproduksi komponen perangkat lunak, mereka benar-benar meningkatkan jumlah pengetahuan latar belakang kebutuhan pengguna untuk menggunakan alat ini aman dan efektif.

- Baru Metodologi (6)
teknik Perangkat Lunak Manajemen Proyek yang terus membaik, dan sedang diterapkan lebih efektif.
pendekatan Semakin kuantitatif, menggunakan “metrik perangkat lunak”
rencana proyek yang spesifik
kerusakan tugas rinci
perusahaan tonggak – hasil tertentu pada tanggal yang dijadwalkan
teratur ulasan dan penilaian
- Masalah Alih Teknologi *
Rekayasa teknologi cenderung mengikuti siklus 15-tahun dari konsep awal untuk aplikasi dalam lingkungan produksi
konsep pembangunan – 5 tahun
prototyping, dan penggunaan awal – 5 tahun
digunakan dalam lingkungan produksi – 5 tahun
* – Rekayasa Perangkat Lunak, Pressman, 4th ed, 835.
- Penting Tren
Perangkat Lunak Metodologi
Lingkungan Komputasi
Pendidikan Tren
- Perangkat Lunak Metodologi – UML Konferensi Dunia, 11 Juni 2001
Ivar Jacobson, salah satu dari “3 amigos” (pendiri UML) – diidentifikasi 4 tren utama dalam pengembangan perangkat lunak:
1. Komponen reusable – berhenti mengulang pekerjaan
2. Lebih up-depan pengujian – produk dengan cacat yang lebih sedikit
3. Landasan transparansi – mengurangi kompleksitas pemrograman saat ini
4. UML “semua jalan ke bawah” – yaitu otomatis menghasilkan produk akhir dari spesifikasi UML (pemrograman otomatis – tujuan waktu yang lama!)

- Metodologi Perangkat Lunak – (2)
Ivar Jacobson – “Tidak ada hambatan teknis – hanya penghalang politik …” untuk mencapai empat tujuan yang tercantum di atas. “Masalah politik adalah karena investasi besar yang telah dibuat dalam bahasa pemrograman saat ini, dan lingkungan pengembangan terintegrasi, penuh dengan compiler, debugger, pembangun GUI, dan lain-meningkatkan fitur produktivitas.”

- Metodologi Perangkat Lunak – (3)
Produktivitas / Tingkat Sukses dari pengembang perangkat lunak sangat bervariasi
Lebih pengembang sukses menggunakan cepat-bertahap-berulang teknik dimana tepat – bukan menempel ke salah satu (“air terjun/water fall”) pendekatan klasik
baru teknik dapat diterapkan berhasil dengan baik proyek-proyek kecil & besar

- Lingkungan Komputasi
Internet / Web layanan berbasis pasar
- Akan melebihi $ 50 milyar per tahun pada tahun 2005 *
- Persaingan sengit
• Microsoft. Bersih
• vs
• J2EE (Java 2 Enterprise Edition) – sedang dikembangkan dan dipromosikan oleh Hewlett-Packard, IBM, Sun Microsystems, dll
* – “Bersih Rivals ..”, USA Today (07/09/01)
- Komputasi Lingkungan (2) – Komputer / Keamanan Informasi
Beberapa laporan baru-baru ini: *

- Sebuah survei terbaru dari 300 perusahaan di Amerika Utara mengungkapkan bahwa mereka mengalami serangan virus komputer 1,2 Juta selama periode 20 bulan terakhir

- Tahun lalu (2001) serangan cyber menyebabkan sekitar $ 12 Miliar di kerusakan dan kerugian, termasuk pelanggaran dari bandara dan bendungan
* – ACMTECHNews, 03/04/02 & 05/07/02

- Komputasi Lingkungan (3) – kegiatan berbahaya lain – SPAM
Semua pengguna komputer yang sedang dibanjiri oleh pesan email yang tidak diinginkan = SPAM
Beberapa memperkirakan bahwa sampai 40% dari semua email di Internet adalah SPAM
ancaman Disengaja (virus, dll) dan SPAM yang sangat meningkatkan biaya administrasi sistem komputer
- Pendidikan Tren
Rekayasa Perangkat Lunak telah matang sebagai sebuah disiplin pendidikan
Rekayasa Perangkat Lunak -Software Enginering Body of Knowledge (SEBOK)- telah didefinisikan
BS / MS program gelar telah dimulai (1 BS / SE – Rochester Institute of Technology – 1996) – dan akan segera diakreditasi oleh ABET (AS)
- Pendidikan Tren (2)
Di masa lalu, siswa mengejar derajat di CS untuk mempersiapkan untuk pekerjaan pengembangan perangkat lunak (software engineering yaitu?)
Di masa depan, siswa mempersiapkan untuk karir dalam rekayasa perangkat lunak akan diharapkan telah mendapatkan gelar dalam SE (bukan CS) – terutama jika terakreditasi

- Pendidikan Tren (3)
Prediksi – mendekati periode panjang “penyesuaian” antara akademis “ilmu komputer” program dan akademis “rekayasa perangkat lunak” program – yang mungkin menyakitkan
Ini membawa kita kembali ke pertanyaan awal kita – “Apa itu Software Engineering?”

- Pendidikan Tren (4)
Mayoritas masalah?
Meskipun upaya awal kami untuk menyajikan definisi nyenyak berbasis “rekayasa perangkat lunak”, ada pandangan yang berbeda dari “rekayasa perangkat lunak” – seperti yang ditunjukkan dalam diagram berikut.
Oh – dan jangan lupa -
Jadi – apa pandangan Anda?
Jadi – Dimana Software Engineering Pergi?
Kendali uap depan, ke lingkungan perangkat lunak bahkan lebih kompleks, termasuk sistem yang lebih besar dan lebih kompleks, risiko keamanan yang lebih besar dan peningkatan kebutuhan untuk profesional, integritas dan kompetensi pendidikan. Sayangnya, tidak ada peta jalan definitif untuk membantu kami menemukan jalan kami.

Everald E. Mills, Ph.D. – CSSE Dept Universitas Seattle-Software Engineering-

Ketika mendengar kata software engineering, yang ada dalam pikiran sebagian orang adalah sederetan proses bernama SDLC (Software Development Life Cycle). Istilah software engineering sendiri pertama kali muncul pada tahun 1968, yaitu pada NATO Software Engineering Conference. Namun sayangnya, sejak saat itu (diperkenalkannya software engineering) sampai sekarang, pekerjaan membuat software masih saja error-prone. Berikut ini beberapa mitos (versi saya pribadi) seputar software engineering:

Code adalah implementasi

Ini mungkin pendapat yang sudah sangat umum, tapi sebenarnya masalah ini tidak dapat dianggap sepele. Ini dapat menjadi awal dari sebuah kehancuran. Ada kesalahpahaman di sini, banyak yang menyalah artikan bahwa implementasi itu ‘tinggal mengerjakan aja, sedikit pakai otak’, mirip seperti (maaf) tukang, padahal kenyataannya di dunia software tidak seperti itu. Sehingga saat ini berkembang pendapat bahwa programming (dalam hal ini coding) adalah pekerjaan yang levelnya paling ‘rendah’, bahkan untuk lulusan S1 dianggap tidak pantas berprofesi sebagai programmer. Konon, programming itu urusan lulusan SMK. Pendapat seperti ini sangat umum di Indonesia. Akan tetapi, jika Anda lihat pekerja di luar negeri, Twitter atau Google misalnya, syarat untuk menjadi programmer (coding), ada yang sampai level Phd. Mitos ini harus dibuang jauh – jauh kalau IT Indonesia mau maju. Dampak lainnya yang dapat kita lihat, gaji programmer di Indonesia tergolong rendah, ini juga akibat dari anggapan bahwa source code adalah implementasi, sehingga programmer dapat disamakan dengan (maaf) tukang, maka programmer dapat dibayar relatif rendah. Coba saja bila anggapan yang beredar dalam masyarakat adalah source code = desain, maka kondisinya akan sangat berbeda.
Pada kenyataannya, sebenarnya source code itu adalah desain, hanya saja dia memeiliki level abstraksi yang beragam (ada yang tinggi dan ada pula yang rendah). Kita bisa saja membuat suatu source code dengan level abstraksi yang lebih tinggi daripada diagram UML sekalipun. Jadi, source code sebenarnya adalah dokumen desain, dia memiliki representasi berupa teks. Sedangkan dokumen desain lainnya yang cukup populer adalah UML, yang memiliki representasi berupa grafis.

Proses analisis kebutuhan dan desain tidak mempedulikan implementasi

Ini anggapan yang dapat berakibat fatal, menyebabkan kegagalan perangkat lunak. Kalau kita bandingkan dengan engineering lain, mungkin dapat dianalogikan seperti merancang alat elektronika tanpa mempedulikan hukum fisika.
Misal, seorang arsitek atau desainer perangkat lunak disuruh membuat aplikasi bioinformatika untuk membuat simulasi DNA. Kalau dia tidak mempedulikan implementasi, bagaimana mungkin dia akan menghasilkan desain suatu perangkat lunak yang dapat bekerja dengan baik pada komputer performa tinggi, baik dengan arsitektur GPU (misal nVidia Tesla), CPU (misal Intel Xeon), maupun campuran keduanya, yang notabene ketiganya memiliki arsitektur dan teknik pemrograman yang sangat berbeda. Karena ketiga arsitektur prosesor tersebut sangat berbeda, maka membutuhkan analisis dan desain yang sangat berbeda juga.
Hal lain yang mungkin terjadi adalah biaya pembuatan software menjadi sangat mahal, termasuk karena software yang dihasilkan tidak efisien sehingga kebutuhan akan hardware meningkat.

Dokumen perangkat lunak hanyalah analisis kebutuhan (spesifikasi) dan desain

Ini adalah salah satu akibat dengan kesalah pahaman dalam memahami bahwa source code adalah implementasi (lihat poin 1). Sejatinya source code juga termasuk dokumen analisis dan desain perangkat lunak, hanya saja pada umumnya dia memiliki level abstraksi yang lebih rendah.
Mempelajari “konsep pemrograman”, otomatis menguasai berbagai bahasa pemrograman

Ini salah satu upaya mencari ’silver bullet’. Seperti matematika, untuk menghitung luas persegi, anda dapat menggunakan perkalian, penjumlahan (sigma), atau integral. Perkalian, penjumlahan, dan integral merupakan bahasa matematika. Dengan mempelajari konsep menghitung luas dengan perkalian, tidak akan menjamin anda dapat menguasai konsep menghitung luas dengan menggunakan metode penjumlahan (sigma) atau integral. Jadi setelah mempelajari konsep menghitung luas dengan perkalian, kita tidak bisa berkata bahwa: “Saya telah menguasai konsep menghitung luas, apapun metodenya”. Demikian pula pada pemrograman, dengan mempelajari suatu bahasa tertentu, tidak ada jaminan dapat mengerti bahasa lainnya. Yang perlu dicatat, dalam pemrograman, konsep pemrograman tidak memonopoli ‘pemberian pengaruh’, justru sering kali bahasa pemrograman-lah yang memengaruhi konsep pemrograman, sehingga melahirkan konsep-konsep baru. Bahasa pemrograman dan konsep pemrograman merupakan dua hal yang tidak terpisahkan.

Perangkat lunak itu abstrak, tidak nyata. Sehingga software engineering berbeda dengan engineering lainnya

Ini biasanya menjadi ‘kambing hitam’ atas payahnya kualitas software engineering saat ini. Kalau kita telusuri, justru software engineering itu berhadapan dengan sesuatu yang sangat nyata. Kita dapat mengetahui perilaku software yang kita buat sampai pada level yang paling kecil, yaitu kode mesin. Kita tidak perlu melakukan prediksi atau eksperimen terhadap perilaku dari kode mesin tersebut, karena itu sudah pasti, kode tersebut akan dieksekusi sesuai desain arsitektur prosesor yang digunakan, kecuali ada kesalahan pada hardware. Justru engineering lainnya (engineering klasik), yang ‘dianggap berhubungan dengan BENDA NYATA’, tidak memiliki kelengkapan informasi seperti ini. Seperti kita tahu bahwa sampai sekarang para ilmuan masih belum menemukan kepastian terhadap bagian terkecil dari materi, ada berbagai teori yang muncul, seperti yang dipelajari dalam fisika kuantum, string theory, dan m-theory. Justru engineering klasik itulah yang sebenarnya bermain dengan hal yang tidak nyata, karena tidak semua informasi yang tersedia telah diketahui. Sehingga engineering klasik lebih sering melakukan eksperimen daripada software engineering. Sedangkan eksperimen pada software engineering mungkin hanya dilakukan saat stress test atau pengukuran kinerja, reliabilitas, dan skalabilitas. Ini semakin memperjelas, bahwa sebenarnya eksperimen dalam software tersebut dilakukan ketika berhubungan dengan hardware, yaitu berkaitan dengan performa prosesor, memory, I/O, dsb. Akan sulit memprediksi secara akurat penurunan kinerja prosesor atau memory pada kondisi tertentu (misal suhu tertentu), kecuali melalui eksperimen. Sedangkan source code, yang menjadi inti dari software, itu sudah sangat nyata, tidak ada yang abstrak, walaupun tidak kasat mata, perilakunya dapat ditentukan secara pasti tanpa perlu melakukan eksperimen.

*http://agilini.us/2011/05/08/mitos-seputar-software-engineering/ini hanya pendapat pribadi, tidak untuk dijadikan referensi