Review for Exam #1 Chapters 1 - 8

Slides:



Advertisements
Similar presentations
Software Processes.
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
1 Software Processes A Software process is a set of activities and associated results which lead to the production of a software product. Activities Common.
Unit 2. Software Lifecycle
1 Chapter 4 - Part 1 Software Processes. 2 Software Processes is: Coherent (logically connected) sets of activities for specifying, designing, implementing,
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
ISNE101 Dr. Ken Cosh. Recap  We’ve been talking about Software…  Application vs System Software  Programming Languages  Vs Natural Languages  Syntax,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
7M701 1 Software Prototyping Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 8
Review slides will be posted on the course web site:
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Software Engineering General Project Management Software Requirements
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Review 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
©Ian Sommerville 2000 Software Engineering, 6th edition Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Overview of Software Requirements
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Review 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Course Instructor: Aisha Azeem
Chapter 3 Software Processes.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements l.
The Software Development Life Cycle: An Overview
ISO Tor Stålhane IDI / NTNU. What is ISO ISO 9001 was developed for the production industry but has a rather general structure ISO describes.
Chapter 4 – Requirements Engineering
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
©Ian Sommerville Software Engineering Slide 1 Software Requirements l Definition: Description and Specifications of a system l Topics covered: Functional.
Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 The requirements engineering process.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Topic (1)Software Engineering (601321)1 Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements.
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
Faculty of Computer & Information Software Engineering Third year
Chapter 7 System models.
1 SWE Introduction to Software Engineering Lecture 4.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Chapter 4 Requirements Engineering (2/3)
Systems Analysis and Design in a Changing World, Fourth Edition
Use Case diagram for the gas pump system
Chapter 13: Software Life Cycle Models Omar Meqdadi SE 273 Lecture 13 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Systems Development Life Cycle
Software Prototyping Rapid software development to validate requirements.
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
Chapter 3: The Requirements Workflow [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements (utvalgte foiler fra Kap 6 og 7 i Sommerville)
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Chapter 4 Requirements Engineering (2/3)
Chapter 4 – Requirements Engineering
Software Prototyping.
Chapter 5 – Requirements Engineering
Software Processes (a)
Abstract descriptions of systems whose requirements are being analysed
Software Processes.
Software Processes.
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Presentation transcript:

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.

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 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 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 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 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 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 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 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 risk specification 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 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 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 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 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]

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.

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

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

The requirements engineering process

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>

Home Automation example using <extend>

Simplified with an abstract use case - generalization

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

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

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]

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

Entity-Relationship Diagram Semantic 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

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