Introduction to Software Engineering (PDF)
Document Details

Uploaded by PromptHeptagon
Mehroze Khan
Tags
Summary
This document is an introductory lecture on software engineering. It covers the software lifecycle, including phases such as analysis, design, coding, and testing. It also discusses the roles within a software development team, including analysts, designers and programmers. Slides are presented by Mehroze Khan.
Full Transcript
Introduction to Software Engineering Instructor: Mehroze Khan Software is: What is (1)instructions (computer programs) that when executed provide desired features, function, and performance Softwar (2)data structures that enable the programs to adequately manipulate inform...
Introduction to Software Engineering Instructor: Mehroze Khan Software is: What is (1)instructions (computer programs) that when executed provide desired features, function, and performance Softwar (2)data structures that enable the programs to adequately manipulate information e? (3)documentation that describes the operation and use of the programs. 2 Failure Curve for Hardware 3 Software doesn't Failure Curve for Software "wear out“. But it does deteriorate! 4 Why is SE Needed? Computers everywhere Toaster, Microwave, Temperature control of A/C, Router, Surgical Equipment… Computers need to be managed Software runs on all computers Make lives comfortable, efficient, effective… SE practices ensure development of good software to improve our living standard 5 Why Do We Need to Study SE? What could be the benefits? 6 Solving Problems Analysis 7 Solving Problems (continued) Synthesis 8 Legacy Software Why must it change? 1 2 3 4 software must software must software must software must be adapted to be enhanced to be extended to be re-architected meet the needs implement new make it to make it viable of new business interoperable within a network computing requirements. with other more environment. environments or modern systems technology. or databases. 9 Software? Computer programs along with associated configuration data and documentation s.t. the programs are correctly operated Configuration data helps set up the programs System documentation helps understand structure of the system User documentation explains how to use the system 10 Engineering? Engineers’ Job? Make things work Apply theories, methodologies, tools appropriately Provide solutions in absence of applicable theories and methods Realize financial and organizational constraints 11 Aspects of Software Production? Technical process of developing software Activities such as management of project and teams Development of tools, theories, methods to support production of software 12 Who Does Software Engineering? Participants (stakeholders) in a software development project 13 Development Team Requirement analysts: work with the customers to identify and document the requirements Designers: generate a system-level description of what the system is supposed to do Programmers: write lines of code to implement the design Testers: catch faults Trainers: show users how to use the system Maintenance team: fix faults that show up later Librarians: prepare and store documents such as software requirements Configuration management team: maintain correspondence among various artefacts 14 Development Team (Roles) Who Does What? 15 Development Team (Roles) 16 Paradig Resource m s Process Software Skillset Engineering Lifecycle Requirements Design Coding Testing Deployment Maintenance Analysis Typical phases in lifecycle of software 17 Software Lifecycle Phases Requirements analysis and definition System (architecture) design Program (detailed/procedural) design Writing programs (coding/implementation) Testing: unit, integration, system System delivery (deployment) Maintenance 18 Software Engineers? Adopt a systematic and organized approach, effectively, to produce high quality software 19 What is a Good Software Product? Good software engineering must always include a strategy for producing quality software Product Quality? Multiple facets… 20 What is a Good Software Product? Users judge external characteristics (e.g., correct functionality, number of failures, type of failures) Designers and maintainers judge internal characteristics (e.g., ease of modification) Thus, different stakeholders may have different criteria Need quality models 21 McCall’s Quality Model 22 Lehman’s Laws (1974) "Continuing Change" — A system must be continually adapted or it becomes progressively less satisfactory. It happens so until it becomes economical to replace it by a new or a restructured version (1974) "Increasing Complexity/Entropy" —Complexity/entropy of a system increases with time, unless work is done to maintain or reduce it (1991) "Continuing Growth" — the functional content of a system must be continually increased to maintain user satisfaction over its lifetime (1996) "Declining Quality" — the quality of a system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes 23 Software Engineering Challenges Acceptable Quality Usability Security Reliability Conflicts? Performance Cost Effectiveness Engineering and operational feasibility Limited development budget Timely Completion Limited time Manage Conflicts… 24 Software Engineering Disciplined, consistent, and systematic effort to construct (design + build) and maintain good quality software in timely and cost-effective manner 25 Terminology for Describing Bugs A fault: occurs when a human makes a mistake, called an error, in performing some software activities A failure: is a departure from the system’s required behaviour 26 Elements of a System Activity: An activity is something that happens in a system. Usually described as an event initiated by a trigger, the activity transforms one thing to another by changing a characteristic. Objects: The elements involved in the activities are called objects or entities. Relationships: Once entities and activities are defined, we match the entities with their activities. The relationships among entities and activities are clearly and carefully defined. System Boundary: Who generates input and who receives output Which objects/activities are part of the system and which are not Nested systems, related systems, interrelated systems 27 A Systems Approach (Contd.) Example of systems: a human respiratory system ?? 28 A Systems Approach (Contd.) A computer system must also be clearly described: System definition of a paycheck production 29 An Engineering Approach Idea to build a house Asking someone to build the house Explaining requirements Getting designs Modifying + Approving designs Inspecting the construction Building a Adding new features House Testing household components Moving in Getting issues fixed after moving in 30 An Engineering Approach Determine and Analyze Requirements Produce and Document Overall Design Produce Detailed Specifications Identify and Design Components Build Components Test Components Building a Integrate Components Make final modifications after residents House move in Continue Maintenance by the Residents 31 An Engineering Approach Requirement analysis and definition System design Program design Writing the programs Unit testing Integration testing Building a System testing System System delivery Maintenance 32 A Process Framework Process framework Framework Activities work tasks Work products Milestones & deliverables QA checkpoints Umbrella Activities 33 Communication Planning Framewo rk Analysis of Modeling requirements Design Activities Code generation Construction Testing Deployment 34 Software project tracking and control Umbrell Risk management a Software quality assurance Technical reviews Activitie Software configuration management s Reusability management Work product preparation and production 35 References 1. Shari Lawrence PFleeger and Joanne M. Atlee, Software Engineering Theory and Practice, Fourth Edition 2. Roger Pressman, Software Engineering: A Practitioner’s Approach 3. Ghezzi et al., Fundamentals of Software Engineering 4. Book slides from UCF Acknowledgement  A few slides have been reused from UCF slides for the SE course 36