Software Engineering


Masa depan Software Engineering

1. Intro

Apa masa depan Software Engineering? Untuk proyek masa depan, kita harus memahami-masa lalu dan saat ini juga. Mengetahui masa lalu dan saat ini akan menunjukkan di mana kita berada dan juga akan menyarankan momentum yang akan mendorong kita ke depan. Dari tulisan iini  berpendapat, bahwa kita disarankan untuk tidak membiarkan arah masa depan kita akan ditentukan semata-mata oleh kekuatan-kekuatan eksternal. Keputusan yang kita buat untuk diri kita sendiri dan diri kita juga harus mempunyai kekuatan utama yang membimbing kita ke depan.

Dengan demikian, struktur dari tulisan ini adalah sebagai berikut:

  1. ringkasan singkat tentang sejarah Software Engineering, yang mengarah ke upaya untuk menggambarkan posisi dan situasi kita saat ini. Tulisan ini hasil  diskusi tentang berbagai tren saat ini, dan dampak potensial atas disiplin Software Engineering.
  2. Tulisan ini diakhiri dengan sebuah permohonan untuk introspeksi masyarakat dalam bentuk penelitian yang digerakkan oleh rasa ingin tahu, menyarankan perlunya forum untuk menetapkan tujuan dan arah untuk masa depan, terutama karena diterangi oleh pertimbangan masa lalu dan kini.

Masa depan Software Engineering harus di tangan kita sendiri. Tapi mungkin membutuhkan beberapa pro aksi dan tekad untuk meraihnya.

2. Masa lalu

Kebanyakan pengamat akan setuju bahwa Software Engineering dimulai sebagai suatu disiplin dalam akhir 1960-an dikenal dengan “Pertemuan NATO ” [3, 121]. Namun, pada kenyataannya, software sedang dikembangkan dan direkayasa untuk setidaknya 15 tahun sebelum pertama konferensi ini. Konferensi, bagaimanapun, kegiatan ini memberikan nama, “Software Engineering”, dan tujuan utama, yaitu berkaitan dengan “Software Krisis”. Peserta di pertemuan tersebut tokoh senior dalam komputasi. Dalam bahwa mereka menemukan seperangkat kemiripan yang luar biasa dalam masalah bahwa mereka mengalami kesulitan menangani, sehingga mereka legitimatisi Software Engineering sebagai studi dari berbagai masalah yang dihadapi dalam pengembangan software.

Presentasi dan diskusi pada tahun 1968 Konferensi NATO berkisar lebih dari satu set topik, beberapa di antaranya sepertinya tidak lagi relevan. Sebagai contoh, perdebatan tentang apakah software harus terpisah dari hardware [12, hal. 129-1351],  telah sejak lama telah diselesaikan.

Lain topik utama pembicaraan pada tahun 1968 adalah kualitas perangkat lunak. Llewelyn dan Wickens [9] terfokus pada masalah pengujian secara umum. Pinkerton [181] ditujukan pendekatan terhadap masalah pengujian kinerja. Ini dilengkapi dengan diskusi yang cukup sepanjang pertemuan peran pendekatan matematika lebih untuk penalaran tentang perangkat lunak untuk menjamin kebenaran dan kualitas lainnya.

Namun topik diskusi yang lain adalah sifat desain, perannya dalam proses pengembangan perangkat lunak secara keseluruhan, dan kaitannya dengan coding [12, hal. 35-65]. Semua masalah ini tetap sebelum masyarakat kita saat ini, dan terus menjadi subyek penelitian yang sedang berlangsung dan diskusi. Tanggapan pelopor awal Software engineering adalah untuk memahami masalah ini dengan penuh semangat dan mulai mencari cara untuk mengatasinya. bahasa pemrograman yang lebih baik telah diusulkan dan dievaluasi. Alat untuk mendukung pengujian telah dilaksanakan, dan dilengkapi dengan metode analisis yang lebih formal, semua ditujukan untuk mengukur dan meningkatkan kualitas.

Perlu adanya upaya pengakuan yang cukup sebelum coding. Pentingnya persyaratan ditekankan, dan posisi dari kegiatan ini di siklus pengembangan software yang lebih besar hidup didirikan. Pentingnya manajemen efektif pembangunan mengarah pada pembentukan metrik software, dan upaya untuk menggunakannya untuk memandu proses pembangunan.

Penting untuk dicatat bahwa banyak dari upaya-upaya penelitian membawa perbaikan penting dalam Software engineering yang telah dipraktekkan. Dalam banyak kasus, dampak dari penelitian telah tidak langsung, dan dalam hampir semua kasus, dampak telah mengambil waktu lama untuk putus asa dilihat dan dirasakan. Tapi dampak telah dirasakan, dan dapat menunjukkan, serta akan rumit setelah lama.

Di sisi lain, upaya despire kuat selama 40 tahun terakhir, banyak masalah tahun 1968 pada dasarnya tetap belum terpecahkan. Pasti ada telah memuaskan kemajuan di berbagai bidang seperti perbaikan bahasa pemrograman, perangkat lunak pendekatan pengujian, dukungan untuk precoding tahap pengembangan, dan metrik perangkat lunak. Tapi di daerah masing-masing solusi saat ini di tangan jauh Mulai dari memadai untuk memecahkan masalah yang dihadapi pengembang perangkat lunak. Perlis komentar yang dibuat pada tahun 1968, dikutip dalam pembukaan untuk makalah ini, adalah, bahkan saat ini, karakterisasi wajar situasi yang kita hadapi sebagai insinyur perangkat lunak. dekade diidentifikasi demikian, kegigihan keras kepala masalah pertama yang lalu telah jelas menyebabkan frustrasi. Tetapi telah semakin juga menyebabkan kecurigaan yang berkembang bahwa masalah-masalah yang mungkin akan manifestasi isu yang jauh lebih dalam dan lebih mendalam.

Pergeseran konseptual memungkinkan pembentukan hukum ketat gerak planet yang, pada gilirannya, menyebabkan penyederhanaan masalah substansial seperti memprediksi posisi planet dan menetapkan kalender handal.

Dalam cara yang sama, kami mencatat bahwa insinyur software selama beberapa dekade terakhir juga semakin memandang kegigihan masalah keras kepala sebagai indikator kebutuhan untuk riset fundamental bahwa probe sifat masalah yang lebih dalam. Jadi, misalnya, evolusi perangkat lunak diakui sebagai masalah sentral setidaknya selama lalu sebagai selama konferensi, NATO 1968 di mana kebutuhan untuk bermigrasi perangkat lunak dalam menanggapi perubahan perlu diidentifikasi sebagai masalah utama rekayasa perangkat lunak. Berbagai alat dan sistem untuk mengatasi masalah ini dibangun dan dievaluasi. Tapi perlawanan keras kepala masalah ini untuk berbagai solusi upaya akhirnya membuat para peneliti awal seperti Parnas [16] untuk mencari masalah yang lebih dalam dan pada akhirnya menyarankan pendekatan seperti pelaksanaan-sembunyi, dan ucapan dari dalam konsep modularitas. Eksplorasi sifat modul, dan penggunaannya dalam meningkatkan efektivitas pengembangan perangkat lunak, juga ditujukan oleh orang lain (mis. [7 8]),. Dan telah memimpin selama bertahun-tahun untuk sebuah spektrum perbaikan untuk berlatih.

