Selasa, 23 November 2010

uts enterprise resource plan

Service Oriented Architecture : Case Study Example MySnack Supplies Pte Ltd.

Sunday, August 15th, 2010
Brief Introduction
MySnack Supplies Pte Ltd. is a medium-to-high-sized snack supply company operating in Singapore and Jakarta. The company has grown very slowly lately and has been loosing its customers to other competitors that make use of technology. A recent customer’s survey pointed to the ordering process that took a long time to fulfilled. Other survey conducted for employees and indicated that employees need to use multiple applications to finish their daily tasks.
Current order handling process : MySnack publishes and distributes a printed product catalog through mail to its existing customers, and customers can only order by phone.
Solution
Asumsi yang digunakan :
  1. Perusahaan merupakan supplier snack yang tidak memproduksi seperti perusahaan manufaktur.
  2. Singapura merupakan Head Office dimana perusahaan Jakarta harus memberikan laporan ke Singapura.
  3. Produk yang memiliki masa kadaluarsa
  4. Batasan bisnis proses hanya di proses pemenuhan pesanan, tidak membahas proses penerimaan pembayaran yang berhubungan dengan pihak ketiga, penagihan, procurement, pemasaran, cara pengiriman yang berhubungan dengan pihak ketiga.
1. Your understanding of their business pains
  1. My Snack Supplier Pte Ltd. kalah bersaing dengan kompetitor mereka yang sudah menggunakan teknologi dalam kegiatan bisnis mereka.
  2. Banyaknya aplikasi yang digunakan untuk menyelesaikan tugas harian menjadi penyebab lambatnya pemenuhan proses pemesanan oleh konsumen.
  3. Penggunaan waktu yang tidak efektif dan resiko data yang salah dan tidak update disebabkan oleh tidak terintegrasinya aplikasi-aplikasi yang digunakan.
  4. Pemesanan saat ini hanya bisa dilakukan lewat telepon dimana konsumen melihat dari katalog produk yang dikirim lewat surat.
  5. Kesempatan untuk mendapat konsumen baru sangat kecil karena katalog produk hanya dibagikan ke konsumen yang saat ini telah ada.
  6. Katalog yang dikirim melalui surat membutuhkan waktu yang lebih lama sedangkan bisnis makanan memiliki masa kadaluarsa makanan, sehingga resiko kualitas makanan yang memiliki masa kadaluarsa menjadi tinggi.
  7. Perusahaan beroperasi di Singapura dan Jakarta dimana kendala jarak bisa mengakibatkan ketersediaan informasi yang tidak update.
2. A high overview of their current systems
  1. My Snack menerbitkan dan membagikan katalog produk melalui surat ke Konsumen mereka yang telah ada. Hal ini dapat memperlambat bertambahnya Konsumen baru sehingga perusahaan kehilangan kesempatan untuk meningkatkan penjualan.
  2. Konsuman hanya bisa melakukan pemesanan melalui telepon.
  3. Jika alamat Konsumen jauh, maka proses pengiriman akan semakin lama dan kualitas makanan menjadi rendah, dikarenakan dari awal pengiriman katalog ke Konsumen, penerimaannya sudah memakan waktu, selain itu Konsumen yang lokasinya jauh kehilangan kesempatan untuk mengetahui informasi mengenai produk terbaru.
  4. Pemenuhan pesanan yang melalui banyak aplikasi dan memakan waktu yang lama.
use case
3. A proposed high overview system based on SOA Reference Architecture
  1. Karena perusahaan sudah memiliki aplikasi-aplikasi namun belum terintegrasi dan digunakan secara optimal, maka SOA Scenario yang cocok adalah menggunakan Indirect Exposure.
  2. Selain menggunakan fasilitas lewat telepon, pemesanan produk bisa juga dari internet dan layanan SMS.
  3. Membuat web service dimana perusahaan di Singapura dan Jakarta dapat terhubung.
SOA Arch
SO
4. Improved their processes to address their business pains – draw some Business Processes
  1. Pesanan dipenuhi apabila konsumen sudah membayar Lunas karena produk memiliki masa kadaluarsa (Asumsi no. 2)
  2. Web portal yang bisa diakses oleh konsumen sehingga bisa memesan secara online sehingga dapat menghemat waktu Bagian Penerima Order dimana kegiatan input data dilakukan oleh Konsumen
  3. Menyediakan layanan pemesanan lewat SMS untuk meningkatkan kemudahan bagi Konsumen
  4. Dengan penggunaan dan pengembangan teknologi, jumlah pemesanan dapat ditingkatkan karena tidak harus melalui telepon dan area pengiriman dapat diperluas bahkan dengan penggunaan Web Service, Konsumen di Singapura dapat memesan barang untuk area pengiriman di Jakarta dengan biaya lokal karena sudah terhubungnya sistem perusahaan. Waktu pengiriman juga dapat dipersingkat, sehingga permasalahan perusahaan dimana “pemenuhan pesanan yang memakan waktu yang lama” bisa dihilangkan.
flowchart
5. Conclusions
Proses pemenuhan pesanan merupakan proses yang paling penting dalam bisnis perusahaan karena pelayanan yang cepat dan memberikan produk yang berkualitas kepada konsumen dapat meningkatkan loyalitas dan kepercayaan konsumen. Penerapan teknologi dapat mengoptimalkan fungsi sistem yang sudah ada di perusahaan. Dengan penggunaan aplikasi yang efektif, dapat menghemat waktu dalam proses pemenuhan pesanan sehingga intensitas pemenuhan pesanan dapat ditingkatkan. Order Form yang diimplementasikan dengan baik merupakan kunci pokok yang dapat mempermudah pelaksanaan aktivitas dalam proses pemenuhan pesanan.
Bagian gudang juga mendapat kemudahan karena Inventory Turnover yang tinggi sehingga tidak ada penumpukan barang dan kecilnya resiko barang rusak atau kadaluarsa. Selain itu tempat penyimpanan juga dapat dikurangi.
Kegiatan pembuatan laporan juga menjadi lebih mudah dilakukan karena kompilasi data dapat menghasilkan berbagai jenis laporan sesuai kebutuhan pihak manajemen perusahaan dan tentu saja merupakan data yang update.
Penerapan SOA dalam perusahaan dapat meningkatkan kinerja sistem dan efektifitas waktu kerja karyawan. Kepuasan pelanggan pun dapat ditingkatkan.

Pengaplikasian MOC dalam Proyek SAP R/3

Sunday, August 15th, 2010
11 TAHAP DALAM PROYEK SAP R/3
SAP R/3 merupakan proyek yang sama seperti proyek-proyek software lainnya yang memiliki siklus hidup pengembangan software. Jika tahap-tahap dalam proyek SAP R/3 dimasukkan dalam 4 tahap siklus hidup proyek pengembangan software (perancangan, pembangunan, pengujian, pemaparan), maka bisa digambarkan sebagai berikut :
11 tahap
Adapun tahap-tahap dalam proyek SAP R/3 adalah sebagai berikut :
Tahap I : Proyek Start-up dan Persiapan
  • Menentukan kerangka proyek
  • Mengembangkan proporsi nilai
  • Membangun infrastruktur manajemen proyek
  • Memperjelas lingkup perubahan organisasi
  • Mengembangkan rencana proyek
  • Memulai proyek
  • Memonitor dan mengontrol proyek
Tahap II : Analisa Kondisi Sistem Saat Ini
  • Mendokumentasikan lingkungan sistem informasi saat ini
  • Mendokumentasikan proses bisnis dan organisasi saat ini
  • Meninjau dan menyetujui tahap analisa kondisi sistem saat ini
Tahap III : Ruang Lingkup Kondisi Sistem di Masa Depan
  • Menetapkan visi dari sistem bisnis
  • Menentukan solusi dari kesenjangan (gap) awal
  • Menetapkan rencana pemaparan awal
  • Meninjau dan menyetujui tahapan ruang lingkup kondisi sistem di masa depan
Tahap IV : Inisialisasi Infrastruktur
  • Menetapkan contoh pengembangan dan prosedur
  • Melakukan pelatihan tim proyek
  • Menentukan standar pengembangan
  • Meninjau dan menyetujui tahap inisialisasi infrastruktur
Tahap V : Analisa dan Membuat Prototype Transaksi Bisnis
  • Mengidentifikasi transaksi bisnis
  • Mengembangkan prototype SAP R/3
  • Mengumpulkan persyaratan konfigurasi SAP R/3
  • Mengkonfigurasi transaksi bisnis dalam SAP R/3
  • Menjalankan prototype SAP R/3 dan mengembangkan prosedur
  • Meninjau dan menyetujui tahap analisa dan prototype transaksi bisnis
Tahap VI : Membangun Solusi dari Kesenjangan (Gap)
  • Merancang interface
  • Merancang bolt-ons
  • Merancang modifikasi SAP R/3
  • Merancang implementasi dari modul tambahan SAP R/3
  • Merancang transaksi bisnis yang diubah
  • Merancang laporan
  • Membangun dan menguji interface
  • Membangun dan menguji bolt-ons
  • Membangun dan menguji modifikasi SAP R/3
  • Mengimplementasikan dan menguji perubahan transaksi bisnis
  • Membangun dan menguji laporan
  • Mengintegrasikan uji coba solusi dari kesenjangan (gap)
Tahap VII : Pemaparan Infrastruktur
  • Merancang konversi data
  • Membangun dan menguji aplikasi konversi data
  • Menetapkan contoh pengujian dan prosedur
  • Merancang pengujian sistem
  • Migrasi ke contoh pengujian
  • Menetapkan contoh produksi dan prosedur
  • Meninjau dan menyetujui tahap pemaparan infrastrukur
Tahap VIII : Prosedur bagi Pemakai dan Pengembangan Pelatihan
  • Mengembangkan panduan prosedur bagi pemakai
  • Menjadwalkan pelatihan dan mengembangkan materi
  • Mengadakan pelatihan pemakai
  • Meninjau dan menyetujui tahap prosedur bagi pemakai dan pengembangan pelatihan
Tahap IX : Pengujian Sistem
  • Melakukan pengujian konsolidasi fungsional
  • Melakukan pengujian kinerja
  • Melakukan pengujian penerimaan
  • Meninjau dan menyetujui tahap pengujian sistem
Tahap X : Pemaparan Solusi
  • Migrasi ke contoh produksi
  • Mengimplementasikan strategi pelanggan
  • Meninjau dan menyetujui tahap pemaparan solusi
Tahap XI : Meninjau dan Menilai Proyek
  • Meninjau kinerja proyek
  • Menyelesaikan proyek
Setiap organisasi yang memulai sebuah proyek untuk membuat proses bisnis menjadi lebih kompetitif dengan menggunakan program software SAP, perlu menetapkan dasar untuk perubahan proses yang berkelanjutan. Program SAP mempunyai tiga tujuan :
  1. Merancang ulang proses untuk meningkatkan penerapan SAP yang terbaik dan sesuai
  2. Mengembangkan kemampuan bereaksi cepat, efektif dan ekonomis untuk mengubah kebutuhan bisnis
  3. merealisasikan penghematan biaya sebagai hasil standarisasi teknologi dan proses bisnis
Salah satu kunci untuk mewujudkan manfaat inisiatif ini adalah secara proaktif mengidentifikasi pihak-pihak yang berkepentingan – stakeholder – yang terpengaruh secara signifikan oleh perubahan yang terkait dengan implementasi SAP. Saat stakeholder teridentifikasi dan implikasi dari perubahan pada kelompok-kelompok ini dinilai, strategi dirancang dan kegiatan taktis yang mencakup pelatihan dan pendidikan, komunikasi, dan keterlibatan pemakai akhir, akan dikembangkan.
Untuk membantu memastikan pendekatan tunggal untuk mengelola perubahan, metode MOC, komunikasi, dan solusi kinerja tim secara terstruktur terintegrasi dalam kelompok yang disebut Organizational and Individual Readiness (OIR). OIR merupakan bagian dari tim proyek SAP.
Adapun misi dari OIR adalah mendapatkan pemahaman kebutuhan karyawan, dengan memfasilitasi individu dan transisi organisasi sambil memungkinkan kemampuan karyawan.
Tujuan yang ingin dicapai oleh OIR adalah mengidentifikasi stakeholder yang terkena dampak dan mengembangkan profil stakeholder yang merangkum perubahan dari masing-masing kelompok, membangun strategi dan taktik yang komprehensif untuk mengelola perubahan, meminimalkan gangguan terhadap operasi sehari-hari dan secara umum memfasilitasi kelancaran transisi dengan lingkungan baru.
Objektif dari OIR adalah memastikan bahwa setiap kelompok stakeholder menerima jenis dan tingkat intervensi manajemen perubahan yang sesuai untuk menyediakan tingkat komitmen yang sesuai dan memahami proyek sebagaimana diukur dari survey stakeholder, meminimalkan kerugian produktivitas dan gangguan operasi sehari-hari sebagaimana diukur dari survey pengawas.
Adapun integrasi antara komunikasi, MOC dan tim solusi performa dapat ditunjukkan dalam gambar berikut :

