Download
software engineering n.
Skip this Video
Loading SlideShow in 5 Seconds..
Software Engineering PowerPoint Presentation
Download Presentation
Software Engineering

Software Engineering

509 Vues Download Presentation
Télécharger la présentation

Software Engineering

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Software Engineering Lecture 10: System Engineering

  2. Today’s Topics • System Engineering Concepts • Business Process Engineering • Product Engineering • Requirements Elicitation, Analysis & Specification • System Modeling

  3. System Engineering • Precedes software engineering • “Put software into context” • Work flow & other human activities • Business model • Business Process Engineering • Focus on a business enterprise • Product Engineering • Focus on a product to be built

  4. What is a “System”? • Types of systems: • political, educational, avionics, banking, manufacturing, … • Computer-based system:“A set of elements that are organized to accomplish some predefined goal by processing information” • Goals: Support a business function, develop a product, etc.

  5. Software Hardware People Database Documentation Procedures System Elements These elements combine in a varietyof ways to transform information

  6. System Hierarchy • Each computer-based system can be part of a larger system • System Engineering Hierarchy • Organize the systems into a set of layered views (Figure 10.1) • Define the elements for a specific computer-based system in the context of the overall hierarchy of systems

  7. InformationStrategy Planning System Engineering Hierarchy Business AreaAnalysis SoftwareEngineering [From SEPA 5/e]

  8. System Modeling • System engineering is a modeling process • For each view: • Define processes • Represent process behavior • List process assumptions • Define external and internal inputs • Model linkages (control, data, I/O)

  9. Assumptions range of allowable data Simplifications partition data into categories Limitations bounds on functionality Constraints guide the implementation Preferences indicate preferred architecture (data, functions, technology) System Modeling [2] Much of this information is derived from customer requirements

  10. Business Process Engineering • Data Architecture • Framework for the data objects used by the business (+ relationships) • Applications Architecture • Elements which transform data objects for a business purpose • Technology Infrastructure • Foundation for data & applications architectures

  11. BPEHierarchy [From SEPA 5/e]

  12. Information Strategy Planning • Focus: World View (entire business) • Goals: • Isolate domains of the business(engineering, marketing, sales, …) • Define data objects visible at the enterprise level (+ relationships & data flow)

  13. Business Area Analysis • Focus: Domain View (selected business area) • Goals: • Isolate functions and procedures that allow the area to meet its goals • Define data objects visible at the business area level (+ relationships & data flow) • Identify information support systems

  14. Business System Design • Focus: Element View(specific information system in a business area) • Goals: • Model the requirements • Design: • Data Architecture • Applications Architecture • Technology Infrastructure

  15. Construction & Integration • Focus: Detailed View(implementation of an element) • Goals: • Implement the architectures and infrastructure • Insert the completed system into the business area (training, logistics, …)

  16. ProductEngineeringHierarchy [From SEPA 5/e]

  17. Elicitation Analysis & Negotiation Specification Modeling Validation Management Requirements Engineering How can we specify a system that meets the customer’s needs and expectations?

  18. Requirements Elicitation • Challenges • Scope: • Defining the system boundary • Lack of clarity on overall objectives • Understanding: • Customer not skilled • Doesn’t state the obvious • Requirements ambiguous, conflicting, … • Volatility: • Requirements change over time

  19. Assess feasibility Identify people & their role(s) Define technical environment Identify domain constraints Select elicitation method(s) Solicit participation from several perspectives Identify ambiguous requirements Create usage scenarios Elicitation [2]

  20. Analysis & Negotiation • Is each requirement: • Consistent with overall objective? • Sufficiently abstract? • Essential to overall objective? • Bounded and unambiguous? • Attributed to a source? (person) • Conflicting with other requirements? • Achievable in technical environment? • Testable, once implemented?

  21. Requirements Specification • Elements of a Specification: • Written documents • Graphical models • Formal mathematical models • Final work product:System Specification

  22. System Modeling • Evaluate the system’s components in relation to one another • Link requirements to system components • Validate assumptions about data flow, work flow, input / output, ...

  23. Requirements Validation • Is each requirement: • Stated clearly? • Verified by an identified source? • Bounded in a quantitative way? • Associated with other requirements? • Consistent with domain constraints? • Testable, with specified tests? • Traceable to the system model? • Traceable to overall objectives?

  24. Requirements Management • Identify, control, and track: • New requirements • Changes to requirements • Active throughout the life-cycle • Traceability Table • Relates requirements to features, source, dependency, subsystem, interface, etc.

  25. Generic Traceability Table [From SEPA 5/e]

  26. System Modeling Techniques • System Model Template(Hatley & Pirbhai, 1987) • Allocate system elements to 5 processing regions: • user interface • input • system function and control • output • maintenance & self-test

  27. System Model Template [From SEPA 5/e]

  28. Modeling Techniques [2] • System Context Diagram (SCD) • Establish the information boundary between the system & the operating environment • External producers & consumers of information • Entities that communicate through the interface / testing capability

  29. SystemContextDiagram [From SEPA 5/e]

  30. Modeling Techniques [2] • System Flow Diagram • Identify major subsystems • Identify data & control flow • Each subsystem can also be decomposed into an SFD • Final product: a hierarchy of SFDs

  31. SystemFlowDiagram [From SEPA 5/e]

  32. SFDHierarchy [From SEPA 5/e]

  33. Questions?

  34. Software Engineeringfor Information Technology Lecture 10: System Engineering

  35. Today’s Topics • System Engineering Concepts • Business Process Engineering • Product Engineering • Requirements Elicitation, Analysis & Specification • System Modeling

  36. System Engineering • Precedes software engineering • “Put software into context” • Work flow & other human activities • Business model • Business Process Engineering • Focus on a business enterprise • Product Engineering • Focus on a product to be built

  37. What is a “System”? • Types of systems: • political, educational, avionics, banking, manufacturing, … • Computer-based system:“A set of elements that are organized to accomplish some predefined goal by processing information” • Goals: Support a business function, develop a product, etc.

  38. Software Hardware People Database Documentation Procedures System Elements These elements combine in a varietyof ways to transform information

  39. System Hierarchy • Each computer-based system can be part of a larger system • System Engineering Hierarchy • Organize the systems into a set of layered views (Figure 10.1) • Define the elements for a specific computer-based system in the context of the overall hierarchy of systems

  40. InformationStrategy Planning System Engineering Hierarchy Business AreaAnalysis SoftwareEngineering [From SEPA 5/e]

  41. System Modeling • System engineering is a modeling process • For each view: • Define processes • Represent process behavior • List process assumptions • Define external and internal inputs • Model linkages (control, data, I/O)

  42. Assumptions range of allowable data Simplifications partition data into categories Limitations bounds on functionality Constraints guide the implementation Preferences indicate preferred architecture (data, functions, technology) System Modeling [2] Much of this information is derived from customer requirements

  43. Business Process Engineering • Data Architecture • Framework for the data objects used by the business (+ relationships) • Applications Architecture • Elements which transform data objects for a business purpose • Technology Infrastructure • Foundation for data & applications architectures

  44. BPEHierarchy [From SEPA 5/e]

  45. Information Strategy Planning • Focus: World View (entire business) • Goals: • Isolate domains of the business(engineering, marketing, sales, …) • Define data objects visible at the enterprise level (+ relationships & data flow)

  46. Business Area Analysis • Focus: Domain View (selected business area) • Goals: • Isolate functions and procedures that allow the area to meet its goals • Define data objects visible at the business area level (+ relationships & data flow) • Identify information support systems

  47. Business System Design • Focus: Element View(specific information system in a business area) • Goals: • Model the requirements • Design: • Data Architecture • Applications Architecture • Technology Infrastructure

  48. Construction & Integration • Focus: Detailed View(implementation of an element) • Goals: • Implement the architectures and infrastructure • Insert the completed system into the business area (training, logistics, …)

  49. ProductEngineeringHierarchy [From SEPA 5/e]

  50. Elicitation Analysis & Negotiation Specification Modeling Validation Management Requirements Engineering How can we specify a system that meets the customer’s needs and expectations?