Review for exam 1 chapters 1 8
1 / 32

Review for Exam 1 Chapters 1 - 8 - PowerPoint PPT Presentation

  • Uploaded on

Review for Exam #1 Chapters 1 - 8. Exam #1 – Thursday, Oct. 2 Review slides will be posted on the course web site: Office hours Dr. Skubic: Tues., 2-3:30 p.m. Jason Goffeney: Tues., 12:30-1:50 p.m. Wed., 1-3 p.m. .

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Review for Exam 1 Chapters 1 - 8' - oswald

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Review for exam 1 chapters 1 8
Review for Exam #1Chapters 1 - 8

  • Exam #1 – Thursday, Oct. 2

  • Review slides will be posted on the course web site:

  • Office hours

    • Dr. Skubic: Tues., 2-3:30 p.m.

    • Jason Goffeney: Tues., 12:30-1:50 p.m.

      Wed., 1-3 p.m.

Chapter 1 overview and intro to software engineering
Chapter 1 – Overview and Intro to Software Engineering

  • Frequently Asked Questions from Fig. 1.1

  • What is the discipline of software engineering?

  • Why is it important? (development cost issues)

  • What is a software product? (programs, documentation, & configuration data)

  • What is the software process?

  • What are CASE tools?

  • Responsibilities and ethics

Chapter 2 system engineering
Chapter 2 – System Engineering

  • Relationship between the software and the system

  • System modeling – describing the architecture using a block diagram

  • The system engineering process and its challenges are similar to the software engineering process and its challenges

  • Emergent properties of reliability, usability, safety, security, and even performance

Chapter 3 the software process
Chapter 3 – The Software Process

  • Generic development phases:

    • specification, design, implementation, testing/validation, maintenance/evolution

  • Software process models:

    • Waterfall

    • Evolutionary (revisit in Ch. 8) – exploratory vs. throw-away

    • Formal systems development

    • Re-use development

    • Iterative models – Incremental and Spiral

  • Under what conditions would you use each model?

Homework 1 solutions
Homework #1 Solutions

1. Pick the most appropriate generic software process model for a system to control anti-lock braking in a car

ANSWER: Formal systems development because of the safety-critical system

[from Chapter 3]

Homework 1 solutions1
Homework #1 Solutions

1. Pick the most appropriate generic software process model for a virtual reality system to support software maintenance

ANSWER: Exploratory development because the requirements would be hard to determine in advance.

[from Chapter 3]

Homework 1 solutions2
Homework #1 Solutions

1. Pick the most appropriate generic software process model for a university accounting system that replaces an existing system

ANSWER: The waterfall model would work here. The requirements should be stable because it is replacing an existing system. If there are existing components that are usable, then re-use development would also be appropriate.

[from Chapter 3]

Homework 1 solutions3
Homework #1 Solutions

1. Pick the most appropriate generic software process model for an interactive system for railway passengers that finds train times from terminals installed in stations

ANSWER: The system will have a complex user interface but it must be stable and reliable. Use throw-away prototyping to find the requirements and then the incremental or waterfall model.

[from Chapter 3]

Homework 1 solutions4
Homework #1 Solutions

2. Explain how both the waterfall model and the prototyping model can be accomplished in the spiral process model.

ANSWER: The spiral model will look different depending on the nature of the project and the associated risks. With low riskspecification and no need for prototyping, the spiral model looks like the waterfall model. With high risk specification that calls for prototyping to discover the requirements, the spiral model looks like the prototyping model.

[from Chapter 3]

Chapter 4 project management
Chapter 4 – Project Management

  • Why is software project management so difficult?

    • Distinctive challenges, e.g., an intangible product

  • Management techniques

    • Milestones, reviews, deliverables

    • Bar charts and activity networks

  • Risk Management

    • Identifying risks

    • Different types of risks

    • Managing risks

Homework 1 solutions5
Homework #1 Solutions

4. Explain why the intangibility of software systems poses special problems for software project management.

ANSWER: Software cannot be inspected like a concrete item such as a house. It is hard to tell exactly what the status of the development is.

[from Chapter 4]

Chapter 5 software requirements
Chapter 5 – Software Requirements

  • Types of requirements

    • User requirements vs. system requirements

    • Functional requirements vs. non-functional requirements

    • Domain requirements

  • How to represent requirements

    • structured language vs. PDL (program description language)

  • The software requirements document

    • What is included?

  • Potential problems

    • Listing requirements in measurable terms

    • Finding ambiguities and omissions

Homework 1 solutions6
Homework #1 Solutions

