Reinvent The Wheel/Menemukan kembali roda

Reinvent The Wheel
Menemukan kembali roda 

Menemukan kembali The Wheel
Nama Anti Pola: menemukan kembali roda Disebut Juga Sebagai: Desain di Vacuum sebuah, Greenfield Sistem Skala Paling Sering: Sistem Refactored Solusi Nama: Arsitektur Pertambangan Refactored Solusi Jenis: Penyebab Proses Akar: Pride, Ketidaktahuan Angkatan seimbang: Manajemen Perubahan, Alih Teknologi Bukti anekdotal: "masalah kita adalah unik." Pengembang perangkat lunak umumnya memiliki pengetahuan minimal kode masing-masing.

    Paket perangkat lunak bahkan banyak digunakan tersedia dalam kode sumber jarang memiliki lebih dari satu pengembang berpengalaman untuk setiap program. Hampir semua pengembangan sistem dilakukan dalam isolasi dari proyek dan sistem dengan fungsi yang tumpang tindih. Reuse langka di sebagian besar organisasi perangkat lunak. Dalam sebuah penelitian terbaru dari lebih dari 32 proyek perangkat lunak berorientasi objek, para peneliti menemukan hampir tidak ada bukti sukses reuse

Latarbelakang
    Software dan desain ulang paradigma yang berbedasecara signifikan. Penggunaan kembali perangkat lunak melibatkan penciptaan sebuah perpustakaan komponen dapat digunakan kembali, pengambilan komponen-komponen, dan integrasikomponen dengan sistem software. Hasil khas adalah jumlah yang sederhana reusesekitar pinggiran sistem dan pengembangan perangkat lunak tambahan untuk mengintegrasikan komponen,”

Desain reuse melibatkan penggunaan kembali arsitektur dan software antarmuka di beberapa sistem aplikasi. Hal ini membutuhkan identifikasi komponen horisontal dengan menggunakan di beberapa sistem aplikasi.

Desain reuse juga mendukung penggunaan kembali perangkat lunak dari komponen horisontal tanpa pengembangan tambahan untuk integrasi, dengan demikian itu adalah pendekatan yang lebih efektif, dalam porsi yang lebih besar dari sistem perangkat lunak dapat dimanfaatkan dari komponen dapat digunakan kembali.

The greenfield jangka (di Greenfield System, alias dari Menemukan kembali Roda) berasal dari industri konstruksi. Hal ini mengacu pada sebuah situs konstruksi baru di mana tidak ada bangunan warisan untuk memperkenalkan kendala pada arsitektur bangunan baru. 

Bentuk umum
   Sistem perangkat lunak kustom yang dibangun dari bawah ke atas, meskipun beberapa sistem dengan fungsi yang tumpang tindih ada. Proses perangkat lunak mengasumsikan "greenfield" (membangun dari awal) pengembangan sistem tunggal. Karena analisis top-down dan desain menyebabkan arsitektur baru dan perangkat lunak kustom, penggunaan kembali perangkat lunak terbatas dan interoperabilitas ditampung setelah fakta.

    Kebanyakan metode software saat ini menganggap bahwa pengembang sedang membangun perangkat lunak kustom dari awal, dan bahwa mereka sedang membangun sebuah sistem tunggal dalam isolasi. Ini disebut asumsi sistem greenfield.

    Sistem greenfield pasti menjadi stovepipes yang kurang potensial untuk interoperabilitas, ekstensi, dan penggunaan kembali. Asumsi greenfield yang tidak cocok untuk sebagian besar masalah pengembangan perangkat lunak di dunia nyata, di mana sistem warisan yang ada, dan interoperation dengan mereka merupakan syarat penting bagi banyak sistem baru. Asumsi Greenfield juga mengabaikan aset perangkat lunak dapat digunakan kembali yang signifikan dalam bentuk freeware Internet dan perangkat lunak yang tersedia secara komersial.
Gejala Dan Konsekuensi

    Sistem tertutup arsitektur-arsitektur dan software-yang dirancang untuk satu sistem pada suatu waktu tanpa ketentuan untuk digunakan kembali dan interoperabilitas.
