Abstrack ~ Dalam beberapa tahun terakhir pengembangan berbasis komponen telah menjadi pendekatan yang nyata. Rekayasa Perangkat Lunak berbasis komponen (CBSE) berhubungan dengan seluruh siklus hidup produk berbasis komponen yang mana difokuskan pada teknologi yang berkaitan dengan desain dan implementasi komponen perangkat lunak dan sistem yang dibangun dari perangkat lunak berbasis komponen. Pengalaman telah menunjukkan bahwa pengunaan suatu teknologi yang statis saja tidak cukup. Pendekatan CBSE membutuhkan perubahan tertentu dalam pengembangan dan proses siklus hidup. Namun, sangat sedikit karya CBSE, baik penelitian atau praktis yang telah membahas topik ini. Pada makalah ini menggambarkan perbedaan prinsip berbasis komponen dan non-komponen proses berbasis dan juga memberikan ikhtisar studi kasus dari sebuah perusahaan yang menerapkan Pendekatan berbasis komponen.

Key Terms: Teknologi, Component-based Software Engineering (CBSE) dan Siklus hidup (Lifecycle).

I. PENDAHULUAN

Pendekatan berbasis komponen dalam beberapa tahun terakhir menunjukkan keberhasilan yang cukup besar dalam banyak aplikasi domain. Pendistribusian berbasis sistem web, desktop dan aplikasi grafis merupakan beberapa contoh domain yang menerapkan pendekatan berbasis komponen dan sukses di terapkan. Pada domain tersebut pengunaan teknologi yang umum digunakan seperti COM,. NET, EJB, J2EE. Walaupun demikian pengetahuan spesifik terhadap proses pengembangan perangkat lunak berbasis komponen masih sangat sedikit. Oleh karena itu, pada makalah ini akan dibahas mengenai karakteristik alasan pengunaan perangkat lunak berbasis komponen dan perbedaan dari non component-based. Terdapat juga studi kasus yang menyediakan solusi pendekatan berbasis komponen pada sebuah organisasi perusahaan

II. TINJAUAN PUSTAKA

Pengembangan sistem merupakan tahap perubahan sistem dari bentuk lama (yang sudah ada) menjadi suatu sistem yang baru, yang memiliki kemampuan atau kinerja lebih baik. Perubahan dalam hal ini, bukan hanya sekedar perubahan fisik (fasilitas maupun sarana) namun menyangkut seluruh aktivitas yang berpengaruh pada

dikembangkan. Analisisi sistem didefinisikan sebagai bagaimana memahami dan menspesifikasi dengan detail apa yang harus dilakukan oleh sistem. Sedangkan sistem desain diartikan sebagai menjelaskan dengan detail bagaimana bagian-bagian dari sistem informasi diimplementasikan, sehingga Analisis dan desain sistem informasi (ADSI) bisa didefinisikan sebagai: Proses organisasional kompleks dimana sistem informasi berbasis komputer diimplementasikan.

Perbedaan model yang diusulkan dan dieksploitasi dalam rekayasa perangkat lunak, telah dinampakan dalam kemampuan untuk secara efisien mengatur semua kegiatan yang diperlukan dalam pengembangan dan penggunaan produk.

Perbedaan tersebut dapat dijadikan dua kelompok model utama : Pertama Sequential dan kedua evolusiner. Model sekuensial mendefinisikan urutan kegiatan di mana satu kegiatan harus selesai sebelumnya. Sendangkan Model evolusiner memungkinkan kinerja beberapa kegiatan secara paralel tanpa persyaratan pada penyelesaian ketat dalam arti satu kegiatan dapat menjalankan beberapa kegiatan satu sama lain. Contoh Model yang terkenal sekuensial adalah model waterfall, atau model V, dan model evolusiner yakni iteratif dan pengembangan inkremental, atau Model Spiral.

Secara independen model tersebut dapat di identifikasi berdasarkan aktivitas yang dikerjakanya dalam sebuah proses siklus hidup (lifecycle). Aktivitas tersebut merupakan :1. Requirement analysis and specification, yakni layanan

sistem, kendala dan tujuan yang ingin di capai oleh sebuah sistem sedangkan untuk spesifikasi ialah apa yang diharapkan oleh sistem bekerja

2. Software Design, menunjukan indentifikasi deskripsi dasar atau sistem abstraksi dan hubungannya dengan satu sama lain

