CSE 305 Software Engineering PDF

CSE 305 SOFTWARE ENGINEERING 1 WELL-KNOWN SOFTWAREENGINEERING FAILURES On 4 June 1996 the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the fligh...

CSE 305 SOFTWARE ENGINEERING 1 WELL-KNOWN SOFTWAREENGINEERING FAILURES On 4 June 1996 the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher diverted off its flight path, broke up and exploded 2 Reason for Failure -Ariane 5 Rocket Integer Over flow An integer overflow occurs when an arithmetic operation attempts to create a numeric value that is outside of the range that can be represented with a given number of digits – either higher than the maximum or lower than the minimum representable value 3 Y2K (1999-2000) Cost–$500,000,000,000 Disaster Businesses spent billions on programmers to fix a glitch in old software Cause To save computer storage space, old software systems often stored the years as two digit numbers The software interpreted “00” to mean 1900 rather than 2000 All sorts of bugs were thought likely 4 What is Software ? A program is set of instructions Software can define as: Set of Instructions/ programs – executed provide desire features, function & performance Documentation Operation Manuals 5 Software Documentation manuals: Requirement Analysis ⬥ Formal specification, context-diagram, DFD Software Design ⬥ Flow charts, ER Implementation ⬥ Source code, Cross Reference listing Testing ⬥ Test data, Test results Operation Manuals : User manuals System overview, Beginners user tutorial, reference guide, reference guide Operation manuals Installation guide, System administration guide 6 Computer Science: A definition “Computer science is a discipline that involves the understanding and design of computers and computational processes. It is a broad scientific topic. It includes the study of how data is processed, the security of networks, organizing databases, artificial intelligence, etc. 7 Software Product Vs Process Software Product: what is delivered to the customer. It may include source code, specification document, manuals, documentation, etc. Software Process: Process is the way in which produce the software. 8 Software Process Reasons why it is difficult to improve the process No enough time Lack of knowledge Wrong motivations Insufficient commitment 9 Software Process 10 Hardware vs. Software Hardware Software □ Manufactured □ Developed/ engineered □ wear out □ deteriorate □ Built using components □ Custom built □ Relatively simple □ Complex 11 Manufacturing vs. Development Once a hardware product has been manufactured, it is difficult or impossible to modify. In contrast, software products are routinely modified and upgraded. In hardware, hiring more people allows you to accomplish more work, but the same does not necessarily hold true in software engineering. Unlike hardware, software costs are concentrated in design rather than production. 12 Failure curve for Hardware 13  Failure curve for Software 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 design was translated into machine executable code. 14 Software characteristics Software is developed or engineered; it is not manufactured. Software does not “wear out” but it does deteriorate. Software continues to be custom built, as industry is moving toward component based construction. Reusability of components. Software is flexible. 15 Software Application Domains System software Application software Engineering/scientific software Embedded software Product line software Web applications Artificial intelligence software 16 Software Application Domains System Software: System software is a collection of programs written to service other programs. It is characterized by heavy interaction with computer hardware; heavy usage by multiple users; concurrent operation that requires scheduling, resource sharing, and sophisticated process management; complex data structures; and multiple external interfaces. Ex. Compilers, operating system, drivers etc. Business Software : Application software consists of standalone programs that solve a specific business need. Application software is used to control the business function in real-time. Engineering /Scientific software: Characterized by "number crunching" algorithms. Applications range from astronomy to volcano logy, from automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing. Ex. Computer Aided Design (CAD), system stimulation etc. 17 Software Application Domains Embedded Software: It resides in read-only memory and is used to control products and systems Embedded software can perform limited functions. Ex. keypad control for a microwave oven. Personal Computer software: Designed to provide a specific capability for use by many different customers, product line software can focus on a limited and esoteric marketplace. Ex. Word processing, spreadsheet, CG, multimedia, etc. Web Applications: Web apps can be little more than a set of linked hypertext files. It is evolving into sophisticated computing environments that not only provide standalone features, functions but also integrated with corporate database and business applications. Artificial Intelligence software AI software makes use of non-numerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis Ex. Robotics, expert system, game playing, pattern Recognition, ANN etc. 18 Software Applications – New Open world computing—pervasive, distributed computing Ubiquitous computing—wireless networks Netsourcing—the Web as a computing engine Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) And also … Data mining Grid computing Cognitive machines Software for nanotechnologies 19 Engineering “The systematic and regular application of scientific and mathematical knowledge to the design, construction, and operation of machines, systems, and so on of practical use and, hence, of economic value. Particular characteristic of engineers is that they take seriously their responsibility for correctness, suitability, and safety of the results of their efforts. In this regard they consider themselves to be responsible to their customer (including their employers where relevant), to the users of their machines and systems, and to the public at large.” 20 Engineering 21 Software Engineering Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings. According to Fritz Bauer :Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. According to IEEE : Software Engineering is a a systematic, disciplined, quantifiable approach to the development, operation, and maintenance 22of Why need Software Engineering? It allows you to improve the quality of the software products. To increase productivity & provide job satisfaction to software professionals. It will enable you to control software schedules and to plan effectively. It helps to reduce the cost of software development. Allow you to meet the customers' needs and requirements. It helps you to support the engineers' activities systematically and efficiently. 23 Software myths Software is easy to change. Computers provide greater reliability than the devices they replace. Testing software can remove all the errors. Reusing the software increases the safety. Software can work right the first time. Software can be designed thoroughly enough to avoid most integration problems. Software with more features is better software. Addition of more software engineers will make up the delay. Aim to develop working programs. 24 25  Course Page Moodle Page—Go to the URL bellow http://lms.srmap.edu.in/moodle/ Access the course CSE 305 Software Engineering - Even Sem 2022 Google Classroom Breakout Software Process Software Process: Process is the way in which produce the software. 28 Software Engineering: A Layered Technology 29 Layered Technology A quality Focus Every organization is rest on its commitment to quality. Total Quality Management, Six Sigma, or similar continuous improvement culture and it is this culture ultimately leads to development of increasingly more effective approaches to software engineering. The bedrock that supports software engineering is a quality focus. Process: It is a foundation layer for software engineering. It defines framework for a set of Key Process Areas 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 30  Layered Technology Methods: It provides the technical how-to's for building software. Methods encompass a broad array of tasks that include requirements analysis, design, program construction, testing, and support. There could be more than one technique to perform a task and different techniques could be used in different situations. Tools: Provide automated or semi-automated support for the process, methods and quality control. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called Computer-Aided Software Engineering (CASE) A Generic Software Process Model A software process – as a framework for the tasks that are required to build high-quality software. 32  Process framework Why process : A process defines who is doing what, when and how to reach a certain goal. To build complete software process. Identified a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. It encompasses a set of umbrella activities that are applicable across the entire software process. 33 Process Framework Each framework activities is populated by a set for software engineering actions – a collection of related tasks. Each action has individual work task. 34 Generic Process Framework Activities 1. Communication: Heavy communication with customers, stakeholders, team members Encompasses requirements gathering and related activities 2. Planning: Workflow that is to follow Software project plan- describe technical task, likely risk, resources will require, work products to be produced and a work schedule. 35 Generic Process Framework Activities 3. Modeling: Help developer and customer to understand requirements (analysis of requirements) & design of software 4. Construction: Code generation: either manual or automated or both Testing – to uncover error in the code 5. Deployment: Delivery to the customer for evaluation Customer provide feedback 36 Umbrella Activities Software project tracking and control Assessing progress against the project plan Take adequate action to maintain schedule Formal technical reviews Assessing software work products in an effort to uncover and remove errors before goes into next action or activity Software quality assurance Define and conducts the activities required to ensure software quality Software configuration management Manages the effects of change 37 Umbrella Activities Document preparation and production Help to create work products such as models, documents, logs, form and list. Reusability management Define criteria for work product reuse Mechanisms to achieve reusable components. Measurement Define and collects process, project, and product measures Assist the team in delivering software that meets customer’s needs. Risk management 38 Assesses risks that may affect that outcome of project or quality  Process Flow Process Flow– describes how framework activities and actions (in it) are organized w.r.t sequence and time. 39 Process Flow (Contd.) Linear process flow executes each of the five activities in sequence. An iterative process flow repeats one or more of the activities before proceeding to the next. 40  Process Flow (Contd.) An evolutionary process flow executes the activities in a circular manner. Each circuit leads to a more complete version of the software. A parallel process flow executes one or more activities in parallel with other activities modeling for one aspect of the software in parallel with construction of another aspect of the software. 41 Identifying a Task Set Before proceeding with the process model: what actions are appropriate for a framework activity given the nature of the problem, the characteristics of the people and the stakeholders? A task set defines the actual work to be done to accomplish the objectives of a software engineering action. A list of the task to be accomplished A list of the work products to be produced A list of the quality assurance 42 filters to be applied  Identifying a Task Set For example, requirements gathering (elicitation) is an important software engineering action that occurs during the communication activity. Requirements gathering is also to understand what various stakeholders want from the software that is to be built. 43  Example of a Task Set The task sets for requirements gathering action for a simple project may include: Make a list of stakeholders for the project. Invite all stakeholders to an informal meeting. Ask each stakeholder to make a list of features and functions required. Discuss requirements and build a final list. Prioritize requirements. Note areas of uncertainty. 44  Example of a Task Set The task sets for requirements gathering action for a big project may include: 1. Make a list of stakeholders for the project. 2. Interview each stakeholder separately to determine overall wants and needs. 3. Build a preliminary list of functions and features based on stakeholder input. 4. Schedule a series of facilitated application specification meetings. 5. Conduct meetings. 6. Produce informal user scenarios as part of each meeting. 45  Example of a Task Set 7. Refine user scenarios based on stakeholder feedback. 8. Build a revised list of stakeholder requirements. 9. Use quality function deployment techniques to prioritize requirements. 10. Package requirements so that they can be delivered incrementally. 11. Note constraints and restrictions that will be placed on the system. 12. Discuss methods for validating the system. 46 47 Process Models Process Patterns A process pattern: describes a process-related problem that is encountered during software engineering work, identifies the environment in which the problem has been encountered, and suggests one or more proven solutions to the problem. It provides a template, a consistent method for describing problem solutions within the context of the software process. 49 Process Pattern Types Stage patterns—defines a problem associated with a framework activity for the process. Task patterns—defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice. Phase patterns—define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature. 50 Process Assessment & Improvement Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting and learning. CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a diagnostic technique for assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the assessment [Dun01] 51 Process Assessment and Improvement SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessment. The intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any defined software process. [ISO08] ISO 9001:2000 for Software—a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides. Therefore, the standard is directly applicable to software organizations and companies. [Ant06] 52  Software process model Process models prescribe a distinct set of activities, actions, tasks, milestones, and work products required to engineer high quality software. Process models are not perfect but provide roadmap for software engineering work. Software models provide stability, control, and organization to a process that if not managed can easily get out of control. Software process models are adapted to meet the needs of software engineers and managers for a specific project. Build and Fix Model Build and Fix Model The earlier approach. Product is constructed without specification or any attempt at design. Developers simply build a product that is reworked as many times as necessary to satisfy the client. Model may work for small projects (e.g.,100-200 LOC) but is totally unsatisfactory for products of any reasonable size. Maintenance is high. Prescriptive Model Prescriptive process models advocate an orderly approach to software engineering Organize framework activities in a certain order Process framework activity with set of software engineering actions. Each action in terms of a task set that identifies the work to be accomplished to meet the goals. Prescriptive Model The resultant process model should be adapted to accommodate the nature of the specific project, people doing the work, and the work environment. Software engineer choose process framework that includes activities like; Communication Planning Modeling Construction Deployment The Waterfall Model Also called as classical/linear model. It is the oldest paradigm for SE. When requirements are well defined and reasonably stable, it leads to a linear fashion. 58 Waterfall Model (contd.) Requirement Analysis and Definition: systems services, constraints and goals are defined by customers with system users. Scheduling tracking: Assessing progress against the project plan. Require action to maintain schedule. System and Software Design: establishes and overall system architecture. Software design involves fundamental system abstractions and their relationships. Waterfall Model (contd.) 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. 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. Waterfall Model - Examples In the olden days, Waterfall model was used to develop enterprise applications like Customer Relationship Management (CRM) systems, Human Resource Management Systems (HRMS), Supply Chain Management Systems, Inventory Management Systems, Point of Sales (POS) systems for Retail chains etc. Waterfall is still widely used in traditional organizational environments and processes. Research shows that 51% of organizations still use Waterfall, based on a 2017 report from the Project Management Institute. Waterfall Model - Advantages All phases are clearly defined. One of the most systemic methods for software development. Being oldest, this is one of the time-tested models. It is simple and easy to use. Waterfall Model - Drawbacks Difficult to define the all the requirements at the beginning of the project. 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. The V-Model A variation of waterfall model depicts the relationship of quality assurance actions to the actions associated with communication, modeling and early code construction activates. Team first moves down the left side of the V to refine V the problem requirements. E V R A Once code is generated, I L F the team moves up the I I D right side of the V, C A performing a series of tests A T T I that validate each of the I O models created as the O N team moved down the left N side. 10 65 Incremental Process Model C- Communication P - Planning M – Modeling C - Construction D - Deployment Delivers software in small but usable pieces, each piece builds on pieces already delivered The Incremental Model Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. First Increment is often core product Includes basic requirement Many supplementary features (known & unknown) remain undelivered A plan of next increment is prepared Modifications of the first increment Additional features of the first increment The Incremental Model It is particularly useful when enough staffing is not available for the whole project. Increment can be planned to manage technical risks. Incremental model focusses more on delivery of operation product with each increment. Incremental Model - Advantages Rigid nature of sequential approach. This method is great help when organization is low on staffing. Generate working software quickly and early during the software life cycle. More flexible – less costly to change scope and requirements. Easier to test and debug during a small iteration. Easier to manage risk because risky pierces are identified and handled during its iteration. Each increment is an easily managed milestone. Incremental Model -Disadvantages This model could be time consuming. Each phase of an increment is rigid and do not overlap each other. Problems may arise in system architecture; all the requirements are not gathered up entire software life cycle. Evolutionary Process Model Produce an increasingly more complete version of the software with each iteration. Evolutionary Models are iterative. Evolutionary models are: Prototyping Spiral Model Concurrent Development Model Evolutionary Models: Prototyping Quick plan communication Modeling Quick design Deployment Construction delivery & of prototype feedback Construction of prototype 72 Prototyping cohesive Best approach when: Objectives defines by customer are general but does not have details like input, processing, or output requirement. Developer may be unsure of the efficiency of an algorithm, O.S., or the form that human machine interaction should take. It can be used as standalone process model. Model assist software engineer and customer to better understand what is to be built when requirement is Prototyping cohesive Prototyping start with communication, between a customer and software engineer to define overall objective, identify requirements and make a boundary. Going ahead, planned quickly and modeling (software layout visible to the customers/end-user) occurs. Quick design leads to prototype construction. Prototype is deployed and evaluated by the customer/user. Feedback from customer/end user will refine requirement and that is how iteration occurs during prototype to satisfy the needs of the customer. Prototyping (cont..) Prototype can be serve as “the first system”. Both customers and developers like the prototyping paradigm. Customer/End user gets a feel for the actual system Developer get to build something immediately. Prototyping - Disadvantages Customer cries foul and demand that “a few fixes” be applied to make the prototype a working product, due to that software quality suffers as a result. Developer often makes implementation in order to get a prototype working quickly without considering other factors in mind like OS, Programming language, etc. Customer and developer both must be agree that the prototype is built to serve as a mechanism for defining requirement. Evolutionary Models: The Spiral 77 Spiral Model Combines iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. It provides potential for rapid development of increasingly more complete version of the software. Using spiral, software developed in as series of evolutionary release. Early iteration, release might be on paper or prototype. Later iteration, more complete version of software. Spiral Model Divided into framework activities (C,P,M,C,D). Each activity represents one segment. Evolutionary process begins in a clockwise direction, beginning at the center risk. First circuit around the spiral might result in development of a product specification. Subsequently, develop a prototype and then progressively more sophisticated version of software. Unlike other process models that end when software is delivered. It can be adapted to apply throughout the life of software. Spiral Model - Advantages It is realistic approach for development for large scale system. High amount of risk analysis. Good for large and mission-critical projects. Software is produced early in the software life cycle. Spiral Model - Disadvantages It is not widely used and can be a costly to use. Risk analysis requires highly specific expertise. Project’s success is highly dependent on the risk analysis phase. Doesn’t work well for smaller projects. It demands considerable risk assessment expertise and relies on this expertise for success. It may be difficult to convince customers that the evolutionary approach is controllable. 82 Quiz 2 Breakout More Process Models Concurrent Development Model It represented schematically as series of major technical activities, tasks, and their associated states. It is often more appropriate for system engineering projects where different engineering teams are involved. The activity-modeling may be in any one of the states for a given time. Evolutionary Models: Concurrent 87 Concurrent Development Model All activities exist concurrently but reside in different states. The analysis activity (existed in the none state while initial customer communication was completed) now makes a transition into the under-development state. Analysis activity moves from the under-development state into the awaiting changes state only if customer indicates changes in requirements. Series of event will trigger transition from state to state. E.g. during initial stage there was inconsistency in design which was uncovered. This will trigger the analysis action from the done state into awaiting changes state.  Specialized Process Models Component based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements Aspect Oriented software development (AOSD) —provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) 89 SDLC: Component Based Development  CBD model (cont.) Modeling and construction activities begin with identification of candidate components. Classes created in past software engineering projects are stored in a class library or repository. Once candidate classes are identified, the class library is searched to determine if these classes already exist. If class is already available in library extract and reuse it. If class is not available in library, it is engineered or developed using object-oriented methods. Any new classes built to meet the unique needs of the application. Now process flow return to the spiral activity. CBD model - Advantages CBD model leads to software reusability. Based on studies, CBD model leads to 70 % reduction in development cycle time. 84% reduction in project cost. Productivity is very high.