Replikasi dari fungsi perangkat lunak komersial.
Arsitektur dan persyaratan belum matang dan stabil.
Dukungan memadai untuk manajemen dan interoperabilitas perubahan.
Siklus pengembangan yang melibatkan diperpanjang gagal dan prototipe buntu sebelum arsitektur cukup matang untuk mendukung pengembangan sistem jangka panjang dan pemeliharaan.
Manajemen yang buruk dari risiko dan biaya, menyebabkan jadwal dan anggaran overruns.
Ketidakmampuan untuk memberikan fitur yang diinginkan kepada pengguna akhir; upaya luas untuk meniru fungsi sudah operasional dalam sistem yang ada.

Penyebab khas
   Tidak ada komunikasi dan transfer teknologi antara proyek-proyek pengembangan perangkat lunak.
Tidak adanya proses arsitektur eksplisit yang meliputi pertambangan arsitektur dan teknik domain.
Asumsi pembangunan greenfield; dengan kata lain, proses berasumsi bahwa sistem akan dibangun dari awal.

Kurangnya manajemen perusahaan dari sudut pandang komputasi, yang mengarah ke antarmuka software yang unik di setiap sistem.

Dikenal Pengecualian
    Menemukan kembali Roda antipattern cocok untuk lingkungan penelitian dan dalam pengembangan perangkat lunak umum untuk meminimalkan biaya koordinasi di mana pengembang dengan keterampilan yang berbeda bekerja di lokasi terpencil logistik.


Solusi refactored
   Pertambangan arsitektur adalah cara untuk dengan cepat menciptakan arsitektur berorientasi objek sukses yang kuat, produk-independen, dapat digunakan kembali, dan extensible. Kebanyakan pendekatan desain berorientasi objek menganggap bahwa informasi desain diciptakan sebagai hasil proses.

Dalam proses top-down, informasi desain yang dihasilkan dari persyaratan, yang dapat direpresentasikan sebagai kasus penggunaan dan model analisis berorientasi objek. Persyaratan-driven desain arsitektur disebut pertanian arsitektur. Dalam proses spiral, informasi desain diciptakan selama setiap iterasi. Sebagai hasil proses spiral, arsitek memperoleh informasi desain baru karena mereka belajar lebih banyak tentang masalah aplikasi.

Ini adil untuk mengatakan bahwa pendekatan ini menemukan kembali banyak informasi desain mereka.

    Desain prekursor ada untuk sebagian besar sistem informasi aplikasi dan masalah. Desain ini adalah dalam bentuk sistem warisan, produk komersial, standar, prototipe, dan pola desain.

    Pengalaman membuktikan tidak sulit untuk mengidentifikasi setengah lusin atau desain prekursor lebih untuk masalah aplikasi yang diberikan. Informasi berharga dimakamkan di desain yang sudah ada sebelumnya, informasi yang memungkinkan arsitek sebelumnya untuk membangun sistem yang berguna. Penggalian informasi ini untuk digunakan dalam arsitektur berorientasi objek disebut pertambangan arsitektur.

    Pertambangan mungkin berlaku pada tingkat aplikasi untuk masalah desain yang kompleks tertentu. Dalam beberapa kasus, mungkin lebih murah dan berisiko untuk mengeksploitasi keahlian yang ada daripada membuat kode baru tanpa paparan yang sudah ada sebelumnya solusi. Pertambangan berlaku pada tingkat perusahaan, tapi kurang begitu di tingkat global, mengingat mengurangi akses ke sumber informasi.

    Pertambangan adalah pendekatan desain bottom-up, menggabungkan pengetahuan desain dari implementasi bekerja. Pertambangan dapat menggabungkan masukan desain dari proses desain top-down, juga, sehingga ada dapat menjadi traceability top-down dan bottom-up realisme.

Sebelum mulai pertambangan, perlu untuk mengidentifikasi satu set teknologi perwakilan yang relevan dengan masalah desain. Identifikasi teknologi dapat dilakukan dengan berbagai cara, seperti mencari literatur, wawancara pakar, menghadiri konferensi teknis, dan berselancar di Net. Semua sumber daya yang tersedia harus dikejar.

    Langkah pertama adalah pertambangan untuk model setiap teknologi perwakilan, untuk menghasilkan spesifikasi interface perangkat lunak yang relevan. Kami merekomendasikan menggunakan OMG IDL sebagai notasi antarmuka karena ringkas dan bebas dari detail implementasi.