3. Implementation and Unit Testing, untuk pengoptimalisasian dari desain yang di laksanakan yang mana dapat dibentuk menjadi unit yang kecil. Pengujian dapat di lakukan pada tahap implemtasi

4. System Integration, unit sistem yang terintegrasi5. System Verification and Validiation, memperbaiki

sistem secara keseluruhan dan memvalidasi sistem berdasarkan kebutuhan

Makalah Tugas Akhir (atau Kerja Praktek)Pengembangan Rekayasa Component-Based Software dan Lifecycle Component

Muhammad Kuatsar, 21120110141001Program Studi Sistem Komputer Fakultas Teknik Universitas Diponegoro

Jalan Prof. Sudharto, Tembalang, Semarang, IndonesiaEm.kautsar@ce.undip.ac.id

yang panjang selama beberapa periode, sebaiknya menggunakan model sequential. Sedangkan sistem menggunakan teknologi skala kecil dapat menggunakan model evolusioner karena lebih fleksibel dan dapat menujukan beberapa hasil yang cepat dibandingkan model sequential. Model model tersebut menerapkan pengembangan component-based, tetapi membutuhkan adaptasi sebagai dari prinsip pendekatan component-based.

2.1 Model Proses Component-BasedCBSE membahas tantangan emyerupai dengan yang di

temui di tempat lain dalam rekayasa perangkat lunak. Banyak metode, peralatan dan prinsip dari rekayasa perangkat lunak yang hampir sama dengan konsep CBSE. Namun terdapat perbedaann spesifik pada pertayaan yang terkait pada komponen dan dalam hal itu membedakan antara “pengembangan berbasis komponen” dari sistem yang mengembangkan komponen/

1. Membuat Sistem dari KomponenIde utama dari pendekatan berbasis komponen ialah membangun sistem dari komponen yang sudah ada. Asumsi ini memiliki beberapa konsekuensi untuk sistem siklus hidup. Pertama, pengembangan proses sistem berbasis komponen dipisahkan dari proses pembangunan komponen; komponen harus sudah telah dikembangkan dan mungkin digunakan dalam produk lainnya ketika proses pengembangan sistem dimulai. Kedua, proses pemisahan baru yang akan muncul: Mencari dan mengevaluasi komponen. Ketiga, kegiatan dalam proses akan berbeda dari kegiatan pendekatan non-component based. Untuk pengembangan sistem penekanan pada menemukan komponen yang tepat dan memverifikasi mereka, dan untuk komponen pengembangan, di desain untuk digunakan kembali (reusable) akan menjadi pokok utama.

Ada perbedaan dalam persyaratan dan ide-ide bisnis dalam kedua kasus ini. pendekatan yang berbeda diperlukan. Komponen yang dibangun untuk digunakan dan digunakan kembali dalam banyak aplikasi, beberapa mungkin belum ada, dalam beberapa mungkin tak terduga cara Pengembangan sistem dengan komponen difokuskan pada identifikasi entitas dapat digunakan kembali dan hubungan di antara mereka, mulai dari persyaratan sistem dan dari ketersediaan komponen yang sudah ada 1 4. banyak upaya pelaksanaan dalam pengembangan sistem akan tidak lagi diperlukan, tetapi upaya yang diperlukan dalam berurusan dengan komponen seperti lokasi mereka, memilih penggunaan yang paling tepat, pengujian mereka, dll akan meningkatkan kinerja 6.

Kegiatan yang berbeda dalam dua proses, tetapi juga menemukan bahwa banyak kegiatan ini dapat dilakukan secara independen satu sama lain. Pada kenyataannya, proses sudah terpisah karena banyak komponen yang dikembangkan oleh pihak ketiga, secara independen dari sistem pembangunan. Bahkan komponen yang dikembangkan internal dalam sebuah organisasi yang menggunakan komponen-komponen

yang sama, sering diperlakukan sebagai entitas yang terpisah dikembangkan secara terpisah.

