1 / 32

Review for Exam #1 Chapters 1 - 8

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

fearghus
Download Presentation

Review for Exam #1 Chapters 1 - 8

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Review for Exam #1Chapters 1 - 8 • Exam #1 – Thursday, Oct. 2 • Review slides will be posted on the course web site: http://www.cecs.missouri.edu/~skubic/332/ • Office hours • Dr. Skubic: Tues., 2-3:30 p.m. • Jason Goffeney: Tues., 12:30-1:50 p.m. Wed., 1-3 p.m.

  2. 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

  3. 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

  4. 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?

  5. 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]

  6. 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]

  7. 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]

  8. 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]

  9. 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]

  10. 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

  11. 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]

  12. 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

  13. Homework #1 Solutions 3. Give an example to distinguish between user requirements and system requirements. EXAMPLE: 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]

  14. 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) ANSWER: 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.

  15. 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]

  16. Homework #2 Solutions 2. Describe any 2 types of non-functional requirements. Give an example for the gas pump system. ANSWER: 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]

  17. 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

  18. The requirements engineering process

  19. 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

  20. Home Automation example – factor out common functionality with <include>

  21. Home Automation example using <extend>

  22. Simplified with an abstract use case - generalization

  23. Homework #2 Solutions 3. Draw a Use Case diagram for the gas pump system read & validate credit card select fuel options customer dispense fuel debit credit card credit card company <include> [from Chapter 6] print receipt

  24. 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

  25. Context DiagramThe context of an ATM system

  26. 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 medical records system hospital admissions system patient information system drug dispensing system [from Chapter 7]

  27. Data Flow Diagram:Equipment procurement process Process Models show the overall process and the processes that are supported by the system

  28. State DiagramMicrowave oven model

  29. Entity-Relationship DiagramSemantic Data model of a Software design Lack details and need to be supplemented by DD

  30. Name of object class Class Diagram:Part of a Library class hierarchy Class attributes Object’s operations

  31. Class Diagram:Object aggregation

  32. 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

More Related