SE 2730 Review for Exam 1
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?
 maintainable, dependable, efficient, acceptable OR
 F.U.R.P.S.+: Features, Usability, Reliability, Performance, Scalability
2. Generic Software Process
7) What is a software process: a set of activities whose goal is the development or evolution of software
8) 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
9) CASE: Computer-Aided Software Engineering
3. Time Management (Personal Software Process)
10)
11)
12)
13)
How to avoid time overrun? Target and Estimate
The problem with target: unknown feasibility, unpredictable results, not repeatable, pressure
Basis for team estimation: previous project experience; assume “average” developers
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!
14) Word Breakdown System (WBS): continue decomposing till all tasks are under 2-4 hours duration
15) Construction Cost Model (COCOMO) 1:
 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
4. Requirements
16) User requirement (definition) vs. System requirement (specification)
17) functional requirements vs. non-functional requirements vs. domain requirements
18) SMART requirements: specific, measurable, attainable, realizable, traceable
5. Requirement Engineering
19) Requirement engineering process: feasibility study elicitation and analysis specification validation
20) feasibility study:
 a short focused study (2-3 weeks)
 Organizational objective, technical, economic, operational, schedule, legal and political
21) Elicitation and analysis: work with customers on gathering domain, services and constraints information
 stakeholder
 problems
 Elicitation and analysis process: discoveryclassification and organizationprioritization and
negotiationdocumentation
 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
22) 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
23) Requirement validation:
 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.