Arsip Blog

Jumat, 29 Oktober 2010

Model air Terjun

Waterfall Model

Dari Wikipedia, ensiklopedia bebas
Langsung ke: navigasi, cari

Model waterfall adalah proses pengembangan software sekuensial, dimana kemajuan dipandang sebagai terus mengalir ke bawah (seperti air terjun) melalui tahapan konsepsi, Inisiasi, Analisis, Desain, Konstruksi, Pengujian dan Pemeliharaan.
The dimodifikasi "air terjun model". Kemajuan mengalir dari atas ke bawah, seperti air terjun.
Proses pengembangan perangkat lunak
Kegiatan dan langkah-langkah
Persyaratan · Spesifikasi
Arsitektur · Desain
Implementasi · Pengujian
Deployment · Perawatan
Metodologi
Agile · Cleanroom ·
Iteratif · RAD · RUP · Spiral
Air Terjun · Lean
V-Model · TDD
Pendukung disiplin
Manajemen konfigurasi
Dokumentasi
Jaminan Kualitas (SQA)
Manajemen proyek
Pengalaman pengguna desain
Tools
Compiler · Debugger · Profiler
Desainer GUI · Terpadu pembangunan lingkungan
v • d • e

Model pengembangan air terjun berasal dari industri manufaktur dan konstruksi; sangat terstruktur lingkungan fisik di mana perubahan setelah fakta-adalah prohibitively mahal, jika tidak mustahil. Karena tidak ada metodologi pengembangan perangkat lunak resmi ada pada saat itu, model ini berorientasi hardware hanyalah diadaptasi untuk pengembangan perangkat lunak.

Deskripsi formal pertama dari model air terjun sering dikutip sebagai artikel 1970 oleh Winston W. Royce, [1] meskipun Royce tidak menggunakan "air terjun" dalam artikel ini. Royce disajikan model ini sebagai contoh model, cacat non-kerja (Royce 1970). Hal ini, pada kenyataannya, adalah bagaimana istilah ini umumnya digunakan dalam menulis tentang pengembangan perangkat lunak-untuk menggambarkan pandangan kritis atas praktek perangkat lunak yang umum digunakan. [2]
Isi
[Hide]

* 1 Model
* 2 Pendukung argumen
* 3 Kritik
* 4 Modifikasi model
* 5 Lihat juga
* 6 Referensi
* Membaca 7 lebih lanjut
* 8 Pranala luar

[Sunting] Model

Dalam model waterfall asli Royce, tahapan berikut ini diikuti dalam rangka:

1. Persyaratan spesifikasi
2. Desain
3. Konstruksi (AKA implementasi atau coding)
4. Integrasi
5. Pengujian dan debugging (AKA Validasi)
6. Instalasi
7. Pemeliharaan

Hasil model air terjun dari satu tahap ke tahap berikutnya secara berurutan. Misalnya, pertama selesai spesifikasi kebutuhan, yang setelah sign-off dianggap "diatur dalam batu." Ketika persyaratan selesai, satu hasil untuk desain. Perangkat lunak yang dimaksud dirancang dan cetak biru diambil untuk pelaksana (pemrogram) untuk mengikuti-desain ini harus menjadi rencana untuk melaksanakan persyaratan yang diberikan. Ketika desain selesai, sebuah implementasi dari desain yang dibuat oleh pemrogram. Menjelang tahap selanjutnya dari tahap implementasi, komponen perangkat lunak terpisah yang dihasilkan dikombinasikan untuk memperkenalkan fungsionalitas baru dan mengurangi risiko melalui penghapusan kesalahan.

Jadi model air terjun berpendapat bahwa seseorang harus pindah ke fase hanya bila fase sebelumnya adalah selesai dan disempurnakan. Namun, ada berbagai model air terjun diubah (termasuk model akhir Royce) yang mungkin termasuk variasi-variasi kecil atau besar terhadap proses ini.
[Sunting] argumen Pendukung

Waktu yang dihabiskan di awal siklus produksi perangkat lunak yang dapat menyebabkan ekonomi yang lebih besar pada tahap-tahap selanjutnya. McConnell menunjukkan bahwa bug yang ditemukan pada tahap awal (seperti spesifikasi persyaratan atau desain) lebih murah dengan uang, usaha, dan waktu, untuk memperbaiki dari bug yang sama ditemukan di kemudian hari dalam proses. ([McConnell 1996], p. 72, memperkirakan bahwa "... sebuah cacat persyaratan yang dibiarkan tidak terdeteksi sampai konstruksi atau pemeliharaan akan biaya 50 sampai 200 kali lebih banyak untuk memperbaiki karena akan memiliki biaya untuk memperbaiki pada saat persyaratan.") Untuk mengambil contoh ekstrim, jika desain program ternyata tidak mungkin untuk mengimplementasikan, lebih mudah untuk memperbaiki desain pada tahap desain daripada untuk mewujudkan bulan kemudian, ketika sedang komponen program terpadu, bahwa semua pekerjaan yang dilakukan sejauh ini akan dibuang karena desain rusak.

Ini adalah ide utama di balik Big Design Up Front (BDUF) dan model air terjun: waktu yang dihabiskan awal pada pembuatan persyaratan yakin dan desain benar menghemat banyak waktu dan usaha kemudian. Jadi, pemikiran mereka yang mengikuti proses air terjun berjalan, pastikan setiap tahap adalah 100% lengkap dan benar-benar benar sebelum Anda melanjutkan ke tahap berikutnya. Persyaratan Program harus diatur dalam batu sebelum desain dimulai (dinyatakan bekerja dimasukkan ke dalam desain yang didasarkan pada persyaratan yang salah yang terbuang). Desain program harus sempurna sebelum orang mulai untuk menerapkan desain (jika mereka menerapkan desain yang salah dan pekerjaan mereka yang terbuang), dll

Sebuah argumen lebih lanjut untuk model air terjun adalah bahwa ia menempatkan penekanan pada dokumentasi (seperti dokumen persyaratan dan dokumen desain) serta kode sumber. Dalam metodologi kurang dirancang dan didokumentasikan, anggota tim harus pergi, banyak pengetahuan hilang dan mungkin sulit untuk sebuah proyek untuk pulih dari. Haruskah dokumen desain bekerja sepenuhnya hadir (seperti tujuan dari Big Design Up Front dan model air terjun) anggota tim baru atau bahkan seluruh tim baru harus mampu membiasakan diri dengan membaca dokumen.

Seperti halnya di atas, beberapa lebih suka model air terjun untuk pendekatan yang sederhana dan berpendapat bahwa itu adalah lebih disiplin. Daripada apa yang penganut melihat air terjun sebagai kekacauan, model air terjun memberikan pendekatan terstruktur, model itu sendiri berlangsung secara linear melalui fase diskrit, mudah dimengerti dan dijelaskan sehingga mudah dipahami, tetapi juga menyediakan tonggak markable mudah dalam proses pembangunan. Hal ini mungkin untuk alasan ini bahwa model air terjun digunakan sebagai contoh awal model pembangunan di banyak teks rekayasa perangkat lunak dan program.

Dikatakan bahwa model air terjun dan Big Desain Facebook Front secara umum bisa cocok untuk proyek-proyek perangkat lunak yang stabil (terutama yang proyek dengan syarat tidak berubah, seperti dengan software shrink wrap) dan di mana ia mungkin dan kemungkinan desainer akan dapat untuk sepenuhnya memprediksi area masalah dari sistem dan menghasilkan desain yang benar sebelum pelaksanaan dimulai. Model air terjun juga mensyaratkan bahwa pelaksana mengikuti desain, dibuat dengan baik lengkap akurat, memastikan bahwa hasil integrasi sistem lancar.
[Sunting] Kritik

