Midterm-Prep.pdf

Midterm Prep ITSC 3155 – Software Engineering Department of Computer Science College of Computing and Informatics 1 Introduction to Software Engineering 2  What is Software Engineering? Software engineering is “a s...

Midterm Prep ITSC 3155 – Software Engineering Department of Computer Science College of Computing and Informatics 1 Introduction to Software Engineering 2  What is Software Engineering? Software engineering is “a systematic approach to the analysis, design, assessment, implementation, test, maintenance and reengineering of software”, that is, the application of engineering to software. Designing Maintenance Nobody seems to know and Any method you use to make a Planning Testing everyone has an opinion! software can be considered Software Engineering Software Deployment Development Engineering Software Production Techniques! 3  Software Engineering Functions Evaluate final product and Determine needs and constraints documentation by analyzing system requirements Verification, allocated to software Requirement Validation Analysis and Testing Process Software Determine ways to satisfy Control Design requirements and constraints, analyze possible solutions and select the optimum one. Determine methods for controlling project and process, measure progress, and take corrective action where necessary Process Planning Determine product development tasks, precedence, and potential risks to the project 4  What does a software engineer do? Extracting requirements Analyzing requirements Writing software requirements documents Software Engineer Time Building and analyzing prototypes Developing software designs Writing software design documents Researching application domain. Developing test strategies and test cases Testing the software and recording the results. Isolating problems and solving them Learning how to use new software and hardware tools or install and set them up Writing Code Other Writing other documentation such as users manuals Attending meetings with colleagues, customers, and supervisors. Archiving software or getting it ready for distribution 5 Requirements Engineering 6  Software Development Life Cycle The Software Development Life Cycle (SDLC) is a structured process that enables the production of high- quality and low-cost software, in the shortest possible production time. Defines and outlines a detailed plan to meet all customer expectations and demands. Concept What Requirements How Design Implementation Build Test Verification Maintenance Bugs, Feature,.. Laplante, Philip A. What every engineer should know about software engineering. CRC Press, 2007. Software Waterfall representation of SDLC Quality Cost Time 7  Requirements vs. Specification Requirement – A non-technical definition of features that users expect from the system. No JARGON! Specification – A technical definition of what is required for building system. We aren't trying to design it, so KEEP IT SIMPLE! User Requirements vs System Specification 8  Functional vs. Non-Functional Requirements Functional : A developer must implement these requirements so that users can achieve their goals with the product. o What should the program do? ▪ Send email when a new customer signs up. ▪ Open a new account Non-Functional : Place constraints on what goals should be met in the product. o Cover areas that don't directly effect the function of the program. They are typically constraints. These constraints might be implemented by the government (safety regulations), the company (quality regulations), or the client. ▪ Modifying data in a database should be updated within 2 seconds.9  Characteristics of Requirements Characteristics of Good Requirements Symptoms of Poor Requirements Process O'Regan, Gerard. Concise guide to software engineering. Springer, Cham, 2017 10  WRSPM Reference Model The World Machine Model Understand the difference between the requirement and the specification Determine what software specifications we need to constrain the solution based on user requirements. World: The world assumptions influence our system and our problem domain, since we recognize that they are true. Requirements: This is what the user understands about what customer wants from the solution in their own language. Specifications: It is the interface between how the system will meet user requirements which is technical requirements. Program: Code and programs that meet the specifications in accordance with user requirements. Machine: hardware specification. User visible elements W R S P M System side elements Environment System Interface 11 Software Design 12  Software Design Principles The design should be reviewed focusing on both the during the evaluation, the quality of goal and other effects. the design needs to be checked should satisfy all the requirements it should work properly even if an error occurs software should adjust reduce the gap between Source real-world problems and to the change software solutions uniform throughout the process without any change 13 and all parts of software should be mixable  Software Architecture Is often modelled with block diagrams Very top level of design. How software pieces fit together at a high level. Link between idea, and reality. Good Architecture: Faster development. Reduce overall idle time. Maintainable software. Architecture mistakes cannot be corrected once coding has begun. Image link 14 MVC Architecture Pattern Web frameworks such as Django, Laravel,… Organizes large-size web applications. Easily Modifiable Faster Development Process. Easy planning and maintenance. Supports TTD (test-driven development). Image link 15  Microservices Architecture Pattern Microservice are small business services that can work together and can be deployed independently. Benefits Drawbacks Agility Complexity Small, focused teams Network problems and latency Small and Separated Code Base Development and Testing Right tool for the job Data Integrity Fault Isolation Scalability Data isolation 16  Design Activities 1. Architecture Design of system with all subsystems 2. Abstract specification of each subsystem 3. Interface Design for each subsystem 4. Component Design 5. Data Structure Design 6. Algorithm Design 17  UML Diagram Class Diagram Object Diagram Deployment Diagram Use Case Diagram Sequence Diagram Source 18 Agile Software Development 19 Agile Mindset Image Link You will be disappointed if you use agile as a project management tool. Instead of working on agile practices, you should think like an agile team. Rather than being masters of them, try to find the reasons behind them instead. Self-organization is one of the key characteristics of agile teams, because it's very difficult to manage a team with a top-down approach 20 Agile Manifesto Values Individual and interactions Process and tools Working software Comprehensive documentation Customer collaboration Contract Negotiation Responding to change Following plan 21  Agile Manifesto Principles 1 Satisfy the Customer Measure of progress 7 2 Welcome changing Sustainable development 8 Continuous attention to 3 Continuous delivery 9 technical excellence 4 Collaborate Simplicity is essential 10 5 Motivated individual Self-organizing teams 11 Frequently discuss process 6 Face-to-face conversation 12 improvements 22  Agile vs. Waterfall Frame Within a sprint, you'll have the whole team working on these things simultaneously instead of sequentially. Wheels Roller Skate Bike Motorcycle skates board Engine Motorcycle Agile is a mindset, Waterfall is a process Incrementally vs. Iteratively 23  Agile Frameworks Scrum Typically from two weeks to one month long. Sprint is a short, time-boxed period when a scrum team works to complete a set amount of work (typically two weeks). Product backlog refers to a prioritized list of features which a product should contain. Agile is a mindset, while Scrum is a framework to a way to help you embrace that mindset 24 Scrum Common Roles Scrum Master: Coaches Encourages Facilitates self-management Conflict negotiator Product Owner: Most important role Work off of a product backlog. Should have authority to make real-time decisions. An Agile team should avoid Group Thinking because everyone should be able to ask challenging questions about the product. Link 25 Software Implementation and Deployment 26  Programming Principles Keep It Simple, Stupid (KISS) You should be writing code as simple as possible. One of the rules of basic programming is to never get caught up in trying to be overly clever or showing off with a thick block of advanced code. Write DRY Code Don't Repeat Yourself (DRY): When writing code, avoid duplication of data or logic. If you've ever copied and pasted code within your program, it's not DRY code! Composition Over Inheritance Objects with complex behaviors should contain instances of objects with individual behaviors. They should not inherit a class and add new behaviors. Source 27  Programming Principles Single Responsibility Every class or module in a program should only provide one specific functionality. Not to add too many responsibilities in a single classes. Break them up into smaller classes and modules. Separation Of Concerns (SOC) A program should be designed with different containers, and these containers should not have access to each other. You Aren't Going to Need It (YAGNI) You should never code for functionality on the off chance that you may need something in the future. You shouldn't try to solve a problem that doesn't exist! Document Your Code Leave comments to explain objects, enhance variable definitions, and make functions easier to understand. Source 28  Programming Principles Aspects of Refactoring Unused code: unused variables or methods that are in the code base Duplicates : identical functions or variables. Functions and variables with unclear names An excessive amount of text in one method A superfluous amount of comments Incorrectly formatted code fragments: functions and loops not written correctly, extra spaces from the beginning of a line, etc. Practice Offensive Programming Use Exceptions “Defensive Programming” practices in mind, which allows for the firmware to keep running even when incorrect behavior occurs. Source 29 Build Source 30 Buy Source 31 Software Testing 32  Level of Defect Bug can be a defect, and a deviation from expected behavior Level of bug: ❑ Failure: Program deviates from expected behavior. ❑ Error: The part of code that leads to the failure. ❑ Fault: Wrong outcome. Late delivery or software defects can damage a brand’s reputation leading to frustrated and lost customers. In extreme cases, a bug or defect can degrade interconnected systems or cause serious malfunctions. 33  Type of Testing White-box testing is a technique that involves testing the Black-box testing is a technique that assesses the internal structure, logic, and code of the software. It functionality, behavior, and output of the software requires the tester to have access to the source code and without knowledge of its internal structure, logic, or understand how it works, which can help to find errors in code. To do this, the tester must have access to the the implementation, logic, and design of the software, as specifications and requirements of the software, and use well as to improve its performance, security, and them to create test cases. This method of testing can maintainability. uncover errors in the functionality, usability, and compatibility of the software, as well as verify that it meets user and stakeholder expectations. Source 34  Bug Life Cycle Strat Decision to stop testing is mostly dependent on Time, Budget and Extent of Testing. Execute Scenarios YES Defect? Re-test Regression Regression Testing is a type of testing that is done to verify that a NO code change in the software does not impact the existing functionality of the product. All YES Defect Stop Execution Found? NO no one can actually guarantee that the software is defect free now! 35  Verification vs. Validation Does the software work Does the software work compared to the given compared to what the specifications? user needs? Source 36  Verification vs. Validation A way of violating verification, would be if the program accesses the wrong database. In this situation, we are not building the system correctly. It is deviating from expected behavior. A way of violating validation, would be if the program calculates car payments, instead of house payments. Our car payment calculator could be the most stable calculator in the world. However, we were supposed to build a house payment calculator. We are not building the right system. We are building a system which solves problems that it was not designed to solve. (And conversely doesn't solve problems that it was designed to solve.) Source 37 Software Testing Levels 38  Unit Testing Best Practice Should be easy to write. Should be readable. When done correctly, a developer should be able to fix a test without debugging code. Should be reliable. For example, On a development machine, tests may pass, but on a production server, they may fail. Good design flow can help ease these problems. Should be fast. As your software scales, you'll accumulate a lot of unit tests, so you don't want to wait for slow tests. Should be unit and not integration. Simple and has no dependencies. 39 Unit Testing Example Source 40 System vs Integration Testing Source 41  System vs Acceptance Testing Acceptance Testing System Testing We perform system testing to test the software as a whole.A We perform acceptance testing to check if the product meets the complete end to end test is performed to check if all the features requirements of use/business work as expected It includes only functional testing and is performed by end-users It includes both functional and non-functional testing.The tests or stakeholders are performed by a team of testers. We use real data from production to perform acceptance testing Mocked or test data is used to perform system testing It tests the performance, regression,reliability, It verifies the business requirement and what the customer wants compatibility,security and other such aspects of the product. It is a combination of alpha and beta testing It is a combination of system and integration testing The product is considered as a failure if a defect or bug is found Any bugs if found are fixed and retesting is done. Here, we only check if the new product meets specified Here, we tests the system’s integrity and whether it interacts well requirements with subsystems and external applications. 42 Source