Gambar 1 menunjukkan model pengembangan V diadaptasi pendekatan berbasis komponen. Penggunaan model V ini banyak digunakan dalam organisasi banyak organisasi-biasanya besar membangun produk-umur panjang secara kompleks, seperti seperti mobil atau robot. Dalam model ini proses dimulai dengan cara biasa oleh persyaratan teknik dan persyaratan spesifikasi, diikuti oleh sistem spesifikasi. Dalam ap-berbasis non-komponen proach proses akan terus dengan unit desain, implementasi dan pengujian. Alih-alih melakukan kegiatan ini yang sering adalah waktu dan upaya mengkonsumsi, pilih yang sesuai komponen dan integrasikan mereka dalam sistem. Namun, dua masalah yang muncul di sini istirahat kesederhanaan ini: i? Hal ini tidak jelas bahwa ada komponen untuk memilih, dan ii? yang dipilih komponen hanya sebagian cocok secara keseluruhan kami desain. Fakta pertama menunjukkan bahwa harus memiliki suatu proses untuk menemukan komponen. proses ini meliputi kegiatan untuk menemukan komponen, dan kemudian evaluasi komponen. yang kedua Bahkan menunjukkan untuk kebutuhan adaptasi komponen dan pengujian sebelum dapat diintegrasikan ke dalam sistem. Dan tentu saja harus ada proses pengembangan komponen, ini menjadi independen dari proses pengembangan sistem. Gambar 1 juga menunjukkan disederhanakan dan ideal proses. Asumsi adalah bahwa komponen dipilih dan digunakan adalah cukup dekat dengan unit diidentifikasi dalam proses desain, sehingga Proses adaptasi membutuhkan secara signifikan? kurang upaya dari pelaksanaan unit '. selanjutnya, tidak mempertimbangkan apa yang terjadi dalam pemeliharaan proses; apa yang terjadi jika sistem malfungsi karena masalah yang terjadi di komponen, atau karena tidak kompatibel dari komponen. Hal ini menunjukkan bahwa componentbased tersebut

Pendekatan ini tidak hanya terbatas pada pembangunan proses, atau bagian dari proses pembangunan, tetapi untuk seluruh siklus hidup. Pada sangat awal panggung, dalam Persyaratan dan fase Desain,

Gambar 1. Pengembangan model V untuk CBD

Rekayasa persyaratan sistem dan sistem arsitek harus sadar tentang ketersediaan dari komponen yang sudah ada. Sebuah proses yang lebih realistis ditunjukkan pada Gambar 2. fase yang berbeda dari proses pembangunan secara lebih rinci. Persyaratan analisis dan specification. Dalam fase satu kegiatan penting adalah untuk menganalisis kemungkinan mewujudkan solusi yang akan memenuhi persyaratan ini. Dalam pendekatan berbasis komponen menyiratkan bahwa perlu untuk menganalisis apakah persyaratan tersebut dapat dipenuhi dengan komponen yang tersedia. Ini berarti bahwa persyaratan rekayasa harus menyadari komponen yang mungkin dapat digunakan. Karena bukan tidak mungkin bahwa komponen yang tepat dapat selalu ditemukan risiko yang baru komponen harus dilaksanakan. Untuk menjaga dengan pendekatan berbasis komponen dan memanfaatkan nya keuntungan ? salah satu kemungkinan adalah untuk menegosiasikan persyaratan dan memodifikasi mereka untuk dapat menggunakan komponen yang ada.

Gambar 2. Detail pengembangan model V CBD

Sistem dan software desain. Serupa dengan persyaratan spesifikasi fase spesifikasi

sistem dan desain yang sangat terkait dengan ketersediaan komponen. Potensi komponen mematuhi tertentu model komponen. Satu bisa berasumsi bahwa itu akan mungkin untuk menggunakan komponen dilaksanakan dalam

teknologi komponen yang berbeda, tetapi dalam prakteknya sangat sulit untuk mencapai interoperabilitas antara komponen model yang berbeda. Model komponen tertentu memerlukan kerangka arsitektur, dan aplikasi seharusnya menggunakan framework ini. Ini memiliki dampak langsung terhadap keputusan arsitektur. Misalnya, jika model komponen membutuhkan gaya arsitektur client-server, jelas bahwa aplikasi akan menggunakan gaya itu dan tidak saling misalnya pipa-filter?. Hal ini akan menempatkan pembatasan pada desain sistem. Juga, Sifat lain dari komponen dapat memiliki langsung pengaruh pada keputusan desain. Untuk ini alasan proses desain terhubung erat ketersediaan komponen. Implementasi dan unit testing. Ketika membangun sistem berbasis komponen, kasus yang ideal adalah untuk membangun aplikasi dengan integrasi langsung komponen, yaitu komponen yang menghubungkan secara langsung. “Kode perekat” adalah kode yang menentukan hubungan ini. Dalam prakteknya peran kode lem juga akan mencakup adaptasi komponen, dan bahkan pelaksanaan fungsi baru. Dalam kasus ideal komponen sendiri sudah dibangun dan diuji. Namun, tes komponen dalam isolasi yang tidak cukup. Seringkali, desain unit akan dilaksanakan sebagai rakitan dari beberapa komponen dan mungkin kode lem. Rakitan ini harus diuji secara terpisah sejak perakitan komponen yang benar mungkin salah, meskipun komponen sendiri sudah benar