integrasi

STRATEGI MOC UNTUK PROYEK SAP R/3
Dalam menerapkan MOC dalam proyek SAP, ada empat konsep inti yang membentuk strategi MOC secara keseluruhan yaitu :
  1. Profil stakeholder
  2. Kontinum komitmen
  3. Strategi profil
  4. Integrasi dengan tim proyek yang lain
1. Profil Stakeholder
Konsep dasar dari strategi MOC berkisar di gagasan tentang profil stakeholder. Profil stakeholder adalah pengelompokan individu, peran, posisi, pekerjaan, atau unit organisasi (unit mana yang tepat untuk diberikan perubahan) yang dipengaruhi dengan cara yang sama oleh perubahan yang disebabkan oleh pemaparan SAP. Pembuatan profil ini memungkinkan pembentukan strategi untuk mengelola perubahan tebaik untuk setiap pengelompokan. Untuk mengembangkan profil stakeholder, informasi dikumpulkan dari berbagai sumber. Anggota tim OIR akan mengkompilasi informasi ini dalam database perubahan yang dirancang oleh tim untuk memungkinkan kompilasi dan penyortiran implikasi perubahan. Anggota tim OIR akan meninjau dan menganalisis informasi dan membuat profil stakeholder. Profil dibuat berdasarkan bagaimana perubahan didorong oleh implementasi mempengaruhi kelompok stakeholder di seluruh organisasi. Ada dua kategori profil stakeholder :
1. Profil Sponsor/Pendukung/Agen Perubahan
Sponsor, pendukung, dan agen perubahan akan diperlakukan sebagai sasaran pertama, untuk membangun komitmen untuk proyek tersebut. Strategi yang dikembangkan adalah menempatkan orang-orang dalam kelompok ini dalam proses menerima perubahan pada saat yang sama ketika mereka memperjuangkan perubahan. Dukungan untuk kelompok kritis ini akan diberikan oleh manajer proyek dan tim pemaparan sebagai anggota dari kelompok kunci untuk menjalankan peran mereka.
2. Profil Target
Strategi profil target dirancang untuk menggerakkan masing-masing kelompok profil target kemana pun dibutuhkan sebelum pemaparan kontinum komitmen. Rancangan strategi didasarkan pada pelatihan, pendidikan, komunikasi, dan keterlibatan bahwa profil stakeholder target dibutuhkan untuk mencapai tingkat komitmen yang tepat ke arah perubahan. Strategi profil target akan dilaksanakan terutama melalui pemaparan infrastruktur, dengan bantuan dan bimbingan tim MOC. Tanggung jawab utama untuk pelaksanaan beberapa strategi profil target (yang melibatkan kelompok target yang berada di luar pemaparan infrastruktur) akan menjadi milik tim MOC.

Output utama dari profil stakeholder adalah strategi dan aktivitas taktis yang disesuaikan untuk setiap profil yang begerak kea rah profil lokasi yang sesuai dengan kontinum komitmen.
2. Kontinum Komitmen
Setiap anggota profil stakeholder perlu mencapai tingkat komitmen tertentu terhadap proyek SAP agar berhasil. Tingkat komitmen yang diperlukan beragam dilihat dari bagaimana stakeholder terpengaruh oleh perubahan atau apa yang mereka minta untuk melakukan perubahan.
Penempatan yang diinginkan dari setiap profil stakeholder sepanjang kontinum komitmen sebelum setiap tahapan proyek akan digunakan untuk membimbing dan mengembangkan keterlibatan, komunikasi, pelatihan, strategi pendidikan, dan kegiatan taktis untuk setiap profil stakeholder dan untuk memastikan bahwa jumlah usaha yang tepat dikeluarkan oleh masing-masing kelompok.
3. Strategi Profil
Strategi dan kegiatan taktis akan dikembangkan bagi profil stakeholder untuk menggerakkan masing-masing kelompok terhadap tingkat komitment yang diperlukan. Pendekatan secara keseluruhan dari MOC dan strategi profil stakeholder secara khusus, harus sesuai dengan parameter proyek secara keseluruhan. Misi, visi, dan prinsip operasi dari proyek akan digunakan untuk membuat kerangka dimana semua keputusan strategi manajemen perubahan akan dibuat. Selanjutnya, misi tim OIR memastikan usaha yang diberikan cukup untuk berhasil menerapkan strategi.
4. Integrasi Dengan Tim Proyek yang Lain
MOC akan mengintegrasikan dengan tim fungsional untuk mengidentifikasi dan memahami perubahan yang disebabkan oleh implementasi SAP. Setiap anggota MOC akan berfungsi sebagai penghubung ke salah satu tim fungsional (bekerja dengan anggota tim ORI yang lain), dengan tanggung jawab :
  1. Meninjau dan memahami masing-masing kegiatan skrip rancangan yang dikembangkan oleh tim fungsionalnya
  2. Menandatangani skrip setelah memastikan bahwa semua informasi diperlukan dari perspektif pemaparan
  3. Memasukkan informasi ke dalam databse OIR
  4. Membangun hubungan berkelanjutan dengan anggota tim fungsional yang ditugaskan untuk memastikan akses ke ahli dalam masalah subyek saat proyek berlangsung
Comitment continum

RENCANA TAKTIS, UMPAN BALIK, DAN TAHAP MOC
Rencana Taktis
Setelah strategi dan kegiatan taktis sudah ditetapkan untuk setiap profil stakeholder, eksekusi akan dimulai. Ini akan berbeda untuk dua kategori profil. Untuk profil sponsor/pendukung/agen perubahan, tim OIR akan memiliki tanggung jawab utama untuk melaksanakan kegiatan taktis, termasuk untuk berkomunikasi, mendidik, dan melibatkan individu dalam suatu profil. Beberapa kegiatan akan dilakukan dalam bidang organisasi melalui pemaparan infrastruktur. Namun, kepemilikan utama untuk mendaftarkan para sponsor, pendukung, dan agen perubahan dilakukan oleh tim OIR dan koordinasi. Untuk profil target, para manajer pemaparan akan bertanggung jawab untuk meninjau strategi profil dan kegiatan yang telah dikembangkan, menyesuaikan strategi-strategi dan kegiatan sesuai organisasi mereka sendiri, dan mengembangkan dan melaksanakan rencana taktis untuk memastikan pemaparan yang sukses. Para manajer ini akan memiliki kepemilikan pemaparan utama pengembangan rencana taktis dan pelaksanaan, namun akan dipandu dan dibantu oleh anggota tim koordinasi pemaparan dan OIR dan, terutama, oleh para pelatih pemaparan.
Umpan Balik
Proses umpan balik secara formal harus dilakukan untuk memastikan bahwa strategi dan pendekatan MOC secara keseluruhan, sama seperti strategi dan kegiatan taktis profil stakeholder yang disesuaikan. Beberapa mekanisme untuk mengumpulkan umpan balik dari pengguna akhir antara lain :
  • Evaluasi dari demonstrasi nyata, seperti Proof of Concept atau presentasi Skenario Day-in-the-Life untuk peran spesifik dan jabatan.
  • Hubungan antara pemaparan infrastruktur (pemaparan pelatih, manajer, dan koordinator) dan OIR dan pemaparan tim koordinasi. Hubungan ini akan memastikan bahwa informasi dari unit operasi dikumpulkan dan disalurkan kembali ke tim pemaparan.
  • Hubungan antara OIR dan tim fungsional (penghubung OIR ke tim fungsional dan penghubung tim fungsional ke OIR, dimulai pada Tahap Pembangunan dari proyek). Hubungan ini akan memastikan bahwa informasi yang dikumpulkan di lapangan disalurkan kembali ke tim fungsional selama Tahap Pembangunan dan Pengujian.
  • Secara luas dikenal dan mendistribusikan telepon dan akses elektronik untuk menghubungkan dari lapangan langsung ke tim proyek.
Umumnya alat evaluasi yang berlaku (seperti survei elektronik dan manual) dan kuesioner akan dikembangkan oleh tim MOC untuk mendukung saluran umpan balik.
Tahap MOC Untuk Mendukung Proyek SAP

MOC
KESIMPULAN
Untuk menyadari nilai tambah dari setiap proyek SAP, adalah mutlak dan wajib untuk memiliki program MOC yang efektif dipadukan dengan proyek SAP. Terlalu sering proyek SAP gagal mencapai potensi yang dijanjikan karena tim proyek difokuskan pada upaya proses perubahan melalui penggunaan teknologi yang efektif tanpa menempatkan usaha yang sama pada penyusunan karyawan dan manajemen untuk merangkul proses baru dan peralatan.
Secara historis pandangan tentang manajemen perubahan adalah taktis, terkait dengan layanan manajemen perubahan dengan proyek-proyek tertentu. Organisasi sekarang melihat bahwa kemampuan untuk secara efektif mengelola transformasi sebagai misi-kritis dan kebutuhan strategis. Ini harus dibangun dalam bagaimana mereka mengelola bisnis mereka jika mereka ingin menjadi pendorong industri dan tidak mematikan industri.
DAFTAR PUSTAKA
Harrington H. James, Conner R, Conner, Horney, Nicholas F, “Project Change Management”, 2000, McGraw Hill

Integrating BPM with Six Sigma

Sunday, August 1st, 2010
Preface
Nowadays, companies are just discovering the benefits of combining BPM and Six Sigma. Ideal for enhancing the long-term performance of business processes, the BPM and Six Sigma union helps companies better characterize, understand, and manage entire value chains. It also helps companies improve control and predictability of corporate business processes and generate sustainable enterprise improvements in performance levels.
BPM aligns processes across an enterprise using technologies to provide visibility and management at any point in a business process. BPM and associated technologies help model data flow, people, resources, and systems in an organization. They also help build or modify processes to better align enterprise systems with business objectives and market needs. Unfortunately, BPM lacks the analytical tools to solve difficult and complex process problems. Six Sigma, on the other hand, is a quality improvement and problem solving methodology. It has the tools necessary to solve the complex problems BPM can’t solve. Where Six Sigma falls short is in its ability to collect huge amounts of data across enterprises, the direct result of a lack of standardized process monitoring technology. Six Sigma also falls short in controlling business processes. It often uses manual methods and controls, which inhibit its ability to sustain long-term performance initiatives.
Without BPM, Six Sigma may founder because executives lack the critical data needed to focus their efforts. Instead, the executives bounce all over the place looking for performance weaknesses, or they focus on areas where successful performance improvements provide only marginal results. With BPM, Six Sigma projects can pinpoint problems and address the underlying causes.
Business Process Management
Business Processes are a group of activities which are recurring in nature and contribute significantly to the growth and development of the business. Managing these activities efficiently so that maximum business benefit can be captured is better known as Business Process Management. Large organizations with good business process management skills have even managed to put an abstract activity such as Innovation as part of their process management cycle. Even thinking or strategizing for the future is part of a Business Process. Thus the first step in understanding Business Process Management is to understand the range of activities which qualify as Business Process and only then can they be documented and subsequently managed.
The first step when implementing Business Processes in any organization is to understand the lifecycle of a business process. Key questions which need to be answered are :
  1. Why is it important to improve business processes before automating them?
  2. When should you do BPM – what are the main drivers and triggers?
  3. Who should be involved in BPM?
  4. Why are organizational strategy and process architecture important in BPM implementation?
  5. How do you sell BPM technology to the organization?
  6. How do you sell BPM technology to the organization?
  7. What are the critical implementation aspects for a BPM solution?
  8. Why do you need a structured approach to implementing BPM?
Once these key questions are answered and documented, the outline of a defined business process can be seen. All business activities are made up of multiple business processes and business process management is to make sure that these processes are working together for the greater benefit of the organizations. Some of the key points to consider when setting up business processes are discussed in the rest of this article.
Keep in mind that these processes will be managed by people. A business process should not be very rigid; neither should it be too open ended. There should be some room for innovation within the process as well as that is the business process can be improved over a period of time. Many management gurus consider successful organizations those which have captured the DNA of a business process within their working framework.
Simple documentation and automation also makes business process automation work in the long run. If using software to automate business process, it should be made sure that people have been suitably trained on it and rather than change the way of working of the company, the software conforms to the process that you already follow. The automation should be complimentary to business and not anti-productive. It is imperative to remember that Business Process Management is suppose to save time and resources in an organization and should be approached with that principle in mind.
Adherence to Business Process throughout the organization is a must for any organization to gets it full impact. Developing or outlining a business process without true permeation with the company, is like giving a bird wings but asking it not to fly. It is successful implementation and following of a set business process which will save time and money in the organization and bring about greater efficiencies. Following business processes also helps in getting the most out of the people employed in the company without going back to the drawing board each time a familiar situation comes up.
The term Management in Business Process Management makes this activity an ongoing one. One a business process has been set and put in automated or semi-automated motion, it is critical that the process is reviewed at regular intervals to evaluate the affectivity of the process. A facility to maintain feedback from users of the process much be implemented and periodical review of the process and feedback from users will help in implementing changes and improving the process on an ongoing basis. A mature organization is one which has managed to implement the Business Process of Managing Business Processes effectively. The Business Process Management process has been an established business activity for quite some time. Some industries have industry specific business process management certifications. Benchmarking allows to go full throttle in business process management as well as provide excellent ammunition to increase the value of organization in front of customers, suppliers and employees.