OMG IDL juga notasi desain yang baik untuk arsitektur target karena bahasa-independen, platform netral, dan distribusi-transparan. Pemodelan segala sesuatu dalam notasi yang sama menciptakan dasar yang baik untuk perbandingan desain dan trade-off.

    Sementara modeling, penting untuk menggambarkan sistem sebagai-dibangun, bukan desain dimaksudkan atau diinginkan. Sering, informasi desain yang relevan tidak didokumentasikan sebagai antarmuka software. Sebagai contoh, beberapa fungsi yang dicari dapat diakses hanya melalui antarmuka pengguna. Pelajaran desain kunci lainnya dapat didokumentasikan, dan ini berguna untuk menangkap informasi ini, juga.

   Pada langkah pertambangan kedua, desain yang umum untuk membuat spesifikasi antarmuka umum. Langkah ini memerlukan lebih seni daripada sains, sebagai tujuannya adalah untuk menciptakan sebuah awal "strawman" spesifikasi untuk antarmuka arsitektur target.

    Hal ini biasanya tidak cukup untuk menghasilkan desain denominator terendah-common dari teknologi perwakilan. Interface yang umum harus menyerupai best-of-breed solusi yang menangkap fungsionalitas umum, serta beberapa aspek unik yang diilhami oleh sistem tertentu.

Aspek unik harus dimasukkan ketika mereka membuat fitur berharga dalam arsitektur target atau mewakili daerah evolusi sistem yang dikenal. Beraneka kuat dari teknologi perwakilan akan berisi indikator kemungkinan bidang sistem target evolusi.

Pada titik ini, adalah tepat untuk faktor dalam informasi desain top-down sebagai salah satu masukan. Informasi top-down biasanya pada tingkat yang jauh lebih tinggi dari abstraksi dari informasi bottom-up. Rekonsiliasi perbedaan ini melibatkan beberapa arsitektur penting trade-off.

Langkah terakhir dalam proses penambangan adalah untuk memperbaiki desain. Penyempitan dapat didorong oleh penilaian arsitek, walkthrough informal proses review, persyaratan baru, atau studi pertambangan tambahan.

Variasi
   Dalam sebuah organisasi, penggunaan kembali perangkat lunak sulit dicapai. Dalam sebuah survei terhadap beberapa objek-berorientasi proyek aplikasi lusin, Goldberg dan Rubin tidak menemukan reuse signifikan Bahkan jika berhasil, manfaat biaya reuse internal yang biasanya kurang dari 15 pengalaman Industri persen menunjukkan bahwa peran utama dari reuse internal sebagai investasi di software untuk dijual kembali. Di mana volume besar membuat potensi penghematan yang signifikan, reuse dapat mempersingkat waktu-ke-pasar dan kustomisasi produk dukungan.

    Di sisi lain, kita mengklaim reuse yang lazim, namun dalam bentuk yang berbeda: penggunaan kembali perangkat lunak yang tersedia secara komersial dan penggunaan kembali freeware. Karena basis pengguna yang lebih besar, perangkat lunak komersial dan freeware sering memiliki kualitas yang jauh lebih tinggi dari perangkat lunak kustom-dikembangkan. Untuk komponen infrastruktur yang di atasnya software banyak aplikasi tergantung, ditingkatkan kualitas ini dapat menjadi penting untuk keberhasilan proyek.

Perangkat lunak komersial dan freeware dapat mengurangi biaya pemeliharaan ketika perangkat lunak digunakan tanpa modifikasi dan dapat dengan mudah diganti dengan versi upgrade.


Solusi terkait
   Dampak pada pengelolaan kompleksitas pertambangan arsitektur dan generalisasi untuk antarmuka umum dianalisis di pertambangan Mowbray 95. Arsitektur adalah solusi berulang yang membahas banyak masalah yang disebabkan oleh cerobong asap Systems. Hal ini juga salah satu pendekatan untuk mendefinisikan arsitektur komponen-domain tertentu.
Berlakunya Untuk Pandangan Dan Timbangan Lainnya


Menemukan kembali Roda antipattern menempatkan manajer pada risiko yang lebih tinggi, dalam bentuk peningkatan waktu-ke-pasar dan tingkat yang lebih rendah dari fungsi daripada yang diharapkan dari pengguna akhir. Potensi penghematan dari jarak reuse 15-75 persen dari biaya pengembangan, pengurangan 2-5 kali dalam waktu-ke-pasar, dan pengurangan cacat dari 5 sampai 10 kali