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 :
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/3Sunday, August 15th, 201011 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 :Adapun tahap-tahap dalam proyek SAP R/3 adalah sebagai berikut : Tahap I : Proyek Start-up dan Persiapan
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 : STRATEGI MOC UNTUK PROYEK SAP R/3 Dalam menerapkan MOC dalam proyek SAP, ada empat konsep inti yang membentuk strategi MOC secara keseluruhan yaitu :
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 :
RENCANA TAKTIS, UMPAN BALIK, DAN TAHAP MOC Rencana TaktisSetelah 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 :
Tahap MOC Untuk Mendukung Proyek SAP 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 HillIntegrating BPM with Six SigmaSunday, August 1st, 2010Preface 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 :
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 :
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 :
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. 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). 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 :
Conclusion 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
Penerapan Metodologi Model Spiral Dalam Sistem Perpustakaan Terpadu di University of Southern California (USC)Friday, July 30th, 2010PENDAHULUAN 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 SpiralModel 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 :
Gambar 2.1 : Diagram Spiral Development Sektor-sektor pada Spiral Model adalah:
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.Gambar 2.3 : Proyek-proyek dalam Model Spiral Keunggulan model ini adalah :
Kelemahan model ini adalah :
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 :
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 :
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. Tabel 2.2 : Hubungan Aktivitas Siklus Hidup dengan Elemen Survivabilitas E. Persyaratan dan SpesifikasiUntuk 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 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 :
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. Tabel 2.3 : Properti Kunci untuk Sistem Survivabilitas STUDI KASUS A. Gambaran Sistem Saat IniDi 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 :
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 :
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. Gambar 3.1 : Work Breakdown Structure B. Persiapan ProyekSetelah 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 :
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 :
Pedoman proyek yang dibahas dengan staf perpustakaan selama Siklus 0, telah memberikan informasi-informasi untuk memastikan bahwa :
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 :
Peran dan tanggung jawab para stakeholder antara lain :
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. 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 :
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 :
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 :
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 :
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 :
Tabel 3.2 : Hasil Evaluasi Survivabilitas Proyek
Tabel 3.3 : Hasil Evaluasi Persyaratan dan Spesifikasi Proyek F. Proyek Tahun KeduaDi 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 :
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 :
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
|
Selasa, 23 November 2010
uts enterprise resource plan
Langganan:
Postingan (Atom)