Six Sigma
Six Sigma at many organizations simply means a measure of quality that strives for near perfection. Six Sigma is a disciplined, data-driven approach and methodology for eliminating defects (driving towards six standard deviations between the mean and the nearest specification limit) in any process – from manufacturing to transactional and from product to service. The statistical representation of Six Sigma describes quantitatively how a process is performing. A Six Sigma defect is defined as anything outside of customer specifications. A Six Sigma opportunity is then the total quantity of chances for a defect.
The fundamental objective of the Six Sigma methodology is the implementation of a measurement-based strategy that focuses on process improvement and variation reduction through the application of Six Sigma improvement projects. This is accomplished through the use of two Six Sigma sub-methodologies :
  1. The Six Sigma DMAIC process (define, measure, analyze, improve, control) is an improvement system for existing processes falling below specification and looking for incremental improvement.
  1. Define : The first step for such an initiative is to define the current processes of a function, with outputs clearly determined. Data is collected to determine the health of the performance of the particular process as compared to predefined targets. If there is a deviation in the performance measured from the particular process, the effect of the deviation may be translated into monetary terms.
  2. Measure : BPM process maps are developed which incorporate various critical elements of the process. These would include business systems, people and resources that are involved in the entire process. The functions performed by each of these elements are defined and utilized in the analysis stage.
  3. Analyze : With all data and information at hand, an analysis is conducted on the business process to determine areas of weaknesses. What are the key courses for the deviation? How does this deviation affect other processes? Which steps of the processes are too slow? Where is the backlog? This to identify parts of the processes which were irrelevant or which does not add value to the process.
  4. Improve : Once weaknesses are discovered, areas for improvement to address these weaknesses will be identified. This would incorporate the use of “what if” hypothetical solutions in order to shortlist several possible scenarios that would work to improve the current process. A form of integration between automated and human run processes will be developed. At this juncture, the utilization of machines or applications for greater efficiency will be customized towards the particular business process. Data flow between automated processes and human operated processes will need to be smooth.
  5. Control : Monitoring and tracking system needs to be put in place, most probably in the form of a BPM monitoring system where performance indicators are constantly measured. This way, the management team will be able to react to deviations quickly, and make any amendments whenever necessary.
dmaic
  1. The Six Sigma DMADV process (define, measure, analyze, design, verify) is an improvement system used to develop new processes or products at Six Sigma quality levels. DMADV can be used to replace DMAIC at the time there has not produced the expected result, out of which the organization is aiming to create from the scratch. At the time when the implementation of DMAIC , though best efforts are done to make the improvements, DMADV methods can be used.
    1. Define : It describes the need for defining the needs for finding out the goals from the project to be executed, in order to meet the customer satisfaction. Therefore, the first step involves in the explanation of both the internal and external goals from the product.
    2. Measure : The process is done to find out the quantity of the customer’s needs to measure the goal management and the quality of the product.
    3. Analyze : Through the process of analyzing, it is able to find out the existing cause of errors with in the organization and the process. It also helps in evaluating the corrective measures
    4. Design : Once the error origination is found out, the next step is to design the new process or a corrective measures to meet the target specification
  1. Verify : Verification is done simultaneously, to check the performance of the developed design and its quality.
dmadv
Implementing BPM and Six Sigma
BPM approaches are used to define current processes and their role across multiple functions, identify areas within the process that affect critical success factors and develop process improvements for these areas of weaknesses. The identification of gaps between existing processes and ideal processes are addressed with Six Sigma initiatives.
Combined BPM and Six Sigma are a powerful tool. The two approaches are synergistic. What one lacks the other provides and vice versa. Together, they are a better approach to understanding, analyzing, and improving business processes than other methodologies alone. Unfortunately, this union has not become a mainstream approach to improving enterprise-related business processes. One reason may be that companies are unaware of how well these two initiatives work in concert with each other.
A complete Six Sigma methodology and BPM governance organization is essential to reach the benefits which are required to successful implement business process excellence and achieve cost reductions. Six Sigma is a useful and rigorous approach to improve quality. However, Six Sigma only addresses a portion of the components required in a business transformation or improvement project as it and does not provide the tools and methods of moving towards a process-centric organisation. Six Sigma is not a subset of BPM, it is a useful adjunct. The main issues missing are :
1.  The alignment with organisation strategy is crucial to ensure that the strategic objectives and directions are clearly and fully understood prior to improving the processes. This allows critical review of the end-to-end process and its contribution to the overall organisational objectives and results.
2.  The Process Architecture relates to the alignment of the Process Architecture with the business and IT, as well as process guidelines which are the foundations for subsequent process models. This is essential to ensure that it fits with the overall organisation, business and IT objectives. Any changes to these foundations must be reviewed on its merits and communicated. This is the best way to ensure that the processes are transparent and thus manageable.
3.  Fundamentally changing (or re-engineering) the business process to meet current business challenges. Most organisations must look at fundamentally changing their end-to-end processes, rather than just tweaking around the edges : address the root-causes rather than fighting symptoms.
4.  The use of automated BPM tools and a process model and management tool to analyze the outcome of processes provides valuable information. It is crucial that the process itself is not treated as a black box, and all relevant steps (including hand-offs and exceptions) are visible and clearly documented. Good process documentation supports employees in completing their work, allows management to more clearly understand how to manage their processes and allows process professionals to identify additional opportunities for improvement. Important step towards a process-centric organisation and using a Process Modelling and Management tool provides the opportunity to :
  • Share the process information with others
  • Generate reports and identify areas for improvement
  • Relate relevant information (e.g. documents, systems, people and organisational elements) to processes.
5.  The essentials of a BPM project, namely People Change Management, Project Management and Leadership, are especially crucial when innovating rather than just improving the processes. BPM projects fail, not because it propose the wrong improvements, but because it does not consider all the relevant project and implementation aspects. BPM projects are primarily a change management project, not a technology or process project.
6. End-to-end focus of processes, across functional silo’s and even across organisational boundaries whereas the traditional Six Sigma approach relates to optimising a specific component of a process.
7. The management of the processes BPM is aimed at the achievement of an organisation’s objectives through the improvement, management and control of essential business processes. BPM clearly provides the mechanism and tools to manage the processes. Six Sigma provides information that focuses on the measurement of defects. It does not focus on the people aspects of process management.
Case Study : Bharti Airtel Limited
Bharti Airtel Limited was a leading private sector provider of telecommunication services in India, with a customer base of 8.73 million as of July 2004. The company had two branch companies — Bharti Infotel (that dealt with fixed line, long distance, and enterprise services) and Bharti Cellular (that dealt with mobile telephone services). This case is about the six sigma implementation at Bharti Infotel. The case briefly discusses the business imperatives in the fast changing Indian telecommunications industry.
The industry was a monopoly for over half a century after independence and had recently been deregulated with the private players competing with the state-owned BSNL. The industry had exploded in the recent years with increasing number of players, falling tariffs, and improving technology. Stiff competition in the industry meant that any competitive action by a company was immediately imitated by others. Therefore the only sources of competitive advantage in the industry were “quality of service” and “speed”.
This case discusses the various steps in the implementation of six sigma quality management system in the company. The company had already implemented Business Process Management Systems (BPMS) and had begun monitoring their performance on the Non-Financial Parameters (NFPs). The six sigma initiative was expected to leverage on these initiatives. Following the six sigma initiative was the Knowledge Management (KM) initiative that was intended to help share the best practices and learning from the six sigma projects across the entire organization.
This case highlights the contribution of the six sigma quality management initiative to the company’s business strategy, and helps students analyze the process of implementing and institutionalizing the six sigma initiative. The case enables the readers to appreciate the business benefits of six sigma implementation and how it fosters innovation.
corporate structure
Six Sigma Project Selection
The business imperatives (called Big Y’s) drove the selection of Six Sigma projects at Bharti Infotel. The big Y’s were drilled down into little Y’s, processes, critical to quality (CTQ) measures, and projects (as shown in an example in Fig. 2 below).
big Y
The choice of projects happened through a selection from the various project proposals generated. The proposals could be generated through either of the three sources — the Customer Satisfaction (C-Sat) surveys (conducted by an external agency every six months) identify the “red areas”; the monitoring of the NFPs to identify “low performing areas”; or the set of “priority areas” identified by the top management. The CEOs and their executive committee teams then prioritized these projects, and the champion and the project leader were identified for each project. These champions and project leaders then chose their team members. The champions were identified in such a way that they were the customers of these projects, rather than the CEOs. The champions therefore, reviewed the projects’ progress periodically.
There were three major impacts of Six Sigma implementation at Bharti :
  • Not only did people begin appreciating that improvements had happened, but the reasons why they happened as well. This appreciation led to an analysis of the causes of these improvements, and action towards ensuring that this improvement is sustained.
  • The rigor of analysis had improved significantly. People began going to the root causes of the problems, rather than just closing the issue. In terms of tools, the Six Sigma shifted people from analyzing averages to “variations,” a superior indicator of defects. People began talking based on data, rather than just gut feelings or experience.
  • A culture of working in teams had begun as a consequence of working in these Six Sigma projects. The emphasis on customer satisfaction, process definitions, and ensuring process compliance highlighted the interdependence across various functions in the organization and the customer was owned by everyone (not just the front-end employee or sales and marketing functions). These factors, along with the fact that a larger number of associates (people working on contract) began working in Six Sigma projects led to the reinforcement of the culture of working in teams.
As the projects matured, and the organization began replicating success stories across various business, there were far reaching changes in the way management perceived quality as a function, the way people approached processes and problem solving, and the way projects were selected (see Fig. 3).
Major
major2
Conclusion
When Six Sigma projects managed centrally and with an enterprise BPM software application, yield organizations tremendous value in a number of areas. At the top of this list are a few primary categories where this value lies. These include customer satisfaction, increased productivity and reduced costs. Perhaps the single most important aspect of any business, customer satisfaction, is one of the foremost beneficiaries typically of Six Sigma projects. This is due to the fact that Six Sigma is very useful for optimizing customer touch points such as a call center, an email reply system, complaint tracking and so on. Furthermore, even the smallest of improvements in these areas can have a profound effect on the organization’s ability to better serve its clients. In turn, the company is enhancing its overall customer experience and strengthening its relationship with clients.
At the very heart of any Six Sigma project is likely some need to increase efficiency and/or decrease redundancy. This is accomplished – with the help of a BPM system – by standardizing, streamlining, measuring and improving business processes to reduce variations, defects and redundancies and build control into new and existing processes. Moreover, virtually any productivity enhancement can subsequently be directly tied to some sort of bottom-line benefit (cost savings, revenue increase, etc.) – whether it be getting more done with less, having more time for cross-selling and up-selling, decreasing customer churn, enhancing customer loyalty, and so on.
In the end, there are but a few true ways of improving one’s business operations – you do things better or get better people. The latter is something for you HR department to focus on, but BPM and Six Sigma can most certainly satisfy the former. From consistency in operations to cross-departmental visibility to centralized management reporting, BPM and Six Sigma can and will optimize the performance of today’s and tomorrow’s financial institutions. All it takes is some training, steadfast commitment, a dedicated staff and the right tools and methodology.
References
  • Business Process Management Practical Guidelines.Jhon Jeston and Johan Nelis. 2006. Elsevier Ltd.
  • ASIAN CASE RESEARCH JOURNAL, VOL. 11, ISSUE 2 (2007)
  • http://www.bhartiairtel.in
  • http://www.bpm.com/joseph-goodman.html
  • http://www.managementbyprocess.com/joomla/images/ArticlesWhitePapers/why%20six%20sigma.pdf

Penerapan Metodologi Model Spiral Dalam Sistem Perpustakaan Terpadu di University of Southern California (USC)

