Module 1 Software Engineering PDF
Document Details
Uploaded by EncouragingDandelion9555
Tags
Summary
This document provides an overview of software engineering, including definitions, characteristics, and processes. It discusses topics such as software specification and development, as well as maintenance. The document details various models of the software process and some of the challenges in the software development industry.
Full Transcript
Software Engineering Module 1 Software has become critical to advancement in almost all areas of human endeavor. The art of programming only is no longer sufficient to construct large programs There are serious problems in the cost, t...
Software Engineering Module 1 Software has become critical to advancement in almost all areas of human endeavor. The art of programming only is no longer sufficient to construct large programs There are serious problems in the cost, timelines, maintenance, and quality of many software products Software engineering has the objective of solving these problems by producing good, quality, maintainable software, on time, within budget. Definition The establishment and use of software engineering principles in order to obtain economically developed software that is reliable and works efficiently on real machines. A discipline whose aim is the production of quality software, software that is delivered on time, within budget, and that satisfies its requirements. Program Vs Software A program is a set of instructions to solve a problem or specified task Software is something more than a program It consists of programs, documentation of any facet of the program, and the procedures used to setup and operate the software system Any program is a subset of software and it becomes software only if documentation and operating procedure manuals are prepared A program is a combination of source code and object code. documentation consists of various kinds of manuals as given in the figure Operating procedures consist of instructions to setup and use the software system and the instruction on how to react to system failure Software characteristics The software does not wear out Software is not manufactured Reusability of components Software is flexible Functionality It refers to the degree of performance of the software against its intended purpose Efficiency It refers to the ability of the software to use system resources in the most effective and efficient manner. The software should make effective use of storage space and executive command as per the desired timing requirement Reliability A set of attributes that bear on the capability of software to maintain its level of performance under a given condition for a stated period of time. Maintainability It refers to the ease with which modifications can be made in a software system to extend its functionality, improve its performance, or correct errors. Portability A set of attribute that bear on the ability of software to be transferred from one environment to another, without or minimum changes. Usability It refers to the extent to which the software can be used with ease The amount of effort or time required to learn how to use the software. Software Process The software process is the way in which we produce software. It is the set of activities and associated outcomes that produce software. Software engineers mostly carry out these activities. There are four key process activities that are common for all software processes. ○ Software specification The functionality of the software and constraints on its operation must be defined. ○ Software development The software based on these requirements which is specified in the specification must be developed. ○ Software validation The software must be validated to ensure that it satisfies what the system wants. ○ Software evaluation Software must evolve to meet the changing needs. This differs from organization to organization. Surviving in the increasingly competitive software business requires more than hiring smart and knowledgeable developers and buying the latest development tools. We also need to use effective software development processes, so that developers can systematically use the best technical and managerial practices to successfully complete their project Many software organizations are looking at software process improvement as a way to improve the quality productivity predictability of their software development and maintenance software. Not enough time ○ Unrealistic schedules leave insufficient time to do the essential project work ○ No software groups are sitting around with plenty of spare time to devote to exploring what is wrong ith their current development processes what they should be doing differently. ○ Customers and senior managers are demanding more software, of high quality in the minimum possible time. ○ Therefore there is always a shortage of time. ○ One consequence is that software organizations may deliver release 1.0 on a date(deadline). They have to release 1.1 immediately after the previous release by incorporating more features and fixing discovered bugs Lack of knowledge ○ A second obstacle is that many software developers do not seem to be familiar with industry best practices. Normally, software developers donot spend much time reading the literature to find out about the best known ways of software development. ○ Developer may buy books on Java, Visual Basic, or Oracle, but they do not have more knowledge on software process, testing, or software quality ○ The the industry awareness of process improvement -> ISO 9001, capability maturity model have introduced in recent years ○ They should know about these practices Wrong motivations ○ SOme organizations launch process improvement initiatives for wrong reasons. May be an external entity, such as a contractor, demanded that the development organization should achieve CMM level X by data Y. ○ Or a senior manager learned just enough about the CMM and directed his organization to climb on the CMM bandwagon Insufficient Commitment Product and Process Product ○ What is delivered to the customer, is called a product ○ It includes any software manufactured based on the customer's request. ○ It can be a problem-solving software or a computer-based system. ○ It is the result of the project ○ It is called source code, specification document, manual, documentation,etc ○ Basically, it is nothing but a set of deliverables only. Process ○ It is the way in which we produce software ○ It is the collection of activities that lead to a product ○ An efficient process is required to produce a good quality product ○ If the process is weak, the end product will undoubtedly suffer, but an obsessive over-reliance on the process is also dangerous. Software Product Process Product is the final production of the project A process is a set of sequences or steps that have to be followed to create a project A product focuses on the final result The process is focused on each step/stage that should be completed A product tends to be short-term The process tends to be long term In case of a product, the firm guidelines are In con followed Software Life Cycle Models The ultimate objective of software engineering is to produce good quality maintainable software within a reasonable time frame and at affordable cost. This is achievable only if we have matured processes to produce it. For a mature process, it should be possible to determine in advance how much time and effort will be required to produce the final product. This can be done using data from past experience, which requires that we must measure the software process. In immature organizations, the process is usually not written down. In mature organizations, the process is in writing and it is actively managed. A key component of the software development process is the lifecycle model on which the process is based. It is a period of time that starts when a software product is conceived and ends when the product is no longer available for use. It typically includes ○ Requirement phase ○ Design phase ○ Implementation phase ○ Test phase ○ Installation and checkout phase ○ operation and maintenance phase ○ Retirement phase A software life cycle model is a particular abstraction that represents a software life cycle. It is also called software development life cycle. A variety of life cycle models have been proposed based on tasks involved in developing and maintaining software. Build and Fix Model Sometimes, product is constructed without specifications or any attempt at design. Instead, the developer simply builds a product that is reworked as many times as necessary to satisfy the client. This is an adhoc approach and not well defined. Basically, it is a simple two phase model. The first phase is to write code and the next phase is to fix. Fixing in this context may be error correction or addition of further functionality Although this approach may work well on a small programming exercises 100 or 200 lines long But this approach is totally unsatisfactory for software of any reasonable size. WaterFall Model The most familiar model is the waterfall model. This model has five phases. ○ Requirement analysis and specification ○ Design ○ Implementation and unit testing ○ Integration and system testing ○ Operation and maintenance The phases always occur in this order and do not overlap. The developer must complete each phase before the beginning of the next phase This model is named Waterfall Model because its diagrammatic representation resembles a cascade of waterfalls. Requirement Analysis and Specification phase ○ This phase aims to understand the exact requirements of the customer and document them properly. ○ This activity is usually executed together with the customer, as the goal is to document all functions, performance, and interfacing requirements for the software. ○ The requirements describe the “what of a system”, not the “how”. ○ This phase produces a large document, written in natural language contains a description of what the system will do without describing how it will be done ○ The resultant document is known as a Software requirement specification(SRS) document. ○ THe SRS document may act as a contract between the developer and the customer. If developer fails to implement full set of requirements, it may lead to a failure to implement the contracted system. Design phase ○ The SRS document is produced in the previous phase, which contains the exact requirements of the customer. ○ The goal of this phase is to transform the requirements specifications into a structure that is suitable for implementation in some programming languages. ○ Here, overall software architecture is defined, and the high level and detailed design work is performed. ○ This work is documented and known as a software design description(SDD) document ○ The information contained in the SDD document should be sufficient to begin the coding phase. ○ Implementation and unit testing phase During this phase design is implemented. If the SDD is complete, the implementation or coding phase proceeds smoothly Because all the information needed by the software developers is contained in the SDD During testing, major activities are centered around the examination and modification of the code Initially, small modules are tested in isolation from the rest of the software product Integration and system testing phase This is very important phase. Effective testing will contribute to the delivery of higher quality software products, more satisfied users, lower maintenance costs, and more accurate and reliable results. It is a very expensive activity and consumes one-third to one-half of the cost of a typical development project The purpose of unit testing is to determine that each independent module is correctly implemented. This gives little chance to determine that the interface between modules is also correct-> so integration testing is used System testing involves the testing of the entire system where the software is part of the system This is essential to build confidence in the developers before software is delivered to the customer or released in the market Operation and maintenance phase Software maintenance is a task that every development group has to face when the software is delivered to the customer’s site, installed, and it is operational. Therefore, the release of the software inaugurates the operation and maintenance phase of the life cycle. The time spent and effort required to keep the software operational after release is very significant. Despite the fact that it is a very important and challenging task, it is routinely a poorly managed headache that nobody wants to face. Software maintenance is a very broad captivity that includes error correction, enhancement of capabilities, deletion of obsolete capabilities, and optimization. The purpose of this phase is to preserve the value of the software over time. This phase may span for 5 to 50 years whereas development may be 1 to 3 years. About the waterfall model. This model is easy to understand and reinforces the notion of define before design and design before code This model expects complete and accurate requirements early in the process, which is unrealistic Working software is not available until late in the possess, thus delaying the discovery of serious errors. It also does not incorporate any kind of risk assessment. Problems of waterfall models It is difficult to define all requirements at the beginning of the project This model is not suitable for accommodating any change A working version of the system is not seen until late in the project’s life. It does not scale up well to large projects. Real projects are rarely sequential Increment Process Models Increment process models are effective in situations where the requirements are defined precisely and there is no confusion about the functionality of the final product. Although functionality can be delivered in phases as per desired priorities. After every cycle, a usable product is given to the customer. For example, in the university automation software, the library automation module will be delivered in the first phase, examination automation module will be delivered in the second phase and the so on. Every new cycle will have an additional functionality Increment process models are popular particularly when we have to quickly deliver a limited functionality system. Iterative enhancement models ○ The aim of the waterfall and prototyping models is the delivery of a complete, operational, and good-quality product. ○ In contrast, this model does deliver an operational quality product at each release ○ Each release satisfies only a subset of customer requirements. ○ The complete product is divided into a set of releases, ○ The developer delivers the product release by release. ○ At each release, the customer has an operational quality product that does a portion of what is required. ○ The customer is able to do some useful work after the first release. ○ With this model, the first release may be available within few weeks or few months, whereas the customer generally waits months or years to receive a product using the waterfall and prototyping model, RAPID Application Development Models(RAD) This model is an incremental process model and was developed by IBM in the 1980s It is described in the book James Martin's Rapid Application Development User involvement is essential from the requirement phase to the delivery of the product. The continuous user participation ensures the involvement of user's expectations and perspectives in requirement elicitation, analysis, and design of the system. The process starts with building a rapid prototype and it is given to the user for evaluation The user feedback is obtained and a prototype is refined. The process continues till the requirements are finalized. We may use any grouping techniques (FAST, QFD, Brainstorming sessions) for requirements elicitation. Software requirements and specifications and design documents are prepared with the association of users. Requirement planning phase User description phase Construction phase Cut Over phase In this model, quick initial views about the product are possible due to the delivery of a rapid prototype. The development time of the product may be reduced due to use of powerful development tools. It may use CASE tools and frameworks to increase productivity involvemen Challenges In this case, continuous user involvement is necessary. If users can’t be involved throughout the life cycle, this may not be an appropriate model If reusable components are not available, development time may not be reduced significantly. Highly specialized and skilled developers are expected and such developers may not be available very easily. It may not be effective, if the system can not be properly modularised. Evolutionary Process Models The evolutionary model resembles to iterative enhancement model. The same phases as defined in the waterfall model occur here in a cyclical fashion. This model differs from iterative enhancement model in the sense that this does not require a usable product at the end of each cycle. In evolutionary development, requirements are implemented by category rather than by priority. In the case of the incremental model, The entire requirements are splitted into subsets and each module will be implemented in an incremental manner based on the priority. Usable product is released after each phase. 40% of requirements arrived after the beginning of development. But in the case of evolutionary approach, there is no restriction about a usable product. It is well suitable for where there are certain uncertainties , requirements cant be clearly defined. These models are useful for projects using new technology that is not well understood. This is also very useful for complex projects where all functionality must be delivered at one time , but the requirements are unstable and not well understood at the beginning. Prototyping model Spiral model Prototyping Model A disadvantage of the waterfall model is that the working software is not available until late in the process, thus delaying the discovery of serious errors. An alternative to this is to first develop a working prototype of the software instead of developing the actual software. The working prototype is developed as per current available requirements. Basically , it has limited functional capabilities, low reliability and untested performance(usually low). The developers use this prototype to refine the requirements and prepare the final specification document The working prototype has been evaluated by the customer, it is reasonable to expect that the resulting specific document will be correct. When the prototype is created, it is reviewed by the customer Typically, this review gives feedback to the developers that helps to remove certain uncertainties in the requirements of the software. And starts an iteration of refinement in order to further clarify requirements. The prototype may be a usable program, but it is not suitable as the final software product. The reason may be poor performance, maintainability, or overall quality. The code for the prototype is thrown away; however, the experience gathered from developing the prototype helps in developing the actual system. Therefore, the development of a prototype involve extra cost, but overall cost might turnout to be lower than that of an equivalent system developed using the waterfall model. The developer should develop a prototype as early as possible to speed up the software development process. After all, the sole use of this is to determine the customers real needs Spiral Model The problem with traditional software process models is that they do not deal sufficiently with the uncertainty, which is inherent to software projects. Important software projects have failed because project risks were neglected and nobody was prepared when something unforeseen happened. ○ Planning-Determination of objectives, alternatives, and constraints ○ Risk Analysis- Analyze alternatives and attempt to identify and resolve the risks involved. ○ Development-product development and testing product ○ Assessment- Customer evaluation During the first phase planning is performed, risks are analyzed, prototypes are built, customers will evaluate the prototype. During the second phase, a more refined prototype is built, requirements are documented and validated, and customers are involved in assessing the new prototype. By the time third phase begins, risks are known, and a somewhat more traditional development approach is taken. The focus is the identification of problems and the classification of these into different levels of risks, the aim being to eliminate high-risk problems before they threaten the software operation or cost An important feature of spiral model is that each phase is completed with areview by the people concerned with the project(designers and programmers). This review consists of a review of all products developed up to that point and it includes the plans for the next cycle. These plans may include a partition of the product in smaller portions for development or components that are implemented by individual groups or persons. If the plan for the development fails, then the spiral is terminated. Otherwise ite terminates with the initiation of new or modified software.