Banyak berpendapat model air terjun adalah ide yang buruk dalam praktek-percaya tidak mungkin untuk setiap proyek non-sepele untuk menyelesaikan fase siklus sebuah produk perangkat lunak sempurna sebelum pindah ke tahap berikutnya dan belajar dari mereka. Sebagai contoh, klien tidak mungkin tahu persis apa persyaratan yang mereka butuhkan sebelum meninjau prototipe bekerja dan mengomentari itu. Mereka mungkin mengubah persyaratan mereka terus-menerus. Perancang dan programer mungkin memiliki sedikit kontrol atas ini. Jika klien mengubah persyaratan mereka setelah desain selesai, desain harus dimodifikasi untuk mengakomodasi kebutuhan baru. Hal ini secara efektif berarti membatalkan cukup banyak jam kerja, yang berarti biaya meningkat, terutama jika sejumlah besar sumber daya proyek telah diinvestasikan di Big Design Up Front.

Desainer mungkin tidak menyadari kesulitan implementasi desain masa depan ketika menulis untuk sebuah produk perangkat lunak diimplementasikan. Artinya, hal itu mungkin menjadi jelas dalam tahap implementasi bahwa suatu wilayah tertentu dari fungsi program adalah sangat sulit untuk diterapkan. Dalam hal ini, lebih baik untuk merevisi desain daripada bertahan dalam desain yang didasarkan pada prediksi yang salah, dan yang tidak menjelaskan masalah yang baru ditemukan.

Bahkan tanpa seperti perubahan spesifikasi selama pelaksanaan, ada pilihan baik untuk memulai sebuah proyek baru dari awal, "di lapangan hijau", atau untuk melanjutkan beberapa sudah ada, "bidang coklat" (dari konstruksi lagi). Metodologi air terjun dapat digunakan untuk pengembangan yang berkelanjutan, bahkan untuk software yang ada, berasal dari tim lain. Seperti halnya dalam kasus ketika analis sistem gagal untuk menangkap kebutuhan pelanggan dengan benar, dampak yang dihasilkan pada tahap-tahap berikut (terutama coding) masih dapat dijinakkan oleh metodologi ini, dalam praktek: Pekerjaan yang penuh tantangan bagi tim QA.

Steve McConnell, dalam Undang Lengkap, (sebuah buku yang mengkritik maraknya penggunaan model air terjun) mengacu pada desain sebagai "masalah jahat"-masalah persyaratan dan pembatasan yang tidak dapat sepenuhnya diketahui sebelum selesai. Implikasi dari hal ini adalah bahwa tidak mungkin untuk menyempurnakan salah satu tahap pengembangan perangkat lunak, sehingga tidak mungkin jika menggunakan model air terjun untuk beralih ke tahap berikutnya.

David Parnas, dalam A Rasional Proses Desain: Bagaimana dan Mengapa Fake ini, menulis: [3]

"Banyak rincian [sistem] hanya menjadi dikenal kepada kita seperti yang kita kemajuan dalam pelaksanaannya [sistem]. Beberapa hal yang membatalkan kita belajar desain kami dan kita harus mundur. "

Memperluas konsep di atas, stakeholder proyek (non-IT personil) mungkin tidak sepenuhnya menyadari kemampuan teknologi yang sedang dilaksanakan. Hal ini dapat mengakibatkan apa yang mereka "berpikir mungkin" mendefinisikan harapan dan persyaratan. Hal ini dapat mengakibatkan desain yang tidak menggunakan potensi penuh dari apa yang teknologi baru dapat memberikan, atau hanya meniru aplikasi yang sudah ada atau proses dengan teknologi baru. Hal ini dapat menyebabkan perubahan yang signifikan terhadap pelaksanaan persyaratan setelah stakeholder menjadi lebih sadar akan fungsi yang tersedia dari teknologi baru. Contohnya adalah di mana organisasi bermigrasi dari suatu proses berbasis kertas ke proses elektronik. Sementara kiriman kunci proses kertas harus dipertahankan, manfaat dari real-time validasi input data, penelusuran, dan titik keputusan routing otomatis tidak dapat diantisipasi pada tahap perencanaan awal proyek.

Ide di belakang model air terjun mungkin "mengukur dua kali; dipotong sekali," dan mereka yang menentang model air terjun berpendapat bahwa ide ini cenderung menjadi berantakan ketika masalah terus perubahan karena modifikasi kebutuhan dan realisasi baru tentang masalah itu sendiri. Solusi potensial untuk pengembang berpengalaman untuk menghabiskan waktu di depan pada refactoring untuk mengkonsolidasikan perangkat lunak, dan untuk mempersiapkan untuk update mungkin, tidak peduli apakah itu sudah direncanakan. Pendekatan lain adalah dengan menggunakan desain penargetan modularitas dengan interface, untuk meningkatkan fleksibilitas dari perangkat lunak sehubungan dengan desain.
[Sunting] model Modified

Menanggapi masalah-masalah yang dirasakan dengan model air terjun murni, banyak model air terjun dimodifikasi telah diperkenalkan. Model ini dapat menangani beberapa atau semua kritik model air terjun murni [rujukan?] Model yang berbeda Banyak ditutupi oleh Steve McConnell pada bab "siklus perencanaan" dari bukunya Rapid Development:. Taming Wild Software Jadwal.

Sedangkan model pengembangan perangkat lunak semua menanggung beberapa kesamaan dengan model air terjun, sebagai model pengembangan perangkat lunak semua memasukkan setidaknya beberapa tahap yang sama dengan yang digunakan dalam model air terjun, bagian ini berkaitan dengan orang-orang terdekat dengan model air terjun. Untuk model yang berlaku perbedaan lebih lanjut untuk model air terjun, atau untuk model yang berbeda secara radikal mencari informasi umum tentang proses pengembangan perangkat lunak.
[Sunting] Lihat pula

* Agile pengembangan perangkat lunak
* Big Up Front Design
* Chaos model
* Perancangan dan pembangunan bertahap
* Iterfall pembangunan
* Rapid pengembangan aplikasi
* Software proses pengembangan
* Spiral Model
* Metodologi Pengembangan Sistem,
* V-model
* Model Dual Vee
* Daftar filosofi pengembangan perangkat lunak

Waterfall model

From Wikipedia, the free encyclopedia
Jump to: navigation, search

The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing and Maintenance.

The unmodified "waterfall model". Progress flows from the top to the bottom, like a waterfall.
Software development process
Activities and steps
Requirements · Specification
Architecture · Design
Implementation · Testing
Deployment · Maintenance
Methodologies
Agile · Cleanroom ·
Iterative · RAD · RUP · Spiral
Waterfall · Lean
V-Model · TDD
Supporting disciplines
Configuration management
Documentation
Quality assurance (SQA)
Project management
User experience design
Tools
Compiler · Debugger · Profiler
GUI designer · Integrated development environment

The waterfall development model originates in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[1] though Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model (Royce 1970). This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software practice.[2]

Contents

[hide]

[edit] Model

In Royce's original waterfall model, the following phases are followed in order:

  1. Requirements specification
  2. Design
  3. Construction (AKA implementation or coding)
  4. Integration
  5. Testing and debugging (AKA Validation)
  6. Installation
  7. Maintenance

The waterfall model proceeds from one phase to the next in a sequential manner. For example, one first completes requirements specification, which after sign-off are considered "set in stone." When requirements are completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow—this design should be a plan for implementing the requirements given. When the design is complete, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors.

Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.

[edit] Supporting arguments