Friday, July 30th, 2010
PENDAHULUAN
Saat ini, ketersediaan workstation, jaringan, dan infrastruktur penyimpanan data yang murah, memungkinkan berbagai aktivitas eksplorasi pemrograman menjadi bagian dari proses pengembangan sistem perusahaan. Hal ini juga mendukung pengembangan prototipe atau model sebagai bagian dari sistem, mendapatkan reaksi dari user, dan juga dapat memberikan informasi mengenai tanggapan ke dalam proses pengembangan. Upaya standardisasi telah menghasilkan kumpulan informasi yang besar bagi komponen dan bahkan seluruh subsistem yang dapat digunakan untuk mengurangi jumlah kebutuhan pengembangan baru dalam sebuah proyek. Kemampuan pertumbuhan pengembangan sistem dan lingkungan telah mempercepat kecenderungan ini.
Model spiral menjadi sebuah pendekatan yang realistis bagi perkembangan sistem dan software skala besar. Karena aktivitas terus bekerja selama proses bekerja. Developer dan pemakai memahami dan bereaksi lebih baik terhadap resiko dari setiap tingkat evolusi. Model spiral menggunakan prototipe sebagai mekanisme pengurangan resiko. Tetapi yang lebih penting, model spiral memungkinkan developer menggunakan pendekatan prototipe pada setiap keadaan di dalam evolusi produk. Model spiral menjaga pendekatan langkah demi langkah secara sistematik seperti yang diusulkan oleh siklus hidup klasik, tetapi memasukkannya ke dalam kerangka kerja iteratif yang secara realistis merefleksikan dunia nyata.
LANDASAN TEORI
A. Metodologi Model Spiral
Model ini ditemukan, sekitar tahun 1988 oleh Barry Boehm pada artikel A Spiral Model of Software Development and Enhancement. Model Spiral adalah salah satu bentuk evolusi yang menggunakan metode iterasi natural yang dimiliki oleh model prototyping dan digabungkan dengan aspek sistimatis yang dikembangkan dengan model waterfall. Setiap lintasan pada gambar spiral menambahkan kemampuan fungsional pada sistem. Point akhir yang diberi label “delivered system” sesungguhnya bukan merupakan akhir dari lintasaan spiral, melainkan merupakan awal spiral baru yang dimulai dengan pemeliharaan dan evolusi (maintenance and evolution) dari sistem.
Pendekatan dengan model ini sangat baik digunakan untuk pengembangan sistem dalam skala besar karena progres perkembangan dari proyek dapat dipantau oleh kedua belah pihak baik developer maupun user/customer, sehingga mereka dapat mengerti dengan baik mengenai proyek ini. Begitu juga dengan resiko yang mungkin didapat pada setiap aktivitas yang dilakukan. Kelebihan dari model ini ada pada analisa resiko yang dilakukan sehingga resiko tersebut dapat dikurangi sebelum menjadi suatu masalah besar yang dapat menghambat proyek. Model ini membutuhkan pertimbangan langsung terhadap resiko teknis, sehingga diharapkan dapat mengurangi terjadinya resiko yang lebih besar. Walaupun dengan menggunakan prototipe juga bisa menghindari terjadinya resiko yang muncul, tetapi kelebihan dari model ini adalah dilakukannya proses prototyping untuk setiap tahap dari evolusi produk secara berkesinambungan. Model ini melakukan tahap-tahap yang sudah sangat baik didefinisikan pada model waterfall dan ditambah dengan iterasi yang menyebabkan model ini lebih realistis untuk merefleksikan dunia nyata. Hal-hal ini merupakan kelebihan dari spiral model.
B. Aktivitas-aktivitas Dalam Model Spiral
Spiral model dibagi menjadi beberapa framework aktivitas, yang disebut dengan task regions. Kebanyakan aktivitas-aktivitas tersebut dibagi antara tiga sampai enam aktivitas. Berikut adalah aktivitas-aktivitas yang dilakukan dalam spiral model :
  1. Komunikasi Pelanggan (Customer Communication) yaitu tugas-tugas yang dibutuhkan untuk membangun komunikasi yang efektif diantara developer dan pelanggan.
  2. Perencanaan (Planning) yaitu tugas-tugas yang dibutuhkan untuk mendefinisikan sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
  3. Analisa Resiko (Risk Analysis) yaitu tugas-tugas yang dibutuhkan untuk menaksir resiko-resiko yang mungkin akn dihadapi, baik dari segi manajemen maupun teknis.
  4. Perekayasaan (Engineering) yaitu tugas-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut.
  5. Konstruksi dan Peluncuran (Construction and Release) yaitu tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (instalasi) dan memberikan pelayanan kepada pemakai, contohnya pelatihan dan dokumentasi.
  6. Evaluasi Pelanggan (Customer Evaluation) yaitu tugas-tugas yang dibutuhkan untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi software, yang dibuat selama masa perekayasaan, dan diimplementasikan selama masa pemasangan.
spiral model
Gambar 2.1 : Diagram Spiral Development
Sektor-sektor pada Spiral Model adalah:
  1. Mengidentifikasi tujuan, alternatif, dan kendala setiap tahap secara spesifik
  2. Mengevaluasi alternatif, menilai resiko dan pengurangannya, aktifitas ditempatkan untuk mengurangi resiko kunci
  3. Pengembangan dan validasi
  4. Proyek ditinjau ulang dan tahap spiral berikutnya direncanakan
Satu lingkaran dari bentuk spiral pada spiral model dibagi menjadi beberapa daerah yang disebut dengan region. Region tersebut dibagi sesuai dengan jumlah aktivitas yang dilakukan dalam model spiral. Lingkup tugas untuk proyek yang kecil dan besar berbeda. Untuk proyek yang besar, setiap region berisi sejumlah tugas-tugas yang tentunya lebih banyak dan kompleks daripada untuk proyek kecil. Pada awal proses, siklus mungkin pendek sebagai alternatif, ruang keputusan proyek dieksplorasi. Setelah resiko diatasi, siklus mungkin menjadi lebih renggang, dengan kuadran pengembangan yang berasal dari beberapa langkah di metode waterfall. Spiral dapat diakhiri dengan pengiriman produk, dalam hal modifikasi atau aktivitas pemeliharaan spiral baru, atau spiral awal dapat terus dilanjutkan sampai produk pensiun. Pelaksanaan berjalan dari inti spiral berjalan mengitari sirkuit per sirkuit. Sebagai contoh untuk sirkuit pertama dilakukan untuk pengembangan dari spesifikasi dengan mencari kebutuhan customer. Untuk sirkuit pertama harus menjalani semua aktivitas yang didefinisikan. Setelah satu sirkuit terlewati, maka dilanjutkan ke tugas selanjutnya misalnya membangun prototipe. Tugas ini juga harus mengitari satu sirkuit dan begitu terus selanjutnya sampai proyek selesai.
six spiral essential
Gambar 2.2 : Six Spiral Essential
Tidak seperti model-model konvesional dimana setelah proyek selesai, maka model tersebut juga dianggap selesai. Hal ini tidak berlaku untuk model spiral, dimana model ini dapat digunakan kembali sepanjang umur dari software tersebut. Pada umumnya, model spiral digunakan untuk beberapa proyek seperti Concept Development Project (Proyek Pengembangan Konsep), New Product Development Project (Proyek Pengembangan Produk Baru), Product Enhancement Project (Proyek Peningkatan Produk), dan Product Maintenance Project (Proyek Pemeliharaan Produk). Keempat proyek tersebut berjalan berurutan mengitari sirkuit dari spiral. Sebagai contoh setelah suatu konsep dikembangkan dengan melalui aktivitas-aktivitas dari model spiral, maka dilanjutkan dengan proyek selanjutnya yaitu pengembangan produk baru, peningkatan produk, sampai pemeliharaan proyek. Semuanya melalui sirkuit-sirkuit dari model spiral.
proyek spiral model
Gambar 2.3 : Proyek-proyek dalam Model Spiral
Keunggulan model ini adalah :
  1. Model ini sangat baik digunakan untuk sistem dan software yang besar.
  2. Menekankan pada pencarian okumative, dan pemaksaan penggunaan kembali software yang telah ada.
  3. Adanya analisa resiko pada mekanisme untuk memperkecil resiko
  4. Adanya prototyping sehingga memudahkan komunikasi dengan konsumen

Kelemahan model ini adalah :
  1. Memerlukan waktu yang cukup lama untuk mengembangkan software.
  2. Sistem pengendalian yang kurang baik
  3. Biasanya pihak developer dan perusahaan berada pada satu pihak yang sama sehingga pada tahap analisa resiko, mereka bisa sewaktu-waktu dapat membatalkan proses rekayasa Jika pihak developer adalah pihak di luar perusahaan, maka akan timbul masalah okum
C. WinWin Spiral Model
Agar perusahaan memiliki titik acuan umum untuk mengatur manajemen prosedur, biaya dan estimasi jadwal, dan sebagainya, maka penerapan WinWin Spiral Model dapat membantu mengkoordinasi langkah-langkah yang harus diambil karena siklus didorong oleh faktor resiko dan masing-masing proyek memiliki resiko berbeda.
WinWin spiral model dapat menghubungkan penyelesaian dari model spiral dengan tujuan utama perusahaan. Model ini terdiri dari 3 proses utama yang disebut “anchor points”, yaitu :
  1. Life Cycle Objectives (LCO) – apa yang harus sistem kerjakan? Dalam tahap ini komitmen stakeholder dalam daur hidup software.
  2. Life Cycle Architecture (LCA) – apa struktur dari sistem? Dalam tahap ini komitmen stakeholder dalam mendukung perancangan.
  3. Initial Operational Capability (IOC) – peluncuran versi pertama. Dalam tahap ini komitmen stakeholder dalam mendukung pelaksanaan. Terdapat tiga kunci utama dalam tahap ini :
  • Persiapan Software (Software Preparation), termasuk software operasional dan pendukung dengan uraian dan dokumentasi yang sesuai; persiapan atau konversi data; lisensi dan hak yang diperlukan dalam penggunaan software, dan pengujian kesiapan operasional  yang sesuai.
  • Persiapan Lokasi (Site Preparation), termasuk fasilitas, peralatan, perlengkapan, dan pengaturan dukungan pemasok.
  • Pemakai, Operator, dan Persiapan Pemelihara (User, Operator, and Maintainer Preparation), termasuk seleksi, pembentukan tim, pelatihan, dan kualifikasi lainnya untuk pengenalan penggunaan, operasional, atau pemeliharaan.
LCO & LCA - Copy
Tabel 2.1 : Milestone LCO dan LCA


D. Kriteria Keberhasilan dan Kegagalan Proyek : Survivability of A System
Dalam sistem jaringan yang terdistribusi dalam skala besar, peningkatan efisiensi dan efektivitas organisasi bisa dihasilkan dengan menciptakan tingkatan baru integrasi organisasi. Namun, integrasi tersebut disertai dengan resiko tinggi dari gangguan dan berbahaya. Memasukkan kemampuan bertahan hidup (survivability) dalam sistem organisasi dapat mengurangi resiko ini.
Masalah survivability sering terpisah dari aktivitas proyek, dan hanya dianggap sebagai tambahan. Pemisahan faktor pertimbangan survivability dari tugas utama pengembangan sistem harus mendapat perhatian. Survivability harus diintegrasikan dan diperlakukan setara dengan aspek-aspek sistem yang lain, agar pengembangan sistem sesuai dengan fungsi yang diperlukan dan juga kinerja yang dapat digunakan untuk menghadapi kegagalan dan bahaya.
Untuk setiap aktivitas siklus-hidup, tujuan survivability harus ditangani, dan memasukkan metode untuk memastikan survivability. Dalam beberapa kasus, metode pengembangan yang ada dapat meningkatkan kemampuan survivability. Penelitian saat ini adalah menciptakan metode baru yang dapat diterapkan, namun diperlukan lebih banyak penelitian dan percobaan sebelum tujuan survivability dapat menjadi kenyataan.
Spesialisasi dan kebutuhan perangkat tambahan untuk mengadaptasi aktivitas berasal dari model umum dengan persyaratan khusus dari sistem yang dihasilkan. Hal ini dilakukan dengan menetapkan :
  1. Aktivitas yang mengarah ke pendorong (driver) yang menjadi ciri sistem, dan
  2. Kendala (constraint) yang menjadi ciri lingkungan di mana sistem dihasilkan.
Pendorong (driver) utama dalam konteks ini adalah kebutuhan untuk mengembangkan sebuah sistem yang mampu bertahan. Kendala (constraint) termasuk lingkungan politik dan sosial di mana sistem ini akan dibangun. Dengan pertimbangan biaya yang selalu ada, dan keterbatasan dari teknologi dan pengetahuan yang dapat dibawa, dapat digunakan untuk menangani masalah yang dihadapi. Penggabungan ini untuk menghasilkan versi khusus dari model spiral terintegrasi yang mampu bertahan dalam proses manajemen.
survivabilitas - Copy
Gambar 2.4 : Spesialisasi Model Spiral untuk Survivabilitas
Sistem survivable harus memenuhi berbagai kepentingan yang saling bertentangan. Pengguna akhir ingin sistem mampu melaksanakan misi utama operasional mereka. Hal ini sering terjadi bahwa sistem juga harus memenuhi beberapa sertifikasi atau akreditasi otoritas. Langkah-langkah yang diperlukan untuk persetujuan ini mungkin bertentangan dengan kepentingan user. Developer ingin menyelesaikan pekerjaan ini, lebih baik dan lebih cepat dari jadwal dan di bawah anggaran.  Proses pengembangan spiral telah terbukti lebih efektif dari segi biaya dibanding metode tradisional, dengan menampilkan biaya distribusi yang berbeda dari waktu ke waktu. Berdasarkan model spiral, pengeluaran biasanya lebih tinggi dalam spesifikasi aktivitas awal dan desain, sehingga menghasilkan penghematan biaya dalam implementasi dan aktivitas integrasi.
hubungan siklus hidup - survivabilitas
Tabel 2.2 : Hubungan Aktivitas Siklus Hidup dengan Elemen Survivabilitas
E. Persyaratan dan Spesifikasi
Untuk sistem berskala besar yang khusus, paradigma baru untuk persyaratan definisi ditandai dengan hardware, jasa, dan kode yang terdistribusi (termasuk content yang mampu dieksekusi), komunikasi dan infrastruktur routing yang terdistribusi dan terbagi, kepercayaan yang berkurang, dan kurangnya kontrol administratif secara kesatuan. Menjamin survivability sistem dengan misi kritis yang dikembangkan di bawah paradigma baru ini, merupakan upaya beresiko tinggi yang tangguh untuk penelitian rekayasa software. Upaya ini mengharuskan ukuran keamanan komputer tradisional diperbesar dengan strategi sistem survivability yang baru dan komprehensif.
1. Expressing Survivability Requirements
pengelompokan persyaratan - Copy
Gambar 2.5 : Pengelompokan Persyaratan untuk Sistem Survivabilitas