Sistem Integrasi. Proses integrasi mencakup integrasi infrastruktur standar komponen yang membangun kerangka komponen dan komponen aplikasi. Integrasi dari komponen tertentu ke dalam sistem disebut penyebaran komponen. Berbeda dengan Seluruh integrasi sistem, penyebaran komponen adalah mekanisme untuk integrasi tertentu komponen – itu termasuk men-download dan mendaftarkan komponen.

Sistem verifikasi dan Standar validasi.Standar Pengujian dan teknik verifikasi yang digunakan

di sini. Masalah khusus untuk pendekatan berbasis komponen disini adalah lokasi kesalahan, terutama ketika komponen dari jenis“Black Box” dan disampaikan dari vendor yang berbeda. Biasanya, sebuah komponen dapat menunjukkan kesalahan, tapi penyebabnya kerusakan terletak pada komponen lain. Kontrak Interface memainkan peran penting dalam memeriksa input dan output yang tepat dari komponen. Antarmuka ini memungkinkan spesifikasi input dan output dan memeriksa kebenaran yang data.

Dukungan operasi dan pemeliharaan.Proses pemeliharaan meliputi beberapa langkah yang

mirip dengan proses integrasi: komponen baru dimodifikasi ditempatkan ke dalam sistem. Juga, mungkin perlu untuk mengubah kode lem. Dalam sebagian besar kasus yang ada komponen akan diubah atau versi baru dari komponen yang sama akan diintegrasikan ke dalam sistem. Sekali lagi, masalah baru yang disebabkan oleh ketidakcocokan antar komponen, atau rusak dependensi, dapat terjadi. Ini berarti bahwa sistem harus diverifikasi baik secara formal, atau dengan simulasi, atau dengan pengujian. Dibandingkan dengan pendekatan berbasis non-komponen, dalam proses pembangunan berbasis komponen ada upaya signifikan kurang dalam pemrograman, tetapi verifikasi dan pengujian membutuhkan upaya jauh lebih. Verifikasi Kegiatan ini diulang dalam beberapa tahap, dengan tujuan yang sedikit

berbeda:   Memverifikasi komponen dalam isolasi; Memverifikasi komponen dalam perakitan; Memverifikasi sistem ketika komponen di jalanka ke

dalam sistem.

2. Membangunan Komponen Reusable Proses komponen bangunan dapat mengikuti model

proses pembangunan sewenang-wenang. Namun, model apapun akan memerlukan modifikasi tertentu untuk mencapai tujuan; di samping tuntutan pada fungsi komponen, komponen dibangun untuk digunakan kembali. Usabilitas menyiratkan umum dan fleksibilitas, dan ini persyaratan secara signifikan dapat mengubah komponen karakteristik. Misalnya mungkin ada menjadi persyaratan untuk portabilitas, dan kebutuhan ini bisa menyiratkan implementasi menta-spesifik solusi seperti pilihan bahasa pemrograman, pelaksanaan tingkat menengah layanan, gaya pemrograman, dll?. Persyaratan umum menyiratkan fungsi sering lebih dan membutuhkan lebih banyak desain dan pengembangan usaha dan pengembang lebih berkualitas. Komponen pembangunan akan membutuhkan lebih banyak upaya dalam pengujian dan spesifikasi komponen. Komponen harus diuji secara terpisah, tetapi juga dalam konfigurasi yang berbeda. Akhirnya, dokumentasi dan pengiriman akan membutuhkan lebih upaya sejak dokumentasi diperpanjang sangat penting untuk meningkatkan pemahaman tentang komponen. Sebuah contoh dari komponen diperpanjang Spesifikasi dapat ditemukan di ROBOCOP model komponen 5; komponen ditentukan oleh deretan modul: Model executable, model fungsional, model simulasi, sumber daya model, dll Setiap model termasuk dokumentasi yang sesuai.

