Hi. In this lecture we'll talk about different processes that we can use for software development. We will cover a different processes like waterfall model, code-and-fix, prototyping, spiral, phased-release, agile and unified process in this lecture. Notice that no matter which software development process that you use for your project eventually the process will contain to followings stages. Somehow you will need to get a requirements. Somehow you need to perform analysis and design and then come up with a design for the system and then eventually implement a system and finally the test a system. Different software development processes they mainly differ in how this stages are combined, emphasized, and it carried out. After you learn about all this software development processes, the most important thing that you should pick up is that you should understand the strengths and weaknesses of different software development processes. That given a particular scenario, given a particular situation, you know exactly which development process is suitable for that situation. The first model that we need to cover is what we call the waterfall model. For waterfall model, we first get all the requirements, then give all the requirements we try to perform analysis and design and then come up with a model that we can use for implementation. Then after that, we will go ahead and perform implementation and then after we finished implementation, we would perform testing to make sure that there's no defects within the software system. Then finally, we have to performing maintenance to maintain the system. We say that this is a waterfall model because we try to always go down. After we get all the requirement we perform analysis and design and implementation and then testing and then maintenance. From this model, you can see that we can go back but notice that if we want to go back, for example, when we find that the design is not correct because we have captured some incorrect requirements. You can always go back and fix all requirements and then come up with another model. But notice that this is going to be costly. That's why we call it a waterfall model because we want to always go down, not going back. That's why after you finish a particular phrase, for example, analysis and design, you have to always perform review to double-check that the design that you come up with is actually correct before you go into the next step. Because you know that going back is going to be costly. This model can only be applied when the requirements are well understood and also unlikely to change so that's why this is what we call a multi-discipline model. That's why not likely that we use waterfall model in the industry because very likely when we build a software system, changes are going to happen. It's unlikely that we can capture all the requirements and then freeze all the requirements and then we go to the next stage and then perform analysis and design because the requirements they may change from time to time. This are the pros and cons off waterfall process. The pros is that is disciplined. It keeps development predictable and also easy to monitor because you go from one state to another and then you try to avoid going back. Also enforces documentation standards and approval of documents before you proceed to the next stage. It fits well with other engineering process model, is not just for software engineering, if you have other kinds of engineering projects, you may also apply waterfall model. The cons is that you assume linear sequential development is possible. You try to avoid going back. Rigid assuming results of each phrase can be frozen before you move to another phase. Different languages in notations are often used in different phrases. Also make little provision or opportunity for use of feedback, which is a source of high risk. Because you assume that all the things down not going to change within the project. Now we're going to cover some iterative and incremental software development processes. The first one that we talk about is code-and-fix. This is usually the approach that we use in programming assignment. In your programming assignment, you will be given a set of requirements. Then based on that requirement, you're going to build something. If it's correct then you move on. If it's not correct, then you have to perform testing and you find that the software is not correct, then you have to go back and fix your implementation. That's why we call it code-and-fix. We code and then we perform testing. If there's something wrong, we fix it. If we are using this process, then very likely there will be many changes because when there's something wrong, we have to fix it. Very often the structure is going to be messy because you're going to put many worker ranks in your source code to make it work. It's not suitable for large systems because usually this is the approach that we use for programming assignment, but not for a large a subway system. If you're using this process then you make the process unpredictable and also uncontrollable and very likely, maybe over budget, over schedule, and also fails to meet expectations. Because you don't know exactly how many times that you have to fix before you can get the correct system. That's why this is the process that we should avoid. The next process that I'm going to talk about is what we call prototyping. For Prototyping, we try to get us some quick requirements and then come up with some quick design. Then we build a prototype and then involve the client to evaluate the prototype. Notice that the prototype is not the entire system it's not the full system. For example if we're building a web application, then we may simply be the UI of the application so that we can show the UI to the client and then get some further feedback about the system. Then we have to refine the prototype after we get the feedback from the client and we may have to also redesign the system after we get the feedback from the client. Then we build another prototype and then until we get the final product. Basically it's similar to code and fix, but now by using prototyping somehow we involve client evaluation and also enforces some discipline. It's useful when requirements are vague, when you don't know exactly what are the requirements, then you can simply come up with some quick design and to build a little prototype and then ask your client whether this prototype satisfy your requirements on that. If yes, then you further work on the prototype, if not, then you have to refine your design and then build another prototype. That's why it's very useful when requirements are vague, because you can collect more requirements from your client using the prototype. It allows exploration of functionality needed and also using the vagues. These are the pros and cons off prototyping. The pros state that you allow requirements to be quickly explored, and it allows user feedback and approval before we further refine the system, and also allow different solutions to be explored. But the cons, is that it's not really a complete sovereignty for the main process. The process is not visible, making progress hard to measure because you don't know exactly how many times that you have to refine the prototype before you get the final system. Documentation is often sparse or completely absent if we are using prototyping. Notice that the final product may not be the complete system because now we are talking about building a prototype and not a final system. The next process that I'm going to cover is what we call spiral. Notice that for spiral what's special is that we involve another phrase called risk analysis. What we're going to do is that we're going to perform some planning and then perform some risk analysis to foresee all the possible risks within the project. Then now after we get out all the risk, we decide to whether go or not go. If we decide to go then we implement the system, and then after that we involve client evaluation and that we plan the system and then get a risk again etc. This is what we call a spiral, because we have to go several rounds before we get to final system. Hopefully if we go around many times eventually it will go towards a completed system. The pros of spiral is that the risk evaluation can help reduce development problems, because we tried to foresee all the risk before you actually implement a system. Planning and client evaluation phases have the product better meets client expectations. Just because before you go for another run, you will always ask for clients feedback. Then iterative and incremental planning, engineering and evaluation facilitates project management. The cons is that you need some expert in the risk analysis phase to identify all the risks within the project. Also you need more elaboration of phases before you can get the final system. It's more appropriate for internal development rather than contract development, why? Because you know exactly what are the requirements if it's an internal system. Also it's easier to foresee all the risk because you know exactly what are the requirements. The next process that we would cover it uses what we call phase release process. Just because changes are likely to happen in the project, so that's why we have to plan for it. In phrase release, we try to release the system part by part, by releasing different builds of the system from time to time. Then we may further refine build number 1 and they get build number 2, and after build number 2 is completed, then we may release it to the users, etc. Releases are developed and used in parallel. Notice that the development may be incremental. That means we start with part of the system and then we build another part of the system, and then we build another part of the system until we get all the functionalities. Or it can be iterative, that mean we try to get the full system, but we make the system more and more sophisticated. Notice that many organizations, they use a combination of iterative and incremental approaches at the same time. These are the pros and cons of phase release. The pros is that it reduce the risk of project failure because at one time we're going to focus on just one part of the system. It promotes system modularity, and also allow frequent releases. Also allows appropriate expertise to be applied to a particular part of the system, and also allow early training and also use the feedback. But the cons are that the system pieces need to be relatively small, and it may be hard to identify common facilities needed by all pieces. In our pictures, we assume that the parts they are separated. But in reality, for a likely there would be some sharing or some common facilities needed by all the parts. That's why we need to identify that part, because that part is going to be critical, that part is going to be shared by all the other parts.
