Final Cheatsheet- Summary Software Engineering PDF

Preview

Summary

Waterfall Model: easy to manage bad structure (prematurely frozen design) inflexible (discourage change) only work when req are well understood unlikely to change customers see working program until late mistake in req analysis Risk Driven Development Risk lisk Risk ID: Unique identifier of each ris...

Description

Waterfall Model: • easy to manage • bad structure (prematurely frozen design) • inflexible (discourage change) • only work when req are well understood / unlikely to change • customers don’t see working program until late -> mistake in req analysis L2 Risk Driven Driven De L2-- Risk Develop velop velopme me ment nt Risk lisk Risk ID: Unique identifier of each risk item// Description: Summary of risk item// Exposure: Product of Probability and Impact. Can be coarse, but must be sufficient to rank the risk.// Consequence: What is the damage if the risk becomes a problem// Indicator: Earliest indicator that the risk has become reality// Mitigation strategy: Strategy to mitigate the risk// Actions/Status: Actions taken to date Risk Mitigation (Reduce risk) Risk Avoidance: avoid all exposure to the risk Risk Limitation/ Reduction: reduce probability and/or impact Risk Transfer: make it someone else's problem who can better manage the risk Risk Acceptance: monitor and rely on contingency action if the risk materializes. Common for lower impact risks where the costs of other mitigation strategies are greater than those of the risk. Common areas of risk for software projects related to new technologies adopted or needed risks related to architecture such as a need to develop robust sub-system structure that can support required functionality, suitability of the framework to be used, ability to meet quality requirements like performance, ... risks related to building the right system- correct identification and understanding of true functional and non-functional requirements. risks related to organizational issues such as staffing, schedule, and budget estimation, planning and execution...Programmatic Risks. These are real risks but often not the kind of risks that are useful for directly driving development (although work performed during development may help mitigate them). They are identified, tracked and handled by project managers, but are usually out-of-scope when planning development work. Similarly, Business Risks are generally beyond the control of the project manager. Benefits of Iterative & Incremental Process Models Early mitigation of big risks Early visible progress Early feedback, user engagement and adaptation – system better meets needs of stakeholders Complexity is managed – e.g. no attempt to do all analysis upfront Experience during an iteration can be used to improve the process in later iterations L3 L3-- Th The e Unifie Unified d Pr Process ocess UP Phases Inception(LCO)→Elaboration(LCA)→Construction(IOC)→Transition Inception: Understand what to build Vision, high-level requirements, business case// Addresses business risks Elaboration: Understand how to build it Verified baseline architecture, most requirements detailed// Addresses architectural/tech risks Construction: Build the product Complete working product, system test complete// Addresses logistical risks Transition: Validate solution Stakeholder acceptance// Addresses delivery and roll-out risks Phase Gate: Life Cycle Objectives (LCO): ready to commit to develop an architecture. • Life Cycle Architecture (LCA): ready to commit to develop the product • Initial Operational Capability (IOC): ready to commit to put it into use. TimeBoxing: Purpose: Gives a series of close, achievable deadlines// Allows for tighter control, better decisions// Good for team, good for client Too short: x time finish sufficient new work// management overhead for each iteration Too long: complexity of iteration increase// feedback from users comes too late typical mid-size project will deliver 6 or more executables: Inception (1 exploratory prototype)// Elaboration (2, architectural prototype & baseline)// Construction (2, partial / alpha & beta)// Transition (1, final product) neering L4- R Requirem equirem equirements ents Engineering Types of requirements information Business requirement: High-level business objective of the organization. Business rule: Policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement itself but the origin of several types of software requirement. Often, finally not grouped with requirements for this system because they originate and exist beyond the boundary of the system User requirement: Goal or task that specific classes of user must be able to perform with the system. Or a desired product attribute Functional requirement: Description of a behaviour that a system must provide under specific conditions Feature: One or more logically-related system capabilities that provide value to a user and are described by a set of functional requirements. The "big ideas". System requirement: Top-level requirement for a product that contains multiple sub-systems (some may be hardware) Non-functional requirement: Description of a property or characteristic that a system must exhibit or a constraint it must respect Quality attribute: Kind of non-functional requirement describing a service characteris tic or performance characteristic of a product. Can also lead to derived functional requirements. External interface requirement: Description of a connection between system and a user, another system or a hardware device Constraint: Kind of non-functional requirement restricting the choices available to the developer sion & Sc L5 L5-- Vision Scope ope 1.5 Vision Statement For members of HKU who wish to order meals from the student cafeterias or restaurants online, the Cafeteria Ordering System is an Internet-based and smartphone-enabled application that will accept individual or group meal orders, process payments, and trigger deliv ery of the prepared meals to a designated location on the HKU campus. Unlike the current manual ordering processes, members who use the Cafeteria Ordering System will not need to go to the cafeteria to get their meals, which help save time and will increase the food choices available to them. Feature List- examples For the COS FE-1: Order and pay for meals from the cafeteria menu to be picked up or delivered. FE-2: Order and pay for meals from local restaurants to be delivered.