Dalam contoh ini, kita melihat sebuah ilustrasi bagus dari dualitas, dan saling penguatan, dari konseptualisasi pemecahan masalah dan teoritis. Masalah dalam evolusi software akhirnya dilihat sebagai gejala perlunya pendekatan yang lebih disiplin ke pengembangan perangkat lunak, terpusat di sekitar pengakuan dari kebutuhan untuk implementasi modul-bersembunyi. Suatu periode penelitian konseptual diikuti, di mana ada perhatian dibayar untuk memahami sifat dari sebuah modul, untuk mendefinisikan modul ketat, dan untuk mendukung implementasi modul dan penggunaannya dalam evolusi.

Konsep dasar, dan dasar itu disediakan untuk pengembangan alat-alat yang lebih efektif, menyebabkan pendekatan yang lebih efektif untuk evolusi perangkat lunak, dan juga perbaikan lainnya. Penting untuk dicatat bahwa dalam contoh ini, seperti dalam beberapa contoh lain yang dapat dikemukakan, masalah berasal dari domain praktek. Komunitas riset memahami pentingnya dari masalah, menemukan hal yang menarik, dan membuatnya menjadi bagian dari agenda penelitian masyarakat. Pemahaman masalah mendasar adalah dicapai sebagai konsekuensi dari penelitian konseptual mendasar, yang pada gilirannya menyebabkan peningkatan dalam praktek. Sejarah Software engineering berisi sejumlah ilustrasi dari dualitas.

Memang, tampaknya sangat menarik untuk dicatat bahwa editor konferensi NATO 1969 telah mencatat bahwa nada menekankan bahwa konferensi kedua masalah tumbuh dari kesenjangan perangkat lunak “” antara teori dan praktek. Proses fitur komentar panjang dari Strachey [23] yang berfokus pada keberadaan divisi yang kuat antara mereka yang benar-benar membangun sistem perangkat lunak besar, dan mereka yang akan mencoba untuk membantu dengan ide-ide riset dan pendekatan. Strachey dan lain-lain di konferensi tersebut menekankan perlunya saling pengertian yang lebih besar antara masyarakat praktek pengembangan perangkat lunak dan perangkat lunak penelitian (teori). Tentu saja tema ini telah bergaung melalui beberapa dekade yang telah terjadi, dan untuk situasi kita saat ini.

Tampak jelas bahwa agenda untuk penelitian rekayasa perangkat lunak dasar di masa lalu didorong kuat oleh studi tentang masalah yang timbul dalam praktek, dan kemajuan dalam praktek sering manfaat besar dari hasil penelitian. Ini terus menjadi kasus saat ini. Semua ini harus sama sekali mengejutkan, karena sangat sejalan dengan pengalaman di daerah lain seperti kedokteran, fisika, dan kimia. Dalam beberapa hal penting, pengakuan tentang bagaimana untuk mengeksploitasi interaksi antara penelitian dan praktek berdiri sebagai pilar utama dari Rekayasa Perangkat Lunak hari ini.

Tampaknya penting untuk dicatat bahwa studi kasus cara di mana pengembangan perangkat lunak praktek dan penelitian rekayasa perangkat lunak telah melengkapi satu sama lain, untuk kepentingan kedua, sedang dilaksanakan sebagai titik fokus Dampak Proyek [14]. Studi Dampak Proyek ini diketahui bahwa dampak dari penelitian atas praktek cenderung tidak langsung, dan bahwa hasil penelitian jarang bergerak cepat dan langsung dari laboratorium penelitian untuk praktek industri. Kedua peneliti dan praktisi harus terus bekerja untuk memperbaiki situasi ini. Tetapi juga penting untuk menyadari bahwa temuan penelitian tidak jarang menjadi sumber perubahan dan inovasi dalam industri, mempengaruhi agenda untuk perbaikan dalam praktek maka pasti studi tentang praktek industri yang telah mempengaruhi agenda penelitian.

Perangkat Lunak Manajemen Konfigurasi (SCM) menyediakan satu contoh yang sangat spesifik. Dalam pengembangan SCM ditelusuri dari awal awal. SCM tumbuh dari kebutuhan untuk mendukung manajemen proyek pengembangan perangkat lunak yang semakin kompleks diperlukan kerjasama dari banyak orang, dan perakitan dari sejumlah besar objek perangkat lunak, sering membutuhkan penerapan urutan alat dan sistem. konseptualisasi yang jelas tentang hakikat masalah ini berasal dari studi yang cermat dari masalah yang mendasari. Ini menyebabkan sistem SCM awal. ketidakmampuan mereka diamati dari aplikasi mereka dalam praktek, yang mengarah ke siklus lain studi, pemahaman, dan perbaikan. Dampak lain Proyek studi yang mengarah ke kesimpulan yang sama, yaitu bahwa penelitian dan praktek saling mendukung, dan bahwa interaksi lanjutan antara dua bidang usaha tampaknya paling efektif dalam memimpin untuk perbaikan lanjutan dalam praktek, serta pemahaman lanjutan dari isu-isu yang lebih dalam .

3. Saat Ini

Hal tersebut di atas membantu menjelaskan sifat ganda Software Engineering saat ini. Ini mencakup dua komplementer, saling mendukung, jenis kegiatan, yaitu pengembangan alat dan teknologi untuk secara langsung menjawab masalah praktis hari itu, dan mencari pemahaman yang lebih dalam yang dapat memberikan dasar untuk alat yang lebih efektif dan teknologi. Seperti ditunjukkan di atas, sinergi antara kedua jenis kegiatan telah efektif di masa lalu. Memang, sudah diperlukan. Ada kebutuhan yang jelas untuk mengembangkan teknologi pengembangan perangkat lunak, seperti sudah ada kebutuhan akan teknologi berurusan dengan listrik, bahan kimia, mesin, dan pesawat terbang.