Persyaratan Sistem/Kemampuan Bertahan (System/Survivability Requirements). Istilah Persyaratan Sistem mengacu pada fungsi user tradisional yang harus disediakan oleh sistem. Misalnya, sebuah sistem manajemen jaringan harus menyediakan fungsi untuk memungkinkan user untuk melakukan tugas-tugas seperti memantau operasi jaringan dan menyesuaikan parameter kinerja. Persyaratan sistem juga meliputi aspek non-fungsional dari sistem, seperti waktu, kinerja, dan kehandalan. Istilah Persyaratan Kemampuan Bertahan mengacu pada kemampuan sebuah sistem untuk memberikan layanan-layanan esensial dengan adanya gangguan dan bahaya dan untuk memulihkan pelayanan.

Persyaratan Penggunaan/Gangguan (Usage/Intrusion Requirements). Pengujian sistem yang mampu bertahan harus menunjukkan kinerja yang benar dari layanan sistem yang esensial dan non-esensial serta layanan-layanan esensial yang mampu bertahan di bawah gangguan. Karena dalam pengujian kinerja sistem (dan operasi) tergantung sepenuhnya pada penggunaan sistem. Pendekatan yang efektif untuk pengujian terhadap sistem yang mampu bertahan didasarkan pada skenario penggunaan yang berasal dari penggunaan model.

Persyaratan Pengembangan (Development Requirements). Survivability memperketat persyaratan pada pengembangan sistem dan praktek pengujian. Fungsi yang tidak memadai dan kesalahan software dapat berpengaruh sangat buruk pada sistem survivability dan memberikan peluang untuk eksploitasi penyusup.

Persyaratan Operasi (Operations Requirements)Survivability menempatkan tuntutan persyaratan untuk sistem operasi dan administrasi. Persyaratan tersebut meliputi mendefinisikan dan mengkomunikasikan kebijakan survivability, pemantauan penggunaan sistem, menanggapi gangguan, dan mengembangkan fungsi sistem yang diperlukan untuk memastikan survivability lingkungan pemakaian dan pola gangguan berubah dari waktu ke waktu.

Persyaratan Evolusi (Evolution Requirements). Sistem evolusi menanggapi kebutuhan user untuk fungsi-fungsi baru. Namun, evolusi ini juga diperlukan untuk menanggapi peningkatan pengetahuan penyusup atas perilaku sistem dan struktur. Secara khusus, survivability mensyaratkan bahwa kemampuan sistem berkembang lebih cepat daripada pengetahuan penyusup.
2. Requirements Definition For Essential Services
Setiap kebutuhan sistem harus diperiksa untuk menentukan apakah sesuai dengan layanan esensial. Kumpulan layanan esensial harus membentuk subsistem layak yang lengkap dan koheren untuk user. Jika beberapa tingkat layanan esesial dibutuhkan, setiap rangkaian layanan yang disediakan pada setiap tingkat juga harus diperiksa untuk kelengkapan dan koherensi. Selain itu, persyaratan harus didefinisikan untuk membuat transisi ke dan dari tingkat essential-service.
Teknik elisitasi seperti yang terdapat dalam persyaratan rekayasa software dapat membantu untuk mengidentifikasi layanan-layanan esensial. Trade-off dan analisa cost/benefit dapat membantu untuk menentukan kumpulan layanan yang cukup untuk bertahan menangani resiko usaha dan kerentanan. Ketentuan untuk melacak persyaratan kemampuan bertahan melalui desain, kode, dan uji harus ditetapkan. Simulasi gangguan melalui skenario intruder-usage termasuk dalam proses pengujian.
3. Requirements Definition For Survivability Services
Setelah persyaratan ditentukan untuk layanan esensial dan non-esensial, satu kumpulan persyaratan untuk layanan bertahan harus didefinisikan. Layanan ini dapat dibagi dalam empat kategori umum: perlawanan, pengakuan, pemulihan, dan adaptasi dan evolusi (resistance, recognition, recovery, and adaptation and evolution). Layanan bertahan ini harus beroperasi dalam lingkungan penyusup yang dapat dicirikan dengan tiga tahap gangguan yang jelas :
  1. Tahap Penetrasi (Penetration Phase). Dalam tahap ini, penyusup mencoba untuk mendapatkan akses ke sistem melalui berbagai skenario serangan. Skenario ini berkisar dari input acak oleh hacker untuk serangan yang terencana oleh penyusup profesional. Usaha ini dirancang untuk memanfaatkan kerentanan sistem.
  2. Tahap Eksplorasi (Exploration Phase), Pada tahap ini, sistem telah ditembus dan penyusup sedang menjajaki sistem internal dan kemampuan organisasi. Dengan mengeksplorasi, penyusup belajar bagaimana memanfaatkan akses untuk mencapai tujuan gangguan.
  3. Tahap Eksploitasi (Exploitation Phase). Pada tahap ini, penyusup telah memperoleh akses ke fasilitas sistem yang diinginkan dan melakukan operasi yang dirancang untuk membahayakan kemampuan sistem.
Penetrasi, eksplorasi, dan eksploitasi menciptakan spiral peningkatan otoritas penyusup dan pelebaran lingkaran yang membahayakan. Definisi persyaratan untuk perlawanan, pengakuan, pemulihan, dan adaptasi dan evolusi (resistance, recognition, recovery, and adaptation and evolution) membantu developer memilih strategi bertahan untuk mengatasi tahap gangguan ini. Beberapa strategi, seperti firewall, adalah produk dari penelitian dan pengembangan dan saat ini digunakan secara luas di ruang lingkup jaringan.

Persyaratan Layanan Perlawanan (Resistance Service Requirements). Perlawanan adalah kemampuan sebuah sistem untuk mencegah serangan. Perlawanan demikian penting dalam penetrasi dan tahap eksplorasi serangan, sebelum eksploitasi yang sebenarnya. Strategi saat ini untuk perlawanan termasuk penggunaan firewall, otentikasi, dan enkripsi. Diversifikasi adalah strategi perlawanan yang mungkin akan menjadi lebih penting untuk jaringan terbatas.
Persyaratan Layanan Pengakuan (Recognition Service Requirements). Pengakuan adalah kemampuan sistem untuk mengenali serangan atau penyelidikan sebelum serangan. Kemampuan untuk bereaksi atau beradaptasi selama gangguan adalah pusat dari kapasitas sistem untuk bertahan dari serangan yang tidak bisa sepenuhnya ditolak. Untuk bereaksi atau beradaptasi, sistem harus pertama kali mengenali serangan.
Persyaratan Layanan Pemulihan (Recovery Service Requirements). Pemulihan adalah kemampuan sistem untuk memulihkan layanan setelah gangguan terjadi. Pemulihan juga berkontribusi terhadap kemampuan sistem untuk mempertahankan layanan esensial selama penyusupan. Persyaratan untuk pemulihan adalah perbedaan yang paling jelas antara sistem yang bertahan dengan sistem yang hanya mengamankan. Keamanan komputer tradisional mengarah pada desain sistem yang mengandalkan hampir sepenuhnya pada hardening (yaitu, penghambat) untuk perlindungan. Setelah keamanan dilanggar, maka diikuti oleh kerusakan. Kemampuan sistem untuk bereaksi saat gangguan aktif adalah pusat kapasitasnya untuk bertahan dari serangan yang tidak bisa sepenuhnya ditolak.  Dengan demikian, pemulihan penting selama tahap eksplorasi dan eksploitasi gangguan.

Persyaratan Layanan Adaptasi dan Evolusi (Adaptation and Evolution Service Requirements). Adaptasi dan evolusi sangat penting untuk menjaga ketahanan terhadap pengetahuan penyusup yang terus meningkat tentang bagaimana untuk mengeksploitasi dengan fungsi sistem yang tidak berubah.  Adaptasi dinamis secara permanen meningkatkan kemampuan sistem untuk menolak, mengenali, dan pulih dari upaya penyusupan. Sebagai contoh, sebuah kebutuhan adaptasi mungkin merupakan infrastruktur yang memungkinkan sistem untuk menghadapi kerentanan keamanan yang baru ditemukan dengan secara otomatis mendistribusikan dan menerapkan perbaikan keamanan untuk semua elemen jaringan.
properti kunci
Tabel 2.3 : Properti Kunci untuk Sistem Survivabilitas

STUDI KASUS
A. Gambaran Sistem Saat Ini
Di Sistem Perpustakaan Terpadu milik USC (University of Southern California), telah dikembangkan pendekatan berbasis negosiasi untuk persyaratan sistem rekayasa software, arsitektur, pengembangan, dan manajemen. Pendekatan ini memiliki tiga elemen utama :
  1. Theory W : teori dan pendekatan manajemen, yang mengatakan bahwa membuat stakeholder kunci dalam sistem menjadi pemenang adalah kondisi yang diperlukan dan cukup untuk kesuksesan proyek.
  2. WinWin Spiral Model : merupakan perluasan model pengembangan software spiral dengan menambahkan aktivitas Teori W ke depan setiap siklus. “nsur dari WinWin Spiral Model menggambarkan perluasan ini dan tujuan mereka lebih terinci.
  3. WinWin : groupware yang memudahkan stakeholder bernegosiasi mengenai spesifikasi sistem yang saling memuaskan (win-win).
Perluasan Sistem Perpustakaan Terpadu bertujuan untuk mengakses arsip multimedia, termasuk film, peta, dan video. Sistem Perpustakaan Terpadu berbasis Unix, text-oriented, dengan sistem client-server COTS yang dirancang untuk mengelola akuisisi, rototy, akses rotot, dan sirkulasi bahan perpustakaan. Tujuan spesifik penelitian adalah untuk mengevaluasi kelayakan penggunaan model spiral WinWin untuk membangun aplikasi yang ditulis oleh tim mahasiswa pascasarjana USC. Para siswa mengembangkan aplikasi bersama dengan klien perpustakaan USC, yang telah mengidentifikasi banyak arsip USC multimedia yang tampaknya layak untuk ditransformasi ke digital.
Hasil penelitian menunjukkan bahwa model spiral WinWin cocok untuk aplikasi multimedia dan mungkin berguna untuk aplikasi lain yang memiliki karakteristik serupa – teknologi yang bergerak cepat, banyaknya cara pendekatan, sedikitnya pengalaman user atau developer dengan sistem yang sama, dan kebutuhan untuk penyelesaian yang cepat. Hasil studi menunjukkan bahwa model tersebut memiliki tiga kekuatan utama :
  1. Fleksibilitas : Model membiarkan tim beradaptasi dengan resiko dan ketidakpastian yang menyertai, seperti jadwal proyek yang cepat dan perubahan komposisi tim.
  2. Disiplin : Kerangka pemodelan sudah cukup formal untuk tetap roto pada pencapaian dalam “anchor-point”.
  3. Peningkatan Kepercayaan : Model ini menyediakan sarana untuk menumbuhkan kepercayaan diantara stakeholder dalam proyek, yang memungkinkan mereka untuk berkembang dari permusuhan, pendekatan pengembangan yang berorientasi sistem-kontrak menjadi metode yang saling mendukung dan kooperatif.