FE-3: Maintain meal subscriptions for standing or recurring meal orders, or for daily special meals. FE-4: Maintain and archive cafeteria menus. FE-5: View ingredient lists and nutritional information for cafeteria menu items. FE-6: Provide system access through corporate intranet, smartphone, tablet, and outside Internet access by authorized employees (note: this is non-functional and becomes a constraint related to Operating Environment) Feature Tree

ng for R L6- Pr Prototypi ototyping Require equire equirements ments Elici Elicittation Scope of prototype Horizontal prototypes - usually just the UI - almost no functionality is really implemented – it is faked - all reports, charts, results, etc. are hard-coded - objective is to clarify workflow, confirm required functionality and general structure of the interface Vertical prototypes - thin slice of functionality, implemented end-to-end - touches all layers from UI to infrastructure services - architectural prototypes confirm we can satisfy non-functional requirements Fat Fate e of pr protot otot ototype ype Throwaway prototypes - Quick, cheap and dirty no effort put into quality of construction most common for horizontal prototyping will NOT become part of the final product don’t add more to it than you absolutely need to resolve issues Decide before starting that it will be a throwaway REALLY discard it or consider it unreleasable Evolutionary prototypes an increment or part of the final product apply production-level standards of quality L8 Us Use e Ca Case se Model UC ID and Name: POS-UC1: Process Sale Primary Actor: Cashier Supporting Actors: Payment Authorization Service, Accounting System, Inventory System, ... [TTrigger rigger, unless it is simply the first step in the flow] Description: Cashier uses the POS system to process the sale of goods selected for purchase by a customer and brought to the checkout. The POS system calculates the total of the sale and, when payment is confirmed, records details of the sale and issues a receipt. Stakeholders and Interests: - Cashier: Wants accurate, fast entry, and no payment errors, because cash shortages are deducted from his/her salary. - Customer: Wants to make purchase quickly and with minimal effort. Wants proof of purchase. Wants to see display of items and prices as they are entered. - Company: Wants accurate record of transactions. Wants to satisfy customers. Wants to ensure that Payment Authorization Service payment receivables are recorded. Wants fault tolerance such that sales can be captured even if server components (e.g., remote credit validation) are unavailable. Wants fast, automatic and timely update of accounting and inventory data. - Manager: Wants to be able to override easily. Wants to be able to solve cashier problems with minimal effort and interruption. - HKSAR Government: In near future, will want to collect tax from every sale. - Payment Authorization Service: Wants to receive digital authorization requests in the correct format, using correct protocol. Wants accurate accounting of their payables to the branch of the company. Preconditions:: PRE-1: Cashier is identified and authenticated. Success Guarantee (Postconditions): POST-1: Sale is saved. (Future: Tax is correctly calculated.) POST-2: Accounting and Inventory are updated. POST-3: Receipt is generated. POST-4: Payment authorization approvals are recorded Main Success Scenario (also known as Basic Flow or Normal Flow): 1. Customer arrives at POS checkout with items to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 3-4 until indicates no more items. 5. System presents total (Future: with taxes calculated). 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. 8. System logs completed sale and sends sale and payment information to the external Accounting system and/or Inventory system. 9. System presents receipt. 10. Customer leaves with receipt and items (if any). Extensions:: *a. At any time, System fails: To support recovery and accurate accounting, ensure all transaction sensitive state and events can be recovered from any step of the scenario. 1. Cashier restarts System, logs in, and requests recovery of prior state. 2. System reconstructs prior state.

