Software Engineering.pdf

SOFTWARE ENGINEERING MCA  Software is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be collection of executable programming code, associated libraries and documentations. Software, when made for a specif...

SOFTWARE ENGINEERING MCA  Software is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be collection of executable programming code, associated libraries and documentations. Software, when made for a specific requirement is called software product. The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software Components of Software : There are three components of the software: These are : Program, Documentation, and Operating Procedures. 1.Program – A computer program is a list of instructions that tell a computer what to do. 2.Documentation – Source information about the product contained in design documents, detailed code comments, etc. 3.Operating Procedures – Set of step-by-step instructions compiled by an organization to help workers carry out complex routine operations.  Software Paradigms: Programming paradigm is a subset of Software design paradigm which is further a subset of Software development paradigm. 1. Software Development Paradigm: It includes various researches and requirement gathering which helps the software product to build. Requirement gathering Software design Programming 2. Software Design Paradigm: This paradigm is a part of Software Development and includes Design Maintenance Programming 3. Programming Paradigm: This paradigm is related closely to programming aspect of software development. This includes Coding Testing Integration What is Software Crisis? Software Crisis is a term used in computer science for the difficulty of writing useful and efficient computer programs in the required time. The software crisis was due to using the same workforce, same methods, and same tools even though rapidly increasing software demand, the complexity of software, and software challenges. With the increase in software complexity, many software problems arise because existing methods were insufficient. If we use the same workforce, same methods, and same tools after the fast increase in software demand, software complexity, and software challenges, then there arise some issues like software budget problems, software efficiency problems, software quality, problems, software management, and delivery problems, etc. This condition is called a Software Crisis. Causes of Software Crisis: The cost of owning and maintaining software was as expensive as developing the software. At that time Projects were running overtime. At that time Software was very inefficient. The quality of the software was low quality. Software often did not meet user requirements. The average software project overshoots its schedule by half.  At that time Software was never delivered. Non-optimal resource utilization. Challenging to alter, debug, and enhance. The software complexity is harder to change. Factors Contributing to Software Crisis: Poor project management. Lack of adequate training in software engineering. Less skilled project members. Low productivity improvements. Solution of Software Crisis: There is no single solution to the crisis. One possible solution to a software crisis is Software Engineering because software engineering is a systematic, disciplined, and quantifiable approach. For preventing software crises, there are some guidelines: Reduction in software over budget. The quality of the software must be high. Less time is needed for a software project. Experienced and skilled people working on the software project. Software must be delivered. Software must meet user requirements. Operational Characteristics of a good quality software product: Operational characteristics of a good quality software product are based on the functionality and related to ‘exterior quality’ of software product. Various operational characteristics of quality software product are as follows; a) Correctness: The developed software product make sure should meet all the customer specification. b) Usability/Learnability: The software product must be user friendly and easy to understand even for IT-illiterate end users. To learn and understand the operational behavior and how to use the software product should be less. c) Integrity: Quality software should be side effects free product. For example, like each medicine have side-effects (either direct or indirect), in the same way software may have side-effects i.e. it may affect the working of another application, so for good quality software it should have no side effect. d) Reliability: For a good quality software product reliability factor is highly important i.e. software should not have any defects. Not only this, it shouldn’t run time failed. e) Efficiency: Efficiency factor of a quality software relates to the effectively uses the available resources by the software product. For example developed software should be effectively used the available memory (like; permanent memory-ROM and/or temporary memory- RAM) and execute command as per the desired timing requirement. f) Security: To keep data secure from external threats good software product have high security factors. g) Safety: The software should not be hazardous to the environment and/or end user life. Revision Characteristics of a good quality software product: Review characteristics of a good quality software product based on the engineering factors that relates to the ‘Interior quality’ of the developed software. This factor of software quality deals with the efficiency, documentation and the structure of the software product. Various revision characteristics of software are as follows; a) Maintainability: After delivering the software product at the end user, maintenance should be easy for any kind of end user. b) Flexibility: As per the end users requirements software product changes should be easy to make. c) Extensibility: For the future functionality enhancement software product should be easy to increase the functions performed by it. d) Scalability: Developed software product should be very easy to upgrade for more work and/or more number of users. e) Testability: Testing the software should be easy. f) Modularity: Every software is collection of separate programs, unites and modules which are dependent and/or independent of each other. These programs, units and modules are then integrated to make the final software. If the software is divided into separate independent parts that can be modified, tested separately, it has high modularity. Transition Characteristics of a good quality software product: Transition characteristics of a good quality software product based on the data intervention behavior factor that relates to the software end user environment and platform, modules reusability and interoperability of the software. Various transition characteristics of software are as follows: a) Interoperability : Interoperability is the ability of software to exchange information/data with other applications and make use of information transparently. b) Reusability: If we are able to use the software code with some modifications for different purpose then we call software to be reusable. c)Portability: The factor of software refers to how well the software can adopt to changes in its environment and/or platform or with its requirements. The sub-factor of this characteristic includes adaptability, conformance and replaceability. Characteristics of “Software” in Software Engineering Software is developed or engineered; it is not manufactured in the classical sense: Although some similarities exist between software development and hardware manufacturing, few activities are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems than software. The software doesn’t “wear out.”: Hardware components suffer from the growing effects of many other environmental factors. Stated simply, the hardware begins to wear out. Software is not susceptible to the environmental maladies that cause hardware to wear out. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which the design was translated into machine-executable code. Therefore, the software maintenance tasks that accommodate requests for change involve considerably more complexity than hardware maintenance. However, the implication is clear—the software doesn’t wear out. But it does deteriorate. The software continues to be custom-built: A software part should be planned and carried out with the goal that it tends to be reused in various projects. Current reusable segments encapsulate the two pieces of information and the preparation that is applied to the information, empowering the programmer to make new applications from reusable parts. In the hardware world, component reuse is a natural part of the engineering process. Software Engineering is an engineering branch associated with development of software product using well-defined scientific principles, methods and procedures. The technology encompasses (include) a process, a set of methods and array of tools that we call software engineering. Software engineering is a branch of computer science that involves the design, development, testing, and maintenance of software applications. Software engineers use programming languages, platforms, and architectures to create solutions for end users, such as computer games, business applications, operating systems, and network control systems. Software engineers are in high demand across many industries, including healthcare, financial services, manufacturing, education, and government. The term "software engineering" was coined by computer scientist and systems engineer Margaret Hamilton in 1963 or 1964 while developing the guidance and navigation systems for the Apollo missions. Hamilton felt that software developers earned the right to be called engineers. * Software: Software is collection of programs. * Program: Program is Set of related statements.  Different types of software developers – Web Developer Mobile App Developer Desktop Developer Graphics Developer Game Developer Big Data Developer Embedded Developer Security Developer Cloud Developer DevOps developer SOFTWARE DEVELOPMENT LIFE CYCLE 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 other words, a life cycle model maps the different activities performed on a software product from its inception to retirement. Different life cycle models may map the basic development activities to phases in different ways. Thus, no matter which life cycle model is followed, the basic activities are included in all life cycle 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. 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 member might start writing the code for his part, another might decide to prepare 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 recognized. Without software life cycle models 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 important and commonly used life cycle models are as follows: Classical Waterfall Model Iterative Waterfall Model Prototyping Model Evolutionary Model Spiral Model 1. 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 cannot be used in actual software 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 following phases as shown in fig Fig. : Classical Waterfall Model 1. 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 overall understanding of the problem they investigate the different solutions that are possible. Then they examine each of the solutions 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 expertise in the area of development. 2. Requirements analysis and specification: - The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely Requirements gathering and analysis Requirements specification The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed. This is done to clearly understand the customer requirements so that incompleteness and inconsistencies are removed.  The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. For example, to perform the requirements analysis of a business accounting software required by an organization, the analyst might interview all the accountants of the organization to ascertain their requirements. The data collected from such a group of users usually contain several contradictions and ambiguities, since each user typically has only a partial and incomplete view of the system. Therefore it is necessary to identify all ambiguities and contradictions in the requirements and resolve them through further discussions with the customer. After all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements properly understood, the requirements specification activity can start. During this activity, the user requirements are systematically organized into a Software Requirements Specification (SRS) document. The customer requirements identified during the requirements gathering and analysis activity are organized into a SRS document. The important components of this document are functional requirements, the nonfunctional requirements, and the goals of implementation. 3.Design: The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase the software architecture is derived from the SRS document. Two distinctly different approaches are available: the traditional design approach and the object-oriented design approach. Traditional design approach Object-oriented design approach 4. Coding and unit Testing: The purpose of the coding phase (sometimes called the implementation phase) of software development is to translate the software design into source code. Each component of the design is implemented as a program module. The end-product of this phase is a set of program modules that have been individually tested. During this phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing each module in isolation as this is the most efficient way to debug the errors identified at this stage. 5.Integration and System Testing: Integration of different modules is undertaken once they have been coded and unit tested. During the integration and system testing phase, the modules are integrated in a planned manner. The different modules making up a software product are almost never integrated in one shot. Integration is normally carried out incrementally over a number of steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document. System testing usually consists of three different kinds of testing activities: α – testing: It is the system testing performed by the development team. β –testing: It is the system testing performed by a friendly set of customers. Acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product. System testing is normally carried out in a planned manner according to the system test plan document. 6.Maintenance: - Maintenance of a typical software product requires much more than the effort necessary to develop the product itself. Many studies carried out in the past confirm this and indicate that the relative effort of development of a typical software product to its maintenance effort is roughly in the 40:60 ratios. Maintenance involves performing any one or more of the following three kinds of activities: Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. Improving the implementation of the system, and enhancing the functionalities of the system according to the customer’s requirements. This is called perfective maintenance. Porting the software to work in a new environment. For example, porting may be required to get the software to work on a new computer platform or with a new operating system. This is called adaptive maintenance. Advantages Easy to Understand: The Classical Waterfall Model is very simple and easy to understand. Individual Processing: Phases in the Classical Waterfall model are processed one at a time. Properly Defined: In the classical waterfall model, each stage in the model is clearly defined. Clear Milestones: The classical Waterfall model has very clear and well-understood milestones. Properly Documented: Processes, actions, and results are very well documented. Reinforces Good Habits: The Classical Waterfall Model reinforces good habits like define-before-design and design-before-code. Working: Classical Waterfall Model works well for smaller projects and projects where requirements are well understood. Disadvantages High amounts of risk and uncertainty. Not a good model for complex and object-oriented projects. Poor model for long and ongoing projects. Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model. It is difficult to measure progress within stages. Cannot accommodate changing requirements. Adjusting scope during the life cycle can end a project. Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early. 2. PRTOTYPING MODEL Prototype: A prototype is a toy implementation of the system. A prototype usually exhibits 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 the actual system. Need for a prototype 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 the customer. This is a valuable mechanism for gaining better understanding of the customer’s needs:  how the screens might look like how the user interface would behave how the system would produce outputs Another reason for developing a prototype is that it is impossible to get the perfect product in the first attempt. Many researchers and engineers advocate that if you want to develop a good product you must plan to throw away the first version. The experience gained in developing the prototype can be used to develop the final product. A prototyping model can be used when technical solutions 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 issues like the response time of a 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. A prototype of the actual product is preferred in situations such as: User requirements are not complete Technical issues are not clear Fig.: Prototype Model 3. EVOLUTIONARY MODEL: It is also called successive versions model or incremental model. At first, a simple working model is built. Subsequently it undergoes functional improvements & we keep on adding new functions till the desired system is built. Applications: Large projects where you can easily find modules for incremental implementation. Often used when the customer wants to start using the core features rather than waiting for the full software. Also used in object oriented software development because the system can be easily portioned into units in terms of objects. Advantages: User gets a chance to experiment partially developed system Reduce the error because the core modules get tested thoroughly. Disadvantages: It is difficult to divide the problem into several versions that would be acceptable to the customer which can be incrementally implemented & delivered. Fig.: EVOLUTIONARY MODEL 4. SPIRAL MODEL: The Spiral model of software development is shown in figure. 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 loop 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. 4.1. 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 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 project risk. Fig : Spiral Model  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 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 around the spiral. ADVANTAGES OF SPIRAL MODEL 1.Software is produced early in the software life cycle. 2.Risk handling is one of important advantages of the Spiral model, it is best development model to follow due to the risk analysis and risk handling at every phase. 3.Flexibility in requirements. In this model, we can easily change requirements at later phases and can be incorporated accurately. Also, additional Functionality can be added at a later date. 4.It is good for large and complex projects. 5.It is good for customer satisfaction. We can involve customers in the development of products at early phase of the software development. Also, software is produced early in the software life cycle. 6.Strong approval and documentation control. 7.It is suitable for high risk projects, where business needs may be unstable. A highly customized product can be developed using this.  DISADVANTAGES OF SPIRAL MODEL 1.It is not suitable for small projects as it is expensive. 2.It is much more complex than other SDLC models. Process is complex. 3.Too much dependable on Risk Analysis and requires highly specific expertise. 4.Difficulty in time management. As the number of phases is unknown at the start of the project, so time estimation is very difficult. 5.Spiral may go on indefinitely. 6.End of the project may not be known early. 7.It is not suitable for low risk projects. 8.May be hard to define objective, verifiable milestones. Large numbers of intermediate stages require excessive documentation. Comparison of different life-cycle models The classical waterfall model can be considered as the basic model and all other life cycle models as embellishments of this model. However, the classical waterfall model cannot be used in practical development projects, since this model supports no mechanism to handle the errors committed during any of the phases. 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 subject to many risks. The prototyping model 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 objectoriented 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 queries 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 incremental model is that it reduces the customer’s trauma of getting used to an entirely new system. The gradual introduction of the product via incremental 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.