Dalam kasus Software Engineering, Namun, ini belum mungkin, karena tidak ada ilmu-ilmu yang ada tampaknya memberikan dasar yang memuaskan atas suatu teknologi yang efektif bagi rekayasa perangkat lunak. Jelas Matematika, terutama Matematika menawarkan banyak hal, tetapi begitu juga Sosiologi, Manajemen, Psikologi, dan Epistemologi. Jadi, kami telah mengembangkan dasar kita sendiri dalam sains, menggambar penting pada berbagai disiplin ilmu yang ada, dan sintesis sebagai tampaknya berguna. Akibatnya, kita telah melihat perkembangan di Software.

Teknik kedua kegiatan yang bersandar terhadap pengembangan teknologi, dan kegiatan yang bersandar terhadap penyelidikan ilmiah. Hasilnya telah menyebabkan beberapa keberhasilan penting. Masyarakat Software Engineering harus bangga dengan fakta bahwa Pengembangan software sekarang menjadi salah satu kekuatan terdepan di dunia ekonomi.

Total nilai produk pengembangan software dan jasa tentu harus diukur setidaknya dalam ratusan Milyar (US) dolar setiap tahunnya.

Pengembangan software dipandang sebagai industri yang dapat membawa kekayaan bangsa-bangsa, perusahaan, dan individu di seluruh dunia. Selain itu, software sekarang mendorong aplikasi dalam hampir semua bidang usaha manusia.

Aplikasi tradisional software untuk masalah di daerah-daerah tradisional seperti bisnis dan komunikasi, misalnya, sekarang dilengkapi dengan penggunaan penting dari software dalam kedokteran, transportasi, dan bahkan seni dan hiburan. Tentu saja keberhasilan pengembangan komunitas software dalam tantangan pertemuan yang diajukan oleh daerah-daerah tersebut beragam harus dilihat sebagai kemenangan bersejarah dimensi.

Meskipun keberhasilan harus dikreditkan paling langsung kepada komunitas praktisi, itu akan menjadi kesalahan untuk mengabaikan kontribusi penelitian Software Engineering. Volume besar dari kode yang diperlukan untuk memenuhi tantangan tersebut, misalnya, tidak dapat harus dikelola tanpa teknologi seperti Manajemen Konfigurasi, dan studi dampak-Proyek, seperti yang tercantum di atas, menunjukkan kontribusi yang sangat diperlukan penelitian di daerah tersebut. Bahasa software superior, pendekatan manajemen, pengujian alat, dan metode pemodelan semua memainkan peran yang sama penting. Dan dalam masing-masing daerah penelitian rekayasa perangkat lunak terus memberikan wawasan penting, prototip, dan analisis yang membantu praktek bergerak maju. Dokumentasi dari kontribusi dari penelitian di bidang ini juga dapat ditemukan dalam tambahan studi Dampak Proyek [7].

Adalah penting untuk menekankan, bahwa penelitian Software Engineering terus dilakukan untuk mendapatkan manfaat simetris dari kontak dengan masyarakat praktik pengembangan software. Komunitas pembangunan membawa kepada masyarakat banyak penelitian masalah yang pertimbangan terus memimpin ke daerah-daerah baru yang penting dari penelitian. Memang aliran masalah baru dari komunitas praktek telah terus-menerus melayani untuk memberi energi dan meremajakan komunitas penelitianSoftware Engineering. Energi yang bisa dirasakan melalui sejumlah besar dan beragam lokakarya, simposium, dan konferensi sekarang diselenggarakan lebih atau kurang terus-menerus di seluruh dunia. Ada juga sebuah arsip besar dan berkembang makalah penelitian yang dipublikasikan dalam kumpulan majalah dan jurnal yang juga terus tumbuh dalam ukuran dan ruang lingkup. Singkatnya, tampaknya indikator penting kesehatan dan kesuksesan bagi masyarakat kita semua sudah sangat kuat namun terus membaik.

4. Salah satu melihat masa depan

Gambar saat ini, dengan demikian, masyarakat rekayasa perangkat lunak tampaknya menjadi salah satu kesehatan yang kuat, dengan penelitian dan berinteraksi praktek rentang memperluas untuk kepentingan baik, dan untuk society.In masa lalu kami telah mengembangkan gagasan-gagasan seperti modularitas dan enkapsulasi untuk memungkinkan kita untuk menghasilkan jumlah yang lebih besar dari instruksi mesin dari setiap baris kode sumber tertulis. Kami sekarang mampu menghasilkan sistem yang terdiri dari ratusan jutaan instruksi. Kami telah merancang pengertian seperti Manajemen Konfigurasi Software, Software Produk Lines, Software Test Automation, dan Lingkungan Pengembangan Perangkat Lunak, dan telah menghasilkan alat-alat dan sistem untuk mendukung mereka. Ini telah memungkinkan pengembangan industri perangkat lunak global untuk bidang sistem besar dan kompleks, untuk menjaga mereka di lapangan, dan mereka berkembang di laboratorium pengembangan.

Tekanan dan insentif untuk melanjutkan dengan cara ini sangat kuat, dan tampak tumbuh. Ukuran dan kompleksitas sistem perangkat lunak yang dituntut oleh masyarakat terus tumbuh (persis seperti yang dicatat oleh Perlis pada tahun 1968). Lebih besar dan jaringan yang lebih kompleks, kehidupan yang lebih aplikasi kritis, meningkatkan kepedulian terhadap privasi dan keamanan, semua menciptakan tantangan baru, memerlukan penelitian ke daerah baru, dan melayani untuk hrther energi komunitas riset. Kesuksesan kami dalam memenuhi tantangan teknis di masa lalu emboldens kita untuk menghadapi tantangan-tantangan baru. Dengan demikian, penelitian rekayasa perangkat lunak semakin meneliti tantangan seperti belajar keamanan dan privasi di embedded system, dan cara untuk menentukan berbagai perilaku yang mungkin dari sistem dibangun dari komponen didistribusikan, bahkan ketika kode sumber untuk beberapa komponen tidak dapat diakses. domain baru lain dari investigasi sekarang di cakrawala dan bergerak mendekat. Kami mencatat, misalnya, meningkat tajam dalam kepentingan dalam perangkat lunak yang digunakan dalam, medis 22 [mekatronika] dan domain otomotif [20]. Beberapa tantangan yang dihadapi dalam domain ini tampaknya relatif akrab, dan setuju dengan pendekatan bahwa masyarakat kita sudah dikembangkan. tantangan lain akan memerlukan kecerdikan, dan marshalling teknologi dan wawasan ilmiah dari domain lain (mis. sistem realtime, teknologi database, interface manusia-komputer, dll). Selain itu, tampak jelas bahwa rekayasa perangkat lunak akan memiliki banyak keuntungan dari satu set lebih intim interaksi dengan para peneliti dalam ilmu tradisional, khususnya Biologi. Hal ini semakin jelas bahwa urutan DNA menentukan objek dan proses yang membuat organisme hidup bekerja dengan cara yang mereka lakukan. Para ilmuwan Hidup semakin mencoba untuk memahami perilaku skala besar perangkat (mis. organisme hidup) dengan melihat pengkodean tentang pekerjaan mereka tingkat rendah. Dengan cara ini, mereka membutuhkan keterampilan dan teknologi yang telah Rekayasa Perangkat Lunak untuk berjuang dengan dekade. keahlian teknologi kami dapat membantu penelitian Ilmu Kehidupan. Sebaliknya, sifat perangkat ditentukan oleh urutan DNA jauh melebihi kompleksitas sistem perhitungan yang kami bangun dan belajar di masa lalu. Kita perlu belajar banyak dari ilmuwan bergabung Hidup di mencoba memahami (dan mengubah) sistem yang mereka berhubungan dengan. Memang, semakin jelas bahwa sebagian besar ilmu-ilmu tradisional yang membuat peningkatan penggunaan komputasi dan pemodelan komputasi sebagai alat untuk mengejar riset mereka. Masalah yang mereka hadapi tampaknya memiliki potensi untuk merangsang pertumbuhan dalam penelitian rekayasa perangkat lunak, banyak cara bahwa masalah yang dihadapi oleh bisnis dan industri telah menyediakan komunitas kami dengan inspirasi penelitian di masa lalu.