2a. System detects anomalies preventing recovery: 1. System signals error to the Cashier, records the error, and enters a clean state. 2. Cashier starts a new sale. 1a. Customer or Manager indicates desire to resume suspended sale: 1. Cashier performs resume operation, and enters the ID to retrieve the sale. 2. System displays the state of the resumed sale and its subtotal. 2a. Sale not found: 1. System signals error to the Cashier…. Frequency of Occurrence: Could be almost continuous. Business Rules: PNS-BR-005, PNS-BR-007. Special Requirements: - Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter. - Robust recovery when access to remote services such as the inventory system fails. - Language internationalization on the text displayed, Chinese and English. - Pluggable business rules to be insertable at steps 3 and 7. Technology and Data Variations List:: *a. Manager override entered by swiping an override card through the card reader, or by entering an authorization code on the keypad, or by unlocking with a physical key. 3a. Item identifier entered by scanning item’s bar code with a laser scanner, or via keyboard. 3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme. 7a. EPS transactions are conducted via standard external cradle and card reader. Assumptions:: 1. Assume cashier has access to standard names and list of identifiers for items which do not carry a bar-code (e.g. unpackaged vegetables). Notes and Open Issues: - What flexibility is needed for tax calculation? - Explore the remote service recovery issue. - What customization is needed for different businesses? ysis L9- O Object bject Orie Oriente nte nted d Analysis System Sequence Diagram describe how objects interact via messages, how they collaborate to realize use cases •used to visualize how the system operates in the form of message-passing across the system boundary • add State Machine Diagram to model particular object lifecycles • Sale Class : Sale Instance s: Sale Named instance • Return Add attributes-> Add association and constrain ts (multiplicity) Class Category:: Phy obj: Register (the machine at checkout), ShuttleBus, Item) Description: ProductDescription Places: Shop, Depot Transaction: Sale, Reservation Record of work/ fina, ppl: Receipt, MaintenanceLog Others: Transaction line items, product or service the transaction is for, roles of people, containers of things, things in a container, collaborating systems, financial instruments, schedules. Elimin Eliminating ating ccandid andid andidat at ate e s: Redundant, Instances of class, Vague, event /operation, Outside of scope, An attribute aalization lization fo L9 L9-- Generaliz eralization ation ation-Speci -Specializatio forr Domain Model: Concepts similar yet have differences-> organize them into a generalization specialization hierarchy (E.g. Payment 分三 -> Creditcard, cash & cheque) IsA Rule:: The class Payment is a generalization of CashPayment becoz, conceptually, every CP is a kind of P. member of CP = member of PaymentP property of the domain holds for anarbitrary P = hold for an arbitrary CP 100% Rule:: All of a superclass’s definition should be applicable to its subclasses. The subclass must conform to 100% of the superclass's attributes and associations. Partition into subclasses when: additional attributes of interest in this domain additional associations of interest in this domain subclass concept is handled diff or behaves diff than superclass or other subclasses in ways of interest

