Lecture notes Advanced Software engineering

software engineering a practitioner's approach lecture notes and introduction to software engineering lecture notes pdf free download
JackBrown Profile Pic
JackBrown,Georgia,Professional
Published Date:12-07-2017
Your Website URL(Optional)
Comment
CS605 Software Engineering-II CS605 Software Engineering-II VU Lecture No. 1 Introduction to Software Engineering This course is a continuation of the first course on Software Engineering. In order to set the context of our discussion, let us first look at some of the definitions of software engineering. Software Engineering is the set of processes and tools to develop software. Software Engineering is the combination of all the tools, techniques, and processes that used in software production. Therefore Software Engineering encompasses all those things that are used in software production like: • Programming Language • Programming Language Design • Software Design Techniques • Tools • Testing • Maintenance • Development etc. So all those thing that are related to software are also related to software engineering. Some of you might have thought that how programming language design could be related to software engineering. If you look more closely at the software engineering definitions described above then you will definitely see that software engineering is related to all those things that are helpful in software development. So is the case with programming language design. Programming language design is one of the major successes in last fifty years. The design of Ada language was considered as the considerable effort in software engineering. These days object-oriented programming is widely being used. If programming languages will not support object-orientation then it will be very difficult to implement object- oriented design using object-oriented principles. All these efforts made the basis of software engineering. Well-Engineered Software Let’s talk something about what is well-engineered software. Well-engineered software is one that has the following characteristics. • It is reliable • It has good user-interface • It has acceptable performance • It is of good quality • It is cost-effective © Copy Right Virtual University of Pakistan 4 CS605 Software Engineering-II VU Every company can build software with unlimited resources but well-engineered software is one that conforms to all characteristics listed above. Software has very close relationship with economics. When ever we talk about engineering systems we always first analyze whether this is economically feasible or not. Therefore you have to engineer all the activities of software development while keeping its economical feasibility intact. The major challenges for a software engineer is that he has to build software within limited time and budget in a cost-effective way and with good quality Therefore well-engineered software has the following characteristics. • Provides the required functionality • Maintainable • Reliable • Efficient • User-friendly • Cost-effective But most of the times software engineers ends up in conflict among all these goals. It is also a big challenge for a software engineer to resolve all these conflicts. The Balancing Act Software Engineering is actually the balancing act. You have to balance many things like cost, user friendliness, Efficiency, Reliability etc. You have to analyze which one is the more important feature for your software is it reliability, efficiency, user friendliness or something else. There is always a trade-off among all these requirements of software. It may be the case that if you try to make it more user-friendly then the efficiency may suffer. And if you try to make it more cost-effective then reliability may suffer. Therefore there is always a trade-off between these characteristics of software. These requirements may be conflicting. For example, there may be tension among the following: • Cost vs. Efficiency • Cost vs. Reliability • Efficiency vs. User-interface A Software Engineer is required to analyze these conflicting entities and tries to strike a balance. Challenge is to balance these requirements. Software Engineers always confront with the challenge to make a good balance of all these tings depending on the requirements of the particular software system at hand. He © Copy Right Virtual University of Pakistan 5 CS605 Software Engineering-II VU should analyze how much weight should all these things get such that it will have acceptable quality, acceptable performance and will have acceptable user-interface. In some software the efficiency is more important and desirable. For example if we talk about a cruise missile or a nuclear reactor controller that are droved by the software systems then performance and reliability is far more important than the cost-effectiveness and user-friendliness. In these cases if your software does not react within a certain amount of time then it may result in the disaster like Chernobyl accident. Therefore software development is a process of balancing among different characteristics of software described in the previous section. And it is an art to come up with such a good balance and that art can be learned from experience. Law of diminishing returns In order to understand this concept lets take a look at an example. Most of you have noticed that if you dissolve sugar in a glass of water then the sweetness of water will increase gradually. But at a certain level of saturation no more sugar will dissolved into water. Therefore at that point of saturation the sweetness of water will not increase even if you add more sugar into it. The law of diminishing act describes the same phenomenon. Similar is the case with software engineering. Whenever you perform any task like improving the efficiency of the system, try to improve its quality or user friendliness then all these things involves an element of cost. If the quality of your system is not acceptable then with the investment of little money it could be improved to a higher degree. But after reaching at a certain level of quality the return on investment on the system’s quality will become reduced. Meaning that the return on investment on quality of software will be less than the effort or money we invest. Therefore, in most of the cases, after reaching at a reasonable level of quality we do not try to improve the quality of software any further. This phenomenon is shown in the figure below. b be en ne ef fiit t Software Background © Copy Right Virtual University of Pakistan 6 c co os st tCS605 Software Engineering-II VU Caper Jones a renounced practitioner and researcher in the filed of Software Engineering, had made immense research in software team productivity, software quality, software cost factors and other fields relate to software engineering. He made a company named Software Productivity Research in which they analyzed many projects and published the results in the form of books. Let’s look at the summary of these results. He divided software related activities into about twenty-five different categories listed in the table below. They have analyzed around 10000 software projects to come up with such a categorization. But here to cut down the discussion we will only describe nine of them that are listed below. • Project Management • Requirement Engineering • Design • Coding • Testing • Software Quality Assurance • Software Configuration Management • Software Integration and • Rest of the activities One thing to note here is that you cannot say that anyone of these activities is dominant among others in terms of effort putted into it. Here the point that we want to emphasize is that, though coding is very important but it is not more than 13-14% of the whole effort of software development. Fred Brook is a renowned software engineer; he wrote a great book related to software engineering named “A Mythical Man Month”. He combined all his articles in this book. Here we will discuss one of his articles named “No Silver Bullet” which he included in the book. An excerpt from “No Silver Bullet” – Fred Brooks Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these we seek bullets of silver that can magically lay them to rest. The familiar software project has something of this character (at least as seen by the non-technical manager), usually innocent and straight forward, but capable of becoming a monster of missed schedules, blown budgets, and flawed projects. So we hear desperate cries for a silver bullet, something to make software costs drop as rapidly as computer hardware costs do. Scepticism is not pessimism, however. Although we see no startling breakthroughs, and indeed, such to be inconsistent with the nature of the software, many encouraging innovations are under way. A disciplined, consistent effort to develop, propagate and exploit them should indeed yield an order of magnitude improvement. There is no royal road, but there is a road. The first step towards the management of disease was replacement of demon theories and humours theories by the germ theory. The very first step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, © Copy Right Virtual University of Pakistan 7 CS605 Software Engineering-II VU and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering today. So, according to Fred Brook, in the eye of an unsophisticated manager software is like a giant. Sometimes it reveals as an unscheduled delay and sometimes it shows up in the form of cost overrun. To kill this giant the managers look for magical solutions. But unfortunately magic is not a reality. We do not have any magic to defeat this giant. There is only one solution and that is to follow a disciplined approach to build software. We can defeat the giant named software by using disciplined and engineered approach towards software development. Therefore, Software Engineering is nothing but a disciplined and systematic approach to software development. Now we will look at some of the activities involved in the course of software development. The activities involved in software development can broadly be divided into two major categories first is construction and second is management. Software Development The construction activities are those that are directly related to the construction or development of the software. While the management activities are those that complement the process of construction in order to perform construction activities smoothly and effectively. A greater detail of the activities involved in the construction and management categories is presented below. Construction The construction activities are those that directly related to the development of software, e.g. gathering the requirements of the software, develop design, implement and test the software etc. Some of the major construction activities are listed below. • Requirement Gathering • Design Development • Coding • Testing Management Management activities are kind of umbrella activities that are used to smoothly and successfully perform the construction activities e.g. project planning, software quality assurance etc. Some of the major management activities are listed below. • Project Planning and Management • Configuration Management • Software Quality Assurance • Installation and Training © Copy Right Virtual University of Pakistan 8 CS605 Software Engineering-II VU Project Planning and Management Configuration Management Quality Assurance Management Installation and Training Construction Requirements Design Coding Testing Maintenance Figure1 Development Activities As we have said earlier that management activities are kind of umbrella activities that surround the construction activities so that the construction process may proceed smoothly. This fact is empathized in the Figure1. The figure shows that construction is surrounded by management activities. That is, certain processes and rules govern all construction activities. These processes and rules are related to the management of the construction activities and not the construction itself. A Software Engineering Framework The software development organization must have special focus on quality while performing the software engineering activities. Based on this commitment to quality by the organization, a software engineering framework is proposed that is shown in Figure 2. The major components of this framework are described below. Quality Focus: As we have said earlier, the given framework is based on the organizational commitment to quality. The quality focus demands that processes be defined for rational and timely development of software. And quality should be emphasized while executing these processes. Processes: The processes are set of key process areas (KPAs) for effectively manage and deliver quality software in a cost effective manner. The processes define the tasks to be performed and the order in which they are to be performed. Every task has some deliverables and every deliverable should be delivered at a particular milestone. Methods: Methods provide the technical “how-to’s” to carryout these tasks. There could be more than one technique to perform a task and different techniques could be used in different situations. Tools: Tools provide automated or semi-automated support for software processes, methods, and quality control. © Copy Right Virtual University of Pakistan 9 CS605 Software Engineering-II VU Method T O O Task Set Process L S Quality Focus Figure 2 Software Engineering Framework Software Development Loop Let’s now look at software engineering activities from a different perspective. Software development activities could be performed in a cyclic and that cycle is called software development loop which is shown in Figure3. The major stages of software development loop are described below. Problem Definition: In this stage we determine what is the problem against which we are going to develop software. Here we try to completely comprehend the issues and requirements of the software system to build. Technical Development: In this stage we try to find the solution of the problem on technical grounds and base our actual implementation on it. This is the stage where a new system is actually developed that solves the problem defined in the first stage. Solution Integration: If there are already developed system(s) available with which our new system has to interact then those systems should also be the part of our new system. All those existing system(s) integrate with our new system at this stage. Status Quo: After going through the previous three stages successfully, when we actually deployed the new system at the user site then that situation is called status quo. But once we get new requirements then we need to change the status quo. After getting new requirements we perform all the steps in the software development loop again. The software developed through this process has the property that this could be evolved and integrated easily with the existing systems. © Copy Right Virtual University of Pakistan 10 CS605 Software Engineering-II VU Problem Definition Technical Status Quo Development Solution Integration Figure3 Software Development Loop Overview of the course contents In the first course we studied the technical processes of software development to build industrial strength software. That includes requirement gathering and analysis, software design, coding, testing, and debugging. In this course our focus will be on the second part of Software Engineering, that is, the activities related to managing the technical development. This course will therefore include the following topics: 1. Software development process 2. Software process models 3. Project Management Concepts 4. Software Project Planning 5. Risk Analysis and Management 6. Project Schedules and Tracking 7. Software Quality Assurance 8. Software Configuration Management 9. Software Process and Project Metrics 10. Requirement Engineering Processes 11. Verification and Validation 12. Process Improvement 13. Legacy Systems 14. Software Change 15. Software Re-engineering © Copy Right Virtual University of Pakistan 11 CS605 Software Engineering-II VU Lecture No. 2 Software Process A software process is a road map that helps you create a timely, high quality result. It is the way we produce software and it provides stability and control. Each process defines certain deliverables known as the work products. These include programs, documents, and data produced as a consequence of the software engineering activities. Process Maturity and CMM The Software Engineering Institute (SEI) has developed a framework to judge the process maturity level of an organization. This framework is known as the Capability Maturity Model (CMM). This framework has 5 different levels and an organization is placed into one of these 5 levels. The following figure shows the CMM framework. These levels are briefly described as follows” 1. Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends upon individual effort. By default every organization would be at level 1. 2. Level 2 – Repeatable: Basic project management processes are established to track cost, schedule, and functionality. The necessary project discipline is in place to repeat earlier successes on projects with similar applications. 3. Level 3 – Defined: The software process for both management and engineering activities is documented, standardized, and integrated into an organizational software process. All projects use a documented and approved version of the organization’s process for developing and supporting software. 4. Level 4 – Managed: Detailed measures for software process and product quality are controlled. Both the software process and products are quantitatively understood and controlled using detailed measures. 5. Level 5 – Optimizing: Continuous process improvement is enabled by qualitative feedback from the process and from testing innovative ideas and technologies. SEI has associated key process areas with each maturity level. The KPAs describe those software engineering functions that must be present to satisfy good practice at a particular level. Each KPA is described by identifying the following characteristics: © Copy Right Virtual University of Pakistan 12 CS605 Software Engineering-II VU 1. Goals: the overall objectives that the KPA must achieve. 2. Commitments: requirements imposed on the organization that must be met to achieve the goals or provide proof of intent to comply with the goals. 3. Abilities: those things that must be in place – organizationally and technically – to enable the organization to meet the commitments. 4. Activities: the specific tasks required to achieve the KPA function 5. Methods for monitoring implementation: the manner in which the activities are monitored as they are put into place. 6. Methods for verifying implementation: the manner in which proper practice for the KPA can be verified. Each of the KPA is defined by a set of practices that contribute to satisfying its goals. The key practices are policies, procedures, and activities that must occur before a key process area has been fully instituted. The following table summarizes the KPAs defined for each level. Level KPAs 1 No KPA is defined as organizations at this level follow ad-hoc processes 2 • Software Configuration Management • Software Quality Assurance • Software subcontract Management • Software project tracking and oversight • Software project planning • Requirement management 3 • Peer reviews • Inter-group coordination • Software product Engineering • Integrated software management • Training program • Organization process management • Organization process focus 4 • Software quality management • Quantitative process management 5 • Process change management • Technology change management • Defect prevention © Copy Right Virtual University of Pakistan 13 CS605 Software Engineering-II VU Lecture No. 3 Software Lifecycle Models Recalling from our first course, a software system passes through the following phases: 1. Vision – focus on why 2. Definition – focus on what 3. Development – focus on how 4. Maintenance – focus on change During these phases, a number of activities are performed. A lifecycle model is a series of steps through which the product progresses. These include requirements phase, specification phase, design phase, implementation phase, integration phase, maintenance phase, and retirement. Software Development Lifecycle Models depict the way you organize your activities. There are a number of Software Development Lifecycle Models, each having its strengths and weaknesses and suitable in different situations and project types. The list of models includes the following: • Build-and-fix model • Waterfall model • Rapid prototyping model • Incremental model • Extreme programming • Synchronize-and-stabilize model • Spiral model • Object-oriented life-cycle models In the following sections we shall study these models in detail and discuss their strengths and weaknesses. Build and Fix Model This model is depicted in the following diagram: © Copy Right Virtual University of Pakistan 14 CS605 Software Engineering-II VU It is unfortunate that many products are developed using what is known as the build-and- fix model. In this model the product is constructed without specification or any attempt at design. The developers simply build a product that is reworked as many times as necessary to satisfy the client. This model may work for small projects but is totally unsatisfactory for products of any reasonable size. The cost of build-and fix is actually far greater than the cost of properly specified and carefully designed product. Maintenance of the product can be extremely in the absence of any documentation. Waterfall Model The first published model of the software development process was derived from other engineering processes. Because of the cascade from one phase to another, this model is known as the waterfall model. This model is also known as linear sequential model. This model is depicted in the following diagram. The principal stages of the model map directly onto fundamental development activities. It suggests a systematic, sequential approach to software development that begins at the system level and progresses through the analysis, design, coding, testing, and maintenance. In the literature, people have identified from 5 to 8 stages of software development. The five stages above are as follows: 1. Requirement Analysis and Definition: What - The systems 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: How – The system design process partitions the requirements to either hardware of software systems. It establishes and overall system architecture. Software design involves fundamental system abstractions and their relationships. © Copy Right Virtual University of Pakistan 15 CS605 Software Engineering-II VU 3. Implementation and Unit Testing: - How – 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 specifications. 4. Integration and system testing: The individual program unit 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 the customer. 5. Operation and Maintenance: Normally this is the longest phase of the software life cycle. 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 which are approved. No phase is complete until the documentation for that phase has been completed and products of that phase have been approved. The following phase should not start until the previous phase has finished. Real projects rarely follow the sequential flow that the model proposes. In general these phases overlap and feed information to each other. Hence there should be an element of iteration and feedback. A mistake caught any stage should be referred back to the source and all the subsequent stages need to be revisited and corresponding documents should be updated accordingly. This feedback path is shown in the following diagram. Because of the costs of producing and approving documents, iterations are costly and require significant rework. The Waterfall Model is a documentation-driven model. It therefore generates complete and comprehensive documentation and hence makes the maintenance task much easier. It however suffers from the fact that the client feedback is received when the product is finally delivered and hence any errors in the requirement specification are not discovered until the product is sent to the client after completion. This therefore has major time and cost related consequences. © Copy Right Virtual University of Pakistan 16 CS605 Software Engineering-II VU Rapid Prototyping Model The Rapid Prototyping Model is used to overcome issues related to understanding and capturing of user requirements. In this model a mock-up application is created “rapidly” to solicit feedback from the user. Once the user requirements are captured in the prototype to the satisfaction of the user, a proper requirement specification document is developed and the product is developed from scratch. An essential aspect of rapid prototype is embedded in the word “rapid”. The developer should endeavour to construct the prototype as quickly as possible to speedup the software development process. It must always be kept in mind that the sole purpose of the rapid prototype is to capture the client’s needs; once this has been determined, the rapid prototype is effectively discarded. For this reason, the internal structure of the rapid prototype is not relevant. Integrating the Waterfall and Rapid Prototyping Models Despite the many successes of the waterfall model, it has a major drawback in that the delivered product may not fulfil the client’s needs. One solution to this is to combine rapid prototyping with the waterfall model. In this approach, rapid prototyping can be used as a requirement gathering technique which would then be followed by the activities performed in the waterfall model. © Copy Right Virtual University of Pakistan 17 CS605 Software Engineering-II VU Lecture No. 4 Incremental Models As discussed above, the major drawbacks of the waterfall model are due to the fact that the entire product is developed and delivered to the client in one package. This results in delayed feedback from the client. Because of the long elapsed time, a huge new investment of time and money may be required to fix any errors of omission or commission or to accommodate any new requirements cropping up during this period. This may render the product as unusable. Incremental model may be used to overcome these issues. In the incremental models, as opposed to the waterfall model, the product is partitioned into smaller pieces which are then built and delivered to the client in increments at regular intervals. Since each piece is much smaller than the whole, it can be built and sent to the client quickly. This results in quick feedback from the client and any requirement related errors or changes can be incorporated at a much lesser cost. It is therefore less traumatic as compared to the waterfall model. It also required smaller capital outlay and yield a rapid return on investment. However, this model needs and open architecture to allow integration of subsequent builds to yield the bigger product. A number of variations are used in object-oriented life cycle models. There are two fundamental approaches to the incremental development. In the first case, the requirements, specifications, and architectural design for the whole product are completed before implementation of the various builds commences. © Copy Right Virtual University of Pakistan 18 CS605 Software Engineering-II VU In a more risky version, once the user requirements have been elicited, the specifications of the first build are drawn up. When this has been completed, the specification team Build 1 Implementation, Specification Design Deliver to client integration Build 2 Implementation, Specification Design Deliver to client integration Build 3 Implementation, Specification Design Deliver to client integration Build n Implementation, Specification Design Deliver to client integration Specification team Implementation, integration team Design team turns to the specification of the second build while the design team designs the first build. Thus the various builds are constructed in parallel, with each team making use of the information gained in the all the previous builds. This approach incurs the risk that the resulting build will not fit together and hence requires careful monitoring. Rapid Application Development (RAD) Rapid application development is another form of incremental model. It is a high speed adaptation of the linear sequential model in which fully functional system in a very short time (2-3 months). This model is only applicable in the projects where requirements are well understood and project scope is constrained. Because of this reason it is used primarily for information systems. Synchronize and Stabilize Model This is yet another form of incremental model adopted by Microsoft. In this model, during the requirements analysis interviews of potential customers are conducted and requirements document is developed. Once these requirements have been captured, specifications are drawn up. The project is then divided into 3 or 4 builds. Each build is carried out by small teams working in parallel. At the end of each day the code is synchronized (test and debug) and at the end of the build it is stabilized by freezing the build and removing any remaining defects. Because of the synchronizations, components always work together. The presence of an executable provides early insights into operation of product. © Copy Right Virtual University of Pakistan 19 CS605 Software Engineering-II VU Spiral Model This model was developed by Barry Boehm. The main idea of this model is to avert risk as there is always an element of risk in development of software. For example, key personnel may resign at a critical juncture, the manufacturer of the software development may go bankrupt, etc. In its simplified form, the Spiral Model is Waterfall model plus risk analysis. In this case each stage is preceded by identification of alternatives and risk analysis and is then followed by evaluation and planning for the next phase. If risks cannot be resolved, project is immediately terminated. This is depicted in the following diagram. Risk Analysis Rapid Prototype Specification Design Implementation Verify As can be seen, a Spiral Model has two dimensions. Radial dimension represents the cumulative cost to date and the angular dimension represents the progress through the spiral. Each phase begins by determining objectives of that phase and at each phase a new process model may be followed. © Copy Right Virtual University of Pakistan 20 CS605 Software Engineering-II VU A full version of the Spiral Model is shown below: The main strength of the Spiral Model comes from the fact that it is very sensitive to the risk. Because of the spiral nature of development it is easy to judge how much to test and there is no distinction between development and maintenance. It however can only be used for large-scale software development and that too for internal (in-house) software only. © Copy Right Virtual University of Pakistan 21 CS605 Software Engineering-II VU Determine Identify and objectives, resolve risks alternatives, constraints Develop and verify next-level Plan Next product Phase © Copy Right Virtual University of Pakistan 22

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.