Dengan demikian, tampak jelas bahwa baik tradisional dan komunitas baru praktek akan terus mendorong kita untuk berinteraksi dengan mereka. Mode dan mekanisme interaksi dengan komunitas-komunitas telah dibentuk, dan tentu akan disesuaikan dan berevolusi untuk mendorong interaksi semakin produktif di masa depan. Tampaknya penting untuk mempertimbangkan, bagaimanapun, apakah arah adalah masa lalu yang cocok untuk masa depan. Secara khusus, pengembangan penyelidikan ilmiah dalam Rekayasa Perangkat Lunak di masa lalu tampaknya telah didorong terutama dengan pertimbangan masalah praktis yang timbul dari luar komunitas kita sendiri. Kami telah memperoleh keuntungan nyata dari ini. Tapi apakah itu tampak wajar dan sesuai bagi masyarakat kita untuk melihat terutama di luar komunitas untuk sumber inspirasi penelitian?

5. Pandangan yang berbeda dari masa depan

Ini mungkin saatnya bagi masyarakat Rekayasa Perangkat Lunak untuk mundur, memeriksa lintasan itu telah mengikuti selama dekade terakhir, dan berpikir tentang apakah lintasan mungkin diubah atau ditambah. Kami telah mencatat bahwa disiplin ilmu dewasa seperti Fisika, Biologi, dan Kimia semua tampaknya telah muncul dari praktik yang semakin rumit dan efektif untuk menangani masalah yang timbul dari kesulitan dunia nyata. Meskipun berbagai praktik menjadi semakin efektif dalam menangani masalah ini, yang tumbuh keberhasilan semakin disorot dan terbatas wilayah di mana keberhasilan kurang dapat diprediksi dan dapat diandalkan. Dengan demikian, praktek penyembuhan penyakit yang timbul dari bakteri ditingkatkan secara dramatis dengan ditemukannya antibiotik. Tapi, penyakit virus benar-benar resisten terhadap pendekatan ini. Kurangnya keberhasilan mencolok menyebabkan penyelidikan sifat virus dan pembukaan besar pandangan baru penyelidikan ilmiah dan penemuan. Dalam cara yang sama, kesuksesan awal di metalurgi dibatasi kegagalan beberapa daerah, yang mengarah ke pembukaan daerah baru kimia. Apakah sudah waktunya untuk Software Engineering, saat mengambil bangga dengan apa yang telah kita lakukan sehingga berhasil di masa lalu, sekarang melangkah mundur dan membatasi daerah yang memiliki terus menolak upaya kami yang terbaik, dan untuk melihat apakah sifatnya menyelidik dapat membuka daerah-daerah baru yang besar dan penting dari penelitian ilmiah? kesuksesan masa lalu kita dalam menangani masalah yang timbul & om domain dari praktek bisa dilabeli sebagai penelitian masalah-driven. mungkin sudah saatnya untuk menambah jenis penelitian dengan jenis penelitian yang saling melengkapi kita harus memanggil penelitian rasa ingin tahu-driven. Sedangkan tujuan penelitian masalah-mungkin didorong untuk kembali ke dunia nyata solusi untuk masalah yang dihadapi di sana, dan untuk menjawab pertanyaan-pertanyaan yang timbul di sana, tujuan penelitian didorong rasa ingin tahu-adalah untuk mengidentifikasi pertanyaan-pertanyaan yang bersifat lebih dalam. Biasanya pertanyaan-pertanyaan tersebut berasal dari benak para peneliti setelah panjang dan serius bergulat dengan masalah-masalah dunia nyata. Jadi, misalnya, ahli biologi akhirnya menyimpulkan bahwa, daripada berusaha untuk memahami mengapa antibiotik tidak membantu dengan daftar panjang penyakit, mungkin akan lebih tepat daripada mencoba memahami apa penyakit seperti itu mungkin memiliki kesamaan dalam rangka untuk merancang abroader pendekatan untuk semua itu. Perbedaannya di sini adalah bahwa inisiatif untuk pembentukan arah riset seperti ini datang langsung dari para peneliti di masyarakat, dan hanya secara tidak langsung dari para praktisi dalam domain tersebut.

Jadi, ada dua alasan-alasan penting untuk penelitian rasa ingin tahu-driven. Salah satunya adalah bahwa jenis penelitian mempunyai potensi untuk mengatasi berbagai masalah di berbagai, daripada masalah individu yang terpisah. Yang lainnya, bagaimanapun, adalah bahwa dalam mengejar penelitian didorong rasa ingin tahu, komunitas riset merebut kontrol langsung terhadap arah yang akan mengambil-hal mengambil kendali dari agenda sendiri.

Mahoney [lo] telah mengamati bahwa ini adalah definisi yang sangat disiplin ilmu dewasa. Kita bisa membawa Alasan ini bersama-sama dengan pengamatan tunggal yang jatuh tempo disiplin ilmu tampaknya semuanya berpusat sekitar studi mereka dari inti mendalam dan pertanyaan-pertanyaan abadi yang telah melanggar resolusi yang memadai untuk waktu yang lama (mungkin abad), tapi yang terus mengejar mantap telah menyebabkan temuan tak terhitung bunga dan pentingnya.