Time spent early in the software production cycle can lead to greater economy at later stages. McConnell shows that a bug found in the early stages (such as requirements specification or design) is cheaper in money, effort, and time, to fix than the same bug found later on in the process. ([McConnell 1996], p. 72, estimates that "...a requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time.") To take an extreme example, if a program design turns out to be impossible to implement, it is easier to fix the design at the design stage than to realize months later, when program components are being integrated, that all the work done so far has to be scrapped because of a broken design.

This is the central idea behind Big Design Up Front (BDUF) and the waterfall model: time spent early on making sure requirements and design are correct saves you much time and effort later. Thus, the thinking of those who follow the waterfall process goes, make sure each phase is 100% complete and absolutely correct before you proceed to the next phase. Program requirements should be set in stone before design begins (otherwise work put into a design based on incorrect requirements is wasted). The program's design should be perfect before people begin to implement the design (otherwise they implement the wrong design and their work is wasted), etc.

A further argument for the waterfall model is that it places emphasis on documentation (such as requirements documents and design documents) as well as source code. In less designed and documented methodologies, should team members leave, much knowledge is lost and may be difficult for a project to recover from. Should a fully working design document be present (as is the intent of Big Design Up Front and the waterfall model) new team members or even entirely new teams should be able to familiarize themselves by reading the documents.

As well as the above, some prefer the waterfall model for its simple approach and argue that it is more disciplined. Rather than what the waterfall adherent sees as chaos, the waterfall model provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand; it also provides easily markable milestones in the development process. It is perhaps for this reason that the waterfall model is used as a beginning example of a development model in many software engineering texts and courses.

It is argued that the waterfall model and Big Design up Front in general can be suited to software projects that are stable (especially those projects with unchanging requirements, such as with shrink wrap software) and where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started. The waterfall model also requires that implementers follow the well made, complete design accurately, ensuring that the integration of the system proceeds smoothly.

[edit] Criticism

Many argue the waterfall model is a bad idea in practice—believing it impossible for any non-trivial project to finish a phase of a software product's lifecycle perfectly before moving to the next phases and learning from them. For example, clients may not know exactly what requirements they need before reviewing a working prototype and commenting on it. They may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost, especially if a large amount of the project's resources has already been invested in Big Design Up Front.

Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. In this case, it is better to revise the design than persist in a design based on faulty predictions, and that does not account for the newly discovered problems.

Even without such changing of the specification during implementation, there is the option either to start a new project from scratch, "on a green field", or to continue some already existing, "a brown field" (from construction again). The waterfall methodology can be used for continuous enhancement, even for existing software, originally from another team. As well as in the case when the system analyst fails to capture the customer requirements correctly, the resulting impacts on the following phases (mainly the coding) still can be tamed by this methodology, in practice: A challenging job for a QA team.

Steve McConnell, in Code Complete, (a book that criticizes widespread use of the waterfall model) refers to design as a "wicked problem"—a problem whose requirements and limitations cannot be entirely known before completion. The implication of this is that it is impossible to perfect one phase of software development, thus it is impossible if using the waterfall model to move on to the next phase.

David Parnas, in A Rational Design Process: How and Why to Fake It, writes:[3]

“Many of the [system's] details only become known to us as we progress in the [system's] implementation. Some of the things that we learn invalidate our design and we must backtrack.”

Expanding the concept above, the project stakeholders (non-IT personnel) may not be fully aware of the capabilities of the technology being implemented. This can lead to what they "think is possible" defining expectations and requirements. This can lead to a design that does not use the full potential of what the new technology can deliver, or simply replicates the existing application or process with the new technology. This can cause substantial changes to the implementation requirements once the stakeholders become more aware of the functionality available from the new technology. An example is where an organization migrates from a paper-based process to an electronic process. While key deliverables of the paper process must be maintained, benefits of real-time data input validation, traceability, and automated decision point routing may not be anticipated at the early planning stages of the project.

The idea behind the waterfall model may be "measure twice; cut once," and those opposed to the waterfall model argue that this idea tends to fall apart when the problem constantly changes due to requirement modifications and new realizations about the problem itself. A potential solution is for an experienced developer to spend time up front on refactoring to consolidate the software, and to prepare it for a possible update, no matter if such is planned already. Another approach is to use a design targeting modularity with interfaces, to increase the flexibility of the software with respect to the design.

[edit] Modified models

In response to the perceived problems with the pure waterfall model, many modified waterfall models have been introduced. These models may address some or all of the criticisms of the pure waterfall model.[citation needed] Many different models are covered by Steve McConnell in the "lifecycle planning" chapter of his book Rapid Development: Taming Wild Software Schedules.

While all software development models bear some similarity to the waterfall model, as all software development models incorporate at least some phases similar to those used in the waterfall model, this section deals with those closest to the waterfall model. For models that apply further differences to the waterfall model, or for radically different models seek general information on the software development process.

[edit] See also

[edit] References




Spiral model

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Spiral model (Boehm, 1988).
Software development process
Activities and steps
Requirements · Specification
Architecture · Design
Implementation · Testing
Deployment · Maintenance
Methodologies
Agile · Cleanroom ·
Iterative · RAD · RUP · Spiral
Waterfall · Lean
V-Model · TDD
Supporting disciplines
Configuration management
Documentation
Quality assurance (SQA)
Project management
User experience design
Tools
Compiler · Debugger · Profiler
GUI designer · Integrated development environment

The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.


Contents

[hide]

[edit] History

The spiral model was defined by Barry Boehm in his 1986 article "A Spiral Model of Software Development and Enhancement"[1]. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters.[citation needed]

As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.

[edit] Steps

The steps in the spiral model iteration can be generalized as follows:

  1. The system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
  2. A preliminary design is created for the new system. This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies to use them are decided. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.
  3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
  4. A second prototype is evolved by a fourfold procedure:
    1. evaluating the first prototype in terms of its strengths, weaknesses, and risks;
    2. defining the requirements of the second prototype;
    3. planning and designing the second prototype;
    4. constructing and testing the second prototype.

[edit] Applications

The spiral model is mostly used in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military had adopted the spiral model for its Future Combat Systems program. The FCS project was canceled after six years (2003 - 2009), it had a 2 year iteration (spiral). FCS should have resulted in 3 consecutive prototypes (one prototype per spiral - every 2 years). It was canceled in May, 2009. The spiral model thus may suit small (up to $3M) software applications and not complicated ($3B) distributed, interoperable, system of systems.

Also it is reasonable to use the spiral model in projects where business goals are unstable but the architecture must be realized well enough to provide high loading and stress ability. For example, the Spiral Architecture Driven Development is the spiral based SDLC which shows the possible way how to reduce a risk of non effective architecture with the help of spiral model in conjunction with the best practices from other models.

[edit] References


Spiral Model
Dari Wikipedia, ensiklopedia bebas
Langsung ke: navigasi, cari
Spiral Model (Boehm, 1988).
Proses pengembangan perangkat lunak
Kegiatan dan langkah-langkah
Persyaratan · Spesifikasi
Arsitektur · Desain
Implementasi · Pengujian
Deployment · Perawatan
Metodologi
Agile · Cleanroom ·
Iteratif · RAD · RUP · Spiral
Air Terjun · Lean
V-Model · TDD
Pendukung disiplin
Manajemen konfigurasi
Dokumentasi
Jaminan Kualitas (SQA)
Manajemen proyek
Pengalaman pengguna desain
Tools
Compiler · Debugger · Profiler
Desainer GUI · Terpadu pembangunan lingkungan
v • d • e