Software object responsibilities: 1. Kno Know w ledge (attributes & associations) 2. Beha Behavior vior • fulfilled by its methods • objects may collaborate with other objects / methods to perform the task Operation Contract: describes changes of state in the Domain Model • describe what must happen in abstract terms & x how it will be carried out Evaluating Maintainability: ISO Quality Model Maintainability Sub-characteristics: Modularity: to what extent is the program composed of discrete components such that a change to one component has minimal impact on others? Reusability: how well can an asset be used in more than 1 system, or in building other assets? Analyzability-how easy is it to find deficiencies / the cause of failure if the software does not function correctly? How easy is it to work out what needs to be modified when we want to change or add functionality? Modifiability-how easy is it to make modifications without introducing defects / degrading performance Testability- how easy is it to establish test criteria and perform tests to determine whether those criteria have been met? Gener General al Prin Principle ciple cipless of Desig Design n Traditional properties of a good design support maintainability 1. Good abstraction and separation of concerns Form modules by gro grouping uping simil similar ar co concerns ncerns ttogether ogether and separating them from other groups Eff Effect ect ect: - majority of int interact eract eractions ions will occur within module moduless - interactions betw between een mod modules ules can be kept sim simple ple Res Resu u lt lt: each module tends to capture a single abstraction or feature of a problem and can export the corresponding services through a simple interface 2. Good encapsulation/information hiding nimum aamou Prefer modules that export only a minimum mou moun n t of d detail etail through their interfaces reveal the info which a client absolu tely must know the way the services are actually provided (e.g. data structure) should be hidden Good design = clear separation between interface and implementation Clients depend on the specification/contract of the module and not how the module fulfills that contract Implementation details are hidden-> free to change them without breaking some other part of the system Greatly red reduces uces impl impleme eme emen n tation de depen pen pendencie dencie denciess and makes systems much more mo modifiabl difiable 3. Strong cohesion within modules and methods ated to one another = how closely the oper perations ations wit within hin a mo module dule ar are e related onality tog aim for high cohesion by grou group p ing str strongly ongly rrelate elate elated d functionality togeth eth ether er (as in separation of concerns) while also keeping everything else out

-

Relevant to design at any le vel, from individual functions up to entire subsystems Methods/functions with the strongest cohesion have a cle clear ar sin single gle p purpo urpo urposs e. They execute that single purpose extr extremely emely well and do n nothin othin othingg els else e Modules with low cohesion group many unr unrelated elated rresponsi esponsi esponsibilitie bilitie bilitiess together and, as a result, are often dif difficult ficult to und unde e rstand stand. They also may have to chan change ge ffor or man manyy diff different erent aand nd ated rreasons unrelated easons

4. No unnecessary coupling between modules -> To reduce the number and strength of dependencies- the connections to, knowledge of, or relianc eliance e ees. s on ot other her modules Have-ve effects on Reusability, Analyzability, Modifiability, Testability 5. Once and once only (no redundancy) 6. Design for Testability bility Assi L11- G Gener ener eneral al Resp Responsi onsibility Assignm gnm gnment ent Softw Software are PPatt att atterns erns Inf Inform orm ormatio atio ation n ex expert pert “who has the necessary information for this?” ->Result: lowered coupling – objects use their own information, not that of some other object better cohesion – behaviour is distributed to where it belongs x use if it compromises some other design principle e.g. seek clear separation of concerns & gd abstractions What if the creation process is complex? -> Sep Separ ar arate ate conce concerns. rns. Pass an object that knows the rules of creation or can do it behind an interface. Generally called a Factory (another set of design patterns). For llow ow ccoupling oupling oupling: Creator should be: - contains or has composition relationship with objects of type X - closely uses objects of type X - records objects of type X (above 3) Already has visibility – doesn’t increase coupling - has the data needed to initialize objects of type X (‘has the information’ – from Information Expert) Controller = who should handle system event messages Façade controller = a class that have the information to initialize the object, gd when there is just a small no of system events (as fat controllers lack cohesion Use case/ session controllers = created to handle all events for a particular scenario. For M Maintai aintai aintaining ning hig high h co cohesio hesio hesion n: Fat controllers lack cohesion 2 signs of low cohesion: controller doesn’t delegate & too many attributes (controller is maintaining or duplicating too much state – this belongs in the relevant domain objects) es of clas gn L12- SOLID: Principles classs design Single R Responsi esponsi esponsibility bility Principle (S (SRP) RP)- A class should have only one reason to change - Closely related to the conc concept ept of co cohesion hesion hesion, x a chan change ge to af affec fec fectt unr unrelate elate elated d co code de that happens to be in th the e sam same e modul module; e; if a module is changing, we don't want to be forced to retest code unrelated to that change - The SRP is independent of the type system and so applies for nominal typing, duck-typing, - The best way to view a respo responsibilit nsibilit nsibilityy is a collection of functions in a class that serve one p particular articular ac actor tor - Then we can view that actor as the single source of change for that responsibility (e.g. Who is served by a Shopping Cart? The customer) - ...