Memang, tampaknya bahwa identifikasi dari pertanyaan-pertanyaan ini, dan sifat sulit dipahami dari resolusi mereka yang mencirikan disiplin yang sangat dihormati ilmiah dewasa seperti Fisika, Astronomi, dan Biologi. Jadi, misalnya, Fisika terus mencoba untuk memahami sifat materi dan energi, dan hubungan mereka satu sama lain. Astronomi berusaha untuk memahami asal usul alam semesta. Biologi berusaha untuk memahami apa hidup ini, dan bagaimana organisme hidup bekerja. Tidak ada yang mengharapkan jawaban yang cepat dan mudah untuk pertanyaan-pertanyaan ini, tetapi mempelajari banyak konsekuensi dan manifestasi dari pertanyaan-pertanyaan tersebut telah menyebabkan pertumbuhan disiplin-disiplin, dan rasa hormat yang telah mereka usahakan. Tidaklah penting untuk mengamati bahwa pertanyaan-pertanyaan ini tidak datang dari praktisi mencari bantuan dengan masalah segera mereka. Sebaliknya mereka datang dari pikiran peneliti mencari pemahaman pemersatu yang dapat membantu dalam menangani masalah rentang.

Mungkin sudah saatnya untuk merangkul Rekayasa Perangkat Lunak pentingnya dan ketepatan waktu penelitian yang digerakkan oleh rasa ingin tahu, sebagai pelengkap untuk penelitian masalah-driven yang telah mendorong kami di masa lalu, dan harus terus menjadi sopir di masa depan. Mungkin sudah waktunya untuk rekayasa perangkat lunak untuk mencari pertanyaan-pertanyaan yang mendalam dan abadi yang dapat berguna untuk mendefinisikan kita sebagai suatu disiplin ilmu, sementara juga mengarah pada pemahaman fundamental yang dapat mendukung solusi yang lebih efektif untuk masalah-masalah yang timbul dalam praktek. Mungkin sudah saatnya bagi kita untuk mencurahkan kurang energi kami untuk mencari jawaban atas pertanyaan yang diajukan oleh orang lain, dan lebih banyak waktu dan energi untuk mencari sendiri didorong rasa ingin tahu-pertanyaan.

6. Beberapa pertanyaan

Ini akan lalai jika tulisan ini tidak setidaknya menyarankan beberapa contoh pertanyaan-didorong rasa ingin tahu yang mungkin melayani masyarakat penelitian rekayasa perangkat lunak.

Meskipun tidak tujuan tulisan ini pendek untuk bersikeras atas kesesuaian pertanyaan-pertanyaan yang tepat, dan dengan demikian usaha untuk menentukan arah untuk penelitian rekayasa perangkat lunak, tampaknya tepat untuk setidaknya mencoba untuk memberikan beberapa contoh yang mungkin bahan untuk dipikirkan . Dalam semangat itu, berikut ini adalah yang disarankan:

6.1. Pertanyaan: Apa itu desain (kata benda)? Dan bagaimana seharusnya hal itu dilakukan (verba)?

Seperti disebutkan di atas, pertanyaan-pertanyaan ini memang dibesarkan di konferensi NATO. Memang pada waktu itu Sekarang menyarankan bahwa “desainer perangkat lunak berada dalam posisi sama dengan arsitek dan insinyur sipil, terutama yang berkaitan dengan desain konstruksi besar yang berbeda, seperti kota-kota dan tanaman industri. Oleh karena itu, tampaknya alam bahwa kita harus beralih ke mata pelajaran ini untuk ide-ide tentang bagaimana untuk menyerang masalah desain. ” Naur menyarankan bahwa mungkin banyak belajar dari sebelumnya penyelidikan ilmiah desain, seperti buku oleh Alexander [I]. Sementara banyak memang telah dipelajari oleh disiplin lain mengamati bagaimana memiliki desain mengejar dan memahaminya, ada juga garis pemikiran yang menyatakan bahwa perangkat lunak insinyur mungkin memiliki beberapa wawasan unik tajam dan berguna dari mereka sendiri menawarkan. Sedangkan insinyur sipil, misalnya, akhirnya menangani dengan bukti fisik, perangkat lunak insinyur, karena sifat medium mereka, terpaksa berurusan eksklusif dengan abstrak non-fisik. Sebagai desain tampaknya menjadi non-nyata mungkin insinyur perangkat lunak mungkin memiliki beberapa wawasan unik tajam dan berguna untuk menawarkan tentang sifat desain, baik dan verba nomina. Apakah ini mungkin benar, tampak jelas bahwa orang-orang yang telah mempelajari pengembangan perangkat lunak harus dapat memberikan kontribusi penting untuk memahami sifat desain, dan harus mengejar masalah ini sebagai item kunci pada agenda penelitian masyarakat. Penting untuk menekankan bahwa inspirasi tak tergantikan, intuisi, dan wawasan harus diambil dari masalah yang dihadapi dalam praktek, dan bahwa kontribusi yang sangat berharga untuk berlatih akan dibuat sebagai konsekuensi dari keberhasilan dalam mencapai pemahaman yang mendalam. Namun sifat investigasi desain tidak harus diarahkan sepenuhnya oleh urgensi praktek, penting meskipun mereka mungkin. Rasa ingin tahu tentang sifat desain secara umum, meskipun mungkin tidak memiliki koneksi langsung untuk berlatih, bukan hanya harus ditoleransi, tetapi didorong dan gizi. Dalam kaitan itu, tampaknya penting untuk dicatat bahwa buku ini sendiri berisi kertas yang mengeksplorasi sifat desain perangkat lunak, dan hubungannya dengan masalah yang lebih besar desain di [umum 24]. Makalah berhubungan dengan penelitian-didorong rasa ingin tahu dari jenis ini tidak harus dibatasi hanya untuk halaman-halaman volume khusus seperti ini, tetapi harus menjadi pokok utama tempat penelitian rekayasa perangkat lunak, seperti proses pertemuan seperti Yayasan Perangkat Lunak Rekayasa dan Internasional Konferensi Rekayasa Perangkat Lunak juga.

6.2. Pertanyaan: Apa itu model?