III. STUDI KASUS MODEL PROSES COMPONENT-BASED DI

Suatu Model proses yang digunakan dalam konsumen internasional skala perusahaan besar elektronik. Studi kasus yang dilakukan oleh empat peneliti dalam wawancara intensif dengan berbagai stakeholder pembangunan Proyek: system Architecture, Architecture Component, pengembang, pemimpin proyek, manajemen, jaminan kualitas, client dan spesialis utama.

Divisi pengembangan perusahaan ditempatkan di empat negara yang berbeda dan mereka menghasilkan berbagai produk dengan varian yang berbeda dan model. Perusahaan telah mengadopsi pembangunan berbasis komponen menggunakan productline arsitektur. Komponen model internal dikembangkan dan sebagian besar alat-alat yang secara internal dikembangkan. Alasan yang spesifik persyaratan domain: sumber daya rendah penggunaan, ketersediaan tinggi, dan persyaratan real- time lembut. Komponen Model mengikuti prinsip-prinsip dasar dari CBSE: Komponen ditentukan oleh antarmuka yang membedakan "requirement" dari "Provide" interface. Selain fungsional spesifikasi, antarmuka termasuk tambahan informasi; protokol interaksi, ketepatan waktu sifat, dan penggunaan memori. komponen Model memungkinkan evolusi kelancaran komponen karena memungkinkan adanya multiple interface. Model ini memiliki karakteristik yang spesifik; memungkinkan komposisi hirarkis: a

komponen komposit diperlakukan sebagai standar komponen dan dapat lebih terintegrasi dalam komponen lain. Komponen juga dikembangkan secara internal, tetapi perkembangan mereka dipisahkan dari pengembangan produk. Arsitektur produk-line mengidentifikasi dasar kerangka arsitektur. Arsitektur produk ditunjukkan pada Gambar 3. Arsitektur produk arsitektur berlapis yang meliputi i? sistem operasi, ii? kerangka komponen yang merupakan perantara tingkat antara layanan-domain tertentu dan operasi, iii? komponen inti yang disertakan dalam semua varian produk, dan iv? aplikasi komponen yang biasanya berbeda untuk varian produk yang berbeda. Melengkapi layering horisontal ini ada adalah penataan vertikal dalam bentuk subsistem. Subsistem juga terkait dengan organisasi struktur; mereka bertanggung jawab untuk pengembangan dan pemeliharaan komponen tertentu. itu Proses keseluruhan didesain seperti yang ditunjukkan pada Gambar 4.

Gambar 3. Arsitektur Produk Software

Gambar 4. Proses Pengembangan Produk secara keseluruhan

Dalam proses keseluruhan ada tiga set proses paralel independen: Secara keseluruhan proses pengembangan arsitektur dan platform, bertanggung jawab untuk memberikan newplatforms dan komponen dasar, ii? pengembangan subsistem proses yang memberikan satu set komponen yang memberikan layanan yang berbeda, dan iii? produk proses pembangunan yang pada dasarnya merupakan integrasi proses. Pengaturan proses ini memungkinkan untuk memberikan produk-produk baru setiap enam bulan, sementara pengembangan subsistem komponen memakan waktu biasanya antara 12 dan 18 bulan. Fitur khusus ini proyek adalah bahwa semua kiriman memiliki sama form. Sebuah penyampaian adalah paket perangkat lunak yang ditetapkan sebagai komponen. Dua dokumen utama milik

setiap penyampaian: komponen antarmuka spesifikasi dan lembar komponen; pertama dokumen yang menjelaskan interkoneksi, maka kedua menggambarkan komponen internal. Meskipun pembangunan secara keseluruhan dan produksi berhasil, proses menderita beberapa kelemahan. Yang paling serius adalah akhir penemuan kesalahan, karena antarmuka atau arsitektur ketidaksesuaian, spesifikasi tidak mencukupi semantik dari komponen, atau karena tidak pantas interface. Selain itu, masalah yang terkait dengan enkapsulasi layanan dalam komponen sering terjadi; karena tumpang tindih fungsional, atau beberapa persyaratan mempengaruhi arsitektur, sulit untuk memutuskan di mana komponen tertentu Fungsi akan dilaksanakan. Semua masalah ini menunjukkan bahwa sulit untuk melakukan proses independen; negosiasi antara subsistem yang berbeda dan kesepakatan di banyak rincian teknis antara tim yang berbeda diperlukan. Untuk alasan ini proses yang tidak benar-benar terpisah. Mereka didistribusikan di antara beberapa proyek dan ada secara keseluruhan proyek yang mengkoordinasikan mereka semua. Dukungan proses yang kuat memiliki proyek struktur organisasi lihat Gambar 5.