Penerapan model spiral WinWin dapat diuraikan menjadi empat siklus utama yaitu :
Siklus 0 : Menentukan kelayakan aplikasi multimedia yang sesuai.
Siklus 1 : Mengembangkan LCO, prototipe, rencana, dan spesifikasi untuk aplikasi individual dan memverifikasi keberadaan setidaknya satu arsitektur yang layak untuk setiap aplikasi.
Siklus 2 : Membuat LCA yang spesifik dan rinci, memverifikasi kelayakan, dan menentukan bahwa tidak ada resiko besar dalam pemenuhan rencana dan spesifikasi.
Siklus 3 : Mencapai IOC yang bisa diterapkan untuk setiap proyek termasuk persiapan sistem, pelatihan, penggunaan, dan dukungan evolusi untuk user, administrator, dan developer.
Penggunaan Teori W ada di semua siklus, tapi penggunaan groupware WinWin hanya di Siklus 1 saja, karena disini penerapan yang terbaik.
wbs
Gambar 3.1 : Work Breakdown Structure
B. Persiapan Proyek
Setelah mengetahui gambaran awal sistem saat ini, manajemen proyek dikembangkan dengan mengacu pada Software Project Management. Hal pertama yang harus dilakukan adalah pemilihan Project Manajer dengan peran dan tanggung jawab sebagai berikut :
  1. Membuat WBS (Work Breakdown Structure)
  2. Mempersiapkan dokumen-dokumen yang diperlukan
  3. Memberikan feedback dari hasil pekerjaan proyek
  4. Memberikan penghargaan kepada anggota tim yang mempunyai prestasi yang baik
Berdasarkan kondisi sistem saat ini, maka tujuan dilaksanakannya proyek ini adalah :
  1. Menilai kinerja sistem saat ini
  2. Mencari resiko yang timbul dari kondisi sistem saat ini
  3. Merancang konsep perpustakaan digital
  4. Memberikan masukan bagi perusahaan untuk perbaikan atau pengembangan sistem
  5. Memberikan gambaran pengembangan sistem yang dapat dibuat di masa depan
Agar proyek ini berhasil, berikut adalah persyaratan-persyaratan yang bisa menjadi acuan dalam pelaksanaan proyek :
  1. Membuat konsep persyaratan yang stabil dan standar
  2. Membuat model untuk menguraikan solusi dari masalah
  3. Pengembangan aplikasi software
  4. Manajemen proyek dan strategi pengaturan yang baik
  5. Metode untuk melacak dan keterkaitan biaya-biaya proyek
  6. Manajemen perubahan organisasi
  7. Komunikasi
  8. Ketersediaan hardware
Stakeholder yang terlibat adalah :
  1. Developer (Developer). Anggota tim arsitektur dan prototype akan mewakili perhatian dari developer, seperti penggunaan paket yang umum, persyaratan yang stabil, ketersediaan alat pendukung, dan pendekatan tantangan teknis.
  2. Pelanggan (Customer). Anggota tim perencana dan rationale akan mewakili perhatian pelanggan, seperti kebutuhan untuk mengembangkan IOC dalam satu semester, anggaran yang terbatas untuk alat pendukung, dan pendekatan teknis yang beresiko rendah.
  3. Pengguna (User). Anggota tim konsep operasional dan persyaratan akan bekerja dengan perwakilan komunitas user yang ditunjuk untuk mewakili kebutuhan user, seperti mengakses fitur multimedia, waktu respon yang cepat, interface yang  user-friendly, keandalan yang tinggi, dan fleksibilitas dari persyaratan.
Komunitas yang dibentuk adalah :
  1. Library Information Technology Community (Komunitas Teknologi Informasi Perpustakaan)
  2. Library Operations Community (Komunitas Operasi Perpustakaan)
  3. Center for Software Engineering/CSE (Pusat Rekayasa Software)
Model pengembangan sistem yang digunakan adalah Model Spiral. Agar proyek ini berhasil rencana-rencana yang harus dibuat adalah :
  • Program Master plan : memberikan gambaran mengenai visi, misi, dan tujuan dari proyek sehingga menjadi pedoman untuk semua stakeholder.
  • Management plan : menjelaskan tentang cara proyek dieksekusi, dimonitor dan dikendalikan.
  • Development plan : memberikan gambaran pengembangan yang mungkin bisa dilakukan setelah menyelesaikan siklus ke-n.
  • Configuration Management plan : mengatur penambahan dan pengurangan dari setiap siklus yang telah dilewati.
  • Quality Assurance plan : menilai hasil proyek berdasarkan feedback dari klien dan pustakawan.
  • Maintenance plan : memelihara aplikasi yang telah lolos uji kelayakan setelah digunakan oleh user.
  • Test plan : untuk melihat kinerja aplikasi sebelum digunakan secara umum.
  • Integration plan : mengatur penggabungan data-data agar menghasilkan output yang sesuai dengan keinginan klien dan user.
  • Documentation plan : mengumpulkan semua data dan informasi yang berhubungan dengan pelaksanaan proyek.
  • Transition plan : mengatur pergantian dari sistem lama ke sistem baru sehingga tidak mengganggu aktivitas rutin.
  • Firmware Development plan : membuat jadwal pelatihan karyawan untuk meningkatkan kinerja sumber daya manusia di perusahaan, misalnya dengan mengadakan Knowledge Management Program.
C. Pelaksanaan Proyek
  1. Mengatur Tugas : Model Spiral memiliki 3 siklus utama dimana di masing-masing siklus harus mengidentifikasi kelayakan sampai pelaksanaan program.
  2. Mengatur Tim : Tim dibentuk berdasarkan tugas-tugas yang harus dikerjakan dalam proyek. Pemilihan anggota-anggota tim yang kompeten akan sangat mempengaruhi hasil dan waktu pengerjaan yang dibutuhkan untuk menyelesaikan proyek.
  3. Mengatur Keadaan : Pengaturan pengerjaan tugas sampai tiba waktunya enyampaian hasil proyek diharapkan sesuai jadwal.
  4. Mengatur Dukungan dan Pemeliharaan : Hasil yang diberikan diharapkan mendapat respon yang baik sehingga pengembangan bisa dilakukan sesuai dengan permintaan klien.
D. Analisa Sistem
Siklus 0 : Studi Kelayakan
Penelitian melibatkan penggunaan aplikasi hipotetis, salah satunya adalah aplikasi perpustakaan dengan level yang lebih tinggi. Beberapa staf perpustakaan tertarik karena siswa CSE mengembangkan aplikasi yang berguna bagi perpustakaan USC. Pertemuan dengan beberapa staf perpustakaan untuk mengeksplorasi kondisi menang bagi setiap stakeholder dan untuk menentukan apakah bisa mengidentifikasi sebuah kumpulan tujuan siklus-hidup aplikasi yang layak untuk perpustakaan USC. Resiko-resiko yang ditemukan adalah :
  • Komunitas Teknologi Informasi Perpustakaan didorong oleh visi dekan mereka untuk mempercepat transisi kemampuan digital untuk perpustakaan.
  • Anggaran yang sedikit untuk mengevaluasi teknologi multimedia baru dan mengembangkan aplikasi eksplorasi.
  • Komunitas Operasi Perpustakaan sangat sensitif terhadap resiko atas gangguan layanan
  • Terbatasnya sumber daya untuk percobaan di bidang baru
  • Memiliki berbagai aplikasi terlalu banyak
  • Kehilangan pengendalian terhadap proyek
  • Mencapai IOC dalam dua semester dan kondisi menang untuk CSE
  • User sudah mengalami transisi yang kompleks ke Sistem Perpustakaan Terpadu yang baru. Mereka terus mencari teknologi baru untuk meningkatkan operasi mereka.
Solusi yang diberikan adalah :
  • Mengikuti jadwal proyek yang cepat.
  • Membiasakan diri dengan baik antara satu sama lain dan dengan aplikasi perpustakaan dan klien mereka agar mereka dapat dengan mudah mencapai berbagai tujuan.
  • Berfokus pada satu wilayah aplikasi – layanan arsip multimedia perpustakaan – dan dengan mengembangkan model domain umum dan seperangkat pedoman produk untuk diikuti oleh semua tim.
Siklus 1 : Life Cycle Objectives (LCO)
Pedoman proyek yang dibahas dengan staf perpustakaan selama Siklus 0, telah memberikan informasi-informasi untuk memastikan bahwa :
  • Setiap orang menggunakan proses pengembangan umum
  • Memberikan contoh prototipe arsip multimedia dan model domain untuk perluasan arsip informasi yang khusus.
sistem block diagram - Copy
Gambar 3.2 : Sistem Block Diagram untuk Perluasan
Model domain mengidentifikasi stakeholder kunci yang terlibat dalam sistem dan konsep kunci seperti batasan sistem, batasan antara sistem yang sedang dikembangkan dan lingkungannya. Pedoman proyek dan model domain adalah kunci untuk kemajuan pesat tim karena dapat memberikan perspektif pengembangan umum. Dengan menggunakan groupware WinWin, maka hal-hal berikut ini bisa teridentifikasi :
1. Library Information Technology Community :
  1. Percepatan transisi ke kemampuan perpustakaan digital – visi Dekan Perpustakaan Universitas
  2. Evaluasi multimedia muncul pengarsipan dan alat-alat akses
  3. Memberdayakan user perpustakaan multimedia
  4. Peningkatan kemampuan staf layanan perpustakaan di perpustakaan digital
  5. Meningkatkan anggaran terbatas untuk aplikasi canggih
2. Library Operations Community :

  1. Kesinambungan pelayanan
  2. Tidak ada gangguan transisi berkesinambungan untuk SIRSI yang berbasis Sistem Informasi Perpustakaan
  3. Karir pertumbuhan kesempatan untuk sistem administrator
  4. Tidak ada gangguan operasi jaringan dan layanan USC
  5. Efisiensi operasi melalui teknologi
3. Center for Software Engineering (CSE)
  1. Kesamaan proyek
  2. Kecocokan yang masuk akal untuk model spiral WinWin
  3. 15-20 proyek, 5-6 siswa per tim
  4. Mencapai arsitektur siklus-hidup yang layak dalam satu semester
  5. Mencapai kemampuan operasional yang layak dalam dua semester
  6. Jaringan, komputer, dan sumber daya infrastruktur yang memadai
Selanjutnya diskusi tentang perencanaan kunci dan pedoman organisasi, dengan menyediakan detail lebih lanjut tentang artefak proyek dan ceramah tentang operasi perpustakaan dan sistem SIRSI dan pada aspek teknologi seperti desain user-interface dan arsitektur sistem multimedia. Negosiasi user menunjukkan empat hal kunci yang harus dicapai dalam model negosiasi WinWin yaitu kondisi menang, isu, pilihan, dan perjanjian, dan hubungannya.
Peran dan tanggung jawab para stakeholder antara lain :
  1. Manajer Aset (Asset Manager). Menyediakan dan memperbarui konten aset dan katalog yang memberikan deskripsi. Menjamin akses ke aset. Menyediakan informasi status aksesibilitas. Memastikan pemulihan. Mendukung analisa masalah, penjelasan, pelatihan, instrumentasi, analisa operasi.
  2. Operator. Memelihara kinerja sistem di level lebih tinggi dan menjamin ketersediaannya. Mengakomodasi pertumbuhan dan perubahan aset dan layanan.  Melindungi privasi Stakeholder dan hak kekayaan intelektual. Mendukung analisa masalah, penjelasan, pelatihan, instrumentasi, analisa operasi.
  3. User. Mendapat pelatihan. Mengakses sistem. Permintaan dan browsing aset. Impor dan operasi pada aset. Menetapkan, mengisi, memperbarui, dan akses ke file yang terkait dengan aset. Menyesuaikan dengan kebijakan sistem. Memberikan feedback mengenai penggunaan.
  4. Pemelihara Aplikasi Software (Application Software Maintainer). Melakukan perbaikan adaptif, dan perfektif (tuning, restrukturisasi) untuk pemeliharaan software. Menganalisa dan mendukung prioritas dari perubahan yang diusulkan. Merencanakan, mendesain, mengembangkan, dan memverifikasi perubahan yang dipilih. Mendukung analisa masalah, penjelasan, pelatihan, instrumentasi, dan analisa operasi.
  5. Penyedia layanan (jaringan, database, atau layanan fasilitas manajemen). Peran dan tanggung jawab sama dengan aset manajer.
Untuk meminimalkan gangguan pada operasi perpustakaan, konsep operasional dan persyaratan anggota tim memasukkan artifak user, bukan pustakawan. Akhirnya dibuat 12 aplikasi yaitu :
  1. Stereoscopic slides
  2. Latin American pamphlets
  3. Edgar corporate data
  4. Medieval manuscripts
  5. Hancock Library photo archive
  6. Interactive TV courseware delivery
  7. Technical reports archives
  8. Student film archive
  9. Student access to digital maps
  10. Los Angeles regional history photos
  11. Korean-American museum
  12. Urban planning documents