Model spiral adalah pengembangan perangkat lunak proses menggabungkan unsur-unsur baik desain dan prototyping-in-tahap, dalam upaya untuk menggabungkan kelebihan dari konsep top-down dan bottom-up. Juga dikenal sebagai model siklus spiral (atau pengembangan spiral), itu adalah pengembangan sistem metode (SDM) yang digunakan dalam teknologi informasi (TI). Model pengembangan menggabungkan fitur dari model prototipe dan model waterfall. Model spiral ini ditujukan untuk proyek-proyek besar, mahal dan rumit.


Isi
[Hide]

* 1 Sejarah
* 2 Langkah-langkah
* 3 Aplikasi
* 4 Referensi

[Sunting] Sejarah

Model spiral didefinisikan oleh Barry Boehm pada tahun 1986 artikelnya "Sebuah Model Spiral dari Software Development dan Peningkatan" [1]. Model ini bukan model pertama untuk membahas pengembangan berulang, tetapi itu adalah model pertama untuk menjelaskan mengapa hal-hal iterasi [rujukan?].

Sebagai awalnya direncanakan, para iterasi yang biasanya 6 bulan sampai 2 tahun yang panjang. Tiap tahap dimulai dengan tujuan desain dan berakhir dengan klien (yang mungkin internal) meninjau kemajuan sejauh ini. Analisis dan rekayasa upaya diterapkan pada setiap fase proyek, dengan mata ke arah tujuan akhir proyek.
[Sunting] Langkah

Langkah-langkah dalam model spiral iterasi dapat digeneralisir sebagai berikut:

1. Persyaratan sistem didefinisikan dalam serinci mungkin. Hal ini biasanya melibatkan mewawancarai sejumlah pengguna yang mewakili semua pengguna eksternal atau internal dan aspek lain dari sistem yang ada.
2. Sebuah desain awal dibuat untuk sistem yang baru. Fase ini adalah bagian paling penting dari "Spiral Model". Pada fase ini semua (dan tersedia) kemungkinan alternatif, yang dapat membantu dalam mengembangkan proyek biaya efektif dianalisa dan strategi untuk menggunakannya ditentukan. Fase ini telah ditambahkan khusus untuk mengidentifikasi dan mengatasi semua risiko yang mungkin dalam pengembangan proyek. Jika risiko menunjukkan setiap jenis ketidakpastian dalam persyaratan, prototyping dapat digunakan untuk melanjutkan dengan data yang tersedia dan menemukan solusi yang mungkin untuk berurusan dengan potensi perubahan persyaratan.
3. Sebuah prototipe pertama sistem baru dibangun dari desain awal. Ini biasanya sebuah sistem skala-down, dan merupakan perkiraan karakteristik produk akhir.
4. Sebuah prototipe kedua adalah berkembang dengan prosedur empat kali lipat:
1. mengevaluasi prototipe pertama dalam hal kekuatan dan kelemahan, dan risiko;
2. mendefinisikan persyaratan prototipe kedua;
3. perencanaan dan perancangan prototipe kedua;
4. membangun dan menguji prototipe kedua.

[Sunting] Aplikasi

Model spiral banyak digunakan dalam proyek-proyek besar. Untuk proyek kecil, konsep pengembangan perangkat lunak Agile ini menjadi alternatif. Militer AS telah mengadopsi model spiral untuk pelaksanaan program Future Combat Systems. Proyek FCS dibatalkan setelah enam tahun (2003 - 2009), itu memiliki iterasi 2 tahun (spiral). FCS seharusnya menghasilkan 3 prototip berturut-turut (satu prototipe per spiral - setiap 2 tahun). Saat itu dibatalkan pada Mei 2009. Model spiral demikian mungkin sesuai kecil (sampai dengan $ 3M) perangkat lunak aplikasi dan tidak rumit ($ 3B) terdistribusi, interoperable, sistem sistem.

Juga masuk akal untuk menggunakan model spiral di proyek mana tujuan bisnis tidak stabil tetapi arsitektur harus disadari cukup baik untuk memberikan beban yang tinggi dan kemampuan stres. Sebagai contoh, Spiral Arsitektur Driven Development adalah spiral didasarkan SDLC yang menunjukkan cara yang bagaimana mengurangi risiko arsitektur non efektif dengan bantuan model spiral dalam kaitannya dengan praktik terbaik dari model lainnya.
[Sunting] Referensi



Jumat, 22 Oktober 2010

Systems Development Life Cycle

Systems Development Life Cycle

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Model of the Systems Development Life Cycle with the Maintenance bubble highlighted.

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems.

In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system[1]: the software development process.

Contents

[hide]

[edit] Overview

Systems Development Life Cycle (SDLC) is a process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.[2]

Computer systems are complex and often (especially with the recent rise of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of SDLC models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize".[citation needed]

SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results[citation needed]. Other models, such as Anamorphic Development, tend to focus on a form of development that is guided by project scope and adaptive iterations of feature development.

In project management a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004) "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements".[3]

[edit] History

The systems development life cycle (SDLC) is a type of methodology used to describe the process for building information systems, intended to develop information systems in a very deliberate, structured and methodical way, reiterating each stage of the life cycle. The systems development life cycle, according to Elliott & Strachan & Radford (2004), "originated in the 1960s to develop large scale functional business systems in an age of large scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines".[4]

Several systems development frameworks have been partly based on SDLC, such as the Structured Systems Analysis and Design Method (SSADM) produced for the UK government Office of Government Commerce in the 1980s. Ever since, according to Elliott (2004), "the traditional life cycle approaches to systems development have been increasingly replaced with alternative approaches and frameworks, which attempted to overcome some of the inherent deficiencies of the traditional SDLC".[4]

[edit] Systems development phases

The System Development Life Cycle framework provides system designers and developers to follow a sequence of activities. It consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one.

A Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. A number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize. The oldest of these, and the best known, is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following[5]:

  • Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
  • Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
  • Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
  • Implementation: The real code is written here.
  • Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
  • Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
  • Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

In the following example (see picture) these stage of the Systems Development Life Cycle are divided in ten steps from definition to creation and modification of IT work products:

The tenth phase occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. The tasks and work products for each phase are described in subsequent chapters. [6]

Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap.[6]

[edit] System analysis

The goal of system analysis is to determine where the problem is in an attempt to fix the system. This step involves breaking down the system in different pieces to analyze the situation, analyzing project goals, breaking down what needs to be created and attempting to engage users so that definite requirements can be defined. Requirements analysis sometimes requires individuals/teams from client as well as service provider sides to get detailed and accurate requirements....often there has to be a lot of communication to and from to understand these requirements. Requirement gathering is the most crucial aspect as many times communication gaps arise in this phase and this leads to validation errors and bugs in the software program.

[edit] Design

In systems design the design functions and operations are described in detail, including screen layouts, business rules, process diagrams and other documentation. The output of this stage will describe the new system as a collection of modules or subsystems.

The design stage takes as its initial input the requirements identified in the approved requirements document. For each requirement, a set of one or more design elements will be produced as a result of interviews, workshops, and/or prototype efforts.

Design elements describe the desired software features in detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudocode, and a complete entity-relationship diagram with a full data dictionary. These design elements are intended to describe the software in sufficient detail that skilled programmers may develop the software with minimal additional input design.

[edit] Implementation

Modular and subsystem programming code will be accomplished during this stage. Unit testing and module testing are done in this stage by the developers. This stage is intermingled with the next in that individual modules will need testing before integration to the main project.

[edit] Testing

The code is tested at various levels in software testing. Unit, system and user acceptance testings are often performed. This is a grey area as many different opinions exist as to what the stages of testing are and how much if any iteration occurs. Iteration is not generally part of the waterfall model, but usually some occur at this stage.

