All the Lectures of Software Engineering-I

  • Lecturer:  Dr. Akhter Ali Jalbani
  • Subject Title:   Software Engineering-I
  • Code:   ITC-507

  • Lectures No:   1
    Date:   27/05/2013

    Scope and necessity of software engineering software engineering is an engineering approach for software development. we can alternatively view it as a systematic collection of past experience. the experience is arranged in the form if methodologies and guidelienes. A small program can be written withoutusing software engineering principles. but if one wants to develop a large software product, then software engineering principles are indispensable to achieve a good quality software cost effectively. These definitions can be elaboated with the help of a building construction analoy. suppose you have a friend who asked you to build a small wall, you would be able to do that using your common sense you will get building materials like bricks; cement etc, and you will then build the wall. But what would happen if the same friend asked you build a large multistoried. You don't have a very good idea about building such a huge complex. it would be very dificult to extend your idea about a small wall construction into constructing a lrage building. Even if you tried to build a large building, it would collapse because you would not have the requisite knowledge about the strength of materials, testing, planning , architectural design, etc. building a small wall and building a large building are entirely different ball games. you can use your intuition and still be successfulin building a small wall, but building a large building requires knowledge of civil, architectural and other engineering principles. without using software engineering principle it would be difficult to develop large programs. in industry it is usually needed to develop large programs to accommodate multiple functions. A problem with developing such large commercial programs is that the complexity and difficult levels of the programs increase exponentially with theirsizes as shown in fig. 1.3. For example, 10,000 LOC is not just 10 times more difficult to develop, but may as well turn out to be 100 times more difficult unlees software engineering principlesare used. in such situations software engineering techniques come to rescue. software engineering helps to reduce the programming complexity. sotware engineering principles use to important techniques to reduce problem complexity: abstraction and decomposition. The proble of abstraction implies that a problem can be simplfied by omitting irrelevant details . in other words , the main purpose of abstraction is to consider only those aspects of the problem tha are not relevant for certain purpose and suppress other aspects that are not relevant for the given purpose . once the simpler problem si solved , then the omitted details can be taken into consideration to solve the next lower level abstraction , and so on, abstraction is a powerfull way of reducing the complexity of the problem. The other approach to tackle problem complexity is decomposition , in this technique , a complex problem is divided into several smaller problems and then the smaller problems are solved one by one. However in this technique any random decomposition of a problem into smaller parts will not help. The problem has to be decomposed such that each component of the decomposed problem cn be solved independently and then the solution of the different components can be combined to get the full solution. A good decomposition of a problem should minimize among various components. if the different subcomponents are interrelated. then the different components cannot be solved separately and the desired reduction in complexity will not be realize. Program VS Software product Program are developed by individuals for their personal use. They are therefore, small in size and have limited functionality but software products are extremely large. In case of a program , the programmer himself is the sole user but on the other hand , in case a software product , most most users are not involved with the development . In case of a program, a single developer is involved but in case of a software product, a lrage number of developers are involved. For a program the user interface may not be very important , because the programmer is the sole user. On the other hand, for a software product , user interface must be carefully designed and implemented because developers of that product and users of that product are totally diffrent . In case of a program , very little documentation is expected, but a software product must be well documented. A program can be developed according to the programmer's individual style of development, but a software product be developed using the accepted software engineering principles. LIFE cycle model: A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the software life cycle. A life cycle model represents all the activities required to make a software product transit through its life cycle phases. It also captures the order in which these activities are to be undertaken. In othe rwords, a life cycle model maps the different activities performed on a software product from its inception to retirement. Different ways . Thus , no matter which life cycle model is followed, the basic activities are include in all life models though the activities may be carried out in different orders in different life cycle models. During any life cycle phase, more than one activity may also be carried out. For example, the design phase might consist of the structured analysis activity followed by the structured design activity. The Need for a Software life Cycle model: The development team must identify a suitable life cycle model for the particular project and then adhere to it. Without using of a particular life cycle model the development of a software product would not be in a systematic and disciplined manner. When a software product is being developed by a team there must be a clear understanding among team members about when and what to do. Otherwise it would lead to chaos and project failure. This Problem can be illustrated by using an example. Suppose a software development problem is divided into several parts and the parts are assigned to the team members . from then on , suppose the team members are allowed the freedom to develop the parts assigned to them in whatever way they like, It is possible that one members might start writing the code for this part, another might decide to prepare the the test documents first, and some other engineer might begin with the design phase of the parts assigned to him, This would be one of the perfect recipes for project failure. A software life cycle model defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria have been satisfied. So without software life cycle model the entry and exit criteria for a phase cannot be recognizes without software life cyclemodels. (such as classical waterfall model, iterative waterfall model, prototyping model, evolutionary model, spiral model etc. ) it becomes difficult for software project managers to monitor the progress of the project. Different Software life cycle Models: Many life cycle models have been proposed so far. Each of them has some advantages as well as some disadvantages. A few impotant and commonly used life cycle models are as folloes: 1. Classical Waterfall Model 2. Iterative Waterfall Models. 3. Prototyping Model. 4. Evolutionary Model. 5. Spiral Model. Different phases of the classical waterfall model The classical waterfall model is intuitively the most obvious way to develop software. Though the classical waterfall model is elegant and intuitively obvious. it is not a practical model in the sense that it can not be used in actual softwarwe development projects. Thus, this model can be considered to be a theoretical way of developing software. but all other life cycle models are essentially derived from the classical waterfall model. so. in order to be able to appreciate other life cycle models it is necessary to learn the classical waterfall model. Classical waterfall model divides the life cycle into the fallwing phases as shown in fig.2.1: 1. Feasibility study 2. Requirements Analysis and Specification 3.Design 4.Coding and Unit Testing 5.Integration and System Testing 6.Maintenace Fig: 2.1: Calssical Waterfall Model. Activities in Each phase of the life cycle => Activities undertaken during feasibility study:- The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product. => At first project managers or team leaders try to have a rough understanding of what is required to be done by visiting the client side. They study different input data to the system and output data to be produced by the system. They study what kind of processing is needed to be done on these data and they look at the various constraints on the behavior of the system. => After they have an over all understanding of the problem they investigaate the different solution that are possible. Then They examine each of the solution in terms of what kind of resources required, what would be the cost of development and what would be the development time for each solution. => Based on this analysis they pick the best solution and determine whether the solution is feasible financially and technically. They check whether the customer budget would meet the cost of the product and whether they have sufficient technical experties in the area of development. The following is an example of a feasibility study undertaken by an organization. It is intended to give you a feel of the activities and issues involved in the feasibility study phase of a typical software project. Shortcomings of the classical waterfall model The classical waterfall model is an idealistic one since it assumes that no development error is ever committed by the engineers during any of the life cycle phases. However, in practical development environments, the engineers do commit large number of error in almost every phase of the life cycle. The source of the defects can be many: oversight, wrong assumptions, use of inappropriate technology, communication gap among theproject engineersm, etc. these defects usually get detected much layer in the life cycle. For example, a design defect might go unnoticed till we reach the coding or testing Phase. Once a defect is detected , the engineerings need to go back to the phase, where the defect had occurred and redo some of the work done during that face and subsequent phases to correct the defect and it's effect on the later phases therefore, in any practically software development, work, it is not possible to strictly follow the classical waterfall model. Phase-Entry and phase-exit criteria of each phase At the starting of the feasibilty study, project managers or team leaders try to understand what is the actual problem by visiting the client side, At the end of that phase they pick the best solution and determine whether the solution is feasible financially and technically. At the starting of requirements analysis and specification phase the required data is collected. After that requirement specification is carried out. Finally , SRS document is produced. At the starting of design phase , context diagram and different levels of DFDs are produced according to the SRS document. At the end of this phase module structure (structure chart) is produced. During the coding phase each module (independently compilation unit) of the design is coded. Then each module is tested independently as a stand-alone unit and debugged separatly . After this each module is documented individually. The end product of implementation phase is a set of program module, that have been tested individuly but not tested together. After the implementation phase , different modules which have been tested individully are integrated in a planned manner. After all the modules have been successfully integrated and tested , system testing is carried out. Software maintenance denotes any changes made to a software product after it has been delivered to the customer. Maintenance is inevitable for almost any kind of product. However , most products need maintenance due to the wear and tear caused by use.


    Lectures No:   2
    Date:   27/05/2013

    Specific Instruction Objectives: At the end of this lesion the student of this will be able to: Explain what a prototype is? Explain why and when a prototype needs to be developed during software development. Identify the situations in which one would prefer to build a prototype. State the activities carried out during each phase of a spiral/model. Identify circumstance under which spiral model should be used for software development. Tailor a development process to a specific project. Prototypes: A prototypes is toy implementation of the system , A prototypes usually axhibits limited functional capabilities low reliability, and inefficient performance compared to the actual software. A prototype is usually built using several shortcuts. The shortcuts might involve using inefficient , inaccurate or dummy functions. The shortcut implementation of a function, for example, may produce the desired results by using a table look-up instead of performing the actual computations. A prototype usually turns out to be a very crude version of actual system. Need for a prototypes in software development: There are several uses of a prototype. An important purpose is to illustrate the input data formats, messages , reports and the interactive dialogues to customer. This is a valuable mechanism for gaining better understanding of the customers need. How the screens might look like. How the user interface would behave. How the systems would produce outputs. This is some thing similar to what the architectural designers of a building do; they show a prototype of the building to their customer. The customer can evaluate whether he likes it or not and and the changes that he would need in the actual product. A similar thing happens in the case of a software product and its prototypes model. Another reason for developing a prototypes is that it is impossible to get the perfect product in the first attempt. Many researchers and engines advocate if you want to develop a good product you must plan to through away the first version. The experience gained in developing the prototype can be used to develop the final product… A prototypes model can be used when technical solution are unclear to the development team. A developed prototype can help engineers to critically examine the technical issues associated with the product development . often , major design decisions depend on the responses time of a hardware controller, or the efficiency of a sorting algorithm, etc in such circumstances, a prototypes may be the best or the only way to resolve the technical issues. Examples for prototypes models: A prototype of the actual product is in situation such as : User requirements are not complete Technical issues are not clear Lets use an example for each of the above catory. Examples 1: user requirements are not complete In any application software like billing in a retail shop, according in a firm, etc the user of the software are not clear about the different functionalities required. Once they are provided with the prototype implementation, they can try to use it and find out the missing functionalities. Examples 2: Technical issues are not clear Suppose a project involving writing a compiler and the development team has never written a compiler. In such a case, the team can consider a simple language, try to build a compiler in order to check the issues that arise in the process and resolve them. After successfully building A small compiler (prototype), they would extend it to one that supports a complete language. Spiral model The spiral model of software development is shown in fig. 2.2. The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next lop with requirements specification the next one with design, and so on. Each phase in this model is split into four sectors (or quadrants) as shown in fig. 2.2. The following activities are carried out during each phase of a spiral model. First quadrant (objective setting) During the first quadrant, it is needed to identify the objective of the phase. Examine the risks associated with these objectives. Second quadrant (Risk assessment and reduction) A detailed analysis is carried out for each identified project risk. Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed. Third quadrant (development and validation) Develop and validate the next level of the product after resolving the identified risks. Fourth quadrant (review and planning) Review the achieved so for with the customer and plan the next iteration around the spiral. Progressively more complete version of the software gets built with each iteration around the spiral. Circumstances to use spiral model. The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. However, this model is much more complex than the other models-this is probably a factor deterring it’s use in ordinary projects. Comparison of different life cycle models The classical water fall model can be considered as the basic model and all other life cycle models as embellishments of this model. However, the classical waterfall model can not be used in practical development projects, since this model supports no mechanism to handle the errors committed during any of the phase. This problem is overcome in the iterative waterfall model. The iterative waterfall model is probably the most widely used software development model evolved so far. This model is simple to understand and use. However, this model is suitable only for well understood problems, it is not suitable for very large projects and for projects that are suitable to many risks. This prototyping approach is suitable for projects for which either the user requirements or the underlying technical aspects are not well understood. This model is especially popular for development of the user-interface part of the projects. The evolutionary approach is suitable for large problems which can be decomposed into a set of modules for incremental development and delivery. This model is also widely used for object-oriented development projects. Of course, this model can only be used if the incremental delivery of the system is acceptable to the customer. The spiral model is called a Meta. Model since it encompasses all other life cycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. However, this model is much more complex than the other models-this is probably a factor deterring its use in ordinary projects. The different software life cycle models can be compared from the viewpoint of the customer. Initially, customer confidence in the development team is usually high irrespective of the development model followed. During the lengthy development process, customer confidence normally drops off, as no working product is immediately visible. Developers answer customer using. Technical slang and delays are announced. This gives rise to customer resentment. On the other hand, an evolutionary approach lets the customer experiment with a working product much earlier than the monolithic approaches. Another important advantage of the increment model is that it reduces the customer’s trauma of getting used to an entirely new system. The gradual introduction of the product via increment phases provides time to the customer to adjust to the new product. Also from the customer’s financial viewpoint incremental development does not require a large upfront capital outlay. The customer can order the incremental versions as and when he can afford them. The following question has been designed to test the objectives identified for this modules: 1. Identify the definite stages through which a software product undergoes during its lifetime. Ans: - the definite stages through which a software product undergoes during it’s lifetime are as follows: Feasibility study Requirements analysis specification Design Integration and system testing and maintenance 2. Explain the problems that might be faced by an organization if it does not follow any software life cycle model. Ans:- the development team identify a suitable life cycle model for the particular project and then adhere to it. Without using a particular life cycle model the development of a software product would not be in a systematic and disciplined manner. When a software product is being developed by a team there must be a clear understanding among team members about when and what to do. Otherwise it would lead to chaos and project failure. This problem can be illustrated by using an example. Suppose a software development is divided into several parts and the parts are assigned to the team members. From then one suppose the team members are allowed the freedom to develop the parts assigned to them in what ever way they like. It is possible that one member might start writing the code for his part. Another might decide to prepare the test document first , and some engineer might begin with the design phase of the part assigned to him. This would be one of the perfect recipes for project failure. A software life cycle model defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria have been satisfied. So without software life cycle model the entry and exit criteria for a phase cannot be recognized. Without software life cycle models (such as classical waterfall model, prototyping model, evolutionary model, spiral model etc.) it becomes difficult for software project manager to monitor the progress of the project. 3. identify the six different phases of a classical water wall model. Ans: the classical water fall model is intuitively the most obvious way to develop software. Though the classical water fall model in the elegant and intuitively obvious, it is not a practical model in the sense that it can not be used in actual software development projects. Thus this model can be considered to be a theoretical way of developing software . but al other life cycle models are essentially derived from the classical water fall models. So in order to be able to appreciate other life cycle models it is necessary to learn the classical water fall model. Classical water fall model divided the life cycle into the flowing phases as shown in fig. Fig • feasibility study • requirements analysis and specification • design • coding and unit testing • integration and system testing and maintenance 4. identification two basis roles of a system analyst. Ans: for performing requirements analysis activity systems analyst collects all relevant data regarding the products to be developed from the user of the product and the customer through interviews anmd discussions. For example, to perform the requirements analysis of a business according software required by an organization to ascertain their requirements. The data collected such a group of users usually contain several contradictions and ambiguities, since each user typically had only a partial and incomplete view of the system. There fore a system analyst identifies all ambiguities and contradiction with the customer. After all ambiguities, inconsistencies and incompleteness have been resolve and all the requirements properly understand the system analyst starts requirements specification activity. During this activity the user requirements are systematically organizes inti a software requirements specification (srs) documents. 5. Dffirence between structured analysis and structured design. Ans: traditional design consist of two different activity first a structured analysis of the requirements specification is carried out where the detailed structured of the problem is examined. This is followed by a structured design activity. During structured design, the results of structured analysis are transformed into the software design. 6. identify at least three activities undertaken in an object-oriented software design approach. Ans: in this techniques various objects that occur in the problem and the solution domains and the solution domain are first identify and the different relationships that exit among these objects are identified. The object structured is further refined to obtain the detiled design. 7. state why it is good idea to test a module in isolation from other modules. Ans: during unit testing each module is unit tested to determine the correct working of all the individual modules. It involve testing each modules in isolation as this is the most efficient. Way to debug the errors identify at this stage. So it is always a good idea to test a module in isolation from other modules. 8. identify why different modules making up a software products are almost never integrated in one shot. Ans: integration of different modules is undertaken once they have been coded and unit tested . during the integrated in a planned manner. The different modules making up a software product are almost never integrated in once shot. Integration is normally carried out incrementally over a number of steps, the partially integrated system is tested and a set a previously planned modules are added to it. Finally when all the modules are successfully integrated and tested system tested is carried out. 9. mention at least two reasons as to why classical waterfall modules can be considered impractical and cannot be used in real projects. Ans : the classical waterfall model is an idealistic one since it assumed that no development error is ever committed by the engineers during any of the life cycle phases. However in practical development environments, the engineers do commit a large number of errors on almost every phases of the life cycle. The source of the defects can be many oversight wrong assumption, use of inappropriate technology, communication gap among the project engineers, etc. these defects usually get detected much late in the life cycle. For example a design defect might go unnoticed unless we reach the coding or testing phase. Once a defect had occurred and redo some of the work done during the phase and the subsequent phases to correct the defect and it’s effect on the later phases. Therefore in any practical software development work it is not possible to strictly follow the classical model. 10. explain what is software prototype? Ans : a prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low reliable and inefficient performance compared to the actual software. A prototype is usually built using several shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy functions. The short implementation of function for examples: may products the desired results by using a table look-up instead of performing the actual computation. A prototype usually turns out to be a very crude version of the actual system. 11. identify three reasons for the necessity of developing a prototype during software development. Ans: there are several uses of a prototype. A important purpose is to illustrate the input data formats, messages, reports and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the customer’s needs: • how screens might look like • how the user interface would behave • how the system would produce output this something similar to what the architectural designers of a building to; they show a prototype of the building to their customer. The customer can evaluate whether he likes it or not and the changes that he would need in the actual products. A similar thing happens in the cases of a software products and its prototype models. Another reasons for developing a prototype is that it is impossible to get the perfect in the first attempt. Many researcher and engineers advocate that if you want to develop a good products you must plane to throw away the first version. The experience gained in developing the prototype can be used to develop the final products. 12. identify when does a prototype need to develop. Ans : A prototype can be develop when technical solution are unclear to the development team. A developed prototype can help engineers to critically examine the technical issues associated with the product development, often, major design decision depends on the ossues like the response time of the hardware controller or the efficiency of a sorting algorithm, etc. in such circumstances, a prototype may be the best or the only way to resolve the technical issues. 13. identify at least two activities carried out during each phase of a spiral model. The spiral model of software development is shown in fig: 2.2. the diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops is the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next loop with requirements specification , the next one with design, and so on, each phase in this model in fig 2.2 . the following activities are carried out during each phase of a spiral model. • First quadrant (objective setting) During the first quadrant it is need to identify the of objectives of the phase. Examine the risks associated with these objectives. • Second quadrant (risk assessment and reduction) A detailed analysis is carried out for each identified projects risk. Steps are taken to reduce the risks. For example if there is a risk that the requirements are inappropriate, a prototype system may be developed. • Third Quadrant (review and planning) Develop and validate the next level of the product after resolving the identified risks. • Fourth quadrant (review and planning) Review the results achieved so far with the customer and plan the next iteration around the spiral. Progressively more complete version of the software gets built with each iteration the spiral. 14. write down the two advantages of using spiral model. Ans: the spiral model is called a meta model since it encompasses all other life cycle model. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. How ever this model is much more complex than the other models- this is probably a factor deterring its use in ordinary projects.