Presentation of se
-
Upload
usman-bin-saad -
Category
Engineering
-
view
263 -
download
0
Transcript of Presentation of se
SYSTEM ENGINEERING
1
Name : SYED KEYAN ALI TAHIR (124) USMAN BIN SAAD (118) SHAHID IQBAL (160) M.RAMZAN (074) M.BILAL
SUBMITTED TO:Mehreen Akhter
What is system engineering:-
• It is an approach to design, Implement and evaluate successful development of complex system.
2
Jobs for system engineers:-• System engineer• Mission operation planner• Safety engineer• Airworthiness and certification engineer• Missile defiance national team chef engineer• Signal intelligence analyst• System integration engineer• Ground test planning engineer• Space craft system engineer
Duties of software engineer:-• Engineer have to ensure must that all things are working
properly• They have to create new and latest ideas for their companies• Technical work also required in field• Coordination , leadership and organisation important aspects of
job• They are ready to cooperate with other in daily life
System Engineering•Elements of a computer-based system• Software• Hardware• People• Database• Documentation• Procedures
5
SystemsA hierarchy of macro-elements
6
World viewBusiness or
Product Domain
Domain of interest
Domain view
System element
Element view
Detailed view
System Modeling
• define the processes that serve the needs of the view under consideration.
• represent the behavior of the processes and the assumptions on which the behavior is based.
• explicitly define both exogenous and endogenous input to the model.• exogenous inputs link one constituent of a given view with other
constituents at the same level of other levels; endogenous input links individual components of a constituent at a particular view.
• represent all linkages (including output) that will enable the engineer to better understand the view.
7
Business Process Engineering
8
uses an integrated set of procedures, uses an integrated set of procedures, methods, and tools to identify how methods, and tools to identify how information systems can best meet the information systems can best meet the strategic goals of an enterprisestrategic goals of an enterprise
focuses first on the enterprise and then focuses first on the enterprise and then on the business areaon the business area
creates enterprise models, data models creates enterprise models, data models and process modelsand process models
creates a framework for better creates a framework for better information management distribution, information management distribution, and controland control
System Architectures• Three different architectures must be analyzed and
designed within the context of business objectives and goals:
• data architecture• applications architecture• technology infrastructure
• data architecture provides a framework for the information needs of a business or business function
• application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose
• technology infrastructure provides the foundation for the data and application architectures
9
The BPE Hierarchy• Information strategy planning (ISP)ostrategic goals definedosuccess factors/business rules identifiedoenterprise model created
•Business area analysis (BAA)oprocesses/services modeledointerrelationships of processes and data
•Application Engineeringoa.k.a ... software engineeringomodeling applications/procedures that address (BAA) and constraints of ISP
•Construction and deliveryusing CASE and 4GTs, testing
10
Information Strategy Planning• Management issueso define strategic business goals/objectiveso isolate critical success factorso conduct analysis of technology impacto perform analysis of strategic systems
• Technical issueso create a top-level data modelo cluster by business/organizational areao refine model and clustering
11
Defining Objectives and Goals•Objective—general statement of direction
•Goal—defines measurable objective: “reduce manufactured cost of our product”o Subgoals:
decrease reject rate by 20% in first 6 monthsgain 10% price concessions from suppliersre-engineer 30% of components for ease of
manufacture during first year •Objectives tend to be strategic while goals tend to be tactical
12
Business Area Analysis•define “naturally cohesive groupings of
business functions and data” (Martin)•perform many of the same activities as ISP, but narrow scope to individual business area
• identify existing (old) information systems / determine compatibility with new ISP modeldefine systems that are problematic defining systems that are incompatible with new information model
begin to establish re-engineering priorities
13
The BAA Process
14
salesacct
manufacturing
QC
eng’ring
distribution
admin.
DataModel
ProcessDecomposition
DiagramMatrices
e.g.,entity/process
matrix
Process Flow
Models
Product Engineering
15
System analysis(World view)
The completeproduct
capabilities
Componentengineering
(Domain view)
Processing requirement
Analysis & DesignModeling
(Element view)
Construction&
Integration(Detailed view)
software
function
SoftwareEngineering
programcomponent
hardware
data behavior
Product Architecture Template
16
user interface processing
inputprocessing
outputprocessing
maintenance and self-test
process and controlfunctions
Architecture Flow Diagram
17
bar codereader
subsystem
bar codedecoding
subsystem
data baseaccess
subsystem
shuntcontrol
subsystem
reportformating
subsystem
diagnosticssubsystem
operatorinterface
subsystem
shuntcontroller
mainframecommunications
driver
operator requests CLSS queries, reports, displays
shunt control statusbar code acquisition request
bar code
pulse tach input
linespeed
bar codereader status
sensor status
raw barcode data
partnumber
reportrequests
binlocation
key
sort records
formatedreporting data
sorting reports
shunt commands
CLSS reports
BCR statusshunt status
communications status
timing/location data
operatorinterface
data acquisitioninterface diagnostic interface output interface
CLSS processing & control
sensor dataacquisitionsubsystem
System Modeling with UML•Deployment diagrams
• Each 3-D box depicts a hardware element that is part of the physical architecture of the system
•Activity diagrams• Represent procedural aspects of a system element
•Class diagrams• Represent system level elements in terms of the data that describe the element and the operations that manipulate the data
18
Deployment Diagram
19
CLSS processor
Sorting subsystem
Sensor dataacquisition subsystem
Operator display
shunt controller
Conveyor Pulse tach
Bar code reader Shunt actuator
Activity Diagram
20
get conveyor speed
send shuntcontrol data
get shunt status read bar code
start conveyor line
determine bin location
valid bar code
set for reject bin
conveyor in motion
read bar code
get conveyor status
produce report entry
conveyor stopped
invalid bar code
Class Diagram
21
Box
barcode forwardSpeed conveyorLocation height width depth weight contents
readBarcode() updateSpeed() readSpeed() updateLocation() readLocation() getDimensions() getWeight() checkContents()
class name
attributes note use of capital letter for multi-word attribute names
operations (parentheses at endof name indicate the list of attributes that theoperation requires)
Requirements Engineering• Inception—Establish a basic understanding of the problem
and the nature of the solution. • Elicitation—Draw out the requirements from stakeholders.• Elaboration—Create an analysis model that represents
information, functional, and behavioral aspects of the requirements.
• Negotiation—Agree on a deliverable system that is realistic for developers and customers.
• Specification—Describe the requirements formally or informally.
• Validation—Review the requirement specification for errors, ambiguities, omissions, and conflicts.
• Requirements management—Manage changing requirements.
22
Inception•Ask “context-free” questions
• Who is behind the request for this work?• Who will use the solution (product/system)?• What will be the economic benefits?
• How would you characterize “good” output from the system?
• What problems does this solution address?• What environment will the product be used in?
• Are you the right person to answer these questions?• Are these question relevant?• Can anyone else provide additional information?• Should I be asking you anything else?
23
Getting Requirements Right• “ The hardest single part of building a software system is deciding what to build. No part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”
—Fred Brooks
• “The seeds of major software disasters are usually sown within the first three months of commencing the software project.”—Capers Jones
• “We spend a lot of time—the majority of project effort—not implementing or testing, but trying to decide what to build.”—Brian Lawrence
24
Eliciting Requirements• Why is it so difficult to clearly understand what the customer wants ?• Scope
• The boundary of the system is ill-defined.• Customers/users specify unnecessary technical detail that may confuse
rather than clarify objectives.• Understanding
• Customers are not completely sure of what is needed.• Customers have a poor understanding of the capabilities and limitations of
the computing environment.• Customers don’t have a full understanding of their problem domain.• Customers have trouble communicating needs to the system engineer.• Customers omit detail that is believed to be obvious.• Customers specify requirements that conflict with other requirements.• Customers specify requirements that are ambiguous or untestable.
• Volatility• Requirements change over time.
25
Collaborative Requirements Gathering
• Meetings are attended by all interested stakeholders.• Rules established for preparation and participation.• Agenda should be formal enough to cover all important
points, but informal enough to encourage the free flow of ideas.
• A facilitator controls the meeting.• A definition mechanism (blackboard, flip charts, etc.) is used.• During the meeting:
• The problem is identified.• Elements of the solution are proposed.• Different approaches are negotiated.• A preliminary set of solution requirements are obtained.• The atmosphere is collaborative and non-threatening.
26
Quality Function Deployment
• Function deployment determines the “value” (to the customer) of each function required of the system.• Information deployment identifies data objects and events.• Task deployment examines the behavior of the system.• Value analysis determines the priority of requirements.
27
Elicitation Work Products• Statement of need and feasibility.• Statement of scope.• List of participants in requirements elicitation.• Description of the system’s technical environment.• List of requirements and associated domain constraints.• List of usage scenarios.• Any prototypes developed to refine requirements.
28
Use-Cases• A use-case scenario is a story about how someone or
something external to the software (known as an actor) interacts with the system.
• Each scenario answers the following questions:• Who is the primary actor, the secondary actor(s)?
• What are the actor’s goals?• What preconditions should exist before the story begins?• What main tasks or functions are performed by the actor?• What exceptions might be considered as the story is described?• What variations in the actor’s interaction are possible?• What system information will the actor acquire, produce, or
change? • Will the actor have to inform the system about changes in the
external environment?• What information does the actor desire from the system?• Does the actor wish to be informed about unexpected changes?
29
Use-Case Diagram
30
Elements of the Analysis Model
• Scenario-based elements• Use-case—How external actors interact with the system (use-case diagrams; detailed templates)• Functional—How software functions are processed in the system (flow charts; activity diagrams)
• Class-based elements• The various system objects (obtained from scenarios) including their attributes and functions (class diagram)
• Behavioral elements• How the system behaves in response to different events (state diagram)
• Flow-oriented elements• How information is transformed as if flows through the system (data flow diagram)
31
Activity Diagram
32
Class Diagram
33
State Diagram
34
Negotiating Requirements• Identify the key stakeholders
• These are the people who will be involved in the negotiation
•Determine each of the stakeholders “win conditions”• Win conditions are not always obvious
•Negotiate• Work toward a set of requirements that lead to “win-win”
35