Following are the types of testing:

  • Defect testing
  • Path testing
  • Data set testing.
  • Unit testing
  • System testing
  • Integration testing
  • Black box testing
  • White box testing
  • Regression testing
  • Automation testing
  • User acceptance testing
  • Performance testing
  • Production process that ensures that the program performs the intended task.

[edit] Operations and maintenance

The deployment of the system includes changes and enhancements before the decommissioning or sunset of the system. Maintaining the system is an important aspect of SDLC. As key personnel change positions in the organization, new changes will be implemented, which will require system updates.

[edit] Systems development life cycle topics

[edit] Management and control

SDLC Phases Related to Management Controls.[7]

The Systems Development Life Cycle (SDLC) phases serve as a programmatic guide to project activity and provide a flexible but consistent way to conduct projects to a depth matching the scope of the project. Each of the SDLC phase objectives are described in this section with key deliverables, a description of recommended tasks, and a summary of related control objectives for effective management. It is critical for the project manager to establish and monitor control objectives during each SDLC phase while executing projects. Control objectives help to provide a clear statement of the desired result or purpose and should be used throughout the entire SDLC process. Control objectives can be grouped into major categories (Domains), and relate to the SDLC phases as shown in the figure.[7]

To manage and control any SDLC initiative, each project will be required to establish some degree of a Work Breakdown Structure (WBS) to capture and schedule the work necessary to complete the project. The WBS and all programmatic material should be kept in the “Project Description” section of the project notebook. The WBS format is mostly left to the project manager to establish in a way that best describes the project work. There are some key areas that must be defined in the WBS as part of the SDLC policy. The following diagram describes three key areas that will be addressed in the WBS in a manner established by the project manager.[7]

[edit] Work breakdown structured organization

Work Breakdown Structure.[7]

The upper section of the Work Breakdown Structure (WBS) should identify the major phases and milestones of the project in a summary fashion. In addition, the upper section should provide an overview of the full scope and timeline of the project and will be part of the initial project description effort leading to project approval. The middle section of the WBS is based on the seven Systems Development Life Cycle (SDLC) phases as a guide for WBS task development. The WBS elements should consist of milestones and “tasks” as opposed to “activities” and have a definitive period (usually two weeks or more). Each task must have a measurable output (e.g. document, decision, or analysis). A WBS task may rely on one or more activities (e.g. software engineering, systems engineering) and may require close coordination with other tasks, either internal or external to the project. Any part of the project needing support from contractors should have a Statement of work (SOW) written to include the appropriate tasks from the SDLC phases. The development of a SOW does not occur during a specific phase of SDLC but is developed to include the work from the SDLC process that may be conducted by external resources such as contractors and struct.[7]

[edit] Baselines in the SDLC

Baselines are an important part of the Systems Development Life Cycle (SDLC). These baselines are established after four of the five phases of the SDLC and are critical to the iterative nature of the model .[8] Each baseline is considered as a milestone in the SDLC.

  • Functional Baseline: established after the conceptual design phase.
  • Allocated Baseline: established after the preliminary design phase.
  • Product Baseline: established after the detail design and development phase.
  • Updated Product Baseline: established after the production construction phase.

[edit] Complementary to SDLC

Complementary Software development methods to Systems Development Life Cycle (SDLC) are:

Comparison of Methodology Approaches (Post, & Anderson 2006)[9]

SDLC RAD Open Source Objects JAD Prototyping End User
Control Formal MIS Weak Standards Joint User User
Time Frame Long Short Medium Any Medium Short Short
Users Many Few Few Varies Few One or Two One
MIS staff Many Few Hundreds Split Few One or Two None
Transaction/DSS Transaction Both Both Both DSS DSS DSS
Interface Minimal Minimal Weak Windows Crucial Crucial Crucial
Documentation and training Vital Limited Internal In Objects Limited Weak None
Integrity and security Vital Vital Unknown In Objects Limited Weak Weak
Reusability Limited Some Maybe Vital Limited Weak None

[edit] Strengths and weaknesses

Few people in the modern computing world would use a strict waterfall model for their Systems Development Life Cycle (SDLC) as many modern methodologies have superseded this thinking. Some will argue that the SDLC no longer applies to models like Agile computing, but it is still a term widely in use in Technology circles. The SDLC practice has advantages in traditional models of software development, that lends itself more to a structured environment. The disadvantages to using the SDLC methodology is when there is need for iterative development or (i.e. web development or e-commerce) where stakeholders need to review on a regular basis the software being designed. Instead of viewing SDLC from a strength or weakness perspective, it is far more important to take the best practices from the SDLC model and apply it to whatever may be most appropriate for the software being designed.

A comparison of the strengths and weaknesses of SDLC:

Strength and Weaknesses of SDLC [9]
Strengths Weaknesses
Control. Increased development time.
Monitor Large projects. Increased development cost.
Detailed steps. Systems must be defined up front.
Evaluate costs and completion targets. Rigidity.
Documentation. Hard to estimate costs, project overruns.
Well defined user input. User input is sometimes limited.
Ease of maintenance.
Development and design standards.
Tolerates changes in MIS staffing.

An alternative to the SDLC is Rapid Application Development, which combines prototyping, Joint Application Development and implementation of CASE tools. The advantages of RAD are speed, reduced development cost, and active user involvement in the development process.

It should not be assumed that just because the waterfall model is the oldest original SDLC model that it is the most efficient system. At one time the model was beneficial mostly to the world of automating activities that were assigned to clerks and accountants. However, the world of technological evolution is demanding[citation needed] that systems have a greater functionality that would assist help desk technicians/administrators or information technology specialists/analysts.

[edit] See also

[edit] References

  1. ^ SELECTING A DEVELOPMENT APPROACH. Retrieved 27 October 2008.
  2. ^ "Systems Development Life Cycle". In: Foldoc(2000-12-24)
  3. ^ James Taylor (2004). Managing Information Technology Projects. p.39..
  4. ^ a b Geoffrey Elliott & Josh Strachan (2004) Global Business Information Technology. p.87.
  5. ^ http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle
  6. ^ a b US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT Chapter 1. Introduction.
  7. ^ a b c d e U.S. House of Representatives (1999). Systems Development Life-Cycle Policy. p.13.
  8. ^ Blanchard, B. S., & Fabrycky, W. J.(2006) Systems engineering and analysis (4th ed.) New Jersey: Prentice Hall. p.31
  9. ^ a b Post, G., & Anderson, D., (2006). Management information systems: Solving business problems with information technology. (4th ed.). New York: McGraw-Hill Irwin.

[edit] Further reading

[edit] External links



Siklus Hidup Pengembangan Sistem
Dari Wikipedia, ensiklopedia bebas
(Dialihkan dari Sistem pengembangan siklus hidup)
Langsung ke: navigasi, cari

Untuk kegunaan lain, lihat SDLC (disambiguasi).
Model Pengembangan Sistem Life Cycle dengan gelembung Pemeliharaan disorot.

Pengembangan Sistem Life Cycle (SDLC), atau Software Development Life Cycle dalam rekayasa sistem, sistem informasi dan rekayasa perangkat lunak, adalah proses menciptakan atau mengubah sistem, dan model-model dan metodologi yang digunakan orang untuk mengembangkan sistem ini. Konsep ini umumnya mengacu pada sistem komputer atau informasi.

Dalam rekayasa perangkat lunak konsep SDLC menyokong berbagai jenis metodologi pengembangan perangkat lunak. Metodologi ini membentuk kerangka kerja bagi perencanaan dan pengendalian penciptaan sistem informasi [1]: proses pengembangan software.
Isi
[Hide]

