COE691 Week 1 Lecture PDF

Week1: Introduction to Software Engineering Dr. Rasha Kashef Agenda The Software… Software Engineering Definition and Scope The software problem Cost, Schedule, and Quality Software Development Process Software Life Cycle Software Process Models...

Week1: Introduction to Software Engineering Dr. Rasha Kashef Agenda The Software… Software Engineering Definition and Scope The software problem Cost, Schedule, and Quality Software Development Process Software Life Cycle Software Process Models Waterloo Fall, Prototyping, Iterative, Time-Boxing, and Agile Software? Software is considered to be collection of executable programming code, associated libraries and documentations ‘Software’ implies: large, robust, reusable, evolving Why we study software? Number #1 Reason: Teaches you HOW to DESIGN !! How to think about design, systematic problem solving Software systems? System Application Engineering/sci Embedded Product-line Web & Intelligent software: software: entific software: software: network systems: software: centric software: Software that such as stand-alone “Scientific- Software that Group of Software that uses non- compilers, programs for related” resides within a software that are built in numerical editors, file specific needs algorithms product or focus on a sophisticated algorithm to management system limited environments solve complex utilities marketplace to integrated with problem. address mass remote Robotics, consumer database and expert systems, market business pattern applications recognition What is Software Engineering (SE)? The application of a systematic, disciplined, quantifiable approach What is to the development, Software Engineering operation, (SE)? and maintenance of software (product), that is, the application of engineering to software. — IEEE Standard 610.12 Canadian Standards Association “The systematic activities involved in the design, implementation and testing of software to optimize its production and support” Software Engineering Scope Software Engineering is part of a much larger system design activities – Telephone switching systems, banking systems, hospital admin systems, aircraft Performing Software Engineering in the right procedure would requires a much larger look at system engineering issues – Entities and activities within the system, its interface with other systems and users Understanding the application and user needs is a key attribute in software development – Decide what activity should be supported by the system and how – Many domains, where very different software systems must be developed, with emphasis on different priorities: time-to-market (telecom), safety (aerospace, NASA Shuttle), maintainability (telecom, banking) 6 The Software Problem A Software means industrial strength software that solves a specific problem Three basic forces at play when developing industrial strength software: Cost Schedule Quality 1. Cost: Software Is Expensive Let us look at costs involved LOC: lines of code, PM: person-month Appx 1000 LOC/PM Cost per LOC (line of code) = $3 to $10 Cost = $3K to $10K/PM i.e., each line of delivered code costs many $$ A simple application for a business may have 20KLOC to 50KLOC Cost = $100K to $2.25Million Can easily run on $10K-$20K hardware So, Hardware costs in an IT solution are small as compared to Softare costs. 2. Schedule: Software Requires tight Schedule Business requirements today demand short delivery times for software In the past, software products have often failed to be completed in time Along with cost, cycle time is a fundamental driving force Productivity – for Cost and Schedule Both can be modeled by productivity. Productivity = output/input resources In Software systems, output is considered as LOC (lines of code), KLOC (thousands of lines of code) Input resources is effort - person months; overhead cost modeled in rate for person month Higher productivity leads to lower cost Higher productivity leads to lower cycle time Hence, for projects (to deliver software), quality and productivity are basic drivers 3. Software Quality Along with productivity, quality Developing high Quality Quality of software is harder to is the other major driving factor software is a basic goal define Quality – ISO standard: 6 Attributes Multiple dimensions mean that it is not Concept of Quality is project specific Reliability is generally considered the easy to map Quality to a single number main Quality criterion For some projects, reliability is most important For others, usability may be more important The Software Problem Schedule Productivity = output/input Quality Cost resources Cycle time is a 6 Attributes Measured by fundamental LOC Higher productivity leads to lower cost driving force Higher productivity leads to lower cycle time 1/14/21 Quality and Productivity Quality and productivity The aim of most Besides the need to (Q&P) are the basic methodologies is to achieve high Q&P there drivers in a software deliver software with a are some other needs project high Q&P Roles of people (Stakeholders) in software people involved in software production Customer /client: wants software built often does not know what he/she wants Managers / designers: plan software difficult to foresee all problems and issues in advance Developers: write code to implement software it is hard to write complex code for large systems Testers: perform quality assurance (QA) it is impossible to test every combination of actions Users: purchase and use software product users can misunderstand the product 15 Software Development Fundamentals Process: A particular method, generally involving a number of steps. A process is a Collection of activities, actions and tasks performed when some product is to be created. Software Process: A set of steps or activities, along with ordering constraints on execution, to produce software with desired outcome Many types of activities performed by different people Software process is comprising of many component processes 16 Software Development Process Process is distinct from Software Engineering Proper processes: product focuses on process Purpose is to deliver software product in timely manner, within Products are outcomes of project with sufficient executing a process on a project quality to satisfy clients/end users (i.e. high QP) Software Process 17 Key Processes Engineering Software Development Project Management Configuration Software Process management Change management Other Inspection process Process Improvement Process Software Process 18 SoftwareDevelopment Process Two major processes Engineering– “development and quality steps needed to engineer the software” Project management – “planning and controlling the development process” Key Roles Developers execute Engineering process Software architects, lead developers,... Project manager(s) executes the management process 19  3 Software Development Software Development Process A set of phases and each phase being a sequence of steps For each phase there are A variety of methodologies Corresponding to different sequence of steps for a phase Why have phases? To employ divide and conquer Each phase handles a different part of the problem Helps in continuous validation 21 Software Development Process Commonly has these activities/phases: 1. Requirements analysis 2. Design 3. Coding 4. Testing 5. Delivery 22 Basic Software Development Process Software Design Models 1. Procedural 2. Object Oriented 3. Logic 4. Functional Planning/Design & Documentation Phase 1: Requirement Analysis Forms the basis of State the problem Specifies “what” not agreement between precisely! “how” user and developer Requirement specifications of even Output is the Software Hard task - needs often medium systems can be Requirements Spec not understood well many hundreds of (SRS) document pages 24 Requirements Analysis The requirements The developers This is how the problem understood it in This is how the specification was is solved now that way problem was defined like this solved before. This is how the program is This, in fact, is what the described by marketing customer wanted … ;-) That is the program after department debugging Phase 2: Design A major step in moving from problem domain to solution domain Architecture design – components and connectors that should be there in the system Three main tasks High level design – modules and data structures needed to implement the architecture Detailed design – logic of modules Most methodologies focus on architecture or high-level design Outputs are architecture/description/logic design docs 26  Phase 3: Coding Converts design into code in specific language Goal: Implement the design with simple and easy to understand code Coding phase affects both testing and maintenance Well written code reduces testing and maintenance effort Output is code Software Process 27 Phase 4: Testing & Quality Assurance Defects are introduced in each phase Must be found and removed to achieve high quality Goal: Identify most of defects Very expensive task; must be properly planned and executed Outputs are Test plans/results, and the final tested (hopefully reliable) code 28 Phase 5: Delivery What the “Operations” group does. Varies by distribution model From a user’s perspective, it may be as important as design! Shrink Wrapped Software In house software Web-based Software As A Service (SaaS) … 29 Software Development Lifecycle Typical Effort Distribution Distribution of effort : Coding is not only the most expensive! Req. - 10-20% Design - 10-20% Coding - 20-30% Testing - 30-50% 31 When are defects introduced? Req. - 20% Distribution of error occurrences by Design - 30% phase is Coding - 50% Defects can be injected at any of the major phases. Cost of latency: Cost of defect removal increases exponentially with latency time. 32 Defects… Cheapest way to detect and remove defects close to where it is injected. Hence must check for defects after Cost to fix Error ( log scale) every phase. Time Software Process 33 Software Project and Process Model A process model specifies a general Project - to build a software system process that is optimal for a class of within cost and schedule and with problems. A process structure well high quality which satisfies suited for a class of projects. Best the customer practices -> recipe for success. Different process models perform A project may select its process the 5 phases of process using one of the process models development in different manner! 13 January 14, 2021 Process Models A software process model is an abstract representation of a process.It presents a description of a process from some particular perspective Traditional Modes Waterfall – the oldest and widely used Prototyping – Prototype, followed by Waterfall Iterative – used widely in product dev Timeboxing – Iterative 2.0 Modern Models Agile - Lightweight" methodologies (Speaker), Agile model is best suitable for mobile applications Software Process 35 1. Waterfall Model Linear sequence of stages/phases Requirements -> High Level Description –> Detailed Design –> Code –> Test –> Deploy A phase starts only when the previous has completed; no feedback! The phases partition the project, each addressing a separate concern Software Process 36 1. Waterfall Model Requirements definition System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance January 14, 2021 37 1. Waterfall Model Linear ordering implies each phase should have some output The output must be validated/certified Outputs of earlier phases: work products Common outputs of a waterfall: SRS, project plan, design docs, test plan and reports, final code, supporting docs January 14, 2021 38 1. Waterfall Model Advantages and Disadvantages Advantages Disadvantages Natural approach Inflexible partitioning of the Waterfall model describes a for problem solving project into distinct stages process of stepwise This makes it difficult to refinement Conceptually respond to changing Ø Widely used in military, simple, divides the customer requirements healthcare and aerospace industries problem into Therefore, this model is only distinct independent appropriate when the phases requirements are well- understood Easy to administer in a contractual setup – each phase is a milestone Software Process 39 2. Prototyping Model Used for risky/unfamiliar projects Addresses the requirement specification limitation of waterfall Instead of freezing requirements only by discussions, a prototype is built to understand the requirements Helps alleviate the requirements risk, Expect to “throw away” first version A small waterfall model replaces the requirements stage Software Process 40 2. Prototyping Model: Development of a prototype Starts with initial requirements Only key features which need Cost can be kept low better understanding are Build only features needing clarification included in the prototype Things like exception handling, recovery, standards are omitted No point in including those Cost can be a few % of the total features that are well understood Learning in prototype building will help in building, besides improved requirements Feedback from users taken to improve the understanding of the requirements Software Process 41 2. Prototyping Model Advantages and Disadvantages Advantages Disadvantages Applicability: Requirement will be Potential hit on cost and When requirements are more stable and more schedule hard to elicit likely to satisfy user Potential false sense of When confidence in needs security if prototype does requirements is low Early opportunity to not focus on key (high risk) Where requirements are explore issues not well understood scale/performance issues When design is driven by Ability to modify or user needs cancel the project early Enhanced user engagement Software Process 42 3. The Iterative Model Counters the “all or nothing” drawback of the waterfall model Combines benefit of prototyping and waterfall Develop and deliver software in increments Each increment is complete in itself Can be viewed as a sequence of Most Software Products follow it waterfalls Used commonly in customized development Newer approaches like XP, Agile,… all rely on Feedback from one iteration is used iterative development in the future iterations Software Process 43 3. Iterative Model Advantages and Disadvantages Advantages Disadvantages Applicability: Get-as-you-pay where response time is Architecture/design may important Feedback for not be optimal All requirements are not improvement known Amount of refactoring may increase Execution Total cost may increase Each iteration is a mini waterfall – decide the specs, then plan the iteration Length of iteration driven by amount of new functionality to be added in an iteration Software Process 44 4. Time boxing Time boxing is like Linear Timeboxing Iterative development TB1 Requirements Build Deploy but TB2 Requirements Build Deploy fix an iteration duration, then determine the specs Pipelined Timeboxing Software Divide iteration in a few equal stages TB1 Requirements Build Deploy Use pipelining concepts TB2 Requirements Build Deploy to execute iterations in TB3 Requirements Build Deploy parallel Requirements Build Deploy TB4 Software Process 45 4. Time boxing General iterative development – fix the functionality for each iteration, then plan and execute it In time boxed iterations – fix the duration of iteration and adjust the functionality to fit it Completion time is fixed, the functionality to be delivered is flexible Software Process 46  39 4. Time boxing: Example An iteration with three stages – Requirements (R), Build (B), Deploy (D) Linear Timeboxing These stages are appx equal in many situations TB1 Requirements Build Deploy Can adjust durations by determining the boundaries suitably TB2 Requirements Build Deploy Can adjust duration by adjusting the team size for each stage Have separate teams for R, B, and D Each iteration takes time T, Assume T is 3 weeks, Pipelined Timeboxing In Linear Timeboxing Delivery times will be 3 wks, 6 wks, 9 wks,… In Pipelined Timeboxing First iteration finishes at time T Second finishes at T+T/3; third at T+2 T/3, and so on In steady state, delivery every T/3 time first delivery after 3 wks, 2nd after 4 wks,3rd after 5 wks,… 4. Time boxing Execution and team Sizes Team Size Duration of each In linear execution of Timeboxing allows iteration still the same iterations, the same team structured way to add performs all stages manpower to reduce cycle Total work done in a time box is also the If each stage has a team of time same size S, in linear execution Note that we cannot the total team size is S change the time of an Productivity of a time box is same In pipelined execution, the iteration – Brook’s law still total team size is three Yet, average cycle time times (one for each stage) holds or delivery time has Work allocation different to Total team size in reduced to a third timeboxing is larger; and allow larger team to this what reduces cycle time function properly Software Process 48 4. Time boxing Model Advantages and Disadvantages Advantages Disadvantages Applicability: Shortened delivery Larger teams, When short delivery times by use of project management is times is VERY important; additional harder architecture is stable; manpower, Increases flexibility in feature flexibility high synchronization needed grouping Software Process 49 5. The Agile Model Key Assumptions – Difficult to predict software requirements – Difficult to predict analysis, design, construction, and testing – Design and construction should be interleaved How can we design a process that can manage unpredictability? Process adaptability. Example: Extreme Programming (XP) – 4 phases: Planning (stories), Design (prototype solutions), Coding (pair programming, re-factoring), Test – The tests are the specification – Communication paramount (small team, knowledgeable programmers) 50 Summary Process is a means to achieve project objectives of high Q&P Process models define generic process, which can form basis of project process Process typically has stages, each stage focusing on an identifiable task Many models for development process have been proposed A project should select a process model that is best suited for it (and tailor it to meet its requirements) Software Process 51  52 Next Class Software Modeling Tools Introduction to Requirements Analysis and Specifications