Software Engineering Test 1 PDF

Introduction -- cont. Relationship between software engineering and other engineering The process of software engineering Basic tasks of software engineering Requirement gathering High-level design Low-level design Coding Testing Deployment Maintenance The process of software engin...

Introduction -- cont. Relationship between software engineering and other engineering The process of software engineering Basic tasks of software engineering Requirement gathering High-level design Low-level design Coding Testing Deployment Maintenance The process of software engineering --cont. Requirements: A requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. Understanding Feasibility research Negotiation Requirements changes always happen System design Requirements decomposition Specification Tools selection The process of software engineering --cont. Software design document Data flow Object-oriented design UML (Unified Modeling Language) Implementation Coding Bug fixing Fixing one bug often create a new bug: (a) the bug fix is incorrect; (b) the fix breaks other code that depends on the original buggy behavior; (c) the fix may change system behavior Testing Foundation is requirements Specification The process of software engineering --cont. Deployment: Deployment is the action of bringing resources into effective action. It involves the following: New or new version computer system User training On-site support while the users get familiar with the system Bug fix Maintenance Software maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes. It involves the following: Customer support Bug fix SE vs. Developer and Programmer The word engineer only applies to someone who obtained the license of professional engineering. Software analyst, You can apply for P.Eng. SE vs. Developer and Programmer Skills required for software engineers Computer systems (hardware and software) Computer languages Object-oriented design Software testing and debugging (familiar with tools) Problem solving and logical thinking Communication skills (both written and verbal) Team player Management Summary The concept of software engineering Relationship between software engineering and engineering Basic tasks of software engineering Requirement gathering High-level design Low-level design Coding Testing Deployment Maintenance Skills required for software engineers Question: different and relationship between science and engineering Announcement 3-4 students become a group for the group project 2 students focus on project presentation 2 students focus on project report Please email me your group members by end of January Group project requirements Group project evaluation rubrics Project management tools -- cont. Project management tools -- cont. Software Cost Estimation Models Why do we need software cost estimation models? COCOMO Model Static Single Variable Model Static Multi-Variable Model COCOMO Model COnstructive COst MOdel (COCOMO) COCOMO is a software cost estimate model for software projects that was created by Barry Boehm in the 1970s and published in 1981 in his book. Static Single Variable Model This model is used to estimate the effort, cost and development time for a software project which depends on a single variable. Question: Which one is the single variable? Static Multi-Variable Model This model is used to estimate the effort, cost and development time for a software project with depends on multiple internal or external variables. Question: Single variable model vs. multi-variable model Risk management Risk management Risk management is a process that allows individual risk events and overall risks to be understood and managed proactively, optimizing success by minimizing threats and maximizing opportunities. People, Product, Process, Project. Risk management -- cont. For each task, you should determine the following Likelihood Severity/Impact Consequence Workaround Summary Documentation Benefits of using documents Project management Concept Project management tools PERT charts Critical path Critical path method Gantt charts Software Cost Estimation Models COCOMO, Static Single Variable Model, Static Multi-Variable Model Risk management Concept How to categorize requirements -- cont. System requirements System requirements are the configuration that a system must have in order for a hardware or software application to run smoothly and efficiently such that to achieve business requirements and user requirements. Example: ATM Touch screen or keypad Computer languages, python, C++, C\#,\... Physical measurements -- size \...\... How to categorize requirements -- cont. Requirements How to categorize requirements -- cont. Functional requirements Functional requirements are detailed statements of the project's desired capabilities. Examples of functional requirements Business Rules. Transaction corrections, adjustments and cancellations. Administrative functions. Authentication. Authorization levels. Audit Tracking. External Interfaces. Certification Requirements. How to categorize requirements -- cont. Non-functional requirements Non-functional requirements are statements about the quality of the product's behavior or constraints on how it produces a desired results. Examples -- based on IEEE-Std 830 - 1993 Performance requirements Operational requirements Resource requirements Verification requirements Acceptance requirements Documentation requirements Security requirements Portability requirements How to categorize requirements -- cont. Functional requirements vs. Non-functional requirements FURPS FURPS is an acronym for categorizing the system requirements. Functionality requirement Usability requirement Reliability requirement Performance requirement Supportability requirement Developed by HP. FURPS+ FURPS+ Functionality requirement Usability requirement Reliability requirement Performance requirement Supportability requirement Design constraints Implementation requirements Interface requirements Physical requirements An Example of FURPS Summary Requirements The reasons why requirements are important The characteristics of good requirements The MOSCOW method for prioritizing requirements Requirement categorization Business/ user/ system Functional vs. non-functional requirements FURPS and FURPS+ methods for categorizing requirements Difference between requirement prioritization and categorization Requirements elicitation techniques -- cont. Domain analysis It is a process by which a software engineer learns back ground information. "Domain" means the general field of business or technology in which the customers expect to use the software product. For example, airline reservation systems, medical diagnosis systems, etc. Purpose: Gain sufficient information, understand the system/problems, and make good decisions Benefits of domain analysis: Shorten the duration of the project Increase the quality of software products Anticipation of extensions Requirements elicitation techniques -- cont. Brainstorm: Brainstorm is a group creativity technique by which efforts are made to find a conclusion for a specific problem by gathering a list of ideas spontaneously contributed by its members. Four rules of Osborn's method in Brainstorm Alex F. Osborn developed methods for creative problem solving in 1939.NO. Four rules of Osborn's method Meanings 1 Focus on quantity Do everything you can to keep the idea flowing 2 Withhold criticism Criticism can make people stop contributing 3 Encourage unusual ideas You can always "turn down a wild idea" but you may need to think way outside of the box to find creative solutions. 4 Combine and improve ideas Form new ideas by combining other ideas. Requirement specification You make design decisions or ask for requirement changes Use scientific principles to design and build high quality software products Requirement specification -- cont. Software requirement decomposition Definition: software requirement decomposition is to break down a software system from the system context level to system functions and data entities levels. An example: Recording requirements Unified modeling language (UML): https://www.uml.org/ UML is a general-purpose notational language for specifying and visualizing complex software, especially large, object-oriented project. UML is not a programming language; it is rather a visual language. Engineers use UML diagrams to portray the behavior and structure of a system. UML is applicable for any types of software design Database design Recording requirements -- cont. Unified modeling language (UML) more in later lectures Validation and verification Requirement validation Requirement validation is the process of making sure that the requirements say the right things. Requirement verification Requirement verification is the process of checking that the software product actually satisfies the requirements. Validation and verification Verification vs. validation in software engineering Architecture design -- cont. Component-based architecture --cont. A component is viewed as a functional element or a module of a software product. Example: ATM: Advantage: Easier for understanding, shorten production time Disadvantage: Lack flexibility and scalability Architecture design -- cont. Service-oriented architecture Service-oriented architecture is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. Advantage: Services are easily maintained; reliability; availability; scalability Disadvantage: Increased overhead. E.g. customer needs Examples: Cloud computing: Software as a service; platform as a service Symmetric key management systems Architecture design -- cont. Data-centric architecture Data centric architecture is a software design model where data is the primary and permanent asset, and applications come and go. Database plays an important role Advantage: Simplicity; security; integrity management Disadvantage: performance Example: Data Warehouse Question? Data-centric architecture vs. client/server Architecture design -- cont. Data-centric architecture vs. Client/server architecture Architecture design -- cont. Event-driven architecture (EDA) Event: an occurrence that may trigger a state transition. EDA is a software architecture pattern that the behavior of the software system based on events. Two types of events Hardware vs. software Advantage: Good performance Disadvantage: Complexity (cause race condition) Architecture design -- cont. Event-driven architecture (EDA) example -- State transition diagram Architecture design -- cont. Distributed architecture In distributed architecture, components are presented on different platforms and several components can cooperate with one another over a communication network in order to achieve a specific objective or goal. Advantage: Resource sharing; scalability Disadvantage: Complexity; security Examples: MongoDB -- non-SQL DB Block Chain Think -- Pair -- Share Question 2: Architecture design of group project Architecture design Monolithic Client/server Component-based Service-oriented Data-centric Event-driven Distributed For the group project, which architecture UML: Behavior diagrams -- cont. State machine/transition diagram A state transition diagram is a diagram that is used for modeling discrete behavior through finite state transitions. It describes the behavior of the system. It consists of states and events Examples: Automatic door system Operating systems TCP data communications UML: Behavior diagrams -- cont. Sequence diagrams A sequence diagram is a diagram that shows object interactions arranged in time sequence. It depicts interactions between objects in a sequential order i.e. the order in which these interactions take place. It contains (1) objects, (2) interactions, (3) timeline. Think -- Pair -- Share Structure diagram Class diagrams Component diagrams Behavior diagram Use case diagram, State transition diagrams, Sequence diagrams For the group project, which diagram(s) can be used? And why? Design principle 1: decomposition Decomposition Decomposition is also known as factoring, is breaking a complex problem or system into parts that are easier to conceive, understand, program, build, and maintain. An example: ATM Design principle 2: Cohesion Cohesion Cohesion is a measure that defines the degree of intra-dependability among elements of a module. The greater the cohesion, the better the software design. Example: ATM Design principle 3: Coupling Coupling Coupling occurs when there are interdependencies between one component/module and another. When interdependencies exist, changes in one place will require changes somewhere else. The lower coupling the better software design Cohesion vs. Coupling Design principal summary Summary Race condition Unified modeling language (UML) UML diagrams Structure diagram - Class diagrams, component diagrams Behavior diagram -- use case diagram, state transition diagrams, Sequence diagrams Design principles (3 principles) -- also apply to detailed design Decomposition Cohesion Coupling Key tasks in detailed design -- cont. Interface design (internal) Interface design (external) Think -- Pair -- Share For the group project, which interface design is needed? Key tasks in detailed design -- cont. Creating detailed design Graphical User interface (GUI) design.NET used in Windows, Linux, or Mac OS, and etc. C\# JavaScript, HTML WPF: windows presentation foundation X windows (X11) system for UNIX Key tasks in detailed design -- cont. Internal component design (structure and behavioral) UML structure diagram Class diagram Component diagram UML behavior diagram Use case diagram State transition diagram Sequence diagram Key tasks in detailed design -- cont. Data design, data structure design Data structures Array Stack: last-in--first-out (LIFO) data structure Queue: first-in--first-out (FIFO) data structure Linked list Singly linked list Double linked list Define your own data structures based on requirements Data type Different between integer and unsigned integer Incorrect data type definition can be problematic. Example: students' grade should use unsigned integer or just integer Key tasks in detailed design -- cont. Documenting detailed design Software design document (SDD) Software design specification (SDS) Software detailed design (SDD) Think -- Pair -- Share What does the table of contents for the group project look like? Key tasks in detailed design -- cont. Documenting detailed design Software design document (SDD) Software design specification (SDS) Software detailed design (SDD) Example of Table of Contents of SDD The four sections are mandatory. you can add or remove items. Key tasks in detailed design -- cont. Evaluating detailed design The most popular technique for evaluating detailed design is technical reviews. Keep in mind the following -- be professional Send a review notice with enough time Include a technical expert Include a member of software quality assurance and testing team Present how your design helps meet system requirements Document the review process -- meeting note Key tasks in detailed design -- cont. Managing implementation (4 steps) Prepare a good implementation plan Create an implementation model Learn later Take care of the component implementation Summary Low-level (detailed) design Concept Key tasks in detailed design Understanding requirements, architecture and systems Creating detailed design Interface design (internal and external) Shared memory - concurrency Graphical User interface (GUI) design ASCII code Internal component design (structure and behavioral) Data design, data structure design Documenting detailed design SDD, how to write a SDD Evaluating detailed design Object-oriented design -- cont. Object-oriented design -- cont. Object-oriented design -- cont. Encapsulation Encapsulation is the hiding of information. It prevents users from seeing the internal working of an object Examples: Setter(\...) and getter() Benefits of encapsulation Improves software reliability Easier for maintenance Reusability Object-oriented design -- cont. Abstraction vs. Encapsulation Abstraction means- hiding implementation using abstract class and interfaces etc. Encapsulation means-hiding data like using getter and setter etc. POD vs. OOD POD vs. OOD Think -- Pair -- Share For group project, which OOP features can be used? Summary Procedural-oriented design Object-oriented design Abstraction Concept Inheritance Concept Polymorphism Concept Encapsulation Concept Differences between POD and OOD