* 1 Ikhtisar
* 2 Sejarah
* 3 Sistem tahap pengembangan
o 3.1 Sistem analisis
o Desain 3.2
o 3.3 Implementasi
o 3.4 Pengujian
3.5 o Operasi dan pemeliharaan
* 4 Sistem topik siklus hidup pengembangan
o 4.1 Manajemen dan kontrol
o 4.2 Kerja rincian struktur organisasi
o 4.3 baseline dalam SDLC
o 4.4 Tambahan untuk SDLC
* 5 Kekuatan dan kelemahan
* 6 Lihat juga
* 7 Referensi
* Membaca 8 lebih lanjut
* 9 Pranala luar

[Sunting] Ikhtisar

Pengembangan Sistem Life Cycle (SDLC) adalah proses yang digunakan oleh analis sistem untuk mengembangkan sistem informasi, termasuk persyaratan, validasi, pelatihan, dan pengguna (stakeholder) kepemilikan. Setiap SDLC harus menghasilkan sistem berkualitas tinggi yang memenuhi atau melampaui harapan pelanggan, mencapai penyelesaian dalam waktu dan perkiraan biaya, bekerja secara efektif dan efisien dalam infrastruktur teknologi saat ini dan direncanakan Informasi, dan murah untuk mempertahankan dan biaya-efektif untuk meningkatkan. [ 2]

Sistem komputer sangat kompleks dan sering (terutama dengan munculnya baru-baru ini Service-Oriented Architecture) Link beberapa sistem tradisional berpotensi disediakan oleh vendor perangkat lunak yang berbeda. Untuk mengelola tingkat kerumitan, sejumlah model SDLC telah diciptakan: "air terjun"; "fountain"; "spiral", "membangun dan memperbaiki"; "prototyping cepat"; "incremental", dan "sinkronisasi dan menstabilkan". [rujukan?]

model SDLC dapat dijelaskan sepanjang spektrum gesit untuk iteratif untuk sekuensial. Agile metodologi, seperti XP dan Scrum, fokus pada proses ringan yang memungkinkan untuk perubahan yang cepat di sepanjang siklus pengembangan. Berulang metodologi, seperti Rational Unified Proses dan Metode Pengembangan Sistem Dinamis, fokus pada proyek lingkup terbatas dan produk memperluas atau meningkatkan oleh beberapa iterasi. Sequential atau besar-desain-muka (BDUF) model, seperti Air Terjun, fokus pada perencanaan yang lengkap dan benar untuk membimbing proyek besar dan risiko untuk hasil yang sukses dan diprediksi [rujukan?]. Model-model lain, seperti Anamorphic Pembangunan, cenderung fokus pada suatu bentuk pembangunan yang dipandu oleh lingkup proyek dan adaptif iterasi pengembangan fitur.

Dalam manajemen proyek proyek dapat didefinisikan baik dengan siklus hidup proyek (PLC) dan SDLC, dimana kegiatan yang sedikit berbeda terjadi. Menurut Taylor (2004) "pada siklus proyek mencakup semua kegiatan proyek, sedangkan pengembangan sistem siklus hidup berfokus pada persyaratan mewujudkan produk". [3]
[Sunting] Sejarah

Pengembangan sistem siklus hidup (SDLC) adalah jenis metodologi yang digunakan untuk menggambarkan proses untuk membangun sistem informasi, dimaksudkan untuk mengembangkan sistem informasi dalam cara yang sangat disengaja, terstruktur dan metodis, mengulangi setiap tahap siklus hidup. Pengembangan sistem siklus hidup, menurut Elliott & Strachan & Radford (2004), "berasal pada tahun 1960 untuk mengembangkan sistem skala usaha besar fungsional dalam zaman konglomerat usaha skala besar. Informasi kegiatan seputar sistem pengolahan data berat dan rutinitas angka-angka ". [4]

Beberapa sistem kerangka pengembangan telah sebagian didasarkan pada SDLC, seperti Structured Sistem Metode Analisis dan Desain (SSADM) diproduksi untuk pemerintah Inggris Office of Government Commerce pada 1980-an. Sejak saat itu, menurut Elliott (2004), "pendekatan siklus hidup tradisional untuk pengembangan sistem telah semakin digantikan dengan pendekatan alternatif dan kerangka kerja, yang berusaha untuk mengatasi beberapa kekurangan yang melekat pada SDLC tradisional". [4]
[Sunting] Sistem tahapan pembangunan
Pertanyaan buku-new.svg
Bagian ini membutuhkan catatan kaki untuk pemastian.
Silakan bantu memperbaiki artikel ini dengan menambahkan referensi yang handal. Disertai rujukan bahan mungkin sulit dan dihapus. (September 2010)

Pengembangan Sistem Life Cycle menyediakan kerangka kerja desainer sistem dan pengembang untuk mengikuti rangkaian kegiatan. Ini terdiri dari satu set langkah-langkah atau fase di mana setiap tahap dari SDLC menggunakan hasil sebelumnya.

Sebuah Pengembangan Sistem Life Cycle (SDLC) menganut fase penting yang penting bagi para pengembang, seperti perencanaan, analisis, desain, dan implementasi, dan akan dijelaskan pada bagian di bawah ini. Sejumlah sistem kehidupan siklus pengembangan (SDLC) model yang telah dibuat: air terjun, air mancur, spiral, membangun dan memperbaiki, prototyping cepat, incremental, dan melakukan sinkronisasi dan stabil. Tertua dari ini, dan yang paling terkenal, adalah model air terjun: urutan tahap di mana output dari setiap tahap menjadi masukan untuk selanjutnya. Tahap ini dapat dicirikan dan dibagi dengan cara yang berbeda, termasuk [5] sebagai berikut:

* Perencanaan proyek, studi kelayakan: Menetapkan tampilan tingkat tinggi dari proyek dimaksud dan menentukan tujuannya.

* Sistem analisis, persyaratan definisi: tujuan proyek memurnikan ke dalam fungsi-fungsi dan operasi dari aplikasi dimaksud. Menganalisa pengguna akhir kebutuhan informasi.

* Sistem Desain: Menjelaskan fitur yang diinginkan dan operasional secara rinci, termasuk tata letak layar, aturan bisnis, diagram proses, pseudocode dan dokumentasi lainnya.

* Pelaksanaan: Kode sebenarnya yang tertulis di sini.

* Integrasi dan pengujian: Membawa semua potongan ke sebuah lingkungan pengujian khusus, kemudian memeriksa untuk kesalahan, bug dan interoperabilitas.

* Penerimaan, instalasi, penyebaran: Tahap akhir pengembangan awal, di mana perangkat lunak dimasukkan ke dalam produksi dan menjalankan bisnis yang sebenarnya.

* Pemeliharaan: Apa yang terjadi selama sisa hidup perangkat lunak: perubahan, koreksi, penambahan, pindah ke platform komputasi yang berbeda dan banyak lagi. Ini, langkah paling glamor dan mungkin paling penting dari semua, terus tampaknya selamanya.

Pada contoh berikut (lihat gambar) ini tahap Pengembangan Sistem Life Cycle dibagi dalam sepuluh langkah dari definisi untuk penciptaan dan modifikasi produk kerja IT:
Tahap kesepuluh terjadi ketika sistem tersebut dijual dan tugas yang dilakukan adalah baik dihilangkan atau dialihkan ke sistem lain. Tugas dan produk kerja untuk setiap tahap adalah dijelaskan dalam bab-bab selanjutnya. [6]

