SE 2730 Final Review 1. Introduction 1) What is software: programs, associated documentations and data 2) Three types of software products: generic, custom, semi-custom Why is semi-custom product more and more popular? 3) What is software engineering: an engineering discipline concerning with all aspects of software production. 4) Software engineering vs. computer science vs. system engineering 5) Why is software engineering so important? 6) What is good software? 2. Generic Software Process maintainable, dependable, efficient, acceptable OR F.U.R.P.S.+: Features, Usability, Reliability, Performance, Scalability 1) What is a software process: a set of activities whose goal is the development or evolution of software 2) Four generic activities: specification, development, validation and evolution Specification answers the question of WHAT instead of HOW! Development: high-level design, detailed design, implantation (coding, unit test, integration test, system test) Validation vs. Verification Evolution: fix, add, change, port, improve 3) CASE: Computer-Aided Software Engineering 3. Time Management (Personal Software Process) 1) How to avoid time overrun? Target and Estimate 2) The problem with target: unknown feasibility, unpredictable results, not repeatable, pressure 3) Basis for team estimation: previous project experience; assume average developers 4) Basis for individual work: time record record time in major activity categories record time in a standard way record completed tasks in standard units: for future estimation! 5) Word Breakdown System (WBS): continue decomposing till all tasks are under 2-4 hours duration 6) Construction Cost Model (COCOMO) 1: 4. Requirements What do we need for the estimation? program size in KLOC What can we estimate? total effort in person-month, development time and people required Problem with COCOMO: need to have good estimation of the project size 1) User requirement (definition) vs. System requirement (specification) 2) functional requirements vs. non-functional requirements vs. domain requirements 3) SMART requirements: specific, measurable, attainable, realizable, traceable
5. Requirement Engineering 1) Requirement engineering process: feasibility study elicitation and analysis specification validation 2) feasibility study: a short focused study (2-3 weeks) Organizational objective, technical, economic, operational, schedule, legal and political 3) Elicitation and analysis: work with customers on gathering domain, services and constraints information stakeholder problems Elicitation and analysis process: discoveryclassification and organizationprioritization and negotiationdocumentation Iterative: business req. user req. system req. Interview: closed, open, mixed Ethnography: observations and contextual interview i. Benefits? ii. Issues? Scenarios: real-life example of how a system can be used i. basic structure ii. How to write a good scenario? simple sentence; no conditions; observables only; specific message 4) Specification: requirement specification items and use case model use case: generalization of a collection of scenarios i. actors vs. stakeholders ii. Basic structure: how to document exceptions? iii. Writing guide: verb-noun name; distinguish actors actions from system s actions; active voice; complete; NO user interface; 2-3 pages; scenario writing guides also apply use case diagram: i. UML: Unified Modeling Language ii. four components: actors, use cases, system boundary box, relationships iii. primary actors on the left, secondary actors on the right iv. <<include>>: (1). multiple base cases share the same inclusion case OR (2). the inclusion case is an important part of the base case v. <<extend>>: the extension case consists of additional behavior that can incrementally augment the behavior of the base use case. Goal of refining use cases: completeness and correctness 5) Requirement validation: 6. HCI Design Review: SMART requirements i. guidelines for effective review Prototyping: quickly generate something that can be validated by users i. throw away ii. fast iii. for requirement elicitation, validation, design, etc. 1) CLI, UI, MCI, HCI, GUI
2) What is HCI: input and display devices 3) Limitations of people: memory, stress, physical limitation 4) Three golden rules 7. Architectural Design Place users in control i. Use modes judiciously (modeless) (1). application and system modal ii. Allow users to use either the keyboard or mouse (flexible) iii. Allow users to change focus (interruptible) iv. Display descriptive messages and text (helpful) v. Provide immediate and reversible actions, and feedback (forgiving) vi. Provide meaningful paths and exits (navigable) vii. Accommodate users with different skill levels (accessible) viii. Make the user interface transparent (facilitative) ix. Allow users to customize the interface (preferences) x. Allow users to directly manipulate interface objects (interactive). Reduce users memory load i. Relieve short-term memory (remember) ii. Rely on recognition, not recall (recognition) iii. Provide visual cues (inform) iv. Provide defaults, undo, and redo (forgiving) v. Provide interface shortcuts (frequency) vi. Use real-world metaphors (transfer) vii. User progressive disclosure (context) viii. Promote visual clarity (organize) Make the user interface consistent i. Sustain the context of users tasks (continuity) ii. Maintain consistency within and across products (experience) iii. Keep interaction results the same (expectations) iv. Provide aesthetic appeal and integrity (attitude) v. Encourage exploration (predictable) 1) What is architectural design: decompose into sub-systems and identify the control and communications among sub-systems 2) When should it be performed: early stage of design; in parallel with later stage of specification 3) Non-functional requirement is the key to make architectural design decisions! Performance: Localize critical operations and minimize communications; Use large rather than fine-grain components. Security: Use a layered architecture with critical assets in the inner layers. Safety: Localize safety-critical features in a small number of sub-systems. Availability: Include redundant components and mechanisms for fault tolerance. Maintainability: Use fine-grain, replaceable components. 4) Architectural design conflicts: examples and what to do 5) How to use a block diagram to demonstrate your architecture design 6) Architecture style: generic reusable architectural models Repository
Client server Layered For each: features, examples, advantages and disadvantages 7) How to combine architecture styles 8. Class Diagrams 1) What are analysis and design phase? 2) Object models: object classes and their relationships 3) Differences among domain, design and implementation level class diagrams 4) How to draw a domain level class diagram given the requirements? Step 1: identify objects i. Name identification method: how to perform it? ii. Class name: nouns Step 2: identify associations i. description: one or two words verb phrase ii. navigation: open arrow pointing to B if A knows B and B doesn t know A iii. multiplicity on each end of the association: 0..1, 1, *, 1..* Step 3: refine relationships i. inheritance: is-a relationship (1). make sure child is not simply an instance of the parent (2). problems with multiple inheritance ii. aggregation: part-of relationship (1). still need to show multiplicities (2). composition: if A doesn t exist, B cannot exist. Step 4: add major attributes and operations i. attributes are none_phrases connected by _ ii. most attributes can be identified during name identification process iii. if A and B have association/aggregation relationship, don t list B as an attribute of A! iv. operations are verb phrases or nouns if value-returning v. use verb identification method to identify operations 5) CRC (Class Responsibility Collaboration) method What should be included in a CRC card CRC design process 6) Object oriented design process 7) High cohesion and low coupling: Cohesion: i. Coincidental cohesion (worst): partition randomly. ii. Logical cohesion: logically categorized to do the same thing. iii. Temporal cohesion: grouped by when they are processed. iv. Procedural cohesion: grouped because they always follow a certain sequence of execution. v. Communicational cohesion: operate on the same data. vi. Functional cohesion (best): single well defined task per module Coupling: i. Content coupling (Worst/highest): public attributes or goto statement ii. Common coupling: global variable
iii. Control coupling: module A controls B via control flag iv. Stamp coupling: pass composite data structure and use only part of it v. Data coupling (Best/lowest): a list of simple parameters and use all of them 9. Software testing, verification and validation 1) Two V&V approaches: Static: inspections and review. Dynamic: software testing; execution based. 2) Human makes error; a fault is the representation of an error; failure occurs when a fault executes. Three conditions necessary for a failure to be observed: reachability, infection and propagation. 3) Testing vs. debugging: testing finds failures while debugging look for faults causing those failures. 4) Cost of fixing a defect grows exponentially. 5) You should not test your own code! 6) What is a test case? inputs and expected outputs Also include ID, purpose, pre and post conditions in test documents. 7) Activities of test engineering: Test design: know the requirements and/or the structure of the system Test automation: write scripts, build test harness and stubs Test execution Test evaluation: compare actual outputs with expected outputs; also need automation. 8) Test case design techniques: Functional testing (black-box): i. need to know requirement specification ii. should be able to trace back to all requirements: traceability iii. start early: right after requirement specification is done. iv. Partition testing: (1). Partition same behaviors into one equivalence class. (2). ONLY one test case is generated from one equivalence class. v. Boundary testing: testing on the edge and both sides of the edge of legal input values. Structural testing (white-box) i. need to know the structure of the program ii. use different types of coverage criteria iii. Benefits: (1). Explicitly state the extent to which the software is tested (2). Makes testing management more meaningful Black-box vs. white-box: neither is perfect; we should use both. 9) V model: the design of different levels of testing is based on different stages of development. 10) Testing levels: Unit testing: i. done together with coding ii. mainly white-box testing iii. test harness: simulating other parts of the system (the environment) iv. test stub: minimal function implementations to check the logic of calling functions and interfaces between calling and called functions.
Module/subsystem testing: i. test the subsystem as a whole. ii. starting from this level, we mainly use black-box testing. Integration testing: i. done incrementally as new subsystems are added. ii. focus on the interfacing iii. a good time to tune for performance System testing: i. after the system is completed ii. focus on non-functional requirements (also should validate the functional requirements) Acceptance testing: i. customer testing ii. alpha test vs. beta test 11) Regression testing: ensure fixing a bug does not introduce new bugs. often automated: nightly build and test regression test suites are growing as new ways to break a system are discovered 12) Test plan and management: Start early! Make sure there is enough time scheduled for testing. Traceability is important! 10. Software process models (A.K.A. software life cycle models) 1) Software process: structure set of activities required to develop a software system 2) software process model: an abstract representation of a software process 3) Waterfall model: The result of each phase is document(s) that are approved ( signed off ). The following phase will not start until the previous phase is finished. Freeze output documents(s) after one phase is finished. No going back. In reality: phased may overlap; may rewind back to the previous phase. Advantages: i. simple ii. easy to manage. why? iii. similar to other engineering process models Problem: hard to adapt to changes! When to use: requirements are fixed; changes are limited; part of a larger project with other engineering fields involved. 4) Evolutionary development: Develop the system in many small but complete iterations. Each iteration results in a working deliverable. Present each deliverable to the customer for feedback. Allow intermediate corrections of requirements, specifications, and plans to make sure that the project is targeting the right direction. Examples: i. Exploratory development
(1). Start with well-understood part of the requirements (2). Add new features as proposed by the customer. ii. throwaway prototyping (1). mainly for experimenting when a. Customers don t know exactly what they want b. We want to analyze the usability of an HCI c. We are not sure if a particular approach to solving a problem will work d. We have multiple approaches to solving a problem and we want to experiment to see which is better. (2). NEVER use the prototype in the actual deliverable! Problems: i. lack of process visibility ii. systems are often poorly structured iii. may need special skills 5) Component-based development: Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. Process stages i. Requirement analysis ii. Component assessment and specification iii. Requirements modification iv. System design with reuse v. Development, integration and testing. Advantages: i. Reduce the amount of software to be developed ii. Reduce costs and risks iii. Usually faster delivery of the software Problem: requirement compromises are inevitable. 6) Costs of software engineering activities: 11. Ethics Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs. Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability. Distribution of costs depends on the process model that is used. 1) Issues of professional responsibility: Confidentiality Competence Intellectual property right Computer misuse 2) ACM/IEEE Code of Ethics: 8 principles