The first published model of the software development process was derived from more general system engineering processes (Royce, 1970). This model is illustrated in Figure 2.1. Because of the cascade from one phase to another, this model is known as the ‘waterfall model’ or software life cycle. The waterfall model is an example of a plan-driven process—in principle, you must plan and schedule all of the process activities before starting work on them.
The principal stages of the waterfall model directly reflect the fundamental development activities:
1. Requirements analysis and definition The system’s services, constraints, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification.
2. System and software design The systems design process allocates the requirements to either hardware or software systems by establishing an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships.
3. Implementation and unit testing During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.
4. Integration and system testing The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to
5. Operation and maintenance Normally (although not necessarily), this is the longest life cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier
stages of the life cycle, improving the implementation of system units and enhancing the system’s services as new requirements are discovered.
In principle, the result of each phase is one or more documents that are approved (‘signed off’). The following phase should not start until the previous phase has finished. In practice, these stages overlap and feed information to each other. During design, problems with requirements are identified. During coding, design problems are found and so on. The software process is not a simple linear model but involves feedback from one phase to another. Documents produced in each phase may then have to be modified to reflect the changes made.
Because of the costs of producing and approving documents, iterations can be costly and involve significant rework. Therefore, after a small number of iterations, it is normal to freeze parts of the development, such as the specification, and to continue with the later development stages. Problems are left for later resolution, ignored, or programmed around. This premature freezing of requirements may mean that the system won’t do what the user wants. It may also lead to badly structured systems as design problems are circumvented by implementation tricks.
During the final life cycle phase (operation and maintenance) the software is put into use. Errors and omissions in the original software requirements are discovered. Program and design errors emerge and the need for new functionality is identified. The system must therefore evolve to remain useful. Making these changes (software maintenance) may involve repeating previous process stages.
The waterfall model is consistent with other engineering process models and documentation is produced at each phase. This makes the process visible so managers can monitor progress against the development plan. Its major problem is the inflexible partitioning of the project into distinct stages. Commitments must be made at an early stage in the process, which makes it difficult to respond to changing customer requirements.
In principle, the waterfall model should only be used when the requirements are well understood and unlikely to change radically during system development. However, the waterfall model reflects the type of process used in other engineering projects. As is easier to use a common management model for the whole project, software processes based on the waterfall model are still commonly used.
An important variant of the waterfall model is formal system development, where a mathematical model of a system specification is created. This model is then refined, using mathematical transformations that preserve its consistency, into executable code. Based on the assumption that your mathematical transformations are correct, you can therefore make a strong argument that a program generated in this way is consistent with its specification.
Formal development processes, such as that based on the B method (Schneider, 2001; Wordsworth, 1996) are particularly suited to the development of systems that have stringent safety, reliability, or security requirements. The formal approach simplifies the production of a safety or security case. This demonstrates to customers or regulators that the system actually meets its safety or security requirements.
Processes based on formal transformations are generally only used in the development of safety-critical or security critical systems. They require specialized expertise. For the majority of systems this process does not offer significant costbenefits over other approaches to system development
A software process model is a simplified representation of a software process. Each process model represents a process from a particular perspective, and thus provides only partial information about that process. For example, a process activity model shows the activities and their sequence but may not show the roles of the people involved in these activities. In this section, I introduce a number of very general process models (sometimes called ‘process paradigms’) and present these from an architectural perspective. That is, we see the framework of the process but not the details of specific activities.
These generic models are not definitive descriptions of software processes. Rather, they are abstractions of the process that can be used to explain different approaches to software development. You can think of them as process frameworks that may be extended and adapted to create more specific software engineering processes.
The process models that I cover here are:
1. The waterfall model This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on.
Figure 2.1 The waterfall model
2. Incremental development This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.
3. Reuse-oriented software engineering This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch.
These models are not mutually exclusive and are often used together, especially for large systems development. For large systems, it makes sense to combine some of the best features of the waterfall and the incremental development models. You need to have information about the essential system requirements to design a software architecture to support these requirements. You cannot develop this incrementally. Sub-systems within a larger system may be developed using different approaches. Parts of the system that are well understood can be specified and developed using a waterfall-based process. Parts of the system which are difficult to specify in advance, such as the user interface, should always be developed using an incremental approach
The development of the World Wide Web has had a profound effect on all of our lives. Initially, the Web was primarily a universally accessible information store and it had little effect on software systems. These systems ran on local computers and were only accessible from within an organization. Around 2000, the Web started to evolve and more and more functionality was added to browsers. This meant that web-based systems could be developed where, instead of a special-purpose user interface, these systems could be accessed using a web browser. This led to the development of a vast range of new system products that delivered innovative services, accessed over the Web. These are often funded by adverts that are displayed on the user’s screen and do not involve direct payment from users.
As well as these system products, the development of web browsers that could run small programs and do some local processing led to an evolution in business and organizational software. Instead of writing software and deploying it on users’ PCs, the software was deployed on a web server. This made it much cheaper to change and upgrade the software, as there was no need to install the software on every PC. It also reduced costs, as user interface development is particularly expensive. Consequently, wherever it has been possible to do so, many businesses have moved to web-based interaction with company software systems.
The next stage in the development of web-based systems was the notion of web services. Web services are software components that deliver specific, useful functionality and which are accessed over the Web. Applications are constructed by integrating these web services, which may be provided by different companies. In principle, this
linking can be dynamic so that an application may use different web services each time that it is executed. I cover this approach to software development in Chapter 19.
In the last few years, the notion of ‘software as a service’ has been developed. It has been proposed that software will not normally run on local computers but will run on ‘computing clouds’ that are accessed over the Internet. If you use a service such as web-based mail, you are using a cloud-based system. A computing cloud is a huge number of linked computer systems that is shared by many users. Users do not buy software but pay according to how much the software is used or are given free access in return for watching adverts that are displayed on their screen.
The advent of the web, therefore, has led to a significant change in the way that business software is organized. Before the web, business applications were mostly monolithic, single programs running on single computers or computer clusters. Communications were local, within an organization. Now, software is highly distributed, sometimes across the world. Business applications are not programmed from scratch but involve extensive reuse of components and programs.
This radical change in software organization has, obviously, led to changes in the ways that web-based systems are engineered. For example:
- Software reuse has become the dominant approach for constructing web-based systems. When building these systems, you think about how you can assemble them from pre-existing software components and systems.
- It is now generally recognized that it is impractical to specify all the requirements for such systems in advance. Web-based systems should be developed and delivered incrementally.
- User interfaces are constrained by the capabilities of web browsers. Although technologies such as AJAX (Holdener, 2008) mean that rich interfaces can be created within a web browser, these technologies are still difficult to use. Web forms with local scripting are more commonly used. Application interfaces on web-based systems are often poorer than the specially designed user interfaces on PC system products.
The fundamental ideas of software engineering, discussed in the previous section, apply to web-based software in the same way that they apply to other types of software system. Experience gained with large system development in the 20th century is still relevant to web-based software.
Software engineering is a systematic approach to the production of software that takes into account practical cost, schedule, and dependability issues, as well as the needs of software customers and producers. How this systematic approach is actually implemented varies dramatically depending on the organization developing the software, the type of software, and the people involved in the development process. There are no universal software engineering methods and techniques that are suitable for all systems and all companies. Rather, a diverse set of software engineering methods and tools has evolved over the past 50 years.
Perhaps the most significant factor in determining which software engineering methods and techniques are most important is the type of application that is being developed. There are many different types of application including:
1. Stand-alone applications These are application systems that run on a local computer, such as a PC. They include all necessary functionality and do not need to be connected to a network. Examples of such applications are office applications on a PC, CAD programs, photo manipulation software, etc.
2. Interactive transaction-based applications These are applications that execute on a remote computer and that are accessed by users from their own PCs or terminals. Obviously, these include web applications such as e-commerce applications where you can interact with a remote system to buy goods and services. This class of application also includes business systems, where a business provides access to its systems through a web browser or special-purpose client program and cloud-based services, such as mail and photo sharing. Interactive applications often incorporate a large data store that is accessed and updated in each transaction.
3. Embedded control systems These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded systems than any other type of system. Examples of embedded systems include the software in a mobile (cell) phone, software that controls anti-lock braking in a
car, and software in a microwave oven to control the cooking process.
4. Batch processing systems These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs. Examples of batch systems include periodic billing systems, such as phone billing systems, and salary payment systems.
5. Entertainment systems These are systems that are primarily for personal use and which are intended to entertain the user. Most of these systems are games of one kind or another. The quality of the user interaction offered is the most important distinguishing characteristic of entertainment systems.
6. Systems for modeling and simulation These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects. These are often computationally
intensive and require high-performance parallel systems for execution.
7. Data collection systems These are systems that collect data from their environment using a set of sensors and send that data to other systems for processing. The software has to interact with sensors and often is installed in a hostile environment such as inside an engine or in a remote location.
8. Systems of systems These are systems that are composed of a number of other software systems. Some of these may be generic software products, such as a spreadsheet program. Other systems in the assembly may be specially written for that environment.
Of course, the boundaries between these system types are blurred. If you develop a game for a mobile (cell) phone, you have to take into account the same constraints (power, hardware interaction) as the developers of the phone software. Batch processing systems are often used in conjunction with web-based systems. For example, in a company, travel expense claims may be submitted through a web application but processed in a batch application for monthly payment.
You use different software engineering techniques for each type of system because the software has quite different characteristics. For example, an embedded control system in an automobile is safety-critical and is burned into ROM when installed in the vehicle. It is therefore very expensive to change. Such a system needs very extensive verification and validation so that the chances of having to recall cars after sale to fix software problems are minimized. User interaction is minimal (or perhaps nonexistent) so there is no need to use a development process that relies on
user interface prototyping.
For a web-based system, an approach based on iterative development and delivery may be appropriate, with the system being composed of reusable components. However, such an approach may be impractical for a system of systems, where detailed specifications of the system interactions have to be specified in advance so that each system can be separately developed. Nevertheless, there are software engineering fundamentals that apply to all types
of software system:
1. They should be developed using a managed and understood development process. The organization developing the software should plan the development process and have clear ideas of what will be produced and when it will be completed. Of course, different processes are used for different types of software.
2. Dependability and performance are important for all types of systems. Software should behave as expected, without failures and should be available for use when it is required. It should be safe in its operation and, as far as possible, should be secure against external attack. The system should perform efficiently and should not waste resources.
3. Understanding and managing the software specification and requirements (what the software should do) are important. You have to know what different customers and users of the system expect from it and you have to manage their expectations so that a useful system can be delivered within budget and to schedule.
4. You should make as effective use as possible of existing resources. This means that, where appropriate, you should reuse software that has already been developed rather than write new software.
These fundamental notions of process, dependability, requirements, management, and reuse are important themes of this book. Different methods reflect them in different ways but they underlie all professional software development. You should notice that these fundamentals do not cover implementation and programming. I don’t cover specific programming techniques in this book because these vary dramatically from one type of system to another. For example, a scripting language such as Ruby is used for web-based system programming but would be completely inappropriate for embedded systems engineering.
Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. In this definition, there are two key phrases:
1. Engineering discipline Engineers make things work. They apply theories, methods, and tools where these are appropriate. However, they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods. Engineers also recognize that they must work to organizational and financial constraints so they look for solutions within these constraints.
2. All aspects of software production. Software engineering is not just concerned with the technical processes of software development. It also includes activities such as software project management and the development of tools, methods, and theories to support software production. Engineering is about getting results of the required quality within the schedule and budget. This often involves making compromises—engineers cannot be perfectionists. People writing programs for themselves, however, can spend as much time as they wish on the program development.
In general, software engineers adopt a systematic and organized approach to their work, as this is often the most effective way to produce high-quality software. However, engineering is all about selecting the most appropriate method for a set of circumstances so a more creative, less formal approach to development may be effective in some circumstances. Less formal development is particularly appropriate for the development of web-based systems, which requires a blend of software and graphical design skills.
Software engineering is important for two reasons:
1. More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly
2. It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of systems, the majority of costs are the costs of changing the software after it has gone into use.
The systematic approach that is used in software engineering is sometimes called a software process. A software process is a sequence of activities that leads to the production of a software product. There are four fundamental activities that are common to all software processes. These activities are:
1. Software specification, where customers and engineers define the software that is to be produced and the constraints on its operation.
2. Software development, where the software is designed and programmed.
3. Software validation, where the software is checked to ensure that it is what the customer requires.
4. Software evolution, where the software is modified to reflect changing customer and market requirements. Different types of systems need different development processes. For example, real-time software in an aircraft has to be completely specified before development begins. In e-commerce systems, the specification and the program are usually developed together. Consequently, these generic activities may be organized in different ways and described at different levels of detail depending on the type of software being developed.
Software engineering is related to both computer science and systems engineering:
1. Computer science is concerned with the theories and methods that underlie computers and software systems, whereas software engineering is concerned with the practical problems of producing software. Some knowledge of computer science is essential for software engineers in the same way that some knowledge of physics is essential for electrical engineers. Computer science theory, however, is often most applicable to relatively small programs. Elegant theories of computer science cannot always be applied to large, complex problems that require a software solution.
2. System engineering is concerned with all aspects of the development and evolution of complex systems where software plays a major role. System engineering is therefore concerned with hardware development, policy and process design and system deployment, as well as software engineering. System engineers are involved in specifying the system, defining its overall architecture, and then integrating the different parts to create the finished system. They are less concerned with the engineering of the system components (hardware, software, etc.).
There are three general issues that affect many different types of software:
1. Heterogeneity. Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices. As well as running on general-purpose computers, software may also have to execute on mobile phones. You often have to integrate new software with older legacy systems written in different programming languages. The challenge here is to develop techniques for building dependable software that is flexible enough to cope with this heterogeneity.
2. Business and social change. Business and society are changing incredibly quickly as emerging economies develop and new technologies become available. They need to be able to change their existing software and to rapidly develop new software. Many traditional software engineering techniques are time consuming and delivery of new systems often takes longer than planned. They need to evolve so that the time required for software to deliver value to its customers is reduced.
3. Security and trust. As software is intertwined with all aspects of our lives, it is essential that we can trust that software. This is especially true for remote software systems accessed through a web page or web service interface. We have to make sure that malicious users cannot attack our software and that information
security is maintained. Of course, these are not independent issues. For example, it may be necessary to make rapid changes to a legacy system to provide it with a web service interface. To address these challenges we will need new tools and techniques as well as innovative ways of combining and using existing software engineering methods.
Design Pattern merupakan solusi yang dapat digunakan secara berulang kali untuk menyelesaikan permasalahan umum yang ditemukan dalam pemrograman dan design perangkat lunak. Pattern adalah cara mendesain kelas dan cara interaksi yang terjadi antar kelas tersebut sehingga kelas yang dibangun dapat menjadi lebih elegan dan reusable (dapat digunakan berulang kali).
Terdapat Klasifikasi Pattern yang terbagi menjadi 3 kategori, yaitu
1. Creational, yaitu pattern yang berhubungan dengan inisialisasi dan konfigurasi kelas dan objek. Pattern yang termasuk kategori ini antara lain :
- Factory Method
- Abstract Factory
2. Structural, yaitu pattern yang berhubungan dengan decoupling interface dan implementasi kelas dan objek. Pattern yang termasuk kategori ini antara lain :
3. Behavioral, yaitu pattern yang berhubungan dengan interaksi dinamis antara kelas dengan objek. Pattern yang termasuk kategori ini antara lain :
- Chain of Responsibility
- Template Method
Gambar 1 : Tahapan Model LSM
Linear Sequential Model atau disebut juga waterfall model adalah model klasik dalam pembuatan software engineering. Model ini pertama kali diperkenalkan oleh Winston Royce pada tahun 1970. Model ini sering disebut dengan classic life cycle. Model ini menggunakan pendekatan yang berurutan dan sistematis sehingga proses pengerjaannya haruslah langkah demi langkah dan harus menunggu selesainya tahap sebelumnya.
Karakteristik yang ada pada model waterfall ini adalah proses pengembangan software akan dilakukan dengan cara berurutan (sequential) yang diawali dari proses perencanaan, pemodelan, konstruksi software , lalu penyerahan kepada client(user). Namun ada beberapa masalah yang muncul dari waterfall model ini, yaitu jika terjadi kesalahan maka proses tidak akan berlanjut ke tahap selanjutnya sampai kesalahan yang terjadi telah dibenahi dengan baik. model ini juga menjadi dasar atas terbentuknya model-model yang lain.
Dalam waterfall model terdapat tahapan-tahapan proses yang akan dilalui yaitu :
- Requirements definition (komunikasi & pemodelan)
Pada tahap ini akan dilakukan komunikasi terhadap client (user) untuk mendapatkan requirment yang dibutuhkan oleh client. Setelah itu requirement akan dianalisis dan dimasukkan ke dalam software.
- System and software design (pemodelan)
Pada tahap ini software akan mulai didesain sesuai dengan requirement yang telah didapatkan. Pada tahap ini juga akan dibentuk sebuah arsitektur software serta fungsi dan sistem yang siap ditransformasikan ke dalam sebuah program.
- Implementation and unit testing (konstruksi)
Tahap ini konstruksi software akan dimulai, namun akan dipisahkan berdasarkan unit-unit tertentu. Semua yang telah didesain dalam tahap pemodelan akan diterapkan pada tahap ini.
- System testing ( test program )
Tahap ini software yang telah dibuat pada tahap implementation and unit testing akan disatukan seluruhnya menjadi satu software utuh dan kemudian di coba sebelum diberikan kepada client. Apabila tidak ada error yang terjadi atau tidak ditemukannya bug dalam software, maka software siap untuk diberikan kepada client.
- Penyerahan software ke client
Setelah tahap system testing selesai maka software akan langsung diberikan kepada client.
- Operation and maintanance
Diantara semua tahap yang ada, tahap ini adalah tahap paling lama memakan waktu, sebab pada tahap ini client akan menambahkan masukan-masukan yang diperlukan untuk meningkatkan software sesuai dengan kebutuhan client.
Kelebihan dan kekurangan :
- Kelebihan :
- Setiap anggota yang mengerjakan software menggunakan model waterfall ini telah mengetahui dengan jelas apa yang harus dikerjakan dan waktu penyelesaiannya.
- Dokumentasi sangat teratur, sebab dalam pengerjaannya tidak akan melangkah ke tahap selanjutnya jika tahap sebelumnya belum diselesaikan.
- Merupakan model pengembangan paling handal dan paling lama digunakan.
- Cocok untuk system software berskala besar.
- Cocok untuk system software yang bersifat generic.
- Kekurangan :
- Sistem ini sangat tidak dinamis, karena jika ada perubahan maka harus diulang dari tahap awal.
- Model ini memakan waktu yang lama
- Jika terjadi kesalahan yang fatal dalam proses pengerjaan maka akan mempengaruhi seluruh proses pengembangan software.
- Persyaratan system harus digambarkan dengan jelas.
- Rincian proses harus benar-benar jelas dan tidak boleh berubah-ubah.
Metode ini menyajikan gambaran yang lengkap dari sistem, yang terdiri atas model kertas, model kerja serta program. Pihak pengembang akan melakukan identifikasi kebutuhan pemakai, menganalisa sistem dan melakukan studi kelayakan serta studi terhadap kebutuhan pemakai, meliputi model interface, teknik prosedural dan teknologi yang akan dimanfaatkan.
Gambar 1 : Tahapan Prototype Model
Ciri khas dari metodologi ini adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.
Proses-proses dalam model prototyping secara umum adalah sebagai berikut:
- Pengumpulan kebutuhan
Developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya.
Perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.
- Evaluasi Prototype
Klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.
Tahapan-tahapan dalam prototyping tersebut adalah sebagai berikut :
- Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format dan kebutuhan kesseluruhan perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
- Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berpusat pada penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya).
- Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil. Jika tidak, maka prototyping diperbaiki dengan mengulang langkah 1, 2 , dan 3.
- Mengkodekan system
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.
- Menguji system
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.
- Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi langkah 4 dan 5.
- Menggunakan system
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan
- Komunikasi akan terjalin baik antara pengembang dan pelanggan.
- Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan setiap pelanggannya.
- Pelanggan berperan aktif dalam proses pengembangan sistem.
- Lebih menghemat waktu dalam pengembangan sistem.
- Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya
- Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu lama.
- Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan sebuah kerangka kerja (blueprint) dari sistem .
- Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik dan benar.
Dalam setiap metode mempunyai kelebihan maupun kekurangan, namun kekurangan tersebut dapat diminimalisir yaitu dengan mengetahui kunci dari model prototype tersebut. Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan kebutuhan.
The software development paradigm helps developer to select a strategy to develop the software. A software development paradigm has its own set of tools, methods and procedures, which are expressed clearly and defines software development life cycle. A few of software development paradigms or process models are defined as follows:
Waterfall model is the simplest model of software development paradigm. It says the all the phases of SDLC will function one after another in linear manner. That is, when the first phase is finished then only the second phase will start and so on.
This model assumes that everything is carried out and taken place perfectly as planned in the previous stage and there is no need to think about the past issues that may arise in the next phase. This model does not work smoothly if there are some issues left at the previous step. The sequential nature of model does not allow us go back and undo or redo our actions.
This model is best suited when developers already have designed and developed similar software in the past and are aware of all its domains.
This model leads the software development process in iterations. It projects the process of development in cyclic manner repeating every step after every cycle of SDLC process.
The software is first developed on very small scale and all the steps are followed which are taken into consideration. Then, on every next iteration, more features and modules are designed, coded, tested and added to the software. Every cycle produces a software, which is complete in itself and has more features and capabilities than that of the previous one.
After each iteration, the management team can do work on risk management and prepare for the next iteration. Because a cycle includes small portion of whole software process, it is easier to manage the development process but it consumes more resources.
Spiral model is a combination of both, iterative model and one of the SDLC model. It can be seen as if you choose one SDLC model and combine it with cyclic process (iterative model).
This model considers risk, which often goes un-noticed by most other models. The model starts with determining objectives and constraints of the software at the start of one iteration. Next phase is of prototyping the software. This includes risk analysis. Then one standard SDLC model is used to build the software. In the fourth phase of the plan of next iteration is prepared.
V – model
The major drawback of waterfall model is we move to the next stage only when the previous one is finished and there was no chance to go back if something is found wrong in later stages. V-Model provides means of testing of software at each stage in reverse manner.
At every stage, test plans and test cases are created to verify and validate the product according to the requirement of that stage. For example, in requirement gathering stage the test team prepares all the test cases in correspondence to the requirements. Later, when the product is developed and is ready for testing, test cases of this stage verify the software against its validity towards requirements at this stage.
This makes both verification and validation go in parallel. This model is also known as verification and validation model.
Big Bang Model
This model is the simplest model in its form. It requires little planning, lots of programming and lots of funds. This model is conceptualized around the big bang of universe. As scientists say that after big bang lots of galaxies, planets and stars evolved just as an event. Likewise, if we put together lots of programming and funds, you may achieve the best software product.
For this model, very small amount of planning is required. It does not follow any process, or at times the customer is not sure about the requirements and future needs. So the input requirements are arbitrary.
This model is not suitable for large software projects but good one for learning and experimenting.
CASE (Computer Aided Software Engineering) adalah domain dari perangkat lunak yang digunakan untuk merancang dan mengimplementasikan aplikasi. CASE tools mirip dan terinspirasi oleh CAD yang digunakan untuk merancang produk hardware. CASE tools digunakan untuk mengembangkan perangkat lunak yang berkualitas tinggi, bebas cacat, dan terpelihara. Software CASE sering dikaitkan dengan metode untuk pengembangan sistem informasi bersama-sama dengan alat otomatis yang dapat digunakan dalam proses pengembangan perangkat lunak.
CASE tools memperbesar kemungkinan otomatisasi pada setiap fase life-cycle software. CASE tools sangat membantu dalam meningkatkan kualitas design model suatu software sebelum software itu dibangun/dikembangkan, baik itu untuk software yang dibangun dengan simpel maupun complex environment.
CASE tools dibagi menjadi beberapa kategori:
- Information engineering-supporting products. Ada beberapa proses dari life-cycle, yang dihasilkan dari rencana strategis dari perusahaan dan yang menyediakan suatu repository untuk membuat dan memelihara enterprise models, data models dan process models.
- Structured diagramming-supporting products. Produk ini sangat mendukung dalam memodelkan data flow, control flow dan entity flow.
- Structured development aids-providing products. Merupakan produk yang cocok digunakan oleh sistem analis, karena didukung oleh suatu proses terstruktur sehingga penganalisaan lebih cepat dan akurat.
- Application-code-generating products. Produk ini mampu menghasilkan application-code untuk tujuan tertentu yang telah ditetapkan oleh designer.
CASE tools diklasifikasikan sebagai berikut:
- Upper CASE. CASE tools yang didesain untuk mendukung perencanaan, identifikasi, dan seleksi proyek (permulaan dari perencanaan proyek), tepatnya pada fase analisis dan desain dari suatu system development life cycle (SDLC). Tools yang termasuk kelas ini adalah jenis Diagramming tools, Form and report generators, dan Analysis tools. Contoh CASE tools: Cradle, PRO-IV Workbench, ProKit*WORKBENCH.
- Lower CASE. CASE tools yang didesain untuk mendukung tahap implementasi dan maintenance dari SDLC. Tools yang termasuk kelas ini adalah jenis Code generators. Contoh CASE tools: Level/l-User Sensitive CASE, PRO-IV application Development.
- Cross life-cycle CASE/Integrated CASE (I-CASE). CASE tools yang dirancang untuk mendukung aktifikas-aktifitas yang terjadi pada beberapa fase dari SDLC. Mengkombinasikan Upper dan Lower CASE menjadi satu. Tools yang termasuk kelas ini adalah jenis Project management tools. Contoh CASE tools: Rational Rose, Poseidon, ArgoUML, Catalyze, in-Step, Juggler, PRINCE.
CASE tools dapat digunakan ketika:
- Meningkatnya permintaan pasar akan software, sehingga dibutuhkan tools untuk mempercepat pembuatan software, agar mengimbangi permintaan pasar tersebut.
- Perkembangan teknologi yang semakin cepat menyebabkan client menuntut software engineer untuk memperbaharui software yang sudah ada atau membangun software baru yang memiliki spesifikasi lebih kompleks.
CASE tools digunakan dalam semua aktifitas software engineer, termasuk dalam proses analisis, desain, implementasi, instalasi bahkan maintenance, baik pada lingkungan yang sederhana sampai yang kompleks yang mencakup: database, people, hardware, network, operating system.
Dalam menggunakan suatu CASE tools, ada beberapa tahapan yang harus dilakukan terlebih dahulu. Diantaranya:
- Lakukan studi terhadap teknologi yang ada agar kita bisa mempersiapkan dampak perubahan teknologi yang akan terjadi nantinya, sehingga model yang dibangun nantinya bisa fleksibel terhadap perubahan.
- Evaluasi bagaimana jika organisasi yang sudah ada harus dibangun ulang agar bisa mengambil keuntungan dari teknologi baru.
- Tetapkan suatu ketentuan untuk mengganti sistem yang lama dengan teknologi baru yang paling efektif.
- Tentukan suatu metodologi pembangunan sistem.