Tidak setiap proyek akan membutuhkan bahwa tahap secara berurutan dieksekusi. Namun, fase saling bergantung. Tergantung pada ukuran dan kompleksitas proyek, tahapan dapat dikombinasikan atau mungkin tumpang tindih. [6]
[Sunting] Analisis Sistem

Tujuan dari analisis sistem adalah untuk menentukan di mana masalah itu dalam upaya untuk memperbaiki sistem. Langkah ini melibatkan mendobrak sistem di bagian yang berbeda untuk menganalisis situasi, menganalisis tujuan proyek, meruntuhkan apa yang perlu dibuat dan berusaha untuk melibatkan pengguna sehingga persyaratan tertentu dapat didefinisikan. Persyaratan analisis kadang-kadang memerlukan individu / tim dari klien serta pihak penyedia layanan untuk mendapatkan persyaratan rinci dan akurat .... sering harus ada banyak komunikasi ke dan dari untuk memahami persyaratan tersebut. pengumpulan Kebutuhan adalah aspek yang paling penting karena banyak kali kesenjangan komunikasi yang muncul dalam fase ini dan ini menyebabkan kesalahan validasi dan bug dalam program perangkat lunak.
[Sunting] Desain

Dalam desain sistem fungsi desain dan operasi dijelaskan secara rinci, termasuk tata letak layar, aturan bisnis, diagram proses dan dokumentasi lainnya. Output dari tahap ini akan menjelaskan sistem yang baru sebagai kumpulan modul atau subsistem.

Tahap desain mengambil sebagai masukan awal persyaratan diidentifikasi dalam dokumen persyaratan yang telah disetujui. Untuk setiap persyaratan, satu set dari satu atau lebih elemen desain akan diproduksi sebagai hasil wawancara, lokakarya, dan / atau usaha prototipe.

Desain elemen menggambarkan fitur perangkat lunak yang diinginkan secara detail, dan umumnya termasuk diagram hirarki fungsional, diagram tata letak layar, tabel aturan bisnis, diagram proses bisnis, pseudocode, dan diagram hubungan entitas-lengkap dengan data penuh kamus. Unsur-unsur desain dimaksudkan untuk menjelaskan perangkat lunak secara rinci yang cukup bahwa programmer terampil dapat mengembangkan perangkat lunak dengan desain input minimal tambahan.
[Sunting] Implementasi

Modular dan kode subsistem pemrograman akan dilakukan selama tahap ini. Unit pengujian dan pengujian modul dilakukan dalam tahap ini oleh para pengembang. Tahap ini bercampur dengan berikutnya dalam modul individu akan membutuhkan pengujian sebelum integrasi ke proyek utama.
[Sunting] Pengujian

Kode ini diuji pada berbagai tingkat dalam pengujian perangkat lunak. Unit, sistem dan ujian penerimaan pengguna yang sering dilakukan. Ini adalah wilayah abu-abu sebagai banyak yang berbeda pendapat ada seperti apa tahap pengujian dan seberapa banyak jika iterasi apapun yang terjadi. Iterasi umumnya tidak bagian dari model air terjun, tapi biasanya beberapa terjadi pada tahap ini.

Berikut adalah jenis pengujian:

* Cacat pengujian
* Path pengujian
* Data set pengujian.
* Unit pengujian
* Pengujian sistem
* Integrasi pengujian
* Kotak hitam pengujian
* Putih pengujian kotak
* Regresi pengujian
* Otomatisasi pengujian
* User penerimaan pengujian
* Kinerja pengujian
* Proses produksi yang menjamin bahwa program melakukan tugas dimaksud.

[Sunting] Operasi dan pemeliharaan

Penyebaran sistem meliputi perubahan dan perangkat tambahan sebelum matahari terbenam dekomisioning atau sistem. Mempertahankan sistem merupakan aspek penting dari SDLC. Sebagai personil kunci perubahan posisi dalam organisasi, perubahan baru akan dilaksanakan, yang akan membutuhkan update sistem.
[Sunting] Sistem topik siklus hidup pengembangan
[Sunting] Manajemen dan kontrol
Tahapan SDLC Terkait dengan Kontrol Manajemen. [7]

Pengembangan Sistem Life Cycle (SDLC) tahap menjadi panduan program untuk kegiatan proyek dan menyediakan cara yang fleksibel tetapi konsisten untuk melakukan proyek-proyek untuk kedalaman yang cocok dengan ruang lingkup proyek. Masing-masing tujuan fase SDLC dijelaskan di bagian ini dengan kiriman kunci, deskripsi tugas yang direkomendasikan, dan ringkasan tujuan pengendalian terkait untuk manajemen yang efektif. Hal ini penting bagi manajer proyek untuk menetapkan dan memantau tujuan pengendalian pada setiap tahap SDLC sedangkan proyek pelaksana. Kontrol tujuan membantu memberikan pernyataan yang jelas dari hasil yang diinginkan atau tujuan dan harus digunakan selama proses SDLC keseluruhan. Kontrol tujuan dapat dikelompokkan menjadi kategori utama (Domain), dan berhubungan dengan fase SDLC seperti yang ditunjukkan pada gambar. [7]

Untuk mengelola dan mengendalikan setiap inisiatif SDLC, masing-masing proyek akan diminta untuk menetapkan beberapa derajat Kerja Breakdown Structure (WBS) untuk menangkap dan jadwal pekerjaan yang diperlukan untuk menyelesaikan proyek. WBS dan semua bahan program harus disimpan di bagian "Proyek Deskripsi" dari notebook proyek. Format WBS sebagian besar diserahkan kepada manajer proyek untuk membangun dengan cara yang paling tepat menggambarkan pekerjaan proyek. Ada beberapa bidang utama yang harus didefinisikan di WBS sebagai bagian dari kebijakan SDLC. Diagram berikut ini menjelaskan tiga bidang utama yang akan dibahas dalam WBS secara yang ditetapkan oleh manajer proyek. [7]
[Sunting] Karya kerusakan struktur organisasi
Breakdown Kerja Struktur. [7]

Bagian atas dari Struktur Perincian Kerja (WBS) harus mengidentifikasi fase utama dan tonggak dari proyek secara ringkasan. Selain itu, bagian atas harus memberikan gambaran cakupan penuh dan jadwal waktu proyek dan akan menjadi bagian dari upaya deskripsi proyek awal yang mengarah ke persetujuan proyek. Bagian tengah WBS didasarkan pada tujuh Pengembangan Sistem Life Cycle (SDLC) tahap sebagai panduan untuk pengembangan tugas WBS. Unsur-unsur WBS harus terdiri dari tonggak dan "tugas" sebagai lawan "kegiatan" dan memiliki jangka waktu yang pasti (biasanya dua minggu atau lebih). Setiap tugas harus memiliki output yang terukur (misalnya dokumen, keputusan, atau analisis). Tugas WBS dapat bergantung pada satu atau lebih kegiatan (misalnya rekayasa perangkat lunak, sistem rekayasa) dan mungkin memerlukan koordinasi erat dengan tugas-tugas lainnya, baik internal maupun eksternal untuk proyek. Setiap bagian dari proyek yang memerlukan dukungan dari kontraktor harus memiliki Pernyataan kerja (SOW) tertulis untuk menyertakan tugas-tugas yang sesuai dari fase SDLC. Pengembangan SOW tidak terjadi selama tahap tertentu SDLC tetapi dikembangkan untuk meliputi pekerjaan dari proses SDLC yang dapat dilakukan oleh sumber daya eksternal seperti kontraktor dan struct. [7]
[Sunting] baseline dalam SDLC

Baseline merupakan bagian penting dari Pengembangan Sistem Life Cycle (SDLC). Baseline ini ditetapkan setelah empat dari lima fase SDLC dan sangat penting untuk sifat iteratif model [8] Setiap awal dianggap sebagai tonggak dalam SDLC..