Ada laporan dua masalah yang disusun oleh klien perpustakaan yaitu :
1. Medieval Manuscript
Ketertarikan cara memindai manuskrip abad pertengahan sehingga peneliti bisa membaca isinya dan mengenali tangan juru tulis, tanda-tanda khusus, dan sebagainya. Masalah yang terkait adalah bagaimana mengirimkan gambar tersebut.
2. Edgar Corporate Data
Pemerintah Semakin menggunakan WWW sebagai alat untuk penyebaran informasi. Dua situs yang sering digunakan sebagai file ASCII. Untuk informasi tekstual, format dari tabel statistik sering hilang saat didownload, e-mail, atau mentransfer program statistik. Walaupun informasi ini berguna bagi peneliti perpustakaan khusus, seringkali terlaluadalah database informasi perusahaan Edgar (http://www.sec.gov/edgarhp.htm) dan Biro Sensus (http://www.census.gov). Sebagian dari masalah ini adalah bahwa beberapa informasi (khususnya yang di situs Edgar) tersedia hanya banyak kesulitan untuk memasukkannya ke dalam format yang dapat digunakan.
Pernyataan-pernyataan ini lebih kurang terperinci dibandingkan dengan persyaratan khusus yang diatur dalam aplikasi industri. Tim harus mengerjakan laporan ini agar prototipe, rencana, dan spesifikasi tetap konsisten. Untuk membantu mengatur dan menavigasi artefak WinWin dan mengendalikan terminologi yang diasosiasikan, maka solusi yang diusulkan adalah pemberian taksonomi domain dan pedoman untuk menghubungkan unsur-unsur taksonomi dengan elemen dari spesifikasi persyaratan.  Taksonomi sangat membantu dalam mengkategorikan bentuk-bentuk menjadi perhatian umum, seperti yang mempengaruhi kontrol user.
domain taksonomi - Copy
Tabel 3.1 : Domain Taksonomi

Siklus 2 : Life Cycle Architecture (LCA)
Di Siklus 2, tim memilih arsitektur siklus-hidup yang khusus untuk aplikasinya dan menguraikan isi artefak LCO ke tingkat detail yang diperlukan untuk LCA, termasuk menanggapi komentar instruktur atas paket LCO. Masalah yang timbul :
  • Inkonsistensi antara artefak
  • Kegagalan untuk menentukan atribut kualitas
  • Kesalahpahaman umum tentang ruang lingkup aplikasi
  • Ketidakmampuan untuk mengakui bahwa rencana ini adalah untuk fokus pada aktivitas pengembangan di Siklus 3.
Karena keterlambatan dan perubahan prototipe peralatan, tim mengembangkan prototipe dalam Siklus 2. Hal ini memiliki pengaruh tidak menguntungkan karena harus mendestabilisasi beberapa perjanjian WinWin dan persyaratan produk. Setelah klien perpustakaan melihat prototipe, mereka ingin mengubah persyaratan.
Di sisi positif, prototipe umumnya diperluas dari persepsi para pustakawan dari apa yang tim dapat hasilkan. Pustakawan yang mengusulkan masalah data perusahaan Edgar, kagum dengan produk akhir, yang dibangun dengan format teks sederhana dan memberikan one-stop situs Java yang mengolah beberapa jenis informasi bisnis. Tim melihat di luar parameter masalah dan meneliti jenis informasi yang diperlukan untuk memenuhi kumpulan data. Klien perpustakaan yang lain juga sangat puas dengan nilai tambah terhadap waktu yang mereka investasikan. Tim mampu mengatasi beberapa tantangan karakteristik proyek di dunia nyata.
Tantangan yang dihadapi :
  • Tidak bisa menggunakan server Sistem Perpustakaan Terpadu untuk prototipe mereka karena diperlukan dalam transisi dari sistem lama ke Sistem Perpustakaan Terpadu yang baru.
  • Keterlambatan dalam mengatur server Web alternatif yang sesuai.
  • Pustakawan tidak bisa memberikan masukan pada keputusan kritis, yang menyebabkan tambahan kerja ulang.
  • Konflik yang terjadi antar personil
  • Menjaga konsistensi di pandangan beberapa produk
Solusi :
  • Campuran WinWin spiral model terdiri dari fleksibilitas dan disiplin membiarkan tim proyek beradaptasi dengan tantangan ini sambil tetap sesuai jadwal.
  • Secara khusus, penggunaan manajemen resiko dan resiko yang terus berkembang, membantu tim memfokuskan upaya mereka pada faktor-faktor keberhasilan yang paling penting untuk proyek.
Menggunakan pedoman berdasarkan standar komersial seperti J-STD-016-1995, dan metode berorientasi obyek, khususnya metode Booch dan Teknologi Pemodelan Berorientasi Obyek. termasuk sistem block diagrams, requirements templates, use scenarios, physical architecture diagrams, class hierarchies, object interaction diagrams, dataflow diagrams, statetransition diagrams, data descriptions, dan requirements traceability relations.
Masing-masing memiliki nilai, tetapi pengaturan secara keseluruhan baik yang berlebihan dan lemah didukung oleh alat-alat yang terintegrasi.yaitu Unified Modelling Language (UML).
Siklus 3 : Initial Operational Capability (IOC)
Tantangan utama untuk Siklus 3 adalah :
  • Proyek didorong oleh pengalaman proyek dari siswa bukan oleh prioritas pustakawan.
  • Tim harus bekerja dengan campuran dengan berbagai latar belakang.
  • Mengintegrasikan tim yang telah menghasilkan artefak LCA berbeda untuk aplikasi yang sama.
  • Instruktur harus membujuk siswa untuk bergabung dengan tim yang berbeda karena mereka terus bertengkar tentang arsitektur yang lebih baik.
  • Beberapa anggota tim memiliki pengalaman LCA yang luas tentang aplikasi dan yang lain tidak ada.
  • Anggota tim dieksploitasi orang yang kurang berpengalaman, dan sebaliknya.
  • Perubahan dalam kursus instruktur, model proses (spiral menjadi risk-driven waterfall), dan pendekatan dokumentasi (laissez-faire menjadi put-everything-on-the-Web)
  • Server Sistem Perpustakaan Terpadu dan search engine tidak tersedia.
Solusi :
1. Manajemen Resiko. Meskipun memiliki kendala, setiap proyek berhasil tepat waktu memberikan paket IOC – kode, dokumentasi siklus hidup, dan demonstrasi. Kami percaya bahwa alasan utama adalah penekanan yang kuat pada manajemen resiko, yang memungkinkan tim untuk mulai dari pendekatan waterfall murni untuk mengatasi resiko penting apa pun yang muncul. Daftar resiko membantu tim memprioritaskan resiko dengan menilai resiko (kemungkinan besarnya). Setiap minggu, tim menilai kembali resiko untuk melihat apakah prioritas telah berubah atau untuk menentukan berapa banyak kemajuan telah dibuat dalam menyelesaikannya. Strategi kuncinya adalah desain jadwal, di mana tim mengidentifikasi kemampuan kelayakan utama dan fitur pilihan untuk diterapkan sesuai jadwal yang diijinkan.
Beberapa resiko dari daftar resiko khusus termasuk :
  1. Jadwal yang Ketat. Termasuk mempelajari dengan hati-hati persyaratan agar tidak over-commit, descoping fitur good-to-have jika mungkin, dan berkonsentrasi pada kemampuan inti. Aktivitas pemantauan resiko termasuk memantau semua aktivitas untuk memastikan bahwa jadwal tersebut terpenuhi.
  2. Ukuran Proyek. Termasuk descoping fitur baik-untuk-memiliki dan kemampuan kalau persyaratan terlalu berlebihan dan mengidentifikasi kemampuan inti yang akan dibangun.
  3. Menemukan Search Engine. Termasuk melakukan evaluasi software search engine, secara aktif mencari search engine gratis untuk evaluasi dan seleksi, dan menentukan yang terbaik untuk proyek. Aktivitas pemantauan resiko termasuk menyerahkan laporan evaluasi dan melakukan demonstrasi sehingga keputusan yang tepat dapat dibuat.
  4. Diperlukan Keahlian Teknis. Termasuk mengidentifikasi daerah teknis yang kritis dan paling sulit dari proyek dan memiliki anggota tim untuk melihat langsung ke dalam. Aktivitas pemantauan meliputi secara dekat mengikuti perkembangan masalah kritis dan mencari bantuan jika perlu.
2. Keterlibatan Klien dan Reaksi. Keterlibatan pustakawan dengan tim mahasiswa sebagian besar secara kualitatif dan kuantitatif berbeda selama semester pertama. Persyaratan sistem umum sudah dinegosiasikan, tapi ada beberapa persyaratan baru yang menambahkan perbedaan kecil ke konsep asli. Namun, waktu yang diperlukan untuk partisipasi pustakawan tidak begitu luas. Kecuali untuk satu proyek, para pustakawan sangat senang dengan presentasi akhir. Lima klien perpustakaan ingin mengadopsi aplikasi atau memperluas untuk kemungkinan penerapan. Aplikasi-keenam yang tidak diterima dengan baik, merupakan upaya untuk mengintegrasikan tiga proyek gambar fotografi (slide stereoskopik, arsip foto Perpustakaan Hancock, foto sejarah regional Los Angeles) ke dalam satu aplikasi. Tim hanya memiliki waktu singkat untuk menggabungkan potongan-potongan tiga arsitektur tersebut dan user-interface. Beberapa fitur yang dihasilkan baik, tetapi tidak ada klien yang antusias tentang pelaksanaan hasil. Para pustakawan menyatakan bahwa bekerja dengan Teori W dan filosofi WinWin membuat mereka mudah untuk “berpikir besar” tentang proyek-proyek mereka. Proses negosiasi yang seimbang bahwa visi yang memungkinkan tim dan pustakawan untuk menyetujui suatu kumpulan penyampaian yang layak untuk produk akhir. Meskipun komitmen waktu tidak besar, partisipasi dalam proyek ini membiarkan para pustakawan fokus waktu pada aplikasi multimedia dan rekayasa software. Salah satu keuntungan terbesar bagi pustakawan adalah bahwa mereka menjadi lebih akrab dengan masalah perpustakaan digital dan teknik-teknik rekayasa software yang terlibat dalam pelaksanaannya.
3. Sifat Produk. Laporan teknis interface mencerminkan sifat teknis jenis bahan yang dimasukkan dan diharapkan oleh user masa depan, sedangkan interface arsip film mahasiswa mencerminkan kebutuhan dan kepentingan para langganan yang sangat berbeda. Aplikasi berbasis Netscape menggunakan berbagai jendela untuk menampilkan atribut naskah, untuk query naskah yang diinginkan dengan menggunakan search engine, dan untuk masuk dan katalog manuskrip baru.
4. Penerapan Aplikasi. Hanya “student film archive” yang benar-benar diterapkan. Ternyata, aplikasi ini satu-satunya dengan anggaran, orang, dan fasilitas yang memadai untuk mempertahankan produk setelah dilaksanakan. Pada tahun berikutnya, perpustakaan USC memilih aplikasi yang akan dikembangkan untuk IOC dan mengimplementasikan aplikasi-aplikasi yang bisa dipertahankan oleh klien.
E. Evaluasi Proyek
Prinsip-prinsip dalam penyusunan spesifikasi software :
  1. Memisahkan fungsi dari implementasi
  2. Spesifikasi sistem berorientasi kepada keperluan sistem
  3. Spesifikasi harus memuat sistem dari software yang merupakan komponen
  4. Spesifikasi harus termasuk di mana sistem akan dioperasikan
  5. Spesifikasi sistem harus berupa model kognitif
  6. Spesifikasi dapat dilaksanakan
  7. Spesifikasi sistem harus bertoleransi terhadap ketidaklengkapan dan kemungkinan perluasan sistem
  8. Spesifikasi harus dibatasi dan keterkaitannya longgar
Dari hasil analisa sistem, dapat diketahui beberapa aspek penting yang mempengaruhi keberhasilan proyek ini. Berdasarkan kemampuan sistem bertahan hidup, dapat dijabarkan elemen-elemen kunci yang menjadi perhatian selama aktivitas siklus hidup sistem.
Aktivitas Siklus Hidup
Elemen Kunci Survivabilitas
Definisi Misi Anggaran yang memadai untuk evaluasi teknologi multimedia
Konsep Operasi Memperkecil resiko atas gangguan layanan selama pengerjaan proyek
Perencanaan Proyek Berfokus pada transisi ke kemampuan perpustakaan digital
Definisi Persyaratan Menggunakan model domain umum dan pedoman berdasarkan standar komersial
Spesifikasi sistem Membuat Sistem Informasi Perpustakaan
Arsitektur Sistem Jaringan, komputer dan sumber daya infrastruktur yang memadai
Desain Sistem Menggunakan teknik pemodelan berorientasi objek
Implementasi Sistem Tanggapan positif dari klien sehingga mendukung kelanjutan proyek
Pengujian Sistem Integrasi data yang konsisten
Evolusi Sistem Kemampuan memberikan hasil lebih dari yang diharapkan klien
Tabel 3.2 : Hasil Evaluasi Survivabilitas Proyek

Persyaratan dan Spesifikasi
Strategi
  1. Menampilkan Persyaratan Survivabilitas :
    1. Persyaratan Kemampuan Bertahan
    2. Persyaratan Penggunaan/Gangguan
    3. Persyaratan Pengembangan
    4. Persyaratan Operasi
    5. Persyaratan Evolusi
Interface yang user-friendly Mengacu pada pedoman berdasarkan standar komersial
Menyusun anggaran yang memadai
Pelatihan user
Desain awal aplikasi baru yang disesuaikan dengan persyaratan baru dari klien
  1. Definisi Persyaratan untuk Pelayanan Esensial
Menggunakan search engine untuk evaluasi dan seleksi demi kelayakan proyek
  1. Definisi Persyaratan untuk Pelayanan Survivabilitas :
    1. Persyaratan Layanan Perlawanan
    2. Persyaratan Layanan Pengakuan
    3. Persyaratan Layanan Pemulihan
    4. Persyaratan Layanan Adaptasi dan Evolusi
Diversifikasi sistem, isolasi fungsional Pengecekan integrasi aplikasi
Backup sistem
Mengadopsi aplikasi atau memperluas kemungkinan penerapan
Tabel 3.3 : Hasil Evaluasi Persyaratan dan Spesifikasi Proyek
F. Proyek Tahun Kedua
Di tahun kedua, sebagian besar proyek dikembangkan dengan mengikuti proses tahun pertama (dari LCO, LCA sampai IOC). Perubahan yang dibuat berdasarkan keinginan pelanggan dan siswa, saran mereka, dan pelajaran lain yang dipelajari selama tahun pertama. Dari 16 proyek pada semester pertama, klien memilih lima aplikasi untuk pengembangan sesuai dengan komitmen perpustakaan untuk mempertahankannya setelah semester kedua (IOC). Empat aplikasi sedang ditransisikan ke operasi perpustakaan, dan yang kelima memiliki prospek yang baik untuk transisi perbaikan. Beberapa bagian diadaptasi dari proses tahun pertama ke proyek-proyek tahun kedua. Hasil yang dicapai adalah :
  1. Dokumentasi. Pedoman dokumen direstrukturisasi untuk mengurangi duplikasi, dan disesuaikan agar bisa digunakan dengan Rational Rose dan Unified Modeling Language (pengembangan OO dan metode desain telah digunakan di tahun pertama, tetapi tidak tersedia alat pendukung khusus).
  2. Deskripsi Arsitektur Berlapis. Dengan menggunakan UML dan Metodologi Pengembangan Sistem Terpadu sebagai metode berorientasi obyek, perbaikan deskripsi arsitektural sistem software bisa lebih kuat menjadi tiga lapisan model yaitu domain deskripsi, analisa sistem, dan perancangan sistem. Setiap lapisan sejalan dengan yang lain. Layering meningkatkan konsistensi internal karena dapat memelihara hubungan yang berbeda (didokumentasikan melalui pelacakan referensi sederhana) antara tampilan di dalam dan di luar setiap lapisan. Banyak tim masih menemukan konsep konsistensi dan pelacakan sulit dipahami, tetapi mereka menjadi lebih sadar dibanding tahun pertama proyek dimana isu-isu ini sangat penting. Melalui deskripsi domain, tim mampu dengan cepat memahami bagian-bagian dari domain klien mereka yang relevan dengan sistem target. Dengan representasi ini, tim mampu bekerja dengan klien untuk membicarakan tanggung jawab, kualitas, dan komponen yang penting dari sistem target tanpa kehilangan klien dalam desain teknis yng terlalu detail. Selama analisa sistem, sistem ini memiliki semua hal yang di harapkan dan diinginkan klien. Secara keseluruhan, Layering membantu mengelola kerumitan arsitektur dengan membiarkan tim menangkap, memvalidasi, dan menyaring informasi dengan cara yang praktis dan berguna serta berkomunikasi secara efektif.
  3. Penerimaan Klien. WinWin dan persiapan prototyping dan pelatihan, prototyping awal, dan penerapan tinjau ulang LCO dan LCA cocok ke dalam pendekatan spiral WinWin dan meningkatkan produktivitas dan kualitas proyek tahun kedua melebihi usaha tahun pertama. Ada sedikit penjelasan persyaratan pada tahap lanjutan siklus-hidup, yang meningkatkan partisipasi dan penerimaan klien ke titik “aktivis klien”. Ketika sebuah tim diberikan beberapa kritik oleh dewan peninjau, seringkali klien aktif akan membela tim dan usaha mereka. Diskusi yang dihasilkan sering menyebabkan identifikasi tambahan tujuan penting, kendala, dan alternatif, membuat model spiral iterasi lebih efektif, dan menghasilkan produk yang lebih memuaskan untuk klien. Peringkat kepuasan keseluruhan dari kritik klien, pada skala 1 sampai 5, naik dari 4,3 pada tahun pertama menjadi 4,7 pada urutan kedua.
Dari proyek-proyek tahun kedua, terdapat indikasi kebutuhan lebih untuk UML dan pendidikan Rose, kebutuhan untuk pedoman dokumen yang lebih baik, dan perlunya COCOMO model II dikalibrasi ke proyek. Sejauh ini hasil menunjukkan bahwa model spiral WinWin baik digunakan oleh industri untuk transisi. Proyek-proyek perpustakaan digital sesuai dengan tes industri karena sekitar 20 persen dari tim murni karyawan industri, dan tim tambahan merupakan campuran karyawan industri dan siswa penuh waktu. Bahkan, sejak tahun pertama proyek, organisasi industri yang telah mengadopsi banyak unsur model spiral WinWin.
Beberapa organisasi afiliasi USC-CSE yang lain mengadopsi konsep model spiral WinWin ke dalam proses pendekatan siklus hidup mereka. Model proses software baru pada umumnya memakan waktu bertahun-tahun untuk validasi.
G. Hasil yang Dicapai
Klien perpustakaan dan manajemen menemukan bahwa proyek ini cukup berharga sehingga mereka berkomitmen baik untuk melanjutkan serangkaian proyek serupa dan untuk mendukung transisi produk dan mempertahankannya setelah implementasi. Pada gilirannya, tim memperoleh data yang luas dan umpan balik tentang bagaimana meningkatkan program dan pendekatan proyek baik untuk program masa depan dan untuk praktek industri.
Jumlah Siklus. Untuk proyek ini, memang tepat menggunakan siklus tunggal untuk masing-masing LCO dan LCA. Proyek yang lebih kecil bisa ke LCA dalam siklus tunggal; proyek yang lebih besar mungkin memerlukan beberapa siklus untuk mencapai tujuan LCO dan LCA. Berdasarkan hasil tinjauan LCO, dengan menggunakan siklus tunggal hanya menghasilkan hasil yang kurang memuaskan saat setengah proyek berjalan. Pada beberapa proyek, detail tidak seimbang baik dalam pengarsipan atau query/browsing bagian dari paket LCO; siklus LCA memperbaiki ketidakseimbangan itu. Menggunakan tiga siklus untuk menghasilkan LCO dan LCA akan memberikan waktu yang cukup untuk memproduksi dan mengkoordinasikan tiga artefak.

Tingkat Fleksibilitas. Tim mampu beradaptasi dengan kondisi di dunia nyata, seperti kejutan yang baik dan tidak baik dari paket COTS, tidak tersedianya paket infrastruktur yang diharapkan seperti server, kurangnya keahlian pada sistem informasi perpustakaan, dan komplikasi personil. pendekatan lebih formal atau berorientasi kontrak tidak akan mampu mengakomodasi perubahan-perubahan dalam waktu singkat.

Komunikasi dan Kepercayaan. Setidaknya untuk jenis aplikasi ini, hasil paling penting dari definisi produk bukanlah spesifikasi ketat, tetapi tim stakeholder dengan cukup kepercayaan dan berbagi visi untuk beradaptasi secara efektif terhadap perubahan yang tak terduga. Pada awalnya, klien perpustakaan yang sangat tidak pasti tentang kemajuan proyek. Dengan LCA, ketidakpastian dan keraguan tentang bekerja dengan tim mahasiswa telah diganti dengan antusiasme dan kepercayaan yang cukup besar, meskipun banyak yang masih tidak pasti tentang parameter teknis aplikasi. Pertumbuhan ini berlanjut melalui masa pengembangan dan mendorong komitmen bersama untuk mengejar proyek-proyek tambahan pada tahun berikutnya. Kemampuan pendekatan WinWin mampu mengembangkan kepercayaan yang konsisten dengan pengalaman sebelumnya.
Transisi yang Lancar. Dalam penggunaan model spiral WinWin sebelumnya, transisi dari perjanjian stakeholder WinWin ke persyaratan spesifikasi kurang lancar. groupware WinWin membantu kelancaran transisi ini. Pemetaan taksonomi domain WinWin ke daftar isi persyaratan dan spesifikasi yang membutuhkan penggunaan taksonomi domain sebagai daftar untuk mengembangkan perjanjian WinWin yang efektif serta berfokus pada negosiasi stakeholder.
Penggunaan Waktu Developer. Meskipun pendekatan ini menghindari beberapa inefisiensi, namun masih mengalami hambatan yang signifikan dari dokumentasi berlebihan dan upaya untuk mengkoordinasikan beberapa tampilan. Proyek tahun kedua telah mengurangi dokumentasi yang berlebihan dengan menggunakan alat bantu terpadu berorientasi obyek Rational Rose (yang menurunkan jumlah dokumentasi), sehingga menghasilkan lebih sedikit inkonsistensi. setiap tim terdiri dari lima anggota, yang mengurangi inkonsistensi dan overhead karena lebih sedikit orang harus berbicara satu sama lain. Akhirnya, penambahan pelatihan dan kesempatan untuk umpan balik. groupware WinWin membantu dengan pembangunan tim dan prioritas fitur, tapi orang-orang membutuhkan pelatihan lebih awal dan pengalaman dalam penggunaannya. Siswa juga perlu pelatihan lebih lanjut tentang keterampilan Web kunci dan umpan balik yang lebih pada produk.

Penerimaan Klien. Ada dua halal yang dapat dipelajari dari proyek ini. Yang pertama adalah tidak menyelesaikan negosiasi sebelum prototyping karena perjanjian terganggu setelah klien melihat prototipe. Dalam proyek tahun kedua, kami memiliki tim negosiasi dan prototipe secara bersamaan. Pelajaran kedua adalah memastikan klien diberi kuasa untuk mendukung produk tidak hanya dengan pengetahuan dan antusiasme, tetapi juga dengan sumber daya untuk operasi dan pemeliharaan produk. Dalam proyek tahun kedua, ini menjadi kriteria utama kami untuk memilih aplikasi.
KESIMPULAN
Proyek akan dimulai pada pendekatan terhadap beberapa resiko yang sesuai untuk menetapkan asumsi agar evolusi sukses. Asumsi-asumsi tersebut adalah :
  1. Peluncuran awal yang memuaskan stakeholder kunci sehingga mereka akan terus berpartisipasi dalam evolusinya
  2. Arsitektur peluncuran awal dapat diukur untuk mengakomodasi kumpulan lengkap persyaratan siklus hidup sistem (misalnya kinerja, keselamatan, keamanan, distribusi, lokalisasi)
  3. Organisasi user operasional cukup fleksibel beradaptasi dengan kecepatan evolusi sistem
  4. Dimensi evolusi sistem sebanding dengan dimensi sistem yang digantikan
Langkah kunci berikutnya untuk evolusi bertahan hidup adalah untuk mengembangkan abstraksi yang lebih kuat dan metode penalaran untuk menentukan perilaku dan struktur dari sistem distribusi berskala besar, sehingga memungkinkan analisa yang lebih komprehensif atas pelayanan penting dan jejak intrusi saat membatasi kompleksitas. Selain itu, dapat meningkatkan representasi dan metode yang diperlukan untuk mendefinisikan intrusi. Sangat penting untuk bergerak melampaui keterbatasan bahasa alami dan untuk mengembangkan semantik yang seragam untuk penggunaan intrusi yang memungkinkan analisa yang lebih ketat dan bahkan memungkinkan untuk penerapan metode komputerisasi.
Hasil lain dari penelitian melibatkan pengembangan gaya arsitektur standar atau template untuk strategi bertahan hidup yang dapat dimasukkan dan disusun dengan sistem arsitektur untuk meningkatkan sifat bertahan hidup mereka. Template tersebut dapat secara independen dianalisa untuk menetapkan dan mendokumentasikan kontribusi mereka terhadap sistem bertahan hidup.
DAFTAR PUSTAKA
  • http://www.sei.cmu.edu/reports/00sr008.pdf (Spiral Development: Experience, Principles, and Refinements Spiral Development)
  • http://csse.usc.edu/csse/TECHRPTS/2001/usccse2001-501/usccse2001-501.pdf (Understanding the Spiral Model as a Tool for Evolutionary Acquisition)
  • http://csse.usc.edu/csse/TECHRPTS/1998/usccse98-512/usccse98-512.pdf (Using the WinWin Spiral Model: A Case Study)
  • http://www.sei.cmu.edu/reports/02tr026.pdf (Life-Cycle Models for Survivable Systems)
  • http://www.sei.cmu.edu/reports/89cm021.pdf (Software Project Management)