Sangat menarik untuk dicatat bahwa sebagian besar bekerja pada topik-topik seperti perancangan perangkat lunak, arsitektur perangkat lunak, dan persyaratan perangkat lunak akhirnya angin sampai berurusan dengan model. Sementara model tampaknya menjadi kendaraan penting untuk eksplorasi banyak topik rekayasa perangkat lunak, tampaknya menjadi kesalahan berpikir pemodelan semata-mata sebagai manifestasi kegiatan lainnya. Mungkin juga penting untuk merenungkan pertanyaan tentang apa model itu sendiri, dan apa aktivitas pemodelan adalah semua tentang. Seperti pertanyaan di atas, mungkin bahwa insinyur perangkat lunak, karena keterlibatan mereka panjang dan mendalam dengan non-bukti nyata, mungkin memiliki beberapa wawasan khusus yang mungkin kurang jelas tampak bagi mereka yang berurusan dengan model dalam konteks dari-pekerjaan mereka dengan bukti fisik seperti mobil, kursi, atau bangunan. Memang, Plato, dalam bukunya Alegori yang [Gua 19], menyarankan bahwa apa yang kurang langsung diamati dan diamati mungkin, dalam arti penting, akan lebih nyata, dan apa yang langsung bisa diamati, dalam arti yang sama, akhirnya ternyata kurang nyata. Perangkat lunak insinyur sering memiliki arti bahwa model abstrak dari sistem yang mereka berusaha untuk membangun sering kali, dalam arti tertentu (saat ini) sangat intuitif, lebih berharga dan berguna daripada (sering cacat dan tidak memadai) kode yang paling langsung diamati. Seperti Plato, akal di sini adalah bahwa abstrak, model diimplementasikan sebenarnya mungkin akan lebih nyata dan penting, sedangkan kode langsung diamati mungkin lebih sempurna, dan kurang memuaskan, bayangan dari “realitas”. Mungkin Software Engineers harus mempelajari Plato sebagai bagian dari pendidikan mereka?

Tampak jelas bahwa konsep model berkaitan erat dengan pengertian tentang abstraksi, dan dengan demikian bahwa Software Engineers, yang menangani secara efektif dengan penciptaan dan eksploitasi dari abstraksi, mungkin memiliki beberapa wawasan khususnya yang tajam dan berguna ke sifat model dan pemodelan.

6.3. Pertanyaan: Bagaimana kita bisa mengukur secara kuantitatif perangkat lunak dan menilai kualitas?

Masalah menentukan kualitas perangkat lunak juga diucapkan pada tahun 1968 Konferensi NATO, dan telah menjadi subjek penelitian terus menerus dalam beberapa dekade sejak saat itu. ketidakmampuan terus kami membuat banyak kemajuan dalam datang dengan langkah-langkah yang terdengar ilmiah dan terpercaya efektif dalam berurusan dengan spektrum luas masalah terus frustrasi masyarakat. Sangat menarik untuk dicatat, misalnya, yang mencoba untuk mengukur bahkan dimensi perangkat lunak yang paling dasar, ukuran tubuh kode perangkat lunak, telah membuat frustrasi. Seharusnya kita

mengukur sejumlah pernyataan, “garis”, karakter, titik fungsi, kode yang dihasilkan mesin, dll? Memang seluruh buku pedoman. [15] telah ditulis untuk menyarankan berbagai cara yang berbeda dalam dimensi ini tampaknya mudah perangkat lunak yang akan diukur. Upaya untuk mengukur kualitas telah semakin frustasi. Memang, tidak jarang untuk dicatat bahwa kualitas adalah multidimensi, meliputi atribut seperti ketepatan, efisiensi, ketahanan, fleksibilitas, dll demikian sering dikatakan bahwa lebih masuk akal untuk mencoba mengukur “kualitas” daripada mencoba untuk mengukur kualitas “lebih monolitik”.

Tapi upaya untuk menentukan langkah-langkah dari berbagai dimensi kualitas telah terbukti sama-sama frustasi.

Seperti disebutkan di atas, frustrasi lanjutan tersebut harus diambil sebagai indikasi yang jelas bahwa ada kemungkinan masalah mendasar yang cukup mendalam, dan yang langsung penyelidikan mungkin menyebabkan memuaskan pemahaman dan wawasan yang luas dan penting. Wawasan dan pemahaman cenderung memiliki dampak penting bagi perbaikan praktek. Tapi di sini juga tampaknya penelitian ini pada akhirnya mungkin akan lebih berhasil jika rasa ingin tahu didorong, bukan didorong oleh urgensi praktek. Masalah mendasar di sini tampaknya adalah bahwa entitas yang akan diukur dan dinilai tidak memiliki manifestasi berwujud sama sekali. Tampaknya jauh lebih mudah untuk mengukur dan menilai entitas yang memiliki manifestasi yang setuju untuk deteksi oleh panca indera manusia yang tradisional. Bagaimana kita berurusan dengan keinginan untuk mengukur sesuatu yang tidak terdeteksi dalam cara ini? Mereka yang bekerja pada akhirnya penampilan cenderung untuk jatuh kembali pada pengukuran lebih akrab dan nyaman dari fisik. Jadi, misalnya, Mekanik Engineers tampaknya jauh lebih berhasil dalam mengukur perangkat mekanis yang dihasilkan dari pekerjaan mereka, dari desain yang mereka hasilkan. Software Engineers tidak memiliki penampilan tersebut untuk mengukur, sebagai hasil kerja kami adalah non-nyata. Kita memang dapat, dan di masa lalu, mencoba untuk menilai perangkat lunak yang kami bangun dalam hal pengaruhnya terhadap dunia nyata. Tapi mungkin sudah saatnya bagi kita untuk melengkapi pendekatan tidak langsung untuk mengukur dan mengevaluasi perangkat lunak, dan mencoba serangan langsung atas masalah sulit mengukur intangible secara langsung. Memang jenis entitas lainnya seperti hukum, proses, desain, dan resep meningkatkan masalah yang sama. Upaya praktisi di daerah-daerah untuk mengukur dan menilai secara kuantitatif non-penampilan mereka terus menimbulkan frustrasi yang sama. Rekayasa Perangkat Lunak Mungkin memiliki sesuatu yang unik untuk menawarkan. Mungkin sudah saatnya bagi kita untuk mengatasi masalah ini secara langsung.

6.4. Pertanyaan: Apa itu Software?