* Fungsional Baseline: didirikan setelah tahap desain konseptual.
* Alokasi Baseline: didirikan setelah tahap desain awal.
* Produk Baseline: didirikan setelah desain detail dan tahap pengembangan.
* Diperbarui Produk Baseline: didirikan setelah tahap konstruksi produksi.

[Edit] Tambahan untuk SDLC

Pelengkap metode pengembangan perangkat lunak untuk Pengembangan Sistem Life Cycle (SDLC) adalah:

* Perangkat Lunak Prototyping
* Bersama Aplikasi Desain (JAD)
* Pengembangan Aplikasi Cepat (RAD)
* Extreme Programming (XP); pengembangan dari pekerjaan sebelumnya di Prototyping dan RAD.
* Pengembangan Open Source
* End-user pengembangan
* Pemrograman Berorientasi Objek

Perbandingan Pendekatan Metodologi (Post, & Anderson 2006) [9] SDLC RAD Objek Open Source JAD Prototyping Pengguna Akhir
Kontrol formal MIS Standar Lemah Pengguna Pengguna Bersama
Waktu Pendek Panjang Menengah Frame Setiap Medium Short
Banyak pengguna Sedikit Sedikit Bervariasi Sedikit Satu atau Dua Satu
Staf MIS Ratusan Banyak Sedikit Split Sedikit Satu atau Dua Tidak ada
Transaksi Transaksi / DSS Baik Baik Baik DSS DSS DSS
Interface Minimal Windows Lemah Minimal Crucial Crucial Crucial
Dokumentasi dan pelatihan Vital Terbatas Internal Dalam Objek Limited Lemah Tidak ada
Integritas dan keamanan Vital Vital Unknown Dalam Objek Limited Lemah Lemah
Reusability Terbatas Beberapa Tidak Ada Mungkin Vital Lemah Terbatas
[Sunting] Kekuatan dan kelemahan

Hanya sedikit orang di dunia komputasi modern akan menggunakan model waterfall ketat untuk mereka Pengembangan Sistem Life Cycle (SDLC) sebagai metodologi modern telah digantikan pemikiran ini. Beberapa akan berpendapat bahwa SDLC tidak lagi berlaku untuk model seperti komputasi Agile, tetapi masih istilah yang secara luas digunakan di kalangan Teknologi. Praktek SDLC memiliki keunggulan dalam model pengembangan perangkat lunak tradisional, yang cocok untuk lingkungan yang lebih terstruktur. Kelemahan menggunakan metodologi SDLC adalah ketika ada kebutuhan untuk pengembangan iteratif atau (yakni pengembangan web atau e-commerce) dimana stakeholders harus meninjau secara rutin perangkat lunak yang akan dibuat. Daripada melihat SDLC dari perspektif kekuatan atau kelemahan, itu jauh lebih penting untuk mengambil praktek-praktek terbaik dari model SDLC dan menerapkannya ke apapun mungkin paling sesuai untuk perangkat lunak yang akan dibuat.

Suatu perbandingan kekuatan dan kelemahan dari SDLC:
Kekuatan dan Kelemahan dari SDLC [9] Kelemahan Kekuatan
Control. Peningkatan waktu pengembangan.
Monitor besar proyek. Peningkatan biaya pengembangan.
Detil langkah. Sistem harus didefinisikan di muka.
Mengevaluasi biaya dan target penyelesaian. Kekakuan.
Dokumentasi. Sulit untuk memperkirakan biaya, overruns proyek.
Terdefinisi dengan baik input pengguna. User input kadang-kadang terbatas.
Kemudahan pemeliharaan.
Pengembangan dan desain standar.
Mentolerir perubahan staf MIS.

Alternatif dari SDLC adalah Rapid Application Development, yang menggabungkan prototyping, Joint Application Development dan pelaksanaan CASE tools. Keuntungan dari RAD adalah kecepatan, biaya pengembangan berkurang, dan keterlibatan pengguna aktif dalam proses pembangunan.

Hendaknya tidak diasumsikan bahwa hanya karena model air terjun yang asli tertua SDLC model bahwa itu adalah sistem yang paling efisien. Pada suatu waktu model menguntungkan sebagian besar ke dunia otomatisasi kegiatan yang ditugaskan untuk panitera dan akuntan. Namun, dunia evolusi teknologi adalah menuntut [rujukan?] Bahwa sistem memiliki fungsi yang lebih besar yang akan membantu membantu teknisi meja / administrator atau spesialis informasi teknologi / analis.
[Sunting] Lihat pula

* Application Lifecycle Management

[Sunting] Referensi

1. ^ PEMILIHAN PENDEKATAN PENGEMBANGAN. Diakses 27 Oktober 2008.
2. ^ "Pengembangan Sistem Siklus Hidup". Dalam: Foldoc (2000/12/24)
3. ^ James Taylor (2004). Mengelola Proyek Teknologi Informasi. hal.39 ..
4. ^ Ab Geoffrey Elliott & Strachan Josh (2004) Bisnis Teknologi Informasi Global. p.87.
5. ^ Http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle
6. ^ A b US Department of Justice (2003). SUMBER INFORMASI MANAJEMEN Bab 1. Pendahuluan.
7. ^ A b c d e U. S. House of Representatives (1999). Pengembangan Sistem Siklus Hidup-Kebijakan. hal.13.
8. ^ Blanchard, BS, & Fabrycky, WJ (2006) Sistem rekayasa dan analisis (4th ed.) New Jersey: Prentice Hall. hal.31
9. ^ Post b, G., & Anderson, D., (2006). Manajemen sistem informasi: Penyelesaian masalah bisnis dengan teknologi informasi. (Ed 4.). New York: McGraw-Hill Irwin.

[Sunting] Bacaan lebih lanjut

* Blanchard, BS, & Fabrycky, WJ (2006) Sistem rekayasa dan analisis (4th ed.) New Jersey: Prentice Hall.
* Cummings, Haag (2006). Sistem Informasi Manajemen untuk Zaman Informasi. Toronto, McGraw-Hill Ryerson
* Beynon-Davies P. (2009). Sistem Informasi Bisnis. Palgrave, Basingstoke. ISBN 978-0-230-20368-6
* Komputer Dunia, 2002, Diakses pada tanggal 22 Juni 2006 dari World Wide Web:
* Manajemen Sistem Informasi, 2005, Diakses pada tanggal 22 Juni 2006 dari World Wide Web:
* Artikel ini awalnya berdasarkan bahan dari Free On-line Dictionary of Computing, yang dilisensikan di bawah GFDL.

[Sunting] Pranala luar
Wikimedia Commons memiliki kategori mengenai: Siklus Hidup Pengembangan Sistem

* US Department of Education - Siklus Hidup Manajemen Dokumen
* Pengembangan Sistem Lifecycle (SDLC) Review Dokumen G23 dari Sistem Informasi Audit and Control Association (ISACA)
* The Siklus Hidup Pengembangan Sistem Agile
* Software sebagai Service Application Service Provider Siklus Hidup Pengembangan Sistem
* Manfaat Pensiun Guaranty Corporation - Solusi Teknologi Informasi Metodologi Siklus Hidup
* Industri SDLC Interest Group
* Negara Maryland SDLC
* HHS Enterprise Kinerja Kerangka Life Cycle
* CMS Terpadu Investasi IT & Sistem Kerangka Kerja Siklus Hidup
* Koleksi Semua Model SDLC dalam Satu Tempat Dengan Sumber Daya Bagus Eksternal
* OpenSDLC.org