3. Give an example to distinguish between user requirements and system requirements.


User requirements: (in natural language) The hospital PDA must interface to a database which stores the patient information

System requirements: (with diagrams) Specify the type of database system and an entity-relationship diagram to show what patient information will be stored and with what relationships.

[from Chapter 5]

Homework 2 solutions
Homework #2 Solutions

1. Write user requirements for an unattended gas pump system using natural language in a standard way (like Fig. 5.10 and 5.11)


1. Fuel delivery system

1.1 The system should provide an unattended fuel delivery service where a specified amount of fuel is delivered to customers. The cost is deducted from the customer’s credit card.

1.2 The sequence of actions to dispense fuel should be:

1. The customer selects the type of fuel to be delivered.

2. The customer inputs either a cash limit or the maximum amount of fuel to be delivered.

3. The customer validates the transaction by providing credit card details.

Rationale: The amount of fuel allowed depends on the credit limit but customers may wish to fill up rather than specify a certain amount of fuel. By specifying the maximum, the system can check if credit is available.

4. The pump is activated. Fuel is delivered.

Hw 2 question 1 continued
HW #2, question 1, continued

5. The transaction is terminated either when the pump nozzle is returned to its holster for 15 seconds or when the customer’s fuel or cash limit has been reached.

Rationale: Termination should not be immediate when the nozzle is returned as the customer may wish to restart the transaction, e.g., to fill the fuel can as well as the car

6. A receipt is printed.

7. The fuel stock is updated.

Specification: PUMP_SYS/FS. Section 1.

[from Chapter 5]

Homework 2 solutions1
Homework #2 Solutions

2. Describe any 2 types of non-functional requirements. Give an example for the gas pump system.


examples: performance, efficiency, space, portability, safety, ethical, standards (See Fig. 5.3)

For gas pump system:

  • Must follow the standard interface look established by the client (e.g., layout and color)

  • Must be implemented on the client’s existing hardware platform

    [from Chapter 5]

Chapter 6 requirements engineering processes
Chapter 6 – Requirements Engineering Processes

  • Phases (what artifact is produced after each phase?)

    • feasibility study

    • requirements elicitation and analysis

    • requirements specification

    • requirements validation (review slides)

  • Potential problems

    • e.g., stakeholders don’t know what they want; conflicts, etc.

  • VORD – viewpoint-oriented requirements def.

  • Use cases (review extra slides posted)

    • Associations – includes, extends, generalization

Problems of requirements analysis
Problems of requirements analysis

  • Stakeholders don’t know what they really want

  • Stakeholders express requirements in their own terms

  • Different stakeholders may have conflicting requirements

  • Organisational and political factors may influence the system requirements

  • The requirements change during the analysis process. New stakeholders may emerge and the business environment change

Home Automation example –

factor out common functionality with <include>

Homework 2 solutions2
Homework #2 Solutions

3. Draw a Use Case diagram for the gas pump system

read & validate credit card

select fuel options


dispense fuel

debit credit card





[from Chapter 6]

print receipt

Chapter 7 system models
Chapter 7 – System Models

  • Context model

    • The context diagram

  • Behavioral model

    • Data flow diagram (also called process model)

    • State diagram

  • Data model

    • Entity-relationship diagram

    • Data dictionary

  • Object models

    • Hierarchy showing inheritance

    • Aggregation

Context diagram the context of an atm system
Context DiagramThe context of an ATM system

Homework 2 solutions3
Homework #2 Solutions

4. Draw a context diagram for a patient information system in a hospital. Include image storage for x-rays and a patient admissions system.

image database







patient information


drug dispensing


[from Chapter 7]

Data flow diagram equipment procurement process
Data Flow Diagram:Equipment procurement process

Process Models show the overall process and the processes that are supported by the system

State diagram microwave oven model
State DiagramMicrowave oven model

Entity relationship diagram semantic data model of a software design
Entity-Relationship DiagramSemantic Data model of a Software design

Lack details and need to be supplemented by DD

Class diagram part of a library class hierarchy

Name of object class

Class Diagram:Part of a Library class hierarchy

Class attributes

Object’s operations

Class diagram object aggregation
Class Diagram:Object aggregation

Chapter 8 software prototyping
Chapter 8 – Software Prototyping

  • Evolutionary prototyping

    • Start with requirements you understand the best

    • Deliver the prototype

  • Throw-away prototyping

    • Start with requirements you least understand

    • Throw away the prototype and start over

  • Advantages & Disadvantages

  • Rapid prototyping techniques

    • HL language, DB programs, component assembly with re-usable components

  • User interface prototyping