Arsitek Sistem dan manajemen memiliki tanggung jawab keseluruhan untuk berbagai kebutuhan seperti kebijakan, arsitektur line product, produk visi dan tujuan jangka panjang. Arsitek proyek memiliki tanggung jawab untuk proyek secara keseluruhan yang menghasilkan dalam lini produk. dia ? dia koordinat desain arsitektur dari keluarga produk dan subsistem. Tes dan jaminan kualitas

Gambar 5. Struktur Proyek Organisasi

QA manajer memiliki peran serupa dalam domain mereka: untuk memastikan koordinasi dan kompatibilitas tes dan proses yang berkualitas. subsistem arsitek memberikan desain subsistem dan mengkoordinasikan keputusan desain dengan subsistem lain. Setiap subsistem memiliki tim testing dan QA manajer yang bertanggung jawab terhadap kualitas komponen subsistem tersampaikan. Tim integrasi yang bekerja di proyek pengiriman diwakili oleh produk arsitek, QA dan uji manajer yang mengkoordinasikan kegiatan dengan proyek-proyek lainnya. Bisa di amati bahwa tim proyek memiliki banyak "non produktif" pemangku kepentingan. Hal ini sejalan dengan pendekatan berbasis komponen - upaya yang lebih harus diletakkan pada arsitektur secara keseluruhan dan pengujian, dan kurang pada pelaksanaan itu sendiri. pengembangan proses dalam kasus kami adalah jantan dari evolusi Model. Platform ini, subsistem dan produk yang dikembangkan

dalam beberapa iterasi sampai fungsi dan kualitas yang diinginkan tercapai. Hal ini memerlukan sinkronisasi iterasi.

IV. KESIMPULAN

Kesimpulan

Berdasarkan hasil penelitian dan pembahasan, maka dapat diambil kesimpulan sebagai berikut :

Pendekatan berbasis komponen tidak dapat sepenuhnya digunakan jika proses pembangunan dan bahkan pengembangan organisasi tidak diadopsi sesuai prinsip-prinsip dasar CBSE. karena ini Pendekatan ini bertujuan untuk meningkatkan usabilitas komponen yang ada, upaya untuk implementasi menurun, dan upaya untuk verifikasi sistem meningkat. Hal ini memerlukan penyesuaian pembangunan proses. Dengan studi kasus industri kami telah menunjukkan kesulitan untuk mencapai pemisahan lengkap proses pengembangan sistem dari komponen, serta kebutuhan untuk sebuah organisasi proyek yang menempatkan lebih menekankan pada isu-isu arsitektur dan sistem dan komponen verifikasi.

DAFTAR PUSTAKA

[1] _ L. BASS,P.CLEMENTS AND R. KAZMAN, Software Architecture in Practice, Addison Wesley, 1998.

[2] _ V. BORGHOFF,R.PARESI, editors_, Information Technology for Knowledge Management, NewYork: Springer Verlag; 1998.

[3] IVICA CRNKOVIC AND MAGNUS LARSSON editors_,Building Reliable Component-Based Software Systems, Artech House Publishers, ISBN 1-58053-3272, 2003.

[4] D. GARLAN,R.ALLEN AND J. OCKERBLOOM,Architectural Mismatch: Why Reuse is so Hard, IEEE Software, Vo. 12, issue 6, 1995.

[5] _5_ ITEA project, ROBOCOP-Robust Open Component Based Software Architecture for Configurable Devices Project/http__www_hitech_

[6] M.MORISIO,C.B.SEAMAN,A.T.PARRA,V.R.B ASIL,S.E.KRAFT

AND S. E. CONDON, Investigating and Improving a COTS-Based Software Development Process, In Proceedings , 22nd ICSE, ACM Press, 2000.