Telah membingungkan untuk dicatat bahwa pertanyaan ini entah bagaimana pernah dibuat subjek penyelidikan yang serius oleh masyarakat penelitian kami. Pada ICSE 2002, pertanyaan ini diminta lebih dari 30 peserta konferensi yang dipilih secara acak, dan ditemukan bahwa tidak pernah memikirkannya. Memang, pada panel penutupan konferensi yang salah satu peneliti yang paling dihormati di komunitas rekayasa perangkat lunak mencela sebagai pertanyaan nilai meragukan. Namun, tampaknya aneh bahwa disiplin harus dinamai sebagai rekayasa mengejar sesuatu yang disebut “perangkat lunak”, dan belum ada definisi “perangkat lunak” tampaknya bisa diterima oleh masyarakat, dan tidak ada penelitian tampaknya telah dibahas pemahaman terhadap hakikat konsep entitas??. Sangat mungkin bahwa akan ada keberatan sedikit saran bahwa “perangkat lunak” berisi elemen desain, bagaimanapun representable oleh model, dan yang harus diukur, dan harus bisa menerima kuantifikasi kualitas. Dengan demikian, investigasi atas pertanyaan sebelumnya berpotensi memberikan kontribusi untuk memahami apa sebenarnya perangkat lunak. Tapi ada juga harus ada ruang untuk melakukan penyelidikan langsung ke sifat perangkat lunak itu sendiri, di samping pertanyaan dalam berbagai bagian dan manifestasinya. Mungkin salah satu pendekatan adalah untuk mempertimbangkan kodrat berbagai manifestasinya, dan sifat persamaan dan perbedaan. Penelitian sebelumnya telah menyarankan bahwa, misalnya, proses-proses perangkat lunak [13]. Memang dekade penelitian tampaknya untuk mengkonfirmasi bahwa perangkat lunak komputer dan perangkat lunak proses memiliki banyak kesamaan. Jika hal ini terjadi, maka apa yang mendefinisikan jenis entitas yang kita sebut sebagai perangkat lunak, yang kedua adalah subtipe? Karakteristik apa yang dapat kita simpulkan & om setiap dengan mempelajari yang lain? Apa pendekatan untuk pengembangan, verifikasi kualitas, dan evolusi yang bisa membantu dengan yang lain, dan apa semua ini katakan tentang jenis super dari keduanya? Apakah ada subtipe lain memang perangkat lunak, dan apa yang mungkin mereka memberitahu kita tentang semua ini? Pertanyaan-pertanyaan ini tampaknya dalam, bertahan, rasa ingin tahu-didorong, dan tidak mungkin kepentingan langsung kepada masyarakat praktek. Eksplorasi pertanyaan-pertanyaan ini, tetapi, mungkin mengarah pada pemahaman fundamental yang mungkin memang nilai yang sangat besar kepada masyarakat praktek. Mengejar pertanyaan-pertanyaan ini bisa menentukan arus penting dari penelitian selama puluhan tahun rekayasa perangkat lunak, dan bisa berbuat banyak untuk menempatkan kontrol agenda penelitian masyarakat kita di tangan kita sendiri.

7. Masa depan rekayasa perangkat lunak adalah di tangan kita.

Pada awal makalah ini disarankan bahwa masa depan kita ada di tangan kita. Makna dari pernyataan yang sekarang harus lebih jelas. Tulisan ini telah mencoba untuk membuat suatu kasus untuk kepentingan penelitian rasa ingin tahu-driven, sebagai pelengkap terhadap masalah- didorong penelitian yang telah dominan di masa lalu. Tapi itu adalah rekayasa perangkat lunak masyarakat yang harus memutuskan pada pentingnya jenis penelitian,

dan harus mendukung dengan cara-cara nyata, seperti menerima legitimasi di tempat-tempat fitur yang publikasi. penerimaan tersebut pasti tidak terjamin, namun. Sudah jelas, misalnya, bahwa akan ada peningkatan arus masalah yang berasal dalam praktek, dan tidak ada keraguan bahwa akan ada kebutuhan terus meningkat bagi masyarakat kita untuk bergulat dengan mereka. Sejalan dengan itu, ada beberapa tempat yang terus meningkat untuk presentasi kertas tersebut, dan publikasi hasil penelitian arsip yang berasal dari domain praktek. Jika tempat publikasi memilih untuk bersikeras hanya pada publikasi hasil penelitian masalah-didorong, dan jika tempat tersebut memutuskan untuk menolak publikasi untuk penelitian yang digerakkan oleh rasa ingin tahu, maka arah komunitas kami akan telah ditetapkan.

Untungnya, tempat ini semuanya dikontrol oleh komunitas riset kita sendiri, bagaimanapun, dan dengan demikian keputusan ini tidak diperintahkan atas kami, maka dapat dipilih oleh kami. Penilaian pesimis dari situasi saat ini adalah bahwa makalah penelitian didorong rasa ingin tahu-jarang diterima oleh tempat publikasi, dan yang tampaknya menjadi memutuskan preferensi untuk kertas didorong oleh kebutuhan praktek. Tidak ada yang salah dengan ini, jika keputusan untuk mendukung surat tersebut, pada dasarnya dengan mengesampingkan kertas dari jenis yang lain, adalah hasil pertimbangan cermat apa yang terbaik untuk kesehatan masyarakat. Di sisi lain, tampaknya belum ada perdebatan tentang hal ini, menyebabkan kelangsungan arah penelitian dan lintasan yang dimulai dekade lalu. Mungkin sekarang saatnya untuk peninjauan kembali terhadap lintasan. Ini akan menjadi malu besar jika masa depan penelitian dalam bidang rekayasa perangkat lunak ditentukan oleh standar dan kelambanan, bukan dengan pertimbangan apa yang kita sebagai sebuah komunitas berpikir yang terbaik bagi diri kita sendiri. Sebuah perdebatan tentang hal yang diperlukan, dan sekarang tampaknya menjadi waktu yang tepat untuk seperti debat. Permohonan dan penampilan dari makalah ini untuk tempat ini adalah tanda yang sangat menggembirakan. Kita hanya bisa berharap bahwa sinyal awal pertimbangan beberapa pertanyaan mendasar yang dapat membentuk inti dari sebuah disiplin ilmu rekayasa perangkat lunak bertahan lama.

8. Referensi

