Principles of Software Engg. free essay sample

University of Ballarat GRADUATE SCHOOL OF INFORMATION TECHNOLOGY AND MATHEMATICAL SCIENCES ITECH6501 Principles of Software Engineering Name: Abdulhadi Zawi (30088958) Individual Assignment 20 marks – refer to Course Description for weighting Semester 2011/05 Report Due Date: Refer to course description In this first assignment, TWO software development methodologies will be examined using the first four laws given in the prescribed text. Glass’ law Requirement deficiencies are the prime source of project failures. LI) Boehm’s first law Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed. (L2) Boehm’s second law Prototyping (significantly) reduces requirement and design errors, especially for user interfaces. (L3) Davis’ law The value of a model depends on the view taken, but none is best for all purposes. (L4) The first software development methodology will be the Waterfall M odel, the second software methodology will be one of either Agile Methodology or the Rational Unified Process (RUP or UP). For both the software development methodologies do the following: 1. Describe each law in your own words. Illustrate with a practical example. [2 + 2 = 4 marks] Waterfall Model: Glass’ law: Requirements are the basic and fundamental source of input to the Waterfall Model. Requirement deficiencies in the beginning of the project will lead to a low quality design of the software and that low quality of the design will lead to a low quality software product at the end. If a crucial requirement is not captured in requirements gathering phase or a wrong requirement is captured then it leads to customer dissatisfaction, and eventually the project will fail. Boehm’s first law: The requirements gathering phase in Waterfall Model is more prone to errors and most of the times major errors in the end product are originated from the requirements and analysis phases of the software development life cycle. This is because of the customer are most of the times non technical and they can not describe their requirements in very well formed manner. Also, the requirements gathering teams are not familiar with the domain customer is working in, so there is a huge chance of misunderstanding the requirements or missing out some crucial ones. If some error occurs in the requirements gathering phase it will lead to a wrong design and that wrong design will lead to a product with deficiencies. If we need to remove those errors after completing all the waterfall phases then we need to capture the requirements again, change the whole product design based on the new requirements, develop the software and test it again. It will definitely increase the cost of developing those requirements with a lot of rework, as compared to if they were captured correctly at the first place. Boehm’s second law: Prototyping is a good method of removing some errors at the very early stage of software development. With a prototype a customer can easily visualize what will be the final product and the developers also get the requirements clarified by the customers. The prototypes are the GUIs with none or very limited functionality to help customers tell if some critical aspect of the end system is missing. They also help the developers in designing robust software in the early stages of the development cycle. As an example if a user thinks that he will select from the dropdown list the names of the cities or the developer thinks that the user will enter the city name in the text box, it can be clarified easily with the help of a simple prototype. Davis’ law: Models are designed to have a better understanding of the existing systems, and for the systems to be developed. The importance of a model is based on the time when it is developed and for the purpose it serves. A very high level model can be developed to show the customer how the end product will work with other existing systems or a detailed entity relationship model can be used to design the database. The models are effective but if and only if they are used in the proper perspective there is no one model that can serve at different levels of understanding. Agile Methodology: Glass’ law: Requirements are the driving factor in customer satisfaction, which leads to the successful projects. If the customer is not satisfied with the requirements they had in their mind and the product they get at the end, then the project is definitely going towards failure. The Agile software development methodology is heavily based on frequent communication and collaboration of development teams and the customer. This frequent communication helps the teams and the customer to find out if something is missing or something is not required as and when it is developed. This is the main reason that we have higher success ratios in Agile software development projects. Boehm’s first law: To remove errors in the later stages of development is more costly because a lot of rework is required. It is much easy to correct them as soon as they are identified. The Agile software development methodology helps in getting user feedback after every iteration. In each iteration a small portion of software is delivered and user can easily identify any issues with that and if there are any errors they can be removed before any further development is carried out. Boehm’s second law: In Agile software development, each iteration acts as a prototype of the actual system, and hence user can easily identify the potential problems in the early stage of development. The initial prototype of the system helps the development teams identify the initial set of requirements to start working with. They develop the prototype to capture the requirements and then in each iteration a small number of new requirements are developed and delivered to the customer to get their feedback. If there is a problem in the interface the customer sees it as soon as a new iteration is completed and can easily get it corrected. Davis’ law: In Agile software development methodology the importance is put on the working software delivered to the customer and all the activities revolve around this. The models are made just to understand and communicate some concepts about the software to be developed. These models can be detailed enough to expand the whole wall of an office or it can be a simple diagram to tell other developers how one has tackled some specific problem. The purpose remains the same; i. e. to help understand and build the system. Any level of model can not be a substitute for everything. There is no â€Å"One size fits all†. . Your first task is to describe each software development methodology clearly and completely in your own words. You may use diagrams, examples or UML to help you do this. [2 + 2 = 4 marks] Waterfall Model: The main idea of waterfall model is to develop software phase by phase. There are different phases of software development namely Requirements gathering, an alysis and design, development, testing and deployment. In waterfall model, software engineers collect requirements and try to make sure that each and every requirement is captured and documented in the requirements document. Once the requirements phase is completed the requirements document is fed to the analysis and design phase. Based on the details given in requirements document, the design of the software is developed and documented. Once a design is made for the software to be developed, it is given to the developers/programmers to code according to the design. They create the software by coding whatever is present in the system design given to them. When the software is ready, it is tested against the requirements document and if all the requirements are met (which are stated in the requirements document) then the software is delivered to the customer. An important thing to note here is that there is no feedback loop in each phase. We can not go to requirements phase from the design phase or from the coding phase. The only way to go is to go down the phases one by one. There can be no activities in parallel in two different phases. Agile Methodology: Agile software development is a new method of developing software. It is iterative and incremental in nature. The main concept is based on early delivery of working software in frequent cycles. The high level requirements are captured from the customer. Customer then prioritizes them and the development team plans for development of high value requirements first in the first cycle. The development team gets more details about the requirements to be developed from the customer. They develop and test that piece of software, then deliver it to the customer, and iteration completes here. At the beginning of next iteration the customer gives the feedback and prioritizes the remaining requirements and the same cycle is repeated again. This loop goes on until the customer is satisfied with the software they have and there are no more requirements from the customer. . Using the first four laws of the text, show where these are either implemented or missing in each software development methodology (Total Two). If a law is missing, explain the consequences and suggest how the process might be improved. [4 + 4 = 8 marks] Waterfall Model: Glass’ Law: Waterfall model is based on the assumption that each and every requirement is captured i n first phase of development life cycle. Glass’ law can not be implemented easily in Waterfall model of development. Rather it can be observed and can be verified with a lot of failed projects that followed the waterfall development model. The inherent nature of waterfall model does not allow to modify the requirements document once the requirements phase is over. The communication with the customer (for requirements) is reduced to nothing and hence there is no chance of having a requirement change communicated to the development teams. If we have communication channel open with the customer throughout the development cycle of the software we can utilize the Glass’ law in reducing the chances of failure because of requirements errors. Boehm’s Law: Waterfall model does not cater this law also. If there are any errors in the requirements phase they are only rectified in the internal testing phase or in the user acceptance testing phase. But if an error is identified at those stages, we need to go back to the requirements and design phases to start working over it once again. Hence the cost of rework is very high. Also the requirements defects cause the ripple effects in other requirements and hence more work is often required to just correct a small problem. There is only one way removing requirements errors in waterfall model, i. e. o have prototyping and a flexible attitude towards changing requirements. Boehm’s 2nd Law: As mentioned above, prototyping is one of the best practices that can be used to minimize the requirements errors early in the life cycle. In waterfall model, in requirements gathering phase if we collect requirements with the help of a prototype then it will be really easy to identify some of the errors, specially the user interface errors. The pr ototypes can be developed quickly and hence they are good in reducing the cost of correcting some requirement errors down the track. Agile Software Development: Glass’ law: In agile software development Glass’ law is taken as the basis for all the activities. As the agile manifesto suggests that they value working software over comprehensive documentation. The definition of working software comes from the customer. The customer decides which requirement is critical for the working of the software through out the development cycle, so the development team delivers the parts of the software which are ‘working’ from the customer’s point of view. Since the requirements are set and prioritized by the customer, and the customer has the opportunity to have a feel of what’s going right or wrong from the beginning, the overall requirements contains lesser number of errors and hence the final product will have higher success rate. Boehm’s law: In agile software development the total duration of an error to occur in requirements and to be developed is only limited by the duration of iteration. If there is any misunderstanding or ambiguity in the requirement, there is a high chance of it being rectified in the same iteration as the developers seek explanation from the customer. Even if they could not perceive those errors in the begging, errors are captured before the next iteration, as the customer uses the software and finds out the problems. Boehm’s law is being used in its full in agile software development as the errors are captured and rectified as soon as they occur and hence the cost and effort is reduced on rework. Boehm’s 2ns law: This law is also implemented in the agile software development in a sense. The difference is that in prototyping the piece of software is only a set of GUI with no or limited functionality. The customer does get a feeling of how t will look like at the end but do not get the real feeling of what that software will do. On the other hand the working software, delivered in each iteration of agile software development, is not only used for user interface issues but it also gives the real functionality. The only difference between prototype and a small working piece of software in agile software development is t hat the prototype is used for the identification of GUI problems and can cover the whole software, but a small working piece of software is not delivered to identify GUI issues rather it is delivered to the customer to use the functionality it provides. . For each software development methodology, give an example of a project which it would be well suited for and one which it would be inappropriate for (Total Two projects for each software development methodology). [2 + 2 = 4 marks] Waterfall Model Appropriate Project: Waterfall model is more suitable for a very big department of defence project e. g. To develop a communication software for distant team members. The requirements in this kind of projects are clear and stable. The duration of the whole project is normally very long, often years, and hence each phase of development can be completed with perfection. Inappropriate Project: Small volatile projects like an interactive web based solution can not be developed with waterfall model of development. The requirements in these projects changes very fast and the business needs may vary on the daily basis. The life cycle of such projects is usually small, most often in months and their majority requirements are highly unstable in nature. Agile Software Development Appropriate Project: The projects with a limited time and budged can be successfully developed with agile development methodology, as the customer picks the requirements that are critical and hence gets the higher value for money. An example of such a project may be a web based solution where a customer can add a new feature and may discard some other on the basis of their business needs. The changes occur very rapidly in such projects and therefore the new requirements are very frequent, hence it is more suitable to be developed using agile development methodology. Inappropriate Project: Some government projects where a big design is required for the approval or the cost and time estimate is required for a project to be awarded is not suitable for agile software development. In such projects the funding body usually breaks it to phases and gets it developed phase by phase and hence its impossible to apply agile software development principles. Agile software development is also inappropriate for mission critical software projects, e. g. a software to be used in life saving machines. NOTE: All description should be in your own words and references could be made from the text. Remember to adhere to the Plagiarism rules.