[I] C. Alexander, Notes on the Synthesis of Form, Harvard University Press, Cambridge, MA, 1964.
[2] R.W. Bemer, “Checklist for planning software system production”, in P. Naur and B. Randell, eds., Software
Engineering, Report on a conference sponsored by the NATO SCIENCE COMMITTEE, Garmisch, Germany, 7-1 1 October 1968. Scientific Affairs Division NATO, Brussels, Belgium, pp. 165-181. Also available at http://home~acres.cs.ncl.ac.~1k/brian.rande11/NATO/nato 1968.PDF.
[3] J.N. Buxton and B. Randell, eds., Software Engineering Techniques, Report on a conference sponsored by the NATO
SCIENCE COMMITTEE, Rome, Italy, 27-3 1 October 1969. Scientific Affairs Division NATO, Brussels, Belgium, also
available at http://l~on~epages.cs.t~cl.ac.tiWbria~~.randell/ATO/~iato 1969.PDF.
[4] E.W. Dijkstra, “Complexity controlled by hierarchical ordering of function and variability”, in P. Naur and B.
Randell, eds., Software Engineering, Report on a conference sponsored by the NATO SCIENCE COMMITTEE, Gannisch,
Germany, 7-11 October 1968. Scientific Affairs Division NATO, Brussels, Belgium, pp. 181-186. Also available at
http://l1o1n~pages.cs.11c1.a~.u1~/brian.rande11/ATOInato 1968.PDF.
[5] J. Estublier, D. Leblang, A. van der Hoek, R. Conradi, G. Clemm, W. Tichy, and D. Wiborg-Weber, “The Impact of
Software Engineering Research on the Practice of Software Configuration Management”, ACM Transactions on Software
Engineering Methodology, 14,4, Oct. 2005, pp. 383-430.
[6] S. Gill, “Thoughts on the sequence of writing software” in P. Naur and B. Randell, eds., Software Engineering,
Report on a conference sponsored by the NATO SCIENCE COMMITTEE, Garmisch, Germany, 7-11 October 1968.
Scientific Affairs Division NATO, Brussels, Belgium, pp. 186-189. Also available at http://homepares.cs.nci.ac.uklbrian.randell/NATO/nato 1968.PDF.
[7] J. Goguen, J. Thatcher, and E. Wagner, “An Initial randell/rande11/Algebra Approach to the Specification, Correctness, and Implementation of Abstract Data Types,” in Current Trends in Programming Methodology, K 4, Data Structuring, R Yeh (ed.), Prentice-Hall, Englewood Cliffs, NJ, 1978, pp.80-149.
[8] B.H. Liskov and S.N. Zilles. “Specification Techniques for Data Abstractions” IEEE Transactions on Sojlware
Engineering, v. 1, #I, 1975, pp. 7-19.
[9] A.I. Llewelyn and R.F. Wickens, “The testing of computer software”, in P. Naur and B. Randell, eds., Software Engineering, Report on a conference sponsored by the NATO SCIENCE COMMITTEE, Garmisch, Germany, 7-
11 October 1968. Scientific Affairs Division NATO, Brussels, Belgium, pp. 189-200. Also available at htt~://home~ages.cs.ncl.ac.uk/brian.randell/NATO/nato 1968.PDF.
[10] M. Mahoney, “Software as Science-Science as Software”, in History of Computing: Software Issues, U. Hashagen, R. Keil-Slawik and A. Norberg (eds.), Springer-Verlag, Berlin, Germany, 2002, pp. 25-48. Also available at
http://www.princeton.edu/%7Emike/softsci. htm.
[ll] M.D. McIlroy, “‘Mass Produced’ software components”, in P. Naur and B. Randell, eds., Software Englneerlng, Report on a conference sponsored by the NATO SCIENCE COMMITTEE, Garmisch, Germany, 7-1 1 October 1968. Scientific Affairs Division NATO, Brussels, Belgium, pp. 138-151. Also available at http://homepa~es.~s.n~l.a~.~ik/brian.ra11del1/A’TO/nato 1968.YDF.
[12] P Naur and B. Randell, eds, Software Engmeerrrzg, Report on a conference sponsored by the NATO SCIENCE
COMMITTEE, Garmisch, Germany, 7-11 October 1968. Scientific Affairs Division NATO, Brussels, Belgium. Also
available at htt~:l/homepa~es.cs.ncl.ac.uk/brian.randell/N ATOInato 1968.PDF.
[13] L.J. Osterweil, “Software Processes Are Software Too, Reviqited”, Proceedings of the 19th International Conference
on Software Engineering (ICSE 1997), Boston, MA, May 1997, pp. 540-548.
[14] L. Osterweil, C. Ghezzi, J. Kramer, and A. Wolf, “Editorial”, ACM Transactions on Software Engineering Methodology, 14, 4, Oct. 2005, pp. 381-382.
[15] R. Park. “Software Size Measurement: A Framework for Counting Source Statements,” Software Engineering
Institute, Camegie-Mellon University Technical Report # CMUISEI-92-TR-020, ADA258304, Pittsburgh, PA. Also
available at h~t~~:!/~v~~~~v.~t:i.~rn11.s~i~1~nt~blicatic~nsiciocu1~1eritsi9Z.2. tr.020.litinl. .
[16] D.L. Parnas, “On the Criteria to be Used for
Decomposing Systems into Modules”, Communications of 1171 A.J. Perlis, Keynote speech, 1968 NATO Conference, in
P. Naur and B. Randell, eds., Software Engineering, Report on a conference sponsored hy the NATO SCIENCE
COMMITTEE, Gannisch, Germany, 7-1 1 October 1968. Scientific Affairs Division NATO, Brussels, Belgium, pp.
135-138. Also available at htt~~:/ll?omepages.cs.ncI.ac.uk/brian.randell/NATOInato 1968.PDF.
[18] T.B. Pinkerton, “Performance monitoring and systems evaluation”, in P. Naur and B. Randell, eds., Software
Engineering, Report on a conference sponsored by the NATO SCIENCE COMMITTEE, Garmisch, Germany, 7-1 1 October 1968. Scientific -airs Division NATO, Brussels, Belgium, pp. 200-204. Also available at http://homepa~es.cs.ncl.ac.uk/brian.ra~~dcll/NATOInato 1968.I’DF.
[19] Plato, The Republic, Book VII, 360BC. Translated by Benjamin Jowett, P.F. Collier, New York, copyright 1901
The Colonial Press. Also available at httn://~v~~y~t_..~~lumbia.~d~~/p~~l~lic~o – republic – .I? tm, Markup, Copyright 1995, Institute for Learning Technologies.
[20] A. Pretschner, M. Broy, I. Kriiger, T. Stauner: “Software Engineering for Automotive Systems: A Roadmap”, in Future ofSoftware Engineering 2007, L. Briand and A. Wolf (eds.), IEEE-CS Press, 2007.
[21] B. Randell, “Towards a methodology of computing systems design”, in P. Naur and B. Randell, eds., Software
Engineering, Report on a conference sponsored by the NATO SCIENCE COMMITTEE, Garmisch, Germany, 7-1 1 October 1968. Scientific Affairs Division NATO, Brussels, Belgium, pp. 204-209. Also available at http://homepages.cs.ncI.ac.~ik/brian.randell/NATOInato 1968.PDF.
[22] W. Schiifer, H. Wehrheim, “The Challenges of Building Advanced Mechatronic Systems”, in Future of Software
Engineering 2007, L. Briand and A. Wolf (eds.), IEEE-CS Press, 2007.
[23] C. Strachey, in J.N. Buxton and B. Randell, eds., Software Engineering Techniques, Report on a conference
sponsored by the NATO SCIENCE COMMITTEE, Rome,Italy, 27-3 1 October 1969. Scientific Affairs Division
NATO, Brussels, Belgium, pp. 9-12. Also available at http:llho~nepa~es.cs.t~cl.ac.uldbrian.randell/NATO/nato -. 1969.PDF.
[24] R.N. Taylor and A. van der Hoek, “Software Design and Architecture: The Once and Future Focus of Software
Engineering”, in Future of Sofmare Engineering 2007, L. Briand and A. Wolf (eds.), IEEE-CS Press, 2007.

[25] Leon J. Osterweil, Future of Software Engineering(FOSE107).